• Read more about Rails + Girls = A Better Rails Community

The Rails community has had its share of misogynistic debacles over the last several years. Dominated by male programmers (recent statistics suggest 94% of employed Rails programmers are male), the inroads to professional Rails development for females are not exactly accessible or welcoming.

Of course, it's not just the Rails community that lacks representation from women. When only 18% of the Computer Science undergraduate degree recipients in 2010 were female (Source - NCWIT.org) it's obvious there is a lack of female participation in the entire field of programming.

Though the speculation of why this has become a problem is varied, Rails Girls is a movement that's focusing on the more important part of the equation - solving it.

No community can be considered healthy without a balanced representation in gender and race. That's why at Intridea we're excited to sponsor Rails Girls DC, taking place September 14-15th at the Living Social offices in Washington, DC. We're supporting Rails Girls because we want to foster a healthier community - one where women are building their great ideas alongside men, in equal numbers and with equal opportunity.

Women can apply now to attend the free development workshops that are taking place around the world including Germany, Estonia, Spain, Belgium, and more. Additionally, Rails Girls has open sourced their guides to organizing these events, making it easy for Rails developers to change the shocking statistics that plague our community.

We're looking forward to being a part of this great event. Additionally, we're hiring Rails developers and women are encouraged to apply!

• Read more about Five Tips for Hackathon Participants

This past weekend I participated in Hack the Midwest, a Kansas City hackathon. The event was a huge success drawing a crowd of around 100 developers. As one of the visiting developer evangelists said, it was a great turnout for a New York hackathon, much less one in the midwest.

At the competition I built Qup.tv, a simple service that will send you email alerts when Netflix adds new titles to its streaming catalog. I was lucky enough to win top honors at the event, but this wasn't my first rodeo. With three Rails Rumbles, two Node Knockouts, and a Startup Weekend under my belt I'm beginning to get a sense of what works and what doesn't. So here's my list of things to keep in mind when competing in a hackathon:

1. Have a Layered Strategy

You will never accomplish everything you set out to complete at a hackathon. Something at some point will take ten times longer than it was supposed to, so you need to plan for having multiple goals any of which could end up being the final product. Your first stage should be something that you expect you can complete in well less than half the time allotted. For example, here was my layered plan for Qup:

1. Users can sign in with their Netflix account and will receive emails of the latest Netflix releases
2. Users can add items to their queue or watch them with one click from the email. For queueing, users should not have to be logged into Qup or Netflix
3. Users can filter based on Netflix rating, Rotten Tomatoes score, and exclude genres they don't want updates about
4. Track usage activity to be able to show which of the titles are most popular
5. Add in support for Amazon Prime Instant Videos and/or Hulu

Even though my app won I only got through about half of what I thought I might be able to accomplish in 24 hours. I also ended up doing a decent amount of work tracking genres and usage activity which didn't show up in the final product at all because I didn't have time to polish and expose it. Which brings me to tip #2.

2. Cut Everything That Doesn't Work Well

It's a hackathon so judges will excuse a bug here and there, but regardless of how cool or important a feature is if it is likely to glitch more than 20% of the time you should cut it out of your final product. A smaller, less featured, but smoothly working project is going to win over a more featured but buggy project.

This applies to any kind of live demo in addition to a "go check it out" URL. Don't demo anything that the judges can't do themselves when they use the app (unless they don't get to use the app, in which case you'd better work hard to make sure your demo runs glitch free).

3. Style First, Substance Later

You can ignore this tip if you're working on a team with a dedicated designer (and how lucky for you if you are), but you should avoid the temptation to dive straight into the depths of coding when you start your project. Instead here are the things that you should do first:

1. Create some kind of logo for your project
2. Create the best looking landing page you can, even if it takes much longer than you'd like to spend on it
3. Create accounts on Twitter, Google Analytics, UserVoice, etc. Anything you'll want to have at the end create at the beginning
4. Buy domains, hosting accounts, etc. and get them all set up how they'll need to be

Why waste your time on all of these technicalities? Because the landing page is the first impression of your app that any judge will get, and if it doesn't impress them then you're already fighting an uphill battle. I spent perhaps the first hour and a half to two hours out of the 24 hour hackathon building the landing page for Qup, but that meant that I wasn't scrambling to make an ugly slapped-together mess pretty at the last second.

Integrate design and style as you go because when there's 45 minutes left you're always going to choose fixing a bug over polishing the interface.

4. Deploy Early, Often, Always

As soon as you have your pretty landing page and logo you should get your production environment up and running. If you can, use a Platform-as-a-Service like Heroku to take the operations burden off of yourself: you'll have enough to worry about on the app side.

Once you have a working production environment, make sure that you're deploying and smoke testing your code on a regular basis. There are almost always small (or large) problems that don't show up locally but do on a production box.

You'll notice that many of these tips have been about avoiding doing things at the end. That's because regardless of how carefully you plan you will be scrambling to fix earth-shattering bugs in the final minutes of the competition. It's tempting to put a tip like "don't deploy anything in the last two hours" because I've been burned multiple times by breaking something big while fixing something little at the last minute, but I won't. Instead you should be deploying SO FREQUENTLY that any fixes in the last minutes can be rolled back if they are deemed to be a bad idea.

5. In Presentations Show, Don't Tell, and Stop When You're Done

Your tech stack and the different ways you tackled the engineering challenges that your project presented are all very interesting. To you. Judges don't care, judges don't give a s**t. Instead keep your presentation focused only on the cool things your project does for the end user.

At Hack the Midwest we only had three minutes for presentations. Nearly everyone was running right up against the buzzer, so I was nervous. When it was my turn I gave maybe 20 seconds of exposition and then jumped right into the demo. I showed off my key features, anxious that any second I'd be cut off. In reality I probably still had a minute or more left. But rather than continuing to vamp about how I piped an RSS feed into an API queue fetch pool, I just stopped. I had already made my pitch, and I wouldn't do anything but hurt my chances from there.

Developers like to believe that code can speak for itself, and that's actually pretty true. However if your hackathon includes a presentation component you must speak for your code, so don't completely ignore a plan for presenting.

Do Something YOU Want

One last bonus tip is this: hackathons are about having fun, not winning. I've done seven of them and last weekend was the first prize of any kind that I've won. The beauty of the hackathon is that it gives you the opportunity to prove your mettle against yourself as much as against anyone else. It lets you say "what can I truly accomplish in X hours?". For me, this is a powerful drive and one that I'll gladly challenge myself with again and again. You can expect to see me in most every hackathon that comes around; I'm hooked.

• Read more about City Programmer, Country Programmer - Building Rural User Groups

Metro areas generally have really active user groups where Rails_Awesome_Lord presents regularly, famous hackers drop in to give presentations, and the Rails Elite throw smashing parties and drinkups after each meeting. But not all developers live in (or near) metro areas and can partake in such festivities. If you're among the rural band of outlaw programmers, this post is for you.

Portland, Maine isn't a tech hotbed by any means and when Adam Bair and I took over our small Ruby User Group after the last coordinator moved to NYC we were pretty sure that garnering attendance and participation would prove difficult in our area. However, to our surprise it wasn't hard at all. In fact, we found that Maine had a scattered yet hardcore group of programmers, each looking to find other programmers. We meet monthly and the size of our group fluctuates from 6-15 people depending on the month. We do very little outreach aside from Twitter announcements and messages to the Google Group. So what's the secret? How do you call the mavericks out of their programming caves and get them to join you?

Here are some tips for getting your own user group started, even if your village is but wee and agrarian:

1. Location - We host the user group right at our house. Since we already have all the necessary hardware (laptops, HDMI cables for hooking laptops up to the TV, seating, etc) it's convenient to just host everyone at our place once a month. It's much easier than lugging a bunch of equipment around, negotiating with companies to use their space, setting up equipment and so forth). Additionally, people tend to feel more relaxed in a house-setting which leads to more in-depth conversations, knowledge-sharing and time spent together.
2. Money - If you're hosting the user group in your own space (or in another free/low-cost charge space) you won't need a lot of financial support. It's worth asking your own employer if they would be willing to sponsor the event with pizza and drinks in return for handing out a few stickers and mentioning their support. Intridea sponsors our small group each month (along with several others) with pizza and drinks! If your employer can't help you out chances are that another member's employer might be willing to help you in exchange for some promotion.
3. Content - Herein lies the challenge that most user group coordinators are faced with! It can be cumbersome to come up with good presentations every month. Here are a few ideas:

• Presentations are not necessary for a rural user group. In fact, many of your members might dread public speaking and would probably appreciate a more casual format to the meetings until you all get to know each other better. Instead of official presentations, consider volunteering to show off some code you've been working on to the group. Afterward, it's likely that someone else will feel inclined to show some code as well. If the members can trust each other to be low-key (who wants to feel like they're going to work at the office when they go to a user group?) then everyone will end up sharing more information in the long run.
• If you do offer a presentation, keep in mind that it doesn't need to last 60 minutes, nor does it need to be delivered to the group as though you were presenting at RailsConf (unless of course, you are presenting at RailsConf and need somewhere to practice!). If you just want to run through some new code you've been working on and that takes 20 minutes, that's ok. If you want to put together a presentation on CoffeeScript, keep it light and engaging. Programmers just enjoy getting together to talk shop with each other. If we don't have anything officially prepared for the group then we'll open up the floor to people that want to show off some code.
• Ask other members to give presentations - if you hear that one of your members has been learning Backbone.js for a new project at work then ask him to present at the next meeting.
• It's beneficial to maintain a good relationship with other local/nearby user groups. Often our Portland members will caravan down to the New Hampshire and Boston Ruby User Groups if we don't have any concrete plans for our own group that month. This way, our members are still getting together and talking about programming.
• Twitter is your friend - Make sure you follow local (and local-ish) devs. If you catch wind that one of them is coming close to your town exercise those social skills and reach out to them - invite them to speak at your user group while they're in town! We've been fortunate to have generous programmers from the New Hampshire and Boston area who have travelled to give presentations to our group in Portland.
• Burn Out - If you start to feel burnt out, rather than let the user group die off, reach out to another regular member and ask for some help. There's no shame in taking a sabbatical!

With all of those tips in mind, there's also one more important thing to remember: a user group is a community. It takes a little bit of time and effort to build it, but once you've done that work it comes with all the benefits of any other close-knit community. If the community is cared for then it can become a tremendous resource to all of its members for anything from code advice, job hunting and mentoring to board game partners and craft beer enthusiasts.

If your area is lacking a user group, step up and host one; people will be thankful that you did! A house, a laptop, and a few conversations on Twitter is all you really need to get started. And maybe a year from now you'll be able to look around you and see a strong community of programmers gathered together, sharing stories, strategies, and experiences.

• Read more about 12 Tips For Teaching A Programming Class

As someone who has both attended and instructed many 2-5 day classes on programming topics, I’ve come to understand there are certain things teachers can do to make classes more useful and enjoyable.

Here are 12 tips to keep in mind when creating and teaching a technical course:

1. Rest- I’ve learned to make sure I get plenty of rest the night before I teach. I also make sure I have plenty of caffeine, water, and healthy snacks at my disposal during the day. Do not underestimate how much energy it takes to run a class.
2. Relax- You lose your train of thought, you freeze, you stutter, you sweat a little, you don't know the answer, you forget their names... Relax, these things happen. Believe it or not, your students want you to succeed and are very forgiving. Just realize that mistakes happen: handle it, and move on. If you can't recover quickly, simply make the class take a 5-10 min break to recover or defer to the other instructor.
3. Break the Ice with Introductions- For me, the hardest part of teaching a class is the first hour of class on the first day. You don't know the students and they don't know you. The best way to get around this is to quickly introduce yourself then have the students go around the room and introduce themselves. "Please tell us your name, where you're from (location, work), what's your specialty, and what you hope to get out of the class". This takes the pressure off you, distributes it across everyone in the room and gives you the time to get comfortable and ease into the role of instructor.
4. Labs- Lots of them. Labs are the most important aspect of teaching a class on programming. Students will not absorb the information from your lectures as well if you don’t give them frequent opportunities to put the material to use in a practical way. It's like playing a musical instrument - you can read about it all day long but when it comes down to making music there's no substitute for physical practice and interaction with the instrument itself. Knowledge is solidified during lab time. This is when most of the "Ah-ha!" moments occur.
5. Avoid Slides if Possible- Slides work really well for short presentations because they help support your succinct message; in the classroom, slides can actually hinder students from paying attention. Slides also have a tendency to kill the opportunity for spontaneous subjects. It's okay to go off on a tangent, especially if your students are engaged. Don't just read from a slide deck. Build things with them on the fly. There's nothing techies love more than live, working, and tweakable examples. Student: "How does that work? Why does that work?" Instructor: "Here, let me show you". That wins over slides every time.
6. Encourage Discussion- People like to talk. Give them frequent opportunities to talk with you and the other students about the material. I've found that if you encourage lots of discussion during the lecture (and throughout the course) people tend to help each other a lot more during labs. It creates a more lively and memorable environment. People pay attention more if an interesting conversation is likely to break out at any time.
7. Two Is Better Than One- Even if your class is small, it’s always better to have at least two instructors. One instructor can do most of the lecturing while the other can ask questions, point out typos, play devil’s advocate, gauge the students' engagement levels, and pay attention to the pacing. The secondary instructor can also walk over and help individuals while the primary is interacting with the rest of the class, ensuring a consistent flow. If one of the instructors gets flustered or loses their train of thought the other instructor can take over or help get things back on track.
8. Contextualize- Structure your class so that each topic builds on the previous one. Lay out a foundation and build upon it. Stick with the same application or domain space throughout the course. Put some thought into the transitions between topics in your curriculum and lay it out in a way that is comprehensive and progresses logically and predictably.
9. Legos- During the lectures and the labs you are giving students small building blocks of knowledge and inspiration. Don’t forget to give your students the chance to build something. Decide on an appropriate application to build throughout the course. This will help to solidify the knowledge and put those Legos to good use.
10. Break Often- It’s easy to get rolling on an activity or topic and forget about taking breaks. Set a timer for yourself if you have to because your students need plenty of opportunities to go to the bathroom, grab water, refill their coffee cups, stretch and socialize for a few minutes at least every hour. Pay attention during breaks; you'll quickly learn if people are having a good time or not. Be aware of mass exodus or silence.
11. Continuing Education- Make sure students learn enough to ask the right questions when they finish your course. Make sure you’ve taught them well enough so that when they try to practice the material a week later at home, they know how to ask the right questions, look in the right places, etc. Give them the equipment they need to succeed once your class is over.
12. Post-Course Availbility- Don’t disappear when all is said and done. Make sure your students know how to get ahold of you. Encourage them to seek you (and each other) out if they have questions or concerns. Ask them for feedback about the class. Create a Google Group so they can ask questions about the concepts after the class is done. This allows them to have access to you and the other students.

With these tips you should be well equipped to deliver a quality and exciting class that your students will talk about and remember for years to come. Teaching programming classes is an act of servitude, and one that is highly respected. Taking the time to create an engaging curriculum and a thoughtful structure will be of great benefit to you and everyone else.

Those that know, do. Those that understand, teach.

Aristotle

tl;dr

The format I've used which seems to work best (to keep folks engaged and encourage knowledge solidification) is:

For each topic:

• 30-40 mins of lecture
• 15-30 mins of lab/exercise
• 10-20 mins of discussion of different solutions
• 5-10 mins break
• Encourage lots of questions and discussion throughout all sections
• Always have a minimum of two instructors

• Read more about Vim Tip: Fast (and Easy) Project Searching

Our developers tend to have interesting conversations throughout the day in Socialspring Stream, our communication and collaboration application. It occurred to me today that it would make sense to take some of the useful tidbits of information that surface there and share them with the rest of the development community! After all, the conversations are captured already - all I need to do is bundle up the relevant bits of information and serve them to you via our blog; in other words, expect more quick posts of tips and tricks here!

Fast Project Searching With Ack

You can set ack to be grep within vim, in order to make searching within your project faster and more effective. It’s a great programmer search tool. Here’s how:

• Install ack (instructions found here)
• Then in your .vimrc file “set grepprg=ack”.
• Then whenever you “:grep ” vim will use ack instead of grep!

Why would you do this? Because its so much faster! BetterThanGrep cites these reasons (among others) in this list on their site (full list here):

Top 10 reasons to use ack instead of grep

• It's blazingly fast because it only searches the stuff you want searched
• ack is pure Perl, so it runs on Windows just fine. It has no dependencies other than Perl 5.
• Searches recursively through directories by default, while ignoring .svn, CVS and other VCS directories.
• Ignoring .svn directories means that ack is faster than grep for searching through trees.
• Which would you rather type?
  • $ grep pattern $(find . -type f | grep -v '.svn')
  • $ ack pattern
• ack ignores most of the crap you don't want to search
  • VCS directories
  • blib, the Perl build directory
  • backup files like foo~ and #foo#
  • binary files, core dumps, etc

Today's Vim tip was brought to you by Adam Bair, who was giving another developer advice on grepping over a project directory. Check back often for more tips, or follow us on Twitter for timely notifications about similar tips and tricks!

• Read more about .NET Meets Geospatial Rails at MADExpo

Last week, I packed my bags and headed for Norfolk, VA to speak at the Mid-Atlantic Developers Expo. I've spent the better part of the past year traveling the country, speaking about Geospatial Programming using Ruby and Rails. As a long-time lover of maps, the topic has been a joy to introduce to the community of Ruby developers, at both small regional conferences like MagicRuby or MountainRuby, and at major national conferences like RubyConf 2010 and RailsConf 2011.

MADExpo, however, was a different kind of conference. MADExpo is primarily a conference attended by Microsoft .NET developers. I was nervous about how my talk, primarily aimed at Rails developers, would be received by "the other side." What could I possibly tell a bunch of .NET guys about doing Geospatial apps if my expertise is Rails?

As it turns out, quite a bit. I was genuinely surprised by the interest, attention, and questions I received during and after my session. Most folks were genuinely interested to learn how Rails developers are doing GIS apps, and had insights to offer about how certain problems are solved using .NET.

One of the main points of my speeches on Geospatial Rails is that "we should draw inspiration from outside our bubble of knowledge." Old-school desktop GIS has a lot to teach web developers about what is possible, what is useful, and what is realistic. MADExpo made me realize that there's another piece of this argument that I had been missing. Not only should we be looking at what desktop GIS can teach us: we should be looking at what users of other web stacks can teach us as well.

The slides from my presentation are available on Scribd. I welcome feedback and ongoing conversation about the future of Geospatial programming, and I'm looking forward to bringing a modified version of this presentation to the fifth annual Lonestar Ruby Conference in August this year! Hope to see many of you there. In the meantime, feel free to leave your comments below or ping me with questions on Twitter!

• Read more about When Programmers Need Marketers

If you’re a programmer these words might make you feel unwell. To an outsider it seems like the Marketing crowd dresses themselves with esoteric buzzwords in order to mystify and confuse the rest of us. But to be fair, most (real) marketing professionals are creative and brilliant problem-solvers and avant-garde engineers within their own culture — just like most programmers. It’s best not to mark and avoid the otherworldy marketers, though it might be tempting. Whether or not we understand their language and their seemingly mystical approach — we need them.

In just under four years at Intridea we’ve grown organically from a small 3-person startup with a great idea to a full-fledged, profitable company of nearly fifty employees. Most of us work remotely, and we are spread out across the United States and even across the world in a few cases. There are certain aspects of this operation that we have mastered over the years: we know how to hire brilliant engineers and designers; we know how to deliver outstanding quality; we know how to nurture a strong and respectful relationship with our clients. But as our company grows to new heights we encounter new challenges. Currently we’re faced with the challenge of hiring a strong Marketing Director to build and promote our brand, develop advertising strategies, and help to increase our presence. Finding the right person is a lot harder than we thought it would be.

As a web and mobile development shop, we have interviewed our fair share of developers over the years. Github is a service that has actually made this task significantly simpler. It’s hard for a sub-par developer to hide behind bad code that’s visible to the world. And since most Ruby and Rails developers these days have Github accounts, it has become easier to make more informed decisions about who to hire. The same cannot be said for hiring marketing professionals. As a company of developers, designers, and QA engineers entrenched in the web and mobile development communities, we’re not exactly tuned in to the wacky world of marketing. Trudging through the marketing muck (and trust me, it gets mucky) has proved to be toilsome.

The biggest problem is that there isn’t a clear way to vet people that claim to be marketing professionals. We have found that simply looking at their career history is not a good enough indicator of their level of competency. It’s too easy for marketing pros to sound “expert” by lavishing their resumes and Twitter profiles with extravagant buzz words and phrases. And every marketing expert and their first-born have worked for at least one large corporation. Who’s to say that they actually did anything of value during their one year stint for Pepsi Co? Or that they were actually responsible for the strategic branding of Urban Co-Op Something-or-Other that sold to Bigger Co-Op Something-or-Other?

Additionally, it’s hard to find a Marketing Director that has experience working specifically with web development companies and distributed teams. A Marketing Director for a growing Ruby on Rails and mobile development shop will need a different set of skills and expertise than a Marketing Director for a large Fortune 500 company. And since most marketing experts are not programmers or techies in general, they won’t already be familiar with our culture or our existing brand and strategy.

Marketing experts and people pretending to be marketing experts are both good at one thing: they know how to talk. They sell themselves really well. So how do you tell the really good ones from the “I have 3000 Twitter followers so I’m a marketing expert” types? We don’t know. And that’s why we haven’t hired a Marketing Director yet.

How do other growing companies approach this problem? Aside from combing through resumes and giving thorough, speculative interviews, how do you sort through the scores of self-proclaimed “gurus” to find the brilliant marketing types? We know that marketing is a legitimately necessary field and that most of the people in that field are awesome at what they do. Unfortunately, there’s a lot of noise at the entry level and it can be difficult to identify the true experts. Without code samples and a tight-knit community, it’s hard to know who to trust and where to find the innovative marketing experts that can really take our brand and presence to the next level. We would love to hear how other development companies have approached this challenge!

If you’re reading this and you’re bursting to tell us that we’re totally wrong about marketers, and you know because you happen to be the kick-ass marketing expert that we’re looking for, then send us an email and tell us why we need you. Talk to us candidly about what makes you different from the rest!