Quick review:
The Kindle DX has finally made it worth owning a Kindle for the purpose of reading technical books.  The native PDF rendering works wonderfully.  Also, many of the books below, if not free in the first place, were significantly cheaper than the dead tree equivalent which resulted in a large cost savings.  Finally, the weight of the Kindle, roughly 18oz, is significantly lighter to carry than all of these books (which only represent a few of the 100+ PDFs on the device which only occupy a few percentage of the total storage capacity).

Worth the $500?  I’d say so.

(Click any of the images for their original 12MP image)

_Why’s Poignant Guide to Ruby

Golden Gate Ruby Conference Wrap-up

The Well Grounded Rubyist

Random Lambda Calculus PDF

Pragmatic Programmers – Programming Cocoa

Peepcode – Git Internals

First RubyConf since 2005 – conferenced out.  But he missed it.  Glad to be back.

Background – Coming up on 10th anniversary working with Ruby.  Early 1999, version 1.2 or 1.4.  Was much younger than (shows photos of a young kid).  Downloaded new languages daily.

Downloaded Ruby, thought it was cool, it made it past lunch, made it into the night.  Fell in love and it’s been the case ever since.  Was Java and C and moved everything to Ruby, serious for 10 years.

Is it OK to love a software tool?  Is that something you want to do?

You HAVE to love your software tools – the work we do is some of the most difficult on the planet (no dangerous), programmers, like poets, constantly start with a blank sheet of paper and construct completely out of imagination and make something from nothing.  You’re tired at the end of the day.  You have to love the tools or else you’ll resent what you do and it’ll show in your work.  Really really important to work with tools you love.  Grateful to Matz.  Went to Japan to talk to Matz, but Matz left, (Dave speaks to Matz and shows his appreciation).

Wrote books
Talked at lots of events
Went to lots of conferences (Ruby and Rails)
Learned at Rails conferences, to be cool, you need to swear on your slides.

F**K RUBY (in reference to the famous DHH slide)

(takes away the asterisks)
FORK RUBY

It’s time to fork Ruby!  But isn’t JRUBY, Rubunious, etc etc enough?  They’re not forks.  They’re implementations.

It’s time to fork the language.

(Shows a chart of times between releases)

1.0 -> 1.4 – 14 months
-> 1.4 – 8 months
-> 1.6 – 13 months
-> 1.8 – 48 months
-> 1.9 – 54 months

There’s a problem with this…  The bigger the time gap, the more stuff gets stuffed in and too many changes to manages.

Big changes == Slow adoption

Slow adoption == Unproven

Ruby 1.9 has great international language support for character encoding.  It was done nicely but the first library to be ported ran into many problems.  Not enough people using 1.9 to send feedback.

Shows a Katamari image (big ball of garbage), calls it a pattern.  The language picks up features as it rolls around the landscape and gets bigger.

Bigger is not better.  Bigger is scary.

Proposes tonight as a community to fork the Ruby language.

Some project ideas
• Ruby LIte
• Parallel Ruby
• Optionally-typed Ruby
• Closure-based Ruby

