Too Long; Didn't Read

Daniel Korenevsky

Late last night I opened up my laptop to catch up on my Chicago shows (PD and Land), and instead found myself chipping away towards the nirvana of inbox zero. In the process, I got to thinking... I realized that when we send emails - for example concerning bugs that a client discovered and we fixed - there might be more depth than necessary. The how and why are important (especially in the early stages of a relationship), but after some time, “These bugs were fixed” could be all they need (or want) to hear.

Our clients don’t just trust us with their technology, they trust us to optimize for their time. It’s an (overly)constrained resource, and it’d be plain rude not to respect it. We have the unique position of being a startup ourselves, and working with startups- we can empathize. I know that my day-to-day is a constant cycle of growth and change - roles and responsibilities evolve, my bandwidth get’s pushed to the brink and I have to make...


Riding Rails with a Composite Primary Key

Lance Ennen

So you've inherited this massive Oracle database full of sophisticated relationships, and started connecting it to your shiny new Ruby on Rails business intelligence application to ride fast on its productivity benefits. However, you got stumped and quite terrified when you noticed that after going through all the effort to convince your team and your boss to go with Rails over [insert legacy programming language framework], almost half the database tables use composite (compound) primary keys consisting of multiple columns each instead of Rails' expected ID column. The chief example is the LineItems table, which relies on both OrderID and ProductID to make up its primary key. Additionally, it includes a quantity column, so you could not hide it behind a has_and_belongs_to_many relationship with the excuse that it conceptually represents a many to many relationship between Orders and Products. Of course, you could add a simple primary key ID column, but then not only...


Big Astronaut at RailsConf 2014

Lance Ennen

Big Astronaut’s own Andy Maleh is presenting at RailsConf 2014! Will you be there?

We’re excited to see RailsConf come back to Chicago this year, and Big Astronaut will be there in full force. We’re always looking for *awesome* engineers to join our development team. Feel free to ask our team questions as you see them walking around with Big Astronaut t-shirts.

We’ll be kicking off Tuesday April 22, 2014 with David Heinemeier Hansson’s Keynote at 9:15am.

After the morning break, come check out Big Astronaut’s VP of Engineering, Andy Maleh’s, talk on "Ultra Light and Maintainable Rails Wizards”.

Ever wonder how to build an Ultra Light Rails Wizard?

Andy’s talk will cover the role of wizards in web applications since the dawn of the World Wide Web, the most notable being the humble Shopping Cart. Despite their prevalence, many developers struggle with writing effective and efficient wizard code, often resulting in an...


Don't serialize just a few! Give me all attributes!

Mark Moschel

To send data to Google Analytics for e-commerce support, we needed to embed Order model data as a JSON object in the DOM. Because we needed to customize this JSON object and keep its logic separate from the Order model, we opted to use ActiveModel Serializers. We considered overriding the as_json method but didn't want to change the default to_json serialization behavior. ActiveModel Serializers allow us to build serializers for multiple use cases and keep them separate from the main Order model logic.

The required JSON object needed to include order data, line item data, and product data. The line item data would include all the attributes of Line Item. However, with the current implementation of ActiveModel::Serializer, we needed to list all the attributes of Line Item as parameters to the attributes class method.

 class LineItemSerializer < ActiveModel::Serializer attributes :attr1, :attr2, :attr3, … # etc. There could be a lot of parameters here

Instead, it seemed...


Ruby SuperModule Comes To The Rescue!!

Lance Ennen

Tired of Ruby's modules not allowing you to mix in class methods easily? Tired of writing complex code and using complex libraries like ActiveSupport::Concern to accomplish that goal?

Well, worry no more! SuperModule comes to the rescue!!

SuperModule allows defining class methods and method invocations the same way a super class does without using def included(base).

This succeeds ActiveSupport::Concern by offering lighter purely idiomatic Ruby syntax and simpler module dependency support.

1. Just include SuperModule at the top of a module definition:

 module UserIdentifiable include SuperModule belongs_to :user validates :user_id, presence: true def self.most_active_user User.find_by_id(select('count(id) as head_count, user_id').group('user_id').order('count(id) desc').first.user_id) end def slug "#{self.class.name}_#{user_id}" end end

2. Mix newly defined module into a class or another super module

 class ClubParticipation <...


You're Hired! You're Fired!

Lance Ennen

What is the #1 thing everyone complains about with regards to using Heroku as a Rails Web Hosting platform?

If you guessed "price" you would not be far off from the truth. In fact, Heroku gives a lot of bang for the buck to get websites started and on the way to mega-stardom, but the inability to scale dynos up and down automatically based on web server load can be such a boon when you know the site is a ghost town at night not worth having 5 dynos fired up at $34/month each.

Enter HireFire: a dyno manager for Heroku, allowing you to autoscale your web and worker dynos, saving on server costs at nighttime and handling greater traffic during the day. It can integrate directly with NewRelic to get response times, request rates, and Apdex as data to use for scaling Heroku dynos automatically.


Very recently, I experimented with HireFire.io on a Staging web server for a Chicago healthy gourmet food site called Factor 75 (highly recommended approach to...


Rocket Fuel Labs is now Big Astronaut

Mike Pollack

Rocket Fuel Labs has officially left the building, in a good way.

When we started our company, we chose a brand that would be both inspirational and exciting to our team and clients. Although it would seem (in hindsight) that a number of other people had similar ideas.

To avoid confusion and allow us to focus on the opportunities ahead, we have re-branded. We’re growing the team (more news on that shortly), continuing to build great products for fantastic clients, and most importantly we’re still focused on crafting awesome software applications.

We're proud to introduce:


So say hello to us on FacebookTwitterEmail, or stop by one of our offices (Austin, Chicago, Denver).

Allow us to reintroduce ourselves:

Big Astronaut was founded in early 2013; we started as an outsourced product development team for clients that were looking to create or radically rethink their existing web applications.

Our earliest clients were...