This week I read a blog post that I thought really related to the class about the history of software development. The blog goes over software development’s history from early computers to development today. The blog starts off with early computers, giving interesting facts like how the first piece of software was made with punch cards, and took 52 minutes to complete calculations. Then, there is a section about personal computers that people have in their homes. The section goes into how programming languages were becoming more well known, and how people started using computers outside of work in the mid-1990s. After, there is a paragraph about mobile computing devices, and how they developed from IBM Simon in 1994, and programmers starting to create phone apps in the 2000s to our smartphones of today. The blog ends with the software development of today. The ending is about how old programming languages are still used, and new languages are being made today. The ending also describes how modern software development is enhancing “dumb” devices by putting chips in them.

 I selected this blog post because software development is my dream job, and I thought it would be interesting to read about the history of it. This blog has a great way of showing how software has progressed over time ,and I think every CS major should read it since we do not want history to repeat itself.

 I think this blog was a great read that I recommend for many reasons. One reason I would recommend this blog is because it is a good history lesson for people that are interested in software development. It is good to learn about the past, so that we could prevent similar mistakes from happening again. Another reason I would recommend this blog is because it has a lot of interesting facts for people interested. One example is when the blogger writes about how the IBM Simon was the first predecessor to smartphones in 1994, and it even had a touchscreen and email! The last reason I would recommend this blog is because it could help having this knowledge in a future job to show how interested you are in software development, and how knowledgeable you are in the area.

This blog taught me about how software development has progressed through time from software that needed an hour to run to our technology of today. The material affected me heavily because it showed me how programming languages from early in its history, like C, are still used today. It makes you really think about how much was overachieved in the beginning, or is being underachieved now. I will use this knowledge to try and further software development in my future.

https://praxent.com/blog/history-of-software-development-innovation

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.

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.

https://www.monterail.com/blog/vue-vs-react-2021

Web development has never been my main area of interest. It’s not the environment I’m the most comfortable in, especially when dealing with projects involving many different frameworks and libraries. In order to prepare myself to contribute something useful to the LibreFoodPantry project, I basically picked a framework out of a hat from what I roughly remember in class. As a result, I’m reading up on Vue.js.

Vue (pronounced “view,” which I am still struggling to pronounce correctly when reading) is a frontend framework, meaning it is used as a way to streamline creating the user interface of a website (as opposed to the backend, which refers to work done on the server’s end, or the API layer, which connects the frontend and the backend).

Vue was created by a solo developer named Evan You, and is currently maintained by him and a small team. It allows users to either define the site’s interface in JSX as one would do with React.js or in HTML templates. It is well-documented and considered easy to learn by many developers. It is suitable for small projects, but can also scale to larger ones. It is progressive, meaning that features can be introduced to a project incrementally as they are required.

As someone without a lot of intuition around tech stacks, I figured it would be a good idea to find an article that compared Vue to another framework, rather than just reading about it on its own. The article linked above compares it to React, an older and more well established frontend framework created and maintained by Facebook. It is not as thoroughly documented, but has a much larger community of developers. Unlike Vue, you can only use JSX with it. It is also primarily meant for large projects, and developers of smaller projects using React might fight themselves with a lot of unnecessary boilerplate.

Both Vue and React use the concept of a Virtual DOM, meaning that they modify the state of the HTML document but only change it dynamically as is needed, rather than reloading the entire thing. They both have large libraries of components that can be added for additional functionality (Vue’s is smaller but has more officially maintained components). Vue and React also show similar performance.

Vue and react both have pros and cons. My instinct is to avoid boilerplate as much as possible, and I can’t imagine I will be working on lots of very large web apps, so I think I would generally prefer Vue over React, if it was up to me to choose one, especially since you can pick and choose how much of its complexity you want to worry about.

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

Considering how far along we are now in the semester, I decided to revisit a much earlier topic, design patterns. For this week’s blog post, I am going to look at a post by Ravi Kiran, a research analyst at Edureka. In class, we covered what are design patterns and what are some examples of design patterns and in this blog post, Mr. Kiran starts off the same way by introducing the audience to what are design patterns and why we use them. Then he begins to talk about what are the four categories of design patterns which are creational, structural, behavioral, and JEE (Java EE-based). The blog then proceeds to list examples of design patterns, what categories the design pattern falls under, and explains a little bit about why that design pattern falls under that specific design pattern category. The blog post does not explain all of the examples but instead for the ones that it does explain, it explains it very well in the form of a UML diagram and snippets of Java code. In addition to all of the technical information, this blog post gives us, it also gives real-world examples where that design pattern can be applied.

I chose this topic because when we were learning about this topic in class and when we did a homework assignment, I found the topic to be very interesting. I really wished we had spent more time on this topic in class. It was only after reading this post that I realized in class and on the homework, most of the design patterns that we covered in class fall under the creational or structural categories. After learning about the Singleton pattern in class and working on it on the homework, I think conceptually I understood the topic, but after not working on it for some time and revisiting the topic, I think I understand it better now than I did back then. One of my regrets early on in the semester was not doing the Advanced Assignment working with the Factory design pattern. When I was reading about that design pattern for the assignment, I found it interesting and thought I understood the topic, but I did not do the assignment because I was not sure if I understood the topic well enough to do the assignment. After reading more about the topic and seeing the UML diagram, it validated my thinking about the topic. I am the kind of person who second guesses themselves a lot and after reading this blog post, it makes me want to just go for it the next time I don’t quite understand something or understand it completely. I feel like if I just did the assignment back then I probably could have done it but I second-guessed myself.  

https://www.edureka.co/blog/java-design-patterns/

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.

Hello everyone! Hope everyone is doing great! In This week’s blog post I want to write about the front end and the back end and what are the differences between them. Front end and back end are the two most popular terms used in web development and they are very crucial for web development and are quite different from each other. Web development is the process of building websites and applications, Unlike UI UX Design, web development focuses more on coding and making sure the website functions well. Both the front end and bank end need to communicate with each other for the website to operate effectively and to improve the website’s functionality.

Front-end development is a style of computer programming that focuses on the coding and creation of elements and features of the website. This is the part of the website that the user interacts with and can be also referred to as the ‘client side’ of the application. This means as a front-end developer your job is to code and bring to life the visual elements of the website. It includes everything that users directly experience such as text colors and styles, images, graphs and tables, buttons, colors, navigation menu, animations, and content organization. The languages used in Front end development are HTML, CSS, and JavaScript. Responsiveness and performance are two main objectives of the Front end. The developer must make sure the site is responsive.

The back-end is also referred to as the “server-side” of the website and focuses on the side of the website user can’t see. It stores and arranges data, and makes sure everything on the client-side of the website works fine. As an example, let’s say you are using a social media website, you need an accessible place to store all the user’s information, this storage is called database systems such as Oracle, SQL Server, and MySQL, these are not seen by users and done at the back end of the website. Back-end uses languages such as PHP, C++, JAVA, Python, JavaScript, and Node.js.

The difference between the frontend and back end is that they work on different sides of a website which is the client-side and server-side, both have different strengths, both work in different languages. I used this article because it makes the front end and back end very easy to understand and In the future if I work as a web developer it’s very important to know about these concepts.

https://www.kenzie.academy/blog/front-end-vs-back-end-whats-the-difference/

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

REST stands for REpresentational State Transfer. It was introduced by Roy Fielding as a part of his doctoral dissertation. It’s purpose is to allow the use of data while not having it tied to an entity specifically. This allows the data to be represented differently through various mediums we refer to as hypermedia. 

A RESTful interface is resource dependent. In order for an application to follow REST guidelines, it must adhere to a set of constraints. The first constraint states an interface should interact on a client-server basis. The client machine should be able to make requests to the server, and in return the server will respond according to the information it received. 

The second constraint states the client-server interaction must utilize a uniform interface. In order for the client and server to interact RESTfully, the use of Universal Resource Identifiers (URIs) is imperative. Any resource that is involved between the client and server must be identifiable in order for the interaction to be successful. 

Thirdly, all requests between the client and server must be stateless. This means that a request made from the client side must have all the necessary information so the server can complete the request. This is necessary to keep the workload on the server to a minimum as it handles various requests from different clients. The burden of keeping track of the session state of the application is the responsibility of the client, and it basically gives a snapshot of the current state to the server when the request for additional resources is made. 

The fourth constraint states that any response from the server must either be cacheable or non-cacheable. This will allow the client to reuse data from a request for a certain period of time (if the server allows it) without having to resend the request to the server.

The fifth constraint states that the client and server should have layers in between them. This allows legacy systems to have continued support as improvements and new features are added to the system. This will continue to work as long as the implementation of the interface has not been changed.

The last constraint is an optional one and it’s called code on demand. This constraint states that the functionality of a client can be extended by allowing code to be downloaded and executed. This allows the client to be simpler.

While I found all of this to be informative, I was mostly taken aback that the formulation of this architecture is to be accredited to a student pursuing their doctorate degree. It places things in perspective for me that any assignment that I am given does not only have to be completed for a grade, but it can be used as an opportunity to change the way the world interacts with things.

The information that I conveyed in this post is all thanks to two the following links

https://restfulapi.net/

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

This week I took a look at some of the popular acronyms that are out there and wanted to focus on the SOLID principles. SOLID is a set of design principles introduced by Robert C. Martin in the essay, “Design Principles and Design Patterns,” written in 2000. Martin argues that without good design principles, a number of design smells will occur. I thought that this would be a fitting topic to cover since I am learning about clean code in my Software Process Management class. SOLID is an acronym for a set of five commonly used principles among software developers:

Single Responsibility Principle – A class should have one, and only one, reason to change. In order to follow this principle, a class or any module should simply serve one purpose. It is important to prevent functions from doing more than one thing, which can be done by keeping them small. By utilizing this principle, code is easier to test and maintain in the future. 

Open-Closed Principle – Changing a class can lead to problems or bugs. Martin argues that you should be able to extend a class’ behavior without modifying it. In order to have a class that is open for extension but closed for modification, use abstractions. Through the use of interfaces and inheritances that allow polymorphic substitutions, one can follow this principle. In doing so, code is easier to maintain and revise in the future.

