以前、Scalaを使ってCLIツールを作るという記事を書いたのですが、やはりJVMベースのアプリケーションには起動時間のオーバーヘッドが付き物なのでちょっとしたCLIツールをScalaで書こうという感じにはなかなかなりません。そこで今回はPicocliというJava向けのCLIツール用ライブラリとGraalVMを使ってネイティブCLIコマンドをScalaで作る方法を試してみました。 github.com sbtプロジェクトの作成 今回はPicocliのドキュメントで例として掲載されていたchecksumコマンドをScalaで実装してみます。まずは以下の内容でbuild.sbtを作成します。 name := "picocli-scala-example" version := "0.1" scalaVersion := "2.12.7" libraryDependencies ++= Seq

先日開催されたSpark + AI Summit 2019にあわせてDatabricks社からSpark用のストレージレイヤ「Delta Lake」のOSS化が発表されました。 databricks.com GitHubリポジトリはこちら。 github.com Delta LakeはSparkのライブラリとして実装されており、分散ストレージ上で以下のような機能を提供します。 ACIDトランザクション（テーブル単位） タイムトラベル（任意の時点の過去データを参照可能） スキーマバリデーション（スキーマ変更も可能） 実際に動かしてみる Delta Lakeの動作にはSpark 2.4.2以降が必要です。ローカルファイルシステムでも動作するのでspark-shellで動きを確認してみました。 $ bin/spark-shell --packages io.delta:delta-core_2.

吉田さんがこういう記事を書いていたので真似してデータベースアクセスライブラリ版を書いてみました。 xuwei-k.hatenablog.com 2009年からのグラフですが、トップ5のスター数の推移はこんな感じ。 slick/slick ★1930 github.com 相変わらずの一番人気。この1年では300くらいスターが増えている。DBIOで強制モナモナやjoinしたつもりなのに何故かサブクエリになるSQLなど問題が多いのに何故こんなに人気があるのか考えさせられるものがある。クエリビルダは非常に柔軟かつ強力だけど、やはり出てくるSQLが想像もつかないのは厳しい。joinを多用するアプリケーションでは（MySQLの場合は特に）使わないほうがよいと思うし、シンプルなCRUDしかしないんだったらこんなに複雑なクエリビルダ要らないのではという気がする。 また、最近はそうでもないけどSQLだけで

GitHubリポジトリはこちら。 github.com なぜ作ったのか？ Scala業界のフレームワークは関数型的なアプローチのものが主流になっています。これらのフレームワークはノンブロッキングI/Oや並列処理をうまく扱うことができますが、本質的な複雑さをもたらします。自分の経験では、特に企業システムなどの場合は従来の同期サーブレットでも十分というケースも多いのではないかと感じています。 また、既存のScala用のフレームワークはタイプセーフなDSLでルーティングや入出力パラメータなどを定義するものが多いのですが、この手のものはシンプルな静的解析でメタ情報を抽出することが難しいためSwaggerなどの外部ツールとの相性が悪いという欠点もあります。 Restyはこのようなケースにおいてもプログラミング言語としてのScalaのアドバンテージを活かすことのできるシンプルなフレームワークがあるとい

ScalaのI/Oライブラリシリーズ第三弾です。今回試してみたのはbetter-filesという、2015年に開発が開始された比較的新しいものです。名前からもわかる通り、I/Oライブラリといってもファイル操作を重視したライブラリになっています。 github.com 特徴はjava.ioに対するユーティリティやimplicit conversionを提供するものではなく、新たにScala用のインターフェースが実装されており、Javaとの相互運用のためのメソッドが提供されているということです。Scala標準のコレクションライブラリと同じような立ち位置と考えるとわかりやすいかもしれません。 better-filesを使用するにはbuild.sbtに以下の依存関係を追加します。 libraryDependencies += "com.github.pathikrit" %% "better-fi

昨年から密かに作り続けていたScala WarriorというWebアプリケーションをScala関西 Summit2016にあわせてリリースしました。 github.com これはRuby WarriorにインスパイアされたScala学習用のゲームで、Scalaコードを書いて侍を操作しステージをクリアしていくというものです。 実装にはScala.jsを活用しており、プレイヤーが入力したコードをScala.jsでJavaScriptにコンパイルし、それをクライアントにサイドに返却してブラウザ上で実行しています。エディタではCTRL+SPACEでコード補完、CTRL+Sでコンパイル結果の確認ができます。このあたりのコードはscala-js-fiddleを参考にさせていただきました。 とりあえず動くものをリリースしたというだけでステージ数も少ないのですが、今後少しずつ改善していければと思っています

去る10月14日（金）弊社の主催でULTRA Beer Bashというイベントを開催しました。 Web界隈のCTOさんたちがパネルディスカッションを行うトラックと、最新の技術動向のプレゼンテーションを行うテクニカルトラックの2トラック構成のイベントだったのですが、テクニカルトラックのアレンジを自分の方で担当させていただきました。準備時間も短かったのですがスピーカーの皆様にご協力いただきフロントエンドから機械学習、インフラ、DDDそしてエンジニアのキャリア論まで素晴らしいセッションを揃えることができました。 当日はイベント内容のSNSでの拡散はNGというアナウンスがされていたのですが、テクニカルトラックに関しては通常の技術イベントと同じくSNSでの拡散OKということにしておけばよかったかなと思います。せっかくの魅力的なセッションがご参加いただいた方以外に拡散しないのはもったいないのでこのエン

Scala関西 Summit2016の翌日、京都のはてなさんオフィスに伺わせていただき弊社とはてなさんの合同Scala勉強会を開催しました。 今回はクローズドな勉強会ということで普段あまり外には出せないようなリアルな悩みなどもご相談させていただいたのですが、当日の内容を可能な範囲でまとめてみたいと思います。 Scalaの利用状況について はてなさんでScalaを採用しているのは3プロジェクト、社内でScalaを書けるエンジニアは10人ほど、フレームワークはPlay + SlickもしくはScalatra + Slickとのことですが、最近のプロジェクトではSlickはDSLを使わず生SQLを書いているそうです。WebフレームワークはFinchも検討されたそうなのですが、生産性に問題があるという判断で採用には至らなかったとのことでした。 弊社でScalaを使っているのは2プロジェクトですが、

10月8日（土）大阪で開催されたScala関西 Summit2016にスポンサーとして参加させていただきました。 summit.scala-kansai.org 私自身は前職時代を含めここ4年ほどはScalaで仕事ができるようになっていますが、日本だけでなく世界的に見てもScalaの普及度というものはまだまだだなと感じることがよくあります。弊社は東京の会社ですが、今回スポンサーをさせていただいたのは関西にも「これからScalaを使いたい」というプログラマがいらっしゃるのであればそれをサポートすることでScalaの普及に貢献できるのではないかという思いがあってのことです。 当日はスポンサーブースを出していたり、自分自身もスポンサーセッションで登壇させていただいたりしたので他のセッションにはあまり参加できなかったのですが、その中でも参加したセッションについて紹介したいと思います。 はてなにおけ

Akka HTTPの入門についてはセプテーニさんのこちらの記事がわかりやすいです。 labs.septeni.co.jp APIサーバにAkka HTTPを使ってみようかなぁと思っているので試しにリクエスト、レスポンスにJSONを使うのをやってみました。spray-jsonを使うモジュールが用意されているみたいなので依存関係に追加します。 libraryDependencies ++= Seq( "com.typesafe.akka" %% "akka-http-experimental" % "2.4.6", "com.typesafe.akka" %% "akka-http-spray-json-experimental" % "2.4.6" ) コードは以下のような感じ。ちょっと関係ない部分も入っちゃってますが、ケースクラスのプロパティ数に応じてjsonFormat1〜jsonFor

ニューヨーク寒いです。今日もサイバーエージェントさんに負けずに参加したセッションを紹介したいと思います。 Introducing the Scala Center 今日はHeatherさんのキーノートから始まりました。 Scala CenterはScalaの教育コンテンツの開発とオープンソースコミュニティの整備の2つが柱で、Scalaの開発に関してはASFのような組織化された開発コミュニティの構築・運用を支援していくようです。Courseraで提供予定の教材の紹介や、ScaladexというScalaライブラリなどを検索できるサービスを開発しているそうで、デモなども行っていました。 まだ立ち上がったばかりで先行きが不透明な部分もありますが、今後の動向に注目したいところです。 Lightbend Lagom: Microservices "Just Right" Lightbend Lagom

最近HamstersっていうScalaライブラリを発見しました。関数型っぽいコンテナや機能を提供するものなのですが、非常にコンパクトでなおかつ関数型プログラミングに慣れていなくても簡単に使えるというものです。 github.com 使い方はREADMEを見ればだいたいわかると思いますが、以下のような機能があるようです。 Validation OK/KO Monads Monad transformers HLists Union types ひとつずつ見ていきましょう。 ValidationとOK/KO ValidationはEitherのリストを格納するコンテナ、OK / KOはright-biasなEitherのエイリアスで、組み合わせて使います。 こんな感じで全部の結果を保持するか、 val e1 = OK(1) val e2 = KO("error 1") val e3 = KO(

昨日西新宿のTISさんオフィスで開催された第二回Reactive System Meetup in 西新宿でSlick3について話してきました。 reactive-shinjuku.connpass.com 発表資料はこちらです。ところどころSlickディスになってしまい大変申しわけありませんでした。 Reactive database access with Slick3 from takezoe www.slideshare.net セッションでお話しさせていただいた通り、Slick3は単体で使ってもDBIOによるモナディックなAPIを持った並列実行が可能なデータベースアクセスフレームワークに過ぎません。Slick3のどのへんがリアクティブなのかというと、個人的には以下の2点なのではないかと思っています。 戻り値をFutureで扱うことができるのでリアクティブなシステムの一部にデータベ

PythonにはIPython NotebookというWebブラウザで利用可能なインタラクティブシェルがあります。これは編集内容を保存できたり、過去に実行した内容を繰り返し実行できたりなど、ちょっとしたコードを試したり学習用途には最適なものです。 IPythonは言語非依存部分がJupyterとして独立しており、サードパーティによってPython以外にも様々な言語用のカーネルが開発されているようです。jupyter-scalaを使うとIPython NotebookでScalaを使うことができました。 インストール&実行方法は簡単で、予めIPythonをインストールしたのち、jupyter-scalaのサイトからアーカイブをダウンロードし、適当な場所に展開後、展開したディレクトリのbinディレクトリに含まれているjupyter-scalaというシェルスクリプトを実行します。これでScala

Scalaのコードを書くのにIntelliJを使っています。もともとEclipseユーザだったので最初はEclipseマップをカスタマイズしたキーバインドを使っていたのですが、Macへの移行を機に限界を感じ、デフォルトのショートカットを覚えることにしました。 とはいえ、control+space（補完）や、alt+enter（Eclipseのクイックフィックスみたいなもの）を除くと日常的に使っているショートカットは以下のように10個にも満たないですw ショートカット説明 command + B宣言を開く command + Oクラスを開く command + shift + Oファイルを開く command + shift + Fファイル検索 alt + F7使用箇所を検索 alt + command + B実装を検索 F1クイックドキュメント command + F12クイックアウトライ

Slick 3.0がリリースされたので、GitBucketをSlick 3.0にアップデートするべくいろいろ試してみました。 Slick 3.0は別名Reactive Slickというだけあり、これまでとはプログラミングモデルがドラスティックに変わっています。具体的に言うとDBIOActionというオブジェクトを介してデータベース操作の定義と実行が明確に分離されています。要するにMonadicなプログラミングスタイルになっているということです。 他にもReactive StreamsとかOptionサポートの強化などSlick 3.0の新機能はいろいろありますが、一番大きいのはこの点だと思います。 また、DBIOActionの実行は全面的にFutureベースになっています。Playなどと組み合わせて使用する場合、Slickを使った処理があってもAsyncResultで返すことができるように

Reactive Streamsというのはノンブロッキングなback pressure可能な非同期ストリーム処理の標準的な仕様を提供しようというもので、実装としてはAkka Streams、RxJava、Reactor Composable、Ratpackなどがあります。 Reactive StreamsについてはAkkaのコミッタであるKonrad Malawskiさんの以下のスライドがとてもわかりやすいです。 2014 akka-streams-tokyo-japanese from Konrad Malawski ストリーム処理（というか非同期メッセージング全般に言えることですが）では受信側の処理能力を超えるデータを送信し続けるといずれキャパシティを超えてオーバーフローが発生してしまうため、送信側に比べて受信側の処理能力が低い場合は送信側が手加減してデータを送信する必要があります。な

warファイルをサーブレットコンテナにデプロイするだけで利用可能なGithubクローン、GitBucket 1.0をリリースしました。 https://github.com/takezoe/gitbucket 当初の目標（6月末）からは少し遅れてしまいましたが、Gitリポジトリの作成、リポジトリビューア、Wiki、Issuesなどは一通り実装しており、なんとか実用に耐えうる機能は揃っているのではと思います。フォークやプルリクエスト、タイムライン、チーム管理、メール通知などまだまだ未実装の機能は多いですが、今後のバージョンアップで随時機能を追加していきます。 フレームワークとか 少し話は変わりますが、GitBucketはScalaで書かれており、フレームワークとして以下のものを組み合わせて使用しています。 Scalatra scalatra-forms（Play2のフォームのようなバリデーシ

Play2の開発モードはなぜ遅いのか？ Play2の開発モードは非常に遅いです。 わかりやすく言うとSeasar2のHOT deployを10倍くらい遅くしたような感じです。これはファイルを編集した際のリコンパイルが遅いというのもあるのですが、編集せずに普通に動かしているだけでもめちゃくちゃ重いです。もちろんアプリケーションの規模にもよりますが、一般的に「大規模」とまでは言えないようなレベルのアプリケーションですら開発していてストレスを感じるレベルです。 これはなぜかというと、そもそも更新のチェックやクラスのリロードなどで１リクエストの処理が遅いということもありますが、リクエストが直列化されて処理されているからというのも大きいと思われます（Play2のソースをちゃんと読んだわけではなく、Seasar2のHOT deployのときの経験と、Play2の挙動からある程度想像で書いてます）。 特

昨日の日記で長々と書いたplay2-fastassetsですが、実際のアプリに組み込んで効果を確認できたので0.0.1としてAmaterasのMavenリポジトリにpublishしておきました。こんな感じでご利用ください。 resolvers += "amateras-repo" at "http://amateras.sourceforge.jp/mvn/" libraryDependencies += "jp.sf.amateras.play2.fastassets" %% "play2-fastassets" % "0.0.1" 諸事情によりPlay 2.0.1用にビルドしてあります。最近のバージョンのPlayで使用する場合にはリポジトリをcloneしてbuild.sbtのPlayのバージョンを変更してビルドしなおすか、面倒であればソースファイルは1つだけなのでコピってPlay2プロ