As a trend from the previous posts, I am still working with JavaScript, and I am still learning more and more about it. In this article I learn some best practices around JavaScript itself. Some new things and some things common for any programming language.

https://www.w3.org/wiki/JavaScript_best_practices

There is not much to summarize for this article as it is simply some best practiced coding techniques for proper JavaScript coding. Like mentioned earlier it does include some things that by now I should already know and practice. As in comments should be as needed but not in excess, naming conventions should be simple and understandable, Big O notation matters and to optimize your loops and avoid nesting them and keeping to clean code style of one function one purpose instead of excess purposes inside a function that might be iterated out later or nonsensical to someone code reviewing. But there were some more JavaScript specific practices that were more related to web development.

                Progressive Enhancement is a concept that I get on a basic level just thinking in terms of providing a service to someone means going through the barriers of your platform to make sure they have access to it, like Microsoft office products working on mac. In this article it mentions the idea that when scripting or perhaps even JavaScript itself is not available to a platform that you need to manage the code in a style that will work with any platform. To me that seems easier said than done but it does make sense that if the interface to the user can be managed by something else before scripting is done then you achieve your goal of progressing your user base and opening your code up.

                Another practice I learned was regarding data security. That at any time any data being passed through my code should be checked first. I have heard examples of specific businesses being hacked due to a very specific fault in the design itself that left open vulnerabilities which lead to personal information being stolen. Most cases I have heard is simply the human aspect in security vulnerability where a hacker just calls to get access to a password for an account that can then access that data. But in the examples given in the article it is specific to making sure that the data passed to you does not fault in error and that there is some methods that allow you to discern data types from another to avoid further conflicts or generally avoid validation on the users end to prevent them messing with your own websites code.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

This week I read a blog post that I thought really related to the class about custom software development. The blog started with a section about the process of custom software development. It consists of research, UI design, MVP development, testing, maintenance, and monitoring/support. The blog then goes into why it can be for you. It gives reasons like how it makes your business more unique, and personalized to the needs of your business. The next section finally goes into the 7 benefits. They are a personalized process, cost-effective, reliable, continuous support, flexibility, seamless integration, and exclusive ownership. I see all those benefits as a definite win, especially how you would be making it your own, and nobody can take it from you. The blog ends by going over how the advantages outweigh the negatives, and how they are too evident not to use.

 I selected this blog post because software development is my dream job, and I thought it would be interesting to read about custom software development since I have never heard of it before. This blog did not disappoint in that aspect, and I think it will help tons of others as well.

 I think this blog was a great read that I recommend for many reasons. One reason I would recommend this blog is because it goes in-depth on the different benefits. It makes a section for each benefit, and explains how it is a benefit. An example of this is with the cost-effectiveness benefit. The blog writes about how this is a huge benefit because since it is custom, you will only be paying to make it, but in the long run it will last you the entire time. Another reason is because custom software development could be something that you will need to know to do in the future, and it is good to know why it is so important. Then, when the time comes in the future, you will be ready. The final reason I will be going over is because it shows how the benefits outweigh the disadvantages. If anyone thinks custom software development is not worth it, maybe this blog could help them change their mind.

This blog taught me about how custom software development is really beneficial, and it should be used the most often. The material affected me heavily because it showed me that custom software development will be widely needed in the future, so I got to understand it. I will use this knowledge to try and further software development in my future.

From the blog CS@Worcester – Anesti Blog's by Anesti Lara and used with permission of the author. All other rights reserved by the author.

DRY, or “Dont Repeat Yourself” is an approach to writing code that emphasizes avoiding repetition in your code. In other words, “Dont Repeat Yourself” is essentially a way to tell developers to write methods for anything they think they might need to use in more than one place. For example imagine you are writing a program where certain parts of the code need to do similar things. One way to approach this problem is to write a segment of code to do the necessary task each time the need for it comes up. While this would work in practice, it is far from the best way to approach this issue. Solving the same problem by creating a separate method that achieves the intended goal and can be called whenever it is needed is a far better and more time efficient solution. Geeks for Geeks has a great concise article about this, and even gives some example using java code.

And that really it as far as “Dont Repeat Yourself” goes. Its a straightforward rule that helps keep developers from wasting time writing repetitive code snippets. While it may seem simple to implement, I know for a fact that I have had plenty of experience writing repetitive code. During my first internship especially. The issue came down to the ever changing project requirements, and my need to adjust my code to meet those requirements. In doing that I know that I definitely wrote repetitive code that could have been its own separate class or function, however as I was working on many different files and pieces of the code, it didnt resonate with me at first that some of this code can be written as one method and called as needed. Eventually while I was polishing up some of the code I realized this mistake and corrected for it. I wrote functions that accommodated most of what the repetitive code was supposed to do and replaced that code with calls to these new methods. This ended up causing many small bugs to pop up however, and I had to spend more time looking for them and fixing them. Had I slowed down when writing my code I would have been able to plan ahead and create these functions from the get go; saving me time and energy in the long run. Going forward I try to be more careful with the code that I write; and try to think ahead to what may need to be reused. Once I figure that out I can create a function for it and save myself time and energy later on.

https://www.geeksforgeeks.org/dry-dont-repeat-yourself-principle-in-java-with-examples/

From the blog CS@Worcester – Sebastian's CS Blog by sserafin1 and used with permission of the author. All other rights reserved by the author.

This is a presentation given at the WeAreDevelopers World Congress 2018. WeAreDevelopers is a Vienna based company designed to connect developers seeking jobs with companies presenting employment opportunities. They primarily do this through conferences and events where they host speakers discussing myriad topics relating to IT and Software Development. This specific presentation was given by Daniel Lebrero and he discusses four habits that he’s noticed that efficient developers have. He breaks all four of these habits down into smaller facets that exemplify the habit. E.g. breaking down “Fast Feedback” into “Test-Driven Development”, “REPL”, “Code Reviews” and “Continuous code reviews.”

I chose this specific presentation because it directly relates to what we do in class on a daily basis. Everyone should be making continuous progress to be more efficient in their work and being able to hear directly from someone in the industry what makes someone efficient, is one of the fastest and easiest ways to improve yourself. The speaker was clear and provided cogent, real world, examples of the habits discussed. He even coded little .js programs to show how a developer would utilize simple scripts to automate tedious work and explored different IDEs and CLIs that he was familiar with.

I found a lot of what he was saying held a lot of truth. I have noticed similar habits in hiring directors and successful people in the IT field. The two things in particular that resonated with me were the topics of “Focus” and “No menial work.” One thing that plagues my development cycles, whether that doing school work for one of my classes or tasks at my actual occupation, is distractions. Mr. Lebrero advises disabling notifications, to the point where you don’t even have the push notification number showing how many unread notifications you have. He claims that it takes between ten and fifteen minutes every time your work is interrupted to get back on task and to return to the headspace you were in prior to the interruption. I agree that, while I am working, any little distraction throws me completely off track and makes it difficult to work. It’s important to have a quiet and clean workspace and lines of communication that don’t impede your work flow. Of course if something is urgent and worth the ten or fifteen minutes it takes to get back to work, that’s something completely different. On the matter of “No menial work” however, there really shouldn’t be any excuses. Whether a task is worth automating comes with experience and perspective, it’s important to fully understand your task and what’s being asked of you before you try to automate it; as it may take longer to code a small automation script than to just tough it out.

From the blog CS@Worcester – Jeremy Studley's CS Blog by jstudley95 and used with permission of the author. All other rights reserved by the author.

Deploying a large application with Docker often requires a number of Docker containers to be running at the same time and on the same network. Rather than orchestrating this manually, Docker offers an orchestration tool that makes this more manageable: Docker Swarm. I’ve come across the phrase “Docker Swarm” on occasion, but I never had reason to really look into it. It seems like a very useful tool, and I wanted to explore it this week with Gabriel Tanner’s “Definitive Guide to Docker Swarm.”

A Docker Swarm is comprised of a number of Docker hosts that run in “swarm mode.” These hosts act either as a manager that manages relationships between nodes or a worker that runs services.

Tanner defines a node as “an instance of the Docker engine participating in the swarm.” A device may run one or more nodes, but it is typical in deployment environments to distribute Docker nodes across multiple devices. Manager nodes take incoming tasks and distribute them to worker nodes. They also maintain the state of the cluster and manage orchestration. A swarm should have multiple manager nodes in order to maintain availability and to avoid downtime in the case of a manager node failure. Worker nodes exist to carry out commands from the manager nodes such as spinning up a container or starting a service. A manager node can also be a worker node and is both by default.

Services in a Docker Swarm are the definitions of tasks to be carried out by nodes, and defining a service is the primary way a user interacts with a swarm. Creating a service requires the user to specify a container image to be used and a set of commands to be executed.

Docker Swarm offers a number of benefits. It contains a built-in load balancer that allows you to dictate how services and containers are distributed between nodes. Swarm is integrated directly into the Docker command-line interface and does not require the installation of any additional software. It is easy to scale and allows you to apply updates incrementally.

I chose this source because I wanted to look more in-depth at some features of Docker I don’t have much experience with. I was not really sure what Docker Swarm was used for, so the context I gained from this article will surely be useful. I did not have space to cover it in this post, but Tanner’s article also details how to set up a Docker Swarm. I will definitely be saving this information for future use.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

