タグ "Hack" が付けられた記事

これがないと捗らない、僕がカスタムしてるAtom設定(late 2017)

  1. 1. Config
  2. 2. Keymap
  3. 3. Stylesheet

前回の「これがないと捗らない、僕が使ってるAtomパッケージ(late2017)」を受けて、さらに追加でカスタムしてる部分。
つまり前回紹介したパッケージが入ってないと関係ないのもあったり。
あの大量のパッケージ郡とこの必須設定、あと紹介しなくてもいい超個人的設定を足すことで、今の僕の快適環境ができあがる。

ここまでカスタムすると他のエディタで入力しようとは思わないので、最近いろんなMarkdownエディタが増えたりしてもまったく希望に合わないのが残念。というか世間が本当に求めてるのはMarkdownビューワー兼ファイラで、エディタは外部エディタがいいんじゃないか、と思う(僕が欲しい、とも言う)。しかもLintも効かないんじゃあねぇ……

そんなこんなで大掃除ついでに設定の棚卸し第二弾。

Config

基本はPreferencesから設定すればいいと思う。というかそっちから設定してもconfigに反映される。
必須というのは日本語の約物まわりだけ、これだけで日本語入力がかなり快適に。

config.cson
"*":
# デフォルトで入ってるbracket-matherに日本語の括弧系も追加
"bracket-matcher":
autocompleteCharacters: [
"()"
"[]"
"{}"
"\"\""
"''"
"``"
"“”"
"‘’"
"«»"
"‹›"
"「」"
"『』"
"【】"
"()"
]
# custome-title用設定
core:
titleBar: "custom-inset"
"custom-title":
template: "<%= projectName %><% if (relativeFilePath) { %> - <%= relativeFilePath %><% } else { %> - <%= fileName %><% } %> <% if (gitHead) { %> [<%= gitHead %>]<% } %> - Atom"
# editor内の設定
editor:
# 文字として扱わないものにデフォルト以外の記号と日本語約物を追加
nonWordCharacters: "/\\()\"':,.;<>~!@#$%^&*|+=[]{}`?-…_、。!?「」『』【】()・”’‘~"
"toggle-quotes":
# バッククォートを追加
quoteCharacters: "\"'`"

Keymap

一部抜粋のなのでこれをこのまま使うと他のとコンフリクト起こす可能性があるので、参考程度に。
基本はEmacsのキーバインドをベース。
ただ、修飾キー周りが煩雑として特にルールもないので最近ちょっと困ってる。
なるべく各アプリやOSのデフォルトキーバインドに寄せたいが、
そのあたりのルールも明確に基準があるわけでもなく、
かといって修飾キーベースで操作単位のスコープにしたい、という思いが上手く噛み合わなくて歯痒い。

ここに書いてある以外にも大量に設定してるけどわりと良く忘れてしまうのでなんとかしたい。

keymap.cson
# for all
# ------------------------------------------------------------
'body':
# ctrl-tabによるタブ変更順を設定
'ctrl-tab ^ctrl': 'unset!'
'ctrl-tab': 'pane:show-next-item'
'ctrl-shift-tab ^ctrl': 'unset!'
'ctrl-shift-tab': 'pane:show-previous-item'
# line-jumperによる複数行移動をEmacs的キーバインドにする
'alt-v': 'line-jumper:move-up'
'alt-shift-v': 'line-jumper:select-up'
'ctrl-v': 'line-jumper:move-down'
'ctrl-shift-v': 'line-jumper:select-down'
'ctrl-k': 'editor:delete-line'

# text-editor for editing
# ------------------------------------------------------------
'atom-text-editor':
# Emacsのsubword mode的なキーバインド、キャメルケース等でも単語づつの移動が可能になる
'alt-b': 'editor:move-to-previous-subword-boundary'
'alt-backspace': 'editor:delete-to-beginning-of-subword'
'alt-d': 'editor:delete-to-end-of-subword'
'alt-f': 'editor:move-to-next-subword-boundary'
'alt-shift-b': 'editor:select-to-previous-subword-boundary'
'alt-shift-f': 'editor:select-to-next-subword-boundary'

# text-editor for editing
# ------------------------------------------------------------
# TODO: github-commitview-editor内でmulti-cursorが動かない問題
'atom-text-editor:not([mini])':
# multi-cursor-plusのキーバインド操作をemacベースにして設定
'ctrl-l': 'multi-cursor-plus:mark'
'ctrl-p': 'multi-cursor-plus:move-up'
'ctrl-n': 'multi-cursor-plus:move-down'
'ctrl-b': 'multi-cursor-plus:move-left'
'ctrl-f': 'multi-cursor-plus:move-right'
'ctrl-alt-b': 'multi-cursor-plus:move-to-beginning-of-word'
'ctrl-alt-f': 'multi-cursor-plus:move-to-end-of-word'
'ctrl-a': 'multi-cursor-plus:move-to-first-character-of-line'
'ctrl-e': 'multi-cursor-plus:move-to-end-of-line'
'ctrl-alt-home': 'multi-cursor-plus:move-to-top'
'ctrl-alt-end': 'multi-cursor-plus:move-to-bottom'
'ctrl-shift-p': 'multi-cursor-plus:select-up'
'ctrl-shift-n': 'multi-cursor-plus:select-down'
'ctrl-shift-b': 'multi-cursor-plus:select-left'
'ctrl-shift-f': 'multi-cursor-plus:select-right'
'ctrl-alt-shift-b': 'multi-cursor-plus:select-to-beginning-of-word'
'ctrl-alt-shift-f': 'multi-cursor-plus:select-to-end-of-word'
'ctrl-shift-a': 'multi-cursor-plus:select-to-first-character-of-line'
'ctrl-shift-e': 'multi-cursor-plus:select-to-end-of-line'
'ctrl-alt-shift-home': 'multi-cursor-plus:select-to-top'
'ctrl-alt-shift-end': 'multi-cursor-plus:select-to-bottom'
# Emmet展開(AquaSkk,AutoCompleteの挙動と近づける)
'ctrl-enter': 'emmet:expand-abbreviation'
# snipet展開中のカーソル移動(AquaSkk,AutoCompleteの挙動と近づける)
'tab': 'snippets:next-tab-stop'
'shift-tab': 'snippets:previous-tab-stop'
# atom-notes がeditor内からでも呼べるようにデフォルトを上書き
'cmd-shift-l': 'atom-notes:toggle'

# Stylus記述用
# ------------------------------------------------------------
# Emmet展開
'atom-text-editor[data-grammar~="stylus"]:not([mini])':
'ctrl-enter': 'emmet:expand-abbreviation-with-tab'

# Markdown記述用
# ------------------------------------------------------------
'atom-text-editor[data-grammar="text md"]':
'ctrl-backspace': 'markdown:outdent-list-item'

# Autocompleteによる補完がある場合専用
# ------------------------------------------------------------
'atom-text-editor.autocomplete-active':
# 選択をEmac的上下で可能に
'ctrl-p': 'core:move-up'
'ctrl-n': 'core:move-down'
# Enter:改行, Shift-Enter:補完入力
'enter': 'editor:newline'
'shift-enter': 'autocomplete-plus:confirm'
# Snipet展開中の場合にtabで前後の入力に移動できるように
'tab': 'snippets:next-tab-stop'
'shift-tab': 'snippets:previous-tab-stop'

# Tree view
# ------------------------------------------------------------
'.tree-view':
# toggle-vcs-ignored-filesが気づかずに誤爆するので設定なしにする
'i': 'unset!'

Stylesheet

おそらくテーマにatom-material-uiを使ってないとUI周り、tree-viewとかはほぼやりなおしな気がする。
というか、atom-material-uiのそのへんが気にくわないので直してる感じ。

他は気づきたいものはちゃんと目立たせたりとか。
あまり必要なさそうなものは載せてない。

styles.less
// 全体的なUI設定
// ------------------------------------------------------------
// 全体のフォント設定
atom-workspace {
font-family: 'Noto Sans UI', 'Noto Sans CJK JP', -apple-system,
'BlinkMacSystemFont', 'Hiragino Kaku Gothic ProN', sans-serif;
}
// tree-view, bottom-dock, right-drawerの幅制御
atom-panel-container {
.left {
max-width: 240px;
}
.right {
max-width: 240px;
}
.bottom {
max-height: 240px;
}
}
// Tree-viewの文字サイズ、行間などが納得いかないのでカスタム
.tree-view {
font-size: 0.9rem;
}
.tree-view .full-menu {
padding-left: 4px;
}
.list-tree .list-nested-item > .list-tree > li,
.list-tree .list-nested-item > .list-group > li {
padding-left: 16px;
}
.list-tree.has-collapsable-children .list-nested-item > .list-item::before {
margin-right: 4px;
}
.list-group .icon::before,
.list-tree .icon::before {
margin-right: 8px;
}
.list-tree.has-collapsable-children li.list-item {
margin-left: 14px;
}
.list-tree.has-collapsable-children .list-nested-item > .list-tree > li,
.list-tree.has-collapsable-children .list-nested-item > .list-group > li {
padding-left: 24px;
}
.list-group li:not(.list-nested-item),
.list-tree li:not(.list-nested-item),
.list-group li.list-nested-item > .list-item,
.list-tree li.list-nested-item > .list-item {
line-height: 1.5rem;
}
.list-group .selected::before,
.list-tree .selected::before {
height: 1.5rem;
}

