Active record has a multitude of features and niceties. From merging scopes to performing complex joins. However, sometimes it falls short. One shortcoming is a Union query.

When I’ve got a roadblock with active record, I reach for either raw SQL or Arel Tables. Both of these work well but tend to produce verbose code. That’s why it’s nice to to stay in Active record for readability. Ok, so let’s actually look at how to accomplish this.

Request specs have a lot of benefits over traditional controller specs. They allow for full stack testing at the controller level. One thing I recently ran into was how to write this for AJAX requests.

When working with multiple databases, code can become intertangled with records spanning across the systems. Seperating database domain reponsibilities away from each other is challenging but a good end goal. Sometimes this isn’t possible which in the case of testing clean-up can make for some tricky configuration details.

Recently, I’ve really dug into the Hanami framework. Coming from a Rails background it is really fascinating to see what a Ruby framework looks like in a post-Rails world. One of the first things I setup with new Rails projects is a process by which I can test mailers in development. The letter_opener gem is perfect for this purpose and luckily has a non-Rails setup guide.

A common theme I’ve noticed throughout my career is that every product, every feature, and every company eventually hits a threshold in their application of what was designed to support. Once this magic threshold is reached, the application starts to fall down the technical debt cliff. Now, I’m not saying that this is due to bad design or bad decisions, really it is just that technical debt is difficult to identify and more difficult to prioritize. It isn’t building new features or fixing existing bugs, but rather building better architecture for the future. That’s tough to sell as something worth investing in. In this article, we’ll discuss several metrics for identifying technical debt in your application.

In addition to request params being sent with malicious characters, a user’s session can also contain them. If your website relies on session data (and most do) to determine if a user is logged in, then you may experience the pain of seeing ArgumentError: string contains null byte appear in your logs. Luckily, building on the previous two posts we can quickly craft a mechanism to check a users session and invalidate the request if necessary.

In this article, we’re going to learn how to build a React Drawer component from start-to-finish. We’ll work through several iterations of the component. Finally, we’ll end with something that could be reusable anywhere throughout your application.

When working with asynchronous requests and setting state in React, you can encounter some interesting side-effects. What happens if the request succeeds before the state is set? The reverse? With situations like this it’s hard to be confident in what the logic flow will look like. setState solves for this via allowing callback functions to be defined.

Strong parameters are a great way of guarding against unexpected request params. They allow you to specify the names of keys that are accepted from a given request. I’ve found working between a JavaScript front-end and Rails back-end sometimes you need to adjust request values (especially when at an intermediary step during a refactor). However, strong parameter values can’t be modified which makes this a bit more complex.

Previously, I described a process of using Rack to validate request objects for malicious formats (specifically null bytes). However, request params come in many different formats from arrays to hashes to arrays containing hashes, there are a lot of different cases to cover. Fortunately using recursion allows for an elegant solution that covers each scenario.