Sprint 2 personal Retrospective

For our second sprint I think our group improved in many aspects of the process. Last sprint there was a lot of confusion around what exactly needed to be done and how, as well as issues with managing time and expectations. The group also had relatively poor over all communication over discord, although that was more attributed to the fact that many tasks did not really need to involve more than one team member at a time. We addressed those issues in the last sprint retrospective and this sprint I believe that we did much better over all. Firstly we communicated much more than before, using discord more often to ask questions or gather information that we need from other groups. We also had more clear goals this sprint, which consisted of getting many aspects of the back end written up and hopefully working, as well as finishing up refactoring the front end. The team did a good job getting all the tasks done in a timely manner, even writing in stand-in code in areas where another team member was working on implementing a feature. In this case that team member was me, as I was working on inventory.js my team was finishing up their endpoints, and since they could not connect to anything they created stand-ins while I finished up my portion of the project. Another area I think we did good in this sprint was being timely with merge request approvals. This sprint if a merge request was created it tended to be approve within a few hours.

As a team I think we did much better this sprint compared to the previous sprint, and we flushed out pretty much all the big issues we had before. I do not really have any suggestions for things that we could improve going forward as a team. We communicated well, managed our time and work load well, and in the end got almost everything we needed done. As a team we have found a system that works. As an individual however I definitely have some things that I know I can continue to work on to improve going forward. The biggest is still time management. I did better with my own time management this time but I still could do better as I did leave many issues for later in the sprint; however I did not save them for the last second like I did before.

Since there was not too much that can be criticized with the teams performance this sprint, there are not many things I believe that we need to directly address to improve on next sprint. We will however need to keep this level of performance, and most likely bring it up a notch next sprint. While we have not had a planning session yet, we have discussed an abstract of what will happen next sprint, and the main focus will be testing and fixing bugs. Given that this will be a very involved task we will need to be communicating even more and there will have to be more collaboration between members as bugs may pop up in multiple areas of the project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/blob/BackendCreation/src/data/inventory.js

I primarily worked on getting inventory.js written out with the correct endpoint connections so that the team members working on the endpoints can use them to connect to the DB.

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.

Sprint 2 – Retrospective

I thought this sprint went well. While the team definitely has room for improvement, I thought that the team cooperated and managed to accomplish our main goal for the sprint, which was to give functionality to the backend of the project. We managed to add the necessary endpoints as well as give invesntory.js functionality. We also managed to accomplish other tasks like adding commitlint to the gitlab-ci.yml file in all the projects repositories as well as coming to a consensus regarding the naming conventions and style decisions. I thought that, overall, the team was much more cohesive this sprint compared to the previous one. The team was able to communicate much more effectively, and the team was more aware of what needed to be accomplished.

I think the team still has room for improvement that could help us become even more cohesive and efficient. I think the biggest area where we could improve is how we come up with tasks and divide the labor. The tasks that we had in our sprint backlogs over the past couple of sprints were rather imbalanced. There were some tasks in there that were important, challenging, and took a lot of time to complete. But at the same time, there were also other tasks were minor, easy, and took little effort to complete. This led to some team members having tasks that would take them more than one sprint to complete, while other team members did many simple tasks and were left with little to do by the end of the sprint. I think this sprint we should try to break up the big tasks into smaller ones, and group minor tasks into bigger, more general tasks. I think team members should also ask the other team member for help if they think that they cannot finish their task by the end of the sprint.

Individually I thought that my performance was satisfactory. I mainly worked on adding commitlint to the gitlab-ci.yml file in the project repositories, but I also spent time trying to understand how RabbitMQ worked. For the latter, I created a demonstration for RabbitMQ that shows how things are sent and received. Ultimately, I managed to complete six tasks by the end of the sprint that are worth seven points. I think my biggest issue was that the tasked I worked on were either too specific like adding commitlint or too broad and vague like figuring out RabbitMQ. I also think that I didn’t communicate with my teammates as much as I should have.

Personally, I have a lot of room for improve in several areas. One of the areas that I want to see myself improve is communication. I felt like I did not communicate with my teammates as much as I should have. For example, I felt like I should have kept my teammates updated with my progress on the RabbitMQ demonstration. For the next sprint, I want to use Discord as well as class time to communicate with my teammates more. Another area where I want to improve is taking on more challenging tasks. Over the past couple of sprints, I felt like my tasks were either too simple or too minor. So, for the upcoming sprint, I want to try taking on a bigger and more challenge tasks.

List of issues that I worked on:

Issue InventoryAPI#2: Added commitlint in gitlab-ci.yml in InventoryAPI.

Issue AddInventoryFrontend#6: Added commitlint in gitlab-ci.yml in AddInventoryFrontend.

Issue CheckInventoryFrontend#4: Created gitlab-ci.yml in CheckInventoryFrontend and added commitlint.

Issue CheckOutGuestFrontend#7: Created gitlab-ci.yml in CheckOutGuestFrontend and added commitlint.

Issue InventoryBackend#27: Created gitlab-ci.yml in InventoryBackend and added commitlint.

Issue InventoryBackend#22: Spent time learning how Rabbit MQ works and created a simple demonstrations that shows how things are sent and received.

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

Kindred Spirits

Apprenticeship is a long road, a road that doesn’t look easy at first, a road that is filled with uncertainty, doubt, questions, a road that can bring lack of self-confidence, a road that can take away your passion and leave you to think that you are not good enough. What is the best thing that someone might desperately need during this long journey to feel reassured, to feel understood, to keep that passion burning and ideas flowing? This chapter is telling us how kindred spirits what is exactly we need in our journey as craftsmen.

As the book states, the problem today is that organizational cultures that encourage software craftsmanship are rare. We find ourselves stranded without mentors and in an atmosphere that seems at odds with your aspirations. I remember talking couple of weeks ago with one of my classmates about this issue. Today graduation is around the corner, and we are at the door of apprenticeship with the fear of not being supported, of landing in a company that doesn’t value progress, ambition, passion, and willingness to achieve. I want to work in a company that feeds my aspirations, where ideas are exchanged, where there is life in the job that I do. And not just doing exactly what is expected of me, making things hard and boring.

It is important to be surrounded by people who share similar goals and values as you. People that enjoy learning together, advice are shared among the group and there is the enthusiasm to get out of a comfort zone. I also believe it is important to stay connected to the people that inspire us and fee our mind. Making a list of communities and getting involved is important. I am thinking that LinkedIn is a great example of this. It is not just a platform where you can find job opportunities, but it allows people that share similar values and goals to connect, stay connected and grow they passions together.

The last point the author mentioned is about the need to retain our thoughts and the ability to ask critical questions and not just go with the group. This was very relatable to me as I sometimes find myself having a great idea and hesitating to share it with the group. Or a better idea can be shared before I share mine and I end up losing the confidence. I realize that we should not feel intimidated by other people’s ideas and mindset. Creativity and critical thinking are things we all possess. I personally will not hold back anymore and will speak my mind because it might benefit my community.

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

Sprint review #2

This sprint I feel as though my team and I made a lot of progress. One aspect of our project that was really holding us back was getting a keycloak instance up and running. We were able to follow a tutorial guide online to make a basic vue app and secure it with keycloak and all create our own users in the realm.

Our team worked very well this semester and I believe we were able to improve our communication in our team. We have implemented a twice a week virtual check in on thursdays and saturdays and that has been a great way to check in with each other and this has improved our progress.

One thing we should work on during the final sprint is getting our demo up and running and secure it with keycloak. Although our team communication has improved I believe we should begin to make better use of the issues board and add more updates to issues as we work on them through the week.

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

Sprint #2 Retrospective

With reflection on the previous sprint we had a more clear vision of what we could modify and change about the front end systems and possibly some work to be done about the back end system. We also as a group decided to reach out to the IAM and AWS teams to see if we could integrate their work with ours. I also had not finished my previous tasks so it was an issue that I personally needed to address and focus on during this sprint.

I still had the two previous issues from the last sprint on my hands but I did take the responsibility of communicating with the other teams and start working on understanding their work to help integrate it with our team.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/8

On this sprint the majority of my time was working learning html and CSS, but in a manner that was constructive and effective as my previous sprint learning session did not go well. In this sprint I had a far more effective learning period by following a six hour html and CSS course which helped me greatly [https://www.youtube.com/watch?v=1Rs2ND1ryYc]. A major portion of my time was watching this, pausing to test out the things I learned and working on the html pages for the Worcester state styled formatting. This would all have been added to their necessary repositories, but I noticed something both funny and disappointing at the same time that changed all the work that I needed to complete.

While I was nearing the end of the sprint I felt as if the pages I did have were ready for testing and possibly creating a branch for and wanted to test it in one of the front ends. I tried running the front end docker containers on my desktop, but I never could get the local host page to run. It would load forever and never show me anything. I also tried separate front ends to see if it was just one front end’s issues, but I still had the same issue. It wasn’t until I tried running two front ends at the same time and had to change one of the ports to discover that it was just local host 8080 that was having a hard time. I tried connecting to it without any containers running on those ports and a page I had not seen in a while showed. It turns out somewhere on my mac laptop Jenkins was running [https://www.jenkins.io/]. This was preventing me from running and I had to do a deep dive through my laptop to find it and stop it completely which had taken far more time than I wanted to. With it disabled I ran the containers and connected to the local host page. It was there that I found that a front end landing page had already been made and implemented and I had unnecessarily wasted my time on trying to create pages for the front end systems. Now I don’t feel as if my time learning on html was wasted but the app.vue already had the needed formatting and style that was appropriate for the landing pages.

Right at the weekend before the end of the sprint was around the time that the IAM team contacted me and provided information on how to set up the keycloak system and I had spent a little bit of time that weekend looking it over. That same weekend was when I had made the discovery about Jenkins. The href task was easy enough to implement and I had tested it and it worked. I just did not have the time at the end to create my own separate branch for each front end as I felt like it needed to be split into separate and specific issues for documentation reasons. The next sprint will have those two fully solved and I’ll probably be focusing the majority of my time on integrating the IAM teams work and testing out their work with ours, but at least I understand html fairly well now!

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Stay in the Trenches

Christian Shadis

In the apprenticeship pattern Stay in the Trenches, Hoover and Oshineye explore the importance of maintaining a development position in the face of success and the opportunity to progress into management. This is a very important topic, since many developers (and employees of other types too) have their careers reach stagnation once they make the leap into management due to their misconceptions about career progression.

This pattern is counterintuitive to me, as historically I have considered management positions to be the goal of any employee, and the thought of turning down a promotion would not seem to propel a career forward. Upon further reflection, the benefits of the pattern are more apparent. If a developer commits to remaining a developer throughout their career, they remove limitations on their potential growth as a developer and employee. They will continue to grow and evolve with the industry and become masters of their craft. Conversely, a developer who accepts a promotion into management may stagnate quickly. Management is a completely different occupation than development, and the recently promoted manager may find their skill set does not transfer. Similarly, the organization may not have much room for progression beyond middle management.

Remaining in a development position instead allows the programmer to spend their entire career mastering their development skills, increasing their capabilities and qualifications for more intense, higher-paid, senior-level programming positions. The programmer can advance and progress with development-based promotions, but staying out of management lends a significant advantage for attaining more prestigious programming jobs in the future.

I hope to use this pattern throughout my career. Once I had aspirations of progressing through management positions until I am high up at a large company, but progressing through management positions won’t be possible by virtue of programming skills – instead, a more attractive plan is to progress through the levels of development and engineering to finally land at a senior position. Not only will this maximize my potential as a coder, but remaining in a position interesting to me instead of stagnating in a more boring occupation will maximize my job satisfaction.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Walking the Long Road. 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.

Sprint Retrospective 2

For this sprint we did much better as a group. Communication improved and we are comfortable with the project now. After the first sprint I was worried about how we would perform but now I am much more confidant in our abilities. I am excited for what we will achieve during the upcoming sprint.

Over this past sprint we have gotten the backend to work, added commitlint, updated config files and pipelines, and learned how to use RabbitMQ. I personally did the commitlint for the backend, frontend, and API projects, and worked on the pipeline. I am happy about how everything turned out, and I feel like I learned a lot about how commitlint and the gitlab pipeline works. When working on commitlint I decided it would be cleaner to work in a separate branch since I needed to push to gitlab in order to test my work. I am happy about how it worked in the frontend project, but in the backend I accidentally worked on the main branch instead of the commitlint branch. When working in the future I must always be aware of which branch I am working on and review my work before pushing, since you should not orphan public commits.

When working on the frontend I ran into a problem that was not present for the other projects. I found a solution on stackoverflow and made a comment about it. I am not sure that this is the best place to explain myself since I wonder if people will be able to find my comment in the future.

One thing that I am happy about is that I have increased my workload. I still want to do more in the future, but I am happy that I am doing more to help my group out. I think this is something we could all work on as a group. Most of our work is done in class which is ok, but we would get much more done if we all worked outside of class. One thing I think we could do to improve this is to schedule out-of-class work sessions where we would work for a few hours.

One thing that I think didn’t go well was branching. We made many branches this past sprint, and I do not think we used them properly. In my case, I made a useless branch since I did not use it at all. I feel as though using many branches, while useful, can contribute to confusion with our team and future teams. I do think we should be branching, but I feel as though we could do it better.

Overall, I am happy with the progress we are making. I am glad that the backend works finally, and I am glad that the gitlab project is coming along. I am excited for the upcoming sprint since we have almost finished refactoring, and we can begin working on new features. I am concerned about making new features since I do not have any ideas as to what to do, but whatever we decide to do as a group will be fun to work on.

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

Apprenticeship Patterns: Breakable Toys

Christian Shadis

In the apprenticeship pattern Breakable Toys, Hoover and Oshineye explore the effectiveness of learning through failure, and the dynamics of doing so in a workplace where failure may not be embraced. Essentially, they advise the developer to work on projects on their own time with the important distinction that they can safely develop without harming any other developers with breaking changes. They refer to these projects as ‘Toys’ because the developer should work on projects they find interesting or fun, which will make them more motivated to continue working on it.

This pattern, unlike some others in the book, is perfectly intuitive. “Practice makes perfect” is one of the more well-known clichés we echo, and this pattern is based on constant practice. In fact, much of the information I’ve learned about programming thus far has come from troubleshooting code I’ve written and figuring out why it doesn’t work. The only problem with constantly practicing a trade menially is a blurring of the lines between work and free time; however, developing projects of personal interest to the developer would make the practice far more engaging and feel less like work.

This pattern is not a particularly difficult one to implement, as developers are likely to build personal projects simply because they enjoy development. Yet if a developer uses their skills to build something they don’t care about, it only feels like work – instead, working on building ‘Toys’ feels more recreational and sustainable to implement in free time. To effectively use this strategy, the developer must emphasize the breakability of what they build and focus on using failures to improve both the project and their underlying development skills.

I hope to use this pattern throughout my career, but more specifically I plan to implement this pattern throughout my first development job. I will be exposed to many new technologies and frameworks in my new position. Using these technologies only at work would limit my comprehension of them. Instead, utilizing these new technologies in the failure-friendly environment of personal development projects will maximize my improvement as a developer.

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.

Sprint Retrospective #1

This blog post is about the sprint 1 retrospective. This is our first sprint as a third group in the Cs-448 class. The topic of the project that we will be working on, which was presented to us as a team is about LibreFood Pantry AWS Deployment. In the first moment, the professor sent an email as a beginning to present us that what group we would be in, who would be the members of our group, and most importantly what would be the project we would work on. That was our first familiarization with our team members. Working as a group for one project, I took it as a very positive thing. I really like when I share ideas with other people about a specific topic, and I also like when I take ideas from others from where I can learn too.

The first thing we as a team did, was that we first created the issues. After that, we shared the roles on what we will be working on. We had very good communication as a team and we also were really clear about the project. The issues I worked on were the Deployment Option for EKS and the other issue was research I did about the Microservices Architecture.

These were the two issues I worked on. In the first issue I had about deploying options for EKS, I tried to give some tips about deploying applications Amazon EKS in the cloud, also I tried to determine which deployment options for EKS we should be using. For my second issue, I mostly did research on what is Microservice Architecture, when, and how to use it, and most importantly the benefits that microservices have.

Working as a team on one project like this, looked like a little challenge thing for me. But at the same time, it helped me improve my acknowledgments. We as a team on this first sprint tried to share ideas, and give our contributions regarding the issues that we created. We had some struggles mabey in the first days we started working on the issues, but got the point. And I think that overall we have done a very good job as a team. We also tried to find other communication ways, like writing for any question or suggestion through discord, and also we have met each other virtually through zoom meetings. These helped us a lot as a team too. And hope that all other sprints will work better than we start.

The issues I worked on:

Deployment Option for EKS: https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/15

Research Microservices architecture: https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/14

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

“Nurture Your Passion”

Passion is the devotion we invest in of our interest, could be a hobby, sport, or even a profession. Upon reading the book “Apprenticeship Patterns”. There are multiple chapters that are divided up into 35 patterns to give a breakdown of the broad idea of being a craftsman. For example, I have read chapter 3 “Walking the Long Road”, towards the pattern of “Nurture your Passion”. This pattern entails about keeping a strong leveled mentality. Going into our career field as a software developer which the environment would cause an impact on one’s passion. This pattern gives us an idea on how to tackle this situation. 

After understanding the purpose of this pattern, I saw it made sense to find multiple ways to help keep positive during workflow. The section of drawing your map caught my attention because whenever we have a certain goal, dreams, and needs it is separated out from our work goals, dreams, and needs. Two different lives which you try to maintain but eventually it outweighs each other which conflicts you. Personally, speaking we would rather just be selfish and accomplish our own goals and dreams. We are only human. But at the same time, we do not want it to conflict our mindsets when it comes to our profession.

For the type of action, they would want to conduct to keep our passion in check was to write up a list to control a conversation.  It is true you must keep a cool mind and keep your mind positive. But there will be days where things will not work out. For example, what if you had a bad day, the only it will do is put you in a funk for whatever reason It may be. Work related. Personal related. There are many factors you don’t have control like an environment or said workflow. 

I believe that I can take these steps but not all of them. I do agree that you must absolutely make sure the passion is there and do however to protect it because it what makes us motivated to stay concentrated. People are different and should be able to nurture their passion differently. Composing a list can help but nobody would like to compose one before work daily, that can be taxing. Sometimes you must be selfish, such as leaving work while the team are staying late. Just playing it by ear on a daily as it can shift constantly. A road we are set and take the necessary actions. 

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