Comments on: Startup Camp Melbourne wrap up

By: Michael Specht

Michael Specht — Wed, 08 Oct 2008 10:14:55 +0000

@Kim, based on the plan we needed to have sites live by 10pm Saturday but I’m not sure the definition of what live mean was clearly understood. Our site did not make it due to DNS propagation issues.

Competition is good but not necessarily were people come together for educational purposes which is what many in Melbourne were there for, to learn what was needed for a startup. Having said that I hear there is a rumour of an Australia wide startup camp over a single weekend, winner takes all .

@Sjors yep so many a project has failed due to technology, I feel next time we need more preparation.

By: Startup Australia: StartupCamp Melbourne I Coverage

Startup Australia: StartupCamp Melbourne I Coverage — Wed, 08 Oct 2008 05:12:27 +0000

[...] Bootstrappr The Inquisitr Sjors Provoost Pieter Peach Michael Specht TheSquigglyLine Semantic Aesthetics Never Read [...]

By: Sjors 'George' Provoost

Sjors 'George' Provoost — Tue, 07 Oct 2008 11:35:49 +0000

The issue of machines (both laptops and the deployment servers on the Internet) is definitely something that needs to be addressed. We lost a lot of time on that and it’s not the first time I’ve experienced that problem during gun-shot projects.

I agree that a pre-meeting briefing, having laptops pre-configured and getting hosting arranged before the weekend is a good idea.

The only problem with that is that I would not like to see the choice of platform(s) made in advance.

On the other hand, there could be a dedicated Starupcamp deployment server, with stuff like PHP, Ruby on Rails (Passenger) and whole lot of other things pre-installed. It should not run any projects from previous camps and one person in the room should have root access. Any extra tools could be installed during the weekend provided they don’t endanger other projects.

Then there’s the laptops. The whole group has to set up their development environment on their Linux/Mac/Windows(XP/Vista) boxes, which is time consuming and a recipe for disaster.

One way to solve that is if you group people with the same skills, but that takes away a lot of the fun and learning potential. It also makes the teams less flexible.

Another way would be to have a central development box in the room with a login for everyone and pretty much the same config and root access policy as the deployment server. Files are shared via Samba so you can use your favorite IDE. This way the team needs to configure only 1 box in stead of 4+.

By: Kim Heras

Kim Heras — Tue, 07 Oct 2008 11:35:47 +0000

Hey Michael

Well done on making it to, and through, the weekend being so sick. It’s an intense couple of days, so I’m sure your team and all the people involved appreciated your commitment.

Now, onto our war of words

By launch – I meant our sites had to go live at 10pm on the 2nd night. You’re right in saying the code-freeze was the next day, but we had to be ready for the world at 10pm – approx 24 hours after start, and presented to the VC at 10am the following morning – approx 36 hours after start.

But listen, that statement was more about trying to drive some competitiveness than division. I figure we need a little more friendly competitiveness in the industry to spur each other on.

My bad if it was taken the wrong way.

Keep up the good work on your site.

Kim.