Author Archives: kylerlai

Sprint 2 Retrospecive

A lot of things worked pretty well this sprint compared to the last. Communication, effort, work, progress, collaboration, planning, and more were all present and at a great level compared to the last sprint. We still had our own section that we mainly worked in but there was plenty of collaboration for tackling a difficult issue, researching an issue, or just divvying up work should someone have free time. I think that our Sprint 2 goal was very concrete and our issues that we made at the start of the sprint as well as throughout led to a smooth sailing to the finish line.

I wouldn’t say that there was anything that didn’t work well but rather things that could be worked on. Communication could always be improved, and even though it’s a night and day difference between Sprint 1, there were some points in which it would’ve been nice to hear from certain team members what was going on or why they weren’t present. This may be more of just my personal feelings but there is one member who handles almost all Gitlab organization and use and takes notes of our meetings, and I’m not sure if it’s for their sake or for the team’s sake, but I feel that they could ask the rest of the team to help with any of these. They are the most adept at using Gitlab and I assume wants to stay on top of things and as organized as possible but I’m certain other team members could help out even if a little. 

To improve as a team, communicating when a team member can’t make the meeting and making good progress and decisions without certain team members present would be great. I think we divvy up our issues well but other work that aren’t exactly issues could be divided up between members especially if it’s rather menial.

I think I could’ve gathered a better idea of our group’s work and flow and what other team members are working on. For the Sprint 2 Review, I prepared to share what I had worked on but was wholly unprepared to share what other members have worked on and present our work. 

The apprenticeship pattern I felt was most relevant to my experiences was “Confront Your Ignorance” from Chapter 2. This pattern states that “There are tools and techniques that you need to master, but you do not know how to begin… and there is an expectation that you already have this knowledge.” The solution to this pattern states to “Pick one skill, tool, or technique and actively fill the gaps in your knowledge about it.” Although this pattern doesn’t exactly describe my experience during the sprint, it felt the closest out of all the other patterns. Rather than tools and techniques, I would say that I need to better understand our group’s work and plans as well as individual members’ work. To handle this, I could go through our Gitlab issues seeing what has been accomplished and who is assigned to what, I could explore our repositories to get a better understanding of the individual pieces of the project, and I could simply ask my team members about what they have worked on, what they plan to work on, and their idea of our group’s work. Taking notes would’ve been a great option as well due to how much information might be shared during our meetings.

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

Sprint 1 Retrospective

What worked well this sprint was our division of roles and tasks as well as the planning for tasks and the sprint as a whole. Each member had a specific section of our project that we worked on, some even taking part  in more or most of the project, as well as connecting the pieces of the project. I think we spent a lot of time planning and working out what we need to do, the path we want to take, and the many decisions along the way. This hopefully led to less confusion while working through the sprint. 

What didn’t work so well this sprint was the communication. Communication during certain moments in the sprint was lackluster and thus other members didn’t know what certain members were up to or working on. This also led to those other members having to pick up work had the certain member not done their work within a specific time.

To improve as a team, I think we should communicate more. Specifically, what we’re working on, what we can and can’t do, if we need help, and to complete tasks that require more than one member. As we move towards a complete product, I think the work may become more complicated and the communication will be necessary to connect and join respective pieces of the project.

To improve as an individual, I need to communicate more and stay on top of my work. Putting in more effort to communicate with my teammates and completing my tasks should be my number one priority. Personal issues, lack of effort, or lack of understanding led to me not being able to complete my tasks. Not only is that quite the issue, but I didn’t communicate any of that to my team at all, and thus they have no idea what I’m up to and have to pick up the work that I didn’t do. 

The apprenticeship pattern I felt was most relevant to my experiences was “Expose Your Ignorance” from Chapter 2. This pattern states that there are people depending on you to know what you are doing and need confidence that you can deliver. The solution to this pattern says to “Show the people who are depending on you that the learning process is part of delivering software [… and that the …] most obvious way to expose your ignorance is to ask questions.” I felt that this pattern partly describes what I experienced during this sprint. There are people relying on me to do my part but I don’t have the confidence in my ability and am unfamiliar with a lot of the processes that we will work through. My teammates, on the other hand, are very familiar with the processes or are very willing to learn. 

