The Highgroove blog. Sit pit-side with us to learn how we work. Sometimes technical, sometimes business-oriented, but always focused on simple solutions.
You are browsing posts by cbq. Check out all posts on our blog.
It's true. We're hiring. Like a lot of technology companies. But, did you know that we are turning down many qualified applicants? Since we started tracking, only 11% of applicants who go through our hiring process become "Hired Full Time" employees of Highgroove. That means about 1 in 10 who apply receive an offer letter. Why is it we can -- or rather why we have to be so picky in who we hire?
→ Read More
Startup Weekend in Atlanta kicked off last night with over 116 participants, and 48 pitches, eventually forming into 18 teams. The concept behind Startup Weekend is to start something up -- a concept, business, or idea, over the weekend. It's centered around technology, with people dividing themselves into categories like: "business folk", "designers", "developers", and other niches. Yup, there was a technology lawyer, there too.
What kinds of ideas are being worked on right now?
→ Read More
by cbq
The StartupRiot MAKE event kicked off last night at ATDC with the help of Sanjay Parekh and some very awesome sponsors and teams.
We're happy to be a part of this awesome event. At 5 pm on Friday, teams started trickling in and sponsors started setting up displays. The food arrived and many people began networking and planning already.
At 6 pm, Sanjay announced the teams, and each team got up and spoke about what they were building, and what they needed -- be it a designer, some mobile development help, or back-end development.
→ Read More
This week's Tech Talk was on Visualizing Scaling, and Consistent Hashing techniques for scaling data.
Patrick talked through several visualizations he created in HTML5 to visually explain many common scaling techniques.
If you've heard of the techniques and algorithms: "sharding" or "master-slave", or even "consistent hashing" for distributing data across servers, but never really known how they work, this talk goes through the basics and shows visually how data can be scaled out across multiple servers.
→ Read More
by cbq
Dave's Tech Talk this week is on security on web applications, focusing on Ruby on Rails applications, and using the static analysis security scanner called Brakeman (brakeman on github).
In this talk, Dave looks at how static security analyzers work, and how we used it to find some very tiny (already fixed within a few minutes of finding) possible security weak-points in an application we built for a client.
→ Read More
by cbq
Highgroove hosted our monthly Hack Night, and with 20 attendees, this was our largest yet.
To program a computer in a clever, virtuosic, and wizardly manner. Ordinary computer jockeys merely write programs; hacking is the domain of digital poets. Hacking is a subtle and arguably mystical art, equal parts wit and technical ability, that is rarely appreciated by non-hackers. See hacker. -- Urban Dictionary: hack
Hack Nights are a chance for Highgroovers to simply "hack" which means: to experiment, learn, and play with technologies we might not get to during our day-to-day. So, what did we hack on?
→ Read More
by cbq
Will's Tech Talk this week is on Riak. "Riak is an open source, highly scalable, fault-tolerant distributed database." -- Riak Overview on Basho.com.
The main use-case is to use in web applications that have heavy requirements for data, where lots of data must be "written" or "read" in a distributed fashion, but needs to be high-availability.
→ Read More
by cbq
Stafford is talking about productivity hacking with RescueTime. "It's like server analytics for you and your time," says Stafford.
We all like to think of ourselves as productive, but we can all use some help being more efficient. One tool Stafford likes using is RescueTime that tracks where you're spending your time while using your computer.
→ Read More
This week's Tech Talk was on Monday because of the holidays. This is a recurring Tech Talk we've done before, and one of my favorites.
We're all productivity junkies at Highgroove, and this week's talk was chock full of useful advice, tips, and tricks from our Methodologist, Chris.
→ Read More
Dave Worth's Tech Talk today is on merging codebases, using some workflow tricks and the GitFugitive vim plugin ("a Git wrapper so awesome, it should be illegal") by Tim Pope.
We regularly work with other software development teams, and merging codebases and features is routine work for us. Dave shows us his workflow so we can get faster, and more efficient at merging lots of features all at once, together.
→ Read More
This week's Tech Talk was on Sencha Touch, a cross-platform framework aimed at next generation, touch enabled devices.
Brandon went over a small sample Sencha Touch and Ruby on Rails app that we're using as a "spike" on the Beltline for Bikes Project for the Matchstic "On the House" community service project.
It's currently compatible with Apple iOS 3+, Android 2.1+, and BlackBerry 6+ devices. Sencha Touch is the world's first app framework built specifically to leverage HTML5, CSS3, and Javascript for the highest level of power, flexibility, and optimization. We make specific use of HTML5 to deliver components like audio and video, as well as a localStorage proxy for saving data offline.→ Read More
This week's Tech Talk was on the R Project for Statistical Computing within Ruby. The RinRuby project integrates the R interpreter in Ruby, exposing R's statistical routines and graphics (charting, plotting) from within Ruby.
What would you do with R from within Ruby....
→ Read More
by cbq
Today, I attended a workshop from the Atlanta EO chapter led by the charismatic Jim Ryerson of Sales Octane on improving your sales process, through the use of a Sales Playbook. I'll admit, I've always been pretty good at selling (it helps to have an awesome team and product behind you), but the Sales Playbook we have (and that went through a ton of editing today) makes it even easier.
What's in a Sales Playbook? Ours contains things like:
→ Read More
This week's Tech talk at Highgroove HQ is on Power VIM. Or, rather, using the vim editor to be an ultra-productive coder
Mike Skalnik showed off his vim setup, and focused on how he uses it to be more productive. He can edit Ruby and Ruby on Rails projects similar to how TextMate (preferred by other Highgroovers), but with some nifty power tricks up his sleeve like searching, finding recent files, editing multi-lines, having vim auto-correct his code (and find typos and errors)!
→ Read MoreThis week's Tech Talk was on the Heroku Cedar Stack support for Rails applications. Stafford Brooke demoed his most recent application for a client that makes use of all the new capabilities of the stack, including very cool scaling and background processing, making it super easy to scale client applications cost effectively.
Deploying an application the Cedar Stack with Heroku means our clients can spend less time futzing over deployment and questions about "can it scale as we grow" and more time on what their customers want.
→ Read More
by cbq
This week's Tech Talk at Highgroove HQ is on Advanced git (our favorite source control tool). Our own Andy Lindeman is presenting the 2nd part in his series on advanced git workflows.
Andy is covering:
by cbq
We’ve got an amazing team of personable, optimistic, trusting, true-craftsmen developers (and a whip-smart office manager) at Highgroove.
We’d love to keep everyone on the team happy, productive, and with us for a long, long time. However, we realize that even our team of A-players may become ready to move on to different opportunities. We have alumni from Highgroove at some of the coolest companies in the world: Scout, Twitter, Github, and Scoutmob to name a few.
When it’s time for a Highgroover to move on, we have an awesome Exit Interview we give.
At Highgroove, we’ve been consulting on software projects since 2006. I can tell you that it’s been a long, hard learning process on how to sell service based consulting. We’ve certainly come a long way in helping our clients be happy about the services we provide.
by cbq
It’s no secret we’ve been growing. We outgrew our office space about a month ago, and started looking for a new spot.
Our approach to office space has always been iterative. About 2.5 years ago, I went to visit a friend of mine, Mike Landman, who owns a company called Ripple (that we did some work for) at his office. After our meeting, I asked if I could just sit at one of the empty desks to take a phone call and do some work. Highgroove was just me, Derek and Andre, working from our homes (and coffee shops).
by cbq
On a recent project, we’ve been keeping track of the lines of code, and it’s continually going down. You may be thinking — how is the project progressing? With less code, is the application doing less or providing less functionality?
Quite the opposite, actually.
It’s amazing to look back at Highgroove’s Top 10 Moments of 2006 while compiling this list of our top 10 moments of 2010.
While this list isn’t as good as the Top 10 Videos of 2010 or the Top 10 Fails of 2010, we sure had fun this year with our amazing clients.
We’re looking forward to a great 2011 — now where is our jetpack and the flying cars we were promised?
by cbq
At Highgroove, we’re not Designers. We’re back-end Ruby on Rails experts. However, we love working with Designers of all types: UX/UI Experts, Wireframing Experts, PSD to HTML gurus, and other hyper-specialists, as well.
We love crisp, user-friendly interfaces that are simple, and straight to the point. When building a web application, it’s tempting to try to design out all the screens or flows that a user (or visitor) to the web application will see, but it’s practically impossible.
What inevitably happens when doing BDUF (Big Design Up Front), is that we all assume “that designers are able to foresee problem areas without extensive prototyping and at least some investment into implementation.”
For some web applications, “slapping on design at the last moment” can work (especially for internal-only, quick and dirty prototypes), but the best way to design a web application is Iteratively, on-going, while the application comes together (during implementation).
We’ve created a couple of documents and how-tos, internally, here at Highgroove to get smart designers up to speed on how to use version control systems like git (using the GUI interface, versus the command line), and how to design a web application that has ways to handle empty screens, error messages, etc. By getting Designers up to speed quickly and using light-weight tools, it helps us version HTML/graphic changes, and respond iteratively to both client requests (“can we make this smaller?”) and functionality requests (“can we simply add a ‘login as this user button’?”) to web applications.
Besides finding the perfect designer who is also the perfect developer (and also the perfect project manager and communicator and content writer and tester), what do you do to iterate on Design when building web applications?
At Highgroove we do Iterative development. There’s no better way to create software, than incrementally, with planned releases every week (or every 2 weeks). Here are some tips that we’ve learned that make Iterative development work:
What other tips do you use to make Iterations successful?
Last night, I spoke at the Georgia Tech Entrepreneur Society on “Building a Product.”
I have built several products myself, and everyday we are heavily involved in the building of products for our wonderful clients at Highgroove. Before the talk, my mind was spinning with ideas on what to tell these Georgia Tech Entrepreneurs.
I ended up telling a few stories, but there are really two main points I wanted to impart, that I’ve seen make products (at least, web-based, or technology-based products) successful:
This is crucial. There is no way you can make a product without using it day to day. Many of the improvements Derek and Andre make to Scout are gradual adjustments that build on each other, adding up to something big over time (charts are a good example). 1
The clients we’ve seen that use their own product have a much better chance of succeeding, we can attest to this.
Nobody likes to fail. When you get good at failing, it’s actually more like a lesson. In fact, when you get really good at marketing, each tiny lesson is actually “a stepping stone towards success.” We’ve made plenty of mistakes building products, but the worst is continuing down a path that just isn’t right, or won’t amount to any value.
We’ve given up plenty of times, and blogged about it. It’s important, when you give up, to assess why — we like doing that through blogging and sharing about our failures (and successes). 2
Thanks to the Georgia Tech Entrepreneur Society for hosting me. If you’re a Georgia Tech student interested in business, startups, and tech, they have weekly meetings and speakers.
1 Our failed experiment: great on the rack, bad in the mirror on the Scout Blog
2 We Just Undid Three Months of Dev work. Here’s What We Learned on the Scout Blog
by cbq
InfoEther has finally released their Ruby and Rails Ecosystem White Paper to the public. It’s a thorough look at the Ruby and Rails community, the individuals, vendors, services, and shops that all comprise this wonderful ecosystem.
We’re happy to report that Highgroove Studios is one of the vendors identified that contributes back to the community in the form of our work on Ruby, Ruby on Rails, Training, Speaking, and the various plugins and libraries we maintain. Also, Scout makes a cameo (it should be on the tools page, too)!
A friend recently asked us, here at Highgroove:
“I am wanting to get into Ruby and Ruby on Rails development — what tools should I use, so I can start with a leg up?”
It’s a great question, and once we answered, our friend said: “you should put this on-line.” So here goes…
I just got back from Matchstic’s May BrandCamp — a 2-day intensive workshop for companies on branding, and specifically for helping companies define their own brands.
I am so excited about what we learned about Highgroove, and what makes our team so unique and special, when compared to all the other software development shops. It used to be our differentiator was Ruby and Rails, but with so many other companies now realizing the competitive advantage (or at least claiming they know it), we’ve come to realize that our clients love us for many many other reasons. The fact that we’re experts in Ruby and Ruby on Rails is only one of many factors.
I’ll be blogging more about what we’re doing to help solidify our brand — the brand we already knew and had, but now has become so much more clear.
by cbq
One of our client’s web services (an API) experienced some brief downtime recently, related to an error on our part in rolling out some new data.
Things like this happen — they’re inevitable when dealing with even simple APIs and web applications. But, it’s not the downtime itself that is the main problem, it’s the communication of the issue, the solution, and the future prevention that are more important.
A first draft of our e-mail to the client had a sentence like this:
“Our sincerest apologies for this service hiccup, we always strive for the highest quality products and services and feel terribly when something like this occurs.”
This was quickly scrapped, since this sentence:
Instead, we just simply outlined 3 main points:
Much better, don’t you think?
Jonathan Wallace has joined the Highgroove Team!
Jonathan joins us as a Ruby and Rails Developer, out of our Atlanta office. Jonathan blogs over at Two Minute Spates on Ruby, Rails, iPhone, git, and entrepreneurship.
His previous role had him telecommuting, so joining our Results Only Work Environment (ROWE) will be easy for him!
Now, if only we could find time to pull him away from all that awesome client work to fill out his bio for the Highgroove Team page….
The NYTimes.com had a fantastic article this weekend on The Rise of the Fleet-Footed Start-Up. Here at Highgroove, we have been preaching about being lean, building products agilely, and doing more with less for quite some time. It’s great to see a piece in the NYTimes.com Business section advocating this now-proven successful model.
…the lean playbook advises quick development of a “œminimum viable product,” designed with the smallest set of features that will please some group of customers. Then, the start-up should continually experiment by tweaking its offering, seeing how the market responds and changing the product accordingly.
Ready. Set. Iterate!
Most developers think that every “other” developer’s code is “no good.” In fact, it is exactly this “Not Invented Here” syndrome that makes it dangerous for other developers to evaluate an existing project’s quality without a checklist or template as a guide.
Here are a few of the things in Highgroove’s Code Review tool-belt, that we look for:
Even when we come across a project that may not contain many of these quality indicators, it’s not the end of the world. Once we’ve identified the broken windows, we can get to work fixing them.
Photo Credits:
by cbq
One of the best features of Ruby on Rails development is the “Rapid Feedback Loop” that allows developers to quickly make a change and see right away how that new feature, enhancement, (or bug fix) behaves and looks in real-time.
This Rapid Feedback Loop actually becomes even cooler when you loop in the client — the product owner requesting a new feature or enhancement. At Highgroove, we do outsourced development and feature additions for many different projects. We’re always looking for ways to enhance that feedback loop with our clients. Here are few tools for quickly enabling an even more rapid feedback loop, that we can’t live without….
by cbq
On the rails-business list, someone asked recently about Iteration Based Contracts.
“Iterations” in the software development world are a simple, yet powerful concept for developers and businesses. An Iteration is a pre-defined timeframe, usually 1 or 2 weeks, a pre-defined cost, and a general overview of the functionality and goals of an iteration (see also: Iterative and Incremental Development).
Some examples of Iterative development might have one goal:
Or may include a package of goals, usually building on a previous iteration:
Most businesses looking for development really don’t care about the hourly rates when it really boils down to work (i.e., $20/hr for 5 hours of development for one developer or team == $100/hr for 1 hour of development for another developer or team). They really just want their product or service to work, and they would really like to know how much it will cost and how long it will take.
There is an old adage (backed up by some empirical evidence and real-world proof) that says:
“you can build software 1) on time, 2) on budget, and 3) on scope, but you can only pick two….”
This is not to say that no developer team could never do all three, but it’s actually a lot more manageable (and fun) for businesses and developers to fix “time” and “budget”, and alter the scope in Iteration based development.
You might be thinking that we’re still back in Square 1 — i.e. aren’t those pesky developers just packaging up a set of hours and time — how will I know what will get developed in that time and for that cost? But, something very cool happens when you really embrace those constraints.
With an iteration, both parties are agreeing to a fixed amount of money and time, and the developers (and product owners) will develop as much functionality and business value within the Iteration. If development on an Iteration begins, and then the business owners suddenly have a fantastic new idea (which usually happens right after the first demo, once they have working software in their hands), they can simply ask the developers to make it happen. Similarly, if the developers think of a great way to simplify a process, leverage an existing plugin or library, or add (or remove) an additional feature, they can propose it without recourse. Both parties know how it affects the Iteration, and thus, the bottom line. There is no concept of the “change-order” and the rapid-feedback-loop created from iterating makes sure that what is being developed by the developers is exactly what the business owners want.
At Highgroove, we have a Master Services Agreement for Iteration Based Contracts, and without posting all the nitty gritty details, the meat of it revolves around the compensation and deliverables:
Compensation. Highgroove shall be compensated for Services at the rate of: Development per Iteration (Ruby/Rails/JavaScript/HTML/CSS): $xxxDeliverables are always outlined as attachments to the agreement, and are usually story-based (see BDD).
Iteration Based Contracts require quite a few more mechanisms to ensure that developers are not just packaging up X number of hours — there has to be agreed upon functionality and time-frames surrounding those deliverables within the Iteration(s).
We’ve found that our best clients are really seeking a proven process, and a team that can execute on that process: being transparent and delivering real business value at every step. Iteration Based Contracts are a great way to structure this relationship.
Deploying Rails applications has definitely become easier with the use of tools like Capistrano and Phusion Passenger (a.k.a. mod_rails/mod_rack), but really keeping them serviceable, maintainable, and always humming along can require a bit of work.
Andre over at Scout has written a fantastic guide — a checklist, really for putting a Rails or Sinatra application in production and keeping it up in tip-top shape.
Read the Production Server Sysadmin Essentials or, as Andre likes to call it: “Sysadmin Eye for the Dev Guy”.
by cbq
A new client of ours had a big problem. The site they built was getting too many searches (a very good problem to have). The searches all used Andre’s geokit gem and the geokit-rails plugin to provide local results.
Even with the library’s multi-geocoder support (Google, with failover to Yahoo), the site was hitting the limits imposed by both services every day!
So, we quickly implemented a query caching mechanism that caches geocoding lookups that don’t change very regularly, saving the site from making all those API calls. But, the cool part is, we actually added this functionality to the open-source library itself, and the client’s application now directly benefits.
Several things will now happen, because we contributed back to the open-source library, instead of keeping this “addition” to ourself (and the client):
Truly leveraging open-source technology, when done right, can be a huge win for everyone: the client, vendor, and community.
Alanta’s (3rd?) Startup Weekend is on Nov 13 – Nov 15 at ATDC.
We’re big fans of Startup Weekend for a couple of reasons:
A very big thank you to our friends at The Kauffman Foundation, ATDC (and all the other sponsors) for their support of this Atlanta event.
We published Part 2 of our lessons learned from undoing 3 months worth of development work on Scout, our server monitoring service.
As developers, we love technically beautiful solutions. But sometimes the best features are the ones that get the job done — and prove themselves by providing real business value.
We hope you enjoy us sharing these lessons, if so: up-vote us on Hacker News and be sure to subscribe to the Scout RSS Feed or Follow Us on Twitter.
by cbq
At last month’s Atlanta Ruby User Group (Meetp), I gave a presentation on “Teaching Ruby on Rails.”
I’ve taught Ruby on Rails for the Big Nerd Ranch for almost 4 years now, and given on-site trainings all over the world, from Wells Fargo to the New York Times, to startups and even government agencies. I’ve also done this talk before at the first Acts As Conference (Ruby on Rails local conference in Orlando, Florida), but I have refined it a bit based on more experience teaching Rails at various organizations.
Being an effective teacher, and thus, Teaching Rails (and for that matter, any real technical programming language and framework) boils down to 4 main points:
We’re hoping to get video of the presentation up soon, but if you just want access to the slides with notes, I’ve provided them in the footnotes.
I just wanted to post a quick note to anyone searching for problems with Rails Page Caching with Apache.
We just helped a client through a tricky issue that manifested itself through some strangely generated cached files.
A visit to the resource:
http://example.com/articles
Would correctly generate the page:
/path/to/app/public/articles.html
Subsequent visits would load the cached page.
For a client’s application, we needed to programmatically (without user-intervention) update the Status (Wall) of a Page for a Company. After researching the API and several guides, you would think it was just not possible..
In fact, there’s even a forum post on the Facebook developers forum on How to update facebook page status from 3rd party application
where a Facebook employee explains that it is impossible (as of 2007, at least).
The good news is, it is not impossible (as of right now). Here’s how to update the Status of a Facebook Page Programmatically, through the API.
What you’ll need:
Update: As pointed out in the comments, publishing through Facebook using the method described below does place content on the fan page, however, it is not displayed in any user’s feeds or streams, which makes it not quite so useful. We have since opted to go with the uber-cool ping.FM service and we even wrote a little ping.fm ruby wrapper library for their API.
If you’re thinking about doing this year’s Rails Rumble, Highgroove HQ in Atlanta (map) is offering up our office space for any teams in the Atlanta area for the competition (Aug 22 – Aug 23).
Highgroove has a team, and we know of a few more folks seeking teams. Ping us if you’re interested in joining or forming one. Registration ends soon (this weekend)!
Both James Edward Gray II and Matt Todd were quoted in Satish Talim of Ruby Learning’s Poll: 20+ Rubyists are using Sinatra – Do You?
Sinatra is a Ruby framework for quickly creating web applications with minimal effort — a DSL for the web. We use Sinatra for several client projects, and it is also an integral part of Scout.
Scout got a major facelift today, to show off all the new features we’ve launched over the past few months.
To learn more about many of the new features, including:
head on over to the Scout Blog to read all about it.
Now with deep Rails Instrumentation, triggers, a more robust agent, and more
by cbq
I’ve updated my course material for the class I’m teaching at the Big Nerd Ranch next week. We’re teaching Ruby and Ruby on Rails in a 7-day, intensive course for those new to programming and those who want an in-depth exposure to Ruby before diving into Rails.
I wanted to share this diagram I made for the new Rails 2.3.2 architecture — a mix between Marketing material and Architecture diagram that I’m calling a “Marketecture” diagram:
In addition to talking about Rails’ semi-new focus on RESTful controllers, there’s even a section on Test-Driven Development with Rails with the new TestCase libraries.
Derek and Andre learned a thing or two about sponsoring and presenting Scout at the Golden Gate Ruby Conference this weekend.
Being a product owner ourselves (and developers on many web-based products for lots of companies), we know that the marketing and sales side of a product is half the battle.
Read Lessons from our First Tech Conference and vote +1 in the comments if you think Derek could stunt double for the ShamWow guy.
ProPublica is an independent, non-profit newsroom that produces investigative journalism in the public interest.
Yesterday, NPR’s Marketplace aired a segment featuring their “Eye on the Bailout” — a Ruby on Rails application to track the $1.1 trillion taxpayer-funded bailout. Behind this Rails app is a one smart development and investigative team. The app is fully RESTful (allowing developers to pull and syndicate bailout related data in several formats), and it also pulls in feeds from several different news sources.
Highgroove was all too eager to help, but the real credit goes out to the amazing development team, led by Dan Nguyen and Scott Klein.
Read the segment on Marketplace.
Link: Eye on the Bailout
Geoffery Grosenbach interviewed the Highgroove Team for the latest Ruby on Rails Podcast, released last Friday.
We talked about the technical aspects of the upcoming refresh to our Ruby on Rails Monitoring service, Scout.
Learn more on the Scout Blog or Listen to the Podcast.
by cbq
Re-blogging the news from Scout — we’re sponsoring the Golden Gate Ruby Conference and demoing some very tasty updates to Scout.
Stop by and say hi to Derek and Andre in the booth. I don’t know which one of them will be the booth-babe, yet.
James and Dana are back from Mountain West Ruby Conf, and the videos of their talks are up:
http://mwrc2009.confreaks.com/
James said of the conference:
“The talks were very high caliber, the venue great, and the hosts generous. This conference also proves that not only does a single-track conference still work, it’s just plain better.”
Here are 4 reasons for prototyping applications first. By prototyping, I mean an emphasis on building working applications rapidly:
1. It is much easier to edit an existing application that to try to dream one up with nothing visual and interactive to work with.
2. Too much planning leads to over-complication. Sometimes you can be too smart for you own good. “What if the user wants to do X or Y.” Don’t guess, find out.
3. A working application that can be tweaked beats a theoretical application that is perfect (and either sucks when it’s “done” or never sees the light of day)
4. A Prototype forces you to focus on the core functionality, that makes or breaks your idea. Trust us, the logo is not your killer feature.
Credit is due to our good friend Mike Landman of Ripple for Reasons #1 and #3.
by cbq
Highgroove is attending Startup Riot 2009 tomorrow. We’re excited to be attendees this year (last year we were presenters on Scout).
If you’re attending, be sure to say “hi!” to Matt and I!
I’ve been in the New York Times newsroom at 5 pm on a Friday, when a reporter dropped in with brand new test score results from across the New York public school system — suddenly, it was like a machine springing to action. There were graphic designers loading SQL dumps of data, collaborating with developers and reporters, all working with the numbers to culminate and disseminate the information, and create factual reporting. It was truly amazing – even better than the afternoon I spent in the pits at a NASCAR race.
I bring this up not simply because of this fantastic article on nytimes.com about these Renegade Cybergeeks at the Times, but because I have seen what kind of great things happen when you put smart, motivated people together, towards great causes.
Last week, we got the chance to work with these developer/journalists (or perhaps journalist/developers) once again — and I couldn’t help but be simply thrilled to help, in a small way, by providing hands-on consulting and training to their Interactive and Computer Aided Reporting Teams.
We’re delighted to associate with these geeks.
We’ve made a few slight changes to the Highgroove Studios site. Here’s the lowdown:
An emphasis on experience. We’ve been building Ruby on Rails applications since the framework existed. Along the way, we’ve published books, and contributed to a few, too. In short, we’re extremely proud of our time with Rails and want the world to know about it.
Updates to the Highgroove Team. We have some real experts on our team. From Ruby core developers, to former Big-5 Consultants — we’ve been around the block and we’re very proud of our accomplishments. Be sure to check out the updates bios and the new members.
A showcase of our work. We have been involved in a lot of successful projects. We’ve been in the trenches at lots of companies, working with lots of smart people, and it shows.
In true Highgroove fashion, we’ve launched it already, so we can tweak it as we go.
Many critics are hailing Little Big Planet as the video game of the year. Its “flexible, fun, and powerful” level creator and sharing system has created an interactive platform never before seen in gaming.
But you don’t need to tell our James Edward Gray II about it – in March, at the MountainWest Ruby Conference" in Salt Lake City, he’ll be giving a featured speech on how Ruby programmers can learn from Little Big Planet’s creative problem solving and code reading. He’ll also be discussing some of the most creative Ruby projects out there, showing how their developers build servers, optimize code, and more.
A Playstation 3 and advanced knowledge of Super Mario Brothers Level 1-1 is optional but encouraged for attendees of this talk.
Come see Matt talk about the Rack project, a minimal interface between webservers supporting Ruby and Ruby frameworks that’s behind the new Rails Metal functionality.
He’ll be going over Rack, and showing an example of a quick and dirty framework. He may even show how we use Rack handler’s to help handle Scout’s load.
Other topics include:
Check out the Atlanta Ruby Meetup Group and the January Meeting Event Details for more information.
by cbq
MerbCamp is the first official gathering for the Merb community.
Our own Matt Todd is speaking on “Going Beyond Web Sites with Merb” — where he’ll talk about using Merb to do things other than just your run-of-the-mill web-sites — things like APIs, Web Services, lightweight protocols, and making your grass greener. Well, maybe not that last one.
You can Register at:
We’ve had the pleasure of working with Matt Todd recently on several Highgroove projects.
Matt’s going to be speaking at RubyFringe, “an avant-garde conference for developers that are excited about emerging Ruby projects and technologies” on July 18-20, 2008 in Toronto, Canada.
And while there is a very clever joke I could insinuate about Matt’s talk entitled Being Dumb And Using It To Your Advantage, on Matt being “the expert on dumb,” I can’t quite come up with it — and then there’s the fact that he is actually really frickin’ smart.
If you’ve ever thought of an idea, only to convince yourself “eh, that’ll never work, that’s a dumb idea” — his talk will make you think otherwise.
A while back, we wrote an article on Running Background Jobs in Ruby on Rails.
The Ruby on Rails framework has a number of tools for running your code outside of the web-request, including the venerable script/runner for one-off tasks, but using them can be a little heavy on your server. If you want to run a task on the minute, or on demand, script/runner will load your entire Rails environment, which can be from 20-50 MB, depending on how many libraries and how much code you’re pulling in.
There are also a few other good guides, recipes, and libraries that we’ve mentioned before, including:
We’ve found that it’s not terribly hard to build your own job server that runs continuously in the background and can handle all kinds of jobs, including those that should run on a specified interval. Here’s how we did it.
Come see us talk about Scout Server Monitoring and Reporting at StartupRiot on May 19, 2008, and watch all the other startups present their wares. This looks to be a really great event.
See ya there!
The success of our Scout monitoring tool’s Beta has been amazing. We appreciate all the feedback we’ve received so far.
We’ve decided to spin-off a separate product based on Scout. It’s called Skraut. Just as Scout can monitor a server to know when it’s in trouble, Skraut can monitor your significant other, to know when you’re in trouble.
We hope you like it. Remember to signup for the Beta program, launching soon!
If you’re just getting started with testing (and general test-first or test-driven development) in your Ruby and Ruby on Rails applications, you have a couple of choices.
You can go with Ruby’s Unit::Test, built right in to Ruby, and built-in to Rails with unit, functional, and integration test suites setup for you.
Or, you could setup Rspec with Mocha, and implement a form of testing called Behavior Driven Development or BDD.
Both approaches serve the same goal: better, tested code, easier code to maintain, and in general, just better practices.
My advice is to start with unit tests, and then move to Rspec later.
Last night, I demoed Scout to a room-full of Rubyists at the Atlanta Ruby User Group Meeting.
I would love to share all the wonderful feedback, but instead, I’ll share some of the excellent questions (and more elaborate answers) that were asked of Scout:
What are the security pitfalls, i.e. can someone simply write a ‘rm -rf’ plugin?
To answer that, let’s look at the architecture of Scout first:
The security measures needed for Scout are the same as for any other software. In fact, in some ways, it’s easier to be more secure – the plugins are relatively few lines of code and easy to review. For a more closed environent, you can create a copy of the plugin code and host it on one of your own servers (a plugin is plain text).
Is Scout open source?
The Scout client is completely open source. The gem is a normal Ruby gem, open for development, and distributed under the MIT and/or Ruby License (whichever you prefer). The Scout Plugins people write are also completely open, in fact, they are surrounded and fostered by a community that encourages branching, fixes, and general open-ness.
The Server, where you aggregate your data, do reporting, and in general, collect information about your account is not open-source. We maintain the server, and keep all your data safe and sound.
When does it launch?
We’re doing the plumbing now – account subscriptions, a new home page, privacy policies, backup procedures, etc. We’ve recognized that lots of people are anxious to get going and we’re working to get it ready for public use as fast as possible.
For those who missed my talk at the most excellent Acts As Conference put on by the good folks at Rails For All in Orlando, Florida — here’s the cheat sheet.
My talk was on the lessons learned from teaching the Ruby on Rails Bootcamp and various on-site Trainings over the past year and a half. Here are the 4 key things you need to do to be a successful trainer:
Define Your Purpose – Come up with a clear, specific, desired outcome. Are you attempting to teach the basics, or promote mastery? A quick how-to, or a detailed guide to a particular way of development? A clear purpose helps your audience hit the ground running. An unorganized braindump can leave your students frustrated when they go at it alone.
Know Your Audience – You’ve got to understand everything you can about your audience. This means not only their current level of knowledge, but their past experiences, and even their goals. Ask questions before and during your training to understand everything you can about them. This will help immensely with the next tip.
Give Relevant Examples – Cater your examples to the domain that your audience knows. If you are teaching a bunch of journalists, use concepts from the publishing world. Never use foo, bar, or any other made up word in any example. If you don’t know, guess, and if your audience corrects you on the concept, you now have attentive listeners, contributing to your solution!
Teach How to Learn – Show, don’t tell. Stress how to find out why something works the way it does. Give plenty of examples, and help your audience figure out concepts. Give them the resources to continue learning and to find out more. Show them how you figured it out, or where you went to learn.
I’m sure there are plenty more tips, but I’ve found these 4 to be extremely valuable to me in coming up with valuable lessons and ways of teaching. Thanks to everyone who came up to me afterward to ask questions and share feedback about teaching!
Recently I’ve been reading Obie Fernandez’s book, The Rails Way.
I made an appearance in one of the chapters, but the real credit goes to Obie for pulling together an exhaustive 850-page book.
It’s not for beginners, but if you’ve taken one of my Rails training classes, it’s a great reference book and next step.
Reviews of the Rails Way:
by cbq
When training, I hate using ‘foo’ and ‘bar’ in examples. It means I’m ignoring a major portion of my responsibility — relating the Rails concepts I’m teaching to the problem my students are trying to solve.
For example, let’s say you are training students that are building an application for managing project teams. When teaching RESTful webservices, try explaining how a resourcefully-built web application could provide a free API for retrieving information about the project team members. The team members could be displayed on a totally separate web application by simply exposing these teams of people as bona fide resources.
The example might not be completely relevant – they might not need to connect to other web applications. It might shine light on another problem they need to solve – can we do the same for sharing the project schedules?
In the end, it makes my students more productive. They focus on solving their biggest problems and not just learning all of the Rails concepts.
Just a quick note that I’ll be speaking on "Lessons from the Trenches “ Learning from the Rails Bootcamp at the regional Ruby on Rails Conference dubbed acts_as_conference (a play on the Rails way of introducing behavior through code) in Orlando, Florida, on Feb 8-9.
If you’re interested in how to effectively teach your friends, colleagues, bosses, and maybe even your mom about Ruby on Rails, registration is now open to the public. Looks to be a great conference line-up, with keynoters Obie Fernandez and Dan Benjamin, and plenty of great talks.
by 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:
Check out our new site, and let us know what you think at hello@highgroove.com.
by cbq
It’s not often that we here at Highgroove Studios make mistakes (joke), but the Slingshot Hosting Application was broken for a few hours recently.
I added several new plans (based on our customer feedback), wrote tests to ensure that they worked, and then checked the code back into our repository so I could deploy:
cap deploy
All was great until one of our customers notified me of an error when trying to order one of these new plans! What I should have run was:
cap deploy_with_migrations
Easy to fix, and even easier to push out changes! Problem solved.
Not using Capistrano yet? Sign up with Slingshot and get a customized capistrano deployment recipe file and our very own slingshot.rb library that makes setting up your application a breeze.
OK, so it’s not as entertaining as the Top 10 YouTube Videos of 2006 or as heart-wretching as the Top Ten Breakups of 2006, but Highgroove Studios had a lot of great moments this past year.
For those of you who speak Ruby-on-Rails, here is how we came up with this list:
HighgrooveTopTen.find(:all, :order => 'RANDOM()')
10. We helped Blurb.com launch a NY Times-featured web application in time for the Christmas Season.
9. James Edward Gray II’s 2nd book, TextMate: Power Editing for the Mac got published (as well as several recipes in the must-have Ruby Cookbook ). He was, however, turned down for his next book entitled: “Ruby Ninja Tricks: 17 Deadly Ways to Kill a Man Using Only Ruby.”
8. Derek Haynes, who led the development of the Magma Design Automation customer service portal, proved Murphy’s Law, when his salesforce.com login expired 45 seconds into his one-minute Rails presentation at the salesforce.com conference. At least, that’s the story he claims.
7. We all attended RubyConf 2006 in Denver, Colorado, but forgot to bring our clever “Highgroove-Powered” t-shirts, and a few other important things like toothpaste. Ahem, CBQ.
6. Our #highgroove IRC Ruby bot became self-aware, stopped reporting all our Basecamp messages, code pastes, and check-ins, and became deeply interested in collectible Bratz doll figurines.
5. Confirming what we’ve known for years, CBQ was officially declared a Big Nerd. No, really, he’s teaching the Ruby on Rails BootCamp at Big Nerd Ranch in Atlanta, Georgia and up and coming in Frankfurt, Germany.
4. We sponsored the Rails Day 2006 contest, competed, and won “Most Useful Web Application,” for our entry Heartbeat.
If you’re not using it to monitor and maintain your production Rails applications, well, you should be!
3. Slingshot Hosting, our Business-Class Rails Hosting company, released several deployment guides, deployment tools, added better Partner-managed support, and shall henceforth be known as Slingshot “So-Incredibly-Easy-To-Launch-A-Rails-App-You-Have-No-Excuses-Now” Hosting.
2. We learned Hebrew, Japanese, Spanish, German, Finnish, Norwegian, and Danish. Well, not really, but we built an AJAX-powered application with a translated interface to all these languages.
1. We decided to change our slogan, from “Keeping it Simple.” to “Keeping it Simple” (see, without the period, now it’s perfect).
Here’s to 2007!
A Presentation on with Screech Powers, Cesar Milan (The Dog Whisper), Sean Penn, and guest Ruby celebrity (and Atlanta native) Obie Fernandez. Despite the antics, Capistrano is a powerful, yet simple, bona-fide, big-boy tool. It sure does make our life easier. We like it so much, we’ve made it our goal with Slingshot Hosting to get your Ruby on Rails application up and running with our customized Capistrano Recipes, so you can focus on development.
by cbq
It’s tough finding a developer who doesn’t like Ruby on Rails. However, it’s also easy finding developers who think “Rails Deployment” is the next release of a horror movie series.
We’ve developed exclusively in Rails over the past 1.5 years, and a major piece missing from our development process was a simple system for deploying, managing, and monitoring our client applications.
Enter Heartbeat and one-click Capistrano deployment. With Heartbeat, you can run any of your applications’ Capistrano recipes and Rake tasks on a remote system from a single web page.
Watch Heartbeat deploy a Rails application [MOV | 6.9 MB]
Born on RailsDay 2006, Heartbeat is helping us overcome the most difficult part of the Rails life cycle. In a couple of weeks, we hope it will do the same for you.
Highgroove Studios, along with the Atlanta Ruby User Group, the Birmingham Ruby User Group, and several other organizations, is happy to announce that planning and organizing for the Southeast Ruby Conference is underway.
Our first official planning meeting will be held at the September Atlanta Ruby User Group meeting, on September 5, 2006.
With the excitement and pledging of support so far, this is shaping up to be a standout conference.
If you are interested in planning, sponsoring, or just pledging support, contact me (Charles Brian Quinn).
UPDATE: rails_cron is no longer available, and daemon_generator has moved. BackgrounDRB has gone through a major rewrite, and I’ve got a chapter on Background Processing in The Rails Way by Obie Fernandez. Thanks to Chris Johnson and Douglas F Shearer for the updated information.
Without a way to run long-running tasks, Heartbeat, our 2006 Rails Day Entry, wouldn’t have had a pulse.
Like Heartbeat, most web applications need to run regulary scheduled or long-running tasks at some point in their life-cycle. These tasks are often not inititated by a web request. How can you check the validity of a URL every 15 minutes? How do we get an eCommerce store to calculate the most popular items every 5 hours? How can we re-index our site for searching every day?
If you’ve ever had to do this, chances are you’ve used cron (the *nix tool used to schedule remote tasks) coupled with script/runner. However, wouldn’t it be great if you could maintain your tasks and background “jobs” inside the ruby language, or even better, as part of your Rails application?
Let’s explore two ways to do this: the excellent BackgrounDRb plugin by Ezra Zygmuntowicz, which was used to power Heartbeat, and the fabulous rails_cron by Kyle Maxwell.
Not only were we a Rails Day 2006 Sponsor, but we also competed.
Our entry is called Heartbeat. It’s a simple, elegant, web-based tool for monitoring and maintaining Rails-based applications. From the Heartbeat home page:
Monitor the uptime of URLs and run your application’s rake tasks. Manage your Rails applications from a web interface! Heartbeat can be extended however you want – if you can write a rake task, Heartbeat can execute it!
Here are some screenshots from the application we completed in 24 hours:
We’re not done with Heartbeat just yet. This is only the first 24 hours of development.
by cbq
Just to prove how much we love Rails Day 2006, we’re sponsoring the event. Slingshot Hosting is going to be giving away 6 months of our Dedicated Plan – that’s some serious Rails Business Hosting that a Rails Day Winner could really use.
