ThinkPad TrackPoint Keyboard II 購入

今年初めに ThinkPad TrackPoint Keyboard のワイヤレス専用版がリニューアルされ Bluetooth に加えてワイヤレス USB 接続をサポートしました。そして先月 JP 版が発売になりました。

www.lenovo.com

昔 ThinkPad やスペースセーバーキーボードのユーザだったというのもあるのですが、ちょうど自宅でテレワーク用の端末と MacBook Pro で HHKB と Magic Keyboard の2台を取り替えて使ってるのが煩雑だったので、1台に統合できるならということで買ってみました。もちろん JP 配列です。

ThinkPad のキーボードらしくキートップの下側に R が入ってます。近年のモデルにあるタッチパッドも省かれているためコンパクトです。クリックボタンの左右がちょっとしたパームレストにもなります。

f:id:kondoumh:20200605083509j:plain

上部側面に Bluteooth - ワイヤレスの切り替えスイッチ、Windows と Android の切り替えスイッチ、充電用の USB-C ポート、ワイヤレスのドングル格納ソケットが配置されています。電源スイッチは右側面にあります。チルトスタンドは使った方が打ちやすい気がします。

f:id:kondoumh:20200605084818j:plain

軽量薄型キーボードとしてはストロークもそれなりにあって打ちやすいです。慣れれば Magic Keyboard よりいいかなと。

キー配列はコンパクトな JP キーボードとしてはまあ標準的です。Windows ではたまに使う Home と End がファンクションキーの並びにあるのはよいと思いました。しかし、右 Alt と Ctrl の間にねじ込まれている PrtSc は使わないので省いてピッチを広げて欲しかったですね。さらに PgUp/PgDn が左右カーソルキーのすぐ上に配置されているため、誤タイプでページングしてしまいびっくりします。ほぼ使わないので Fn のコンビネーションでいいと思いました。後述のようにリマップツールでカーソルキーにマッピングしちゃいました。

TrackPoint は専用のドライバーソフトウェアを導入しなくても Windwos / macOS 共に動作しました。ThinkPad X40 を使ってた頃はドームタイプのキャップを沢山ストックしてたりしましたが、今時は TrackPoint だけで頑張るのはつらいのでマウスや Trackpad と併用します。ホームポジションのままカーソルを動かせるのはやはりいいですね。

macOS では Karabiner-Elements でキーリマップしました。

HHKB でも使ってるやつです。

blog.kondoumh.com

Windows キーボードの共通設定。

f:id:kondoumh:20200607181302p:plain

TrackPoint Keyboard 固有の設定。

f:id:kondoumh:20200607181325p:plain

Windows では KeySwap を使いました。

KeySwap for XPの詳細情報 : Vector ソフトを探す!

かなり昔からあるレジストリ変更してキーマップを変えてしまうツールです。

f:id:kondoumh:20200607141657p:plain

もうちょいモダンなツールないかなとは思うのですが。

ともあれ、打ちやすいコンパクトキーボード1個で環境を切り替えられるようになったので満足しています。

Puppeteer Recorder でテスト用スクリプトを生成する

Puppeteer を使うと Web 画面の E2E テストが手軽に書けます。

github.com

ただ最近の Web UI は DOM 要素に ID が振られていないことが多く、Selector 書くのに Chrome DevTools などで要素をインスペクトしてパスをコードに貼り付けるという作業が多くなります。そうやって作ったスクリプトもサイトデザインの変更で動かなくなったりします。

Puppeteer Recorder はブラウザの操作を記録して、Puppeteer のスクリプトを生成してくれる Chrome 拡張です。

chrome.google.com

インストールすると拡張のアイコンから操作を記録可能になります。

f:id:kondoumh:20200603124701p:plain

Record ボタンをクリックして記録を開始します。kondoumh を検索して、僕のホームページを開くという操作をしてみました。イベントが記録されています。

