Apprenticeship Pattern “The Deep End”

I decided to write a post about this section because I found very interesting. The author starts off this section with a quote from Christopher Hawkins,

“If you’ve never fallen on your face, odds are you haven’t attempted anything worth a damn.”

– Christopher Hawkins, “So You Want To Be a Software Consultant”

This quote made recall an experience I had during my freshman year of college. I was meeting with my advisor in her office, talking about how I was having difficulties learning the content in one of my classes. I was debating whether to retake that class in the following semester because I thought if I retook the class a second time, I would understand it better. My advisor advised me not to and gave me this piece of advice, even if I don’t understand everything in this class right now completely, this was fine. As I took more upper-level courses, I will gain new insight and start to understand the material in previous classes a lot better and may even learn to see it in a different light. At the time, I found that piece to be very strange because I had always thought if a course is prerequisite, you need to understand in the previous course to understand the material in the next class. Now I see in later classes, you apply the information that you learn in a previous class and by doing so, can understand the ins and outs about that topic and gain a better understanding of the topic.  

In this section, the author talks about the dangers of taking it easy and taking on only tasks that you know you can complete. He also talks about how by doing so, you will not grow because their skills will not improve and as a result, they won’t become confident in their work. Whilst it is true the author wants us to step outside of our comfort zone, he also talks about how important it is to be smart while doing it. In the short story given in the book, Enrique who was challenging himself by taking a job in Nigeria, did not blindly take a leap. Before he even made the move, he connected with people who knew were already working there and so he got himself a mentor that helped ease the transition.

I agree with the points that the author brought up. One additional point that I want to add would be the author does not say it is important to make large leaps or take on a challenging problem without a mentor, it is just easy when there is someone there to guide you.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

My Second Sprint: An Improvement in the Journey

                Over the past few weeks I have once again had the opportunity to take part in developing the LibreFoodPantry software platform. From start to finish this second sprint has challenged our team in creating a solution to the question of security for this software. In this sprint we had mainly focused on how key cloak deployment would work and how we would adapt the existing web pages to utilize this security platform. We learned much throughout the sprint however we found that there was still much more to our role than just the webpages.

                Just to reiterate our goals, a group of my peers and I were tasked with creating a secure login service for LibreFoodPantry that would allow users to sign up and sign into the food pantry’s website. We had previously spent the last sprint attempting to understand how this third party software functioned and what we would need to do in order to implement it. This sprint would focus on the implementation of Keycloak and what would be the least disruptive method of doing so. The goals were as follows; create a working instance of keycloak with a front page without any containerization, understand how to create and maintain users, roles, secure each new page we added within the same login system, then transition this system to a container system such as Docker.

Getting started we first focused our efforts on everyone getting an instance of Keycloak running. After ensuring that I could get it working reliably I posted my results on Gitlab for my peers to have their own working version of Keycloak with a frontend page. We were then able to move on to our other issues. I was tasked with reviewing NPM and how to adapt existing frontend pages to Keycloak as well as ensuring that permissions and logins could be carries between different pages. Others among us worked on researching the deployment of Keycloak on a Kubernetes cluster using AWS as well as communicating with other groups to begin to synchronize and ensure we were working on features that mattered for the other groups.

                The team worked well together, and we once again made a point to meet twice a week to discuss progress and synchronize ourselves outside of normal meeting times. It was worth the extra meeting times as I was able to assist group members in ensuring that they could have Keycloak working and that their computer was set up to properly install and run Keycloak and the frontend page.

                Our main problems came about once again in properly updating our work in the issues tab and a failure to properly estimate the weight of some issues we had created. I once again found that I was stuck on a single job most of the sprint trying to adapt existing pages to utilize Keycloak. It would be apt to say that I was again immersed in my own work and communicating less than would be ideal. However unlike last sprint I was able to work past this in a shorter time frame and was able to communicate this to my groupmates. With this out of the way I had started work on adapting this system to work in containers such as those found in Docker or in a Kubernetes cluster.

                At the end we had started to make more progress quickly but by that time the sprint had come to a close. While this was not an ideal sprint, it was definitely an improvement over the last and I feel that we had done better in estimating the weight of certain issues although not solving this problem entirely. We hope to continue practicing working in the Scrum format and improving our grasp on what issues need to be created and how much weight they should carry.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly 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.

CS-448 AP Blog 9 (Read Constantly) – Reading Faster Prevents Coding Disaster

When you have read deep enough into “Apprenticeship Patterns” as much as I have, you start to notice a key feature of the book: many of the practices found within it are pre-requisites or co-requisites to other practices. Similar to a tech-tree structure found in a video game, proper software programming practices go hand-in-hand – this allows one to become proficient in many skills at once.

As usual, I have found that “Reading Constantly” is actually a practice that I already engage in. However, in contrast to the book, my level of “daily reading” is much smaller; I read for about 5-10 minutes each day, and it may not necessarily be related to the programming practices I need to study on. However, the book does state that reading during down time (even standing in line) is beneficial – perhaps, in an attempt to disagree, I was corrected by my own reading. This reinforces the idea: read, read, read!

I agree with Apprenticeship Patterns, and must also state that you should have a “queue” of books lined up; as you finish one, immediately start another. Tying in with “Practice, Practice, Practice”, constantly reading will keep you well-informed and up-to-date on problems that are relevant in today’s programming era.

When it comes to professional applications, “Reading Constantly” does not simply involve reading to obtain more knowledge. It also consists of:

  • Reading to acquire new connections within the academic community
  • Reading to apply skills from previous experiences
  • Reading to non-verbally communicate the idea that we are willing to improve ourselves

So, by taking some time to read every day, I am essentially performing both a “working” and “recreational” activity. I am able to boost my workplace performance in an enjoyable manner. Similar to the ideas found in the coding dojo, reading should come at ease, with information effortlessly flowing in like a gentle stream. Forcing yourself to learn new information is both un-enjoyable and ineffective.

Overall, I think that everyone and anyone who is considering an advancement in their career to read constantly. In a way, it makes us similar to our machines – we take in new input, compute it within our brains, and create solutions as output for our audiences. It’s a beautiful cycle, and it all starts with a good book.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) 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.

Sprint2- Retrospective Blog

For this sprint, my team, team-1, have worked with two epics, which are refactoring backend and adding commitlint to gitlab-ci.yml for all projects which are reportingAPI, reportingFrontend, reportingBackend. We have finished the epic of adding commitlint to gitlab-ci.yml for all projects by following the instructions. However, the most important goal that our team wants to achieve in this sprint is to make the backend work as expected. First of all, we checked the code to see how they were written, and to see if they were written correctly. However, after I found many errors in syntax and some logic implemented incorrectly in the old code. I decided to create the new backend instead of spending time to fix all of those bugs. As a result, we divided our team into three subunits to work independently with the backend. One would try to refactor or fix the old code as much as they can, one would try to create the new backend, and one would create the test for the backend.

My role in this sprint is to create the new backend and refactor it in the new style. I worked with a docker file and index.js to create a backend server. Then, I created a docker-composed.yml containing node image, mongodb, and rabbitmq, to ensure all the services work correctly. After that, I used javascript to generate all possible methods that can be used to make required http requests, endpoints. In the end, the new backend worked as I expected. It has Rabbitmq service and Rabbitmq functions used to receive all messages from a queue. Then, the backend will store those data into mongodb as two collections, guestInfo and Inventory. Finally, this backend will generate the .csv report when we send the required http request.

As for the results of this sprint, I believe our team has achieved its primary goal which is to make the backend work. However, it is not perfect. There are still some issues that we need to solve in the next sprint to meet the customer’s requests, such as creating a function that automatically consumes messages using Rabbitmq, adding some more required columns to the report, change the _id property in the fake data to studentID. On the other hand, we have also created a test for this new backend even though it is not completed yet. We are planning to complete it in the next sprint.

In summary, there are some differences in how things work in this sprint. We have worked independently on the same problems but in different ways. This sounds like we wasted our time having multiple people working on the same problem. However, for this project, I think it makes sense to do it this way. That is because we all do not have enough knowledge to solve the problem, so there is no guarantee that we can successfully create a new backend. So, we decided to keep it safe by preserving and refactoring the old code while working on the new code. I think this is one of the disavantages of this sprint and needs to be improved in the next sprint. In the next sprint, we will back to work with the regular way, each person should take care of different issues to use their time effectively. For myself and my entire team, we have made some improvements comparing to the first sprint. The only thing I think our team should improve more is that we need to communicate more to understand the project deeply, to be ready for the presentation.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns “Confront Your Ignorance”

This apprenticeship pattern describes to us how after being able to expose your ignorance, you must now be able to confront it. Once we are able to find the gaps in our skillset, it is up to us to tackle those problems head on. Confronting your ignorance does not mean to learn in isolation because doing that encourages us to create a standard where hiding your failures is okay. What we need to remember is that learning in public is always beneficial for an apprentice and that is what helps us move onto our next step of becoming better software engineers. What we worry about is when exposing your ignorance you become dependent on others as well as just creating problems for others when you don’t know something. That is why confronting your ignorance helps bridge the gap from between exposing your ignorance to being able to actually contribute to projects because confronting it is the best way to fill in your gaps.

What I have been able to away from this is that just because we don’t know something does not mean we should just constantly depend on others. If we fail to understand how to do something, we need to be able to ask for help so that hopefully next time we can do it on our own. With every project we take on in the future, it is obvious that we will need help in order to continue onward. We need to not work in secret to hide our failures and to use our mentors and peers as resources so that we grow and fill in those holes we all so definitely have.

After reading this pattern, it helped my reflect on a time where I created a Java application for work that would scan RFID badges of employees. I was tasked with this and initially had thought that if I could do it on my own I could prove I was capable and hardworking. In the end I took too long and did not have much to show for it, I was then partnered with someone who did have experience creating apps and in the end we were able to develop a functioning app. Pattern reminded me about this experience and that exposing and confronting my ignorance does not show that I’m weak, but that I want to grow as an apprentice.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

I think that in this sprint we greatly improved our workflow as a team, we knew what we were doing and were a lot more efficient about knowing what we were doing and completing it. We were also a lot better at communicating with each other this sprint than in the previous one, keeping each other updated on what we were doing and what we had to wait on in order to complete our section of the work. We just overall worked a lot better together and were able to complete things as a team as needed in order to get the job done.

Despite the fact that I think we did work a lot better as a team and we did communicate better, I think that it could still certainly use improvement. While we are better about it I still feel like there is some difficulty in communication about what each of us is working on at any given time, and we tend to just wait until class to talk to each other, other than the occasional discord message. We also still have trouble working on the technical side with git, making sure we are merging when we should and focusing on the epics, most of the time, at least for me, we just focus on the individual issues on the issue board and completely ignore the epics aspect of the project organization. Similarly, I think we are still having issues actually running the code with the backend in order to actually test things, but I think that is something we can definitely iron out in the last sprint.

To improve as a team, on the issues listed above, I think that we need to focus a little more again on communicating, especially when things are done and need to be reviewed, and then when they need to be merged. I don’t think we have huge issues in these areas, we just need to make sure we are letting everyone else know when we are done with things. We should also make more explicit what we are working on at any given time, only pulling things to in-process when we are actively working on them would fix this issue I think. Possibly we should focus more on completing epics than the individual issues, just to keep a little more structure to our workflow, but I don’t think it’s been a huge problem thus far, just something to think about. And lastly, I think a big focus of sprint 3 would be making sure we can actually run the code for testing and have the docker images work properly and everything. I think we have talked about it briefly, but getting that fixed I think should be a priority.

As an individual, I think I still need to be a bit more productive and involved in the actual coding process, a lot of what I have done this sprint was just refactoring the file structure and getting some documentation issues worked out (which come to think of it could probably use a little more work). Other than that I feel like I have done very little actual programming work in the past 2 sprints. I just feel like when it comes to doing things other than coding I have a little bit less interest and it is harder to motivate myself. This is a personal issue and I want to finish out the last sprint being as productive as I can be. I am definitely also a culprit of not communicating enough, so I want to make sure for our last sprint that I am keeping everyone updated on what I’m doing and when I’m planning on doing it.

Issue #18 Removed an old file that was a placeholder from a previous group called endpoints.js.

Issue #21 Merged the endpoints folder and the subProcesses folder to remove complexity within the system, keeping the endpoints folder as the main folder for the endpoints.

Issue #2 We discussed naming conventions as a group and I added a markdown file in the Documentation repository to keep track of any style conventions we want to keep a record of.

Issue #24 Created the endpoint for getInventory, using the endpoints from the API and the methods written in the Inventory.js file for functionality.

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.

Reflect As You Work

Reflect As You Work is a pattern which requires retrospection. When working it is important to actually gain experience and not just go through the motions. Quoted from the pattern, “The goal is to extract the maximum amount of educational value from every experience by taking it apart and putting it back together in new and interesting ways” is an excellent quote which I think encapsulates the entire idea of the patten. As apprentices we want to learn as much as possible since not doing so will start us on a road to complacency.

One thing that I will implement into my work is the idea of Personal Practices Maps. This seems like a very useful tool which will aid in retrospection. Right now I know my strengths, but I do not know my weaknesses. Using the Personal Practices Map will allow me to observe trends in what I do and help with my retrospection.

Another thing that I enjoyed about Reflect As You Work was that it mentioned how good experience directly leads to career opportunities. When Dave learned about a new pair programming technique it directly lead to him writing an column for StickyMinds.com. While I don’t expect to be writing any columns, I do hope that the skills I gain will lead to other employment opportunities in the future.

Reflecting as I work will help with Drawing My Own Map. While navigating the map I should be acquiring new skills which will shape the future of the map, which will lead to even more skills. Over time these skills will drastically improve my marketability, which will have a much greater impact on my map as opposed to earning a lot of experience at a single company.

Reflect As You Work is a good pattern which, while not flashy, is very important to remember throughout the entire apprenticeship. As an apprentice, the goal is to learn. It is important to always learn from your experiences and grow as a developer; if not you will become stagnant. My goal after reading this pattern is to begin reflecting on my work and actively try to improve myself, because if I don’t no one else will.

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

Sprint 2 Retrospective

I did the bulk of the work for this sprint in one sitting. I haven’t really figured out whether I think this was a good idea or not. On one hand, changing gears is something I’m not great at and I try to minimize it as much as I can. On the other hand, I wound up being pretty burnt out on the project.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/15

Here’s the first issue I completed. “Learning RabbitMQ” is kind of an ephemeral goal, so I decided to only look into what I consider to be the bare minimum of what we will actually need, which is essentially just the ability to put messages in the queue and take them out of the queue. I feel like I know enough about it to work with it and help get other people up to speed.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/16

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/17

I’m sticking these issues together because I wound up having to do them at the same time. To refactor things in the backend, I had to at least make sure it ran without errors, and to do that I needed to sort out the dependencies so that everything being imported at the top of index.js was either removed or installed.

It wasn’t until after I finished doing all this that I remembered someone had already modified the backend server to get it to work, only on a different branch. While that kind of tunnel vision is generally a bad thing in my opinion, doing all this work enabled me to actually understand how this project works. Specifically, I had a breakthrough in understanding that the server is actually just a program with its entry point being the index.js file. My previous experience with web development lead me to believe that the actual flow of the program logic was obscured behind all kinds of layers of indirection and it is in my opinion a little embarrassing that I didn’t see sooner that that was not the case.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/22

Finally, I deleted a directory containing a project from the previous developers that they were using to mess around with RabbitMQ. Not much else to say about that.

I also considered tackling the issue I wrote before about updating the documentation for every project, but I decided against it. Apart from being a little burnt out, I also figured that it’d probably be better to put it off as long as possible so that whoever tackles it can go into it with as much knowledge as possible.

Individually, I think my main issue is just a matter of setting aside time for this project. As a team, I think our biggest problem is the granularity of our issues, although it’s somewhat necessary considering our experience level and the nature of the project. While I struggle to put the work in, I don’t think the team as a whole has this problem. 

All that being said, I am kind of excited about this project now. I was initially skeptical of my ability to contribute to this project, but now I feel like I actually sort of know what I’m doing

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