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.

When designing a frontend (like anything else in software development) it is important to choose your tools wisely. There are many different ways to write a frontend, but Vue.js and React.js are two of the most popular. Both Vue.js and React.js are JavaScript libraries which utilize JavaScript to generate webpages, although Vue.js is much more similar to classical web design.

In “Vue vs React in 2021: Which Framework to Choose and When” by Maja Nowak, Nowak discusses the main differences between the two frameworks. Before Nowak discusses the differences, they discuss the similarities since the two frameworks are similar. Both frameworks are virtual DOMs, which means webpages only update elements which are actually changed. They are also substantial libraries, which optimizes and reduces the amount of code needed to build websites.

Despite these similarities, these two frameworks are different in a multitude of ways. One major way in which they are different is syntax: Vue.js uses HTML whereas React.js is more similar to writing JavaScript code. This makes Vue.js easier to learn for web developers compared to React.js. This also means that Vue.js is weaker since React.js can use JavaScript’s flow control and advanced IDE features to improve design.

Vue.js is a much more lightweight option between the two, which has its advantages and disadvantages. For one, Vue.js being lightweight makes it easier to apply to smaller projects. Nowak notes that although Vue.js is lightweight that does not mean it cannot be used for larger projects. According to “State of Vue.js” the ease of integration is one of the biggest advantages of using Vue.js which is an aspect of being lightweight.

React.js is a much more advanced framework which may not necessarily be needed for every project, but may help significantly for some. React.js was designed by Facebook and is geared towards large-scale projects. Even though React.js is more difficult to learn, there are many more React.js developers compared to Vue.js. One major advantage of React.js is its programming style and patterns. React.js is much more similar to JavaScript which can be useful for developers to design a more complex application.

For me personally, I think I would enjoy React.js more than Vue.js. I have not designed any websites yet and have not gotten used to HTML. I think this would make it easier for me to learn React.js. Although I want to use React.js I will use whatever my employer requires. I don’t plan on doing much frontend work, but I do think it is a good skill to learn.

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

When writing code, it is always important to write as cleanly and efficiently as possible. Code can be sometimes confusing and hard to read to begin with, and writing poor code makes it much harder. We measure the quality of code using design smells. Design smells are different metrics such as rigidity and fragility which measure how poor a certain part of design is.

Yonatan Fedaeli writes in his article “Software Design Smells” that there are seven main design smells: rigidity, fragility, immobility, viscosity, needless complexity, needless repetition, and opacity. These smells exist in all code to a certain extent, but some code has much less smells than others. The goal is to limit each of these smells as much as possible.

Rigidity is software’s inability to change. This makes it very difficult to add new features to a project. An easy way to fix this design smells is by designing each section of software independently of each other since the more interdependence a project has the more rigid it will be.

Fragility is a software’s tendency to break whenever a change is made. This is similar to rigidity, but different in that it is not difficult to make the change but difficult to make the change work. Any small change can totally break the entire project in a very fragile design.

Immobility is a project’s inability to reuse components. When a project is immobile, each piece of the project is so dependent on the rest that is almost impossible to use it in a different context. When writing a large project it is important to reuse code so that you are not wasting time writing the same thing multiple times.

Viscosity is how closely a project follows the original design goal. When a project is very viscous each new feature either preserves a complex design or does not follow the design goal. When a project’s environment is viscous it means that the project exists in a complex work environment. It may be difficult to build or test and you may spend extra time trying to get the project to run.

Needless complexity is when a project is more complex than it needs to be. Software is already complex to begin with, and it is important to write clear code so that people reading it do not need to spend extra time trying to figure out what it does.

Needless repetition is when code is repeated multiple times when it could be abstracted. This is similar to immobility in that code is not reused, but different since this smell focuses on abstraction and how code does not need to be rewritten many times.

Opacity is a project’s inability to be understood by the developer. This is similar to needless complexity in that an opaque project can be needlessly complex, but includes much more than that. Usually an opaque project has a poor initial design which is why it is difficult to understand.

When writing code it is important to write clean, efficient code. Keeping design smells in mind when coding will keep your projects clean and good quality.

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

When designing an API it is extremely important to get it right the first time. API calls are the backbone of you application, and without well designed endpoints your frontend will not be able to communicate with your backend effectively, if at all. If you do not design your API with forward thinking in mind, you may end up redesigning many of your endpoints and a good portion of your application as well. The good news is that API design is usually left to experienced developers; the bad news is that experienced developers still mess up from time to time.

Since designing a good API is so important, there are many standard practices which will help you with your design process. “REST API Best Practices – REST Endpoint Design Examples” is an article written by Kolade Chris which outlines nine best practices that you should keep in mind whenever you are designing an API.

To begin with the simple practices, it is important to use JSON format for sending and receiving data. Firstly this is a good practice because it is industry standard, but more importantly it is designed to be used with many of the most common frontend languages, such as JavaScript, PHP, and Python.