Although I did expose my ignorance and ask questions of some of my teammates who were much more experienced than I am, I could have done so much earlier. Not only that, but I still feel hesitant to ask questions because there are plenty of things I should already know but don’t. Reading this pattern may have encouraged me to ask questions more often and much earlier in the sprint, increasing communication from myself and between teammates, and would hopefully lead to me knowing what I need to know to tackle my tasks.

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

Apprenticeship Patterns

After reading Chapter 1 and the introductions for Chapters 2 through 6 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye, I have a much better understanding of the “stages” of a software developer’s career. I found it interesting how the career was divided into being an apprentice, journeyman, and master and how it doesn’t necessarily relate to a job. These stages are more like checkpoints for the software developer’s career as a whole, not for the phases that may come with starting and working a job. 

I like how the stages aren’t locked by experience or time but rather mindset. The apprentice is described as someone who knows there are better ways to do things and are willing to learn, the journeyman moves around working on various projects with various people readying themselves to become a master, and the master furthers the field through teaching and creating. I feel that the stages could be summarized as learning, exploring, and improving. I also like how the stages involve the roles of the previous stages; as such, a master is not exempt from learning and improving. In a field that is constantly evolving, even those with the highest expertise can learn a thing or two. 

I think Chapter 4’s introduction was most relevant to me because I think it has advice that can apply to everyone in any facet of life. “Be aware of the bigger fish, the bigger ponds, the many other ponds, don’t settle for being better than the mediocre, let go of perceived competence, be better than you were yesterday.” Finding these faults, acknowledging them, and moving forward with them in mind seems to be key, not only in a software development career, but in any facet of life. 

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

Set-up Task #5

LibreFoodPantry

I found it interesting how thorough the Code of Conduct was. The lists of encouraged and unacceptable behavior as well as the tiered consequences for violating the Code of Conduct made me think that there have been lots of instances of poor behavior in this community in the past. I may be completely wrong about this, but if not, it really makes me think about how or why people would join or be invited to this community dedicated to a good cause only to spread hate and negativity. 

Thea’s Pantry

Despite working with Thea’s Pantry for quite a while now, I have not put much research into it at all. I knew it was a place for students and people to get help with food insecurities but I didn’t really know where it was or how it worked for those people. The User Stories give me a great sense of how the pantry works as a guest and some insight into how staff manage it. I liked the listed step-by-step process for the various interactions that make the pantry what it is. I find that following instructions is much nicer than figuring things out on my own so having these stories of how the pantry is intended to work makes me feel comfortable should I ever be in one of the scenarios.

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

Semantic Versioning

One of the earlier topics we went over in this course was Semantic Versioning and how many companies or groups will use it to keep track of their development. Sometimes shortened to “SemVer,” Semantic Versioning describes a versioning structure that will better communicate “implications of new versions, such as breaking changes, new features, or bug fixes” (Victor Pierre). It allows developers to have some comfort in knowing what changes will be made or have been made and whether there is some level of risk in moving to a new version. This risk lies mostly in software that have some sort of dependency, such as libraries or frameworks as updates to those can lead to dependent softwares having to update some part or most of their work, and the software not working otherwise. 

Semantic Versioning employs a three-part version number in the format, MAJOR.MINOR.PATCH, with each part signifying a different impact of the release.

  • MAJOR: Incremented when making incompatible changes or introducing breaking API changes.
  • MINOR: Incremented when adding new features or functionality in a backward-compatible manner.
  • PATCH: Incremented for backward-compatible bug fixes or patches.

