I’m learning Elm nowadays and I’ve been really happy that there’s finally a way to get into FP and functional programming languages from a front end person’s background.

In my exploration, mostly through random blog posts and this great Pragmatic Studio course, I’ve found one thing difficult.

These fancy pants ML-like programming languages have way too many un-googleable function names in the standard library!

I’m going to list a few of the unrecognizable ones here and give you my own name for them. Let me know more and I will add them. Bookmark this page if you ever want to be able to find out what one of these wild and crazy characters in your Elm source are really for.

1. The superplus ++ The append operator. Works for Strings, Lists and Text types.
2. The forquals /= The not equals operator.
3. The lefthat <| The backward function application operator.
4. The downflipitandreverseit or the righthat |> The forward function application operator.
5. The leftdubs << The function composition to the left operator. This is not a bitshifting operator.
6. The rightdubs >> The function composition to the right operator. This is not a bitshifting operator.
7. The cons :: The cons operator.
8. The pigsnout (..) docs The import everything from a module syntax.
9. The backticks `andThen` docs The use-as-infix syntax.
10. The silence := The JSON Decoder application operator.

What else do you find ungoogleable in Elm? I hope this helps many others on the same journey to understanding Elm.

Let’s start brushing our teeth as programmers.

We need to consistently prioritize updating our frameworks/libraries/dependencies. Having unit tests makes this much easier, but even if you don’t have them, it’s still necessary.

Don’t think about this like flossing

Brushing your teeth is something that you do extremely regularly and have built up such a habit that you can’t really imagine life without it. Flossing is a nice to have that many of us skip with impunity. It doesn’t necessarily have to be once a day, but thinking about updating on a regular, predefined basis will force you to need to consciously make the choice to disregard instead of absentmindedly forgetting.

On teams, you should make sure that there’s a recurring task/calendar event every month to ensure that your codebases are up to date. This is most important with frameworks/impactful libraries like Ember/Angular/React, but it is just as helpful for anything inside of the world of Node/Ruby/Python/Java/anything-with-dependencies.

Once you make this as much of a habit as brushing your teeth, you won’t even need to think about it because it becomes every team member’s shared expectation. Use reverse-broken-window syndrome to your advantage. If everyone is doing it, each person will keep up with the crowd.

The automated, electric toothbrushes

I still use the plain old toothbrushes that I get for free every six months from my dentist, but I know that many are bigger fans of the electric/sonic variety. Gratefully, they exist for programmers trying to keep depencenies up to date too!

1. Greenkeeper

This is a great tool by the makers of Hoodie that will automagically open PRs against your npm project when a dependency releases a new version.

1. Sibbell

This tool will send you emails whenever a dependency creates a new GitHub “Release”

1. VersionEye

For open source Node projects, VersionEye will show you which entries in your package.json are out of date

Start Now

There’s nothing stopping you from starting this practice right now. You are resourceful. You could make a slackbot for this, setup a shared calendar, or any other myriad solutions. All I can tell you is that once you do, your team will be better off.

Here’s to gingivitis free software!

Tonic is a new service/tool for web developers that I’ve been playing with for a couple of days. It’s very similar to an IPython notebook, but completely through a web interface. It’s very interactive, and allows you to fluently write, test, and play around with Node.js code. You can test things out very quickly, just like JSFiddle, JSBin, CodePen or Plunker, but it is backed by npm which makes it much nicer.

This is their marketing copy. They say that Tonic removes friction. I was very surprised by how true that was.

NPM is first class

Any require statement is automatically parsed, and the dependency is added to the implcit package.json file that backs every “Notebook”. You don’t have to fiddle around with the JSON yourself, but rather just add var request = require('request'); and you automagically have the current version of request. There’s also some special additional syntax to use in your requrie statement if you do happen to require specific versions.

Endpoints are first class

The killer feature of this tool though is not the npm integration, but rather its ability to create on the fly APIs. I’ve been looking for something like this from a lot of other tools. I have wished there was a way to create a one liner API and deploy to Heroku as an endpoint by only using the web. Until now, I haven’t had anything like that. Now, not only do I get an API in 2 clicks and 3 lines of code, but it also supports CORS!

Creating a new http endpoint is as easy as clicking on compose in gmail. Clicking on new Notebook, and then writing this code, got me a passthrough to a non CORS, but open endpoint in < 5 minutes.

No more needing to spin up node on my VPS just to CORS enable APIs!

This is basically a two liner (of not boilerplate) to get my own Duolingo profile. In case you don’t know, I’m extremely addicted to Duolingo and many of my side projects are tools to remind me to practice learning languages every day. Tonic is going to make that tool writing so much easier! I don’t need node proxies anymore, I can just build my apps in JS Bin, calling to this new Tonic-built endpoint and be done in minutes!

I’m really excited about this; I’m sure you can tell. See you in the comments!