Phillip interned with Big Nerd Ranch as a backend developer in 2015 and was hired as a permanent employee after the internship. In this interview, he describes his journey from non-developer to Nerd.
Phillip interned with Big Nerd Ranch as a backend developer in 2015 and was hired as a permanent employee after the internship. In this interview, he describes his journey from non-developer to Nerd.
Function composition is a technique used to build complex functions out of simpler ones. Elixir does not provide a mechanism for composing two functions into a new function. Let’s play with that a little and see what can be done.
I took a week-long hacking vacation (“hackcation”?) to start an iOS app side project. I learned testing in Ruby, which is known for the maturity of its testing tools and practices, and I was interested to see how they applied in the context of Swift. After a week, here are some of my impressions.
Elixir’s IO lists are one of the secrets to blazing response times in the Phoenix framework. Here’s how.
Erlang’s IO Lists enable Elixir to very efficiently write to files and sockets. But do you know how to use them?
Maybe you’re convinced of the value of breaking large chunks of code into smaller pieces, but are you familiar with the different ways it can be done? Each of these decompositions has its own pros and cons, and learning about them will help you choose the best approach for your situation.
Unicode strings are multi-layered things, which makes comparing them, traversing them and transforming them a bit more complicated than with ASCII. Learn how to wrangle them correctly in Elixir.
You may know that Elixir has great Unicode support. But how? Let’s see how Unicode and UTF-8 actually work and how Elixir is able to handle any string you give it.
If only there was a way to have Rails raise an error when an unexpected parameter is encountered out by strong params… Actually, there totally is!
Every complex backend server eventually needs three things – emails, workers and searching. At the Ranch, we like to whip out Solr for handling complex searches. Unfortunately, Solr can make testing frustrating – it needs to be running in the background any time we run integration specs, but starting up Solr is slow. Is there a way to lazily load Solr only for the tests that need it?
In the last post on authorizing jsonapi_resources, we began looking into adding authorization rules to
jsonapi_resources web services. We worked on a sample web service for tracking video games, and got to the point where user
josh could only see and edit his own records. Today, we’ll improve our web service by adding permission for
josh to view (but not edit) games belonging to the user he’s following.
The JSON API web service specification is growing in popularity and adoption, and in Rails the
jsonapi_resources gem is a great option for creating conforming web services. The gem handles a lot of the grunt work for you, but it can also make it hard to know how to do common tasks like controlling access to resources based on authorization rules. Let’s take a look at how to implement authorization for your resources. In this first post, we’ll do it directly in the resources itself, and in the second part, we’ll using the popular
Third-party solutions can solve difficult problems when you’re writing code, but relying on remote services makes writing automated tests more complicated. You can use fakes to solve this problem.
We’ve just kicked off a series of short how-to videos. Today, Dee Del Rosario shows you how to use n to manage multiple versions of Node.js.
It’s common to have a style guide to help with code quality, but do you have a style guide for your test code? Test code quality is important because test suites get increasingly hard to maintain over time. Fragile tests discourage you from making app changes. Poorly performing tests don’t get run. And difficult-to-read tests slow you down as you’re maintaining your system.
After spending a little time with Elixir, you might have found out its secret. Elixir embraces metaprogramming. In fact most of Elixir is written in Elixir. Let that sink in.
Browser validation has come a long way, but sometimes you need the server’s help to determine whether is something is valid. This post explores how do this using Ember Data and Rails JSON API.
We recently had our annual app-building competition, Clash of the Coders. It’s a fantastic opportunity for us nerds to experiment with unfamiliar technologies, stretching ourselves and our tools. It’s all about learning, a fundamental value of Big Nerd Ranch. After an intense 72-hour coding marathon, our team (The Artists Formally Known As (╯°□°)╯︵ ɥsɐןɔ, yep) came out with an online, multiplayer game equipped with clients crossing four platforms: iOS, Android, Web… and Arduino!
A while back, I got all fluffy talking about love and coffee and all that other stuff. Programming isn’t all butterflies and rainbows, folks. Eventually it will happen. You’re going to have to deal with time zones.
Don’t manage vendor assets with Rails gems; use Bower and NPM. Here’s a true story of how backend and frontend developers can work together.
I’m excited to announce that for the third year running, Big Nerd Ranch is hosting the Global Day of Code Retreat at our Intergalactic Headquarters in Atlanta, Ga.
When I teach our web services class Ruby on the Server, a question I occasionally get from students is why we spend half of the first day learning about Rack. After all, Rails is the heavyweight of the Ruby ecosystem, and what most people come to learn about.
Why would an experienced iOS developer want to take our Ruby on the Server bootcamp? Nerd Steve Sparks on learning new tricks and why you need a guide.
Ever wonder how Ruby handles Arrays or Hashes? Join our Data Structure Hack Night on Monday, August 25, and re-implement some of the Ruby core!
At Big Nerd Ranch, we love certain things. We love coffee, we love fitness and we really love technology. When Apple announced Swift, I found it really hard to resist cracking open the free books and seeing what it’s all about.
Over the last few years I’ve had the opportunity to work on several Service Oriented Architecture (SOA) applications. I learned that writing integration tests for such applications is difficult, but important. The challenge lies in the fact that most SOA applications use testing approaches that are well suited for monolithic applications, but these approaches are not always suited for testing SOA applications. It is important because without integration tests it is far too easy for subtle bugs to creep into your code base.
When you create an application programming interface (API), you’re establishing a contract with everyone who uses it. This too is true for web service APIs. As soon as someone begins using an API, changes require coordination between all clients in order to prevent breakage, costing precious time and money.
Rails API versioning to the rescue: In order to allow breaking changes to an interface, we can version it so that clients may specify exactly what representation they expect for their requests. Then they are able to decide for themselves when it is time- and cost-effective to upgrade their dependency.
Consistent API design is important. But it is incredibly easy to lose sight of this when you are actually writing the API. Here is the method I used to ensure consistency.
As Rubyists, we give back to the community by helping out. And sometimes, helping out includes taking out the garbage.
Last week, I got to attend a tech conference… without internet access. I was lucky enough to go to dotRB, a unique Ruby conference, and I loved the format, approach and experience.
I recently went to Boulder, Colorado, for the 2013 Rocky Mountain Ruby conference. More than 300 Ruby enthusiasts gathered there to attend workshops, presentations, drink ups and more.
Have you recently used a Twitter, Facebook or Google API? If so, you probably authenticated with OAuth2. Instead of using their own authentication schemes, most new services choose to implement OAuth2, the latest revision of the OAuth protocol. It gives your users a secure way to talk to your service, but more importantly, allows users to safely authorize access to their data from third-party services without giving them their credentials. Let’s build a sample server implementation in Ruby and see how it all works.
Editor’s note: This post first appeared in a slightly different format on Jonathan’s personal blog.
Madison Ruby taught me that conferences are where you go to meet your heroes.
In our previous posts about data integrity in Rails, we covered null constraints, default values and uniqueness constraints. These database constraints help ensure that data exists where it’s supposed to and in a form that makes sense for your domain model.
] At this year’s annual Clash of the Coders, I teamed up with Steve Sparks and Mark D to create Krëndler, a framework that can be added to any iOS application to record and play back a user’s touch events. Steve and Mark took care of the iOS aspect, while I created an API for them to use to store the touch event data they collected.
Ruby and Rails gives us tools to quickly create powerful web applications. With little effort we are able to model our domain objects and build relationships between them. When it all boils down our apps aren’t really interesting without data, and it is supremely important that we ensure our data is safe, consistent and reliable. We can dramatically increase these factors by taking full advantage of the tools at hand. I want to tell you about some of these tools.
In my professional career, I’ve never felt prouder than when I was accepted as a speaker at RubyConf India. I’ve spoken at numerous user groups, helped organize events, and even performed in front of huge crowds, but this was the first time I had been given the opportunity to speak at a conference.
Last weekend, we hosted our second Rails Girls workshop, inviting 50 women to come to our office to learn more about web development through the lens of Ruby on Rails.
Big Nerd Ranch recently sent Brian Gardner and me to the Railsberry Conference in Krakow, Poland. Having been to several Rails conferences already, I expected some technical talks, Agile process talks, and the requisite talk on refactoring.
St. Augustine, Florida, was packed with brilliant minds this past week, and I’m glad to have been a part of it. It’s a bit startling to think about all the information that was delivered and receiving during the two short days we met for Ancient City Ruby (ACR).
It was a pretty big adventure for me to attend PyCon, flying across the country to a conference I’d never attended before so I could meet people I only knew via some mailing lists and Twitter. It was a little nerve-wracking at first, but once I got to California and started mingling with people, the experience became amazing.
There are many options for Ruby on Rails hosting, but Heroku is one that we recommend to clients and use internally for Ruby on Rails applications. Using Heroku? There are steps you can take to get more performance out of your Heroku application.
Occasionally in the life-cycle of an application we find that we need two distinct domain objects to quack alike, even if their underlying structures differ greatly. Moreover, often the second, third and thirty-ninth such objects come long after the initital object entered the application. One approach would be to shove all of the necessary functionality into the original object and add a ”type” flag of some sort. Another would be to use single table inheritance or even multiple table inheritance (here’s a gem) if we’re feeling fancy. Another approach is to decorate the objects identically so they all quack like the round-duck-in-the-square-hole you want them to be.
I have recently been hearing quite a bit about people using Rails engines. I was intrigued about how they are used and how they integrate into a Rails application, and I soon got a chance to satisfy my curiosity by working on a couple projects that used these engines. Here I will talk a little about what Rails engines are used for and how they are integrated into a Rails application.
A while ago, I hit a lull in my skill advancement as a Rails developer. I had long since learned to think of my resources as resources. I did my best to limit my controller actions the basic CRUD methods. I considered the “fat model, skinny controller” mantra to be sacrosanct. But I was still often finding myself going way out of my way to implement otherwise mundane features, for example sending mail after saving an object or adding a routine accept/reject to something.
The December edition of Hack Night was held earlier this week. In our final Hack Night of 2012, we invited not only local developers, but the women we met when hosting Rails Girls ATL.
There were some great talks at RubyConf this year, covering themes like concurrency, monitoring and architecture, among others. But there were also a number of presentations about the future of Ruby, which piece together an interesting dialog.
Last weekend, I had the pleasure of participating in #blackhack, a hackathon held in Atlanta for the black tech community. Hackathons are a great time, and they also bring together developers, designers and startup entrepreneurs from the community.
As we build apps, most workflows end up basing themselves around one interface or user experience that gets priority over others. As more and more services are added, this inevitably creates problems. Building your API early helps prevent multi-platform nightmares and lets developers focus on doing what they do best.
There are (many) other advantages of building your API early.
Ruby ships with an Interactive Ruby Shell (IRB) that every Ruby developer has played around with at some point. It’s a great place to experiment with unfamiliar methods and running bits of code, but if you really want to dig into an object or do hardcore debugging, it can leave a lot to be desired.
The Global Day of Code Retreat is a daylong event where developers from around the world gather in small groups to practice their craft. It’s an intense day of coding where we get to pair program with others, learn new skills and focus 100% on doing it right.
Rails 4.0 has yet to be released, but since it might be here by Christmas, it’s time to start getting ready.
Highgroove requires everyone to attend a conference every year, and begrudgingly I agreed to head to Hawaii for Aloha Ruby. The flight was long but well worth it, the weather was amazing, and the conference was packed with useful information.
Each month, we open our doors for a Hack Night, inviting others to join us as we experiment with and work on various technologies.
About three years ago, I worked at a product company where the central functionality in our app consisted of five or six domain models with excessive callbacks. I often found myself attacking the knotty nastiness for days at a time, trying to track down stubborn bugs.
This past Saturday, I attended the Atlanta Code Retreat at the Highgroove office. I hadn’t been to a code retreat before this one, and I really didn’t know what to expect. What I got a was a challenging but fun day of pairing with five different developers, and writing in four different languages.
When an app requires full-text search developers usually have two major contenders to choose from: Solr and ElasticSearch. Each addresses different use cases, but generally, ElasticSearch performs noticeably better when an app expects frequent reindexing, as is often the case. Gems like Tire make setting up ElasticSearch a breeze, but setting up more advanced indexes and interfacing with ActiveRecord can sometimes be a pain. Read on to see how to make your life easier with ElasticSearch and Tire.
Highgroove really likes Pry. It’s a great tool for digging into your code and seeing what’s going on with tons of great features. However, there are situations where using a standard
binding.pry breakpoint will not block your program and allow you to inspect it. I recently ran into this situation when trying to debug an application that used Foreman to manage it’s processes. Luckily, the pry-remote project turned out to be a great solution.
The latest version of Ruby comes standard now with Comma Separated Value support built right in via the CSV library written by one of our very own alumni, James Edward Gray II. You might know CSV as the extremely portable format file used for everything from Excel Documents, to Numbers Spreadsheets, to lists of emails, to even generic data files. The CSV library is quite generic and useful by itself, but sometimes, you really need the expanded capabilities that only an Excel or Numbers document can support. Read on to find out how to generate Excel and Numbers compatible .xlsx files with Ruby.
Highgroove Studios is proud to be helping Collective Idea bring Finish Weekend to Atlanta this June:
As the web continues to mature, JSON APIs (and XML if you’re into that) have become increasingly important. But if you’ve tried to use Rails to write an API recently, you know there are a handful of competing methods and gems focused on making this better. I’m all for interchangable libraries, but, as Yehuda Katz pointed out in his recent talk at RailsConf, Rails needs a “convention over configuration” approach to solving the JSON serialization problem once and for all. So I was pretty excited when I heard about Jose Valim’s ActiveModel::Serializer.
Highgroove sent me, Jonathan, and Patrick to RailsConf 2012. I’ve been learning a lot by going to some great talks and enjoying talking to my fellow Rails developers. If you see any of us, feel free to say hello!
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.
Database-bound tests are a drag. Inconsistent tests are a pain. Database-bound, inconsistently failing tests are the worst!
Last night at the Highgroove Studios office, we held the March edition of Hack Night, our monthly social coding gathering. We focused on starting, polishing, and/or discussing open source projects ranging from the super useful to the super silly (beer is always provided at our hack nights…)
Last month I had the privilege of attending the very first SpreeConf in New York City. If you aren’t familiar with Spree, it is an awesome Rails e-commerce engine you can use to build a full-featured online store. The conference was held over two days; the first day featured several training sessions. The sessions covered a range of topics including theming, configuring, and testing Spree. The second day was filled not only with talks related to Spree, but to e-commerce and Open Source in general.
At Highgroove, we’re always looking for new Ruby gems to help speed up development and keep the code DRY. The gem I found this time was Heroku’s very own Databasedotcom gem, a fantastic Salesforce.com API wrapper for Ruby! I must admit, I wasn’t very surprised to find a gem since Salesforce owns Heroku, but I did not expect it to be so fantastic and easy to use. Here’s how!
Waaaayyy back in December, I had the pleasure of attending a code retreat. In that post, I discussed what I learned.
One of my least favorite chores as a developer is dealing with email. I’m not talking about my inbox. That is a post for another day ;). I’m talking about emails sent by web applications. Whether it is a sign up confirmation email, a receipt from a purchase, or reminder for your dog’s birthday. Chances are, if you have a web application, it sends email.
It’s easy to say “We’re agile” and “We use Behavior/Test Driven Development” and thus “we use the right tools to empower our developers!” but what are those tools? For me that discussion is entirely about the tool stack you choose, how that stack empowers you as a developer to do things right the first time. Luckily thanks to the ruby community as a whole we have a large number of high-quality choice to choose between.
Highgroove hosted our monthly Hack Night, and with 20 attendees, this was our largest yet.
In Ruby, blocks are kind of a big deal. We use them for everything from basic iteration to executing callbacks. They are also really handy for writing Domain Specific Languages, or DSLs for short. For example, checkout how blather uses blocks to respond to an XMPP message.
When I went to Europe for the first time, first to England and then to France, I was deeply obsessed with track cycling. Since I was (kind of) writing my Masters Thesis while my wife was (actually) doing serious research for hers, I had plenty of spare time to hunt down every concrete or wood-banked oval in all of France. My process started out by simply looking for the famous ones like Roubaix and Vélodrome d’Hiver. I quickly realized that every town in France has a great website and they nearly always listed the address of their velodrome if they had one! With that in hand, I would then search for it in Google Earth and put a push-pin there. This was a strange and silly obsession but it taught me a few things. It taught me to read a bit of French, to provide correct accents to Google France’s search site, and to do my best to search like I was actually a French speaker. I’m not sure if I succeeded, but this is the exact opposite of what we want our users to have to do with any of the sites we create. Luckily Ruby on Rails provides extensive support for Internationalization (i18n for short) via mechanisms such as Translation and Localization. The prior simply creates mappings between variables (and parameters) and some copy in the language to be displayed. The latter does things like format numbers, times and dates, and currencies correctly according to the language to which we are localizing. This alone should make us ecstatic but we can leverage the tools provided in even more exciting ways.
In case you missed it, the awesome Globay Day of Coderetreat occurred on December 3rd. The amount of fun I experienced was unexpected and impressive! I learned some things too. Read on to find out what.
One of the more complicated Ruby/Rails projects we work with at Highgroove has many points where it interacts directly with the filesystem.
At Highgroove Studios, we’re hyperspecialists in Ruby on Rails web application development. Not only do we write amazingly complicated code on time and on budget, but we follow up all our work with tests so we know our code works.
At rubyhoedown, the inimitable Jim Weirich gave an awesome presentation on using the debugger in ruby. Before his new found respect for the ruby debugger, Jim told us that puts statements worked just fine for him.
Active Shipping is a nifty Shipping API extension for Active Merchant. It provides methods for interacting with common shipping carrier APIs. Recently we used Active Shipping on a client’s e-commerce site to provide customers with many shipping options from several carriers.
RubyConf, ahhh RubyConf.
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!
Here at Highgroove we often use the popular Factory Girl gem in our tests.
Before getting the opportunity to work with the Highgroove team I spent considerable time checking out their website. It might have been embarrassing if it didn’t have such a fun vibe to it. The picture on the front page of folks energetically making coffee certainly drew me to the site as much as having a good friend happily working there already. It definitely did not hurt that there was a Velociraptor craftily hidden behind the classic Konami code either. During my interviews I couldn’t help but almost sound fanboy-ish in describing my own coffee-dorkdom and mentioning that I had read the blog and bios often during the preceding weeks. I did so just to get a feel for the team with and for whom I hoped to be working. What I didn’t realize at the time was the breadth and depth of the knowledge base the crew has, and it is stunning!
Ruby on Rails is an open source, free framework for rapidly prototyping and developing robust, scalable web applications. Ruby on Rails is excellent all by itself, but one of the greatest parts of the Ruby on Rails community is the extensive list of code libraries, plugins, and extensions, often shortened to just: Ruby “gems”, hosted on RubyGems. As of writing this, RubyGems reports that it is hosting over 28,000 gems!
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.
If you’ve ever tried to integrate Jabber into your app or just wanted to write a bot to respond with TWSS jokes, you’ve probably checked out XMPP4R or Switchboard. These libraries are great and have a really solid feature set, but if you find yourself writing a lot of boilerplate and really want a library with more of a Ruby feel to it, try out sprsquish’s gem, Blather.
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.
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.
Here at Highgroove, we do code reviews, which ensures everyone is reading some code on a regular basis. However, being a developer usually means you’ll be reading code regularly anyway. In the past, I used to avoid this if I could. However, now I’ve learned how much I can get from it, and use it to improve myself as a developer.
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.
ActiveRecord is wonderful for the easy queries. But there are times, in the name of performance, when one must bust through the ORM facade and dip below into SQL.
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.
Using different ‘environments’ in Ruby on Rails development is an established best practice. Rails provides you with 3 default ones: Production, Development, and Test, and at Highgroove we like to add a ‘Staging’ environment as well. Heroku supports multiple environments, and they make life a lot easier when building applications.
When building fancy AJAXy apps that have complex user flows outside of page navigation, it’s important to let users know if they are about to trash something they just wrote. Ever had a browser lose several paragraphs of text you typed in? Not fun!
He may be too humble* to admit it, but Andy Lindeman, one of our new(er) hires, is awesome.
April 9th and 10th in San Francisco was the first ever CodeConf. Read on for a recap on this incredibly insightful and wonderful conference.
Virtually every application we push to production relies very heavily on open source code in one way or another. This means we’re utilizing the experience, knowledge, and expertise of the OSS (Open Source Software) community to solve many of our problems. Things that would’ve taken us quite a bit of time, money, and effort to iterate on in order to bring the quality to something on par with the OSS options are freely available and open for us to incorporate in our projects.
Bug-free code is hard to come by, but we strive to do the best we can. The most important part of this is automated testing, and code coverage metrics are a commonly used indicator of the quality of tests. However, code coverage is a misleading metric: Having “Good” code coverge in your tests isn’t really an indicator of good testing, but having “Bad” code coverage definitely means that your tests are insufficient.
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.
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.
We’re still recovering from RubyConf (specifically the 10k, Jonathan’s first ever, has yet to release its iron grip on his calves), but we have had some time to reflect on what value we at Highgroove extracted from the conference.
New albums drop on Tuesdays, why not drop some nifty knowledge as well?
At Highgroove, we’re experts at glue. Not that kind of glue, but the kind that connects one technology to another.
“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.
Have you ever had a problem with rude cows in Ruby? If you have unruly class methods that need proper handling, read on.
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.
It’s late Friday afternoon, I’m angry at this problem I’ve been working on for an hour (or more), but I’m stuck. The sun is out and a cool breeze is blowing softly outside and I want to be riding my bicycle through the streets of Atlanta at full speed! Right now, I can think of nothing more than how much I hate this bug. I’m stumped.
I recently completed my first sprint triathlon. The feeling of accomplishment
was overwhleming and I almost cried crossing the finish line. For those not
familiar, a sprint triathlon consists of a 400m swim, a sixteen mile bike ride, and
a three mile run in that order. Numerous volunteers provide water, gatorade,
directions and most importantly, moral support and kind words along the
course. I’m unable to overstate how welcome and vital words of encouragement
are. “You can do it!” “Great job! Keep it up!”.
A friend recently asked us, here at Highgroove:
If you’re keen on the tongue in cheek, check out my amazing blog post about integrating facebook into a rails app.
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.
Jonathan Wallace has joined the Highgroove Team!
Most database-backed applications, especially Ruby applications written in Rails do fine with a SQL Database, like MySQL. Adam Wiggins of Heroku does a great job explaining how SQL Databases are an Overapplied Solution. There are definitely a few cases we’ve seen where a NoSQL solution like Redis can really shine.
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.
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.
I just wanted to post a quick note to anyone searching for problems with Rails Page Caching with Apache.
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.
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.
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?
Update: Apple has since removed the date and time information from the JSON data. This code will no longer work. It was fun while it lasted, no?
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.
James and Dana are back from Mountain West Ruby Conf, and the videos of their talks are up:
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.
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.
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.
MerbCamp is the first official gathering for the Merb community.
We’ve had the pleasure of working with Matt Todd recently on several Highgroove projects.
Andre, Charles, and myself leave for RailsConf Thursday.
A while back, we wrote an article on Running Background Jobs in Ruby on Rails.
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.
One of our current projects at Highgroove sends a lot of email to its users. It essentially walks them through a process and emails them at each step. All of those messages include URL’s to visit the relevant page in the application for that step. Since we’ve emailed them the URL’s we don’t want them to have to login every time they click one.
Andre and I will be at SF Beta tonight demoing PlaceShout, our short-form local reviews service.
I had an unusual Christmas Eve. While my wife was entertaining the family, I was in my office programming until nearly midnight. (Have I mentioned how much I adore my wife?!)
Much of what Rails provides to get your apps up and running isn’t optimized for performance. It’s crafted to be more efficient for developers, not more efficent at runtime. before_filter callbacks on your RESTful controllers to get the current object? That’s an extra database call. All those nifty plugins you are using to kickstart your app? They probably generate far more SQL (and slower SQL) than if you coded the same functionality ad-hoc. ActiveRecord itself is slow compared to raw SQL and object instantiation.
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.
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.
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.
The following quotes were heard during the first two days at the Big Nerd Ranch Ruby on Rails Bootcamp, here in Wiesbaden, Germany. They could have been said during the super-intensive course or during the hands-on building of a fully working sample application. Or maybe during the wine-tasting….
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.
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.
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.
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.
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.
If you’re like me and have been putting off RESTful routing in Rails (in other words - the future), checkout Andre Lewis and his presentation on RESTful routes at Thursday’s Silicon Valley Ruby on Rails Meetup.
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.
I just finshed fixing file uploads in a HighGroove application to work with any size file. I uploaded a 14 byte file to make sure I had things right. This has a few gotchas in Rails, so I thought I would share the recipe for success.
1. Java hearts Ruby
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.
Using a subdomain as an account key is a great way to personalize a web application. Rails has a nifty plugin written just for this, but the implementation information is a bit scattered. Here’s a step-by-step guide for implementing, testing, and simulating this powerful feature.
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.
There are countless links out there that will bury you in suggestions for how to write Rails code, so I’m going to take the road less travelled and give you three non-code tips that I think are really important.
Microsoft has declared victory over J2EE, and is now setting their sites on Ruby on Rails.
Salesforce, the large Customer Relationship Management tool, and Ruby on Rails, the elegant web development framework, seem like an awkward pair. About as awkward as dipping a Wendy’s french fry in a frosty.
About half of the geeks of the world prefer newsgroups for communication and the other half swears by mailing lists. (A tiny percentage prefer web forum or pigeon, but clearly these people suffer from insanity.) The Ruby community has long had both: the comp.lang.ruby newsgroup and the Ruby-Talk mailing list.
Realizing that hitting “talk” on my phone dialed the previous number. Figuring out that the arrow next to my fuel gauge showed which side the car fuel door is on. Tab completion.
A couple of times a month, I’ll have a “wow - that’s so useful and so simple” moment. One of the first times I experienced that with Ruby was with
Metaprogramming is your secret identical twin that likes doing all of the things you don’t. Need to take out the trash? Just tell your twin. Need to program in Java? Send your twin an email.
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.
Heartbeat is a single-web page control panel that lets you run any rake task within your application’s directory, from deployment to tests to migrations. If you can write a rake task, Heartbeat can execute it! Additionally, you can use it to monitor the uptime of your URLs.
Not only were we a Rails Day 2006 Sponsor, but we also competed.
Auto-Complete is a great tool when it provides possible results BEFORE you finish typing. Unfortunately, using Rails’s included AJAX helpers to query the database as you type often results in a large delay before matches are returned.
Another San Francisco Ruby Meetup. Another record-breaking attendance mark (has any Ruby group in the world brought together more than 110 people?).
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.
I’ll be giving a Rails presentation to OK.rb this coming Tuesday (June 13th). Anyone in the OKC area is more than welcome to attend.
We love Ruby on Rails - since 2005, all of our applications have used the web framework. But we don’t enjoy deploying Rails applications.
One of the most important (and least loved) activities in a programmer's life is debugging code. When debugging PHP, there are several strategies, ranging from strategic use of print_r to elaborate systems that send debugging information to specific debug tables in a database.
In this article, we look at a simple tip for finding errors in SQL code when using PEAR::DB.