Sprint Review #3

This sprint was the worst one for me. The team did great job, it’s just I, who did not did much job in this sprint. This sprint/weeks of this semester was a roller roaster for me. So many projects to do, presentations, assignments, essays. Every professor was pushing their assignments. I learned a valuable lesson this past weeks and it was a “stick with one capstone my friend”. I took two capstones as I liked both software developing and data analysis. It is not that, I liked one capstone and dislike another one, it is because of the amount of work. I think it is okay to take two capstones if you are taking only 2-3 classes so that you can only focus on capstone classes but a semester with 5 classes, 4 of them are CS courses and each classes having final projects was a hell for me.

As for the sprint, I did not do much work than just cleaning up some code. You can find the commit here. In the console of the browser, there was an warning saying the request to HTTP request may not success every time. So I simply added a try catch to get rid of that annoying warning. So now if we make a bad request to HTTP then the code will console log an error. Another reason I added try catch is that, suppose we were to use this program in real life or real POS or anywhere where this application will be running and if there is a bad request then the application will crash. And nobody would want to restart the application every time. With try catch, the application will console log the error and keep running. That is all I did for the sprint. I did not put much work to the team and I wanted to do more but with tight schedules, I wasn’t able to do much. There was able another error with my device, the docker image kept failing for my MAC while it worked for the other devices of my team mates who had windows. I had that issue until my scrum master told me to add a timeout in the docker file which did fix the issue but then it was pretty late. It was my fault for not talking about it in meeting or in discord group chat. I was responsible for getting in touch with another group about key-cloak but I never had time to.

Final thoughts: Front-end wouldn’t have been success without Michale Friederich. He did all the integration between back-end and front-end. If I were to do that then it would take me longer. So hats off to him. Everyone in the group did an amazing job throughout the semester. I have read everyone’s sprint review blog and they are putting in the work more than me. If it were to be different team mates then I don’t think we would have finish this much of work at the end of the semester as everything was new to us. Everyone in my group had a great vision of what the project should look like at the end and we delivered it about 95% of finished application. The next group who will take over after us will just have to clean up the code, connect with key-cloak etc but it will not be as messy as it was when we first received the application as we had to reformat everything. Overall, I was paired with talented developers and I am glad I paired with them. Happy Coding!

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

The Long Road Pattern

For this week’s apprenticeship pattern, I did a reading on “The Long Road”. The Long Road pattern is about your future. In this pattern it talks about trying to imagine yourself 10 years, 20 years, or even 40 years from now. They want you to think about that and possibly write down a summary of your profession. By doing this, it will enable you to think how you would want your professional path to be like and allows you to plan how things could go. The problem in this pattern is that you want to become an expert in what you want to do however, things may get in the way like that such as promotions and just always picking the highest paying job and by doing this, it takes away the goal you had originally which is to do something that you enjoy doing but instead doing jobs that in reality sucks.

My initial reaction to this, is that it is an interesting pattern to read about. It is interesting because I never thought to look past 5 years into the future and just thinking about the future and where I want to be in general. Obviously, everyone wants to make six figures, but the main goal is to make that much by doing something you love or enjoy doing. After reading this pattern I did take a moment to think about where I would like to be down the road and it made me realize what I really wanted to do with my future. Of course things happen, and the future isn’t exactly set, but it gives me a good idea of what I need to do and what I have to do to accomplish it.

The pattern has changed the way I view my profession because I never thought about needing to take a step back and think about the distance future of where I would like to be. Do I still want to be programming all my life or would I like to do something different by the age of 40? It was an eye opener to me because it really allowed me to set goals that I want to achieve by a certain age. Sure, programming is fun and all but there’s much more to life than sitting around a desk and creating programs and such. I want to create memories that will last a lifetime and explore the world.  If I can find a career that would enable me to do that then that would be the ideal job.

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

Sprint Review #3

This past sprint session was my teams final sprint for the semester and our main focus is now on our final presentation. During the first sprint we spent time setting up front end and back end files with the goal of making a simple system to secure with Keycloak. The Keycloak implementation in itself took much more time than anticipated so our final product is Keycloak securing a simple front end vue application. There were many roadblocks in getting Keycloak to work – JavaScript connector not working, figuring out how to create a shared realm with multiple users, and general issues coming up with each step we took in trying to link it with a web app. Initially we have assigned different team mates to different areas of our project but by the middle of the second sprint getting an instance of Keycloak to work became an all hands on deck priority. I did spend some time working on a backend with the hopes of linking it with our front end however there is not enough time in the semester. The front end, back end, and API should each have their own dev container and this is something the next semester students can pick up, however I did go in and create a dev container for the API. I wanted to make the system ready for future semesters to pick it up from there and link the pieces together. The most important part is we have figured out how to attach Keycloak to any web application and the next semester students should be able to use our research to secure LibreFood Pantry with Keycloak.

Our group worked well during our final sprint and I think our communication skills all improved greatly over the course of the three sprints. Keycloak being an add on to any system comes with many “wires” to connect to the existing system and we experienced issues at almost each next step of connecting it to the vue app. Our team had to learn how to communicate at each road block and work together to solve the problem. I think towards the end we improved by talking about these issues during class and finding solutions on the spot and making decisions then rather than taking the issue home and trying to figure it out on your own. Most of us have preferred to work on coding projects individually however that isn’t how real programming jobs work. In an office setting the software development team will be expected to collaborate on the project and constantly merge code together and all work on different pieces of the same over all system. I’m grateful to have a better idea of how to work with other developers and this will help me in my first programming job.

I am proud with the final product we created. We hit the main goal of understanding Keycloak and learning the steps to implement it with any web application and if we had more time in the semester I think our group would have been able to connect it to LibreFood Pantry, and I am excited to see the next semester students take our work to the end.

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.

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.