The White Belt

For this week’s blog post, I have decided to look at the apprenticeship pattern “The White Belt”. This chapter talks about how you have gained a deep understanding of your first language and have become confident. However, you are struggling to learn new things and it has become more difficult to learn new skills. The main idea of this chapter is to wear a white belt and forget everything you have been taught thus far and learn from someone with a blackbelt. Dave H. Hoover & Adewale Oshineye, the authors of the book, say on this, “Wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way”. (Dave H. Hoover & Adewale Oshineye). As discussed in the text, when you take this approach in learning some new material this will accelerate your learning process tremendously. When you take this step towards ignorance, you can express yourself idiomatically and gain a far better understanding of your new knowledge. This way when you consider both what you learned and your old knowledge you have developed productive insights in both fields.

What I found interesting about this pattern was that it’s like what we learned in the chapter “Your First Language”. In that chapter it mentioned finding a main language but not forgetting about what you learned in the past. With this chapter we can apply both knowledges and expand on our main language. By being able to take a step back you can develop your skills in a way that I didn’t eve think about. Now knowing this knowledge, it has made me rec consider what I would be doing out in the real world at my profession. If presented with a problem that I have no past knowledge about, instead of trying to guess what the solution to it would be I can ask someone who knows, a.k.a a blackbelt, and expand my knowledge of the subject. With everything I Have learned I both chapters, this gets me excited to go out into the world and gain more knowledge to become a “blackbelt”.

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

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

Sprint 1 Retrospective

In this sprint I was working with a team of 6 individuals. With this group we decided to split into two teams, 3 people to work on the frontend and 3 people to work on the backend. During this sprint I was a part of the team working on the frontend.  Throughout the duration of the sprint, I found that this team dynamic worked well. This allowed us to divide up the work and conquer it as two individual teams. I feel if we were all working together and grabbing any task, this would have caused mass confusion and the likely hood of less work getting done. From a frontend perspective, I think having 3 team members to work on the frontend was the correct amount. I say this because in our repository we were working on mainly three different files. These files were our App.vue, id-input.vue, and register-form.vue. Due to this coincidence, we were able to give everyone a separate file to mainly work on.

In this sprint I only could find one thing that didn’t work well. This was assigning roles to current issues in the sprint backlog. With assigning roles, I found that a lot of old issues were left over from the previous class that were still assigned to them. I found this frustrating at first due to me not know my teams profile pictures and thinking they had assigned themselves to that role. Once I figured out their profile pictures that part of the issue subsided. However, I found that with my team as well every once and a while someone would assign themselves to an issue that I had already begun working on. This kind of issue could cause issues later down the road because if they were to push code like mine but different at the same time as me, it could affect the code.

Something that we could improve on as a team is switching up the team dynamic. I only say this as I know that the backend team has much more work to do then the frontend team. When we first started the sprint, the frontend was in okay shape. This being that we had files that were somewhat working, and we had issues that we could easily identify. With the backend however, they were given files and containers that were not working at all. At the end of this sprint the frontend team was able to have get all forms working for the most part and able to set up CSS styles. With the backend team they made great strides in getting the backend to work, but they still have got a lot on the product backlog. If we were to switch the team dynamic to 2 on frontend and 4 on the backend, I believe this would give the extra manpower to get a fully functional backend with rabbit mq.

From an individual perspective I believe I could improve on my commits. I am very prone to committing a lot of non-important commits. I feel as though I should try in this sprint to try and limit how many commits I send to the branch before my issues from the sprint backlog have been finished.

Sprint Commits:

Add Frontend image to Docker Compose: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/1edd0dd2761c6eca6b2658ac84b8ad9a9a0a6c8f

Update form on main branch: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/ca34a3f3d27dc958472fa556d4ab210d0afa656b

Form update to newer form: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/ca34a3f3d27dc958472fa556d4ab210d0afa656b & https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/3d6e549feb1088c5704509b31d62a2d4d6f5a9e0

Fixed Submit Button on Register Form: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/78c425fbaa3a2db3dafb4ba383e31aeb86709c7b

Allow Data communication between Register-Form.vue and id-input.vue: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/93497903597726c44fb8aa5a662d8fdad0343151 & https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/9ccc74f09d3e5687b06d6752a0efcb17b90a81a7

Changed idnum from this.props to method call upon form creation: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/131ab93c5f000b742052db31d0ff5aba95772223

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

CS 448 Post #1

I wanted to do my first post on the first pattern we are given in chapter 2 because it is the start of delving into the patterns we will be working with after chapter 1 and start of chapter 2 introducing what the book will be about. The first pattern here is “Your First Language”, and it talks getting started with programming languages and how you can start and improve at working with one. It is recommended to start with one language and take time to learn and get used to it so that you are fluent in it. Solving problems using this language can also help you gain experience and get a better understanding. You will want to spend enough time with the language to become fluent in it, but keeping the introduction to the book and chapter 2 in mind, you don’t want to get stuck with it and instead want to be able to learn other languages after the first one.

I think that it is smart to focus on one language when starting out before moving onto others, and having problems to solve with that language can be very helpful at understanding and working with that language. It reminded me of doing worksheets or assignments in school for a subject after doing studying and some practice. It is also good to not start trying to learn multiple languages at once because some of what you learn from them may start to get mixed up, and starting with one language before moving onto others and possibly doing multiple languages simultaneously is the smarter route to take. In my past CS courses, we were taking time with a language before moving on the next one, working on and solving problems with that language. Because of that, I have seen how effective this way of learning languages is.

I thought that this was a great first pattern and problem to go over after the first chapter and the second chapter’s introduction, since this book is going to go over many other patterns in this chapter and later chapters, and this pattern covers the starting point for readers and programmers learning new languages.

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

Sprint 1 – Retrospective

During this sprint, team one performed extremely well. Despite being a new team that is completely new to this project, everybody did their best to be as productive and cooperative as possible. I thought that the team operated efficiently and worked as a unit. We were able to come up with great methods to communicate, find issues, divide the labor, as well as a method to review and approve completed tasks. In the end we managed to finish the vast majority of our tasks and we are already preparing for the next sprint. Personally, I thought I did well during this sprint as well. I completed all of the tasks that I assigned myself, and I found the time afterwards to help my teammates with any issues that they were having with their tasks.

With that being said, we did struggle as a team trying to understand what the project was about. Most of the files in the project had little to no functionality, and the backend was basically missing. The backend was only a skeleton with placeholder files. The only things were able to do during this sprint was moving files around for organization purposes as well as spend time trying to understand this project. I personally had issues trying to understand how the architecture works as well as what some things do like RabbitMQ for example. I also thought that spent too much time with my tasks than I should have especially when considering how easy they were. Most of my tasks were just creating new folders and moving files into them.

I think our team has a lot of room for improvement. For starters, I think we need to spend more time during the planning phase of our sprints to fully flush out what we want to do and how we want to do it. For this sprint, we all had an idea of what we were doing, but I felt like we did not use Gitlab or Discord effectively to plan or communicate as we could have. Another area that I think the team could improve on is appropriately allocating the amount of time it takes. I did the most the tasks during this sprint, however, all my tasks combined took less time than some of the issues that my teammates were working on despite their issues having the same amount allocated to them as any of my issues.

I also had a lot of room to improve as an individual. For example, I could have spent more time outside of class trying to understand the project. For the future, I’m going to put in way more time outside of class trying to make sure that I am prepared. Another area that I would like to see myself improve is coming up with as well as creating better issues. I thought that the tasks that I came up with and created were too repetitive and minor. For the next sprint, I want to create and work bigger, more relevant tasks. Other than that, I thought that this sprint went well, and I look forward to the next one.

List of issues that I worked on:

Issue Community#59: I created the Documentation repository

Issue Community#60: I moved files from general to the Documentation repository.

Issue backend#3: I created src/endpoints folder in the backend.

Issue backend#4: I created src/data folder in the backend.

Issue backend#5: I created src/lib folder in the backend.

Issue backend#6: I move items.js into src/data in the backend.

Issue backend#7: I move endpoints.js into src/endpoints in the backend.

Issue backend#8: I move config.js into src/lib in the backend.

Issue backend#9: I move database.js into src/lib in the backend.

Issue backend#10: I move logger.js into src/lib in the backend.

Issue checkoutguestfrontend#3: I created src/id-input-field/assets and src/id-input-field/components folder to aid with organization.

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

Sprint 1 Retrospective

With the end of my first ever sprint experience, I would like to reflect back on what worked, what didn’t work, and what changes could be made. To be honest, I felt like we were kind of just thrown into the first sprint with little time to prepare, but as the sprint progressed, my team ended up getting the hang of it. As a team we managed to create enough issues to work on throughout the sprint and everyone took up different issues to work on. We were swift to approve merge requests and review other members’ changes, so I think we worked efficiently on that part. 

