Author Archives: Jason Knowles

Use The Source

So we’re finishing up our second sprint regarding the AMPATH project, and honestly I feel like we’re making some progress. Personally, I’ve been concentrating on Angular fundamentals to help me understand the “big picture” a bit more. I realize I need to implement strategies to hold onto and straighten my knowledge of these fundamentals. To accomplish these goals, one of the tasks I’ve been doing is applying the “Use The Source” pattern. For instance, I’ve been meticulously going over the AMPATH project code, trying to familiarize myself with every aspect of the app’s process.

The authors describing a successful application of the Use The Source pattern seem to emphasize the importance of specific procedures, such as:

  • Find an open-source project and analyze its structural pattern.
  • Study every aspect of the project, including the code, layout, methods, and history.
  • Try to think of why the original authors implemented processes in the ways that they did.
  • Seek additional resources giving clarification for procedures that seem unclear.
  • Attempt to refactor either parts or the entire project; perhaps in a personal “breakable toy.”
  • Ask for (and/or offer) feedback whenever necessary, with an emphasis on constructional criticism.

These points seem to outline the primary objectives I should concentrate on when “using the source.” I’ve been trying to follow this outline the best I can.

After attempting to analyze the structural pattern of the AMPATH app, I’ve been realizing that it seems to rely heavily on HTTP processes and routing. Having limited knowledge of these topics, I felt I needed to familiarize myself with these processes going forward.

I’ve asked for feedback from the AMPATH development team, who suggested that I should focus on understanding the processes of REST APIs. This helped direct my attention to several quality Angular video tutorials concerning these topics.

Now that I have a better understanding of the workings of the AMPATH app, I’ve been working on a Angular breakable toy of sorts. The idea is to replicate many of the pivotal functionalities of the project. So far my “breakable toy” has HTTP, REST (Representational State Transfer) and CRUD (Create, Read, Update, Delete) capabilities. My ultimate goal is to make it sort of a “lite” version of the AMPATH app that emulates the basic idea of the program, such as submitting and retrieving medical records. I want to compare my implementation to that of the AMPATH development team. Perhaps this can help me better understand why they implemented certain processes in the fashion they did. 

Following these aforementioned procedures are helping me successfully apply this pattern. I recommend that anyone looking to further their progress in any complex open-source project to “Use The Source.”

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

Retreat Into Competence

Retreat Into Competence seems like the ideal apprentice pattern to apply this week. Our capstone team is in the process of discussing ideas for implementing the AMPATH application with offline capabilities. The problem is that I have become keenly aware of how complex this project is for me to even begin to understand. I’ve been noticing that my limited knowledge of Angular is certainly hindering my process. So I started to think to myself, “what can I learn more about that can help me move forward with the AMPATH project?” Then, and I’m not kidding here, I started thinking about this textbook trying to remember the name of the pattern that discussed what I should do when I feel I’m in over my head. I found it, and as the name suggests, I should Retreat Into Competence.

There’s an Angular tutorial by sitepoint that I have done portions of at least a couple of times before. It’s incredibly helpful and seems to cover every important aspect needed to develop applications in Angular. I’ve used it last semester when I first started learning both Angular and Typescript for the first time.  Now I’ve been finding myself going back to it again and again. I feel this is a great way to Retreat Into Competence because it’s something I’ve done before and become at least somewhat familiar with. Right now I’m in the process of going through the tutorial as thoroughly as possible to ensure I understand every piece of code that’s in there. I think I’ve got the CRUD (Create, Read, Update, Delete) part down, which helps boost my confidence a bit as I proceed to tackle the more complex topics. But I’m still Retreating Into Competence, and I know I have some more substantial learning to do before I can say that I’ve successfully finished applying this pattern.

Ultimately, I need to work on better understanding how the AMPATH application communicates back and forth to a remote server.  I had at least a high level understanding of the “Todo app” discussed in the sitepoint tutorial. And when I “retreated into competence” and started to go through the tutorial again in a meticulous fashion, Angular is seeming more clear to me than ever before. I am hoping to finish the sitepoint tutorial section regarding REST (Representational State Transfer) APIs before my next team meeting on Tuesday. Learning more about the workings of REST and mock servers should help provide some clarification regarding how the AMPATH server communication works. Then perhaps as the pattern suggests, I can “launch forward like a stone from a catapult” after momentarily Retreating Into Competence.

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

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.

Angular Project: “Clean-up” and Good Style Practices

My teammate and I are currently finishing up our Angular “Blackjack” project. The program seems to be running fine and doing everything we originally intended it to do. Now comes the important task of “cleaning up” our project. Examples of this are going through our program, rectifying any remaining bugs, and fixing any potential style inefficiencies within our code.

In order for us to clean up our code as efficiently as possible, I feel it is a good idea to brush up on ideal Angular style practices. By doing so, we can ensure our code is up to par with Angular standards. There is an excellent Angular Style Guide article that I strongly feel can help us in our “clean-up” task.

The guide is an article directly from the official Angular website. It gives examples of various “Angular style” coding techniques. Each is followed by a suggestion of whether the developer should (“do”) follow the example style, “consider” the style, or abandon the style (“don’t”) for a better alternative. I will outline certain styles mentioned in this article. I will also offer my personal takeaways on these style suggestions, as well as the Angular article in general.

General Naming Guidelines

Angular asserts the best practice is to name project files in a way that specifically identifies the function of that file. Each should follow the standard pattern of ‘feature.type.extension’. For example, our Blackjack project has a “player hand” component. Based on the suggestions of this article, we felt it was most appropriate to name each of the “player hands” companion files as ‘player-hand.component.ts’, ‘player-hand.component.html’, etc. Furthermore, the article suggests that each component, service, etc, along with their companion files, should all be located within the “src” folder in their own sub-directory. When going through the process of “cleaning up” our code, we will ensure that each section (service, component, etc) are in the folders they ought to be, in accordance with Angular standards.

Single Responsibility Principle (SRP)

The Angular article suggests that a project should follow the SRP whenever possible. Based on everything I’ve learned in the Computer Science program so far, it is always best to have a function to do just “one thing” as clearly and efficient as possible. Thus I feel it should follow that in Angular, we should only have the code for one component per file, one service per file, and so on. Though it is technically possible to write code for multiple types within one file, according to this article, it is bad practice to do so. When looking over our code, we will ensure we have all of our components, services, etc within their own appropriately named files.

The Angular article goes in great detail of good Angular style practices, and which ones to avoid. We have referenced this article a great deal during our project, thus I feel it directly relates to this course. I am sure this article will be useful during my professional career when working on additional Angular projects.

 

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