Liskov Substitution Principle – Named after Barbara Liskov, this principle requires that every derived class should be substitutable for their base or parent class. This is a way of ensuring that derived classes extend the base class without changing the behavior. Implementing this principle is like implementing the open-closed principle, as it prevents problems or bugs brought about by any class changes.

Interface Segregation Principle – The idea of this principle is that it is better to have multiple smaller interfaces as opposed to a few bigger ones. Developers should be inclined to build new client-specific interfaces, instead of starting with an existing interface and making changes. 

Dependency Inversion Principle – Martin states, “Depend upon Abstractions. Do not depend upon concretions.” meaning every dependency in a design should target an interface or abstract class. No dependency should target a concrete class. Being able to utilize this principle will make your code more flexible, agile, and reusable. 

While these principles are certainly not a fool proof method of avoiding code smells, they offer many benefits when followed correctly. It has become good practice for developers to follow these principles in order to keep code clean so as to not introduce any problems with future changes. I think this is a very useful set of principles to follow, and I plan to refer to it for anything I plan to develop in the future. These principles drew ideas from the concept of code smells and clean code, so it was interesting to finally connect the topics that I’ve been learning about in two different classes.

The Importance of SOLID Design Principles

Design Principles and Design Patterns

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Hello blog (mood-status: feeling tired), writing this blog after the family dinner party on a Saturday night. But anyway, on writing about this week-12. Same reason from last-blog, I writing this once again because I am falling behind on blogs when there is nothing to talk about, besides kept being busy with other courses like HWs and projects, etc. (You get the point. Well, if you are a student) 

I decided to go on the Syllabus once again to look at the course topics.

Then I choose the subject of Refactoring.

Refactoring is used to restructure an existing code body, altering its internal structure without changing its external behavior. It’s small behavior-preserving transformations. Each transformation does minor parts, but a sequence of these transformations can produce a significant restructuring. Since each Refactoring is minor, it cannot go wrong. After each Refactoring, the system maintained fully working and reduced the chances of a system breaking during the restructuring.

Refactoring can help lower the cost of intensification. When a software system is robust, there is to keep intensifying it, fix problems, and add new features. But the quality of a codebase makes a big difference in how light it is to make these changes. Often intensifications are applied on top of each other to make it frequently more challenging to make changes. From setting this change, it’s essential to refactor code so that added enhancements don’t lead to unnecessary complexity.

Refactoring is a part of everyday programming. When Refactoring isn’t a particular task that would show up in a project plan, it’s a regular part of programming. When it’s needed to add a new feature to a codebase, look at the current code and consider whether it’s structured to make the recent change straightforward. Refactor the present code to make this new addition easy if it isn’t. Refactoring first in this way is faster than if it hadn’t carried out the Refactoring first.

Once the code program has finished, the change, then added to the new feature. Also, it said it apart and got it working; the notice appears that the resulting code, refactor it into a better shape return to code to become less confusing from how it works. When modifying a program, much of what needs to do already encode into the program. This code may be functions I can quickly call or hidden inside more significant parts. If it is difficult to understand the code; It refactors won’t have to work again next time.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Hello blog (mood-status: feeling tired), writing this blog after the family dinner party on a Saturday night. But anyway, on writing about this week-12. Same reason from last-blog, I writing this once again because I am falling behind on blogs when there is nothing to talk about, besides kept being busy with other courses like HWs and projects, etc. (You get the point. Well, if you are a student) 

I decided to go on the Syllabus once again to look at the course topics.

Then I choose the subject of Refactoring.

Refactoring is used to restructure an existing code body, altering its internal structure without changing its external behavior. It’s small behavior-preserving transformations. Each transformation does minor parts, but a sequence of these transformations can produce a significant restructuring. Since each Refactoring is minor, it cannot go wrong. After each Refactoring, the system maintained fully working and reduced the chances of a system breaking during the restructuring.

Refactoring can help lower the cost of intensification. When a software system is robust, there is to keep intensifying it, fix problems, and add new features. But the quality of a codebase makes a big difference in how light it is to make these changes. Often intensifications are applied on top of each other to make it frequently more challenging to make changes. From setting this change, it’s essential to refactor code so that added enhancements don’t lead to unnecessary complexity.

Refactoring is a part of everyday programming. When Refactoring isn’t a particular task that would show up in a project plan, it’s a regular part of programming. When it’s needed to add a new feature to a codebase, look at the current code and consider whether it’s structured to make the recent change straightforward. Refactor the present code to make this new addition easy if it isn’t. Refactoring first in this way is faster than if it hadn’t carried out the Refactoring first.

Once the code program has finished, the change, then added to the new feature. Also, it said it apart and got it working; the notice appears that the resulting code, refactor it into a better shape return to code to become less confusing from how it works. When modifying a program, much of what needs to do already encode into the program. This code may be functions I can quickly call or hidden inside more significant parts. If it is difficult to understand the code; It refactors won’t have to work again next time.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.