Category Archives: Week 12

Creating Workflow Diagrams & Beginning the GitLab Migration

Last week started on Monday with trying to resolve why the DCO bot would not show up as a status check for a GitHub repository. I tried enabling it for the test organization instead of an individual repository and that still wasn’t working. Eventually by searching the error message that appeared in the box I found out through an article for enabling CI that in GitHub you need to manually trigger the process before you can enable it as a status check. This solved the issue and after creating a branch, committing to it, and merging it with master, the DCO bot ran for the first time and then showed up as a status check in the branch restrictions menu. I updated the pull request with a comment about this since it resolved a discussion that had been ongoing with Dr. Jackson. After that, I commented on the workflow diagrams issue to see which sections should have diagrams created for them. I looked over the contributing document and thought that Getting ready to work, Work, and Getting your work reviewed and merged all seemed like they could use some diagrams. Finally, I figured out what I would be doing for the rest of the week and planned questions for the next day’s meeting. 

Tuesday started with a research meeting that was quickly joined by Dr. Jackson over the phone. We discussed various things including the ongoing project board issue that needs to get resolved so we could update the documents with which board structure to use and how to set it up. We also talked about changing to a different license for some of the project files. I helped to resolve a Discord issue with server joining messages. Most of what I would be working on for the rest of the week was beginning the migration from GitHub to GitLab as it was at this point a pretty sure thing that we were going with this platform. I would start this by deleting the previously imported repositories and re-import them.

Wednesday I started this GitLab migration and deleted all of the previous repositories in the LibreFoodPantry GitLab group. I then imported all of the projects from GitHub to my account and transferred them to the LFP group. One issue that I discovered when importing the projects was that it didn’t link issues that were created by some users on GitHub that didn’t have a GitLab account and it made me the owner of these un-linked issues. After that, I read over the license that Dr. Jackson suggested we start using. After reading it over, I agree with Dr. Wurst that it seems a little too complicated. After getting a response from Dr. Jackson on which sections to create diagrams for, I started working on this by creating a new feature branch. I started with the Getting ready to work section. I looked at the links he suggested for how commit diagrams were designed and somewhat used some of the styling from these later when I was creating my commit diagrams. As I was creating the diagrams, I was running through the workflow myself to see that it worked properly for me. I ended up adding some git commands into the contributing document that I thought would be helpful. I also created a new issue that I discovered when testing this workflow about how to shops update their master branch when changes are made in LFP’s upstream. I suggested using GitLab’s auto repository mirroring function that takes care of this automatically. I also tested out pushing an empty commit to a new branch and creating a work-in-progress merge request back to the LFP project. I thought it was cool that when you push to a branch after doing this the commits also go to the WIP merge request so others can see your progress. By the end of the day I had created diagrams for Getting ready to work and the work sections. 

Thursday was exciting. A decision had finally been reached and we would end up using GitLab and Discord! After seeing this I posted my migration issue and also replied what was the best document to follow for importing repositories. It was decided that shop managers would re-import the projects so that they would be the owners of any issues that didn’t properly link in the import. I then went back to the diagrams and tested out how you update a feature branch from the master branch. I realized that I forgot to add the developer’s computer to the diagrams and went back to the previously created diagrams and added this. I also wanted to figure out where upstream was pointing to and realized that it was the LFP project’s master branch after some searching. I then had to figure out how to set the upstream’s master for a cloned repository of this from the shop fork, this was aided by a past exercise from CS348. I think this command should probably be added to the contributing document since it is not mentioned and not something that happens automatically. I also discovered some other issues that should be touched up on in the contributing document but I wanted to finish the diagrams before migrating to GitLab so my commits would transfer over properly. The hardest part of the diagrams was creating the commit graphs. I figured this out by looking at the commits that were on the different branches through the Web UI and after that I discovered that GitLab has a commit graph for repositories. That helped greatly with creating diagrams for the merge commits part of the workflow. I then finished the Getting your work reviewed and merged diagram and pushed that to the branch. 

On Friday there was a bunch of notifications since a lot of new issues were created on GitLab since we started migration to this platform. I started looking at some of the new ones and also replied to Dr. Wurst’s question about why commits on his projects seem to have transferred correctly. I discovered that the issue with linking accounts is more related to issues and not commits and that GitLab seems to make dummy accounts for commits if it can’t link to an actual account. I then enabled the DCO push rule for Dr. Wurst’s imported projects. I then created a pull request for my diagrams before the ProjectTemplate repository was imported to GitLab. I  also assigned myself some new issues to work on. Later that night Dr. Jackson discovered when importing the ProjectTemplate repository that issues I created on GitHub weren’t being linked to my GitLab account on. We tried to resolve this in various ways by enabling different options. I tried signing in to GitLab with my GitHub account and set the same email address on both platforms to the same one and made it publicly viewable. Sadly, this did not resolve the issue and we would try to fix it the next day.

Saturday, Dr. Jackson decided that I should import the ProjectTemplate repository myself so that it would automatically link all of my work to my GitLab account. This worked fine except for a couple of merge commits I had done with a private GitHub email address through the Web UI. We decided this was fine and I left it as-is. Finally, I enabled DCO checks for the BEAR-Necessities-Market project and updated the issue with this information.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Going Back To Square One

Good my fellow readers!

Today I will be discussing an individual Apprenticeship Pattern from the book, Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. The pattern I would like to discuss today is naturally the first one, Your First Language, because where else is there to start but at the beginning?

The pattern starts by defining itself as a pattern for those who have surface knowledge of a couple of languages. It suggests that this particular pattern is for those who need to learn a language to solve a problem at work for example, or need to know a language for a job interview. It then launches into the solution, through execution of the pattern. To put it plainly the pattern is to pick a language and learn it. Having a problem to solve helps the process by giving you a goal to work towards and a drive to keep learning. It is also advised to take things slow and in small steps. It is also suggested to find a community and learn from its members as some methods or teachings may only be spread by word of mouth. It ends by reminding the reader to not get stuck with one language and to spread out into other languages.

I will admit, with this being the first pattern in the book I expected it to be for total beginners but it is aimed at just about everyone. What I find interesting about this pattern is that it seems to cater well to those who have never really picked up coding before or someone who, like myself, have had years of high school and college education in coding. I will admit that the amount I know about all the languages I have learned about is somewhat shallow. Some go deeper but many are probably not that far off from just surface knowledge. I might just try following this pattern after graduation. At first, I would have only recommended this pattern for only beginners who haven’t had formal schooling but after reconsidering, I think even those like myself who have had formal schooling can benefit from this pattern.

That’s all I have to draw from this first pattern and I hope to get more from future patterns. Until next time readers!

 

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

“Expand Your Bandwidth” Apprenticeship Pattern

I am writing this blog post about the “Expand Your Bandwidth” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about learning about a greater variety of topics than just what tends to be the most relevant. The chapter describes the problem as having a narrow understanding of software development that focuses only on the low-level details of past work. The solution to this is to just start learning about different things. I think that this is a relevant concept that I seem to be dealing with at the moment. My specialty is computer science, and I have a deep understanding of many of the fundamental concepts in computer science. Software development, though, involves much more than just computer science, and I have not researched software development beyond researching computer science. The problem here is that I have a narrow understanding of software development, and the solution is to research the other topics that are important to understand besides computer science.

I think that this chapter relates closely to the “Concrete Skills” apprenticeship pattern. The main difference is that this assumes you already have a full set of skills that are already being applied in a day job, and “Concrete Skills” is about developing those skills in the first place. I have not yet begun a career in software development, though, so these problems are effectively the same. I have a narrow understanding of software development, and this narrow understanding is a set of concrete skills.

There are often times that I do research new and unfamiliar concepts, but these tend to be concepts that are still within the field of computer science and not software development. I do have a goal of learning and understanding more, and there are a lot of topics that I find interesting enough to read about, develop some experience with and practice applying. This book constantly emphasizes the importance of a willingness to read, practice, research and learn, but it puts an equal emphasis on software development. My concerns should be lessened by just applying myself more toward software development in particular.

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

Studying the Classics

 

 

 

 

 

 

 

 

 

 

 

Link to the article: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch06s03.html

 

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Expand Your Bandwidth

The apprenticeship pattern of “Expand Your Bandwidth” refers to the situation in which you’ve picked up a basic set of skills, however your understanding of software development is still narrow and only focused on the low-level details of what you’ve been working on. In this situation, you’ve only been taking in a relatively small amount of information gradually, but sometimes you need to take in a large amount of information and efficiently absorb it. So in this case, “Expand Your Bandwidth” means to be able to do just that.

I can see how this pattern is really important and would be immensely helpful to master, but being able to take in more information than you’re used to and at the same time efficiently absorb it, understand it, retain it, and apply it is a tall task. No doubt that mastering this early on in your career will be a massive boon.

