Presentations have a very big limitation – they’re fleeting. As passionate as you may be, you need to ensure that the content you’re trying to pass along stays with your audience. For some talks, a video recording may be sufficient. In my particular area, code snippets and slide handouts are almost a necessity.

As an ideal, I’d like to be able to take my content, and be able to painlessly derive:

• A presentable set of slides
• A slidedeck that can be hosted and reviewed later
• An outline view of the presentation content
• A PDF of slides that can be printed and distributed
• A code repository for any demos
• A text file of any code snippets used in the presentation
• Incidental thumbnail images and description text

Much of this can be done using free services like GitHub and Heroku, so we’ll postpone talking about headless Firefox and Selenium, and spend the first half of the tutorial examining just how we can begin creating an integrated environment.

Slide Markup

The flaw with software like PowerPoint and Keynote is simple – they’re presentation based. You start with a blank slide, and start dragging items onto it – images, text, charts – in a way that you hope will be visually appealing. But your talk is really about the content. Aesthetics should be used to enhance and emphasize your talk, not the other way around.

What’s missing here is semantic markup. We use semantic markup to write web pages (HTML), documents and tutorials (DocBook), or really anything we want (XML). The key to these formats is that we describe what the content is, rather than how it should be displayed. Here are a few options for how to represent slides in a similar way:

Slidy

Slidy is a tool that allows you to define your presentation using XHTML. By using CSS and JavaScript, Slidy presents a series of <div> tags as different slides. By applying different classes to each <div>, you can control the manner in which Slidy displays the content. Additional goodies include a table-of-contents, and an outline view.

Slidedown

Slidedown uses a similar approach to Slidy – using HTML to describe slides. However, Slidedown uses special syntax, called Markdown (for more information, take a look at the Markdown site, to actually create the HTML. The Markdown file then gets processed by Ruby libraries into regular HTML that operates in a similar way to Slidy. Here’s an example of what that might look like:

!SLIDE
# Introduction to Slidedown
## Presented by [Kevin Gisi](http://www.kevingisi.com)

!SLIDE
# Code example
@@@ ruby
    def foo
       puts "Welcome from Slidedown"
    end
@@@

This code could then be processed using Slidedown in order to generate HTML slides. Furthermore, Slidedown uses Pygments, a Python tool, to automatically syntax highlight code snippets. This tool provides a very quick way to generate slide content. However, Slidedown has no outline display, and no method of navigating over a table-of-contents.

Slide Show (S9)

Slide Show is my personal favorite, and the option that we’ll be using for the rest of this tutorial. Like Slidedown, it uses Markdown syntax, but it provides more visual options, better syntax highlighting, and some additional options. Slide Show doesn’t require any !SLIDE keywords – it assumes you want a new slide when you create a new header. A few noticeable downsides – there’s no way to bookmark specific slides (the other options use anchor tags in the URL. Additionally, the Slide Show pages will not render in Internet Explorer.

Note: You can still follow along with this tutorial in order to create your build environment using a different semantic tool, but you’ll have to modify some steps to generate the slides themselves.

Step 1: Creating a Slideshow

Let’s create a sample slide using the Markdown format Slide Show requires. In an empty project folder, create a file called slides.md. Inside there, we’ll define the content for our presentation:

# Introduction to Slide Down
## By KevinGisi.com

# Here's a Demo Slide
This is a simple example of how to create a presentation using Slide Show.

# Thanks!
Hope you enjoyed the presentation!

To convert the Markdown file into a slideshow, we’ll need to install the Slide Show gem:

$ gem install slideshow

Note: If you don’t have RubyGems installed, head over to the RubyGems documentation page for instructions.

With the gem installed, we can simply run:

$ slideshow slides.md

Open up the slides.html page that was generated, and you’ve created your first slideshow using semantic markup!

Step 2: Hosting with GitHub

GitHub is a great way to make your slides accessible to your audience, and other people who may not be fortunate enough to attend your talk. GitHub provides great tutorials on installing Git and setting up your account at their help page. Once you’ve set up Git, create a new project. You will receive instructions on how to push out your code. Here’s an example of what it might look like:

$ git init
$ git add .
$ git commit -m "Initial checkin"
$ git remote add origin git@github.com:gisikw/slides.git
$ git push origin master

Once this is done, you’ll have a code repository sitting available where anyone can get access to your slide content – but it’s not quite hosted yet!

Processing with Sinatra on Heroku

While we’ve got the code hosted so that anyone can build the slidedeck for themselves, it would be nice to actually generate the content right away. Ideally, we could write an application that could grab the code from our repository, and build the HTML slides automatically.

GitHub’s Post-Receive Hook

GitHub actually has the ability to fire off notifications whenever it receives a commit. The link above actually shows the documentation on what information they send to a URL we can specify. GitHub sends a JSON post with information regarding the repository – like the name and owner – and the commit itself – like the message.

Well this is great! All we need to do is create a small site that can accept the JSON, clone a copy of the repository, generate the content, and host it indefinitely. Heroku is where we go next.

Heroku Hosting

Heroku is an absolutely phenomenal free cloud-hosting provider. They provide very easy support for Rails and Rack-based applications, which means we can host a small Sinatra application to handle these slides. There are a few concerns we need to be aware of:

1. Heroku is not a fan of File I/O. In fact, they provide a nearly read-only file system. The exception to this is the tmp directory. We’ll be using the tmp directory to store our generated slide resources. Note: The tmp directory is wiped out each time we deploy a new version of our application, so if we make a change, we’ll need to ensure the slides get re-generated.

2. Heroku isn’t a VPS (Virtual Private Server), which means we don’t have normal command-line access. While some commands, such as git clone, we can execute with regular system calls, we’ll need to generate the Slideshow itself by digging into the gem and executing it from within Sinatra, rather than the command-line calls we may be used to on a local machine.

With these two things in mind, it is actually relatively easy for us to write a small Sinatra application to get things rolling.

Step 3: A Small Sinatra Handler

Create an empty project folder, and drop the following code into app.rb:

require 'rubygems'
require 'json'
require 'slideshow'

AUTHORIZED_USERS = %w{gisikw}
ROOT = Dir.pwd
IGNORE = Dir.glob("#{ROOT}/tmp/*")

# Sinatra Actions
get '/*' do
  if File.exist?("#{ROOT}/tmp/#{params[:splat]}") && !File.directory?("#{ROOT}/tmp/#{params[:splat]}")
    send_file "#{ROOT}/tmp/#{params[:splat]}", :disposition => :inline
  else
    (Dir.glob("#{ROOT}/tmp/*")-IGNORE).collect{|x|File.basename(x)}.collect{|x|"<a href='/#{x}/slides.html'>#{x}</a>"}.join("<br>")
  end
end

post '/' do
  @push = JSON.parse(params[:payload])
  return "Repository not authorized" unless AUTHORIZED_USERS.include? @push["repository"]["owner"]["name"]
  process
end

# Process Method
def process
  clone_repository
  generate_slides
end

# Helper Methods
def clone_repository
  `git clone #{@push["repository"]["url"]}.git #{ROOT}/tmp/#{@push["repository"]["name"]}`
end

def generate_slides
  Slideshow::Gen.new.run(["#{ROOT}/tmp/#{@push["repository"]["name"]}/slides.md","-o","#{ROOT}/tmp/#{@push["repository"]["name"]}"])
end

Note: You’ll notice that I have an array of authorized users at the top of this file – be sure to change it to contain your GitHub username – the application is deliberately filtering to make sure any contents that get sent in come from your repositories alone

This is all we need to support the functionality! We won’t delve into Sinatra, as their documentation is absolutely fantastic. Suffice it to say, all we need is two actions. First, a post '/', which responds to the JSON sent by GitHub whenever they receive a push. Second, we have a get '/' action, which both renders files directly out of our tmp directory, and generates a list of available slideshows instead of displaying a 404 page.

However, there are two other files that Heroku will need – a config.ru file (that instructs Heroku on how to run the application), and a .gems file (so we can ensure that the Slideshow gem is installed).

The config.ru file is pretty straightforward:

require 'rubygems'
require 'sinatra'
require 'app'
run Sinatra.application

And finally, the .gems file:

slideshow

And we’re ready to go! Make sure that you sign up for an account with Heroku, because we’re about to push this out to the cloud. If you don’t have the Heroku gem installed, be sure to grab it with:

$ gem install heroku

Once that’s installed, we can push our application out by creating a new Git repository:

$ git init
$ git add app.rb config.ru .gems
$ git commit -m "Initial commit"
$ heroku create APPNAME
$ git push heroku master

If this is your first time using the Heroku gem, you’ll likely get prompted for your email and password. Once you do this, the Heroku gem will automatically upload your SSH key, so you won’t have to do this again. Open up your browser to the new application, and you should see absolutely nothing!!

Step 4: Adding a Post-Commit Hook

Time to finish the job. Head over to your GitHub page, and look at your slide project. Click on “admin”, and then “Service Hooks.” You’ll see a text field where you can enter in a post-receive URL. Throw in the link to your new Heroku application. For me, that was http://slides.heroku.com, but yours will depend on what application name you chose.

Finally, do another push of your original slides:

$ git commit --allow-empty -m "Build system test"
$ git push origin master

Give it a few seconds to send the POST to your Heroku application, and before you know it, you have your slides sitting there, automatically generated for you. Take a look at my example!

Summary

It took a little bit of work to get set up with our integrated build system, but now that it’s up and running, we can add as many new slide decks as we like. We simply need to add the Heroku URL to each GitHub project we want built! In this way, we can make modifications to the original source file, which is really focused on content, and not ever have to worry about rebuilding the visual version – just check things into the repository. We can also offer a persistent link now that permanently display the updated version of our slides for all to see.

In Part 2 of this tutorial, we’ll examine how we can expand the Sinatra application to generate additional content, grab our code snippets, and even generate handouts, so stay tuned. In the mean time, happy presenting!

While shrinking your time into 25-minute focused chunks might not work for you (whether because of your work environment, or the way you manage focus), there are certainly techniques that you can apply to improve the way you spend your time.

Determining Features

As a young kid, I used to have a terrible time keeping my room clean. We’d have long weekends where I’d sit in my room, unable to make any progress because the work to be done was so daunting. The floor was buried in clothes; the clothes were buried in toys; and the toys were buried in books. It was almost impossible to get anything done. But once my parents suggested “Just get your desk clean; worry about the rest later,” things started to click.

I hardly knew it at the time, but I was beginning to take an agile approach to the room-cleaning project. And that strategy continues now – when I’ve got a long email to write, it can be intimidating. Instead of trying to spend a long chunk of time struggling through, I hit “Compose”, and quickly write out:

Effectively what I’ve done here is divided a large “project” into three key “features”, just like you would with an Agile project, but on a micro level. I now have three small features that need to be completed – specifically, writing three paragraphs, from the small caps-lock cues I gave myself. These tasks themselves will take only a few minutes to complete. While I may not complete them all at once, I will get a sense of satisfaction each step of the way.

The central conceit of this technique is that we are always pleased when we get something done. Unlike the Pomodoro Technique, where the achievement is the completion of an arbitrary quantity of work-time, we instead have a deliverable (be it a paragraph of an email, a passing test in an application, or a clean desk), that we can take satisfaction in.

Managing Focus

I find that trying to control my mind can be stressful – we are actively bombarded with new information every day, and are passively trained to have a very short attention span. Actively trying to force ourselves to focus on a solitary activity can be a real and damaging additional stressor. Focus is important, but balancing it with an Agile approach to time-management can result in a less stressful lifestyle.

When you choose to divide your projects into micro-tasks, consider whether or not you get distracted. To what extent can you effortlessly focus? Some of us can write a chapter of a book without distraction. For some, writing an email is the best we can do. Some of us get distracted mid-tweet. The key to successful Agile task-management is a good understanding of how much you can focus before it becomes a stressful challenge.

Divide your tasks into chunks that you can handle. Personally, I’m quite scatterbrained, and so dividing emails into paragraphs gives me the flexibility I need to avoid fighting with my own thought process. The key is to objectively look at the times when being focused becomes a stressful activity, rather than a productive one, and to adjust your tasks accordingly. To the extent you can work at a consistent, yet comfortable pace, you can be productive, without having to force yourself into mental habits that go against your regular brain activity.

Agile Time Management—A Misnomer

The lesson here is that time-management does not offer us an intrinsic reward. As humans, we get intrinsic pleasure from accomplishing tasks, and so the real term should be task-management. So make sure to follow these steps if you’re looking to improve your productivity:

• Consider your ability to focus without stress
• If anything is beyond your focus range, split it into smaller features
• Take pride in having deliverables whenever you work
• Enjoy the focus you have, and keep things stress-free

Enjoy your work, and keep it manageable, and you’ll be productive!

This sounds like a perfectly reasonable way to try and improve our productivity at work, and it’s seems in line with many newer techniques in the field of software development and human resource management. The number of pomodoros completed is the metric for successHowever, the Pomodoro Technique focuses on the completion of it’s own unit, the pomodoro, as the metric for success. While some struggle with productivity, often this stems from a lack of motivation – which can result in intentional, or even unconscious procrastination. Finally, what side effects can result from micro-management of our time?

Is Pomodoro Agile?

The Pomodoro Technique seems to fit quite nicely with Agile project management trends – Pomodoro creates a micro-form of the agile timebox, and treats that as an atomic piece of work.

Pomodoro also falls in line with Scrum practices – being honest about where time is being invested, catching issues early, and understanding that the rate of work is constant. You should never be inclined to “work a harder pomodoro”, but you should consider whether your goals are too ambitious for your available time.

However, there’s one key distinction – at the end of a pomodoro, you might not be done. You record that you completed 25 minutes of work, whether or not the task you were working on is complete. Pomodoro requires no deliverablesIn a traditional agile development, the goal is that there is a deliverable product each iteration. The client, and the programmer, can take a small pride in having fully completed a certain set of features. This is not always the case with the Pomodoro Technique – the focus is on boxing the time, not the product.

Is Pomodoro Motivating?

One of the reasons for implementing the Pomodoro Technique is that “excitement decreases when complexity is high.” This happens to come straight out of the Pomodoro Technique Illustrated. This seems like a strong argument for the Pomodoro Technique as a tool to help fix a motivation deficit.

Dan Pink, argues that “Rewards can deliver a short-term boost—just as a jolt of caffeine can keep you cranking for a few more hours. But the effect wears off—and, worse, can reduce a person’s longer-term motivation to continue the project” in his latest book on motivation, Drive.

The completion of the pomodoro is just such a reward – while completing one can provide a sense of satisfaction, it is an abstract concept that has no intrinsic value. We are intrinsically motivated to complete tasksWhat Pink discusses in his book is the concept that we are motivated to complete tasks, independent of artificial or substantial rewards – perhaps the Pomodoro Technique can do harm by overemphasizing the need for another abstract reward system. The accomplishment of tasks alone can be great motivation in the right environment.

What is the cost?

Andy Hunt, in his book Pragmatic Thinking & Learning, discusses the importance of right-brain thinking, especially with regard to increasingly creative fields like computer science. It’s no coincidence that so many successful developers in the perceived math-laden, algorithmic field are also accomplished musicians and artists. Because the right-brain is responsible for the creative solutions we so often need to perform our jobs, it is vital that we encourage creativity.

The Pomodoro Technique can threaten this need. Andy tell us “Answers and insights pop up independently of your conscious activities, and not always at a convenient time…you need to be ready to capture any insight or idea twenty-four hours a day, seven days a week, no matter what else you might be involved in.”

While focusing on the task-at-hand is important, an exclusive focus can prohibit creative thinking. The Pomodoro Technique needs to be used with caution, so that it does not prevent the spontaneity and free-form nature of the creative process.

What To Apply

While the Pomodoro Technique might have some flaws, it does encourage some very good practices, namely:

• Really examine where you spend time
• Make sure to take honest breaks
• Record your time investments objectively
• Use trends to illustrate places to improve
• Spend your time deliberately (like your money)

Consider the usefulness of good time-management, but take caution not to allow it to limit your own process.

Note: I have a great deal of respect for Francesco Cirillo’s work, and highly recommend that you take a look over at http://www.pomodorotechnique.com. I also recommend examining Staffan Nöteberg’s Pragmatic Bookshelf release, Pomodoro Technique Illustrated for more information.

The intent was to produce a language that had performance comparable to C, but developer satisfaction comparable to that of Python or Ruby. The language features some impressive ideas, including type inference, shorthand for declaration, initialization, and assignment, and interfaces, but I’d like to talk about my favorite features – Go routines and channels.

“Hey Joey, look at the f***in’ tubes!”

~George Carlin

Go Routines
Rather than using threads, Go supplies a mechanism called a Go routine. While these operate in a similar manner to threads, they have the benefit of being load-balanced internally across real threads by the Go language.

func threadedThing(){
  // Do some stuff
}

func main() {
  go threadedThing();
  // Continue without blocking!
}

Go routines can also be declared anonymously, like so:

func main() {
  go func() {
    // Do some stuff
  }(); // <- parentheses to call the function
  // Continue without blocking!
}

Channels (Tubes)
Go calls them channels, I call them tubes! Channels form the basis of how we can communicate between Go routines. Take the following example:

func printer(input chan int){
  var a int;
  for {
    a <- input;
    fmt.println("Receieved: ",a);
  }
}

func main() {
  tube := make(chan int);
  go printer(tube);
  for i:=0; i < 10; i++ {
    tube <- i;
  }
}

In the above example, the printer will block until it receives an item from the input channel (a <- input), and then print it out. Meanwhile, the main send values through the channel (tube <- i) - and it also blocks. However, if we change the declaration of the channel to include a buffer...

tube := make(chan int, 10)

...the main can continue to loop, simply dropping things into the channel buffer.

When is a tube not a tube?
Consider the following example:

func main() {
  killswitch := make(chan int);
  go server(killswitch);
  // Do some work
  <- killswitch;
}

Here we see an example of how you might "join" another "thread", but in Go terms. Rather than using the channel to communicate data, we simply await any communication from the channel, and then quit. Since reading from the channel is a blocking operation, the server Go routine can simply write any value to the killswitch channel, and the main will read it, discard it, and terminate.

Channels can be used for a variety of different purposes - to transmit data, to acts as a termination signal, and even as semaphores. The flexibility of a language like Go makes it a treat to work with, and I encourage you to head over to http://golang.org and take a look for yourself!

The final day of RubyConf 2009 was a poignant reminder of _Why: why we love Ruby, why we go to conferences, and why the Ruby community is unlike any collection of developers. This was perhaps embodied best by the Programming with the Stars event which ran during the lunch period of each day of the conference.

Developers passionately watched as pairs competed in a paired-programming event to demonstrate good coding practices and refactor things for the better. Every individual in the room was excited and involved in considering best practices for development in Ruby—in what other community are individuals so excited about not only getting work done, but doing it in the best way possible? A big thanks to Corey Haines (@coreyhaines) for organizing this event!

The day had several great talks as well.

• Stuart Holloway urged Rubyists to consider what their next language was going to be—specifically, by discussing things he loved about Clojure. Stuart reminded us that we’re passionate developers, and our enthusiasm doesn’t need to be constrained to a specific language domain—get out there and have fun with something new.
• Aaron Patterson (@tenderlove) and Ryan Davis brought the house down with their Worst. Ideas. Ever presentation. Some of the fantastic topics included optimizing web performance by writing in assembly, “Ruby doesn’t scale…but XML scales like a boss!”using PHP for Rails views, and making Ruby more “enterprise” by converting it to XML (because, as everyone knows, Rails doesn’t scale, but XML does). The mentioned that they actually did encounter a few bugs in Nokogiri and other libraries, just in writing the samples for this project—bugs that likely could have gone unchecked otherwise. The overall message: do stupid stuff; play with fire; having fun with a language is hardly something to be avoided—even if the overall product might not have any real value.

As the _why-esque art from the RubyConf whiteboard—along with all the presentations from the event—remind us, Ruby is fun, Ruby is never finished, and there are always people who look forward to working with you in the community.

Thanks to everyone involved for a truly phenomenal RubyConf 2009.

Day two of RubyConf 2009 was just as exciting as the first. Unfortunately, I slept through a piece of it! I woke up around 9:30AM—just short of making it to Ben Scofield (@bscofield)’s presentation on non-relational databases. Ben gave a really fantastic presentation at Windy City Rails 2009, where he described particular problem domains that don’t lend themselves to standard relational modeling—specifically cross-bred animals like Ligers when trying to model classifications of species, or worse, the incredibly confusing situation regarding comic books. From talking to Ben, the presentation he gave today would have been a great followup to that talk – as he demonstrated some of the non-relational tools that developers are beginning to use for persistence. I’m very sorry I missed his talk, but thankfully, all the presentations are being recorded!

Great talks continued throughout the day; some of the highlights included:

• Jim Weirich (@jimweirich)’s talk on SOLID Ruby covered the idea that as developers, we still have a really hard time discussing what good code design is. The SOLID principles were laid out as objective means of evaluating static languages—but that doesn’t mean there isn’t great use for them as guides for developing Ruby code. SOLID, while written for static languages, is a good guide for RubyMost notably, Jim talked about how Java developers consistently try to “program to the interface”, because the abstraction layer of interfaces allows for increased modularity. With Ruby, this isn’t necessary—objects are objects. However, in order to maintain the modularity, clients who use functions that expect a certain type of object need to know what the input specs are. Therefore, it’s incredibly important to discuss the virtual concept of “protocol” between methods, in documentation.
• Chris Wanstrath (@defunkt) presented on Python—specifically looking at ideas that the Ruby community could learn from or take away. He gave a brief overview of the language, and a brief description of some of the cool libraries that Ruby doesn’t quite have, or could improve upon. Chris’ ultimate message was that adopting new languages is a practice that should be encouraged, because communities have a lot to learn from each other, and it’s never good to get too comfortable at any one thing for too long.
• Noah Thorpe (@aquabu) gave a demonstration of various audio libraries in Ruby. He discussed how music could be generated from mathematical constants, using various technologies. However, Ruby does have the limitation of being an interpreted language, so real-time audio is a bit crippled. He did suggest, however, that JRuby might help to fix this problem. Several of the demos were very exciting, and I can’t wait to play around with the code myself.

Day two of the conference ended with a hasty rush to the Startup Crawl—a tour of open-house events hosted by Ruby startups in the San Francisco area. While I decided not to attend, many developers are currently traveling between such wonderful companies as Scribd, Engine Yard, Heroku, Justin.tv, Apture, Yammer, HeyZap, Pivotal Labs, SocialCast, Sauce Labs, ZenDesk, Shop It To Me, Chargify, BigTent, Airbnb, Plato’s Forms, and Dropbox.

Recent Twitter updates suggest some transportation hiccups, but it appears to be a great event!

Way out in San Francisco, I’m attending RubyConf 2009 from November 19 through November 21, and JRubyConf 2009 on November 22. It was a pretty significant financial investment (many attendees receive corporate travel funds) but I managed to make it out to San Francisco early Wednesday.

For me, the experience actually started just after I switched planes – I discovered that I had actually been sat next to the department head of the computer science department at Michigan Tech. My usual social-anxiety-ridden self, I sat and read for a while, listening to music. Then, in the spirit of RubyConf, I decided I had a duty to be outgoing. She and I talked for the majority of the flight about the structure of their program, difficulties faced in CS education, and the gamut of subjects. She really got me to reconsider whether I’ll be looking at grad school when my undergrad career is over.

Then, of course, I arrived in San Francisco, took the shuttle to the hotel, and discovered that the hotels are quite segregated. After about two hours of walking, I managed to find a little downtown area, bought some Subway, and it was a good day.

RubyConf began with Matz’ keynote – he discussed the idea of a “true” language. Matz (@yukihiro_matz) discussed the idea of creating a language that can solve 80% of the worlds’ problems – naming it ZPET (Zero-Point-Eight True). He argued that Ruby needs to improve on distributed systems, and needs to provide better solutions for functional programming, but that ultimately, Ruby could be the ZPET that the world needs.

There were some fantastic presentations throughout the day:

• Several Japanese Ruby developers gave talks expressing their concern about the communication gap between US and Japanese Rubyists, noting that the core team of developers working on the Ruby implementation conduct their work in Japanese – making collaboration difficult. They discussed some of the activities the Japanese Ruby community is involved in, and invited everyone to attend RubyKaigi in 2010.
• Sarah Mei @sarahmei gave a talk about her experience teaching Ruby to high-school girls. Using the Shoes framework as a platform, she was able to give some impressive insight into what students found easy, difficult, or just plain fun. She pointed out the fact that the stereotypes surrounding programming need to be updated, as programming “has more to do with language than with math.”
• Nathan Talbott @ntalbott spoke out against reliance on TDD/BDD alone to make a project succeed—it’s simply not the case. Nate identified a possible cause—that features requested by clients (or determined by developers) are not always perfect. We’re good at solving problems, but not knowing which problems to solveAs developers, we’ve become very good at solving problems, but not great at determining which problems to solve. He discussed the idea of Experiment Driven Development (EDD) to help address this issue. Using new frameworks like Vanity, which was just released today by @assaf, we can take a baseline product, and test conversion rates on different projected features – this helps direct developers into solving the correct problems, rather than arguing over which features need to be implemented, or have a net effect on the user experience.
• Oh yes, and there were flying robots!
  

After the regular sessions ended, I meandered on over to Kincaid’s Bayhouse, which featured a fantastic dinner, with some new friends. Truly, this has already been a fantastic experience, and I can’t wait for tomorrow’s sessions!

]]> http://www.kevingisi.com/2009/11/rubyconf-part-one-education-and-ideals/feed/ 2 http://www.kevingisi.com/2009/11/a-curious-use-for-selenium-slideshows/ http://www.kevingisi.com/2009/11/a-curious-use-for-selenium-slideshows/#comments Thu, 12 Nov 2009 17:31:04 +0000 Kevin W. Gisi http://www.kevingisi.com/?p=517 As a cheap, and tech-agnostic developer, I’ve particularly enjoyed using the Slideshow (S9) gem to create my slidedecks for various presentations I’ve given. Thanks to some phenomenal jQuery, I’m able to write up my talks in Markdown, generate an HTML page, and give my talk directly from the browser.

But I’m a lazy, cheap, tech-agnostic developer. To make things a bit easier, I went to the trouble of creating a continuous build system on my private git repository, that creates my HTML page when I commit the Markdown file, pushes it out to http://slides.kevingisi.com/presentation, and no manual building for me anymore.

There was a problem, however. While S9 will gracefully degrade into an outline format, there was no real way for me to display a nice thumbnail version of the slides. I was left with no distributable of my slidedeck. And sadly, Internet Explorer users were unable to view my slides, because S9 is utterly incompatible with IE (read: S9 was written in the past 10 years).

Enter Selenium! After a bit of setup, I was able to get Selenium working with Firefox-headless, to grab a screenshot of each slide in the slidedeck. Selenium, Firefox-headless, and Xvbf let me grab snapshots of each of my slides, and ImageMagick created a PDFTo make this easy, I took a copy of @jeffrafter’s Crocodile gem, made a few modifications (mainly, executing Javascript calls to advance slides before taking screenshots), set up the X virtual frame buffer out on my server (big thanks to this tutorial: Running Selenium Headless), and boom! Now, I’ve got PNG images of every slide in the deck, ready and available. Throw in a little ImageMagick (convert slide_*.png slide.pdf), and now I’ve got a fine distributable that can be uploaded to SlideShare, printed off, copied, and viewed by Internet Explorer users. Just take a look at the results!

Ruby on Rails: The Third Age

The Ruby on Rails framework is going through some radical changes. Not only are we on the cusp of Rails 3, but new technologies like InheritedResources and Formtastic allow us to do things we never could have dreamed of before. Have you seen Ryan Bates’ tutorial on building a blog in 15 minutes in Rails? Let’s cut that down to five.

Together, we’ll take a look at some of the new gems and plugins that have been released, along with some of the upcoming changes with Rails 3 to see how this technology can make your development experience even easier.

Associated Resources
Slides: HTML | PDF
SpeakerRate

Dates and Locations
Chippewa Valley Code Camp—November 14, 2009

Selenium has notoriously been used for integration testing, and @jeffrafter used it to grab screenshots of submissions for the Rails Rumble 2009, but this modification makes browser-based Slideshows even more accessible!

]]> http://www.kevingisi.com/2009/11/a-curious-use-for-selenium-slideshows/feed/ 3 http://www.kevingisi.com/2009/10/firefox-extension-under-new-management/ http://www.kevingisi.com/2009/10/firefox-extension-under-new-management/#comments Mon, 26 Oct 2009 01:28:23 +0000 Kevin W. Gisi http://www.kevingisi.com/?p=467 Last Friday, I received a phone call from The Pragmatic Programmers, my publisher on the Firefox Extensions: Tools for Productivity book. Unfortunately, they decided it was no longer in their best interest to continue with my book, so Prags and I are parting ways.

