Wrap Parameters Without Changing Markup

While updating logic that caused a POST with a JSON body to change into a POST as multipart/form-data, I ran into an issue where the Rails controller was expected params in a nested way. Sure, I could change my inputs to have a different name that would cause the nested structure, but that was changing logic down the line.

Rails was wrapping the incoming parameters automatically since the prior request was of 'Content-Type': 'application/json'. Well, I'd really like this same behavior on my new request as it would solve my current conundrum.

Turns out ActionController has a method that can help out with that… the aptly named wrap_parameters method.

In my case, the name I needed was the same as the controller so I could use this:

class FooController < ApplicationController
  wrap_parameters format: %i[mutlipart_form json]
end

This produces a params payload like so:

ActionController::Parameters {
  "account_id_eq"=>
Continue reading "Wrap Parameters Without Changing Markup"

Genetic Algorithms and Machine Learning; also August PragPub

Query for NULL ‘or’ empty string in ActiveRecord

Sometimes you come across a query that looks for an attribute that is NULL 'OR' an empty string. Sure there are options we could employ that may remove the necessity of checking for both but let's see how we can improve our code a bit first!

The majority of the time I see this as a SQL fragment in ActiveRecord:

Foo.where("name is null or name = ''")

Which produces the following SQL:

SELECT * FROM "foos" WHERE (name is null or name = '')

Sure you can say now that ActiveRecord has or it could be done like so:

Foo.where(name: nil).or(name: '')

However, I'm currently in a project that doesn't support or yet so I went playing to see what I could come up with that wouldn't be a SQL fragment. My first thought was to

Continue reading “Query for NULL ‘or’ empty string in ActiveRecord”

Christmas in July! Save 40% on pragprog.com

Code with the Wisdom of the Crowd: Get Better Together with Mob Programming, in print

Build Reactive Websites with RxJS: Master Observables and Wrangle Events, in beta

Rediscovering JavaScript: Master ES6, ES7, and ES8 now in print and shipping

Programming Elixir ≥ 1.6, in print, plus free offers

Getting Clojure: Build Your Functional Skills One Idea at a Time, in print

Modern Vim: Craft Your Development Environment with Vim 8 and Neovim, in print; May PragPub Magazine now available

Modern Vim: Craft Your Development Environment with Vim 8 and Neovim, in print; May PragPub Magazine now available

Xcode Treasures: Master the Tools to Design, Build, and Distribute Great Apps in beta

Xcode Treasures: Master the Tools to Design, Build, and Distribute Great Apps in beta

Simplifying JavaScript: Writing Modern JavaScript with ES5, ES6, and Beyond in print

Simplifying JavaScript: Writing Modern JavaScript with ES5, ES6, and Beyond in print

Data retention with the Serverless Framework, DynamoDB, and Go

At Honeybadger we have standard retention periods for data from which our customers can choose. Based on which subscription plan they choose, we’ll store their error data up to 180 days. Some customers, though, need to have a custom retention period. Due to compliance or other reasons, they may want to have enforce a data retention period of 30 days even though they subscribe to a plan that offers a longer retention period. We allow our customers to configure this custom retention period on a per-project basis, and we then delete each error notification based on the schedule that they have set. Since we store customer error data on S3, we need to keep track of every S3 object we create and when it should be expired so that we can delete it at the right time. This blog post describes how we use S3, DynamoDB, Lambda, and the Serverless Continue reading “Data retention with the Serverless Framework, DynamoDB, and Go”

Docker for Rails Developers: Build, Ship, and Run Your Applications Everywhere, in beta

Craft GraphQL APIs in Elixir with Absinthe: Flexible, Robust Services for Queries, Mutations, and Subscriptions, in print

Journey to ElixirDaze 2018

Last October I discovered an interesting Github issue, Elixir-Lang #6643. It was opened José Valim, the creator of Elixir.

Here's part of the introduction to this issue:

Elixir master now includes a code formatter that automatically formats your code according to a consistent style.

We want to convert Elixir's codebase to use the formatter on all files. We understand this means a lot of code churn now but, on the positive side, it means we can automatically enforce and/or format future contributions, making it easier for everyone to contribute to Elixir.1

This issue set off a massive refactoring project to get Elixir conforming with its new formatter. Today, new pull requests to Elixir must pass through the formatter without requiring changes. I think this will have a ripple effect on every Elixir project in production.

While closing this issue, José provided the following statistics on the refactor: