sbt 1.4.xで作ったjar/war内のファイルのタイムスタンプがおかしくなる問題を修正した

最近GitBucketでTomcatにデプロイするとエラーになるというレポートがあり、調べていたのですが、

github.com

どうやらwar内のファイルのタイムスタンプが負の値になっており、warの展開時にその値をファイルの更新日時として設定しようとしてエラーになっているようで、sbt 1.4.0での以下の修正が原因であるらしいことがわかりました。

github.com

以下のような感じで環境変数SOURCE_DATE_EPOCHで明示的にタイムスタンプを設定するようにすれば回避できます。

envVars := Map(
  "SOURCE_DATE_EPOCH" -> System.currentTimeMillis().toString
)

GitBucketではsbt-ioのAPIを直接使用して、warファイルをいったん展開して内容を変更してからwarファイルを作り直すということを行っているのですが、その際に引数でタイムスタンプを指定することもできます。

IO jar (
  sources = contentMappings.map { case (file, path) => (file, path.toString) }, 
  outputJar = outputFile, 
  manifest = manifestFile, 
  time = Some(System.currentTimeMillis())
)

とりあえずはこれで問題を回避できたのですが、なんでこんな動きをするのか不思議だったのでもう少し詳しく調べてみました。

sbt 1.4.0以降では前述の修正により、packageタスクでjarファイルやwarファイル*1を作成する際にデフォルトでが各エントリのタイムスタンプに0を設定するようになっているのですが、sbt-io側の以下のタイムゾーン調整*2により、タイムゾーンによってはセットする値が負の値になってしまっているようです。

さらにJDKのZipEntryのコードを見ると、どうやらzipファイルの各エントリはxdostimeという値に加えてextraフィールドにmtimeというミリ秒単位のタイムスタンプを持っており、xdostimeの方には想定通りの値（= 0）がセットされるものの、mtimeの方には負の値がセットされてしまうようです。

github.com

というわけで最終的にsbtに以下のプルリクエストを送ってマージしていただきました。

github.com

修正は1行だけですし、実際にこれが原因で困るというケースはほとんどないような気もするのですが、原因を調べるのがなかなか大変だったので記事を書いてみました。*3

*1:GitBucketではxsbt-war-pluginを使っています。

*2:JDKのZipEntry.getTime()がタイムゾーンによって返すタイムスタンプを調整しているため、予めタイムゾーン調整済みのタイムスタンプを設定する必要がある。

*3:あとからさらに調べてわかったのですがunzipコマンドではちゃんとタイムスタンプのレンジチェックが入っているようなのでsbt-ioでの展開時の処理でも補正するべきなのかも…。

CSVをMarkdownのテーブルに変換するVSCode拡張を作ってみた

昔Atom用に作ったものを移植しただけですが、こんな感じでCSVテキストを範囲選択してコマンドパレットから「Convert CSV to Markdown table」を選択すると適当にフォーマットしてMarkdownのテーブル記法に変換します。

GitHubリポジトリはこちら。

github.com

VSCodeのMarketplaceからもインストールできるようにしてあります。

marketplace.visualstudio.com

VSCode拡張の作成方法については公式のドキュメントにまとまっています。Yeomanでプロジェクトの雛形を生成し、vsceコマンドでパッケージの作成や公開を行うという感じです。

code.visualstudio.com

パッケージの公開のところが少し面倒で、マイクロソフトアカウントでAzure DevOpsにサインインしてアクセストークンを作成する必要があります。また、ドキュメントではvsce create-publisherコマンドでpublisherを作成するとなっているのですが、このサブコマンドはすでに非推奨になっているようで、Marketplaceの管理画面から作成する必要がありました。ここまで準備しておけばvsce publishでMarketplaceに公開できます。

また、vsce packageでvsixパッケージを作成し、拡張マネージャのプルダウンメニューから「Install from VSIX」を選択することでこのパッケージをオフラインでインストールすることもできます。

Atomでは標準の拡張開発言語がCoffeeScriptでしたが、VSCodeではTypeScriptが使われているので開発もやりやすいのではないかと思いますし、ちょっとした拡張がサクッと作れるようになるとなにかと便利なので色々と研究していきたいと思います。

