Author Archives: rainiery

Sprint 2 Retrospective

Backend Example:

For the second spring, our team focused on developing the frontends, backend, and keycloak of the inventory system. But a big problem the team encountered during the sprint is that to develop the inventory system, we had to learn all this new material such as Vue.js, Express, and API. Even though I was introduced to these concepts last semester, it’s still comparatively new next to all the time in college where I used Java and C++. And even though we had the entire first sprint to get familiar with the material, actually applying it to a project is a bit more difficult. It caused the progress on development to lag and a decent chunk of what was planned for the sprint didn’t get finished, like writing the API for example which was my responsibility and I’ll get to that later.

I worked on developing the backend and event system components for the inventory system during the second sprint. For the event system, I met up a couple times with the team members working on the event system from other teams. We talked about how our systems were going to communicate with each other to the point I at the very least know what to implement on my side. The inventory system just has to send messages to the reporting system whenever the inventory goes up or down and it will do that through a JavaScript file called “send.js”. I also managed to create a base skeleton for the backend which is heavily based on an existing example which I’ve linked above. I also tried to write the API but I didn’t really manage to finish it well enough and even though I did work with APIs last semester, it’s been a while. I feel that the biggest reason for the unfinished API is because I didn’t even study API during sprint one, I mainly studied express. All of these tasks most of what I did during sprint two outside of a few miscellaneous things that don’t come to mind immediately.

On what to improve as a team, I can’t really think of much outside of trying to keep up with the new material because I feel a good portion of the class is dealing with the same problem. I feel that the inventory team is doing decently all thing considering. As an individual I could improve on my knowledge of API and some other subjects by using the inventory system wiki more. I could also try and free up more time to work on the system since I planned to work on the API some more and I barely got anything done since I had a test last Friday and I have another test this coming Tuesday. I might have time on Tuesday afternoon or Wednesday but I also have other classes that I have to keep up with and I should also set a concrete goal or write a to do list to guide myself. I just came up with that and it sounds like a good idea so I’ll stick to that plan.

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

Code Review


According to the article linked above, to code review is to consciously and systematically convene with one’s fellow programmers to check each other’s code for mistakes. There are many different ways to code review such as through an email thread, pair programming, over the shoulder, or tool assistance. Through email, a programmer can easily send their colleague a file with the un-reviewed code allowing both of them to exchange regardless of schedule or location. Pair programming is when two software developers work on the same code side by side, allowing both to more fluidly exchange ideas. Developing over the shoulder is similar to peer programming except only one developer actively works on the code while the other acts as support. Tool assistance allows for even more flexibility than email chains since it allows for code review through software-based code review tools.

Code review is a very simple concept as it is simply peer reviewing in the context of software development. The importance of peer review is that another person can examine and point out someone’s mistakes unlike automated processes. Developers are still human and make human errors which are less likely to be picked up through artificial means. And solely relying on tests written by the original developer runs the risk of overlooking errors not picked up by tests or in the worst case, following the assessments of a flawed test. That’s why peer review, and by extension code review, is so important to speeding up and streamlining software development.

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

Learn How You Fail

This week I read the section “Learn How You Fail” in chapter five of Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. This section focuses on the concept of learning from your mistakes by understanding your shortcomings. An example the authors use to illustrate this is writing an implementation of binary search and its tests in one sitting without compiling the code or running tests once. Once finished, compile the code and run the tests in order to find any mistakes you’ve made. Repeat this process until the code compiles and passes all the tests while also writing down notes on each iteration. These notes will act as an identifier to your personal shortcomings which will certainly be useful into the self-assessment that allows one to set realistic expectations and a direction to aim towards in self-development.

The concept of “Learn How You Fail” has a lot in common with “Expose Your Ignorance” like how they both promote self-improvement and emphasize examining one’s shortcomings. But the most important similarities among these is that they’re both concepts that center around learning from your failures. However, the key difference is that EYI is opening up yourself to failure while LHYF is learning from that failure. It’s just that both concepts complement each other in that one naturally leads to the other. Take for example that exposing your ignorance could very easily act as the direction needed for self-development similar to the notes in the “Learn How You Fail” example.