Ruby Lite
• Do we need it?
• Shows a chart of download sizes from release to release, they gradually increase over releases.  Starts under 2.5mb, gets to 10mb by 1.8.  1.9 is 32mb.  As of August, almost 40mb.  It has grown exponentially
• Can use this information to find out when Ruby 2.0 will be released: June 11, 2011.  100mb (laughs)
• Looks at number of methods
∘ Same pattern
• TOO BLOODY BIG
• Maybe there’s room for a light version?
• What would you do?
∘ Attack the language, built in classes or libraries
• Lose language features
∘ ?x (?\M-?C-x)
∘ -> (a,b) {c}
∘ Strange %q delimiters
∘ Here documents?
∘ Implicit sting concat
∘ Alias
∘ Nested assignment
∘ :: for method call
• Can live without these!
• All trivial things, what about bigger things
• Lose language features
∘ Class variables
∘ Global variables
∘ 70% of $vars
∘ unless/untill
∘ Protected
∘ Proc
• Not here to get rid of Ruby, just forking it
• Roll back encoding support, utf-8 is OK for the lite version, get rid of encoding support.  Much smaller!
• Lose built-in classes/modules
∘ Complex
∘ File::Stat
∘ FIleTest
∘ Mutex
∘ ObjectSpace
∘ Process:Gid/Status/Sys/Uid
∘ Rational?
∘ ThreadGroup
• Tirm down built in classes/modules
∘ String – 106
∘ Array – 81
∘ IO – 76
∘ Module – 59
∘ Hash – 53
∘ Time – 48
• ls x in (start..end)?
∘ To find out if x is in the range, how many methods to find this out?  4 methods.  ===, cover? include? member? All practically do the same thing.
• Trim down standard library
∘ Currently 127
∘ Trim to 10
‣ dlk
‣ irb
‣ mkmf
‣ minitest
‣ open-uri
‣ optparse
‣ rake
‣ rbconfig
‣ rdoc
‣ rubygems
∘ Everything else is a gem!  You don’t need to throw anything away!

Parallel Ruby – PUBY – not such a good name… PRUBY it is, squash it together
• How do we do it?
• We already have the construct.  The = sign
• a, b = b,a
∘ Assignment happens in parallel
∘ Values on LHS don’t impact calculations on RHS
∘ Documented as parallel assignment
• We can take this and make it more powerful
• a, b = calc1(c), calc2(y)
∘ Could perform calculation sin separate threads/processes
∘ Assignment only completes when all values become available
• But we can’t take the = operator, we need a new one
• //e?
• a, b, .. //= x, y, xx
• If any rvalue is a proc, call it rather than assign it
• (Shows code for finding the longest work in a (very) long list….) – Great candidate for parallelism, break up the work into chunks
∘ Shows a divvy-up function to do such a task
∘ *results //= *divvy_up(words, 10, longest) – Spanned out to multiple parts and all procs executed independently.  Sends out N processes, returns N results
∘ p results.max_by (|size,word|, word}
∘ Map/Reduce in 3-4 lines of code
∘ Kind of fun
• Is this the whole story?
• How do we share data without stepping on each other?  No idea!
• Possible idea…
• Within binding block, only variables listed as parameters are available and they are frozen/deep copied
• Will it work?  Who knows, but fun to investigate
• Hey, it’s just a concept

oTuby – Optionally typed Ruby
• Why?  Documentation aid to IDEs Runtime Checking (maybe)
• Type != Class
• Need to find a middle ground
• Possible approaches
∘ Just go for it — annotate with class or module names
∘ Command-line option to freeze built-in classes to allow optimizations
∘ Runtime type inference?

CLUBY – Closure-based Ruby, Ruby with blocks
• Make it easier to create lambas or project objects
• First, free the braces!  No need to spell lambda anymore!
• Next, rationalize blocks and procs
• Replace them all with { |prams|    }
• 3.times { |val| puts val * 9 }
• More cool examples of passing blocks
• Re-work the while syntax
• We can do much of this today but we don’t because it’s too damn ugly
• Re-writing class methods….Get rid of class variables
• Lose some keywords; class, modules, def, if, then, else, elsif, while, unless, until, case, when
• Lose a lot of syntax
• Gain a lot of flexibility
∘ What were once control structures are now methods…

Let’s play!  Experiment!

Just for Avi…  Yes, Smalltalk did this a long time ago…

Four different ideas of many ideas.  Thousands of experiments!

Would love to see more people doing this.,,,

More radical re-writing of the syntax

There’s a word for all of this…  Bullshit.  Who knows if any of it is going to work!

Tath – Old Scottish word,  A wonderful word!  The luxuriant grass which rises in tufts where the dung of cattle has been deposited.