My Life in Red and White

昨年ベンゲルの自伝が出版されたのでこれは読まなくてはとKindle版を購入していたのですが、年末年始の休暇中にようやく読むことができました。

My Life in Red and White: The Sunday Times No 1 Bestseller (English Edition)

内容については幼少期〜選手時代からカンヌ、ナンシー、モナコでの監督時代、名古屋、アーセナル初期〜Invincibles時代、エミレーツスタジアム建設期〜辞任、そして現在のFIFAでの仕事とベンゲルの歩みが自身の言葉で綴られています。

読んでまず思ったのは、晩年のイメージと違ってかなりスパルタンな経歴と思想の持ち主なんだなということです。とにかくハードワークと精神論という感じですw 若手を中心に一度信じたプレーヤーを辛抱強く使うのは積み重ねられた成功体験によるものであることがわかる一方、アーセナルでの監督時代はそれが足枷になっていた面があることも否めないのですが、まあそういう部分も含めてベンゲルらしいなという感じがします。

当時は知りませんでしたが、名古屋での18ヶ月はフランスリーグでのスキャンダルから逃れてサッカーに集中できる充電期間にもなっていたようですし、異文化への適応という面でその後アーセナルでの仕事にも役立ったようです。選手が練習熱心すぎて練習しすぎないようボールを隠さなければならなかったとか、料亭でのプレスカンファレンスで足が痺れて死にそうだったなどの面白エピソードが多いのも名古屋時代の特徴ですねw 短い期間ながらここで日本との繋がりができたことは自分を含め、現在日本に多数のアーセナルファンが存在するきっかけにもなっていると思うので、当時のフランスリーグでのスキャンダルについてはむしろ感謝すべきなのかもしれません。

全編通して物議をかもしそうな負の側面についてはあまり触れられていないのもベンゲルらしいところで、アーセナルの監督を辞任したのは自分の意志ではなかったという点くらいでしょうか。エミレーツ建設時代の心労や、プレミアリーグの発展とともに肥大化するクラブ組織の中での苦労は痛いほど伝わってきましたし、それだけに辞任も無念であったろうと思います。ただ、個人的にはベンゲル自身もエミレーツの建設のための負債の返却が終わって、ある意味緊張の糸が切れてしまったことがその後の成績にも影響したのかもしれないと感じました。

たらればになってしまいますが、もしバルサとのCL決勝でレーマンが一発退場していなければ、セスクやロビンがいた時期に一度でもプレミアリーグで優勝できていれば、ミラクルレスターのシーズンにカソルラが怪我をしなければ、もう少し違う未来もあったのではないかと考えてしまいますね。そうすれば何人かの主力選手は移籍することなくチームは競争力を保つことができ、ベンゲルはまだ監督で、エジルはこんな去り方をしなくても済んだかもしれない。今となってはどうにもならないことですが、現在のアーセナルの窮状を目の当たりにしているだけに、後半のアーセナル時代の章を読んでいると当時の記憶が思い起こされて辛い気持ちになってしまいました。

巻末にはベンゲル監督の記録や写真なども掲載されており、アーセナルファンであればもはや記念品として持っておくべき一冊と思います。自分はKindleで読んだのですが（スマートフォンの翻訳機能が便利w）、あまりにも名著すぎたのでハードカバーもオーダーしてしまいました。日本にはアーセナルファンが多いので日本語訳も出るといいなーと思いますが、割とストレートな英語で書かれていますし、分量もさほどでもないので英語での読書の題材としてもちょうどよかったです。

なんにせよ、ベンゲル自身はまだサッカーへの情熱を失っていないようですし、今後はFIFAというより影響力の強い立場からサッカーの発展に尽力してくれるはずです。また、ベンゲル退任後に暗黒時代に突入してしまったアーセナルもまだまだ予断を許さないもののアルテタの下で一時期の絶不調を脱しつつあります。ベンゲル先生の今後の活躍を願いつつアーセナルを応援し続ける所存です。ハードカバーが届いたらもう一回読み直してみようw

実践Terraform AWSにおけるシステム設計とベストプラクティス

仕事でTerraformを使っているのですが、Terraform弱者すぎて毎回「なんもわからん…」となっているので学習のために日本語で読める本として購入してみました。

実践Terraform　AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）)

Terraformの基本と、様々なAWSリソースのTerraformでの作成例がハウツー形式で紹介されているという感じです。一通り読んでみての感想はTerraformというよりAWSの知識が重要という点を再確認したという感じでした。とはいえ雰囲気でTerraformを使っていたので基本的な部分や実践的なノウハウをサクッと押さえられたのはよかったです。

チーム開発についての章がありCIとの連携例が紹介されていますが、Terraform EnterpriseやTerraform Cloudについても言及があってもよかったのではないかと思いました（tfstateの保存先としてTerraform Cloudが紹介されているのみ）。

インプレスさんのこのシリーズはキャッチーなトピックがタイムリーかつ読みやすい分量で書籍化されていますね。元々は技術書典で販売されていた書籍を商業出版するというコンセプトでスタートしたシリーズだそうですが、従来の出版形態では難しそうな書籍も出ていますし、技術分野が多様化し、移り変わりも早い現在の状況にあった出版形態だと思うので密かに応援しています。達人出版会さんでDRMフリーな電子書籍が購入できるのも良いですね。

tatsu-zine.com

2020年の振り返り

今年も今日で仕事納め（の予定）ということで、いつも通り1年を振り返ってみたいと思います。

リモートワークへの移行

今新型コロナウィルスの影響で3月頃から完全にリモートで作業をしています。同業他社の皆さんも似たような状況かとは思いますが、元々トレジャーデータでは地理的にチームが分散しておりリモートのメンバーと働くことに慣れていること、必要に応じてリモートでも業務が可能な環境が整備されていたこともあり、仕事のしやすさという意味ではそこまで大きな影響は感じませんでした。

とはいえ、自宅の環境面でストレスが溜まることはやはり多く、会社としても今後完全にリモートファーストに移行する流れなのでもう少し本格的に自宅環境を整備してもよいかなと思っています。また、電車通勤がなくなったのは素直に喜ばしいのですが、運動不足が深刻なので少し意識的に体も動かしていきたいところです。

仕事関係

上記の新型コロナウィルスの影響による環境の変化は勿論のこと、社でも方針転換があったりしましたが、自分の業務内容にはそこまで大きな影響はなく今年も引き続きPresto周りを中心に仕事をしていました。

大きなところでは昨年から進めていた某マイグレーションプロジェクトをようやくリリースすることができました。実作業で言えば2〜3ヶ月程度で行けたような気がするのですが、途中に色々あってなんだかんだで結局1年かかってしまいました。もう1つ、すでに着手してからすでに2年が経過しているプロジェクトがあり、こちらも年内に終わらせる予定だったのですが、諸事情により来年に持ち越しとなり晴れて3年目に突入してしまいました。来年には必ず終わらせたいです。

あとは社内の管理系のアプリケーションでScala.jsを結構本格的に使い始めました。詳しくは今年のScalaMatsuriでのtaroleoさんの発表で紹介されています。Scala.js自体はちゃんと動くのですが、主にライブラリの部分などでやはりScalaと全く同じ感覚では書けないなぁと感じる部分があります。

11月にはオンラインで開催されたPresto Conference Tokyo 2020で仕事絡みの発表をさせていただきました。トレジャーデータでのPrestoのリグレッションテストに関する取り組みについて紹介させていただいたのですが、この取り組みはDBのテストに関する論文を読んだりするきっかけにもなったのでよかったです。

takezoe.hatenablog.com

OSS関係

OSS関係はさらにアクティビティが低下してしまいました。新しいことといえばMetalsをちらほらいじっていたくらいでしょうか。

takezoe.hatenablog.com

あとはScalaで書いたCLIツールをネイティブコンパイルしたいなと思い、GraalVMやscala-nativeを試したりしていました。結論としては単にScalaで書いたアプリケーションをネイティブコンパイルするのであればGraalVMを使うのが良さそう。scala-nativeはScalaでCを書くためのものという感じで、ちょっとユースケースが違いそうです。

takezoe.hatenablog.com

scala-nativeに関しては（実用的かどうかはさておき）Modern Systems Programming with Scala Nativeという本がとても面白かったです。

takezoe.hatenablog.com

既存のプロジェクトでは、GitBucketは今年は2回だけのリリースとなりました。リリース回数は少なかったものの、新コミッタであるonukuraさんがかなりアクティブにコミットしてくださり、特にWeb APIのカバレッジが劇的に向上しました。

takezoe.hatenablog.com

ScalatraはScala 2.13に対応した2.7.0をリリースしました。また、毎年ドメインの更新時に話題に上がっていたのですが、ついにscalatra.orgのドメインを自分の方で引き取りました。Scalatraに関してはさすがにこれからガンガンやっていく感じにはならないと思いますが、今後も緩々とメンテナンスを続けていきたいと思います。

takezoe.hatenablog.com

Apache PredictionIOは残念ながらAttic行きが決定してしまいました。MLOpsは熱い分野でKuberenetes絡めて有力プロダクトが次々と出てきましたし、自分たちも転職してしまったりSalesforce社の主要メンバーもアクティブではなくなってしまったりという状況だったので止むを得ないですね。しかしこれでClickに続いて二度目のAttic行きを経験することになるとは…。

来年の抱負

今年は兎にも角にも新型コロナウィルスの影響が大きかったですが、いずれにしても今後もリモートワークが続くことになりそうなので前述の通り自宅の作業環境をもう少しちゃんと整えたいなと思っています。

また、通勤時間がなくなったことで運動不足はもちろんですが、ポッドキャストを聞いたり読書をしたりといった時間が大幅に減ってしまった実感があるので、PCで作業する以外のインプットの時間も意識的に作っていきたいところ。OSSもここ2年ガクッと活動量が落ちてしまったので来年は少し復活させていきたいです。

まだしばらく先が読めない感じなので中々目標なども立てにくい感じですが、まあこればかりは頑張ってどうにかなるものでもないので、来年はあまり気張らず必要以上に消耗しないようやっていければと思います。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

だいぶ今更感がありますが、現職では業務における運用作業の比率が割と高めなこともあり、読んでみました。和訳版ですが、分量と読み辛さが相まって読み終わるのにかなり時間がかかってしまいました。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

もちろん前職もWebサービス企業だったのでサービスにタッチしていた頃は運用にも関わっていたのですが、立ち上げ時期のサービスだったこともあり、とにかくできることをやるという感じで運用のための組織的な仕組みをどう作るかというのはあまり深く考えたことがありませんでした。サービスとして存続できるかどうかもわからないうちに継続的な運用を考えても仕方ないという話もありますし、大きな会社だともともと全社的な仕組みがあって新規サービスでもそれに乗っかれたりもしますが、まだそういう感じでもなかったです。

で、この本なのですが、まずとにかく読みにくい…。1冊の書籍というよりは論文集という感じなのですが、そのせいで話題がだいぶ散漫になっている感じがあり（分量が多いのもあるのですが）、中には分散システム入門みたいな話もあったりして、いったこれは何の本なんだっけ？となることもありました。それと翻訳が結構厳しめで、元の英文を想像しながら読まないと意味がよくわからないような箇所もありました。参考になりそうな部分だけつまみ読みしようにもそういう構成になっておらず、全部通して読んでみないとどこに何が書いてあるのかよくわからないというのも読んでいて辛いところでした。

内容的にはGoogle内部のエンジニアリングの様子を垣間見れるという意味では貴重かと思いますし、特にオンコールに入るまでの教育周りなどや新サービスのローンチを効率化するための取り組みなどは参考になりました。ただ、SREというのは基本的には「ソフトウェアエンジニアが運用を行うとどうなるか」という話と認識しているのですが、運用におけるSREとアプリケーションエンジニアとの役割分担など、これはあくまでGoogleの事例集という感じで、実際に現場においてどう適用すればいいのかというのは正直ちょっとこの本を読んだだけではちょっとイメージしづらかったです。

今年になって実践編のサイトリライアビリティワークブックも和訳が出ているようで、こちらを読めばもう少し具体的なイメージが掴めるかもしれないですが、これまた中々の分量なので読む前から若干腰が引けてしまうところです…。

サイトリライアビリティワークブック ―SREの実践方法

GitBucket 4.35.0をリリースしました

このバージョンにはWebフックが設定済みの場合のみ発生するDBマイグレーションに関するバグおよび標準でバンドルされているnotificationsプラグインに関する互換性問題が存在します。すでに修正版である4.35.2 がリリースされていますのでこちらをご利用ください。

Scalaで実装されたオープンソースのGitサーバ、GitBucket 4.35.0をリリースしました。

https://github.com/takezoe/gitbucket/releases/tag/4.35.0

結局今年は2回だけのリリースでした。リリース頻度は少なかったですが、新コミッタの@onukuraさんのおかげで様々な新機能が実装されたり、Web APIのカバレッジが大幅に改善されています。変更内容は多岐に渡りますので、主要な新機能のみ紹介したいと思います。

エディタ、ソースビューアのカラーテーマが選択可能に

エディタやソースビューアのカラーテーマを好みにあわせて選択できるようになりました。エディタのカラーテーマは上部のプルダウンから選択できます。

ソースビューアのカラーテーマはアカウント設定で選択できます。

イシュー、プルリクエストの入力補完

テキストエリアでの入力補完がイシューやプルリクエストにも対応しました（#で補完をトリガーできます）。

クリップボードからの画像アップロード

ファイルアップロードが可能なテキストエリア（イシューやプルリクエスト、コメントなど）で CTRL + V でクリップボードから画像を貼り付けられるようになりました。

なお、この機能はブラウザのClipboard APIを使用しているため、このAPIを実装していない古いブラウザ（Internet Explorerなど）では動作しません。

コミットコメントでの複数イシューのクローズ

コミットコメントでイシューをクローズする際、これまでは以下のように記述する必要がありました。

fix #1, fix #2, fix #3

このバージョンでは以下のようにカンマ区切りで記述するだけで複数イシューを一度にクローズできるようになりました。

fix #1, #2, #3

ファイル編集時にプルリクエストを作成可能に

オンラインエディタでのファイル編集時に直接ブランチにコミットするだけでなく、プルリクエストの作成を選択できるようになりました。これに伴ってリポジトリへのコミット権がないユーザでもファイルの編集を行うことができるようになりました。

マイルストーンのオーバービュー

各マイルストーンのオーバービューを表示するページが追加されました。該当のマイルストーンに紐づけられたイシュー、プルリクエストおよび進捗が一画面で表示されます。

コミットステータスの表示を改善

GitBucketをCIと連携している場合、各コミットにビルドステータスが表示されるのですが、これまではGitBucketの画面内の限られた場所にしか表示されていませんでした。このバージョンではブランチの一覧やコミットの詳細画面などにもステータスが表示されるようになりました。また、ビルドステータスを詳細は以下のようにツールチップウィンドウで表示されるようになりました。

Web APIのカバレッジを大幅に改善

以下のWeb APIが新規に追加されています。GitBucketでサポートされているGitHub互換APIの一覧はこちらのWikiページを参照してください。

• Issues
  • Comments
    • Get an issue comment
    • Update an issue comment
    • Delete an issue comment
  • Milestones
    • List milestones
    • Create a milestone
    • Get a milestone
    • Update a milestone
    • Delete a milestone
• Pull requests
  • Update a pull request
  • Merge a pull request
• Repositories
  • List public repositories
  • List repository tags
  • Branches
    • Get branch protection
    • Delete branch protection
    • Get status checks protection
    • Get all status check contexts
  • Commits
    • List branches for HEAD commit
  • Contents
    • Get a repository README
  • Reference
    • Create a reference
    • Update a reference
    • Delete a reference
  • Collaborators
    • Check if a user is a repository collaborator
    • Get repository permissions for a user
  • Webhooks
    • List repository webhooks
    • Create a repository webhook
    • Get a repository webhook
    • Update a repository webhook
    • Delete a repository webhook

前述の通り、今回のリリースにはこの他にも様々な改善やバグ修正が行われています。詳細についてはIssueの一覧をご覧いただければと思います。また、今回のリリースにはいくつかの非互換な変更が含まれており、標準添付以外の多くのプラグインがそのままでは動作しない可能性がありますのでご注意ください。