philosophy


22
Jan 10

hustle

do the hustle

That time was so much more glamorous

A realization has been dawning on me as of late, one that I’ve always known, but that is easy to forget, easy to misplace, easy to neglect. The best way to learn anything is to do it, to struggle through, to forge on, to fight and gnash teeth and curse at. There is no knowledge as highly regarded as that which you have to work for.

I’m not even particularly certain how this all came about, it seems to have been a culmination of things. I didn’t intend to but somehow I ended up putting on my plate a bunch of new stuff to learn around the same time. Git, ruby, rails, blogging, prosper, hosting my own domain, and testing (Testing being a decidedly late addition). This blog was the genesis of a lot of it, that and just being curious.

I had my first post back on October 2nd of last year, as of writing this 112 days ago. At that point I didn’t really know anything about the 7 topics above, I started the blog using Google’s Blogger platform, it was an easy onramp.

After a month or so, I was encourage by some friends to move the blog to my own domain, which you are now at. I also kicked off the prosper project around the same time as starting this blog. I played around with ruby and a crazy friend convinced me to try out rails. I moved prosper to GitHub and began learning git. Now prosper supports 19 backends and has gained over 100 unit tests in the last few days.

Here’s the kicker though, I don’t know what I’m doing. I never really did, I just started doing stuff, and have been running ever since. There have been days when I’ve gotten 5,000+ hits on this site, several days with several hundreds of hits and I’ve been steadily increasing the daily reader count. I don’t know how I did that, I just kept writing, I liked it, I promoted it over twitter and hacker news if I thought I had written something insightful, and I guess that is working. The same thing with prosper, I saw a need for something that didn’t exist, I had a vague idea of how to make it, and I started coding. I’ve rewritten and refactored it piece by piece to the point that it supports all kinds of things I never thought it would. It’s due for another architectural change after I finish these unit tests.

If there is one key thing I could convey to anyone reading this is to hustle. You will never be prepared for the things you are capable of doing. You will achieve your greatest accomplishments not by building up a grand framework of skill and then deftly creating something glorious, but by starting small and persevering in making it better and better. It is never an easy road and you will gain a grand framework of skills, but you have to push your boundaries to grow.

This came together for me last night, I was working on a rather tricky bit of rails and broke something. I hadn’t gone too far into it and so I typed rake db:rollback and git reset head --hard and was back to a working application. I stopped myself for a second and thought about what I had just done, how improbable it all was from where I was just a month ago. I then thought about what I was doing in rails, and thought about how earlier in the day I was wrapping up prosper functionality in unit tests and finding regressions, and how I would have to write some cucumber tests for what I was doing, and I realized that 112 days ago I didn’t have the vaguest idea of any of this.

I would love to put a triumphant “I’m just so damned smart and talented and handsome” paragraph here, but that’s not the case. I just steeped myself in this stuff, I worked in git daily, I read about it, watched screencasts, I bought agile web development in rails, I got design patterns in ruby, I hustled. And you can do it too, take the first step today.

The first step that you should take is to invest yourself in something non-trivially. Want to learn rails, then go buy agile web development in rails, want to learn github, move an active project out there, want to learn linux, reformat your machine so that’s all you have. You have to invest yourself, it plays a trick on your brain that makes it want to not waste that “investment” by quitting. If you can burn your boats (Hernán Cortés reference) all the better. I had no choice but to learn git or else I couldn’t keep working on my project, and as a side bonus I got the joy (and frustration) of working in git everyday.

Get out there and hustle, learn something new, do something that scares you, reach beyond your grasp.


21
Jan 10

unlicense’d

colbert portrait by lockwood

Freedom has never kicked so much ass

I wrote yesterday about the importance of open source software. I got one comment saying that prosper would be awesome if it were in the public domain. Here is the comment from Arto Bendiken

Prosper looks *sweet*. It’d be awesome if Prosper indeed were in the public domain. I think such a move would make for a decisive selling point over the numerous competing PHP libraries, setting Prosper clearly apart from the herd and allowing it to be easily embedded into any new emerging PHP web frameworks.

It’s worth mentioning that a key reason that SQLite, which is in the public domain, has prospered (no pun intended) has been the fact that it can be so easily (both technically and legally speaking) embedded into any other software. The end results of technical excellence combined with singularly liberal licensing speak for themselves: http://www.sqlite.org/famous.html

I think a lot of these same benefits could come into play also in such a potentially key higher-level web app infrastructure piece as Prosper. It certainly seems that you have the technical side of things well in hand, already, so here’s hoping for a bright and prosperous future.

Well I completely agree with Arto and want to clear up any confusion about prosper and its license. Prosper was original hosted on Google Code, which requires you to choose a license, at the time I selected the MIT/X11 license based off of my belief that it was the most free. A little further down the road I saw the WTFPL – Do What The Fuck You Want To Public License and thought about switching to that. There is a bluntness to the ideal of that license that appealed to me.

The problem with the WTFPL is of course its name, I want prosper to power lots of things and that means taking into account a wider audience. While hackers and rock star programmers can easily adopt something with WTFPL, I didn’t want to be responsible for some corporation turning their back on an otherwise useful library because they were squeamish about a word in the license.

no copyright

I always thought people just hated the letter C... then I found out this means no copyright

Then I found this post on Hacker News (ironically by the same Arto Bendiken) and it lead me to the Unlicense. The Unlicense is exactly what I was looking for and simple to adopt. If you go to the GitHub repo you will see that the project is now officially Unlicense’d. The 0.8 release will be the first official Unlicense’d release, and so will every release going forward. I believe in free and open source software and so I’m publicly declaring now that prosper will always be free, open source, and unencumbered. The mechanism that I will use to ensure this going forward will be Unlicense.

What’s the big deal, plenty of things are open source, why is this any different? The difference is that I’m giving this away fully, without any restrictions. Want to build a cool new library that uses prosper as the low-level database abstraction layer, go for it. Want to build a proprietary ORM that utilizes prosper, go for it. Want to repackage prosper and try to sell it (as underhanded as that is), go for it. Want to smother prosper with jam and eat it, if you can find a way to, go for it. Want to…. enough already, you can do whatever you like.

It is easy to talk about things like freedom and support them in the abstract, it becomes more difficult when you have something concrete. People could very well take prosper and take it in directions I don’t care to see it go, but that is life, that is creation, that is the essence of open source. It is my goal to see prosper provide a solid foundation for building new and better tools and frameworks in php. I want as many people as possible to use it, and so this was a logical choice.

The next time you have some useful chunk of code lying around and you want to give it to the public domain for the good of the public, think about using Unlicense. I can’t say it any better than they can so I will just quote their section about why you should use Unlicense. “Because you have more important things to do than enriching lawyers or imposing petty restrictions on users of your code.”


12
Jan 10

who cares?

man shrugging

I shot who in the what now?

It’s one of my favorite questions to ask during a technical discussion. Who cares? Some others I like to throw out our, why should I care? why does it matter? and I don’t care! Am I some sort of raging lunatic completely out of my mind and trying to pick a fight with everyone I meet? Yes, but that’s not why I ask these questions. I ask these questions because as great as the big picture is we sometimes have to drop complexities to get stuff done.

When you have a big flow diagram or giant UML Class Hierarchy it can be fun to think about the abstract way that things interact and how you can pass state around and whatnot. This definitely is useful for getting a feel for a new system, but then there comes the worst part of any software developer’s job, actually getting things done. You see that’s what we get paid for, actually putting our fingers on keys, typing stuff out, compiling it, and shipping a product. Part of this is doing the upfront design work and getting all of our t’s crossed and i’s dotted, but just as important is actually getting something working.

I talked about this before in my post about simplifying things. This simple question, “who cares?” (you can be more diplomatic about it if you like) is a great tool for getting to the heart of a problem. I like the simplicity and straight-forwardness of the question, it normally catches people off guard and challenges their assumptions.

Frank: So we need to pass this data into the layer
Bob: Who cares?
Frank (taken aback): I care, I care deeply about this data
Bob: But why do you care about it being in that layer, its just going to hand it off to this layer, and that layer doesn’t care at all about it
Frank: I guess you are right, we don’t need it there

BAM!!! Problem simplified! For anyone that’s ever taken any education classes you may recognize this as a rather blunt application of Socratic Method. The point is confrontation, but not between the two people discussing something, between each person and their preconceived notions about a problem or situation.

In High School I took a chemistry class, it is one of the few classes that I really remember in any detail from so long ago, the teacher taught the entire semester in Socratic Method. He would question us, we would experiment, we would reason out why we observed what we observed, he prodded us, and we cherished our knowledge. Anyone can tell you water is composed of 2 hydrogen atoms and 1 oxygen atom, but when you had to work for it, when you had to defend your knowledge of it from scrutiny, it became concrete, it became your discovery.

Applying this to software development is useful, we can get locked into our preconceived notions, and direct, blunt, sometimes even rude questions can spur you to really consider what you are talking about. Software is incredibly fluid, sometimes an idea or concept can become out-dated in a matter of months or a matter of hours. The biggest ones are the most difficult to challenge, because they often have the most dependent code around them, but this makes them the most important to constantly consider.

Keeping your conceptual design, implementation, and solution in lock step with a problem domain often involves some amount of change, that change can be hard to come by though. By challenging our standing beliefs we can find new avenues for exploration or strengthen the existing techniques and gain a better understanding of them.


11
Jan 10

grok

banging head

necessary part of grokking something

Computer nerds should be familiar with the term grok while the rest of the populace has no need for such a silly word. You may hear it down at your favorite nerdery, “I don’t quite grok this” or “Once I grokked it, I flew through the project.” What does this word mean though and where did it come from.

Grok for the non-nerd means, “to understand thoroughly and intuitively.” Although this is true it belies what it truly means to grok something. For that we need to realize the origin of this fantastic geek speak, this term is straight out of Robert A. Heinlein’s Stranger in a Strange Land. He defined it as follows

Grok means to understand so thoroughly that the observer becomes a part of the observed—to merge, blend, intermarry, lose identity in group experience. It means almost everything that we mean by religion, philosophy, and science—and it means as little to us (because of our Earthly assumptions) as color means to a blind man.

The great thing about grokking something is that it changes your world view, it fundamentally shifts the way that you see, perceive, and understand the world. The bad thing about grokking something is that it is incredibly difficult to get to that point. Let’s take a look at a fantastic chart I’ve whipped up to help us understand this better.

grok

the graph of grokitude

In this graph we have time and effort along the horizontal and understanding along the vertical. We can spend a great deal of time after “mastering” a subject before we get the epiphany and truly grok something. To really understand a subject on the level that a computer nerd would consider grokking it takes not only a full in-depth knowledge of the function of something, but an understanding of the design, an internalization of the principals, and a familiarity that borders on oneness.

This is the reward for hundreds or thousands of man-hours spent toiling in something, the day when the clouds part and you truly understand something, this has an amazing non-linear effect on your understanding and your productivity. Once you grok something, be it a framework or a library or a concept, your ability to use that and your productivity in it increase in a non-linear fashion.

Although it is important to have a wide breadth of knowledge we must remember the importance of having a few areas of incredible depths of knowledge. These areas will permeate everything else you do, so try to choose wisely. The subjects that you truly grok are the ones that will effect your big picture outlook.

Here are my suggestions for some fundamental things to learn, and learn to a point that it fundamentally shifts the way you look at the world.

  • A Pure Object Oriented Langauge – I would suggest smalltalk for purity, but ruby makes a fine substitute and has more application.
  • A Functional Language – For this look no further than Haskell, and Learn you a Haskell for Great Good
  • A Set Language – Take the time to learn SQL, its a tool most of us use everyday and very few of us take the time to learn properly
  • A Markup Language – HTML + CSS, these are the embodiment of separating data and display, learn them intimately.

Learning these, but more importantly grokking them will color the way you approach problems and solutions. Having a depth of knowledge in a key variety of tools allows you to quickly master new ones, better understand problem domains, and more completely express your thoughts in the abstract.


8
Jan 10

limits

cliff edge

its beauty is only matched by its cliffy-ness... or something

I had to make a hard decision today, it was one that I had known I would have to make at some point, and frankly I was just putting it off. I’ve written about burnout before and I’m no stranger to pushing myself harder than I should. But I like to think that because I’m aware of the danger and am actively working to avoid burnout that I can push myself, and still maintain some sanity.

Part of maintaining sanity is knowing one’s limits. I have a full-time job, prosper, and until today 2 side projects. Today I resigned from one of my side projects and I released any code or concepts I had worked on to the other developer. It was not something that I particularly looked forward to doing, but I had to prioritize. I had to dispassionately measure the various aspects of my life and make a cut before I burned out and lost everything.

Now I’m left with a strange feeling, almost ashamed that I let down the other party, but at the same time a sense of relief has come over me. After I made sure that I didn’t burn down any professional bridges, another wave of relief. Looking forward in my calendar and seeing all the time I’ve got to work on Prosper and my other side project, a wave of excitement. The problem was that I was spread too thin, at my limit, I was pushing ahead 110% but not moving anything forward. Now though I feel back in control, pushing ahead and making things happen again.

I’ve given this new attitude a shot in the arm over the last few days. For the last few days I’ve been knocking out tasks that have been long outstanding and non-trivial. It’s easy to trick yourself into thinking you are being productive by banging out a few quick trivial tasks and checking some stuff off the todo list, but picking long standing non-trivial tasks is important.

My girlfriend’s father’s computer was the first such task. It’s hard drive died, and I’ve had it for far too long. What should have been a simple diagnostic-swap-reimage was bedeviled by problems. I didn’t have the right keyboard to perform the diagnostic (all my usb keyboards were read by the bios but not the ubcd prompt), then the replacement drive I was provided was the wrong type, and the recovery disks were all oddly labeled. The task itself though is not that difficult, get the right drive, swap, get the right disk, click click type, wait 4 hours for reimaging. The giant tower sitting there day after day had become a constant and depressing embodiment of my inability to move tasks forward. Yesterday though I finally hooked it all up, found the right disk (on the third try) and reimaged it. Everything works fine now and the problem is solved.

For the presentation I’m giving at CodeMash I plan on doing a live demo, I needed to pin this completely down to the last detail and do all the boring set up work so the presentation can be all whiz-bang cool. After an hour or two hacking around this is now done. My minimal PowerPoint presentation is well on its way to being complete. Getting these non-trivial roadblocks out of my way is freeing up my mind to think of other things, to begin figuring out how to move other things forward.

My suggestion for anyone feeling overwhelmed is twofold. Be realistic, are you taking on too much, I was, it happens to the best of us. It’s never a great feeling to admit that you’ve overextended yourself, but it’s much better than just constantly being overextended. Are there tasks that are constantly at the back of your mind, nagging todo’s that you keep putting off, well just tackle them. It’s not fun, but when you put them off they start growing larger and larger in your mind’s eye. The live demo only took around an hour to code through, even though in my mind it was important and therefore a monumental task.

Pick out one of those tasks that’s been on your todo list for a while, knock it out, just having it done is worth the work.


5
Jan 10

experimentation

Female in lab

Like most computer related things this type of experimentation will have less blond women

I love my mom, she is a kind, intelligent, funny person. She has worked 2 jobs since I was just a little kid and she still does. For most of my childhood she worked in what we refer to in this country as the “Service Industry.” This is a nice euphemism for mind-numbing tedium, the fact that she put in 14-16 hour days to give me the chance to sit here and blog and make good money consulting is a testament to her devotion as a mother. I remember growing up she worked at a Gas Station and at Arby’s, sometimes bringing home some tasty chicken sandwiches or Apple Turnovers.

Now my mom works retail and in an office. She gets to work in a nice office and do office work which means that she now has to professionally use a computer. Being the “computer” son I get the calls when there is some task that falls outside the scope of her knowledge, and after all she’s sacrificed for me, I’m ecstatic that I get to help her.

The things she needs help with our never very complicated, sometimes its an unfamiliarity with an FTP Client or looking for a way to open up and print multiple files quickly and easily. She normally has figured out or been told some way to get the job done, but it’s so slow and tedious that there must be a better way. Normally after a few minutes of explanation we figure out a way that she can do her job faster and easier, and everyone wins.

In my job as a software developer I often have to think about the user, and its an interesting relationship. On the one hand if there were no users then I would make no money and that would be sad, on the other hand the users often end up taking a simple and elegant piece of code and twisting it into a horrible abomination so they can understand it better. The mental images of a slack-jaw fool and a well-meaning bug filer compete in my head. Now though I have a new user mental model, my mom.

I know that she is hardworking, intelligent, and does know how to use a computer for daily tasks. Yet, even with these great user attributes, she still doesn’t discover things that I do, and I wonder why.

green screen with assembly

Yea that's assembly not basic, go complain about it in the comments.

Perhaps its a generational difference, I can’t actually remember a time when I didn’t have a computer. I remember distinctly getting the old green and black computer with 5.25in disks that I could play submarine hunting games on from my Uncle Marty. One of the first things I did with this new toy was to get a book from the library full of BASIC games and start typing them here, that’s right I’ve been programming since I was about 6 years old. The thing that no one ever told me was that I could break the computer, to me it was a toy, and the worst thing that could happen is I mess up my disk and have to try again. As I moved up to more and more powerful machines I’ve always kept that same mindset, the computer is there to accept my commands, there is almost nothing I can do to it that can’t be undone.

My mom on the other hand is pre-occupied with the idea that she might break the computer. This is a major difference between computer people and users. Watch a power user trying to figure something out, they will experiment see what happens when they click this or that, issue this command, or right-click in this box over here. A normal user on the other hand normally just uses the program in the way that they’ve been instructed to, instead of exploring the interface.

In a perfect world everyone would read the user manual, in real life though people don’t. Even if people did, it’s hard to learn reading, it’s easy to learn doing. The power user learns through trial-and-error how something works, once they feel comfortable with the bulk of the application they may turn to the manual to figure out some of the trickier bits. The normal user will never get to a level of comfort to attempt to master the tricky bits. As the power user explores they feel validated and gain a sense of control, giving them a desire to assert their control over the rest of the system. The normal user is simply performing a rote task, the tool is not there to be explored and mastered, it merely performs some function.

Its the difference between becoming a magician and learning a card trick. I can learn a card trick and practice it everyday, becoming incredibly good at the card trick, this in no way makes me capable of sawing a woman in half (and having her live).

Trying to get users to experiment involves a few things

  • Everything your application does should be easily and apparently reversible.
  • Experimentation should be rewarded, never punished
  • The Application must cope well with the unexpected, no nasty error messages
  • Context Sensitive Help
textmate

TextMate is full of win

Case in point: I’ve recently got my sexy new iMac with the excellent TextMate for coding. It is one of the best experiences I have ever had, but it’s not because it is easy. TextMate encourages you to explore and experiment, defining a function, def :tab: will automatically write the end and position you to write the methods. The Bundles menu is quick and accessible, the bundles make it easy to figure out what to do and the reward is instant. All of this culminates to making the software seem usable and easy, even though its very complex.

Turning users into explorers is no small task, but the payoff is great. The more a user feels in control, the more they explore, the more they explore the more in control they feel, its a positive feedback loop. The more in control a user feels the more they associate your project with being easy to use and generally a good piece of software.


4
Jan 10

simplify

it's so simple

simplicity is sometimes surprisingly complex

I love abstractions, most people do, they allow us to take complex things and wrap them in simple things and everyone is happy. The thing to realize is that there are degrees of complexity and different goals of abstractions.

Programming is one of those things where more often than not our abstractions are really helpful. The problem becomes one of perceived complexity vs. actual complexity. A good example is network protocols.

Network protocols are these complex beasts that let us talk across networks with some degree of certainty. Its really quite the marvel of engineering prowess, man has taken the various blinkenlights and cables and a big ole’ pile of Cisco and now you can watch a video of a cat playing keyboard whenever you like. Network protocols were designed to simplify the process of two programs on physically distant machines sharing information.

When you first try to learn a complex abstraction it can seem daunting, UDP, TCP/IP, sockets and fifos and netcats oh my! Sometimes it can seem overwhelming, but take a step back and realize that no matter how complicated a piece of software is, its just moving around bytes.

Perl has a philosophy that at the end of the day, everything is strings. That’s why its the glue that holds together the interwebs, because it’s just a really good string manipulation language. At the end of the day that’s all the internet is, strings floating around, normally between angled brackets.

Like most of the things I write I’m almost certain I had a point… oh there it is. When I started writing prosper it seemed like an impossible mountain to climb. I wanted to write a library that would bridge the gaps between all supported database backends, to have it be a sort of universal data access object.

prosper simplified

This was much easier to think about than the actual problem

I had a few false starts on my project until I took a step back, I simplified my problem domain, and created an architecture that worked. Instead of focusing on the end result of prosper I thought about it in a more abstract way, prosper was a mapper from function calls to string snippets. This isn’t actually what prosper does today, prosper is in fact much more complex now than I would have ever imagined when I first started out.

The obstacle that stood in my way the most when starting out on prosper was being overwhelmed and unsure. The problem domain I was trying to tackle was too big, even when I tried solving it i ended up painting myself into a corner by focusing too much on how one specific backend acted. I needed a simpler problem that was more easily solvable, but one that would in the end help me reach my actual goal.

As much as I wish I could take credit for this idea, it’s not mine, it’s something called Minimum Viable Product. I wanted something that at its core would produce cross-platform SQL, so the first iteration was to make something that did exactly that. If you go on GitHub and pull one of the earlier commits you will see that that’s exactly what I built. Over time I have added the ability to execute those strings, connection and transaction management, standardized results, prepared statement support, and much more.

I couldn’t have accomplished any of this though if I hadn’t taken a step back from the problem domain and looked at the simpler problem at the core of what I was trying to do. I stumbled in the beginning, I’ve refactored again and again, over the break my good friend Ian took a look at the library and found a whole slew of problems, and I thank him for it. Prosper isn’t perfect yet, but it is moving toward being something really worthwhile, and to begin moving it required that I have something, anything, to start with.

So here is my suggestion for you for the new year. If you have some project that you’ve wanted to do but couldn’t figure out how to start, step back from the problem domain and try to find the core of the problem and solve it with the simplest thing that could possibly work. Don’t worry about the first iteration, or the first 20 iterations, you have to just get started. Once it is started you can iterate and refactor and maybe throw everything away and start again. No matter what the outcome of the first iteration it will be worth it, the best case scenario is that you can use the first iteration as a core moving forward, the worst case is that you learn a bunch about the problem domain and have to try again.

It’s the start of a new year, resolve to start your dream project, because that’s the hardest part. Once you get rolling momentum has a fantastic way of carrying you through.


30
Dec 09

minimalism

minimalism

minimalist staircase... looks really dangerous

I am a minimalist at heart, I like simple things with clean lines and no clutter. This is one of the reasons I love my new iMac, its just a beautiful magic floating screen filled with win. Minimalism is more than just an artistic movement or an ironically expensive interior design style. Programming is by its nature minimalistic, we programmers (as I have said before) are a lazy bunch. No one wants to type the same code over and over again, so we came up with functions, and then classes, and then inheritance, and frameworks, and aspect oriented programming, and so on and so forth. We want to reduce the amount of work that we as the developer has to do.

Here is a simple windows program that pops up a hello world screen using Visual C++

// GT_HelloWorldWin32.cpp
// compile with: /D_UNICODE /DUNICODE /DWIN32 /D_WINDOWS /c

#include <windows.h>
#include <stdlib.h>
#include <string.h>
#include <tchar.h>

// Global variables
static TCHAR szWindowClass[] = _T("win32app");
static TCHAR szTitle[] = _T("Win32 Guided Tour Application");

HINSTANCE hInst;
LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
    WNDCLASSEX wcex;

    wcex.cbSize = sizeof(WNDCLASSEX);
    wcex.style          = CS_HREDRAW | CS_VREDRAW;
    wcex.lpfnWndProc    = WndProc;
    wcex.cbClsExtra     = 0;
    wcex.cbWndExtra     = 0;
    wcex.hInstance      = hInstance;
    wcex.hIcon          = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_APPLICATION));
    wcex.hCursor        = LoadCursor(NULL, IDC_ARROW);
    wcex.hbrBackground  = (HBRUSH)(COLOR_WINDOW+1);
    wcex.lpszMenuName   = NULL;
    wcex.lpszClassName  = szWindowClass;
    wcex.hIconSm        = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_APPLICATION));

    if (!RegisterClassEx(&wcex)) {
        MessageBox(NULL, _T("Call to RegisterClassEx failed!"), _T("Win32 Guided Tour"), NULL);
        return 1;
    }

    hInst = hInstance; // Store instance handle in our global variable

    HWND hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 500, 100, NULL, NULL, hInstance, NULL);

    if (!hWnd) {
        MessageBox(NULL, _T("Call to CreateWindow failed!"), _T("Win32 Guided Tour"), NULL);
        return 1;
    }

    ShowWindow(hWnd, nCmdShow);
    UpdateWindow(hWnd);

    MSG msg;
    while (GetMessage(&msg, NULL, 0, 0)) {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
    return (int) msg.wParam;
}

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) {
    PAINTSTRUCT ps;
    HDC hdc;
    TCHAR greeting[] = _T("Hello, World!");
    switch (message) {
    case WM_PAINT:
        hdc = BeginPaint(hWnd, &ps);
        TextOut(hdc, 5, 5, greeting, _tcslen(greeting));
        EndPaint(hWnd, &ps);
        break;
    case WM_DESTROY:
        PostQuitMessage(0);
        break;
    default:
        return DefWindowProc(hWnd, message, wParam, lParam);
        break;
    }
    return 0;
}

Holy Shit! This is after I stipped all the comments, removed whitespace, and reformatted to 1TB. But here is how much code you need to do something similar in C++ leveraging Qt

#include <QtGui>
 
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    QLabel label("Hello, world!");
    label.show();
    return app.exec();
}

This is great news for the developer, we can accomplish the same result with much less code. We are now much more productive and so we have freed up some precious developer time that we can spend on something else. Our code is much smaller, much more minimalist now, which is good because we are lazy. This ends up being a dual edged sword because there is now the temptation to start coding up more features, because they are so easy to implement now. We have made our code more minimalist but in doing so have enabled developers to make their applications feature bloated and anything but minimalist.

Jeff Atwood wrote a post yesterday, Responsible Open Source Code Parenting, in which he asserts that John Gruber is being a negligent open source parent.

I don’t mean this as a personal criticism. John’s a fantastic writer and Markdown has a (mostly) solid specification, with a strong vision statement. But the fact that there has been no improvement whatsoever to the specification or reference implementation for five years is … kind of a problem.

The question I had, and still have is why. I wrote this comment on Hacker News yesterday regarding this post

The idea that since markdown hasn’t done anything in years its somehow being stewarded improperly is a bit foolish. Look at Gruber’s vision statement, he wanted to make an easy-to-read easy-to-write markup.

He did it, it is done, it’s called markdown. If Atwood had his way Gruber would have spent the last 5 years filling it up with features and today we would be reading a post about how Markdown went from slim and sleek to fat and bloated.

Gruber set out to do something, then he did it, now it’s done. It’s a minimalist approach. Atwood would have rather he spent the last 5 years allowing for “open source collaboration” that would help in “moving forward and maturing” Markdown. To what ends?

It is easy to add feature after feature to something with the belief that you are somehow adding value, but the whole world doesn’t think this way. Let’s illuminate this with an example.

Apple Remote Windows MCE Remote
apple remote

There are 7 buttons

mce remote

The technical term is an assload of buttons

That’s how the Apple Remote is intended to look, it’s not lacking buttons because they haven’t gotten around to putting some more on, they intentionally kept it simple. Now I’m not trying to argue that one remote is superior to the other, I prefer the Apple Remote, but the important word there is prefer. Atwood makes the mistake of thinking since something hasn’t changed in 5 years its a problem. What if Gruber did the cost-benefit analysis of the new features for the last 5 years and decided that it just didn’t need anything else.

People have asked me if I’m going to use Disqus and although I tried it for a bit I decided to just use the simple built-in commenting system. Disqus was all kinds of bells and whistles, it is (in my opinion, which since it’s my blog is the only one that counts ;) ) ugly, and it’s benefit doesn’t outweigh it’s cost in my opinion. By the time I took out all the stuff that made Disqus feel bloated to me I realized I basically had the simple built-in comments, just hosted by a third party, so I abandoned it.

There is a cost to every feature you throw into your software, the cost is added complexity. I have decided that complexity better come with some gain for the user, otherwise I won’t add widgets and gadgets and features just to add them.


23
Dec 09

decompress

festivus card

Get ready for the feats of strength

The holidays are upon us and no matter what holiday your particular sky god has you celebrate (Festivus for the Rest of Us!) there is one thread of humanity that binds us together at this time, days off from work. When you have some time off of work you can spend it doing any number of worthwhile things

  • Drinking egg nog until you black out
  • Eating your weight in sugar cookies
  • Having that same argument with your family that you’ve been having for the last 10 years
  • Watching 24 hours of A Christmas Story
  • Spending quality time with friends and loved ones
  • Living through the same day over and over and over, á la Groundhog’s Day (Best saved for the actual Groundhog’s Day)

If you are reading this blog there is a good chance that you are some sort of programming nerd, its ok, I don’t care what the New York Times says. As a proud nerd you have probably heard of some sort of technology that interests you, maybe clojure has piqued your curiosity, or you finally want to learn that “rails” thing all those young whippersnappers keep talking about. I would argue that this can be a great way to decompress, if you do it right.

First off, find something different than what you are used to, if your 9-5 is .Net don’t spend your precious free time learning more .Net, that’s stupid. Go find something radically different, maybe look at a functional programming language, go find that weird kid in the corner and talk to him, he probably has interesting stories about fire. This might seem like a waste of time at first, but it’s not. It’s all too easy to get locked into an ecosystem, doing the same thing day in and day out, to get comfortable there and to start thinking that your way is the only way or the best way. Reading about other technology outside of your realm might not have a direct benefit to your 9-5, but you may gain a perspective or understanding that would be incredibly difficult to get from your standard frame of mind.

Second off, this isn’t work, this is fun. You are allowed to make mistakes and change your mind. If you work through a tutorial or get done with the first chapter of something and find that you really don’t care, then go find something else, the software world is full of interesting things. The thing is, only stop if you grok the subject and dislike it, don’t necessarily stop just because you don’t get it at first.

erlang source in gedit

What? Caroling? No fuck that, I got some erlanging to do!

Third off, this is just to whet your whistle. Don’t ignore your loved ones, squirreled away with your Beginner’s Guide to Erlang because you’ve fallen in love with the idea of massively parallel systems. Take this time to investigate several things, learning the basics and setting up your love affair for the next few months. Then make sure you tell the people you care about that you love them and eat too much food and do people things.

For me this break will be about Rails. I’ve followed rails for a while, I’ve always been impressed with it, and I’ve had a few false starts. I’ve gone through the Getting Started tutorial more than once. I’m a php guy at my core, but learning how other people do the web is worthwhile. I’ve started the adventure already and think that this time it might stick. I have a 2 hour car ride up to Cleveland and back that I plan to fill with listening to Rails podcasts.


That’s all for now, go relax and decompress, that’s what I plan on doing for the next 4 days. As a side note I will probably not update during the holiday break so if you obsessively check or your rss feed gets lonely don’t worry I will be back on the 28th.


21
Dec 09

impedance

you can find really cool images searching for impedance mismatch, this one has lazers (with a z)

you can find really cool images searching for impedance mismatch, this one has lazers (with a z)

There is a threat to good software, one that threatens the most promising of software projects. This threat is impedance mismatch. I use impedence mismatch in the sense that Object-relational impedance mismatch uses the term, but make no mistake, I’m not talking about the difficulties of writing an ORM. What I wish to discuss is far more insidious, it is death by a thousand paper cuts, it can spell ruin for any project. Impedance mismatch is born out of the confusing first steps of a project, it can also arise from multiple developers working over time on a large project or from internal disagreements over the optimal solution.

The major problem is that when we go about designing some new piece of software, some whiz-bang solution, we do not fully understand the problem domain. Any good development team will spend days filling up whiteboards with the solution that models the problem domain, but anyone with experience will tell you that once you get into the guts of a problem you realize that things need to be changed. This is fine, in fact this is a sign that you are solving the actual problem and not the ideal one you began with, don’t worry about changing your solution to meet the realities of the domain. The problem though is making these changes first class citizens and not some weird third class monster thrown into the mix.

Have you ever been on a project and heard a conversation like this?

New Developer: What is X?
Grizzled Veteran: X is what we refer to internally as Y
New Developer: Why do we call it Y internally but X on the UI
Grizzled Veteran: Time constraints… budgets…. other misc. bullshit
New Developer: *mental note: X is called Y sometimes*

BAMMO! There’s some nasty impedance mismatch there. The problem is not so much in what we display to the user, or what our object properties are called, or what the database columns are named, the issue is that we have made our mental model convoluted. At the heart of all these systems we build as software developers is some sort of mental model, at runtime this is expressed in system as an object graph, for persistence it is expressed as a collection of tables and relationships, but all of these things are just a representation of some mental model.

artist depiction: working with an elegant mental model

artist depiction: working with an elegant mental model

When our mental model is internally consistent and simple and elegant, it makes life easy and happy and unicorns shoot out of our monitors and everything is sunshine and puppies. When your mental model gets convoluted it can be an awful and bewildering experience. The problem comes from an increased overhead, instead of the mapping from one representation to the next being clear-cut, the developer has to carry around a hashmap in their skull mapping various representations of their mental model. The difficulty of carrying out even trivial tasks is increased as the mapping from X -> Y -> Z -> Q -> P takes place.

impedance mismatch vs. coupling: battle to the death

impedance mismatch vs. coupling: battle to the death

So let’s just name everything the same and go home, problem solved. Oh, if it could only be so easy, the problem is that on the other end from impedance mismatch is a devilish little troll named coupling. Coupling is the amount that two pieces of software are intertwined, they could be tightly-coupled wherein changing one requires changing the other, or they can be loosely-coupled all the way to the point of being considered decoupled or orthogonal. Orthogonal pieces are nice to work with because you can change one and know that you won’t have side-effects on other pieces. Orthogonality goes by some other names: encapsulation, modularity, and decoupled, it is generally considered a Good Thing© and I make no argument against it.

We now have these two seemingly opposing forces, we want to decrease impedance mismatch without introducing coupling, what should we do? There are many ways to deal with this issue, let’s look at a few.

Adapters are nice little pieces of code (also called wrappers), that allow two different things to look the same. Let’s assume we want to write some code to manage users, users have a name, an address, and an age. The developer of the class decides that this object can be pretty simple.

class User {
  public $name;
  public $address;
  public $age;
}

The database developer decides that he loves structured data and that this should be broken out into all kinds of columns and tables.

table user (
  user_id int autoincrement primary key,
  first_name varchar,
  last_name varchar,
  addr_street varchar,
  addr_number int,
  addr_city int foreign key,
  addr_zipcode int,
  age int
)

table city (
  city_id int autoincrement primary key,
  city_name varchar,
  state_id int foreign key,
)

table state (
  state_id int autoincrement primary key,
  state_name varchar,
  state_abbrev varchar
)

We could create an adapter class that bridges the difference, for brevity’s sake I won’t include the code for it, but it would basically translate strings into database fields, as the application developer I get to imagine the database as mirroring my object, even though it doesn’t.

ORM – ORM’s are like automatic adapters. They are not without their faults and some implementations are better than others, but they mask the complexity of marshaling data and reduce the impedance mismatch.

Convention over Configuration – This was made famous by Ruby on Rails. There is some strong convention that you follow that allows for a consistent mapping between domains, an example would be that tables are always named the pluralized version of the class name.

There is no silver bullet to solving the problem of impedance mismatch, but a combination of the above can help limit it. The best thing you can do is be aware of the problem, don’t introduce impedance where it is unnecessary, and never be afraid to ruthlessly refactor out impedance mismatch when you find it. Keeping impedance mismatch low increases developer productivity, lowers the bar for bringing on new people, and makes unicorns leap out of your monitor farting rainbows.