Category Archives: Week 10

GitHub and GitLab Issues

Week 9 started on Monday by dealing with the flagged GitHub accounts. As suggested by Dr. Wurst, I created a support ticket in the account and said that I was a student researcher testing out the GitHub platform for an open source project and if they could unflag the account and to contact Dr. Wurst if they had any questions about the project. I also included the issue of issue cards on project boards getting automatically removed by a spam filter. I copied this response for each one of the testing accounts so I ultimately filed 4 support tickets with GitHub. After that I tested out Dr. Jackson’s question about if shop managers on GitLab had the ability to manage their own subgroups if they are given owner permissions from the parent group owner. I tested this under the testing GitLab group by removing the shop manager account from the top-level group, creating a new shop subgroup, and adding the shop manager as the owner. This worked the way I thought it would and the shop manager was able to create subgroups within the shop subgroup and could add new members that weren’t in the parent GitLab group. I updated the GitHub issue card with confirming this finding. Then, I went on to read Dr. Jackson’s response to my earlier question of if it was still worth it to create documentation for GitLab Free based on his earlier response that GitLab Free doesn’t allow the creation of multiple issue boards and this would impact our use of the platform. Dr. Jackson’s detailed response included different ways of having workflows with the one issue board limit on GitLab Free. I ended up drawing some of these out on a whiteboard to visualize the concepts. I kind of like the concept of Dr. Jackson’s second option of having one board at the LFP level and that would be used by all of the shops. Although he says it is a disadvantage, right now I like the idea of all shops using one unified workflow as it makes documentation simpler and makes sure everyone is following the same steps to contribute to the projects. One question I have from this is how do the shop level boards look with this option or is it only just the one board in the LFP group? I also listened to the podcast he recommend about why a company switched from GitHub to GitLab. I found it pretty interesting and what they were saying mostly goes along with the differences I have found between the two services. I did like hearing from the perspective of someone who has a self-hosted instance of GitLab as this hasn’t been something I have been looking into but was interested in how this worked. Finally, Monday finished with discovering that our GitLab Gold membership wasn’t renewed properly and that we don’t have the Gold features available to us currently. This is a pretty big issue as it limits what I am able to test to just GitLab Free features. I emailed Dr. Wurst about this and he submitted a support ticket. 

For the rest of the week I checked to see if the GitLab Gold or the GitHub support tickets were updated. On Sunday I got a response from GitHub support to all of the support tickets saying that having multiple user accounts was against their terms of service and that they would remain flagged. I emailed Dr. Wurst about this and he would contact GitHub Education to see if there was anything they could do to help us. The GitLab Gold membership still hadn’t been fixed yet at this point. After looking at those, I went back to the diagrams I had been working on the previous week. I updated some of the GitLab diagrams to be consistent and fix an issue that it looked like the shop manager had to add themselves to a group which they don’t have to do. I then looked at some of the other documents in the community section of the LFP organization on GitHub to see how Dr. Jackson had formatted the other documents and what information to include. One thing I have a question on is what is the DCO and do I need to sign off on this for the commits I will be making to the project? Another is what to include for the licensing information at the bottom of the document? I then looked at the question Dr. Jackson had about if GitLab had an equivalent to the GitHub Probot framework for creating and using bots across the service. I found that although it seems possible to create bots on GitLab, they don’t seem to have a framework yet like GitHub does. 

Week 10 was short. On Monday I looked at the email response from GitHub Education regarding the multiple testing accounts. I found their response to be unhelpful to our situation and that their education features weren’t what we are looking for in testing permissions and project configurations for LFP. I took a quick look at the new website that Dr. Wurst created for LFP and how it currently links to the GitHub organization. I also read some of the principles listed on the LFP GitHub Community section like the Agile principles and the “FOSSisms“. I found the FOSSisms to be particularly interesting to read about with the process of contributing and working in open source projects, especially with how to get started with contributing to an open source project since that’s what I have been learning with this project. 

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.

Find Mentors

Hi everyone and welcome to another apprenticeship pattern blog post. Today apprenticeship blog post is going to about find mentors which I think is important because I’m doing the same thing in my new internship. I realize when you new to your craft or job it’s important because to always ask a question and help when needed and there should be someone you can count on. I agree with this pattern because when working and you come across a problem and have no idea how to fix it, you will need guidance and that will be your mentor. I think the best way to learn is to listen to those who have to be there before. I also agree that everyone will always find a mentor because I think there always someone that is willing to help anyone new that needs help. There might even be more than one mentors that will supervise an apprentice for example in the new job I have many people helping when I have trouble with a problem. I also agree that real-world apprentices have to scratch and claw their way into the lives of master craftsmen and are grateful for whatever attention they can get because I think that some mentors don’t if you want to learn or not so I think it always best to ask question and try to shadow the mentors as much as possible. I agree that when finding a mentor, you shouldn’t expect the mentor to know everything because no one does, and you are still walking the long road too. I like how the actions give a good tip on finding a mentor because it’s important to find the right one especially one the is patient with you. All in all, I think this apprenticeship pattern find a mentor is helpful and important. I know when I first started my job, I was looking for a mentor to help me when needed and I lucky to have a few that is patients with me. I feel like it was really important because I don’t think I can progress fast without taking the knowledge of others.

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

Use Your Title

Hi my readers. Welcome back to my blog.  In this blog post I am going to talk about an interesting pattern called “Use Your Title”.

Most us, who have worked in big companies and most of you who will in the future, are gonna have a FANCY title at your job. Sometimes even the person itself will get confused by its own title as at the beginning might not describe well what it means.

The best advice given by the authors for this pattern is: “Don’t allow your title to affect you! & Don’t be fooled by an impressive title!” It happens a lot nowadays that people have to explain what they really do because not everyone is aware of what a job title might be and what are the duties and responsibilities. There are also a lot of other cases where people misinterpret the job titles. My job title in my company is Support Engineer. and when some people would hear the name Support they automatically told me ” So you like talking on the phone with customer huh?!” That’s where I had to explain what my real position was and what was I actually doing. As I come from Albania, at the beginning I used to ‘blame’ on the company for giving me this title, but later on I realized it was the people who were to blame.

As you might know by now, I am graduating this May with a major in Computer Science and Software Development concentration. While having a conversation at my office with my teammates we all agreed that our titles were a bit too much as we hadn’t graduated as Engineers but developers. However, we all like using the fancy title.

The other side of the coin is where you have such a high job position and your job title doesn’t fully express much about it until you say what you actually do.

In both cases, the most important thing is to explain what you do with your own words and not the title, fancy or not. It is always good to have a written definition of what you do and what your duties are as you might never know who you might come across to.

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

Sprint 4 Retrospective

This past sprint flew by. We did manage to get some work done, although perhaps not quite as much as I would have liked. Still, it was a valuable sprint and we learned quite a bit during it.

Since the last review, we solidified the workflow through which we’re going to be contributing to the project. For each task, we’re going to be creating a branch. Then, after committing it the new branch, we’re going to be creating a pull request for it that we’ll use for development. As we commit, the commit history will appear on the pull request in our GitHub repository, and the progress of the component can be commented on and tracked by others. Once the component is done, we’ll leave a comment saying so, and then it will be be reviewed and pulled into the main branch.

There was a bit of a hold up for some time because we are required to use Google’s Angular Material Design were struggling to identify exactly where to find that. We didn’t entirely realize that the Angular Material Design library was exactly that. Once we did though, we updated the master branch so that all future branches would have compatibility with Angular Material. Our group in particular had already made a branch called Questionnaire-Form before we got it working with Material Design, so we elected to delete this branch and create a new one, named Q-Form.

Also, from what I’ve heard, our back-end plan is currently not going as anticipated. In the beginning, we had plans to either use mocking or to create a server with fake information that we could draw upon. Then, last sprint, we had established that we were going to be using mocking and tying that in to different services that our front end components needed to use. However, it seems as though we don’t fully understand how the back end is currently implemented, and it’s something that we’ll likely need our professor to look even further into before we dive in.

If I could change one thing about how this work has been going, it would definitely be to do more work more often. Currently I think it should be entirely possible to be finishing components almost weekly, and it seems as though no one in the class has been doing that. At least, they haven’t been pushed to the master branch if there has been significant work. However, hold ups with sorting out the development environment and getting material design to function have been a major slow-down, so it is understandable that things haven’t been getting done as fast as we had anticipated.

Going forward, we’re looking to make sure that our new form component on our Q-Form branch works exactly how the Angular Material Form component is designed to work. Right now we have it functioning how it should, with an input field and a submit button, however we’re struggling to get it styled in the exact way that Angular Material is meant to be. Once we cross that hurdle, it’ll be far easier to get components finished, committed, and merged into the master branch.

On to the next one!

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

“Expose Your Ignorance” Apprenticeship Pattern

I am writing this blog post about the “Expose Your Ignorance” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about making known what it is that you do not know in order to learn. People have a tendency of wanting to appear competent and knowledgeable about any job that is expected of them, but faking expertise is counterproductive. It is more helpful to seek knowledge than it is to hide ignorance. I have been looking at job descriptions lately, and many of them are filled with expectations and preferences referring to things I have never worked with before or have minimal experience with. My aptitude is for algorithms and data structures; I have studied and developed and implemented them a lot, for years. When it comes to “technologies”, though, I do not know anything about software development. There are so many languages and frameworks and libraries and acronyms that I am not familiar with because they have never been necessary or relevant before, and now I see that a lot of jobs are expecting proficiency with these tools. I am used to solving problems without extra tools, so in order to work in a new environment where an unfamiliar tool is necessary, it is important to establish that I do not know how to do anything using the tool. Then, I can begin to ask questions and learn how to apply my skills to the new problem. During the CAPSTONE project this semester, for instance, I am required to work with the Angular framework, and a tool for making things with Angular. I have no practical experience with any of these things, so whenever I need to know something in particular, I put out a question, so then I can learn. Rather than going off and trying to learn how to use these utilities, it is much more efficient to begin by seeing whether anybody else around already has an answer. Sharing knowledge and asking questions is a much more practical way to learn about how to work in a new environment.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Pattern 6 – Be The Worst

For this post, I was looking for an eye catching pattern name and “Be the Worst” definitely caught my eye. After a second a of thought, it was pretty obvious what this pattern would be about. This pattern breaks down why it is important to not be the big fish in the little pond. It encourages apprentices to not rush into leadership roles and to not strive to become the best on your team and stagnate with your position. Instead, if you find yourself at the top and lacking learning opportunities, it may be time to move on and find the bigger pond, to surround yourself with higher tier developers when you leave.

I almost entirely agree with this pattern. I remember growing up in a relatively small town, where we had a couple athletes who were notably better than anyone else in the town at their respective sport and position. None, yes none, of them tried to get into bigger school districts where they may be challenged more and had more of an opportunity to get scholarships and even potentially make it professionally. Instead they all enjoyed their high school careers at a school with roughly 500 students in a division 3 conference. They didn’t aspire to leave the little pond and they never made it anywhere in terms of athletics. There are definitely parallels to this even in the college world and looking for positions directly out of school. There are always going to be people who are happy to just cruise by and not learn everything that they can at each step of their careers. I honestly feel like these are the people who are most likely to never even get a job in respective majors and then somehow blame the university for not finding them a job with a 2.0 GPA. No one owes you anything and you can’t expect anything to be handed to you, knowledge especially. There is always more to learn and never enough time to get everything into a four year curriculum. Never settle for being the best you know. All that means is that you need to meet more people.

The only part of this pattern I disagree with is how the authors try to sway readers from promotions. Promotions and new responsibilities even outside of coding are definitely important to becoming the best within a company. If the goal is to rise through the ranks of a company, isn’t this an obvious side effect? That being said, I will definitely consider this pattern as I move along in my career.

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.

Find Mentors

While most of the Apprenticeship Patterns  I have read thus far are mainly focused on developing long term skills with an internal locus of control, as many of these patterns’ goal is to change our perspective to be more successful and adaptable to the software development industry. What I like most about this pattern, “find mentors”, is that the authors give good advice for branching out socially into the software development community by finding skilled individuals who can serve as mentors that can use their perspective and experience to catalyze the growth of our skills.

What spoke out most to me about this pattern and the reason I decided to write about it was their quote which seemed to me to encapsulate exactly the meaning of what they were going after; “Your apprenticeship is unlikely to happen in isolation”. While it is ultimately up to us as apprentices to take responsibility for our own development, there is an immense value in finding someone else who is worlds more experienced than you to show you the ropes and use the benefit of their experience to learn the best ways to do certain things or pitfalls to avoid.

The authors give a lot of good advice which I would not have thought about without reading this pattern. First, they highlight not only the importance of finding mentors but also the difficulties associated with finding something. Not only is there the risk that the individual is not interested in mentoring an apprentice, but it can also be difficult to find such a suitable person. The solution the authors provided is to start out by lurking at online forums related to the field and topics that we are going into. After lurking and getting a good sense of the community and their values, then it is good to start discussing on threads with people, and even asking for advice.

What I learned from this pattern is the importance of finding a skilled mentor to catalyze my professional development, as well as concrete strategies for finding people who might be willing to take on an apprentice. While the responsibility is on us as apprentices to gain the skills needed to succeed, finding a mentor is definitely a huge step forward in the journey to master the craft of software development.

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 “Breakable Toys”

