Audited is a Ruby gem that adds change logging to Rails models. It’s great for figuring out what happened to a model or a group of related models over time.
If you have an application that generates a lot of audit records they can start to slow down your application a bit. Not only do the audit records have to get written to the database, but since they are versioned the save process needs to read the database first to get the current max version number before the new record can be written.
Making these saves asynchronous can improve your Rails app’s response times. Testing with our application showed a 14% speedup with audit-intensive code. That is of course an anecdote, not data.
We had originally forked the Audited gem and modified it to work with multiple asynchronous job processing libraries (we use Resque). After we opened a pull request and some great help from project members, a discussion took place in the PR about whether the code should be merged into...
Chances are that if you’re even remotely interested in web and app development you’ve seen the words “React Native” and “Relay” more than a few times this year, and for good reason: both offer tantalising new approaches to develop apps natively and in browsers.
React Native brings React’s component-based framework and fiendishly frictionless developer experience to iOS and Android. And the newer data-fetching framework Relay, in tandem with GraphQL, offers product developers an entirely new — and arguably more intuitive — way of trafficking data in and out of their apps.
But this post is about something that at the time of writing remains something of a wild frontier: combining React Native and Relay together in a way that makes sense.
I’m not going to cover the nuts and bolts of this process – thanks to the tinkerings of numerous intrepid contributors, it’s not too hard to get React Native and Relay talking to each other. The more interesting part is how we can take React Native’s conceptual approach to view navigation, composed of...
At chloe + isabel, we’ve taken great strides to maintain modular CSS. As our website and the amount of code it required grew, we realized we needed to rethink the way we write our CSS to keep it all manageable. We made our code modular, created a style guide, and have been focusing on finding ways to make our design component-based as opposed to our CSS. With a lot of hard work, we were able to cut the size of our stylesheet in half, and now can build new features at twice the speed.
When your app is small, it seems easy and quick to declare CSS styles based on one-off feature designs. For example, a designer will get a feature request that is unlike anything else that exists on the app, and/or she wants to create a unique experience for that feature. If that feature is unlike any other in the app already, you’ll end up writing a ton of custom CSS to satisfy its...
I’m an inveterate Emacs user. It’s been my Swiss Army chainsaw of choice for over 33 years. Part of the beauty of Emacs is that it’s extensible and configurable. The relatively new1 package manager and ELPA package archive are a great start, but sometimes it’s better — or simply more fun — to roll your own.
I’ve developed a few Emacs Lisp functions that let me run our Rails RSpec tests at varying levels of granularity and within various environments.
Granularity: what to test.
Environment: where to run the test.
Recently we upgraded our stack from Ruby 2.1.0 and Rails 3.2.18 to Ruby 2.2.1 and Rails 4.2.1. We also took this opportunity to upgrade many of the gems we use. Here are some notes about the process.
Our back end is Ruby on Rails and MySQL, running on Heroku instances (some for the app, some for asynchronous workers). We make use of AWS for S3 storage and other work such as Jenkins deployment servers. The code base makes use of over 100 top-level Gems and contains over 2,100 files with over 100,000 lines of code (including comments).
We saw a few major benefits to upgrading both Ruby and Rails:
At chloe + isabel we often have to make client-side components with lots of features. Our merchandiser’s time is limited and life is too short to wait for full page loads. We used to use spine for these components but recently we’ve become big fans of React. The main selling points for us:
Recently we’ve had to make quizzes for our merchandisers to take. I’d like to show you a general purpose solution I made to quickly create these quizzes...