Over the past few months at Salsify we've spent some time exploring Ember.js and incorporating it into parts of our front-end. There's a lot to say on the topic, but today we'll just be taking a look at one of our first forays outside of the land of Ember's baked-in pieces: automatically generating breadcrumbs based on a user's application state.
Most Rails developers quickly learn that minimizing the number of database queries by properly specifying eager loads is critical for good application performance. Unfortunately specifying eager loads is error prone and can cause encapsulation problems. In this post we'll explore having Rails automatically handle eager loads.
I wanted to share a bit of information that we found interesting when writing active record migrations on tables leveraging STI (Single Table Inheritance). We came across a not so obvious gotcha with STI models re-defined in migration classes and wanted to explore our thought process while solving the subsequent problems.
By Joel Turkel on Dec 12, 2013 4:45:00 AM
Previously we blogged about eager loading calculations with database views in Rails to avoid running lots of database queries. The approach we described really only works if your SQL is fairly static and you don't mind creating database views for each of your calculations. In this post we'll explore an alternative approach that avoids these issues by not using database views. First let's quickly recap the problem...
By Joel Turkel on Oct 30, 2013 6:15:00 AM
Update: The plugin discussed in this post has been packaged into the delayed_job_heartbeat_plugin gem.
Previously we've blogged about how to write Delayed Job plugins and how to aggregate jobs into job groups. In this post we'll explore how to proactively detect failed Delayed Job workers so their jobs can be retried in a timely manner. This is useful if a worker crashes, is automatically restarted by your platform provider, or is shutdown by auto-scaling infrastructure.
By Randy Burkes on Sep 12, 2013 5:22:00 AM
Here at Salsify we follow a git flow branching model, so it is common for us each to work independently on feature branches while regularly merging to and from a shared develop branch. We also routinely push code to staging and production environments for internal review and release. The combination of our fast-paced development environment and extensive use of branching occasionally results in conflicts when landing new features. We recently encountered one of these conflicts (sequencing not code) in a pair of ActiveRecord migrations and found a workaround we thought might be useful to others. The following migration excerpts were written on two different branches: