Author Archives: mikefriedrich1

Sprint 3 Retrospective

For the last sprint, the main objective, from a frontend perspective, was adding some final touches to the code and making documentation for next years group. My biggest objective however for this sprint was to get semantic versioning to work. Semantic versioning, in simple terms, allows us to make version tags for any ne code that is pushed to the main repository. For example, if I pushed something new to the main branch that is a new feature, it will tag this as let’s say “v2-0-1” and it will make a container as well with this tag. This is helpful to us because if we ever need to go back to an old version of the code, it will be easy using the tag container in our docker-compose file. This for a few days was giving me issues until I found what the cause was. The main issue was our docker compose version. Throughout the sprints we have been using version 3.8 but for semantic versioning to work I need to add a docker compose apk to the ci and change the version to 3.3. This allowed the versioning to work and tag.

For this sprint I though everyone worked well together and got a lot done on both the frontend and the backend. Like the other sprint we did a divide and conquer style of completing the issues the were left for us to finish in this sprint. Everyone had a final hard task to do in both the frontend and the backend which gave us more hands-on knowledge that we all can take to our future workplaces.  The only thing that I think didn’t work well for this sprint was people doing task but not assigning themselves the issues. We had an issue where two people were working on the same issue which caused confusion between the two. A compromise was eventually found, and the issue was complete but in the future people should not be doing this as it could lead to a bug or error In the code from different algorithm styles.    

As a team, besides what I talked about above, I found that there is not much we can improve on as a team. I found that this sprint went very well and am proud of the work the was complete during this time. Also, this being our last sprint we will not meet again to be able to improve together. As an individual like last sprints, I had some issues with commits again. For semantic version I had roughly 30 commits trying to test the pipeline and find the errors. I could not find a way to test the ci locally, so I swamped the commit log with tests. In the future I need to either find a way to test ci locally to make changes before clogging the system or I need to e better about error tracing so there is only like 5 commits compared to 30.

Commits:

Update guest data to new datapoints: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/5de3e0c143b3cabb9a517839257be9a3adec33d4

Updated port numbers in code: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/94d4e5e98e17f1f37e3ec87dc5f307b69d1cc762

Updated README: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/8edbb8c6b24592bea5da04418032c49f03469638

Semantic versioning: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/82ce990f6d689810a6bab6ad7e31f89ab8614a28 and many more commits in repo for testing

Fix v-show bug: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/b3cdca325396169af224897768dd80d1d069e2b8

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

The Long Road

For this week’s additional blog post, I have decided to look at the apprenticeship pattern “The Long Road”. In this chapter you, are aspiring to become a master software developer. However, your aspiration conflicts with what people expect from you. Conventional wisdom tells you to take the highest-paying job and the first promotion you can get your hands on, to stop programming and get onto more important work rather than slowly building up your skills. In this chapter it is advised that you should focus on the long-term. Value learning and long-term growth opportunities over salary and traditional notions of leadership. No one is so far ahead that you can’t match their skill level given the decades you will have to hone your craft. No business or technical domain is closed to you. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“This pattern is not for people aspiring to become CIOs or project managers, or filthy rich. Along the way, it is not unlikely that you will take on roles of power and responsibility or find yourself quite wealthy. However, these roles and benefits are not the main motivation of the successful apprentice—they are merely by-products of a lifelong journey. And rather than counting the days to retirement, the craftsman will willingly and joyfully work into her final decades. We don’t want to give the impression that everyone must follow a single road (see Draw Your Own Map) or that this is the right road for every software developer (see A Different Road). Some people leave development permanently and become executives, testers, salespeople, or project managers”. (Dave H. Hoover & Adewale Oshineye).

This chapter was an interesting one to read. I liked how it talked about how this is a unique profession, and you will be doing it for some time if the passion is there. I also liked how it talked about how you shouldn’t jump ship right away if there is an opportunity away from software development. I don’t think that this chapter will stick with me out in the real world, however. I feel as though this chapter is geared towards people with a mind set of already leaving this profession.

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

Retreat Into Competence

For this week’s blog post, I have decided to look at the apprenticeship pattern “retreat into competence”. The idea of this chapter is that you, a software developer, are beginning to realize how little you know, or that you have taken on a new challenge that is not working well in your favor, or your having problems with both. Due to you realizing how little you know you begin to get overwhelmed with your ignorance. The solution to this is to pull back and launch yourself like a stone from a catapult. You need to retreat or take some time away from your task to re collect yourself so you can come back to the task stronger than before. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“An apprenticeship is a roller-coaster ride. You will experience the thrill of learning new technologies, leveraging your knowledge and creativity to deliver value to your customers. But you will also experience the heart-in-your-throat terror of perceiving just how little you know compared to the craftsmen and experts you meet along the way. It can be overwhelming, particularly when a deadline is looming or when you’re dealing with production issues.” (Dave H. Hoover & Adewle Oshineye).

This pattern is most relevant to people who have stretched themselves to far thin to be able to concentrate on the task in front of them anymore. However, by pulling back you do have the chance to launch more forward than you have been able to before. Note however this pattern does come with risks as if you forget to launch back forward or don’t have the desire to there can be repercussions. I liked this chapter as I am a person who can get stretched thin very quickly and am not able to bring myself to walk away for a bit to recollect myself. I liked that this chapter talked about both the pros and the cons of using the pattern. This will be something that will stick with me while I’m in the field because I am prone to being stretched thin and will sit there and still try to figure out the problem for hours. By walking away for a bit, I will be able to launch forward.   

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

The Deep End

For this week’s blog post, I have decided to talk about the chapter “The Deep End”.  The idea with this chapter is that you a software developer, feel as though you have hit a rut with your learning. To be able to feel confident you need to grow your skills, your confidence, and your portfolio of successful work. You feel the need to challenge yourself with bigger things. This may involve bigger projects, larger teams, more complex tasks, new and business domains, or new places. The solution to this problem is to jump into the deep end. The longer you wait and stir with the idea that you are in a rut the longer you will be in that rut. If an opportunity comes up when you can take a challenging job you should take it, most people learn by taking difficult jobs and expand their knowledge from the research it provides. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“Even though we advocate seeking out the most challenging tasks you are capable of, you still need to remember that if the water level is above your head it means you’re drowning. Even in Enrique’s example, where he was changing his life in a big way, he was still moving to a country where he knew at least one person and could speak the national language. It’s your responsibility to offset the risks of this approach by Finding Mentors and Kindred Spirits who can provide help when you need it” (Dave H. Hoover & Adewale Oshineye)

This means that if a job is too over your head, don’t take it just to prove yourself. If you need try to find a mentor that will help expand your knowledge. I found this chapter to be very interesting. I like how it talked about how if you feel as though you have reached the end, try to grab a more challenging project to expand your knowledge. I liked this because it reminds of being in school and being assigned project that I knew nothing about. By working on them and doing research I found those project to be the most fun to work on. This chapter will definitely be applied while I am out in the field as I will remember that enjoyment from school.

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

Confront Your Ignorance

For this week’s other blog post, I have decided to look at the chapter “Confront your ignorance”. This is somewhat a continuation of the previous chapter “Expose your ignorance”. The idea of this chapter is that you, a software developer, have found gaps in your skillset, gaps that are relevant to your daily work. These gaps include tools and techniques that you need to learn. However, you don’t know where to begin and it is already expected that you know these things. Unlike “exposing your ignorance”, the solution here is to not start asking questions to try and close this gap. The idea of this chapter is to divide and conquer what you need to learn by picking one skill, tool, or technique and activity fill those gaps. However, like the other chapter, can you actively close this gap by finding a mentor in the workplace who will teach you this. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“This pattern is closely tied to Expose Your Ignorance, but implementing it is less of a challenge to your pride because it can be done in private, without anyone else ever finding out the things you did not know. However, as an apprentice with aspirations to mastery, you need to be willing to Expose Your Ignorance as well. Using this pattern in isolation (that is, confronting your ignorance without exposing it) runs the risk of encouraging a culture where failure and learning are unacceptable because everybody does their learning in secret.” (Dave H. Hoover & Adewale Oshineye Pg. 29)

After reading this chapter, it has changed slightly the way I will think in a work environment. I liked how this chapter coupled ideas from the previous chapter giving me a more deeper understanding about learning and growing in the workplace. I though it was cool how ideas were continued in this chapter with a different meaning. Now when presented with the issue of my own ignorance, I know now the way to think if this should be something I’m asking question about or learning on my own.

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

Exposing your Ignorance

For this week’s blog post, I have decided to look at the apprenticeship pattern “Exposing your ignorance”. The idea of this chapter is that you, a software developer, are being paid to know what you are doing. The problem is that you have become unfamiliar with some of the required technologies. This starts to fill you with uncertainty that you are not the correct fit for the job. The solution to this issue is to expose your ignorance. Show the people who are depending on you that the learning process is part of delivering software. Let them see you grow. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“The most obvious way to expose your ignorance is to ask questions. This is easier said than done, particularly when the person you’re asking has assumed that you already know the answer. Press on! Sure, you could protect your pride and take less direct routes to obtain the required knowledge, but remember that your road to journeyman will be shortened by taking the most direct route available” (Dave H. Hoover & Adewale Oshineye pg. 26)

While this method does expose your ignorance to the other team members, this shows that you can and are willing to learn and grow. This is what make a craftsman, someone is is willing and can learn multiple things, rather than an expert who is advanced only in one aspect. This chapter was a fun one to read. I found that exposing your ignorance was an idea that I didn’t even think about. Personally, I am a person that can clam up very easy and become afraid to ask something, thinking it may sound stupid. After reading this chapter, it has shown me that I can be in a professional setting and its okay to show the team my ignorance. This will tell them that I’m trying to grow and learn more. This chapter has changed the way I think about my actions inside a job context. Now if I am in the field and feel as though I have a stupid question, I know now to ask.

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

Sprint 2 Retrospective

For this sprint my focus was to get the frontend and backend talking to each other. This worked well and now they are communicating and sharing data as seen from the commit below. During the sprint we like during the last one was on teams of three, three assigned to the frontend and three assigned to the backend. Like last time this team dynamic worked well as we were able to complete a lot of issues in a timely manner.  Also, I found that the new commit scheme using commitlint made commits much easier to read. Due to the way you must commit a message, it made it so much nicer and easier to read know what type of commit they were sending such as a feature, fix, etc.

During the sprint however I did think that there was an issue with the team dynamic. On the frontend we didn’t have a lot of issues for this sprint. This sprint was mainly to focus on integration and adding files to make commits and other applications work well. For this it was mainly me and Sandesh who were working on this. Brendan did some work as well, but I thought to my self what the best team dynamic as Brendan when he would finish his issue most of the other issues were already assigned. Also, during this sprint, the backend team had their hands full with issues such as rabbitmq and making sure that it integrates with no issues. They managed to get most of the issues done as their team dynamic is structured very well and they all have a passion for working on the backend. Like the last sprint, I think that if the teams changed to 2 and 4 then every group member would have things to work on as the backend team normally has many more issues to work on during a sprint then the frontend team.

Apart from the team dynamic, I found that there were no other things that could be improved as a team. From an individual standpoint, there could be some things that could improve. Like last sprint I am still experiencing issues with too many commits. It has definitely gone down but every once in a while, when I commit work, I sometimes accidentally leave my test objects in the code which if not explained to other group members could confuse them. Due to this, I find myself sending a “fix” commit to remove all these test objects. What can be done to remedy this is to read all my code again before submitting. Like if were taking an exam, double checking my answers would ensure that every test object is removed form the code before any commit is sent through. Apart from that I really enjoyed this sprint and the work that I was submitting.

Commits

Added Commitlint to frontend repository: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/6179634a126b7dadb3e2edb193a87195a9aa6281

Change frontend skema to match backend: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/cc60a90c708823c01d47e705946363d7cf94c274

Make gitlab.ci file for frontend: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/57cca658ba91a8707934a246d31912dc63f8a19d

Frontend docker container with nginx: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/5842bad96d66457b3574bd54d48096e0ad2938d7

Fix container to reload and not crash: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/59a5599f7d3440f8472c4a5adc4f8abdb7b89e24

Integrate frontend image with backend:  https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/321de2c87834105dabf1ecdb185cda3e699705d0

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

Unleashing your Enthusiasm

For this week’s blog post, I have decided to look at the apprenticeship pattern “Unleash your Enthusiasm”. 11this chapter is all about you as a programmer being very excited about the craft of software development. However, you find that you are holding back and being more enthusiastic about the work your colleagues are doing. Fear not, as your enthusiasm and love for the craft does not go unnoticed. Because of your inexperience, it brings some unique attributes to the team, including that infectious enthusiasm and an unfettered imagination. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“In any group setting, there is a tendency to conform to the norm, particularly for newcomers. Most teams are not hyper-passionate or overly enthusiastic about technology. Predictably, they are focused on delivering the next project or improving on the aspects of the development life cycle that are causing them pain. Therefore, enthusiastic apprentices can often succumb to the urge to fly under the radar. They either repress their enthusiasm altogether or allow it to manifest only outside of their day jobs.” (Dave H. Hoover, Adewale Oshineye Pg. 22).

Essentially because of you being a newcomer you tend to try and acclimate to the rest of the group and start to lose that newcomer enthusiasm and begin to try and become unnoticed. The yare risks however that come from unleashing your enthusiasm. One of these risks are that if the morale is low or the team is not welcoming, you will likely get some eye rolling from your enthusiasm.  Another risk that could come from unleashing your enthusiasm is depending on the team, they may not enjoy that you are exposing your ignorance and where your knowledge stands.

From reading this chapter I found it to be an interesting take on when you begin working in a job setting with a new team. I liked that in the chapter it talks about both the positives and negatives of unleashing your enthusiasm. Although this chapter did not really change the way that I think about programming and my enthusiasm when I would get a new job. Knowing who I am as a person and my personality, I am not one to “unleash” my enthusiasm on a new group of individuals, so I don’t see this chapter as being helpful in that sense. However, if I were to train a newcomer and they brought this enthusiasm to the table, I now know what they could bring to the table, and I will not disregard it now.

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

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.