Rails Envy

Hi!

I see you have prepared really well, nice work.

However if you could produce a little example application during your presentation, it would be perfect. I know it must be harder to talk and code but it gives much deeper impression.

Just my 2c :-) Priit

Priit, actually did a great job doing a code demo after my talk, where he built a few things!

Unfortunately it didn’t make it on film.

Thanks for the Kudos!

Great Job guys!

Great presentation and explaination of the business method and Rails. A few questions though…if you don’t charge at a fixed price based on spec how do you charge in an adaptive development method? Seems like a lot of time and a project that might never end. When and how do you end the project?

I have found most clients want that fixed price so they know they will get most of what they want within the budget they have.

Great job!

Great talk, loved it. I use Rails, but the business perspective really intrigued me, and I’d love to hear a follow-up with more about Agile Programming.

One minor thing: Signal to Noise Ratio isn’t about getting a whole lot of noise from just a little signal… As it pertains to Rails, it seems to be more about accomplishing what really matters without a lot of unnecessary code or configuration.

Very Nice presentation. No comments about that yet. But a little constructive criticism about your presentation skills (I’d want somebody to tell me)...you say “kind of”...A LOT!

One small suggestion - try not to say “kind of” so much! Other than, good stuff.

Nice video! Very professionally done! Great presentation explaining the ‘why’ to do adaptive programming and Rails. Good persona and nice straight forward interesting slides.

Thanks for the kind words everyone…

Chris.. You’re right.. most clients don’t want a never-ending product. However, so many projects go over budget all the time, because specification documents are crap (as I said in the video). I think the key is to divide up specification documents into Phases or Milestones, and provide a buffer for each Phase for Debugging/Extra Features. If you leave padding in there for the unexpected, then things become more flexible (agile). I think I’m going to do a writeup on here with some of the “Best Practices” in regards to doing contract work. There’s a lot to be said.

I know kind of say “Kind of” like 5 times in the first kinda of minute of the video. It does kind of get better as I get more kind of relaxed into the talk.

“I think I’m going to do a writeup on here with some of the “Best Practices” in regards to doing contract work.”

Looking forward to it!

My favorite part is still that guy’s head. Because everything is an object in Ruby. EVERYTHING.

In fact, if you’re even talking about Ruby, that conversation is an object. If you’re just thinking about Ruby, your thoughts become objects.

Basically Ruby takes everything you could ever imagine and turns them into objects. Be it bald head or an argument about databases at a Ruby User Group meeting. Objects. Everything. Everywhere.

Ken, I can’t see the video either

Great video, it rings very true for me.

One question though: Does a painter not like to paint?