The absurdity of Ruby's Hash default value
The Hash default value behavior in Ruby is one that can leave people confused. The hallmark of a good API is that it is obvious what is going to happen in each way you use it. This is one of the few places I can think of where Ruby’s standard library has surprising and confusing behavior. In the case where you use a value object – like a
Numeric– as the default value, everything works as you would easily expect.
However, most objects in Ruby are not value objects. They are mutable, which leads to seemingly strange behavior when you accidentally mutate the memoized default. Combined with Hash extensions, like Hashie, you can accidentally ruin your understanding of Hash and end up in a confusing spot.
A checklist for reviewing Rails database migrations
Software teams often cite code reviews as a primary means for ensuring quality and reducing bugs in their code. However, without high quality reviews, the efficacy of this practice is questionable. In most places that I’ve worked, a change requires only one code review (either through necessity due to team size or through informal norms). When this is the case, the code review becomes a taxing process where, if you’re not on your game, bugs or maintainability issues can start to leak into production. This means that it often falls to the senior engineers to do code reviews. However, relying entirely on the seniors means that they become a bottleneck in the process. When it comes to “dangerous” changes like Rails database migrations, the bottleneck of relying on a small subset of the team can mean that velocity drops. Or, to keep up velocity, you make code reviews less stringent and quality drops.
In try to “scale myself” for my team, I have started to experiment with checklists for performing code reviews. The first one that I wrote up is a checklist for reviewing Rails database migrations. We run on Heroku, which means that zero-downtime migrations are easy to do, as long as you write your migrations correctly. I intend this checklist to help more junior teammates do as thorough of a job in reviewing as I do. Going forward, I want to make more checklists for doing different types of code reviews, to further scale myself for my team.
Grouped pagination in ActiveRecord
Sometimes, designers will mock-up an extremely usable page that they’ve thought about and tested. Once they’re done and they bring it to you to implement, you look at it and think, “how on Earth can I do that efficiently?” One such case happened at work recently.
We were working on a “command center” of sorts where we show our customers a list of upgrades in various states. The design called for what looked like three different lists of records with each table consisting of records in a state. Since a customer can have potentially dozens of these records, we knew we wanted to paginate the page. The wrinkle in setup was that the pagination should consider the full list of records as the dataset, not each list individually. This caused us to wonder how we can efficiently implement grouped pagination in ActiveRecord.
Using the double-splat operator in Ruby
The double-splat operator is one of my favorite additions in Ruby 2.0. For some reason, the two little asterisks together make me happier than an optional
Hashparameter in a method. Even so, outside of method definitions, I didn’t realize there was a use for the double-splat operator until I dug into a bug in Hashie. I liked the result enough that I wanted to take a quick minute and share what I found.
Talking to yourself for self-teaching
Do you ever talk to yourself? How about publicly? We, as a society, often make fun of our friends for talking to themselves. But self-talk can be a powerful technique for self-teaching something. As an exercise, I tried using a tweet storm to share how I was approaching relearning a numerical methods technique. This post is a recounting of why I did it and what I learned. I’ll also share whether I think I will do it again.
Senior developers: Can you recommend your path?
One of the duties I have at work is to mentor some of the Rails developers on our team. I enjoy this immensely, yet struggle with at the same time. In a previous life, I wanted to be a professor and help people learn computer science and programming. I became jaded with academia, so left it and have been working in the software industry ever since. However, I still have that urge to teach, which is why I enjoy mentoring so much. My struggles with mentoring come from my long background in software development. I have been programming in some form since I was nine years old and have been paid for programming since I was eighteen. As such, I have somewhere between 13-22 years of experience across myriad different computer-related backgrounds. I spent the majority of my waking hours from the age of fourteen to the present building my skillset. Can I really ask more junior developers to do the same? How on Earth do I reconcile that when suggesting ways to improve to my colleagues?
Does Phoenix make database CRUD too easy?
In 2014, the Phoenix framework emerged onto the web development scene as a fast, productive, and concurrent solution for the modern web. Its focus was on massive concurrency, thanks to the power of the Elixir language and Erlang’s BEAM virtual machine. The original branding stressed the productive aspect, positioning the framework against the venerable king of productivity, Ruby on Rails. Those who are familiar with Rails will see a lot of inspiration from Rails. The way Phoenix auto-reloads code in development mode makes it just as easy to use as Rails. The router grammar requires a good squint to see the difference between the two. This inspiration certainly makes for a quick learning experience for Rails developers. But I wonder: at what cost? Does Phoenix make it too easy to structure your application like a Rails application? Is this convenience to the detriment of using the full power and expressivity of Elixir?
Finding Rails migrations
Sometimes, I find myself working across several branches helping different teammates with their stories. Often, these branches use Rails migrations to easily manage the database changes that need to be made to support the work. This means that I end up running migrations from many different branches. Because I am human, I often forget to roll those migrations back before switching branches. When a destructive migration has to happen as part of a branch, it leaves me in a situation where I have several migrations that I need to roll back at any given time. In addition, they might be interleaved with migrations that exist on the
masterbranch if it’s a longer-running branch.
RailsConf 2018: What's in a price? How to price your products and services
So you have something new to sell: maybe your first book or a hip new SaaS. How do you decide the price? How do you know you’re not overpricing? Or underpricing? Why, oh why, did you ever think to sell something?!
Instead of choosing a number by looking inward at your costs, you can use what programmers use best: an abstraction! You’ll learn a model for picking the right price for your product and what that price communicates so you can confidently price your next great invention. You’ll leave with an actionable list of next steps for pricing your future projects.
Four things to consider when using Redis in production
Ruby programmers rely on Redis as a high-performance key-value store for many different jobs. Redis is suitable for many different tasks, including caching, acting as the transport medium for a message bus, and service analytics. Redis is often one of the first external dependencies you reach for as a Ruby programmer because it forms the backbone of the Resque and Sidekiq asynchronous job systems.
When you’re starting a new project, it is tempting to set up the bare minimum configuration for Redis because it works well out of the box. However, once you’ve started to put some load on the system, there are several concerns that you should be aware of when using Redis. In this post, I’ll talk about some of these concerns and some high-level ways of addressing them.
The four main concerns I will discuss in this post are monitoring, security, high availability and redundancy, and horizontal scalability. This is the first in a series of posts where I will cover these intermediate-to-advanced topics in depth.