// リガチャのあるフォントに対応(Hasklig)
// ------------------------------------------------------------
atom-text-editor {
text-rendering: optimizeLegibility;
}
atom-text-editor.editor .syntax--string.syntax--quoted,
atom-text-editor.editor .syntax--string.syntax--regexp {
-webkit-font-feature-settings: 'liga' off, 'calt' off;
}
// ファイルやフォルダ、プロジェクト、コマンド検索で使われるミニエディタをカスタム
// -------------------------------------------------------------
atom-text-editor.editor.mini {
font-size: 1.2rem;
color: #fff !important;
padding-top: 0;
line-height: 1.75rem;
}
.tree-view-search-bar .editor.mini {
font-size: 1.2rem;
}
.advanced-open-file .editor.mini {
font-size: 1.2rem;
}
.advanced-open-file li.list-item {
line-height: 1.75rem !important;
font-size: 1rem;
}
// 全角スペースを目立たせる(idegraphic-space)
// ------------------------------------------------------------
atom-text-editor,
atom-text-editor.editor {
.highlight.ideographic-space {
.region:after {
color: #800000;
content: '×';
background-color: #cccccc;
}
}
.line-number.ruby-block-highlight {
background: rgba(215, 0, 0, 0.4);
}

.highlights {
.ruby-block-highlight .region {
background: rgba(215, 0, 0, 0.4);
}
}
}
// 対応する括弧を目立たせる(Bracket-matcher)
// ------------------------------------------------------------
.bracket-matcher .region {
background: rgba(215, 0, 0, 0.4);
border: 1px solid #b71c1c !important;
position: absolute;
}
// コメントが斜体にならないようにする
// ------------------------------------------------------------
atom-text-editor.editor {
.syntax--comment {
font-style: normal;
}
}
// document-outlineがダークテーマでも問題ないように
// ------------------------------------------------------------
.document-outline heading-node.list-nested-item.highlight {
background: rgba(255, 255, 255, 0.061);
}

これがないと捗らない、僕が使ってるAtomパッケージ(late2017)

  1. 1. テーマ
    1. 1.1. UIテーマ
      1. 1.1.1. atom-material-ui
    2. 1.2. シンタックステーマ
      1. 1.2.1. gruvbox-plus-syntax
  2. 2. 共通
    1. 2.1. 選択系、変換、入力補助
      1. 2.1.1. Sublime-Style-Column-Selection
      2. 2.1.2. change-case
      3. 2.1.3. editorconfig
      4. 2.1.4. expand-region
      5. 2.1.5. highlight-column
      6. 2.1.6. highlight-line
      7. 2.1.7. highlight-selected
      8. 2.1.8. line-jumper
      9. 2.1.9. lines
      10. 2.1.10. toggle-quotes
      11. 2.1.11. toggler
      12. 2.1.12. trailing-semicolon
      13. 2.1.13. trailing-spaces
      14. 2.1.14. sequential-number
      15. 2.1.15. show-ideographic-space
      16. 2.1.16. symbols-tree-view
      17. 2.1.17. tabs-to-spaces
      18. 2.1.18. todo-show
      19. 2.1.19. multi-cursor-plus
      20. 2.1.20. pigments
      21. 2.1.21. regex-railroad-diagram
      22. 2.1.22. autocomplete-paths
    2. 2.2. ファイル、タブ、ペイン操作系
      1. 2.2.1. atom-fuzzy-grep
      2. 2.2.2. split-diff
      3. 2.2.3. advanced-open-file
      4. 2.2.4. douglas
      5. 2.2.5. expose
      6. 2.2.6. hey-pane
      7. 2.2.7. tree-view-filter
      8. 2.2.8. tree-view-git-status
      9. 2.2.9. zentabs
      10. 2.2.10. auto-encoding
      11. 2.2.11. convert-to-utf8
    3. 2.3. Linter系
      1. 2.3.1. linter
      2. 2.3.2. linter-ui-default
    4. 2.4. MiniMap系
      1. 2.4.1. minimap
      2. 2.4.2. minimap-autohider
      3. 2.4.3. minimap-find-and-replace
      4. 2.4.4. minimap-highlight-selected
      5. 2.4.5. minimap-pigments
    5. 2.5. HyperClick系
      1. 2.5.1. hyperclick
      2. 2.5.2. hyperlink-hyperclick
    6. 2.6. 汎用フォーマッタ
      1. 2.6.1. aligner
      2. 2.6.2. atom-beautify
    7. 2.7. その他
      1. 2.7.1. sync-settings
      2. 2.7.2. atom-notes
      3. 2.7.3. atomic-chrome
      4. 2.7.4. platformio-ide-terminal
      5. 2.7.5. tablr
      6. 2.7.6. preview
      7. 2.7.7. auto-update-packages
      8. 2.7.8. busy-signal
      9. 2.7.9. custom-title
      10. 2.7.10. file-icons
      11. 2.7.11. file-types
      12. 2.7.12. goto-definition
  3. 3. 各言語とか用途とか別
    1. 3.1. Git
      1. 3.1.1. gist
      2. 3.1.2. git-blame
      3. 3.1.3. git-plus
      4. 3.1.4. merge-conflicts
    2. 3.2. Markdown
      1. 3.2.1. markdown-preview-enhanced
      2. 3.2.2. document-outline
      3. 3.2.3. markdown-table-editor
      4. 3.2.4. markdown-writer
      5. 3.2.5. toggle-markdown-task
      6. 3.2.6. tidy-markdown
      7. 3.2.7. language-markdown
      8. 3.2.8. linter-textlint
    3. 3.3. JSON
      1. 3.3.1. atom-json-color
      2. 3.3.2. pretty-json
      3. 3.3.3. linter-jsonlint
    4. 3.4. Ruby
      1. 3.4.1. language-haml
      2. 3.4.2. language-slim
      3. 3.4.3. language-rspec
      4. 3.4.4. language-rabl
      5. 3.4.5. linter-rubocop
      6. 3.4.6. linter-erb
      7. 3.4.7. linter-haml
      8. 3.4.8. linter-slim
      9. 3.4.9. autocomplete-ruby
      10. 3.4.10. rubocop-auto-correct
      11. 3.4.11. rufo-atom
    5. 3.5. Rails用
      1. 3.5.1. autocomplete-rails-partial
      2. 3.5.2. rails-db-scheme
      3. 3.5.3. rails-open-rspec
      4. 3.5.4. rspec
      5. 3.5.5. ruby-block
      6. 3.5.6. rails-i18n-plus
      7. 3.5.7. rails-snippets
      8. 3.5.8. rails-transporter
    6. 3.6. JavaScript系(node.jsやメタ言語、フレームワーク含む)
      1. 3.6.1. atom-typescript
      2. 3.6.2. language-vue
      3. 3.6.3. linter-eslint
      4. 3.6.4. linter-coffeelint
      5. 3.6.5. prettier-atom
      6. 3.6.6. aligner-javascript
      7. 3.6.7. js-hyperclick
      8. 3.6.8. vue-hyperclick
      9. 3.6.9. vue2-autocomplete
      10. 3.6.10. gulp-snippets
      11. 3.6.11. jquery-snippets
    7. 3.7. HTML系(メタ言語含む)
      1. 3.7.1. language-jade
      2. 3.7.2. language-pug
      3. 3.7.3. linter-htmlhint
      4. 3.7.4. linter-pug
      5. 3.7.5. tag
      6. 3.7.6. emmet
      7. 3.7.7. indent-tooltip
    8. 3.8. CSS系(メタ言語含む)
      1. 3.8.1. Stylus
      2. 3.8.2. linter-stylelint
      3. 3.8.3. linter-scss-lint
      4. 3.8.4. linter-stylint
      5. 3.8.5. autocomplete-css-with-stylus-support
    9. 3.9. PUML
      1. 3.9.1. language-plantuml
      2. 3.9.2. plantuml-viewer
    10. 3.10. その他の言語系
      1. 3.10.1. language-apache
      2. 3.10.2. language-nginx
      3. 3.10.3. language-lisp

Atomのカスタマイズはパッケージだけじゃないんだけど、とりあえずパッケージ入れないことには始まらないってことで、2017年の棚卸し的に列挙しておこうと思う。

僕の場合、Ruby(Rails)とJavaScript,HTML,CSSを書くことが多いのでそのへんに特化してるカスタマイズになってるはず。使用パッケージが結構多くてそれぞれのパッケージ間でキーマップがバッティングしてたり、スタイルの競合がおこってたりするのでstylesheetとkeymapで弄ってたり、configで特別な設定してたりするけど、それはそれで別の記事に書く。

テーマ

UIテーマ

atom-material-ui

いろいろ設定できるし見やすいので。
ちなみに設定だけだと各種パッケージと上手く行かなかったりするので
ゴリゴリにStylesheet弄ってる。そこについては後日書きます。

シンタックステーマ

gruvbox-plus-syntax

ビビッドな発色も少なく丁度いい感じ。
すごい好きなんだけど、ややメジャーではないらしくエディタのテーマとか選べるツールとかにgruvboxテーマがないのが残念。

共通

選択系、変換、入力補助

Sublime-Style-Column-Selection

SublimeText的な矩形選択(見たままの四角の範囲を選択可能)。

change-case

選択した単語のキャメルケース、スネークケースとかを相互に変換。ケバブケースもドット記法なども幅広く対応しててうれしい。

editorconfig

コーディングフォーマット統一のためのeditorconfigをAtomで対応するためのパッケージ。

expand-region

選択範囲を文字、単語、クォートや括弧で囲んだ要素、と順々に大きくできる。

highlight-column

キャレットのある列をハイライト。

highlight-line

キャレットのある行をハイライト。

highlight-selected

選択してるものと同じものをハイライト。

line-jumper

設定した行数文だけキャレットを一気に移動する。僕はEmacsのページ送り的な送り用途として使用している。

lines

選択した複数行をA-Z順にソート

toggle-quotes

シングルクォートとダブルクォートのトグル変換。configで設定すれば例えばバッククォートも対応できたりする。

toggler

Booleanのような二元的要素をトグル変換。専用のconfigを設定すれば、自分で対応を文字列を増やせる。

trailing-semicolon

行末にセミコロンとカンマをつける。キーバインドで設定すると捗る。

trailing-spaces

行末のスペースを目立たせる。

sequential-number

複数行にわたって連番生成連番の文字列を生成。

show-ideographic-space

全角スペースを目立たせる。わかりやすくStylesheetでカスタムした設定すると良い感じ。

symbols-tree-view

メソッド定義などの一覧をドロワーにツリー型で表示。

tabs-to-spaces

インデントのタブorスペースをトグル変換。ファイル保存時にファイル全体に対して自動実行も可能。

todo-show

プロジェクト内に存在するTODOやNOTEなどのコメントを抽出して表示。

multi-cursor-plus

デフォルトより高機能なマルチカーソル。キーバインドがバッティングしやすいので僕はゴリゴリにkeymapを編集してる。

pigments

カラーコードになってる部分をその色で表示。CSSとか書くなら。StylusやSassの変数も対応してるので重宝する。

regex-railroad-diagram

正規表現をビジュアルで表示してくれる。

autocomplete-paths

path入力のAutocompleteアドオン、でもたまに邪魔なときがある気がする。

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

atom-fuzzy-grep

プロジェクト内をag的なfuzzyGrepしてファイル表示。

split-diff

Paneで分割してDiff表示、見やすい。しかも保存してない状態でもDiffとれるので、長大な文字列とか大きめなオブジェクトを一時的に比較する時も重宝する。

advanced-open-file

ディレクトリ毎に絞り込みでファイルを開ける、フルキーボードで階層ごとに掘っていく場合に便利。

douglas

CLI用リポジトリ管理ツールghqのローカル管理下にあるプロジェクトのショートカット、全てのプロジェクトがGit管理されていればプロジェクトマネージャーはこれだけで十分だと思う。

expose

開いてるタブをmacのexpose的に表示、切り替えできるやつ。

hey-pane

複数paneで分割してる時にアクティブなペインを自動的にほぼ最大化する。フォーカスしたペインに自動的に適用したりもできる。

tree-view-filter

tree-viewで表示しているファイルをインクリメンタルに絞り込む。

tree-view-git-status

tree-view上でgit-statusによる色分け表示する。追加ファイルや変更したファイルとかが視覚的にわかりやすいし、未コミットのファイルもみつけやすい。

zentabs

最大タブ数の設定制御。設定数を越えると古いタブから自動的に閉じていれ変わる挙動になる。設定でピン止めしたファイルや、未コミットファイル除外したりもできる。たくさんファイル開きすぎてわかんなくなっちゃうので。

auto-encoding

エンコーディングの自動判別。

convert-to-utf8

マルチバイトのファイルをutf-8に変換。

Linter系

linter

Linter機能。各言語用は後述。ないと死ぬ。
各言語用のLintは後述。

linter-ui-default

Linter表示用。たぶんLinter入れると入ってくるはず。

MiniMap系

minimap

画面端にコード全体をざっと単純化して見わたせるようなやつを表示。他のパッケージで拡張可能。

minimap-autohider

ミニマップをスクロールしてない時以外は自動的に非表示。

minimap-find-and-replace

ミニマップ内で検索文字列を全てハイライト。

minimap-highlight-selected

ミニマップ内で選択した文字を全てハイライト。

minimap-pigments

ミニマップ内でカラーコード部分をカラー表示。

HyperClick系

hyperclick

コード中のいろんな要素がクリッカブルになる、キーバインドにも対応してるので対象の文字列にキャレットがある時にキー操作でも動作できる。**-hyperclick系のアドオンとかで拡張可能。言語特化のアドオンは、後述の言語別のところで。

URLをクリッカブルにしてデフォルトブラウザで開けるようになる。

汎用フォーマッタ

aligner

オブジェクトの定義とか、連続して変数に値を入れるとき、=:をセパレータとして左右のインデントが揃うようにしてくれるフォーマッタ。言語別のものもある。

atom-beautify

ネストした要素のインデントをうまいこと整形してくれるフォーマッタ。JSONとかも良い感じにやってくれたり。けっこういろいろ対応してる。

その他

sync-settings

GitHubGist経由でAtomの設定を複数端末で同期する、アンインストールしたパッケージも同期できるようになって凄く便利になった、ないと死ぬ。

atom-notes

notational-velocityライクなノートシステムをAtomに組み込み、メモ系の集積ができてそれがカスタマイズした強力な補完機能のAtomで編集できるのは強み。ないと死ぬ。

atomic-chrome

同名のchrome-extensionをGoogle Chrome系のブラウザに入れることで、ブラウザで開いてるページのtextareaを同期的にAtomで編集できるようになる。例えばPull RequestなどMarkdown対応のテキストエリアをAtomで編集できるのはかなり便利。ないと死ぬ。

platformio-ide-terminal

Atom内でターミナルを動作させる。

tablr

CSVエディタ。

preview

プリプロセッサ言語から元言語へコンパイル後の表示。

auto-update-packages

パッケージにアップデートがあったら自動でアップデートする。ちょいちょい自分で確認しなくていいので楽。

busy-signal

ステータスバーに状況表示アイコンをプラス。確かLinterと一緒に入ってくるはず。

custom-title

Atomのウインドウに表示されるタイトルのルールを変更できるようになる。上手く好きなようにファイル名の表示とかにカスタマイズすると地味に便利。

file-icons

ツリービューやタブにファイルのアイコンを表示して視認性を上げる。わりとないと死ぬ。現在もアップデートが盛んでちょいちょい対応アイコン増えてるのがうれしい。

file-types

自動で判別されるファイルタイプのルールをカスタマイズを楽にする。

goto-definition

メソッドの定義元にジャンプできるようになる。

各言語とか用途とか別

Git

gist

GitHubのGistを編集したりアップロードしたり、挿入したり。Gist系はいくつかあったけどこれが一番使いやすかった。

git-blame

行ごとにgitで変更した人を表示する。

git-plus

よく使うgit操作をAtomから直でできる、Atomのコマンド補完が効くので便利、基本的なgit操作はこれだけでいける。わりとないと死ぬ。

merge-conflicts

gitでmergeしようとしてコンフリクトした時の編集サポート。コンフリクトの解消はGitKrakenでやってるけど、一応入れてる。

Markdown

markdown-preview-enhanced

デフォルトのMarkdownプレビューより高機能なプレビュー、TOCやプレゼンモードもあったりする。目次機能もあったり、いろいろと便利。

document-outline

右ドロワーに編集中のMarkdownの目次をページ内リンク付きで表示。

markdown-table-editor

Markdownのテーブル記法編集補助、うまいこと縦のカラム表示を整えてくれる。

markdown-writer

Markdownの全般的な入力補助。とりあえず入れてる。

toggle-markdown-task

Markdownのチェックボックス記法のチェック状態のトグル変換。そんなに使わないけどいちいちキャレットを移動するのが面倒なので。

tidy-markdown

Markdownのテーブル記法の整形や番号付きリスト記法の番号振りなおしなど、フォーマッタ。

language-markdown

デフォルトのものより高機能なハイライタ。

linter-textlint

特に日本語に強い自然言語用のLinter、textlintをAtomで使えるように。Markdown以外でも効く。

JSON

atom-json-color

JSONファイルを階層によってカラーリングを変えて視認性を上げる。

pretty-json

JSONファイルの整形フォーマッタ。

linter-jsonlint

JSON用のLinterアドオン。

Ruby

language-haml

haml用の言語ファイル。

language-slim

Slim用の言語ファイル。

language-rspec

Rspec(Rubyのテストフレームワーク)用の言語ファイル。

language-rabl

Rabl(Ruby用のJSONやxmlに特化したテンプレートサポートGem)用の言語ファイル。

linter-rubocop

Rubocop用のLinterアドオン。

linter-erb

erb用のLinterアドオン。

linter-haml

haml用のLinterアドオン。

linter-slim

slim用のLinterアドオン。

autocomplete-ruby

Ruby用のAutocompleteアドオン。

rubocop-auto-correct

Rubocopルールに従って自動修正。

rufo-atom

Ruby用フォーマッタのrufoをAtomから実行、まだsave時に自動でやってくれたりはしないもよう。JSのprettierな感じになってくれるとうれしいな。

Rails用

autocomplete-rails-partial

Railsのパーシャビュー名のための用Autocompleteアドオン。

rails-db-scheme

schema.rbを参照して自動補完や定義元にジャンプ。

rails-open-rspec

現在開いてるファイルに対応したRspecのファイルを開く。

rspec

Atom上でRspecをrun。

ruby-block

do``if``begenendなどの対になるブロック要素をハイライト。

rails-i18n-plus

Railsのi18n用のAutocompleteとHyperClickアドオンのセット。

rails-snippets

Rails用のスニペット集。

rails-transporter

Model,View,Controllerなど対応するファイル同士を素早く開けるようにする。

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

atom-typescript

TypeScriptの言語ファイルか補完や便利機能まで、IDE的サポート。

language-vue

Vue.js用の言語ファイル。

linter-eslint

JavaScript用のLintパッケージであるEslintのAtom-lintアドオン、prettierと連携もできる、ないと死ぬ。

linter-coffeelint

CoffeeScript用のLinterアドオン。

prettier-atom

JSのフォーマッタprettierをAtomから実行、save時に自動実行できる、ないと死ぬ。

aligner-javascript

JavaScript用のalignerアドオン。

js-hyperclick

JavaScript用のHyperClickアドオン。

vue-hyperclick

vue.js用HyperClickアドオン。

vue2-autocomplete

Vue.js用Autocompleteアドオン。

gulp-snippets

gulp用のスニペット集。

jquery-snippets

jquery用のスニペット集。

HTML系(メタ言語含む)

個人的にはPug(Jade)しか書きたくないけど、どうしても使わざるを得ないので他も少々。

language-jade

HTMLプリプロセッサJade用の言語ファイル。

language-pug

JadeはPugになりました。

linter-htmlhint

HTML用Linterアドオン。

linter-pug

Pug用Linterアドオン。

tag

HTMLの閉じタグのショートカットと補完。Pugで書けばいらないんだけどね。

emmet

html,css(プリプロセッサ含む)の強力なスニペット集。

indent-tooltip

Jade(pug)やStylus,Sassのインデントベース記法の環境で現在のキャレットの位置がどの要素のネスト中なのかツールチップで表示。

CSS系(メタ言語含む)

個人的にはStylusしか書きたくないけど、どうしても使わざるを得ないので他も少々。

Stylus

Stylus用の言語ファイルとスニペット集。

linter-stylelint

CSS用のLinterアドオン。

linter-scss-lint

SCSS(SASS含む)のLinterアドオン。

linter-stylint

Stylus用のLinterアドオン。

autocomplete-css-with-stylus-support

Stylus用のAutocompleteアドオン。

PUML

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

language-plantuml

PlantUMLの言語ファイル

plantuml-viewer

PlantUML用のUML図ビューワ

その他の言語系

language-apache

language-nginx

language-lisp

俺の好きなフォントで読ませろ2017年夏決定版

  1. 1. 俺の好きなフォントで読ませろ2017年夏決定版
  2. 2. 俺は俺の好きなフォントで読むぜ
  3. 3. Gist
  4. 4. ちょっと説明とか
    1. 4.1. 使用フォント
    2. 4.2. 上手く表示できないこと
    3. 4.3. 適用範囲
  5. 5. フォントに関してあれこれ

俺の好きなフォントで読ませろ2017年夏決定版

WebサイトにCSSを書くとき、font-familyをどうするか問題。そこに銀の弾丸はない。常々、サイト側がfont-familyを設定するのは装飾的な要素のフォントを使う時以外はエゴだと思ってる。かといってレガシーめなブラウザだとあまり美しくないフォントがデフォルトになってることもまだあるので、やはりfont-familyをある程度設定されるのは今のところは仕方ないと思ってる。

俺は俺の好きなフォントで読むぜ

そもそもだ、あまり読みやすさにこだわってるサイトはそんな多くない気がする。特に日本語のブログ界隈。そこで、もういっそ俺の好きなフォント設定で読ませやがれ、と思ってStylishで殴りつける方法で解決することにした。
註:Stylish:ユーザー側でスタイルシートを設定できるブラウザ拡張。

Gist

/*
Force global font setting
^(?!https?://(.*).?(localhost|192.168.)).*$
*/

@font-face {
font-family: 'Noto Sans';
font-weight: 100;
font-weight: 200;
font-weight: 300;
font-weight: 400;
font-weight: 500;
src: local('NotoSans');
font-display: swap;
}
@font-face {
font-family: 'Noto Sans';
font-weight: 600;
font-weight: 700;
font-weight: 800;
font-weight: 900;
src: local('NotoSans-Bold');
font-display: swap;
}
@font-face {
font-family: 'Noto Sans CJK JP';
font-weight: 100;
font-weight: 200;
font-weight: 300;
font-weight: 400;
font-weight: 500;
src: local('NotoSansCJKjp-Regular'),
local('SourceHanSansJP-Regular'),
local('Noto Sans CJK JP'),
local('Source Han Sans JP'),
url(//fonts.gstatic.com/ea/notosansjapanese/v6/NotoSansJP-Regular.woff2) format('woff2'),
url(//fonts.gstatic.com/ea/notosansjapanese/v6/NotoSansJP-Regular.woff) format('woff'),
url(//fonts.gstatic.com/ea/notosansjapanese/v6/NotoSansJP-Regular.otf) format('opentype');
font-display: swap;
}
@font-face {
font-family: 'Noto Sans CJK JP';
font-weight: 600;
font-weight: 700;
font-weight: 800;
font-weight: 900;
src: local('NotoSansCJKjp-Bold'),
local('SourceHanSansJP-Bold'),
local('Noto Sans CJK JP'),
local('Source Han Sans JP'),
url(//fonts.gstatic.com/ea/notosansjapanese/v6/NotoSansJP-Bold.woff2) format('woff2'),
url(//fonts.gstatic.com/ea/notosansjapanese/v6/NotoSansJP-Bold.woff) format('woff'),
url(//fonts.gstatic.com/ea/notosansjapanese/v6/NotoSansJP-Bold.otf) format('opentype');
font-display: swap;
}
@font-face {
font-family: 'YakuHanJPs';
font-weight: 100;
font-weight: 200;
font-weight: 300;
font-weight: 400;
font-weight: 500;
src: url("https://cdn.jsdelivr.net/npm/yakuhanjp@2.0.0/dist/fonts/YakuHanJPs/YakuHanJPs-Regular.woff2") format("woff2"),
url("https://cdn.jsdelivr.net/npm/yakuhanjp@2.0.0/dist/fonts/YakuHanJPs/YakuHanJPs-Regular.woff") format("woff");
font-display: swap;
}
@font-face {
font-family: 'YakuHanJPs';
font-weight: 600;
font-weight: 700;
font-weight: 800;
font-weight: 900;
src: url("https://cdn.jsdelivr.net/npm/yakuhanjp@2.0.0/dist/fonts/YakuHanJPs/YakuHanJPs-Bold.woff2") format("woff2"),
url("https://cdn.jsdelivr.net/npm/yakuhanjp@2.0.0/dist/fonts/YakuHanJPs/YakuHanJPs-Bold.woff") format("woff");
font-display: swap;
}
*:not([class*="ico"]):not(.fa):not(.DPvwYc):not(i){
font-family: 'Noto Sans', 'YakuHanJPs', 'Noto Sans CJK JP', sans-serif;
-webkit-font-smoothing: subpixel-antialiased;
}
h1, h1 *:not(p), h2, h2 *:not(p), h3, h3 *:not(p), h4, h4 *:not(p), h5, h5 *:not(p),
li, li *:not(p), dd, dd *:not(p), dt, dt *:not(p), th, th *:not(p), td, td *:not(p),
figcaption, figcaption *:not(p), caption, caption *:not(p),
cite, cite *:not(p), label, label *:not(p), select > option {
font-feature-settings: "palt" 1;
}
pre, pre *,
code, code *,
kbd, kbd *,
samp, samp *,
var, var *,
.blob-wrapper * {
font-family: Hasklig, 'Source Han Code JP', monospace !important;
text-align: left;
}
p {
letter-spacing: 0.038em;
word-wrap: break-word;
font-feature-settings: "palt" 0;
}
:lang(en) p {
text-align: left;
}

ちょっと説明とか

使用フォント

以下のフォントを使ってるのでまんま使うならインストールしておいて下さい。

  • 源真ゴシック
  • Noto Sans
  • Hasklig
  • Nasu

完全に個人的な趣味。アルファベットはNoto Sansを使って、日本語は源真ゴシック。コーディングフォントはまだ納得行ってないけど今のところ良く使ってる構成で。こういう和英混植の場合の英字フォントを先に指定して、優先させるハックは好みのフォントを設定しやすいので好き。

もし好きなフォントがあって使いたかったら適宜CSSを修正してください。

上手く表示できないこと

コード表示まわりはいろいろややこしかったりするんですが、上手いこと全称セレクタとか:notセレクタとかで回避したつもりです。が、対応しきれない場合があります(特にアイコンフォント)。

行がぴっしりそろうように、スペースで単語を区切らない日本語を逆手にとったtext-align:justifyハックしてます。故に、日本語だけのときはいいんですが、長めのアルファベットが連続した場合、行の表示が変になることがあります。

適用範囲

頭の部分にコメントアウトしてあるけど、開発する時は当たってほしくないので正規表現でサイトを指定。Stylish側の設定が「正規表現がマッチするサイト」という形なので、正規表現は設定したドメインを「含まないもの」にしておく。お好みで。

フォントに関してあれこれ

一番いいのは、既存のフォントを元に自分の好きなフォントを組み合わせてつくれたら良いんだけど。Font forge使ってやろうとしたけどリガチャ回りとか上手くいかず挫折。そのうちまたチャレンジする。

次に良いのはブラウザ側の標準機能で、英字フォントはこれ、和文にはこれ、monospaceだったらこれ、みたいにできればいい。(現状ある程度は細かくできるけど)。ただし、これだと冒頭で言ったようにサイト側のCSSに設定されてるとアウトなので痛し痒し。これが「font-familyの決定版!」とか言うのにエゴだと良いたくなる元凶。

ただ、せっかく作ったサイトをあまり美しくないフォントで見られるのはたまらねえ、って意見もわからなくない。けど、それこそがエゴなんだけど。そんなことを言う前にletter-spacingline-heightを追いこめ。(上記設定でどちらにも触れてないのは、一律にStylishで汎用的に上書きするのが難しかった為、妥協した。)

OSのデフォルトフォントと、ブラウザのデフォルトフォントと、捨てられない下方互換が生んだ膿なんだろうなぁ。ブラウザのデフォルトフォント問題はそのうち解決されそう。なのでサイト側のCSS最適解がfont-family:sans-serif;だけになるのもそう遠くない日だろう。

Mac周りをいろいろと物理的にアップデートした

  1. 1. MacBook Pro 13inch BTOカスタムを買いました
    1. 1.1. カスタムの話
  2. 2. 4Kディスプレイを新調しました
    1. 2.1. Macと接続する話
  3. 3. Ergodox + MagicTrackPad
  4. 4. Macの移行とか
  • 7/2 解像度まわりに関してちょっと誤解があったため追記

いろいろたてつづけにMac周りの環境をアップデートした話。ちょっとお金に余裕ができたから環境をアップグレードしてみたら、Macを変えなきゃいけなくなって、結果的に予想以上にお金はとんでった。それでも環境も良くなったので幸せっちゃあ幸せ。その顛末の話。

MacBook Pro 13inch BTOカスタムを買いました

巷ではMacが出るたびにMacってそんなに良くないでしょ教とスタバでノマド宗が対立するわけだけど、彼等はコマンド叩かない派だろうなので別世界の闘争ですね。

そもそもそろそろとは思ってたもののMacを買い変える予定はなかった。だが、WWDCを控えたある日、リッドクローズ(クラムシェル)モードで使ってたMacBook Airに異変があったことに気づいてしまった。クローズできてない。殻を閉じてるはずの貝が半開きだ。確認したらバッテリーがわずかに膨張してた…。思いあたるのはなんか回してたプロセスが暴走してるなーって思ってたけどほっといたことがあって、長時間高負荷高熱状態が続いたんでしょう、きっと。

そんなわけで、WWDCもちょうどあってラップトップのアップデートが来るとの話もあり、買い替えることに。ちなみに瀕死のMacBook Airは修理に出して戻ってきたら妻さんにあげる予定。

カスタムの話

僕は今の職場の影響もあって現在はUSキーボードに慣れてしまったので、BTOモデルで。あ、印字がカッコイイとか見栄えのどうでもいい話じゃない。US配列のほうが記号系が打ち易い、あとSKK派としてはかな/英数キーとかどうでもいいです。必要でもKarabinerでコマンドキーをDoubleFunctionにすればいいし。普段は家で外付けキーボード使うけど、持ち出すこともあるので、一応US配列にしといた。これは後から変えられないし。

あとはメモリとSSD容量を増設。CPUはそのまんま。MacBookAirの時にやっぱり256GBだとちょっと窮屈だったり、外付けHDDと併用して整理する必要があったのでここは余裕を持たせる為に増設。メモリも念のため。CPUは一時的に高負荷になることはあるだろうけど、まあ予算的に泣いた感じで妥協した。

ともかく考えたのは、基本は今までどおり家での外付けをバシバシ繋げてデスクトップ的に使う運用をメインとしつつ、いざとなったら持ち運んでもそれだけで(いろんなもの持たなくても)大丈夫なように。という感じで。15インチか迷ったけど予算と持ち運び時の利便性を重視して13で。ということで、基本閉じてるためにTouchBarはないモデル。(あのオプション高いし、物理ESCキーは欲しいし、タッチバーって手元に近いところに視線を移す必要があるのはなんか違うんじゃないのかね)

4Kディスプレイを新調しました

職場でRetinaのMacBookProを使い出して、やっぱりフォントがくっきりパッキリキレイなのは良いなぁと思ってしまって。じゃあ家でもってことで4Kにすることにした。

で、結局買ったのが「KEIAN KWIN-4K32B 4K液晶ディスプレイ 32型大型ワイド」

結果的に言えば、ちょっと大きすぎた。大きくても27インチぐらいがベストだったかもしれない。ただ、しっかりと4KなのでQuickRes使って、HiDPIモードシステム環境設定の解像度調節をOptionキーを押しながら設定することで細かく調整できる。なのでRetina的な表示で1920x1080にしてるとかなり良い感じ。でもやっぱり27インチにしといても良かったと思いつつも、実はこのディスプレイ、DELLとかの割と安価なディスプレイに比べてもまだ安い。4K32インチで4万円をきってくるのはお買い得。しかもIPSパネル。

その分、発色まわりはちょっと残念かな、この辺は画質調整次第ですこし改善できるから良しとする。個人的のはグレアパネルが反射しすぎて苦手なのでノングレアなのもうれしい。それと、スタンドまわりはかなりやっかい。まず付属のスタンドはそんな良くない。僕はアーム派なのでどうでもいいと思いきや、VESAの200x100アダプタを噛ませたんだけど、なんとディスプレイ本体につけるビスの径が違う。具体的には通常だとM4規格なのにこの本体側の穴はM6。確かに32インチになると重さもあるのでそっちのほうがいいんだけど、普通にやったらハマらない。

で、結局アーム側のアダプタの穴をダイヤモンドヤスリでしこしこと削って拡張して合わせた。一つにつき円状に2mmづつ広げる、これを4箇所。丸一日かかりました。

Macと接続する話

でまわってるケーブルとかの情報は本当クソだ。HDMI1.4のものなのか、2.0のものなのか悪意を感じられるレベルで情報不足。どいつもこいつも「4K対応!」って謳いすぎ。4K/60Hz対応(HDMI2.0)なのか、4K/30Hz(HDMI1.4)どまりなのか全然わかりゃしない。というか4K!みたいに言ってる機器はほぼHDMI1.4なので本当注意が必要。つかませる気マンマンの意図が透けて見えやがる。

詳しくは調べてもらえばいいけど、「4K」とは通称で、4000を意味するのみ。解像度の長辺側がだいたい4000pxであればなんでも4Kといって良いらしい。HDMI1.4でも2.0でもどちらも事実上は「4K」出力は可能だけど、伝送量は桁が違う。1.4は3840×2160(30Hz)、4096×2160(24Hz)が限界だ。HDMI2.0であれば4096×2160(60Hz)でいける。ゲームとか動きの速くない動画じゃなければいいと思うかもしれない。だけどできるのにケーブルの問題でできないのは気にくわない。HDMIっていうれっきとした規格があるんだからそれを明記しないで、単に「4K!」と喧伝するのは本当底意地が悪い。

そんな中で、僕の選んだ接続環境は「AUKEY USB C ハブ 4K HDMI 出力 4x USB3.0 ポート ( USB Type c パワーデリバリー 充電ポート付き )」と「Plugable USB Type-C(USB-C)- HDMI 2.0 変換ケーブル」にした。MacBook Pro専用の二つのUSBを使って横にぴったりドック的に着くスタイリッシュなアダプタと悩んだけど、最終的にはこの構成に落ちついた。というのも

  • ドック的な奴でHDMI2.0対応明記がみつからなかったのと、どうも発熱問題があるっぽい
  • MacBook Pro専用よりかは汎用のほうがなにかと良いだろう
  • ドック的な奴でよくついてるカードリーダーは別にUSBの口さえあればUSBカードリーダーでどうとでもなる
  • 家以外の環境で使った時にHDMI-HDMIが必要な日が来るかもしれないのであるにこしたことはない
  • 家で使う分にはHDMIアダプタ経由にしてしまうとアダプタが劣化した時に面倒(以前にアダプタが接続不良になって難儀した)
  • Thunderbolt-HDMIのこのケーブルの公式で謳ってる説明の説得力

7/2 追記の補足。QuickResのほうがさらに細かく設定できるのは間違いないけど、純粋に倍のピクセル密度にしないと疑似になってしまうため、60Hzでず、30Hzで表示される。動画もあまりみないし、ゲームもMacではしないので大したことないと思いきやマウスカーソルの滑かさですでに驚愕だったので、60Hzつまり60fpsで動作させることを優先させた。

という理由から


現在の使ってる環境

  • macOS sierraでQuickRes使用のHiDPIモード、2048x1152の解像度
  • macOS sierraで解像度設定をOption押しながらの調節で1920x1080の60Hzで動作
  • default writeで外部ディスプレイ用のフォントアンチエイリアスを調整
  • Ergotronの100x100のVESAマウンタに200x100のアダプタ噛ませて、ビス穴拡張してKEIANと繋げた
  • Mac-Thunderbolt to HDMI2.0ケーブル-KEIANディスプレイ(直結)
  • USB接続はAUKEYのアダプタで、電源もパワーデリバリー経由で取る

Ergodox + MagicTrackPad

以前からつかってた変態キーボードKinesisですが、Ergodoxに乗り変えてしまった。セパレート型にあこがれて。
Ergodoxで情報を見るとよく親指Enterとかに慣れないって言うけど、僕の場合はKinesisで慣れたのでまったく問題ない。

スイッチは秋葉原に繰り出してCherry MXの打ち心地の違いを入念にチェック、スコスコ軽く打ててそれでいて音がしない感じが好きなので、一番肌に合ったのはピンク軸。ただ、Ergodox EZの場合、CherryMX互換のGeteronだからピンク軸はない(当時。現在もピンク軸はないもののErgodox EZの軸はCherryMXが正式採用された模様)。そこで、密かに試してみたかった赤軸+静音リング。ピンク軸まで満足度は高くないものの、十分満足できる範囲だったので、Ergodox EZ 赤軸 + 静音リング二つが現在の仕様。打ち心地に関しては満足してる。

そのうち紹介したいと思うけど、親指に割りあてたEnterBackspaceの配置をKinesisを使ってた時から逆にした。これが慣れずに誤爆すること多数。また、MagicTrackPadも未だ置き場所が確定してない。左右の間に置くのがいいのか、右のさらに右に置くのがいいのか。一つ言えるのは手全体の動きが少なくなるようにするのが良いので専用の台を仮につくったらちょっと使いやすくなった。この方向でもっと改良していきたい。

ちなみにキー配置に関してはけっこう弄ってる。ファームウェアのビルドもDockerで難なくできるし、カスタムもそう難しくない。タップと押し続けて違う動作をさせられるのでこれでKarabinerへの依存が減ると思いきや、挙動に納得行かずDoubleFunctionはKarabinerにまかせてる。どうせ他の機能の実現でもKarabinerに頼らざるを得ないし。

あとは細かいカスタムで言うと、ホームポジションのポッチがなくてわかりにくいのはいろいろ試した結果、ダイモ(エンボスのラベルテープが作れるテプラ的なやつ)で作ったテープを貼ったらすごく良い感じになったので、誰かに伝えていきたい。

Macの移行とか

僕はMacのOSをアップグレードする時とか、本体を乗り変える時、前のデータをまんま移行しない派。以前の移行アシスタントは信頼性に欠ける時代があったのと、環境をきれいにする良いきっかけになるから。

今回はBrew Caskを使い出したのでかなり楽にいろいろとインストールできたと思う。それに付随するようにいろいろ初期設定とかダウンロードとかやってくれるシェルスクリプトを書いて実行したんだけど、ちょっと上手くいかなかったこともあるのでもうちょっと改良していきたい。

ただ、それだけで当然カバーできない設定もけっこうあってこの週末でようやく整ったかな、って感じ。
ともあれ、ムダにデカいディスプレイもフォントをパッキリ表示してくれるし、キーボードも馴染んできたし、Macも速くなったので万々歳。一気にやったからお金がいっぺんに出てってしまったこと意外は大満足。

Macの初期設定やら、Ergodoxとかの話はもうちょっとつっこんでまた書きます。

Atomで新規ファイルのデフォルトのSyntaxをなんとかする

  1. 1. 新規ファイルの設定をする
    1. 1.1. Init Script を弄る

どうも。通常の文書はなんでもMarkdown、そして気にいったテキストエディタで書ければいいのに、と思ってる僕です。
Markdownエディタがそれなりにあるけど、やっぱり慣れ親しんだというか、Packageいろいろ積んで自分好みに最高になったAtom君で何でも書きたいわけですよ、僕は。

新規ファイルの設定をする

AtomはPreference以外でもいろいろ弄くれるので、今回はそれを弄る。New File… とかで新しくファイルを作った時、もしくはファイルを開いたけど、拡張子などから特に設定が見つからなかった時のデフォルトのファイルのSyntaxを変える方法。

Init Script を弄る

MacならメニューバーからAtom>Init Script...と選択すると、init.coffeeファイルが開ける。ここでinit、つまり初期化設定をしてるので、これを上手く編集してやればSyntaxの初期値が設定できる。

デフォルトでは説明と例がコメントアウトで書いてあるので、実質何も動いてない。これに以下のように付け足す。

atom.workspace.observeTextEditors (editor) ->
    original = editor.getGrammar()
    if original? and original is     atom.grammars.grammarForScopeName('text.plain.null-grammar')
        editor.setGrammar(atom.grammars.grammarForScopeName('text.md'))

この設定の最後の部分のtext.mdが実際に設定されるScopeNameとなる。使いたいSyntaxのパッケージ、つまりLanguage-markdownをPreferenceで見て、GrammerのところにScope:text.mdとかあるのでそれを書く。
たとえばHTMLならtext.html.basicになる。

これで設定したら保存してAtomを再起動すれば適用されている。

ボドゲ「インカの黄金」のカードデザインが納得行かないので自作した

  1. 1. インカの黄金の面白さと問題
    1. 1.1. ルール
    2. 1.2. デフォルトカードの問題
  2. 2. よろしい、ならば作ってしまえ
    1. 2.1. コンセプト
      1. 2.1.1. バリアントルール「ダッシュ」
    2. 2.2. 自作
      1. 2.2.1. 出力
      2. 2.2.2. カット
      3. 2.2.3. 貼り
    3. 2.3. あとは遊ぶだけ

「インカの黄金」という割と定番でとっつきやすく楽しめるチキンレース系のボドゲは知ってるかい?ボドゲを普段やらない層でも簡単に理解できて楽しめるので重宝してるんだけど、どうしてもカードデザインが納得行かないので自作して改良する話。

インカの黄金の面白さと問題

ルール

ルールを簡単に説明すると、

  1. プレイヤーは探検家になって遺跡をみんなで一緒に探検
  2. ターン毎に進むのか帰還するのかをせーので選択
  3. 予想される状況は財宝か罠
  4. 獲得した財宝は罠にかかることなく生還しないと持ち帰れない(いわゆるチキンレース)
  5. 獲得人数で割り切れない財宝の場合、置いたままにして帰還する時にそのターンの帰還者数で割る

というのが主なルール。つまりギリギリまで粘って進み、かつ、帰還する時は他プレイヤーとタイミングが被らないようにする、というの最適解のゲーム。他プレイヤーと帰還のタイミングが被ると帰り道にある財宝をも人数で割る必要があるので、獲得できる可能性が減る。ここが面白いポイント。行くか、帰るか、そろそろ罠で死ぬかもしれないがおそらく他のプレイヤーも同じこと考えてる。帰るなら一人のタイミングで帰る必要があるし、行くのも帰るのも判断に悩む。というのが醍醐味。

デフォルトカードの問題

ルール的に、せーのっで他プレイヤーと同時に次の行動を表示する。ここで、お前まだ行くのか!もう帰るのか!うわー、帰還タイミング被ったわー、と盛りあがる。そう、ここがポイント。

実はインカの黄金は「ダイヤモンド」というゲームで従来は「進むトークン」を握って、せーのでみんなで手を広げるゲーム。インカの黄金になって、進むと帰還を示すのはそれぞれのカードで、せーので裏で出していたカードを表にする、というやり方に変わった。ここまでは良いんだけど、問題は進むカードと帰還カードのデザインがいまいちパっと見てわかりにくいのが問題。


どうこれ?パっと見わかんなくない?左が帰還で右が進む。

世界観も重要なのでデザインにこだわってるのは素敵だけど、この判別のつきづらさはいただけない。初心者が行くと帰還を間違えることもあれば、せーのでめくった時に瞬間的に判断できることが重要。ん、どっちだ、って一瞬でも考えるようであればその面白さを損なわれてしまう。

よろしい、ならば作ってしまえ

コンセプト

間違えない、一瞬でわかる、がもっとも重要視すべきポイント。できれば世界観に沿ったものにはしたかったけど、この際それは切り捨てた。

誰でもわかる、ということでピクトグラムを採用。わかりやすく大きく文字をつけ、色も使って危険なのか安全なのかも表現。これならば間違えないはず。

そして今回はせっかくなんでバリアントルール用ダッシュカードも作ってみた。

バリアントルール「ダッシュ」

仲間うちでやってみて割と良いアクセントになってるのが、このダッシュルール。

  1. 5ラウンドで1ゲームだが、1ゲーム中に一度だけ使い捨てで使える
  2. そのターンの効果をダッシュしたプレイヤーだけで受けることができる
    • 例えば障害なら障害を一人で受け、ダッシュしてないプレイヤーは障害としてカウントされない
    • 財宝ならばダッシュしたプレイヤーだけで分配、一人なら一人占め

自作

今回の方法として、画像をベクター形式で作ったものをA4に適当に面付けして、それをシール紙に出力。カットしたものを別途購入したブランクカードに貼る、という方法。ちなみに元画像はピクトグラムをフリーで配布しているところから使わせていただいた

ヒューマンピクトグラム2.0

カードのほうは自作ゲームでも使われてるらしいものを。そこまで高額なものでもないので。

出力

シール紙に出力したけど、今回は耐水性の光沢紙をチョイス。最初に普通のシール紙を買ったら間違えて4つ切りのを買ってしまった。結果的には発色も良くなかったのでまあ良いか。ということで光沢紙を買ったけど、剥離側も印刷面も光沢でわからなかったので間違えて剥離紙側に印刷してしまって失敗。

という紆余曲折あったものの、無事完了。発色も光沢も良い。耐水性もあるらしいので良い感じ。文句をつけるとすれば滑りにくいので、プレイ時にひっかかりを感じないかどうか、という点。ただし、ゲームの性質上すばやくカードを操作する必要も、多く持つ必要もないので大丈夫そう。あとは耐摩耗性がどの程度あるか。

カット

裁ち落としするために一般的な3mmの広くとって、トンボ的なガイドラインを付けたものを用意した。なのでこのガイドに従って切っった。これは上手くいった感じ。


ついでに角丸君をつかって角を落としていく。一つ4つだから意外に数が多かったけど、簡単なので良しとしよう。カードより一回り小さくつくってあるので角は落とさなくても貼るのには問題ないけど、こういうひと手間は意外に大事で、よくできてる感を醸し出してくれる。

貼り

治具を作ったらちゃんと行くのだろうけど、面倒なので目で合わせて貼っていく。当然曲った。そう、僕は携帯のフィルム貼りなども含めちょっと苦手。しかも角丸にしたから剥離しにくい、という仕様。といいつつもそんなに大きな問題なく完了。


あとは遊ぶだけ

と、つくっておいてまだ遊べてないけど、出来は上々。世界観はともかくとして、視認性はかなり良い。問題だった行くのか戻るのかを混同するようなことはなさそう。まぁ満足かな。あとは実際プレイしてみてまたなんかあれば考えなおすとしましょうか。

Alfredの同期がDropboxのAppsディレクトリだとできなかった件

  1. 1. Alfredの同期
    1. 1.1. あれ、同期したいディレクトリが選べない
    2. 1.2. 公式に説明があった
    3. 1.3. そもそも
  2. 2. LaunchBarから移行してみての所感

長らくこれまでLaunchBar使いとして頑張ってきましたが、環境が変わったのをきっかけに僕もついにAlfredの軍門に下りまして。

Alfredの同期

Alfredは有料のPowerPackを導入することでDropbox経由の同期ができる。一部設定はあえて同期しないようになってるものの、追加したWorkflowとか同期できる。どうせWorkflowを使えないんじゃ意味ないし、LaunchBarもそもそも有料だしで、当然PowerPack入れてみました。

あれ、同期したいディレクトリが選べない

で、Dropboxを使うアプリの多くは~/Dropbox/Apps(またはアプリ)以下で同期設定を持つものがある。アプリ関連のはここでまとめたいところだけど、どうもこのディレクトリが同期設定で選べない。これでは同期できない。Alfredだけ他の場所で同期するのも管理が面倒になるし、美しくないし。

公式に説明があった

簡単に言えば、Dropbox/Apps/はなんか不可解な動作をするので、Alfredはこれを採用しないし、ここで同期をさせなくしている。それでもどうしても使いたいなら

  • Alfredを終了
  • ターミナルでdefaults write com.runningwithcrayons.Alfred-Preferences-3 dropbox.allowappsfolder -bool TRUEと入力
  • Alfredを起動

するとできるようになるよ。
ってことらしい。

とりあえず僕はそれでやってみたけど今のところは問題なく動いてる。でも問題あるようだったら別の方法を考えよう。

そもそも

そもそもDropboxのAppsディレクトリ自体やっぱりちょっと変で、アプリの環境によってDropbox/アプリだったりDropbox/Appsだったり日本語だったり英語だったりで統一されない。しかも別モノ扱いなので面倒。僕はこれは、Appsをシンボリックリンクでアプリという名前で作って対応してる。

LaunchBarから移行してみての所感

お作法が違くて慣れないところもあるけどそんなに困ってない。省略語の柔軟さとファイル操作はLaunchBarのほうが秀でてる感じだけど、Alfredでも必要十分、という感じ。そもそも僕が移行したのはそれよりもWorkflowの充実さと作りやすさ。LanuchBarも機能拡張いろいろできるんだけど、ちょっと作るのが面倒だし、コミュニティとしてかなり寂れてるので将来性に難アリ、という感じ。

実はMacユーザーが増え始めたころにAlfred賛美の流れができて、なんか不服だったし、今もAlfredに降るのは少しだけシャクなんだけど、そんなこんなでしばらく使ってみます。よろしくAlfred。

最近割と上手くいってるオレオレBEMding

  1. 1. オレオレBEMding
    1. 1.1. 壮大なる勘違い
    2. 1.2. オレ的BEMコンポーネント設計
    3. 1.3. FLOCSSとの親和性
    4. 1.4. でちょっと小細工
      1. 1.4.1. blockについて
      2. 1.4.2. elementについて
      3. 1.4.3. modifierについて
  2. 2. 今んとこ上手く割といってます
  3. 3. 参考

HTML/CSSでの開発手法としていろいろあるなかで、最も有名ものの一つで命名規則のBEM(MindBEMding)っていうのがありまして。構成の手法としてSMACSSやFLOCSSなんていうのが、あっていったいどれがいいの?悩んだあげくにFLOCSSベースのオレオレBEMdingに落ちついて、それが割と上手くいってるって話。

オレオレBEMding

そもそもMindBEMdingってなに?って話なんだけど、Block,Element,Modifierで区切ってClass名をつけていきましょうよ。構成も理解しやすいし、名前も一意になるよ(意図しないスタイルの競合が起こらない)という手法で、具体的には、block__element--modifierという書式が一般的。詳しくは解説のドキュメントを漁ってください。

壮大なる勘違い

で、なるほどな、と思ってやってたわけだけど、最初はblockとelementの真意を理解してなかった。というのも、HTMLのマークアップはけっこう入れ子になっていくもんで。それでいてBEMってのはシングルクラス的なものだとぼんやり解釈してたんだけど、結果として、BBBEMとかBEEMとか平気で書いてた。

こりゃちがった。原意的に言ってるかはよく知らないんだけど、原則的に最多の状況でBEMまでが許される。BとかBEとかBMは可。そしてその原則を守ろうとするとシングルクラスよりマルチクラス的になる。

例えば、グローバルナビを想像すると、グローバルナビはページ全体をBlockとした時の1つのElementだけど、ナビの中のメニュー要素の一つはナビをBlockとしたElement。これをシングルクラスかつBEMにのっとることは半ば不可能で、無理にやろうとすると、BEEMとかになっちゃう。

BEMはただの命名規則にとどまらずに、BlockとElementとModifierの構造もわかりやすくする為にある。単純にトップダウン的に__で繋げていけば良いってもんじゃない。

と、これを理解せずに単純にやってたわけですよ。BEEMとか酷いときはBEEEEEMとかを量産してたわけですよ。

オレ的BEMコンポーネント設計

そして大事なのが、Blockは自身の位置情報を保持してはいけないこと。スタイル的に言えば、positionとかmarginとかの情報は持たせない。(自身のサイズやpaddingは内包する要素になるので可とする)

コンポーネント的に使うために、Block自身が自分がどこに位置するかのスタイルを持たせない。こうすると例えば、何かの変更により位置が変わった時にBlock自体のスタイルを変更する必要がなく、そのBlockを1コンポーネントとした時に流動性が上がる。

じゃあどうやってそのコンポーネントの位置を決めるかというと、そのコンポーネントは階層構造を見ると視点を上に上げていくとコンポーネントブロックはその上のブロックに対するelement要素になるはず。そのelement要素に位置情報としてのpositionやmarginを設定することで、コンポーネントの位置を設定する。

これがマルチクラスじゃなきゃ不可能だと僕が思ってる所以。つまりそれまでトップダウン的に考えてたんだけど、ボトムアップなアプローチで考えるべきだと思いなおした。

FLOCSSとの親和性

別にSMACSSでも良いんだけどね。FLOCSS的に上で書いたようなコンポーネント単位の部品をガツガツ切り出していく。

FLOCSS的なcomponentとprojectってどう分けるの?と思ってたけど、componentが一番小さいパーツ、projectはcomponentを一つまたは複数内包するもの、layoutはトップダウン的にページ全体から見たもの。layoutに限ってはBEMでいうBlock部分での自身の位置をスタイルしていい例外条件にする。

つまりlayoutが複数のprojectを内包していて、projectが複数のcomponentを内包している。

ただ、このオレオレFLOCSSはちょっと自分でもまだ甘いな、と思っていて、そもそものFLOCSSが定めるprojectとcomponentの定義から外れてる気がするし、componentとprojectが上手く噛み合わない時もたまにあったり、componentの数がたくさんできてしまったりしている。これは今後の課題。

あと、自覚してるけどなおせてないのはcomponentが例えばtopButtonとか、位置を表現してしまってたりすること。これは自分の命名が悪いですね。流動可能なcomponentに位置を意味する命名をしてしまうと、他の場所で流用する時に齟齬がでるし、流用しにくいものになってしまうので。

でちょっと小細工

で、本来のBEMではBlock__Element--modifierとelementには__、modifierには--という感じで区切ってつなげる。実はこれは厳格には決まってない。オレオレBEMdingだから厳格に決まってても破るけど。ちなみに単語間は-と一つのハイフンで区切る。で、僕がいろいろ調べて今使ってるのが、pre-blockName_element.is-modifierという書き方。

blockについて

blockはlower camelcaseで表記する。複数の単語を使う場合、topNaviとか、そんな感じ。これはJSで慣例的に使われてるし、CSSでスネークケースでJSでキャメルケースだと混乱しやすいので統一したかったので。かつ、prefixとして、FLOCSSの何にあたるかを一文字つける。layoutならl-、projectならp-、componentならc-。それでSASS的なファイルをパーシャルにするのも、そのとおりにする。そうすると探しやすいし使いやすいし、わかりやすい。

elementについて

elementも同様にlower camelcaseで表記。なのでハイフンやアンダースコアの用途が他で被らないので、_とアンダースコア一つだけつける。ハイフンじゃないのは、アンダースコアのほうが区切りを視認しやすいから。

modifierについて

ここまで書いてきたとおり、マルチクラス前提の構築なので、modifierは別クラスで当てる。こうすると、JSでのクラス変化による操作も使える。というかそれ前提の書き方になってる。prefixとしてis-を付ける。かつ、スタイルでは、その上要素があること限定で付ける。

例えばセレクタで.c-topNavi_item.is-currentみたいに書く。CSS側でスペース空けずに書いたセレクタの場合、そこだけ限定で当たるのを利用する。SASSとか(僕は最近Stylus派だけど)なら&amp;.is-currentとかやってもいいね。

で、これの効能が思ったより良くて、シングルクラス的にmodifierまで設定するよりも各modifier共通のスタイルはその上の段階(BとかBEとか)で普通にスタイルできるのも良い。modifierが各modifierで異なるスタイルだけ持つことのになるので無理無理BEMdingよりよっぽど自然になる。

今んとこ上手く割といってます

そんなこんなで結構アレンジしたけども、それでいて本質にのっとってる(気がする)オレオレBEMdingでした。BEMっぽいのは多々あるけど、ほんとにそれがいいのか、っていうのを確認できてないので、しばらくはこのオレオレBEMdingを使いながら遊んでいきます。

参考


失敗を糧に作ったキーケース兼iPhoneケースが調子良い

  1. 1. 設計
    1. 1.1. これまでの失敗策と気になる点を糧に
  2. 2. 制作
    1. 2.1. 下準備と切り出し
    2. 2.2. 縫い穴開け
    3. 2.3. 縫いとiPhoneケース付け、そして仕上げ
  3. 3. 完成品と所感

ちょっと前まで失敗続きだったレザークラフトだけど、会社から仕事用携帯としてiPhoneを支給されたのを機にキーケースとカードケース機能も追加したケースを作ってみたら思いのほか使い勝手が良く大満足。

まずはこれが完成品。
キーケース完成品

設計

これまでの失敗策と気になる点を糧に

まずよくあるキーケースの作りの使い勝手の悪さ。ボタンで開けて、数本あるキーの中から該当のものを選ぶ、鍵をかけて(もしくは開けて)、またしまってボタンをとめる。と、鍵を開け閉めするには工程が多すぎてストレス。ジャラジャラするのもイヤ。そして失敗策の反省は無駄に大きかったのと、ギチギチに作りすぎたこと。

  • 素材
    • たまたま見かけたコーティング加工された革が安かった
      • いつものように塗りやらしなくて良いので楽でしかも丈夫
  • 機能
    • 鍵は回転式で取り出す
      • 失敗してた財布やらに搭載されてた機能をさらにブラッシュアップ
    • 交通ICカードも楽に使えるようにカード入れも搭載
      • 余ったスペースはなにかカード的なものを挟めるよう
    • iPhoneケースは迷ったあげく、100均のものを接着
      • 要は固定できてりゃ良いわけで
    • もちろんDカンつけてウォレットチェーン的なものに付けられるように

制作

下準備と切り出し

いつもながら設計には頭を悩ませた。日常的に使う鍵は3本あるので、それをどう搭載するか。ポケット等に入れたときに他の物に当たらないようにカバー部分を作りつつ取り出しやすくしなきゃいけない。同時にカメラの場所も確保しなきゃいけないわ、閉じた時に閉じたままにしたい。が、ボタンにすると面倒。基本的に片手運用しやすいように。

そうしてできた型がコレ。

キーケース 型

型どおりに切り出したら一番表面に来る部分は溝を掘る。前回適当に作った試作でわかったけど、やっぱり溝があるとないとで糸の収まり具合に差が出るし、なによりメリハリがつく。

キーケース 切り出し

縫い穴開け

今回は秘密兵器で、ハンドプレス的な機械を導入した。これだとハンマーを使わないので、音が出ない。集合住宅でもへっちゃらマシン。もちろん先端も変えられるから、ポンチも抜けるしボタンも付けれる。新兵器の使い勝手を味わいながらバシバシ穴を開けていく。

キーケース 穴あけ

縫いとiPhoneケース付け、そして仕上げ

新兵器で穴を空けて終わったら縫い。今回の重ね合わせはそんな複雑ではなかった。強いていえばキーホルダー部分の回転させる為のところがちょっと悩んだくらい。あとはバシバシ縫っていく。やっぱり縫っていく工程が一番好き。できあがりがわかってくるし。糸がキュっと収まっていくのが気持ち良い。

キーケース 縫い

縫い終わったら内側に100均で買ったiPhoneケースを接着。ここは深く考えずに革対応のボンドでペタリ。クリップとクランクで乾くまで固定。このiPhoneケースだけで使うと思うとアレだけど、パーツとして使うのであればかなり良い感じ。

キーケース iPhoneケース接着

接着が終わったら角や余分な部分を落として、仕上げのヤスリがけとコバ磨き。今回はテストも兼ねて以前自作した小さいコバ磨き棒を電動ドライバに装着して電動コバ磨き。思ってたより重くて疲れたのでやっぱりいつかリューターが欲しいところ。

キーケース 仕上げ

完成品と所感

完成品の写真をいろんな角度から各機能がわかるように。
キーケース完成品
キーケース 内側
キーケース 外側

  • 成功
    • 鍵はかなり取り回ししやすい機構を実現できた
      • 片手で目視せず手の感覚だけで該当の鍵が出せる
      • ジャラジャラしない
    • iPhoneもしっかり収まってる
    • Dカンも良い感じについてワイヤーリールと相性が良い
    • 閉じたとき、マグネットでちゃんと閉まる
    • カードケース部分もしっかりカードも入ってICも反応する
  • 失敗
    • すこし寸法に余裕を持たせすぎたのかやや大きめ
    • 真ん中が逆側に開きにくくやや電話しにくい

と、今回に関していえば失敗よりもiPhoneも鍵も交通ICカードもひとまとめにできた上に取り回ししやすいものに仕上がったので失敗はゼロではないものの、久々に自分の満足行く仕上がりとなった。

いつもどおり実験的な工程をやってみたり、今回で言えば静音型新兵器を導入して手応えがあったのと、いつも使わないコーティング済みの革を使ってみたことが大きかったし、結果的に成功したのが良かった。染色やカービングの楽しさとは別に革の種類にも興味が湧いてまた一段と沼が深くなってしまった。

ちなみに僕の静音新兵器の構成はコレ。

ジェストにリバティ、そして下敷きへ

  1. 1. ジェットストリームアタック
    1. 1.1. ボールペンについて
    2. 1.2. 邂逅
    3. 1.3. ジェットストリームの欠点
  2. 2. 自由を求めて
    1. 2.1. Pen of liberty
    2. 2.2. 合体
    3. 2.3. 使い勝手
  3. 3. さらに追い求める
    1. 3.1. そして下敷へ
    2. 3.2. 手が喜ぶ書き心地

ジェットストリームの書き味が心地良いのは周知の事実だけど、さらに軸を良いものに変えて、下敷にも気を使うと最高になるよ、って話

ジェットストリームアタック

ボールペンについて

僕のボールペン好きはけっこう早く、大学生にもなると筆箱は持たずに鞄に筆記用具はボールペン一本だけ、とかだった。それはそうと社会に出るとシャーペンとボールペンの地位が逆転するよね。学生はテストやノートで消せることが大事だけど、社会に出ると消えないことのほうが重要になってくるわけで。

邂逅

そんなこんなで、良いボールペンはないかな、とずっと思ってたうちにジェットストリームに出会う。実はその前にサラサの書き味とインクドバドバが気に入ったんだけど、どうにも速乾性に欠けてたり。その点、ジェットストリームは書き味を含め攻守のバランスが素晴しい

ジェットストリームの欠点

そんな攻守揃ったバランス派のヤツにも唯一にして致命的な欠点がある。それは軸。軸がダサい。作ってる方々には申し訳ないが、軸がダサい。使いづらい。高級ラインナップのプライムも、あのチープな宝石みたいなのはなんなんだ。あえてダサくする必要はあるのか。と、問いたいぐらいダサい。が、一色のやつに関しては割と書き易いほうだと思う。が、なんであんな宝石つけたんだ。いらんだろ、それ。

自由を求めて

Pen of liberty

ジェストの軸を変えたいと思うのは僕だけじゃないらしく、ネットを探せば互換性のある軸の話や改造して入れる話もいろいろ出てくる。実はジェットストリームの芯(リフィル)は多色用と単色用や、ボール径によって太さが変わる。僕の愛用は0.7mm。0.7mmの単色用リフィルが入るものの中で絞り、実際に持ってみたり、総合的に見た結果、OHTOのリバティに白羽の矢を立てた。

リバティの凄いところは見た目も高級感あるわりにびっくりするほど安価、しかも持った時の重心のバランスも良い。グリップ部分はラバーでつるつる滑らない。コスパが良いバランス型。

合体

liberty parts

他社リフィルが適合する場合、大きく二種類ある。無改造でそのまま入るもの、何かしらの手を入れないと適合しないもの。リバティの場合は後者で、少しばかり手を加えないと使えない。実はジェットストリームのリフィルはリバティにセットするには少し短い。その分を足してやらないと使えないわけだけど、いくつか方法があって、僕が採用した手順は

  1. リフィルじゃなくて、単色のジェットストリームのペンを買ってくる
  2. 分解して、芯とペン先を押さえるバネを取り出す
  3. バネをリバティの後部に入れちゃう
  4. リフィルをセットして、完了

という純正のバネをリサイクルする方法。実は他の方法として、リフィルより少し太いビニールチューブをリフィルにセットしてゲタにする方法も試したところ、たまにインクが出にくくなってしまう問題が置きた。それに、リフィルの交換の度にリフィルに対して改造するより、軸に対しての改造のほうが手間が少ないのもバネ仕込みの利点。

使い勝手

書き味については素晴らしいの一言。もともと書き味の良いジェットストリームが、リバティのバランスとグリップを得て、さらに増幅された感じ。しかもバネ仕込みのうれしい誤算として筆圧強めで書くとき若干ペン先が軸側に押し込まれる。これが程良く力を吸収してくれて柔らかさを生んでさらに心地良い。唯一気になる点としては、もともとジェットストリームの利点のノック式じゃなくなること、さらに言うとリバティのキャップがちょっと固いこと。無理矢理良さに変えるなら、キャップ式のほうが高級感があって良いよね、キャップを後部に付けて重心のバランス変えられるよね、胸ポケに入れてても安心だしカッコイイよね、ということかな。

さらに追い求める

そして下敷へ

ソフト下敷

書くほうは満足行くようになったら、受けるほう、つまり下敷。ここで使ってみたのはソフト下敷。人に寄っては紙が少しボコっとなってしまうのを嫌う人もいるかもしれないけど、書き心地を追求するなら是非使ってほしいのがソフト下敷。字が上手くなった気がするぐらい書き心地が変わる。そもそも人の手は感覚が鋭く、固いものの上で書きものをする場合、硬さと反発を感じる。それがソフト下敷だと筆圧を心地良く吸収してくれる

手が喜ぶ書き心地

ジェストにリバティでソフト下敷、本当にやってみてほしい。一言で表すなら「手が喜ぶ」感覚。是非味わってみてほしい。字を書くってこんなに気持ち良かったっけ、って思うから。余談だけど、リバティにはフリクションも入るよ。