Showing posts with label software. Show all posts
Showing posts with label software. Show all posts

Monday, July 11, 2011

A usefull Postscript Trick

In this blog post I will share a Postscript trick which I use a lot.

Postscript is best known as a page description language. It is a very powerful language, in fact, Postscript is Turing-complete. The language is stack-oriented so you will see a lot of stack operators like dup, exch and roll. These operators can be used to perform all necessary (and possible) stack operations. But it can be very tasking for a programmer to use them correctly.

For example, the following code draws a rectangle perpendicular to the coordinate axis with its lower left vertex at (x,y) and a width of w and height of h. In the comments an impression of the stack is given.

/rectangle {     % stack: h w x y
  moveto         % stack: h w
  dup            % stack: h w w
  3 -1 roll      % stack: w h w
  0 rlineto      % stack: w h
  0 exch rlineto % stack: w
  neg 0 rlineto  % stack:
  closepath      % stack:
  stroke         % stack:
} def
You can easily get lost in all these stack manipulations. Make one mistake and it is likely that your expectations are not met.

Luckily you can solve this problem within postscript. If you look at the above code again, you may notice that a definition is made. The symbol "/rectangle" is associated with the code-block by the def operation. One can associated other values with this operator. You can use it to simplify the above code.

/rectangle {      % stack: h w x y
  /y exch def     % stack: h w x
  /x exch def     % stack: h w
  /w exch def     % stack: h
  /h exch def     % stack: 
  x y moveto      % stack: 
  w 0 rlineto     % stack:
  0 h rlineto     % stack:
  w neg 0 rlineto % stack:
  closepath       % stack:
  stroke          % stack:
} def
There is one problem with this solution. It defines, and possibly overrides, associations for the symbols "/x", "/y", "/w" and "/h". This method leaks its variable in to the context in which it is called. Again, postscript can solve this problem. Initially the associations are made in the dictionary userdict. By using an other dictionary and throwing the dictionary away after it's service, we avoid polluting the userdict. (In the following code examples I will omit the impression of the stack.)
/rectangle {
  4 dict begin
    /y exch def
    /x exch def
    /w exch def
    /h exch def
    x y moveto 
    w 0 rlineto
    0 h rlineto
    w neg 0 rlineto
    closepath
    stroke
  end
} def
Here we first define a dictionary for four keys with 4 dict. Start using it with begin. When we are done we discard it with end. This nicely allows the usage a variable with out polluting the userdict. Because I used this trick so often I polished it up a little. I left out the "body" of this method so you can concentrate an the scaffolding.

/rectangle {
  [/y /x /w /h] dup length 0 add dict begin {exch def} forall
     ...
  end
} def
That one-liner signals the variable names used in this method, creates a dictionary and initialises it with values from the stack. The 0 add is there to easily add local variable. I the body of the method is using a local variable add one the the integer to ensure the size of the dictionary.

This wraps up this Postscript type. I explained how you can use variable in methods without polluting the userdict.

Tuesday, June 21, 2011

Graphviz: dot

In this blog post I will discuss the programming language dot.

Dot is a graph description language. I will dive right in and show you an example. The following code:

graph example {
    a [label="root"]
    b [shape="box"]
    c [color="red"]
 
    a -- b -- d
    a -- c -- e
    c -- f [label="indirect"]
}
produces this output:

This clearly shows the capabilities of dot. For more information about dot, and it companion programs visit the Graphviz website.

Monday, May 2, 2011

Learning Language Categories

In this blog post I will advocate to learn new language categories instead of new languages.

Every once in a while you find a post on a forum addressing the question which new language should one learn. Notable examples can be found by googling. Here is a sample:

In my opinion, growing as a developer is not about specific languages. If this was the case then why does nobody suggest C# if one knows Java or vice versa? Seldom is such an advice given. But if it is all about learning languages then this advice should surface as often as any other advice.

I think that language categories are more important then languages. One reason to learn a new language is to broaden your horizon. By seeing new solution to old problems your problem solving toolbox grows. Even if it is not possible to apply the language directly it often is possible to adopt the idea. By going beyond a language category barrier, the novelty and creativity with which problems can be solved grow enormously.

So the next time the question "Which language should I learn next" is asked, go ahead and advice to learn a new language category.

Saturday, April 30, 2011

Having an opinion

In this blog post I will explain why having an opinion is important.

At my first job as a software developer there was a legendary senior developer. Hey called himself a technocrati. He had a vast amount of experience, a no-nonsense way of communicating and openness towards the inexperienced. although he could program circles around me while being blindfolded and with one arm tied behind his back, he always took the time to explain things to me if I had a question.

Although I learned a lot from him, he gave me one pivotal piece of advice: "Have an opinion".

Like all sayings of masters, one should reflect on the meaning.

I am certain that having a opinion, means have a well founded opinion. Having an opinion without a clear reason is void of meaning. It could come around with the sleightest amount of suggestion.

If the advice "Have an opinion" actually means "Have a well founded opinion" the meaning becomes clear to me. Study relentlessly. So I did, and I am still doing that.

An other interpretation of the advice I gleaned from the behavior of "the master" is this. "Have an opinion, and voice it".

It is nice to have a well founded opinion, but it is a waste if you hold it back. By giving your opinion on a certain topic, you are effectively spreading knowledge. For me this was enticing. It was not uncommon to have to following thoughts after a meeting with the master. Why does someone have this "outrageous" opinion? He seems a knowledgeable person, maybe his ideas have merit. Let's just look into them just to be sure.

I would like to conclude this blog post with my narrated version of his advice. Have a well founded opinion, and voice it.

Saturday, January 15, 2011

Parametrized JUnit tests

In this post I will examine parametrized JUnit tests.

With the introduction of Junit 4, a lot has changed for testing Java software with Junit. One of the more esoteric additions are parametrized tests. It allows a developer to run a great deal of test which differ only in a set of parameters. Without further ado I will show you a parametrized test.

@RunWith(Parameterized.class)
public class FactorizationTest
{
    private int number;

    private List expectedResult;

    public FactorizationTest(int number, Integer[] result)
    {
        this.number = number;
        this.expectedResult = Arrays.asList(result);
    }

    @Test
    public void factorize()
    {
        assertEquals(expectedResult, Factorization.factor(number));
    }

    @Parameters
    public static Collection<Object[]> data()  
    {   
        List<Object[]> data = new ArrayList<Object[]>();
        data.add(new Object[] { 2, new Integer[] { 2 } });
        data.add(new Object[] { 8, new Integer[] { 2, 2, 2 } });
        data.add(new Object[] { 9, new Integer[] { 3, 3 } });
        data.add(new Object[] { 72, new Integer[] { 2, 2, 2, 3, 3 } });   
        return data;
    }
} 

Lets focus on line 17 of the method annotated with @Test. This method asserts that the expectedResult is returned by the static method Factorization.factor(int) which is called with parameter number. Both expectedResult and number are private fields of the class FactorizationTest. The fields are assigned in the constructor.

By annotating the class with the @RunWith(Parameterized.class) we are telling Junit to run this class with the Parameterized Runner. By implementing a Runner you can specify how to run the tests.

