Author Archives: antcao

Second Sprint Retrospective

Last week, my team completed our second Sprint. Like the first Sprint, we did a good job. Each of us stuck to the parts we left off after the first Sprint, so with me, that meant continuing with the CheckInventory frontend. The issue I wanted to get done by the end of the first Sprint was connecting the backend to frontend, so that instead of displaying a hardcoded value, it would pull from the backend. By doing so, the frontend would have its full functionality. However, that was easier said than done, as I spent almost two weeks trying to figure it out, only for my teammate to figure it out before me. They had created a shared network for their frontend that connected to the backend. I ended up using the same shared network with no problems. I created a method that called ‘GET’ from the backend in order to display the value. The next issue was figuring out how to call this method upon mounting the page. I spent a week trying to solve this, until it was suggested that I try calling it through a button press, as that had success with my teammate’s frontend. I tried that, but the button simply refreshed the page. Later, I tried a different button, which ultimately worked. However, I was not satisfied with that, so I did some more research and found a ‘beforeMount’ method, which solved the problem. I committed, and made a merge request for both the shared network, method and mount issue. With a week left of the Sprint, I spent time playing around with the design of the frontend, as there was discussion in the visual identity team. I refactored the frontend in order to call the header, CheckInventory, and footer components in the App.vue file, instead of using a router, like it was originally. I then fixed the footer to sit properly, and used the appropriate colors and fonts, according to the school’s guidelines. I completely overhauled the header, using the ‘Thea’s Pantry’ logo, adding a navigation bar, and adding a yellow strip to the bottom. Additionally, I used the correct colors and fonts, once again complying with the school’s guidelines. I was able to commit and merge those changes before the end of the Sprint, and present them to the client.

What worked well was still communication. We all communicate really well, and when we need something from someone, or someone to review something, it’s done fairly quickly. Our chemistry has also become more friendly, we’re more open and joke around with each other, while also being strict with our work. Speaking of work, something else that worked well was solidifying our roles in a way. Since we all stayed working with stuff we worked on during the first Sprint, we knew what we were doing from the beginning, instead of figuring out everything from scratch. Personally, what worked well for me was being proactive, especially with the design part of the frontend. I felt motivated to make it look good, and it felt less like work. However, something that did not work for me was again the expectation of doing enough. Towards the end, I felt like I was, but I felt most of the time I wasted a lot of time researching. It is not exactly my fault, but it also is.

As a team, there’s not much we can improve on, as communication is good, chemistry is great, and we have done a lot of work and progress. Something I suggested in the last blog post was clarifying what we are working on, like a stand up at the start of class. We had done this one time. Although I do not think it’s necessary, it could be a way to clear up confusion if there is any. Personally, what I want to improve on myself is using my time better. I feel I spend too much time researching, and although I cannot just speed that up, I could do it more efficiently.

The Apprenticeship pattern I chose for this Sprint was “Retreat into Competence,” in layman’s terms means I am overwhelmed by how dumb I am. This is referring to the fact that I have to spend time researching in order to fix my issues. There is nothing wrong with doing that, it is just that I spend too much time doing that. If I had read that before the Sprint, it probably wouldn’t have changed anything.

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

First Sprint Retrospective

Last week, my team completed our first Sprint of the semester and presented our work to our professor and the client. Overall, as a team, we did a great job for having not done or been a part of a Sprint before. Each one of us was assigned an issue at the start of the Sprint to work on over the period. One of these issues was evaluating the frontends, so I reviewed each of them and found that two of them, AddInventory and CheckInventory, did not run properly. It was determined that it was a server/deployment issue, so I contacted a member of that team through private messages. The team was aware of the issue and were working on it, so I suggested to my team that we focus on the backend for this Sprint. However, we decided that it would be better if we try to fix it ourselves instead of waiting. So I was given the CheckInventory frontend. In class, another member was able to get the AddInventory frontend to run, so I asked for their help outside of class, where we determined that the frontend was unfinished. So my task for the next couple of weeks was to fix that, and I did so by comparing it to the AddInventory and CheckoutGuest frontends. I then “borrowed” files that were missing from my frontend, and edited and fixed ones that did exist. This consisted of organizing some files into new folders, copying over frontend-prod-build and frontend-dev-up commands, index.html file, and much more. After I got it to run, I edited it so that it would match the AddInventory frontend. After all of that, I committed, pushed and made a merge request. The pipelined failed with that, due to a yarn lock issue, so I fixed that, linted, and then committed and pushed again. 

