Mark van Venrooij's blog

Devnology codefest: Space Invaders quine

You saved the world

As a participant in Devnology Code Fest Space Invaders I knew immediately what the solution should be.

Some time ago I visited the Hot or Not Software Craftsmanship session by @KevlinHenney. In that session Kevlin introduced me to the principle of a quine and showed some examples. One of the examples was the Qlobe – a quine that shows a globe in the source code that rotates 45 degrees when executed.

So my contribution should be a space invaders quine. Furthermore my ruby skills need some practice so it will be a ruby space invaders quine. This is also a good excuse to finally finish reading Programming Ruby: The Pragmatic Programmers’ Guide. Below you a few possible game states are shown, the full solution can be found at GitHub.

"
#####################################################r
#01     **********                                   #
#02     **********                                   #
#03     **********                                   #
#04     **********                                   #
#05                                                  #
#06                                                  #
#07                                                  #
#08                   i                              #
#09                   i                              #
#XX                   %                              #
###0        1         2         3         4         5#
###12345678901234567890123456789012345678901234567890#
######################################################
"

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

"

#####################################################r

#01 ********** #

#02 ********** #

#03 ********** #

#04 ********** #

#05 #

#06 #

#07 #

#08 i #

#09 i #

#XX % #

###0 1 2 3 4 5#

###12345678901234567890123456789012345678901234567890#

######################################################

"

"
#####################################################r
#01                 *********                        #
#02                 *********                        #
#03                 *********                        #
#04                 **    **                         #
#05                   i                              #
#06                   i                              #
#07                   i                              #
#08                        i                         #
#09                        i                         #
#XX                        %                         #
###0        1         2         3         4         5#
###12345678901234567890123456789012345678901234567890#
######################################################
"

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

"

#####################################################r

#01 ********* #

#02 ********* #

#03 ********* #

#04 ** ** #

#05 i #

#06 i #

#07 i #

#08 i #

#09 i #

#XX % #

###0 1 2 3 4 5#

###12345678901234567890123456789012345678901234567890#

######################################################

"

"
#####################################################r
#01   **********                                     #
#02   **********                                     #
#03   **********                                     #
#04   **********                                     #
#05                                                  #
#06                                                  #
#07                                                  #
#08                                                  #
#09                                                  #
#XX                       %                          #
###0        1         2         3         4         5#
###12345678901234567890123456789012345678901234567890#
######################################################
"

invaders =  SpaceInvaders.new(field)
invaders.next_move
" ____  ____ ___ ___   ___       ___  __ __   ___ ____
 /    |/    |   |   | /  _]     /   \|  |  | /  _]    \
|   __|  o  | _   _ |/  [_     |     |  |  |/  [_|  D  )
|  |  |     |  \_/  |    _]    |  O  |  |  |    _]    /
|  |_ |  _  |   |   |   [_     |     |  :  |   [_|    \
|     |  |  |   |   |     |    |     |\   /|     |  .  \
|___,_|__|__|___|___|_____|     \___/  \_/ |_____|__|\_|


game has been reset for next try
"

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

"

#####################################################r

#01 ********** #

#02 ********** #

#03 ********** #

#04 ********** #

#05 #

#06 #

#07 #

#08 #

#09 #

#XX % #

###0 1 2 3 4 5#

###12345678901234567890123456789012345678901234567890#

######################################################

"

invaders = SpaceInvaders.new(field)

invaders.next_move

" ____ ____ ___ ___ ___ ___ __ __ ___ ____

/ |/ | | | / _] / \| | | / _] \

| __| o | _ _ |/ [_ | | | |/ [_| D )

| | | | \_/ | _] | O | | | _] /

| |_ | _ | | | [_ | | : | [_| \

| | | | | | | | |\ /| | . \

|___,_|__|__|___|___|_____| \___/ \_/ |_____|__|\_|

game has been reset for next try

"

pragmatic-programmer

Adjust design to get green bar

10 December 2011 / Mark van Venrooij / 1 Comment

pragmatic programmer

A while ago I read the pragmatic programmer. In the book are many tips listed. In the back of the book there is an tear-out card with all the tips collected. As I’m working on different locations all the time I rarely look at the card. The tips however seem very useful to me. Therefore I created a small Google App engine application that sends me a random tip every day. TDD-ing my way through the requirements I now get a tip every day. During the development I ran into one little problem with stubbing my randomizer method.

For the unit-tests testing sending the mail I needed to stub the random result to give a certain result. So I could check that the rest was working. For mocking & stubbing I use Mockito. The normal way you stub a method in a class is to create a mock version of the class and use the when-then pattern as documented over here. The problem I had was however that the method getting the random result was part of the class under test. This resulted in the test failing because sending the mail was never being executed as it was a Mock. Please see the code below:

public class TipRepository {
    ...
    public String randomTip() {
        return tips[getRandomNumber()];
    }

    private int getRandomNumber() {
        return (int)Math.round(Math.random() * (tips.length-1));
    }
}

1

2

3

4

5

6

7

8

9

10

public class TipRepository {

...

public String randomTip() {

return tips[getRandomNumber()];

}

private int getRandomNumber() {

return (int)Math.round(Math.random() * (tips.length-1));

}

And the test looked like this:

public RepositoryTest() {
    @Test
    public void randomTestShouldReturnExpectedTip() {
        TipRepository tipRepo = mock(TipRepository.class);
        when(tipRepo.getRandomNumber()).thenReturn(0);
        assertEquals(tipRepo.randomTip(),"sometip")
    }

}

1

2

3

4

5

6

7

8

9

public RepositoryTest() {

@Test

public void randomTestShouldReturnExpectedTip() {

TipRepository tipRepo = mock(TipRepository.class);

when(tipRepo.getRandomNumber()).thenReturn(0);

assertEquals(tipRepo.randomTip(),"sometip")

}

Please note that I use TestNG as testing framework. In TestNG the expected and actual result are reversed if you compare it to JUnit.

So all my tests where failing. In order to get a green bar again I need to adjust my code to be able to test it. After a lot of thought I created an extra class that contains only the randomizer method to pass it into the repository as a dependency.

public class TipRepository {
    private Randomizer randomizer;
    ...

    public TipRepository(Randomizer randomizer) {
        this.randomizer = randomizer;
    }

    public String randomTip() {
        return tips[randomizer.randomNumber(tips.length-1)];
    }
}

1

2

3

4

5

6

7

8

9

10

11

12

public class TipRepository {

private Randomizer randomizer;

...

public TipRepository(Randomizer randomizer) {

this.randomizer = randomizer;

}

public String randomTip() {

return tips[randomizer.randomNumber(tips.length-1)];

}

public class Randomizer() {
     public int getRandomNumber(int maxValue) {
        return (int)Math.round(Math.random() * maxValue);

    }
}

1

2

3

4

5

6

public class Randomizer() {

public int getRandomNumber(int maxValue) {

return (int)Math.round(Math.random() * maxValue);

}

And the test now looks like this:

public RepositoryTest() {

    @Test
    public void randomTestShouldReturnExpectedTip() {
        Randomizer randomizer = mock(Randomizer.class);
        TipRepository repository = new TipRepository(randomizer);
        when(randomizer.getRandomNumber(2)).thenReturn(1);
        assertEquals(repository.randomTip(), "some tip");
    }
}

1

2

3

4

5

6

7

8

9

10

public RepositoryTest() {

@Test

public void randomTestShouldReturnExpectedTip() {

Randomizer randomizer = mock(Randomizer.class);

TipRepository repository = new TipRepository(randomizer);

when(randomizer.getRandomNumber(2)).thenReturn(1);

assertEquals(repository.randomTip(), "some tip");

}

Of course you can argue that getting a random number is not the responsibility of the Repository and that therefore the new design is better. But in the old situation the random number was coming from the Java API. Therefore it was not a responsibility of the Repository either. I’m happy to have a green bar now, but I don’t like changing the code just for the tests to be passing. Please let me know your thoughts in the comments or via Twitter.

Review: The clean coder

10 October 2011 / Mark van Venrooij / 0 Comments

The clean coder

Last week I finished reading The clean coder written by @unclebobmartin. The book’s subtitle: “A Code of Conduct for Professional Programmers”, summarizes the book quite good.

Throughout the book @unclebobmartin tells about his own experiences during his career. Also he illustrates the points he wants to make with excellent example discussions between (project) managers and developers. These example stories are quite entertaining and make the book easy to read.

The first few chapters discuss how a professional developer behaves as a person. It’s all about managing expectations & making sure that you’re in the right state to do your job. After that some practices that improve the quality of your work are introduced. Examples practices are TDD, testing in general and estimation. The last chapters discuss how to behave in a team. A embarrassing paragraph in these chapters is called “Degrees of failure”. In that part @unclebobmartin basically explains how the education system fails to educate software developers.

It’s a nice book to read and has nice suggestions how software developers can improve their work and become craftsmen. However many of these tips are not new to me. They can be found in the enormous blob of blogs about agile / lean / etc. development. Only the estimation chapter gave me some real new information. Because the book is written in @unclebobmartin’s distinctive style I still recommend the book. The pragmatic programmer is a different league though.

How I learned about customer value

7 October 2011 / Mark van Venrooij / 0 Comments

Confidence by h.koppdelaney, on Flickr

The article do users change their settings remembered me about a program I wrote as a student. I created a tool to categorize my expenses similar like Yunoo a.k.a. Afas Personal. This was however a local application. Why the heck should you share your finances on the internet? But let me go back to my memory. At the time I started building the application I did a little bit of research if there was this kind of software available. Sure there was, I just thought it didn’t look nice so I build it myself using Swing (I do know better now ;-)). I was just a little bit overconfident and suffered from the NIH syndrome.

Basically the application enabled me to download a file with all my transactions, load it to my program and categorize my expenses. I even created some rule engine like thing to categorize recurring transactions automatically. All these transaction are then shown in a JTable structure. The program also included budgeting, reports, some graphs, etc.

Back then I didn’t like how the information was shown in the transaction overview. There was too much information shown and it was shown in the same order as was used by the import file. So I made this table structure configurable. The configuration made it possible to hide columns and rearrange them. Also I created some ways to edit the configuration and store it into an XML file (it was the common fashion back then). This change resulted in al lot of work. I needed to create file handling & XML parsing code. But the main issue was that I used the UI as the (view) model.

Every transaction had an id which was shown in a column. It was quite easy to create the logic to find the transactions id as long as the id column was shown. If it wasn’t shown however it was not possible to match a row in the table to any transaction stored in the database. This was especially difficult because every other column may or may not be visible. So I created a view model that made is possible to find the transaction corresponding to the data shown in the UI. Because I wasn’t used to writing automated test (as everyone knows a real programmer doesn’t test), it took quite a while to create the model, hook it up to the interface and make it configurable. I think I spent at least some 40-60 hours on this feature. When I was done I was pretty proud as a developer that I was able to create this feature.

As the only customer of the product I wasn’t happy though. Yes the new feature improved my application a bit. But it didn’t help to support the main goal of the application: getting more insight in my expenses. The day I realized this I was pretty disappointed. If I look back now I learned a lot about customer value by making this (classic) mistake. This is also why I keep emphasizing customer value in the Agile/Scrum team I’m part of. By the way I learned a lot more by building this toy project. I still have all the sources of the program & I use it from time to time to experiment with new languages (I have some Scala classes that mimic the original functionality in Java), new practices and new IDE’s. As a software developer I think every other developer should have toy projects to experiment and improve his/her skills and become a craftsman.

Now I’m using an off-the-shelf product to categorize my expenses and make budgets. Sometimes I still have that nagging feeling that I could make a better program than the one I bought. I learned however that if I’m going to build this thing I need to spend a lot of time to have the same capabilities I like in that product and I think I can spend my precious time more effective.

Review: The pragmatic programmer

11 September 2011 / Mark van Venrooij / 2 Comments

The Pragmatic programmer

Finally I had time to read the pragmatic programmer: From journeyman to master. I wish I prioritized differently. The book is written by @PragmaticAndy & @pragdave. This is the second book written by Andy Hunt I’ve read. Read my blog posts about that book. The pragmatic programmer is ranked 2^nd in “Top Ten Most Influential Programming Books of All Time”. I don’t know if that is true but I think every software developer should read this book.

First of all the book is easy to read. It sometimes reads like a novel. In the book many topics are covered. From using a VCS via architectural principles to practical advice how to handle problem solving. Throughout the book you find 70 tips. These tips are also collected in a quick reference guide in the back of the book. Some of the tips:

3. Provide options, Don’t make lame excuses
Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.

8. Invest regularly in your knowledge portfolio
Make learning a habit.

20. Keep your knowledge in plain text
Plain text won’t become obsolte. It helps leverage your work and simplifies debugging and testing.

55. Don’t think outside the box – Find the box
When faced with an impossible problem, identify the real constraints. Ask yourself: “Does it have to be done this way? Does it have to be done at all?”

In the book there are many analogies used. These make the advice easier to remember. I won’t forget broken windows theory and Cooking stone soup. The book is pretty old. It has been published in 1999, but for me it is still accurate. Yes there are some things when you notice that the book is that old. CORBA is named and EJB is marked as a good example for configuration over integration. As a developer working in the Java world using Spring, Hibernate and all the other frameworks. I agree that configuration has his place. However many times I’ve been in configuration hell. For me this mantra has evolved to be convention over configuration, mostly popularized by Ruby on Rails.

Overall the book overall covers many practices and tips that are still useful. Some of them you know already, some might be new. I gained the most insight in the plain text chapter. The combination of plain text with version control is fantastic. I would strongly recommend reading this book.