This week, I will be exploring another apprenticeship pattern, which is “Breakable Toys.” I briefly mentioned this pattern in my last post, and I thought it was worth revisiting.

The professor of my capstone, Dr. Wurst, had suggested for us to try to create something, even if it wasn’t exactly what we were trying to do. This would allow us to dive deep into learning one thing.

The term he used for what he was talking about was “spike,” which I isn’t exactly the same as this pattern, but it certainly is a similar idea. This pattern more pertains to doing projects on your own time to learn from your mistakes.

In school, it wouldn’t make sense to turn in projects that don’t work. It would be hard to pass most classes if I did. In many cases, school or work, failure is not an option. Of course the authors don’t advocate experimenting with those projects. They would rather you learn independently so that you can apply the skills you pick up.

For the past few blogs, I have talked about being more proactive. I have made a conscious effort, but it has been hard keeping it up. I have to realize that change doesn’t happen overnight, and it’s good to take these setbacks in stride to avoid being discouraged.

In the pattern, it uses the analogy of someone learning to juggle. I once read a study where of those instructed to juggle just five minutes a day, all of the participants were able to juggle by the end of the study. Reading this was enough to encourage me to try this experiment for myself. I set a timer for five minutes everyday, and I was able to pick it up after a few weeks.

The important thing to note is that five minutes was the minimum I set for myself, but I would invariably go for much longer than that. Currently I do not have any side projects that I am actively pursuing. If I were to set a five minute minimum to do something, although it would be small, it would be far better than nothing. I’m willing to bet most days it turn into much, much longer segments of time than five minutes.

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

Apprenticeship Patterns – Practice, Practice, Practice

This pattern discusses the importance of practicing when it comes to improving your skills as a software developer. Many people’s daily programming activities do not give them the space to learn by making mistakes. If you find this to be the case, it is important to find an environment where you can practice without interruptions or pressure. For this pattern to be useful you need to carve out time to develop software in a relaxed and stress-free environment. If you aren’t relaxed, it will be harder to learn from your practice. Feedback is also important when it comes to practicing coding because it helps prevent bad techniques from being developed. The point of practicing is not to hone your memory, but to learn the nuances of your skill. This is why it is effective to do something a little different every time an exercise is performed. Choosing the right thing to practice is almost as important as the practicing itself. A good way to practice is to go through old programming books that focus on the fundamentals of computer science, as the information rarely stops being useful and provides a large source of interesting problems.

Reading this pattern was interesting because it complements the last pattern I wrote about, Use the Source. While that pattern discusses how reading code is important for improvement, this pattern talks about how practicing coding is important. I thought this pattern was very useful because it goes over the most effective strategies for practicing. The advice given about practicing in a relaxed environment and practicing within a community is very true. Enjoying your practice and getting feedback on it are both important aspects that are necessary if you want to see real improvement. The advice about doing exercises from older books that focus on the fundamentals rather than the latest trendy framework is also useful. There are so many frameworks out there that it can be overwhelming to pick one that you want to practice with, and sticking to the basics is usually more helpful anyways. Overall I thought this pattern was interesting to read through and I will try to apply what I’ve learned from it when I’m practicing in the future.

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

“Practice, Practice, Practice”

After “Expand Your Bandwidth”, we learned how to learn skill set. To make those skills better, I don’t know any other way than “Practice, Practice, Practice”. This is no secrets in life and coding is no exception. Once you learn, practice is the way that you can apply, and deeper understand from your mistakes. There is no point learn language without apply it to practice.

This is good point, if we take the time to practice our craft without interruptions, in an environment where you can feel comfortable making mistakes. When we don’t code with other people, we don’t feel pressure to get it right. When we make mistake, we just debug to fix and learn from it. The “deliberate practice” seem nice but we do not live in ideal world. Although it would be great, if there are program that learn from our coding and suggest exercise base on us weakness. It is better if we have stress-free and playful environment to practice, I would feel more comfortable doing in this area. Because I do feel the pressure coding in classroom. Although it is comfortable and less tress when we are coding alone. It is having its downside, to get better we need someone else to look at our code. Good code is not just the code can run or not. Code is good code when it is clean and efficient, by other developer look that our code. They could tell us where are our strong and weakness. We correct them and repeat the process; this is how we are getting better. As in the book suggest, each time should be a bit challenge. Take what we have learn and devise it to the next level. As I am graduating soon, this is one of my goals. I will try to practice more as well as learn new technology.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.