Andy pointed me toward the #hackDPL event in July, and I figured it would be a good opportunity to contribute to the community and spread the word about Drupal. So Friday after work I headed down to Grand Circus and got to coding with 43 of my new closest friends.

Hackathons usually have a common goal, whether it's producing an implementation of a particular API, or creating an app around a particular theme. This hackathon was centered on providing a mobile 'app' for the Detroit Public Library, to help bridge the digital divide.

For the time being, you can see the completely-functional Drupal-7-based responsive website we made for DPL inside of 23 hours: compro #hackDPL staging. If you'd like the code, clone it on GitHub.

What can a Drupal nut do to be successfully at a hackathon? Here are some concrete tips:

10. Set up early, if you can

Some hackathons forbid working on your solution before the event, in which case you'll have to just be in the environment-setup mindset when you get there. If you can, though, build out a repo and a local and a staging environment with your install profile of choice. This will make it much faster to get up and running with the actual Drupal work when you arrive.

9. Learn with Drupal 8, compete with Drupal 7

I wanted to provide something of tangible value to the library, and to do it in the time allotted. Drupal 7 was the answer for this.

Drupal developers are notoriously in-demand, though, so a hackathon could be a good opportunity to take the time and try to build something with Drupal 8.

8. Combine devel_generate with copy/paste

I had the benefit of a great partner, Sharen, who was willing to paste existing content into the new site. This, in conjunction with devel_generate, gave the new solution both the look and feel of a finished app.

The judges are wowed by eye candy, and nothing fits the bill better than legible text and imagery.

7. Content types and Views = early and often

As with any Drupal project, most implementation comes down to constructing Views based on content types. If you can make a list of the content types you need, you can construct Features containing the types and the Views quickly, then deploy using Features. New fields (and most often their module dependencies) get picked up with "drush fua", so the turnaround can be really quick.

I spent the first 6 hours just making content types and views and rolling them as features. Sharen patiently waited for new things to add.

6. Don't take shortcuts with fields

This is likewise good advice for any Drupal project; if the field holds currency, use commerce_price. If it's a location, use addressfield (and add a geofield that's geocoded from it). If you find yourself putting lots of data in text and "long text" fields, it may be preferable to choose a more-semantically-appropriate solution from contrib -- it will certainly pay off later in the process.

5. Take advantage of contrib and Features

You can do some really cool stuff with contrib in a short amount of time. For instance, the leaflet view to show the various branches on a map was something I pulled off inside of a half-hour.

4. Theme the slug first before worrying about the wrapper

It's a habit of mine to paste in a slug of common HTML elements used in the body of content as the first node (basic page, simple input filtering). With a good starter theme, you should be able to give colors and styles to these elements very quickly, demonstrating the intended aesthetic before any sort of layout is in place.

The layout and other wrapper-specific stuff is subject to change, so theming it as the last piece is advisable.

It's just nice for the plain development site to have some color and indicate theming progress.

3. Take breaks and talk to people

I really don't remember the time I spent building content types and views. What I remember is talking with other attendees about how the Klingon Bird-of-prey in Star Trek IV: The Voyage Home took an impossibly-long amount of time to go around the Sun at over Warp 9. We nitpicked Star Trek, discussed the relative prowess of Street Fighter characters, and altogether had a good time.

Sure, you're not necessarily there to have fun. But especially as an Ambassador for the Drupal content management framework, it's good to get out there and meet people.

2. Sell the solution, not the philosophy

I think all the work came off the rails when I opened my stupid mouth in front of the judges.

Instead of doing an in-depth demo of how functionally-complete the site was and how well it worked on mobile, I spent a decent chunk of the allotted 5 minutes talking about open source software and how platform apps aren't the right fit.

If you find yourself in front of judges who will be seeing competing apps of all stripes, be sure to show off how cool the site looks and works. Chances are that the other entries don't have a usable and useful back-end interface out of the box. Use that to your advantage.

While we know the advantages of Drupal, hackathon judges care a lot more about look and feel. They give extra points to feature-completeness. You can build quite a functional site in 24 hours, especially with more than one person tackling the job.

1. Stage 5: Acceptance

In the days following the crushing loss at #hackDPL, I was more disappointed that the site would never see use than about not winning $5,000. In a short time the site had become my baby, and I was determined to deliver good work product to the people at Detroit Public Library.

The more people who participate in a hackathon, the less likely you are to win. Be ready to just give up on your beautiful site. If at all possible, try to use the time to do things that aid your during-the-week work, like:

• Implement grid styles
• Roll features for things like search_api

Altogether, #hackDPL was a fun experience with some hard work and learning mixed in. While I hope it isn't for a while, I look forward to participating in the next cool hackathon in Detroit.