Three OSCiers attended DevDays DC and for a one day show there were some interesting moments and quite a bit of information to be absorbed.

The conference started with a funny clip by the people at Fog Creek and had a nice lineup of speakers.

You can find my notes from most of the presentations here.

So, is James Bach (@jamesmarcusbach) the bad boy of testing?

I flew up to Boston on Monday to lead some workshops on Continuous Integration. I checked into my room at the Hyatt and then went downstairs to see who was around. I ran into a couple of speakers milling about, and eventually joined one of them, and we headed over to the MIT Press bookstore, me to look for my Solr book. I wasn’t too sure of the name of the other speaker I was with (I asked once, but couldn’t quite remember what it was…). So we got to the book shop, I ask my fellow speaker again: James Bach. The name I was familiar with, but couldn’t quite place it… I ended up buying Parentonomics, and then we go for coffee.

So, over coffee, he asks me about what my topic is, and I gave him the brief summary of my two CI related workshops. Wow.. Little did I realize that I was sitting with the guy who rails against the “fetish” that Agile folks have for automated testing! That his entire approach to “testing” is to use skilled, motivated folks who do “sapient testing”. And I’m the guy who’s selling an approach that REQUIRES automated tests! That encourages expanding the use of automated testing!

He actually walked me through a process of talking about how to “think like a tester”, and it was really great mini-workshop.. He definitely subscribes to the socratic approach, and believes in his message, I was sweating at the end of it! That chat probably sparked more ideas in less time over that coffee then anything else this week. I also heard a lot of ideas and phrases that were echoed in Michael Bolton’s keynote later on in the week. Clearly a lot of collaboration between the two!

Probably the biggest idea that James and chatted about was the idea that automated tests really aren’t automated tests, they are automated checks. They verify that the expected behavior of the code was met. His argument that if you want to do testing, real testing, then computers, automated processes can’t meet that need, only people can.

Now, I don’t know if I believe that is completely true, but I am very aware that the “manual testing” where long test scripts written as Word documents are executed by human beings by hand are really a waste of human potential. And that those test scripts are really, to use James terms, “check scripts” because the people are not using any creativity! In fact, a lot of my interest in CI comes from the idea that people should not do monkey testing, that machines can do it much better, and my frustation with the perception that testing is a low value activity and can be easily shipped off to low skilled folks.

I think that this shift away from the term “test” for automated tests is actually happening in many places. In the Ruby world, we have libraries like Shoulda that are moving from using words like assert to other words like should. A Cucumber test really shows how controlled the space that a test needs to be to work well in an automated fashion:

Scenario: See all vendors
Given I am logged in as a user in the administrator role
And There are 3 vendors
When I go to the manage vendors page
Then I should see the first 3 vendor names

So while I don’t know if I am bought in on the idea that only people can do “testing”, and machines can only do “checking”. Tools like Heckle try to simulate aspects of what a human can do. While not suggesting that we can automate the “does my website look okay after someone changed the CSS” type of work today, in the future our automated testing will be more capable then just “checking” because we will move beyond the very constrained tests we have today to ones that mimicing the richness of the simulators that Airline Pilots use. Instead of testing the training given to pilots, we’ll be testing the robustness of software via simulations!

At any rate, James Bach, while taking a rather provocative approach to sharing his ideas, does subscribe to my favorite bullet in the Agile Manifesto: Individuals and interactions over processes and tools.

Here is him giving a great presentation with the subversive title of “How to Fake a Project” that was incredible entertaining, and also quite thought provoking:

What do you think? Automated testing is a fetish of the Agile community?

Why do we need to sell Agile?

For those of us who know and love Agile, the benefits of Agile seem obvious.  It can be frustrating when someone doesn’t inherently see those benefits, and we sometimes forget that we need to sell our clients or our managers on our process.

For some perspective on the gut reaction many people have to Agile, consider the following quote.  John Zachman penned a famous paper on software architecture design in the 1980’s, where he said:

“Some kind of structure (or architecture) is imperative because decentralization without structure is chaos.” – J.A. Zachman, 1987, “A framework for information systems architecture”

As practitioners of Agile, we need to remember that someone’s first reaction may be that we are engaging in chaos, and so we need to consider beforehands the needs of our client or manager and how we can convince them to follow a better process.

In this post, I will briefly present 12 techniques for selling a traditional client on an Agile project plan.  This post is based on a talk I gave at Agile 2009 and to a number of other user groups, and which you can see on Slideshare here.

As part of preparing this presentation, I created a survey of fellow grad students in UVa’s MSMIT program and other colleagues in the field.  I asked them how they have sold Agile or been sold on Agile.  Not everyone who answered the survey was a fan of agile and many of their quotes are interesting.

You can see the survey yourself here, and add your own feedback to it:
http://www.tinyurl.com/SellingAgileSurvey/

Those who answered the survey are all experienced IT veterans who have worked for a wide range of organizations, including Booz Allen Hamilton, SAIC, Capitol One, the International Monetary Fund, Fannie Mae, Freddie Mac, and more.

First, a couple of general comments from the survey that I found interesting:

“Agile seems to carry the connotation of ‘codelike-hell’ or just, ‘work faster’.”

“I am skeptical of any methods that that could be interpreted as ‘cutting corners’”

These are common first impressions of Agile, and I hope the following 12 techniques will give you ideas how to convince your clients or managers that Agile is the way to go and their first impressions are not accurate.  These techniques are based on a survey of current literature, my own consulting experiences at OpenSource Connections, and the feedback I received from the survey mentioned above.

1. Trial by Sprint

“You need to show a success to get adoption.”

Consider giving your boss an option.  Ask them to give you a sprint or two to try Agile out, and if they don’t like it, then you will go back to the old ways of doing things.  Make sure that you pick tasks for those trial sprints which can be successfully accomplished, and will show your boss the value of the incremental delivery of Agile.  You should also encourage your boss to play a role in the daily standups and see how communication in your team improves.

2.  Case Studies in Success

Do some research on similar companies to yours, and what methodologies they are using.  By googling around online, you should be able to find some case studies on Agile success and present those to your boss.

3.  Client Testimonials

For consultants, make sure you go back to your clients after a project and interview them.  Ask them how your process worked, and gather some quotes you can use in future proposals or client discussions.  I did this for one of our recent projects, and the customer gave us some great feedback like:

“Certainly one of the most successful projects ever here … Scrum eliminated my biases of what developers could do by letting them self-select.”

4. Find a Champion

One approach is to let others do the selling for you.  This is particularly useful for consultants who already have a relationship with a client, and you can let some of the clients’ employees talk about how they want you to use Scrum.  Or, as one of my classmates did, he became the internal champion for Agile:

“I highlighted the benefits to the Project Manager: higher productivity and less team management stuff since the team will take care of lots of team-management and updating (burn charts) instead of PM’s managing those details.”

Basically, identify a stakeholder in the project who is most in need of the benefits of Agile, and enlist their support to help you sell management on the use of Agile.

5. Use Metrics of Success

Many traditional clients like their current methods because they provide metrics that they can graph and look at.  They don’t always immediately understand how they can measure a project using methodology without a lot of documents.

But Agile has its own metrics too, and perhaps you can use those to sway the client.  Consider presenting them with information on velocity, story points completed vs waiting, test coverage, unit test success, etc.  Some Agile tools will provide these in pretty reports, but you can also fashion them yourself.  And don’t forget to show them the benefits of the burndown chart if you’re using Scrum, and emphasize how this gives them a real time view into the health of a sprint without encumbering the developers with lots of reporting.

6. Show how Agile combats common IT failures