Practices two and three are similar since they both relate to naming convention; use nouns instead of verbs as endpoints, and name your collections plural. The reason you should use nouns as endpoints is because the verb part is contained in your HTTP request such as POST or GET, so you can do GET /items. The reason you should use plural collection names is to indicate that it is in fact a collection and not a single item.

The fourth practices Chris mentions is to follow industry standard status codes. This is very important, but also not difficult to do; simply look up standard status codes and follow those.

Practices five and six are also similar to each other; they both relate to narrowing your search. When designing an API, you should use nesting to indicate how things relate to each other, and you should also use filtering, sorting, and pagination to narrow down a request which returns multiple values. For example, if you wanted to find a specific blog post by title you could design your endpoint like this: https://blog-website.com/users/userId/posts?title=query. This indicates that the post exists within the user endpoint, and also queries based on title.

An easy but important practice is to use SSL with your endpoints. When using SSL you will have https// instead of http//. The increased security is definitely worth the expense you might need to pay.

The final two practices are the most important: use semantic versioning and provide adequate documentation. It is important to use versioning when designing an API so that users are not forced to use the most updated version, and it is important to provide documentation so that users know how to actually use the API.

Following these practices does not guarantee that your API will be designed well, but it does ensure that you won’t have basic problems with it.

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

Docker is an open source technology which enables the easy use of containers for software development. Steven J. Vaughan-Nichols, in his article “What is Docker and why is it so darn popular?”, writes that “… over 3.5 million applications have been placed in containers using Docker technology and over 37 billion containerized applications have been downloaded.” Needless to say, Docker is quickly becoming industry standard with “… almost 40 percent market-share growth in 12 months.” For anyone looking to get into software development, it is an absolute requirement to learn how to use Docker or something very similar.

Docker containers attempt to copy a virtual machine setup without actually running an entire virtual machine. The main difference is that Docker containers all run on a single operating system instead of emulating multiple different operating systems. This allows for much more efficient usage of resources, and it is estimated that between four and six times as many applications can be run on a Docker system as opposed to the traditional virtual machine setup.

One major reason why Docker is so versatile is that it allows your project to be packaged with all of its requirements on the container; because of this you would not need to pre-install dependencies on each machine you wish to run your application on. This also allows you to run your applications on cloud services very easily; in fact, Docker is specifically tailored to run on cloud services such as Puppet, Chef, Vagrant, and Ansible.

Since Docker is easily integrated on cloud servers this means that it is also easy to emulate a live server build. When a developer wants to test a change on a live server they can simply run a container which is set up in the same way as a live container. These containers can be tested very fast and safely, and it is reported that developers who used this method had “three times lower rate of change failure”.

Personally, I believe Docker is the future of software development. There are many benefits to using Docker with very few drawbacks, if any. Although Docker may take some time to learn and get used to, it most certainly will make developers’ jobs much easier in the long run. I anticipate that Docker will quickly become industry standard due to the many benefits listed above. Docker is a great software which will allow designers to run more applications, on a multitude of different machines, with quick turnaround on updates and fixes.

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

Application Program Interfaces (API’s) are a set of queries/commands that a user is allowed to use, and are necessary when using microservice architecture. API’s can be considered the messengers between microservices, since they transfer data between services. REST API’s are API that conform to the REST model, which use JavaScript Object Notation (JSON) to transfer data. JSON is a human-readable data format and is used because it is easy to understand. In a blog post “What is an API? A Digestible Definition with API Examples for Ecommerce Owners” Matt Wyatt explains what an API is and why you would want to use it.

API’s use endpoints, which are URL’s that execute a certain method in the API. There are 4 default methods that are standard practice: GET, PUT, POST, and DELETE. GET will retrieve data from the API, PUT will update an existing entry in the API, POST will create a new entry in the API, and DELETE will delete an entry in the API. These methods are just the standard methods, and many others may be created by the developer of the API.

API’s are used in most applications available today. Whenever you do anything online, you are most likely using an API. API’s are so ubiquitous that it would be more difficult to find an application which does not use them. Using Facebook as an example, you would use a login API, a search API, a feed API, friend request API, and possibly many more which are not obvious to the user.

Benefits of using such API’s include increased security, faster response time, and the ability to scale certain features when needed. API’s allow applications to restrict what data they allow in and out, which greatly increases security. This control is paramount when used in an application which contains sensitive information, such as personal details or banking information.

Personally, I believe API’s to be an excellent solution to a wide range of problems. They can easily allow access to data and restrict it at the same time. I see similarities between API’s and Java classes; good Java classes have access methods (getters/setters) which control how the class is used, their attributes are mostly private, and their implementation is kept a secret from the user. A good Java class can be used by someone who has no knowledge of how it works behind the scenes, and the same is true for API’s.

In conclusion, I think API’s are a useful tool that I most certainly will be using in the future. Regardless of my future job, frontend or backend, I will need to either create API’s or use them. They are so universal that avoiding them is almost impossible, although I wouldn’t want to avoid them. They offer a simple solution to a very complex problem, and provide extra benefits along with it.

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