After having worked in both type systems Flow is the better option IMO. I’ve come to distrust TypeScript when considering whether the type system is covering my code appropriately. This makes it feel like using a very bulky documentation system when compared to Flow and leads to a more manual working relationship with the compiler to ensure correctly behaving code.

I found this all on the internet, but don’t really remember where.

dotfile

# git lg
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
# git ll
git config --global alias.ll "log --pretty=format:'%C(yellow)%h%Cred%d\\ %Creset%s%Cblue\\ [%cn]' --decorate --numstat"

# Better diffs (comes from git contrib scripts)
git config --global pager.log 'diff-highlight | less'
git config --global pager.show 'diff-highlight | less'
git config --global pager.diff 'diff-highlight | less'
git config --global interactive.diffFilter diff-highlight
curl https://raw.githubusercontent.com/git/git/master/contrib/diff-highlight/diff-highlight > ~/bin/diff-highlight && chmod +x ~/bin/diff-highlight

Since the focus through both articles seems to be on REST as a SPA API (not REST as an service-to-service communication API) I find it strange that the author waits until the closing thoughts of the second article to make a sideways glance at GraphQL (by mentioning Relay). Perhaps the timing of the article wasn’t right to address that topic yet, but I feel it would be an important part of the conversation today.

tldr; Use Yarn, ESLint, Jest, Webpack, code splitting, and hash static assets for caching.

Doesn’t get into how to do any of that beyond a superficial English description of one CI process.

Relevant to my current work, thanks!

I’d love to see a deeper cut: Is there type inference? Destructuring? Product and sum types? Can we see examples of the same thing using both tools? How about examples of things one can do that the other can’t?

I’d also love to see stronger opinions: Should I decide just on the basis of existing Angular/React? If I don’t use either, which tool should I pick? Does one have a noticeably larger, friendlier community?

I work mostly in Haskell or JavaScript although as I get more into data science I anticipate Python to take up more usage. ELisp because Emacs. With Haskell I start with types.

Emacs as my “IDE” unless I can’t make changes to a file “on save” as some open source projects don’t control for whitespace on the end of lines and such. If it’s not Emacs it’s probably Sublime Text.

ITerm2 (because Mac) and zsh are where I spend my time when I’m not in Emacs.

Pretty much everywhere I do work uses git in some form (GitHub, Phabricator, etc).

If I control a project end to end my stack looks like:

• Paper or org-mode, then Sketch or Photoshop
• React (or Preact) for webapps and static sites. A litany of JS tooling: babel, glamor, webpack 2, apollo/redux, etc. I build frontends based on APIs these days (as opposed to rendering html in Rails/Django/etc and “sprinkling” JS). If I need to render HTML I’ll use a Universal architecture with React although PWA patterns seem to be better for people with spotty connections these days.
• GraphQL endpoint. I’m working on a Haskell GraphQL implementation so I can swap node out but might also move to Elixir or similar in the near future. This is the point-of-entry for any UIs and allows a much nicer interface than REST.
• Haskell and Servant for microservices. Still using JSON for communication and it would be nice to have something “better” like grpc. There’s no grpc implementation on Hackage, so I need to find the time to write it myself if I want it.
• Docker for deployment (and development env if I have enough services to spin up). I like Swarm’s services model and TLS by default, etc. Alpine as the base for as many images as possible.
• Postgres is my go-to database with sqitch to perform migrations, etc.
• Terraform is becoming my go-to for setting up new servers.
• Digital Ocean has served me well in the past but I’m considering moving to AWS for my personal work because it makes more sense from a “marketable skill” perspective.
• Prometheus for monitoring

Because I bias towards starting with microservices I’m also pretty set on automating as much as possible. Infrakit is interesting in the “server automation” space since it can use Terraform to set up the servers. CI/CD, lerna-semantic-release for JS-based monorepo stuff, etc.

I feel like my workflow is different for each isolatable portion of the stack, so I won’t list them all since this is getting long :)

From the comments (with no response by the author):

I might be missing something but couldn’t your issues with Octo on Node.JS be solved simply by using the Cluster module native to Node ? From what you describe as your immediate advantage for using Golang that sounds like exactly what Cluster does for Node.

Can anyone comment?

Writing a parser for the GraphQL simplified schema language for a Haskell GraphQL implementation. Schemas will be able to be written as such.

type Query {
  hero(episode: Episode): Character
  droid(id: ID!): Droid
}

type Character {
  name: String
}

type Droid {
  name: String
}

This is a departure from my previous approach which intended to use native Haskell data structures to construct a schema and deliver introspection information, etc. I believe this new approach to be more easily implemented in conjunction with the query language and resolvers. Then I might be able to layer a more interesting DX later.

I accepted an offer to work at Dropbox, so am taking November off to work on side projects and develop a running habit.

• Vim
  • My first “advanced” editor. Although now I use Emacs.
• JavaScript
  • This is my main money-making skillset. The ability to build for such a wide variety of platforms isn’t offered by other languages.
• Haskell
  • Heavily influenced the way I write code especially around how much I can reduce the complexity.
• Docker
  • Hard to exclude this from the list if only because I worked there for ~2 years. It also provided jumping off points to expand my knowledge in networking, dist-sys, linux, seccomp, etc and has changed how I think about deploying.

I’ve noticed a couple errors already, such as this line about the kinds of dependencies available. (There are actually dev, peer, bundled and optional in addition to regular dependencies)

