Monthly Archives: February 2006

Using Ruby on Rails on Mac OS X at the Apple Developer Connection

Using Ruby on Rails on Mac OS X at the Apple Developer Connection.

The Apple Developer Connection has a nice Ruby on Rails tutorial called Using Ruby on Rails for Web Development on Mac OS X. As the title suggests, it is aimed at getting OS X users off the ground with Rails.

The Apple Developer Connection doesn’t supply any attribution for their articles, but this one was written by none other than Mike Clark, who along with Dave Thomas runs the always-sold-out Pragmatic Studio series of Ruby on Rails and Ajax training.

Cheers to Mike for taking the time out of his busy schedule to write up a great tutorial. [Riding Rails]

List of what's coming up in Rails 1.1

List of what's coming up in Rails 1.1.

Today someone on the Rails mailing list asked, innocently enough, “Is there by any chance some document available summarizing all the
(major) beautiful new stuff in Rails 1.1?” As is to be expected, he received instructions on how to do a diff between the 1.0 release tag and trunk as well as links to the CHANGELOGS. He used “summarize” carefully. Turns out there was nothing like he was looking for. Well, not for long…

Scott Raymond, of Blinksale and IconBuffet fame, rolled up his sleeves and did the dirty work for the rest of us. So, as requested, here is a summary of what will be new in Rails 1.1. Thanks Scott. [Riding Rails]

Dr. Contextlove or: “How I stopped worrying and learned to love iCal”�

Dr. Contextlove or: “How I stopped worrying and learned to love iCal”�.

A favorite topic of GTD‘ers is the contexts that we each choose to identify the times, tools, or locations by which a given task can or must be undertaken. This is a highly personalized decision, and I’ve learned a lot from seeing how other people are doing it.

Since I see it’s been a while since I’ve talked about how I’m using contexts, here’s an update that reflects how I’m now using Kinkless GTD and iCal to keep things wrangled.

Contexts, enumerated

It’s worth mentioning that a lot of my approach has been shaped by my move from Entourage to kGTD + iCal. While the actual contexts haven’t changed too much, the way I organize and think about them has evolved, as we’ll see a bit later.

The context themselves, with a brief explanation, where it’s useful or non-obvious . . .  [43 Folders]

Picking your micro-ISV niche

Picking your micro-ISV niche. By Bob Walsh, Safari Software, Inc.

Over at The Business of Software forum, Jackson asked today,

“…But the problem is – how to know what kind of (web or desktop)
app to build. How do you detect the trend that will be big, while the
trend is still in its infancy?”

Of the 68 things you have to do to be a successful micro-ISV,
figuring out what kind of app you’re going to build is first and
foremost. Get this right, a few years of sweat, toil and work may just
make you the next Google Guy; get it wrong and all that effort will be
wasted barking up the wrong tree.

Now if I had the absolute right, one-size-fits-all, ironclad answer
to this I’d package it up, sell it, and sail off to some very nice
tropical isle. No such luck. But I can suggest three pointers, based on
the research I did for my micro-ISV book, and a bit more rumination since it came out in January to get you started.

Get off the Hype Cycle.

Teenagers have cloths and cell phones, programmers have the latest
and greatest programming technology. They share one thing in common:
the Hype Cycle. The Gartner Group defined this 12 years ago as the
cycle new technologies go through, whether they’re as big as P2P VoIP
or as small as Ruby on Rails.

They cycle starts with a Technology Trigger, such as Jesse James Garrett’s seminal post on Ajax. Then it moves to the Peak of Inflated Expectations (where we are now) when everybody who is anybody or wants to be anybody is doing it and getting VC money to do it. Next is the Trough of Disillusionment,
when the shine is off the apple, the VC money runs away and people
wonder what all the fuss was about. Finally, maybe, the technology
makes it to the Slope of Enlightenment and perhaps the Plateau of Productivity where real benefits, revenue and results accrue.

Over 25 years, I’ve seen a multitude of technologies ride the Garner Hype Cycle (more info here and here). The Hype Cycle is not your friend if you’re starting or building a micro-ISV:

  • Hype Cycles and VC money were made for each other, hence the VC
    saying, “fund 20, pray for 2”. Unless you get very lucky, or can
    program very fast, your odds of catching a Hype Cycle at the very
    beginning are marginal.
  • If you miss the wave, you are going to go down. “Me too!” is not a
    revenue strategy for micro-ISVs – we usually don’t have OPM (Other
    People’s Money) to burn.
  • Micro-ISVs have customers – or hope to. Customers have problems
    they hope to have fixed. If the technology being hyped can’t be used to
    fix a real problem, it’s not going to fuel your micro-ISV.

Don’t write a product for programmers.

For most programmers who decide to go micro-ISV, the first impulse
is to write an app or tool or library for other programmers. Very
common, very human, very wrong. Now don’t get me wrong, I love new
programming tools and stuff as much as the next programmer. And if
you’ve got a genuine product that will solve one of my many unmet
needs, I’m going to poke around Google until I find you.

But as a micro-ISV market, programmers suck. Unless you’re product does something I really am impressed with,
the typical programmer is going to puff up their chest and huff, “I
could code that in an afternoon!” as they click off your web page.
What’s more, the programmer market is from a marketing point of view
dozens of tiny little programming language enclaves, each jealous of
the others.

Finally, a programming tool is not the same as a way to solve a
specific problem that people online with money actually have, it’s just
a potential: it will be a very hard sell to convince IT managers or
individual programmers that they need another tool unless they just so
happen to need that particular tool at that particular time.

Pick part of the Long Tail, and solve it well.

One of the few key advantages micro-ISVs have over existing
companies is the opportunity to look at a problem and solve it better
and deeper. The world abounds with problems solved poorly or not at all.

Think about any company you’ve ever worked work and how they used
Microsoft Excel as the application to solve all sorts of specific small
business problems. Why? Because until very recently it was just not
economically feasible to develop, market and support a solution to a
business or consumer information problem that only a few people here
and there had.

With a billion people using the Internet, and the ability to create
an instant market with the right search terms, there are tens of
thousands of problems that can be solved lucratively now by micro-ISVs.
It’s called the Long Tail, and if you don’t know about it, it’s time you get read in. The Long Tail and micro-ISVs were made for each other.

Picking your micro-ISV’s market and defining your first application
– be it for the web or desktop or mobile or PDA – is not easy, but it
is critical. I’ll have more to say down the road re finding problems
worth solving, but for now, avoiding the Hype Cycle, getting
knowledgeable about the Long Tail and not writing a programmer product
will get you off to a good start.  [MyMicroISV]

Some thoughts about one-man shops

Some thoughts about one-man shops. I noticed a post today by Rob Merrill (mostly because he linked to me in the post) on the Good Recruits blog titled Yes they are looking. I thought what he had to say tied in nicely with some of my own thoughts recently about the job I left behind.

If you are currently the boss, or the CEO of a company, which has one IT employee, you might want to listen up. What Rob had to say about “a feeling that the employee is serving everyone else, never being served.”, because that's exactly what wound up happening to me.

That was my first IT job, so naturally at first I was very excited that I was getting paid to work on and with computers all day long. I had a lot to learn, and to get up to speed on, so it kept my interest pretty well. I even relished the challenge of keeping things running that were so obviously out of date and in need of upgrading. I kind of wore it as a badge of honor that even though we had old, crappy equipment, I managed to keep things going and people were able to get their jobs done. Eventually, we finally had no choice but to upgrade and I was glad to get that experience under my belt, even if it did mean working 60 hours over 4 days.

Once that was done, however, the challenges began to get few and far between. That upgrade was in 2000. They are still using most of the equipment we purchased then. They are completely dependent on 6 year old hardware and software. There are still no plans to phase it out or replace any of it. Aside from that one upgrade in 2000 they never, in the 7 plus years I worked there, set aside budget items for technology. There was never any serious discussion about doing anything differently than the same way they'd been doing it, technology-wise. (There were plenty of discussions, but none of them ever included the go-ahead to spend any money, so I can hardly consider them serious)

On the other hand, every user and management complaint about that old technology and it's limitations, was directed at me, the person with no budget and no authority to spend money or make decisions. I was given the task of doing everything I could to make sure everyone had the training they needed to use their computers, but those same users were never held responsible for actually learning anything. In 7 years not a single supervisor ever asked me to give them feedback on the tech skills of the people who worked for them, or asked me to take part in an interview to make sure someone they were hiring had the requisite computer skills, but most of them did blame me when those same people didn't know how to do something, regardless of how many times I'd showed them.

Despite my best efforts to work on preventing break downs, to proactively deal with training issues and database maintenance, and to try and suggest ways to improve the state of the technology (which were mostly ignored anyway), most of the people I worked with saw my role as little more than sitting around waiting for something to break. A view that was obviously shared by my supervisor and other senior management, given their refusal, six months later, to actually hire another IT person because “we really wouldn't have enough for them to do”.

Which would be fine, had they not allowed me to simply walk out the door and take most of my knowledge with me. They've gotten away with that, because in the interest of parting on good terms and not wanting to leave the handful of very good friends I made while working there left hanging, I agreed to be “on-call” for them in case of emergencies or to do some things that they would have had trouble doing on their own, for 6 months or until they found a replacement. One week from today, the 6 months will be over. There are still a handful of things that I have not gotten handed over to anyone, and while I think they've found someone to call for PC emergencies, this past weekend when one of those brilliant users “accidentally” set a master password on their database library file, I was the person they had to turn to as their database expert.

Anyway, to make a long story even longer, if you find yourself supervising a one-man IT Department, you might want to take Rob's point. They probably are looking, and you probably won't be near as lucky as my former employers have been. Not to toot my own horn, but I don't know many people who would agree to still share knowledge and information six months after leaving a job, whether they were making a little extra on the consulting fees or not. It simply takes up too much time. They were very lucky in that regard, I could have just as easily left in August, pointed them to my documentation and told them to figure it out on their own. Will you be able to do that if your IT person leaves? If not, you'd better start planning for it, or do everything you can to keep him/her satisfied with their current job.

I'd do both if I were you.  [Out of the Frying Pan, and into the Cube]

Remote configure your Tiger Mac through the command line

Remote configure your Tiger Mac through the command line.

I was trying to configure my Mac’s built in Remote Desktop sharing last night through the command line. The RDC client, which is built into every Tiger Mac, was prompting me for a password when I attempted to connect using an open source VNC (screen sharing) client from my PC. So I did some research and found some very interesting information about configuring Mac OS X’s Remote Desktop (ARD) client from the command line. The kickstart command line tool referenced in the Apple KB article is included in the Remote Desktop Client and is therefore in every 10.4 Mac as well as some earlier systems.

The cool thing about it is that kickstart enables you to remotely activate and deactivate ARD connections. So as long as you leave SSH enabled and you have administrative privileges, you can tunnel into an SSH command line session on your Mac, sudo kickstart with the appropriate settings, and turn ARD on, then get the screen of your Mac and do your thing. As the discussion thread points out, this works even for Macs that have no physical screen attached, like a PowerBook with a broken LCD or a headless Mac Mini.

You can do even more with two more command line utilities included in ARD, networksetup and systemsetup, which allow you to do things like configuring the network settings and other “control panel” level settings.

I like this so much that, in combination with a dynamic DNS solution, I might throw out the rapidly aging Timbuktu client we bought to help my mother in law troubleshoot her system.  [Jarrett House North]

Another reason why mainstream media is losing readers

Another reason why mainstream media is losing readers

A Failure of the Press

we were attacked on Sept. 11, we knew the main reason for the attack
was that Islamists hated our way of life, our virtues, our freedoms.
What we never imagined was that the free press — an institution at the
heart of those virtues and freedoms — would be among the first to

This provocative quote from a Washington Post article titled  A Failure of the Press
by William J. Bennett and Alan M. Dershowitz represents another
indication that people across the political spectrum are beginning to
realize that the press has betrayed not only its duties but its

It has gone so far that the bias of the media is no longer an issue.
The real question now is where will this abdication of responsibility

Reporting opinion as news has given way to outright support of
organizations and causes which seek to destroy our American way of
life. We really don't need more enemies when the Fourth Estate is
acting like a Fifth Column or is cowed by threats. See When fear cows the media By Jeff Jacoby, Globe Columnist,  February 19, 2006.

To counter this spreading of disinformation and opinion as reality,
we should refer to original sources before passing on inflammatory
information as gospel. Otherwise we are like those clueless people who
pass on bogus spam warnings or those people who absolutely believe that
9-11 was an inside job.

This isn't a matter of political leanings. It is a necessity that we
have a free and open press which expresses opinions and presents news.
When opinion masquerades as news, there is a natural reaction in the
physical universe and we see blogs supplanting MSM media when this

What is the future?

I think there is still a bright future for mainstream media, but it
will have to clean house first. Today's news is suspect and like the
old story of finding too much rat shit in the coffee grounds, we are
looking for other suppliers of news.

If I read the Daily Kos, I know in advance what the agenda is and can sift fact from opinion. If I read Instapundit, I know I am reading a Libertarian viewpoint. If I read Anti-Idiotarian Rottweiler or Capitol Hill Blue,
I know within seconds where the writer's sympathies lie and can
evaluate whether to believe the information presented. In addition, I
can follow the links to see if they lead to actual source material or
merely to others who have similar opinions and no facts.

I think the smaller independent newspapers get this already and have
enlisted bloggers to help them stay balanced and still keep the costs

What news media do you trust?  [Ripples: post-corporate adventures]