Category Archives: CS-448

Sprint retrospective #3

This last sprint has been different from the other two. This was our last and we needed to talk and communicate well with the team and know exactly what to do for the last sprint. We started by talking about the issues that we created in the past sprint that we did not finish and then after that, talked about the plans we had for sprint planning 3 and the new issues that needed to be created.

The issues that I have created and worked on are: “Discuss Integration with Inventory System”, “Research Kubernetes from AWS Team”, “Backend: Create HTTP calls for Database”, and “Research: How to deploy RabitMQ on Kubernetes”. These issues were put under the status “done” because we had all the information needed. I did not really have time to work on the first about discussing integration with the inventory system from the other section but my teammate Mike Morley talked with them and gathered all the information needed. I did work on Kubernetes, actually, 90% of my time working on it.

I talked with the other team too, but did my own research and gathered all the information I needed. One of my Teammates Andrew Sychtysz talked with the Scrum Master from the Kubernetes team and also did his own research on the same issue as mine. The more information we have, the better. Kubernetes have a lot of interesting articles, but with them, I felt like the information were very broad and too much, so I decided to watch videos/tutorials. I did watch a lot of videos and learned a lot about Kubernetes and I am planning on sharing all that I know on GitLab.

The other issue about Rabbit MQ, I did a lot of research on it because for some reasons but since it was not part of our project, the professor said to abandon that issue. But I am deciding to talk about it at least because I do have a lot of information on RabbitMQ that I found interesting and did watch some videos and read articles.

As individuals, we did work and completed what we were supposed to do. Some issues still need reviews, some will be put back in to open section for those who will work on this project next year. As a team, we all contributed and were there for each other whenever we needed help. For example when Mike Morley helped discuss with Inventory System from the other section because I was not available to do that. Also when Andrew helped with Kubernetes, or when I and Lena Viazmitinov worked on the backend. We might not finish the project but we did work and have all put up with the work.

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

Final Sprint Retrospective

Christian Shadis

This past week, my development team in my Software Development capstone completed our third and final Scrum sprint for the Spring 2022 semester. We completed our final Sprint Review on April 28th and have officially stopped working on the project. This was my first experience working in an Agile environment, along with my first time working on a Humanitarian Free & Open-Source Software Project.  

There were several areas in which our team excelled. The team did an excellent job of labor division, as through the entire semester, all team members were contributing equally to the advancement of the project. We also worked well together as a group; we were able to concurrently work on code very effectively, combining the knowledge of everyone to solve problems we couldn’t as individuals. Throughout the semester, we improved our workflow, increased efficiency of standup meetings, and improved the organization of our source control and merge processes.

There were some areas to improve for our team. We struggled to create appropriate issues in Gitlab to work on – we often found that we were creating issues that were too vague, too large, or duplicates of another issue. We also could have done a better job of maintaining the Epics board in Gitlab; we focused primarily on the issues and not on the Epics they were attached to.

As an individual, I worked well throughout the semester. I was the Scrum master for my team, a position I had never held and was not confident in. I challenged myself to help the team stay organized and balanced in our Scrum meetings and saw improvement throughout the semester. During the first sprint, we would often get sidetracked during standup meetings talking about problems team members were running into and were using more time than necessary. I was able to help the team keep our focus on the current meeting and save other discussions for after, increasing the efficiency of our utilization of class time.

I believe the semester went well both for the team and for my individual work, but there are areas in which I can improve. First, I found myself feeling disorganized occasionally throughout the semester from making too many changes at once – I would like to get better at treating issues as small, independent tasks that are fixed alone on a branch and then merged, instead of completing several small changes in the same issue and branch. This will make it easier to stay organized with what I am working on and will make the source control system more effective at tracking the work I did on each issue.

I contributed to the project in several ways in the final sprint. The major hurdle we faced was getting the backend and API to connect so HTTP calls can be made to the API. I spent the majority of my time trying to debug the various errors we were running into, such as connection errors and socket hangups https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/40 . This issue is a great example of our misuse of issues – while only one issue was listed, it consisted of many hours of work and many changes to files —  Javascript files, the bash scripts responsible for starting the server, and the API itself. While I was ultimately unsuccessful in completing my fix, I was able to gain a more complete understanding of the project and how each file and component fits into the larger picture of the system.

I would consider the sprint and the semester successful overall. Essentially, we have a working and validated API, most backend code, and have linked the two together. The next steps for next semester’s group will be to continue to develop testing, along with incorporating Identity and Access Management and deploy the server on Amazon Web Services. I feel much more comfortable working in an Agile environment and working on smaller pieces of large HFOSS codebases, and I feel far more capable of working as a developer professionally in the coming year.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Nurture Your Passion

Christian Shadis

In the apprenticeship pattern Nurture Your Passion, Hoover and Oshineye explore the importance maintaining an interest, curiosity, and passion for computer science despite hostile conditions. They discuss the ways hostile work environments, boring projects, and cynical coworkers can bring down the morale of programmers, especially those in a developer position rather than an engineer position. They discuss the ways in which the developer can resist these negative external conditions to maintain their passion for the subject and continue growing as a developer.

This pattern coincides well with the Breakable Toys pattern, which discusses using interesting personal projects to supplement your development skills to avoid stagnation. Using this pattern would be an excellent way to Nurture Your Passion. Working on fun and interesting projects is an intuitive way to gain appreciation for a skill and spending the extra time working and learning on your own is an excellent way to supplement your knowledge in the subject; a win-win!

The pattern makes a lot of sense – in my non-CS jobs, I often felt uninspired and bored. While the work was not as engaging or creative as development, I was completely devoid of passion for my work. This made the day drag, led to resentment for the company, and caused an overall poor experience working. Working in a field that I am far more interested in will give me the opportunity to have passion for my work, but I must try my best to ensure it does not fizzle out due to stagnation. If I lose passion for coding, my development job will become as unfulfilling as my previous jobs.

I hope to use this pattern throughout my career, but especially so over this coming summer. I am likely most qualified to be a software developer, which is not as exciting a job as an engineer but using this pattern will ensure that my passion for development does not disappear before achieving a more desirable position. Specifically, I plan to rebuild my website in a full-stack capacity to fill in web-dev knowledge gaps, but also just to have fun working on a type of project I have not before.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Perpetual Learning. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Apprenticeship pattern: Find mentors

This week I read the pattern “Find mentors”. In life, we all need a mentor who will train, and teach us what will become our knowledge tomorrow. Some examples: in schools, universities, at home, our mentors are our teachers, professors, and parents because they teach us and train us to become great people in the future and whatever we know today, it’s thanks to them and their sacrifice. But we have to keep in mind that tomorrow, we will also be someone’s mentor or leader.

In this pattern, the author is talking about seeking out those who have gone ahead of us and striving to learn from them. Everyone at some point has been an apprentice. Teachers, before becoming who they are, were students like us too and had mentors (teachers, professors) who made them who they are. Parents, yesterday were children too and had their parents who were their mentors/leaders and examples for them to follow. It’s a rule of life, which is we can only give what we receive.

To become great software developers, we need to surround ourselves with software developers who already have the knowledge and are willing to teach us and help us understand. Seeking help and knowledge from someone isn’t a sign of weakness, on contrary. That is something that a lot of software developers, even people in general don’t understand.

What I get from this pattern, is that in the computer science field, if we want to be the best or become better at what we’re aspiring for, we need to surround ourselves with people who have more skills than us in the domain that we want to master. Also, we need to keep in mind that we’re walking “The Long Road” and that no one knows everything. Even our mentors learn something new every day. The fact that they know more than us does not mean they know everything.

Our apprenticeship is unlikely to happen in isolation, and just as there will be people ahead of us, there will also be apprentices who have not yet reached our skill level. The other side of our search for mentors is that we must be willing to provide mentoring to those who seek it from us. Passing along what we have learned from our mentors is one way in which we can begin the transition to journeyman status.

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

“Be The Worst”

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

“Kindred Spirits”

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

Craftsmanship Log #8 – White Belt

Although I tend to speak rather broadly about certain apprenticeship patterns, nonetheless many of the patterns I have written about in this blog do apply to the field of Software Development. After all, the book, from which these patterns have originated from, that I have been reading for the past few months is more focused on programming than any other craft. This is the reason why this particular pattern applies to my learning process of Software Development which, ironically, I realise that I have not applied to the degree that I thought I have when learning other programming languages. In fact, a significant part of the learning process is to “unlearn” pre-existing knowledge and approaching learning a craft in a “blank slate”. This notion corresponds to a pattern titled “White Belt” which, though it may seem ironic, it is in fact a very significant pattern.

When a developer faces the need to utilize this pattern, it means that their pre-existing knowledge may be interfering with acquiring new knowledge and skills more challenging, or even impossible. When it comes to programming languages, the know-how that one may be holding on from learning and mastering their first programming language may impair their problem-solving approaches. Oftentimes, they may be expecting to see tools or concepts from one language they already know that are completely non-existent in the language that they are learning. Moreover, the potential differences in syntax can also throw an apprentice off when learning a new language, thus it is easy for us to hit a roadblock simply because the solutions we may want are (or so we think) simply not there. As such, a way to avoid this roadblock is to simply approach the new language that we are learning as its own thing and with a clear state of mind.

Usually, I tend to say that I like or agree with a pattern because in my own experience I tend to utilize such patterns in my own, perhaps roundabout way. However, this pattern is the first that has made me question my own approach to learning, which is contrary to this pattern. I often tend to look for “common ground” between my pre-existing knowledge and the new knowledge before me to “save time” and get to “the good stuff” faster. In a way, this pattern hurts my pride as a software apprentice. And, in all fairness, it should. It is important for me to acknowledge that flaw in my learning process and instead wear the white belt when I pick up a new programming language to learn.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Reading List

The ‘reading list’ apprenticeship pattern supposes a solution to a situation where you are finding books you want to read faster than you can get through them. There are lots of really good resources available for programming, and reading them is a great way to help you improve your programming skills. However, with such an abundance of resources, it becomes difficult to manage everything you want to read. The solution is, as is suggested by the name of the apprenticeship pattern, to maintain a reading list. This list should store both books you want to read and books you have already read. Hoover and Oshineye recommend storing your reading list somewhere public so that other people can see and learn from your list. Keeping a list like this for several years will allow you to analyze your reading habits and pick out spots where there might be gaps in your knowledge. As you work through your list, you can use the bibliographies of the books you read to add new books to your reading list. This can also help you narrow your research down into an area you take interest in.

I think this apprenticeship pattern is interesting, and I think it’s a great way to keep track of what you want to read. I think the advice to read books included in the bibliographies of books you thought were useful is really useful. I also really like the idea of being able to monitor your progress as you work through your reading list. I already kind of do this, just not exclusively with programming resources. I use a website to keep track of the books I want to read and the books I’ve already read. I like being able to see all of the books I have or want to read, because I know if I didn’t store that information somewhere I would forget all about it. It’s also really interesting to be able to analyze my own reading statistics like what genres I tend to read and what days I read more. I use it mostly for pleasure reading, but I think it would be useful to dedicate a section of my existing list to programming resources.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective #3

As the third and final sprint for the semester, and with that my involvement with the N.I.C.E project, has come to an end, it is time to reflect on the progress that has been made, as well as what has changed with respect to team and personal work compared to the previous two sprints. The difference between this and the previous two sprints is that this sprint was the proper beginning of actual implementation of the features that we had been brainstorming as a team over the previous two sprints. With this being the case, we were no longer at the stage where we struggled to find some footing regarding the project’s infrastructure; we had actually begun laying the foundation that this project will be based on. In simpler terms, this is the sprint where we were no longer working on spike solutions, but actual source code. This meant that we were overall working with a more hands on approach to this project.