There are 2 kinds of package dependencies, “dependencies” and “devDependencies”.

That combined with the complexity introduced in step 3 by using Gulp instead of package.json scripts makes me hesitant to recommend this guide to anyone. For example, this would be the comparison to the gulp config:

{
  "scripts": {
    "clean": "rm -r lib/*",
    "build": "babel src --out-dir lib",
    "watch": "babel -w src --out-dir lib"
    "start": "node lib"
}

It seems to continue the complexity theme with the webpack config as well.

The author glances off some good ideas here (if you can get past the presentation) but I feel they come to the wrong conclusion. The conclusion seems to be “use rails like we did in 2006” with some other backing service(s). I really wouldn’t fault anyone for choosing this path especially if they don’t have a lot of modern UI experience but personally I’ll be sticking with my Universal React application (and mobile, etc UIs) which fetch from a GraphQL endpoint.

I just got my static site generator working with “scaffolding plugins”, which means it’s only a bit of cleanup and some testing away from being able to support anything that compiles to JS and can render “universally. The first POC is going to be a site using Preact since it’s so similar to the first React/Relay scaffolding. Then I’m going to turn an eye to something a bit more "difficult” to integrate like PureScript and continue on with Vue.js, GHCJS and other examples.

The best part is that all of the “frontends” will have the same data-layer (GraphQL), so any advancements in data types, image processing, generating search indexes, etc can be shared by every single LEO site.

Yesterday 33 boats sailed into the port and 54 boats left it. Yesterday at noon there were 40 boats in the port. How many boats were yesterday evening still in the port?

I recognize this framing as the kind of “standardized test” question that you were expected to “fill in the blanks” on when I went through school. Given such a problem, an answer is expected even when the information contained in the question is too vague or incomplete to produce such an answer. If challenged, the most common result is to be marked wrong, told your reasoning was wrong and often also results in angry teachers. Often answering this type of question “correctly” would require looking at the multiple choice answers and deducing the proper framing from the available answers that seemed most correct.

Deconstructing the static site generator I built to enable it to run on multiple “backends” and arbitrary “frontends”. This will mean it is no longer tied to React/Relay and can use anything to render routes (pug, Preact, PureScript, etc). Step 1 is pulling out a package that turns a directory of files into a GraphQL API/Schema.

I use a CODE keyboard currently. My main complaint is that I don’t have rainbow LEDs for it. I also used to use a Kinesis Freestyle, but it just didn’t work out long-term.

Most pressing for me in Haskell is the lack of Hystrix/Zipkin-type libs. Circuit breakers, distributed tracing, etc. As much as the string issues are annoying, they really don’t hold me back. Having best in class “architectural” libs would make my life significantly better I think. That said, it’s the most pressing from my personal perspective, not that of a beginner, etc.

JavaScript… Perhaps Promises. I think Generators need a boost in awareness and redux-saga type libs so that code isn’t littered with Promise/Async-Await (which tend to cause errors to “disappear”).

for $work:

I’m finishing up the mvp on a Shake-based build system. The purpose is to isolate and run builds for a (multi-language) mono repo. We’re using containers to isolate the builds, but are giving a significant amount of trust to the first users of the system. It also has a responsibility to produce Docker artifacts. I’d appreciate being pointed to any papers in this area to inform future work.

On the UI side, I’m introducing Flow to a Relay-based application as well as shipping a component development environment for an internal component library. My first thought for the dev env was carte-blanche, but it is using webpack betas and I don’t have time to dig that deep into the internals to fix it. Thus I landed on using react-storybook which has a slightly less satisfying “API” (sample below) but is much more consistently developed and I can depend on it to not break as often.

import React from 'react';
import { storiesOf, action } from '@kadira/storybook';

storiesOf('Button', module)
  .add('with text', () => (
    <button onClick={action('clicked')}>Hello Button</button>
  ))
  .add('with some emoji', () => (
    <button onClick={action('clicked')}>? ? ? ?</button>
  ));

for $not-work:

Building a GADT to define the API to implement multiple backends for my docker-registry v2 implementation, much like the users package has done. The first major backend is going to be Postgres based and use the large-object support I’ve been prototyping.

I’m trying to put some time into designing my personal site now that it’s readily deployable via the static site generator that I wrote. Historically I’ve done design work in Photoshop but I’m trying to work in Sketch for this project. I also want to get the deployment onto CI and am toying with the idea of splitting the content out from the UI code. that will give me ~3 branches on GitHub. master for deployment, leo for the UI code and data for the markdown files.

I’ve been writing in JS for years and it’s been my main working language for the last.. 7 years? The thing I like the least about es6 is the whole fat arrow syntax. It makes things hard to scan, and that makes it bad code IMO. Sure, you save some keystrokes when writing it, but it’s easier to miss when you’re looking through someone else’s code. I don’t think the class syntax is that bad. It’s pretty easily readable.

The examples provided in the link are pretty abysmal and contrived. If you look at real world code using the class keyword, it’s much less goofy.

Building a Docker Registry and blogging about it.

I’m pretty close to having a working image upload. The code handles the GET/POST/PATCH/PUT/HEAD sequence for resumable layer uploads, even if the logic is minimal (read:incomplete). I’m currently spending some time stepping through the requests coming from the Docker client. After layers, I’ll have to deal with manifests.