AtomからVSCodeに乗り換えたので使ってる拡張パッケージを対応表にしてみた

  1. 1. 使用感比較
    1. 1.1. UI
    2. 1.2. 見た目のカスタマイズ
    3. 1.3. パフォーマンス
  2. 2. 選択系、変換、入力補助(エディタ操作)
  3. 3. ファイル、タブ、ペイン操作系
  4. 4. HyperClick系
  5. 5. ミニマップ
  6. 6. その他、機能拡張
  7. 7. Linter系(Atomのみ)
  8. 8. 各言語とか用途とか別
    1. 8.1. Git
    2. 8.2. Markdown
    3. 8.3. JSON
    4. 8.4. Ruby
    5. 8.5. JavaScript系(Node.jsやメタ言語、フレームワーク含む)
    6. 8.6. HTML系(メタ言語含む)
    7. 8.7. CSS系(メタ言語含む)
    8. 8.8. PUML
    9. 8.9. その他の言語系
  9. 9. おしまいに

年末年始にAtomの使ってるプラグインを列挙して棚卸しをしたけども、ちょっと前のMSのGitHubの買収を機に食わず嫌いしてたVSCodeを使ってみた。

ただし使うにあたってはAtomで使ってる環境と同程度のことができてくれないとダメなので調べてみた。

結果から言って今はVSCodeに乗り換えてしまった。せっかくなので使ってるAtomとVSCodeの拡張パッケージをそれぞれ対応する表にしてみた。ちなみに元々「俺のAtomは環境だ」と笑い話的に言っていたのでややAtom寄りの表になってるのはご容赦いただきたい。

使用感比較

拡張パッケージ表に行くまえに使用感を比較した所感。100%満足はしてないもののパフォーマンスの恩恵が大きく、なんとかAtomでできたことを損なうことなくVSCodeでも許容できるレベルにもっていけたのが乗り換えの決め手。

UI

ほとんどどちらも同じような感じで差異は大きくない。ただ、プロジェクト内から文字列検索した時の結果表示がAtomのほうがエディタ部に表示されるのでわかりやすい。VSCodeだとエクスプローラー部分に表示されるのが小さくてみづらい。

またキーバインドの設定はAtomイベントが発火したのか表示できるけど、VSCodeは表示する機構がないで、コンフリクトしてるキーバインドのデバッグが非常にしづらい。

見た目のカスタマイズ

見ためのカスタマイズは完全にAtomのほうが柔軟。これはDevToolsを開ける上、設定のLESSファイルを自由に編集できる。ということは変更したい箇所のセレクタにCSSを書いてあげることで如何様にもなる。

一方VSCodeは全てではないものの主要箇所はできて、まあ必要十分かな、という感じではある。個人的にはツリービュー(エクスプローラー)の文字サイズや行の高さなどはカスタムしたいけどできないのがもどかしい。

パフォーマンス

よくAtomは遅いと言われるけど、うん、まあ否定できない。それでも一応速くはなったんだけど。あとログファイルみたいに大きなファイルを開くとビーチボールがぐるぐるしてどうしようもなくなることがある。

VSCodeは最初の表示は速い。ウインドウの起動はちょっとかかるけどAtomに比べたら軽い。またファイル表示はキビキビ開く。ただし、これはどうもLinterやシンタックスハイライトなんかは開いた後でやってるような感じ。まず表示を優先する、みたいな挙動っぽい。大きなファイルは大きすぎた時はまず警告出してくれるので助かる。


さて、以下に拡張機能を列挙していくんだけど、自分で探す場合の注意としてはVSCodeのパッケージは検索すると同名のものが出てきたりする。同名のものをフォークして上げただけ、みたいな感じっぽいけどインストールの際はちょっと注意したい。

また、見つからなかったものは[-]とかって書いてあるけど、単に検索力が足りなかったり別のパッケージの一部にその代替機能が含まれてたりする可能性はあるのでご注意されたし。

選択系、変換、入力補助(エディタ操作)

概要 詳細 Atom Package VSCode Package
矩形選択 SublimeText的な矩形選択。見たままの四角の範囲を選択可能。 Sublime-Style-Column-Selection -
選択範囲を段階ごとに広げる 選択範囲を文字、単語、クォートや括弧で囲んだ要素、と順々に大きくできる。 expand-region expand-region
キャレット列のハイライト - highlight-column -
キャレット行のハイライト - highlight-line ビルトイン
選択した文字列のハイライト 選択してるものと同じ文字列をハイライト。 highlight-selected -
ブラケットハイライト 対応するブラケットをハイライト ビルトイン -
ブラケットカラーハイライト 対応するブラケットごとに色をかえてわかりやすく表示 bracket-colorizer Bracket Pair Colorizer
文字ケースの相互変換 キャメルケースとスネークケースだけでなく、ケバブケースもドット記法なども幅広く対応してるのでうれしい。 change-case change-case
クォーテーションマークを相互に変換 シングルクォートとダブルクォートのトグルだけでなく、設定でバッククォートも対応できる。 toggle-quotes Toggle Quotes
二元的要素のトグル変換 true/falseなどをトグルで変換。設定で対応文字列をカスタマイズ可能。 toggler toggler
タブ-スペース変換 インデントのタブorスペースをトグル変換。 tabs-to-spaces ビルトイン
セミコロンやカンマ付与 今キャレットがどの列にあろうとも現在の行末にセミコロンとカンマをつける。キーバインドで設定すると捗る。 trailing-semicolon toggle semicolon
行末スペース制御 行末のスペースを目立たせたり自動で削除したり。Atomはスタイルをカスタムすると良い感じ trailing-spaces Trailing Spaces
全角スペース制御 全角スペースを強調表示。Atomはスタイルをカスタムすると良い感じ。 show-ideographic-space EvilInspector
制御文字の制御 BackSpaceなど制御文字を削除するフォーマッタ。不意に紛れこむと思わぬバグを起こすのでありがたい。 - Remove backspace control character
連番の数字を挿入 複数行にわたって一括で連番生成。 sequential-number vscode-input-sequence
選択した複数行をソート 選択した範囲に含まれる複数行をアルファベット順や逆順などでソート lines Sort lines
カラーコードの部分だけカラー表示 カラーコードになってる文字列の背景色をその色で表示。CSSとか書くときに便利。StylusやSassの変数も対応してるので重宝する。 pigments Color Highlight
正規表現補助 正規表現をビジュアルで表示してくれる。 regex-railroad-diagram Regex Railroad Diagrams
Path入力補完 Path入力補完、でもたまに邪魔なときがある気がする。 autocomplete-paths Path Intellisense
列のフォーマッタ オブジェクトの定義とか、連続して変数に値を入れるとき、=:をセパレータとして左右のインデントが揃うようにしてくれるフォーマッタ。言語別のものもある。 aligner Better Align
インデントフォーマット ネストした要素のインデントをうまいこと整形してくれるフォーマッタ。JSONとかも良い感じにやってくれたり。けっこういろいろ対応してる。 atom-beautify Beautify
高機能マルチカーソル デフォルトより高機能なマルチカーソル。キーバインドがバッティングしやすいので要カスタム。 multi-cursor-plus -
キャレットの行移動補助 設定した行数文だけキャレットを一気に移動する。Emacsのページ送り的な送り用途として使える。 line-jumper line-jumper

ファイル、タブ、ペイン操作系

概要 詳細 Atom Package VSCode Package
ペイン自動最大化 複数Paneで分割してる時にアクティブなペインを自動的にほぼ最大化する。フォーカスしたペインを自動的に最大化したりもできる。 hey-pane -
ツリービューのフィルタ ツリービューで表示しているファイルをインクリメンタルに絞り込む。 tree-view-filter -
タブの規制 最大タブ数の設定制御。設定数を越えると古いタブから自動的に閉じて入れ変わる挙動になる。設定でピン止めしたファイルや、未コミットファイル除外したりもできる。たくさんファイル開きすぎてわかんなくなっちゃうので。 zentabs -
メソッド定義などのツリー表示 定義されたメソッド、変数などをサイドドロワーにツリー表示 symbols-tree-view ビルトイン
TODOコメントの抽出 プロジェクト内に存在するTODOやNOTEなどのコメントを抽出して表示。 todo-show Todo Tree
GHQ連携 CLIリポジトリ管理ツールghqの管理下にあるプロジェクトのショートカット。全てのプロジェクトがGit管理されていれば、プロジェクトマネージャーはこれだけで十分だと思う。 douglas vscode-ghq
変更ファイルの強調 ツリービュー(エクスプローラー)上でGitステータス▽による色分け表示する。追加ファイルや変更したファイルとかが視覚的にわかりやすいし、未コミットのファイルもみつけやすい。 tree-view-git-status ビルトイン
ファイルエンコーディング判別 エンコーディングの自動判別。 auto-encoding ビルトイン
ファイルエンコーディング変換 マルチバイトのファイルをutf-8に変換。 convert-to-utf8 -
FuzzyGrepファイル検索 プロジェクト内をag的なfuzzyGrepしてファイル表示。 atom-fuzzy-grep -
ディレクトリごとのファイル操作 ディレクトリごとに絞り込みでファイルを開ける、フルキーボードで階層ごとに掘っていく場合に便利。 advanced-open-file -
Expose風タブ操作 開いてるタブをmacのexpose的に表示、切り替えできるやつ。 expose -

HyperClick系

概要 詳細 Atom Package VSCode Package
HyperClick コード中のいろんな要素がクリッカブルになる。キーバインドにも対応していて対象の文字列にキャレットがあるときはキー操作でも動作する。**-hyperclick系のアドオンとかで拡張可能。言語特化のアドオンは後述の言語別のところで。 hyperclick -
HyperClickのURL対応 URLをクリッカブルにしてデフォルトブラウザで開けるようになる。 hyperlink-hyperclick ビルトイン

ミニマップ

概要 詳細 Atom Package VSCode Package
Minimap サイドドロワーにコード全体をざっと単純化して見わたせるようなやつを表示。他のパッケージで拡張可能。 minimap ビルトイン
Minimap選択文字列ハイライト Minimap内で選択した文字を全てハイライト。 minimap-highlight-selected select highlight in minimap
Minimapを自動で隠す ミニマップをスクロールしてないとき以外は自動的に非表示 minimap-autohider -
Mimimap内検索文字列ハイライト ミニマップ内で検索文字列を全てハイライト。 minimap-find-and-replace ビルトイン
Minimapカラーコード表示 ミニマップ内でカラーコード部分をカラー表示。 minimap-pigments -

その他、機能拡張

概要 詳細 Atom Package VSCode Package
多人数同時編集 他の人とつなげて同時にシェアしながらコーディングできる。モブプロ、ペアプロなどでものすごい活躍する。 teletype VS Live Share
Atomキーマップコンフィグ Atomでデフォルトのキーマップに一括で変更する ビルトイン Atom Keymap
コーディングフォーマットの統一 EditorConfigの対応。プロジェクトルートに.editorconfigという設定ファイルを置いて制御。 editorconfig EditorConfig for VS Code
設定の共有、同期 GitHubGist経由でエディタの設定、インストールしているアドオン情報を複数端末で同期する。 sync-settings Settings Sync
ノートテイキング 検索しやすいノートシステムをエディタに組み込み、メモやスニペットなどの一元管理を自分のカスタマイズしたエディタで編集できるのは強み。Atom版はnotational-velocityライクでかなり使いやすい。 atom-notes VSNotes
ブラウザ連携 同名のGoogleChrome拡張をブラウザに入れることで、ブラウザで開いてるページのテキストエリアを同期的にエディタで編集できるようになる。例えばPull RequestなどMarkdown対応のテキストエリアをエディタで編集できるのはかなり便利。 atomic-chrome GhostText
ターミナル エディタ内でターミナルを動作させる platformio-ide-terminal ビルトイン
CSVエディタ エディタからCSVを表計算アプリケーションのように表示、編集できる tablr Excel Viewer
拡張パッケージ管理 パッケージにアップデートがあったら自動でアップデートする。ちょいちょい自分で確認しなくていいので楽。 auto-update-packages ビルトイン
ファイルアイコン ツリービュー(エクスプローラー)やタブにファイルのアイコンを表示して視認性を上げる。VSCodeでは各種テーマでさらにカスタム可能。 file-icons ビルトイン
ファイルタイプの判別補助 自動で判別されるファイルタイプのルールをカスタマイズを楽にする。 file-types -
差分表示、補助 Paneで分割してDiff表示、見やすい。しかも保存してない状態でもDiffとれるので、長大な文字列とか大きめなオブジェクトを一時的に比較するときも重宝する。 split-diff Partial Diff
コードプリプロセス プリプロセッサ言語から元言語へ変換。 preview -
ステータスアイコン ステータスバーに状況表示アイコンをプラス。確かAtom用のLinterと一緒に入ってくるはず。 busy-signal -
ウィンドウタイトルのカスタマイズ Atomのウィンドウに表示されるタイトルのルールを変更できるようになる。上手く好きなようにファイル名の表示とかにカスタマイズすると地味に便利。 custom-title -
定義元にジャンプ メソッドの定義元にジャンプできるようになる。 goto-definition -
ステータスバーにファイル名表示 現在開いているファイル名とファイルパスをステータスバーに表示 ビルトイン Active File In StatusBar

Linter系(Atomのみ)

概要 詳細 Atom Package VSCode Package
Linter Linter機能。各言語用のPackageを別途追加が必要。各言語用のLintは後述。 linter -
Linter表示 Linter表示用UI。たぶんLinter入れると入ってくるはず。 linter-ui-default -

各言語とか用途とか別

Git

概要 詳細 Atom Package VSCode Package
Git総合サポート Git周りのこといろいろ - GitLens — Git supercharged
Git履歴表示 Git logビューア git-log Git History
Git変更内容アイコン AtomにビルトインのステータスバーにGitのファイル変更状況アイコンを表示する - Git Indicators
gitignoreサポート gitignore用のシンタックスハイライト - gitignore
Gist GitHubのGistを編集したりアップロードしたり、挿入したり。Gist系はいくつかあったけどこれが一番使いやすかった。 gist -
Git Blame表示 行ごとにGitで変更した人を表示する。 git-blame GitLens — Git supercharged
Git操作ショートカット よく使うGit操作をAtomから直でできる、Atomのコマンド補完が効くので便利、基本的なgit操作はこれだけでいける。ビルトインのものでも十分だがあると便利 git-plus -
コンフリクトのサポート Gitでmergeしようとしてコンフリクトしたときの編集サポート。 merge-conflicts ビルトイン
ホスティングサービス対応 GitHubなどのホスティングサービスを開いたり、プルリクエストページを開いたりできる。GitHubだけでなくBitbucketなど他のサービスにも対応しててうれしい - Open in GitHub, Bitbucket, Gitlab, VisualStudio.com

Markdown

概要 詳細 Atom Package VSCode Package
Markdown表示の拡張 デフォルトのMarkdownプレビューより高機能なプレビュー、TOCやプレゼンモードもあったりする。目次機能もあったり、いろいろと便利。 markdown-preview-enhanced Markdown Preview Enhanced
入力補助 Markdownの全般的な入力補助。とりあえず入れてる。 markdown-writer Markdown All in One
目次自動生成 編集中のMarkdownの目次を自動生成 Markdown TOC Markdown All in One
テーブル記法補助 Markdownのテーブル記法編集補助、うまいこと縦のカラム表示を整えてくれる。 markdown-table-editor Markdown All in One
テーブル記法補助2 別のMarkdownのテーブル記法編集補助 Markdown Table Formatter Markdown All in One
Markdown目次機能 ドロワーやエクスプローラーに編集中のMarkdownの目次をページ内リンク付きで表示。 document-outline ビルトイン
タスク記法のトグル Markdownのチェックボックス記法のチェック状態のトグル変換。そんなに使わないけどいちいちキャレットを移動するのが面倒なので。 toggle-markdown-task Markdown Checkboxes
フォーマッタ 番号付きリスト記法の番号振りなおしなど、フォーマッタ。 tidy-markdown -
シンタックスハイライト Atomデフォルトのものより高機能なハイライタ。 language-markdown -
TextLint 特に日本語に強い自然言語用のLinter、textlintをAtomで使えるように。Markdown以外でも効く。 linter-textlint vscode-textlint

JSON

概要 詳細 Atom Package VSCode Package
シンタックスハイライト(階層) JSONファイルを階層によってカラーリングを変えて視認性を上げる。 atom-json-color -
フォーマッタ JSONファイルの整形フォーマッタ。 pretty-json JSON Tools
Linter JSON用のLinterアドオン。 linter-jsonlint -
ソート JSONオブジェクトをアルファベット順などでソートできる。 - Sort JSON objects

Ruby

概要 詳細 Atom Package VSCode Package
総合サポート - Ruby Ruby
Hamlサポート haml用の言語ファイル。 language-haml Ruby Haml
Slimサポート Slim用の言語ファイル。 language-slim Slim
Rspecサポート Rspec(Rubyのテストフレームワーク)用の言語ファイル。 language-rspec rspec-snippets
Rablサポート Rabl(RubyOnRails用のJSONやxmlに特化したテンプレートサポートGem)用の言語ファイル。 language-rabl -
Linter(RuboCop) Rubocop用のLinterアドオン。 linter-rubocop ruby-rubocop
Linter(erb) erb用Linter linter-erb -
Linter(Haml) Haml用Linter linter-haml -
Linter(Slim) Slim用Linter linter-slim -
入力補完 Ruby用の入力補完。別途Solagraph Gemのインストールが必要。 autocomplete-ruby Ruby Solargraph
自動修正 Rubocopルールに従って自動修正。 rubocop-auto-correct -
フォーマッタ Ruby用フォーマッタのrufoをエディタから実行。JSのprettier用のプラグインのほうが主流になりそうな感じ。 rufo-atom rufo (Ruby formatter)
Railsサポート - - Ruby on Rails
Railsパーシャルビューサポート Railsのパーシャルビューの自動補完 autocomplete-rails-partial -
Rspecファイルを開く 現在開いてるファイルに対応したRspecのファイルを開く。 rails-open-rspec -
Rspecの実行 エディタからRspecをrun。 rspec Rails Run Specs
ブロック文法の補助 do,if,begenendなどの対になるブロック要素をハイライト。 ruby-block -
i18nサポート Railsのi18n用のAutocompleteとHyperClickアドオンのセット rails-i18n-plus -
Rails補助 Rails用のスニペット集。 rails-snippets Ruby on Rails
Rails補助(ファイル) Model,View,Controllerなど対応するファイル同士を素早く開けるようにする。 rails-transporter -

JavaScript系(Node.jsやメタ言語、フレームワーク含む)

ちなみにPrettier系入れずにプロジェクトにESlintと統合するeslint-plugin-pretteirを使って統合している。

概要 詳細 Atom Package VSCode Package
TypeScriptサポート TypeScriptの言語ファイルか補完や便利機能まで、IDE的サポート。 atom-typescript ビルトイン
Vue.jsサポート Vue.js用の言語ファイル。 language-vue Vetur
Vuc.js入力補完 Vue.js用Autocompleteアドオン。 vue2-autocomplete Vetur
ESlint JavaScript用のLinterであるEslintサポート、prettierと連携も可。 linter-eslint ESLint
JS用HyperClick JavaScript用のHyperClickアドオン。 js-hyperclick -
Vue.js用HyperClickアドオン Vue.js用HyperClickアドオン。 vue-hyperclick -
Jestサポート JS用テストフレームワークJestのサポート - Jest

HTML系(メタ言語含む)

概要 詳細 Atom Package VSCode Package
Pugサポート - language-pug Pug (Jade) snippets
HTML用Linter HTML用Linterアドオン。 linter-htmlhint -
Pug用Linter Pug用Linterアドオン。 linter-pug -
HTMLタグ補完 HTMLの閉じタグのショートカットと補完。Pugで書けばいらないんだけどね。 tag Auto Close Tag
Emmetサポート html,css(プリプロセッサ含む)の強力なスニペット集。 emmet ビルトイン
インデント記法サポート Jade(pug)やStylus,Sassのインデントベース記法の環境で、現在のキャレットの位置がどの要素のネスト中なのかツールチップで表示。 indent-tooltip -

CSS系(メタ言語含む)