Though admittedly not perfect, this sprint proved to be the most productive sprint both in terms of actual productivity, given how we had to work over 42 issues, and well as individual and team growth. During this sprint we as a team had a much clearer direction in what we thought needed to be implemented, as well as how we would approach said implementation. This meant that members of both the Docker and the Source Code groups were more independent, which helped make some very good progress. That is not to say that all team members were working in complete isolation – on the contrary, there was by far more communication taking place across both Gitlab and Discord between team members during this sprint. This was especially prevalent in the Source Code team, which I was part of, as I made time to meet independently with my fellow team members to discuss or collaborate on certain issues. In my case, I was assigned to work on the following issues:

1) Implement file parsing to implement a question into a card component
2) Implement a method to make multiple copies of the single question preview component
3) Implement the component that contains a single question preview
4) Build a page that shows previews of the questions for the interview
5) Fix the visuals for the card components on the question previews

Sadly, we did not manage to implement certain issues exactly as we had envisioned them either due to bugs occurring or due to lack of time, though we still managed to make some satisfactory progress despite it all. Moreover, unlike the second sprint, there has also been improvement with respect to time management during meetings, something that we had reflected on and had problems with in earlier sprints. Though there were still cases were the conversation would veer off topic, we as a team were more conscious and thus put more effort into returning to our topic of discussion. This was also affected by our documentation; given that we begun to put more effort into documenting the development process into the appropriate issues on Gitlab, it has been easier for team members to be on the loop and communicate any misunderstandings outside of meetings. Moreover, I feel like my own working process has improved as a result, especially my weakness in properly gauging an issue’s proper weight. During this sprint, I feel like I have improved in taking the proper care to dissect and break down a goal into smaller goals so that implementing a feature is easier in terms of what steps need to be taken towards implementation, as well as seeing how my issue could be connected to another team member’s issue. Thus, instead of panicking to implement a vague issue, I noticed that I made better progress by implementing smaller and clearer issues.

As I mentioned, this sprint was by far the most productive sprint for the course. Though there may have been some occasional flaws or problems in productivity, these flaws were not as significant when compared to the second sprint. Overall, as a team we have noticed that we had finally gotten on a steady and clear path.

Direct links to issues:
1) Implement file parsing to implement a question into a card component: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/42
2) Implement a method to make multiple copies of the single question preview component: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/41
3) Implement the component that contains a single question preview: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/39
4) Build a page that shows previews of the questions for the interview: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/28
5) Fix the visuals for the card components on the question previews: https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/48

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Find Mentors

Find Mentors is an apprenticeship pattern that talks about the importance of having someone that you can directly go to for help or ask questions in order to further your own understanding about the subject matter. This pattern talks about the importance of having a mentor, and the difficulty associated with finding a good one. Mentors can give you insights that you might not otherwise be able to figure out on your own, and guide you in a direction that will be the most beneficial for you. The main issue is finding a mentor who is not only competent in what they do but also willing and able to take the time to help you.

In my internship I was fortunate enough to be part of a small company with a tightly knit culture. As a result I was able to get to know a lot of the people in the engineering department and likewise I was able to pick their brains for new knowledge. I was also fortunate to have a very competent programmer manage me, as I was able to frequently ask them for questions or assistance with certain tasks that I otherwise would have taken much more time and effort trying to figure out on my own. They were essentially my mentor for the span of the internship, even going out of their way to recommend resources for me to look into on my own time that they believed would be beneficial to me. As a result of this experience I whole heatedly agree with this apprenticeship pattern, and I believe that if possible everyone should try to find someone to mentor them. This however brings up the issue mentioned in the initial paragraph, and that is finding good and willing mentors.

After my internship ended it became difficult for me to ask that same engineer for advice, and since then I haven’t really had anyone on the same level as them to directly mentor me. This is why I believe that it can be an issue trying to find a mentor outside of work. When you’re in the office its easy to get in touch with people smarter than you and get help, however outside of that environment its difficulty to find someone who is willing to give up some of their time to help what in many cases is a stranger. The authors do give some advice on how to go about this, and I believe that it is good advice that may eventually lead to a connection. But it still boils down to finding someone that wants to and has the time to help you.

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