Posted in Keeping it Simple, Ruby on Rails 
Comments
James
As technologists and especially programmers we are always expected to automate as much of any process as we can. In general, this is a good rule of thumb and I'm a big follower of that philosophy.
However, though it may be hard for us to admit, some problems are better solved with less technology. Let me give two examples I've run across recently.
First, let's talk about filtering spam. I'm sure this raise some eyebrows, but I believe spam filtering is a human's job. My reasoning is very simple: I have not yet seen a perfect spam filter, so it's a given that I will at least need to correct some automated guesses. Because of that, a recent project of mine has no automated filtering built-in. That's right, I'm doing it all by hand and I much prefer it to any other system I've tried.
My complaint here isn't against automated spam filtering. It you like the filters, by all means use them. However, think through your implementation very carefully.
My complaint is that most automated filters are built around the automated filter as the main focus and my corrections correcting it as a secondary concern. Even worse, some implementations don't really account for my need to make corrections at all. I'm glad we make things so easy on the computer, but that means we're inconveniencing me. That can't be right. If I must be involved anyway, I want my role to be as simple as possible.
When I designed my new spam filter, I started with that goal. The specific solution for it may be different for each of us: I want a page I can go straight to, check boxes for all messages, and a single button to classify them all at once; or I want to receive emails as they come in and I will reply to the spam messages to signal the software should eliminate them; or whatever. The point is that this is the right starting point. If you want to mix in some automatic filtering that's fine, but I found that just addressing this correctly in the first place reduced my spam stress enough.
Let's talk about another example. In one of the applications Highgroove is currently working on the "Create" step for a typical set of CRUD actions is a little tricky. You could design a system of forms around it and walk the user through the process, but it wouldn't be a great experience. It's just one of those edge cases where it's really hard for a computer to understand what is needed, but a human will get it in an instance and be able to provide just the right answer. Beyond that, the create operation will be super rare compared to everything else the application does.
How did we address this? With a good old fashioned phone call.
The user can go into the application and put in their create request, which includes their phone number and a good time to call them. With a quick call the human can ask all the right questions and build what they need while they have them on the phone. It's low hassle for all parties involved and gives the application that extra personal touch.
What will we do if the application grows so huge that this process becomes a bottleneck? Well, that's a problem we would just love to have! We bet we would be able to bring on another person to help with the extra load when we reach that point.
Don't let this post talk you out of writing any Rake tasks or other automations you truly need, but the next time you run into one of those problems the computer can't handle too well don't underestimate the power of a low tech answer. Perhaps the computer can help you do it better, instead of trying to do it for you.
Comments
Derek
When getting a shuttle to the airport, I came across this great idea immortalized in clipart.
Posted in Ruby on Rails, Business Comments
Derek
Andre and I recently finished the initial launch of Placeshout’s Facebook application. There are several “getting started” tutorials available on building Facebook applications with Ruby on Rails, but there were quite a few issues we ran into that are beyond a “How To” blog entry.
If you are building your first Facebook application, expect very slow going at the start. I’d take your time estimate and double it. Here’s why:
- It takes some time to grasp Facebook in a multi-developer environment. You need to create separate Facebook applications with different names using different tunneling ports. You’ll also need to create several test accounts. Inevitably, I installed one application when I meant to install another. Getting our version control system setup for our development boxes and production system took some time.
- Understanding how Facebook handles sessions. We ran into several issues – knowing when to require an app install vs. a login, handling an app install redirect inside an iFrame application, etc.
- We ended up using a combination of Rails’ #respond_to and unique Facebook-only actions to handle requests. Many of our pages were quite different in Facebook, and trying to fit format-handling in the existing actions only made things more confusing.
- Testing was a pain. Because we integrated with Placeshout.com, we needed to integrate user accounts. Planning and testing integration steps took quite a bit of time. Facebook and rFacebook have some testing conventions, but that’s like saying that because the speedometer in my Ford Escape goes up to 120 MPH, it can go 120 MPH.
- The rFacebook gem and plugin were our weapons of choice. I don’t have any complaints. We modified several pieces of code to fit our application – including creating a user and installing the application, but that’s not out-of-the-ordinary. The rFacebook team has done a solid job in a short amount of time.
In the end, it felt a lot like traveling to a non-English speaking country – at the start it’s difficult to get basic things accomplished. Once you get in a groove though, you enjoy the scenery and forget that at one time, you didn’t throw up when drinking tap water.
Posted in Business Comments
CBQ
You may have noticed a change of scenery on the Highgroove Studios site, and (for those of you not in feedreaders) this blog.
We’ve taken a good look back at where Highgroove has been, and a bigger look at where we’re going.
Here’s a highlight reel from the new web presence:
- We’ve got Andre Lewis (also known as Rails guru, technology expert, published author, geo-location extraordinaire, Alcatraz-swimmer, nice guy). Andre has joined the Highgroove team as a Partner.
- We’ve got products. Placeshout and Scout (limited client-only) are up and kicking!
- We’ve got vision. We’re still focusing on our sweet spot – solving complex problems with simple solutions. Making web applications easier to use. Making technology easier to understand. Embracing constraints. Leveraging Ruby and the Ruby on Rails framework.
- We’ve got great clients. Fortune 500s, government agencies, educational institutions, DemoGOD winners, Salesforce-award-winners, and very happy companies of all sizes and shapes.
Check out our new site, and let us know what you think at hello@highgroove.com.
Posted in Community, Presentations Comments
James
I’ll be representing Highgroove at the Lone Star Rubyconf this weekend. I’ll give two talks, one for the charity event the night before and another at the main conference.
At the charity event I’m going to go over Ruby’s block syntax. I’ll cover what blocks are, how they are used, and give a lot of great examples. This is a good talk to sit in on if you’re new to Ruby and it’s even for a good cause.
For the conference I’m going to talk about heroes and super powers. I’m sure I’ll manage to sneak a little Ruby in there too, for those that enjoy that. This talk takes an in depth look at glue code and Ruby’s features supporting such. It’ll be fun stuff that doesn’t get talked about enough.
If you are attending the conference, do flag me down and say hello. I’m always interested in meeting fellow Rubyists.
Hope to see you there!
Comments
Derek
There’s a very easy way to ensure that your project won’t be quoted by a quality, not-starving-for-work web development firm: make the firm sign a Non-Disclosure Agreement (NDA) before you provide an overview of the project.
We care about confidentially and security, but we don’t sign an NDA until we hear an overview of the work. There’s too great of a chance that something you want done is currently living in one of our current projects. We don’t want to get involved in a legal gray area.
So now for the real reason.
In my life, I’ve never overhead an original, compelling idea that I could act upon better than the person who thought it up (this doesn’t discount the idea that I’m just not as smart as everyone else…but that’s another blog post).
If Mark Twain gave me an outline of The Adventures of Huckleberry Finn and said “there’s everything – go ahead and write it!”, the book would have been better suited for kindling than English class. I don’t have the skills to put together a great novel (let’s be honest – I don’t have the skills to write a poor novel).
Smart people know this. It’s not the idea – it’s execution, domain knowledge, and leadership.
Posted in HowTo, Ruby on Rails Comments
Derek
Sometimes our Ruby on Rails apps work perfectly with test data, but when they go to production, errors creep in. Debugging errors on a production server is a pain and a bit dangerous.
Here’s what we do to quickly and safely debug issues on our production servers:
1. Add the following capistrano task to create an SQL dump of your data. If it’s a large database, it may be worthwhile to compress the SQL dump as well.
desc "Exports the production db to the home directory of user"
task :db_dump, :roles => [:app, :db] do
run("mysqldump -u #{database_username} --password=#{database_password} #{application}_production > production.sql")
end
2. Create the following rake tasks to grab database dump and import the data locally.
namespace :db do
desc 'Grab a dump of the production database on the server and places it in db/production.sql.'
task :get_production do
`cap db_dump`
`scp DEPLOY_USER@SERVER_NAME.slingshothosting.com:production.sql #{RAILS_ROOT}/db/production.sql`
end
desc 'Imports the database dump of file db/production.sql into development.'
task :import do
`mysql -u root app_name_development < db/production.sql`
end
desc 'Grabs a dump of the production database from the server and imports the data into the local development database.'
task :get_import => [ :get_production, :import ]
end
3. Install the Firefox plugin Server Switcher to make it easy to switch between the production and local server in your web browser.
4. Disable mail in your development box – it’s not a good feeling when you realize you’ve emailed several thousand users while testing out a newsletter script.
config.action_mailer.delivery_method = :test
Posted in Open Source, What We Wrote Comments
James
If you are following the Capistrano preview releases, you may have noticed a new dependency. Capistrano now depends on HighLine, an open source input library by yours truly.
The reason for the switch is that Capistrano needed a reliable way to grab passwords in a cross-platform way. That turns out to be a lot harder than you might guess. On Unix, termios can make short work of such challenges, but that’s an extra C extension install and it doesn’t work on Windows.
HighLine combines the knowledge of several platform gurus to use the right solutions in the right place. Even with all that knowledge as an advantage Capistrano’s maintainer, Jamis Buck, still had concerns. termios can’t be made a HighLine dependency, since we want to stay cross-platform and when defaulting to stty HighLine was a little flaky for the way Capistrano users might need it. Jamis and I discussed these concerns and HighLine was patched with better support for Capistrano’s needs. Jamis later added the dependency and HighLine benefited from another round of expert knowledge.
It still impresses me how much we can accomplish with the super friendly open source model of development. Thanks for the input Jamis!
Posted in Oklahoma, Presentations, Ruby on Rails Comments
James
If you are just getting into Rails or still don’t get what all the fuss is about and you happen to be near Oklahoma, you may walk to catch my talk tomorrow night for Refresh OKC. The meeting starts at 6:30 PM in the Oklahoma City Public Library.
I’ve got a massive talk prepared covering as large a portion of Rails as I can possibly fit in given the time. I do include some cool topics like using the Rails console and even AJAX. I even sneak in a little magic.
Do drop by if you are in the neighborhood…
Comments
Derek
At the Bovine Bakery in Point Reyes Station, CA, there’s a custom shelf on the wall that holds a collection of coffee cups. I thought it was a nice decoration, but then I read the posted notes – people can leave a coffee cup and use it instead of a throw-away paper cup. It’s a win for the Bovine Bakery, the environment, and the Point Reyes community.
Why I love this idea:
- Less paper cups in the trash
- The coffee is $0.25 cheaper when you use your own cup
- I’d be more likely to get my coffee from a cafe where I leave my coffee cup
- It’s a great decoration – the coffee cup is like an online avatar. My favorite is the metal coffee cup in the bottom right.
