Better Endeavor Blog - Home

Speaking Engagements

2008-07-02T17:03:00Z

I recently found out that I'll be speaking at both RailsConf Europe and the Lone Star Ruby Conference with a few of my Intridea colleagues..

RailsConf Europe

Michael Bleigh will be presenting our RailsConf Europe talk: Hacking the Mid-End: Unobtrusive Scripting and Advanced UI Techniques in Rails, on September 3rd. Here's the talk overview:

As web application development advances beyond the static page, a whole new field of development is emerging. In the Javascript behavior layer and markup abstracting helpers lie the ’Mid-End’: advanced user interface problems that don’t fit traditional ‘back-end’ and ‘front-end’ models. Explore this new field with case studies and real code such as usage of Lowpro Javascript behaviors to keep the behavior separate from the markup. Learn how to give back-end developers the tools to create simple, repeatable, quality markup through block-accepting helpers. Discuss the methods that allow for rapid development of complex interactions in new and exciting ways and see real examples. Finally, look into the future of the Mid-End and what lies ahead for user interface development.

Then, immediately after my talk, I'll board my plane to head off to..

The Lone Star Ruby Conference

Adam Bair, Pradeep Elankumaran, and I will be leading a training on the first day of the LSRC. The training is titled: Rails Refactoring: Triage, Prevention, and Performance. And the overview:

Maybe you inherited a mess of a Rails project – or perhaps your own codebase is poorly-tested, not very DRY, or just generally confusing. Worse yet, maybe your Rails site has slowed down to a crawl or even stopped working entirely. Whatever the reason, it’s time to consider refactoring these rough spots and boosting your site’s performance.

In the first half of the day we’ll go through real-life examples of (shameful) code we’ve written and refactored, give tips on how and when to start, and show you how to avoid the need for a future refactor. In the second half, we’ll introduce common Rails performance pitfalls, how to diagnose them, and how to solve them. We’ll also talk about other ways to speed up your app.

If you're attending either conference, stop by and say hi!

Launching CrowdSound - Easy User Feedback

2008-05-14T14:11:00Z

Intridea just launched our newest product - CrowdSound. CrowdSound is a tool that allows companies and websites to gather, organize and respond to suggestions from their users. It is available as a customizable widget that you plug into your own site.

Here my own CrowdSound widget. (The typical widget is 250px wide - I customized this to be 650px):

Please try it out, and then sign up at CrowdSound for your own!

Speaking at RailsConf 2008

2008-03-24T05:51:00Z

I recently found out that I'll be speaking along with Josh Owens at Railsconf 2008. We'll be speaking about our experience rapidly building web applications during the first Rails Rumble, a 48-hour contest for developing a Rails site from concept to completion.

Railsconf 2008 will be held in Portland, OR on May 29th - June 1st. Stay tuned for scheduling details.

Emerging from hiding - and launching VisualCV.com!

2008-02-11T11:51:00Z

Seeing how I haven't posted a single thing in over a month, I can see how you might expect the worst. Have no fear, I have not been abducted by aliens, nor have I been jailed for embezzlement (yet). I have merely been toiling day and night with my Intridea teammates on an exciting new project for our VisualCV clients. I am pleased to annouce that all of our hard work has finally come to fruition, and www.visualcv.com launched early this morning.

From the start we knew VisualCV would require a lot of effort and long hours, and we were right! Thanks to the coding efficiency Ruby and Ruby on Rails allow us, as well as the agile methods we put in place, we were able to meet very tight deadlines.

VisualCV aims to replace the traditional paper resume with an online version that allows you to present images, audio, and video alongside traditional resume content. The VisualCV management team and advisory team is impressive, headed up by Phillip Merrick, former CEO and Chairman of webMethods, so we're expecting good things from this endeavor.

Stay tuned for updates on VisualCV, as well as some more technical posts about some of the technology we used and some tips and tricks I've picked up.

Check VisualCV out now!

[UPDATE]

VisualCV has been generating a lot of media buzz so far - check out some of the coverage below:

TechCrunch
Washington Post (registration may be required)
See the official press release

In the News

2007-12-16T11:02:00Z

Intridea is starting to get a national reputation for Ruby on Rails knowledge - several of us were recently contacted by eWeek.com for an article on Ruby on Rails 2.0. Adam Bair and I both had some comments that they chose to run - check it out to see what we had to say:

Ruby on Rails 2.0 Users Give Thumbs Up

ActAsTaggableOn - Advanced Rails Tagging Plugin

2007-12-04T17:06:00Z

One of my Intridea co-workers, Michael Bleigh, has put together an excellent tagging plugin, called ActsAsTaggableOn, which is meant to be a replacement for acts_as_taggable_on_steriods. ActsAsTaggableOn allows for multiple tag sets per model - for example, a user could have tag sets for sports, interests, music, etc. You can then reference the tag lists as user.sport_list, user.interest_list, and user.music_list, in addition to getting them all at once with user.tag_list

Here's his blog post with more details

RubyConf 2007

2007-11-16T08:27:00Z

The 2007 RubyConf was a couple of weeks ago (Nov 2nd-4th) in Charlotte, NC . I attended with a few of my Intridea colleagues – Pradeep, Michael, and Jeremy. So this post is not all that timely, and I imagine anything worthwhile to say about RubyConf 2007 has already been blogged about to death. Not only that, but I was part of a panel at last week’s DCRUG meeting, where we discussed RubyConf, so I have already probably talked the topic to death. And yet, still I write… must be the egotist in me that assumes my 2 subscribers want, nay – need, to know there weren’t enough men’s restrooms, or there should have been more coffee on the last day. Here on the Better Endeavor Blog, we get into the meat of things and tell you what’s really important.

Some Persistent Themes of RubyConf 2007

1. Ruby != Rails
There was an obvious push by the organizers of RubyConf to differentiate Ruby from Rails. Rails is a runaway success and has helped propel Ruby into prominence, and yet there were no exclusively Rails-focused talks, and most only mentioned Rails as an ancillary portion of the presentation. That said, a majority of the attendees were doing Rails development as opposed to non-Rails Ruby development.

2. RubyConf != RailsConf
The organizers also seemed to want to differentiate their conference from RailsConf. From the small size to the (at times) disorganized schedule, RubyConf had a more “folksy” feeling (to quote Chad Fowler).

3. Alternate Ruby VMs
The second morning was devoted to alternate Ruby VMS with people from IronRuby, jRuby, and Rubinius each talking for an hour about their implementation.

The Rubinius talk was by far the most interesting – instead of talking about high-level technical details, Evan Phoenix (the main Rubinius dude) compared lines of Ruby code in each of the projects. IronRuby, jRuby, and Matz’s Ruby each had less than 100 lines of Ruby code, with thousands of lines of other stuff (C#, Java, or C). Rubinius, on the other hand, was approximately half Ruby and half C, and steadily tilting more towards the Ruby side. His point was that a Ruby programmer can more easily contribute to a project developed in their language of choice.

4. Testing
So in case you haven’t heard – all the cool kids test, and so should you. And most of the super-cool kids are using Rspec for testing. I’m neither cool nor super-cool yet, but I’m working on that. One point that was given several times in the conference was that testing matters much more than which testing framework you choose.

Quibbling, Grousing, Bellyaching, and Nitpicking
(or Suggestions for Next Year’s RubyConf)

The RubyConf website was oddly lacking in details – especially for a technical conference. Most conspicuous in its absence was the address of the hotel where the conference was being held. I would have hoped for location information, abstracts, sponsorship opportunities, and additional information. Maybe next year a conference wiki so intrepid conference goers could provide some of the content?
The usual slow wifi complaints – this doesn’t need to be explained.
There were some very unfortunate room assignments – one time slot in particular was standing-room-only in the smaller room, while the large room was sparsely (at best) attended. I definitely understand it can be difficult to predetermine attendance, and this was the first year with multiple tracks. Perhaps a survey or recommending the use of a conference attendee scheduling tool?
Refreshments – on the last day there were no refreshments available after lunch. Since the close-by Starbucks was closed, that left a bunch of programmers with nothing to drink, and worse yet, no caffeine!
Breaks – I really could have used more of a mid-morning and mid-afternoon break. Most of the talks were good, but sitting and listening for hours on end is tiring!

Praises, Accolades, Commendations, and Flattery
(or I Really Did Have a Great Time)

Despite the lack of Rails topics, there were a wide-range of talk topics. There were talks on everything from Optimizing C Extensions, to What Makes Beautiful Code?, to VOIP, to Rspec.
Good city – from the bits of it that I saw, Charlotte is a really nice city. There was little traffic, the streets were clean, and there seemed like a lot to do.
Good venue – the 3 ballrooms we used at the Omni worked well for all-in-one-room talks in the mornings, and two different talks in the afternoons. There were also many hotels and restaurants within walking distance.
Great people – I meet a lot of kickass people at RubyConf, and especially had a great time hanging out and tossing ideas back and forth with my new Intridea co-workers.

Matz

Matz ( for the unwashed masses – Yukihiro Matsumoto, the creator and chief designer of Ruby ) was a good sport and agreed to have a photo take with me and my Intridea peeps. Thanks (for the photo, and more importantly for Ruby)!

(From left to right – Pradeep Elankumaran, Matz, me, and Michael Bleigh)

Amazon Web Services Startup Challenge

2007-10-31T07:50:00Z

Intridea has officially entered three products into the Amazon Web Services (AWS) Start-Up Challenge. We're very excited about the products, all of which should be launching on November 5th.

Scalr

Scalr is a complete turn-key hosting solution that’s self-curing and self-scaling. It based on EC2 and provides an easy, web-based interface for setting up and managing your servers.

MediaPlug

With MediaPlug, website operators can add social media (images, audio, and video) to a website in a fraction of the time, at a fraction of the cost, and without the need to learn complex video transcoding systems. In addition, uploads are offloaded to MediaPlug servers to reduce the burden on the customer website.

SocNet

SocNet is built on Intridea’s MediaPlug and Scalr products, and allows customers to quickly create a social networking site that can scale to millions of users easily.

Startup Weekend DC - Suggestions For Future Dev Teams

2007-10-30T05:52:00Z

Startup Weekend DC has come and gone – in 54 hours we envisioned, designed, developed, and deployed HolaNeightbor. We had a large development team full of talented programmers, and I had a great time working with them all. I’ve had some time to think about the experience – what went right, what went wrong, and what I’d do differently. So, without further adieu, here are my:

Suggestions for future Startup Weekend development teams

Send instructions out to all developers prior to the weekend on how to properly install any required software – in our case, subversion and Ruby on Rails.

Find a production server before the weekend starts, make sure you have someone experienced in deployment, and deploy to a test environment as early as possible.

Have an design integration team. This team would work with the design group to create XHTML/CSS mockups, and then with the development team to incorporate the designs.

If possible, decide on a limited set of CSS selectors early on that developers can use while creating their views, and the designers can then use to apply formatting.

Don’t get too caught up in “the right way to do it” – there is plenty of time AFTER the weekend to refactor code. We made an early decision to develop using REST, which backfired a bit, since not everyone was up to speed on RESTful routes.

If you have a large group of developers, pair-program. There are only so many chunks you can break a project into, so assigning a two-person team to a task makes a lot of sense. Also, errors tend to accumulate in conjunction with lack of sleep – an extra set of eyes can avoid typos and other silly mistakes.

Use plugins, but only if someone has used them before. Why re-invent the wheel? – a lot of functionality is out there, free for the taking. If you do use a plugin, however, make sure you have someone who has used it before and can configure it correctly. A lot of extra time can be spent trying to make a plugin work if you don’t know what you’re doing.

Do the simplest thing possible first. Get your basic functionality in place first, THEN shoot for the moon.

Take a break. Make sure you get up every hour or so for a few minutes. Every few hours take a 15 minute break. Be sure to stretch – especially your shoulders.

Get some sleep. We didn’t work past 1:00am any of the nights, and I think that worked well for us. If you do decide to go the crazy route of little sleep, try drinking an energy drink followed immediately by a 20-minute nap – that’s just enough time to freshen you up while not making you groggy.

Enjoy yourself! StartupWeekend is fun – you’re spending the weekend with a bunch of other sharp developers, hacking together a cool product. Though starting up a company is neat, half of the coolness of the a Startup Weekend is the people you meet.

Startup Weekend DC - Day 3

2007-10-29T07:04:00Z

Day 3 of Startup Weekend was a bit of a blur, contributed to by a lack of sleep combined with a rushed deadline. Early in the day, things were looking positive for a midnight release with a significant batch of features. We were continuing to add and improve upon features, and designers were working on getting mockups of key pages together. Unfortunately, things did not continue to go smoothly throughout the day.

Funky Problems

We ran into a couple of odd Rails problems - first we had trouble with the Rails image_tag method.

<%= image_tag @photo.public_filename %>

Running the above would result in the following error

You have a nil object when you didn't expect it!
The error occurred while evaluating nil.to_sym

After spending quite some time trying to debug the error, we eventually gave up and hard-coded @photo.public_filename into the <img src=""> tag.

The second strange problem was with the restful_authentication. Though I couldn't replicate the error on my box, other team members were receiving errors about a frozen object.

We were, unfortunately, unable to resolve either problem and ended up writing some hackish code to make things work. These two issues ate up time that could have been spent on important features.

Incorporating the Design

On Saturday, the designers told us they'd be able to code up the XHTML/CSS so we could concentrate on delivering features. The design team, however, was quite small compared to the development team, and just didn't have the manpower to deliver on that goal. Throughout the day the design team worked on creating mockups of key pages for us. The mockups looked outstanding, but, unfortunately, turned out to be graphical, rather than XHTML/CSS mockups, which meant we had to slice them up ourselves. Several developers took a turn at working on the CSS, and a homepage and inner template were pieced together.

Shaving Features To Make Launch

As midnight loomed, it became obvious that we'd be unable to launch with a full feature set as planned. Strange rails problems, along with having to incorporate the CSS, just sapped too much of our development strength. To make matters worse, we didn't receive access to our production server until mid-day, which meant one developer had to spend most of his day dealing with server-related issues. As a result, we began cutting feature to try launch with a limited feature set. Anything that was particularly unstable was the first to go, and then features that were only partially implemented and easily hidden.

Narrowing our focus to the essential site functions helped get us back on track.

A Released (if Flawed) Product

At 11:57pm, we had made our final commits, deployed the app, and HolaNeighbor was launched to many cheers from those still hanging around. Champagne was poured and there was much celebration... until someone tried to sign up and was promptly greeted by a Rails error. It turns out migrations had not been run and the database was not working. That was easily fixed, and we could call it a weekend.

Overall thoughts for day 3:

Better communication between development and design team could have resulted in incorporation of the designs. The design team came up with some great looking concepts, but there just wasn't time to implement them.
Overall, I had a great time - I learned some new coding tricks, made some new friends, and became a co-founder of a company. Not bad for 54 hours! I'll definitely do StartupWeekend again if it comes to the DC area.
A special thanks to all those involved with Startup Weekend - the weekend was a major success!

Startup Weekend DC - Day 2

2007-10-28T07:06:00Z

Day 2 of Startup Weekend started out with a surprise. The night before a consensus had been built by a small group, and two members were going to combine those ideas into a 5-7 page powerpoint. Apparently they had their own ideas, because what was agreed upon by the small group, and what was presented were far apart.

Morning Surprise

The small group had agreed to focus on building social networks for community organization, and to focus exclusively on condo associations for the weekend. One of the main benefits of this approach was security - since user accounts would be created by a network admin (probably a condo board member), users could be assured that everyone in the group was an actual resident of the community. This approach also gave us a target group to sell the application to . We came up with a simple, but useful set of features based around the idea of 3 main type of information - People, Resources, and Notices.

What was presented did somewhat resemble what had been agreed upon - a location-based social network. Two key elements, however, had changed (along with several smaller details):

Instead of focusing tightly on community organizations, a social network could now be created by anyone that wants to. The network can be defined geographically using zip codes or by drawing a polygon on a map (this option was widely regarded by the dev team as not doable in the weekend.)
Instead of belonging to only one network based on belonging to a community organization , users could now belong to many networks, with a central page aggregating information from all networks

After this presentation I was starting to feel discouraged - I wasn't really interested in building a new Facebook, which is what this seemed to be moving towards. I was also bothered that two people had hijacked the whole project and basically made it what they wanted it to be, regardless of the consensus built by the small group the night before. This discouragement only grew as the User Experience team came up with their own idea of what was being built. Two hours into the second day, with no code being written, I had serious doubts that we'd be able to come together, and was considering packing it up and heading home.

Afternoon Delight

Once we actually started some coding, things started to improve. Reps from UX and Dev got together and hammered out a features list that both groups could agree on. For the first part of the day we worked on finalizing a data schema, writing specifications for models, and then starting to code those models up. The second half of the day we started to work on controllers - adding in small pieces of functionality at a time. The Design team was also working hard during this time, and was able to hand the design to a developer for conversion to XHTML/CSS.

We were expected to present a prototype of what we had at 9:00pm - and we would have met that if not for crippling network issues that left us unable to make subversion commits. After a drawn out process of doing commits one at a time, some of the design was integrated and we had some basic functionality to present to the group around 9:45.

Midnight Coding

Though I was not all that impressed with what we accomplished during the day, the demo was a major success. We were only able to show some basic things like creating an account, logging in, uploading photos, and some basic entry of resource, but the other teams seemed extremely pleased with what we had so far. The founder of Startup Weekend, Andrew Hyde, who has been at each of the weekends so far, said we showed more, by far, on Saturday night than any of the other weekends. Aw shucks, you must say that to all the development teams!

After the demo, after the network issues were resolved, and after a lot of people left, a core team of developers were left, and we really cranked through a lot in a short period of time. There is still a long way to go tomorrow, but I'm confident we can launch with a reasonable set of features by midnight Sunday.

Overall thoughts for day 2:

There are a lot of very strong personalities in the groups, and early in the day there was a lot of head-butting, espcially between Development and User Experience.
I don't think that breaking up into such tightly defined groups early on - Development, Design, User Experience, Marketing, Business Develpment - is that great of an idea. Many people have overlapping areas of interest and could have valuable input to give to several groups. I don't claim to have a perfect solution, but I think having at least one representative from every group embedded in the other groups could foster better communication.
The dev team is so large that we have trouble communicating and getting stuff done when we're all together. It wasn't until most people left and only 6-10 developers were left that we really hit our stride.

Startup Weekend DC - Day 1

2007-10-27T06:19:00Z

This weekend I'm participating in Startup Weekend DC, which is, to quote the blog - "an idea, an experiment, a chance to gather the tech community and create a company over one jam packed weekend." I just returned from the first day...

Choosing An Idea

Our first goal was for the day was to choose the idea for our startup. After about 3 hours of several rounds of voting and group discussions, we settled on Social Networking for Condos. The idea was to build a social networking application that condo associations could use to help foster communications between residents. I can't say I was too jazzed about this idea, since I think the whole social networking thing is overdone. That said, it is a good application for the large team of developers we have (30+), since there are definite, concrete sections of functionality that can be broken down and divided among teams.

After making the decision, we broke into teams by area of expertise (Development, Creative/Design, User Experience, and Marketing/Business Development.) In my group - the developers - we quickly decided to use Ruby on Rails since a majority of people were familiar. After finding out that a box was being provided for development, we also decided on using Apache/Mongrel/MySQL as the rest of the stack, and subversion for source control.

Defining the Project

In theory, each group was supposed to focus on their niche and then come back together with something to present to the other groups. This is where things started to break down. Each different group had their own idea of what the site was going to be, who the target customer would be, revenue streams, etc. After a great deal of debate between the groups, a smaller group of us from each team met to come to agreement on the most very basic functionality. After even more debate among the smaller group, we could all agree that we were building a social networking app for condos that would help solve condo-related communication problems.

This pretty basic idea was presented back to the whole group. More discussion followed about specific features, and people were still pulling in several different directions. The option to completely scrap the idea and start with something new was presented, voted on, and scrapped. It seemed to me that the organizer was getting very frustrated at our lack of progress at this point. It was decided that the small group would barricade ourselves back into the room until we came up with a vision for the product.

Yet more discussion and debate followed, and we eventually settled on some base pieces of functionality that we could all (for the most part) agree upon. Two people volunteered to stay and put the thoughts and ideas together into a short PowerPoint to present Saturday morning, and the rest of us packed up to head home.

Overall thoughts for the first day:

Though I wasn't really excited about the Condo Social Networking idea, I quickly started to see how such a product could be useful, and potentially marketable.
I was surprised how many directions the different groups took the idea of a social networking app. Social networking apps are pretty well understood at this point - I didn't think it would be difficult to all agree on at least a base level of functionality.
Sometime during one of the endless rounds of discussion someone said that people needed to make sure they were arguing to attain consensus, rather than arguing to win the argument. He said arguing to win an argument seems really prevalent in DC - can't say I disagree with that!
I'm a bit worried about the size of the development team. I think, even with using a pair-programming approach, we're going to be stepping on each others' toes quite frequently.
That said, I can't wait to get done with this idea-generation phase and actually get into some coding!
I'm hoping to mainly fill a testing role, and getting to use some of the rspec fu that I learned at the Pragmatic Studio last week.

Test-Driven Development with Rails Studio

2007-10-20T03:30:00Z

I recently returned from the Pragmatic Studio's Test-Drive Development with Rails studio. I've been to several Pragmatic Studios, and have come to expect very high quality instructions from people who know what they're doing and are actually using the stuff they are teaching - the TDD studio definitely lived up to my expectations. The instructors were Joe O'Brien and Jim Weirich (of rake, rubygems, and flexmock fame).

I'm a bit ashamed to admit I have not been much of a tester in my Rails development thus far. I've always recognized the value behind testing, but just hadn't had the impetus to really get me going. The main reason for me attending this studio was to provide the kick in the ass to get me started with testing... and it succeeded.

The first two days covered traditional Rails unit and functional testing, while the third covered rspec. The best parts, in my opinion, were the pair-programming live code demos put on my Joe and Jim. In the demos, Joe would write the test while Jim would implement the code for that test. It really cemented in my mind the idea behind Red (initial failing test), Green (passing test), Refactor (cleanup and refactor code).

We also covered some other really cool technologies like cruisecontrol.rb (a tool for continuous integration) and Selenium and FireWatir (tools for automating testing in the browser).

Now that I've seen some real-life TDD, I'm looking forward to incorporating it into my own development practices.

Rails Rumble

2007-10-16T00:32:00Z

Last month I competed in the first annual Rails Rumble, a Ruby on Rails coding competition. The idea behind the competition was to design, develop, and deploy a fully-functional Rails application over the course of a weekend - 48 hours. Teams could consist of up to 4 people, but I chose to go solo. Why? Probably because I'm a little bit nuts...

My entry was Your Pet Records - an online repository for pet health information. This isn't a site that is too useful to the general public, but I could see it taking off in a niche market if presented correctly. The site allows users to create an entry for each of their pets and then add health information for their pets - vet visits, allergies, medications, and the like. The user can then create printable PDF sheets for pet sitters/walkers or if they move to a new vet. If developed futher, vets would be given logins and the ability to update information for any pets they saw in their practice.

The competition was a lot of fun. I got to play around with some new tools - like deprec for setting up the Rails stack. I also got to jump around from role to role - sysadmin installing a required library one minute, to designer tweaking some css the next minute, to developer coding up some new functionality the next. Of course that meant I probably didn't do too stellar a job on any one piece!

Some of the things I noticed as the competition went on, and my lack of sleep accumulated:

Browser Testing - I never really did test the site in anything other than Firefox on Mac until 11:30pm on Sunday. It was one of those tasks I kept putting off, figuring I'd get to it eventually. As a result, my site is broken in IE7. It looks completely fine - except for the minor glitch of not having a login box! Oh well - less learned - it pays to browser test early!
Subversion - at the start of the competition, my svn commit messages were quite detailed - "Added validations to pet model and enhanced error messages on pet creations page" - as the competition wore on, my messages eventally turned into messages like "changed some stuff" This would probably be more detrimental on a larger team.
CSS code - as I hacked away at the design of the app, I found myself more and more writing inline CSS code instead of extracting it into an external CSS file. I think this was because I didn't have a whole lot of time to plan out the CSS.
IRC / other competitors - it was amazing how helpful people were on the #railsrumble IRC channel. Even though we were all competing with each other, people were very quick to offer suggestions and links to resources whenever someone else had a problem.

Results were announced at Ruby East - I didn't place in any of the categories, but was happy with how my weekend project turned out - and I'd definitely do it again next year. Hats off to the winners and honorable mentions - there were some really great apps out there!

New Beginnings

2007-10-12T02:00:00Z

Hi, I'm Chris, your friendly neighborhood Ruby on Rails programmer. For the last 10 years I've moonlighted as a freelance web developer, spending my evening and weekends coding and designing, while also holding down full-time jobs. Most recently I've been employed by George Washington University, where I've worked full-time as a web developer for the past 2.5 years. Today was my last day at GW, and is also my last day as moonlighting freelance developer.

Why the big changes? I've accepted a position at Intridea, a DC-based Ruby on Rails development shop. Though I enjoyed my time at GW, and my many late nights of coding for my freelance business, I'm really looking forward to focusing all my efforts toward building Intridea. I've already been chatting with some of the guys there, and I know I'm going to learn a lot, because they're all really sharp. I'm also going to be able to play with cutting-edge Rails stuff that I've wanted to take for a whirl - stuff like unobtrusive javascript, Amazon Web Services, sass, and Rspec (among others).

Making the leap is helping to kickstart a few other projects that I've been putting off for a while. This blog, for one. I've been meaning to put this blog together for almost a year now, constantly having ideas that made me say "hey, I should blog about that." Now I have a place to do that. I'll be cross-posting some of the more technical articles on the Intridea blog, but some of the content here will be unique. I hope this blog will eventually be a good place for Rails tips, tricks, and wisdom, though you'll have to be the judge of that!

Better Endeavor Blog - Home

Speaking Engagements

RailsConf Europe

The Lone Star Ruby Conference

Launching CrowdSound - Easy User Feedback

Speaking at RailsConf 2008

Emerging from hiding - and launching VisualCV.com!

In the News

ActAsTaggableOn - Advanced Rails Tagging Plugin

RubyConf 2007

Some Persistent Themes of RubyConf 2007

Quibbling, Grousing, Bellyaching, and Nitpicking (or Suggestions for Next Year’s RubyConf)

Praises, Accolades, Commendations, and Flattery (or I Really Did Have a Great Time)

Matz

Amazon Web Services Startup Challenge

Scalr

MediaPlug

SocNet

Startup Weekend DC - Suggestions For Future Dev Teams

Suggestions for future Startup Weekend development teams

Suggestions for future Startup Weekend development teams

Startup Weekend DC - Day 3

Funky Problems

Incorporating the Design

Shaving Features To Make Launch

A Released (if Flawed) Product

Overall thoughts for day 3:

Startup Weekend DC - Day 2

Morning Surprise

Afternoon Delight

Midnight Coding

Overall thoughts for day 2:

Startup Weekend DC - Day 1

Choosing An Idea

Defining the Project

Overall thoughts for the first day:

Test-Driven Development with Rails Studio

Rails Rumble

New Beginnings

Quibbling, Grousing, Bellyaching, and Nitpicking
(or Suggestions for Next Year’s RubyConf)

Praises, Accolades, Commendations, and Flattery
(or I Really Did Have a Great Time)