Category Archives: Week 11

The Workflow in Action

Last week started on Monday with getting back on track with this project. I looked at some of the issue updates on GitHub including the issue about switching to Discord. I then emailed Dr. Wurst asking about how the DCO sign-off works for committing to the project, hoping that I could push my setup documents and diagrams before the next day’s LFP committee meeting. To my surprise, the GitLab Gold issue had been fixed and the WSU account now has access to all of the Gold features again. I was really happy about this since it means I could go back to testing the advanced features offered with this package. Sadly, the GitHub issue still remains but as of Monday they hadn’t deleted my testing accounts yet. After that, I looked at the Probot question one last time and created my reply to Dr. Jackson about this. Finally, I looked at Dr. Wurst’s earlier question about free server time for open source projects. I couldn’t seem to find much information directly about if this was available, at least with Amazon Web Services or Google.

Tuesday started with a research meeting with Dr. Wurst. We covered a lot in this meeting, but the biggest thing was separating out the old issue card and breaking it into multiple new issues, as the old one was starting to get too big and congested. Dr. Wurst then closed the old issue for good. The new issues included:

By doing this it makes it easier to choose one task and finish it and see the whole progress as it moves across the project board on GitHub. 

After the meeting, I read the contributing document to see how I am supposed to be making additions to this project before committing and pushing to the repository. I then updated my local repository for the shop setup documents and re-exported all of the graph files. I then looked at the first pull request for this project and approved it and merged it into the master branch. Dr. Jackson decided that we should start using our own workflow when making additions to the LFP projects now, so I created a new branch for my setup documents, signed the previous commits with the DCO and then push the changes to GitHub. I then created a pull request and requested it to be reviewed by Dr. Jackson. 

Wednesday started with reading issue updates. I then looked to see if there was a way to always sign commits without having to add the -s parameter each time. I couldn’t find what I wanted to for this. I then started working on revising the documentation according to Dr. Jackson’s review comments. I pushed my changes to the branch. Finally, I started looking at what to do for creating workflow documentation. I discovered that Dr. Jackson had already wrote a lot that covered this already and asked on this issue card what more I can add to it. 

Thursday, I found out that the links in the setup documentation for the diagrams had broken when merged into the master branch. I fixed these image links for the setup diagrams by making them relative as Dr. Jackson suggested. I then started figuring out the answer to Dr. Jackson’s question about how labels work on GitLab issues and issue boards. With this I figured out how the different labels work in GitLab. This included group labels that allow a group level issue board to control issues with projects underneath the group. In response to the original question about how the two boards had a “doing” column I finally came to the conclusion that the original hand-off situation Dr. Jackson was asking about must have had two different column names such as “Team1 doing” and “Team2 doing” as if both boards had the same column name, moving an issue on one board automatically moves it on the other. I then updated the issue card with my response. 

Friday, I updated the platform comparison feature sheet with some of the things I’ve discovered since using the platform and closed Dr. Jackson’s comment about WIP merge requests. I then posted the link to this Google Sheet on the issue card on the community board about GitHub vs. GitLab. I then reviewed and approved some pull requests for Dr. Jackson. I then started looking at the documenting continuous integration issue and looked at how to enable CI for a GitHub project specifically using Travis as it seems to be the most popular CI marketplace app on GitHub. I actually found this really easy to do, only needing to set the language in the config file to Java for an example project I had. Finally, I reviewed another pull request for Dr. Jackson and added some suggested edits before approving, especially fixing broken document links. 

Saturday, I approved and merged some more pull requests and continued looking at how to get the DCO bot to work on a GitHub repository in order to double check the instructions Dr. Jackson posted for how to do this in our documentation. 

Sunday, I looked at if GitLab has its own version of a DCO bot. I found through different pages that using GitLab’s Push Rules for commits you can create a rule that enforces all commits to be signed according to a regular expression. I then had to figure out the correct regular expression that checks that all commits have a line matching the form:

Signed-off-by: ‘firstName lastName’ <username@domain>

After reading through a couple of tutorial websites and finding this great one that lets you test in real-time your expression against a string I finally figured out the correct expression to be:

Signed-off-by: \w+ \w+ <.+@.+\..+>

I then tested this on the GitLab web UI to make sure it works, and it did. I then tested it with locally with GitBash and also with branches. I found it works a little differently than the DCO bot on GitHub and blocks all commits from being pushed unless they have the included signature. I actually like this as it prevents the commits from even getting pushed to a project without including the sign-off. The downside is that this sign-off is needed on merge commits too. I then updated the DCO documentation to include instructions for enabling this on GitLab and added some comments on the pull request about this. Finally, I created the high-level continuous integration document, added a definition for it and an overview of how to enable it on GitHub and GitLab. I pushed this and created a pull request for this.

In retrospective after this week, I found that I enjoyed the workflow we are using with selecting an issue to work on, creating a branch, pushing the work, then asking for it to be reviewed by someone else before merging. I especially like the reviewing part as you can always have a second opinion before posting the work you have done to the master branch.

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

Draw Your Own Map

According to my next Apprenticeship Pattern blog I chose “Draw Your Own Map,” as one of the most interesting patterns and which fits perfectly in my logic. When you decide to enter the Software Development world, you may think that it’s a hard and tough game, or sometimes you believe that your career will always … Continue reading Draw Your Own Map

From the blog cs-wsu – Kristi Pina&#039;s Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Expose your ignorance

Hello everyone and welcome back to another apprenticeship patterns blog post which is going to about expose your ignorance for CS 448. I think it’s an important pattern because I was in the same situation because I was uncomfortable with having the idea I didn’t know what I was doing and I didn’t want other people to think I don’t know what I do so I would stay quiet and try to guess what’s going on and it wasn’t working so well for me just like the article says. I now think it’s better to let people know what you are struggling on so that they can help you through your problems. When I first started my internship at an IT company, I first let everyone know that I didn’t know much or anything about IT, and everyone was very understandable and help me through it. I think if I would of stay quiet and act like I knew what I was doing it would of cause more harm than if I didn’t. I know that in ordered to learn more and grow, you must expose your weakness. I think this pattern does a good explaining that you should find your weakness and work on it and add more to the list as you go and don’t be a shame of it. I agree that you must show the process through your journey for the people that depend on you to know your stuff because if you don’t then you would show no promise. It’s also important to build a strong relationship with people as you are in your journey. All in all, I think this pattern was important because it highlights most of the stuff that should make you successful when on a journey to be a craftsman. I don’t disagree with anything in this article because most of the stuff that it goes, I try to follow every day because its good advice which I hear from successful people. I think it’s important to honest with your self and knows that you still learning and everyone doesn’t know everything and everyone is still learning

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

“Concrete Skills” Apprenticeship Pattern

I am writing this blog post about the “Concrete Skills” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about dealing with concerns about seeking a role on a team but not having any practical experience. I chose to write about this pattern in particular because I find it relevant to myself at the moment. I am searching through job descriptions and they all seem to prefer certain areas of experience that I do not have. This is also evident in our capstone project. The “solution” section of this chapter in the book says to gain some concrete skills. I do have concrete skills; my aptitude is for mathematics, data structures and algorithms – computer science in general. It refers specifically to “tools” and “technologies”, though, and I know nothing about that. It becomes apparent when I work on the capstone project that my expertise has no application here. This sort of computer programming has nothing to do with computer “science.” There is no logical problem to solve, there are only tools and frameworks to learn how to utilize in order to accomplish some basic tasks. My past experiences have not seemed to have prepared me to be any better than anyone else at approaching these problems. It seems, then, that the “concrete skills” that I need are of a different sort. The chapter recommends looking at the CVs of others and finding a common set of discrete skills that seem important to become familiar with. This seems like a good idea. In order to gain some level of confidence about being able to perform on a team, it would be helpful to become familiar with the skills and common knowledge among the demographic. Rather than continuing to study computer science, there seems to be an additional field of knowledge that I am unaware of a name for, which is comprised of tools and technologies that are required for certain software development tasks. It seems like it will be important for me to gain some “concrete skills” in whatever field it is this might be.

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

