Lunar Logic Blog

Elm Tricks from Production: From Angular v1 to Elm in 4 days

2020-01-29T00:00:00+00:00

This is part of a series of posts about Elm in production at Lunar Logic. Be sure the check the first post for more context.

You might be wondering, how the hell did they manage to migrate the entire frontend of AirCasting from Angular to Elm in 4 days? The answer is simple: we cheated. But we swear this is totally legit and we encourage people to do the same!

In a previous post we explained why and how we choose not to rewrite the entire frontend from scratch:

The best way to rewrite any application from one technology to another is incrementally, while it continues to run. At first the new language can take over separate parts of the application and then gradually incorporate more and more code.

In particular, over the last year, we have been using new features as an excuse to bring us closer to the finish line. In other words, we never stopped producing value for our customers. Also, having the removal of Angular in the back of our minds at all times, allowed us to come up with more and more tricks on how to make it happen. We actually kept a list on the wall in front of us to function as a constant reminder.

After several months of work, we realized we got close enough to remove Angular completely. That is when we took 4 days off the development of new features to complete our mission.

We are pretty sure the cost of those 4 days was worth it. In fact, it will probably be repaid in the next iteration not needing to learn Angular v1 or having to deal with its complexity.

There is still a long way in front of us. As a matter of fact, we only removed Angular by extracting code to vanilla JavaScript and kept the Elm ports. But, for sure, the future looks brighter now!

Elm Tricks from Production: Automated testing is just another tool

2019-10-17T00:00:00+00:00

This is part of a series of posts about Elm in production at Lunar Logic. Be sure the check the first post for more context.

Since Lunar Logic is the oldest Ruby shop in Poland, it’s no wonder people have been exposed extensively to Ruby and Rails. Being part of the community, we have gotten accustomed to its values. In particular, we have used automated testing a bunch. This is made easy by the gems and tools that are available in the ecosystem.

Unfortunately, when the friction of doing something approaches zero, so does employing it without questioning its costs and benefits. As a matter of fact, testing does not come for free: tests are code and as such require time to write and maintain.

We argue that automated testing is yet another tool to achieve a shorter feedback loop. But not the only one and not the right one in every possible situation. Also, tests can be used in a variety of scenarios: TDD, unit testing, property-based testing, acceptance testing, etc.

At the unit level, where we will focus our attention in this post, sometimes it’s arguable if tests are needed. That is especially true when working with a language with a sound type system like Elm.

But let’s talk with some code in front of our eyes. We will start with a stupid example just to prove the point and then move to production code from the open source Aircasting.

The first example is the sum function:

sum a b = a + b

Should we test it? Of course not! Let’s forget for a second we shouldn’t have written the function in the first place: there’s no need to redefine +. In any case, the Elm compiler applies + only to numbers. Also, the fact that + returns the correct result should be and is guaranteed by the language maintainers. Therefore, the only problems we could introduce in the sum function are using the wrong operator (e.g. -) or not using the addends properly (e.g. sum a b = a, sum a b = a + 1).

What about the following boolToString function?

boolToInt bool =
  case bool of
    True -> 1
    False -> 0

Elm enforces callers to use a Boolean for bool. That’s because the function branches on bool with True and False. This function is so simple and declarative that we wouldn’t put the effort to test. Where we could consider a test is when composing sum and boolToInt together in a more complex sumBoolsOrDefault:

sumBoolsOrDefault predicate bool1 bool2 default =
  if predicate
    then
      sum (boolToInt bool1) (boolToInt bool2)
    else
      default

Following a functional programming style the basic building blocks of a program are simple and declarative functions. Most of the times the developer and the type system are enough to guarantee the correctness. It’s when composing simple things together that testing starts paying off. But where’s the tipping point? It depends.

Let’s take an example from AirCasting. In particular, each session at the bottom of the screen shows the timeframe in which measurements were taken. For recordings spanning multiple days we want to display “mm/dd/yyyy hh:mm - mm/dd/yyyy hh:mm” otherwise “mm/dd/yyyy hh:mm - hh:mm”:

The logic resides in the Times module. Let’s follow the thinking process that brought us to the formatting code.

First of all, in AirCasting startTime and endTime for each session are Posix.

Therefore we first need to write functions to extract and format year, month, day, hour and minutes from Posix values.

For the year it’s enough to use toYear : Zone -> Posix -> Int and take the last two digits:

toYear posix =
  posix
    |> Time.toYear Time.utc
    |> String.fromInt
    |> String.right 2

For the day we can use toDay : Zone -> Posix -> Int and pad a “0” to the left if needed to have two digits, thus:

toDay posix =
  posix
    |> Time.toDay Time.utc
    |> String.fromInt
    |> String.padLeft 2 '0'

For the month we can use toMonth : Zone -> Posix -> Month and write a function to transform a Month into a string:

monthToString month =
  case month of
    Jan -> "01"
    Feb -> "02"
    Mar -> "03"
    ...

Hours and minutes follow a similar pattern:

toHour posix =
  posix
    |> Time.toHour Time.utc
    |> String.fromInt
    |> String.padLeft 2 '0'


toMinute posix =
  posix
    |> Time.toMinute Time.utc
    |> String.fromInt
    |> String.padLeft 2 '0'

Also, we need to distinguish between two posix values being on the same date or not:

areOnSameDate p1 p2 =
  toYear p1 == toYear p2 && toMonth p1 == toMonth p2 && toDay p1 == toDay p2

Should we test the functions mentioned above? In our case we haven’t done so. In fact, they are all simple and declarative building blocks. Now, let’s put everything together:

format start end =
  let
    toFullDate p =
      toMonth p ++ "/" ++ toDay p ++ "/" ++ toYear p ++ " " ++ toTime p
    in
      toFullDate start
        ++ (if areOnSameDate start end
          then
            "-" ++ toTime end
          else
            " - " ++ toFullDate end
          )

We used types to drive the development and the format function is where we decided to test. That’s because the function is “complex” enough to necessitate test coverage.

What defines “complex” is hard to say. But I can steal some wisdom out of an Elm discourse thread:

it’s hard to predict;
tricky code;
I fear or I know I will fear of changing some functions;
encoders / decoders;
sequence of actions for data;
logic that can’t easily be encoded in the type system;
correctness in very important parts.

Be sure to read the thread mentioned above because it’s full of great stuff. Thanks a lot to all the people who have participated and shared so much there!

Special thanks to Rafał for proofreading this post.

Elm Tricks from Production: Adding event listeners to DOM nodes that do not yet exist

2019-10-04T00:00:00+00:00

This is part of a series of posts about Elm in production at Lunar Logic. Be sure the check the first post for more context.

There are some situations where it is required to attach a callback to a DOM node which does not yet exist. There are multiple solutions to this problem. In this post we will talk about the two we employed in AirCasting.

If the DOM node is supposed to be rendered soon after the web page is loaded, it is possible to “loop” until the element appears. For example, AirCasting allows users to modify the to colour code thresholds of measurements shown on the map by interacting with the slider at the bottom of the page (aka Heatmap):

Notice that the slider has multiple handles, to make this happen we use the “noUiSlider” library. The section of the page where the slider should be mounted is rendered by Elm. This is a problem because the JavaScript code that initializes Elm is the same that bootstraps the Heatmap slider. We solved that problem by using a setTimeout to wait for the slider container to appear in the DOM:

const setupHeatMap = () => {
  const node = document.getElementById("heatmap");
  if (!node) {
    setTimeout(setupHeatMap, 100);
  } else {
    // setup heatmap
  }
}

In some cases the DOM node we want to append a callback to appears as a result of a user interaction. In this instance, it doesn’t make sense to use setTimeout. In fact, there’s a chance that the interaction would happen much later or never. Not to mention the fact that the DOM element could appear and disappear multiple times.

Luckily, we can use the “Mutation Observer” API:

The MutationObserver interface provides the ability to watch for changes being made to the DOM tree.

In AirCasting we use the MutationObserver to enable users to scroll the sessions list horizontally when scrolling vertically with a mouse wheel.

We could not use the setTimeout strategy because the sessions list disappears whenever a session is selected. Also, if a user opened the application using a link to a selected session, the setTimeout would keep looping until the session was deselected.

For the reasons mentioned above, we decided to use the DOM Mutation Observer API via a wrapper written by pablen. The gist provides the code and an example of how to use it.

In our case, we want to setup the scroll behaviour as soon as the sessions list appears on the screen:

const setupHorizontalWheelScroll = node => {
  // …
};

createObserver({
  selector: ".session-cards-container",
  onMount: setupHorizontalWheelScroll
});

Notice that we keep adding the callback whenever .session-cards-container appears. We don’t need to unregister the callback since the DOM node is discarded whenever a session is selected and the container disappears.

Elm Tricks from Production: declarative, bug-free user interfaces with custom types

2019-09-26T00:00:00+00:00

This is part of a series of posts about Elm in production at Lunar Logic. Be sure the check the first post for more context.

There are 4 possible statuses when it comes to fetching data in a frontend application:

before fetching
while fetching
successful fetch
failed fetch

In JavaScript it’s easy to either forget handling some statuses or to declare cleanly what to render on screen for each status. This opens the gates to a lot of bugs. Ever been on a page with a spinner that never disappears?

Elm solves both the problems defined above in perfect functional-programming style, adding a type. In particular, let’s say we want to create a new cool webapp. It will show a random number every time the page is refreshed, cool right?! We can use a public API to fetch the random number. Also, we need to choose a type, let’s go with Int. Unfortunately, the random number API is really slow so we need to show a message while fetching. We could use 0 to mark the fact that we still don’t have the random number:

case number of
  0 -> Html.text "Loading..."
  i -> Html.text ("The random number is: " ++ String.fromInt i)

But this is not a good solution: if the API returns 0 as a random number we will be showing the loading message forever! Let’s try with Maybe Int:

case maybeNumber of
  Nothing -> Html.text "Loading..."
  Just i  -> Html.text ("The random number is: " ++ String.fromInt i)

Cool, now we can distinguish between not having the number or having it. What if we got an error though? Let’s add a flag for that:

case (maybeNumber, hasFailed) of
  (Nothing, False) -> Html.text "Loading..."
  (Just i, False)  -> Html.text ("The random number is: " ++ String.fromInt i) 
  (Nothing, True)  -> Html.text "Could not fetch random number" 
  (Just i, True)   -> WTH??

Problem is there’s a combination that does not make sense at all (i.e. (Just i, True)): we fetched a number but there’s an error. Custom type to the rescue:

type RemoteData
  = Loading
  | Success Int
  | Failure

case remoteDataNumber of
  Loading   -> Html.text "Loading..."
  Success i -> Html.text ("The random number is: " ++ String.fromInt i) 
  Failure   -> Html.text "Could not fetch random number"

Now, let’s say that instead of loading the random number every time the page is refreshed, we want to start fetching as soon as a button is clicked:

type RemoteData
  = NotAsked
  | Loading
  | Success Int
  | Failure

case remoteDataNumber of
  NotAsked  -> Html.text "Click the button!"
  Loading   -> Html.text "Loading..."
  Success i -> Html.text ("The random number is: " ++ String.fromInt i) 
  Failure -> Html.text "Could not fetch random number"

The beauty of this solution is that, as soon as we declare our random number to be of RemoteData type, the Elm compiler will enforce checking all the branches. Also, it’s really easy to see what the app is doing depending on the status of the request.

AirCasting uses the pattern shown above extensively. In particular, to avoid reinventing the wheel we used RemoteData. One example is the function that takes care of rendering either the sessions list or the selected session at the bottom of the map page:

viewSessionsOrSelectedSession selectedSession =
        div []
            [ case selectedSession of
                NotAsked ->
                    viewSessions

                Success session ->
                    viewSelectedSession (Just session)

                Loading ->
                    viewSelectedSession Nothing

                Failure _ ->
                    div [] [ text "error!" ]
            ]

In other words, if the request for the selected session is not ongoing, show all the sessions. If the selected session is loading show its view while waiting for the data to come. If the request was successful show the selected session view for it. If the request failed show the error message.

If you are not using Elm you can still apply the pattern successfully. Unfortunately, there won’t be a nice compiler helping guaranteeing an error free application 😉.

Elm Tricks from Production: Migrating from Angular v1 to Elm

2019-08-29T00:00:00+00:00

This is part of a series of posts about Elm in production at Lunar Logic. Be sure the check the first post for more context.

Intro

The previous post left us hanging with a cliffhanger:

Being a seven-year-old product, it had accumulated some rust. In fact, AirCasting has been using the first version of Angular since inception. Unfortunately, using an outdated web framework from 2010 makes work cumbersome and slow. That translates into higher costs, many bugs and a lot of frustration.

Gladly, this last iteration was about revamping the entire user interface: the perfect excuse to introduce a new technology, cut costs and improve the product.

In fact, the post mentions the introduction of Elm but never explains the how.

Migrating from Angular v1 to Elm

The best way to rewrite any application from one technology to another is incrementally, while it continues to run. At first the new language can take over separate parts of the application and then gradually incorporate more and more code. Compared to a full blown rewrite, small increments enable:

using the old code until it’s rewritten;
using the old logic as guidance to drive the new one;
being able to build new features while working on the migration;
being able to stop at any time.

That’s why the team used the following plan to migrate from Angular v1 to Elm:

create the smallest possible proof of concept to make sure Elm is a good fit;
embed multiple Elm applications inside Angular;
merge the previous multiple Elm applications into one with the remaining Angular mounted on top;
move more and more Angular to Elm when a good excuse presents itself.

The smallest possible proof of concept in Elm

Despite having experience in Elm, we didn’t want to jump in the dark. Therefore, we decided to build a super tiny proof of concept. In other words, we found the smallest possible “component” that could be rewritten in Elm. Doing that we:

learnt how to embed an Elm application into an Angular one;
made sure the whole team was ready to commit to Elm;
reassured ourselves that small iterations were possible.

In the end, we selected the sessions list to become the first functionality to be rewritten in Elm. The sessions list is the place where the user can select which stream of health and environmental data to visualize in detail:

Commit 4cff375d6b9d83ab58ff16bd69b8069c27eb51d1 is where the magic happened. In particular, we first replace the list with an empty div:

-      <ul>
-        <li ng:repeat="session in sessionsForList" ng-class="sessionCssClass(session.$selected)">
-          <input type="checkbox" collection-condition="canSelectSession(session.id)" collection="selectedSessionIds" collection-id="session.id" ng-model="session.$selected" ng-disabled="isSessionDisabled(session.id)">
-          <dl ng-click="toggleSession(session.id, false)">
-            <dt><label class="narrow"></label></dt>
-            <dd>
-              <label class="narrow">
-                ,
-                
-                <span ng-class="shortTypeCss(shortType.type, session.$selected)" ng-repeat="shortType in session.shortTypes"><span ng-hide="$index==session.shortTypes.length-1">/</span></span>
-              </label>
-            </dd>
-          </dl>
-        </li>
-
-        <li ng-show = "sessionsCount === 50 || sessionsCount === 100">
-          <button ng-click="updateSessionsPage()">Load More...</button>
-        </li>
-
-      </ul>
+      <div id="sessions-bottom-elm"></div>

Then inside the Angular controller that oversees the sessions list (i.e. SessionsListCtrl) we initialize the Elm application on the empty div:

+    angular.element(document).ready(() => {
+      const node = document.getElementById('sessions-bottom-elm');
+      const flags = $scope.sessions.get().map(formatSessionForList).map(formatSessionForElm);
+      elmApp = Elm.SessionsList.init({ node, flags });
+
+      elmApp.ports.checkedSession.subscribe(({ selected, deselected }) => {
+        if (deselected) $scope.toggleSession(deselected, true);
+        if (selected) $scope.toggleSession(selected, true);
+        $scope.$apply();
+      });
+
+      elmApp.ports.loadMoreSessions.subscribe(() => {
+        $scope.updateSessionsPage();
+        $scope.$apply();
+      });
+    });

In more detail:

the angular.element(document).ready() is needed to wait for the DOM to be safe to manipulate;
the sessions are still managed by Angular, Elm just displays them; that’s why they are formatted and passed as “flags” (initial values) to the Elm application;
since each session in Elm can be selected, we subscribe to the checkedSession port. That way, Elm can communicate to JavaScript that a session was selected / deselected which in turns delegates to Angular with $scope.toggleSession();
the sessions list is paginated therefore we need to subscribe to loadMoreSessions.

Whenever the user tweaks the search parameters, the sessions list needs to be updated with the sessions matching the new criteria. Angular listens to that by using a $watch. Therefore, we just add a line inside the callback to pass the sessions to display to Elm:

   $scope.$watch("newSessionsForList()", function(newSessions, oldSessions) {
     console.log("newSessionsForList()", newSessions, oldSessions);
     $scope.sessionsForList = newSessions;
+    if (elmApp) elmApp.ports.updateSessions.send(newSessions.map(formatSessionForElm));
   }, true);

The Elm application for the sessions list is straightforward.

That’s it! Elm is initialized by the Angular controller and via ports it communicates in and out.

Multiple Elm applications inside Angular

Elm supports compiling multiple Elm applications at once:

➜  AirCasting git:(master) elm make --help
The `make` command compiles Elm code into JS or HTML:

    elm make <zero-or-more-elm-files>

When using Webpack and Elm loader, it’s enough to pass an array of files in the configuration.

That is exactly what we used to inject other Elm applications inside different Angular controllers. In fact, after taking care of the sessions list, we moved to the filters:

One of the first filters we moved was the Crowd Map. The feature is well described in the tooltip:

The CrowdMap averages together all the measurements from all the sessions listed on the sessions list and displays these averages as colored grid cells. The color of each grid cell corresponds to the average intensity of all the measurements recorded in that area. Click on a grid cell to view the underlying data.

The first step was to replace the Crowd Map controls with an empty div:

-          <div class="textfield">
-            <p>
-              <input type="checkbox" ng-model="storage.data.crowdMap" id="checkbox-crowd-map">
-              <label for="checkbox-crowd-map">Crowd Map</label>
-            </p>
-          </div>
-          <div>
-            <div class="slider full-slider">
-              <p>Resolution</p>
-              <div slider slider-max="maxResolution" slider-min="minResolution" slider-value="storage.data.gridResolution" slider-onslide="storageEvents.onResolutionSlide" ></div>
-              <span></span>
-            </div>
-          </div>
-          <div>
-            <ul class="buttons">
-              <li><button ng-click="storage.resetCrowdMapLayer()">reset</button></li>
-              <li><button ng-click="storage.updateCrowdMapLayer()">submit</button></li>
-            </ul>
-          </div>
+          <div id="crowdMapLayer"></div>

Then inside the Angular controller that oversees the filters (i.e. MobileSessionsMapCtrl) we initialize the Elm application on the empty div

if (process.env.NODE_ENV !== "test") {
  angular.element(document).ready(function() {
    const node = document.getElementById("crowdMapLayer");

    const flags = {
      isCrowdMapOn: $scope.params.get("data").crowdMap || false,
      crowdMapResolution: $scope.params.get("data").gridResolution || 25
    };

    const elmApp = Elm.Main.init({ node: node, flags: flags });

    elmApp.ports.toggleCrowdMap.subscribe(() => {
      storage.toggleCrowdMapData();
      $scope.sessions.fetch();
    });

    elmApp.ports.updateResolutionPort.subscribe(newResolution => {
      storage.updateCrowdMapResolution(newResolution);
      sessionsUtils.updateCrowdMapLayer($scope.sessions.allSessionIds());
    });
  });
}

Whenever the checkbox to enable / disable the Crowd Map changes, the subscriber to the toggleCrowdMap port is notified. Also, whenever the slider is moved by the user, the callback registered to the updateResolutionPort port is invoked.

And again, the rest is straightforward Elm! See the commit d9c2f60280013e399187586dd8b77b3330bfe9fa for more details.

This is the exact same strategy we employed to build the proof of concept. And the same one we repeated for other filters:

Tags;
Profiles;
…

Merge Elm Applications into One

Eventually, we got to the point where the Elm applications needed to communicate among themselves. That is where we decided to go from a single Angular application with multiple Elm applications on top to a single Elm application with some Angular sprinkled on top. Commit bbb7a7c74a02e56971f680704058609b6f6c8496 is where it all happened.

First of all, we created a JavaScript pack to initialize the single Elm application:

import { Elm } from "../elm/src/Main.elm";
import { buildAvailableParameters } from "../angular/code/services/_sensors";

document.addEventListener("DOMContentLoaded", () => {
  //...

  window.__elmApp = Elm.Main.init({ flags });
});

Notice we decided to easen the migration by putting the Elm application on the window object. That way Angular components can access the Elm ports easily. The Main.elm entrypoint contains all the Elm code that was previously scattered among multiple ones. That is clear if we take a look at the diff on the Elm loader config:

   files: [
-    resolve(__dirname, "../../../app/javascript/elm/src/MobileSessionsFilters.elm"),
-    resolve(__dirname, "../../../app/javascript/elm/src/FixedSessionFilters.elm"),
-    resolve(__dirname, "../../../app/javascript/elm/src/SessionsList.elm")
+    resolve(__dirname, "../../../app/javascript/elm/src/Main.elm"),
   ]

To initialize the Angular stuff we wait until a div with id elm-app is on the DOM:

const initAngular = () => {
  if (!document.getElementById("elm-app")) return setTimeout(initAngular, 100);

  // ... init Angular
};

initAngular();

That works because the root div rendered by Elm has exactly that id.

Migrating the remaining parts

Now that we have only one Elm application, the only thing to do is keep up the momentum. In other words, make good use of the re-writing opportunities offered by new work on the application.

Managing tags in Jekyll blog easily

2019-08-20T00:00:00+00:00

To categorize your posts in Jekyll you can use categories, tags or both of them. In our blog, we did the latter, but it was a bit chaotic. I decided to clean this up, get rid of categories completely and use tags in a more convenient way.

My goal was to:

make it easy to assign tags to posts
display tags in post details
be able to click any of them and see all posts with this tag
display a list of all tags used in the blog

In theory, all of it is pretty easy to do.

To assign tags to a post, just put their names, space separated (or as a YAML array if you prefer this way), in the front matter:

tags: tech jekyll blog ruby
---

To display them, just use post.tags variable:

{% for tag in post.tags %}
  {% assign tag_slug = tag | slugify: "raw" %}
  <a class="tag-link"
    href={{ site.baseurl | append: "/tags/" | append: tag_slug | append: "/" }}
    rel="category tag">
    #{{ tag }}
  </a>
{% endfor %}

To create a tag page, which will display all posts with this tag, add tags collection in the _config.yml:

collections:
  tags:
    output: true
    permalink: tags/:path/

and add a layout:

---
layout: default
---

<div class="snippets">
  <h1 class="snippets-heading">Articles tagged with "{{ page.tag-name }}"</h1>

  {% for post in site.posts %}
    {% if post.tags contains page.tag-name %}
      {% include snippet.html %}
    {% endif %}
  {% endfor %}
</div>

This assumes that you have _tags directory and files for every tag you want to use there (e.g. jekyll.md) with following content:

tag-name: jekyll
---

Maybe it’s easy, but not really convenient - I wanted to be able just to add a tag to the front matter and have it working already, without a need to add an additional file to the _tags directory.

I discovered that there is a mechanism called hooks which I can use to achieve this goal.

I’ve written this simple hook which you can place in the _plugins directory:

Jekyll::Hooks.register :posts, :post_write do |post|
  all_existing_tags = Dir.entries("_tags")
    .map { |t| t.match(/(.*).md/) }
    .compact.map { |m| m[1] }

  tags = post['tags'].reject { |t| t.empty? }
  tags.each do |tag|
    generate_tag_file(tag) if !all_existing_tags.include?(tag)
  end
end

def generate_tag_file(tag)
  File.open("_tags/#{tag}.md", "wb") do |file|
    file << "---\ntag-name: #{tag}\n---\n"
  end
end

And voila! - I don’t need to bother to create tag files manually anymore!

The last thing then - I wanted to display all the tags used in the blog. I could easily display all the tags - using site.tags variable - but I didn’t want to include tags that were used in the past, but are not assigned to any post right now. Also, I thought it would be nice to display post count for each tag.

It turned out that you can write a simple plugin for that:

module AllTagsFilter
  include Liquid::StandardFilters

  def all_tags(posts)
    counts = {}

    posts.each do |post|
      post['tags'].each do |tag|
        if counts[tag]
          counts[tag] += 1
        else
          counts[tag] = 1
        end
      end
    end

    tags = counts.keys
    tags.reject { |t| t.empty? }
      .map { |tag| { 'name' => tag, 'count' => counts[tag] } }
      .sort { |tag1, tag2| tag2['count'] <=> tag1['count'] }
  end
end

Liquid::Template.register_filter(AllTagsFilter)

And use it like that in a template:

<div class="all-tags">
  All tags:
  <ul>
    {% assign tags = site.posts | all_tags %}
    {% for tag in tags %}
      {% assign tag_slug = tag['name'] | slugify: "raw" %}
      <li>
        <a class="tag-link"
          href={{ site.baseurl | append: "/tags/" | append: tag_slug | append: "/" }}
          rel="category tag">
          #{{ tag['name'] }} ({{ tag['count'] }})
        </a>
      </li>
    {% endfor %}
  </ul>
</div>

That’s it! I hope you find it useful.

Elm Tricks from Production: Intro

2019-07-16T00:00:00+00:00

We are happy to announce the release of a new version of AirCasting!

This is exciting for us because the application not only has a new look and many new features. There’s also been a lot of work on the infrastructure, performance and technology.

Being a seven-year-old product, it had accumulated some rust. In fact, AirCasting has been using the first version of Angular since inception. Unfortunately, using an outdated web framework from 2010 makes work cumbersome and slow. That translates into higher costs, many bugs and a lot of frustration.

Gladly, this last iteration was about revamping the entire user interface: the perfect excuse to introduce a new technology, cut costs and improve the product.

At Lunar Logic we have our group of functional programming aficionados: we have used Elm, “a delightful language for reliable webapps”, in the past and decided to do the same for AirCasting. Our experience has confirmed once again how great of a technology Elm is. In particular, in the last few months of use we have noticed:

A dramatic decrease of bugs: the Elm type system prevents invalid states and catches a lot of problems in development, way before the code gets to production.
Changing code is like a walk in the park: in Elm we say “if it compiles, it works”. That means once the program is written and it works as expected, it’s really easy to modify or add new features.
It’s a joy to work with: developers have a great time working with Elm, users enjoy error-free applications and stakeholders can build features fast and effortlessly.

In other words, Elm enables fast iterations, cutting costs and keeping everybody happy. But don’t take our word for it, this is a testimonial by Michael Heimbinder, Founder & Executive Director of HabitatMap (AirCasting):

Moving AirCasting from Angular to Elm has simplified the process of developing new features and identifying and zapping bugs. The comparative ease of working in Elm makes for better communication between members of the development team, which results in better code in less time

The Elm community is not as mainstream as React’s and Angular’s. Therefore, the ecosystem is smaller and fewer developers are up-to-speed with the technology. We argue that it doesn’t really matter how big an ecosystem is, as long as it’s big enough. When it comes to programmers, we expect to attract the people who became dissatisfied with traditional approaches and challenged the status quo. At NoRedInk that is already reality:

Elm is the #1 reason developers apply

Since AirCasting is powered mostly by Elm now, we have decided to publish an “Elm Tricks from Production” blog series. So fasten your seatbelt and get ready to see:

why Elm is the best;
why AirCasting is cool;
real Elm code from production;
what concepts Elm entails that could be applied in other languages / frameworks.

Truth Doesn’t Sell Well

2019-05-21T00:00:00+00:00

One aspect of being a part of a radically self-organizing company is that we often openly discuss and challenge how we do things. A discussion that received more attention recently was one about sales. I’ve been involved in sales at Lunar for six and a half years. What’s more, for the better part of my career I’ve been indirectly or directly involved in the sales process with customers ranging from early-stage startups to major banks and mobile network operators (and anything in between). It’s no wonder I occasionally get summoned to share my experience on the topic.

There are a few recurring themes in our discussions, but there is one that is especially relevant for Lunar Logic: how to balance what we believe is true with what a customer wants to hear.

What Experience Teaches You

Let me set the stage for this thread. We take our shared values seriously. When we say we are open and transparent we don’t limit it to the internal context only. We behave in the very same manner when we are in front of a customer. Or a potential customer. It has been a cornerstone of how we communicated during the sales process for years. If something is unlikely to happen, we’ll say so. If something doesn’t make sense, we’ll let you know. If we don’t want to or don’t feel competent to do something, we’d be completely clear about that.

Throughout Lunar Logic’s almost 15 years on the market, we’ve been involved in more than 150 projects. We’ve seen a lot. We’ve seen good choices, bad choices, risks that tend to pay off, those that don’t, well-designed experiments, and pretty bad ones. We’ve seen how very, very few plans end up turning out, well, as planned. Most of all, we’ve seen lots and lots of work, done and paid, that shouldn’t have been done in the first place.

Early-stage startups constitute a prominent part of our potential customer pool. Typically, they do have some funds, an idea, and most frequently a strong opinion on how to proceed. They are looking for a software development partner who will turn the idea into a product within the budget they have available. What they primarily want to hear is that it is possible. Further on, they want to confirm that the price they’ll need to pay is modest and well within the range of their available capabilities.

A side note: a host of our customers that are not early-stage startups choose their software development partner similarly, except they use a narrower scope – a part of their existing product or a small project – to make an assessment.

Mixed Blessing of Transparency

That’s where the issue emerges. On the one hand, we have a potential customer with expectations that whatever they thought of is possible within the constraints they face. On the other, we are painfully aware that it is unlikely going to fly. We see unvalidated assumptions that require validation before it makes sense to make a more significant commitment. We see common product mistakes that burn the budget without providing much value. We see an overly optimistic stance toward estimating the effort needed to build the whole thing. What the customer optimistically expects and what our experience suggests can’t easily be merged.

We have a choice there. We can tell the customer what they want to hear. The price, however, is compromising our shared values, especially transparency and trust. That’s one thing we don’t want to do. The other option is telling the truth the way we see it. This way we live up to our values. Such a choice, unfortunately, means that the customer hears things they don’t want to hear.

Let me give you just a few examples. If the client wants to get what they expect and at a good quality it will cost more than they assume. If they freeze both the scope and the budget they will pay with cutting corners on quality, future rework, and maintainability. More importantly still, most of what the customer thinks they do need they do not. There are, on the other hand, crucial things that they do need to succeed but no one is yet aware of these features.

We could pretend that we are aware of neither of these. We could cash on a customer’s dreams before they understand that what they are asking for won’t give them the outcome they hope for. We could manage the inevitable disappointment through making sure we “did what was explicitly expected of us.”

We choose differently. We decide to be honest about the journey we plan to embark on with the potential customer. And that’s where the problem is.

Truth Doesn’t Sell Well

Telling the truth, heck, selling the truth, is a tough job. It’s like telling a car buyer that ten thousand bucks they have won’t be remotely enough for a luxury car they dream of and, by the way, they likely don’t need a car at all.

No matter how you phrase the message, in the vast majority of cases, a customer will walk away. They will find someone willing to give them what they want. The customer won’t need to look too far away. Sure, such a seller would forget to tell how old the car is, and that it instantly requires further investments even to keep it operational, and that the maintenance cost will go through the roof very soon. But hey, no one explicitly said it was supposed to be a new car; don’t blame the seller for delivering what the customer asked for.

Now, the curious part. The argument presented like that stands its ground. Quite often when we share it with a prospective customer, they’d nod in agreement. They’d go with us through a Discovery Workshop, where we explore the business context, key assumptions, analyze competitors, and so on. They’d attentively listen when we argue that the original scope is overinflated, highly speculative, and not validated in any way by future users. They’d seem to understand that it doesn’t make sense to make a significant commitment on an uncertain idea. They’d even agree that neither they can afford to build everything nor does it make any sense.

And then, almost inevitably, they will choose a company that provides an attractive quote on the scope they initially planned. Oh, and they would likely praise us for our professional and mature approach when discussing the product idea too.

A sensible argument is not a match to a promise of fulfilling dreams.

Unpleasant Truth

In the world of software product development, an honest message is rarely welcomed. Because we deal with an intangible product, we expect it to be quick and easy to build. Because the industry is truly global, it is possible to find a company that would do precisely what anyone expects within almost any set of constraints. Because we notice the immense success of the startup scene and staggering stories of a host of software companies, we massively inflate our hopes for the success of almost any software product born in our brain.

The truth is nothing like that. Out of more than 150 projects that we built or contributed to a significant majority is dead by now. Many of the surviving ones never made a good return on the investment. Several turned into a lifestyle business sustaining a couple of founders and little more. A few achieved real commercial success. Neither has become another Twitter or Facebook or anything remotely close.

When I shared this post with my colleagues I received feedback that the previous paragraph may sound discouraging, off-putting even. I believe it is the opposite. When you look at the statistics you will find that at least 9 out of 10 startups fail. That’s the industry benchmark. In these unfavorable conditions, we do better than average.

An explanation may be that our approach to the sales process likely discourages quite a lot of potential clients with unsustainable ideas; thus I’d expect our results to be favorably skewed. Honesty and candor in communication is an integral part of this story.

We all are a subject of the illusory superiority bias. It doesn’t matter whether we evaluate our driving skills, our performance, or the quality of our idea. We tend to overestimate our qualities and abilities. What follows is that we don’t want to hear the truth, let alone act on it. It’s unpleasant.

And yet, to improve our chances of success, that’s precisely what we need to do.

If you are evaluating Lunar Logic as a potential software development partner for your product or project now you know our motivations. You understand what you can expect of us and why we may be reluctant to give you what you ask us for. It’s neither the most natural nor the easiest path to follow, but these are the standards we aspire to. We believe that this brings both our clients and us closer to sustainable success.

Economic Value of Craftsmanship

2019-04-29T00:00:00+00:00

Lunar Logic turns 15 this year. It’s quite a spell in this line of business. If you look at such a time frame you can safely assume that throughout the time the company has changed significantly.

It’s the people who define what the organizational culture, and thus the company identity, is. From that perspective, it’s enough to look at how the Lunar lineup has changed to figure how much we evolved. Let’s just say that with an exception of Ewelina—our office manager—and Paul—the founder—there’s no one who has seen the whole history of the company. We have changed.

And yet there’s one trait that remained consistent throughout all these years. Craftsmanship. It would characterize Lunar Logic A.D. 2005. It would be the same at the time when I joined in 2012. It would be no different today.

Craftsmanship

I explain craftsmanship as an aspiration to take pride in the quality of the work we do and continuously getting better at what we do. A tongue in cheek validation of whether we are craftspeople is as follows: if we don’t hate the outputs of our work from a year ago, be it code, designs, or processes, we don’t learn fast enough.

I like this way of framing craftsmanship because it is generic. It doesn’t boil down to a notion of software craftsmanship, which was popularized throughout the last several years in the industry. I can perceive myself as a craftsperson as much as our software developers can.

It would be interesting to analyze why, despite some major events and changes, craftsmanship remained a shared value at Lunar Logic. It is, however, another story. For this one, it is enough to stress how important craftsmanship is for us right now.

Does it mean that we would always aspire to achieve the best quality the way we understand it at any given moment? After all, that’s what you could translate craftsmanship into. The answer is no. In other words, despite our aspiration, we would sometimes compromise on our quality standards. Why?

Quality as an Investment

Let’s start with the assumption that embracing craftsmanship as an attitude translates into quality. Quality is an investment. It’s one side of a trade-off. The other side of it is time and effort. In other words, money. This investment is of diminishing returns. It means that the initial investment of some time and effort into quality will yield a better outcome than the following one that required similar time and effort. And that investment would bring a better outcome than another similar one.

In reverse, each similar increment in quality requires more time and effort, thus it costs more.

Couple that observation with a definition of craftsmanship I offered at the beginning. It says that we continuously learn more, which means that our understanding of good quality gets deeper. Simultaneously, we aspire to produce quality work we are proud of. Over time, it would mean that we want our work to be of higher and higher quality. What follows is that we would introduce more cost.

The additional cost, to some extent, is offset with the gains we get from good quality work. If a product is buggy and unusable the cost investment in better quality would easily be compensated by additional value created by simply removing obstacles that prevent customers from using the product effectively. However, the better the product the smaller improvement of the value.

At some point, another investment in quality improvement would cost more than it would deliver value. By that time, further investment in quality isn’t economically sound anymore. And yet, being craftspeople, we want to move the quality needle indefinitely. Inevitably we are bound to reach the point where our craftsmanship can’t be economically justified anymore.

Too Much Craftsmanship?

That’s probably the most important lesson of our craftsmanship journey. When we build a product for a customer, we set craftsmanship in the economic context. How much quality can be justified in a given situation?

The answer almost never is “as much as possible”. We work extensively with early-stage startups. In such scenarios, the key value we can provide is an opportunity to validate, or more likely invalidate the idea. There’s obviously some level of quality that is required for people to try a product so that they can provide meaningful feedback. How much more effort invested in high quality can be rationally justified, though?

It is a rare case that very high technical standards are a prerequisite to validating the product market fit. It would be true for scaling. It would be true for rapid and continuous development. It wouldn’t be so when the goal is to put the product out there for early adopters to try it and share their feedback.

Craftsmanship as Economical Trade-off

This means that, more often than not, we constrain ourselves in our pursuit of craftsmanship when we are working on commercial gigs. We would go only as far as we can economically justify to our clients.

By the way, it is different when we do some work internally, e.g. when working on internal projects during slack time. We often use these opportunities to hone our skills, thus attempt to deliver the best possible quality. In such a case the goal is not the product but the learning process thus the economic equation is completely different. It does, however, give us a good understanding of the cost side of pursuing very high standards of quality. Through that, we make better decisions when working with our clients.

