Where Am I: URL Assertions with Cypress

The URL that appears in the browser's URL bar is one of the first and
primary ways that users interact with our web apps. The URL tells the app
and the user of their location within the route hierarchy of the app. It
sometimes even contains state. The URL consequently serves as an excellent
first assertion when writing integration tests.

When writing Cypress integration tests, there are
several ways for us to assert about the current URL.

The cy.url() and
cy.location()
functions are the primary ways for us to gain access to information about
the current state of the URL. From there, we can perform a variety of
assertions.

We can assert about the entire URL:

// URL: http://localhost:8000/pokemon
cy.url().should('eq', 'http://localhost:8000/pokemon');
// ✅ passes

This is certain the most precise assertion. The tradeoff is that it requires
us to know something

Continue reading “Where Am I: URL Assertions with Cypress”

The Ray Tracer Challenge: A Test-Driven Guide to Your First 3D Renderer, in beta

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”