For my final blog post I wanted to write about an important topic: software development processes. This relates to another class I am taking, Software Process Management, but I wanted to write a blog post about the topic in this class because it encompasses everything we have done in this class. In the same way that design patterns lay out a method for solving problems, the software development process lays out a method for designing software.

In a blog post published by Diceus, “Step by step software development: 7 phases to build a product”, the software development life cycle is laid out in 7 steps: Brainstorming, Feasibility Analysis, Design, Programming, Integration, Quality Assurance, and finally Release. Some of these steps relate more to this class, and others relate more to Software Process Management, but all of them are necessary to release a functional product.

Brainstorming, also called planning, is the most important part of the software development life cycle. This is the step where you think of products that customers would want, and an abstract thought of how you would implement the idea.

The next step is the feasibility analysis. This step does not relate to this class so much, but it is important to decide if a project is worth working on.

The next step is the Design step. This is the step where you design the product. I would imagine this is where the API is designed (not programmed) since you have to build your product around the API. I would also assume that design patterns are discussed and chosen based upon the product requirements in this step. I am not sure if UML diagrams would be designed here or during the programming stage since the source does not say, but I would not be surprised if class hierarchy is considered when planning.

The fourth step is Programming. This is the longest step, and is the grunt work of the designing phase. If UML diagrams were not already designed, they certainly will be during this step when programmers actually implement the code. I would also imagine this is the step where docker containers are set up.

The fifth step is Integration. This is the step where a product is integrated into all sources and environments. This step might also be where docker is set up, but I am not sure since the source does not mention containers.

The sixth step is Quality Assurance. This is another step which does not relate to this class very much, although I suppose excess technical debt can be managed during this step if it was not already during the programming step.

The final step is Release. This is the final step when your product is released to the consumer. This is the goal of every software development process.

I think that a good, organized roadmap is crucial for any product’s development, but it is also very important for software. Software is hard to develop, and systems like this make it easier.

From the blog CS@Worcester – Ryan Blog by rtrembley and used with permission of the author. All other rights reserved by the author.

As a big fan of LaTeX, I really enjoyed learning and using PlantUML in class. For those of you who do not know what UML is, UML stands for the Unified Modeling Language which is a language that allows us to create models/diagrams. It is commonly used to create some sort of visual to convey information to an audience. In class, we used PlantUML to show the relationship between classes but there are still a lot of things you can do with the language that we did not have time to cover in class.

In this first blog post by Rachel Appel, she goes over most of what we covered in class at a slightly slower pace.

In addition to covering what was covered in class, in her blog post, Ms. Appel also shows another way of using PlantUML diagrams. She shows us how to create USE diagrams. USE diagrams allow us to describe the relationship between users (or actors in Ms. Appel’s USE diagram) and the software and its components. I find this especially useful when describing to others the principle of user privilege or even from a managerial standpoint describing to your employees what information or resources, they have access to.

In the previous blog post, it talked about what kinds of diagrams you can make using PlantUML, and in this blog post, it talks about some style choices you can make in your diagrams and informs you about some features in PlantUML to organize your diagram.

https://www.codit.eu/blog/plantuml-tips-and-tricks/?country_sel=be

The blog post talks about many different features you can find in PlantUML. It talks about how to change the direction of the arrows, changing the box shape, changing the arrow color, and even adding a legend at the end of the diagram. The next topic that the post talks about text alignment and adding a background to your diagram. The post also talks about a couple of other really cool features you can do in PlantUML so be sure to give the post a quick read!

I picked this topic to do this week because it was in fresh in my mind after talking about it with one of my professors. It is also a topic that I found really interesting when we covered it in class at the beginning of the semester and is something I always wanted to learn more about. In the past, whenever I had to create a model for another class I used LaTeX, Excel and/or MatLab to generate the diagram and sometimes I had to jump through so many hoops to get the diagram to look the way that I wanted to. With PlantUML, there are a lot of built-in features that I can choose from and use so I can see myself using this knowledge in another class.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

This week I have chosen to continue to write about API’s and specifically the differences in all the API’s out there as REST shouldn’t be the only type of protocol used and learning more about the different kinds of API’s used will be a great boost in the future. I have chosen a blogpost that I think goes over these different kinds of API’s well enough for someone to start learning about the different kinds of API’s

In summary, Castellani goes over the main types of API,s which are Open API’s, Partner API’s, Internal API’s, and Composite API’s. An Open API is also called a public API in which it is publicly available to developers and user without much restrictions. The focus of this API is on the outside external users for third party services/data. A partner API is an API that is only given access to specific business partners and are used for outward communication outside the company. An internal API is also called a private API has many restrictions and is only worked on by the internal development teams. A composite API is a combination of multiple API’s and services. Castellani also goes over different protocols such as SOAP which stands for simple access object protocol which came before REST. It was the first to bring standardization in how to manage service using network services but was seen as too strict. There is also RPC protocol which stands for remote procedural call protocol which is the oldest out the three given. This protocol is hard to maintain and update and was used for client code execution.

This blogpost has given new bits of information on the different kinds of API’s out there. The way we have changed from the different rules and protocols to what we mainly use today. The previous versions were restrictive in their own ways and eventually were let go for what we have today. I wonder if eventually we will let go of REST and create a new set of rules to follow. There might be some situations where a certain protocol would be preferred over the over but people just mainly go for REST which is what we are working with in our API’s. There is also the parts on the different types of API’s and the one I have worked on is perhaps and open API and would like to see on how something like a composite API would look like to work with and handle.

Source: https://blog.axway.com/amplify-products/api-management/different-types-apis

From the blog CS@Worcester – kbcoding by kennybui986 and used with permission of the author. All other rights reserved by the author.

I wanted to do my next blog post on backends and frontends because we learned about them through the past few activities and while I have a general idea of how they operate, I want to clear up some confusion and get a better understanding of them. I was having some technical issues with my Visual Studio Code and Docker while working on those activities and spent some time getting them working, so I feel that I missed out on some parts of the work.

Based on the activities and my own understanding before doing more research, I saw the backend as the background code that makes the program work, while the frontend is what the user interacts with and uses the backend. The backend works with the API, endpoints, and paths that use the HTTP methods. The frontend works with the application and design, as well as being the interface for the user. They cooperate to run programs because they worked together in the activities to run the LibreFoodPantry data.

When looking more into the frontend and backend from an article from GeeksForGeeks called “Frontend vs Backend”, it was saying similar things about the two that were covered in the activities with the frontend and backend working as client and server sides of a program respectively. The frontend is the client side that the user directly interacts with, while the backend is the server side that runs the program and manages the data. The programming languages that the frontend uses are HTPP, CSS, JavaScript, and the ones that the backend uses are PHP, C++, Java, Python, JavaScript, Node.js, C#, Ruby, and REST.

As mentioned earlier, the frontend and backend sides act as two sides of a program that work together, with the frontend being what the users interact with, while the backend is not able to be seen by users but runs the code and even though it is not directly interacted with by the user, it runs what is interacted.

The main frameworks that the frontend uses are AngularJS, React.js, jQuery, SASS, and Flutter. The main frameworks that the backend uses are Express, Django, Rails, Laravel, and Spring.

I learned more about the fronted and backend aspects of web development through this article and reviewed what I knew from the activities that I may not have understood because I had to dedicate time to fixing the program so I could actually test it. I have a good understanding of how to work with the backend and frontend of a program, and can continue working on activities and homework.

https://www.geeksforgeeks.org/frontend-vs-backend/

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

After learning the backend concept, I have learned about the frontend concept for these weeks. Especially, I have a chance to work with the .vue files to build the frontend in my homework 6. Although I was given some lectures about the .vue file in class, I am not really sure about what I am supposed to do in these files. Moreover, there were a lot of new syntax that I had never seen before. Thus, I did some searches with a hope that I could find a good resource to help me learn about .vue file.

Vue Files is one of the resources that I find useful. This website will introduce to readers an overview of a Vue project, like what folders and files should be included in a Vue project. In particular, the site will focus on describing in detail what a .vue file is and what blocks should be included in a .vue file and how to write each block. From the web, I learned that a .vue file is a custom file format that uses HTML to describe a Vue component. Each component consists of three types of blocks, which are <template>, <script>, and <style>. Each block will contain different types of code. Specifically, <template> contains HTML code; <script> contains JavaScript code, and <style> contains the CSS style of the component.

Moreover, according to the webpage, I have learned a lot of new syntax which is used to build a template of a component. First of all, text interpolation whose syntax is {{myVariable}} is used only to specify any valid JavaScript expressions in the template; and it cannot be used to modify any HTML code. Moreover, the website also introduces to readers about directives which are Vue- specific syntax elements used in the template. For example, v-model is used to take inputs and to update the variable values. v-if/ v-else/ v-else-if is a conditional statement that works in the same way as the equivalent in JavaScript. v-for is used as a loop statement to generate lists of elements in the template. v-on is used to define an action to take if an event occurs, such as click, mouseover, focus, etc.

Furthermore, in the components section, the website also introduce some elements could be written in the vue component’s script block, such as name, data(), methods, props, mounted(), computed, watch, etc. The website also provide syntax and the purpose of each element to help readers understand and be able to write a complete vue component’s script.

In short, I believe this site is well worth my reading as it contains all the information that I need to do my homework-6. Furthermore, I find it useful because besides providing information about the .vue file, it also has specific examples for each syntax, so readers can practice with the new syntax directly on the website.

From the blog CS@Worcester – T&#039;s CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.