I’ve maintained a blog since sometime in May of 2005. As with many
blogs, posting regularity varied. Sometimes it was daily, sometimes a
month or two would go by with nothing new at all.
This is something different.
The content on the old site changed over time, just like it’s author.
Interests come and go, technologies that were once shiny and new have
lost some of their shine. I stopped writing short posts that were mostly
links to other people’s content, and starting writing longer articles. I
did some interviews, and a bunch of book reviews.
Then, as is prone to happen, I got busy. In the time I’ve been writing
this I’ve gone from having one child to having three. My job
responsibilities have changed. This site got a bit neglected as a
result.
So a while back I started thinking about the site, and what I wanted it
to really become. And I thought. And then I thought some more. My
thoughts evolved over time, and I’ve settled on what I’m launching here
today.
I’m a curious person, and always have been. My interests are varied, and
change often.This site is a reflection of those facts. Some of the
content from the old site has been migrated to here, much of it was not
as it was either not relevant or didn’t fit well with the new site. The
focus of this new site will be whatever happens to have my interest at
the time: mostly technology, software development, and entrepreneurship,
but extending into other areas as well. I will continue to do interviews
and book reviews, and have several of both to publish in the very near
future.
I hope to write here on a more consistent basis, but they will be longer
articles and as such it’s not likely to exceed more than once or twice
per week. I’ve created a new section just for links to interesting
things, called Curiousities, and there will be content there daily.
Twitter bashing has become a bit of a
past-time for somepeople. I don’t think that the
criticism leveled at Twitter is fair or accurate. It is generally based
on a misunderstanding of the technical problems they are facing. In the
case of TechCrunch, it’s a desire to drive traffic to the TechCrunch
website by fabricating conflict and making personal attacks.
Twitter has had a hard time scaling. This is obvious to anyone that uses
the service, and is readily admitted by the people behind Twitter. The
present problems have brought out all of the Armchair Architects, and
I’ve seen a lot of commentary stating “I don’t understand why this is so
hard, all you need to do is [insert gross over-simplification of the
problem here]”. It’s very easy to apply some 20/20 hindsight to this
problem, but another thing entirely to be in the trenches day after day
working to keep Twitter up and running while trying to make large-scale
changes to fix the underlying problems.
Here’s the thing. Twitter was started as a side-project inside Odeo. It
was developed in Ruby on Rails, the same tool that they had used
successfully to build Odeo. While this choice is a major discussion
point for their critics, it seems to me to have been a very reasonable
decision. Ruby on Rails was what they were familiar with, and at first
glance seems to be a good fit. I suspect most people would have made the
same decision, given the same situation. The bottom line: They made the
best decision they could, based on what they knew at the time. Keep in
mind that nobody even knew whether Twitter would gain any traction -
certainly none of them could have anticipated the warm reception it has
been given.
Obviously their existing architecture isn’t working. The fine folks at
Twitter have figured this out, and they are busy rebuilding the system
to handle the current load and scale accordingly. This isn’t an
overnight fix - it will take time to rebuild Twitter with all-new
innards. Let’s be patient. Frankly, the internet needs to take a
collective chill pill on this topic.
If you’re not following me on Twitter, you can remedy that
here.
One of the most useful ideas I’ve seen in the past few years was
Dashboard. Dashboard was an open source
project launched by Nat Friedman of Ximian (since acquired by Novell).
It’s aim was to provide a “dashboard” of information relevant to you
while you were doing work. If you were having an IM conversation with
your friend Bob, it would show you the last few emails Bob had sent you,
previous IM conversations with Bob, Bob’s contact information from your
address book, etc.
I had always thought that Dashboard was an intriguing concept, and one
of the few examples of real innovation on the desktop that I have seen
in a while. It was a bit dissapointing to see the project get sidelined,
but these things happen.
A project emerged
recently
for OS X that is based on the same concepts, although implemented
differently. It’s called
Shelf and
is written by Tom Insam who is a developer at
Dopplr (though all indications are that this is an
independent project and not supported or endorsed by Dopplr).
Shelf watches the applications you are using in OS X, and displays
relevent information from applications local to your computer as well as
web sites (like Dopplr, naturally). Here is Tom’s own description from
the Shelf website:
Shelf is an app for MacOS that looks at the current foreground
application, and tries to figure out if what you’re looking at
corresponds to a person in your Address Book. Then it’ll tell you
things about them. … Just run it. It’ll sit in the background, and
watch the foreground application. If it can tie something you’re
looking at (the current url in your web browser, for instance, or the
target of an open chat) to a person in your Address Book, it’ll open
a window and show you their name and picture, and it’ll try to fetch
RSS feeds for any URLs in their address card.
Although it’s a newer project (only at version .13), Shelf seems to be
off to a promising start. It provides hooks into a number of different
applications on OS X already (according to the Shelf site):
Safari - looking at the foreground url, and for microformats in the
source of the current page.
Firefox - looking at the foreground url.
Mail.app - From the email address of the sender of the currently
selected email.
NetNewsWire - From the homepage url of the currently selected
feed item.
Twitterrific - From the homepage or twitter page urls of the
currently selected tweet.
Adium - From the IM username of the current conversation.
iChat - From the IM username of the current conversation.
Address Book - The currently selected person.
This is an idea whose time has come, I think. There are obviously some
gaps here, for example if you use GMail as your email application (as I
do), or Google Reader for RSS feeds. Integrating with all of these
applications is a tricky problem, but it’s not insurmountable. I think
it’s certainly worth solving though, as the benefits could be huge.
I hope this project doesn’t fall by the wayside, as it has too much of a
potential impact on the way we work. It’s possible that Apple will
implement something similar, it seems like the next logical progression
of Spotlight.
This has been pretty well publicized, but here it is in case you missed
it. Community Engine allows you to add social networking capabilities
(profiles, photos, blogs, forums, and more) to any application simply by
adding this plugin. Extracted from live websites, so it is real-world
tested.
Awaken is a slick little app for OS X that I picked up as part of the
MacHeist bundle. I’ve used it as a timer for those occassions when I
need to force myself to work on something for “Just 10 minutes”, but
here are some other uses.
I stumbled across a great site tonight, chock full of the geekiest
videos I’ve seen. The main sources seem to be university lectures. Very
good stuff, and in a variety of disciplines such as Computer Science,
Business, Chemistry, and Mathematics.
In my time as a developer, and now managing a team of developers, I have
come to realize that there are two kinds of programmers: the Journeyman
and the Craftsman. These terms aren’t mine - I’ve seen them used other
places - but they describe the developers I’ve worked with pretty well.
The Journeyman
…knows one programming language.
…knows one operating system.
…can’t be bothered to learn something on their own.
…doesn’t know anything about the operating system or hardware their
applications run on: “Someone else takes care of that”.
…never masters his tools. “I know my way around my IDE, that’s good
enough”
…doesn’t refactor: “It’s ugly, but it works. Leave it alone!”
…only learns about the part of the system they are working on. No need
to learn the rest of the system: “That’s not my job”.
…doesn’t want to take on an unfamiliar technology: “I haven’t had any
training on x”.
The Craftsman
…knows a handful of programming languages, and is always on the
lookout for the next one he should learn. He knows that learning any new
language will stretch his mind and make him a better programmer in the
language he uses day to day.
…devotes time to learning about new technologies, and helps to make
others aware of them.
…understands the platform and operating system his applications run
on, because he knows that’s the only way to diagnose many problems.
…masters his tools. He can perform magic in his chosen editor, and is
always looking for ways to make himself more efficient.
…rarely passes up an opportunity to broaden his knowledge of the
system he is working on.
…is always willing to take on something he’s unfamiliar with. He can
pick up most things pretty easily, and enjoys the challenge of learning
something new.
One craftsman is worth three or four journeymen. Easily.
It’s the journeymen whose jobs often end up moving overseas (and
rightfully so, they add little, if any, value).
The longer I manage development projects, the more I value the craftsmen
I have around me.
I’d heard (first from Joel
Spolsky, I
believe) about a cool new travel planning site called
Tripit. I’m making arrangements for a trip to St.
Louis later this month, and so I thought this would be a good
opportunity to try it out. To say the least, I’m impressed.
The first thing that I noticed was the registration process: there
isn’t one. All you have to do is take any travel-related email
(hotel confirmation, airline itinerary, etc) and forward it to
plans@tripit.com. If the email account you sent it from isn’t already
registered with Tripit, they create an account for you and send you your
registration details. Most sites would have you create an account first,
filling out a lengthy form before you could use it. Tripit’s strategy on
this is brilliant as it removes all barriers to entry to their service,
making it completely painless.
Tripit then takes that email and creates an itinerary. I emailed it a
hotel confirmation, and it was able to extract out the hotel name,
arrival and departure dates, the city I was staying in and more. It
builds a nice itinerary out of this data, and adds some useful
information to it like weather and maps.
Tripit also allows you to collaborate, sharing your trip information
with others in your party. There’s also a social networking component.
If you add contacts who also use Tripit, you can see who else might be
close to you on an upcoming trip. I don’t really travel enough to
probably get much use out of that, but I can certainly imagine that it
will be useful to a lot of people.
One other nice feature is that it can publish your itinerary in
iCalendar format, for
consumption by Google Calendar, Outlook 2007, or Apple’s ICal. It also
appears to have good support for mobile devices, though I haven’t had a
chance to try that out. One other nerdy item to note is that they’ve
marked up many of their pages with
Microformats.
All in all, Tripit is an impressive service so far.
I would definitely recommend giving it a try - it’s as easy as it gets.
“A blog about open source technology at The New York Times, written by
and primarily for developers. This includes our own projects, our work
with open-source technologies at nytimes.com, and other interesting
topics in the open source and Web 2.0 worlds.”
There are a lot of nice posts in there, including one on how they used
EC2 to convert their archives to PDF.
Desert is a component framework for Rails that allows you to seamlessly
define in your plugins: \* Models \* Controllers \* Views \* Helpers \*
Routes \* Migrations \* Plugin Dependencies
I'm going to check this out for something I'm about to start on.
Paul Graham has released Arc, his
long-awaited Lisp dialect.
Arc is designed above all for exploratory programming: the kind where
you decide what to write by writing it. A good medium for exploratory
programming is one that makes programs brief and malleable, so that’s
what we’ve aimed for. This is a medium for sketching software.
I’ve owned the Macbook Pro for a little while now, and am getting
comfortable with OS X. I think it’s time to dig a little deeper though,
so I’m going to buy a book or two.
I’m a long time computer user, and have a lot of *NIX experience, so
I’m not looking for something too basic. I’d like something that will
teach me the ins and outs of the whole operating system, and let me go
from being “comfortable” to “power user”. I’m leaning towards Mac OS X
Leopard: The Missing
Manual, but I thought I would ask here if anyone else has any other
recommendations.
Peter Cooper (who I interviewed
recently
) has just announced SwitchPipe, which aims
to make deploying and hosting Rails (and other frameworks, such as
Django) applications easy. From the site:
Introduction / Overview\
SwitchPipe is a proof of concept "Web application server" developed in
Ruby. More accurately, it's a Web application process manager and
request dispatcher / proxy. Backend HTTP-speaking applications (Web
applications) do not run directly within SwitchPipe, but are loaded into
their own processes making SwitchPipe language and framework agnostic.\
SwitchPipe takes control of, and manages, the backend application
processes, including loading and proxying to multiple instances of each
application in a round-robin style configuration. As an administrator,
you can define the maximum number of backend processes to run for each
app, along with other settings so that you do not exceeded preferred
resource limits. SwitchPipe quickly removes processes that "break" or
otherwise outlive their welcome. For example, you can let SwitchPipe
kill any backend processes that have not been accessed for, say, 20
seconds. This makes hosting many multiple Rails applications, for
example, a quick and non-memory demanding process, ideal for shared
hosting environments.\
...\
SwitchPipe's goal is to be:
* super easy to configure * the easiest way to deploy multiple HTTP-talking backend
applications * painless in terms of management; no hand-holding of different
applications is needed * a permanent daemon that can handle configuration changes in backend
apps “on the fly” * a reliable solution on Linux and OS/X (and anything POSIX
compatible, ideally)
I haven't spent much time with SwitchPipe yet, but if it lives up to
Peter's claims this will dramatically simplify hosting
Rails/Django/Camping/whatever applications.\
What's interesting to note is that this originated with Peter's [widely
read
article](http://www.rubyinside.com/no-true-mod_ruby-is-damaging-rubys-viability-on-the-web-693.html)
on why such a thing was needed. Unlike a lot of other people who have
complained loudly about the state of Rails on shared hosting
environments, Peter put his time and talents towards creating a solution
which he then released within 3 weeks. This is
definitely something we need more of.\
So what are your thoughts? Is this the solution we've been waiting for?