Author Archives: dlivengood

Kindred Spirits

The pattern “Kindred Spirits” in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, by Dave Hoover and Adewale Oshineye, addresses the need for social connections to other software developers. Fostering relationships with kindred spirits will create an environment that promotes curiosity and avoids stagnation. Groups share knowledge which allows members to learn from each other. The pattern warns of groups that will resist change and shun those who present change. Groupthink is also warned of in this pattern.  Conforming to some standards is necessary when participating in a group but that conformity should not discourage growth.

I have never been very good with making new connections. Most, if not all, of my computer science connections have been through school and, with graduation nearing, I will need to find new kindred spirits. “Kindred Spirits” suggests finding groups that meet in person, making this currently unadvisable (Social Distancing) but good to remember for down the road. While maybe not as effective as in person meetings, there are plenty of online groups to check out. The open-source communities seem like a good potential place to start. Also, many in person groups will have ways of communicating remotely so it still may be worth looking into.

“This pattern is simple in principle, and for some people (our extroverted cohorts) it is simple in practice. For others, however, it can be difficult.”

This line makes it clear that the difficulty I find with this pattern is common. My innate aversion to large groups and strangers has caused me to avoid attending events in the past, but it is becoming increasingly apparent that I will need to change that behavior.

While I find groups stressful, I agree with the pattern about the benefits of being part of one. Software development communities are great sources of knowledge and inspiration.

The pattern, “Kindred Spirits,” is one I will need to practice. Since I still have a great deal to learn, I think it will be imperative to find a group that will teach and inspire me. Other software developers will always have new things for me to learn if I seek them out.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

“Use the Source”

“Use the Source” is a pattern from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern focuses on the need for reading code written by other developers. Some good sources of code to examine are open source projects. By examining source code, a programmer can see what their bad habits are and adopt new, better habits. Another benefit from code reading is learning new algorithms to solve different kinds of problems. Expanding one’s collection of code solutions allows a programmer to be flexible and able to solve more problems.

I found this pattern particularly interesting. Since programmers are constantly required to work with other’s code, it is imperative that they learn to read code efficiently with practice. I do not have much experience with this myself and this pattern has made clear how important reviewing other’s code is. Regardless of what career I pursue after graduation, it will be important to read code effectively. I will need to start looking into some open source projects so I can improve my skills. Now I just need to find some projects that I contribute to and am interested in.

“Use the Source” suggests contributing to open source projects for software you already use. This is very helpful advice to me; I use a lot open source software.

  • Atom: text editor
  • Eclipse: IDE
  • Insomnia: REST client
  • GIMP: image editor
  • Several different game system emulators

I briefly examined some of GIMP’s source code. GIMP has a label on issues for newcomers, allowing for quick access to simpler issues.  After reading through some of the code, I realized that it would take a great deal of time to get an idea of the project architecture.

