Record What You Learn

15 April 2018 @ 09:23pm by erik
Tags:


Problem

Those who do not learn from history are doomed to repeat it.

Solution

The solution the text offers is to keep a record of your journey in a journal, wiki, or blog. Having a chronological record of the lessons you’ve learned can help those you mentors you, it can also be a vital resource to draw upon when needed. Those who follow this pattern sooner or later realize they’re trying to solve a tough problem and use what you’ve recorded to solve the problem. Try to avoid writing lessons down and then losing the information and forgetting to keep it updated. An example the text offers is someone who keeps a wiki for his private thoughts and the other for sharing with the world.

I think the pattern is good advice, I like the idea of keeping a blog to update as I start my career as an apprentice. I liked the idea of having two wikis, one designed for personal use and one to share with others. Having a more personal blog or wiki allows you to be painfully honest with yourself and the progress you’re making. Having something to go back to and refresh yourself has many benefits and can help you in a bind when you might not have anyone to ask. I keep cheat sheets at the current job I work and having that information saved makes my job much easier. Another good suggestion from the text is creating a textfile or page on a blog or wiki to save tidbits of information or quotes from software craftsmen, in the example the book noted, someone uploaded all their saved quotes online for others to learn from. I like how this patterns ties into the Breakable Toys pattern, you can start projects that you can share online, creating a chronological history of every step of the project, where things went wrong, and what you did to fix it. I think during my time as an apprentice I will continue to blog what I learn and keep the lessons I learn from mentors and colleagues. I like the idea of Sharing What You Learn, a lot of the lessons I’ve learned have come from other people who’ve taken the time to create blogs posts or YouTube videos describing the steps they took.

0 comments

Four Practical Steps to Execute a Software Quality Strategy

4 December 2017 @ 10:26pm by erik
Tags:


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.

0 comments

Design Patterns: The Builder Pattern

4 December 2017 @ 10:21pm by erik
Tags:


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.

BankAccount.java

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)
            .withOwner("Marge")
            .atBranch("Springfield")
            .openingBalance(100)
            .atRate(2.5)
            .build();
BankAccount anotherAccount = new BankAccount.Builder(4567L)
            .withOwner("Homer")
            .atBranch("Springfield")
            .openingBalance(100)
            .atRate(2.5)
            .build();

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.

0 comments