As for me individually, I took on three issues, all of them involving the rearrangement of the file structure for each of the frontends. Issue #3 involved refactoring the file structure of checkInventoryFrontend where I based it off the MicroServices example. Issue #4 involved refactoring the file structure of addInventoryFrontend where I based it off the MicroServices example. Issue #6 involved refactoring the file structure for CheckoutGuestFrontend where I based it off the MicroServices example. I didn’t have much of a problem with them, as they were not complicated to complete.

As for what didn’t work well, overall, I think we as a team spent a lot of time trying to understand what everything was supposed to do. From each of the frontend to the backend, there was basically nothing implemented nor functional. I think because there was the daunting task of having to create the inventory system from the ground up, I had trouble actually picking out what needed to be done for this sprint. That aside, we managed to dedicate this sprint to preparing the files for implementation so that we would be able to start working in the next sprint.

As a team, I think we were able to come together and get work done. Some of the members of my team are people I have yet to work with, but there was no issue there. I am happy that I was able to help a fellow teammate resolve an issue they were having with the API. Aside from that, there was not much else communication between teammates during work periods as everyone was focusing on more individual tasks. This first sprint was more focused on the housekeeping tasks so there wasn’t much need for collaboration in the first place. I think in the next sprint, we will be able to greatly benefit from more communication and asking for help when needed. 

What I can improve on individually is to come up with more meaningful issues. This last sprint, I only created a handful of issues, all of them involved creating or moving files around. Now that this coming sprint will be more hands-on, it will give me a chance to come up with more specific issues, focusing on parts of the project that need to be implemented. I would like to work more efficiently, finishing issues within their estimated weight time. Overall, I am looking forward to the next sprint now that I have an idea of how the entire sprint process goes.

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

Sprint 1 Retrospective

My first Sprint Retrospective experience overall truly has been great. Being introduced to a new team environment is different every time, I did not really know what to expect. I had a specific mindset going into this one particularly. I wanted to know, where will I fit in best? I wanted to know the best ways I could assist my team in tackling this project. My teammates made this process very easy. They are intelligent and very ambitious about our project. They were very open about their strong suits and what topics they thought they might not feel as strong in. It allowed us to fill in those gaps and get everyone on the same page. I learn a lot from them.

List of my major contributions to GitLab:

Issue Title: Basics of Keycloak.
Issue Link: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/issues/1

Product Link: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/blob/main/Keycloak%20Introductions.md

Issue Title: Gateway/Ingress. Once requests are past it, are all communications considered secure?

Issue Link: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/issues/4

Product Link: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/blob/main/API_AccessControl_Authentication_using_Istio_Ingress_Gateway.md

It’s been a very fluid experience so far teamwise most definitely. My individual performance is a different story. I need to make a conscious effort to change the some of the ways I approach things the next Sprint. I created 13 out of 44 issues created. I undercalculated the weight on many of those issues. And instead of continuing to build those issues into smaller ones, I just kept trying to take the heavy issue head on. This put me in many inconclusive rabbit holes. Instead of confusing my teammates with information that is still very new to me, I just kept reading in hopes that something would suddenly click for me and I could produce a confident result. I will link an example of one of the issues I am referring to.

Research: Deploying Keycloak on AWS Kubernetes: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/issues/5

Another issue I struggled with was the Gateway/Ingress Research Issue I completed. I spent an incredible amount of time creating that research writeup. Which I personally don’t feel confident on it. I am not sure it is tutorial we will even be following. But I think that it is a good start to grasp the concept of what we will be working on. Another one of my struggles was that I didn’t prioritize Keycloak. I completed my Gateway/Ingress research before I attempted to secure my first NodeJS App with Keycloak versus a Standalone version. Which the Standalone version does not promote a strong understanding of Keycloak versus securing a NodeJS app.

Aside from my self criticisms. I feel very confident heading into our next Sprint. I really am finally starting to feel that confidence behind my understanding of these concepts. It was relieving to secure a NodeJS app with Keycloak for the first time. And it was extremely motivating to start coding again. I can really feel all the knowledge I absorbed start to piece together. I am excited to move forward with tutorials to further learn my way around Keycloak. I have been communicating with other groups on how to deploy Keycloak on AWS Kubernetes. I know what I personally need to improve on to further help elevate my teams process during our next Sprint.

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

Sprint retrospective #1