Sharing what I learned

 

 

 

 

 

 

 

 

 

 

 

 

 

Link to the blog: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s07.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.

Expand Your Bandwidth

In their chapter dedicated to Perceptual Learning, the authors offer some good advice under the apprenticeship pattern “Expand Your Bandwidth”. This pattern stood out to me because the main focus is on improving the learning process itself, not just skill building exercises.

The situation which the authors describe for us is an analogy which says that we as apprentices spend gain our knowledge by “drinking steadily through a straw”, and the fact that “there are seasons in an apprenticeship when one must drink from the fire hose of information”. This spoke to me because the fire hose metaphor is definitely how I feel. While it is important to take your time and learn the necessary development skills to their fullest extent, there are times in which we as apprentices need to open the flood gates of information and learn new skills and technologies as fast as humanly possible.

The reason why this pattern is called “Expand Your Bandwidth” is because that is the solution the authors provide for applying this pattern. They recommend a number of platforms such as a Google blog aggregator, following organizations on Twitter, as well as joining a technical conference whenever possible. I appreciate this advice, because it definitely makes sense to me to utilize the internet as much as possible as a vehicle for exposing us to as much information as possible, allowing us to accelerate our learning.

One important distinction or warning that the authors provide us budding apprentices is to not only know how to improve our volume and velocity of learning but to also know when to turn that off, and begin drinking from the proverbial straw again. While it is integral to be able to learn a vast amount of information efficiently, it is equally important to know when to slow down and focus more deeply on a smaller volume of data, allowing necessary skill development to accelerate as opposed to a broader learning approach.

This pattern definitely made an impression on me, and I will have to start applying that by taking up the authors advice to join a community or forum. Personally, I think I will begin by learning about contemporary industry related statistics provided by popular software development sites like stack overflow, etc.

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

Pattern 7 – Sweep The Floor

I decided to read “Sweep The Floor” for this week’s post. This pattern discusses the idea that even if you feel overwhelmed and unable to contribute to your team, there are still ways that you can contribute. This means that even if you can’t tackle the complicated tasks and project straight out of the gate when you start a position, it is still important to be involved and demonstrate that you can deliver quality work in some way, shape, or form.

This is great advice especially for us newly graduating apprentices. When I was at both of my internships, I did plenty of “floor sweeping”. This was anything from writing up documentation, drawing out flow patterns, taking notes during meetings, and writing unit tests. One of the biggest benefits to sweeping the floor when you start a new job, is that you are learning the business logic first, then tackling the complex coding challenges that come with the job as well. For example, this way if your company is working on software that has five different user types and dozens of permissions that require different user types for access, you can learn how this works through writing the documentation and use this knowledge in future tasks for the software. You might even find yourself leading a discussion on the business logic even though you might not have contributed notably on a technical level. From my experience, it made me feel like I was one of the team. I could contribute to conversations, and offer ideas for possible solutions even though I wasn’t entirely comfortable with how to write the code for the particular task.

I also don’t think that this is limited to newly graduating professionals, or even in the world of software development. This line of thinking can be applied to all facets of business, as there are always menial tasks that no one wants to do but offer a learning avenue with a lower risk. When I worked in a hardware store/rental center, I had to learn the software we used as well as how all of our equipment worked. I cleaned the equipment and wrote up requests for customers as a way to learn more about diagnosing machines and giving customers better feedback when they called. Sweeping the floor is good advice both literally and figuratively.

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.

Craft Over Art

This blog is about another pattern from the Apprenticeship Patterns book. This pattern is about Craft Over Art. Choosing whether to add that extra feature that you think will impress your colleagues rather than focusing on what the customer specifies or want. This problem would occur to you more than you would think. We are not just programmers we are also artists. Creating beautiful, unique and creative applications are all within us, but if you are working for someone else, you might have to forgo of your creativity.

The book suggests focussing on delivering value to the customer rather than advancing your own self-interest. As a craftsman you are primarily building things in terms of the specification, working under someone and not indulging in your creative self. As craftsmen, we work for the customer. You need to do your best work in ways that place the interests of your customers over your desire to display your own skills or pad your resume. The book even says “If your desire to do beautiful work forces you out of professional software development and away from building useful things for real people, then you have left the craft.”  They said that the things we build for customers can be beautiful but it must be useful. That part of the process of maturation is developing the ability to sacrifice beauty in favor of utility when it becomes necessary.

I am split on this pattern. I kind of agree that we should do what the customer has asked us and enhance its quality, making it a software that can do almost everything that they needed. But, I also think that you can still practice art even if you are working for a company. You can inquire on your customer and see if they like what you are trying to do, but then again I see how this can conflict with the other software developers. Since you are not the only person that would be working on a project when you become an apprentice, there are things that others would think is not necessary to the software, so there definitely going to be things that gonna have to be agreed upon.

 

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

“Breakable Toys”

The third and final of “patterns grow out of an exposure to new information or a desire to acquire new knowledge: whether you’re practicing a new technique, building something in an effort to learn a new platform, or studying the source code of an innovative new open source tool.”. As this pattern “Breakable Toys”, is also important as 2 last blog posts. “Success is built on failure”, this is a well-known quote. But in the environment that sometimes does not allow for failure, we need to be both or leave some room for failure. We need to learn keep trying after failure, to be the kind of people who can succeed when faced with difficult problems.

Budget for failure by designing are good for side project. We want to have failure in the manage area, they need safe place to make mistake. When implementing the Breakable Toys pattern, make your systems relevant and useful to your life. This is good for our own personal project. In these project, we allowed to fail, we can try out new ideas and techniques. The person who get effect by these failure is us, not to others. The book suggests that a classic example of the use of this pattern build our own wiki. I think this is good idea, this require a lot of components work together: HTTP, REST, parsing, web design, caching, full-text search, databases … we can learn a lot from it. They need maintaining, so there will have thing to do, plus we could keep adding feature. This is great long-term project.

Failure and things go wrong are always happen in the tech industry. The important part is how to fix it and what did we learn from it. It is good for business to know this and leave some room to fall back in, like a backup system or good security team.

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

Apprenticeship Pattern “The Long Road”

I once watched a video by a self-proclaimed “lifehack guru,” where he talked about what he claimed to be a revolutionary new way to “think stuff done.” I always take ideas like this with a grain of salt, but in this particular video, I thought there was something to the advice he gave.

He said to look at your cluttered desk (or area of your choice) and to imagine it clean. The important part is this: you pause and take some satisfied breaths about how good it feels to have a clean desk. Note you have not done anything yet, but you feel the satisfaction of what it will feel like when you are done. Already, you should find that you have, without meaning to, probably thought of a few steps to achieving it.

That’s a long way of getting around to introduce the pattern, “The Long Road,” but the action that it suggests feels very similar. It suggests to imagine your future ten years from now and further, even the most far fetched version, and use that thought experiment to help plan your future career choices.

The “guru’s” advice was surprisingly helpful for doing something as trivial as cleaning my desk. I keep that advice when I do a lot of tasks now, even years after I have last watched it. However, so far I have only used it for short term and slightly longer term tasks that I need to do. I have not thought about applying it to something as significant as career goals, as the pattern suggests.

The pattern talks about keeping your sights set on the long term. This is something that I have been neglecting. I keep my head down and work hard on what is in front of me, but I don’t often step back to see the big picture. This affects me because when the pressures of school or elsewhere aren’t there, I sometimes don’t know what to do with myself. Without something assigned and a deadline, I can sometimes waste my time because I haven’t set myself goals.

It can be hard to set goals without the long term plan of where you want to take it. Otherwise it seems meaningless. What I liked about the guru’s advice was the pause to meditate on the moment where you accomplished your goals and hold that image. Although that is not mentioned in the pattern, I will use that step as I map out my future.

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