Monkey Opus

High Geek Humor

Fri, 07 Sep 2012 09:30:00 -0400

Brett: ls
Brett: sorry, wrong window!
Sean:
stuff.txt
music.mp3
todo.txt
Sean: -bash: sorry: command not found
Brett: lol
Sean: -bash: lol: command not found
Brett: lol >> /dev/null 2>&1
Sean:

Git Better

Fri, 15 Jun 2012 09:01:00 -0400

Git (along with the GitHub web app) is the best version control system I’ve ever used. And it’s not even close. Git is so much better than all the version control systems I used before it (SVN, Perforce, SourceSafe, CVS and RCS) that it’s hard to compare them. They don’t even seem to be the same kind of products. It’s like trying to compare a train and a cruise-ship because they both happen to be means of transportation. I just have to exclaim, “It’s BETTER!”

Besides a better personal and team development workflow, git and GitHub have been instrumental to opening up the open source world to wider participation. It’s hard to find a working developer who uses git and GitHub, and hasn’t contributed to an open source project. That just wasn’t the case a few years ago when SVN ruled the scene and contributions were by emailed patches rather than pull requests. The ability to own your own version of a project with 1 click of the mouse (or entry at the command-line) and the ability to contribute back your improvements with 1 click, with neither click requiring permission, has been transformative.

All that being said, git still gets lots of well deserved flack, and not just from proponents of other distributed version control systems, like Mercurial (which I’m sure is great too), but from git’s users. Yes, there are lots of ways git could be improved, and it seems to be getting better all the time, but one thing I’ve not seen discussed is better handling of in progress changes on a single machine.

Git’s greatest strength, making branching easy and common place, leads to personal and team workflows that involve a lot of moving from branch to branch. When every feature and fix gets its own branch, and you are participating in code reviews, and handling pull requests and doing all the wonderful things git makes possible, you can be switching branches dozens of times a day, even dozens of times an hour. The problem is your uncommitted changes come with you from branch to branch! This is madness.

Just commit them or stash them you say? Sure, that is the current idea. When you need to change branches you have some choices, commit or stash, lose the changes or take them with you. But why not leave them where they are?

Your change is incomplete. It’s in progress. Committing broken, half done things feels wrong. Stashing? It’s fine, but it’s manual, time consuming and error prone. It’s a hassle. Taking changes with you is not always an option (if the other branch conflicts) or a good idea (if the changes have nothing to do with the other branch). Why not just have a smarter git that lets you leave them where they are?

I want to checkout a different branch and have my in progress changes to the current branch just stay where they are, as uncommitted changes to the working copy of that branch. When I change back to the branch later, my changes are sitting there just as I left them, ready for me to pick back up that work. You can’t tell me this isn’t how git should work! It just makes sense.

Occasionally you do want the changes to come with you, and there is backwards compatibility to worry about, so it can probably be a flag:

git checkout -keep <other branch>

-or-

git checkout -leave <other branch>

-or-

git checkout -stash <other branch>

I’m no expert on git internals, and I’m sure git would need to do some fancy things to pull this off. I can imagine reusing the stash feature to implement the mechanics of this, but preferably in a way that’s cordoned off from the normal stash so that the stash continues to work as is today and doesn’t get cluttered up with these auto-stashes.

I could be completely off on the implementation details, but I’m not off on the desirability of this feature. What say you git developers?

Not a git developer but think this is a wonderful idea? It can probably be done as a wrapper. Send me the GitHub link when you have it working! :-)

Shaving the Yak (or why software development is so distracting)

Thu, 19 Apr 2012 08:29:00 -0400

tldr; software development is prone to distractions as new tasks spin out from the original task. Developers should try a productivity aid (just a notebook, text editor, or outliner to start) to help them manage this phenomenon, mainly by increasing their awareness of the issue as it happens.

For non-developers that might be reading this, the call stack (or just stack) is the place where an executing program keeps track of what it is doing. When part of a program calls to another part of the program, an entry is placed on the stack so that when the other part of the program is finished, the program returns back to the original point where the call was made, and the program continues on from there. This layering of the stack as one procedure calls another which calls another, and so on, can get very deep. The stack can get so deep in fact, that the execution of the program must be abandoned. When this happens it is called a stack overflow (which is where the name for the software development Q&A site comes from).

Why mention this (simplistic) definition of a call stack? Because software developers often use the stack as an analogy to the functioning of the human mind. You start one task and realize that to complete it, you need to do some other thing, but to complete that other thing, you need to first do a third thing, and so on. When this happens, your mind is acting like a call stack. What you really want to do is task A, but you are actually working on task C, because task C is needed to complete task B, which is in turn needed to complete task A. You have to keep track of all of this.

Let’s consider filling out your income taxes by way of an example. You want to complete your taxes on time, but to do that you need to have a list of all your deductions, and to do that you need to know what your out of pocket medical expenses were, and to do that you need a receipt that you are missing from your dentist, and to get a copy of the receipt you need to call them, and to call them you need to find their phone number. So you find yourself Googling local dentists rather than completing your taxes (frankly, you’d be better off texting them). In a sense you are completing your taxes by Googling for dentists, but there are some important risks you start to face when your call stack gets this deep.

One risk is analogous to stack overflow. Your stack gets so deep that you can no longer keep track of everything. It could be that you find yourself so far removed from your original task that you can’t remember what all the intermediate steps were, or you just abandon the whole affair because the original task starts to feel hopelessly remote. Here’s an example of what this can feel like, “Let’s see, I was originally sitting down here to work on my taxes, and I just now found that email from Frank from back in September, once I Googled a solution to getting my email search working again, and tried the third solution after the first two didn’t work, and I down-voted those and up-voted the third one, so I now see that the Dallas meeting was in September, and that means that my hunch was right, Jeff couldn’t have been there and hmmm… why do I care if Jeff was at the Dallas meeting? What’s that got to do with my taxes?”

Another type of risk of a deep stack is that one of these sub-tasks becomes huge and time consuming to complete. This is very common in software development. So common in fact that software developers have special names for this: a rat’s nest, a rabbit hole, or yak shaving. Whole companies have been built as a side effect of this common phenomenon. Developers come up with a good solution for problem C, so they can get task B done, so they can build product A, only to realize that the benefits of a solution to problem C actually make for a more compelling product (or at least one that’s already built).

This morning, I found myself in this ridiculous call stack:

13. Googling lots of links to put in this blog post because I’m a compulsive hyperlinker.

12. Writing this blog post because I realized how deep my call stack had gotten this morning, and feeling like it was a common and vexing problem that all of us, but especially developers, regularly face. Maybe by examining the problem, describing it, and thinking about possible solutions, I can help myself and others.

11, Googling for solutions on how to get Cabal (a Haskell package manager) to use gcc on the Mac when it’s not in /Developer/usr/bin/gcc. Answer: use a sym-link as specified here.

10. Using Cabal to install pandoc, a markdown converter written in Haskell.

9. Using pandoc to convert a textile gist I found and forked that documents Sublime Text 2 keyboard shortcuts

9 (aborted). Trying to get Marked to use RedCloth to render textile.

8. Trying to get Marked to render the local version of the shortcut reference.

7. Trying to move the shortcut reference, so I can edit and preview it locally in Marked rather than as a gist because I’m worried I’ll lose track of the gist.

6. Modifying the shortcut reference I found to contain just the shortcuts I’m likely to use in an order that makes more sense for me.

5. Googling for shortcut references for Sublime Text 2.

4. Looking up Sublime Text 2 keyboard shortcuts so I can get more comfortable with Sublime Text 2.

3. Working to get more comfortable with Sublime Text 2 so I can use it rather than TextMate.

2. Switching away from TextMate because the Clojure and Common Lisp support is not really up to snuff.

1. Setting up a reasonably productive Clojure development environment that’s not Emacs (my wife won’t let me grow a neckbeard).

Meta-goal: Start to work more with Clojure for use on some projects (and tangentially Common Lisp because I’m not a big fan of the JVM).

At some point I got deep enough in this stack to realize I was in trouble, but it took the reconstruction of this call stack just now to realize how much trouble I was truly in (I’d have guessed my stack was about 4 deep).

Q: Given a stack this deep, how much time has gone by?
A: About 3 hours.

Q: How much have I got accomplished towards my original task #1?
A: Almost nothing.

Q: How often has this happened with the task #1?
A: This is the second day in a row; different call stack, same result.

Q: Sitting there at task #11, what are my chances of getting back on task with the original goal?
A: Very low.

Q: How many of these calls where unavoidably necessary and how many of them could have been skipped to stay on task?
A: This is a judgement call, but from #6 on, I was pretty far off the rails.

Q: If any of these tasks turned into a rat’s nest and started taking more time than their value towards the original task warranted, would I have been aware and known to turn back?
A: No, in fact #6 turned into a rat’s nest but I plunged ahead anyway.

So what could have improved this? I think the solution to this problem lies mostly in increased awareness. If someone had tapped me on the shoulder, described the call stack I was in, and asked, “Is this a rational plan to achieve #1?” I would have blushed, said “no”, and immediately adjusted my activities.

I sometimes serve this role with my co-workers when I notice some task is taking a long time or when they come to me asking for help on some issue that seems very remote from what they are ostensibly working on. My first response is often to ask them to recreate the stack so we can decide together if some of it needs rolled back.

Usually no one is there to prompt us to be more efficient so we need to be able to prompt ourselves. We need to develop a self-awareness of this common and productivity sapping pattern. How might we do this?

I’m going to try doing it with a textual call stack. As I work, I’m going to jot little notes about what I’m doing, why I’m doing it, and when I started.

1 - 5:17 AM - Setup a productive Clojure environment
~~2 - 5:17 AM - search the web and read about Clojure/REPL/editor integration~~
2 - 5:25 AM - Setup Sublime Text 2
~~3 - 5:25 AM - D/L Sublime Text 2~~
~~3 - 5:26 AM - Read about Sublime Text 2 extensions~~
~~3 - 5:31 AM - Install Sublime REPL extension~~
3 - 5:31 AM - Configure Sublime REPL extension for use with Clojure
4 - 5:32 AM - Google error with Sublime REPL and Clojure

If this method, once iterated upon, proves to be effective, I’ll consider creating something that helps with the process. I can imagine that help with automatically entering the time and depth, calculating the elapsed time, “popping” the stack, getting alerts when too much time is spent on deep tasks (too much time probably being relative to depth of the task) and help with task switching (freezing one stack so you can resume work on another). All of these could probably be very beneficial to this process, but at this point the minimally viable tool to try this out is a notebook or text editor window in a very prominent place.

Is this a good idea? Let’s discuss it on HackerNews. If do you try it out, let me know if it helps you and I’ll be sure to report back on my results too.

Update: I’m going to use Tree for the Mac (a left to right outliner) rather than a text file so that “calling” and “popping” are easier and so my call stack depth (how far in the weeds I am) is more visually apparent.

Snooty Monkey: Andrew's Perspective

Fri, 07 Oct 2011 17:06:00 -0400

Guest post by Andrew, one of the Snooty Monkeys.

I met Sean the same year that Snooty Monkey was started. At the time, I was working on a digital textbook application called ezLearnz, while working at a day job that had nothing to do with software. Sean was also working on an education app called Live Syllabus, while working a day job at IBM. We saw the possibility of a 1 + 1 = 3 situation… known as a synergistic relationship in the corporate world we were working in at the time.

Sean and I met regularly on Saturday mornings for more than a year. During this time, Sean mentored my process of becoming a software developer and we discussed educational topics, including an idea very similar to what is now P2PU. We realized we were both passionate about products that simplify and facilitate education and learning. In the end, we did not continue to pursue either of our education apps; we realized the education landscape was changing too rapidly, and what was missing from existing products was a revolutionary user interface that would radically improve users’ learning experience. During this time, I started getting interested in self-improvement apart from our discussions on the subject.

A year later, I started contracting for SnootyMonkey. Our discussions on education continued, but at this point broadened to self-improvement, philosophy, maximizing global happiness, and other interesting thoughts.

Recently I’ve become interested in the softer skills of web app development, particularly marketing. I like the idea of becoming a well-rounded web app generalist… being able to not only create an awesome app, but find people willing to pay for it. Luckily, Snooty Monkey happens to be in need of a suitably Snooty (yet open, transparent, and ethical) Marketer. And applying Snooty Monkey’s new tagline, “Simple Self-Improvement for a Complex World” to my own career, while improving Snooty Monkey, is just so deliciously recursive. Stay tuned for more Simian Snootiness as I work to figure out ethical web marketing!

A New Direction for Monkey Opus

Sun, 02 Oct 2011 18:35:47 -0400

The Snooty Monkey tagline is a common household phrase of course. But just in case anyone reading this is a recent immigrant from Papa New Guinea, or just concluded a multi-year NASA space travel deprivation experiment, the tagline is, “Simple Software for a Complex World”.

As of this moment, Snooty Monkey has a new tagline, “Simple Self-Improvement for a Complex World”. Why the new tag line? The old tagline reflected a clear mission in 2008, let me take my skills as a “software product person” and build a self-supporting consultancy, lest my family starve to death. The new tagline reflects an aspirational change here at the end of 2011, and it better fits the broader original goal of Snooty Monkey, which was to create a bootstrapped software company.

This brings me to the actual topic of this blog post, changes in Monkey Opus (which happens to be the very blog you are reading). In the past Monkey Opus has not been terribly focused. There has been a mix of entrepreneurship, product management, and technology topics. Moving forward, the focus will narrow. It’s not that entrepreneurship, product management, and technology topics will never be discussed here. I certainly won’t be able to always resist that temptation, but the major focus of Monkey Opus is now self-improvement.

Why self-improvement? Because it’s what Snooty Monkey is all about as a software company. We are all monkeys. This life of ours is our opus. Let’s be snooty about it and make it a good one!

Snooty Monkey: Lessons Learned

Tue, 27 Sep 2011 17:54:00 -0400

Snooty Monkey was started in 2008 as an experiment. The focus of the experiment? Can a CTO / Lead Developer / Product Manager type (that’s me by the way) create a hybrid micro-ISV / consultancy company? One that purposely stays small (just me? me and 2?), while serving a niche client base (bootstrapped entrepreneurs) with a niche service (temporary technical co-founder). Can doing this afford me the time to experiment with software products of my own without the traditional startup pressure that each one be a hit or the whole company fails?

Unlike a good experiment, where things are tested one at a time and variables are controlled, by necessity this experiment had lots of variables and was chaotic at times. The grand experiment is far from over, in many ways it’s just begun, but some of these experiments have now run their course, their questions have been answered and the results are ready for review and confirmation by the rest of the scientific community. It’s time to refocus the lab on new questions.

So, what has been tested so far with Snooty Monkey? What were the hypotheses? And what can now be concluded?

Experiment: Can I support my family without a “job”?
Hypothesis: Yes.
Conclusion: Yes. I’ve worked for myself since early 2009. I have yet to take the plunge and hire an employee, but Snooty Monkey is the main source of income for a few contractors (I call them friends though).

Experiment: Is there a market for a freelance “temporary: technical co-founder / CTO / lead developer / product manager” in the bootstrapped entrepreneur community?
Hypothesis: Yes.
Conclusion: I can say in no uncertain terms that many non-technical founders of bootstrapped startups will be willing to partner for some or all of the technical aspects of their business so they can focus on what they do best, eventually replacing Snooty Monkey with their own technical team when the business finds product/market fit and needs to scale. If you have the skills, drive, maturity and experience to make a good technical co-founder, there is a market for you services for cash rather than equity. In these 3 years, about 80% of the work and about 90% of the revenue for Snooty Monkey has more or less fit the experimental description. At times I’ve done work for big companies (mostly sub-contracted through interactive marketing firms) and for venture-funded startups, and almost without fail, this work has been less rewarding and fulfilling for me and less successful for the company. At the end of the day, I’m a technical entrepreneur. If I’m doing something else for you, you’re probably not getting as much bang for your buck as you should and I’m probably not having as much fun as I should.

Experiment: Can I pick and chose the projects I want to work with to fit my technical interests?
Hypothesis: Yes.
Conclusion: Yes. When I left the Biggest Blue Java shop, I made a promise to myself not to work with technology I don’t like. I’ve built many Ruby on Rails and Objective-C products, and I’ve got projects with Erlang, CoffeeScript and even Prolog in them, all of which I really enjoy. The couple of side trips into C++, Flash, Flex, and Java have been few, brief and mostly self-inflicted (Ouch, I forgot how much that sucks! Note to future self…).

Experiment: Can I pick and chose the projects I want to work with to fit my interests?
Hypothesis: Yes.
Conclusion: Mostly no. My main interests are self-improvement, philosophy, literature, sports, alternative software development technology, and education. I’ve had some luck building products in the field of sports, but other than that, I’ve not had much interest aligning my interests with my bootstrapped entrepreneurs’ product needs. I’ve built many branded marketing apps. I’ve built scientific apps, quality assurance apps, customer service apps, healthcare apps, etc. All of these have been very interesting in their own right and I’ve learned a ton with each one. But when I work on my own products as Snooty Monkey, I have a perfect fit with my own interests (Snooty Monkey’s two current products are in self-improvement and sports). This kind of alignment is a powerful force that should not be undervalued.

Experiment: Can I mantain my own high ethical standards while contracting my time to others?
Hypothesis: Yes.
Conclusion: Mostly yes. I’ve been extremely impressed with the character of the entrepreneurs I’ve been fortunate to work with. I regularly hear and read about startup horror stories starring villainous and greedy entrepreneurs. But the entrepreneurs I’ve met and agreed to work with have been some of the most upstanding people I know. They’ve been impeccably fair to me and to their customers. I’m close to suggesting a hypothesis that entrepreneurs are better people on average than society at large would lead you to expect. The one exception to charting my own ethical course has been in the area of software patents. Unfortunately I’ve not seen eye to eye with some of my very best clients about the nature, value and ethical standing of the broken US patent system. The work I’ve done in just the last 3 years has led to over a dozen patent applications, many of which I directly helped formulate (Snooty Monkey does work for hire so those patents belong to the clients). I’m not proud of this. It is a case of my deeds not living up to my thoughts and words. I’m considering declining to directly participate in software patent activities in the future. This could cost Snooty Monkey valuable business.

In looking back over these questions, I find it a bit difficult to remember how scary and unknown they seemed at the time, I can’t help but be pleased at how things have turned out.

The risk I now face is that I become complacent. I’m my own boss, I have a decent income, and I get to work with great people, my team of contractors and bootstrapped entrepreneurs, who want nothing more than for me to succeed. After all, me succeeding is the only way my clients get to succeed. There are no politics, no ulterior motives, and no bureaucracy. It’s the business of software in its purest form. Just them and their idea and me and my keyboard.

In some sense then, I’ve become too successful at what I do now, which is helping others build software companies without taking or before taking investment. This is now an 80-hour-a-week job for me. I could do nothing else for the foreseeable future. But it’s not what I set out to do. It was all a means to an end. That end being to build my own bootstrapped software company. And not just any software company. I want to create software products that help me improve my life, and if all goes well, help others improve their lives in the same way.

I’m ready to admit that I’m no longer making any progress on this. I’ve done some really amazing and cool things since starting Snooty Monkey. I wrote a book, I created some great products, I’ve even helped create what are now some great companies. But I need to get this train back on the original track. I need to better balance the two parts of my business. I need to manage my goals, my time, my tasks and my attention to achieve more. I need to improve myself. I need to be better.

I owe this to myself, I owe it to my family, I owe it to Snooty Monkey’s contractors, clients and current and future customers.

During the last couple of weeks I’ve been working with Andrew (one of said contractors) on the seeds of a new plan. This plan is going to germinate and change and grow (or shrivel and die) here in the open on this blog. Get your popcorn ready! It’s going to be an exciting show.

Build Erlang R14Bx on Mac OS X Lion

Wed, 27 Jul 2011 08:42:00 -0400

Usually to build software from source on Linux or Mac OS X, you follow the pattern:

./configure
make
sudo make install

When trying this on Mac OS X Lion you’ll find that make is no longer part of the OS like it was with Snow Leopard and before. Instead, it is part of Xcode 4.1 or greater. So you need to head to the Mac App Store app and get your free copy of Xcode 4.1 (or greater) so that you’ll have make installed.

Another wrinkle, specifically for getting Erlang from source, is that there are some obscure flags you need to use with configure to get Erlang to build cleanly. This sequence works (tested on Erlang R14B03 and Lion 10.7 (11A511):

CFLAGS=-O0 ./configure --enable-darwin-64bit
make
sudo make install

Thanks to the community on the Erlang questions mailing list for collaborating on this solution. I’m just passing it along.

Erlang's Treatment of Memory and Threads

Wed, 13 Apr 2011 11:08:37 -0400

Erlang's Treatment of Memory and Threads:

This is a good, short post on Erlang’s unusual treatment of memory and threads. Substitute “Ruby” or “Python” for “Java” if it makes it easier for you to understand and none of the comparisons will be much different. It serves to explain why you overlook Erlang’s quirky syntax (which I happen to mostly like) when you need extreme concurrency.

Bringing Serendipity Back

Wed, 16 Mar 2011 08:13:00 -0400

If Timberlake can bring sexy back, then I guess dictionaries can bring serendipity back too. I’m a regular user of online dictionaries and they all seem about the same to me (which is to say, somewhere between pretty bad and awful) so I use them through Google rather than having a go to favorite. I search for the word and then pick one or more of the top 10 hits to look at.

Today a search on the word “monotonist” (I know what it should mean, but I said it the other day, and then wondered if it was actually a word or if I just made it up) brought me to this fairly gross site - http://www.websters-dictionary-online.com/definition/monotonist (linked with nofollow to avoid giving them any link juice). I’m certain, due to the suspicious lack of branding, the poor performance of the page loads, and the dubiousness and quantity of its ad content, that it’s not actually associated with Webster’s (which is here - http://www.merriam-webster.com/).

What caught my eye was this part of the page:

How cool! I can’t begin to count how many hours I spent unintentionally reading the dictionary as a kid. I’d ask my parents how to spell a word, or what a word meant, and they’ d inevitably answer “d-i-c-t-i-o-n-a-r-y” or “it means you should look it up”. I’d traipse over to the family set of the Funk & Wagnall’s encyclopedia (bought from the grocery store on subscription, those were the days!) and its accompanying dictionary (in 2 volumes) and look up the word. Once I found my word, I could never resist the siren call of the other words on the page. Mixed among the handful of words I knew were amazingly short words, gigantic polysyllabic monstrosities, foreign words without enough vowels or with too many vowels, and words with accompanying black and white pictures, line drawings or maps. Each trip to the dictionary was a multi-paged odyssey through the English language.

Sadly, I doubt my kids, lifelong online dictionary users, have ever experienced this. The Web was invented to provide better context; the raison d'etre of the hyperlink and the subsequent Web server and Web page was to provide context to referenced concepts with just one simple click. But what these online Web dictionaries don’t have is page context. What else is on this dictionary “page”? What is on the “opposite page”? The “next page”? The “previous page”? And why are these words near one another? Is there a shared prefix or root? A shared word of compound words?

Links and the power of the Web to provide context are used in every online dictionary page and it would be hard to argue that the Web doesn’t provide a much better experience for exploring a specific word. You have links to antonyms and synonyms and etymology and stems and related words, and, and, and… But what about the words that are “physically” near this one? I haven’t seen an online dictionary attempt to provide this until stumbling on this shady site.

The “nearness” of words is an important concept in my brain’s structure and in my understanding of English. I don’t think I’m alone in this, but I do think that in the span of just one generation we’ve probably lost that part of the organizational structure of our language in our brains. It’s a shame. We shouldn’t go back to paper dictionaries of course, but there is something for the other dictionary sites to learn from and improve on in this site’s listing of adjacent words.

This is not healthy. All but one (#7 Angry Birds) of the top 10...

Sun, 13 Mar 2011 23:14:00 -0400

This is not healthy. All but one (#7 Angry Birds) of the top 10 grossing applications in the Mac App Store are from Apple.

Also not good: when my daughter asked about the mind mapping tool I use, I told her to get it from the Mac App Store, and then my wife and son looked at me puzzled and said, “You mean in iTunes?” These are two long time Mac users.

Why exactly did the Mac App Store need to be a separate application?

Settling for (the Right) Mediocrity

Mon, 17 Jan 2011 08:24:01 -0500

Settling for (the Right) Mediocrity:

Smart stuff from the folks at Working Software:

What is it that you can compromise on that people may expect, in order to deliver what you consider to be exceptional in a period of time that fits your budget and release schedule? … they may be willing to forgo such pleasantries if you deliver them some quality in your application which they consider to be exceptional. The key to living with mediocrity, releasing software and, hopefully, making money is to figure out which bits of the application you’re building can get away with being mediocre, then spend all your time working on the bits that will make your product exceptional.

Apple is Not a Software Company

Sun, 02 Jan 2011 10:16:00 -0500

Marco Arment, the founder of Instapaper and former tech lead at Tumblr recently wrote that there really isn’t much of a market for tablets, just for iPads. I have no bone to pick with his main point, he’s right about that. But part of his analysis is way off base (the bold emphasis is mine):

And, like they’ve done so far with Android, the hardware manufacturers will continue to attempt to make their own user-facing applications and front-end interfaces, but these usually suck. (Other people may describe “suck” with kinder, apologist adjectives like “getting better” and “not bad”.)

These manufacturers aren’t software companies: they’re hardware companies that write software out of necessity. Apple is a software company that makes hardware out of necessity. The software side of a modern computing platform is far more difficult and expensive to create and maintain than the hardware. Anyone can cobble together the same processors, DRAM, flash, and radios as Apple, put them into a plastic case, and run a commodity OS on them with slight front-end customizations. But not everyone can create an entire software platform.

Apple is absolutely not a software company that makes hardware out of necessity. That sells Jonathan Ives and his team of brilliant industrial engineers short. Creating innovative hardware is still very hard. Copying Apple’s hardware is easier, but still difficult; it takes a few tries to get right.

I can see where Marco is going with this, he wants to paint a simple picture of two types of companies, hardware and software companies. He wants to put Apple, Google and Microsoft into the software category and all the other tablet makers that use Windows and Android such as HP, Dell and the Asian manufacturers into the hardware category. He then wants to say good software is really hard and good hardware is really easy, so the tablet manufacturers that aren’t software companies are stuck. Apple makes their own hardware so it works fantastically well with their software, but the hardware companies are forever disadvantaged because they can’t make software that will will work fantastically well with their hardware.

This is just not an accurate picture though, Apple is not a hardware company dabbling in software or a software company dabbling in hardware. Apple is the last of a breed of something we used to have a lot of, a systems company. Systems companies create systems composed of hardware and software.

I’m not sure how old Marco is, but I’m guessing he’s a bit younger than me because I can remember a time when the computing landscape was dominated by systems companies: IBM (z/OS, RS/6000 and AIX, PS/2 and OS/2), DEC (VMS), HP (HP 3000, HP-UX), SUN (SPARC and SunOS/Solaris), Silicon Graphics (IRIX), Apple (Mac), Be (BeOS and Be Machine).

In a classic disruptive move, Microsoft and it’s flock of PC OEM’s (Dell, Gateway, Acer, etc.) killed off the systems companies one by one, either outright, or by forcing them to abandon their systems (HP, IBM except for the mainframe) in favor of becoming a Windows OEM. Apple is the only one that survived as a systems company at a time that didn’t favor the systems companies; hardware compatibility was king and hardware innovation was static (More’s Law was driving all the innovation).

Now that Moore’s Law is breaking down and innovation in hardware form factors and interfaces is back on the top of everyone’s agenda, it’s a great time to be a systems company again. Apple is outperforming their technology peers, and we all want iPad systems, not some hardware devices running Android or Windows software.

The Golden Football

Fri, 24 Dec 2010 07:47:43 -0500

The Golden Football is a new description by Evan Miller of the economics of GroupOn. The idea is that GroupOn moves the economic activity to the right of the normal micro-economics price/demand curve by offering up a lower price than the market has settled into charging for that particular good or service in exchange for a higher volume than the market would normally demand for that good or service at that lower price.

The Golden Football is formed from happy customers getting a price lower than they’d pay…

And from business getting more quantity of sales than the price would normally generate, and therefore more profit.

It’s an interesting model, and very different than the loss leader / lifetime customer value story that’s normally told about GroupOn.

All the graphs and the model are courtesy of Evan, I’m just trying to spread the word so that hopefully some enterprising economist will test the model or some entrepreneurs will validate it by applying it in new ways.

The $20 Starbucks Test

Thu, 23 Dec 2010 11:06:00 -0500

A couple of weeks ago I had the good fortune to meet Hugh Crean, the ex-CEO of Farecast, ex-Microsoft executive (they acquired Farecast) and current Entrepreneur in Residence at General Catalyst. A group of us talked to Hugh for close to an hour, and I learned more about the travel industry in that short span than I’ve learned in a lifetime of flying, hoteling and using Kayak, Priceline and the like.

The purpose of our chat with Hugh was to get some feedback on a project we are working on, and Hugh shared a cool $20 technique for validating your new product, service or startup idea that I’d like to pass on. Here is how it works:

Get yourself a nice crisp $20 from an ATM
Go down to your neighborhood Starbucks
Walk up to strangers with empty coffee mugs and tell them you are worried about your brother, need some advice, and can you buy them a cup of coffee in exchange for a quick 5 minutes of their time. (This will be awkward for most of you to do. Get over it. The “worried about my brother” line is a bit of psychology that means most people won’t turn you down. If they do turn you down, you just got a point in the Rejection Therapy Game anyway, so consider yourself lucky).
Buy them a simple coffee, not a mocha-whippa-frappa-latta-chino; you want your $20 to last.
Explain that your brother has a crazy business/product idea, and that he’s about to get a 2nd mortgage on his house, raid his 401k and quit his job. His wife is a nervous wreck, afraid that they’ll lose their house and retirement fund, and he’s hit your parents up for seed money that they really can’t afford to lose. Your parents and your sister-in-law have come to you for help to try to talk him out of his hair-brained scheme.
Explain that this is where they come in, your brother is a very logical and reasonable guy, and can be convinced by good reasons, but he has been blinded by thinking this is a really good idea. The problem is, you sort of agree with him, so you need some really solid reasons to give him as to why his idea won’t work, and why he shouldn’t proceed with his plan. Then… pitch your idea! Sell it the best way you can. Respect their time (you asked for 5 minutes), but give the best 2-3 minute pitch you can.
Now, ask for their reasons the idea won’t work. Keep them focused on the idea, not the backstory (they may want you to convince your brother of the merits of retirement savings or the dangers of 2nd mortgages), and really listen. Resist the temptation to argue against their objections. Then thank them heartily for their time.
Repeat until your $20 runs out.

What will you learn from the experiment?

The most likely outcome is you’ll hear mostly the same obvious rejections of your idea that you yourself have and have come to believe are surmountable. Your $20 didn’t generate any great new insight, but was an inexpensive check that you aren’t blind to an obvious shortcoming.

A good outcome, is that you hear lots of interesting and sound new objections that you never thought of before. This should give you real pause about your idea. Both its merits, if the objections are good ones, and the extent that you’ve sufficiently thought through your idea and are being realistic about it.

A not so likely outcome is that your strangers will find themselves agreeing with you and your “brother” that it is a great idea. They themselves will want to buy the product or service and they’ll start naming other people that need it. They’ll also probably apologetically offer up a few lame objections, because that’s what you asked for. In the unlikely event this happens with your idea, you probably have a real hit on your hands. Run with it!

Two quick caveats… this works best for a consumer product or service. If your idea is for a better steel retracting refluxerator for pediatric heart surgeons, then the man on the street in the coffee shop might not be a great source of insight. Also you have to get comfortable with the white lie you’ll be telling about your “brother”. If you can’t get comfortable with that, it’s understandable, but it is an important part of the technique. The negative priming and the distancing of yourself from the idea gives your coffee companion free reign to trash your idea so find some other way to provide some distance from the idea. If instead you say it’s your idea, then even when you invite criticism and honesty, people will candy-coat their feedback. Luckily our social norms will not stand in the way of them trashing your brother who’s not in the room.

"Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it."

Sun, 19 Dec 2010 16:58:06 -0500

“Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.”

- Alan Perlis

Always Be Building Your Own Products

Sun, 19 Dec 2010 08:58:00 -0500

Like many small technology companies, Snooty Monkey makes the mortgage and the payroll through work for clients while carving off time to build products. It’s not ideal, but it beats the alternatives: working a corporate job for years to save up a financial runway, or ceding autonomy to outside investors, who of course get a say in how their money is spent.

Once you have built a successful services business in a niche that matches your passions and interests (in the case of Snooty Monkey, building brand new products for entrepreneurs), you can start to ask yourself: this is profitable; this is fun; why not just do this forever?

Even if your long term goal is to have a services business (or be a freelancer) and build products for other people, you should never stop building your own products. There are important professional obligations that client work brings. Being free at times from those obligations is critical for long term success.

#1 Learn radically new stuff

When working for a client, you have an obligation to manage technical risk and to properly represent your experience and skills. Both of these work to prevent you from learning radically new stuff “on the clock”.

Managing technical risk involves choosing a sound technology that’s suited for the task at hand, that’s robust and relatively bug free, and where you have a reasonable assurance that they’ll be future development to fix bugs, fix security issues and adapt to new operating systems and language versions. You also are obliged to choose technologies that are readily picked up by someone else should you get hit by a bus. If you are the only Logtalk programmer in a 4 state radius from your client, it’s probably not a great idea to build your client’s project in Logtalk without their informed buy in.

Representing your experience and skills is all about communication and honesty. If you literally wrote the book on a given technology, say so. If you are waiting for your copy of the book to arrive from Amazon, and will know more next week once you get to chapter 2, say so! When hiring freelancers or project teams, clients are usually paying for more than your raw intelligence. Part of your rate derives from your skills and experience with a technology. If you don’t have said skills and experience, many clients won’t be interested in you learning them on the job, and others may expect a break in your usual rate until you come up to speed. This is a reasonable position for your client to take if your usual rate properly reflects the skills and experience you bring to the table.

That’s not to say a given client might excuse you from all these obligations and give you free reign to learn a risky new technology that you have no experience with on the job. But that’s a double rainbow client. Don’t expect to have them.

None of this precludes trying new things and continual improvement. You also do your clients a disservice by never learning, adapting and improving. Each project should be better than the last. Always been a Test::Unit user but want to use RSpec for the next project? Want to switch from your tried and true restful-authentication to the new hotness, authlogic? These evolutionary improvements are not what I’m cautioning against in client work. It’s the big disruptive changes that make you suck for a long time until you “get it” and that you have a good chance of deciding are a mistake and abandoning.

So how do you make those big leaps forward that require a huge step back first? Do them on your own time of course. And rather than building the blog sample from the book or some other toy project, you might as well try building a useful product. You’re going to invest the time in the new technology anyway, if it turns out to be great stuff, it’d be great if you got a fantastic new product out of it along the way.

In that vein, Snooty Monkey kicked off the development of a new product last week; the idea for it has been kicking around since Summer. Some weeks we’ll spend no time on it, some weeks we’ll be able to carve out a few hours or a whole day. Our “rule” (admittedly arbitrary) is, everything has to be new. The main purpose of the project is learning and having fun. The secondary goal is creating the product (if it was the primary goal, we’d use the tried and true technology stack).

Out: MySQL In: CouchDB

Out: Ruby In: Erlang (the 1 tiny exception to the rule, it’s new for all but 1 of us)

Out: Rails In: Nitrogen

Out: XHTML In: HTML5

Out: JavaScript In: CoffeeScript

Out: AJAX interval polling In: Comet and Web Sockets

Out: CSS In: LESS

Reader’s imaginary Socratic dialog section:

Q: Is this choice of technology driven by the needs of the project or is it a bit gratuitous? A: Uhh… the tail is wagging the dog.

Q: Will you be able to build the new product as fast as you would if you used a tech. stack in your comfort zone? A: No.

Q: Will you be able build a successful product with it? A: Dunno.

Q: Will you learn a lot? A: Hell yeah!

Q from a Geek: Is it going to work well to combine CoffeeScript with all the JavaScript generated by Nitrogen. A: Dunno, waiting for that CoffeeScript book to get here from Amazon. We’ll find out. But I think you missed the point. Go back to the top and re-read the post.

#2 Reconnect with your inner customer

The other great reason to not stop building your products is empathy. Being a “customer” of your own services stokes the flames of empathy. It’s important to walk in your customers shoes, to put yourself in the position to care about the same things they care about. Are you sitting your customer down for the three legged stool talk (“Sorry Jack, scope, time or resources; only 2 can be fixed…”) yet again? When was the last time you sat yourself down for the same talk?

Treat yourself like you treat your customers. Don’t give yourself special breaks and exceptions you wouldn’t give them. Make a budget (in time, not dollars) and try to stick to it as they have to. How easy do you make sticking to the budget? Are there things you are doing, such as lots of tangential work on the project that’s not core, or a lack of timely visibility and tracking that make it hard to stick to it? Or are you so fixated on the budget that you sacrifice the other goals of the project?

Most important to rebuilding the empathy with your clients is to scratch your own itch with the product. Build something that you are madly passionate about, and that you are the customer for. It’s easy to slip into a calloused, distanced, assembly-line mode of working when building product after product for customers. You need to rekindle the spark that comes when you are building something that you are truly obsessed with. By reminding yourself what it’s like to care so much about the outcome, you’ll be better able to empathize with your clients.

Erlang native compilation, why not?

Wed, 15 Sep 2010 10:27:14 -0400

belucid: what are the downsides of compiling Erlang native? (HiPE) Any reason not to use it all the time?
MononcQc: the native modules aren't garbage collected when loading a new version
MononcQc: also they are not portable like .beam files
MononcQc: they're slower to compile and are not necessarily faster
MononcQc: but they are entirely worth it for numerical stuff
belucid: ok
belucid: so I should run some perf tests with both
belucid: and see if it makes a diff for my application
MononcQc: ideally, yeah
MononcQc: always measure
belucid: yep
belucid: and then... if they do make a meaningful diff, the impact is that I really shouldn't plan to load new versions
belucid: and of course, need to compile for the target machine
MononcQc: oh, load new versions all you like
MononcQc: it's not a big overhead
MononcQc: just something to consider
belucid: ok
belucid: just shouldn't plan on loading new versions forever and ever then
belucid: at some point it would add up
MononcQc: yeah, but then you'll need to tear the node down to upgrade the VM
MononcQc: so I'm not sure it's actually that problematic in practice
belucid: gotcha
belucid: on days like today, Erlang R14B release day
belucid: you'll bring the app down anyway
belucid: thanks as always MononcQc!
MononcQc: no problem

The Erlang Shell

Mon, 13 Sep 2010 09:19:40 -0400

One option to running the Erlang shell when your code is in ./src, including files in ./include, and building to ./ebin is to run erl from ./src as such.

erl -pa ../ebin

All your modules are then local and can be accessed. You can include records with rr(module).

Thanks MononcQc on #erlang.

"From a single bit to a few hundred megabytes, from a single microsecond to a half an hour of..."

Mon, 06 Sep 2010 17:16:45 -0400

“From a single bit to a few hundred megabytes, from a single microsecond to a half an hour of computing, it confronts us with completely baffling ratio of 1 to 1,000,000,000! The programmer is in the unique position that his is the only discipline and profession in which such a gigantic ratio, which totally baffles our imagination, has to be bridged by a single technology. He has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before.”

- Edsger Dijkstra via Manuel Simoni

rm all the results of a find

Wed, 01 Sep 2010 10:03:02 -0400

rm all the results of a find:

I’d never had the need to remove everything found by the find command before. Since rm expects arguments, rather than piped input… it breaks the normal Unix pipe it all together paradigm.

Some quick googling brought xargs into the picture though. xargs constructs an argument list from its piped input and executes its argument with them. Perfect for what I was trying to do:

find . -name *.pyc -print0 | xargs -0 rm