Software development is about process refinement. Try something, see if it works, revise, adapt, reset, and try again. If you’re doing the same thing the same way every time you’re not moving forward and, in this field, that means you’re falling behind. Do that long enough and you start to apply it to other things in your life. I switched from a QWERTY layout to Dvorak for more or less that reason (working out well, by the way) and I’ve taken up baking and gotten into coffee with much the same approach. (more…)
After a lot of soul searching on my professional future and the path that I want that future to take I have left VirPack and, today, begin my new adventure at Foxguard.
Here I will have the opportunity to build and likely manage a development team, the freedom to build quality and maintainability into the software process from day-one, and an opportunity to really make a difference in an industry in flux.
On the down side, I no longer have a window in my office.
Deep breath; here we go!
Back in the 1940s a guy named Dvorak got it into his head that the way we type is wrong. Our fingers transit too far across the keyboard, he argued, and as a result our motions are inefficient and slow. Dvorak rearranged the standard QWERTY keyboard to make typing more efficient, eliminating the design constraints which had originally informed the layout we all learned to type on.
In theory, that should make for a faster typist though it does take some getting used to. For me, this marks the jumping off point and possibly a painful transition. This entire post was touch typed using the Dvorak layout and, despite quite a bit of practice on a
One of the projects I have been working on with VirPack has been the establishment of a developer’s training program and central to that program has been Robert Martin’s materials on Clean Code. While many of Martin’s ideas have sparked some interesting discussions at VirPack, none has been more controversial than his discussion of Test Driven Development. Martin holds to a three-part cycle: Fail, Pass, Re-factor – in which you write just enough of a test to fail, just enough code to pass, and sometimes re-factor to clean up before cycling back to failure. This results in a number of areas, particularly in Martin’s examples, where tests seem to be written merely to justify an action everyone agreed was necessary in the first place — say, a test to see if you can construct an object which is then run, and fails, because the object does not yet exist.
While I am pretty well sold on Martin’s coding philosophy I decided to take my coworkers objections under advisement but with a grain of salt. Most of the Kata and examples that Martin works through are very simple; they have to be in order to be short enough and accessible enough to communicate the points he is trying to make about software development but that simplicity also means that the early fixed-costs of TDD seem very big compared to the actual “meat” of the problem he is trying to solve.
So I set out to try out true TDD on a project which I knew was going to be complicated. Martin’s examples of things like a bowling score calculator had just a few plausible test cases and a mere handful of interesting results which could emerge from a complete examination of all possible execution paths. I wanted something much bigger and much more complicated and the historian in me knew just where to look. (more…)
There’s a wonderful post over on the JitBit founder’s blog which is apparently a 2nd generation attempt to answer this question. Follow
Job requirements: professional skills in driving normal- and heavy-freight cars, buses and trucks, trolley buses, trams, subways, tractors, shovel diggers, contemporary light and heavy tanks currently in use by NATO countries.
Skills in rally and extreme driving are obligatory!
Formula-1 driving experience is a plus. (more…)
Elliott Kember, has a post on his blog right now discussing an apparent “security vulnerability” in Chrome. Security Vulnerability is in quotes there, not to mock Mr. Kember, but because the behavior Chrome exhibits is debateable as either vulnerability or feature. First, let’s walk through the behavior.
If you’ve saved passwords into Chrome, navigate to chrome://settings/passwords and click on a row. You’ll see a “show” button which, when clicked, displays your saved password. (more…)
Inversion of Control (IOC) frameworks have become quite the rage as the software craftmanship movement has gathered steam. IOC makes it much easier to break complex multi-part programs into distict, and more importantly testable, components so that they can then be glued back together at run time. There are lots of nifty frameworks that can make this happen but at the moment I’m playing with Ninject.
Ninject is a very minimalistic IOC framework which focuses on what it calls a “fluent interface” that leverages the compiler and IDE rather than a huge XML file to map dependencies. Overall it’s very fast, very light weight, and very powerful. I’ve picked it up quickly and found it to meet almost all of my IOC needs.
Save one. And this is apparently a big problem for a lot of people. Ninject doesn’t like overloaded constructors. (more…)
Most of the software development I do is user-facing in some sense. In other words, the guy I expect to be clicking the buttons and pounding the keyboard when my applications are running isn’t a technology professional, he’s a mortgage broker from Topeka, or something like that. I’m developing software for my parents generation or at least that’s the way I like to think about it. So I try to make my interfaces clean, my options minimal, and my help-text easy to understand.
I’ve been doing that for a long time; so long in fact, that it’s easy to forget that not everyone writes code that way. (more…)
Power users are important, or they ought to be. Power users are the folks who can help you figure out what your product is really capable of doing; they encourage you to push the boundaries of your existing feature set and can really help to highlight aspects of your service that you didn’t know were important.
No one seems to have told this to the folks at Netflix. (more…)
The great thing about computers and the internet is that, almost no matter what it is that you do, someone else will figure out some clever way to do something novel with the fruits of your labor. The folks over at If This Then That or
Indeed, the concept of the Rich Web — all those clever interactive widgets that you depend on to get through your day — is an appropriation of a technology that was never designed to do what it now does. HTML is not and was not designed as a way to build applications but simply as a way to represent documents. Were the HTML standard maintained simply as a method of document representation — in other words, were its features and functionality updated with only an eye for its original purpose — the resulting changes would destroy huge chunks of the public web.
Obviously, this would be bad. (more…)