I'm a Ruby guy who lives in, Edinburgh. These days I pass my time freelancing though my company and solving problems for other people - but in a past life I was a teacher of english as a second language, and I'm currently trilingual.
The Ruby community and its conferences are great because it lets me get in touch with the community that's nurtured and supported me for the years I've been in the industry and gives me a great chance to give back by sharing the things I'm most passionate about - programming, linguistics, learning and how you can be better at all of these.
You know about PDFs right? Those horrible documents that you have to shell out to wkhtm2pdf to generate, can't edit and generally can't do much with?
Good! Then I'll surprise the socks off you with the awesome might of the Majestic Sea Creature - Prawn. A Ruby library for manipulating PDF documents and the supporting ecosystem of tools and other libraries so that you can, well, do anything anything to a PDF document.
Wouldn't that be interesting?
Heck - you might even learn a bit about how the documents are structured and built so if you were broken (like me) - you could hand-roll one in Notepad. But don't do that. Please.
Mostly though, I think you'd leave with a new found appreciation for this humble, ubiquitous document format and the really cool stuff you can do with them in Ruby these days.
I have a couple of problems with this proposal:
1) IMO, Prawn basically hasn't moved much in the last couple of years (1.0.0.rc1 => rc2 after 1 1/2 years!). While you certainly don't need to add features to a library that is relatively mature (which Prawn certainly is), it shouldn't rot for months either. 2) The Prawn documentation is rock-solid. I don't see which benefits a talk would bring over just working through the documentation. 3) While I like Prawn for certain tasks (and still use it to this day), I have found that wkhtmltopdf (and its wrapper wickedpdf) are way more relevant for real-world applications like generating PDF versions of views (e.g. invoices, product data sheets etc.) because HTML/CSS are just way easier to handle. Of course, this is highly subjective and wkhtmltopdf (and therefore wickedpdf) certainly has its own set of specific problems – but in this case I'd prefer practical use.