Posts tagged with What We Wrote
You are browsing posts about What We Wrote. Check out all posts on our blog.
For those following along at home, you know that we love to work iteratively,
and as such, work towards our big-picture goals one small step at a time. We
also take software quality seriously, and an important part of software quality,
particularly when it comes to web applictations, is security. We've begun to
develop a new process to address security in our applications. In the process we
also want to contribute back to the community where we can because it will make
the entire web ecosystem that much better. After the break we'll talk about our
high-level process and how we implement it.
→ Read More
At Highgroove we love giving presentations. We sponsor the Atlanta Ruby Users
Group (ATLRUG), we each attend at least one
conference per year where we are highly encouraged to speak rather than
simply attend, and we give weekly tech talks
at the office. Each Highgroover has their own presentation tool-stack ranging
from extremely simple using nothing more than a web browser with various tabs
they manually rotate through, to sophisticated Keynote slide-decks. One can
also use a very editor and CLI-centric collection of tools to build flexible
presentations using many of our everyday tools like git,
guard, slim, and
Github with Github Pages.
If you like using those sorts of tools to speed things along read on after the
jump.
→ Read More
I started watching Gary Bernhardt's Destroy All Software screencasts
recently and after watching a specific episode, I had to have his Ruby
testing setup. After sitting in Vim config for a while, with some
improvements I made, I started feeling like I should somehow contribute my
changes back. After I started adding a few more changes suggested by fellow
Taconaut Steven Harman, I decided it really needed to be a Vim Plugin.
→ Read More
This weekend we Highgroovers (a.k.a. Taconauts) took some time to do one
of the things we really love: create and release Open Source Software. In
fact, we released not one, but three new tools into the world:
grocer, git_tracker, and puppet-osx_defaults.
→ Read More
"With all of the people doing this, why hasn't anyone ever just made a ..."
"I really like doing this, but everytime I get to this point I struggle. I need
to make that better."
"Man... what I really need is something that makes this job less tedious!"
Those sentiments have reared their ugly heads in some way or another with every
crafty endeavour in which we at Highgroove have gotten involved. Sometimes those
crafts are working on bikes (crafty and artisanal as well as mechanical),
brewing beer (crafty, artisinal, and after some patience, tasty if you're
careful), working on rails apps (crafty and often fun!), or pulling shots of
espresso (crafty, tasty, and caffeinated. Sometimes with latte art.) Instead
of simply wishing there was a solution, Highgroove encourages us to solve the
problem, not just for ourselves, but for others.
→ Read More
Cluster analysis methods have been gaining popularity as a way of Relating pieces of data in large datasets with one another. Examples in social networking are obvious: friends on Facebook cluster into cliques and communities, which cluster into even larger groups. Demographics and other marketing research can also be aided by sorting prospective customers into groups based on preference.
→ Read More
Search is a hard problem, thankfully a lot of really smart people have spent a lot of time on it and come up with some awesome tools. Most of our projects involve some kind of search functionality, and often tuning search indexes on the database server will get us enough performance to launch the minimum viable product. But say we have 350,000 things that need fulltext search with ordering and boosting, or 50,000 things with extremely complex access controls in a high traffic environment that needs to search quickly and scale up to 10s of millions of things? Here's a low-level look at some of the specific steps we've taken to make Rails scale. Can rails scale?. We disagree. Onward!
→ Read More
Bayesian networks have proven extremely useful for classifying events and documents, reliability analysis, and in many other fields. Essentially, wherever a well-defined chain of causation given between many pieces of data exists, a Bayes net can help provide probabilities for the "hidden variables" of a system: in the cases above, for example, the category a document belongs to, the probability a system will fail if a certain component fails, etc.
As part of another project here at Highgroove, I've been developing a gem called glymour that learns a Bayes net's structure automatically, which is important when it becomes impractical to manually define causal relationships (e.g. when taking into account dozens of different variables). Working on an open-source gem while relating it to a larger project has made me understand one of its many benefits: open source code is kind of like a constrained writing in which you are constrained to being as general-purpose as possible (and reasonable).
→ Read More
Feature Flags are one of my favorite patterns. Ross at Flickr blogged a pretty good description on the Flickr Code blog in 2009, and a Ruby gem ‘rails-settings’ appeared in 2009 to give Rails developers a “Global Hash” which can be used to implement feature flags. This has been forked by a handful of people, updated to work with Rails 3, adding support for settings associated with models, etc.
However, the official rails-settings gem hasn’t been updated since 2009 and many of the forks are not of an acceptable level of quality for us to use. Some have removed tests, some have lots of backwards compatability code, and most are pretty hard to read. I spoke with some other developers and decided to build a new one from scratch, using rails-settings as the inspiration, so here we are!
→ Read More
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.
→ Read More
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.
→ Read More
Highgroovers. Flexible, self-starting, curious, good, nerdy, professional.
These are a few of the words we used to describe ourselves in our annual
2010 Recap meeting (attendance optional -- we're ROWE
baby!). We are always re-examining our
best practices (a best practice - how meta!) to insure that we're delivering
maximum value to our customers.
"Delivering maximum value." That sounds lame!
→ Read More
“On your mark, get set, GO!” Nothing like the thrill of starting an intense race, whether it be a short hundred-meter dash or a long, grueling marathon.
→ Read More
If you’re keen on the tongue in cheek, check out my amazing blog post about integrating facebook into a rails app.
For the short and sweet version, you can jump to the README on my github fork of facebooker2.
Trying to handle image manipulation, creating PDFs, or in-memory caching in pure Ruby is like trying to win the Tour de France on your hipster single-speed bike. The single-speed works 90% of the time, but when you have demanding performance requirements, it’s not good enough. Many popular Ruby libraries, such as MySQL/PostgreSQL, RMagick, and most of the webservers Ruby applications are deployed on (like Passenger, Mongrel, and Thin), harness the blazing speed of the C language and libraries to handle the heavy lifting and performance-intensive business that Ruby can’t keep up with on its own.
In some of my recent work, I had the opportunity to delve into and expand on a Ruby extension written in C for looking up geographic information based on IPs. This library was vital to one of our client’s projects that has immense performance requirements without the possibility of full request caching. By utilizing the existing GeoIP C library for accessing their special in-memory binary database, we were able to keep up with the demand the application would be seeing.
As is common at Highgroove Studios, along with making sure our contributions to the library were open sourced, I took the lessons and experience gained from this unusual endeavor and presented them to our local Ruby User Group here in Atlanta. I focused more on exposing the bridge between the Ruby and the C environments and understanding the internals of the Ruby language from a C standpoint. However, armed with this knowledge, any Rubyist is able to open up most any Ruby extension or even the Ruby language implementation itself and understand what’s going on. My goal was to get the developers over the initial hurdle of being able to read the code and understand it enough to investigate further.
Personally, I gained from this experience a better appreciation for the real beauty of the Ruby language and the effort required to make it as fluid and dynamic as it is as well as having a more thorough understanding of the internal workings of the language. Working this close to the language core has also made a difference on my Ruby style, both in trying to fight the language less but to also use it more efficiently and effectively.
For more information, check out the presentation slides and some of the C examples I wrote for the presentation. Also check out the GeoIP I contributed to which inspired this whole adventure.
If all you Rails programmers love TextMate as much as I do, you will want to know that my TextMate book is now shipping. Amazon has it in stock already.
If you been a casual TextMate user until now, I promise this is the best excuse you’ve ever had to put an end to that. Allan Odgaard, the creator of TextMate, actually read through the book as I worked fixing my errors and adding a terrific collection of helpful tips. You just can’t beat having that kind of knowledge. That’s why I’ve already been using the book as my personal TextMate reference for months now.
Pick up a copy. You won’t regret it.
Just wanted to make sure Highgroove customers and fans are the first to know, my new book is official:
James’s Book on TextMate
If you’re living under a rock, TextMate is the wildly popular text editor for Mac OS X shown off in most Rails screencasts.
It even won the covetted Apple Design Award for Best Developer Tool just a few weeks back.
I’ve been heavily involved with TextMate development for some time now and am excited about the opportunity to show you how to really get the most out of it. The book will cover beginning to advanced editing techniques, built-in automations and how to create your own, even how to teach TextMate new languages. I promise, there’s something for everyone in here.
Some time ago I read a “10 Best Things You Can Do as a Programmer” list and one of the points on that list was: Learn one text editor very well and use it for everything you can. I believe that’s great advice and TextMate was my pick. I’m now ready to pass that knowledge on to all of you!
You’ll be seeing even more news about this book very soon now. (Weeks, not months!) Stay tuned…
I’ll be fair with you and tell you right out that I am biased in this matter, but I still have to say:
GO BUY THE RUBY COOKBOOK RIGHT NOW!!!
Yes, I wrote six of the bazillion recipies in the book (on DRb and Rinda), but I do not make money when they sell copies, so you can trust what I am saying here.
Basically we are talking about nearly 1,000 pages of EVERYTHING on Ruby. I don’t care who you are or what you do with Ruby these guys wrote something about your problems. How cool is that?
These recipes are just loaded with code, tips, links to related resources, etc. They even manage to be funny in places. (You will laugh at the dinosaur ad.)
Why are you still reading this?! Get up. Go outside. Hail a cab. Get yourself to a bookstore and pick this up! GO!
(If you have back problems you shoudn’t be carrying books this big, trust me. Instead you can grab the PDF version O’Reilly just made available.)
Related Tags:
