Author Archives: Jason Knowles

Sprint 1 Retrospective: Getting up and Running

We’ve just completed our first sprint in the Software Development Capstone course. I will be posting similar blogs biweekly for the next few months. The purpose is to periodically check in and reflect upon the overall progress of our team.

Many of us, such as myself, learned for the first time what a sprint refers to in the context of software development. The whole concept of “sprints” and scrum is brand new to me. In very simple terms, scrum is a framework where teams produce material in small “bursts” (i.e. sprints) where the intention is to increase overall productivity. I must say that I am enjoying the team based environment, especially because it seems to closely emulate what we should expect when we graduate and transition to our soon-to-be careers.

This first sprint was designed to help us become more familiar with working in development teams, setting up our environment for future sprints, and the whole concept of sprints in general. We are working with AMPATH this semester, contributing to a healthcare consortium software project that is primarily used in the Kenya area. We hope to provide the AMPATH application with feasible offline accessibility, where data can be submitted online once an internet connection is reestablished. Offline access would be a great asset to those using the software, as Kenya internet access is reportedly unreliable at best.

It is our team’s personal goal to contribute as much as possible, assisting our class in accomplishing everything the AMPATH team expects from us. So we spent this sprint getting everything up and running that will be required of us to contribute to the AMPATH project:

  • Slack – Our team has been (and will continue to be) using this platform for communication among ourselves and other teams. Personally I think Slack has certainly contributed to our team’s productivity. While our in-person collaboration is great, I feel it is equally important to have a means of communicating asynchronously; Slack provides this capability for us. We also use Slack to complete our stand-ups, which help periodically determine what each of us currently working on.
  • Trello – We are currently using Trello as a scrum board to manage tasks during each sprint. We’ve spent this first sprint becoming familiar with Trello, such as how to create and assign one or more of us to a “task card.”  For this sprint, we’ve typically either told each other personally or via slack if we completed a Trello card. I feel managing tasks could have been easier if we used Trello more productively; this is something we should work on in future sprints.
  • JIRA – This is a project management web app (similar to Trello) that the AMPATH development team uses. We’ve spent some time reading tutorials regarding the JIRA framework, because we will likely be using this soon.
  • Angular, etc – It was imperative to ensure we all had the required Angular stuff up and running. We’ve also read tutorials to familiarize ourselves with the framework, and how tests work for it. The AMPATH app is written in angular, so in turn we needed the node package manager installed in order to run the angular framework. For more experienced users looking for flexibility, I would recommend Node installation via the Node Version Manager (nvm) app. This is a great tool that allows the on-the-fly switching to different versions of node, something that is much less feasible with the proprietary version from the node.js website.
  • WebStorm – This IDE provides the TypeScript and Angular support we need when working on the AMPATH project. I recommend this to anyone who is a student looking for a good Angular/TypeScript IDE (it’s free for students, otherwise the price is a bit too pricey in my opinion).
  • GitHub – We ensured all of us as a team had GitHub accounts because this is the version control system that AMPATH uses. We then created and forked the project repository to our personal team’s organization. From here we all helped each other successfully clone and install the application to our personal computers.

I feel we collaborated well as a team; overall I would say we’ve had a successful first sprint. My only concern is that we had to change some code in the module files to get the application to run properly. We are not sure if this is a problem in our end, or an issue that AMPATH is experiencing as well. We are in the process of communicating with the AMPATH development team to figure out the best resolution.

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

Reading List

I’ve noticed something about myself that has occurred especially during the past few months. I mean I’ve always enjoyed reading anything that captured my interest, but lately, I have developed a colossal appreciation of reading. This appreciation seems to go leaps and bounds ahead of any time in my life that I can remember. I think this has a lot to do with the amount of time I have spent learning and reading about computer science topics, subjects that I am absolutely fascinated with. I am certain the apprenticeship pattern textbook has only further solidified my interest in reading, software development, and computer science as a whole.

That being said, I have chosen to reflect upon the Reading List pattern this week. The idea concentrates on the importance of keeping and maintaining a “books of interest” record. As someone aspiring to enter the job field of Software Development within a few short months, I feel it is my responsibility to acquire as much knowledge on relative topics that will help further my career. And as much as I like watching informative tutorial videos from time to time, as the context of this pattern implies, sometimes there is no replacing the content of what certain books have to offer. Even many of the people offering such tutorial videos online seem to consistently reference material from one book or another.

I’ve begun personally applying the Reading List pattern after completing the step of signing up for a goodreads account. It’s a powerful, easy to use web app that allows users to keep track of books. Goodreads seems to possess all the capabilities that anyone developing a quality reading list should expect; I think the authors describing this pattern would certainly approve. I was able categorize books I’ve read, books I’m currently reading, and books I’d like to read. After adding a variety of computer science books to my reading list, I noticed the app started to recommend popular books relative to the subject. I will continue applying the Reading List pattern by updating my goodreads book log every time I’ve finished reading a book or started a new book. And from book recommendations from goodreads, mentors, colleagues, and other comparable sources, I will also queue books I would like to read sometime in the future.

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

Concrete Skills

The Concrete Skills apprenticeship pattern seems to give the assertion that entry level software developers should maintain a quality understanding of the “basics.” Employers can and should have the expectation that new hires can contribute in some substantial way, right from the gate. I feel this patterns’ context stresses the importance of understanding the fundamentals of programming, essential algorithms, and computer science in general. One of my main responsibilities as an undergraduate is to learn and maintain such fundamentals that any reputable employer should expect from any entry level software developer.

The authors describing this pattern do a great job of highlighting some pivotal “concrete skills” one should strive for as a newcomer to the field. For instance, it is suggested that gathering a solid understanding of one’s first programming language is a primary skill we should strive for. I realize that my first language (Java) is just the beginning of a myriad of languages I expect to be exposed to in the near future. I ought to practice Java to the point where I can roughly draft code for any rudimentary procedure at any given moment. My potential employers need to know that I grasp the basics of vital data structures and design patterns. I should strive for a solid understanding of these fundamentals to a point where I can just start shelling out code whenever it is asked of me. When I can do this to a point of solid understanding and self-confidence, this will be the day that I can say that I have done so by successfully applying the Concrete Skills pattern.

What I found most interesting about this pattern was the implication of the importance of learning how to play “buzzword bingo” to get your foot in the door as an entry level Software Developer. I must say I found this amusing in the sense that I pictured someone at an interview saying something like “…yeah I’m familiar with APIs, ASP, IDEs, J2EE, NPM, SQL, UML…” and all sorts of other alphabet soup. But at the same time, the term “buzzword bingo” was especially enlightening for me. Any quality resume/CV I’ve ever encountered for inspiration had similar keywords sprinkled throughout them. Thus I have set a personal task for myself to become familiar with such popular buzzwords to a point where I can at least explain them. Proficiency would be great, but I feel I can begin to apply the concrete skills pattern by at least researching more about these recurring buzzword terms. I feel this, along with striving and maintaining a solid understanding of my “first language” Java, are great ways to apply the concrete skills pattern.

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

The White Belt

I’ve been in the Computer Science (CS) program at WSU for quite some time now. Though I’ve learned a lot in the process, I realize that graduating in May will be just the beginning of my career. I still have a lifetime responsibility of learning ahead of me, and I must find a way to effectively approach this everlasting task.

The textbook references The White Belt as what I feel to be a highly effective pattern to apply when learning new things. The idea is to keep an open mind and bring a proverbial “clean slate” whenever approaching something new. I’m going to use the example of learning new programming languages to further explain this pattern.

We focus a lot on the Java programming language in our school’s CS program. Because of this, I feel I have a proficient understanding of that particular language. We have branched out into other programming languages as well, such as C and TypeScript. But since Java was my first programming language I’ve become proficient in, I always find myself comparing the new languages I learn to Java while I am learning them. The White Belt pattern has changed the way I feel I should be approaching new material. I shouldn’t be making assumptions of new technologies based on my knowledge of other topics, no matter how comparable they may seem. I should be applying The White Belt pattern when approaching new ideas.

For instance, consider a scenario where an algorithm that has been coded in the most effective way known possible for the Java programming language. I should not assume that the code will be just as efficient in a different programming language just because some of the terminology may be similar. I should approach learning a new programming language in the same fashion that I learned Java. A good start would be to consult the community who are well-versed in the skill I am seeking to learn. I ought to start at the very beginning, practicing beginner projects before attempting the more advanced ones. As simple as a “Hello World” exercise may seem based on prior coding experience, The White Belt suggests I should “set this previous knowledge aside.” Based on reading the context of this pattern, I will always try to approach new topics with an open mind and a “clean slate.” This applies not only to the example of learning new programming languages, but also any new situation I may find myself during my professional career.

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

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

We’ve been assigned to read Chapter 1 of the textbook with the same name as this blog post, but I couldn’t stop there. I read the whole book during this past week or so, and I did this for two primary reasons. First, I thought the book was very interesting and couldn’t bring myself to stop at Chapter 1. I could not find myself disagreeing with anything the authors asserted within this chapter. Second, I’ll be writing blog posts reflecting on various “apprenticeship patterns” discussed in the textbook throughout the next several weeks. I thought it would be particularly useful to have a general idea of each pattern. This makes it easier for me to pick and choose which “currently relative” patterns would be most useful to practice and reflect upon in future blog entries. That being said, this blog entry in particular will focus solely on the first chapter.

So what is an apprenticeship pattern? Dave and Ade, the primary authors of this textbook, describe it as something that we as entry level software developers can use to further our careers. The aim these authors seem to have is not on how to develop software itself, but rather how, as apprentices, to approach software development as a whole. Rather than explicitly teach us how to write software, I feel that the authors’ ultimate goal is to teach newcomers in the field how to accumulate and apply knowledge as effectively as possible.

What I found most insightful regarding this chapter is the comparison of modern software craftsmanship with the traditional model of the idea. I feel that the authors of this textbook are suggesting that the modern software craftsman ought to embrace this traditional overview of craftsmanship. In medieval times, the primary responsibility of an apprentice was to further their knowledge in their craft. This cannot be done by mastering just one aspect of the field. It seems to me that an apprentice should strive for at least an abstract understanding of every aspect of their trade, no matter how remote it may seem.

Attributes such as cross training whenever possible can help improve production and advancement of the apprentice. I feel this also helps advance the field of Software Development as a whole. I find this particularly thought provoking because sometimes today’s expectations of society may pressure us to focus solely on whatever narrow tasks we are expected to perform in a given job position. If we follow that path, we may become experts in that particular area, but what happens if that position becomes obsolete?

The goals of this textbook’s authors seem to focus on preparing us for the inevitable constant change and advancement of Software Development and Computer Science as a whole. Since our field is constantly changing, we must remain flexible with the ability to consistently adapt to this inevitable advancement and change. I feel this can only be done by expanding the knowledge of our craft. We should accept that our primary job position today may be obsolete tomorrow, and focus on expanding our knowledge in computer science as a whole. It seems to me that this textbooks’ authors assert this should be our primary goal. I believe the apprenticeship patterns discussed in the upcoming chapters give us that insight on how to flexibly advance in such a technologically advanced career as Software Development. I look forward to blogging about many of these patterns in the near future!

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

CS-448 Software Development Capstone

Hello everyone; this is my first blog post for the CS-448 Software Development Capstone course.

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

Code Review vs Unit Testing

With this semester coming to a close, I thought it would be appropriate to write about our most recent topic discussed (code review) and compare it with something widely covered during this course: unit testing. I found a great Codacy blog to aide my exploration of the similarities, differences and importance of these two topics.

Codacy explains that code review generally means to manually inspect the code, whereas unit testing is implemented to automatically detect bugs within the code. It seems to me that unit testing is focused solely on finding malfunctions (bugs) in a product, whereas code review considers the overall style, readability and functionality of that code as well.

Rather than asserting that one is superior to the other, Codacy suggests that both code reviews and unit testing ought to be done in all software projects. I feel software developers can produce efficient and supreme quality products when appropriately combining the two techniques. Thus I have to agree with Codacy regarding the implication that unit testing should not replace code reviewing, and vice versa.

The blog author gives a great example of why unit testing alone should not replace code review. It seems that there was an actual situation that occurred where a vast series of unit tests were run to ensure the integrity of a very important governmental system. But when the program was scheduled to go live, it failed to run. It turns out that the system was scheduled to launch on a Sunday, but the unit testing team only worked weekdays, thus unit tests were not run on the weekends. For one reason or another, it seems that code reviews had failed to be conducted for this governmental system.

My takeaway from the scenario described above is the fact that code reviews should have certainly have taken place. This is because I feel that code reviewers, through proper analysis, could have identified there was a flaw within the code that made the system inoperable during Sundays. Examples such as this solidify my belief that human analysis should be coupled with computerized testing. In a sense, code reviews “double check” the work of automated unit tests.

On the other hand, I also agree with Codacy in the sense that code review should not replace unit testing either. In regard to automated unit testing, computers generally have the capacity of identifying bugs at a speed that far exceeds the capability of the average person. Trying to manually replicate the work of automated tests in this sense just seems inefficient to me.

I found Codacy’s blog regarding “Code Review vs Unit Testing” to be engaging and informative. Based on what I’ve learned from the real world examples given by Codacy, I feel that code reviews and unit testing are equally important. My goal is to continue to learn and improve my expertise in code review and unit testing. I am confident that I will need both of these skills during my professional career.

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