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 andy. Check out all posts on our blog.
by andy
Rails 4.0 has yet to be released, but since it might be here by Christmas, it's time to start getting ready.
Some Rails 4.0 features can be used today, and I describe how in the whirlwind tour I recently put together for the Atlanta Ruby Users Group.
→ Read More
by andy
Staying on top of the new technologies and features in web development can be difficult. The volume of information being generated is vast, and I have found myself becoming discouraged when I can't seem to keep up.
The primary ways I stay on top of the community are Twitter, selected newsletters (e.g., Ruby Weekly), and blogs.
Blogs are great, but they pile up quickly. However, I've found a compromise that works for me: my Blog A-List.
→ Read More
by andy
There is a new drama in the software development community, and it's about whether you should learn to code or not.
I think the best ideas are somewhere in the middle of all the extreme statements and blog post titles that get upvoted on Hacker News.
I think you should learn to "code," but not because it might make you a "coder".
More after the break.
→ Read More
Sunspot, a Ruby interface for Solr
usually backed by ActiveRecord objects, recently introduced native geospatial
searching capability in the master branch (currently a 2.0.0 prerelease).
While the functionality has not been released as a stable version yet, I felt that a blog post introducing the features is appropriate with the hope that folks will try it out and give feedback!
Read on for a short example.
→ Read More
A recent project we worked on at Highgroove involved scheduling events on a calendar. These events had a lifecycle of "statuses," such as "pending approval" and "approved."
All users were able to set the "status" to values such as "pending approval," but only certain privileged users could move them to states such as "approved."
We were already using CanCan for authorization, but there was no built-in facility for authorizing field-level changes. There were workarounds in certain cases, such as using custom actions, but none of these fit with our specific use case.
Read on for how we modeled the problem and used a Plain Old Ruby Object (PORO) to keep things clean.
→ Read More
by andy
At Highgroove, we love giving each other compliments. In fact, since everyone at Highgroove kicks ass in some way, compliments are constantly flying around (actually, I think that in and of itself was a compliment).
Well-deserved compliments foster teamwork, increase morale, and make us better as a team than we could be on our own.
One specific way we compliment one another is by giving the Highgroove Award. The award can be given by anyone to anyone; the recipient is recognized on the website and with a physical trophy (it's a bit over the top on purpose!).
Read on for how we added a technical twist to giving the award.
→ Read More
We help one of our clients operate a high traffic API that, among other things, returns data that is associated with an IP address range. It's similar to querying for information from WHOIS.
The IP address ranges are specified in a MySQL database with ip_start and ip_end columns. The IP addresses are first converted to their representation as 32-bit integers.
For instance, the range 1.1.1.1 to 1.1.3.3 would look like:
| ip_start | ip_end | ... |
|---|---|---|
| 16843009 | 16843523 | ... |
Read on for more about how we helped optimize the queries that search for an IP within these ranges.
→ Read More
by andy
I have only been a professional software developer for a few years, but I feel like I have already acquired bad habits.
One of the hardest for me to break is the desire to create software in a cloistered environment where the requirements are stable and the best technical approach always wins over other constraints like schedule and cost.
Thankfully Highgroove's iterative software development process forces me to flee from these broken methods of building applications.
Read on for more of my thoughts.
→ Read More
by andy
One of the more complicated Ruby/Rails projects we work with at Highgroove has many points where it interacts directly with the filesystem.
Writing tests for an application whose code requires reading from or writing to the filesystem presents challenges, especially if done naively.
While it's tempting to simply use the real filesystem during unit tests, this presents a few problems:
So what's the solution? Fake the filesystem during unit tests.
More after the break.
→ Read More
by andy
Like many software professionals, developers at Highgroove tend to code a lot outside of the work we do for our clients. In fact, Highgroove specifically allots each developer time to work on non-billable projects. Usually this time is used for some combination of sharpening our axes by reading technical material or watching screencasts, and working on open-source software or other internal projects.
Because Highgroove is a results-only work environment, making sure we are meeting or exceeding results is very important. Last night, a few of us hung around at the office and worked on an internal web application to help us track these results, holding us accountable and encouraging us not only achieve them day-to-day, but to do so longer term.
by andy
At Highgroove, we build database-backed web applications. These days, there are many options when choosing a database backend. We normally start with relational database systems (e.g., PostgreSQL and MySQL) because they are very mature and feature niceties like ACID transactions and locks.
On the other hand, we also work with newer NoSQL database systems that often trade features like transactions, locks, and joins for higher performance and scalability. One popular option is a document-based store called MongoDB. By design, MongoDB does not support ACID transactions (though many operations are atomic) or traditional locks.
In many cases MongoDB, paired with an object-relational mapper like mongo_mapper is a great solution for Ruby and Rails applications. And after the break I explore a solution that allows a developer to “lock” a MongoDB document while still maintaining the high performance and other features MongoDB is known for.
At Highgroove, we test our code extensively. The best testing code has solid coverage, yet also shares many of the qualities of well-written code in general, such as readability and lack of repetition.
The popular testing framework RSpec ships with constructs that aid in writing elegant testing code. One advanced technique to keep things DRY is shown after the break.
by andy
At Highgroove, we are pragmatists. While we value writing clean, maintainable, and extensible code, we also value shipping features for our clients in tight iterations.
Sometimes it feels like achieving both of these goals is simply not possible … and yet focusing on either one at the expense of the other is not satisfactory either.
To achieve a balance, we aim to periodically refactor our code: improve or restructure it without affecting its external function.
More after the break.
by andy
Because Highgroove is growing, I am no longer the newest employee, though having been on the job only about two months now, I still feel pretty new.
I came to Highgroove after leaving a developer position at a large company. The decision to leave was not an easy one to make, but I decided I needed a change to fully realize my goals.
When I updated my résumé in preparation for a new job search, I listed several of these goals. I am happy to say even at this early stage, Highgroove is matching up well with them. I explain more after the break.
by andy
If I simply wanted to learn the basics of Cucumber, RGeo, TorqueBox, or any number of other interesting open-source Ruby technologies, I could sit down at my desk and read documentation, check out the source code, or post to a mailing list if I ran across a problem.
But how much more could I benefit if I were able to speak face-to-face to an expert? Or sit at a table of Rubyists from many different backgrounds and spar about the pros and cons of these tools?
Documentation, source code, and mailing lists on their own simply cannot compete with a good technical conference.
I attended Magic Ruby 2011 in Orlando, FL this past weekend. I learned a lot, and additionally learned how much I still need to learn! I have highlighted a few talks that really stood out to me below, but you can check out the full list of talks and slides.