One of my professors, Ryan Nelson, has been running a study of project retrospectives over the last 10 years, and has published articles in MIS Quarterly Executive detailing the Top Classic Mistakes in IT projects.  The top 3 are consistently:  Poor estimation and scheduling, Ineffective Stakeholder Management, and Insufficient Risk Management.  Agile can be used to address all those classic mistakes.

Consider why projects normally fail in your organization, and present the ways that Agile combats those common failures.

7. Examples of government/industry leaders using Agile

As one of my classmates pointed out:

“Clients, especially the military, are wary of catch phrases and sometimes unwilling to change their habits.”

If your client or boss fits that description, then you need to convince them they are not the first to try Agile, and that it has been used elsewhere successfully.  Try to find examples of their peers in industry or government using Agile, and point to them as an example.

One example you can use is my previous blog post about the CIA using Agile and Scrum.

8. Comparison to other methodologies

Compare how Agile/Scrum work compared to areas that your client or boss is already familiar with.  Try to point out both the similarities and the differences.  For example, one of my classmates took the following approach:

“I gave an overview of the Scrum process and highlighted the ease of transition since iterative/incremental development has been in practice for a long time (in other forms such as a spiral approach)”

9.  Listen to their needs and address them.

“I am always skeptical of anything that promises it is the ‘only’ or the ‘best’ [methodology].” – Comment from a development manager

Instead of going into the meeting and kicking off the discussion with your rant on why Agile is the best development methodology, take time to listen to your client or manager first.

Ask them how their projects have been going, what challenges they face, and take notes on their common problems.  Then suggest how Agile will address some of these issues.

The key here is to spend most of your time listening, and only then talk up the benefits of Agile.  This will assure your audience that you have heard their concerns, and that you are trying to present positive solutions to their problems.  This can be much more effective than trying to force a methodology on them.

10.  Sneak it in

This is a very common approach, and one that I have done before too.  One of my classmates is a technology program manager, and they commented that:

“I make sure I utilize agile practices where ever I can – I just don’t use the agile terminology.”

The point here is not to be deceptive, it’s just that sometimes you don’t need the sign off from the boss to do something.  After you successfully conclude your project, you can then point out to your boss that “by the way, all that stuff we did that really impressed you – that was Agile.”  Now that they have a positive impression and have witnessed some success, you can work on letting them formally adopt the process.

Note that doing this might require you to temporarily also fill out the same reports or status updates your current process requires, but hopefully you can get those dropped after having showed the benefits of Agile.

11.  Compromise

An agile purist may not like the idea of compromising, but I found the following sentiment to be pretty common:

“The methodology that has worked in my experience has been to incrementally introduce Agile … Start using a limited set of the practices and gradually start bringing in more.”

Similar to the “Sneak it in” approach, this can be done with or without your boss’s knowledge.

12.  Agile Project Management Office

One other thought to consider is setting up an Agile Project Management Office, or PMO.  A traditional PMO is a very document and regulation intense group, but some Agile practitioners have started to promote the idea of a lighter weight PMO.  An Agile PMO focuses less on micro managing teams, and more on providing an interface to traditional processes.  The Agile PMO can help Agile development teams by taking ownership of any burdensome compliance requirements which go against Agile processes.  This allows the developers to concentrate on developing code how they want, and not filling out checklists of documents.

They can also serve as an educator and coach to the client.

Conclusion

There are many variants on the above ideas, but I hope this quick list has given you some direction on different strategies you can use for convincing people to adopt Agile.  Keep in mind that each of these strategies has pros and cons, and you should consider the needs of your situation before adopting any particular strategy.

If you have other suggestions, please leave a comment and I look forward to hearing your feedback!

Arin Sime’s presentation last week at Agile 2009 on how to sell a traditional client on an agile plan made a good impression, apparently.  First, his presentation was featured on the front page of SlideShare.

Now, he’s received an excellent writeup from Adam Goucher (we were pointed to Adam’s writeup from here).  Many thanks to Adam for the kind words about Arin’s writeup!