The idea of “Learn How You Fail” is also one that applies to many different contexts outside of software development. For example, before someone learns how to ride a bicycle, they’re likely to fall dozens of times. A saying I’ve encountered in everyday life is that mindlessly failing again and again will only get you so far, improving muscle memory and the like. A key aspect in learning effectively and quickly is knowing exactly what to improve on. That’s why I personally believe that a direction or a goal is incredibly important not only to this concept, but to learning as a whole.

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

Test Automation


This week I’ll be writing about test automation since the class has already covered this topic; specifically with section five and homework assignment two. According to the link above, test automation is the practice of running tests automatically, managing test data, and utilizing test results to improve software quality. In order for a test to be automated, it must fulfill three criteria. First, the test must be repeatable since there’s no real sense in automating something that can only be run once. Second, a test must be determinant meaning that the result should be consistently the same given the input is also the same every time. Third, the test must be unopinionated which means that aspects that are tested shouldn’t be matters of opinion. These criteria allow automated testing to save time, money, and resources which results in software to be improved efficiently.

Personally, I’ve experienced how efficient test automation is through simply working on assignments; for this class even. I don’t quite remember what assignment I was working on, but I recall using gitlab’s built in automated testing environment. I was nearly finished with the assignment but there was one function that wasn’t working correctly. Instead of having to go to the directory, run the tests, edit the code, and push the changes to gitlab, I had the option of simply running the tests and editing the faulty code on gitlab. The option was extremely convenient and freed up a decent chunk of time, and that was just a minor assignment. I’d imagine that applying automated testing onto larger projects would save even more time.

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

Behavior Driven Development

            Since my last blog post for CS-443 focused on test driven development, I thought I was appropriate to talk about behavior driven development, also known as BDD for short, for this blog post. The reason I chose to write about this topic aside the reason just mentioned is because BDD is one of the topics covered in this class according to the syllabus. The article linked above acts as a tutorial for this type of development going through the specific procedure of BDD. According to the article, behavior driven development works as a three-step iterative process. The first step is to take a small upcoming change to the system, also known as a user story, and form concrete examples of new functionalities until they’re generally agreed upon. The second step documents those examples in a way that can be automated and checked for agreement. The final step implements the behavior described in the documents written in the previous step and begins with an automated test to guide the development of the code. This process continually adds a new behavior to the system each iterative loop.

            Before I wrote this blog post, I assumed that behavior driven development would have been a new concept to me unlike test driven development. However just like TDD, BDD is actually a concept I’m familiar with on some level. As I’ve taken computer science classes in WSU, I got into the habit of writing out what specific functions a program I’m working on needs. I wouldn’t go as far as create a user story for each task I’d have to do; that’s still a fairly new concept for me. But, just like the iterative nature of behavior driven development, I would document what behaviors a program needs to function and implement them into the code with some tests to guide development. Another thing that caught my attention is the last step of BDD which utilizes tests to give direction to the development of the code. Because of this, you could say that behavior driven development implements test driven development in its own way.  I don’t have much to add to this point, I just thought It was interesting enough to point out.

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

