Saturday, December 9, 2017

Points earned per kata in CodeWars

How many points is each kata worth?







See your points earned per challenge here: https://www.codewars.com/users/<put your username here>/site-events



Ref:
1. https://airtable.com/embed/shrDt7USqZ7GStRb0/tbly10FthXIRqbd7L/viwJf0lpHrvPCKNfb

Count number of set bits in a 32-bit int




using System; public class Kata { public static int CountBits(int n) { int count = 0; int mask = 1; for(int i = 0; i < 32; i++) { if((mask & n) == mask) count++; mask = mask << 1; } return count; } }

Sunday, October 1, 2017

Solve the right problem

Often bugs will appear and programmers will attempt to solve the symptoms, rather than digging down and finding root causes.

Similarly, a misunderstanding of a single requirement leads to the wrong design - either over-engineered or simply wrong.

I have seen these problems happen countless times, and have committed them myself countless times. Solving the wrong problem is simply a waste of time and effort. Near the end of a project, with an impending deadline, these mistakes can be extremely costly. Everyone is already stressed and trying to go faster than they should. And then when you add in the mistake of solving the wrong problem it can result in missing the deadline.

How can I make sure to solve the right problem? Here's some ways

  • Understand the requirements, even if you aren't working on that specific section of the project
  • Write and read unit tests - this will help you understand the code and design intimiately
  • When a bug comes in, realize that it's probably a symptom. Don't just jump in and throw a band-aid over it.
  • Communicate with teammates. Chances are if you're doing something in isolation, you're probably solving the wrong problem. Talk to others, never assume

Saturday, September 9, 2017

Keep design simple - don't design ahead

Keep the design as simple as possible.

Your current design should only support your current features. 

The problem is when we start looking ahead at all of the features as a whole, and then try to create some grand architecture in order to support all of the features.

You know what WILL happen? The design will be overkill, will be wrong, and it'll be fragile. It may work for feature #1, but once you start on feature #2, the design does not support it all. 

I've seen this happen over and over and over.

Wouldn't it make more sense to do the following?
  1. Design and code feature #1 using the simplest design possible
  2. Add unit tests
  3. Design feature #2 based on the current design. This may require refactoring the existing design to support feature #2. Keep it as simple as possible.
  4. Add unit tests
  5. Rinse and repeat all the way until the end
At the end you have the simplest design possible that currently supports all of the features. Since your code is always backed by unit tests, you can safely refactor. The design has grown exactly as needed. It's a bottom-up design. 
Note: Evolution is a bottom-up design process. 


When you design ahead, you're doing top-down design. And it typically looks like this:
  1.  Look at all features and come up with a design that seems to support all the features
  2. Code feature #1
  3. Code feature #2 - oh, the requirements for this changed. I'll need to refactor the framework a little bit to force it to handle feature #2
  4. Code feature #3 - oh, now that i'm coding this, i realize that the current design won't exactly support this. I'll just tack on this little thing and it'll work.
  5. Rinse and repeat for hundreds of features
At the end you have a top-down design that was changed many times due to bottom-up forces. The result is a kludgey mess that no one can make sense out of.

Since requirements always change, and because you don't know everything about every feature until you really start to work on that feature, there will always be bottom-up forces on the design. If the design has been kept as simple as possible every step of the way, then the bottom-up forces can be absorbed painlessly, and the design can gradually evolve. 





Sunday, August 20, 2017

Reading time calculation

Problem: I want to figure out how much reading i need to do in order to finish a book within a certain number of days

Solution
1. Go here and find out how long it'll take based on your WPM: http://www.readinglength.com


2.  Run this python script and update the parameters
There's two different approaches:

  • Process-oriented: I want to spend X minutes per day on this task 
  • Results-oriented: Regardless of how long i spend on this task, i want to accomplish X per day
In this case the results-oriented approach probably makes more sense. I could spend 30 mins reading a book, but due to distractions I could only read 5 pages. So process-oriented is not a good approach to this since the end result is that I need to have X number of pages completed in Y days.

Ref: run Python online here https://repl.it/languages/python3

Friday, August 11, 2017

Mocking static methods

Problem: How can I mock static methods in unit tests?


Solution
There are two cases:
  1. The static method is in a class that I can change
  2. The static method is in a class that I CANNOT change



Case 1 - Static Method is in a class that I can change


//Code Under Test
public class Foo { public static void Log(string msg) { System.IO.File.WriteAllText("log.txt", msg); } public bool Bar() { Log("Bar was called"); return true; } }

Solution - change method to a delegate, and then set it in the unit test to do nothing

1. Change Log method to a delegate

public class Foo { public static Action<string> Log = (msg) => { System.IO.File.WriteAllText("log.txt", msg); }; public bool Bar() { Log("Bar was called"); return true; } }

2. In the unit test do this
[TestMethod()] public void BarTest() { //Arrange Foo foo = new Foo(); Foo.Log = (msg) => { }; // a function that does nothing bool result = false; //Act result = foo.Bar(); //Assert Assert.IsTrue(result); }


Case 2 - Static Method is in a class that I cannot change

//The Logger class is in some library that I cannot change
    public static class Logger
    {
        public static void Log(string msg)
        {
            System.IO.File.WriteAllText("log.txt", msg);
        }
    }

//Code under test
    public class Foo
    {
        public bool Bar()
        {
            Logger.Log("Bar was called");
            return true;
        }
    }

Solution - wrap call to static method in a virtual method, then mock the wrapper to do nothing

1. Wrap call to static method in a virtual method, change code to call the wrapper

//Code under test
     public class Foo
    {
        public virtual void Log(string msg)
        {
            Logger.Log(msg);
        }
        public bool Bar()
        {
            Log("Bar was called");
            return true;
        }
    }

2. Mock the wrapper so it doesn't do anything
//Note: This is using Moq (https://github.com/Moq/moq4/wiki/Quickstart)

        [TestMethod()]
        public void BarTest()
        {
            //Arrange
            Moq.Mock<Foo> foo = new Moq.Mock<Foo>();
            bool result = false;

            //Act
            result = foo.Object.Bar();

            //Assert
            Assert.IsTrue(result);
        }

//Since Log() is void, and because there are no other virtual methods in the Foo class, i don't need to actually use the Moq Setup() method here.









Saturday, July 15, 2017

Recommended design-level books

I was recently asked which design books i would recommend. So here's design books that I've read and would personally recommend.
  1. Refactoring

Refactoring skills consist of these parts:
  1. Being able to spot code and design "smells". 
  2. Being able to systematically refactor smelly code to a better structure

Refactoring: Improving the Design of Existing Code

I use this site as a reference. When I do code reviews I send links to specific refactoring and code smells. 


2. Design Patterns

This book teaches the SOLID object-oriented design principles + design patterns. 

For example: 
1. The D in SOLID = Dependency-Inversion Principle
2. One design pattern is called the Observer Pattern. One thing this pattern used for is to invert dependencies. 

3. Making existing code unit testable

This book is basically about techniques to make existing code unit testable. The side effect of making code testable is that it has a good, loosely coupled design. 

Working Effectively with Legacy Code

4. Agile Principles, Patterns, and Practices

This book explains everything having to do with Agile. There are parts about the process, but more importantly it explains what we can apply as individual developers. Things like design principles (SOLID), patterns, refactoring, and test-driven development, and much more. 

Agile Principles, Patterns, and Practices in C# (there's a Java version too i think)
There was an error in this gadget