A New Language: Where To Start?

When you learn a new speaking language (English, French, Spanish, Hebrew, Afrikaans….) you generally find your course or program is broken down into scenarios. For example, mostly all books, audio or videos will have the topics: Greetings, At The Airport, Public Transport, At The Hospital, Hotel, Restaurant and so on. Essentially, everything you need to “get going”. Of course, a lot is assumed, but the assumptions cover 80% of the market picking up a new language. Is it different with programming?

I think not. What we don’t always have is a “program” of topics to cover that can be referenced- or at least, not one readily packaged. There are many reasons for that being the case, but this post is not about that. So what are the topics….?

For me, that is, i find going back to good ol’ One-Oh-One basics of data structures a really useful way to learn the ins and outs of a language. This is not a new idea by any stretch of the imagination. But take a list like this, and tackle the structures one by one in your new language. Pretty soon, you get to figure the language out in the detail you need to get on with the job.

Of course, the bonus is that you’re going to need a variation of one of those implementations somewhere in some form or another (even if your framework provides native implementations). But building data structures from the ground up teach you all the essential scenarios: How to define a class, inheritance capabilities (if applicable), methods, signatures, variables… And provided you are (should be) familiar with the details of the requirement, you can free your mind to focus on the language, and not a new problem at the same time.


Classical, Functional or Prototypal?

I have updated the maths playground on this site as part of an ongoing adoption and learning of new languages and in particular, programming approaches. The language itself is not really the issue when you’re tackling a task. In fact, learning a ‘programming language’ itself (the syntax that is) is a non-issue. What you do come up against is, is a mindset.

Taking the “classical” languages like C, C++, C# and Java as examples, the way you code in each is roughly the same. Different semantics, but a lot of variable commonality. (Of course, you can get frameworks, like the Symbian SDK, which obsfucate things enough for you to appear as another language). Then you take something like Ruby, and the way you think _has_ to change, or you’re just going to hit your head against the proverbial. And then still, something quite different like Javascript (in it’s more modern form).

Having been schooled in more classical approaches (C, C++), the jump to functional programming was an interesting curve. And now, another shift to prototypal programming has been as interesting. Still some concepts make me ponder though. Nonetheless, i’ve documented the differences, in the form of code, between the pseudo-classical and prototypal approaches in using Javascript.

Any pointers welcome, thanks 🙂


Optimizing And Readability

Optimizing code is generally an expensive process (read: time-consuming) and there are established ways of getting to the bottom of “what to optimize”. Thankfully, profilers are available to help with a lot of the guesswork, so it’s generally a good idea to make sure you work with one *most of the time*. Moving along, it was high time for me to look at some Ruby profiling.

The documentation for ruby-prof is pretty neat and the library itself is quick to get up and running with. And so we start. For my initial problem, I wrote a goal-seek algorithm for accurately estimating gross earnings, given a target nett earning using a tax table- as opposed to just using a base tax-rate. Anyhow, my first stab algorithm (a simple linear search) included the lines:

def seek_annual_gross(m_nett, base_perc)
  sample_gross = m_nett * base_perc
  paye =
  p_nett = sample_gross - paye.monthly_tax
  margin = MARGIN*m_nett
  if((p_nett-margin < m_nett) && (p_nett+margin > m_nett))
    return paye.annual_gross.round_to2.to_f
  elsif(p_nett-margin > m_nett)
    return seek_annual_gross(m_nett, (base_perc - (margin)))
  elsif(p_nett+margin < m_nett)
    return seek_annual_gross(m_nett, (base_perc + (margin)))

The profiler showed up what i kinda suspected- always a good sign. Essentially, my incremental margin for the next step was too small (fixed) and thus, getting closer to the solution was taking too long- and endangered the stack 🙂 What i needed was a better guess at how much to increment.

% cumulative self self total
time seconds seconds calls ms/call ms/call name
22.58 0.28 0.28 177 1.58 3.22 Integer#times
16.13 0.48 0.20 171 1.17 259.18 NettGoalSeek#seek_annual_gross
6.45 0.56 0.08 179 0.45 0.50 Float#round_to2

Some minor adjustments to the routine, including an adjusted guess:

increment = MARGIN*(p_nett - m_nett)/margin

and modifying the appropriate calls

if((p_nett-margin < m_nett) && (p_nett+margin > m_nett))
  return paye.annual_gross.round_to2.to_f
elsif(p_nett-margin > m_nett)
  return seek_annual_gross(m_nett, (base_perc + increment))
elsif(p_nett+margin < m_nett)
  return seek_annual_gross(m_nett, (base_perc - increment))

And the profiler now reports:

% cumulative self self total
time seconds seconds calls ms/call ms/call name
2.78 0.16 0.01 11 0.91 6.36 NettGoalSeek#seek_annual_gross
2.78 0.35 0.01 17 0.59 1.18 Integer#times
0.00 0.36 0.00 19 0.00 0.00 Float#round_to2

A significant difference! Incidentally, the time to run, according to the test harness, went down from 1.122316 seconds to 0.189661 seconds. The high-level indicator showing enough of a difference as well.

The by-product of this optimization included the ability to get even more accurate estimations since the stack never overflowed, despite the required margin of error.

The moral: optimization doesn’t need to sacrifice code readability. At the right time, in the right spot, for the right reasons, you can achieve a sweetspot (of sorts) between two opposing(?) constraints. But that’s not to assume i’ve found the nicest sweetspot in this little piece 🙂

So in between refactorings or when there’s a lull in production, indulge the geek inside you.


Attitude Driven Development

A.D.D. From the textbooks of an introduction into the business world (Department of Decision Sciences, UNISA):

Control does not, however, keep workers from making mistakes. The motivation of workers and a positive attitude towards their tasks, limit the number of mistakes they make.

It explains why TDD on it’s own will fail, and also why some folk don’t even need a fully bulked up test suite, if one at all. Although personally, i think no matter how good you are, there has to be something challenging in every project which you need a safety net for to keep the productivity going.

And it explains a lot of things about business, but more importantly for me, the business of software production. Also, it helped me realise why the solid programmers i have had the honour of working with are good AND cool to work with.

Attitude towards your craft (and fellow crafters even) and the passion for what you do will be directly proportional to the number of bugs waiting for you in 3 months time on a tight deadline. And, i suppose, the converse would also be true: the number of bugs you’re dealing with today (of your own making) are a direct result of your attitude applied when first implemented, and if not of your own making, those bugs reflect the attitude of the guilty coder.

Of course, i maintain the assumption of all things being equal, most notably: skill and ability.

And therein lies a great life lesson too (it’s part of why i really groove on programming as a lifestyle). The relationship between the bugs in your life and your attitude towards your life is more apparent and plain to spot than you might imagine.


SharpDevelop + Monorail

Monorail rocks, but getting going in #Develop can be cumbersome in that you need to create a lot of placeholders. Fortunately, you can create a template which you can drop into your data/templates/project/CSharp sub-path of your #develop installation
for example: C:\Program Files\SharpDevelop\2.2\data\templates\project\CSharp
Using this template, you can now

Create a “MonoRails” web project


Have it create all the skeletal placeholders


Build (change relevant config settings) and view when hosting it locally


This template in it’s current form references the Castle binaries from the install directory. You might want to change that bit of detail if your installation is not “standard” (ie. next > agree > all > next > finish).

Download Template


Subversion and Bzr

Subversion has been a friend of mine for some time now. Given the order of environments I have been required to work in, it’s more than suited our needs… anyhooo. Then there’s Bzr which has really grown on me, especially for offline version control. But what is really cool, is using both of them. I probably could set up a bzr server, but the subversion repository is already in place… incremental adoption always works smoother.

How easy is it? Just run bzr branch <svn:uri> and you’re set. Easy. Then you can run multiple ‘bzr commit’ commands to keep a local versioned control record of code changes, and when you’re within connectivity with the subversion repository, just ‘bzr push’ and Robert is your father’s brother. ‘Bzr update’ will check out changes from the repository.

For straightforward environments, this should suit you just fine with minimal fuss for a lot of satisfaction.

Rants Technology

Recycled Software

What’s up with everything being ported to .NET? There’s nothing more boring than copying somebody else’s idea, unless of course, your own ideas are pretty crap 🙂

And (sup)porting a dozen applications to be used with the .NET framework surely cannot be considered as innovative either- it’s real name is “market strategy”. I must confess though, we’ve (that is, i) benefitted much from having tried and trusted Java libraries (example, NHibernate) ported across, but i’ve also wondered many a time, why not just use Java then? And now

An aside, what i loved about the marketing around NHibernate is that it builds on the solid reliability and legacy robustness of Hibernate in a Java world 🙂

But it’s all just recycled software ideas and methinks a large pop of the lemming community are looking for “innovation” in all the wrong places.

<warning>Massive Generalisation About to Occur</warning>

Software developers are more into being “advertained” (advertisement + entertainment) than any other population group i know. Trouble is, i always presupposed we’re more critical than most. But perhaps we’ve reached a point where we’ve started buying into our own hype? Afterall, we can make it fly with words like interoperability, multi-platform and integration. Oooooo… :p

Business Technology

Enforcing DDD

So you’re all excited about TDD by now. You’ve also hooked into DDD and cutting your teeth on some of the more progressive methods for delivering software accurately, and, fairly rapidly. And with time, you probably need to start leading a team in DDD. Or you just need to interface with a team but want to make sure everyone’s on the same page. That is, the last thing you need is DDD-mutiny…. 🙂

We were putting the domain together and started adding in the NHibernate mapping files. One of the many beautiful things about NH is the ability to generate the schema based on the mapping file data. Now, strictly speaking, the database is not all that important from a design perspective. At least, that is, not initially if you try remain true to your DDD-allegiance. Anyway, this post is not about all that. This post is about enforcing DDD and one of the things you might want to do is remove the temptation to do some fundamental ERD analysis during the domain design. And if you don’t want to, then don’t 🙂

So how’s this for aggressive and extreme?

<?xml version="1.0" encoding="utf-8" ?>

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">

    <class name="NHibernate.Examples.QuickStart.User, NHibernate.Examples" table="[2239987-9382WED-23D23]">

        <id name="Id" column="[LKJDSA-98DSJHDS-9D76SD]" type="String" length="20">

            <generator class="assigned" />


        <property name="UserName" column="[130SF98-08JDY-98BNXDS]" type="String" length="40"/>

        <property name="Password" column="[10DDD398-08EFHJDY-98CVBDDS]" type="String" length="20"/>

        <property name="EmailAddress" column="[1098-0KHS8JDY-98DDDS]" type="String" length="40"/>

        <property name="LastLogon" column="[10998HG-08JDY-98DS]" type="DateTime"/>



You get the idea? And replace those funny column/table names with GUIDs for extra spice. Or even better, random base64-encoded strings. Of course, you can write a script to generate random table and column names for all your mapping files in a release build if you’re not comfortable with the idea of a “random” database schema during development.

Imagine trying to decipher the following while debugging:
select KJHDSA-AS878, SL-983LD23-2J FROM ASLKAJS8-32JH INNER JOIN ASLOE-876-35 ON DAS-3FE-43 = 321JDH-8786 WHERE ALOYWI-9876D = 2

For me, the bigger question would be: why are you trying to debug the SQL when you’re effectively abstracting that part of the solution and ‘supposed’ to be treating it like a black box?

But before anyone gets me (too) wrong, I’m not suggesting this as a standard practice, just a far-out idea which opens up some possibilities for managing DDD adoption 🙂

Business Technology


Following up on the theme of overtime, voluntary or otherwise, there’s another good reason why it’s counter-productive. In a team environment, all it takes is one person to work that little extra bit on a regular basis, and because everyone’s capacity is inter-dependant, that extra workload starts to catch up and takes it toll.

For example, imagine a business manager getting more leads than hours in the day to follow up on.

Developers producing more code than hours available to test.

Testers reporting more bugs than hours available to fix.

Analysts churning out more requirements than there are hours to spec.

Might not be such a bad situation, but one of two things end up happening. Everyone catches up at an unnatural pace, or the pace-setter gets bored or frustrated because the feedback cycle is taking too long- for them.

Estimates become unreliable, planning ends up hazardous, at best, and a false sense of productivity starts to pervade the project. But it’s not all gloom and counter-productive. It only really becomes an issue when the feedback gap gets too wide. And that’s where methinks the heart of most productivity, and certainly learning issues lie: the length of the feedback cycle. But that is a book on it’s own 😉

Business Technology

TDD, Functions and Design

A function assigns a dependant variable (the range) to an independent variable (the domain). Alternatively stated, a function will assign a result to an argument. And by that definition, we eliminate “void” methods and properties since these have neither range, nor domain. It is accepted though that these constructs can still alter the state of an object, but the focus of this post revolves on Functions and TDD.

This definition is useful since it also helps to describe bug resolution as a function, or more accurately, as an inverse function. An inverse function is determining the inputs based on the outputs. So when we’re resolving bugs, we’re inverting a particular function. So let’s look at releasing functionality in software…

We implement a function, with both range and domain. At some point in time, that function starts to behave “unexpectedly”, ie. it’s buggy. Functionally, either the range or the domain of the function has contradicted expectations. And the more granular the function, the greater the likelihood is that the domain introduced the bug and that the range is symptomatic. Of course, this can change as the implemented function increases in cyclomatic complexity. But back to TDD…

TDD recognized the domain-range behaviour of a function and attempted to introduce a mechanism whereby the domain-range relationship could be documented in an automated fashion. In doing so, a programmer could efficiently determine where the system changed expected behaviour as the domain and range of the various functions increased through integration. The programmer was then empowered to make empirical-based decisions, quickly, and in doing so progress (hopefully more rapidly) towards completing the various functions. Or at least, that’s the way i always understood it….

Then a school of thought emerges asserting that TDD is more about design, and not testing. And while it is acclaimed (and true, imho) that TDD will bring about a better design, it is still more about testing than it is about design. TDD documents what the expected inputs and outputs of any given function are, and the relationship between the range and domain. When it starts to focus on design, or is utilised with design as the primary focus, it’s no longer TDD, but should be rephrased: Perspective Driven Design, or User (as in caller) Driven Design. In which case, xUnit frameworks, tools and processes are inadequate. Why indeed would statements like Assert.AreEqual() be required to check wether the _design_ works? It’s not, and as such, TDD fundamentally remains, and should always remain, functionally oriented.

Along with TDD come some well understood concepts like defensive programming, as an example. DP has nothing to do with design, but everything to do with functionality. Of course, DP can come without TDD too 😉 But it still remains that TDD is about testing the function, not the form. And wether the form evolves into a good design or not, depends on the programmer. TDD won’t guarantee you a good design. You can still hack it. And it also won’t guarantee you good function either- you can easily write pretty bad tests.

Stick to proper design principles outside and beyond TDD and intelligently utilise a combination of experience, technology and common-sense to get it looking right. And use TDD, primarily, to get it acting right But try not confuse the two…