Making LOVELAND

Weequinox

Tue, 20 Mar 2012 20:41:00 -0400

This week marks the end of the WDET Call to Action 30-day drive for volunteer hours. We hope to segue this energy into another collaboration supported by the Knight News Challenge: you can help by voting for it!

We’re wrapping up proposals & contracts on a few new projects this week and starting to design them in earnest beyond vague outlines. First there’s a flurry of emails and shared design documents, giving way soon to code and mockups and live test sites. For now it feels like the calm before the storm.

During this breathing room between client work we’re building One Day In Detroit and blogging about it. Beyond a fun, hopefully useful app it’s also an exercise for us in openness, writing, and inviting a loose network of collaborators to design, hack and test.

Jerry has been attending hockey games, hobnobbing with the mayor, picking up rubble, running between meetings, sending mockups and brainstorms, and blogging prolifically.

Mary, as far as I can tell from across the continent, is keeping up communications with our clients and partners new and old, organizing our timelines and business dealings, juggling contracts, and raising puppies.

Happy equinox all! Many new launches, articles and partnerships coming this spring. And as always we’re on the lookout for talented Rails or front-end developers who dig our brand of crazy - drop me a line at larry@makeloveland.

❦

Remember to forget

Tue, 20 Mar 2012 17:31:00 -0400

Ok, so we all know caching is a good idea if not an absolute necessity for your production web servers. Why did it take me until last week to install memcached? Every smart architecture employs it or similar. I had this idea it was a painful setup process - not true. Getting your Rails app speaking the memcache is frighteningly easy.

Requests to certain apps (geographic searches, say… where the data changes infrequently) have been taking longer as the content size grows. The built-in file-based caching works for the basics but doesn’t cut it here because we need the data to expire & refresh every few hours.

It only took a few minutes to install the memcached server on OSX (brew install memcached) and Debian (apt-get install memcached). Once that’s running, the dalli gem gives you seamless action caching & session storage in Rails. (NB: The only issue was having to use 127.0.0.1 instead of localhost in the configuration.) Requests for Call to Action map data dropped from 500ms to 2ms. I’ve been strategically hitting the slow requests on our various sites, applying Rails action & fragment caching with excellent results. Don’t I feel silly having not tried this sooner?

❦

Hello folks! Today we have the beginnings of maps on One Day....

Mon, 19 Mar 2012 20:10:00 -0400

Hello folks! Today we have the beginnings of maps on One Day. This is one of Jerry’s test tours showing on a Google Map. Did you know they offer driving/walking/biking directions through the API? Yes indeed, just feed the Google server a list of locations and it’ll tell you the best route, complete with Polyline coords and turn-by-turn directions. I’ll also recommend their geocoder (which we’re using to turn addresses into lat-longs).

Next there needs to be a sense of order in these marker locations: how will we do it? Numbering? Animation? Only time will tell.

Identity

Sat, 17 Mar 2012 18:07:00 -0400

Today I stirred FB & Twitter sign-in into One Day In Detroit so that new folks can make an email/pass account or just press the one button and be done. It’s technically simple these days (I use devise & omniauth and it takes an hour to set up), though I grapple with the approach & justification for each new project. Do we require an account to play with the site? Which features? Will people need to choose Yet Another Password? Creating accounts is a drag, and with all the small experimental sites we craft at Loveland, we’d like everyone to feel free to experiment with a minimum of “drag.”

Last year I researched ways to share accounts across our sites so there’s just one “you” to remember. We called it your “LOVELAND ID” and I was really inspired by 37signals’ movement towards unifying their account system. I’ll tell you, no small task. Here are some approaches:

Shared database tables - in Rails normally each app has its own database. Well, you can tell your User model to connect to a different one… so if you point every User model to the same table you’ll be able to log in with the same credentials to each site, right? Yes, but I wouldn’t recommend this anyone. It’s a mess. It also requires every app to use exactly the same authentication library and user schema, making upgrades very sticky. I did this with the Inchernet and LoveTax originally (using authlogic, they are Rails 2 projects) and felt very clever. Okay, so I wanted to plug WDWOT in later, but it runs on Rails 3, and devise is the preferred way there. Shoot. You can massage your authlogic table and encrypt passwords using :authlogic_sha512. But this is a smelly approach.

CAS - RubyCAS is an industrial-strength single-sign-on solution. Pretty cool. I actually got this working with our Loveland database, roughly following this guide. It has a big, inscrutable, non-rails server component, and I shelved it because I didn’t find an easy way for users to sign up from the app.

OAuth - Very popular. I settled on this as the cleanest, most standard and futureproof way. We have one app that’s an OAuth provider and it holds onto all the user data and gives you the signup/login flow. Each of the other apps is an omniauth client; when you want to log into one, it sends you to the provider. This excellent guide will explain everything (and provide source code!).

Today, this foray doesn’t have much practical significance because we’ve decommissioned Living in the Map and LoveTax, so essentially it’s the Inchernet and WDWOT left. For clarity I’ve split them up and put the accounts back on their separate servers. In retrospect, instead of simplifying life confused the backend architecture and user interaction — people had to leave WDWOT and login on makeloveland.com, etc. Going forward, my choice now would be to rewrite the OAuth strategy with more foresight and factor it into a library reusable across each app’s code.

❦

Map Considerations

Wed, 14 Mar 2012 16:26:00 -0400

For the WDET Call to Action project I had the chance to reevaluate our map toolkits and check the latest offerings. Our requirements included solid mobile interactivity, flexible shape drawing (I dig GeoJSON), choose-your-own-stylishness, and - for the wide audience we expect - the most complete browser compatibility available - including IE. So I sat down with a mocha and compiled this chart. I used to love polymaps (it powers the inchernet and WDWOT), but it’s so bleeding-edge it doesn’t support IE (at all) or smartphones (very well).

Leaflet came out the clear winner, wrapped in Wax. I’ve been digging Wax and TileMill to present big datasets fast, especially to mobile viewers. See the difference between whydontweownthis.com, where Polymaps loads tons of client-side markers, and wdwot.com with its slick pre-rendered tiles. Each parcel is still clickable either way.

Astute readers may have noticed I didn’t mention the Google Maps API. It gets simple jobs done, isn’t very customizable, and I’d rather plug into the OSM ecosystem.

❦

Day One of One Day

Tue, 13 Mar 2012 21:28:00 -0400

Hi! I’m Larry and I write the code for LOVELAND Technologies. Lately I’ve been inspired by Jerry’s blog-a-day oath as well as my favorite design & development process blogs, including 37signals’ SvN, Etsy’s Code as Craft and BERG’s weeknotes.

So here we go! Yesterday we kicked off a new project, One Day In Detroit, and since Jerry’s going to be walking everyone through the process I will too. In later posts I’ll travel back through time to show you fun techniques from our other sites. Here’s what’s involved in spinning up a new app!

Create a new Rails project on my laptop and point my web server to it. I’ve always happily used Passenger and Preferences Pane, but today I’m trying out Pow (which is rad). Either way, a few seconds and you have a site running your app at http://oneday.dev.
You’ll want a database to go with that. Make an empty MySQL db on the dev machine (and on the testing server for good measure). Call them oneday_local and oneday_stage.
I sketch out the data models for the app, basically the high-level Things we’ll be manipulating. In this case, I’ll say Tours, Places, and Users. A Tour is a list of Places. Write down their attributes (name, description, location, etc) and run a “rails generate model Tour…” and “rake db:migrate” and you’re in business.
Caveats: you need to tweak the place.rb model file and Place migration for RGeo (see below) so that it makes your table spatial. And also use the Devise generator for your user.rb & migration… the docs cover this.

I’ll gather the building blocks (gems) for big chunks of functionality thanks to the lovely Ruby ecosystem. For starters let’s plunk these in the Gemfile:

haml for page templates. It’s just so much more pleasant than ERB.
devise handles user authentication & registration & so on. Full-featured, bulletproof, customizable, the industry standard for handling users in Rails 3.
omniauth works with Devise to not only add authentication to Facebook and Twitter, but several dozen other services. Awesome.
rgeo to work with geography features (it provides geometric data types and projection goodies. Works with MySQL spatial and PostGIS. The rgeo_json gem will translate geometry to GeoJSON for your javascript mapping pleasure. I like this path a lot, very intuitive and accomplishes a lot with notsomuch code.
exception_notification is a life saver when you administer over a dozen sites on your own. It emails you whenever there’s an exception in your Rails program. Simple!
kaminari for slicing your content into pages
nokogiri for parsing XML documents
andand offers you a fun shorthand for checking object properties; I use it all the time.
paperclip is photo uploading made super easy.

For the front-end libraries I’ll kick off with

jQuery in every project. Do I need to say anything about this?
Twitter Bootstrap gets you good-looking, snappy UI components and base styling.
960.gs for the 12-column grid layout (Bootstrap does this too now but I’m accustomed to 960!)
Wax & Leaflet for lightweight web maps. Leaflet rocks as an alternative to Google Maps - not only can you choose your tile-styles from CloudMade’s library, design your own, render your own with TileMill, but it plays nice with GeoJSON and works on your smartphone.

That’s the toolbox so far.

❦