What worked really well was communication between the team. I felt that whenever someone had an issue or needed something done, someone answered within the day, which is really good. I think the team chemistry was also really good too, it did not feel too serious but also not too laid back. We also helped each other whenever we could, which is good. On the personal side, what worked well for me was just working in general. Like this whole thing is something that I have not experienced before, so just being part of a team to get work done for someone else kind of gave me fuel to work and make this a good thing. However, something that did not work well for me was the expectation to get enough done. For each week we plan for something to get done, but every time for me, I felt like I did too little or not enough. Maybe it is something in my head, or I am setting the bar too high, but that ghost pressure was not nice. 

There is not a lot that I would say we can improve on as a team, mainly because our communication is good, the atmosphere is great, we help each other and we get things done. What we could do, just as a minor thing, is clarify what we are working on. Although I do not think this is an issue, it has been expressed by members of the team, so this can be a good way of getting some bearings. As an individual, what I can improve on is just getting more done. Although I did finish my part of the Sprint by the end of it, it did not feel enough to me, so going forward I want to do more. To go with that, I would like to be more open about what I did do, some of my teammates were not aware of what I did in some of the past weeks, so I would like to improve on.

The Apprenticeship pattern I have chosen that resonates with me this Sprint is “Confront your Ignorance,”  which is basically not knowing the information needed for the work at hand. I chose this one because it describes what happened to me during this Sprint. I realized very quickly that I did not understand many things in the frontend and the Inventory system overall, which was scary and discouraged me. If I had read about this pattern before the Sprint, I do not think much would have changed. I still would need to do a lot of research regardless.

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

Apprenticeship Patterns

As the end of my education comes closer and closer, friends and family always ask about any jobs in the field and the future overall. This worries me because I have nothing planned whatsoever, I have no idea what is going to happen, and that scares me. I would love to have a job in software development, but at the same time, I fear I do not know enough to compete, and even if I do get one, I will not know enough to keep up. However, after reading a small part of Apprenticeship Patterns, I felt a little better about the future, to know that many others have felt this way. It also was nice to read that learning still continues once I get in somewhere, which sounds silly, but in my mind, and I am sure others would think the same way, in order to get a job, you need to know everything. So to see that people who think they know everything can still continue to learn something new is promising and also scary. Although I have spent my entire university education learning computer science and software development, I still feel like I know nothing. After reading this, it does not change the fact that I feel that way, but it makes me more optimistic about my time after university. Something that really stuck to me was the part about the guy who had a stack of certificates saying he knows all this stuff, and then he runs into some hackers that are doing stuff that he did not even know could happen, and the hackers were also still learning too. I think that stuck to me mainly because it feels like that’s me in this situation. Like I’m going to have a degree saying I can do this stuff, and yet I look around and there are others who know stuff that I didn’t even know where they got it from. But I can always learn that stuff too, either on my own, or at a job, or in class, if I watch them really closely.

Will I continue to read Apprenticeship Patterns? Maybe. As the fear of reality slowly continues to seep in, I will probably scramble and look for something to help and it might just be that. But who knows, the future does not look as bad anymore, kinda.

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

Thea’s Food Pantry

In my final semester of university, I am taking the Software Development capstone course, where we will work directly with Thea’s food pantry, creating and deploying a system that allows the pantry to keep track of how much food there is, who is getting it, etc. I thought that would be it. However, after looking at LibreFoodPantry, I was surprised by how much they actually worked with not just food security, but with software and technology as well. I thought we were just helping because we can, but this is actually something that has a focus in software and software development, which allows for some real world experience. 

After going through the gitlab of Thea’s Pantry, it looks very similar to what I worked with last semester in my software architecture course, but with some added repos and documentation. The thing I liked about this was the amount of documentation there was. I like this because it allows me to refer back to something while I am working to make sure I am doing exactly what needs to be done and how it should be done. Other than that, it was very similar to what I did in class last semester. Hopefully, with the documentation and teams, we will be able to get things done.

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

Frontend or Backend Development?

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.

REST API

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.

Design Patterns

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.

UML Diagrams

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.

Software Architecture

Hello again,

My name is Anthony Cao, and I will continue to use this blog to document my education in software development and what it has to offer. I am taking another software class that will correct the way I write code, making it more efficient.

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

Stakeholders

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.