Welcome back, dear readers! In part 1 of this post, we did a quick overview of SQL’s window functions and views. Now, we’re going to see how we can use those features from right within Rails.
The more I work with Rails apps, the more I love ActiveRecord. It’s a really elegant abstraction over your data layer, and lets you focus on business logic instead of crafting SQL statements. For the majority of use cases, this works great. But as apps grow in both database size and complexity, we can start to see some compelling reasons to get “closer to the metal” and work more directly with our database.
We’ve been working on a Rails app that uploads images using
We wanted to extend this functionality to enable our friends at Steamclock to build a mobile app that upload images as well.
In order to make collaboration easy, we decided to follow the JSON API specification and to generate the API documentation.
Images on the web are tricky business these days. With the rise of high-density screen resolutions, there’s an increasing need to serve up a multitude of sizes and formats. Manipulation is also key: users want the ability to crop and edit their photos, even perform more advanced manipulations like colour correction and compositing.
For some time now, ImageMagick has been the mainstay for programmatic image manipulation. However, there’s a new neighbour on the block, and they live in the cloud.
Cloudinary is a SaaS product that offers storage and manipulation of images and video. Like Amazon S3 or Rackspace Cloud Files, it provides object storage for media assets. But the real magic of Cloudinary is its ability to dynamically generate and manipulate images on-the-fly.
We’ve been playing with Cloudinary recently on a client project, and I wanted to share a couple of tips on integrating Cloudinary into a standard Rails/CarrierWave workflow, as well as some general Cloudinary tips on image manipulation.
React’s virtual DOM offers some interesting opportunities for simplifying the process of testing, and Airbnb’s Enzyme framework makes testing your components an absolute pleasure. We recently tried out Enzyme on a React project at Brewhouse. We were blown away by how much simpler it was to write tests, and we’re never looking back.
Recently, I have worked on a project where one of the biggest obstacle for me was to understand the app’s business logic due to its callback chains. Whenever I create a model, I get an error because it tried to validate something that was supposed to be created during a callback. At that time, I found myself in what it seemed to be a rabbit hole that does not end. (Ok, I might have been exaggerating because it was probably just about 5 callback chains. MAYBE. I don’t really want to count). It got a bit frustrating and I knew that there had to be a better way.
Brewhouse Software is pleased to announce the newest biker in the gang - Edward Chan.
Edward’s role at Brewhouse will spotlight on all things related to business operations. This includes driving and growing revenue, managing relationships with clients and partners, executing on operational challenges and much more.
We sat down with him to learn a bit about his career path…and how he likes his coffee (our name is Brewhouse for a reason!).
Whenever I come across a rails application with inconsistent data or bugs that are hard to nail down I tell myself: “They (the developers) were just a couple of keystokes away from preventing those issues from happening”.
At Brewhouse, we follow five simple practices to make our Rails applications robust. It all comes down to failing early, loudly and often. We ensure that data is valid and applications behave properly by catching issues early on.