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.

When working on a big project, in a big team, with a lot of other people working together, things can become confusing. Sometimes, code may not work, or you will not entirely understand what is happening. The best thing to do is step back and take a technical review. Review the code, the goals, and any other areas that may be in need of improvement or assistance. Take the time to straighten things out so you and the team can get back to work efficiently and effectively. But how do you go about a technical review?

In this blog post, Tony Karrer talks about what a technical review is, some ways to identify when you need to review, some strategies, and some areas of review. They describe a technical review as “a deep-dive assessment of your software, infrastructure, team and processes,” and that “it provides findings and recommendations intended to foster a mutual understanding between business and software leaders, shedding light on the current state of your technology and your team.” Some signs that you are in need of a technical review are slow or late delivery, random or persistent bugs, and sleepless nights from strategic worries. However, taking a technical review shouldn’t just be in response to malfunction, it can be due to scaling and new markets, keeping up with competition, outgrowing your stack, changes to the tech team, or simply because you want to be on top of things. Karrer describes four strategies, each different from the other, ranging from general to specific and in depth. They are straightforward analysis, pragmatic assessment, expert recommendations, and finding sessions. After determining which strategy you are comfortable with, you can go ahead and start reviewing. They provide some examples of where you may want to review, including background information to get a general idea of the project, architecture, targeted code, or process and team. If there are areas that need work or are struggling, then that is one hundred percent a spot you want to review. While you are doing that, create a summary and list your findings, and include some recommendations or solutions if you have any. Finally, bring them to the review meeting, where you will review the project together with your team and sort out the issues and find possible solutions.

Doing this in class was actually fairly helpful. I feel like if it was my code, I would have found more benefit in it, but I understand the premise of it, it’s good to have multiple people look at the code and come together and see what kind of issues we found. 

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

When you go to write code, maybe you already know what you want the code to do, knowing what it should give you as outputs and answers, but you might not know how to go about writing the code itself. In test driven development, you start with writing the tests first, and then trying to pass those tests, slowly as you go. It sounds like a strange approach to it but it is not as bad as it sounds.

In this blog post, Arek Torczuk talks about test driven development, and how it is the best thing that can happen to software development. First, they start off by describing test driven development, where they say it is, simply, a failing phase, a passing phase, and then a refactoring phase. In the failing phase, we create a test that will fail. In the passing phase, we create or write code, minimal code, that will pass the test. In the refactoring phase, we clean up the tests. Typically with coding, you would write the code, and then write tests. However, Torczuk presents some problems with this way of code development, like when to stop writing tests, or when you are sure implementation is finished. With test driven development, they say there are benefits, such as when writing tests, it makes you ask yourself, what do you want the code to do. They say that you should know the answers to these tests before the code is written. They then go on to provide situations where code may be impossible to test, and how test driven development can be used to help that, like using mocking. They provide code examples with these too, to further help visualize solutions. They provide some additional sources at the end of the article in the event you would like to learn more about test driven development. 

This is a strange way to write code, and for those used to writing code before everything else, this can be a difficult adjustment. Personally, I found it fairly difficult to start, but afterwards I was able to write the tests, and then write the code to pass those tests, and then keep doing that. The tests do provide a build up of the code, instead of doing everything all at once, which was what Torczuk was trying to get at with his blog post. It allows the tests to provide the framework of the code and lay it out. 

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

Testing is an important part of coding, and software development. Sometimes though, testing can be tedious work, and creating tests that work properly according to your code can be difficult. This should be the case anyways, as testing is a key aspect to software development, but what if you could do this process a bit more quickly. Creating mocks and stubs can be a good alternative, especially if multiple people are working on different parts of the same project or software. 

In this blog post, June Jung touches upon mock and stub testing. They describe mock testing as “creating a fake version of an external or internal service that can stand in for the real one,” and stub testing as “creating a stand-in, but a stub only mocks the behavior, but not the entire object.” The whole idea of mocks and stubs is to create a fake or a stand-in that does not do anything. This may seem strange, having completely useless methods and functions, but the thing we want to test for is the interactions between the methods and functions. Seeing whether or not they return the correct return values, call the correct methods, etc. This will reduce the amount of time needed to test the functions, compared to testing full, complete functions and methods. Jung says that by using mocks and stubs, you can “reproduce more complex scenarios more easily. For instance, it is much easier to test the many error responses you might get from the filesystem than to actually create the condition.” Jung says this specifically for unit + component testing, but this principle can apply for any kind of testing. In fact, they touch upon multiple cases where mocks and stubs can be used, such as internal functions, integration testing, and contract-based testing. They also provide code examples, and graphs to help you visualize the concept, which can be helpful.

Jung says that as your code grows, your tests should as well, meaning you shouldn’t continue to use the same tests as you continue to write more code, losing the mocks and the stubs. That being said, they’re good to help start, providing a base to continue with. Jung’s blog post is a good resource, as they also have linked another post that goes into the difference between mocks and stubs. It also appears that their blog post is part of multiple posts, which may be worth looking at for more information.

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