Arin’s next speaking engagement is at the University of Virginia’s EdUI conference on September 22, covering the Facebook API.  He’d love to see you there!

OSC is proud to announce that we will attend and sponsor this year’s EdUI Conference 2009 which is bein held at the University of Virginia on 21st-22nd September 2009. A number of folks from the OSC team will be attending, and stop by our booth in the Vendor Hall on the second day and introduce yourself!

EdUI 2009 boasts a powerhouse lineup of renowned and popular headliner speakers, most often found at the Web industry’s premier events. In addition to these, it features a series of presentations, selected through a proposal process, to allow peers, colleagues, and geek kindreds to enlighten one another with their expertise and ideas. Our very own Arin Sime will be speaking on The Facebook API: Thinking About UI in a Social Way.

I’m very pleased to be co-speaking with Wayne Graham at EdUI 2009 at the University of Virginia this September 22nd.  EdUI 2009 posted the full conference schedule today, which included the talk Wayne and I will give.  Here’s the description for our talk:

The Facebook API:  Thinking about UI in a social way

Building an application for the Facebook API is very different than your standard application. The basic concepts and flow of your application need to conform to underlying principles of social media in order for people to use your application and share it with their friends. We will discuss the development and implementation of Facebook applications based on our own experiences and drawing on the best practices of other projects. Wayne will discuss his implementation of the Facebook-Athenaeum project, and Arin will discuss his experiences building an application for fundraising on Facebook. The presentation will be a mixture of high level design concepts, details on the Facebook API, and code examples. 

We’ll be speaking on Day 2, September 22, from 2:15 – 3:00 pm.  I’m really looking forward to hearing all the great speakers at this conference, and I’m honored to have a chance to present with Wayne at EdUI!

Last Thursday I had a great opportunity to speak at AgileCville, and give a dry run of my upcoming presentation at Agile 2009.

Eric took this photo of me speaking.  It looks like I’m doing The Robot.  I’m not, but that would have been cool.

I’d like to thank all those who attended. I really enjoyed the chance to share my thoughts on “How to sell a traditional client on an Agile project plan.” I got a lot of great feedback from everybody. I’m flattered how much of it was positive, and I also got a lot of very helpful constructive feedback that I will definitely incorporate as I polish my slides for Agile 2009. Most notably perhaps, I’m going to take a crack at improving the quality and consistency of the graphics in the slides.

The slides are available online here. I also brought my voice recorder with me, and I’ve posted very roughly edited audio from the meeting here. The presentation was about 35 minutes long, and then we had a very interesting and valuable discussion session for about an hour after that. If you try to listen to the audio, be forewarned that not everyone’s voice comes through clear in the second half when we’re having our discussion.

I’m really looking forward to seeing everyone at Agile 2009!

To celebrate my one year in the “real world”, I went to Toronto to attend the FutureRuby conference. The format of the conference is consistent with all other conferences I’ve been to, the unConference with an unThink style of philosophy. This was also my second Ruby specific conference, and the first one I attended, RubyDCamp, was a great experience so I was looking forward to this one. There many things that got me excited about the conference, the first one was the website:

another one was the conference motto:

People who program in Ruby aren’t like other coders

We are the artists, philosophers, and troublemakers. We realize that the fringe of today is the mainstream of tomorrow. We grease the engines of progress, even when we’re working outside of the machine.

FutureRuby isn’t a Ruby conference, but a conference for Rubyists. This is a call to order – a congress of the curious characters that drew us to this community in the first place. We have a singular opportunity to express a long-term vision, a future where Ruby drives creativity and prosperity without being dampened by partisan politics.

The conference location was also an added benefit. Of course it was more costly to go to Canada, but I like to travel and this was a great chance to visit a new place. The conference itself, or activities related to the conference started as early as Thursday with a iPhone app development class. Friday was the early registration day and opening party time. I got into the city Friday night, so I missed that day’s events. But of course everyone was talking about the party and the roof top view the next morning at breakfast, so check out this video about it:

The Unspace HQ Commencement Party from Luismi Cavallé on Vimeo.

For me the conference started Saturday morning when I picked up my bag of schwag:

Then was the opening note by @peteforde who kicked off the weekend by expressing how he wishes that this conference is something that will help rubyists everywhere shape the future of the community. He was then followed by this great list:

Speaker: Nathaniel Talbott
Description: The revolution isn’t free – none ever is. If we want to keep Ruby real and not have the life sucked out of our community by soulless corporations we have to learn to take value and turn it into cash. And yes, we *can* learn!
Notes: Great starting presentation, funny and insightful. This presentation eased my worries that the talks will be very technical and over people’s head and I won’t be able to benefit from them. The speaker’s biggest point is owning your work and your tools. Do not let the corporates dictate the future. Developers are the ones who use the tools and they’re the ones who should decide what to use. See the presentation here.

Speaker: Ilya Grigorik
Description: Tokyo Cabinet offers a great many features right out of the box: key-value store, ordered traversal, attribute search, schemaless data structures, and even indexing. We’ll explore these features with hands on examples and then delve into the advanced and little known feature of TC: ability to script it with Lua! We’ll explore a number of lean & mean recipes to take TC to the next level. A cache server you say? Perhaps a graph database?
Notes: Of course everything conference I go to, there’s a new database engine being introduced. This one was cool though and I’m looking forward to see it get widely used.

Speaker: Austin Che
Description: I will discuss a programming language that makes Ruby look like child’s play. The language of life, DNA, has shown its robustness and expressiveness through billions of years of pervasive use. Engineers have recently begun to use DNA to reprogram life to create a myriad of novel biological systems. Biology is currently at the tip of a revolution similar to that of electricity and magnetism at the beginning of the 20th century. The electrical engineering revolution has allowed non-physicists to program in high-level languages like Ruby by distilling classical physics into a set of engineering design principles. Similarly, the emerging field of synthetic biology applies engineering principles to biology. Efforts to bring modularity, interchangeable parts, abstraction and standardization to biology is beginning to allow non-biologists to quickly and predictably design and build biological systems. Soon, it may become child’s play to program with DNA.
Notes: This talk was designed to blow your mind away, in many ways. It’s one of those thing you go “Hunh?!?!” about because of both how hard and technical it is and how cool it is. After the talk everyone started googling for websites where they can program DNA to spell their name. I had a talk with Austin Che at the Pravda Gala and he’s a very cool guy. It was great presentation about biology and programming combined.

Speaker: Anita Kuno
Description: Usain Bolt revealed his nutrition sources to a Canadian journalist; KFC, McDonald’s and Chinese Food. If the world’s fastest man doesn’t bother eating healthy food, why should we? Ah, because we know something he may not. We know about Version Control!
Note: This was an interesting talk. I personally was expecting Anita to tie it in to Ruby or at least programming more than what she actually did. It did fit the theme if you looked at it this way: the future of ruby depends on healthy rubyists and the health of rubyists depends on nutrition. I did learn one interesting fact though, I can influence the structure of my body and specifically my bones over the next 10 years with what I eat. Something to keep in mind for those of us who sit all day in front of a computer which damages our back.

Speaker: Foy Savas
Description: In a world were the boundaries of bytecode define your allegiance, one speaker will challenge our assumptions and defy our prejudices while writing a talk summary that reads more like a movie trailer. Because though the future is coming, who knows if it’ll be ours? Will the right tool for the job prevail or are we facing what seems to be the inevitable rise of the virtual machines? Foy will tell us where he thinks we’re all going and how we might avoid such disaster.
Notes: Hands down the best presentation of the day. Foy used his slides very well and the talk had a fast pace. The topic of his talk is something I have been discussing with people at OSC for a while. The ability to use multiple languages in our application to benefit from each language’s strength is something that would please many developers. Of course Foy had everyone tweeting about crack during his talk when he mentioned how he went from C++ and Rack to C++Rack to CRack.