概要 詳細 Atom Package VSCode Package
Stylusサポート Stylus用の言語ファイルとスニペット集。 Stylus language-stylus
Stylus自動補完 Stylus用のAutocompleteアドオン。 autocomplete-css-with-stylus-support -
Stylusフォーマッタ Stylus用フォーマッタSupremacyサポート、かなり柔軟な設定が可能。 - Manta’s Stylus Supremacy
Stylus用Linter Stylus用のLinterアドオン。 linter-stylint Stylint
CSS用Linter CSS用のLinterアドオン。 linter-stylelint stylelint
Sass用Linter SCSS(SASS含む)のLinterアドオン。 linter-scss-lint Sass Lint

PUML

UMLをテキストから表現したもの。
細かいレイアウトは難しいもののテキストならGit管理もできるし素早くかけるので覚えてよかった。

概要 詳細 Atom Package VSCode Package
PlantUMLサポート PlantUMLの言語ファイル language-plantuml PlantUML
PlantUMLビューア PlantUML用のUMLを表示 plantuml-viewer PlantUML

その他の言語系

概要 詳細 Atom Package VSCode Package
Apache Apacheのコンフィグ用 language-apache Apache Conf
nginx nginxのコンフィグ用 language-nginx nginx.conf
Lisp Lispサポート language-lisp Lisp
envファイル 環境変数を設定するenvファイルのシンタックスハイライト DotENV -

おしまいに

VSCodeに乗り換えたものの、今もAtomは好きだし、なんとなくVSCodeは好きになれない。もしかしたらあるイベントで好きでAtom使ってるところにかなり無理にVSCodeを勧められた経験からかもしれない。(やれ補完がどうとか。それはVSCodeの機能ではなくLanguage Serverだ)

Web上でもVSCode推しみたいのを良く見る。しかもAtomを貶めてまで。エディタは宗派で戦争になるためそういう推し方は好きじゃないんだよなぁ。あ、あれだインド行った時、自分の旅の一部としてとても楽しかったけど、インド推ししてる日本人の方々をどうも好きになれなかった感じと似ている。

なんにせよどんなエディタを使おうにもこういう拡張が充実してきてみんなが平和に好きなエディタを心地良く使う世の中がいいよね。

ちゃんとしたGitコミットメッセージをCommitzenを日本語で使って楽に書く

  1. 1. 決定打は’Commitzen’
  2. 2. タイプ、スコープの効能
  3. 3. 日本語でどうしましょ?
  4. 4. Commitzenを少しだけ日本人に優しくしました
    1. 4.1. 使い方
  5. 5. もうちょっと拡張するには
    1. 5.1. 使い方

Gitを使うようになって以来、使えば使うほどこれは良いバージョン管理だなぁと関心する。その反面、コミットに対しての悩みはつきない。コミットメッセージ、粒度。そのへんをどうしたら良いのか決定打が無いまま、ちゃんとしてるっぽいようにできてはいるけど今イチ自信がないままだった。

そう思いつつもいろいろと思考錯誤してようやく最近ではこれで行こう! と自信もって上手くできてる感がでてきたのでそのへんのことを共有していこう。

決定打は’Commitzen’

Commitzenは一言で言えば対話的にコミットメッセージを作るやつ。NPMで配布されていて、Angularで使われているコミットメッセージのルールが元になってるそうな。

簡単に言えば

Type(Scope): Title

Body

というメッセージルールで書く。ScopeBodyに関してはオプショナルでなくても可。
タイプは例えば、feat, fix, style とか。大項目みたいな。
スコープは言わずもがな。変更範囲。タイトルは普通のコミットメッセージみたいなコミットの要約で、Bodyはさらに細かい説明、これはよくある1行空けて詳細を説明、みたいなのと一緒。
これを対話的に

  1. このコミットのタイプは? (選択式)
  2. スコープは?(enterでスキップ)
  3. コミットの要約
  4. さらに細かい説明(オプショナル)
  5. 破壊的変更について
  6. 関連するissueについて

みたいな感じで質問に答えるように入力する。こうすることによって「うーん、コミットメッセージ、どう書こう」みたいなのをちょっと楽にしてくれる。さらには、タイプを選択式にすることによってメッセージの統一性を強制し、スコープをちゃんと考える契機にもなる。

タイプ、スコープの効能

実はメッセージを入力するのが楽になるだけじゃなくて「メッセージと内容の整合性」をちゃんと意識してる場合、変更内容の粒度や区切りもある程度しっかりしてくる。

バグ修正のコミットに機能追加を含めてはいけない。後からアレコレしたい場合に無理が生じてくる。Gitの良いところは履歴であり戻れることなので、戻りやすく、選択できるレベルにしておくのが良い。だけど例えばバグ修正と機能追加が1つのコミットにある場合、バグ修正は取り込みたいけど、機能追加は問題があって取りこみたくない、という場合に死ぬ。

さらにconventional-changelogというのがcommitzenプロジェクトの一環にある。これはこのタイプを自動で判別してCHANGELOG.mdを自動生成したり、セマンティックバージョニングをコントロールする方法。簡単に言えばfixが含まれていれば0.0.1(patch)上がってfeatが含まれていれば0.1.0(minor)上がる。

日本語でどうしましょ?

僕は個人的に言えばプライベートなものかつ、日本人のみのチームで作業されるものは日本語コミットメッセージで良いと思ってる。コミットメッセージを書くためにうんうん悩んで時間を浪費したりするのは本質じゃないし、読むときもいちいち機械翻訳にかけて理解するのももったいない。

ただし、被検索性は高くもっていたいのでそれなりなルールは必要で、コミットメッセージに日本語か嫌われるのはこのへんが大きいとにらんでる。問題は文法と表記のあいまいさ。

英語だとSVC文法で、さらに本質から先に出てくる。日本語は逆でSCVというか、大切なことほど後にでてくる(ごめんなさい、このへんの言語的な細かいことは正確に解説できる知識がないです)

fix SomeClass work properly

というメッセージと

SomeClassが正しく動作するように修正

というメッセージ、どっちが見やすい? 英語のほうが理解しやすいように思う。後からコミットメッセージをもとに探す場合、もう何でさがしたらいいかわからない。バグフィクスって書く? 修正って書く? っていう表記揺れだったり、「修正」が最後に来るので目で追う場合もズレる。文字数が多くなって自動でBodyに送られた場合はさらにキツい。

で、じゃあ表記揺れをルールで縛ってある程度書き方も一文じゃなくて配慮したルールにしてみたとしよう(これは以前僕が日本語コミットを書くなら、と独自に考えてみたもの)

修正: SomeClassが正しく動作するように

もしくは「修正」を外に出したので説明を追加すると

修正: SomeClassが正しく動作するようにsome-functionを追加

とか。これならまず本質が「修正」であることがわかるし、メッセージの最初が主語なのでSomeClassに対する修正だな、とわかりやすいと思う。そしてこれをAngularルールで書いてさらに日本語を混ぜると

fix(SomeClass): add some-function for working properly

fix(SomeClass): 正しく動作するようにsome-functionを追加

日本語話者にとってもタイプとスコープ程度は英語でも誰も困らないし、ちゃんと明記されてるし、その後の説明は日本語でも何をしたのかわかるし。まずタイプとスコープを最初に固定することでそのあとメッセージがもうちょっと変更内容をちゃんと説明しやすく書ける。

これだと日本語コミットでもわかりやすいし、バランスも良いと思う。もちろんパブリックなリポジトリや日本語話者のみで構成されていなければ英語で書くべきなのは言うまでもないけど。

Commitzenを少しだけ日本人に優しくしました

そんなわけで、日本語で書こうが英語で書こうがCommitzenが役に立つのはわかってもらえたはず。で、日本語で書くような場合、対話型で設定できたとしてもまだちょっとやりづらい。英語にそこまで不自由を感じないようになった僕でも日本語を読むほうが圧倒的に速い(漢字は文字あたりの情報量が圧縮されているということ抜きにしても)。

で、commitzen(cz-cli)は何もしないと対話的CLIのところにcz-conventional-changelogが使われている。ここを~/.czrcとかで別のものに指定ができるような作りなのでcz-conventional-changelog-jaというもの作った。作ったと言ってもオリジナルをフォークして日本語訳しただけなのですがね。

これを適用すると対話の質問やタイプ選択の説明が日本語になる。自分でも使ってみたけど、英語でコミットするにしてもこっちのほうが使いやすい。

使い方

グローバルに設定してプロジェクト問わず使うとしたら

$ yarn global add cz-cli cz-conventional-changelog-ja
# or npm i -g cz-cli cz-conventional-changelog-ja

とインストールしたら、ユーザー直下に

~/.czrc
{
"path": "cz-conventional-changelog-ja"
}

としてやる。そうすると

$ git cz

とやったときにデフォルトのcz-conventional-changelogではなくcz-conventional-changelog-jaを参照するので、日本語で表示されるようになるはず。

もうちょっと拡張するには

それで使ってたんだけどどうも僕がメッセージ書いててタイプの種類が少なかったり合わなかったり感じてた。コミットメッセージを書きやすくするためのツールなのにこの場合のタイプはうーんどうしよう、みたいに詰まるのは本末転倒だなぁ、と。

もちろんこのTypesを制御する方法ああるんだけど、これってプロジェクトやチームによっても変わるのでもっと柔軟なほうが良さそう。その都度別バージョンのcz-conventional-changelogをフォークしたりするのも違うよなぁって思いもあってcz-customizable経由でやることにした。

cz-customizableは、質問やタイプ情報の設定を外部から読み込めるようにして、カスタムできるようにしたもの。なので日本語で使う場合も.cz-config.jsを書いて参照するようにしたらいい。

参考までに僕の設定を載せておきます。

使い方

運用としては、上の-jaのようにグローバルに設定してプロジェクト問わず使うとしたら

$ yarn global add cz-cli cz-customizable
# or npm i -g cz-cli cz-customizable

とインストールしたら、ユーザー直下に

~/.czrc
{
"path": "cz-customizable"
}

cz-cliが参照するのをcz-customizableにする。で、cz-customizableはデフォルトでは.cz-config.jsを参照するので、下記のようにファイルを作って置く、と。

~/.cz-config.js
'use strict';
module.exports = {
types: [
{
value: 'feat',
name: 'feat: 新機能',
title: 'Features'
},
{
value: 'fix',
name: 'fix: バグ修正',
title: 'Bug Fixes'
},
{
value: 'HOTFIX',
name: 'HOTFIX: 致命的で緊急なバグ修正',
title: 'Critical hotfix'
},
{
value: 'UI',
name: 'UI: UIやスタイルの更新',
title: 'UI'
},
{
value: 'docs',
name: 'docs: ドキュメントのみの変更',
title: 'Documentation'
},
{
value: 'style',
name: 'style: フォーマットの変更\n (コードの動作に影響しないスペース、フォーマット、セミコロンなどの変更)',
title: 'Styles'
},
{
value: 'texts',
name: 'texts: 文字や文章の更新',
title: 'Text and literals'
},
{
value: 'i18n',
name: 'i18n: 国際化',
title: 'Internationalization'
},
{
value: 'typo',
name: 'typo: タイプミスの修正',
title: 'Typos'
},
{
value: 'refactor',
name: 'refactor: リファクタリングのための変更\n (機能追加やバグ修正を含まない変更)',
title: 'Code Refactoring'
},
{
value: 'perf',
name: 'perf: パフォーマンスの改善のための変更',
title: 'Performance Improvements'
},
{
value: 'ux',
name: 'ux: ユーザーエクスペリエンス/ユーザビリティの改善',
title: 'UX'
},
{
value: 'test',
name: 'test: 不足テストの追加や既存テストの修正',
title: 'Tests'
},
{
value: 'config',
name: 'config: 設定の追加や変更',
title: 'Configuration'
},
{
value: 'build',
name: 'build: ビルドシステムや外部依存に関する変更\n (スコープ例: gulp, broccoli, npm)',
title: 'Builds'
},
{
value: 'ci',
name: 'ci: CI用の設定やスクリプトに関する変更\n (スコープ例:Travis, Circle, BrowserStack, SauceLabs)',
title: 'CI'
},
{
value: 'chore',
name: 'chore: その他の変更\n (補助ツール、ドキュメント生成などのソースやテストの変更を含まない変更)',
title: 'Chores'
},
{
value: 'WIP',
name: 'WIP: 作業中',
title: 'WIP'
}
],
scopes: [
// { name: '*' },
// { name: 'admin' },
// { name: 'exampleScope' },
// { name: 'changeMe' }
],
// it needs to match the value for field type. Eg.: 'fix'
/*
scopeOverrides: {
fix: [
{name: 'merge'},
{name: 'style'},
{name: 'e2eTest'},
{name: 'unitTest'}
]
},
*/
// override the messages, defaults are as follows
messages: {
type: 'コミットする変更タイプを選択:\n',
scope: '変更内容のスコープ(例:コンポーネントやファイル名)(optional):\n',
// used if allowCustomScopes is true
customScope: '変更内容のスコープ(例:コンポーネントやファイル名)(optional):\n',
subject: '変更内容を要約した本質的説明:\n',
body: '変更内容の詳細("|"で改行)(optional):\n',
breaking: '破壊的変更についての記述(optional):\n',
footer: '関連issueを追記 (例:"fix #123", "re #123")(optional):\n',
confirmCommit: 'このコミット内容でよろしいですか?'
},
allowCustomScopes: true,
allowBreakingChanges: ['feat', 'fix']
};

もし参考にしていただけたら幸いです。

新しいタブがお好みの背景画像のMarkdownメモになるGoogleChrome拡張を作っている

  1. 1. 概要
  2. 2. 作った理由
  3. 3. ここに来てアップデートと紹介した理由
  4. 4. 技術的な話
  5. 5. 余談

実は最初のバージョンを公開してからけっこうたつんだけど、つい最近いろいろとアップデートしてみたので、ちゃんとお知らせしようと思います。こういうやつ。

YANTAN Preview

概要

  • Cmd+N とかでChromeの新しいタブを開いたときに表示されるページを置きかえるやつ
  • Markdownで書ける。GFMだからタスクリスト記法も対応してる
    • 簡易的な入力補完もつけた
  • どっからか(e.g. Flickr, 500px)の画像を参照するのではなく自分でローカルファイルを選択
    • 美麗な画像 = お気に入りの画像 とは限らないので
  • 画像にフィルタかけたり、文字色の設定とかできる

詳しくは紹介ページを作ったのでそちらを御参照頂きたい。

作った理由

同じような新しいタブページにメモできるようなやついろいろにインスパイアされたのは間違いない。というか既存のものが気に食わないから作るに至った。
というのも有名どころとかって確かにカッコ良くて綺麗な画像をランダムで表示してくれたりするんだけど、概要でも書いたようにそれが自分のお気に入りかというとそうじゃないんだよね。

で、僕には世界を旅行してフラフラしてる間にとった自分にとってかけがえのなく、そして誰にでも胸を張って見せれるような綺麗でお気に入りで思い入れのこもった写真がある。例えば既存の綺麗が画像が表示されるやつでマチュピチュとか表示されるでしょ、そうすると「おー、行ったなぁ」ってなる。なるんだけど写ってるは自分の写真じゃない、そこが納得行かなかった。

もちろん僕だけじゃなくて、風景写真とかじゃなくて例えばアニメやゲームの画像が良いよ、とかって人も居るだろうと思った。そういうのが、自分の好きな背景にしたかった理由。

あとはちょっとササっとメモ取るときに、エディタとは違う場所にメモとりたいときとかあって。Markdownで書けたら簡単になんでもイケるし。

ここに来てアップデートと紹介した理由

アップデートも紹介も前からしたいなーと思いつつ後回しにしてた。つい最近’Markdown New tab’っていうGoogle Chrome拡張が少しバズったりしてたので「おいおい、同じようなの僕もけっこう前に作ったじゃん!」ってなんか憤慨した。

そっから今までやりたいなーと思ってたらローカル画像をキャッシュして使ったり(それまではURLを入れてそこから取得してた)、入力補完を入れたり。ちょいちょいアップデートした。

以前PentazeminというElectronアプリも作ったんだけど、そのときに紹介ページをつけただけでグっと見てもらえる、使ってもらえる率が上がったので、今回も作った。それが上で紹介してるやつ。
このPentazeminもアップデートはそのうちしたい。かなりのポテンシャルあるし。

まあそんなわけでアップデートして紹介ページも整えました。

技術的な話

作ろう! と発起したきっかけのひとつに、あれ、SPAの技術ってChrome拡張でも活きるんじゃね? と思ったことが大きい。
で、実際に使ってのはVue.js。大枠部分は本当楽しく気楽につくれていて幸せ。

ちょっと苦労したのは入力補完。というのもやってる実装は

  1. 特定のキーの時にイベント発火
  2. その中で現在のキャレット位置を特定
  3. キャレットの位置を利用して全文を行ごとにわけて現在の行を特定
  4. 現在の行が補完すべき状況だったら、補完する文字をキャレットの部分に挿入
  5. キャレットの位置を挿入した文字数だけズラす

という流れ。もしかしたらもっと良い実装があるかも。とにかくこのキャレットと入力文字の周りがけっこうやっかい。発火タイミングはKeyupなのかKeydownなのか、対象がReturnキーだったので改行が入ったり入らなかったりして。結局Keydown時にイベントをpreventで奪って、補完しない時は改行を、補完するときは補完文字と改行を挿入するようにしてる。

リリースに関しては、「webpro/release-it: CLI release tool for Git repos and npm packages.」を使ってみてる。なかなか良い。でもまだ最後の方でコケてしまうのが解消できなくて悩んでる。とはいえ、ビルド、自動でパッケージのバージョン表記を更新、タグ付けてPush、あたりまでできてるので実用には耐えれている。
本当はそのあとReleaseに上げて、それをフックにしてChrome拡張配布用のAPI叩いて自動リリース、までやらせたいんだけど…

ちなみに紹介ページはPentazemin時につかったNuxt.jsを改変してシュシュっと作った。といっても一日半かかってしまったけど。まあこれはアイコンや紹介画像、ロゴっぽいやつとか画像制作に時間かかってるのもあるから仕方ない。ただこの画像と説明があるとないとで全然違うので、サボらない。

余談

とまあここまで既に余談だけど、さらに余談。

自分がプライベートで作るものはよっぽど日本特化じゃないかぎり英語ファーストで作ってる。これは、僕が世界をいろいろ見た結果の感覚として、日本は貶すファーストの減点法で評価したがるし、欧米圏はわりと褒めるファーストの加点法で評価したがる傾向だと思ってるから。
趣味でやってるレベルのもので叩かれて無駄に精神力は削られたくないし、褒められるほうが嬉しくてモチベーションアップにつながるから。

わざわざツライ環境で戦うことを選ぶほど僕はマゾじゃない。

あとは寄付を募りたくて悩んでる。基本的に趣味プロダクトはフリーで提供していきたいと思ってるんだけどやっぱりサポートはあったほうがいい。今はPaypal.meだったりKyashだったり個人間送金が昔より手軽になって良い。でも、法的にどうなのか良くわからないので躊躇してる。
ソフトウェア販売(但し払わなくても使える)という形式にするとか、ギフト券とか、ウィッシュリストとかいろいろ方法はあるんだろうけど、それも本当に法的セーフなのはどれなのか、とかよくわからない。

お金により発生するモチベーションと評価は欲しい。

自分が欲しいと思うものを作ってるだけなので当たりまえなんだけど、それなりに使い勝手の良い拡張だと思うので、もし良ければ入れみて試していただけると嬉しい。Chrome拡張なら削除も簡単だし、Vivaldiでも使えてるよ。

もっと気楽にブログが書きたい

またいつものごとくブログを書かない期間があいてしまった。
けっしてネタがないわけではなく、むしろ書きたいネタはけっこうある。
でもブログ書くぞ!みたいにキーボードを叩きはじめるのはなんかおっくうだったり。

1つの原因としてわりとちゃんとしたことを書きたい、みたいな思いがあって
ネタとして貯蔵してるものもだいたいちゃんとしたことを言いたいがため、みたいなことがあって
書き始めるところから終わりをみすえると、ああなんかちょっとエネルギーいりますよね、
みたいに思っておっくうになってしまうのが一つ。

もう一つは単純に優先順位の問題で、ブログを書く、という行動の優先順位が僕の中で低い。
どうせエディタを触り出すなら趣味プロダクトのコードを書いてしまうし、
なんならインプットしてる時間のほうが圧倒的に多い。

パソコンの前にいないときは料理したり、ゲームしたり、でかけたり、と。
じゃあブログ書くぞ!みたいな感じになかなか入りづらい。

かといって書き物が嫌いってわけじゃなく、例えば仕事だといろんな情報をチャットに残したり
ドキュメントやナレッジに残すのはけっこうやってるほうだと思う。

ブログ書く機会を増やす、っていう施策をなんかとりたい。
ある程度決めた時間を書くことにあてる、とか。
あと前々からずっと思ってるのがもっと気軽に持ち運べるキーボードによる入力環境を用意すること。
例えばサっと出して電車の中でもブログ書けるとか。

前はポメラを考えてみたんだけど、僕にはSKK+SandSじゃないと打てないという枷がある。
そうするとポメラは無理だし、iPhone+BTキーボードも考えたけどSKKないし。
今はGPD PocketとかSurface goとかならいけそうかなぁ、と考えてる。
でもそこまで投資できるほど資金が潤沢ではないので見送りかなぁ。

もうひとつは最初に言及した心理的な問題。
職場の同僚君のブログを見てたりするけど、ほんとカジュアルに書けててうらやましく思う。
今日はここで遊んだー、とかこういうの買ったー、とか。
揶揄する意図は全くなく羨ましい。
彼をみならってもうちょっとカジュアルに書いていきたい。
まずは習慣をつけること、頻度を上げること、文量は気にせずホイっとやっていきたい。

2018年、最近の僕の暮らしのお話

  1. 1. 消費的趣味、ゲームと映画と読書と
  2. 2. エンジニアとして
  3. 3. 日々の生活はというと

なんとなく日記的なことを書きたい夜なので、最近の暮らしの話を。

消費的趣味、ゲームと映画と読書と

僕の中で消費的趣味には3種類あって、それがぐるぐるとサイクルしていたんだけど最近は映画は少なくなったかもしれない。昔はどっぷりゲームばっかりする期間、映画ばっかり見る期間、本ばっかり読む期間、っていうのがわかれていてそれがサイクルみたいに回ってたんだけど、最近はどうも同時進行な感じ。

このGW、二つ映画を見にいった。一つ目はレディ・プレイヤーワン。各所で大絶賛されてるしレビューはそういうところを見てください。僕の感想も、最高でした、の一言。ほんと、俺、ゲーマーで良かったわ、って思わせられた。熱い展開もあったし、良かった。
もう一つはジュマンジ。やっぱりこれもゲームつながりなんだけど、最高だった。特に僕はジャックブラック大好きなので、かなり気持ちよく笑わせてもらった。

最近はもうこういうあんまり深いこと考えずに見てワーっと発散するような映画が好き。なんだか小難しい映画をあえてみようとは思わない。もしかしたら映画は僕の中で消費的趣味とわりきったからかもしれない。以前ならともかく、今はもう映画を見て何かを考えようとは思わない。

ゲームはモンハンの波が一段落つき、友人とやっていたフォートナイトにも少し疲れて最近あまりやってない。それよりもゲームするならエンジニア的な勉強やら試しになんかやってみたり、あとは実用書的なものを読んでる時間のほうが欲しいし、そうしてる。こういうのも一つの波なんだけど。
ただまぁそういうのに疲れてくるとゲームやりたいな、って思うんだけどガっと夢中になれるようなゲームもなくてちょっとモヤモヤしてる。

読書のほうは、楽しむための読書はずーっと寝る前にちょこちょこ読んでるの。最近はラノベチックなものが多くなったなぁ。テンプレ的な異世界転生モノも読むんだけどあんまり楽しめず、割と硬派なダークファンタジーみたいなものが好きな気がする。そういえば最近時代劇読んでないなぁ。以前は読む小説の8割は時代劇だったし、今でも好き。というか時代劇って一種のファンタジーだと思ってる。

エンジニアとして

職業エンジニアになって1年ちょっと。ふりかえってみるとまぁ進捗悪くないような気がする。まだまだ足りないことも多いんだけど。年度が変わっていろいろあって、後輩に教えるようなこともでてきた。というか誰もそういうの積極的にやらないから勝手出ただけなんだけど。

教えることから教わることも多いのでやってるし、教えた人が評価されたら僕の評価もあがるんじゃないか、という打算8割で動いてる。そういうのは先日あえて後輩ちゃんに伝えた。変に気をつかって遠慮するより、こっちもメリットがあってやってんだぜ、っていうことをちゃんと開示したほうが良さそうに思えて。あとの2割は、放置はダメだろ!という憤り。

会社に対してはいろいろ思うところがあるけど、やれる道を探してやっていくしかないな。割とマジメに戦略的に僕の立ち位置を確保しに行ってる。それでも上手くいかなかったら環境を変えるだけだし、環境を変えれるように動いていくしかない。不満を言うだけでは何にもならないので現実的にいろいろ手を打っていってる。
それが会社から評価されたかは別として、この1年ちょっとを振り返ってみてわりと納得行く形でレベルアップしてるのであながち的外れでもなさそうという実感がある。

日々の生活はというと

昨年度、妻の仕事のほうがちょっと大変そうだったけど部署移動とかもあり、すこしは良くなったような気がする。僕の人生は僕の夢だった世界旅行を終えた今はすでにボーナスステージ。なので妻と楽しく暮らせたらなにより。もうすぐ結婚して丸3年。小さな波はあれどそれなりに上手くのりこなしてると思う。
妻はいろいろ心配性なようで、もうちょっと気楽に生きてくれたらなーと思う。僕はずっとずっと一人でいることを基準にした加点法の世界で生きているので二人で居ることがすでにプラスだと言っているんだけどなぁ。

なんかこう、日々生きてきて、良い意味で諦めが良くなった気がする。コントロールできない物事に振り回されないことを念頭に置くというか。例えば妻の機嫌はコントロールできないし、妻の考えてることはエスパーじゃないので読めない。だから必要以上に気にしないし、深い入りしないようにした。もちろん気遣いや思いを汲むように努力はしてる上で。
ただ、自分がコントロールできるの自分の肉体だけ、という考えが強くなった。自分の気持ちすらもコントロールがままならないので、肉体をコントロールすることで自分の気持ちを動かすようなアプローチに変更した。そうしたら割とやることはシンプルになって良い感じ。

話変わって日々の週末はというと会社の同僚さんとキャンプに行ったり、ゲーム仲間と定期的にボードゲームに興じたり、エンジニア的な勉強会やセミナーに行ってみたり、わりと日々充実してる気がする。予定がなければジムに行くのも続いてるし、体が休みを欲っしていなければ技術の勉強をしてる。後輩ちゃん達に教える立場に身を投じたため、割と必死で勉強してる。なるべく形にしようと先日紹介したモンハンの弱点表示ツールとか、あとGoogleChrome用の拡張を作ってみたり、ちょこちょこいろいろやってる。

今年度も粛々と虎視眈々とやっていく。

二年たっても買って正解だったと思える新生活グッズ

  1. 1. 食洗機
  2. 2. シャワーヘッド
  3. 3. パンチングボウル
  4. 4. シリコンスパチュラとシリコンおたま
  5. 5. ヨーグルトメーカー
  6. 6. 匙つき菜箸
  7. 7. 光目覚し時計
  8. 8. マキタの掃除機
  9. 9. テンマの衣装ケース

新生活シーズンですね。僕等夫婦は今のところに引っ越してきて約2年半。それまで実家暮しだったのでいろいろと買いそろえた中でこれは買って良かったと思うのを書いていこうと思う。だいたいの家にあるだろうものは除いて。

食洗機

よっぽど手洗い好きじゃない限りはなぜ導入しないかがわからない。僕は機械でできることは人がやるべきじゃない、という哲学があるので食洗機を導入しない理由がない。高温で洗うので油汚れなんて手洗いよりはるかに綺麗に落ちる。この世には食器洗いきっかけで勃発する夫婦喧嘩あるらしいけど、そもそも食器手洗いが発生しないから無縁。ちなみにウチはタイマーにして夜中に回してる。

がんばれば自分で取りつけれる。というか僕は自分でとりつけた。なお電気代、水道代は知らん。でもメリットがでかすぎるので異常に高くなければ使わない理由がない。食べ終ったあと、サっと水で流してつっこむのですぐに洗わなくてもシンクに洗いものがたまらない。何より食器洗いがめんどくさいという心理障壁がなくなる。これが一番でかい。めんどくさいものをめんどくさく感じなくなるというはソリューションとして大正義だと僕は思ってる。

残念な点は、やっぱり場所を少し大きく取ること。それと事実上パナソニック一択なところ。

シャワーヘッド

うちのシャワーの水圧が低い。シャワーがあんまり気持ちよくない。シャワーヘッドはたぶんみんなが思ってるより簡単に交換できる上、素晴しく効果が高い。水圧が低い備えつけのヘッドだったのを、穴の細かいヘッドに変えたら水圧は上がるわ細かい粒で気持ち良いわで最高になった。シャワーの出る穴が小さいってことは単純に水圧が上がる。ホースを潰して持つような原理ね。

で、水の粒が細く細かくなったことで体に当ったとき気持ちいい。ウチの実家はいろいろ良い設備が整ってるけど、シャワーヘッドだけはウチのほうが気持ちいいのを年末年始に帰省した時に実感した。ふふん。

マジでオススメ。

パンチングボウル

ザルじゃなくてパンチがいいよ。紹介してるやつは普通のボウルとパンチングのボウルそれぞれ3種類でそれぞれの大きさがピッタリだからスタッキングもできるし。なんでザルじゃなくてパンチングがいいかってとザルだと細かいものがひっかかって取りにくいから。100均とかでよくあるプラスチッキーなザルよりも金属のほうが断然耐久製あるし、2年半、ずっと使ってるけどまだまだずっと使えそう。これだけでいろいろ事足りる。

シリコンスパチュラとシリコンおたま

木ベラとかあるけど、基本的にたいていのことは耐熱ゴムヘラで十分。しかも鍋に少し残っちゃう、ってこともゴムヘラだとない。精神衛生的に凄くいい。汎用性高すぎる。
おたまも形が変形するからキッチリとれる。熱にも普通に使う分には心配ないし便利。

ヨーグルトメーカー

朝食で夫婦でヨーグルト食べてるとすぐになくなるので、ヨーグルトを買って牛乳で増殖させる作戦に移行。牛乳パックのまんま作れるので無理なく続けられてる。だいぶコスパは良いと思う。

匙つき菜箸

厳密にはこれと違って使ってるのは木製なんだけど、ほぼ同じ感じ。持ち手側がスプーンになってるようなやつはいくつかあるなか、普通に丸型だと干渉して使いにくい。ちょっとすくうので十分なのでこの程度の凹みで十分。シリコン菜箸も使ってみたけどなんか重くて取り回しづらかった。

光目覚し時計

最近はスマートスピーカーの流れでタイマー的に付くライトも注目を浴びてるけど、フィリップスはだいぶ前から光目覚ましを作ってる。どうしても起きれないときもあるけど、基本的には寝起きはわりとやんわり起こしてくれる。もちろん音もなる。あと時間でゆっくり暗くなるようにもできるのでベッドサイドランプとしても良い感じ。

マキタの掃除機

ダイソンとか高いじゃないですか、でもコードレス掃除機が良いじゃないですか。サッと使えるのは良い。掃除に対して心理障壁を小さくするのはサっと掃除するようになるから良い。掃除機をかけるのが面倒なんじゃなくて、大抵の場合は掃除機を出してきてコードにつないで、掃除機かけて、コードを外してしまう工程が面倒なわけで。やっぱり家事の基本は極限まで心理障壁をなくすことにフォーカスするべし、だ。

テンマの衣装ケース

衣装ケースにしては少し高めかもしれない。しかしながら定番の無印などには到底およばないようなスムーズさ。しっかり止まる。頻繁に使うし、買いかえるようなものでもないから奮発して購入。道具はデザインとかよりまず使い勝手。天馬のフィッツ最強伝説。

モンスターハンターワールド モンスター弱点早見システムを作った

  1. 1. 概要
    1. 1.1. 経緯的な話
    2. 1.2. 開発的な話
    3. 1.3. バズらせるというか知らしめる話

狩人のみなさまにおかれましては楽しいハンターライフを送っておりますか?

タイトル通りなんだけど、MHW向けにせっかくなのでスマホから簡単に見れるシステムを作った話。
作ったものはここ。
MHW 弱点検索

概要

こんな感じ。
サムネイル

  • 検索というよりフィルタ
  • ロード時間とか、準備時間にササッと確認できると良いなあ
  • 種類や名前を指定してそのモンスターの弱点とかを表示するシンプルなシステム
  • キーワードも対応してる、AND、ORも使える
  • なにげに英語対応した
  • PWA対応なのでスマホのホームに登録すると捗る

経緯的な話

以前にGoogle SpreadSheetに作ったやつがあるけど、あれでも十分だったところ、たまたま仕事の技術勉強会での発表の出番が周ってきて何か動くサンプルが欲しかったのでチャチャッとそれらしきものを作ったのがきっかけ。ちなみに発表の内容は、静的なページであってもJavaScriptで何か動いてるとしたらそこにテスト必要だよね、という感じ。

ちなみに勉強会には間に合わず、プロトタイプというかただボタン押すと動くやつ、みたいなので発表した。とはいえそこで原型はできたちゃったので、それをベースにちゃっちゃっと完成させた。勉強会でサンプルで書いたテスト以外は書いてない。本末転倒。

とはいえ実用十分だし、つながりのある人達がフィードバックしてくれるし、自分も使ってみてちょこちょこアップデートを繰り返してようやく一段落。

開発的な話

静的ページオンリーで行こうと思ったので、いっそのこと純SPA的に作ろうと思った。そして利用者のスタイルとしてゲームやりながらスマホをいじるのがメインと思われたことからPWAにしてみる。

スマホ特化なのでいろいろフレームワークを検討したけど、OnsenUIがてっとり早そうだったのと僕の好きなVue.js用があったので採用。使ってみての感想はいろいろとちゃちゃっと作るには良くできてるけど、混みいったことをやろうとすると癖とかが足枷になりえたり。まぁそれはどのフレームワーク使ってもそうなんだろうけど。

Vue.jsは以前作ったPentazemin以来しばらく間が開いたので、再入門的な感じになった。ただPentazeminの時にいろいろ頑張ったせいか、だいぶサクサク作れた。あそこで独力で頑張った努力は無駄どころか自分にとって大きな資産になってる感をすごく感じた。それとともに今回もちょっと違ったことやったりで知見が増えた感覚もある。

特にSPAにしつつもURLで言語環境分けたり、ローカライズ周りだったり。あとはキーワードの実装もなかなか頭をひねった。そう思うとこういう自分の好きな題材で好きなフレームワークや開発技術を持ちいて趣味開発するの最高に良い。ちょうどゲームのほうも落ちついてきたので気持ち的にも良かった。

最初はGitHub-Pagesで運用しようと思ったけどなんかファイルが上手く読まれないのでNetlifyで。このブログでも使っるNetlifyだけど改めて便利さを思い知った。静的なものであればNetlifyに上げさえすれば動くので、内部的に動的な要素を必要としないなら十分だし手軽で最高。SPAがっつり作れば動的っぽいけどフロントエンドでどうにでもできちゃうのでこれで事足りちゃうってのがまたすごい。便利な世の中で幸せ。

バズらせるというか知らしめる話

せっかく作ったのでいろんな人に使って欲しいのは当然だと思う。そうしていろいろと知らせてみたものの、バズらせるのって難しい。

Twitterでお知らせするも僕のフォロワーはそんな多くない。ハッシュタグつけたら良いんかと思ったけどこれが実は簡単な話じゃなかった。というのも、Twitter公式で見てるとハッシュタグつけても拾われるのは何らかのアルゴリズムが噛んでる。人気があるのが良く表示されるというか、表示される為の人気を取るハードルが高すぎる。特に同じタグでかなりの数のツイートされてる場合。
公式で見てない場合、時系列的に載るとは思うんだけどここも流れが早すぎて流れてしまう。画像がないからかな、と思ってプレビュー画像を作ってみたけど変わらず。これは時間帯とかも関係すると思うのでなかなか一概に言えず。

5chやまとめサイトで情報が載るのが一番良さそうだけど、5chってそういう宣伝的なのを嫌う傾向にありそうだし、まとめサイトってなにをどう拾ってるのかよくわからん。5chに載るのは、宣伝じゃなく上手く貼るような独特の手法が必要そうな気がする。5ch専用ステマというか。よくポジティブに話題になるのは、なんか上手いこと工作してるんだろうなあ、と思う。

一方で英語対応したので海外掲示板のRedditにも載せてみた。こっちは5chみたいな暗黙の了解みたいなのとかないので自分でバシっと。スレ立てて1時間も立たないうちに感謝のコメント付いたのでだいぶ嬉しかった。本当、日本には存在しない感謝や褒めるのを惜しまない文化は素敵。というか日本で感謝と褒めを惜しむ文化ってなんなんだろう。みんな褒めたり感謝しあったりするほうがハッピーに暮らせると思うよ。誇張じゃなくて、その文化の違いだけで移住する価値十分にあるケースも少なくないと思う。

そんなこんなで知らせるところでだいぶ苦戦してる。自分とその周りに役立てばそれで十分なんだけどね。

これがないと捗らない、僕のKarabiner設定(late 2017)

  1. 1. Karabiner-elements
    1. 1.1. GUI設定 Overview
      1. 1.1.1. Simple Modifications
      2. 1.1.2. Function Keys
      3. 1.1.3. Complex Modification
        1. 1.1.3.1. Change Space to R-Shift (if alone)
        2. 1.1.3.2. Change Delete to R-Ctrl (if alone)
        3. 1.1.3.3. Change L-Cmd + R-Opt to L-Cmd + Space
        4. 1.1.3.4. Change L-Opt + R-Opt to L-Opt + Space
        5. 1.1.3.5. Change L-Opt to TAB (if alone)
        6. 1.1.3.6. Change R-Opt to ESC (if alone)
        7. 1.1.3.7. コマンドキーを単体で押したときに、英数・かなキーを送信する。
        8. 1.1.3.8. Change FN1 to (, Shift + FN1 to <
        9. 1.1.3.9. Change FN2 to ), Shift + FN2 to >
    2. 1.2. JSON設定ファイル

昨年末から続いてる極まりつつある入力環境シリーズ、Karabiner編。
macOSユーザの大半が使ってるであろう、Karabiner(-elements)というキーボードセッティングユーティリティの設定のお話。ここの設定はもはや無いと使えないレベル。

Karabiner-elements

macOS Sierra以前にKarabinerというツールがあって(それ以前はKeyRemap4macbookという名称だった)。Sierraで内部的に大きく変更があって、簡易的な代替としてKarabiner-elementsが生まれた背景がある。その後アップデートを繰り返し今では以前のKarabinerにひけを取らない、もしくは以前よりも柔軟な設定ができるユーティリティとして生まれ変わっている。

で、もちろんGUIから設定もある程度できるんだけど、内部的にはJSONで設定ファイルが書かれている。さらに柔軟な設定となるとJSONを直接編集する方法になる。なので今回はGUI部分はさっと紹介に留めてJSONをメインで。というより、設定JSONさえ入れればすぐにその設定を使えるので良い。(Karabiner時代は独自のxmlだったので以前よりやりやすくなったと思う)

僕の場合、外付けキーボードを使っていて、そちらでファームウェアレベルでキーリマップはできるものの、外してノートのキーを直接叩く機会もあるので、共通する設定はKa rabiner-elements側で行なっている。また、僕の設定はかなりErgoDox特化の設定でもあるのでご注意を。

GUI設定 Overview

Simple Modifications

Caps LockCtrlにしているだけ。Caps Lockが無いと大変な人って多数派なんだろうか疑問である。システム環境設定側でもできるけど、いろいろ絡めるとこちらで設定するのが良い。

Function Keys

基本的に叩かないのでわりとどうでもいい。デフォルト。すごい偏見だけどWindows使ってた人ってFunctionキー好きだよね。

Complex Modification

Change Space to R-Shift (if alone)

SandS用。SandSとはSpaceShiftキーを両立させるキーで、単体で押したらSpace、他と組み合わせるとShiftになるようなキーのこと。ちなみに僕の使うErgodoxではDoubleFunctionとして設定できるけど、挙動はKarabinerでやるほうが好みの感じになるのでこちらでやってる。

Change Delete to R-Ctrl (if alone)

これは完全に僕の好み。しかもErgoDox特化。黄金の小指を捨てて鋼鉄の親指にするためのもの。要は親指位置にCtrlキーを持ってきていて、それが単体押しだとDeleteとして動作したらいいよね、って感じ。ちなみにノートのキーボードを直で叩く時は小指が黄金化せざるを得ない。

Change L-Cmd + R-Opt to L-Cmd + Space