This pattern includes some useful examples of where you could seek out new knowledge and experiences. For example, signing up for Google Reader or any other blog aggregator and subscribing to software development blogs that interest you is definitely a good idea to learn about a variety of topics from multiple perspectives. If nothing else, this is something that I certainly plan on taking away from this post. Rather than wasting my time on websites like Reddit, I think it’s in my best interest to spend that time reading something more productive. I also think subscribing to a moderately high-traffic online mailing list and trying to answer people’s questions is a good idea as well (maybe something like stackoverflow).

Overall, I’d say that this pattern made me understand a little better about how an apprentice will have to take in much more information than they’re used to taking and also be able to process and retain it, while at the same time not getting overwhelmed by it. Of course there are times in which you should stop focusing on expanding your bandwidth and come back to the craft, so it should only be used as a means to an end.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Pattern 8 – Record What You Learn

I decided to read “Record What You Learn” for this week’s post. This one is pretty self explanatory, record what you learn. The pattern says to do just this, and explains that this is a way to review key learnings throughout your journey of software development craftsmanship. The pattern also notes that it is important to not let your writings become a graveyard for what you have learned. By this, they mean that you should consistently go back and review what you’ve written in the past to possibly amend the posts, or to find links to other notes you have written.

I agree that this is a very valuable “study” technique and it works for all facets of learning. The most difficult part of this, is that this is a very time intensive way to remember everything. As you learn more, the bigger the library of written lessons gets. This mean that every time you learn something, that review session gets longer. I think that this means that it is important to acknowledge that you simply will have to relearn things from time to time, but documenting what you’ve learned for higher level topics, is a great way to save time in the future.

While I do see how this could be difficult for an individual who is learning vastly different and often irrelevant topics when compared to each other, this is definitely something that can be used as part of a company project wiki. Large companies are constantly hiring new personnel who have to play catch-up to learn a code base as well as the coding styles of their peers. Having some sort of blog or wiki for the project could help these new-hires get acquainted with how the company functions and how to solve problems that are specific to the particular stack and business logic that the company is utilizing.

I do not know if I see myself personally following this advice, because this is not really my learning style. I tend to learn something by repetition instead of documenting what I’m doing. However, I do recommend that anyone who learns well via methods like flash cards, studying notes, etc, give this method of learning a try. It could be quite useful to someone who succeeds` when applying these learning methods.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: The Deep End

The Deep End in Chapter 2: Emptying the Cup of Apprenticeship Patterns is a pattern that reflects much of how I’m feeling lately. There are several places in life where this pattern pops up — often because you’ve realized that things feel stagnant in your career. Things need to change in order for you to grow and expand your skillset, and your current environment doesn’t reflect one of growth. The solution of this problem is to make a large life change and let the chips fall where they may. It’s scary to do this because you’re so comfortable where you are and with the work you do, but at the same time you’re stuck in a rut and you need some sort of upheaval in order to feel excitement once again.

I’m feeling this pattern quite a bit right now because I’m finishing up my degree at Worcester State. I’m not quite in a rut at the moment, although the next phase of my professional development is going to demand that I move forward at a rapid pace. Going through the interviewing process is tricky, because I feel constantly aware of the areas of knowledge that I lack expertise in. Obviously no one can know everything, and it’s more important that you’re capable of learning and being an essential part of the team. I think that being hired as an entry level developer is going to be interesting because you really do feel as though you’re being thrown into the deep end.

It feels extremely overwhelming to move into a workspace that you have no experience in, especially in my case where I have no current internships. I know what to expect on a general level, however I also know that there will be many things that I won’t fully understand until I’ve worked as a software engineer for some time. In order to learn any of those things, I’m going to have to fail from time to time. That’s exactly the point of “The Deep End”, and that’s exactly what I need to make sure I remember. If you’re never in a place where you’re failing, you’re never in a place where you’re setting and aiming towards goals.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Retreat Into Competence

One thing that was brought to my attention when going through the computer science / software development major, was that many of us suffer from what I was told was “impostor syndrome”; the persistent feeling that I do not know anywhere near enough, and that fear that your are a hack or a fake. While this persistent fear is definitely a symptom of inexperience, it nevertheless is a challenge to gaining confidence in our abilities.

Thankfully the authors of Apprenticeship Patterns have developed a pattern for dealing with this fear in the real world. Their advice is when you feel overwhelmed by the volume of information you don’t understand yet, you should temporarily “retreat into competence”. By taking a short time to work on some problem which you do know well, you can reset your perspective and freshen your resolve to tackle the new challenges, bounding back like “a rock in a catapult”, using the backwards momentum to launch yourself even further than you would have gone originally.

While this is definitely a helpful strategy for compartmentalizing our learning experience, too much reliance on this pattern will result in mediocrity, as you would hardly make any meaningful progress and your skill as a craftsman will stagnate. The authors acknowledge this, and definitely warn against it, suggesting that retreating into competence should only be done with set time restrictions before we move forward again. Time boxing in this way will ensure we can regain our confidence and composure while at the same time making sure that we are always driving forward.

I definitely appreciate this pattern though and will definitely be applying it in the future to keep myself on track. It is remarkably helpful to be able to, as the authors put it “overcome the fear of your own incompetence”. By taking one step back and two steps forward, we can continue the march of progress at a more comfortable pace, and hopefully alleviate some of the fears and overwhelming feeling when facing the vastly expanding world of software development. This is definitely a pattern I have subconsciously been applying previously, but I will definitely make a more conscious effort to use it and time box myself properly to ensure stable progress.

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

Apprenticeship Pattern “Stay in the Trenches”

The long and short of the pattern is to not accept a lucrative position or promotion if it takes you away from practicing your technical skills. If those skills aren’t constantly honed, they will be lost or become outdated before long.

A family friend was a midlevel manager at a software development company before he was laid off. He had gotten away from doing the technical work. The trouble was that most companies promote from within, so it was hard for him to apply for a job that he had before. It was also hard for him to start a job doing the technical side because those skills weren’t as fresh in his mind. There’s a good lesson to be learned from his story.

I often hear from people complain their manager is out of touch. The pointy haired boss  from Dilbert strikes a chord for so many for a reason. Perhaps more fitting to this pattern is The Office’s (U.S.) Michael Scott. While he has his moments, he is by in large an extremely incompetent manager. However, he does go on some sales calls in the series, and it is clear that he is a brilliant salesman. It seems that it is common that people are promoted to the point where they are inept at that position and advance no further.

Although the pattern does not quite suggest that people are promoted until they aren’t the best managers they can be, it seems to suggest that if you are no longer using your technical skills, you will become more and more out of touch with that side. You will no longer be on track to become a master craftsman when you accept this route.

I do not want that to be me. I would like to continue to grow and learn. I have talked to people who have a technical background and become something else, such as a salesman or manager. I have been tempted to take this route. I am not saying that I won’t do something similar someday, but for the time being, this does not fit into my goals.

My goal is to become a master craftsman. I’m aware goals change over time, but I would like to pursue this for a while before reassessing. I feel as though the reason I would change tracks if I found that this career was no longer what I wanted. I don’t think that will be the case, but it is a possibility. The one thing I know I won’t do is change tracks if I’m happy where I’m at. Sometimes what seems like the logical next step to advance your career can actually be more of a step back. It is best to instead to choose the path that will lead you towards becoming a master instead.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Sweep the Floor

Hello there! For this week’s blog I have decided to write about the chapter of our textbook called “Sweep the Floor”. The chapter caught my attention because of the small description of it. The description of the chapter was something along the lines of you are a new member of a software development team and you need to gain their trust. This is something that intrigued me because I will be starting in a software development team as a new member at the end of May, and I am not quite sure what to expect. I have never worked in a real-life software development team, let alone develop software full-time 8-10 hours a day 5 days a week. This chapter was something I was hoping would help me when it comes time to integrate myself into my new team come May. So the problem that’s set out in this chapter is basically the same as mentioned above, the team doesn’t know you, you don’t know the team, so how can you find your place and find out how you can contribute best to the team? The solution is somewhat elementary and what some would think of as common sense. The first part of the solution is to volunteer for some small, perhaps even mundane task that either nobody else wants to take on or is too busy to take on. Sure, this isn’t a task you went to college for four years to complete. Maybe the task is transferring some physical data into excel, or updating computer software around the office. It doesn’t matter what the task is, what matters is that by taking the initiative and volunteering yourself for the small day-to-day not so glamorous tasks, you are slowly gaining your teams trust and finding your place on the team. They will appreciate that you are taking a step forward and doing things that need to be done; getting in the trenches (so to say) and eventually this will lead to your team trusting you to take on bigger tasks that are more normal for a software developer like pushing things to production and writing major elements of a program. I hope to use this tactic in my workplace to quickly assimilate into my team and find my place.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.