One thing remains the same, though. If we decide to look at such code or design in a year from now we’ll hate it. After all, that’s what craftsmanship is all about.

Radical Transparency and Trust

2019-02-27T00:00:00+00:00

When I describe Lunar Logic as a company I inevitably mention transparency. Transparency is built into everything we’re doing.

There are no proxies that would isolate our customers from the team. No project managers who would relay information back and forth. No filter that would make sure that outgoing communication is “proper”.

We want to have our team in front of the customer every day on a video call. And vice versa. It’s not just a nice-to-have. It is our expectation. The practice comes from an Agile technique—standups. Yet we are far from rigid followership of the practice. The goal for us is to have frequent opportunity to validate our work. We want to share what we’re doing, our obstacles and questions. We want to understand whether the outcome of our work responds to the needs of the product. We want to validate whether we’re making good progress. We want to learn about any open issues on our client’s end.

Transparency in Action

We are transparent. Sometimes brutally transparent. It’s not unusual that our developers would share their very critical opinion about the idea of a feature or a choice of a technical solution. Don’t get me wrong. They wouldn’t refuse to go with the decision they believe is suboptimal. However, they wouldn’t hesitate to share a contrary point of view so that the eventual decision is made in presence of all the available options.

A similar attitude is seen in our technical processes. The code repository is always accessible to our customers. We push code into it as frequently as reasonably possible. Any progress that we’re making is instantly visible.

Same is true for working features of a product. In fact, one of the very first things that we do in a new project is to set up a demo server where we upload new features. This way a client who isn’t necessarily tech savvy would still see progress in an almost instantaneous manner. Not only that, though; they’d be able to validate whether working features are actually what they want.

Feedback

We all crave for feedback. Team members would regularly go out and ask our customers whether they have any feedback, especially critical, for them. Sharing critique is fine. Not sharing feedback at all, when one has some, is not. On occasions, we end up working for a client who, only after the collaboration is finished, mentions some source of dissatisfaction and, without a miss, it leaves us puzzled. Why didn’t they share it when it was happening?

By the way, feedback is a two-way street. If we find something we want to share we will. From time to time, one of our team members would end up labeled “a troublemaker”. It can be in a form “oh, we love her technical skills but she just keeps questioning our planning and estimation practices” or a similar one.

We are very open and honest with business discussions as well. When we are down to negotiating our rates I’m always happy to explain our constraints. It is then clear where there is a space to change something and where the change is highly unlikely to happen. One could say that it’s inviting our clients to exploit us and thus make us sign worse deals than we could have otherwise. I look at it differently. I perceive it as living by our standards with transparency occupying a prominent place on that list.

Why So Serious?

By now you probably figured that transparency is an element of any work that we’re doing from technical work to business negotiations. Why so serious, you may ask.

The answer is straightforward. No business relationship, any relationship really but let’s stick to business here, would last unless we can build trust eventually. I acknowledge that during an intro call with a potential customer we can’t assume trust between parties. Ultimately, we see and hear each other for the first time in our lives. And yet we either aspire to build mutual trust fast or prefer part our ways soon.

Trustless collaboration is tiring and taxing for both parties. Simply put, we don’t want to pay that tax. We prefer to terminate a relationship in which we don’t feel trusted or can’t trust a client. It holds true even if from a technical perspective everything is going just fine. It happened in the past.

Now, I don’t know any better catalyst of trust than transparency and candor.

That’s why transparency is one of the pillars of our organizational culture and the part our value proposition for the clients.

Radically Transparent Organization

There’s an interesting follow-up to the story so far. While it may sound appealing it stands true only as long as everyone at Lunar acts in the way described above. So how do I know that all Lunar folks would be transparent every day in front of our customers?

The answer is, again, hidden in how we operate internally at Lunar Logic. There’s not a single bit of information that would be a secret for anyone at the company. That includes all the financials and, of course, salaries.

In all the stuff that we do we consider transparency as a crucial aspect. A phrase “I’m sharing it for the sake of transparency” is often used. Especially when someone is not sure whether something would be of interest of others. In such situations, we simply prefer to be on the safe side, i.e. be transparent.

Like many things, it goes both ways. On one hand, our default way of acting is being transparent, on the other everyone can be expected to openly share their course of actions and reasoning behind. Openness and transparency aren’t purely an opt-in mechanism. Should one attempt to avoid it there would be peer pressure to counter such behaviors.

This means that being transparent not only is the easiest way to thrive at Lunar; it is the only way.

Shared Value

Since candor and transparency are so ubiquitous they become our nature. Thus it is obvious that when in front of our customers, we would behave likewise.

The following is the excerpt from our wiki page about making decisions.

We are a small company and few things are formalized so it happens every now and then that we encounter a new situation where there isn’t a standard way of doing things. Here’s a short guideline that should help on such occasions. Whenever you don’t know how to tackle the situation remember three things:

We want to keep our clients happy so answering the question “what would delight the client?” will give you a good idea how to act. Of course, it also means that we don’t want to make one client happy at the expense of another client’s dissatisfaction.

“It’s easier to ask forgiveness than it is to get permission.” ~Grace Hopper.

“If you don’t know what to tell, tell the truth” ~Pawel

While I understand that what’s on the company wiki doesn’t necessarily make it the part of organizational culture, that’s one of the first few pages our new hires would read. Interestingly enough, every now and then “if you don’t know what to tell, tell the truth” explicitly comes as a rationale for sharing something with an outside party. This shows that it isn’t an empty declaration but the standard we live by.