To start off, our first print went very well. Our project for this class is
the LibreFoodPantry Identity and Access Management System. Our main goal in
this sprint was to get familiar with Keycloak and learn how to implement it and
also building a small API. The issue that was created for Keycloak and what I
did researches on are “Keycloak authentication”, which had a weight
of two and “Deploying Keycloak on AWS Kubernetes” which had a weight
of two as well based on the time it took to do research and find good resources
to help us move forward with our projects.

In our team, we decided to divide and separate tasks. It was actually a way
for us to do multiple tasks at the same time and go forward with the plan. So,
Mike and Lena started working with frontend and backend, then with API after,
George who was the scrum master, took care of managing everything, handling the
whole group, creating documents. I and Andrew did researches on Keycloak and how
to implement it. Even though we all had our tasks to do, we were also able to
help others in case of need.

Doing research seems an easy task, but in reality, it is not. When I started
first doing research on Keycloak authentication, I had a lot of different links
but it was hard for me to find one that had the exact information that me and
the group were looking for. Not saying that there were no good links but Keycloak
is pretty broad and I had to do a lot of research and dig in to find good ones.
One of my mistakes here was that I was trying to find good links, good articles
and completely neglected the side of watching videos. Then, with a couple of
videos I have been able to understand and find good resources that I shared
with the group.

Looking to my personal achievement and work, I want to improve the way I
share my thoughts with the team. I barely created issues during the first
sprint planning, and was not really involved in sharing my ideas and opinions. I was
contributing to the conversations but never putting anything visual on GitLab
as a proof of my contribution. So, for the next sprint, I decided that I will
be more involved and put up my work to show my contribution to the group.

Looking at the team work, we did an amazing job working together on our
first sprint. We all listened to each other, everyone felt comfortable talking
and sharing their ideas. Also, everyone put a good effort and got the work
done. But one thing I think we need to work more on is the communication among
us out of class. Having a little time of communication did not make the first
sprint planning easy. We were all working on our tasks and talking about it
just in class either on Mondays and Wednesdays. So, organizing ourselves and
try to find a time for all of us that works and schedule weekly meetings out of the
class so we can talk more about the project, our tasks and express whatever
thoughts, opinions and questions we have at the moment will be very helpful. And, we
can meet via zoom or discord voice channels and talk more about the project.

The two issues that I worked on:

Keycloak authentication: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/issues/1

Deploying Keycloak on AWS Kubernetes: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/issues/5

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.

Sprint 1 Retrospective

Overall, with my work on the issues listed below, I think that the methodology of using the GitLab boards worked really well for us as a team, allowing us to pick which issues we personally wanted to tackle and notify everyone of what was currently being worked on. I also think that the methodology that we figured out as a group of requesting someone to check over our commits before we merged the branches worked really well.

Overall, I just don’t think we had a handle on the project when we made the first set of issues, so a lot of them were undefined and others really had no purpose. Our first sprint had no real direction and was just a bunch of random issues that we thought we had based on random comments in the code and what we thought should be done. This lack of direction, I feel, really hurt our productivity as we were focusing on things that had very little to do with each other and were just in there as things that could be done to grab some extra time units that it seemed like we needed. I also don’t think we communicated enough over the course of the sprint as to what everyone had done, which caused a bit of confusion. I also felt like I personally didn’t do as much as I would’ve liked, as some of my issues fell flat and left me feeling like I hadn’t contributed as much as I would’ve liked. The biggest issue we ran into on the technical end was the fact that our backend had almost no functionality at all, and needing a backend in order to properly try out and work on frontend behavior really put a damper on the amount of progress that was possible for us.

To improve our team issues I think we just need to flesh out what we need to do as a group, in order to fully grasp the scope of our sprint and what functionality the project needs as a whole. We also need to flesh out how we want to handle organization in terms of the file hierarchy and structure within the repos, as well as a proper naming system. These issues would be easily possible with a refactor I think. This first sprint was really a trial run, in my opinion. We are slowly figuring out and narrowing in on what needs to be done to get this thing working and finding examples to go off of to start to create some real functionality.

As an individual, I think I need to communicate more with the group and see if anyone else needs help, I guess so far I haven’t felt like as much of an active member as I would have liked. I also need to be less rigid about issues and not feel like I can add them as they come up because sometimes I feel like I shouldn’t add things to a sprint that is underway because of the seeming rigidity of SCRUM. There are things that can be done and issues that can be added or modified over the course of the sprint, at least I think there should be. I just need to let go of my personal hangups with SCRUM in order to work more effectively with the team. That and manage my time better, as this sprint, I kind of dropped the ball.

Issue #17 This issue represents work done by Sebastian and I trying to figure out how the backend worked, and our conclusion that it needed to be completely rewritten

Issue #62 I added dev containers to each of the repos of the project, however they may need to be updated as we go.

Issue #16 This was abandoned after figuring out that the file the comment was part of was just copy-pasted as a placeholder.

Issue #15 This was also based on a comment about a file being used as a test, I moved it to its own folder but have determined it has no functionality, but we will keep it around just in case we need some of the code.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice

This week I chose to write about Practice, from the Perpetual learning portion of the book. I think that this is an important topic because practicing is important in any skill or craft.

As a Software Apprentice, practicing is crucial. Practice will help me develop concrete skills in new areas. Concrete skills are necessary to land my first job. And the author poses the problem that my daily programming activities do not give me the oppurtunity to learn by making mistakes. This last part is not true for me. I do have the oppurtunity to make mistakes quite often.

One thing that Dave mentions is that practicing has to be done in a relaxed environment. So personal projects outside of work are an important part of the software craft. This makes sense to me. Because when programming for work. There are calls, meetings, and deadlines.Coding for school projects is similar. But if I am practicing for my own sake, I can relax and focus on learning. Dave also mentions to carve out some time everyday to practice. This makes a lot of sense to me. At the end of the pattern, Dave recommends that I complete the same excercise from scratch, once a week.

Over the winter break, I had some spare time one my hands, and I decided to take on a personal project. I wanted to learn about the React framework, so I decided to build a calculator with React. I made a calculator website one year before with vanilla JavaScript. It was nice to be able to learn at my own pace. And I had to remind myself that I was coding to learn, and it was okay that the project took me longer than expected. This was a good learning experience. I made an app that does works as expected, and I have something new on my GitHub. So practicing helps me to achieve the skills, and as long as I put the code in a public place, the projects become part of my resume. Creating personal projects will be part of my coding journey, and one of my favorite parts too.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective #1 – Team Two

During this past sprint session my team and I worked on the LibreFood Pantry Identity and Access Management System. Our goals in this sprint were getting a KeyCloak implementation going and building a small API to work with keycloak and LibreFood Pantry. The first issue I created was designing our API (what endpoints should it have and what basic structure should it have). This issue had a weight of one and I was able to complete it between class on Wednesday and the following class on Monday. This involved creating the LibreAPI/src folder and using NPM to initialize the folder with a package.json file and manually add the folders. The next issue I created was to begin creating the API and writing code. This step involved watching a lot of videos and reading tutorials on how to implement a simple API. The API has two basic functions: Post a string and get an array of all the strings. Two YAML files were created in order to service the endpoints using OpenAPI implementation. I also created an issue on linking KeyCloak with our API and put in in the backlog until there was more research available and I would be able to have the other team mates catch me up on their KeyCloak information. 

Our team divided into two sections: I would work on the API, Mike would start with frontend and backend files then join me in API development, George (our scrum master) handled creating all the legal documents and licensing/documentation, Andrew and Gracia did research on KeyCloak set up and implementation. The research documents were very helpful when it came to better understanding KeyCloak’s structure, function, and how we could link it using a JavaScript adapter. Overall, the division of team labor felt fair when allocating individual team tasks. Having two students focus on development (Mike and I) and the rest of the team handle KeyCloak kickstart (George, Andrew and Gracia). KeyCloak is a very large system and there was a lot of research that needed to be done before we could begin a simple implementation. 

As an Individual I want to improve the way I communicate with my team and try to keep my focus narrowed in. During group meetings, I would find myself asking questions to the research team about KeyCloak that are very off topic from the current discussion. In reflection, I think this may sometimes throw off the group discussion and put my teammates “on the spot” to mentally shift gears to what I’m asking to try and best answer my question. I think this throws off the workflow and next sprint I plan on writing down questions that come to mind as I am working and near the start of the meeting (possibly during my stand up) and chip away at questions during that time, or bring questions up when they are relevant. 

As a team I believe we worked very well together. We all have a true interest in this project and put in a lot of time outside of class to get things done. For this next sprint, we plan on all focusing on getting keycloak up and running and will revisit the code we worked on once we get past our current roadblock which is getting one instance of keycloak to work and use that as the basis for our project. One way we can improve as a team is to communicate more outside of class via discord channels and also communicate with other teams.  We are in the same classroom as other teams working on LibreFood Pantry and our project needs to be linked together with everyone else’s work by the end of the semester. This means we need to take more time to talk with other teams during class or via discord voice channels. 

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