Monthly Archives: February 2022

Sprint One Retrospective

During the first sprint for my Software Dev Capstone project we encountered many problems and learned much about the software. Our group is working on the ReportingSystem aspect of Thea’s Pantry, which is a project that was developed by prior students. Our main goal was to refactor the project, but it seems as though we have much more to do than that.

When we first received the code, it seemed to be in working order. The more we dug into the project, the more it dawned on us that the ReportingSystem was either non-functional or difficult to run. As of completing the first sprint, none of us have gotten to successfully run the program.

Most of the tasks we did were basic refactoring/restructuring. For example, one issue that I completed was to add a public folder to the frontend to copy the example project. In this commit I moved relevant files from the backend to the frontend. I think that I have broken part of the backend with this change.

One thing that I think that didn’t go well is our planning when creating issues. In the previous example, I may have broken an integral part of the backend. We should have investigated more before we created the issue. Personally I think this is forgivable, it seems like an easy fix and we are inexperienced at creating issues.

One refactor that I am proud of is my refactoring of the src/report.js file in the backend project. I added comments and reorganized the methods to hopefully flow in a more logical way. The file was slightly hard to understand, and I hope that the refactoring makes it more clear as to what the file actually does.

One thing that I think that went well was our teamwork. We split tasks up well and few people were working on the same thing. Although most of us were working on the backend, we took different parts of the backend which did not overlap. Hung also designed a frontend while the rest of us were working on the backend.

I think that as a team we could improve on communication. We have decent communication right now, but it is brief and mostly during class. We also have not communicated with other teams to discuss how the larger project is supposed to work, for example we need to figure out what format the guest and product data will be in. Team 3 helped us out by sending a tutorial on RabbitMQ, and more interaction like this will be beneficial.

I think that I could improve by having a clear plan for each sprint. During this sprint I was all over the place and didn’t get as much done as I had hoped. This is probably a byproduct of learning the software, but I could still have done a better job. For the next sprint I plan to focus on learning RabbitMQ and getting the backend to run. This will also help my teammates plan around what I am doing and hopefully devise their own plans in accordance with my own.

Overall I think that sprint one was a good sprint, especially for a team which has never worked in a software development environment before. We have much to learn and improve on, but I think that we are headed in the right direction with the project and collaborating in general.

From the blog CS@Worcester – Ryan Blog by rtrembley and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “The White Belt”

This apprenticeship pattern describes as how we as programmers are comfortable with the language that we are best at and then how we try to apply our knowledge to learning something else. In the end it is hard to learn something new that way. What we realize by doing this is that it is difficult to then try and learn something new, and then we may end up becoming stagnant in our growth. The white belt method tells us to forget everything we thought we knew previously and come into learning something new with the mindset of a beginner. Although we lose productivity in the beginning, it will end up being a big step in mastering something new.

One of the most interesting things I enjoyed while reading about this pattern was an example of how to reimplement a Java pattern into another language like Io and then into something like J. we can notice how the code can change drastically from one to another and yet at the end of the day they all do the same thing. This example is eye opening to showing how similar and different every language is and that we can’t just take the same knowledge we have in something and apply it to something else. We have no make sure we go in with a fresh mind and try and follow the new language’s nuances and set of rules and forget everything we think we should know instead of trying to apply it to something new.

This pattern is very insightful and applies to what I’m currently working on in class. We are attempting to learn how to code in React Native and I feel as though my growth in learning and the progress that I want to achieve is not what I want to. It might be because I’m trying to apply my skills in java to a front-end language and that does not mesh well whatsoever. I’m an impatient person when it comes to learning something new, but this pattern is a great way for me to keep in the back of my mind because progression shouldn’t come in an instant, it comes with slow and steady progress and constant repetition.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Craft over Art

The pattern I decided to read is titled “Craft over Art” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The line that best summarizes this pattern is the one that states how the programs we create can be beautiful, but must be useful. This pattern starts off with a quote by Richard Stallman in “Art and Programming” that defines programming as, “a craft, which is a kind of art, but not a fine art.” This distinction is important because it shows how making beautiful programs is a good thing, but how its beauty should never outweigh the utility of the program that has been created. This pattern ends by giving us two tasks. The first task asks us to find something to do where we can prioritize usefulness over beauty. The second task is a reflective one that has us think about times we have chosen artistry over utility in our craft.

One of the sentences that I found interesting was the one that described how “utility and beauty are not opposed to each other, but interdependent.” This sentence stood out to me because although there is no denying that programs must be useful, it reminded me that I can not completely neglect the aesthetics of my program either because it goes hand in hand with how it is used practically.

As far as how this pattern has caused me to change the way I think, I would say that this pattern has made me be more mindful about the kinds of choices we make in our capstone project. We have already had a couple of conversations around this topic and I’m happy to say that our team has erred on the side of practicality over aesthetics. One of the things we have said in our team is that we should focus on setting the foundation of our project, and if we have enough time, we can come back and worry about our application’s appearance some more.

Overall, there isn’t anything that stands out that I strongly disagree with. It was a reassuring chapter to read after reflecting on some of the decisions my capstone team has already made on this topic. Additionally, it is a great message to instill early on in my programming career.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: The White Belt

This week, I decided to look at the next apprenticeship pattern in chapter 2, “The White Belt.” This pattern describes the dilemma of a programmer being confident in their skills of a language but has reached a plateau in their personal development. This pattern offers a solution to those who feel that they are not acquiring new skills fast enough. After reading through the previous pattern, I’ve gathered that it is important to keep learning and honing your skills. And this pattern directly addresses an issue that one would encounter when doing so.

The solution provided in this section is to put aside your current knowledge when approached with new knowledge. While this will potentially affect productivity in the short term, it will allow time for new knowledge to sink in. In the pattern, it states, “wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way.” This can be applied to learning anything because it can be beneficial to approach something new with the mindset of a beginner. The example with Dave the therapist was an example of when the mindset could apply outside of learning code. Dave found that taking a “not knowing” stance when working with clients opened up a new door of unforeseen possibilities and solutions. He put aside his expert knowledge on the subject and approached clients with curiosity.

Another example that I would like to refer to is that of the 10-year industry veteran Steve. He mentions that after reading “Working Effectively with Legacy Code,” his codebase improved into a better tested, adaptable system that was more fun to work with. While Steve did not go into detail, it was interesting to know how much more a 10-year veteran could grow. I certainly don’t have that many years of experience, but when learning new things, we are all starting at this hypothetical white belt. For the most part, the languages I have learned thus far are all based on similar logic. It would be beneficial for me to take one of my existing programs and implement it in a vastly different language. Not only would it give me a chance to learn a new language and the idioms, but it could also improve my coding skills in general, as mentioned by the 10-year veteran Steve.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Your First Language

For this week’s blog post, I have decided to look at the apprenticeship pattern “Your Fist Language”. The idea of this pattern is when you first start your programming journey. This is when you only know one or tow languages. The main concept of this chapter is to isolate what langue you would like to use as your main language. According to Dave H. Hoover and Adewale Oshineye, the authors of the book, they say on this, “Pick a language. Become fluent in it. For the next few years this will be the main language you use to solve problems, as well as the default skill you hone whenever you are practicing. Making this choice is a challenge. It is important that you carefully weigh the options, as this is the foundation upon which your early career will be built.” (Dave H. Hoover & Adewale Oshineye).

When first reading about this pattern, it really grabbed my attention. At Worcester State we learn an abundance of different languages to be able to be prepared for the outside world. However, something that has always been a question for me is “What language do I stick with?”. What was cool about this chapter was that it said to have a main language under your belt, but it never said to toss aside the other languages. As an example, they talked about a job requiring a specific language to be able to be hired there. Rather than disregarding the job and looking for something else, they suggest making a toy application to learn a basic understanding of that language. Some of these toy programs will involve a problem to solve. Unlike a simple “Hello World” application, solving a problem will give you a more in-depth dive of the language. Another good thing to add to your toy application is a test class. Test classes always help ensure that what you are coding is spitting out the correct information.

With this chapter in the book, I agree with everything that they are saying about your first language. I loved how they talked about having a min langue but not disregarding the other languages you have learned or will learn.  It also made me consider more what will be my main langue when I go out into the field and what language I’m willing to put more research into.

Book: Apprenticeship Patterns, Dave H. Hoover & Adewale Oshineye

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

The Deep End

Months ago, I found myself standing in “The Deep End” since I wasn’t able to land any internship before graduating this year. The situation was exactly the same as how they described in the book, I needed to grow more skills, my confidence, and my portfolio of successful work, I needed to challenge myself with bigger works, projects, complex tasks, and teams, etc. The YouTube algorithm even made my situation worse by showing people about my age are “better” coders than me in my opinion. I was afraid that I did not do “enough”.

 Currently, what I really felt at that time was envious, seeing people better than me virtually is rough but seeing people who I know landed works while I carried them through classes is overwhelming. My resume, my ability, my confidence, all of them were kind of irrelevant at that point. I created an invisible time limit for myself to be successful, to this point, I still think there are pros and cons to doing it, the risk could be high but I take it.

Later, exactly in how they advise the action, I should instead jump into working on projects that I did not do to create a time limit for it, I’m willing to take more work than anyone in the team and fulfill my responsibilities to not only build my portfolio but also my skills and my confidence. Then, after a while, I will analyze my set of skills fit to what role in the industry and pick the right opportunity based on it.

Besides, when this post is online, I’m currently handling an internship and a capstone project in which I volunteered to be the Scrum master that instead does not make me feel overwhelmed but motivated, as I am learning new materials every day.

In conclusion, it likes how The Deep End was described in vol. 15 of “Diary of the Wimpy Kid: The Deep End”, which follows Greg Heffley’s summer story, a dramatic summer yielded great memories, things could be tough initially, but if I keep continuing on this track, hopefully, the result will be what I aimed.

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

Sprint Retrospective – Sprint 1

For the first sprint of the semester, I individually didn’t get as much done as I hoped to. I did help others, and collectively as a team we got a good amount done,  but I hoped to get more done individually. For this first sprint, I spent a lot of time looking through the project and the different repositories to find out about each component, how it worked, and how it interacted with the other components. Due to this, I feel that I learned a lot about how the project currently works, how it’s supposed to work, and what systems currently function or do not function. However, this also means that I didn’t have a lot of completed tasks.

The only issue that I had assigned myself on GitLab was the one to rename the subprocess files in the Reporting Backend. We felt that the names ‘send.js’ and ‘receive.js’ weren’t very descriptive, and in order for them to properly reflect what they were for, they would need to be renamed to something more descriptive. This sent me down a rabbit hole of looking through the project files to see everywhere the files were referenced so that nothing would be broken by renaming them, and also to be able to update the names in any documentation in which they were referenced. This led me to discovering that many things in the project were pulled from an old version of the backend, and that many things would have to be redone in order for it to pull new changes and build the image from the new repository. Additionally, I noticed that there were two sets of send and receive files, one in the subprocess folder of the backend, and one in the RabbitMQ folder. This had me very confused, as I at first didn’t know what the send file was for because our module wouldn’t need to send any information through the queue system, but then I discovered that it was simply to insert dummy test data into the queue for it to be received by the backend. I still don’t fully understand why there are two sets of these files, but I now understand what they’re for and will be able to modify and use them.

What worked well within our team was everyone being individually proficient, as well as being proficient in certain areas that others were not. Everyone on the team had their own strengths and weaknesses, and we were able to coordinate so that people’s strengths complimented each other, working towards a more cohesive whole. For example, I am more knowledgeable about the backend systems more so than the frontend systems, so I know more about how the docker containers work and some JavaScript, whereas others know more about Vue and the design of the frontend and are much more proficient than me in JavaScript.

