• Read more about OAuth2 Gem: Just in Time For Facebook's Graph

While I’d been tracking with great interest the progress of OAuth 2.0, Facebook lit off the powderkeg yesterday by announcing that their entire API was moving to the protocol (as well as to RESTful JSON). As a developer who had been constantly confounded by the relentlessly hostile environment that Facebook seemed to present to developers, yesterday was a sudden and welcome about-face. The acquisition of FriendFeed, it seems, gave Facebook the talent they needed to do it right this time.

But anyway, on to the news! We have just released a gem for OAuth 2.0 to work with the new Facebook API. You can get it right now:

gem install oauth2

We wanted to get this into the hands of developers ASAP so for now the functionality is pretty much limited to the “web server” type of authentication (the protocol includes many different strategies, all of which will be implemented on the gem over time) and has been tested to work with Facebook’s new API.

So how do you use it? Here is an example Sinatra application containing all of the code necessary to authenticate and then perform requests against the Facebook API.

require 'rubygems' require 'sinatra' require 'oauth2' require 'json'  def client   OAuth2::Client.new('api_key', 'api_secret', :site => 'https://graph.facebook.com') end  get '/auth/facebook' do   redirect client.web_server.authorize_url(     :redirect_uri => redirect_uri,      :scope => 'email,offline_access'   ) end  get '/auth/facebook/callback' do   access_token = client.web_server.get_access_token(params[:code], :redirect_uri => redirect_uri)   user = JSON.parse(access_token.get('/me'))    user.inspect end  def redirect_uri   uri = URI.parse(request.url)   uri.path = '/auth/facebook/callback'   uri.query = nil   uri.to_s end

So now you’re ready to get started with the new Facebook API! This is still an early release, but I’ll be working on it a lot in the coming months, partially as preparation for my talk at RailsConf in which I’ll be delving into the OAuth 2.0 specification and what it means for Rails developers in-depth. The code is, of course, available on GitHub where you can report any problems you run into. Enjoy!

Update: Those who aren’t terribly familiar with the protocol may wonder why OAuth 2.0 isn’t just rolled into support of the OAuth gem (or why I didn’t fork it and do it that way). Honestly, I would have liked to, but OAuth 2.0 is an almost entirely different beast than 1.0a and they share so little functionality that it would basically be two projects living under the same gem name. So that’s why!

• Read more about Rack Middleware and Rack Applications: What's the Difference?

Rack is the common Ruby web infrastructure powering just about every framework known to Ruby-kind (Rails, Sinatra and many more). Rack Middleware are a way to implement a pipelined development process for web applications. They can do anything from managing user sessions to caching, authentication, or just about anything else. But one thing that confused me for a long time: what’s the difference between a Rack application and Rack middleware? Both are ostensibly the same, something that responds to #call(env), so how are they different? Unlike Rack applications, Rack middleware have knowledge of other Rack applications. Let’s take a look at what this means with a few simple examples.

The simplest Rack application (in class instead of lambda form) would be something like this:

class RackApp   def call(env)     [200, {'Content-Type' => 'text/plain'}, ["Hello world!"]]   end end

Note that because the method required by the Rack specification is call and (by no coincidence) this is how you execute Procs and lambdas in Ruby, the same thing can be written like so:

lambda{|env| [200, {'Content-Type' => 'text/plain'}, ["Hello world!"]]}

This hello world app would simply output “Hello world!” from any URL on the server that was running it. While this is obviously simple, you can build entire powerful frameworks around it so long as in the end a request boils down to a status, some headers, and a response body. But what if we want to filter the request? What if we want to add some headers before the main application gets it, or perhaps translate the response into pig latin after the fact? We have no way to say “before this” or “after that” in a Rack application. Enter middleware:

class RackMiddleware   def initialize(app)     @app = app   end      def call(env)     # Make the app always think the URL is /pwned     env['PATH_INFO'] = '/pwned'     @app.call(env)   end end

See the difference? It’s simple: a Rack middleware has an initializer that takes another Rack application. This way, it can perform actions before, after, or around the Rack application because it has access to it during the call-time. That’s why this works in a config.ru file:

run lambda{|env| [200, {'Content-Type' => 'text/plain'}, ["Hello world!"]]}

But this does not:

use lambda{|env| [200, {'Content-Type' => 'text/plain'}, ["Hello world!"]]}

Because the ‘use’ keyword indicates a Middleware that should be instantiated at call-time with the arguments provided and then called, while ‘run’ simply calls an already existing instance of a Rack application.

This is something that can be quite confusing, especially if you’re new to the Rack protocol, so hopefully this clears it up a bit!

• Read more about Ruby Quick Tip: Instant Utility Modules

Sometimes you want to write a batch of utility methods that can be accessed from a module for example Utility.parse_something(string) or any number of useful little tools for your application. Here’s a very clean-looking way to achieve it:

module Utilities   extend self    def parse_something(string)     # do stuff here   end    def other_utility_method(number, string)     # do some more stuff   end end

By placing "extend self" at the top of the module, you are telling it to include all of the methods defined on your module as class methods on…your module. Which means that you can now access them like other class methods! While there are other ways to do this, I think this is a very semantically clean way that gets it done quite nicely.

Update: And this is exactly why I post these Quick Tips, because sometimes there’s another solution that I hadn’t heard of! Using Ruby’s module_function you can achieve the same effect:

module Utilities   module_function      def parse_something(string)     # do stuff here   end    def other_utility_method(number, string)     # do some more stuff   end end

The module_function method either takes multiple symbols as arguments for the methods to turn into module methods or, if invoked without arguments, will cause all subsequent methods to be defined as module functions. You can read the Ruby documentation about it here. Ultimately I’m not sure which I’d go with, as module_function is pretty esoteric (I’ve never come across it in code that I’ve read), but so is extend self. It’s your call, developers!

• Read more about Intridea Insider: Brendan Lim

This week on the Intridea Insider, meet Brendan Lim, our Director of Mobile Development.

If you're a member of the Ruby on Rails or Mobile Development communities, chances are you've heard of Brendan Lim. He started his career off with a bang after creating Yappd (a Twitter clone with pictures) in 2007 with Brent Collier. Soon after Yappd was acquired by his former employer, Kajeet, Brendan met with Dave Naffis, Senior Partner at Intridea, and began working with the Intridea team after his obligations to Kajeet had been fulfilled.

His last two years at Intridea have not been quiet. He started by helping out with client projects, but his talent for coming up with and creating applications was quickly noticed. Brendan always has fresh ideas and can quickly transform those ideas into working applications. His first endeavor in mobile development with Intridea was to create a mobile version of Present.ly, our microblogging application. Since then he has created several mobile applications, including three apps to help you find the best Curry (iCurry), Pho (iPho) and Sushi (SushiMe) food anywhere using your iPhone.

Brendan's Car Finder app, which makes brilliant use of augmented reality, garnered attention from sources like Wired, boingboing, and Cult of Mac. Time recently mentioned Car Finder in their "10 Tech Trends for 2010" article. And most recently, Brendan created Grub.it, an application to help users find top-notch dishes at their local restaurants, with fellow Intridean, Pradeep Elankumaran.

I asked Brendan how he comes up with product ideas and how those ideas evolve into applications: "Almost every idea I've come up with has been a result of needing a solution to a problem that wasn't already solved, or because I thought I could accomplish something better. For example, the idea for Grub.it surfaced because we wished we could find the best hidden meals in every town. And we came up with Yappd because we wished Twitter had better photo integration at the time." He credits his girlfriend, Edel, with supporting his new app ideas and acting as the first beta tester for most of his applications.

Brendan has been building quality applications at Intridea for the past couple of years, but he has always been gifted with ingenuity. As a young teenager he was heavy into gaming; after his brother introduced him to HTML and web design he created video game review sites like, N64Xtreme and VGamers.com. "I would contact the PR departments of video game publishers and ask to review upcoming titles. I remember for the Nintendo 64, I bought one game and ended up with 50."

Most high school gamers have only dreamt of being able to review games in order to support their gaming hobby. But then Brendan took it about ten steps further when he met some of the people from Gamers.com and was offered a job managing video game pages for several platforms.

Along with his many computer-related hobbies, Brendan was also into video production as a teenager. As a freshman in college, Lexus paid him to make a video of their driving school. You can see some of his recent videos on Vimeo, including this one called Insomnia. He is also a talented photographer, which is a hobby that started with an interest in automotive photography and has now lead to landscape, city, creative, and portrait photography.

Although Brendan was a typical "geek", only several of his close friends were privy to his computer-related hobbies. I asked him why his geekery wasn't made public, and he explained, "I wrestled and played a little football in high school. I'd hang out with my friends for a bit but as soon as I came home I would just stay on my computer. It was where I was most comfortable".

Brendan entered Auburn University in Alabama as a pre-med student, but quickly realized that it wasn't for him. The school had just received funding from the owner of Verizon to start a software engineering program with a focus on wireless technology. The Wireless Software Engineering program was a perfect fit for him, considering his computer background and his love for collecting tiny, unlocked cell phones from overseas.

While Brendan was studying full-time at Auburn University he also had a lot of jobs. "I spent more time working and doing projects than I did studying. I liked teaching myself how to learn new languages by making things on the side." He loved creating solutions to problems even back then: "I created a Rails app for school called Notefad that allowed my friend and I to share and edit notes during class. I'd be terrified to look at the code now, but it was fun and actually helped us out."

But he didn't just create apps to meet his needs as a student; in fact, he built several applications with his friend while he was in college: "We started Freebielance, which was similar to eLance. We also did CheckoutSource which we were developing as a payment gateway. That didn't work out too well. We built it all out, applied for a merchant account, and then realized we couldn't afford it!"

Now, as the Director of Mobile Development, Brendan gets the opportunity to come up with lots of product ideas and to work on apps for several different platforms. Although Brendan started using Rails while he worked at Kajeet with Brent, he now finds himself using a lot of Objective-C, which he claims to love; "I'm actually a big fan of Obj-C. Although, for our client work we're using Appcelerator's Titanium platform. It allows us to develop iPhone and Android apps (fully native) using their JavaScript API. It definitely helps save time by letting us get apps out quicker for multiple platforms using a single code base."

Brendan has an intensity and energy about him that you can see in his work. He gets fired up about an idea and he executes on it flawlessly and without fuss. And when he's not coding like a ninja, or shooting video, or taking pictures, or relaxing in his new condo, then he's probably out giving presentations. "In the past month I did a talk at RubyConf India about MacRuby. I also did a talk at the MobileX Conference in Nashville on Building Native Apps with Titanium and gave the closing keynote. I'll be going to the MobileX Conference in Lexington this week and will be doing the same Titanium talk, an Introduction to Palm webOS talk, and the closing keynote again."

Of course, Brendan loves his mobile devices just about as much as he loves developing for them. I had to ask him what his favorite apps were for the iPhone and his new iPad. His list of favorites goes on endlessly, but he especially loves Keynote, "because I can work on my presentations from the iPad and actually show off my presentations on it. I actually had to do a whole talk using my iPad today at the Atlanta Mobile Devs Meetup because I couldn't find the projector!" He also really likes the Epicurious app, which aids him in his effort to cook more at home. The Eyewitness app is another one of his favorites, along with Netflix, Air Video, and Things.

Brendan is young but has already come across great professional success. He gets to wake up everyday in the city that he loves, and walk over to his desk in his loft to start work for the day. His ingenuity, raw talent and work ethic have brought him to where he is today: from a gamer hiding his geekery from his high school wrestling friends, to an accomplished Director of Mobile Development with Intridea. And we're lucky that Brendan loves us as much as we love him: "I love it at Intridea. I love the people I work with. It's like a family here."

• Read more about Intridea Brings Kansas City Barbecue to Ruby Midwest

Ruby Midwest is an upcoming two-day, single track regional Ruby conference taking place in Kansas City on July 16 and 17. Today they announced their speaker list (including our own Michael Bleigh, a Kansas City native) and we’re happy to blog about our involvement with the conference. Intridea is sponsoring OMGWTFBBQ, a dinner at the conference hotel with Kansas City barbecue open to all attendees after the first day of the conference.

Catering will be provided by Fiorella’s Jack Stack Barbecue (it’s delicious, trust us). So if you’re heading to the conference (with keynotes by Yehuda Katz of Engine Yard and Chris Wanstrath of GitHub) and you want to take a few hours, enjoy the best food Kansas City has to offer and socialize with your fellow Midwest Rubyists, RSVP for OMGWTFBBQ today!

More details will be announced as the conference draws near, but we’re looking forward to helping make Ruby Midwest’s first year a runaway success as a regional conference. See you in Kansas City!

• Read more about SASS & Static Webpages (No Framework, Please!)

Here is a quick tip for users who like the idea of using SASS-powered stylesheets, but may not want to bother setting up a development framework to do so.

A Really Quick Intro to SASS

If you’re not familiar, SASS (“semantically awesome stylesheets”) builds off your existing CSS knowledge, but tosses some dynamic spice into the mix. The result leaves you with increased power and flexibility as a coder/designer.

The result is code that is easier to read, takes up less space, and supports the very helpful nesting of styling rules. Another tremendously useful feature is the ability to use variables throughout all of your stylesheets — something that becomes invaluable when working on larger websites or applications. SASS also supports mixins, operations, and beyond — learn more at the SASS website, or by reading Michael Bleigh’s excellent SASS intro.

SASS with static websites, you say?

Until somewhat recently, I’d only used SASS when jumping in to help with design work on pre-existing, larger Rails applications. This works great, as the markup is already in place and changes are easy to make. My SASS experience in this regard has been a good one.

When coding a new, larger site from scratch, however, I’ve never found a satisfying approach to use SASS from square one. I’ve dabbled with a few different SASS-compatible static website frameworks (Middleman, StaticMatic, etc) — but never felt comfortable enough with these to full integrate them into the beginning of my HTML/CSS coding process. As such, my preference has remained: build the layout in static HTML, and when fully coded & styled, integrate into the Rails app. Sadly, SASS fell by the wayside too often with this approach.

But finally, thanks to the latest beta versions of the HAML/SASS gem, an accessible solution lies in wait. This setup will auto-compile your SASS into CSS whenever changes are made. Best of all, no additional framework setup or files are needed… just what I’ve been looking for. Make it happen as follows:

1. Install the latest HAML/SASS gem

When I discovered this technique, the latest gem was installed as follows:

gem install haml-edge

However, in the meantime there have been beta releases of SASS 3.0, which should achieve the same ends. install this gem as follows:

gem install haml --pre

If you’re curious if anything more recent has been released, check out the HAML/SASS blog.

2. Setup your local project directory

Do this however you like: I usually start with an index.html and fresh directories for stylesheets, images, and javascript. Populate with any templates/frameworks you may have, as desired. Just make sure you have a directory for you SASS files in place. Here is an absolute bare-bones version to show how this technique applies:

3. Summon the sass --watch kraken

Finally, from the command line, run this line to make the magic happen:

sass --watch path_to_sass:path_to_css

The path before the colon is wherever your SASS files are located… the path after the colon is where you want the CSS to be generated. Of course, your HTML should reference the location of the CSS files. Keep in mind: when styling this way, any changes you make to a CSS file will be lost if/when the SASS file is changed (the overwrite is automatic).

Also note that you will need to run this step each time you want to enable auto-compiling SASS. It will run in the background, and instantly take action if a SASS file has been changed.

And that’s it. Whenever you make changes to any SASS files in the directory you specified, the corresponding CSS files will be automatically updated (and created, if necessary). This lets you benefit from the dynamic nature of SASS without requiring any framework setup.

• Read more about Toggle CSS3 Bookmarklet

If you’ve begun to use CSS3 experimental features in your sites lately such as box-shadow, border-radius or text-shadow, you know how much pain it can take away from the design process. Unfortunately, lots of people are still using Internet Explorer and can’t see all these pretty additions you’ve added.

I thought it would be useful to have a simple way to run a sanity check on my design to make sure it wasn’t going to look awful or unreadable once all of the CSS3 goodies were taken away. With that in mind, I created a bookmarklet that will toggle the display of all of that modern goodness.

Just drag this link: Toggle CSS3 into your bookmark toolbar. Then, by clicking it, you can turn off (and back on) the most common CSS3 improvements. Once installed, if you visit a page such as CSS3.info and click the bookmarklet, you should see the CSS3 effects toggle off.

Note that this is a simple, none-too-bright bookmarklet and only removes the obvious traces of CSS3. It doesn’t inspect your CSS for non-supported color values (like RGBA) or deal with many of the more advanced features of CSS3. In fact, all it does is eradicate these styles:

• border-radius
• box-shadow
• text-shadow
• border-image
• background-origin
• background-clip

However, it’s still a useful tool if you’re designing for the future with an eye for the past. Enjoy!

• Read more about Intridea Insider: Brent Collier

This week on the Intridea Insider, meet Brent Collier, Senior Engineer at Intridea and unofficial Apple spokesperson.

Brent's Mom always worked in IT, so he had the advantage of being raised around computers from an early age. He grew up playing video games like RC ProAM and Gran Turismo. But his engineering skills were first born and cultivated through building with Legos, long before he ever touched a computer or gaming console. Like many software engineers he had a curiosity for understanding the mechanics of how things worked from a very young age. "I've always been into building and taking things apart. I like to know how stuff works."

Although Brent later enjoyed tinkering with hardware as a teenager, he entered VCU in Richmond, VA with the intention of studying art. "I did lots of drawing and a little sculpture as a kid but I quickly realized that there was no money in art and then moved to Mechanical Engineering." Mechanical Engineering was a natural choice for Brent since it coincided with his interest in building and fixing things. Eventually his passion for software development surfaced and he switched to Computer Science. He explains that although he had fun working with computer hardware, "I didn't really get into software as much until I was in college. I just didn't realize how much information about it was so readily available until then."

Armed with a CS degree from VCU, he went out into the world and claimed a Java job with a consulting company in Richmond. He wasn't in love with the client-focused world of consulting, so when a friend nudged him to interview with Kajeet, a mobile start-up in Bethesda, he jumped on the opportunity.

Yappd had incredible potential and quickly got press from sources like TechCrunch, Mashable and PCMagazine.com. Brent was thrilled about the possibilities for Yappd, but it was quickly acquired by his employer.At Kajeet, Brent met Brendan Lim (Check back next week for an Insider post on Brendan). "We quickly became really good friends, and we used to sit around thinking up start-up ideas. Twitter was just starting to pick up in 2007 and it always annoyed me that you couldn't seamlessly upload pictures, so we ran with the idea and created Yappd. That was the application that got me started with Ruby and Ruby on Rails." So Brent and Brendan poured their energy and free time into building Yappd, a Twitter clone with pictures.

Brent started at Intridea with Brendan several months after Yappd was acquired. He was hooked on Ruby and didn't want to continue working in Java. He says that, "Java just felt crusty and gross" after working with Rails.

Since starting at Intridea, Brent and his wife Amy (whom he met while bartending at Bennigan's) moved from his home state in Virginia to the Raleigh/Durham area in North Carolina. They wanted to raise their two boys, Cameron and Dillan, in a safe and family-oriented location. He enjoys the lack of traffic congestion in Raleigh/Durham compared to the DC/MD/VA areas, along with the lower cost of living and the nicer people.

In the last year at Intridea Brent has worked on a multitude of projects, but his favorite was Earthaid, a home utilities monitoring service. "They monitor your usage and suggest ways to lower your energy consumption. It was a quick, somewhat small project, and we had a dedicated, full-time designer which makes any project better!"

When Brent isn't working on a development project or playing with his kids, or being a ninja with Brendan, he tinkers a bit with Obj-C and mobile development. He has done a little work on some Titanium projects and is looking forward to more. He proudly admits to having a love affair with Apple (which coincidentally began around the same time he switched from Java to Ruby), and wants to develop apps for Apple devices like the iPad.

I asked Brent if he has a favorite Mac app, and although he insisted that he loves all Mac apps, I did get him to suggest CloudApp: "One of my most recent favorites is called CloudApp; you just choose a file and drag it to the menubar then you get a link automatically copied to your clipboard. It's super useful and I probably use it ten times a day!" He advocates that CloudApp is much quicker than Skitch if you don't need to annotate.

Like many of Intridea's engineers, Brent gets to work from home. He prefers to work at his kitchen table with the house windows wide open and sunlight pouring in. He codes to trance or garage rock for inspiration and attributes AWDWR and The Pragmatic Programmer as the books that motivated him to be a great programmer. He is another example of how a childhood filled with Legos, video games and nurtured curiosity can result in future adult awesomeness.

• Read more about iPad Wallpaper Template for Photoshop

The iPad has arrived, so let the design fun commence! Featured here is an iPad wallpaper template in Photoshop (PSD) format (download), allowing you to easily create & test your new background creations with minimal layer nightmares.

The PSD is setup to let you view a single wallpaper layer (or layer group) in several common scenarios:

As you can see, you'll need to take into account how the app icons, bottom dock, and lock screen UI will interplay with your wallpaper – while also throwing the orientation variable into the mix (horizontal or vertical). Before we dive in, here is a crash course on how iPad wallpapers work. Quite simply:

The coolest thing about this PSD template is that you can view a single wallpaper layer in four different iPad viewing scenarios – all with absolute minimum in layer visibility headaches. How it works:

First, open the attached Photoshop template and paste/insert your 1024x1024 wallpaper image into the "Wallpapers" layer folder. Ensure your image is perfectly aligned within the template guides. Note: you'll want to hide the "iPad" layer group so it doesn't get in the way.

Once your image is in place, make the "iPad" layer group visible again. Enable visibility in either the horizontal or vertical layer sub-group, and then make visible either the lock screen or home screen layer -- all of the above to suit your desire.

Voila! An iPad of your desired viewing scenario will be overlayed on top of your wallpaper. Next, you can simply hide/show layers within the "iPad" group to see how your wallpaper looks in different situations. You'll never need to move your wallpaper layer.

With any hope, this template will be of great service to you. Download the PSD here.

Finally, I must give acknowledgements to teehan+lax for their excellent iPad GUI PSD, which was a helpful resource. DigitalCitizen.ca also has a helpful article I used to learn up on the subject. Check out both of these sites if you want to read more. Otherwise, go forth and design!

• Read more about Ten Keys to Building an Enduring Ruby Users Group

Intridea founded and sponsors the DC Ruby Users Group, which has been a great success. Our monthly meetings average around 30 attendees, but some have had twice as many.

While I would not be so bold as to claim I've found the secret to successfully organizing and running a local Ruby Users Group, there are some things I believe have contributed greatly to our group's success:

1. Be welcoming and inclusive. It's a stereotype, but not one without some truth to it: a lot of techies tend to be introverted. At every meeting, I make it a point to ask who is at their first DCRUG event and welcome them. Furthermore, as responsibility-juggling allows, I also try to greet attendees at the door and introduce myself. Invariably, some folks will sit quietly, keep to themselves, and leave after the lectures — but I hope they leave with a desire to attend again, perhaps even as a presenter.
2. Appeal to multiple levels of skill and experience. At recent meetings, a show of hands has indicated that about half the attendees are not experienced Rubyists, and are looking for a chance to learn introductory concepts. An advanced topic would be overwhelming. At the same time, our core group of Rubyists want to learn more about these advanced concepts. Our solution: make sure that each meeting has at least one talk that appeals to newbies (e.g. "Intro to Rails models") and one that will interest experienced Ruby developers (e.g. "Background Jobs with Resque").
3. Cover a variety of subjects. Our talks on cutting-edge technologies like MongoDB and XMPP have been great, but not every talk needs to be software-related, or even technical. Two of our most popular presentations have been regarding legal issues that affect software companies and tips on how to give great presentations.
4. Meet on a consistent basis. We hold our meetings on the second Thursday of every month (except when a record-setting blizzard makes travel impossible). This makes planning simpler and the predictable timing helps attendees leave room in their busy schedules.
5. Don't "reinvent the wheel": use Meetup.com . Initially, we used a homebrewed system for scheduling DCRUG meetings, but then realized it would be more efficient to leverage the work Meetup has already done. They are completely focused on making it easy to organize gatherings and we've been quite happy with the service.
6. Publicize through various channels. Don't wait for them to come to you! Meetup now has a nice feature that lets attendees cross-post their RSVP to Facebook and/or Twitter. Additionally, DCRUG has its own Twitter account and we cross-promote to other groups nearby, such as the ones in Northern Virginia and Baltimore.
7. Make yourself a checklist Seriously, even for an informal meeting, there are so many moving parts — lining up speakers, coordinating with the hosts, ordering food, publicizing the event, thanking the appropriate people, etc. — that you'll invariably forget something. I create a bulleted list in Google Docs and, after each meeting, simply make a copy of that document for the next DCRUG, editing as appropriate.
8. Location, location, location! We have been fortunate enough to have StreamSage allow us use of their sizeable and Metro-accessible space, for free. This, alas, is easier said than done, but not impossible. It is crucially important that you find a meeting space that is conveniently-located for your attendees, or they will be far less likely to attend.
9. Follow up each meeting with a get-together Ruby user groups provide not just an educational opportunity, but a social one as well. After every meeting, we head to Post Pub, a bar located a block away. Many folks go with soda as their drink of choice, but this isn't about getting a buzz. Rather, it's a chance for attendees — presenters and audiences — to socialize in an informal environment and talk anything, Ruby-related or otherwise, with their peers.
10. Free pizza and soda! It may sound silly, but is surprisingly effective. Our meetings start at 7pm, which means many attendees come straight from work and are hungry. Prior to the first presentation, the boxes of piping-hot Domino's pizza and cold soda at the back of the room serve as a place for attendees to congregate and chat, instead of just sitting in their chairs, waiting for the meeting to begin.

For those of you looking to start a local Ruby Users Group, I hope this helps you kick it off successfully. For folks who are looking to improve an existing one, I hope you find this helpful. And I hope everyone will come by and check out a meeting of the DC Ruby Users Group.