I recently come across some surprising code involving exceptions which prompted me to look a bit deeper into exceptions in Ruby. In this post, I would like to share some of what I found.
This is where it all started. I had a script that did something like the following (it was not quite this simple, but it shows the important parts):
Recently, a new client approached us with a performance problem on their existing Ruby on Rails application; they were experiencing massive growth with over 50,000 new users per day signing up, and their app was receiving over 400 requests per second (and growing).
The rapidly increasing load was leading to big problems, with their existing Rails application experiencing frequent outages and causing sleepless nights for their team. They asked reinteractive to investigate and find out how we could get the app stable as fast as possible.
If you are familiar with Rails, you know that it has a predefined directory structure. Rails was one of the early adaptors of the MVC (Model, View, Controller) pattern. In fact that is one of the key strengths of the framework; it is easy to learn since everything has its own place. This is all well and good if your Rails app is relatively a small one - but when your app starts growing with features and functionality, soon you will find some code snippets that don’t seem to fit into the standard Rails directory structure. This is when these methods tend to get pushed to the ActiveRecord models. However, not all of these methods directly relate to a model; often these methods contain some validations required by the business/client.
In such scenarios, implementing the logic via service objects or services would be a good idea. Simply put, a “service object” is a Ruby class that contains some of the application's business logic without pushing it to the ActiveRecord layer. Often, a Service is a PORO (Plain Old Ruby Object).
RUBYGEMS_GEMDEPS is a 'new' environment variable for RubyGems(>=2.2.0). With this line of code in your
You don't need to type
This is a story about a first-hand experience I had recently with a service. I am not naming the service, the goal of this post isn’t to name-and-shame. Instead, I want to highlight an issue that happens on various websites all over the web. I am a user experience designer by trade. I am also a “regular user”, sometimes, though my experience with the web and UX usually makes me a bad usability test participant. Regardless, on with the story.
I am moving house in the near future, so I went online to look for moving companies. I found one that also offers re-usable boxes for free if you book your move with them! Sold. On to the booking process. Since I haven’t moved the current contents of my home before, I have no idea about the size of truck I need. Is the smallest truck big enough? I’ll select it to see what happens. To my relief, a help text appears as soon as I select the option. “Ideal if you are only moving a few large pieces of furniture”... Hmm, that’s not me, I’m moving the whole house. Finally I settle on the “ideal for 1-2 bedroom apartments” option. All good.
In software development, it is easy for developers to sometimes choose tools that are not perfect for the job. This could be because maybe it made sense at that particular time, we were facing a tight deadline, we were not familiar enough with our tools, or a plethora of particular circumstances. It is always beneficial to consider alternatives.
Recently, we have encountered a few situations where using alternatives to our "default" tools improved our project code. The tools that were already in place did the job sufficiently well, but replacing them with simpler ones made more sense in these situations.
Ruby is a great programming language, but like all programming languages it is not suitable for everything. Sometimes it can make sense to use native libraries on the platform or C to improve the performance of slow Ruby code.
This post will explore calling C libraries and functions from Ruby. Although the methods mentioned in this post are not limited to just that, it is a very common use case.
Writing a book is a long process. I can say that now because my first book, Rails 4 in Action, has just been published via Manning Publications. I learnt a lot from the book writing process, and I'd like to share some of those lessons with you.
This was a big one for me. I've been involved in writing Ruby on Rails applications professionally for four years now, and as a hobbyist for a year before that. My co-author, Ryan Bigg (who also worked for reinteractive, back when it was known as RubyX!), has been involved in writing them for a lot longer than that. Writing a book that starts from the basics? Should be easy, right?
We have reached the point where if your business doesn’t exist on mobile you are suffering serious disadvantages regardless of what you are selling or providing. Deciding between what to build is a topic that needs its own blog post. Discussing the native app, hybrid app vs mobile website/responsive website topic is a separate one that I wouldn’t like to get into today. For the purposes of this post I will assume that you have decided on the right solution for you and that happens to be a native app. What can you do to ensure its success?
Context is crucial to the success of any app. With the web it’s easy - people will be using it while sitting at a desk or at least sitting with a laptop somewhere. With mobile, it can be any number of places and situations. If you’re building an app for runners, think of what features they can and should access while running. For example, for a runner it’s very useful to know their heart rate, their speed, track their movements on a map, see how many calories they’ve burned and have the ability to share their progress with their peer group. All of this is great to have in a mobile app, but should you have it all present at once? Or does it make sense to have a big “Start/Stop” button that takes up the whole screen? If you go with the start/stop button, how large should it be? What’s the ideal size to prevent accidental taps while in motion, but at the same time prevent the runner from having to stop to activate it? Or, what about a GPS app for mountain climbers? They probably don't have available hands to fiddle with their device while trying to keep safe. What features are still useful, and how can you ensure that your app is actually usable in the real world?
Last week, I fixed an interesting issue and want to share it with you.
It first came from a bug report when a user found that one of the PDF's logos was missing. Because we use wickedpdf to generate PDFs, naturally, the first thing I did was open the html we serve to wickedpdf in the browser. And guess what, the logo was showing correctly in my browser. That is strange, so I open the html template and check the source code, and what I found was something like this: