gitorious.org - the free open source hosting service (came first)
gitorious.com - the commercial company behind it (came later)
getgitorious.com - official doc, starting point etc (recently added as a common starting point)
mattdebord and estel: I'm one of the core Gitorious committers. What specifically did you find messy? The initial setup or GUI/UX? Honest question, as we're constantly trying to prioritize based on the painpoints of users. :)
BTW we've recently addressed the complicated manual setup with a new, automated installer that gets you set up within 30 minutes: http://getgitorious.com/installer
Exact same reasons here. I love being able to suspend, resume and clone VM dev environments, and there's plenty of OS X software I really don't want to give up outside of dev work (Keynote, Sparrow, Reeder, Final cut, Pixelmator, etc..)
I was on a 11" Air until last week, transitioned to a 13" Macbook Pro this weekend. Performance was a bit sluggish when running a full Ubuntu desktop inside a VM on the Air, but feels snappy and great on the MBP.
My setup is just a basic Ubuntu desktop install inside VirtualBox (with Vbox guest additions installed). Haven't noticed any particular problems with the gfx support, but then my Ubuntu desktop is fairly basic - I only need an Emacs frame, Chrome and few terminals panes to do most of my day to day work.
I also use Vagrant to create, suspend, resume and destroy VMs when I just need something headless to deploy and test our product to.
I can relate to the OP: I like OSX for general work, but prefer Linux for programming workflow and tooling (mainly because of the debian package system). My solution from now on is to do my dev work inside a Linux VM (through Virtualbox). Seems to work well. Would love to see others experiences with similar setups, anyone else going a similar route?
http://railsplayground.com specializes in RoR hosting - they offer both shared hosting, vps and dedicated servers. Extremely rapid and competent service.
I've used them for both my startup and some smaller personal projects over the last 10 months, very satisfied so far.
Found my Better Half. Fathered my daughter. Built v.1 of http://thoughtmuse.com singlehandedly on nights and weekends, in under five months (as estimated).
Javascript: Start with Douglas Crockfords "Javascript: The Good Parts". Excellent, terse primer on safe Javascript development.
Startups: Read content by people like Peter Graham, Joel Spolsky, Rob Walling, Guy Kawasaki, Bob Walsh, Andy Brice - just to mention a few of my personal faves. Skim around, there's lots of great free content out there on software startups!
Good point, will definately look at adding some more hints/teasers of other stuff that can be done.
I'm also planning on producing some good content (articles and screencasts) on what you can do with mindmapping both in general, and with ThoughtMuse specifically.
Cheer up - Paul Grahams worldview isn't the only one out there.
Do some reading on 'mISV' companies. Google Bob Walsh, Erik Sink, Rob Walling, Andy Brice and Patrick McKenzie - all of whom have written excellent material about building viable, bootstrapped, part-time software businesses.
Also, see this excellent talk by DHH on alternatives to the classical 'balls out, big risk/reward' startup scenario:
I concur. I also use Spring at my dayjob, without the problems the OP describes.
Spring is really useful for setting up the underlying infrastructure/plumbing/cross cutting concerns of a system - however, you don't have to use it for all your domain logic too. Don't drink the dependency injection cool-aid. :)
Not sure about the comprehensive spec at page 9 though: BDUF - Big Design Up Front is often a naive approach. Requirements and constraints tend to change as you go along. Too much up front specification can be a waste if 30 percent of those features never see any use. I'm all for thinking each specific task, function and web page properly right through before coding it, though. :)
I also have trouble with "design for reusability" at page 39. Building one-off components is a waste IF you are going to build similar stuff in the future. However designing things for reuse also incurs overhead in itself that first time around. The specific project context should determine if building for reuse is cost-effective. Also, designing for reuse can be taken too far. We sometimes burn ourselves by thinking too generally - see some of the more complex J2EE frameworks out there...