Dave has done the depositing!  Go be nourished!

Summary
What’s wrong with Ruby?  Not much!

But this should not stop us from having fun.  Lets produce all of these wild ideas and see what works, and if they do work, maybe they will roll back into core.

Surprise him!

First RubyConf – 30 or so users.  Has grown a lot. (~500 here today)

Keynote Topic: Reasons behind Ruby

Matz wanted to create a programming language.

Matz _loves_ freedom and wants to maximize it.

Ruby is Imperfect.

Complaints:
• Ruby is slow
• Ruby lacks features
• Ruby is too complex
• Ruby inconsistent
• Ruby consumes too much memory
• This list goes forever

Why do we love Ruby?  …Or how I learned to Stop Worrying and Love Ruby.

Love matters.  It’s the greatest reason behind Ruby.

But why do we love it?  It’s enjoyable.  It made programming fun again.  Again?  It used to be fun.  But no longer.

In 1980, BASIC.  Matz first computer – Sharp pocket computer
• Great pleasure
• Matz could make intelligence
• Gave a sense of creation
• At same time though, great pain
• Aristocracy
∘ Language designers and implementers on top
∘ Programmers on the bottom
∘ Barrier between

No command can be added.  No data type can be added.  No abstraction.

Lisp, found a year or two later
• Everything was opposite of BASIC
• No discrimination
• Extreme abstraction
• You can change everything
• Great pleasure

