But let’s set the stage: you install VIM on Ubuntu 22.04, open up a file and try to yank to the clipboard with "+y or "*y, and when you hit Ctrl+V in a different app, nothing appears.

You then go back to the terminal and look for VIM’s +clipboard support, but sadly when you run vim --version, it shows -clipboard.

Time to fix VIM with +clipboard

1. Modify the brew formula, but we need to make a copy first: cp /home/linuxbrew/.linuxbrew/opt/vim/.brew/vim.rb ./vim.rb
2. Modify the file: vim ./vim.rb. Replace "--without-x" with "--with-x".
3. Uninstall the currently installed VIM version: brew uninstall vim
4. Install Ubuntu dependencies: sudo apt-get install libncurses5-dev libgtk2.0-dev libatk1.0-dev libx11-dev libxt-dev
5. Install VIM from the local formula: brew install --build-from-source ./vim.rb

Take a look after it’s compiled and installed: vim --version.

Voila, now we got our +clipboard!

I have a YouTube video playing in Firefox, and a colleague asks me a question. I turn around on my swanky swivel chair and roll over to their desk. *boink* the 3.5mm audio cable unplugs from my machine. No biggie, I’ll just plug it back in after I’m done conversing with my colleague.

5 minutes later, I return to my machine and plug the audio cable back into the machine. No sound. Nani?! I go into “Settings” -> “Sound” and I see that “Dummy Output” is selected for “Output Devices”. No biggie, I click on the dropdown and proceed to select “Line Out - Builtin Audio”.

And… nothing. Silence is golden, I suppose. I should say, if you’re having issues with Ubuntu 22.04 (or later) not even showing your audio devices, you have a different problem.

For me, I could select my other audio devices (yes, plural, including the S/PDIF and HDMI Audio out) but when I navigate away from the “Sound” page, it reverts to Dummy Output. I can only assume it’s not letting me change, but the UI doesn’t reflect that fact.

Time to fix “Dummy Output”!

For the savvy reader, you’ll have noticed (pulse) audio within the first paragraph. This is indeed the culprit. For some reason, if the audio is playing and the device gets disconnected, there is a bug wherein pulseaudio gets stuck on “Dummy Output”.

The fix is quite simple with two options:

1. Reboot your machine (ahaha, who does this anymore? This is 2023, and we’re going for 20 years of uptime baby!)
2. Restart pulseaudio service.

Let’s go with option 2: pulseaudio --kill && pulseaudio --start

… and we’re back 🎉🎧!

There are plenty of great tutorials for past versions of Elm, Elixir and Phoenix, of course. Some of those lessons are largely still applicable, but with Phoenix 1.3, the directory structure for things have shifted around a little bit, so here’s a fresh introduction to getting all of these moving targets to play nicely together.

Oh, and we don’t have to monkey around with Webpack, as we’ll be doing everything purely the Phoenix-way: with Brunch! No unwieldy configs and monkeying around with cryptic Webpack config parameters.

Let’s jump in!

Installing (or updating) Elixir to 1.6.x

Skip to the next step if latest Elixir (1.6.x) is already installed.

Before we get anything off the ground, we need to install Elixir. I highly recommend installing Elixir using the version manager asdf, which can manage both the Erlang runtime (necessary to compile and run Elixir) and Elixir platform under one unified tool. More details on installing asdf are available on their Github page.

From a clean slate with asdf, installing both Erlang and Elixir itself should quite simple:

$ # We may need to install dependencies for Erlang runtime
$ # for our system prior to installing Erlang itself.
$ # See: https://www.tiot.jp/riak-docs/riak/kv/2.2.3/setup/installing/source/erlang/

$ asdf plugin-add erlang
$ asdf plugin-add elixir
$ asdf install erlang 21.0.3 # Latest version as of this writing, but double check newest version with `asdf list-all erlang`!
$ asdf install elixir 1.6.6 # Same notice as above ^. Check `asdf list-all elixir`

If we have an older version of Erlang or Elixir, we will want to update them both. Updating Erlang and Elixir versions with asdf is trivial and operates exactly the same as above, except we will not have to perform the two plugin-add steps:

$ asdf install erlang 21.0.3 # Latest version as of this writing, but double check newest version with `asdf list-all erlang`!
$ asdf install elixir 1.6.6 # Same notice as above ^. Check `asdf list-all elixir`

Installing (or updating) Phoenix to 1.3.x

Skip to the next step if latest Phoenix (1.3.x) is already installed.

Before installing Phoenix, we should go through the Phoenix pre-install guide (tl;dr we’ll need Hex [an Elixir package manager], PostgreSQL and Node.js–If we don’t have Node.js yet, we can install it with asdf as well!).

Once we have the pre-requisites installed, installing Phoenix itself is one command away:

$ mix archive.install https://github.com/phoenixframework/archives/raw/master/phx_new.ez

If we’re on an older MINOR release of Phoenix (i.e. 1.2.x or below), we’ll have update our local Phoenix package:

$ mix local.phoenix

If we’re already on 1.3.x, but not the absolute latest version of 1.3.x, we can use:

$ mix local.phx

Note: Phoenix changed its mix task name between 1.2 and 1.3 from phoenix to phx.

Installing (or updating) Elm to 0.18.x

Skip to the next step if latest Elm (0.18.0) is already installed.

Installing Elm once we have npm installed is a piece of cake.

$ npm install -g elm

Updating is similarily easy, you just have to run:

$ npm update -g elm

Yep, that’s all we have to do! Easiest step of this whole process, by far. Thanks, Elm!

Creating a new Phoenix project

With all our dependencies installed, we can create a new Phoenix project like so:

$ mix phx.new phoenixWithElm

This will create a new folder named phoenixWithElm at the current working directory, and prompt us to install the default Node.js dependencies for Phoenix (the Brunch build tool, for one).

Unless we have reasons to defer installing the dependencies (which we will need, eventually), we should respond with [Y]es now.

Installing and Configuring “elm-brunch”

We need a third party node package called elm-brunch, which is a plugin for Brunch and performs the Elm compilation for us whenever we save a .elm file in the assets directory.

From now on, all actions should be performed from within the assets/ directory of our project. Filepaths and Directories will be given relative to assets/.

To start, add the "elm-brunch" line to our package.json file:

{
  // ...
  // Other sections
  // ...
    "devDependencies": {
        "elm-brunch": "^0.11.1",
          // ...
          // Other dependencies
          // ...
    }
}

After we’ve added elm-brunch to our package.json file, we need to install it:

$ npm install

If everything has gone well so far, we just need to put the final touches on our elm-brunch configuration and we should be off to the races!

We should still be inside of the assets/ directory. Time to edit brunch-config.js. Under plugins section, we should see babel as the sole default plugin:

{
  // ...
  // Other sections
  // ...
  plugins: {
    babel: {
      // Do not use ES6 compiler in vendor code
      ignore: [/vendor/]
    }
  }
}

We want to extend this section to include our elm-brunch plugin configs:

{
  // ...
  // Other sections
  // ...
  plugins: {
    babel: {
      // Do not use ES6 compiler in vendor code
      ignore: [/vendor/]
    },
    elmBrunch: {
      // (required) Set to the elm file(s) containing our "main" function `elm make`
      //            handles all elm dependencies relative to `elmFolder`
      mainModules: ['elm/Main.elm'],

      // (optional) If specified, all mainModules will be compiled to a single file
      //            This is merged with outputFolder.
      outputFile: 'elm.js',

      // (optional) add some parameters that are passed to elm-make
      makeParameters: ['--warn']
    }
  }
}

These are the bare minimum configs necessary to compile our Elm app, and more config flags are available and documented in the elm-brunch repository.

We want to make an additional change to the paths section, which is to add "elm" to the list of watched paths:

{
  paths: {
    // Dependencies and current project directories to watch
    watched: ["static", "css", "js", "elm", "vendor"],
    // Other configurations
  },
}

Creating our Hello World Elm app!

With all of the config all setup, we just have one last thing to do: Create an elm/ directory under assets/ and make an Elm file within it!

$ mkdir elm
$ cd elm

Then using our favourite text editor, create and save Main.elm with the bare minimum content:

module Main exposing (..)
import Html exposing (..)

main =
    p [] [ text "Hello world" ]

Let’s boot up the Phoenix server (which will in turn start up a Brunch watch job) and have it compile our Main.elm file:

$ cd ../.. # If we are still inside of `assets/elm/`, back out to project root
$ mix phx.server

Compiled Elm files can be found in <project_root>/priv/static/js/elm.js by default. We can change both the location and the name of the compiled file in the brunch-config.js file if we so wished.

One last thing we need to do before we can check out our Hello World elm code, add it to our layout file so that it gets loaded on page load.

Add this line to lib/property_speculation_web/templates/layout/app.html.eex:

<script src="<%= static_path(@conn, "/js/elm.js") %>"></script>

It should go right below the existing <script> that’s pointing to /js/app.js.

Everything is in place and we should be able to hit up localhost:4000 in a browser and see the Phoenix App’s greeting screen.

To make sure that our Elm app is actually loaded, open up the inspector and plunk down this line of JS:

Elm.Main.embed(document.getElementsByClassName('logo')[0])

Immediately we should see the words “Hello world” overlap the Phoenix logo banner. Huzzah! This proves that our Elm app is being loaded onto the page, and can be successfully mounted!

Troubleshooting tip: If you’re running into issues, make sure that the elm/ directory is created under <project_root>/assets/!

Wrapping Up

Congratulations! At this point the Brunch is setup to compile changes made to our Elm code in real time, so long as the Brunch watcher is running (and it will be autorun whenever the Phoenix server is started). The app template is updated to load our elm.js file.

I have noticed that the Brunch watcher self-exits and does not restart when brunch-config.js is modified while Phoenix is running, necessitating an entire server reboot. If you know a way around this, I’d love to hear from you! My contact info is in the footer, please reach out!

Let’s review our finalized directory structure under assets/ and priv/:

.
├── assets
│   ├── css
│   ├── elm # This is where we should put our *.elm source
│   ├── elm-stuff # This is where Elm packages and dependencies go
│   ├── js
│   ├── node_modules
│   ├── static
│   └── vendor
└── priv
    ├── gettext
    ├── repo
    └── static
        ├── css
        ├── images
        └── js # This is where our compiled Elm gets output as "elm.js"

• This list focuses on the two main directories and filters out all the other directories.

Here (and elsewhere in the world), there’s an illusion of progress created by overemphasising certain properties over others. Sleekness, smallness and pocketability of technological artifacts. Yes, we now can fit in our pockets a computer that’s hundreds of thousands of times[1] faster than the 486 I first used as a 5 year old. Or obtain the play-by-play on gossip among friends. Let’s not forget the most important progress of them all: I can immortalize (or not: Snapchat) this moment, selfie style!

To discredit this as not progress would be disingenuous. Yes, they are indeed facets of progress, but of such a limited use that I want to refer us to a different kind of progress: People progress.

The collective psyche of the people we associate with–often referred to as “culture”–progress at a very different pace. No, not “slower” (or “faster”). Different.

Progress among people happen through direct and indirect contact, but contact nonetheless. Direct contact is the the face-to-face, phone-to-phone, and text-to-text type. The speed of cultural progress happens in that general order. Indirect contact happens largely through mass media and other types of impersonal associations. Loosely understood as the zeitgeist of a time: it’s the “air” about a populace, there is this osmosis-like diffusion of thoughts and conduct that permeates society organically and allows the acceptance of certain thoughts and actions while rebuking others.

When an idea becomes popular, we say it has hit “critical mass”. Direct contact among a large enough sample size of the populace has embraced this new idea. This can be exciting and rewarding–sometimes financially so for its progenitors.

Critical mass, however, does not necessarily imply unification of culture. But if the critical mass is limited to a particular demographic, be it geographic, age, race, religion, etc. then fragmentation is inevitable.

You would be correct to remark, “But progress is not uniform!”. The kind of progress needed to forge long lasting unity and avoid fragmentation does not exist. Not in the real world, anyways. We need to increase the bandwith of contact, direct contact, between ourselves and others unlike us. Only openness and vulnerability between the various groups that comprise our culture allows for unification and reconciliation. There is no silver bullet.

Let’s be excited when a startup that we happen to be part of makes it into the big leagues of the unicorns, when the new iPhone/iWatch/iThing comes out, or when self driving cars finally makes it to the commercial realm. These things are all worth celebrating.

But don’t forget that progress in the cultural sphere changes at its own pace, buffeted by our ability to be open and inclusive. The kind of progress that will matter twenty years later will be the kind we make happen today, as people, one contact at a time.

[1] I was way off with this remark. I looked up performance benchmarks of the 80486 DX2 and it can performs about 2MFLOP/s, whereas an iPhone 7’s CPU is in the ballpark of 2-3GFLOP/s (that’s a 1000x difference, not “hundreds of thousands”).

Thanks to Jimmy He, Nancy Ku, Nolan Ku and Eric Tsai for reading earlier drafts of this post and offering feedback.