週末に趣味プログラミングをする人のための Github organization として foundweekends を作った。参加したい人は twitter か Gitter で声をかけてください。

当面の活動は @n8han から conscript、giter8、pamflet を引き継ぐことだ。

Scala プログラマの週末の嗜みとして、僕も一つ sjson-new という JSON ライブラリを書いてみた。
sjson-new は型クラスベースの JSON コーデックライブラリで、Jawn のための wit だ。つまり、複数のバックエンドに対して sjson的なコーデックを提供することを目指している。

コードは　spray-json を元にしているが、データの扱いに関しての考え方は Scala Pickling の方に近い。Pickling と違って、sjson-new-core はマクロとか普通のパターンマッチング以外での実行時リフレクションなどは一切使っていない。

Json4s-AST と使う場合:

libraryDependencies += "com.eed3si9n" %%  "sjson-new-json4s" % "0.1.0"

Spray と使う場合:

libraryDependencies += "com.eed3si9n" %%  "sjson-new-spray" % "0.1.0"

これは先日書いた sbt 1.0 ロードマップの続編だ。この記事では sbt server の新しい実装を紹介する。感想やコメントがあれば sbt-dev mailing list にお願いします。

sbt server の動機は IDE との統合の改善だ。

ビルドは、巨大で、可変で、共有された、状態のデバイスだ。ディスクのことだよ! ビルドはディスク上で動作するのもであって、ディスクから逃れることはできない。

-- Josh Suereth、The road to sbt 1.0 is paved with server より

マシンに積んであるディスクは根本的にステートフルなものであり、sbt がタスクを並行実行できるのもそれが作用に関する完全なコントロールを持っていることが大前提になっている。同じビルドに対して sbt と IDE を同時に実行していたり、複数の sbt インスタンスを実行している場合は、sbt はビルドの状態に関して一切保証することができない。

sbt server というコンセプトは元々 2013年に提案された。同時期にその考えの実装として sbt-remote-control プロジェクトも始まった。ある時点で sbt 0.13 が安定化して、代わりに Activator が sbt-remote-control を牽引する役目になり、sbt 本体を変えない、JavaScript をクライアントとしてサポートするなどという追加の制約を課せられることになった。

sbt 1.0 を念頭に置いて、僕は sbt server の取り組みをリブートすることにした。sbt の外で何かを作るのではなくて、僕はアンダーエンジニアリングすることを目指している。つまり「オーバーエンジニアリング」の逆で、自動ディスカバリーや自動シリアライゼーションといった僕から見て本質的じゃない既存の前提を一度捨てようと思っている。代わりに、気楽に sbt/sbt コードベースに取り込めるような小さいものがほしい。Lightbend 社は Engineering Meeting といってエンジニア全員が日常から離れた所に集結して議論をしたり、内部でのハッカソン的なことをやる合宿みたいなことを年に数回やっている。2月に美しいブダペストで行われたハッカソンでは sbt server リブートという提案に Johan Andrén (@apnylle)、 Toni Cunei、 Martin Duhem の 3人が乗ってくれた。目標として設置したのは、IntelliJ IDEA に sbt のビルドを実行させるボタンを付けることだ。

sbt 1.0 にに関して TL上とかで議論があったので、叩き台としてこれを書くことにした。何かをちゃんとリリースできるように仕切り直しするための中期的なミッション・ステートメントだと思ってほしい。sbt-dev mailing list にて今後も議論を続けていきたい。

タイミング

いつ sbt 1.0 をリリースできるかという予定はまだ見当が付いていない。
sbt 1.0 の最大の機能はコードの再組織で、それは既に進んでいる: http://www.scala-sbt.org/0.13/docs/Modularization.html

sbt/io、 sbt/util、 sbt/librarymanagement、 sbt/incrementalcompiler といったモジュールがある。実装という観点からするとインクリメンタルコンパイラが sbt の中で一番複雑な部分だと思うので、まずはそれをモジュール化することを目標としてきた。全部のモジュールの API が安定したときが、sbt 本体にも 1.0 を付けれる時になる。

モジュール化の動機

僕にとって ScalaMatsuri とはライフスタイルのようなものだ (他の 27名近くいるオーガナイザーも同じように思っているんじゃないだろうか)。確かに、近日東京で 550名を動員したカンファレンスがあって、それは成功に終わった。しかし、オーガナイザーは 2015年の 2/28 からかれこれ 11ヶ月間準備してきた。僕が関わったのは一部でしかないけども、ScalaMatsuri 2016 はこれまでで一番関わりの深いカンファレンスになったと思う。この何ヶ月の間 Slack、Hangout たまには対面で、さまざまな議論を重ねてきた。面白かったのは、一緒にアイディアを出し合ってそれが実現されるのをみることだったと思う。僕が奇抜なアイディアを出して、その詳細を誰かが実行してくれることもあれば、他の人が始めたことを元に僕が現場の作業をすることもあった。

色々言いたいことは「グローバルな技術カンファレンス」と「日本のコミュニティの交流」の両立でも書いちゃったので、かぶる部分もあると思う。

ScalaMatsuri 運営ブログに「グローバルな技術カンファレンス」と「日本のコミュニティの交流」の両立を書きました。

Scala は柔軟なプログラミング言語なので、個人的な Good Parts のような言語のサブセット、もしくは主義主張のあるスタイルガイドを作ることは有用だ。

セットアップ

-Yno-lub を試してみたい人は、以下を project/ynolub.sbt に書いて sbt プラグインを引っ張ってくる:

addSbtPlugin("com.eed3si9n" % "sbt-ynolub" % "0.2.0")

lub

Scala の型推論が型 A と型 B を統合するとき、それらの <:< に関する lub (least upper bounds, 最小上界) を計算する。この過程を lubbing と呼ぶこともある。具体例で説明する:

scala> if (true) Some(1) else None
res0: Option[Int] = Some(1)
 
scala> if (true) List(1) else Nil
res1: List[Int] = List(1)

ここ数年考えているのは、少なくとも今ある形での lubbing は有益ではないのではないか、ということだ。

猫番という新しいシリーズを始めた。(これは最初から Pamflet で書いている)

Cats は Scala のための関数型プログラミングのライブラリで、これは僕がそれを使ってみた記録だ。 Cats は、現在開発中で未だ実験段階にある。

I gave a talk at Scala Days 2015 San Francisco with Josh Suereth (@jsuereth).

• video on parlesy.com
• slides

最近 Mac と Ubuntu、それから Java 6 と Java 7 を行ったり来たりしてる。
Java の切り替え方を統一したいので、ここにメモしておく。

追記: jEnv という便利なものを Yoshida-san に教えてもらったので、それを使ったほうがいいかも。

Zshrc

OS によるシェルスクリプトの切り替えはこんなふうにやってる:

## basic
[ -f $HOME/dotfiles/zshrc.basic ] && source $HOME/dotfiles/zshrc.basic

## aliases
[ -f $HOME/dotfiles/zshrc.alias ] && source $HOME/dotfiles/zshrc.alias

case "${OSTYPE}" in
# MacOSX
darwin*)
  [ -f $HOME/dotfiles/zshrc.osx ] && source $HOME/dotfiles/zshrc.osx
  ;;
# Linux
linux*)