f:id:kondoumh:20200603144235p:plain

ストップボタンを押すと Puppeteer のコードが表示され、クリップボードにコピーできるようになります。

f:id:kondoumh:20200603144301p:plain

生成されたコード

const puppeteer = require('puppeteer');
(async () => {
  const browser = await puppeteer.launch()
  const page = await browser.newPage()
  
  const navigationPromise = page.waitForNavigation()
  
  await navigationPromise
  
  await page.goto('https://www.google.com/search?q=kondoumh&oq=kondoumh&aqs=chrome.0.69i59j69i60l5.2485j0j7&sourceid=chrome&ie=UTF-8')
  
  await page.setViewport({ width: 1280, height: 689 })
  
  await page.waitForSelector('.g:nth-child(1) > .rc > .r > a > .LC20lb')
  await page.click('.g:nth-child(1) > .rc > .r > a > .LC20lb')
  
  await navigationPromise
  
  await browser.close()
})()

HTML 要素による判定とかは無理ですが、大枠の操作は手早く作れて便利だと思います。

Windows Terminal 正式リリース版をチェック

Windows Terminal Preview 版を触ったのは1年ぐらい前。

blog.kondoumh.com

最近正式リリースされたらしいと聞いていたので、会社の Let's note の Windows Update をかけてからバージョンを確認したところ、確かに 1.0 に到達していました。

f:id:kondoumh:20200531102400p:plain

起動時にエラーが出て、settings.json のフォーマットに breaking change があったことが分かりました。この issue の指示に従って、globals の内容をフラットに展開したらエラーは消えました。

github.com

ペインを水平・垂直に分けられたり、Direct Write でテキストレンダリングしてたり、コマンドプロンプトのリプレイスとしてリッチなターミナルが使えるようになったものです。

f:id:kondoumh:20200531104426p:plain

今は Git for Windows の bash をデフォルトにしてますが、Windows 10 May 2020 Update でリリースされた WSL 2 と共に試したいところ。Windows マシンも Update しないとですが。

Cloud Native Buildpacks を GitHub Actions で使うための Action 作ってます

Buildpacks ステキでした。

blog.kondoumh.com

これを社内プロジェクトの CI で使うために GitHub Actions の Action にすることを試みました*1

最初 Docker Action でサクッと作れるだろうとたかを括っていたのですが、よく考えるとコンテナイメージを Docker コンテナ内でビルドするので DinD (Docker in Docker) になってしまいます。かといって JavaScript Action でこういう CLI ラッパーを作るのはやだなぁと思って Docker の公式 dind イメージ使えばなんとかなるんじゃないかと試してみました。

docker/Dockerfile at master · docker-library/docker · GitHub

結果、問題なくイメージがビルドできました。

github.com

Marketplace に出すのはもう少し社内プロジェクトで評価してからにします。

2020.6.2 追記

Marketplace に公開しました。

github.com

*1:というか社内プロジェクトで使いたいという話でちょっと調べたのでした。

Dockerfile 記述不要の Cloud Native Buildpacks を使ってみる

アプリがコンテナイメージで配布されていると利用者側は導入が楽で便利です。しかし Dockerfile を記述するのはそれなりに経験が必要で、試行錯誤してるうちかなりの時間が溶けてることもままあります。Dockerfile 書いた後もセキュリティスキャンとか、ベースイメージ更新など色々とやることがあります。

Cloud Native Buildpacks は、プログラミング言語・フレームワーク・ビルドツールなどのアプリ構成に応じてコンテナイメージをよしなに作ってくれるツールです。元々 Heloku で開発されて今は CNCF*1 のプロジェクトになっています。

buildpacks.io

ドキュメントにしたがって macOS にインストール。

Installing `pack` · Cloud Native Buildpack Documentation

$ brew tap buildpack/tap
$ brew install pack

サンプルアプリの java-maven をビルドしてみます。

