I had one of these pointed at me yesterday. Eric and I were travelling on 520 near 405 and because of the 405 onramp and the car in front of us we wound up merging left. The car behind us did the same at the same time, but he tried speeding up to cut us off. It didn't happen and he flipped us off. Eric flipped back. We ignored him until he passed us on the right up near 140th, pointing the gun at us. Unfortunately for the idiot with the gun, he was driving a white suburu outback with a vanity plate reading "DONGER". Within 90 minutes the guy was in custody.

Some people are beyond stupid. To them, we say "fuck you":

ZenTest version 3.3.0 (aka Project Doesn't Suck) has been released!

  sudo gem install ZenTest

or grab it from the project page.

It is true. Autotest used to suck. But no longer. I just wrapped up the last of my rewrite of autotest and it is much much cleaner. Autotest is now 73% the size of before, much easier to maintain and enhance, and it now sports a nifty plugin feature. Check it out:

I'll be releasing autotest in a new ZenTest release tomorrow.

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.

ZenObfuscate

...for when you really really have to ship a binary...

"Being perfectly honest, your obfuscator has made me feel like writing RubyCocoa apps is a commercially viable business, whereas before I had my doubts." - Aidan Rogers, Infurious

ZenObfuscate is now commercially available and is already being used in a commercial application.

What is it?

ZenObfuscate is a translator for a fairly large subset of ruby that converts your pure ruby code into a dynamically loadable binary, protecting your intellectual property(*).

How does it work?

ZenObfuscate has a commandline interface that takes the specified ruby files and outputs a dynamically loadable binary (.bundle on osx, .so on unix/linux and .dll or windows).

Please understand: We aren't simply scrambling variable names and the like. We're compiling your code down to binary. No, not a simple loader with a string (encrypted or not) on the tail. This is a real translation to C and compiling a binary.

ZenObfuscate is built on a solid foundation: RubyInline and ParseTree. Both are long-standing open source packages for ruby with a ton of unit tests. ZenObfuscate also ships with a suite of unit tests (themselves partially obfuscated to show it works on both sides).

When is it available?

ZenObfuscate is available nowish on an individual basis.

How much does it cost?

ZenObfuscate costs $2500 for a site license or is individually negotiable for other licensing schemes. Yes, that is expensive. That was on purpose. But don't let that thwart you too much. If your product is really cool and we want to see it succeed, we'll make it work. "Really cool" is not freecell.

What are the restrictions on licensing?

ZenObfuscate is a commercial product produced wholly by Eric Hodel and Ryan Davis and is not for redistribution. All rights are reserved, etc., etc. Binaries produced from ZenObfuscate have no restrictions of any kind (except determined by their authors).

What type of support do you offer?

We try our best to make our product work for you, within reasonable limitations. If we had to put a number on it (and we don't want to) we'd probably say that 10 hours of support are included with the site license and after that we'd have to negotiate additional support. We doubt this will happen.

Requirements

ruby 1.8.x, ruby2c, parse_tree, rubyinline (all available as gems) available on darwin ppc, darwin intel, freebsd x86, freebsd amd/64bit, and linux x86 (with coaxing and/or bribes).

Known Limitations

There are issues with what the obfuscator can translate to C and as a result you may need to modify your code in order to translate it. Usually this is a pretty straightforward and simple task. We do a good job of translating static ruby to its equivalent C, but not all ruby has an equivalent in C.

• Only translates methods in classes and modules, not freestanding code.
• Explicit returns are required in all methods.
• Temporary: Conditional logic (including ?:) may not be on the right hand side of an assignment.
• Temporaryish: Exception handling and generic block closures currently don't translate.
• Some expressions in ruby we don't currently do, but could upon request, where some other ruby expressions will never translate.

(*) No. You'll never ever fully protect your IP if they have it in hand. That is simply a fact. We just raise the bar enough that it isn't worthwhile for most people.