Craft over Art

            This week I read the section “Craft over Art” which is found in chapter three of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section focuses on a software developer’s struggle in balancing their own personal want of making something with artistic merit and a client’s need of a product fulfills their requirements. The developer might add components that may be impressive but could also be pointless to or be an outright hindrance to the client’s wants. The developer may also want to polish up a project to a mirror sheen that deadlines would simply not allow for. And additionally, a software developer is a craftsman and not an artist. That doesn’t necessarily mean that a developer can’t produce something with beauty; a craftsman creates beauty by fulfilling a request to their utmost abilities. It just means that the client’s wants should be balanced with the software developer’s personal standards.

            The whole “Craft over Art” concept I agree with and in fact, I’ve thought of the concept on some level before through a practical point of view. Like why would I add features to software that wouldn’t benefit the user in some way? I’d just be wasting time I could use to polish up the existing components of the software. For example, If I were to work on a program that kept track of the transactions of a business and I added an option to play chess, that’d seem kind of pointless. If I really wanted to make a chess program, then I’d set that aside as a side project that I could do for fun. That doesn’t conflict with the “Craft over Art” concept since there have been plenty of craftsman who’ve worked on personal side projects in between their main commissioned projects. Even when just talking about software, I’ve heard of a fair number of programmers who’ve made little side projects like a game for example on their off time. And when working on main projects, I at the very least try to fulfill the minimum requirements so I can go back and polish it up as much as I feel the need to. But even then, there are time where the circumstances don’t allow for much polish so I just have to suck it up.

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

Sprint 1 Retrospective


For our first sprint, we mostly focused on learning what we need in order to build the inventory system such as Vue.js, Express, and API. I worked on researching Express by finding, studying, and recording resources such as Express tutorials and syntax guides among other sources. I also got in some practice writing and running Express JavaScripts, though not as much as I’d like to since there weren’t many examples I could find online. The team also created repositories for each component of the inventory system and a wiki where each member can place links to helpful resources. The link to the wiki, which include the resources on Express that I found during the sprint, can be found in the link above. If I were to describe what worked well, I wouldn’t know what to say since this sprint focused on learning rather than building. The same also applies for what didn’t work well since components can’t work incorrectly if you don’t build any.

Overall, I feel our team did fairly well considering one of our team members was incapacitated for a good amount of the sprint. We were able to finish tasks that amounted to 13 weight out of the tasks planned that amounts to 18 weight. That’s six weight for each remaining team member with one extra. The only thing I remember the team really struggling on was getting used to working in the structure of a sprint. So, I can’t really think of a way the team can improve outside of getting use to the workflow and structure of a sprint. It’s about as specific an area I can think of for improvement and it’s a pretty general area. And when I talked to my team in our sprint retrospective, they couldn’t think of much to improve on as a team either.

However, I can think of a bit more to say if we’re talking about what to improve as an individual. For example, the entire sprint I had a general feeling that I didn’t have a clear goal in mind outside of “study Express”. This probably resulted me to not have as fast of an output as I could have and also caused me to worry more that I wasn’t doing enough work. It’s also one of the major reasons why I couldn’t practice writing and running Express JavaScripts as much as I’d like to outside of the other reason I mentioned earlier. Another area I could improve on is summarizing the outcome of each task assigned to me. I say this because I didn’t realize I was supposed to do this until the meeting near the end of the sprint. But then again, this issue kind of ties back to what to improve as a team; getting use to the workflow and structure of a sprint. So, all I can really think on what to improve on as an individual is planning on a specific goal for each sprint to give a clearer direction and remembering to summarize the outcome of each of my tasks.

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

Expose Your Ignorance

The book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye covers multiple patterns important to being an apprentice. One of these patterns is called “Expose Your Ignorance” and centers around the issue of not knowing enough about a topic kind of important to the task at hand. Many people’s first instinct is to feign competence in order to avoid worrying their peers and suffer through embarrassment. The pattern instead suggests that people admit their shortcomings and ask questions. It might be hard to do but the benefits far outweigh the risks like learning important information sooner rather than later for example. Doing this has the added benefit of developing the learning ability through enforcing a “not knowing” mentality which just means to approach a situation if you were a novice. This mentality pushes an individual to broaden their horizons rather than becoming an expert on a single subject in a specific context. It also allows one to form strong relationships since this will be showing others your learning ability and flexibility.

