Statically Typed

because Hindley-Milner rocks

Ideas for Coding Challenges

At work I’m splitting my time between two groups: my old group which develops software in the wild-west fashion and another group using a very process heavy waterfall model.  Most developers I know hate the waterfall and in general, I’ve never seen it implemented in a way that makes sense.  Within this second group, it makes sense.  The defect rate has to be astoundingly low (1 in 100,000 lines of C++ code) which necessitates the kind of oversight and process they’ve set up.  On the flip side, none of the software developers are writing code nor have they written code in the past 2 months.

I’ve proposed a code dojo, i.e. a weekly software challenge.  The benefits are two part.  First, we get to see how everyone else thinks and where they are in their proficiency.  Second, we get to learn new tricks and stretch our coding muscles.  For the first challenge I’ve thought of a very basic test, one that utilizes a text book string finding algorithm combined with a little regular expression magic:

Given a text file, parse the randomly generated lines under the following two conditions:

  • For each line yield only a single string containing the numbers such that “A+1ekd9345kj” translates to 19345
  • Convert named numbers between zero and nine into their numerical representation as long as no number separates them.  Hence, “(9a3?ni&n e4” translates to 9394 but “(9a3?ni7n e4” becomes 9374.

Turns out, though, that randomly generated lines don’t make for many of the second condition.  I used a rather unscientific approach, I bodged a quick little Java script (I’ll turn it into Scala tomorrow):

public void produce(int _number, int _length){
    if( _number < 1){

    System.out.println( make( new Random(), _length, "") );

    produce( _number - 1, _length );

protected String make(Random _rand, int _size, String _in){
    if( _size < 1){
        return _in;

    return make( _rand, _size - 1, _in + (char)(_rand.nextInt(94) + 32) );

which produced the following output:

&g-eXuyy}HiWw76FQ{*_fSIp\kcKlXb)S$wWs^) BwvH#Z-"R\
+LbB#?K!KW&ny(CuDh:lm*uK#+c!@-[MgJtxG&'Tm}Na s;ou(
-Xg8ez*sfut|]:)o5[(#&yiJP XJnuiV%;p9 KCu#QO!vzc53h
!-s>`H-F7Mu0h`SiP#$y6b.0xvqnwjK-#;%"gAu {YUlc`CjS0
; wmV"h\Bi|ap!:K$UxA7/.Lq)&ZR"5FETtb)!xJBv,TX]>WJA
4<@-ZvS[tx qPS&W?r,P$?eV${n+w&{q:/nP##i1V]OK#3Mm1&
6Q)(O@+\QkY c2_7'&3OS:^EGzMVB:!Kej[WK8!]t;h1F&XZAU
pynZ[nO#s]!snW$c|bwDeO4.S`|Ro[ b.wFIRL}i[][0K}+Q@e

Not very scientific, I know, but it does prove the point.  I’ll have to come up with something more interesting to overcome this limitation.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


This entry was posted on March 9, 2010 by in C++, Java, Scala.
%d bloggers like this: