I (along with probably 1 000 000 other people) have found the self-help series of Dummies books quite amusing on different levels. As the saying goes, if I had a penny for every time “… for dummies” comes up in a situation joke…

Now there are a number of dummies books covering a host of programming topics. I would be surprised if they haven’t covered every mainstream language, framework and toolset available to the masses. Of course, there’s always “… in 24hrs” to cover what’s missed: C++ in 24hrs. You’ve got ask yourself: “Why, with the abundance of literature available, would a graduate want to spend 3 years (or more, sometimes involuntarily) studying something which can be studies in 24hrs?”

Well, truth be told: software is hard. It’s a popular quote, I’ve said it before and “kids” will probably still be quoting it generations from now. The only thing I could add to that quote is the word “really”. Software is really hard. Not all of it. Not all the time. But it is. Really.

Neither a dummies book, a 24hrs book, or even a 2 week course in learning how to code in c# is going to make you a programmer. In fact, no amount of certification is going to certify you as a competent programmer. The one common trait between certified (and good) programmers and not certified (yet good) programmers is the time spent on the keyboard. Voluntary time. That, and an odd fashion sense says I who doth dare venture out to the mall in my PJs.

Time behind the keyboard is a way of life. You need to develop (if you haven’t been born with it) a particular style of thinking and a particular approach. It’s not a one-style fits all either. There is no ultimate secret recipe to be a programmer (except for the time behind keyboard thing- and quite possibly the poor fashion). In KungFu, you can study the Crane, Tiger, Praying Mantis, Monkey and Snake and there are probably more too. In programming, there are no definitive animals to master. It’s more like a zoo from Star Wars. Looks like Monkey, walks like Snake but eats like Duck. It’s not too important what approach you have, so long as it does the job proper (sic).

Afterall, software is -really- hard but not always rocket-science (the two concepts are mutually exclusive). So don’t be fooled by dummies. It’s simple but not without complication. It’s straightforward but never cut-and-dried. It’s easy but really hard.

There’s been a lot of excitement in the local ADSL market with prices getting better and better and now with the lines being upgraded to 10Mbps, things are getting even better. If you need to check wether your line is eligible for a 10Mbps upgrade, check here on Telkom.

I once read the question that asked wether the bandwidth limitations do in fact impact on our behaviour (and hence performance in the education/business world).

For example, at the time of writing, a 5GB cap on bandwidth “seems” like a lot of bandwidth for home (or small office) users; and let’s say that’s on a 1024 kpbs line.

Now would getting 15GB (for the same price and maybe bump up the line speed at the same time) really make a difference to how you use the internet? Surely if you get by on what you got, getting more is not really going to affect you? Well, to argue by hyperbole, how would “no cap” change the way you use the internet?

Would it make you more productive?
Would your (small) business benefit from the boost- in a measurable financial way?

Or what about on the negative side; would it syphon time away from “real” world activities into the virtual world of increased time spent on social networking and virtual marketing. Is that so bad?

Whatever answer you come up with, the boost does impact on your home (or small business) at least in the short term. Think of a toddler who has been denied Smarties only to arrive at a birthday party with a bowl full of Smarties in the middle of the table (within easy reach) for everybody to snack on. And for one thing, it makes the cellular provider data bundles an absolute joke, trying to “sell” you increments of 10MB. But that’s a different rabbit hole..

It’s not uncommon when moving across to the BlackBerry platform, to get a little confused or even frustrated. It’s a “who moved my cheese” series of moments because in reality, “we” tend to expect that BlackBerry will do things in exactly the same way as “our” previous handsets. And when it doesn’t, “we” might think it’s broken. Truth be told, BlackBerry does do a lot of things a little differently and IMHO those differences are what make it great.

Note:
I see the same kind of frustration when users migrate from Windows to Ubuntu or Mac.
I see the same kind of disappointment when users switch from Symbian to BlackBerry.
I see the same kind of disillusionment when developers switch from [insert-language-of-choice-here] to Ruby.

Security prompts on the BlackBerry platform are one of those areas that come up for discussion quite often. To understand “why” it does things the way it does things, here’s an 8min video clip which is extremely useful in explaining that. You decide wether that’s good or not, but whatever conclusion you come to, remember, it’s just the way it is.

Personally, I think giving the user (or the BES admin) the final say and control is the better policy when you start examining all the other options available.

Yes, it can be argued that it does demand a level of sophistication on the user’s part, but like anything out there (be it a carving knife, a phone, an OS, an application, a motor vehicle, a bank account or a piece of sports equipment) your understanding of that “thing” is directly related to your proficiency and enjoyment in using that “thing”. A phone, even a BB, is no different.

I’ve mentioned Heroku a couple times before in my posts and I mention them again today. I was impressed way back then when I started 2 years ago, and I’m further impressed today.

I finally managed to get around to moving Morty from the now deprecated HerokuGarden onto the Heroku platform. And it was a cinch! (just one little surprise on the .gems file tripped me up easily sorted though)

The heroku gem makes life (too?) easy and even on a the most basic of basic (read: free) deployments, Morty is running pretty smoothly.

When whipping out the Josephus game, I used Jasmine to write the tests… er.. spec for anticipating the behaviour of the code. Among the many reasons I use a “test-driven methodology” (even in the smallest of projects) is that I like to (nay, NEED to) keep a close eye on the strategic direction of the code while I’m minutely engaged in the technical direction. And a picture like this is so easy to read:

Strategy

If you’re into math puzzles, you have probably come across the Josephus Problem at some point or another. If you enjoyed testing your ability at finding the right spot, there’s an interactive version (the theme slightly mangled with creative licence). Enjoy!

If you know me (or have worked with me) then there’s one thing you’ll be quickly become aware of with regards my coding behaviour: tests. I love tests. More importantly, I love meaningful, passing tests that validate my sanity and check my logic in critical areas.

And Javascript is no exception. I’ve run with jsUnit for quite some time now (because it just worked). Subsequently though, I got my hands dirty with it’s upgraded re-written cousin: Jasmine. There’s not much I can say about getting going with Jasmine since, to be fair, it really is so simple and well documented on the site already, needless to say:

1. Don’t Panic
This useful bit of instruction should be mandatory on every new piece of technology and before you take on any new learning. Don’t you feel better already?

2. Download the archive for standalone javascript projects
The primary folder of interest is the aptly-named lib folder which is, well, the core library.

3. Prepare a test runner
You need a test runner (test harness, if you like) for actually running the tests and a demo has been provided for you in the form of the included SpecRunner.html

4. Write tests
The included ‘src’ folder is the sample functionality under test. This is usually your own code. The ‘spec’ folder contains sample test code. I say -test- but when you start moving into proving behaviours, -test- seems such a dry word, and so the word -specification- is born, but that may sound too technical and daunting (until you become used to it). The two are, for all intensive purposes the same to the newly initiated, but quite different once you start grokking the subtle differences.

5. Have fun
Now go get on with doing something awesome.

Because i code… and code… and code… then code some more (you get the point) i tend to spend a fair amount of time with my fingers on the keyboard, an open LCD monitor staring back at me and worlds of awesomeness (all disguised as code) swirling around me. And then every so once in a while I’ll get some fresh air and go do something else “cool”.

But for the most part, i sit. Sometimes slouch. Badly.

Then a few years ago i started with regular back pain. I won’t bore you with the details. We have all back pain somewhere between the thoracic and the lumbar. It happens. And so i tried almost everything to correct my bad posture. Surfing helps keep that back flexed “the other way” but you can’t -always- surf. Ok, so you can. But unless you’re really really (really really) good or have rich grandparents, you’re not going to eat nicely (an entirely different problem altogether).

Alexander Technique, sitting on a oversized (and somewhat colorful) swiss ball, taking frequent breaks; all the tips you can throw a Google search at. Even tried changing my desk setup and “sitting correctly”. I followed the diagrams and posters on the walls of the physio to the ‘T’. None of it was that practical and most of it interfered with “me”. The ball actually made my shoulder/back problem worse.

Then I got a Mac and that all changed. Just kidding. It wasn’t the Mac

No, quite accidentally, i came across working out with kettlebells right about the time my brother started working at this gym in cape town: one80. Of course he learned a lot working there and he shared his knowledge and as he settled in, i spent some time working out with one80 here and there. The short times that I have spent in their gym inspired me to do more body-weight and kettlebell workouts. The result: no more back pain!

I can code for hours longer… i can swim way more than i used to… i feel “lighter” on my feet and i’ve had to do some pretty amazing things around the house. For example; fix a curtain rail from a very awkward angle (which, in a thousand words i won’t get right in describing) needless to say when my daughter walked into the room and saw me she said: “Wow, Mommy. What’s Daddy doing?”

No to mention the almost-daily heater-goblet-squat up and down two flights of stairs (once in the morning, once at night). Not that easy when you have a baby-gate to navigate and the gas bottle is full. And of course, playtime is so much more fun when you can squat, press and launch a 13kg toddler for 20 quick reps.

So, yes. If you just know you need to get back in shape -even if it’s just so you can code for longer or survive behind the keyboard for those extra hours- turn your life around, one80 degrees.

I guess a lot of folk don’t realise just how many creative and energetic startups are born in South Africa (there’s a lot in that for another story some day, bit not today) and one of the more recent ones is personera.com.

Aside from the energy these guys have been feeding off and into the world wide social web, the brainchild Sheraan Amod certainly seems to have done all the right homework. Particularly useful was this quick piece on marketing innovation.

A suggestion for all budding (and current) BlackBerry developers out there. When you purchase your signing keys, be sure to NOT use your regular email address. Instead create an account like bbsigning@youremaildomain.com or rim@youremaildomain.com to receive all the automated emails you get when signing.

For example, on one project, I have a build process that signs about 30 .cod files per build. But each build has specific builds for different OS levels, as well as different builds for testing, staging and production.

Add that up and you get 30 .cod files x 3 (one for each cert) = 90 x 3 (for each build type) = 270.
270 x 2 (for each platform) = 540. 540 x 4 (one for each white label) = 2160 emails!

For a daily build… and then adhoc builds. And not including any other projects. And you cannot get rid of the automated emailing. Standard RIM policy.