Blog 6: Share what you learn

The context given here is that You have been an apprentice for a little while. You know a few things and people are starting to look to you as a source of knowledge. Up until now, you have focused exclusively on your own improvement as a craftsman. To become a journeyman, you will need the ability to communicate effectively and bring other people up to speed quickly. A good way to prepare you for that is to develop the habit of regularly sharing the lessons you have learned. This may take the form of maintaining a blog or running “brown bag” sessions amongst your peers. You can also make presentations at conferences or write tutorials for the various technologies and techniques that you are learning.

The books highlight that Being part of a community of individuals where both learning on your own and humbly sharing that newly acquired knowledge are valued is one of the most powerful aspects of apprenticeship. It makes otherwise-esoteric fields of knowledge suddenly accessible, and provides apprentices with guides who speak their language. That being said some lessons should not be shared, and it’s important to keep in mind that there is an ethical dimension to knowledge. Before sharing something, consider whether that lesson is yours to share. It may be a secret, or it may harm others. Things that seem obvious to you because of your current context may in fact be your employer’s “secret sauce” and it is all too easy as an apprentice to overlook the consequences (legal, financial, and political) of sharing that knowledge.

I can personally relate to the content in this pattern because I have worked for 2 years as a tutor for introduction to programming class (java) and it has helped me on so many levels. I remember my first instinct was to decline the job when the position was first offered to me. But then I took “a risk” and started working as mentor and all of a sudden, my understanding in the class material got better. I got comfortable sharing knowledge in an effective way, and I got great public speaking skills

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

Blog 5: Use Your Title

The context given here is that as a result of your dedication to learning, you have been hired or promoted (formally or informally) into a position with a title containing words such as “senior,” “architect,” or “lead”. The problem is then that your job title doesn’t match what you see in the mirror. When you introduce yourself in a professional setting, you feel as if you have to apologize or explain away the difference between your skill level and your job description. The solution suggested is not to allow your title to affect you. It is a distraction that should be kept on the outskirts of your consciousness. Use your title to gauge your organization, not yourself.

Impressive titles and responsibilities do not indicate that your apprenticeship is over. They only serve to remind you that there is a shortage of craftsmen in our industry so we should not be fooled by an impressive title. Another variant of this theme is informal versus formal titles. For instance, you may have grown into a position of authority on your team, despite your formal title remaining the same. These informal titles can be hard to ignore, because they are constantly reinforced by your peers, even if they conflict with your self-assessment. During these times, your connections with your mentors and peers will be critical to keep you grounded in reality.

I was really glad to see that the title subject was tackled in this book. So many times, I have found myself in jobs doing way more than what my title said sometimes even doing something completely different. In my current position, I am doing my job and some part of the data analyst job and at first, I got slightly annoyed but I have now realized that I would try to learn from it as much as possible rather than complain about it

I also really liked their action plan which is to Write down a long and descriptive version of your job title. Make sure it accurately reflects what you really do at work and your skill level. Keep this updated, and from time to time imagine how you would view a stranger who had this job description.

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

Blog 4: Dig Deeper

This pattern encourages us to go beyond the surface level work. The context given is that You live in a world of tight deadlines and complex software projects that use a multitude of tools. Your employers cannot afford the luxury of employing enough specialists to fill every role. You learn only enough about any tool to get today’s job done. You select a handful of tutorials on the language or library that you’re working with today and consequently You make decisions without taking the time to understand the issues, and copy the toy examples provided with the tools. The problem is then that You keep running into difficulty maintaining the code you’ve written because it turns out that the tutorials you followed cut corners and simplified complex issues. You find that your superficial knowledge of a thousand tools means you’re always floundering whenever a subtle bug arises or you have to do something that demands deep knowledge.

The solution suggested is now to Learn to dig deep into tools, technologies, and techniques. Acquire the depths of knowledge to the point that you know why things are the way they are. Depth means understanding the forces that led to a design rather than just the details of a design. In other words, it also means understanding type theory rather than simply parroting the things you’ve heard others say. I agree with what is being said because the areas where you have deep knowledge feed your confidence and they indicate places where you can deliver value early in your time with a new team. More importantly, this depth of knowledge is something you can fall back on to give you the strength to tackle new areas.  I have mentioned before how I usually run straight to google or StackOverflow in time of doubts but 95% if the time the website only provides “quick fix” type of answers and there is no real learning happening. I have understood that applying this pattern regularly, will help me truly understand how my tools work and I will no longer just be gluing bits of code together and depending on other people’s magic to do the heavy lifting.

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

Sprint Retrospective Blog #3

This phase in our project is to put together all the pieces we have been implementing for weeks. It is the best part of our project because we have been working on something for months and finally we can see what it looks like after all. However, this realization would not come without many different adjustments to the program. Several pieces have played a role in the process, and all the teams have contributed to the final point. For my part, I have worked on more environment setups. For example, Learn how to use commitlint/conventional commits for the Application source codeEditcommitlintng: Issue worcester/cs/naturalization-interview-confidence-environment/General#13. is one of the resources that I have used to set up the files in a way in case it gets to push the files to the main branch and has a bad commit message it will fail the pipeline but if it gets to push to any branch other than main it won’t fail the pipeline but it will give you a warning. Since we were working on a collaboration that was essential to maintain a good environment for all. The syntax for the file code is commitconfig.sh echo “module.exports = {extends: [‘@commitlint/config-conventional’]}” > commitlint.config.js this will set the configuration. On top of commit messages, the Conventional Commits specification is a lightweight convention. It provides a simple set of rules for generating an explicit commit history, making it easier to build automated tools on top of it. Second, Learn how to add and remove VS Code Dependencies to a Docker imageEdit, Issue: worcester/cs/naturalization-interview-confidence-environment/demo-react#22. We wanted to know how to add or remove NPM dependencies in a Docker container used by React Native projects in this issue. Using VS Code to add dependencies:
Look in package.json for the extension ID and paste it alongside the required version. I have pulled the join working file from gitlab to run to test on the docker environment. After many tries, eventually, all dependencies were installed and the program worked properly.
In issue worcester/cs/naturalization-interview-confidence-environment/demo-react#45: Prompter Question pageEdit, in this issue I followed my opposition team member, which was assigned for that task. The goal for this issue was to create a page that will contain a list of questions that the prompter can choose from and read to the test taker. It should show all of the options in a card format. The full text of a card should be displayed on a new page once it has been selected. Find out what base image criteria isEdit issue: worcester/cs/naturalization-interview-confidence-environment/demo-react#52. As you can imagine, many people find it difficult to choose the right container base image. A base image is available for every major Linux distribution. For programming languages such as Python, Ruby, and Node.js, open-source projects provide their own base images. For services like MariaDB, Redis, Elastic, and MySQL, many open-source projects and vendors provide their own images. While programming languages and services aren’t technically base images, most people consider them to be so and factor them into their decision-making process when selecting standardized base images. This is why the container base image matters when we want to set the environment.

Overall, we had a better sprint due to modification from the previous ones. We have learned how to write issues properly. We had a more detailed plan for every issue. Communication, in general, became absolutely a cornerstone for our success. We have improved on planning. We have selected the topics based on the needs of the previous discussion. As we struggled in the past to break issues into small pieces, we were able to correct that and made a better reading board for everyone. I personally went over the issues on the board where if something is not cleared or detailed then I would ask questions related to that issue.
For the future we wish that we had time to make all the functionalities of the program work. Such as to be able to navigate in the app page by page. To be able to filter question by question from the main page without any difficulty. Finally, set all the functionalities on the app for user friendly. This project has been nothing but learning curve for all of us. Giving the fact that we did not have a blue print from previous example, we now leave a working project for the upcoming team that will be working to improve this application.

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

Use the Source

Programming involves applying the right pattern to a wide variety of scenarios. A way to learn how to apply those patterns is to analyze how other people have done them. One of the best ways to do this is by reviewing the publicly written code by someone who has published open-source code. Reading and understanding the craft a master has created, it will spawn ideas within you as to how to improve your own programming patterns and creations.  

I find it interesting that it gets easier to read someone else’s code the more that you read it and that the faster you can comprehend code is an indication of your level of mastery. I also found it to be an interesting recommendation to use git to track the history of code over time to view how it is improved. Doing this will help you identify the type of errors that passed inspection but eventually needed to be fixed or modified. In the future, you will be able to apply the patterns you observed to the code you write yourself.

I often program using TypeScript and open-source npm packages. Oftentimes with smaller node packages, they lack full documentation of the entire codebase. When this happens, I use my IDE’s source inspection tool to look at the function within the node package to understand how the package classes and functions work. There are also times when there is a node package written in JavaScript that does not come with predefined TypeScript type definitions.

To use these node packages with type safety, I write my own type definitions by inspecting the source code for the open-source package I am using. To some degree, I have already been reading the source, but not with the sole purpose of reading and learning the patterns of the software’s author. In the future, I will spend more time appreciating that I am looking at someone else’s craft that they fine-tuned to the best of their ability. Making sure to learn and take away as much as I can from their programming. I do not disagree with anything in this pattern, as viewing the source is something that I have already made a habit of doing.

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

Sprint Review #3

This sprint was the worst one for me. The team did great job, it’s just I, who did not did much job in this sprint. This sprint/weeks of this semester was a roller roaster for me. So many projects to do, presentations, assignments, essays. Every professor was pushing their assignments. I learned a valuable lesson this past weeks and it was a “stick with one capstone my friend”. I took two capstones as I liked both software developing and data analysis. It is not that, I liked one capstone and dislike another one, it is because of the amount of work. I think it is okay to take two capstones if you are taking only 2-3 classes so that you can only focus on capstone classes but a semester with 5 classes, 4 of them are CS courses and each classes having final projects was a hell for me.

As for the sprint, I did not do much work than just cleaning up some code. You can find the commit here. In the console of the browser, there was an warning saying the request to HTTP request may not success every time. So I simply added a try catch to get rid of that annoying warning. So now if we make a bad request to HTTP then the code will console log an error. Another reason I added try catch is that, suppose we were to use this program in real life or real POS or anywhere where this application will be running and if there is a bad request then the application will crash. And nobody would want to restart the application every time. With try catch, the application will console log the error and keep running. That is all I did for the sprint. I did not put much work to the team and I wanted to do more but with tight schedules, I wasn’t able to do much. There was able another error with my device, the docker image kept failing for my MAC while it worked for the other devices of my team mates who had windows. I had that issue until my scrum master told me to add a timeout in the docker file which did fix the issue but then it was pretty late. It was my fault for not talking about it in meeting or in discord group chat. I was responsible for getting in touch with another group about key-cloak but I never had time to.

Final thoughts: Front-end wouldn’t have been success without Michale Friederich. He did all the integration between back-end and front-end. If I were to do that then it would take me longer. So hats off to him. Everyone in the group did an amazing job throughout the semester. I have read everyone’s sprint review blog and they are putting in the work more than me. If it were to be different team mates then I don’t think we would have finish this much of work at the end of the semester as everything was new to us. Everyone in my group had a great vision of what the project should look like at the end and we delivered it about 95% of finished application. The next group who will take over after us will just have to clean up the code, connect with key-cloak etc but it will not be as messy as it was when we first received the application as we had to reformat everything. Overall, I was paired with talented developers and I am glad I paired with them. Happy Coding!

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

The Long Road Pattern

For this week’s apprenticeship pattern, I did a reading on “The Long Road”. The Long Road pattern is about your future. In this pattern it talks about trying to imagine yourself 10 years, 20 years, or even 40 years from now. They want you to think about that and possibly write down a summary of your profession. By doing this, it will enable you to think how you would want your professional path to be like and allows you to plan how things could go. The problem in this pattern is that you want to become an expert in what you want to do however, things may get in the way like that such as promotions and just always picking the highest paying job and by doing this, it takes away the goal you had originally which is to do something that you enjoy doing but instead doing jobs that in reality sucks.

My initial reaction to this, is that it is an interesting pattern to read about. It is interesting because I never thought to look past 5 years into the future and just thinking about the future and where I want to be in general. Obviously, everyone wants to make six figures, but the main goal is to make that much by doing something you love or enjoy doing. After reading this pattern I did take a moment to think about where I would like to be down the road and it made me realize what I really wanted to do with my future. Of course things happen, and the future isn’t exactly set, but it gives me a good idea of what I need to do and what I have to do to accomplish it.

The pattern has changed the way I view my profession because I never thought about needing to take a step back and think about the distance future of where I would like to be. Do I still want to be programming all my life or would I like to do something different by the age of 40? It was an eye opener to me because it really allowed me to set goals that I want to achieve by a certain age. Sure, programming is fun and all but there’s much more to life than sitting around a desk and creating programs and such. I want to create memories that will last a lifetime and explore the world.  If I can find a career that would enable me to do that then that would be the ideal job.

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

Sprint Review #3

This past sprint session was my teams final sprint for the semester and our main focus is now on our final presentation. During the first sprint we spent time setting up front end and back end files with the goal of making a simple system to secure with Keycloak. The Keycloak implementation in itself took much more time than anticipated so our final product is Keycloak securing a simple front end vue application. There were many roadblocks in getting Keycloak to work – JavaScript connector not working, figuring out how to create a shared realm with multiple users, and general issues coming up with each step we took in trying to link it with a web app. Initially we have assigned different team mates to different areas of our project but by the middle of the second sprint getting an instance of Keycloak to work became an all hands on deck priority. I did spend some time working on a backend with the hopes of linking it with our front end however there is not enough time in the semester. The front end, back end, and API should each have their own dev container and this is something the next semester students can pick up, however I did go in and create a dev container for the API. I wanted to make the system ready for future semesters to pick it up from there and link the pieces together. The most important part is we have figured out how to attach Keycloak to any web application and the next semester students should be able to use our research to secure LibreFood Pantry with Keycloak.

Our group worked well during our final sprint and I think our communication skills all improved greatly over the course of the three sprints. Keycloak being an add on to any system comes with many “wires” to connect to the existing system and we experienced issues at almost each next step of connecting it to the vue app. Our team had to learn how to communicate at each road block and work together to solve the problem. I think towards the end we improved by talking about these issues during class and finding solutions on the spot and making decisions then rather than taking the issue home and trying to figure it out on your own. Most of us have preferred to work on coding projects individually however that isn’t how real programming jobs work. In an office setting the software development team will be expected to collaborate on the project and constantly merge code together and all work on different pieces of the same over all system. I’m grateful to have a better idea of how to work with other developers and this will help me in my first programming job.

I am proud with the final product we created. We hit the main goal of understanding Keycloak and learning the steps to implement it with any web application and if we had more time in the semester I think our group would have been able to connect it to LibreFood Pantry, and I am excited to see the next semester students take our work to the end.

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

Sprint retrospective #3

This last sprint has been different from the other two. This was our last and we needed to talk and communicate well with the team and know exactly what to do for the last sprint. We started by talking about the issues that we created in the past sprint that we did not finish and then after that, talked about the plans we had for sprint planning 3 and the new issues that needed to be created.

The issues that I have created and worked on are: “Discuss Integration with Inventory System”, “Research Kubernetes from AWS Team”, “Backend: Create HTTP calls for Database”, and “Research: How to deploy RabitMQ on Kubernetes”. These issues were put under the status “done” because we had all the information needed. I did not really have time to work on the first about discussing integration with the inventory system from the other section but my teammate Mike Morley talked with them and gathered all the information needed. I did work on Kubernetes, actually, 90% of my time working on it.

I talked with the other team too, but did my own research and gathered all the information I needed. One of my Teammates Andrew Sychtysz talked with the Scrum Master from the Kubernetes team and also did his own research on the same issue as mine. The more information we have, the better. Kubernetes have a lot of interesting articles, but with them, I felt like the information were very broad and too much, so I decided to watch videos/tutorials. I did watch a lot of videos and learned a lot about Kubernetes and I am planning on sharing all that I know on GitLab.

The other issue about Rabbit MQ, I did a lot of research on it because for some reasons but since it was not part of our project, the professor said to abandon that issue. But I am deciding to talk about it at least because I do have a lot of information on RabbitMQ that I found interesting and did watch some videos and read articles.

As individuals, we did work and completed what we were supposed to do. Some issues still need reviews, some will be put back in to open section for those who will work on this project next year. As a team, we all contributed and were there for each other whenever we needed help. For example when Mike Morley helped discuss with Inventory System from the other section because I was not available to do that. Also when Andrew helped with Kubernetes, or when I and Lena Viazmitinov worked on the backend. We might not finish the project but we did work and have all put up with the work.

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.

Final Sprint Retrospective

Christian Shadis

This past week, my development team in my Software Development capstone completed our third and final Scrum sprint for the Spring 2022 semester. We completed our final Sprint Review on April 28th and have officially stopped working on the project. This was my first experience working in an Agile environment, along with my first time working on a Humanitarian Free & Open-Source Software Project.  

There were several areas in which our team excelled. The team did an excellent job of labor division, as through the entire semester, all team members were contributing equally to the advancement of the project. We also worked well together as a group; we were able to concurrently work on code very effectively, combining the knowledge of everyone to solve problems we couldn’t as individuals. Throughout the semester, we improved our workflow, increased efficiency of standup meetings, and improved the organization of our source control and merge processes.

There were some areas to improve for our team. We struggled to create appropriate issues in Gitlab to work on – we often found that we were creating issues that were too vague, too large, or duplicates of another issue. We also could have done a better job of maintaining the Epics board in Gitlab; we focused primarily on the issues and not on the Epics they were attached to.

As an individual, I worked well throughout the semester. I was the Scrum master for my team, a position I had never held and was not confident in. I challenged myself to help the team stay organized and balanced in our Scrum meetings and saw improvement throughout the semester. During the first sprint, we would often get sidetracked during standup meetings talking about problems team members were running into and were using more time than necessary. I was able to help the team keep our focus on the current meeting and save other discussions for after, increasing the efficiency of our utilization of class time.

I believe the semester went well both for the team and for my individual work, but there are areas in which I can improve. First, I found myself feeling disorganized occasionally throughout the semester from making too many changes at once – I would like to get better at treating issues as small, independent tasks that are fixed alone on a branch and then merged, instead of completing several small changes in the same issue and branch. This will make it easier to stay organized with what I am working on and will make the source control system more effective at tracking the work I did on each issue.

I contributed to the project in several ways in the final sprint. The major hurdle we faced was getting the backend and API to connect so HTTP calls can be made to the API. I spent the majority of my time trying to debug the various errors we were running into, such as connection errors and socket hangups https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/40 . This issue is a great example of our misuse of issues – while only one issue was listed, it consisted of many hours of work and many changes to files —  Javascript files, the bash scripts responsible for starting the server, and the API itself. While I was ultimately unsuccessful in completing my fix, I was able to gain a more complete understanding of the project and how each file and component fits into the larger picture of the system.

I would consider the sprint and the semester successful overall. Essentially, we have a working and validated API, most backend code, and have linked the two together. The next steps for next semester’s group will be to continue to develop testing, along with incorporating Identity and Access Management and deploy the server on Amazon Web Services. I feel much more comfortable working in an Agile environment and working on smaller pieces of large HFOSS codebases, and I feel far more capable of working as a developer professionally in the coming year.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.