I'll be giving my talk "Hurting Code for Fun and Profit" as well as hosting RejectConf at GoRuCo this weekend. I hope to see you there!

Generated 2008-03-04 22:49

Effectively immediately I'm dropping support for 1.8.2. I never supported 1.8.3 so everything is 1.8.4 or above.

I only have tentative support for 1.9, but I'm working on both 1.9 and rubinius right now.

I've been quiet lately, both bloggy and email (sorry if I haven't gotten back to you!). I think I'm hitting information overload and my brain is pushing back. That said, I'm going to try to actively fix this. I have a bunch of stuff to release and even more stuff sitting around that could be blog-fodder. Hopefully from here on I'll be publishing daily at least until I'm through my current blog-fodder queue and the releases...

As I semi-jokingly stated for _why's Year in Review, 2006 for me could best be summed up by: "release lecture release consult release overwhelmed release conference release".

I'll be in NYC for the 26th! I'm flying out to meet the fabulous Ms. Amy Hoy to interview at Limewire. I'll be missing the Seattle.rb meeting, but going to my first NYC.rb meeting!

While I'm in the city I hope to hang out with some of the NYC.rb crew, have some arepas, and generally have a good time. What else should I do? I get in way too early.

I spent too many of the last 36 hours working on my presentation coming up in October. It is done, and I'd like to take a breather now. Oh, and by the way, I'll be giving a talk at AJAXWorld in Santa Clara on October 3, 2006! :P

What? The title? You already know it:

"Electric Kool-aid Acid Testing"

So, if you wanted to see that talk, here is your chance.

I was not chosen for rubyconf 2006. Here was my final and submitted proposal:

Electric Kool-aid Acid Testing

(or Drinking the Kool-aid)

Summary

There is a subtle difference between Plain Automated Testing and Test Driven Design. Whether it is called "Test First", "Test Driven Design", or "Extreme Testing" there is one thing that is true: TDD is a expands your mind when it is truly done. I hope to share that experience. I plan on taking those who know TDD and push them further while still being accessible to those to don't know automated testing at all.

Details

There is a huge difference between your average software project and one that routinely does testing in the form of automated unit and system tests. Automated testing is about reducing or removing fear and pain. Fear of breaking things and the pain of maintenance. That difference is similar to climbing a sheer face of a cliff without rope and harness compared to the confidence you gain knowing that you are climbing with rope and belaying partner.

But this talk is not about that.

The difference between plain 'ole automated tests and Test Driven Design (TDD) is much more subtle. It is like the addition of a pair of good climbing shoes and some chalk. It doesn't decrease the fear so much as it gives you focus and clarity, making you more effective. It may seem counterintuitive, but TDD doesn't limit you, it expands your options as it expands your mind.

Your mind starts to clear as you take on TDD and start to shed years of bad habits like overly complicated logic, featuritis, and delving too deep or too fast. You become bolder knowing your tests will catch you when you fall. Eventually your consciousness expands to fill this void as the clutter fades away. Your focus changes and the signal to noise ratio improves as you simplify your design, your code, and your thinking. As a result, you start to look at the whole game differently.

I hope to expand some minds with this talk by incorporating the TDD foundation, add a sprinkling of XP practices, mix in the ZenTest toolset, throw in some Weinberg, and of course, share a drink of some electric kool-aid. :)

By the end of the talk, the audience should have a good grasp on:

• The difference between writing tests and test driven design.
• The TDD life-cycle.
• YAGNI or "You ain't gonna need it".
• "Do the simplest thing that could possibly work".
• How to properly optimize your code and how not to waste your time.

REMEMBER: Proposals are due 6/30!

Summary:

There is a subtle difference between Just Testing and Test Driven Design. Whether it is called "Test First", "Test Driven Design", or "Extreme Testing" there is one thing that is true: it is a mind-bender when it is truly done. I hope to share that mind-bender. I plan on taking those who know TDD and push them further while still being accessible to those to don't know testing at all.

Details:

There is a huge difference between your average software project and one that routinely does testing in the form of automated unit and system tests. Automated testing is about reducing or removing fear and pain. Fear of breaking things and the pain of maintenance. That difference is similar to climbing a sheer face of a cliff without rope and harness compared to the confidence of climbing with with rope and belaying partner. But this talk is not about that.

[ maybe switch over to a more hippie-themed analogy :) ]

The difference between plain 'ole automated tests (POAT?) and Test Driven Design (TDD) is subtle. It is the addition of a pair of good climbing shoes and some chalk. It doesn't decrease the fear so much as it simply makes you more effective. Whether it is called "Test First", "Test Driven Design", or "Extreme Testing" there is one thing that is true: it is a mind-bender when it is truly done and it is very effective.

One of the reasons that TDD is a mind-bender is due to the changes that you brain goes through when you start to incorporate the practices of TDD and as a necessary consequence incorporate XP's tenants of "You ain't gonna need it" and "Do the simplest thing that could possibly work" into your daily process and eventually your way of thinking. As you start to think in TDD your focus changes. The signal to noise ratio changes as you simplify your design, your code, and your thinking. As a result, you start to look at the whole game differently.

I hope to warp some minds with this talk by incorporating the TDD foundation, add a sprinkling of XP practices, mix in the ZenTest toolset, throw in some Weinburg, and of course, a take drink of some electric kool-aid. :)

By the end of the talk, the audience should have a good grasp on:

• The difference between writing tests and test driven design.
• The TDD life-cycle.
• YAGNI or "You ain't gonna need it".
• "Do the simplest thing that could possibly work".
• How to properly optimize your code and how not to waste your time.

Bio:

Ryan Davis has been using Ruby since 2000 and is a founding member of the Seattle Ruby Brigade, the ass-kickingest ruby brigade (per-capita). He has worked on and released coco/ruby, ParseTree, ruby2c, RubyInline, ZenHacks, ZenTest, and ZenWeb. He has not yet released BFTS, metaruby, or zero2rails but they are coming out RSN™. His presentation at RubyConf 2005 on ZenHacks was very pretty.

Whatcha think? Ideas? Glaring mistakes?

This was our old milestone list for metaruby/ruby2c. It does not reflect current status, but status then (approx 2004-10).

1: (done) parse_tree.rb
2: (done) 1st compilable unit
3: (done) massive cleanup and rearchitecture (node class and SexpProcessor
composite class)
4: basic sexp interpreter (numerics), use that to drive the doco for
the ruby subset we support.
5: advanced sexp interpreter (objects)

basic units/goals (in no order)

memory allocation & deallocation
sexp interpreter + documented ruby subset
array
object
string
inlining

huge units/goals:

parser
runtime