Interested in Learning the Elixir language? Join us in this entertaining Elixir tutorial and overview.
Like a pair of jumper cables, ActiveRecord's
eager_load methods are incredibly useful, but also very dangerous when used incorrectly. Knowing when and where to use each approach - and even when to combine them - can save you considerable trouble as your app grows.
I'll explore the when and where of each method below.
I can't recall writing a recursive method in Ruby. I think that's because I find recursion more confusing than iteration (ie
Array#map). Additionally, recursion isn't efficient in an imperative language like Ruby.
While I find recursive functions a bit difficult to grok in any language, writing a recursive function in Elixir is a good exercise for 3 reasons:
- Unlike Ruby, there isn't a performance hit when you use recursion in Elixir.
- Exposure to the inner workings of the
- Exposure to pattern matching in multiple ways.
I'll start with some background on
List and pattern matching, then write a function to sum the contents of a
List. Finally, we'll write a recursive map function.
Most Ruby developers use Git for their version control system of choice. Git is a wonderful tool that can save you countless hours of lost productivity and makes collaborating with others a cinch. Git's distributed nature also allows devs to work anywhere with or without an internet connection without fear of losing work.
With all of the power that Git provides also comes some complexity. Newcomers to Git may find it's syntax somewhat unintuitive and clunky at first. Even Git power users often have to lookup lesser known Git subcommands and options from time to time. Git is similar to a Swiss Army knife in that it contains many useful tools, but can take some time to master or even find a use for them all.
The goal of this post it to describe some lesser known features of Git and how you can leverage these to improve your Git workflow.
Let's get started.
Here's a behind-the-scenes rundown of how we ensure our apps are in peak condition in
*Ed. Note- this is largely unchanged from 2016, so I've updated this post with our 2018 stack.
|Log Monitoring||ELK Stack||$150/mo|
|Server & Service Monitoring|
|Pingdom Server Monitor||$200/mo|
|Scheduled Job Monitoring||Deadman's Snitch||$15/mo|
Stop searching for a single tool
There's no single, do-everything tool that completely monitors a modern-day Rails stack. If there was, it'd be the software equivalent of the Homer Simpson-designed car. There's simply too many specialized things to put into a single monitoring app.
However, there's good news: a number of best-of-breed services play well together to give you great monitoring coverage of your Rails apps and infrastructure.
When picking a monitoring solution, you can typically choose between two options:
- Open Source
The upsides of open source: free to install and more customizable. The downsides: generally more difficult to use and fairly complex to maintain.
Most of the monitoring services we use are SaaS. We typically only use open source options when the paid, hosted option is significantly cost prohibitive. Monitoring software is complicated and keeping your own stack running can be a time-sink. The last thing we want is unreliable software monitoring our apps.
Instrumenting our application with StatsD is easy, especially when we just stick to Counters and Gauges. These metrics return just a single value when implemented. When you get to Timers, however, StatsD steps up it's game and returns eight metrics.
So let's explore the curious case of the timing metric. What do all these metrics mean? How can we use this for instrumenting our application?