Cmd+SpaceでAlfred呼び出しにしてるものをErgoDox使用時とキーボード直の時の差を吸収する設定。直の場合、左親指でCmd、右親指でShiftを叩いてAlfredを呼び出している。が、ErgoDoxのときは左側にSpaceキーがないのでOptキーと組み合わせることで同じ動作をするように。

Change L-Opt + R-Opt to L-Opt + Space

これも上と同様で、Opt+SpaceでOmniFocusのクイックエントリに設定しているから。

Change L-Opt to TAB (if alone)

左のOptを単体で押したらTABとして動作。僕の小指はそんなに長くないし。そしてErgoDox系が素晴しいのは親指の有効活用を目指しているからである。

Change R-Opt to ESC (if alone)

上記同様。

コマンドキーを単体で押したときに、英数・かなキーを送信する。

これは最初からプリセットされているものを読み込んで設定できる。US配列好きの日本ユーザーに割と常識になってる英数、かなキーのエミュレーション。僕の場合、AquaSKKでの設定を使うのであまり出番がないけど一応。

Change FN1 to (, Shift + FN1 to <

ErgoDoxにはb,gキーの右側に特殊キーがある。そこを括弧系の入力に割り当ててる。ErgoDox側でFN1を割り合てて、Karabiner側で実際に入力されるキーを指定。これは本来ならErgoDox側のハードウェア的にやるほうが望ましいけど、ErgoDox側でのShiftを絡めたキー指定が難しいため。

Change FN2 to ), Shift + FN2 to >

上記の逆。h,nの左にも同様のキーがあるので逆の閉じる側の括弧を。余談だけど、その上に配置されたキーは、[]{}を割り当てている。

余談だけどUSキーボード好きのJISキーボード使いずらい派は、括弧のキー配列が横並びじゃなくて縦並びになってるが嫌って人が多いと思ってる。あれはとても直感的じゃない。

JSON設定ファイル

上記までの設定が全部かかれたJSONファイル。ちなみに生成されるのファイルのインデントは4スペースだけど、個人的に見辛いので2スペースにしている。で、つまるところJSONなので、これをGitとかGitHub Gistで管理したりDropboxとSymlinkで同期させたりすると複数端末でも使い勝手が良いよね。

karabiner.json
{
"global": {
"check_for_updates_on_startup": true,
"show_in_menu_bar": true,
"show_profile_name_in_menu_bar": false
},
"profiles": [{
"complex_modifications": {
"parameters": {
"basic.to_delayed_action_delay_milliseconds": 500,
"basic.to_if_alone_timeout_milliseconds": 1000,
"basic.to_if_held_down_threshold_milliseconds": 500
},
"rules": [{
"description": "Change ␣ to R⇧ (if alone)",
"manipulators": [{
"from": {
"key_code": "spacebar",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [{
"key_code": "right_shift"
}],
"to_if_alone": [{
"key_code": "spacebar"
}],
"type": "basic"
}]
},
{
"description": "Change ⌦ to R⌃(if alone)",
"manipulators": [{
"from": {
"key_code": "delete_forward",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [{
"key_code": "right_control"
}],
"to_if_alone": [{
"key_code": "delete_forward"
}],
"type": "basic"
}]
},
{
"description": "Change L⌘ + R⌥ to L⌘ + ␣",
"manipulators": [{
"from": {
"key_code": "right_option",
"modifiers": {
"mandatory": [
"left_command"
],
"optional": [
"any"
]
}
},
"to": [{
"key_code": "spacebar",
"modifiers": [
"left_command"
]
}],
"type": "basic"
}]
},
{
"description": "Change L⌥ + R⌥ to L⌥ + ␣",
"manipulators": [{
"from": {
"key_code": "right_option",
"modifiers": {
"mandatory": [
"left_option"
],
"optional": [
"any"
]
}
},
"to": [{
"key_code": "spacebar",
"modifiers": [
"left_option"
]
}],
"type": "basic"
}]
},
{
"description": "Change L⌥ to ⇥(if alone)",
"manipulators": [{
"from": {
"key_code": "left_option",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [{
"key_code": "left_option"
}],
"to_if_alone": [{
"key_code": "tab"
}],
"type": "basic"
}]
},
{
"description": "Change R⌥ to ⎋(if alone)",
"manipulators": [{
"from": {
"key_code": "right_option",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [{
"key_code": "right_option"
}],
"to_if_alone": [{
"key_code": "escape"
}],
"type": "basic"
}]
},
{
"description": "コマンドキーを単体で押したときに、英数・かなキーを送信する。(左コマンドキーは英数、右コマンドキーはかな)",
"manipulators": [{
"from": {
"key_code": "left_command",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [{
"key_code": "left_command"
}],
"to_if_alone": [{
"key_code": "japanese_eisuu"
}],
"type": "basic"
},
{
"from": {
"key_code": "right_command",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [{
"key_code": "right_command"
}],
"to_if_alone": [{
"key_code": "japanese_kana"
}],
"type": "basic"
}
]
},
{
"description": "Change FN1 to (, ⇧ + FN1 to <",
"manipulators": [{
"from": {
"key_code": "international3",
"modifiers": {
"mandatory": [
"left_shift"
],
"optional": [
"shift"
]
}
},
"to": [{
"key_code": "comma",
"modifiers": [
"left_shift"
]
}],
"type": "basic"
},
{
"from": {
"key_code": "international3",
"modifiers": {
"mandatory": [
"right_shift"
],
"optional": [
"shift"
]
}
},
"to": [{
"key_code": "comma",
"modifiers": [
"right_shift"
]
}],
"type": "basic"
},
{
"from": {
"key_code": "international3",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [{
"key_code": "9",
"modifiers": [
"right_shift"
]
}],
"type": "basic"
}
]
},
{
"description": "Change FN2 to ), ⇧ + FN2 to >",
"manipulators": [{
"from": {
"key_code": "international1",
"modifiers": {
"mandatory": [
"left_shift"
],
"optional": [
"any"
]
}
},
"to": [{
"key_code": "period",
"modifiers": [
"left_shift"
]
}],
"type": "basic"
},
{
"from": {
"key_code": "international1",
"modifiers": {
"mandatory": [
"right_shift"
],
"optional": [
"any"
]
}
},
"to": [{
"key_code": "period",
"modifiers": [
"right_shift"
]
}],
"type": "basic"
},
{
"from": {
"key_code": "international1",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [{
"key_code": "0",
"modifiers": [
"right_shift"
]
}],
"type": "basic"
}
]
}
]
},
"devices": [{
"disable_built_in_keyboard_if_exists": true,
"fn_function_keys": [],
"identifiers": {
"is_keyboard": true,
"is_pointing_device": false,
"product_id": 4871,
"vendor_id": 65261
},
"ignore": false,
"manipulate_caps_lock_led": false,
"simple_modifications": []
},
{
"disable_built_in_keyboard_if_exists": false,
"fn_function_keys": [],
"identifiers": {
"is_keyboard": true,
"is_pointing_device": false,
"product_id": 630,
"vendor_id": 1452
},
"ignore": false,
"manipulate_caps_lock_led": true,
"simple_modifications": []
},
{
"disable_built_in_keyboard_if_exists": false,
"fn_function_keys": [],
"identifiers": {
"is_keyboard": true,
"is_pointing_device": false,
"product_id": 628,
"vendor_id": 1452
},
"ignore": false,
"manipulate_caps_lock_led": true,
"simple_modifications": []
}
],
"fn_function_keys": [{
"from": {
"key_code": "f1"
},
"to": {
"key_code": "display_brightness_decrement"
}
},
{
"from": {
"key_code": "f2"
},
"to": {
"key_code": "display_brightness_increment"
}
},
{
"from": {
"key_code": "f3"
},
"to": {
"key_code": "mission_control"
}
},
{
"from": {
"key_code": "f4"
},
"to": {
"key_code": "launchpad"
}
},
{
"from": {
"key_code": "f5"
},
"to": {
"key_code": "illumination_decrement"
}
},
{
"from": {
"key_code": "f6"
},
"to": {
"key_code": "illumination_increment"
}
},
{
"from": {
"key_code": "f7"
},
"to": {
"key_code": "rewind"
}
},
{
"from": {
"key_code": "f8"
},
"to": {
"key_code": "play_or_pause"
}
},
{
"from": {
"key_code": "f9"
},
"to": {
"key_code": "fastforward"
}
},
{
"from": {
"key_code": "f10"
},
"to": {
"key_code": "mute"
}
},
{
"from": {
"key_code": "f11"
},
"to": {
"key_code": "volume_decrement"
}
},
{
"from": {
"key_code": "f12"
},
"to": {
"key_code": "volume_increment"
}
}
],
"name": "Default profile",
"selected": true,
"simple_modifications": [{
"from": {
"key_code": "caps_lock"
},
"to": {
"key_code": "left_control"
}
}],
"virtual_hid_keyboard": {
"caps_lock_delay_milliseconds": 0,
"keyboard_type": "ansi"
}
}]
}

そんなこんなで年も明けてだいぶたつけど、去年末にもあとめた一連の入力環境カスタマイズシリーズはおしまい。
整理するにあたって確認しなおしたのでこれからはあんまり変わることはなさそう。

とはいえ、キーバインドあたりはまだまだ何とかしたい感ある。
装飾キーの押し分けによってスコープを変えたい、例えばCmd単体ならアクティブなウインドウの操作、Cmd+Ctlrならアクティブなアプリの操作、Cmd+Ctlr+Altでグローバルな操作、とか。

そうやりたいのはやまやまなんだけど、デフォルトで設定されてるキーバインドも大事にしたくて、その両方の落としどころが上手く見つからない感じ。

何故僕はTumblrからHexo+Netlifyに移行したのか

  1. 1. Hexoについて
  2. 2. Netlifyについて
  3. 3. Tumblrについて
  4. 4. それでも僕がTumblrを離れたわけ
    1. 4.1. テーマの自作がやや面倒
      1. 4.1.1. TumblrのJavaScriptが避けれない
    2. 4.2. エントリが管理できない
    3. 4.3. Tumblr == リブログ というイメージが強すぎる
      1. 4.3.1. もにょる
  5. 5. じゃあHexo+Netlifyは?
  6. 6. 昔話

細々ながらも長らくブログをやってきまして。つい先日しれっとTumblrからHexoというブログ特化型の静的サイトジェネレータをNetlifyでホストする方法に移行しました。

Hexoについて

ブログ特化型の静的サイトジェネレータは今ではいろいろ豊富で、Jekyllなんかを皮きりにMiddleman、Hugo、Octopress、Gatsbyなどがある。

で、結果的にできることっていうのはどれもそんなに変わらないんだけど、過程としてそもそも動く言語が違う。ということで僕がHexoを選んだのはNode.jsで動くから、っていう理由だけ。特に僕は既存のテーマとか使うのは好きじゃなく自分で作りたい派だから慣れ親しんだPug、Stylusでテーマ作るのもNode.jsのほうがやりやすい。

と、書いて思ったけどわりとテーマ自作って少ないのかな。昔からいろんなブログを転々としてきたけど、いつだってテーマは自作してきた。それが普通だと思ってた。

まあそんなこんなでローカルで開発できてテストできて、デプロイも簡単なHexoにすることに。それにブログ程度、動的な要素はそんなに必要なくて静的で十分事足りるし。

Netlifyについて

静的サイトをホスティングするWebサービス。Git系リポジトリのWebhookからビルド、デプロイできるし、SSL/HTTPSもばっちり。カスタムドメインも使えるし至れり尽せりな上に基本無料(CDNを日本にしたり、パスワードかけたりは有料)。個人の静的サイトならもうNetlifyで全部いいんじゃないかって思う。

もちろんGitベースのソース管理してデプロイするのは開発に関する知識が少し必要だから使うユーザのレベルは少しだけ要求されるけど、逆に言えばその程度しか要求されないのですごく楽。

各エントリの内容はもちろん、テーマや設定系も全部Git管理できるのは本当にいい。それでpushするだけでデプロイ完了。めっちゃ楽チン。

Tumblrについて

僕はTumblr大好きだったし今でも好き。本当、知ってる人の認識が「リブログ専用ブログサービス」みたいな認識なことだけはクソだと思ってるけど、これは日本のユーザコミュニティの問題なのでもうしょうがない。

Tumblrをブログサービスとしてちゃんと見た時、意外にも使いやすい。文章を書くのに必要なフォーマットはあるし、Markdownだってもちろん対応。WebAPIも用意されてるからMarsEditのようなブログ用のアプリで更新できる。

できないのはOGPにテキストタイプの投稿ではOGPにアイキャッチ画像を載せれないぐらい。コメントはdisqus使ったり、関連記事とかも工夫しなきゃいけないけど不可能ではない。

むしろ、なんだかごちゃごちゃしてて無駄な情報が多いなか、Tumblrの主流はシンプルなミニマリスティックな感じはとてもいい。もう一度言うけど、Tumblrはリブログ専用ではない。

そしてリブログがあるが故に拡散能力が高いのもポイント。普通だとRSSとか巡回や検索流入だけだけど、TumblrはDashboardを潜る(Twitterで言えばTimeLineを眺める)人も多い。そしてRTならぬReblogがある。リブログされれば別の人のTumblrに自分の記事が載る。これはなかなか伝播力あるし、リブログがリブログで広がるより一時ソースお自分の記事としてリブログされるのはかなり楽しい。

何度でも言うぞ、Tumblrはリブログ専用サービスじゃねえ。

それでも僕がTumblrを離れたわけ

そんなTumblr好きなのに別れを決意したにはやっぱり理由がある。むしろ感覚的には好きだからこそ今まで使ってきた、に近い。

テーマの自作がやや面倒

テーマは自作できるし、公式ドキュメントをしっかり読んだり、既にあるもののソースを見ればそんな難しくない。1つのテンプレートファイルで分岐でなんとかしてるってのがわかってしまえば簡単。拡張性もそこそこある。

とはいえ、Tumblrの管理画面で操作することも多く、何度も修正を繰り返すのはちょっと難儀。
バージョン管理もないし、手元で書いたソースをコンパイルして圧縮してそれをコピペしてリロードするのはやっぱり面倒。

TumblrのJavaScriptが避けれない

つまりテーマに手を加えるだけじゃAMPが使えない。強制でJSが挿入されるので。まあ無料のWebサービス使っておいてなに言ってんだ、って話ではあるけども。
AMPに対応しようと思ったら外部のサービスを使う必要があるけど、それだと自動生成にしかならないのでリッチなAMP対応ページを作れない。

エントリが管理できない

Web上のエディタにそのまま書くという暴挙なんてしない。とはいえMarsEditでやるしかない。僕はそれでもまだ不満で、エディタは一つでいい。むしろ一つがいい。

どういうことかというと、自分用にフルカスタムしたエディタで書かかないとストレスたまる。補完とか、シンタックスハイライトとか。世にMarkdownエディタはポコポコ生まれるけど、ほんと意味わかんない。エディタは自分でカスタムして、みんなが欲しいのは管理ツールだけだと思ってる。

そういうわけで、Atomで書いてMarsEditにコピペしてポストするのがおっくう。
MarsEditが最近バージョン上がって、アップグレードフィーを要求されたことと、書いたものや下書きをファイルとして管理しにくいというところも大きな要因。

今後他のプラットフォームに移行したり取り回しを考えると、.mdで保存しておけないは苦痛

Tumblr == リブログ というイメージが強すぎる

テーマを上手くやれば、このサイトはTumblrです、って言わなきゃわかんないようにはできる。独自ドメインでも運用できるし、事実、特設サイトとか簡単なものならパっとTumblrで作って潰すほうがよっぽどスピーディにできると思う。

名前を出すのは失礼かもしれないけど「Tumblr酒場」なるイベントがあるらしい。集まって飲みながらリブログするイベントらしい。リブログはTumblrの機能の一つであって、それ以上ではない。だからTumblr酒場じゃなくてリブログ酒場と名乗るべきだと思う。もう一度言うぞ、Tumblrはリブログ専用サービスじゃねえ。

もにょる

今でこそ悟りを開いたけど、苦労して書いた記事がリブログされ、嬉しくて喜んだのもつかのま、リブログ先のほうが人気があって、そこが1次ソースみたいに扱われた時の悲しさ。手柄をかっさらわれたのような感覚。

そんなことが何度かおこってから、まあでも誰にも見られないような陽の目を浴びない扱いよりはマシか、と思いなおしたけどもね。そういうのがあるとやっぱりライトユーザーはここでブログを書こうとは思わないだろうなぁ。ましてや最近はTwitterやInstagramの波及で承認欲求を大人気なく発揮するのはダサいという風潮はなくなりつつあるのだから。

じゃあHexo+Netlifyは?

そんなこんなでTumblrでやりつづけることに鬱屈を感じつつもリブログされた時の楽しさを舐めながら今までやってきて。でもまあエンジニアの端くれとして自分でフルに管理できる環境でやるか、って思ってやってみた。

結果はというと、前半でも書いたけど、めっちゃいい。
いつものエディタでガーッと書いて、コミットしてプッシュしたら新しい記事がデプロイされる。最高。

細かい設定や拡張性もある。余談だけど、過去記事は全部従来のTumblrの記事から移行してURL変わったのは全部リダイレクトしてる。RSSフィードもリダイレクトしてるからパスは変わったけど、登録しなおさなくても問題ないはず(最初だけ過去記事が配信されなおしてしまうけど)。

リブログされやすい環境は手放してしまったものの、書き易さは格段に上がったのが良い。承認欲求はそんなに高くない僕には承認欲求が満たされやすい環境より、書く時のストレスが少ない環境のほうがよっぽど大事。

昔話

僕がブログを始めたきっかけはiBlogというアプリだった。当時のMacユーザ向けに無料で配布されたアプリで、今みたいなブログサービスがほとんどない時代だった。

今風に言えば静的サイトジェネータのGUI版。あれでブログを始めて、なんかカスタマイズして。

そういえば先日、そのころのiBlogコミュニティで今もつながりある友人と会った。僕も今やWebエンジニア、彼はWebサイト制作会社のやってる。当時の話と、二人ともiBlogがなかったら当時のコーディングをあんなにがんばらなかっただろうし、今につながってないよね、なんて話をした。

今思えばiBlogが半手作り感あったからこそ、自分でテーマを作るのは当たり前の感覚になったのかもしれない。

面白いもので、あれから、GoogleBlogger使ってみたりTumblr使ってみた後で、今こうして使い出したのも静的サイトジェネレータ。やってることはGUIからCUIベースに変わっただけで、なんかまた戻ってきた感ある。

そういうわけで、まだ作りが甘いところをちょいちょい直しつつも、新しくなった環境でこれからも細々とブログ書いていきます。(Tumblrはまた独自ドメイン取る前のURLに戻して、別のものとして楽しんでやっていきます)

モンスターハンターワールド 弱点早見表

攻略サイトがたくさんあるし、同様の弱点早見表もあったり、またTwitterで誰かが作ったやつが拡散されてたりするけど、個人的にはどれも見づらい(し、間違ってたりする)ので自分のために自分で作った。

ちなみにデータはゲーム内の図鑑を参照してるので間違えないはず。
逆に言えばもっと細かいデータとかもあるんだろうけどそこには触れない。TA勢でもない限りはこれで十分だと思う。
一部表記(脚→後脚、胴など)変えたりしてるけど、普通にわかる範囲内で。
背中側と腹側とか厳密に分かれてるモンスターもいるけど、胴、でわかるはず。背中が堅いやつとか明らかにわかるので。

色のイメージと明度でわけて見やすくしてるつもりだけど、項目が多いのでまだゴチャゴチャした印象。もうちょっと淡い色が上手くつかえたらいいんだけど。
とはいえパっと見で「こいつにはコレが効く!ここが弱点!」ってのはわかりやすいかと。
使う場面は相手モンスターはわかってるので、何属性を持っていくか、自分の武器ならどこを狙えばいいか、をすぐわかるようにすることにフォーカスしたつもり。

まあ僕の主武装であるタメ砲撃メインガンスには弱点部位とか属性とか関係ないんですけどね。

それにしても夢中でやってると手に汗かいてくるので、コントローラスキンを買おうか迷ってる。以前使ってたのはかなり良かったものの貼るタイプで少し吸水性があったので汗のオイニーが気になったので一度捨てた。
赤いコントローラーとか好きなんだけど、純正マグマレッドが使いすぎで潰れたので今はもともとの黒。これにスキンでグリップ力つけて色も変えれば楽しいかなーと。値段も高くないので意外にオススメです。