$ git clone https://github.com/buildpacks/samples
$ pack build sample-app --path samples/apps/java-maven --builder cnbs/sample-builder:bionic

SpringBoot アプリのようで、 maven のビルドが延々と続きます。

Successfully built image sample-app

と表示されると成功です。Dockerfile は1行も書いていません。

ビルドされたコンテナを実行。

f:id:kondoumh:20200525235151p:plain

localhost:8080 で起動されたアプリにアクセスできます。

f:id:kondoumh:20200525234247p:plain

コンテナイメージを表示してみるとちゃんと sample-app のイメージがビルドされています*2。 ビルドに必要なイメージも付随してビルドされている模様です。

docker image ls           

REPOSITORY              TAG                 IMAGE ID            CREATED             SIZE
cnbs/sample-stack-run   bionic              660461c452f1        3 weeks ago         71.2MB
cnbs/sample-builder     bionic              bcb0e9518efb        40 years ago        181MB
sample-app              latest              6c61aaf82fc8        40 years ago        301MB

プロジェクトの POM ファイルを解析してよしなにコンテナイメージをビルドしてくれました。SpringBoot アプリではもう自前で Dockerfile 書かなくてもよくなってるんですね。これはなかなかすごいです。

サンプルには、この java-maven の他に kotlin-gradle や ruby-bundler が含まれていていずれも同じようにコンテナを build / run できました。

Document によると Buildpack というモジュールにより、アプリのコードや構成を調査してフレームワークやビルド手順を検出しビルドする模様です。

Buildpack · Cloud Native Buildpack Documentation

このリポジトリでは、Java / .NET Core / Node.js / Go / PHP の Buildpack が公開されています。

github.com

GitHub から Node.js の サンプルを取ってきて Node.js の Buildpack を指定してイメージをビルドしてみます。

github.com

$ git clone git@github.com:contentful/the-example-app.nodejs.git
$ cd the-example-app.nodejs
$ pack build example-app-node:latest --builder gcr.io/paketo-buildpacks/builder:base
:
Successfully built image exapmple-app-node:latest

ビルド成功しました。docker run で実行してみます。

$ docker run --rm -p 3000:3000 example-app-node

> example-contentful-theExampleApp-js@0.0.0 start /workspace
> NODE_ENV=production node ./bin/www

Listening on http://localhost:3000

無事起動しました。

Vue.js のアプリは依存関係のライブラリのビルドに Python が必要だったりしてこの Buildpack ではビルドできませんでしたが、今後は Dockerfile 書かなくてもビルド・デプロイできるアプリが増えていきそうです。

Buildpacks にはベースイメージの rebase など運用上便利そうな機能もあり期待が持てます。

Rebase · Cloud Native Buildpack Documentation

*1:Cloud Native Comupting Foundation https://www.cncf.io/

*2:40年前に作られたという謎の状態ですが。

setup-terraform Action で Terraform 実行を簡潔に

HashiCorp から GitHub Actions の setup-terraform Action が登場しました。

github.com

公式ドキュメントはこちら

www.terraform.io

従来は terraform-github-actions が提供されていましたが、こちらは今凍結されています。

github.com

Terraform は init / validate / plan / apply と複数のサブコマンドを実行する必要がありますが、terraform-github-actions は Dockerfile Action のため繰り返し uses: で Action を実行する必要がありました。

setup-terraform は JavaScript Action であり、ワークフロー実行環境に terraform CLI を文字通りセットアップしてくれるので、run: でサブコマンドを自由に実行できます。

blog.kondoumh.com

以前 DigitalOcean の Droplets を作るワークフローを terraform-github-actions で作りました。

blog.kondoumh.com

Action を繰り返し適用しているためかなり冗長でした。setup-terraform に置き換えてみます。

PR 作成時のワークフロー

name: Terraform Plan for droplet

on:
  pull_request:
    types: [opened]

env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TF_TOKEN }}
  DIGITALOCEAN_TOKEN: ${{ secrets.DIGITALOCEAN_TOKEN }}

jobs:
  terraform:
    name: 'Terraform'
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout'
        uses: actions/checkout@v2
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1
        with:
          terraform_version: 0.12.24
      - name: 'Terraform Init'
        run: terraform init
      - name: 'Terraform Validate'
        run: terraform validate
      - name: 'Terraform Plan'
        run: terraform plan

PR マージ時のワークフロー

name: Terraform Apply droplet

on:
  pull_request:
    types: [closed]

env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TF_TOKEN }}
  DIGITALOCEAN_TOKEN: ${{ secrets.DIGITALOCEAN_TOKEN }}

jobs:
  terraform:
    name: 'Terraform'
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout'
        uses: actions/checkout@v2
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1
        with:
          terraform_version: 0.12.24
      - name: 'Terraform Init'
        run: terraform init
      - name: 'Terraform Apply'
        run: terraform apply -auto-approve
        if: github.event.pull_request.merged == true

かなり簡潔に書けるようになりました。

ノート・メモ環境 2020 (だいたい Scrapbox)

ノート・メモやタスク管理については過去にもちょいちょい書いてました。

blog.kondoumh.com

blog.kondoumh.com

blog.kondoumh.com

最近はやはり Scrapbox 中心になっています。

書きはじめ

作業計画や実装方式を検討する時などまとまったテキストを書く時、Scrapbox で scratchpad 的なページを作っておいてとにかく素早く書き始めるというのをやってます。Scrapbox は保存について考えなくてもよいので。よくやるテキストエディタの新規バッファで書くのは保存せずに終了させてしまった時のダメージが大きいし、ファイル名を付けるのはある程度内容が明確になるまではペンディングしたいというのがあります。

Markdown で書きたい場合、テキストエディタでは拡張子 .md などのファイルとして保存しないとシンタックスハイライトが効きません。Scrapbox のコードブロックを使えば code:hoge.md とか書くだけでシンタックスハイライト付きのテキストエリアを使えます。ある程度書いたら VS Code や Wiki に持っていきます。

Slack の個人チャンネルで書いてたこともあったのですが Markdown サポートが微妙になったのでやめました。

TODO 管理

ステイホームの影響で買い物を効率的にしないといけないので Google Keep に買うものリストを作るようになりました。Web サイトでも編集できて日常のタスク管理には充分そうです。

chrome.google.com

Trello はほとんど使わなくなり、役所手続きなど年単位の定期的なタスクの管理だけ残ってます。

blog.kondoumh.com

Scrapbox でも TODO 管理を試みたことがありますがちょっとなじみませんでした。

GitHub の Project board も開発にまつわるタスク管理には使っています。

プロジェクトボードについて - GitHub ヘルプ

作業ログ

Emacs で ChangeLog メモ書いてます (14年目!)。

blog.kondoumh.com

改行はしない縛りで80文字前後で箇条書きするようにしてます。「内容を想起できるギリギリの短いセンテンスを書く」という謎の能力が鍛えられるような・・。

文書作成

構造化文書も Scrapbox で書くことが増えました*1。Scrapbox -> Markdown 変換ツールを書いたのでエクスポートも簡単です。

blog.kondoumh.com

blog.kondoumh.com

Markdown 変換後は VS Code のプラグインで PDF に変換することも多いです。

marketplace.visualstudio.com

コードスニペット

これも Scrapbox のコードブロックに書いてます。Gist は全然使ってませんでしたが、使って行こうかなと思ってます。

まとめ

Scrapbox のカバレッジが広い。ステイホームもあってモバイルで何かを書くということも少なくなってますが、Scrapbox がモバイルでも使い勝手よくなってるのであまり変わらないかも。

*1:kibela もちょっと使ってたのですが動作が安定しないのとプレビューが面倒で使わなくなりました。