Computing Broadcast Calendar Dates in Ruby

While building a new product I discovered that broadcast advertisers use a special broadcast calendar to normalize advertising schedules. Each month starts on a Monday. I made an tiny open source Ruby gem called broadcast_calendar to compute the Gregorian/civil dates for broadcast months:

gem install broadcast_calendar

> BroadcastCalendar.dates_for(5,2011)
=> Mon, 25 Apr 2011..Sun, 29 May 2011

I also found a list of pre-printed broadcast calendar dates.

My Presentation Materials

In case you saw me speak at TEDxBaltimore, RailsConf, or Ignite RailsConf over the past few days and would like to get access to my materials, here they are!

• TEDxBaltimore links and TEDxBaltimore slides
• RailsConf HTML5 tutorial materials
• Ignite RailsConf 20 Favorite Gems slides (with code samples!)

Thanks for checking out my blog!

Ruby for Startups at Lone Star Ruby Conference 2009

Recently Confreaks posted video from the Lone Star Ruby Conference talk I gave in August, called Ruby for Startups.

I've refined the talk a few times since then but it's still a good representation of my current state of mind about what I've learned about Ruby and about software design while building OtherInbox. Check it out if you'd like to see more! The slides are posted here.

Ruby for Startups Talk at Lone Star Ruby Conference

Today I gave a talk about my experiences writing the code for OtherInbox, called Ruby for Startups. The slides are below. Hope you find them interesting!

The design principals from the first slide come from Russ Olsen's book, Design Patterns in Ruby (and originally from Design Patterns: Elements of Reusable Object-Oriented Software).

Ruby For Startups

View more documents from subelsky.

Video of my talk at Lone Star Ruby Conference

Confreaks has posted my entire Ruby in the Cloud talk from Lone Star Ruby Conference.  Check it out and let me know what you think!

Here's a 30 second synopsis filmed by Gregg Pollack:

My talk at Lone Star Ruby Conference

I had a great time at Lone Star Ruby Conference,

meeting fellow Rubyists and hanging out with the entire OtherInbox dev team.  I had the privilege of speaking about all the benefits we've gained from using as much Ruby as possible in running our service.  Confreaks will be posting the video soon, but here are my slides:

Ruby in the Cloud (PDF, 5.8 MB)

I really enjoyed sharing our experiences with the conference, but the highlight of the event for me was getting to hear the inventor of Ruby speak, and also getting to meet him.  You will not meet a more generous, noble, joyful person than Matz, and I can't think of anyone I don't know personally who has had more of an impact on my professional life than him.

Speaking at Lone Star Ruby Conference

I will be speaking at the Lone Star Ruby Conference in September about how we use Ruby to deploy, monitor, and manage a cluster of servers running in the Amazon Web Services virtual cloud.   Below is a summary of what I'll be talking about.

In OtherInbox, almost every system administration task imaginable is carried out using Ruby, meaning we as developers can enjoy all of Ruby's expressive benefits and spend less time scripting the shell, writing cron tasks, or using other languages. Because we make fewer context switches from thinking in Ruby to thinking in other languages, we also reap a big productivity benefit.

Using Ruby throughout our cloud also means that porting the application to run in different production environments is a trivial task, because Ruby is the glue connecting the Ruby components together, thus all we require is a Ruby interpreter to deploy.

Two key Ruby technologies have matured in the previous 18 months which make it ideal for almost every layer of managing a cluster of servers:

• god.rb allows fine-grained process monitoring and daemon control (a la monit)
• rufus-scheduler enables Ruby-based scheduling (replacing cron, and providing a great facility for running daemons that must be executed on a recurring basis)

When combined with these Ruby workhorses, developers today can spend much more of their time writing Ruby code, and less time struggling with the vagaries of their production environment:

• Ruby standard library utilities (File, FileUtils, etc.)
• Rake
• Capistrano (for any kind of remote application, not just Rails)

The talk will also include a discussion of using several different AWS gems to make cloud computing simple, by illustrating the use of Amazon's S3 and SQS services to distribute asychnronous work and handle communication between servers.

(cross-posted from the OtherInbox blog)