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.

The post Your First Language appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

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.

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.

The post Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

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.

The post Four Practical Steps to Execute a Software Quality Strategy appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

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.

The post Design Patterns: The Builder Pattern appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.