This is the basic structure for Semantic Versioning but there are many more rules to follow and other cases that will slightly change how the format will look (Victor Pierre). More details can be found on the official Semantic Versioning site (https://semver.org). 

When this topic was first introduced, I recognized it and was quite excited because it’s something I’ve seen quite often in the games I play or in other things related to games. The very first thing that came to mind was modding, especially in Bethesda Games. The Elder Scrolls Series and the Fallout Series are some of the most modded games ever, one of the reasons for this is the fact that Bethesda, some time after the release of a game, will implement modding support and tools. I connected Semantic Versioning to how Bethesda will rarely release a major update to Skyrim or Fallout 4, two of the most modded games ever despite how old they are now. These rare updates will cause the modding community to blow up as nearly every modder will have to update their mods in order to be compatible with the new version. After 10 or so years of these rare but destructive updates, many modders have simply stopped updating their mods, moving on to better things or just not caring enough to do so. It’s come to the point in which people have come together to make “downgraders” to play on an older version of the game to have access to a wider variety of working mods. 

That was a bit of a long story but overall, I think Semantic Versioning is simple but intriguing and most of all, extremely useful. I look forward to seeing changes, patches, updates for games and other software that I use and having access to an easy-to-follow log of just further cements my liking for Semantic Versioning. I’m not so familiar with other ways to keep track of development but this seems like a staple for developers and companies, and one that won’t be replaced so easily.

https://victorpierre.dev/blog/beginners-guide-semantic-versioning/

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

Time to REST

In the past few weeks, we’ve been learning and working with REST and how it ties into the larger picture of software architecture. I found this section confusing at times but mainly interesting thanks to the connection to personal experience. Once I realized that this is essentially the behind-the-scenes of those HTTP errors I’ve seen all my life, I was excited to learn more. 

Web services that adhere to REST are called RESTful APIs or REST APIs for short. REST API is a UI (uniform interface) “that is used to make data, content, algorithms, media, and other digital resources available through web URLs” (Postman). They are defined by three main aspects: a base url, a media type for any data to be sent to the server, and standard HTTP methods. There are four HTTP methods that are generally used in REST APIs:

  • GET: This method allows for the server to find the data you requested and sends it back to you.
  • PUT: If you perform the ‘PUT’ request, then the server will update an entry in the database.
  • POST: This method permits the server to create a new entry in the database.
  • DELETE: This method allows the server to delete an entry in the database.

These methods will have different effects depending on whether it is used to address a collection or an element (Postman). 

The part of REST that I found most interesting and that I’ve seen before were the HTTP response codes. In the case that one tries to go to a website and all they are met with is a white screen with black text stating “404: Error” followed by some details, that is a response code. Response codes will slightly differ depending on the HTTP methods used but most common ones include: 

  • 200 OK
  • 404 Not Found
  • 400 Bad Request
  • 500 Internal Server Error

I found this topic to be pretty interesting and honestly necessary in the case that one works with the web. Knowing the internet and my luck, I’m sure to encounter many of these errors for the foreseeable future and it’ll serve as a reminder to what I’ve learned about REST.

Side Note: Just the other day, when I was trying to log into Blackboard, I was met with a 404 error. I thought I could just reload the page or open a new tab and get into Blackboard but I was still getting the error. It took about five minutes before I could actually log in. I realized that knowing the details of these HTTP responses doesn’t make them any less annoying.

Source: https://blog.postman.com/rest-api-examples/

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

UML Diagrams

Earlier in this course, I learned about UML diagrams, how to read them, how to make them, and so on. This section of the class stuck with me as I thought it was pretty interesting how we use these diagrams to “visualize” our code. I thought I’d gain some more insight on UML diagrams and possibly more on how they are used in the real world.

For those who aren’t so familiar with UML diagrams, let me give you some background. UML stands for “Unified Modeling Language” and is “a way to visually represent the architecture, design, and implementation of complex software systems” (Lucidchart). These diagrams can be generally divided into two types, structural and behavioral. Both types of UML diagrams are pretty self-explanatory but structural UML diagrams display the various pieces of a system and how they are related while behavioral UML diagrams show how the system “interacts with itself and with users, other systems, and other entities” (Lucidchart).

In this blogpost from Lucidchart, one of the first things that caught my eye was under the section “Why should you use UML diagrams?” Of the four bullet points, three of them had me nodding my head in agreement, these were:

  • Bring new team members or developers switching teams up to speed quickly.
  • Plan out new features before any programming takes place.
  • Communicate with technical and non-technical audiences more easily.

To me, these points make perfect sense. I’m not very familiar with how development teams work in the real world but I assume that there are plenty of developers and others that may come and go in companies, groups, and such. It may sound like a simple switch or change but that new person may have no idea what they will be working on or how it will be worked on. UML diagrams could help them adjust more quickly and help them understand their role, team, and work better. As for planning, simply adding a new piece to the diagram to indicate a new piece of the system could help display the relationships to what they already have. And finally, UML diagrams are much easier to digest than multiple files, classes, blocks of code, and such, especially for those who are not developers. A customer may want some update or insight into what they are spending their money on, and so, teams can simply show them a UML diagram and point out where they are and where they plan to go.

Blogpost: https://www.lucidchart.com/blog/types-of-UML-diagrams

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

We Are So Back

Welcome back to my blog. If you didn’t know, my name is Kyler and this is where I’ll be occasionally making blog posts about topics that relate to software, computers, programming, and the like.

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

Performance Testing

When I was in the process of learning how to build a PC as well as planning out what parts to choose, I had to weigh my options on the scales of price and performance. Some time after building it and using it almost daily, I was confident that my shiny new PC could handle nearly everything that I was using it for. I have yet to run into any major performance issues despite how my last sentence sounded but the fear of that still lingers in my mind when I try or want to try pushing my machine a bit. To prevent these worries, performance testing is done on software applications. 

Performance testing “is a type of software testing that ensures software applications perform properly under their expected workload.” It is meant to test and measure a system’s performance “in terms of sensitivity, reactivity, and stability,” using metrics such as response time, scalability, and resource usage (GeeksforGeeks). Doing so ensures that a system can handle the expected workload efficiently and effectively. 

Performance testing can be done on multiple levels such as on the application itself, the system running the application, and other levels that go a bit out of my knowledge.

There are many types of performance testing but the three that seemed most common and simple were load testing, stress testing, and endurance testing. Load testing involves testing the product’s performance under expected loads. This could include simulating user experiences through testing with different tiers of hardware, using the application for a certain amount of time, and doing things that a user may do. This ensures that the application is accessible to as many people as possible as hardware limits and mild activity will not do anything to the application nor the system. Stress testing involves putting the application under extreme loads, pushing to and even beyond its limits. This helps to identify the point in which the product breaks or affects the system, and gives an idea of what to optimize or fix in order to avoid breaking as much as possible. Endurance testing involves putting the application under stress for extended periods of time. Simply running the application over the course of a few hours, days, and possible weeks helps to identify memory leaks and how it handles a different type of load. 

Performance testing is really interesting to me as, on my PC building journey, I was very much interested in the performance of computers and how some applications require better and faster components to enjoy it at its true maximum. I, though not on the level of actual performance testing, have tested my own machine to see its limits, how it handles the maximum of certain applications, and how well it handles my use. Luckily, I’ve had very few crashing of applications, freezing, or other issues. 

https://www.geeksforgeeks.org/performance-testing-software-testing

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

BDD

In a previous blog post, I had talked about Test Driven Development, or TDD. Today, I’m going to introduce a different approach that aims to almost rectify the potential shortcomings of TDD, that approach being Behavior Driven Development, or BDD for short.

BDD can be described  as “a collaborative approach to software development that aims to bridge the communication gap between business and technical teams” with the core idea of creating a “shared understanding of the software’s intended behavior using concrete examples” (Test Guild).

“The process revolves around writing scenarios using the Given-When-Then format, which describes the preconditions (Given), the action or event (When), and the expected outcome (Then).” This is a format that can be easily understood regardless of what people specialize in. TDD involved writing test cases and coding based on those test cases which mainly involved the developers, testers, and those that are closely linked to the programming and technical development. BDD, on the other hand, can involve the non-technical, such as stakeholders and those from other departments on top of the developers and testers. It can be simply put as, “compared to test-driven development (TDD) which is developer-centric, BDD is a team-wide practice” (Test Guild).

The Given-When-Then format allows for less misunderstanding when it comes to what is required of the software. Developers may use names that are short and to the point to describe something but it doesn’t match the behavior that is desired. The same developer or others that have just started working on the code may simply go along with it not realizing that what is desired of the code is something more or something else entirely. By using this format along with full sentences describing exactly what the code should do, there will be less room for error, misunderstanding, and time wasted fixing the code down the line.

One of the difficulties that seems to arise with the implementation of BDD is the inclusion of implementation details in scenarios. This is because scenarios are meant to focus solely on behavior. Including implementation details is basically attempting to set something in stone; scenarios describe what is desired of the code and how developers achieve that can change many times. It ends up adding more work every time that detail has to be met or changed.

BDD is an interesting topic, it seems to be a direct upgrade from TDD but that isn’t always the case. Take a classroom environment for example, it’s a bit odd as we (the students) could be considered developers but what about the other roles in the process? Would the professor act or technically be a stakeholder? It’s a process that can be learned at any point but it seems it can be only truly put into practice in a real world environment. We can certainly take aspects of BDD into mind, the Given-When-Then format and basing development around desired behaviors seems to have little to no downsides for any situation. 

Source: https://testguild.com/what-is-bdd/

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