I looked at this issue, (https://gitlab.gnome.org/GNOME/gimp/issues/4128), and thought it seemed simple enough problem to start with. While the problem seemed simple, I could not navigate the repository and locate where the problem may be. GIMP is significantly more complex than any project I have worked on before. Ultimately, I was not able to make any headway on the issue. I was, however, able to read through portions of the code and begin to see some of the structure behind the it. Though I did not find what I was looking for, I did get a basic feel of the code’s flow.

As stated in Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, developers read far more code than they write. With that being the case, “Use the Source” is an excellent way to grow your code reading skills.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 1

Completed tasks

I was worried about how well my team would work together at the start of the sprint. We are all rather quiet and I feared that would impact our project. Even Professor Wurst expressed some concern. While I feel our communication could use improvement, I think we did a fine job completing what we planned to do in this sprint.

We divided the sprint tasks amongst us and mostly worked on our tasks independently. All work that was completed was shared so that others could study and review the tasks they did not work on. While this worked for our first sprint, I am hesitant to repeat this method as I believe it can lead to confusion in the group. For our next sprint, I think we should try and assign tasks to multiple people so we can emphasize that the responsibility for the tasks fall on the entire group.

I feel we did a great job of sharing our work and resources. Most of our decisions are public on gitlab so that it is clear why we did what we did.

My primary focuses this sprint were learning how to set up a mongo database and how create a REST API for it. One thing I think I could improve on is the frequency of my updates. I generally completed a task before making my work public. It may be beneficial to update more often. Something I would like more from my team is feedback. While my work was reviewed, I have not felt like I have received any real criticism, constructive or otherwise.

By the end of this sprint, we had a good skeletal structure of the update module. We implemented test versions of the technologies we would use in our full stack application and completed a small MEAN stack, a full stack app using MongoDB, Express.js, Angular.js, Node.js. With what we completed in this sprint, I believe the coming sprint will be clearer in scope and better planned.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Breakable Toys

For this week I’ll be covering the pattern, Breakable Toys, from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. The breakable toys pattern uses small personal projects to teach new techniques. When in a professional environment, playing and learning with the project is not an option. To keep ourselves learning new skills after college, the best thing to do is to create personal projects that allow us to make mistakes and grow as developers. These projects, or breakable toys, are chosen by us and will likely hold more interest than work projects. By working on these projects, we can learn the workings of a project without the fear of consequences of our mistakes.

This pattern is a bit obvious, but I still think it is worth reminding ourselves of. I sometimes find myself tired of working on a needed project and begin to lose some enthusiasm. A breakable toy is always a fun and educational way to lift my spirits while still progressing my skills. To me, breakable toys are more than just a consequence free environment to develop in, breakable toys renew my enthusiasm in the craft.

When I just started learning programming back in ’08, I felt like a whole new world had opened up. There was so much to see and learn, and I was psyched for what I was to learn. My first breakable toy was a text-based game. It was terrible, messy, and bugged but I learned a great deal in the process and because the project was personal, I could do whatever I pleased without concern. While I have not worked with that project in over a decade, I can still remember some of the lessons I first learned while making that game.

I would highly recommend exercising this apprenticeship pattern. This pattern combines the developer’s interests with a stress-free environment to create a project that is exciting and rewarding. I think of our coding skills like cooking, part science and part art. To grow as a programmer, it is important to remember that we need to push our boundaries and experiment is we are to learn. A breakable toy is the perfect project to practice old skills and develop new ones.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: First Impressions

I found the readings from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye to be enlightening. I have liked the idea of apprenticeships and the varying stages of skill for a long time, but I have not thought of it as something to consider using in my life before. Considering my CS skills as a craft to be honed is fun and energizing. It reminds me of a game. Starting as an apprentice, learning and improving skills. Making your way to journeyman by fostering connections with others and finally becoming a master and contributing to the industry.

I found the section in chapter 2, “Exposing Your Ignorance,” to be particularly useful for me. I frequently find myself in situations where there are one or more areas of a project that I do not know adequately. It is important to remind myself that most people feel this way at times. This section describes that it is better to be transparent with your knowledge, or lack thereof, than to feign competence. Let colleagues know that you are learning what you need to learn to complete your tasks. This is a bit of a challenge for me. “The need to appear competent is ingrained into people of most industrialized societies.”(Hoover & Oshineye, 2009) Thankfully, this section has reminded me that while I have a lot to learn, it is okay if I am willing to learn.

Another section I read into was chapter 3’s “Sustainable Motivations.” This section is about holding on to motivation through the good and the bad. I empathize with Hoover in “Dave’s low pain threshold.” I too have difficulty with working jobs that I have no passion for. This is what lead me to computer science in the first place. I quite liked this line from Hoover, “While many programmers could probably find higher-paying jobs in the short term, the money that follows from doing what you love will pay off handsomely in the long run.”(Hoover & Oshineye, 2009)

The last area I focused on was chapter 5, “Perpetual Learning.” This chapter’s introduction is about how you must continuously learn new skills or improve old ones to be an accomplished developer. The first section, “Expanding Your Bandwidth,” is about expanding your knowledge through widely available resources. The book recommends following software blogs and “software luminaries.” With the internet, there are countless communities for developers to share knowledge. This section does warn not to constantly use this pattern. Developers should switch between research mode and development mode.

These readings have helped me re-frame the way I view my future career in a more interesting way. I am sure that the rest of the book will contain similarly useful information and I look forward to reading more of it.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Principles of the Agile Manifesto

For my CS capstone’s setup task 5, I have decided to write about my thoughts on the Principles of the Agile Manifesto linked to in the values section of the about page for LibreFoodPantry. Like the name suggests, the Agile Manifesto keeps you on your toes. Developers must be ready and able to respond to any necessary changes that may arise. The manifesto also requires regular communication. I really like how the principles of the manifesto promote living, evolving projects that adapt to situations as needed. I can see how following these principles will greatly assist in project development and achieving all the project goals. I look forward to adopting these principles and experiencing a project that abides by them.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

An(other) Introduction

With the semester starting, my blogs are back. CS 448, the software development capstone, requires regular posts. As such, I will be writing posts about my sprints and about readings from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye.

I’m looking forward to this course and I think I’ll get a lot out of it. This will be my first time working on a project that is not purely academic.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Good Code Reviewing

For my final post for CS 443, I have decided to write about the code review process. I found a blog series on code review by Dr. Michaela Greiler, “The Ultimate Code Review Blog Post Series.” For this post, I will focus on the sixth entry, “A Code Review Checklist – Focus on the Important Issues,” which gives a very thorough checklist of issues to look for when reviewing code. The checklist includes many categories of issues: implementation, logic errors and bugs, error handling and logging, usability and accessibility, testing and testability, dependencies, security and data privacy, performance, readability, and experts opinion. Some of the items on the list include: following S.O.L.I.D. principles, proper testing, and is the code understandable and clean. While reading through the list I recognized a lot of topics that were raised in class and other CS classes. After reading through this article, I feel I have a better understanding of what to look for in code reviews. Before, I did not really know what to check for during the code review activity in class.

In the end, I highly recommend to others to give the entire series by Dr. Michaela Greiler a read through. If not, then maybe just a look through this checklist post. I know I have bookmarked this series and will likely come back to it for future reference.

Articles Referenced:
https://www.michaelagreiler.com/code-review-blog-post-series/
https://www.michaelagreiler.com/code-review-checklist/

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Final Presentation Eve

With CS 343’s final presentation tomorrow, this will be the last post for this project. (Unless I choose to keep playing around with it later) The work on this project has really helped me learn HTML, CSS, and TS.

The newest feature I added to my Pokedex SPA was having the background colors linked to the selected pokemon’s typing.

This took a bit a time, figuring out how to dynamically link the HTML background color to the TS pokemon data. I eventually found the use of angular’s [ngStyle] to be very useful. This method injects a JSON object with CSS properties defined in it. With it, I simply used a method in the TS to grab the pokemon’s typing and return a created JSON object with the CSS property ‘background’ with either a solid color for single typing or a gradient for dual typing.

This project was a lot of fun and I’ve learned a lot. I am tentatively looking forward to tomorrow’s presentations.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

CMMI and TMMI

After CS-443’s class this week, I decided to further investigate CMMI, Capability Maturity Model Integration, process model. I found testbytes’ article, “What is CMMI? (Capability Maturity Model Integration),” to be illuminating. This article gives an overview of CMMI and why it is used in software development.

At the end of the article is a link to another article by testbytes that caught my attention, “What is TMMI (Test Maturity Model Integration) in Software Testing?” TMMI is essentially CMMI with a focus on testing. While the two are similar, the focus of TMMI makes the implementation of CMMI on software testing smoother. TMMI has the same 5 stages of CMMI with some differences.

Level 1: Initial

  • No test processes in place
  • Failing to meet deadlines

Level 2: Managed

  • Tests are planned and monitored
  • Set test designs

Level 3: Defined

  • All projects are tested from early stages onward
  • Test reviews

Level 4: Measured

  • Properly defined test strategies set in place from beginning of development process
  • Projects tested at every stage to ensure bugless code

Level 5: Optimization

  • Testing practices are structured
  • All processes and outcomes are measured

TMMI is an interesting model that optimizes the testing process and while it is similar to CMMI, I’d still recommend a quick read through this of this article to others.

Articles Referenced:

https://www.testbytes.net/blog/what-is-cmmi/https://www.testbytes.net/blog/test-maturity-model-integration/

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.