Ruby Hoedown Day 2 Notes

Here are the notes I took from day 2 of the Ruby Hoedown conference:

Calling Your Code: Gluing Phone Calls to Ruby

Troy Davis

[Troy spoke on how you can use Ruby to write voice applications with phone calls.]
Asterisk - open source PBX & telephony platform
Adhearsion - Ruby framework that sits on top of Asterisk.
Typical flow: PSTN -> SIP -> Asterisk -> AGI request (Asterisk Gateway Interface) -> Accept call with Adhearsion -> Run call flow
Instead of administering the PBX manually, can use Asterisk to administer it in Ruby.
There are various TTS (text to speech) engines (some much better than others).
[Troy walked through a few live demos using mobile phone. There were problems, but overall it's impressive.]
Example apps:
- Yelpvox - call a #, then get surrounding restaurant information
- SendSign - real estate flyer information service. If flyer box is empty, call the provided # to get information. Can then go to SendSign.com, enter in the phone # that you called from, and see the homes that you looked for.
- Frucall - do online comparison shopping by calling a number and entering in a barcode of a product while you're in the store.
What you need to get started:
- Asterisk or FreeSwitch (available in virtual machine format)
- Text to speech engine
- SIP provider
- DIDs (phone numbers)

Joe Kutner

We're used to imperative programming.
It's nice, but the programmer should, ideally, understand all of the entire program (which is often impossible with imperative programming).
Alternative: rules engines, rules-based paradigm
Write rules declaritively, but don't specify how code runs.
Ruleby uses a Ruby domain specific language (DSL) to specify rules
Uses the Rete algorithm. Good, but exchanges memory for speed (be aware of this).

Rick Bradley

Flog - continuous integration for code complexity.
Evolution of a programmer:
1. Lamer
2. Haxor
3. Cowboy
4. Embryo (start to notice testing)
5. Webelo
6. Poseur (half-heartedly do testing)
7. Human
8. Apprentice
9. Journeyman
Test driving code in a greenfield scenario is much more different than testing existing code.
Technique: don't change existing code without test covereage.
Legacy code = code without tests (Michael Feather's book Working with Legacy Code)
[Comments from the audience: This may just unnecessarily confuse the terms "untested code" and "legacy code". What if old code is well tested? Rails 1.0 is well tested, but is still legacy code.]
So, for an existing app without tests, where do you start? Very basically, on the outside, pealing away layers.

Giles Bowkett

[Presentation starts with live demo of electronic music driven by a Ruby script and edited live in a text editor to change the music's style.]
I'm a former DJ.
A lot of DJs are using laptops now, which should in theory, make computer geeks popular at parties.
Venture capitalism is like the patronage system for artists and is stifling.
Programmers are often distracted by shiny toys.
Be profitable from the start by being small and cheap.
I'm trying to create my own niche market using Archaeopteryx and MIDI controllers for DJ work.
This is your brain on music book.
I'm going to test my program by running it for 7 days at Burning Man.
Good business is the best art. -Warhol
[For sure it's an entertaining presentation, but there are too many rat holes and it comes off to me as scatter-brained.]

Yahuda Katz

Ruby can be used in the "enterprise".
While I don't want to use Rhino or Hibernate, we can learn a lot from Java's experiences.
Whereas Ralis embraces convention whole-heartedly, Merb has good defaults set on a highly configurable backend.

David Black