I’ve had trouble “Exposing My Ignorance” for most of my life since again, most people’s first instinct is to feign competence. And of course, that wouldn’t work out since people would get mad at me for not knowing something and I’d end up barely learning anything. But I would still keep up this behavior until either late high school or early college mainly because there were some people in my life that would get mad at me for even asking questions. The reason why I broke out of that habit is because as I got older, I realized that there was so much I had no clue of doing. So, I started asking questions without caring what other people thought because I wanted to learn. For example, I wanted to learn to do my laundry so I just asked my mom to teach me and now I still do my own laundry. The same principle applies to software development; If you either don’t know something or aren’t confident in your knowledge on a subject, ask questions since there’s no real harm in doing so.

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

Apprenticeship Patterns Ch 1 and Ch 2-6 Introductions (Revised)

The book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye begins with its first chapter which centers on the concept and nature of apprenticeship. In it, the authors compare and contrast the apprenticeships of medieval Europe with the software apprenticeships of today. The following five chapters, of which I have read the introductions of each so far, focuses on individual concepts and attributes important to software apprenticeships. Chapter two focuses on “emptying the cup” or how an apprentice should set aside their existing knowledge in order to fully open themselves up to the different approaches of their colleagues and teachers. Chapter three reminds to not be too discouraged of the achievements of your peers as they’re still learning like the rest of us. Chapter four also reminds to not become too complacent or conceited and instead find ways to improve your weaknesses. Chapter five follows that up by advising that an apprentice should learn how to learn since software development is composed of two primary activities: learning and communication. Chapter six finishes off with the point that even though we live in an age where anyone can access limitless information through the internet, books still have some knowledge you can’t find online.

I mostly agree with the points made in the book save for the one in chapter six and even then, it’s mostly with the wording. The way the authors described their point made it seem that physical books have value outside of the internet in the information they have. This is despite the fairly likely chance that many of these books, such as Apprenticeship Patterns, already exist online in some form or another. I’m assuming that the authors only had sources exclusive to the internet like blogposts and websites in mind when comparing them to books. Taking that point of view in mind, I can see where they’re coming from especially with how easy it is to find inaccurate or outright wrong information. I’d go even farther than the authors though and suggest that people check the validity of their sources since physical sources can lie like online sources, the only difference is that it’s easier to lie with the latter.

Outside of the point in chapter six, many of the topics and attitudes covered I feel are not only important for software apprenticeship but also for any skill that an individual decides to devote themselves to. Optimizing one’s learning skills, constantly learning, constantly improving one’s weaknesses, not getting discouraged by the accomplishments of one’s peers, and opening oneself to other viewpoints are all extremely important to cultivating a craft. That’s because these skills all contribute to developing oneself into a well-rounded person, which in turn allows for an individual to learn and improve more quickly.

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

Test Driven Development


            The article linked above talks about test driven development, also referred to as TDD, and how it effects software development. I specifically chose this article since it centers around a topic that we’re supposed to cover in this class. The author explains three key reasons why this type of development is used. The first reason is that test driven development is an iterative cycle comprising of the three steps of failing tests, passing tests, and refactoring code. The “failing tests” phase establishes a baseline to work with, the “passing tests” phase develops that baseline into code that meets minimum requirements, and the “refactoring code” phase further develops that code. The second reason is that TDD forces a developer to question their code on multiple levels. For example, a developer would be pushed to question how a specific component works or what they expect from their code. The last reason is that test driven development allows for faster feedback on software design as poor design is often the reason why testing features fail. The article goes on further to explain how to apply TDD on code that is impossible to test.

            Reading this article, I found myself agreeing with a lot of what the author had to say. What stuck out to me in particular was how TDD forces a developer to question their code. It got me thinking about the habit I developed writing code where I began to write down and plan the general structure of a whatever project I worked on. The way that test driven development pushes someone to understand their code in what component does what reminds me of my habit but on a smaller scale since a developer would usually test a single feature at a time. And this type of development is really a new concept for me since I’ve used that iterative cycle that the author mentioned without even realizing it. The only major difference is that is that I typically didn’t use a test class which is what I’d assume is a given in the context of the article. I usually manually tested my projects which obviously hurt my productivity and deprived me of the benefit of faster feedback in TDD.

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