Google Hangout URL for tonight's ignitespeak open source orientation

I don't think the last post made this clear, but here's the link to tonight's Google hangout session, where I will be conducting an orientation of the app and how it works and what we need.

Here's an embed of the event!

Project orientation for ignitespeak on 9/13

I'll be holding an online orientation session for the ignitespeak project on Sunday, 9/13/15 at 8:00 pm. It'll be a Google Hangout, and we'll record it in case you can't make it.

I wanted to do something efficient to help get everyone up to speed. Right now everyone's getting bogged-down in setup issues.

I want to mentor you on an open source Rails project

Update: there's an orientation session on 9/13/15 if you're interested in helping

I built a small, fun Rails app called ignitespeak to manage speakers and proposals for Ignite Baltimore. I've long thought that it would be a great project for beginners to work on, because it's well-tested, it gets regular use, and it's open source.

I have an ambition to make the app more useful and available to all Ignite organizations around the world. If you're looking for a way to break into Rails development, and would like to get my personal attention, advice, or mentoring on your commits and pull requests, please contribute!  I created a number of Github issues for some possible projects.

If you're really serious about gaining more Ruby/Rails skills, I'd even be willing to do some pair programming with you, either remotely or at an open source hack night.

dependency injection minimal (dim) gem v1.2 released

I just released v1.2 of the dependency injection minimal gem (dim). Originally this project was just a gemification of Jim Weirich's example code, but v1.2 marks my first meaningful feature addition.

dim aims to provide a simple, Ruby-esque way to handle dependency injection. I find myself using it in all of my projects as a way to consolidate into one file all of the configuration that my apps need.

I noticed a common pattern, though. I had started to use dim to encapsulate ENV variables, so that my code would not need to know the source of a configuration variable (usually an API key or a URI for accessing a third-party service); in the test environment, the source might be a hard-coded literal string, but in production it might come from an actual ENV variable.


So I added a register_envmethod to complement the register method that Jim originally added. Below is an example of how I'm using it.

# attempts to read ENV["API_PASSWORD"], otherwise makes sure that the parent container has
# a service named api_password registered
ServerContainer.register_env(:api_password)

The above code will fail if you don't have ENV["API_PASSWORD"] defined, or if ServerContainer doesn't have a parent container with :api_password set. Typically I'm using a YAML file to populate ServerContainer's parent with sensitive values that I want to have in my development environment (and then I make sure to ignore that file in source control).

See the docs or the source code for more details.

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.