Close and Go BackBack to Viget

Events

RailsConf 2009 Wrapup

Ben Scofield
Ben Scofield, Technology Director, May 11, 2009 0

I've been back from RailsConf for a few days now, and I've had a chance to reflect on the things I learned while in Las Vegas for what turned out to be my favorite RailsConf yet. Elsewhere, I wrote about my overall impressions, but for this post I want to focus on several of the sessions I attended and participated in.

Teaching Rails BoF

RailsConf for me really started Monday night, with the Teaching Rails Birds of a Feather session that I moderated. We had a great turnout (somewhere in the neighborhood of 30 people), and the attendees ranged across a number of different disciplines — some people were teaching in a university setting, some were writing books, and others were interested primarily in building the community through educating new developers. Regardless of their backgrounds, though, everyone had good ideas and experiences to share, and I learned about a number of exciting new efforts (including the various components of the RailsBridge effort and the upcoming Rails Tutorials project).

The Even-Darker Art of Rails Engines

Tuesday, I attended James Adam's session on Rails Engines. I heard great things about his presentation on plugins from the 2008 RailsConf, so I had high hopes about this one. As it turned out, the presentation itself was decent, but the content was a little too basic for me — we've looked fairly carefully at the engines support in Rails as the next step for our resourceful plugins, so most of what James talked about I'd already seen. I do have to say that the DHH-headed cherub slide was a real winner, though.

Continue reading "RailsConf 2009 Wrapup"

Look Out! It’s Developer Day in DC!

Ben Scofield
Ben Scofield, Technology Director, April 15, 2009 0

That's right, folks, we're opening up registration for Developer Day in DC. If you're interested in new and exciting developments in technology, you should mark May 30th on your calendar — we've got talks planned on hot-off-the-code-press Ruby 1.9, Cucumber for acceptance testing, and Lily and the Monome, and we're adding more even as you read this.

The inaugural Developer Day in Durham was a hit, and we expect this one to be even better, with more diverse technologies represented and more people to connect with. So join us on May 30th in Falls Church for a day full of engaging talks and good food, all for the low, low price of $50!

Note: If DC is a bit too far for a day trip, don't despair! We're planning on continuing to expand Developer Day to other cities. Email me at ben.scofield@viget.com if you're interested in more details.

Stop Pissing Off Your Designers

David Eisinger
David Eisinger, Web Developer, April 01, 2009 7

A few weeks ago, our local Refresh group pitted me (representing web developers) against Viget designer Mindy in a battle for the ages. Our talk, “Ten Things Designers Do That Piss Developers Off (and Vice Versa),” offered a back-and-forth look at some of the issues that crop up between web professionals. Despite the overwhelming strength of my arguments, I won’t deny that she got some good shots in. Here are some of the key lessons I took away.

Stay off the bandwagon

One of Mindy’s best points was the tendency of developers, when selecting technologies to use on a project, to go with what’s new and hip rather than what’s the best fit or what will yield the best final result. I think we can all relate to learning a new technology or technique and then wanting to immediately apply it to whatever we’re working on.

Technology bandwagon-jumping goes hand-in-hand with another common problem: over-engineering. In my experience, when a chosen technology is a bad fit for a project, it’s typically because it’s too powerful. An over-engineered solution is a nightmare for the next developer — in a past life, I maintained a Spring-powered, Lucene-searchable monstrosity running on dedicated hardware that would have been better served with a WordPress install on Dreamhost.

When selecting technologies, stick with the best fit, whether that’s what you know best or what will lead to the best final product. If you’re just dying to try out some new technology, do what I do: redo your personal site (in lieu of actually posting any new content to it).

Avoid the knee-jerk “No”

Picture this: you’re sitting at your desk one morning, happily reading Hacker News, when an IM window pops up on your screen. It’s your PM, and she’s got a new feature request from the client. It’s not a major change, but it will involve a substantial overhaul of the messaging system you built. What’s your response? Be honest — you give her seventeen reasons why the requested change is a bad idea.

When discussing feature requests, keep in mind that the ultimate goal is to create the best product possible. Requirements change, and though it sucks to complicate elegant solutions, sometimes change is necessary. As an added benefit, if you avoid staying “no” instinctively, when a truly bad idea lands on your plate, your objections will carry a lot more weight.

Remember: you are not the user

Mindy noted a trait common to many developers: a lack of empathy for the user, or rather, the mistaken idea that we ourselves are the typical user. In other words, developers are prone to creating features that they would want to use, regardless of how well they might serve the actual audience of the site.

When deciding on geeky features, it’s important to keep your audience in mind. If you’re designing a site about web productivity, by all means, go nuts — bookmarklets, keyboard shortcuts, customizable RSS feeds, the whole nine yards. But if your site’s intended audience is, say, gardening enthusiasts, your time would probably be better spent elsewhere.

But in the end

We all want to create the best web sites possible. Disagreements arise about definitions of “best”; while a designer wants a site that’s attractive and intuitive, the developer wants one that is stable and maintainable. In the end, these qualities aren’t mutually exclusive — the highest-quality websites have them all.

Mindy has posted her thoughts on the talk, and our slides are available on SlideShare. And if you’re in Durham (or lesser nearby cities), come on out to the next Refresh meeting.

Adding Gitjour to Your Hack Night Toolset

Patrick Reagan
Patrick Reagan, Development Director, March 26, 2009 1

I have been interested in finding an effective way to use gitjour to share code with others during hack night gatherings, but I never really sat down to figure out the correct workflow. Until last night, that is.

At the Potomac Hackers meeting, David and I decided that we were going to collaborate on something that involved Sinatra, CouchDB, and the DataMapper CouchDB adapter. We didn't get to work on any of those things, but we did make some progress toward gitjour mastery. Here's what we did:

Continue reading "Adding Gitjour to Your Hack Night Toolset"

Developer Day in Durham Is a Wrap

Ben Scofield
Ben Scofield, Technology Director, March 23, 2009 0

So our first Developer Day came to a close on Saturday, and everyone I've heard from loved it. Andy Hunt's opening keynote on Refactoring Your Wetware started everything off on the right foot, and throughout the day we had great talks on git, JavaScript, Scala, music, Ruby, and more. Add on the food (catered by downtown Durham's own Rue Cler), and we ended up providing a great experience for the attendees and speakers for a more-than-reasonable price.

In fact, we had such a fun time with this that we've decided to do it again! Stay tuned to the website and twitter for more information on Developer Day DC in late May — the high-quality, low-cost local conference at its finest.

We're the Developers

at Viget Labs. We write about web development trends, tips, best practices, industry events, and our projects — all with an emphasis on Ruby on Rails.

Contact Us

Have any questions, comments, ideas, or secrets to share? Let us know.


How many days in a non-leap year?

Sorry, you need to have Javascript enabled to use this form. (Don't blame us, blame the spammers!) If you'd like to contact us, please visit our Contact page.