What didn’t  work very well was our team communication. We communicated mostly only in class, and only minimally out of class such as on Discord. Given that we were all individually proficient, we had less of a problem completing tasks individually, meaning we had less of a reason to communicate what we were doing and what progress was being made. I think that sharing more information with other team members periodically, such as what progress has been made, what you’re working on, and what still needs to be done, outside of the scheduled times, could have been very productive and helpful for the team.

To improve upon this, we could have scheduled times for meetings outside of class via Discord, where we could discuss the details of what each of us is currently doing and ask others if they need help or if we need help. This way, we could more immediately resolve an issue that someone is facing, rather than having to wait until the next class to discuss the issue with the other team members. Additionally, the extra time spent as a team could help us to figure out each other’s strengths and weaknesses, and to discuss how we could work better as a team.

Individually, I could have improved upon a few things. First, I should have focused more on completing certain tasks, rather than exploring the project independently of any tasks. I could have learned everything I did about the project while completing tasks, rather than without completing tasks. Second, I could have better shared what I learned about the project with other team members.

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

The White Belt

The apprenticeship pattern I’m going to be looking at today is called “The White Belt”, from chapter 2.

The use case for this pattern is when a programmer has reached a point in their development where the rate at which they learn new information has begun to decline. The proposed solution is to hold on to newfound confidence while setting aside newfound knowledge. This way the new knowledge has time to sink in before it is synthesized with old knowledge, allowing new information to flow more easily.

I liked the example brought up here of Dave, a therapist. He found greater success with his clients after approaching his clients with as few assumptions and as much curiosity as possible. I feel that this demonstrates that this is a useful general principle for learning, rather than just one for learning about technology. This is why I find this idea compelling.

Something I found insightful in a more practical way was the idea of suspending the use of idioms you are familiar with in favor of the ones that are considered “best practice” for whatever tool you are using. Even if you don’t necessarily agree with, for instance, the concerns that Java programmers focus on, understanding the community around a language is essential to understanding the language itself. “Emptying your mind” in this way can be especially helpful the more unfamiliar you are with the language you are using, like if you were moving from a procedural to a functional language, for example.

I think that with technology fields in particular, there is immense pressure to be perfect, or at least exceptional. It can be extremely difficult to sacrifice productivity for benefits that are not immediate, and even more difficult to risk looking like you don’t know what you’re doing. Still, this is a leap of faith one must take to be good at what they do. Having it said so clearly makes it easy to see my hesitation as kind of silly.

I think I’m also going to add the book mentioned at one point, “Working Effectively with Legacy Code”, to my reading list. Not much was said about it, save for the effect it had on one reader, but it sounds like something that I, personally, would be really interested in. 

Another thing I’m going to try at some point is the exercise about rewriting a program with different idioms. I want to take something very simple I wrote for practice once, like a program that converts between temperature units, and rewrite it in a completely different language with idioms that are totally unfamiliar to me. I’m not really used to caring about idioms in this way, so I feel like this is the next big step forward I can take as a programmer. 

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

Sweeping The Floor Learning Pattern

This pattern is very important it tells us how to begin the career switch from student to paid professional. It is a scary moment of unprecedented uncertainty. It helps us see with a clearer image that there are levels of expectation. These expectations are stratified to build a path to success. It also throws cautionary tales of getting comfortable doing the work at the outer layers of what’s expected.

This is very personal because everyone of us graduating will face the reality of a professional environment. I could not say that it will be harsh or easy. What I can say is that the expectations and anxiety that we generate ourselves is harsh. It makes me feel better to think that the professional world in general has a path in which one can climb, even if this path is steep. The great fear is that there is no path, the goal is the space station, and you don’t know how to build a rocket.

