Monthly Archives: May 2021

The Final Sprint Retrospective

The most headway came when multiple sets of eyes were on issues. This first proved to be true when the IAM System Community of Practice was working together to establish the logout functionality and to ensure that the user sessions properly expired to prevent unauthorized modification of the database.

This also rang true when Tim Drevitch and myself were finally able to free up time and address out standing issues. As per my comment here, and his comment here, we were able to spin up a docker instance of a database and pretty quickly figure out how to start adding to the database just shy of setting up the specific documents we needed to store individual users/entries. It was three hours of troubleshooting together, researching different aspects, and then explaining them back to each other over voice chat, but we made substantial head way where there was otherwise none (despite it not being a card assigned to either of us).

While there are obvious constraints to having green undergraduate students try to develop software on a very part-time basis, it became very obvious that not all the teams were created equal. When I would meet with the IAM community of practice we would discuss what our groupmates needed of us and I would routinely report back to them that my group had made no mention of any code, functions, methods, etc that they needed from me nor intended to integrate any time soon, much to their surprise. This signals to me an overall unfamiliarity with the tech stack which is not a judgment on them, they’re doing their best given the limited amount of time in the day and the craziness of navigating online learning. That being said it was often the bottleneck within team discussions.

What was within teammate control and —seems to be the modus operandi students within the Worcester State University Computer Science Program— very unacceptable was the lack of communication. I would consistently ask teammates what they were working on and how it was going only to get no response. In fact, there was one teammate who I had never heard talk until three weeks until working with them; it’s anyone’s guess as to why, but my experience with my fellow computer science students has been largely marred by radio silence. My biggest change I would have made to the team was to force my teammates to communicate by instead of asking them “what is stopping them” in the standups, ask them “what is something they encountered that they didn’t understand while they were working”.

My personal failings in the last sprint came largely from my pivoting away from schoolwork to build out skills that would help me attain a summer internship as well as applying to said internships. I became more focused on learning the practical skills gained from sites such as Tryhackme.com and studying for the eJPT certification so that I may pursue a career in information with an emphasis in exploit development and malware reverse-engineering. My ability to engage with school work may have declined but it was a necessary sacrifice to (hopefully) make myself a more viable job candidate.

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

Sprint 3 Retrospective

Summary

In this sprint, I mainly did the following things:

What Worked Well

In this sprint, I had a lot of clear feedback from the prior sprint. This allowed me to very quickly knock out a lot of work in the first few days. It was very simple to go through and make all of the required changes.

What Didn’t Work Well

In hindsight, I should’ve made those “backend modification changes” one card. Instead I had four separate cards and four separate merge requests. It would’ve been cleaner and faster to have one card for it all.

Similarly, having finished those tasks so quickly left me at a loss of what to do for a while. I ended up helping some team mates out with a few things, but eventually I settled on working on the docker aspects of the system. I then ended up spending a lot of that time helping myself understand how it worked and wasn’t able to make as much progress as I otherwise would’ve liked.

I also think that simply due to the nature of the end of a semester, we didn’t really have the time to work outside of class on this. I personally had two projects I needed to create as well as a lot of studying to do. It was also hard to resist planning out my summer in my free time since I needed to buy thing and make plans for my summer of biking, tennis, and grass mowing.

What Changes Could be Made to Improve as a Team

Once again, we overall worked pretty well together. I’d say initially our team didn’t really do too much together. Everyone was working on their individual components and so we didn’t communicate as much as we might’ve been able to. That said, later in the sprint when we actually did need help on things, we all were able to come together and figure things out.

Supposing we were ever to work together as a team, I think we could improve by being more vocal and more unified. I think most of our problems though came from this being a course as well as us being mentally done with the semester. If this were a continuous job, things may have been naturally better.

What Changes Could be Made to Improve as an Individual

In this sprint, I didn’t do as much work I could’ve done. I could’ve asked if my teammates needed help on things and worked on the frontend, for example. I could’ve had a better attention span and self control near the end of semester.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Share What You Learn

