HHKB Professional2用の吸振マットを買ってみた

f:id:takezoe:20200229102348j:plain

ThinkPadキーボードのトラックポイントが実は肩コリの原因なのではという疑惑により最近は再びHHKBと普通のマウスを使う生活をしています。最初はHHKBのキーストローク辛いなぁと思っていたのですが、すっかり慣れてしまいました。肩コリは多少改善したような気がします。

さて、少し前にHHKB用の振動吸収マットなるものが存在することを知り試してみたいと思っていたのですが、PFUオンラインストアでは品切れになっていたので諦めてコルクシートでマットを自作したりなど涙ぐましい努力をしていたところ、Amazonで売っていたのでここぞとばかりに購入してみました。

日付が変わってからクリックしたのですが、その日のうちに自宅に届きました。早速装着。エンボス加工されたマットで筐体の裏側一面が覆われます。

実際にタイプしてみると明らかに筐体が安定し、特に底打ちした時のキータッチが柔らかくなっています。HHKBは筐体がプラスチックで軽量なため、タイプしていると筐体がズレたりデスクからの反動を感じたりするのが欠点の一つだと個人的に思っているのですが、このマットを装着するとデスクにグリップして微動だにしなくなります。一度貼ってしまうと剥がすのが大変そうでですし、値段もそこそこしますが、ただでさえ素晴らしいHHKBのキータッチがさらにいい感じになるのでHHKBユーザの方は是非試してみて欲しいです。

なお、今回購入したのはProfessional 2用のものですが、最新のHybrid用のマットも販売されています。こちらもPFUオンラインストアでは現在品切れ中ですが、Amazonで購入することができます。

HHKB吸振マットHG(HYBRID Type-S,HYBRID,Classic用)

HHKB吸振マットHG(HYBRID Type-S,HYBRID,Classic用)

  • メディア: エレクトロニクス

Amazon Builder's Libraryを読んでみた

昨年のre:Invent 2019で発表されたAmazon Builder's Libraryを一通り読んでみました。通勤電車で読んでいたのですが、途中で冬休みに突入してしまい少し時間がかかってしまいました。途中で日本語にも対応していることに気付いたのですが、折角なので全て英語で読んでみました。

aws.amazon.com

Amazonにおける大規模分散システムの開発で得られたノウハウが公開されているのですが、昨今マイクロサービスの普及もあり、Amazonのような規模でなくとも分散システムに関するノウハウが重要になりつつあります。もちろんAWSのインフラや規模感に依存する部分も多々見られるものの、大規模な分散システムを運用した上で得られる知見というのは得難いものですし、一般論として参考になる部分も多く、とても有用なコンテンツだと思います。

全体を通して共通して述べられていたのは以下のような点です。

  • 複雑な仕組みはなるべく避ける
    • 複雑な仕組みにはテストが難しくなったり、トラブル時により状況を悪化させるリスクもあるので、きちんとメリット・デメリットを検討した上で本当に必要な場合のみ採用すること。また、すでに検証済みのライブラリなどは存在するのであればそれを使用し、車輪の再発明は避けること。
  • できるだけメトリックを取る
    • 何かしら判断を下す際に判断材料となるメトリックが必要。トラブルシュート時なども事前に適切なログ、メトリックが出ていると助けになる。具体的にどのようなログを取るべきかは各記事で説明されていますし、総論としてのロギングに関する記事もありました。

基本といえば基本ですが、どの記事でも繰り返し述べられていたのでやはりこういう部分が大事なんだなということを再確認させられました。

個人的には以下の記事が面白かったです。

  • Avoiding fallback in distributed systems
    • トラブル時のフォールバックはテストが難しい上に問題があってもすぐに発覚しないことが多いなどデメリットが大きいので避けるべきという話。もちろんケースバイケースだとは思うのですが、何も考えずに気軽にフォールバック処理を埋め込んでしまうのはよくないなぁという気付きがありました。
  • Leader election in distributed systems
    • Leader ElectionはカナリーデプロイやA/Bテストなどのための部分デプロイと相性が悪いというのは言われてみればという感じ。システムを冪等に作っておくことでトラブル時など複数のLeaderが存在する状態になってしまっても問題ないようにしておくなど、なるほどと思う点が多かったです。
  • Using load shedding to avoid overload
    • 高負荷時にキャパシティを超えたリクエストを拒否することで受け付けたリクエストのレイテンシを守るという手法。ヘルスチェックやオートスケーリングとの競合など気を付けないといけない点が多く実際にはなかなか扱いが難しそうですが、そういう部分も含めて興味深い記事でした。
  • Workload isolation using shuffle-sharding
    • Route53でDDoS攻撃の影響を最小限に抑えるために考案されたShuffle Shardingという手法について。シャッフルしたユーザの組み合わせを複数シャードにアサインしておくことで攻撃を受けているユーザ以外に影響が出ないようにするというもの。Route53の開発秘話的な面もあり面白かったです。

前述の通り、各記事は日本語でも読むことができますが、恐らく機械翻訳と思われ、記事によっては意味がよくわからない箇所もあったので英語で読んだ方がいいかもしれません。1つずつの記事が適度な長さ(一部やや長めの記事もありますが)ですし、AWSユーザであれば見知った概念やキーワードも多いのでさほど詰まらずに読み進めることができると思います。

マイクロサービス時代のWeb開発では避けて通れない話題がコンパクトにまとめられていますので、まだご覧になっていない方は一度目を通されてはいかがでしょうか。FAQによると今後も定期的に記事が追加される予定とのことなので要チェックです。

100均のコルクシートでキーボードマットを作ってみた

f:id:takezoe:20200102010127j:plain

HHKBを自宅のデスクで使っていると結構タイプ音が響くし底打ちした時の反動も感じるなぁと思っていたのですが、どうやらHHKBの裏に貼り付けられる吸振マットなるものが存在するらしいということを知り、クリックしようと思ったところすでにHHKB Pro2用のものは在庫切れとのこと。

www.pfu.fujitsu.com

悲しい気持ちになりながらインターネッツを彷徨っていたところ以下の記事を発見しました。

freelance.go-creators.com

これなら簡単にできそうだし値段も安いので試してみようということで早速近所の100均(キャンドゥ)でコルクシートを買ってきてトライしてみました。

f:id:takezoe:20200102010143j:plain

こんな感じで現物合わせで適当に線を引いてはさみでチョキチョキ切るだけ。簡単です。

HHKBは筐体がプラスチックということもあり、金属プレートが入ったメカニカルキーボードと比べるとデスクによって結構タイプ感が変わる感じがありますが、コルクシートを敷くことで底打ちした時の反動が和らぎ、ソフトなタイプ感になりました。ただ、あくまでただのコルクシートなのでグリップはしません。本体に貼り付ける必要もありませんし、まあ100円にしては上出来かなと思います。サイズも自由に決めることができるのでHHKB以外のキーボード用のものも作ることができます。

今回は1枚のコルクシートから3枚分作ることができたので1枚はオフィスで使ってみようかと思います。

GitBucket 4.33.0をリリースしました

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

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

CLIオプションを環境変数で設定可能に

GitBucketはDockerなどでの利用時を想定し、通常設定ファイルで行う設定を環境変数経由で設定することができるようになっています。たとえばデータベースの設定は通常GITBUCKET_HOME/database.confで行いますが、環境変数やシステムプロパティ経由で設定を上書きできるようになっています。

これらに加えてCLIから起動する際に指定可能なオプションについても環境変数で設定できるようになりました。

  • GITBUCKET_MAXFILEZIE
    • アップロード可能な最大ファイルサイス(バイト単位、デフォルトは3MB)
  • GITBUCKET_UPLOADTIMEOUT
    • ファイルアップロードのタイムアウト(ミリ秒単位、デフォルトは30秒)
  • GITBUCKET_PLUGINDIR
  • GITBUCKET_VALIDATE_PASSWORD
    • GitBucketではデフォルトではパスワードに使用可能な文字種が限られていますが、この設定をfalseにすることで全ての文字を使用可能になります

プルリクエストのファイルの折りたたみ

プルリクエストの比較ビューでファイル単位で折りたたみができるようになりました。

f:id:takezoe:20191231212428g:plain

WebHookのセキュリティオプション

WebHookによるイントラネット内部のリソースへのアクセスをブロックするオプションを追加しました。このオプションを有効にした場合、IPホワイトリストで特定のサーバに対するアクセスのみ許可することができます。

f:id:takezoe:20191231212539p:plain

Web APIでassignee、assigneesプロパティをサポート

以下のWeb APIのレスポンスにassignee、assigneesプロパティを追加しました。

今回のバージョンではこの他にも様々な改善やバグフィックスを行っています。詳細についてはIssueの一覧をご覧ください。

2019年の振り返り

今年もようやく仕事納めということで一年の振り返りを書いてみようと思います。

f:id:takezoe:20191201023123j:plain

仕事関係

前職、前々職ではOSS活動や執筆活動に割く時間があったのですが、トレジャーデータに転職してからは基本的に仕事に専念しています。年齢による体力的な衰えも実感するところなので無理は禁物ということで…。

2月に2週間ほどUSの本社オフィスで仕事をさせていただき、taroleoさんとオンサイトで作業を進めることができたのは煮詰まっていたタイミングだったのでちょうど良かったです。ただ、特に滞在前半は体調が非常に悪く、休日もUSの祝日で三連休があったのにほぼ寝込んでしまったのは残念でした。

takezoe.hatenablog.com

この1年でチームメンバーが増え、上司がUS勤務の外国人になり、東京オフィスも拡張するなど色々と変化がありました。相変わらず色々と苦戦する部分も多かったですが、ナレッジのカバレッジも上がってきてようやく自分のアイデアを形にしていくことができるようになってきたのでこれからという感じです。また、チームに待望のScalaプログラマが加わったのでオンサイトで相談できることも増えとても助かっています。

英語でのコミュニケーションに関しては業務上必要なコミュニケーションに関してはバックグラウンドやコンテキストが補完されてきたので当初と比べるとだいぶ楽になったかなと思いますがまだまだ課題を感じます。これに関してはコツコツやっていくしかないかなという感じです。

執筆・OSS活動など

トレジャーデータへの転職前から作業していたJava逆引きレシピの改訂版が発売されました。個人的にはもう少し作り込みたかったという気持ちがあるのですが、時間もなく、自分の転職に伴って執筆メンバーが全員リモートでの作業という状況の中なんとか形にすることができました。

takezoe.hatenablog.com

OSS活動に関しては、予想はしていたもののやはりGitBucketにはあまり手をかけることができず、月1ペースのリリースも途切れてしまいました。ただ、頻度は下がったものの定期的にリリースは行なっています。大きな機能追加はなかなか難しいかもしれませんが、今後もメンテナンスは継続していくつもりです。

一方で新たにAirframeやPrestoなど仕事で使っているOSSに関してはいくつかコントリビュートすることができました。また、UberApache HudiやDatabricksのDeltaLakeといったビッグデータのストレージレイヤに関しては仕事との関連もあり興味があったのでウォッチしていました。プルリクエストもいくつか送ってマージしていただきました。

takezoe.hatenablog.com

趣味ではPredictionIOとの絡みでSalesforceOSS化したSpark用のAutoMLライブラリTransmogrifAIをいじったりしていました。

takezoe.hatenablog.com

PredictionIOもうちょっとなんとかしたいところではありますが、MLOpsはOSSでもMLFlowなど強力なものが色々出てきてしまったのでもう出る幕がなさそうな感じが若干あり、悩ましいところです。ApacheConでOSSのCDPであるApache Unomiと組み合わせて使うというセッションもあったようですし、それなりにユーザもいるようなのですが…。

昨年からOSS活動は意図的に減らしていたので計画通りと言えば計画通りなのですが、このブログを書く頻度もかなり減ってしまいました。ある程度仕事に慣れてきた部分もあるので、来年はこういった活動も少しずつ再開していけるといいなと思っています。

イベント関係

昨年に引き続き、Airframe Meetupを2回開催させていただきました。10月に開催された第三回では発表もさせていただきました。

takezoe.hatenablog.com

2月にはTokyo Scala Developers Meetupをトレジャーデータでホストさせていただきました。社外の会場ということもありかなり大変でしたが、弊社のマーケティングチームや来日中だったtaroleoさんにもお手伝いいただきなんとか無事に開催することができました。

takezoe.hatenablog.com

また、7月にはトレジャーデータの東京オフィスで日本で初めてのPresto Conferenceが開催されました。カンファレンス自体も去ることながら、Prestoのオリジナルクリエーターのお三方との長時間に渡るディスカッションに同席でき(私はほぼ話についていけず座っていただけですが)良い経験になりました。

prestosql.io

11月にはロンドンのSkills Matter社が開催しているScala Mattersというミートアップに招待いただき、ScalaにおけるDependency Injectonについてお話しさせていただく予定だったのですが、なんと開催一ヶ月前にSkills Matter社が破産してしまうという事態になり、ミートアップもキャンセルされていまいました。

takezoe.hatenablog.com

Skills Matter社はロンドンの開発者コミュニティでは非常に重要な存在だったようですし、Scala Exchangeという(ScalaDaysを除けば)ヨーロッパで一番大きなScalaカンファレンスを開催されていたのでScalaコミュニティに取っても大きな損失なのではないかと思います。個人的にも2年前にScala ExchangeでLTの機会をいただき、今回もミートアップに招待していただいた縁もあり残念な気持ちでいっぱいです。

振り返ってみるとイベントに関してはそれなりに開催・参加していたなぁという感じですが、そういえば今年はScalaMatsuriに参加できませんでした。2日目のチケットを買ってあったのですが、体調不良で結局参加できず、Scala Conference時代から初めての欠席になってしまいました。

まとめ

仕事ではようやくアウトプットを出せるようになってきたかなという感じですが、まだまだ学ぶことは山積みなので引き続き精進していきたいと思います。来年は控えていたOSS活動なども再開していけるといいなと思っていますが、最近ますます加齢による衰えを実感する日々なので体調管理には気をつけたいと思いますw

入門 監視 ―モダンなモニタリングのためのデザインパターン

今更ですが、最近監視って難しいなぁと思うことが多いのでこの本を読んでみました。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

目次を見るとオンコールやインシデント管理といった人間系、ネットワークやセキュリティ監視など幅広いトピックをカバーしているのですが、200ページ強と分量が少なめなこともあってか、かなりあっさりめでタイトル通り入門という感じでした。

もちろん内容は頷ける部分も多く、監視やオンコールをこれから導入しようという現場では読んでおくと基本的な考え方を学べると思いますが、残念ながら現場で実際に発生する悩みに対してヒントを得られるようなものではなかったです。

ところで監視というかヘルスチェックに特化した記事ですが、最近読んだものではAmazon Builder's Libraryの以下の記事が面白かったです。日本語訳もあります。

aws.amazon.com

aws.amazon.com

入門監視ではヘルスチェックも監視の一手法として軽く流されているのですが、実際はヘルスチェック1つ取ってもこれだけ考えることがあるので、監視に関するその他のトピックについてもこのくらい掘り下げられると面白そうだなと思いました。

airframe-launcherとsbt-packでScalaでCLIツールを作る

私は普段主にScalaを使っているので、ちょっと手の込んだ処理が必要だったりJava/Scalaライブラリを使ったツールが必要な場合にScalaで書けると便利だなと思うことがあります。

AirframeはScala用のDIコンテナを中心とした様々な機能を提供するライブラリ群ですが、そのうちの1つとしてairframe-launcherというCLIツール作成用のモジュールがあり、コマンドラインオプションを簡単に扱うことができます。また、sbt-packというsbtプラグインを使うと作成したアプリケーションを実行可能なコマンドとしてパッケージング、インストールできます。これらを組み合わせてScalaCLIツールを作る方法を紹介したいと思います。

wvlet.org

github.com

まずはbuild.sbtに以下の記述を追加し、airframe-launcherを依存関係に追加します。

libraryDependencies ++= Seq(
  "org.wvlet.airframe"  %% "airframe-launcher" % "19.11.1"
)

手始めにメッセージを表示するだけの簡単なCLIツールを作成してみます。コマンドラインオプションは@optionアノテーション、サブコマンドは@commandアノテーションで指定します。実行時にコマンドラインオプションでサブコマンドが指定されていない場合、isDefault = trueが指定されたコマンドが実行されます。

package com.github.takezoe

import wvlet.airframe.launcher.{Launcher, command, option}

class Hello(@option(prefix = "-n,--name", description = "your name")
            name: String,
            @option(prefix = "-h,--help", description = "show help message", isHelp = true)
            displayHelp: Boolean) {

  @command(isDefault = true)
  def default(): Unit = {
    println(s"Hello ${name}!")
  }
}

object Main extends App {
  Launcher.execute[Hello](args)
}

これをsbt-packでパッケージングします。plugins.sbtに以下の記述を追加します。

addSbtPlugin("org.xerial.sbt" % "sbt-pack" % "0.11")

build.sbtにパッケージングの設定を追加する必要があります。PackPluginを有効にし、コマンドと起動クラスのマッピングを行ないます。

enablePlugins(PackPlugin)
packMain := Map("hello" -> "com.github.takezoe.Main")

sbt packtarget/packディレクトリに必要なファイル一式が生成されます。また、sbt packInstall$HOME/local/binディレクトリに実行可能なコマンドがインストールされるのでこのディレクトリにPATHを通しておけば普通のコマンドと同じように使用できます。

インストールしたコマンドを実行してみます。

$ hello -n Naoki
Hello Naoki!

続いてScalaコードを修正してサブコマンドを追加してみます。Helloクラスに以下のメソッドを追加します。サブコマンド固有のオプションも定義できます。

@command(description = "display a message repeatedly")
def repeat(@option(prefix = "-c,--count", description = "repeat count")
           count: Int): Unit = {
  for(_ <- 0 to count){
    println(s"Hello ${name}!")
  }
}

以下のように実行します。

$ hello repeat -n Naoki -c 3
Hello Naoki!
Hello Naoki!
Hello Naoki!

airframe-launcherにはヘルプを自動生成する機能もあります。isHelp = trueが指定されたオプションを指定して実行すると以下のようなヘルプが表示されます。

$ hello --help
usage: hello [options] <command name>

[options]
 -n, --name:[NAME]  your name
 -h, --help         show help message

[commands]
 repeat         display a message repeatedly

JVMの起動速度という問題はあるものの、CLIツールでもそこそこ大きなものであれば既存のJVM資産が活用できタイプセーフかつ記述能力の高いScalaで書くメリットもあるかと思います。こういった用途にもScalaの活用の幅が広がればと思います。