For the Parameterized this means the following. (The following section is paraphrased. See https://github.com/KentBeck/junit for the details.)

  1. Get an Collection of Object-arrays.
  2. Repeat for every Object-array in the collection:
    1. Construct an instance of FactorizationTest passing as parameters the various elements in the Object-array.
    2. Run all methods annotated with @Test.

The collection mentioned in step 1 is obtained by calling a method annotated with @Parameters. So in this example the following facts will be asserted.

numberfactors
22
82, 2, 2
93, 3
722, 2, 2, 3, 3

In this blog post I made clear how to use parameterized test in the Junit test framework.

Wednesday, August 18, 2010

Maven Versions Plugin

I was going to write about the maven versions plugin. But an other blogger beat me to the punch.
So without restating what can be found there, I will point out what John Ferguson Smart has to say on the maven versions plugin

Saturday, August 14, 2010

Spreading Knowledge

In this post I will outline various forms of spreading knowledge.

I signed the manifesto for software craftsmanship and I take my responsibilities serious. Not only should you maintain a high standard for your self, you should help others in becoming software craftsman.
One way in doing this is by spreading knowledge.

There are various ways one can share and spread knowledge. Any form of communication with the intent of explanation is a form of spreading knowledge. Examples of communication forms abound. Let's group these forms according to the number of senders and receivers.

We will distinguish the following numbers: one and many. Below I have created a table listing the various combinations of senders and receivers.


#Senders#RecieversExamples
11One-on-one tutoring
1manyPresentation or blog
many1Open outcry or a forum
manymanyOpen discussion

In seeing these summary one can check off a list of participation in various forms of communication. For example I now realise that I do not often participate in a forums.
So I will challenge myself in actively seeking out opportunities to contribute to forums.

Saturday, July 24, 2010

Introduction to Software Development - Part 2

In this blog I will outline the second instalment of the introduction to software development I had with a friend of mine.

In a previous post I told the story of introducing software development to a friend. In this second run, we took on a little project to hone our developing skills.

We looked into Mancala. It is a game in which stones get sown around the board. The exercise was meant to develop a feel for architecture.

We had a lot of discussion about responsibilities. Which object should be responsible for a certain task? I think that the question of responsibility is a very good to get your bearing while developing an application.

In the subsequent meeting we will finish this little project.

Fresh Install

In this blog I will outline the pieces of software I would install if I would be doing a fresh install of a computer. It is mainly written for a personal reference.

First of all, the operating system. I started using Ubuntu about three years ago and I really like it. So the primary software will the operating system, and it will be Ubuntu.

Wednesday, June 2, 2010

Introduction to Software Development

In this blog I will outline how I introduced a friend to the art and craft of software development.

A friend of mine got interested in software development, but was not quit sure how to start. Because I have a strong opinion what constitutes "good" software development skills, I offered to guide him in his explorations in software development. This blog summarizes the first day of guidance.

In my opinion a software developer is not tied down to a single language. But an aspiring developer has to start somewhere. The language choice was made on two grounds: my own familiarity with languages and it's popularity in the field. We settled for Java.

After downloading the appropriate software development kit and setting up the PATH variable we could really start. I created the conical "Hello World!"-example using only a rudimentary text editor and the command line. We build upon the example by introducing the following concepts

  • Introduction of a package
  • Separation of source- and class-files
  • Introduction of the classpath
  • Objects

After this bare-boned example we set out to install an integrated development environment. I loaded the die in favor of Eclipse. After downloading and installing Eclipse I challenged my friend to reproduce the command line example. By emphasizing steps which are easer with the help of the IDE, my friend quickly reproduced the afore mentioned example. The following step was the introduction of test driven development. I showed my friend how a test can be used to guide the development of a new feature. Afterwards I explained him the virtues of test with respect to refactoring. The example was extended by writing test and constantly refactoring, thereby introducing the following concepts.

  • Inheritance
  • Method overloading
  • Interfaces
  • Abstract classes

The next step was to introduce version control. My friend could easily motivate the need for some form of version control. In the end we settled for subversion as our version control system. We downloaded a subversion client and extended the PATH variable. I showed him how the command line can be used to version a file, but we quickly installed a Subclipse. Along the way we created a google code project which now hosts are first steps. Guided by tests and committing our progress we enhanced the example with

  • Commit often, Commit Early
  • Command line arguments
  • Alternate output streams
  • Mocking

In the end I showed my friend coding katas. The main goal was to introduce a means to hone his programming skills without my presence. The secondary goal was the introduction of maven as build to. We agreed to do an other session. As a homework assignment my friend would do a kata a day, or more if he likes to. I pointed out "Head First Java" as a good book to learn Java.

This wraps up the summary of the software introduction I gave to a friend.