Speaker: Misha Glouberman
Description: Misha Glouberman is a performer and artist based in Toronto. For the past several years, he has presented a series of events called Terrible Noises for Beautiful People. These are participatory improvised sound events, where groups of non-musicians make sounds together. Misha will talk a bit about these events, and see what sorts of sounds the FutureRuby conference can make. You can read more about these sound events at schooloflearning.org
Notes: Can’t tell you about it. It’s a FutureRuby secret.

Speaker: Ron Evans + Damen Evans
Description: No description available. FAIL.
Notes: The future Wright brothers? The introduced us to flying robots and how it easy it is to download the flying_robot gem (http://github.com/deadprogrammer/flying_robot/tree/master) to use for controlling robots through RAD (Ruby Arduino Development: http://rad.rubyforge.org/). There were cameras and blimps involved too!

Speaker: Brian LeRoux, Brock Whitten + Rob Ellis
Description: The future of Ruby is the same as the future for all computing: the mobile web. Ruby developers need to make sure they are prepared to take their skills mobile. And, currently, building mobile web applications is a pain in the ass. In this presentation, Brian LeRoux, Brock Whitten and Rob Ellis will introduce shortcuts for building device neutral mobile applications with PhoneGap and other techniques for smuggling our precious Ruby onto iPhones, Androids and elsewhere.
Notes: Mobile development is probably the hottest topic these days. With that comes the debate about which platform is the best to use and develop for. Unfortunately, the iPhone, Android, Blackberry phones and Nokia phones virtually have nothing in common. What this means is that if someone wants to develop an application that works on all these platforms, he is forced to develop a specific version for each platform. What these guys presented is a framework that allows you to develop an application once and have it work the way you expect to on all these devices. The interesting note from this presentation was the philosophy behind their work. They stated that the goal behind PhoneGap is for PhoneGap to stop existing. Sounds counterintuitive at first but it’s a great way to approach things. What they want is for their work to be integrated to the core of the platforms, moving towards more of a standard.

Speaker: Adam Blum
Description: Rhodes is an open source Ruby-based framework for building locally executing, device-optimized mobile applications for all major smartphone devices. These applications work with synchronized local data and also take advantage of native device capabilities such as GPS, PIM contacts, camera, and SMS. Yet you write the majority of your interface with high productivity in HTML and Ruby. Rhodes allows you to write an app once and it will then run on all iPhone, Windows Mobile, BlackBerry, Symbian and Android smartphones. During this session we’ll build a sample app for all mobile devices, from scratch, in minutes.
Notes: This was the second mobile development presentation in a row and was the last of the day, so by this time my brain was wondering off. I was ready to get out of that conference room. The presenter didn’t help his case either. Eh, it happens!

Now on to the juicy part, the Pravda Gala. Before walking in to the bar I realized that there was some sort of connection with the name and the vodka with the theme of the conference, but oh boy was in for a big surprise. This bar was completely themed after Soviet Russia. Now I did show images of the conference theme, but this took it to another level. This conference showed me the Ruby community in a different light. This bunch of people have a unique sense of humor, something that seems to be a requirement to get by in this field of work. This party allowed the alter egos of everyone at the conference to be free. You needed to be there for the conversations to understand this more but the images should suffice.

The Pravda Gala from Luismi Cavallé on Vimeo.

I screwed myself when I booked my return flight before the schedule for the conference was out. I booked my flight for 2:30pm on Sunday. Which meant that I missed a good part of the Sunday lineup which was:

Speaker: Collin Miller
Description: Much of what code editors do cover up for the gross impedance mismatch between machines and code. The artifacts of code misshape language design, system architecture, “the community”, and the craft as a whole. Cast off the robes of the textual high-priesthood and think about constructing programs instead of encoding them.
Notes: Did you even think that text was next the best mean of representation? Collin thinks so, and he’s not talking about using images to describe something visual, he’s talking about programming and writing code in something other than text! Interesting talk.

Speaker: Dr. Nic Williams
Description: I will be a developer for another 37 years; and by that time I might have created or maintained 500 to 1000 open source projects. In the last 3 years it is already a become maintenance challenge and in another 37 years I may be begging to retire. That is, unless we can solve the problem today: how to go from 1 to 1000 open source projects and still enjoy yourself. This talk will challenge much of the dogma of open source and will make you rethink what is open source? And how the hell do you live with it once its written?
Notes: awesome presentation! I wish I could get to a point where I can do what Dr. Nic was preaching, which simply was: develop a project that you want to use to solve a problem you want to solve, then ditch it. If you’re the creator of a project it doesn’t mean you’ve inherited it for life and it doesn’t mean that the project can’t survive without you. You CAN retire!

Speaker: Matthew Knox
Description: The Milgram experiments revealed a number of exploitable weaknesses in human psychology, and demonstrated that our collective human intuition drastically overestimates the difficulty of getting ordinary people to do extraordinarily awful things. I’m going to talk about those weaknesses, their exploitation, consequences, and aftermath.
Notes: Good talk about owning what you do and being responsible for the code we unleash on the world. I had to leave before the end of this talk, sorry Mat!

Speaker: Paul Dowman
Description: If you don’t engineer a battleship will you be swallowed by the Failwhale? Where’s the middle ground? A discussion on the philosophy and practice of staying light and nimble without falling down under load.

Speaker: Joseph Wilk
Description: Saucy Multilingual Cucumber seeks Fun and Frolics. Good-looking plaintext acceptance testing framework seeks meaningful relationship with devs, testers and non-techies too. Cucumber to my friends, Cuke to my lovers, I yearn to help you strive towards your business value. Very open minded, I enjoy a good web framework but am willing to get funky with whatever tickles your fancy (iPhone, Erlang, GTK and even Java). Most of all, I’d love to watch you, erm, refactor, and I can keep you safe while you achieve your business and coding dreams. Must speak one of my 23 languages or help me learn a new one. P.S: Don’t be shy, Joseph Wilk knows me as intimately as anyone – he’s been like a father to me – he’ll show you how to treat me right. Don’t worry though – I’m easy to pick up and I don’t bite (unless you want me to).

Speaker: Avi Bryant
Description: No description available. FAIL.

Speaker: Jonathan Dahl
Description: Art, music or words, and software too find limits freeing. Is less more?

Speaker: Francisco Tomalsky
Description: Francisco is a co-founder of 280 North and the creator of the Objective-J programming language. 280 North is bringing desktop-class applications to the browser with their new open source framework, Cappuccino. They recently launched 280 Slides, the first application built on Cappuccino. Before 280 North, Francisco was an early member of the iPhone team at Apple, working on Mobile Safari and Maps.

Speaker: Jesse Hirsh
Description: It is important that we understand the history of Imperial California and the means by which its ideology infects us all. From Hearst and De Young to Kevin Kelly and Chris Anderson the Californian Ideology is the hegemony that prevents other great cities or ideas from rising. Intrinsically we fight these ideas with our own, yet doing so blindly prevents us from seeing who struggles with us, and with whom we stand in solidarity. This presentation will help Future Ruby understand it’s role in ending California’s reign.

All in all it was great conference. Those who weren’t there missed out. I hope there will be a future FutureRuby conference (no pun intended)!

Credit is where credit’s due: Thank you @peteforde and @meghatron and @juliehache and @hyfen and all the other organizers/volunteers for a great conference. Thanks for all the speakers and presenters. Thanks for all the rubyists and non-rubyists who attended. And thanks to everyone on Flickr who provided great pics, including: aquateamhungryfort, luismi_cavalle, soukias, Edward OG, rtlechow, Austin Ziegler and Leftist (in no particular order). For more images check out: Flick