I’d like to thank Dave & Andy for their support as I began developing this book, and their helpful feedback as I’ve gone through various revisions. I would also really like to extend my appreciation to my editor Susannah Pfalzer, who was extremely helpful in guiding me toward reshaping the book toward a more effective product. While I wish that we could continue working together, your help was extremely valuable and appreciated.

I am pleased to announce that I will continue writing the Firefox Extension book as planned. I’ll be moving the existing content into DocBook, and continue writing. I’m looking forward to seeing this book come to fruition, and I’ve got a number of supportive individuals who are eager to review and refactor. While I’m currently on the prowl for a new publisher, I’m prepared to self-publish this book if that doesn’t happen.

If anyone would be interested in helping edit or review, as I push forward with this text, it would be much appreciated—let me know in the comments. Thanks in advance for your support!

]]> http://www.kevingisi.com/2009/10/firefox-extension-under-new-management/feed/ 2 http://www.kevingisi.com/2009/10/kindness-in-the-development-community/ http://www.kevingisi.com/2009/10/kindness-in-the-development-community/#comments Sun, 25 Oct 2009 19:03:00 +0000 Kevin W. Gisi http://www.kevingisi.com/?p=448 I gave my presentation, No More Excuses: Test Your Javascript!, at the Twin Cities Code Camp yesterday, October 24, 2009. We left town at 6 AM, and managed to get to the conference with plenty of time to spare.

I discovered, once I had found the room, set up my laptop, gotten the display working…I couldn’t get to my slides!the servers at the University of Minnesota were down – I couldn’t get to my slides. I panicked, having only 15 minutes to try and fix the situation before I had to present. As the talk drew nearer, I finally opened up Notepad, grew the font, and listed the title, contact information, and slide url – along with an apology for the network issues.

Assuring my audience that my slides were “awesome”, “flawless”, and otherwise “perfect,” I preceded to begin my talk. Fortunately, I had decided to refocus my talk from a description of particular Javascript libraries, to a discussion of why we need to address current Javascript practices. Using the whiteboard as best as possible, I gave a brief overview of the topics I was going to lightly touch on—Javascript performance, Javascript functionality, and progressive enhancement.

Then, an extraordinary thing happened—one of the audience members (@joelknighton) jumped up and began the process of tethering my laptop to his phone. When he discovered I didn’t have the necessary drivers, he checked in with other audience members who had laptops, and found one that was appropriately set up. All of this while I continued my presentation.

My slides were up and running within about five minutes, and I was able to seamlessly transition over, without losing the audience’s focus, and without having to be particularly redundant. I was able to finish the presentation, and went extremely well. A few things to take away:

Have a local copy of everything

This ought to be a no-brainer, and I was sure that I had a local copy. Furthermore, there had been multiple wifi hotspots last time, so what risk was I really taking? You’ve got to plan for the worst – keep things local, no matter what—nobody likes egg on their face.

Practice slideless talks

Despite not having my slides available for the first 20 minutes or so, I was able to communicate relatively effectively about my topic. Granted, I did have a more difficult time moving through things procedurally, but I was able to get the discussion points across. This is definitely something worth practicing, because if your computer explodes, your slides get deleted, you need to be able to speak on your topic without the visual aids you might have otherwise leaned on.

The development community is fantastic

It would have been extremely easy for individuals to react poorly to my preparation failure. People could have walked out; people could have tweeted cynical comments; people could have glared and tuned out—and I really couldn’t have blamed them. Instead, the audience remained receptive and respectful, sympathized with the situation, and actively helped me fix the problem. I’m extremely humbled and honored to be a member of the development community.

]]> http://www.kevingisi.com/2009/10/kindness-in-the-development-community/feed/ 3