Meow is a pure shell program that manages booting and killing any given amount of processes for your development workflow. It gives you the ability to boot/kill these processes in different terminal tabs automatically. Scroll to the bottom to see a quick visual representation on how Meow reads and organizes your processes. To see everything Meow has to offer checkout its repo. https://github.com/LoganBresnahan/meow

As a web developer, I feel elated at the current state of web development. It continues to grow more vibrant and exciting everyday! There are so many wonderful tools to make a web dev’s life easier and more productive. Personally, I do a ton of work with Rails, Webpack, and Elixir! The creators behind these tools and frameworks have made spinning up a new website easier than ever….but can it get even easier?

My normal development setup consists of a booting up a backend, frontend, and cache server. So now we have 3 processes to boot-up somehow. Not a problem! There are some really cool tools out there such as Overmind and the Foreman family of tools that manage Procfile based applications. Essentially reading commands off of the Procfile and running them. Each tool respectively has it’s own features that really shine, but I found they didn’t do exactly what I wanted.

As a Rails developer I use the pry gem a lot for debugging. pry is a repl (read evaluate print loop) which allows you to input text into the terminal within the context of your application similar to using debugger in JavaScript. When using Foreman to boot up my servers for development I noticed that pry doesn't work as expected. It "works" but you simply can't see what you're typing. Foreman wasn't made to receive input. Overmind on the other hand is closer to what I want but still misses the mark. Like foreman, it doesn't handle receiving input when using a repl. However, Overmind is built with tmux. You can simply open a new tab and connect it to your desired process that was started with Overmind and huzzah! My pry session is working and I can see what I'm typing. HOWEVER, I'm too lazy for this approach. I don't want to open up a new tab and handle closing it. I just want everything to be setup with one simple command.

Enter Meow. I created Meow as simple development tool that would let me add commands to a single file, similar to a Procfile, but also give me the ability to boot these commands into a different terminal tab without having to do it manually. All the while, making sure that debugging tools, such as pry, would just work. Not only that, I wanted the option to fine tune how and when processes would die. With Meow you can tell a newly spawned terminal tab to "expire" or "endure" when the main process is terminated. Check out the Readme from the link above to learn all the options available with Meow. Below is an example config file Meow reads from to manage your commands.

# Hi I'm a comment. I must start at the beginning of a line.

--start-config

# For an explanation of these config options check out the Readme.
writable-relative-directory=tmp
auto-check-updates=true
apple-tab-spawn-delay=0.75
unix-shell=bash
kill-signal=15

--end-config

# To execute these commands just type "meow" in your terminal
# If you want to execute just one or a selection of these groups 
# you can give Meow command line arguments "meow 0 2". 
# This will only boot the commands listed in the first and
# last groups.
--start-commands

# I'm the first command of a group so I exist in the foreground
bundle exec rails server
# Commands after the first exist in the background.
yarn start:dev

--new-tab-expire
# New tab expire means it closes when you terminate the first group.

# We can change directories!
-cd $HOME/my_project_two

# I'm the foreground command of this new terminal tab.
iex -S mix
# I'm off to the background.
npx webpack --mode=development --watch=true

--new-tab-endure
# New tab endure means these commands do not exit when you
# kill the first group.

redis-server

--end-commands

Originally published at https://dev.to on May 23, 2021.

I recently learned that the object oriented language, Ruby has built in currying. This is pretty cool considering Ruby emphasized object oriented programming rather than functional programming. Here is an example of some Ruby code utilizing currying with an add lambda.

add = lambda { |a, b| a + b }

curried_add = add.curry.(1)
curried_add.(2) #outputs 3

Normally the add lambda would force us to pass two arguments when calling add, but by chaining in the curry method we bypass this and save the curried lambda in out curried_add variable which we can then call with the second argument later. There is a shorthand for calling our curried lambda in Ruby 2.5 with yield_self which relates to how we can write this in Elixir.

add = lambda { |a, b| a + b }

add.curry.(1).yield_self { |curried| curried.(2) } #outputs 3

How would these two examples look in Elixir?

add = fn
  ({a, b}) ->
    a + b
  ({a}) ->
    fn(b) -> a + b end
  end

add.({1, 2}) #outputs 3

curried_add = add.({1})
curried_add.(2) #outputs 3

Elixir doesn’t have built in currying, so you have to implement something yourself. We are using anonymous functions because they resemble lambdas in Ruby. We use function overloading in our anonymous function to determine which function match to run. You may be wondering why we wrap our arguments in a tuple for our add function. That’s because anonymous functions utilizing function overloading can’t have a different arity. We get around this by using the tuples. Notice, that when passing in only one integer in our tuple argument, our add function returns another function. Our curried_add variable gets assigned to that returned anonymous function which means we can then execute it later. Now for the shorthand.

add = fn
  ({a, b}) ->
    a + b
  ({a}) ->
    fn(b) -> a + b end
  end

add.({1}) |> fn(curried) -> curried.(2) end.() #outputs 3

After trying this out I got a little over zealous and implemented a trivial Elixir module that could pass curried functions to other math operations.

This module utilizes a lot of recursion to get the desired result. The basic idea is to pass your starting accumulator (0), the operand, the integers you want to calculate, and whether you want to curry the operation by having the return value be an anonymous function. Albeit, this is trivial as you could also just have the calculation return the actual calculated number and pass that on to the next CurryMath function which would get the same result. ¯\_(ツ)_/¯

Elixir is awesome, go try some other currying implementations.

Using the Cowboy HTTP web server it’s very easy to handle web socket connections in your Elixir application. Keep in mind, this example is not using the Phoenix framework. With Elixir’s tools, you can quickly create a simple web framework.

Let us start by making a new Elixir application.

Run mix new my_websocket_app

Open the mix.exs file and make it look like this:

Notice the necessary dependencies we need. :cowboy the HTTP server, :plug and :plug_cowboy the HTTP server connection adapters, and :jason the JSON parser. Run mix deps.get to fetch dependencies. Also, notice line 17:

mod: {MyWebsocketApp, []}

This is added because we are going to declare MyWebsocketApp as an application that will be monitored by the Erlang VM.
https://hexdocs.pm/elixir/Application.html#module-the-application-callback-module

Open your my_websocket_app.ex file and make it look like this:

It is here we are using Elixir’s Application module to tell the Erlang VM that our app is an application to monitor.

Next, we have the child workers listed that will be supervised by our MyWebsocketApp.Application. First, the Plug.Cowboy configuration. :scheme is set to :http for local development. :plug is set to our MyWebsocketApp.Router plug that we will create. Inside of :options we have :dispatch which is set to our private dispatch/0 function below, and :port is set to 4000.

More on the dispatch/0 function. What we are doing here is pattern matching on incoming requests to the HTTP server. If a request ends in "/ws/[...]" , that means it will be routed to our MyWebsocketApp.SocketHandler module which is where we will handle web socket connections. What is "[...]"? It matches everything else after "/ws/". You will see in our JavaScript below, our web socket request path will be "/ws/chat". "chat" is scooped up by "[...]". More can be found in the source code for the cowboy router: https://github.com/ninenines/cowboy/blob/master/src/cowboy_router.erl#L196. Finally regarding dispatch/0, if the request is not matched by "/ws/[...]" then the request gets sent to our router, MyWebsocketApp.Router.

Lastly, our final child worker is Registry.MyWebsocketApp. We are going to use Elixir’s Registry module as a dispatcher for the incoming web socket messages. https://hexdocs.pm/elixir/master/Registry.html#module-using-as-a-dispatcher

Make a router.ex file inside your lib directory and make it look like this:

We are using Plug.Router and creating a Plug pipeline that matches on incoming requests and routes them appropriately. get "/" matches to our home route where we use EEx to evaluate our application.html.eex file which we will create shortly so we can present the user with with something to see for our upcoming web socket chat example. match _ proceeds to match anything other than "/" . At the top of the file we are using our Jason dependency as our JSON parser and we are using Plug.Static to serve static assets like our application.js file we will make. https://hexdocs.pm/plug/readme.html#plug-router

Make the application.html.eex file in your lib directory:

This is super basic HTML that we have created. Just note, we are loading our JavaScript file application.js.

Make a sister directory to lib called priv, inside that make a static directory, finally make a js directory inside static. Inside the js directory, make the application.js file:

I’m not going to explain this JavaScript in great detail because this post is really about Elixir. We are just throwing this together to make the chat example work. We are opening up a web socket connection and setting event listeners for incoming web socket messages. We also have an event listener in the case the web socket connection is closed, if so, we re-open it. You should also notice when a user hits the submit button we send our data along to the web socket server. Finally note, we are setting the web socket request path to "/ws/chat" because we are going to use that path as a registry key in our Registry, Registry.MyWebsocketApp.

Now that we have the JavaScript, time to create MyWebsocketApp.SocketHandler. In the lib directory make the socket_handler.ex file:

At last, the reason you probably clicked on this post. This is our MyWebsocketApp.SocketHandler module that handles web socket connections. First note, we are referencing the :cowboy_websocket module with @behaviour. This makes sure we implement the necessary callbacks that are defined by :cowboy_websocket. Those are init/2, websocket_init/1, websocket_handle/2, and websocket_info/2.

Inside of init/2 we are going to grab the path from the request and save that to the state variable that gets passed along to the websocket_init/1 function. It is inside this function that we will utilize Elixir’s Registry module. Remember we setup the supervised Registry process in the my_websocket_app.ex file? If not, go take another look. We set the :keys options to :duplicate. This means that multiple processes can be registered under one key in the registry. In our case that one key is the web socket request’s path name. Anytime someone opens their browser and travels to the page of our website which makes a web socket request with that path name ("/ws/chat") a process id number for their web socket connection will be saved in Registry.MyWebsocketApp. The function register/2 that we call on the Registry module actually saves the current process’s pid (process id) implicitly as you will not see it being passed in as an argument. If you want to see what the process’s pid is when your code runs you can add IO.inspect(self()) to the top of the websocket_init/1 function and it will print to your terminal.

When the browser client actually sends a message utilizing the web socket connection the websocket_handle/2 callback is triggered. This callback has a return value of {:reply, {:text, message}, state}. This actually sends a message back to the client that sent the original web socket message. In our case we want to broadcast that message to every process in the Registry.MyWebsocketApp that shares the same key (users who have made a request to "/ws/chat" by navigating to our home page). This means we use the dispatch/2 function to iterate over all of the pids that are registered and send them the desired message with Process.send/3.

This is where the special websocket_info/2 callback is utilized. Whenever an Elixir process sends a message to our MyWebsocketApp.SocketHandler the callback is triggered. This callback has a return value just like websocket_handle/2 which returns a message to the original client.

That’s it! Now we can actually make sure this all works. Start your development server with iex -S mix. Once everything compiles, visit http://localhost:4000/ in two different browsers just for good measure. As soon as you enter some text in one browser and hit submit you should see it immediately popup in the other browser.

Elixir is amazing! Thanks to all of the hard work by the authors and contributors of the these libraries we are able to make a super easy to use chat server in a very short time. Thanks so much for reading!

References throughout this post:
1. https://hexdocs.pm/elixir/Application.html#module-the-application-callback-module
2. https://github.com/ninenines/cowboy/blob/master/src/cowboy_router.erl#L196
3. https://hexdocs.pm/elixir/master/Registry.html#module-using-as-a-dispatcher
4. https://hexdocs.pm/plug/readme.html#plug-router

Have you ever wanted to create a tiny little service that is just an endpoint for requests from other applications? If so, Elixir(1) and its build tool Mix(2) make it dead easy.

Assuming you’ve installed Elixir on your system, let’s fire up a new Mix application. Please Note, this tutorial was done using Elixir 1.6.5.

mix new my_micro_service

Go ahead and explore the file structure of your new mix application. As you can see it’s pretty minimal. Open up the mix.exs file that exists in the top level of the project’s directory. This file helps us configure our application, and most of your time here will be for installing the dependencies you want to add to the application. Take a look at the public application/0 and private deps/0 functions defined at the bottom of the file.

def application do
  [
    extra_applications: [:logger]
  ]
end

defp deps do
  [
    # {:dep_from_hexpm, "~> 0.3.0"},
    # {:dep_from_git, git: "https://github.com/elixir-lang/my_dep.git", tag: "0.1.0"},
  ]
end

The comments in the deps/0 function are just explaining how to install dependencies. Delete those comments and make your functions look like these:

def application do
  [
    extra_applications: [:logger, :cowboy, :plug, :poison],
    mod: {MyMicroService, []}
  ]
end

defp deps do
  [
    {:cowboy, "~> 2.4"},
    {:plug, "~> 1.6"},
    {:poison, "~> 3.1"}
  ]
end

We are going to install Cowboy(3, 4) our the HTTP server, Plug(5) an interface for handling the server, and Poison(6) our JSON parser. To install the dependencies, run the command:

mix deps.get

Now, find the my_micro_service.ex file within the lib folder. Delete the code inside the definition of the module and make it look like this:

defmodule MyMicroService do
  use Application

  def start(_type, _args) do
    children = [
      Plug.Adapters.Cowboy2.child_spec(
        scheme: :http,
        plug: MyMicroService.Router,
        options: [port: 4000]
      )
    ]

    opts = [strategy: :one_for_one, name: MyMicroService.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

There is a lot going on here and I urge you to read the documentation of supervision trees(7) in Elixir. What we’re essentially doing is starting up a supervised process that starts the HTTP server for us on port 4000.

Now, make a router.ex file in your lib directory and make it look like this:

defmodule MyMicroService.Router do
  use Plug.Router

  plug :match
  plug Plug.Parsers,
    parsers: [:json],
    pass: ["application/json"],
    json_decoder: Poison
  plug :dispatch

  get "/hello" do
    send_resp(conn, 200, "Hello World!")
  end

  match _ do
    send_resp(conn, 404, "Page Missing")
  end
end

We are creating a Plug pipeline with this module. Router(8), match, parsers, and dispatch are all plugs available from the Plug dependency. Down below we define some routes for our application to respond to. The match route might be a little confusing, but all it’s doing is catching any path that we didn’t define and then sending the user a 404.

At this point we can test these routes! Run your application with the following :

iex -S mix run

It might take a few seconds for your project to compile when it’s finished go to, http://localhost:4000/hello

You should see: “Hello World!”

Now go to a route we didn’t set. http://localhost:4000/nope

You should see: “Page Missing”

The last thing we’ll do is create and new endpoint file so we can handle our logic for our “hello” route outside of the router.ex file. Make a new api directory in the lib folder and new file in the api directory titled, hello_endpoint.ex. Make the new file look like this:

defmodule MyMicroService.API.HelloEndpoint do
  import Plug.Conn

  def show(conn) do
    send_resp(conn, 200, "Hello World!")
  end
end

Let’s adjust the router.ex file to handle our changes. Alias the API module namespace and change the get route.

defmodule MyMicroService.Router do
  use Plug.Router
  alias MyMicroService.API

  plug :match
  plug Plug.Parsers,
    parsers: [:json],
    pass: ["application/json"],
    json_decoder: Poison
  plug :dispatch

  get "/hello" do
    API.HelloEndpoint.show(conn)
  end

  match _ do
    send_resp(conn, 404, "Page Missing")
  end
end

Close your previous server with Ctrl-c Ctrl-c. Fire up a new server and see if everything is still working.

That was a very basic example of how to turn an Elixir Mix application into a fun little API micro-service. There is much more that you can do with the tools I’ve presented here. Check out the documentation and see what else you can build.

1. https://elixir-lang.org/
2. https://elixir-lang.org/getting-started/mix-otp/introduction-to-mix.html
3. https://ninenines.eu/
4. https://github.com/ninenines/cowboy
5. https://github.com/elixir-plug/plug
6. https://github.com/devinus/poison
7. https://hexdocs.pm/elixir/Supervisor.html
8. https://hexdocs.pm/plug/Plug.Router.html#content

Stimulus(1) is a new JavaScript framework from the team behind Ruby on Rails(2).

Though Stimulus will most likely be used in various Rails projects, that doesn’t mean we can’t use it in other frameworks such as Phoenix.

If you haven’t already created a new Phoenix project, go ahead and run:

mix phx.new phoenix_with_stimulus

Continue to follow the prompt; installing your dependencies, changing into the new project directory, creating your development database, and testing the local server. Notice we are using Brunch(3) as our build tool. Most people using Stimulus will probably be using Webpack(4), but Phoenix comes with Brunch by default. Let’s use what we have and continue with Brunch.

Now to install Stimulus. Change into your assets directory:

cd assets

Then install the necessary dependencies:

npm install --save stimulus
npm install --save-dev babel-plugin-transform-class-properties
npm install --save-dev babel-preset-env

We also need to edit the brunch-config.js file in the assets directory. Specifically, we are going to edit the plugins section. Make sure yours looks like this:

plugins: {
  babel: {
    // Do not use ES6 compiler in vendor code
    ignore: [/vendor/],
    presets: ["env"],
    plugins: ["transform-class-properties"]
  }
},

To test our setup I’m going to be pulling these examples almost directly from the Stimulus Handbook(5) with a few minor name changes to make things as quick as possible.

From inside the assets directory; change into the js directory, create a controllers directory, change into it, and create a pageController.js file:

cd js
mkdir controllers
cd controllers
touch pageController.js

Now, we are going to find our app.js file and make some changes. The file should be in your js directory. Add this JavaScript to the end of the file:

import { Application } from "stimulus"

import PageController from "./controllers/pageController"

const application = Application.start()
application.register("page", PageController)

Let’s edit the newly created pageController.js file by adding:

import { Controller } from "stimulus"

export default class extends Controller {
  static targets = [ "myInput" ]

  alertText() {
    const element = this.myInputTarget
    const myInput = element.value
    alert(`My ${myInput}`)
  }
}

Continue on to find and edit the index.html.eex file that should already exist within the directory structure lib/phoenix_with_stimulus_web/templates/page. Delete everything in that file and add:

<div data-controller="page">
  <input data-target="page.myInput" type="text">
  <button data-action="click->page#alertText">Click Here</button>
</div>

That’s just about it. Lets make sure we are in the top level of our project directory and then spin up our development server with:

mix phx.server

In your browser navigate to http://localhost:4000/
You should be seeing a screen like this:

Type in some input and hit “Click Here”. You should see an alert from your browser with your input!

I hope this was helpful in getting you started using Stimulus JS with Phoenix! For explanations to these code samples and more detail on Stimulus please see the official handbook(5).

1. https://stimulusjs.org/
2. https://m.signalvnoise.com/stimulus-1-0-a-modest-javascript-framework-for-the-html-you-already-have-f04307009130
3. https://brunch.io/
4. https://webpack.js.org/
5. https://stimulusjs.org/handbook/introduction