The problem of this pattern is one of the final ones, as far as I can tell. It is framed around your near-completion as a developer. I mean this in the sense that you’re a rounded-out developer with a lot of useful skills, but not necessarily a significant amount of real-world experience. In order to truly become a journeyman, you need effective communication skills. It isn’t enough to be a good programmer.

In order to gain such skills, the proposed way is to share that which you have learned. One such way is via a blog such as the one you’re currently reading. I pretty much completely agree with this pattern. I think the best way to learn things is to explain them to someone else. Really, the reason that we are tasked to write large essays in high school and college, despite them being annoying, is because writing is thinking. If you are capable of reading these words, then you’re most likely literate. Modern people take literacy for granted. For millions of years, the vast majority of humans were illiterate and as such their brains developed in a different manner to ours.

According to a discussion with Psychologist Jordan Peterson (that I unfortunately cannot find to link here), illiterate people think differently than literate people. Illiterate people think more in images and experiences, similar to how animals think. (Don’t let your arrogance get the better of you; all humans are animals biologically.) Words themselves are abstractions and your brain has to handle abstractions differently. It has to convert from symbols and sounds to the word to the meaning of the word. I would say that tribes of people that rely heavily on the oral are similarly affected. Nonetheless, literacy has a profound effect on your brain and thus how you learn. Writing is a form of thinking. Literate people have the ability to write or type words without really planning it in their minds, similar to how people can speak without thinking. The words are the thinking. So, when you explain something, you need to find the words to describe it and that process is thinking.

That’s why written words can be so messy; we think through them as we write. Thoughts are messy. So, it is essential to be an effective communicator not only to benefit others. Ignoring the existence of other people, being an effective communicator means you are an effective thinker. This is specifically in terms of words, which I would argue programming requires. The concepts dealt with in programming require intense mental abstractions that most of us take for granted. There’s a reason the general population thinks coding is magic. It’s simply too abstract to fully grasp from a single viewing. This means words are the way we handle that abstraction. Thus, make yourself powerful with words in order to become powerful in your actions as a programmer.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Practice, Practice, Practice

The focus of this pattern is the simple idea that practice makes perfect. The problem arises from the fact that every time we code, we’re practicing. We try new things, we make mistakes, and we learn. However, when the majority of our code is for work, making all of these mistakes is sub-optimal in numerous ways.

Similar to previous patterns, the proposed solution is to practice outside of work. Do coding exercises for fun and learn from them so when you go to work, you can make fewer mistakes. I would mostly agree with this. My biggest criticism is the same as in a previous pattern; not everyone has the time outside of work to keep working. Depending on the job, it would require a person to live and breathe programming. They would need to use their free time, which is intended to keep the individual sane as well as give their mind a break so they can keep coding the following day. This could have overall worse consequences. For example, I’m capable of coding for virtually eight hours straight and I have on occasion. However, I almost always feel brain dead afterwards. Sometimes, I need a few days off afterwards to be able to think about coding again. As an athlete as well, I can say do not underestimate the importance of rest.

That said, I fundamentally agree with the notion of purposeful practicing. I started teaching myself programming in middle school and it was really slow and hard. The times I learned the most were when I could follow a well-made guide to create something simple. As I developed as a programmer, however, I was more easily able to guide myself through these projects. When I learn a new language, I often create a primality test. It introduces me to io, iteration, efficiency, data types, etc. in a language. Often, I’m unsatisfied with the maximum size of a 64bit integer and I start trying to create a larger integer object that can run efficiently and store large integers. This leads to learning even more skills in a language. However, there are books of prime numbers that go into absurdity. These projects aren’t really meant to have a utility outside of making them. This is what the author means by deliberate practice. I’ve spent years teaching myself different technologies and the most successful ways have always involved some sort of practice project. If nothing else, they make you really good at researching.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective III– Reporting System

I am part of Reporting System group in this project and my job is to support and secure other system through keycloak. It is a 5-person team, and my part in this group is to implement a third-party system (KeyCloak), deploying the system (using docker) and help other system by embedding in their teams. Also help with other team tasks other than IAM system.

What I think that worked well in this sprint was that we were clear on what to read and what to look for. We understood the instructions and started the work that we thought it would be useful for us to know and learn. I was able to make some progress and secure the backend and have a better understanding of the tokens. Created a realm for the reporting team and added their users. This link is a good source for anyone who is new to Keycloak and wants to know how it works. There is information for everything you might need with keycloak.

https://www.keycloak.org/documentation

I feel like for each sprint our group is getting better in understanding the requirements and what needs to be done so everything went okay based on the plan. The only thing that I was not able to do in this sprint is to have the keycloack updated with the team frontend and backend. The reason for that is because team was working until the final day before our retrospective and we didn’t have time to try it out and the issue was pushed for next sprint.Again, overthinking some basic stuff that didn’t need a lot of time spending on it continued in this sprint too.

I think in this team I feel comfortable and able to communicate openly with my teammates. Most of the time we spent it working individually or in groups of 2-3. In this sprint we made a lot of progress and created some important part of our system. Not all issues were done by the end of the sprint but we did cover some important ones.

As an individual what I could have changed is helping my team more in other issues too and discuss the problems with my team.

In this third sprint we had enough issues for a team of 5 people. Most of the issues were about building frontend, backend, and figure it out how to make the reporting system work. Issues were mostly individual but also, we had ones that we developed in group. I was assigned to find and understand tokens better and securing the example backend through keycloack. I was able to finish both issues with success and the one that were in group too. Created a project file with all my documentation in GitLab with steps I followed, to complete the work I was assigned for.

We all wrote our descriptions on the issues, what we learned and how we are going to use it in the future. The link is provided in GitLab so anyone who comes after us or want to check on what we did, can use it, and help the others too.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/keycloak-configuartion

Read the readme.md file in the project to follow the instructions. Overall, this sprint was better than the first and second one and we got result. If the first one was trying to understand what was happening, this second sprint was more hands on the deck sprint and the third one was makes things happen.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Rubbing Elbows

The section “Rubbing Elbows”, found in chapter four in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye focuses on a learning technique similar to “Record What You Learn” pattern which I wrote about during week 12 of this semester. To “Rub Elbows” in this context means to sit next to a fellow software programmer and exchange ideas. This could range from simply talking to each other during a lunch break to peer programming which is when two or more developers physically sit side by side and collaborate while they develop software. In any such case as these, a software developer will likely pick up on the small micro-techniques that are too trivial to be covered during active teaching. However, these techniques can add up and significantly contribute to the development of a software programmer. And when even if one were to disagree with their peer’s methods, they at the very least have gained a new perspective to view from. The same can be said in the case where there’s a knowledge gap between peers, which forces both of them to take each other’s viewpoints into consideration.

Again, like the “Record What You Learn” pattern, I’ve experienced and used “Rubbing Elbows” to an extent. In recent memory, me and a peer have helped each other study and do the work in classes that we share. We weren’t able to physically meet up since the pandemic but we occasionally talk to each other online through discord. I remember one conversation where he mentioned Python and I didn’t really know much of the language so I asked him what separated that with programming languages like C and Java. That got me interested enough to the point where one of my final projects for this semester partly uses Python code. There’s also a pet project that I’m toying around with, something to do with chess; I’m kind of tempted to research more of Python so I can write the code entirely in that language. It’s not what I’d describe as a micro-technique, but it’s something that I picked up while “Rubbing Elbows” with a peer.

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

Sprint 3 Retrospective

Photo by Tim Gouw on Pexels.com

For the final stretch of our allotted development time working with the InventorySystem component for the Thea’s Pantry project, we focused largely on getting all the frameworks (frontend, backend, database) into a functional state for the next team taking over on the project. I focused much of my time on getting our frontend components pushed to the container registry for the project on Gitlab: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/50, https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/49.

Originally I had wanted to implement automatic uploading to the container registry using a Gitlab-CI file, but encountered numerous issues related to the file-structure of our frontend projects, Gitlab’s continuous integration system not being able to find certain files, and problems during the build stage throughout the deployment process. As a result of this I eventually decided on using Docker-Compose to push the components to the container registry. While this won’t be able to execute automatically in the same way as a CI file, It was more important to have working containers pushed to the registry for the next team to be able to work with.

Throughout sprint #3, we were able to finish off some of the outstanding issues which were leftover from previous sprints, we finalized parts of the backend framework and implemented partial functionality https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/42, finished setting up all three frontend frameworks for future polish and development https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/26 , and were able to implement a basic database for storing inventory-weight https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/52, as well as some further polish/refinement of the API https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/8.

Additionally, one team member worked on the Identity Access Management system used for the project, Keycloak, and was able to create working frontend and backend environments for using the system to verify users/determine whether someone has appropriate permissions to access certain pages/fields: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/40. Everyone seemed to accomplish a lot this sprint, and I think that we were able to leave the InventorySystem at a good starting point for the next group of people who end up working on it.

If I could have done anything different, I would likely have spent more time on trying to get the CI-file working as intended, as automatic integration/deployment of the project would be more convenient for developers than having to manually push to the container registry each time changes are made. Also, I think that the Vue components for each of the frontends I worked on could have been polished some more (add features such as slideshows, responsive page design, stylized buttons/appearance) but those would very much have been low-priority issues to be focusing on.

Each of the three sprints had different focuses, with the first sprint being focused on learning the tools we were working with, and the second sprint being centered around building the foundational aspects of the project as a framework for future functionality and development.

This third sprint felt like finishing off all of the frameworks, some polish, and getting everything ready to be worked on further. I think that we accomplished a lot as a team over the course of around three months; this was a great learning experience which felt essentially like working in a professional development context. I look forward to the next opportunity I have to work in a similar environment, and wish my teammates well in their future endeavors.

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

Sprint 3 Retrospective

It is hard to believe that I am writing the final blog post for my capstone already, it feels like I was feverishly reading through Keycloak documentation only weeks ago. This final sprint did not exactly go according to plan, but I am not entirely upset with the results. Overall I felt that my team did well on this sprint, but again felt like I should have been further ahead on my own work with the IAM System to allow myself to help more with the Inventory System. But there was some needed bug fixing and research done into different aspects of Keycloak itself that should be helpful further down the line.

As stated, I felt as though the Inventory System team all seemed to make steady progress in developing the different parts of it. There was progress made on the API in addition to the various front ends needed for the Inventory System and it seems that there is a whole skeleton system now in place that can be iterated on later. As for the work on Keycloak, when meeting with Cam and Migena we managed to work out some errors I had made in the setup of some attributes needed to connect Keycloak to Professor Stoney’s basic front end. In addition to this, we discovered that our Keycloak docker image could have a backend with persistence set up relatively easily, with a variety of choices listed here https://hub.docker.com/r/jboss/keycloak/. The other major focus for myself this sprint was on figuring out how to get user information from tokens by making calls from an Open API, as I knew this would be needed for implementing Keycloak into the Inventory System, and potentially others. In doing this I did manage to get authentication tokens, but did not make more progress past this. Once again I felt as though none of this should have taken as long as it did, throughout the sprint I feel like I would get bogged down by one issue and could have handled this a bit better.

I feel as though there are not many changes that could be made for our team to improve, as we simply ran out of time to start compiling all of our work together. As stated I feel like the Inventory System team did get a significant amount of work done, but there just was not enough time to truly start to work together with all of the different systems we had worked on. As for my own performance, I simply feel like I could have done more had I spent more time working. Time management has been a skill I have slowly developed over the course of my time at school, and it has certainly come a long way. That being said, there were still multiple times this sprint where I could have buckled down and simply focused on getting more work done. In summary, I feel as though the work that was done will provide a solid foundation that can be expanded on, but could have been fleshed out a little more had I managed my time more efficiently.

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 3 – Thea’s Pantry

The third sprint went fairly well. For the third sprint I did most of the backend from the get request endpoint to the response that returns the CSV report. To do this I first created the endpoint which gets two query strings from the request: start and end date for which I use as a date range for the data to put into the report. I then send the query strings over to the Report module which has all of the functions to create the report. In this module I first turn these query string dates into ISO dates and then query the guest and inventory data collections for any records between those dates. Then I make it search both object arrays returned by each collection for matching IDs and merge each of those objects with matching IDs into one object in an array. Then, turn that object array into a string with CSV format, have it create a file once that is done with the CSV text, and send a response back to the front end with a download of that file. After creating methods to do all of that, I connected the backend with Haoru’s beautiful front end and tested the system fixing any bugs.

What worked well this sprint was my gained knowledge and experience with Node.js and MongoDB. This allowed me to complete more complex operations with them and create what was needed. Because of this, I was able to finish most of the backend conforming with most of the requirements. Also what went well was how smoothly it integrated with Haoru’s front end, only needing a few tweaks, I wasn’t sure what to expect initially.

What didn’t work well was our teamwork. I would say that our teamwork depreciated since our last sprint due to the amount of work that was needed to get done. Since we all had stuff to do we didn’t have much time to merge everything together. For example, Derin worked on dockerizing our application, but needed more discussion to put it all together than either of us had time to give. Another example was with Migena’s keycloak system, where again, there wasn’t enough time to merge with the main application. Our production was higher than last sprint but at the cost of communication.

What we could have done better as a team was time management. Since we sacrificed how much we got done last sprint in order to work on teamwork, we had a lot of work to do this sprint. If we had organized our time a little better we could have had more time to combine our work this sprint and as a result would have a more complete system.

What I could have done better this sprint would have been to take some extra time to work with Migena and Derin. We came very close to our goals for the end of the semester, with one more sprint I believe we would easily have finished the base idea of what the system would be. Although I was very busy with the backend, I’m sure it would have been doable to combine our progress if I we took an extra 2-3 hours over the course of the sprint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend – link to the main application with the modules spoken about in this post.

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

Sprint Retrospective 2 – Thea’s Food Pantry

The second sprint definitely improved from the first sprint. In this sprint we mostly worked on the Message Queue, sending and receiving JSON data and then inserting it into a local MongoDB database. We did this with RabbitMQ and the ampqlib Node.js package. To do this we first created sample JSON objects then stringified these objects in order to send it to the message queue. Then we pull them off the message queue with our receive module, parse the string back to JSON, and send it over to the Insert module where we then put a timestamp on the data and insert it into the database. I also designed the endpoints and researched how to put JSON data into a CSV formatted file for the report.

What worked well was our teamwork this sprint. Me and Derin worked together to make the send and receive files, changing them to send to two queues, and deciding how we were going to do it. I would say that the teams teamwork has improved greatly from the first sprint where we all kind of did our own thing. This sprint we took the time to communicate and combine our knowledge to get stuff done.

What did not go so well was our production rate. We did not get a whole lot done, as we only worked on the message queue. This could be partly due to getting used to working with others as we had to focus more on communication than work. This means that we did not get to work on dockerizing our application, working with Migena to integrate our keycloak system, or any other of the backend functions such as the endpoints.

Changes that can be made include improving our teamwork/communication skills, everybody should learn at least an overview of the other technologies even if we are not the people implementing them, and communication with the other teams as well. We still do not know the data that will be sent to us, how we will connect our containers together etc. The last thing we should change is our productivity rate. Designing the endpoints and working on the message queue is not enough work for the sprint. There is still a lot to be done and only one more sprint left to do it. For the third sprint, we will all have to pick up the pace to get it done.

Changes I can make as an individual would be making an effort to communicate with the other teams, learning technologies I will not use directly such as keycloak, and communicating with Migena and Haoru to combine the backend with frontend and the keycloak system. I think it would be extremely beneficial for me to at least learn how keycloak works so that I can properly work with Migena to implement it into the whole system. A last thing I would change as an individual would be to take more time to understand Docker as I will be using it in the third sprint to containerize our application. I do not have a great understanding of it just yet.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/tree/main/src/subProcesses

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