Like a lot of people, I dream of starting my own business. I actually tried it once quite recklessly and failed - learned lots of lessons but it was quite painful. So I’m taking a more planned approach instead. My decision to work as a product manager is another step in that plan. My goal here was to learn how to envision, plan, and build successful products. After a year and a half working as a PM, it would be a good idea to review what I’ve gained and what the next step would be.

More than two years have passed since I wrote my last post, and in the meantime, many have asked me when I’m writing the next one. Well, I’m finally publishing a new post with a big news. As the title says, I got a new job as a product manager as I moved to a new company.

It all began when I noticed that the Elm code snippets in my posts did not have syntax highlighting. It was easy to figure out what was going on. I had set up my blog using GitHub Pages gem, which included Jekyll and other supporting libraries. The syntax highlighting library rouge, however, was locked to version 2.2.1 that did not support Elm. Forcefully upgrading rouge might have resolved the issue, but then I thought, why not get rid of the GitHub Pages gem and upgrade all the dependencies? So began the yak shaving.

In the Elm Architecture, update function is responsible for changing Model state. Depending on how you structure your Model, Msg, and update, sometimes you may want to call update function again with another Msg after calling update function. Recursively calling update is straightforward.

I’ve been thinking about how to organize Elm’s port functions and here’s two approaches that I’ve put together. I assume that the readers know basics of Elm, including the Elm Architecture and how ports work. I put a working Elm app example in my Github repository. If you want to run it, follow this instruction to set it up:

Elm Debugger is one of the most amazing debugging tools I’ve ever used - too bad I rarely get to use it because Elm makes it so difficult to produce serious bugs. The Debugger places a limit on the length of displayable text in it, and truncates any text or data structure that might go over that limit. It’s a sensible default, but sometimes it hampers my debugging effort especially when I’m trying to see the exact message I’ve received. Here’s an example of how the it truncates messages in Richard Feldman’s RealWorld example app:

I’ve started trying out Emacs because I lost patience while trying to set up Haskell development environment in Vim. Some random person on the Internet suggested Spacemacs as an alternative, so I decided to give it a try. So far I’m liking it - it works out of box without much configuration. Unfortunately the documentation on setting up Korean language environment was a bit outdated and/or fragmented for an Emacs newbie like me to easily understand. After some researching I’ve come up with a working configuration so I’ll share it here. I’m using D2Coding font, but feel free to use whatever you like.

I’m using Ubuntu 16.04.4 and Emacs 26.1.

Once I heard someone half-jokingly say that he finds CSS harder than Haskell. At the time I just laughed at the joke, but after working with CSS for some time I now understand what he meant. CSS is complex. While it has simple syntax and structure, its output depends so much on the runtime context that it’s hard to reliably predict the result.

Three Problems

For me, three issues stood out:

1. Difficult to determine which CSS rule is finally applied
2. Difficult to know how CSS rules interact
3. Difficult to guess the runtime environment

Introduction

Last year, I learned of the Idris language and wrote a blog post after reading a book on it. Coincidentally, I joined a company that worked on blockchain technology almost immediately after publishing that post. So when I came across a paper titled “Safer smart contracts through type-driven development: Using dependent and polymorphic types for safer development of smart contracts”, which combined two topics of my interest, I just had to read it.

This post is a collection of the thoughts that came across my mind while I was reading the paper. There won’t be any new idea that builds on the contents of the paper. I assume basic understanding of functional programming paradigm, in particular the distinction between pure functions and side effects.

Summary

Once we get through the introduction to Elm, we start to encounter some odd-looking operators in Elm codes. I’m talking about the ones like >>, <<, |>, and <|, which modify how functions are composed and applied. I will give more details about how and when I use them in this post, but here’s my rule of thumb:

1. Use |> and <| to visually describe the flow of data. It’s their main advantage over nested parantheses, which provide equivalent functionalities.

2. Use >> and << to describe function compositions independent of the data flow. In practice, I usually define a new function through composition and use it with |> and <|.

3. Use either the pair of |> and >> or <| and << without mixing them. The shapes of these operators hold inherent directional meanings, so mixing different directions taxes our cognitive resources.