SpiralLab

     var _this = this;    //vanilla
     var $this = $(this); //jQuery

Regardless - A designer that can design for any* framework with standard CSS/HTML is more flexible than a designer that knows HAML, but could't write vanilla markup.

That why I was surprised about the Coffeescript (preferring HAML is a popular opinion, as-is Rspec: yet Erb and Test::Unit are still the defaults).

Edit: I agree that alt. languages/syntaxes in frameworks are nice. Forcing them on people is not nice.

What happens when you give HAML to a non-Rails designer? Maybe it's just taste, but I feel that true markup with template tags for data (erb) is much better than a whole new markup language for designers to learn. YMMV.

What's the problem?

It's cliche, but Art of the Start http://www.guykawasaki.com/the-art-of-the-start/ explains this tactic very well.

If a business grows that rapidly - it is most likely that the original systems will have evolved dramatically from day one anyway - in ways you wouldn't have imagined.

But, IMO it needs a bit more polish. To a designer's eye, this immediately screams "programmer-designed". You may want to hire a designer - hand them these mockups - and let them add a "designers' touch" [more padding, better typographic alignment, softer contrasts, etc].

That said - this is a big improvement over the previous design. Also, please don't feel like I am ragging on your work, just a bit of constructive criticism.

[1]http://news.ycombinator.com/item?id=1660200

If you have a million people `pull`ing from your repo, of course you should have be hosting your own public access point. But, in 80% of cases, people can't be bothered to figure out how to set up Gitosis, pay for slices, mess with DNS, etc. just to host a repo.

To put it another way, see: Heroku vs. EC2

Considering the sources of most of their revenues, I'd say #2 is most likely. Companies that have been in Enterprise that long, making hand-over-fist money from mediocre products, acquired IP, and vendor lock-in often have a "quaint rag-tag" view of the FOSS development community.

I tend to think it's a myopic viewpoint, but then again we are a tiny indie shop, and they are multi-billion dollar company.

Shit happens, servers go down, that's why you also have a remote repo hosted on Linode, and X, and Y too.

This. Try and think of one other computer company that has/takes/enforces that much control on every aspect of their product. Sure, some companies make decent high-quality hardware, and some companies make okay software. But what sets Apple apart is the quality/attention to detail that goes into every aspect of the product.

Each product is designed as an cohesive package, that "just works" out of the box. If you want to hack that product, it's your prerogative, but don't complain that it's not as easy to accomplish.

Disclaimer: We are a Mac software company. We consider hack-ability important, it's just not what Apple is selling.

Compare this [1] to this [2]

[1]http://cappuccino.org/learn/

[2]https://github.com/280north/cappuccino/wiki

Good job Vincent, and props to Github for sponsoring it.

We focused more on making Git easy to use, so it's more of a Versions/Cornerstone type workflow.

For the initial release, we are purposefully not including some of the more "advanced" features, until we get feedback on what's most valuable to our users.

Which tasks are most likely to drive you to the command line?

As for the scripting, are you talking about integrating with git hooks, or just plain scripts? I would love to hear more about your idea, email me at [email protected]

"Advanced" functionality - merging, rebase, etc - was purposely left out because that most likely to be done at the command line no matter what.

As far as Xcode integrations go, I think Xcode 4 actually has Git integrated baked in.