Time flies when you're busy and PRODUCT LAUNCH!!
I've been insanely busy over the last 4 months (actually closer to 6...), but things have calmed down a bit now. I hope to do this more regularly.
But today I shipped a product: Experienced Man's Guide To Cross-Platform Programming with wxWidgets (Release Announcement).
The product page is: Experienced Man's Guide To Cross-Platform Programming with wxWidgets (Product Page) Think of it as a companion PDF with all my notes from using the wxWidgets book pretty much day in and day out for 3 years.
In addition to being a great resource (I hope) for the wxWidgets community, it's also an experiment: if this book sells well I'll do at least two more (one on the TextMate book and one on the 3rd edition to the Prag Prog's Rails book, after I've had some time to play, read, and transfer the notes I made in the second edition over (if they're still applicable).)
So yeah - check it out!!
libedit and vi key bindings
OS X unix commands sometimes provide a interactive prompt for users to enter text. An example would be the Python or Ruby interactive interpreters. These interactive prompts require ways for users to move their cursors around quickly. The Mac has had standard keyboard shortcuts for text fields since the beginning of time (pretty sure MPW, but don't quote me)... but, it's Unix folks! Pick an editor: vi or emacs.
In the NeXT days, those engineers picked emacs - which is why you can use, say Control-A to jump to the beginning of the line in any Cocoa text field.
But I like vi. What to do? Turns out you can turn on vi bindings for console programs (that link to libedit....) You can even add your own commands!!
On OS X 10.5 most programs are use the same underlaying code to handle interactive text input: libedit. This is a pretty obscure library, compared to the more common (on linux systems) readline.
Steps to resize a Windows XP VMWare disk image
Here are the steps to resize a Windows XP VMWare Fusion 2.0 disk image:
Yes, this is pain.
The Axiom is Wrong
So in business school, the one axiom they pounded into our heads was: "The goal of the corporation is to maximize shareholder wealth".
Which is great as far as it goes, but thinking it over tonight, it sounds a little naive. I think a better goal would be "... to maximize stakeholder wealth.". (and wealth in this sense not necessarily being money wealth. Perhaps a better word here would be "contentment", or "prosperity"
Why? Because (I believe) it will actually lead towards the goal of the first! By striving to increase the prosperity of your customers, or employees, or whomever, you should, in theory, have better word of mouth advertising (or less furious customers who shout from every treetop how much you suck), happier more efficient employees and possibly a product with more quality.
This approach seems a lot better to me than the approach of maximizing shareholder wealth... which, taken to it's extreme means moving everything overseas (where it's cheaper), using less quality parts, and ticking your customers off because the quality of your product or services degrades... with the added fact that even your old employees can't buy your stuff because they're not getting paid anymore (or won't buy your stuff because they're bitter). Which seems like it would decrease shareholder value!!
I've started something new: book recommendations at my business blog, and I just posted my first one: Book Recommendations: Python. There's going to be more, so stay tuned!!
Python and Ruby Differences: 0 == ?
So I've been learning Ruby and Ruby On Rails over the last few weeks for a new project. Today I ran across something, well, different:
Returns "0 == true". A "Gotcha!" moment for this old C hacker.
Returns "0 == false".
Investigating this a bit more:
Different Types of programming personalities and how productive they are
So I go back and forth on the idea that a programmer can be 10 times as productive as other programmers. Part of me says, "No, that level of productivity difference just isn't possible". The other part of me has been there when the better programmer solved the junior's problem in 2 minutes flat, where the junior had been dealing with this for hours. (I've been on both sides of this)
However, TiWeb/DevTopics has an interesting article out: Programmer Productivity and the Teninfinity factor, where they outline 5 classes of programmers: visionary/artist, trailblazer, workhorse, drone, and idiot. And these classifications make sense to me... and I think you need a few of each type (except idiots) on your team.