Matz used Lisp
• Didn’t make him THAT happy
• Parentheses?
• (Lost
∘ (In
‣ (Stupid
• (Parentheses
• Macros?
∘ Partially
• Smart people just underestimate ordinarily of ordinary people
• Aristocracy
∘ Happy with it (not in real life)
∘ As long as he has power
∘ And to be able to become designer when he wants

Conflict between owelty and safety.

BASIC gives you no power.  Lisp gives you full power.

Why not go all Lisp?  At both ends, we lose popularity.

Language popularity chicken race

BASIC
–CLIFF–
LISP

If you stay with BASIC you are a coward …

If you go to Lisp you are brave … or you risk your life

(Photos from Rebel Without a Cause)

Balance.  We all love power.  Flexibility  Freedom.  But it’s not free.  It’s like a pilgrimage or walking in the minefield.

Do you want that?  It’s not a task for everyone.  Matz wants it.  He’s done it for 15 years.  And willing to continue.  Help him.

You don’t need to learn Lisp because we have Ruby!

Policy matters.  Policy matters most.
Philosophy.
Attitude.
People Matter.
The community.
“Ruby People are NIce” – Martin Fowler.
Money matters (sometimes).
Productivity Matters.
Efficiency Matters.

Why do we choose Ruby?
Ruby on Rails…
Interesting point…
Turned Ruby into a web DSL
Added vocabulariy
Rules (or syntax)
Rake!
RSPec

“Programming is a process of designing a DSL for your own pplication” — Dave Thomas.

Lisp is very good at being a DSL.

Increases overall productivity

Four million plus Ruby developers by 2013.  Under one million now.  Professional developers. (eWeek projection)

The future is bright.  Too bright, maybe.

Beware of commercial success.

If we are driven by money, we may lose something very important.

What we have
• The community
• Enthusiasm
• Rise of commercial success

What we will have
• More money
• More job titles
• More resources
• Better implementations (faster JRuby makes him sad)  (Rubinious, good try!)
• Faster
• Feature rich
• Provide more satisfactory experiences
• Most Importantly…
∘ We will have more poeple in the community
∘ Some people behave nice…  Some just troll.  But people count.
∘ Matz welcomes them, asks others to welcome them
∘ Nourish them
∘ Feed them better projects, themes, inspiring ideas
∘ Love them.  Great power behind Ruby and the very reason behind Ruby
∘ Matz loves you all.  Loves people using Ruby.

(Photo credit: Anthony Eden)

Barduino is an Arduino based bar monkey implementation.  To sum up a bar monkey, it’s typically a computer control drink dispensing system.  The Arduino, a very cost effective physical computing platform was the perfect base for the Barduino.  And the ability to work with a language I’m comfortable with, Ruby, to write the software that runs on the Arduino made this a relatively simple project.  All of this being made possible with the Ruby Arduino Development Framework.

So first off, let’s take a look at the Barduino in action:

So how was this accomplished?  You can take a look at the source code over at GitHub.

Here’s the basic breakdown of what the Arduino is doing:

• Verify there’s a glass sitting under the dispense area.  This is accomplished with a photoresistor that detects light
• Verify the Arduion has a serial connection for it to receive commands
• Listen for either a “1″ or “2″ being send to the board over the serial line (via the USB port)
• If a “1″ or “2″ is received, call the dispense method pass it the pump it needs to turn on
• Dispense a single ounce of liquid on the given pump and return back to the main loop

So now we have the Arduino programmed and ready to go, but how do we send those characters over the serial port to actually make some drinks?  With a domain specific language written with Ruby of course.  In the case of the Barduino, you have the Barduino-tender.  You build a recipe in a very elegant Ruby like manner and from there, you let the Barduino-tender go ahead and tell the Barduino which pumps to turn on and how many times.  So let’s take a look at an example recipe.

drink 'Screwdriver' do
  serve_in 'Highball Glass'
  ingredients do
    2.ounces :vodka
    5.ounces :orange_juice
  end
end

Now that’s all left to do is run that recipe against the barduino-tender and the Barduino will proceed to dispense 8 single ounce shots from the respective pumps.  You can take a look at the DSL on GitHub.

So what does the circuit look like that’s driving the Barduino?  Here’s a photo, give it a click to head on over to Flickr so you can see what each of the components are.

How about cost? It was very minimal. $34.99 for the Arduino. $9.75 for each pump. And the rest of the parts came from Radio Shack. The total cost of this project was less than $75. And thanks to Mike Wheeler for whipping up the rig for me to mount everything on!

Lastly, the presentation slides, some links, and some other photos courtesy of Anthony Eden (who also contributed to the project with his DSL talk last year at an ORUG meeting).

Notes from Tim Rosenblatt with lots of links to various resources and components I discussed during the talk. (Thanks Tim!)

Lastly, big thanks to Gregg Pollack for running the show at ORUG and be sure to check his latest project with partner in crime Jason, EnvyCasts for some of the most well produced screencasts that you’re going to find in the Rails world. Absolutely worth every penny.

Specifically, the development of JRuby has been full steam ahead ever since Sun decided to hire two developers on full-time to work on the JRuby project.  This has meant constant releases, each with a large change set.  The project has most recently hit its 1.1 state which includes a 100% compatible Ruby 1.8.6 interpreter written completely in Java.  This means you can simply drop the JRuby JAR file in your Java project and begin writing Ruby code.  Or you can go ahead and integrate Swing into your Ruby application; seamlessly.

I work for a Fortune 100 company, a defense contractor with a pretty strict development environment.  What does this mean?  For the most part I’m limited to Windows, anything I would like installed on my PC needs to go through an approval process (which can take 3-6 months, easily) and the existing choice of tools is quite limited.  Luckily, Java is one of the big hitters for development in the software department.  The standard load on my PC contains a pretty recent JRE/JDK which opens the door to JRuby.  JRuby at this point is simply a drop in, a tool I can integrate to my existing environment.  It’s not an executable that needs to be virus scanned or something that shows up in the wonderful Windows “Add/Remove Programs” dialog.  

And it is wonderful.

Next, enter NetBeans, an IDE for the big hitter languages; C++, Java and most recently, Ruby and Javascript.  NetBeans is one of the few tools that makes working in Windows a pleasure.  I’m a Mac guy, so spending 9 hours at work on a PC can be painful at times but a properly configured NetBeans can give me an IDE that looks similar to TextMate.  Couple this with Cygwin and I’ve got a pretty similar development environment as I would in a Mac or Linux environment.  Built in Autotest, incredible code completion (including completion on your ActiveRecord models) and integration with the major SCM tools out there makes NetBeans a necessary tool when working with Ruby in Windows.

JRuby has full support for Rails.  Now I have the option to either work in Rails or the company blessed solution of ColdFusion.  Tough choice, eh?  With JDBC drivers for every major database out there, I can quickly prototype and develop applications against both Oracle and PostgreSQL which I have at my disposal.  

JRuby also has a great community with an active mailing list.  Hit a bug?  Missing a feature?  Go ahead and submit a ticket to their JIRA bug tracking instance and chances are it will get addressed in the next release.  I ran into a bug with the JDBC-PostgreSQL driver, browsed their bug tracking library and found that not only had it been submitted already, but Ola Bini, one of their active developers had corrected the bug that morning and posted a fix that I was able to grab and continue on with my development.

But what about getting Ruby accepted by others in your environment?  I think the general consensus on this has been to simply go ahead an whip up an application and go ahead and demo it.  Show off the benefits, the clean code and the time saved by using Ruby over whatever you would have otherwise built the tool with.  Ask for forgiveness later.  

So the next time you have that itch to integrate Ruby (or Rails) at work, go ahead and give JRuby a look.  You’ll be a much happier person because of it and your co-workers who are unfamiliar with Ruby will thank you.

Te idea behind codepad is that it acts as both a “code paste” site but it then takes the concept one step further by actually compiling the code and displaying the output in your browser.  The code is then available for 24 hours through a unique URL.  From that URL anyone can view your code and its output and even fork the code to create their own paste.

Here’s a quick example of a little Ruby code:

While http://pastie.caboo.se/ seems to be paste site of choice right now within much of the Ruby community, especially with the release of Pastie Packer from Dr Nic, I think codepad will open some eyes with a little more exposure.

It’s also a great service for learning something new or teaching someone else.

Give it a look, you’ve got 9 languages to work with:

• C
• C++
• D
• Haskell
• OCaml
• Perl
• Python
• Ruby
• Scheme
• Tcl

Gregg focused strongly on the importance of community and how you should be involved in it. He pointed out the many options one would have to get involved in their local tech communities; blogging, going to user group meetings and getting your involvement wherever you can.

This blog is my reaction to Gregg’s talk. It’s one of the easiest way to gain yourself some exposure within the community and not just local but the the entire community; world wide. I’m unfortunately a little bit of a drive away from Orlando but I do my best to get to Orlando for their Ruby User Group meetings. I would love to get to lunch_fu which is put on by Florida Creatives every once in a while but it’s not feasible with my distance from Orlando.

Twitter has been an incredible resource for me personally. It has allowed me to be in the know with what’s going on out in Orlando as well as add some input every once in a while. One of the craziest Twitter moments so far would have to be my encounter with Josh Blount. He had been out in the rain with his iPhone which resulted with some technical problems so I went ahead and replied to his tweet with a suggestion on how it could be fixed. It corrected his issue. He even blogged about it, giving me a little credit.

Back to Gregg’s talk. He finished with a little exercise that got everyone shaking hands with someone they had never met before and introducing themselves. This exercise continued at the Izea party. After playing some Rock Band I noticed a small group chatting so I went over and introduced myself. Low and behold, Josh was in that group. Conversation quickly turned to topics such as Python and pinging a MySQL employee with database questions. It was a great night with a lot of good conversation. I really enjoyed networking with a lot of people this weekend.

I now have almost 100 followers on Twitter and if I can pull 100 followers on this blog I’ll consider it a success. So feel free to subscribe or just drop me an e-mail at matthew.d.williams@gmail.com if we didn’t get a chance to talk at BarCamp. Until then, stay tuned and I’ll try to keep it interesting.