Putting my trust on the writers I expect this sweeping the floor pattern a practiced reality in real situations. I don’t believe there are any menial tasks. All tasks must be completed, and I wouldn’t mind if I had to do some of them or even all of them if it’s all I can do. I have used this pattern in my own life differently. When my car brakes I usually fix it myself because I can not afford the extra expense, this is something that I really don’t want to do. It takes time away from my studies, but it also helps me afford it. Some people say why should they pay a mechanic x amount for only an hour of work but the amount it would take a normal person without the tools and environment would much offset whatever savings they think they had. Most of the time I think if I had the money, I would pay double for a professional to do this for me.

You learn the cost of doing something by doing things you wouldn’t necessarily want to do. Sweeping the floor may begin with doing the easy undesirable work but it must progress into doing work you are uncomfortable with. Success in life comes when you accept uncertainty and never get too cozy as to be paralyzed by extraneous events.      

From the blog CS@Worcester – technology blog by jeffersonbourguignoncoutinho and used with permission of the author. All other rights reserved by the author.

Scrum and I: My First Ever Sprint

                Recently I have had the opportunity to take part in the development of a new piece of software. That software is known as LibreFoodPantry, an open-source tool that is being developed to streamline the day-to-day operation of and record keeping involved in running a food pantry. This is the first real piece of software I have ever worked on with a team and the first real application of the Scrum framework I have taken part in. Being in this unique situation I am inclined to talk about the experiences and difficulties I faced during my first Sprint both to those who may have not used Scrum before and to those who are just looking for something to read.

                From the beginning I and a group of my peers were tasked with creating a secure login service for LibreFoodPantry that would allow users to sign up and sign into the food pantry’s website. This sign on system also had the goal of allowing administrators to log into and manage the website and its users. The main goals then were to create a sign in that both users and administrators could use and having the website display different options based on the role of the user signing on. While nervous at first I found it fairly easy to get behind this idea, especially considering the goal would be to utilize ‘Keycloak’ an open source login service that will take care of most security aspects leaving us with the task of understanding how to utilize it, and configuring it to run with the website.

By virtue of this being a Scrum based workflow, we were left to plan out a backlog of jobs to finish in this sprint as well as hosting regular meetings to ensure we progressed accordingly to the jobs assigned for this sprint. We also needed a Scrum Master to ensure that everyone was able to progress as needed and suggest solutions to any roadblocks that may appear during the development process. For this first sprint I was lucky to be chosen for this position and with that we got to work.  

Splitting those large goals into smaller tasks to put into the product and sprint backlogs generally proved to be easy enough. We then got to work and were each assigned separate tasks to complete. I myself was given the task of creating documentation for each of the repositories while may have created a simple frontend to test Keycloak on. Much of this first sprint came down to research on how to integrate Keycloak with our website and how to allow users to sign up, login, and disallow any use of the site without a login.

                The team worked well together and we made it a point to, at least twice a week, have a meeting to discuss our progress and if anything was holding back our progress on a certain job. From a teamwork perspective communication was solid and any resources found were shared via a group chat should another team member find them useful.

                It became clear as we went on however that we had underestimated the amount of work some jobs might take. Along with this, it dawned towards the end that we do not need to all commit to different jobs, but we can create small groups within our team to quickly take care of larger jobs. All of this really became clear as we neared the end of the sprint and realized that there were still some remaining jobs. I myself found that I was stuck on a single job most of the sprint trying to get Keycloak to work in some capacity and did not get to do any job past that. Along with this I found myself being too immersed in my own work and communicating less than would be ideal especially considering I was suck and could use the help.

                While none of us lacked enthusiasm it was clear that we lacked experience working with Scrum and the Sprint cycle. This however is nothing that cannot be improved upon with due diligence and time.  Scrum in of itself is a self-organizing workflow that sets aside specific times for review and adjustment. Going into the next sprint I can say with certainty that we will perform better and build upon the experiences of our first sprint.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.