When I started studying computer science, I was unsure of what I wanted to do. As I learned, software development felt right for me, but that also asks another question, front end or back end? Initially, the front end seemed right for me, not for any particular reason other than working on the website felt better. However, after learning about both the back end and the front end, I am unsure now. 

In this blog post, Lane Wagner talks about their experience with front end development. They say that growing up, they wanted to be good at drawing, so that carried over into their computer science career. When they were working with front end things, they noticed that they focused their time on tweaking CSS, code for formatting the website, and it would always look bad anyways. They then decided that they wanted to become a back end developer instead, and talked about some other factors that affected their decision. These factors ranged from a number of things, such as pay and language preference, but the one that stuck out to me the most was feedback. They say that as a back end developer, you build code that is used by everyone, code like REST APIs, CLIs, and databases. This allows you to get feedback back from them in a way that is more constructive than if it was front end code, like UI. This lets you learn and improve.

After reading Wagner’s post, and reflecting on what I learned in class, I would also probably swing towards back end development too. The reason why I thought front end development would be better for me was because I am more artistic in a way. I also have a communication minor, so it would be a good way to combine the two. However, after learning both back end and front end, back end seems better to work with. The front end felt very convoluted to me, while the back end felt more seamless and streamlined. Maybe that was due to the fact that we spent more time learning the back end and playing around with it than the front end. Regardless, I would still love to learn more about both. I am still young, so learning both and maybe even working with both would help me choose which would be a better fit for me. But for now, back end development may be the better fit.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Growing up, sometimes when I would Google search things, the page would not load and instead, it would give me a code, typically a 404. I never understood what it was or what it meant until recently. The 404 is a REST API response code, a code that the server returns when a web page or URL requests something. There are a bunch of codes, ranging from successful requests to malformed URLs to unstable connections to the servers. But there is more to them than just response codes.

In this blog post, the Postman Team talks about everything REST API related, including their history, how they work, their benefits, some challenges, and go over some examples. REST API uses resources, which can be a number of things, such as a document, an image, or multiples of them. REST is able to use an identifier to determine the type of resource being used in interactions. REST API uses methods, which is the type of request that is being sent to the server. These methods are GET, PUT, POST, DELETE, and PATCH. Each does something different from each other, allowing the user and the server to do a multitude of actions. GET does what the name suggests, it asks the server to find the data you asked for, and then it sends it back to you. DELETE deletes the specified data entry. PUT updates the specified entry, PATCH will do a similar thing. POST will add a new entry. With these methods, they return codes, describing what happened with the request. 200 is a successful response, 201 is a successful creation, etc. There are a number of codes, going from 100 to 599, each with a different response. REST API is flexible, allowing you to do more with them. REST API is used mainly for web use, but can also be used in cloud services and applications. The benefits of using REST API include scalability, flexibility and portability, independence, and lightweight. The challenges of it though are endpoint consensus, versioning, and authentication. The blog post goes into detail about all this in their post.

I chose this blog post because it did a good job of explaining everything about REST API. It even has a YouTube video listed in the post, which also explains what is in the blog post. APIs are used everywhere, so it is interesting to learn about something that is essentially a part of all computer related things. Although this is REST API related, there are a number of APIs, each with something different that they offer.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

A good programmer and software developer will create code and software that is easy to maintain and modify. When problems arise, issues could be taken care of fairly easily. But sometimes, the easiest solutions are not the best ones, it could make the software more difficult to maintain or change. Using design patterns can help identify these issues and show some solutions to those issues. 

In class, we worked with a few design patterns, specifically the strategy design pattern, the singleton, and the simple factory pattern. Each one does something a little different from each other, but they help make things organized in a sense. We used them all together, implementing each one by one, but each could be used separately.

In this blog post, Giridhar Talla writes about design patterns, and describes them as an “existing solution.” They define design patterns as “solutions to commonly occurring design problems in developing flexible software using object-oriented programming.” Design patterns can vary, and can be grouped into 3 groups, creational patterns, creating objects to increase code flexibility and reuse, structural patterns, turning relations between objects and classes into complex structures, and behavioral patterns, defining how objects communicate with another. The specific design patterns Talla goes over are the singleton design pattern, the decorator design pattern, the strategy design pattern, the state design pattern, and the command design pattern. Each pattern is unique in its own way, flexible and simple. After reading, I found the state design principle very interesting. Instead of a lot of conditional statements, you could create multiple states. The user can change how the application works at runtime, which allows you to design finite state machines. I find this cool and unique, as it is something I have not personally done, but the concept seems really interesting.

A good programmer should be able to create reusable and extendable code, it is just good practice. Design patterns can help you make them flexible and maintainable. I chose this blog post because I thought design patterns were really useful and interesting, and I wanted to learn more about other kinds of patterns. Since design patterns are somewhat recognizable due to their reuse, it is not hard to explain unseen software to people who have not looked at it before. Even if it is done wrong, it will help you or a team understand what is wrong with the overall thing, and then from there, you can apply the correct one. I am fairly certain that I will be using these in the future.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

One of the first topics we were introduced to was UML diagrams, which are diagrams that represent something, like the order or the makeup in a visual way. In class, we learned UML class and sequence diagrams. The class diagrams visualize the code files, listing off necessary information, like variables and methods, whether they are private, public, static, abstract, and can have notes for things with special cases. The sequence diagram visualizes the sequence of lines of code in main. UML was also used in making diagrams to explain the architecture of systems.

In this blog post, by Nishadha, they go into detail about types of diagrams and provide examples. UML stands for Unified Modeling Language, and is used to model “software solutions, application structures, system behavior and business processes.” There are 14 types of diagrams, which can be organized into 2 kinds, structure diagrams and behavioral diagrams. The structure diagrams “show different objects in a system.” The class diagrams and architecture diagrams belong to this group. The behavioral diagrams “show what should happen in a system.” The sequence diagrams belong in this group.

Structure diagrams are used to show the relationship between classes and/or objects in a software system. There are seven different diagrams, class, component, deployment, object, package, profile, and composite structure. Each offers something a little different from the other, but do essentially the same thing. Class diagrams show the relationship of classes in software, but object diagrams show the relationship of objects in a real life setting. Finding one to use that matches the situation you need it for is not hard. 

Behavioral diagrams are used to show how things are supposed to work. Like structure, there are also seven, use case, activity, state machine, sequence, communication, interaction overview, and timing. Each are more unique compared to each other than the structure diagrams are, but also do the same thing, showing the flow of it. The flow of logging into an account, the flow of shopping, the flow of code, etc. By visualizing the flow, it can allow you to see what is happening, spots that could have issues, and maximize it to be the best it can be. The post includes examples and templates of each type of diagram in case someone is interested in seeing more or if someone wants to use one. 

I chose this particular blog post because I did not know that there were this many types of UML diagrams. With this broad amount, I can see it being used not just for software and businesses, but for other things as well. Visualizing things out is very beneficial, allowing you to keep track of things and make things concrete, instead of just picturing it in your head. I think UML is cool, it is certainly different from what I have learned in the past, but I will use it whenever I need to. It is also not that hard to learn, making it a little bit more accessible.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

With software development, working in teams is typically normal. Being able to work in a team is important. But what is also equally important is interacting with stakeholders. A team does not make a project just because, typically someone comes up to the team and gives an idea and the team gets to work. That is an extremely watered down version of how it happens, but that is how it works. This can be somewhat confusing so let’s break it down. 

In this blog post, they talk about what a stakeholder is, why they are important and then some examples of a stakeholder. The post defines a stakeholder as a group of people or groups affected by a software development project. They are in the best position to offer specific input on needs at their level. Essentially, they are people who know what they want for this project and those whose interests are important for the project. It is important to get their input on the project because they guide the project in a way. They are able to create a list of things that are needed for the project and a way for the developers to figure out what they are working on exactly. You do not want to ignore the advice of stakeholders and neglect them, as that means the developers are just making the wrong thing. But who is considered a stakeholder? End-users are good to consider, as they are the ones to be using it once it is complete. Knowing their input and how it affects them is important. People like managers, project managers, developers, and partners are all important, as they ensure that certain aspects of the project are doable. Certain authorities are also important to consider, such as shareholders or company owners. It is hard to get everyone in for a meeting on the project all at once, so getting representatives is a better alternative. Determining whether or not their input is needed is also important, as to not waste someone’s time. But again, how do you determine that? There are some questions you can ask, such as “who will be affected by this product,” “how will workflows change,” and “are there any people whose support is vital to the project.” 

Understanding who has valuable input and is able to shape the project will be key to you as a developer, as it lays the foundation and blueprint for what you and your team will be doing. It may be difficult to get everything everyone wants, and you may have to cut some things. But knowing when to do so is up to you and the team.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

A topic we touched upon in class for a tiny bit was mutation testing. It is a different kind of software testing, where it alters your code and then runs your tests. If your tests fail, that means your tests are good. If your tests pass, that means your tests are not good. The altered versions of the code are called mutants, and if they are caught by the tests, as in failed, they are considered killed. If they pass, they are considered to have survived. The concept is strange, but can be effective, especially in finding inaccurate tests or seeing if you have enough tests.

In this blog post, Uncle Bob talks about his experience with mutation testing, how he came upon it, some benefits and how it works. He starts off by stating some issues with unit testing, such as writing enough tests, covering every line, branch, or path, and whether or not a test will fail depending on if you change some code. He answers these issues with sufficiency, coverage, and semantic stability, all of which can be solved by using mutation testing. It is fairly simple to run, and there is multiple ways to go about it. You run pitest tool, which alters your code a little bit, such as inverting if statements. It will do this more than once, where each variation of your code is a mutant. Then, for each mutant, it will run through all of your tests. If the tests fail, the mutant is killed, and if the tests pass, the mutant survived. Ideally, you want all of the tests to fail, which may be difficult to wrap your head around, typically you want your tests to pass. Having mutation testing is just another layer of testing to ensure your code is working properly. If a mutant survived, a number of things could have happened, such as ignored tests or discipline became too relaxed and people started writing sloppy code. Either way, it’s a good way to reinforce your tests and code. 

We did not really get to play around with this a lot in class, but it was cool to see how it worked. It had created multiple batches of mutants and might have ran the tests individually, but I may be wrong about that. If we had the chance to run it on code that we wrote, or if I had ran it on code that I wrote, maybe I could have understood it more. I will definitely use this in the future.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.