VSCode Extension

少し前に Status Bar Title という VSCode Extension を作った。全然大したことないのだが、2020年ももう終わりに近づくのに今年は全然書いていなかったので記録しておく。

ghq rootが複数あると最後のrootにcloneされるようになった

最初のrootが使われると思っていたが、最後(2つめ)が使われた。
調べてみると以下の issue があり、v0.17から挙動が変更されていた。当初意図したものではなかったようだが、今後この仕様になるとのこと。
https://github.com/motemen/ghq/issues/239

README には最初の root に clone されると説明されていたので、修正の pull request を送ったところすぐに修正を取り込んでいただけた。

というわけで、README の説明の通り ghq.root が複数定義されている場合は最後のものが clone に使われるので、ghq list に Go の GOPATH のような固有のパスを含めたい場合は ghq get で使ってほしいパスを最後に書くと良い。

EvernoteからSimplenoteに移行しようとしたがEvernoteに戻った

プライベートなメモは長らくEvernoteを使っていたが、ローカルのデータが大きくなりすぎるとか、コストを安くしたい(プレミアム版を使っていた)とか、Markdownを編集したいとか…そういった理由から、Evernoteの代替サービスを探していた。

結果として 2018 年の11月頃に Simplenote に乗り換えた。

ダークモードに対応

このサイトもダークモードに対応しておこうと思い、prefers-color-scheme を使って配色を分けるようにしてみた。

基本的な方法を解説しているブログは多数あるので、その上で必要だった工夫をメモ。

全体の構成の方針としては、CSS変数を活用してライトモードとの重複コード、または漏れを防ぐようにした。

以下はCSSの構成イメージ。

Blogger Accessibility Performance改善

以前改善してからまた時間がたったので、改めてLighthouseの点数改善にチャレンジ。

なお、Chromeでログインして拡張機能でLighthouseを使っている場合、シークレットウィンドウからの実行を許可した上でシークレットウィンドウから実行しないと、キャッシュが使われてしまい正しい結果が出ない。
lighthouse の npm コマンドで実行するのが無難。

かなり今さらながらghqやpecoなどをきちんと使ってみる

今さらすぎるだろという話ではあるのだが、ghq、pecoなどのツールを、知っていたけどちゃんと普段使いしたことがなかった。以前は Java 中心の開発をしていたせいか CLI はそれほど身近でないというか、あまり高頻度に使わなくても問題のない世界だった。今の職場では、こうしたツールなしでは難があるなと感じてようやく導入した。今さら書くのも恥ずかしい気はするのだが…いくつか気づきや工夫があったので書いておきたい。

Terraform: API Gatewayでdeploymentとstageでstage_nameがconflictする

プライベートでVPSを借りて動かしている古いAPIがある。これをAWSに移行しようと考えており、その過程でTerraformを使ってコード化を進めている。

その中で API Gateway を使っているのだが、stage、deploymentのresourceを普通に定義していったところ、conflictしてしまい正常に実行できなかった。

ghqのroot配下ではVCS導入しないとghq listが遅くなる

今さらながら ghq を使うのをデフォルトにしようと考えてローカルにあるリポジトリをすべて ghq の root に移したところ、ghq list がだいぶ遅くなったように感じた。

以下が原因＆解決策であった。
https://hirakiuc.hatenablog.com/entry/2017/05/06/205846

バージョン管理システムがないディレクトリが多数含まれていると遅くなってしまうらしい。

サンプルプロジェクトは ~/.ghq/github.com/ksoichiro に移動してあったため、そのディレクトリで以下を実行して git 管理としたところ改善した。(管理といっても git init しているだけ)

for i in $(ls -1); do if [ ! -f $i/.git/config ]; then echo "$i is not in vcs"; pushd $i > /dev/null; git init; popd > /dev/null; fi; done

一区切り...

2019年は自分にとって大きな変化のあった年となった。あまりそれ自体については詳しくは書かないつもりだが、具体的にいうと転職して12月から新しい職場で働いている。

このブログの更新も停滞していたが、これを機に再開していきたい。

GitLab CI をセットアップする

今さらだが、自分でセットアップする機会ができたので。

ただのセットアップは公式のマニュアルなどで確認できるので、ここでは実際にビルド、テスト、レビューで活用できるようにするためのことを書く。
かなりの長文なので注意。

yEdの基本的な操作方法＋α

yEd の基本操作を確認する。
内容は独立しているが、一応以下の続き。

yEdでジョブフロー図っぽいものを描く: Edge Routing
yEdでジョブフロー図っぽいものを描く: Layout

yEdをすごく気に入っているような感じになってきているが…あくまで評価の過程。
なお、操作は Windows 10 で行っている。

yEdでジョブフロー図っぽいものを描く: Layout

yEdでどこまで描けるか？本当に良いかを確認するためいくつか図を描いてみる。以下の続編。
yEdでジョブフロー図っぽいものを描く: Edge Routing

ベースとなる図

前回同様に以下をいじってみる。

レイアウトといいながらEdge Routingから入ってしまったが、今回はメニューのLayout直下の項目を試す。

yEdでジョブフロー図っぽいものを描く: Edge Routing

yEdでどこまで描けるか？本当に良いかを確認するためいくつか図を描いてみる。

ベースとなる図の作成

まずPaletteのFlowchartのSectionから、適当にボックスをドラッグアンドドロップする。

ダブルクリックでラベルを入力。

オブジェクトからオブジェクトへドラッグするとラインが引かれる。

オブジェクトの配置の際には、ガイドとなるラインが表示されるため縦横とも周囲の部品と合わせた位置に置くことができる。

ここまでで作れたのが以下。

レイアウトをいろいろとうまくやってくれるのが yEd の良いところのようなので試してみる。今回はEdge Routing。

マークアップ言語によるドキュメント作成

大げさなタイトル？な感じもするが、MarkdownかAsciiDocで技術ドキュメントを書けないかなと改めて調べたことを記録する。

結論としては、MarkdownとyEdが良さそうだと思っている。
(すぐにまた評価が変わるかもしれないが…)

GitLab v7.9.4 のサーバ移行とアップグレード

GitLab Omnibus Package でインストールして運用してきた古い GitLab を別のサーバに移行し、最新版にアップグレードしたい。

ここでは v7.9.4 からの移行とアップグレードを考える。

サーバ移行については、データバックアップが取れるのでそれを新環境で取り込めば良い。

アップグレードについては Omnibus Package でインストールしたものなら基本的に以下を参照すればできる。
https://docs.gitlab.com/omnibus/update/

メジャーバージョンアップはバージョンをまたがない方がよい(1つずつ上げる)ということで、何度かに分けて上げる。

基本的に公式ドキュメントに記載されていることを正しく読み取って組み合わせれば良いのだが、以下では今回のケースで必要なことを事例として説明する。

Android ナイトモードをダークテーマとして提供する

以前の以下のエントリの関連。
Android ナイトモードを起動時に設定するとonCreateが二度呼ばれる

ナイトモードは時間に応じて自動的に変わる設定もできて、そのようになっているアプリもある。ただ、いくつかのアプリを調べてみた感じでは、現状ではON/OFFの設定のみのアプリが多い印象。三日月のアイコンをタップするとON/OFFが切り替わったり、ダークテーマ、ダークモードなど別の名前で提供されているものも多い。

ON/OFFの切り替えだけなら実質的にはテーマの変更であって、テーマの変更として実現すれば configuration の変更にならず onCreate の二重呼び出しなども発生しない。ナイトモードを適用したからといって起動が遅いのは何かを見落としているのかもしれないが、現状では、単純なON/OFFで提供したいならテーマとして提供する方法が無難かもしれない。

以下、ナイトモードの実装状況について確認したアプリについて記録しておく。

Node.js の csv-stringify で CSV レコード内の改行をダブルクォートで括る

Node.js で csv-stringify による CSV 出力をする際、項目(レコード)に何種類かの文字があった場合はダブルクォートで括るようにしたい。

csv-stringify が大体勝手にやってくれるが、現時点の最新版 v5.1.2 では改行の一部の取扱いが期待通りでなかった。

• 行のデリミタが LF なら項目内に LF が含まれているとダブルクォートで括られる。→期待通り
• 行のデリミタが CRLF なら項目内に CRLF が含まれているとダブルクォートで括られる。→期待通り
• 行のデリミタが CRLF なら項目内に LF が含まれていてもダブルクォートで括られない。→期待と異なる
  

Android Studio (Asset Studio) で扱える SVG 画像を Inkscape で作る場合の注意点 (グラデーション)

Asset Studio で、Inkscape で作成した SVG 画像を扱うとき、Inkscape 特有のタグなどのせいでエラーが発生する場合は「プレーンSVG」として保存すれば良さそう。
ただ、この場合は Inkscape のデータが失われる。

参考:
https://graphicdesign.stackexchange.com/questions/82219/how-to-create-proper-vector-images-that-can-be-used-as-an-android-vector-drawabl

グラデーションに関しては上記では解決せず、
例えば ic_launcher.svg などを Inkscape で作って Asset Studio でアップロードしようとすると

ERROR @ line 83: Gradient has no stop info

のようなエラーが出て、グラデーションが適用されない。

フォーマッタの自動適用

前のエントリでも紹介した node-archiver-zip-encryptable の開発では Prettier を適用したが、フォーマットの統一に注意を払わなくて済むのは非常に快適だった。
ルーツが何かは調べられていないが、過去の自分の経験の中で似たようなものには Golang の gofmt があった。
Java のプロジェクトでも適用できないものかと思ったが、 prettier-java は現在 Work in Progress の状態。

vim でタスク管理

これもまた少し前の話になるが、vim スクリプトで簡単なタスク管理用スクリプトを作った。
結果は以下のようなイメージ。

~/.vimrc

要件

タスク管理のツールは世の中に数え切れないほどあるが、自分の場合は以下のようなことが要件で、ちょうど良いものが見つからなかった。