Forem: André

Remount /etc/fstab without rebooting

André — Mon, 03 May 2021 06:32:53 +0000

Ever worked on a thing where you need to mount a network share on boot for a Linux machine and find yourself rebooting it over and over to try new configs and see if it works?

I just did that for 20 minutes, and it turns out there’s a command for this.

mount -a

That’s it.

Here’s an excerpt from the man page:

-a, --all
       Mount all filesystems (of the given types) mentioned in fstab (except for those whose line contains the noauto keyword). The filesystems are mounted following
       their order in fstab.

You’re welcome!

Making sure all commits pass the tests

André — Sat, 01 May 2021 12:29:12 +0000

If you’re a bit too pedantic about your git history, like I am, you probably want to make sure that all the commits are passing whatever checks the project has set up before merging it into the main branch.

It turns out there’s a way to automatically run a command for each commit when you’re doing a git-rebase — you can pass the --exec flag (or the shorthand -x flag).

With this flag, git will run the given command after applying each commit onto the new HEAD. If the command returns a non-zero exit code, the rebase will stop on that commit and allow you to update the commit so that it passes.

For example, if you have a Ruby project (using RSpec) and want to check that all commits after the main branch are passing the tests, you can run the following command.

$ git rebase -x “bundle exec rspec” main

Why bother?

There are a few good reasons, other than the warm fuzzy feeling it brings you inside, to make sure that the commits are valid.

My main reason for caring about this is that it helps you keep track that all commits are working. If you have commits that aren’t passing the tests or have incomplete/broken features, it will be more challenging to track down a separate issue using git-bisect. Since you might land on a commit that is not in a working state, it is harder to tell if a commit is good or bad.

It also forces you to think about commits as an atomic piece of completed work, which makes it easier to write a great commit message which summarizes the unit of work.

Include FactoryBot in RSpec

André — Sat, 10 Oct 2020 14:43:34 +0000

When using FactoryBot for generating random data in my RSpec tests for my Rails app, I had to keep prefixing my call to create with FactoryBot.

This caused my specs to look a bit cluttered.

trace = FactoryBot.create :trace
parent = FactoryBot.create :trace_field, trace: trace
child = FactoryBot.create :trace_field, trace: trace

It is possible to include the FactoryBot methods into RSpec so it will automatically find the methods from there.

To get that working, you could properly set up RSpec, as per the documentation, but if you didn’t you can add this to a file named spec/support/factory_bot.rb.

# spec/support/factory_bot.rb
RSpec.configure do |config|
  config.include FactoryBot::Syntax::Methods
end

Also, make sure that you also uncomment this line in spec/rails_helper.rb so that RSpec includes any files you put in spec/support/.

Dir[Rails.root.join("spec/support/**/*.rb")].sort.each { |f| require f }

Now that we’ve fixed that we can remove the FactoryBot prefix from the create calls to clean the whole thing up.

trace = create :trace
parent = create :trace_field, trace: trace
child = create :trace_field, trace: trace

Sprinkle some Elm in your React

André — Sun, 04 Oct 2020 11:01:58 +0000

After being out of the Elm world for about a year, I decided this weekend to try it out again. I created a new application (using create-elm-app) and got going. After a few minutes, the joy of writing Elm was back. The helpful error messages, the flexibility of describing data in the type system - it was fantastic!

In another side-project I've been working on for a few months, we are using React. Even though React is an excellent framework for building web applications, my fingers started to itch for writing Elm again.

Then it occurred to me - why can't we write an Elm module for a small set of a screen and embed that in a React component?

So that's what this post is about!

To get started, we need a project set up using webpack capable of compiling both React and Elm files. I'll leave this as an exercise for the reader.

This is the contents of the Main.elm file that we'll use to try and figure this one out.

module Main exposing (..)

import Browser
import Html exposing (Html, text)

main : Program () Model Msg
main =
    Browser.element
        { init = init
        , view = view
        , update = update
        , subscriptions = subscriptions
        }

type alias Model =
    {}

init : () -> ( Model, Cmd Msg )
init flags =
    ( Model
    , Cmd.none
    )

type Msg
    = Noop

update : Msg -> Model -> ( Model, Cmd Msg )
update _ model =
    ( model, Cmd.none )

view : Model -> Html Msg
view model =
    Html.div [] [text "Hello from Elm!"]

subscriptions : Model -> Sub Msg
subscriptions _ =
    Sub.none

This doesn't do anything interesting since it only prints out the string "Hello from Elm!", but it's good enough to try and get it running inside of a React component.

Screenshot of the Elm application we'll wrap

How does an Elm application initialize?

When you create any Single Page Application (SPA), you usually have some entry point Javascript that imports the SPA's main module and mounts it on a specific DOM node on the page.

To take a closer look at this, we can open the generated index.html file.

import { Elm } from '../Main';

document.addEventListener('DOMContentLoaded', () => {
  const target = document.createElement('div');
  document.body.appendChild(target);

  Elm.Main.init({ node: target });
});

Example hello_elm.js from a new project

First, we import the Elm application from the Main.elm file
On the DOMContentLoaded event, we create a new DOM element for a div and append it to the body
We then initialize the Elm application to run inside the new div

The main takeaway here is that we will need a DOM node to run our Elm application inside.

Creating the React component

Now that we understand how the Elm application gets initialized, we can start thinking about designing our React component to host it.

Since the only thing we need to initialize the Elm application is a DOM node, let's create a component that renders a div we can use as our target.

import React from 'react';

export default function ElmComponent() {
  return <div />;
}

To get the reference of that div, we can use the useRef hook from react to get a reference to the DOM node for the entire lifecycle of the component. The useRef function takes an initial value

import React, { useRef } from 'react';

export default function ElmComponent() {
  const target = useRef();

  return <div ref={target} />;
}

Now that we know where to put the application, we can import our Elm module and use the useEffect hook to initialize it when the component first mounts to the DOM.

import React, { useRef } from 'react';
import { Elm } from '../Main';

export default function ElmComponent() {
  const target = useRef();

  useEffect(() => Elm.Main.init({ node: target.current });

  return (
    <>
      <h1>Hello from React!</h1>
      <div ref={target} />
    <>
  );
}

Now when we render our ElmComponent, our Elm application will run inside our React application.

The final result

How can we pass data from React?

While embedding the Elm application in an already existing React application, there's a good chance you want to send along some data from the React app to the Elm app. This could be anything from authentication tokens for making HTTP requests to a server to the current user.

To do this, we can change the type signature of our main function in the Elm program to signal that we're expecting the program to receive initial data when it starts up. We also then to add to the data we want to hold in the program to our Model type.

For passing an authentication token from React into the Elm program, so that we can use it to make HTTP requests, we could change our module to something like this.

import Browser
import Html exposing (Html, text)

main : Program String Model Msg
main =
    Browser.element
        { init = init
        , view = view
        , update = update
        , subscriptions = subscriptions
        }

type alias Model =
    { authToken : String }

init : String -> ( Model, Cmd Msg )
init authToken =
    ( Model authToken
    , Cmd.none
    )

type Msg
    = Noop

update : Msg -> Model -> ( Model, Cmd Msg )
update _ model =
    ( model, Cmd.none )

view : Model -> Html Msg
view model =
    Html.div [] [text <| "Token: " ++ model.authToken]

subscriptions : Model -> Sub Msg
subscriptions _ =
    Sub.none

The differences in our new Elm program is:

Model is constructed with an authToken : String value
The type signature of main now specifies the type of the flags passed to it
init also has an updated type signature an build the initial Model with the value from the flags

If we now render the ElmComponent and pass along a string as the flags prop, the Elm program will store that inside the initial model so that we can use it later. Let's run the new program.

import React, { useRef } from 'react';
import { Elm } from '../Main';

export default function ElmComponent() {
  const target = useRef();

  useEffect(() => Elm.Main.init({
    node: target.current,
    flags: "my-very-secret-token"
  });

  return <div ref={target} />;
}

Our rendered Elm program with arguments passed from React.

You can also pass along more complex data to your Elm program using flags, such as objects, tuples, arrays and so on. The Elm guide has great documentation if that is something you want to read more about!

Flags · An Introduction to Elm

In summary

By using this little building block in your React application, you can start introducing Elm into your codebase without rewriting the application.

This can help you try if you like it enough in a low-risk situation and later decide if you want to expand your usage of it throughout the application. Otherwise, you only have a small portion of Elm running and can easily convert it back to React.

But since Elm is fantastic, that'll probably never happen. 😁

Counting large tables in PostgreSQL

André — Thu, 01 Oct 2020 08:39:05 +0000

Imagine you have a really large table (> 100m rows). How do you figure out how many rows there are in that table within a reasonable time?

If you try and do a SELECT COUNT(id) FROM my_large_table, it will end up taking a lot of time since the database will have to scan throw all the rows to count them.

$ heroku pg:ps
 pid | state | source | running_for | transaction_start | waiting | query
------+--------+------------------+-----------------+-------------------------------+---------+--------------------------------------------------
 6926 | active | psql interactive | 00:10:12.549096 | 2020-10-01 08:22:18.090989+00 | t | SELECT COUNT(id) FROM pageviews;
(1 row)

I gave up after waiting for 10 minutes...

A faster way is to get an approximate value by looking at statistics from the catalog table pg_catalog.pg_class.

DATABASE=> SELECT reltuples::bigint FROM pg_catalog.pg_class WHERE relname = 'pageviews';
 reltuples
-----------
 136032896
(1 row)

This took less than a millisecond, compared to the 9 minutes that we waited for the COUNT query to finish. It may not be as accurate, but it's enough useful to set expectations for adding new indices to the table or doing any large operations on it.

GraphQL field names in Ruby

André — Thu, 24 Sep 2020 05:27:17 +0000

While building a GraphQL API, I noticed that many times the name of the field on the type didn’t match the name of the method on the object.

class Types::UserType < Types::BaseObject
  field :is_active, Boolean, null: false
  field :is_banned, Boolean, null: false

  def is_active
    object.active?
  end

  def is_banned
    object.banned?
  end
end

This caused me to have to write custom methods in the Object type that acts as a proxy for the calling the method.

It turns out there’s a documented way in the graphql-ruby gem that basically does all of this for you - the method attribute.

And by using the method: attribute, we can rewrite our previous example like so:

class Types::UserType < Types::BaseObject
  field :is_active, Boolean, null: false, method: :active?
  field :is_banned, Boolean, null: false, method: :banned?
end

We can now keep writing methods using the usual Ruby conventions but expose them in the schema using names that make sense for the API consumer.