Sprint Retrospective 1

14 February 2018 @ 11:07pm by erik

During the first sprint, I learned more about the node modules and dependencies needed for the AMPATH application to load properly, mainly the angular2-ladda module. I learned more about angular and angular testing, including framworks such as Jasmine and Karma. I learned about test debugging right from the browser. I learned how to create a Github organization, a useful tool for any team of developers.

Our team worked well together, I believe we all have the skills needed to take on the task of adding offline functionality for the AMPATH providers. I created the Github organization for our team, and made sure that my team members were on the same page. We organized how the team should manage pull requests and for now will be approving requests when we meet. I think we will have more communication when we actually start writing code and making changes.

The first week, I forked the ng2-amrs repository from the class organization to our team organization. All team members were added so they were able to fork their own copies to work on. From then, my team members and I worked on installing the needed dependencies for the application to compile. From the start everyone had compilation errors because some files were missing or in a different directory. While browsing the Slack channel we discovered that a different team member(Matt) posted a fix to the issue we were all having. The issue was with the angular2-ladda module, the errors showed that we had some missing files. Our team followed the instructions on what changes needed to be made and successfully fixed the errors. Once we had the application compiling properly, we set up our browsers with the help of the AMPATH team’s youtube video showing us how to add the CORS plugin. Once logged in we realized there was no data being shown as the AMPATH team is still working on getting dummy patient data on the test severs.


Your First Language

11 February 2018 @ 06:37pm by erik

Problem: You feel your job depends on you delivering a solution written in a specific programming language and of the same standard of quality as your teammates. Alternatively, obtaining a job in the first place depends on your proficiency in a specific programming language.

Solution: The text suggests picking a language and becoming fluent in it, as it will be the main language you will be using for the next few years to solve problems. It’s a difficult choice to make, especially when looking for jobs that may been looking for specific skills and languages. It’s “important to carefully weigh the options, as it is the foundation upon which your early career will be built.” One good way to gain experience and become fluent in a language is to actually have a real problem to solve, and to “seek out opportunities to create feedback.” Becoming fluent in a language allows you to start working more on test-driven development, allowing you to check your assumptions and aiding development of new languages.

This pattern has good advice, and it’s not the first time I’ve heard someone suggest working on one language and perfecting it instead of trying to learn multiple languages at the same time and expect to be fluent in each one. An interesting tip from the text was building a toy application in the language you’re trying to pursue a job with, one that your prospective employer would be able to access. Good learning experiences come from solving real problems, school gives you a good foundation to build upon and learn from the problems you solve in your professional career. Working in the field and running into real problems, the ability to work with other people and learn from them is a big part of gaining skill. I think Java would be a practical choice to become fluent in as it’s a high demand language that receives a lot of bad press but it running on 3 billion devices. The book also mentioned the community behind these languages and all the resources you have at your disposal. They suggest taking advantage of the support network you have and attending local meetings related to that language.


Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

23 January 2018 @ 09:11pm by erik

The Introduction to the textbook sets the goals for the book and the targeted audience.

“One of our goals for this book is to inspire the people who love to create software to stay focused on their craft.”

“This book is written entirely for you—not for your boss, not for your team leader, not for your professor.”

What Is Software Craftsmanship?
The book considers software craftsmanship as some overlapping values, listed here are those values with my thoughts on them.

  • Growth Mindset, the belief that you can always improve and find faster, easier ways to do things if you’re prepared to work. Failure should be seen as an incentive to change your approach. “Effort is what makes you smart or talented” – Carol Dweck. I think the growth mindset it very important to quality and success and avoiding burn-out.
  • Constantly adapting to constructive criticism and learning to improve areas where you are lacking. This idea is essential to ensuring quality work and keeping up-to-date on the best practices.
  • A desire to be pragmatic rather than dogmatic. This important trade-off allows you to get things done and avoid spending too much time making things “perfect”. This ties in well with YAGNI.
  • A belief that information is better shared than hoarded. Everyone benefits from shared knowledge which is the basis for the idea of Open Source projects. This allows a greater population to improve shared code and learn how things work.
  • Ability and willingness to experiment and not worry about failing, because you are able to learn from the experience.
  • Taking control of and responsibility for our destinies rather than waiting for someone else to give us the answer. I think this is basically saying to take initiative, or try to think differently to solve a problem.
  • Focusing on individuals rather than groups. This book is meant to help you as an individual improve your skills.
  • A commitment to inclusiveness. I think this is a good rule in everyday life but works with being a craftsman.
  • We are skill-centric rather than process-centric. It’s more important to be highly skilled than using the “right” process. I think it boils down to it pays to have the knowledge to use your skills in any situation, not having to rely on a template of tools.
  • Situated Learning, the idea of learning a skill around those using those skills. Working your first job as a software developer would be a good example of this.

Based on the introduction, this text appears to have very useful information for someone who wants to improve the quality of their work and what they contribute. The book includes good lessons that can apply to any aspect of life. It stresses the idea of improving skills by being open to learning from others, learn from mistakes, and never stop improving.


Software Development Capstone Introduction

15 January 2018 @ 07:47pm by erik

Welcome to my blog, beginning January 16th, my blog will be focusing on the book, Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by David H. Hoover and Adewale Oshineye.


Four Practical Steps to Execute a Software Quality Strategy

4 December 2017 @ 10:26pm by erik

In this blog post, Pratik Kothari talks about software quality and gives us some tips on how to develop quality code. Software quality has been more important recently, as companies slowly learn asking for a realistic time-frame allows bugs and quality assurance issues to be caught early, saving time wasted on debugging later on.

What Does Software Quality Mean?

Organizations have different quality standards, for the author, “software quality means that your code is meeting the bare minimum business expectations and do not have serious usability issues.” He goes on to say that it’s next to impossible to implement software without any defects, and that having defects in the system does not indicate poor quality software.

“If the software is meeting business expectations at the end without compromising the user’s ability to perform their tasks, the quality of the software is acceptable.”

Who Owns Software Quality?

The author says that software quality should always be at the center of the software development process and should be owned by a team, not one person. Testers take the brunt of identifying quality issues but it’s everyone job to ensure your product is clean and free of major bugs.

When to Define a Quality Strategy

The strategy for maintaining quality should be one of the initial steps of a product. Everyone should be on the same page on what quality standards are to be met and what is considered done.

Quality Strategy

Having a quality strategy is key to ensure everyone knows the expectations of quality and done-ness. The quality strategy “should be owned and defined by the Project Manager along with Architects, the Testing Lead, and the key team members. Ideally, it should cover the below quality-related objectives.”

  • How to identify personas.
  • How to write and store test cases.
  • Unit testing plan.
  • Regression testing plan.
  • Automation plan.
  • Performance testing plan.
  • Code Quality Review.
  • How to measure quality.

Step 1: Communication

Giving team members a clear picture of what is expected, and who is accountable for what. Like giving developers a heads up if they need to add test development to a project, allowing them to give accurate estimates.

Step 2: Training

Ensuring that gaps in skills are filled with time to learn skills or new members who know the skills. It pays to keep team members up to date on the latest skills.

Step 3: Infrastructure

It’s important to “utilize the greatest and latest infrastructures for quality strategy.”

Step 4: Continuous Improvement

The team regularly reviews what is, and what is not, working well.

I chose this blog post because it had good information on ensuring quality standards in code. The content of the article had good tips for ensuring success and communication is possible in a team. I learned the importance of communication, training, good infrastructure, and continuous improvements. I will use this information in the future when working on a team of people, and strive to do my part in creating quality code.


Design Patterns: The Builder Pattern

4 December 2017 @ 10:21pm by erik

In this blog post, Riaan Nel goes over an example of the Builder Pattern, a creational pattern used to create and configure objects. The following example is from Effective Java by Joshua Bloch.

The Problem

In this example, we are part of a Java team working on software for a bank. We need a way to represent banks accounts.


public class BankAccount {
    private long accountNumber;
    private String owner;
    private String branch;
    private double balance;
    private double interestRate;

    public BankAccount(long accountNumber, 
                       String owner,
                       String branch,
                       double balance,
                       double interestRate) 
        this.accountNumber = accountNumber;
        this.owner = owner;
        this.branch = branch;
        this.balance = balance;
        this.interestRate = interestRate;
    //Getters and setters omitted for brevity.

We run into two problems in the about code:

  • Too many constructor arguments
  • Incorrect object state

The Pattern

The builder pattern “allows us to write readable, understandable code to set up complex objects. It is often implemented with a fluent interface, which you may have seen in tools like Apache Camel or Hamcrest.” The builder will

public class BankAccount {
    public static class Builder {
        private long accountNumber; 
        private String owner;
        private String branch;
        private double balance;
        private double interestRate;

        public Builder(long accountNumber) {
            this.accountNumber = accountNumber;

        public Builder withOwner(String owner){
            this.owner = owner;
            return this; 

        public Builder atBranch(String branch){
            this.branch = branch;
            return this;

        public Builder openingBalance(double balance){
            this.balance = balance;
            return this;

        public Builder atRate(double interestRate){
            this.interestRate = interestRate;
            return this;

        public BankAccount build(){
            BankAccount account = new BankAccount(); 
            account.accountNumber = this.accountNumber;
            account.owner = this.owner;
            account.branch = this.branch;
            account.balance = this.balance;
            account.interestRate = this.interestRate;
            return account;
    //Fields omitted for brevity.
    private BankAccount() {
        //Constructor is now private.
    //Getters and setters omitted for brevity.

We can create new account with the following code:

BankAccount account = new BankAccount.Builder(1234L)
BankAccount anotherAccount = new BankAccount.Builder(4567L)

This makes code clearer and more verbose. Using the Builder pattern is a good solution if you find yourself having to add more and more parameters to the constructor resulting in error-prone and hard to read code. I chose this resource because I wanted to learn more about design patterns, and I did not know much about this pattern. I learned how the Builder pattern can help simplify code that may get too complex and hard to read. The content of the post is good quality and the example used was simple and easy to understand, making learning how the Builder pattern works easier. I plan to use this information when in my professional career whenever the Builder pattern would be the best solution.


Java: The Factory Method Pattern

27 November 2017 @ 11:12pm by erik

In this blog post, Justin Albano talks about the Factory Method Pattern and gives us an example.

The Textbook Definition

According to the Gang of Four book that defined the technique, the intent of the Factory Method pattern is as follows:

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Using the Factory Method involves creating two sets of interfaces: “(1) the product interface that constitutes the object to be created and (2) the creator interface that constitutes the object that will instantiate the product.” The UML diagram for the Factory Methods is below:

The author explains the UML diagram as the following:

Using the general pattern, we build a Creator interface, which includes one or more Factory Methods, as well as any number of other methods. This interface may also be an abstract class with defined methods or even a default implementation of the Factory Method that returns a default instance of Product. From this interface, a set of ConcreteCreator classes are created that return desired ConcreteProduct instances that implement the Product interface.

An Example in Java

  • We create an encryption mechanism that allows the user to supply a string of text and a file name, which is then encrypted and written to disk. Using the Factory Method allows us to use multiple encryption algorithms.
  • We create implementations for two encryption algorithms: (1) SHA-256 and (2) SHA-512. “For both implementations, we will use the Apache Commons encryption implementations (org.apache.commons.codec.digest.DigestUtils).”
  • In the end you should be able to do something like this:

    PersistedFile file =
       new PersistedFile("/foo/bar/text.txt", "Hello, world!",
    new Sha256Encryptor());

    View complete example here

    Colloquial Definition

    A method whose sole responsibility is to abstract the creation process of an object and return that object.

    I chose this resource because I am interested to learn new implementations of popular design patterns such as the Factory Method. This resource gave a detailed explanation along with other patterns that can be good alternatives to the Factory Method pattern like the Template Method pattern and Strategy Pattern. I believe the content of the article is very detailed and informative. The example they used is very interesting and I’m going to implement the code myself to test it out. I plan to use this and many other design patterns in the future. I learned more about the Factory Pattern method and when it is appropriate to use it.


    Code Quality: Fighting Primitive Obsession Code Smells

    27 November 2017 @ 08:47pm by erik

    In this blog post, Anna Makowska talks about primitive obsessions code smells and what you can do to fix them. The author chose to focus on primitive bbession code smell because some smells are harder for developers to detect intuitively.

    “Primitive data types are basic built-in building blocks of a language. They’re usually typed as int, string, or constants. As creating such fields is much easier than making a whole new class, this leads to abuse. Therefore, this makes this smell one of the most common ones.”


    • Using primitive data types to represent domain ideas. For example, using an integer to represent an amount of money or a string for a phone number.
    • Using variables or constants for coding information. An often-encountered case is using constants for referring to users roles or credentials (like const USER_ADMIN = 1).
    • Using strings as field names in data arrays.


    • Code becomes less flexible because of use of primitives instead of objects.
    • Primitive data types are much harder to control. As a result, we may get variables that aren’t valid (supported by the type) or meaningful.
    • Primitives are often related to dedicated business logic. Therefore, leaving this logic unseparated may violate the Single Responsibility Principle and the Open/Closed Principle.
    • When data type logic is not separated in a dedicated class, adding a new type or behavior makes the basic class grow and get unwieldy.
    • By using primitives, the developer loses the benefits that come with object-oriented design, like data typing by class name or type hinting.

    Replace Data Value With Object

    • Instead of a set of primitive values, the programmer has full-fledged classes with all the benefits that object-oriented programming has to offer (typing data by class name, type hinting, etc.).
    • There is no need to worry about data validation, as only expected values can be set.
    • When relationship logic extends, it will be placed in one place dedicated to it.

    I chose this resource because it had plenty of good information on the primitive obsession code smell, when it’s going to lead to problems and how to fix that. I learned two more fixes, Replace Type Code With Subclasses, State, or Strategy (patterns) and Replace Array With Object for when “values of a coded type aim to control the behavior of the program.” I felt the content to be quality content from a author who has experience with spotting and fixing code smells. I will use this information in the future, by keeping an eye out for primitive obsession code smells.


    What Is Project Valhalla?

    20 November 2017 @ 11:24pm by erik

    In this blog post, Justin Albano explains what Project Valhalla is.

    “Project Valhalla is an OpenJDK project started in 2014 and headed by Brian Goetz with the purpose of introducing value-based optimizations to Java Development Kit (JDK) 10 or a future Java release. The project is primarily focused on allowing developers to create and utilize value types, or non-reference values that act as though they are primitives. In the words of Goetz: Codes like a class, works like an int.”

    “Project Valhalla has a very specific purpose: To cease the requirement that Java developers choose between performance and abstraction.”

    What Are Value Types?

    “Value types are groups of data whose immediate value is stored in memory, rather than a reference (or pointer) to the data.” Doing this means saving memory otherwise taken up by overhead data. “Taking data and directly placing its value into memory (rather than a reference) is called flattening and its benefits are more acutely demonstrated with arrays.” “In an array of value types, the values are directly placed into the array and are guaranteed to be in contiguous memory (which increases locality and, consequently, the chance of cache hits). This idea is illustrated in the figure below:

    The benefits to using Value Types are listed by the author:

    • Reduced memory usage: There is no need for additional memory used to store object metadata.
    • Reduced indirection: Because objects are stored as reference types in Java, each time you access it, it first must be dereferenced, causing additional instructions to be executed.
    • Increased locality Using flattened value objects removes indirection, increasing likelihood values are adjacently stored in memory.

    One of the major differences between reference types and value types:

    “The identity of a reference type is intrinsically bound to the object while the identity of a value type is bound to its current state”

    The reason I picked this resource is because I did not know about Project Valhalla and it seemed like an interesting article to learn about. It’s not quite ready to be released in JDK but it’s a useful addition to Java that increasing performance and saves memory. I feel the content of the post was interesting and informative. I learned the benefits of using Value Types versus using pointers and the improvements that have been made to Java. Value Types may soon be released in an upcoming JDK and I would like to know how to utilize them when saving memory is crucial.

    Additional resource: Minimal Value Types article


    Creating Your Code Review Checklist

    20 November 2017 @ 09:12pm by erik

    In this blog post, Erik Dietrich goes over creating a code review checklist. If you were to Google “Code review checklist”, the author lists results that may show up:

    • Does every method have an XML comment?
    • Do classes have a copyright header?
    • Do fields, methods, and types follow our standard naming convention?
    • Do methods have too many parameters?
    • Are you checking validity of method parameters?
    • Does the code have “magic” values instead of named constants?

    He then goes on to list two problems with going through a sometimes lengthy checklist:

    • You can’t keep 100+ items in your head as you look at every method or clause in a code base, so you’re going to have to read the code over and over, looking for different things.
    • None of the checks I listed above actually require human intervention. They can all be handled via static analysis.

    His suggestion for stream-lining the process of going through a big checklist is to automate the easy stuff. “Get static analysis tools that developers can install in their IDEs and run prior to delivering code, which will flag violations as errors or warnings. Get static analysis tools that run on the build machine and fail the build for violations.”

    Code Review for the Important Stuff

    The author lists an example checklist for a code author:

    • Does my code compile without errors and run without exceptions in happy path conditions?
    • Have I checked this code to see if it triggers compiler or static analysis warnings?
    • Have I covered this code with appropriate tests, and are those tests currently green?
    • Have I run our performance/load/smoke tests to make sure nothing I’ve introduced is a performance killer?
    • Have I run our suite of security tests/checks to make sure I’m not opening vulnerabilities?

    The author lists an example checklist for a code reviewer

    • Does this code read like prose?
    • Do the methods do what the name of the method claims that they’ll do? Same for classes?
    • Can I get an understanding of the desired behavior just by doing quick scans through unit and acceptance tests?
    • Does the understanding of the desired behavior match the requirements/stories for this work?
    • Is this code introducing any new dependencies between classes/components/modules and, if so, is it necessary to do that?
    • Is this code idiomatic, taking full advantage of the language, frameworks, and tools that we use?
    • Is anything here a re-implementation of existing functionality the developer may not be aware of?

    I chose this resource because it had very useful information on code review, which ties into QA. I feel the content of the article is very informational and useful to my future career. It is a good starting point for making sure you have thoroughly checked the quality of your code and automated tests are only going to increase in use, so it makes sense to automate what you can.