何度目かもうわからない近況報告

  1. 1. 近況報告
    1. 1.1. 結婚式することにした
    2. 1.2. なんか海外の友人達がたくさん来る
    3. 1.3. ToDoアプリ的なやつ作ってリリースした
    4. 1.4. 入力環境がわりと極まってきた
    5. 1.5. ブログをなんとかしようと思う

どうも、どうもどうも。
ブログはいつも書こう書こうと思いつつ月日が過ぎてしまうね。
今回もまただいぶ期間があいてしまいました。書きたいネタは実はけっこうあるんですが、どうにも手をつけるのが苦手な様子。そんなこんなでまた、近況報告からやってみようと思う。

近況報告

結婚式することにした

最近の一番の関心ごとと言えばコレ。念願だった世界旅行から帰国してそろそろ3年、結婚して2年半。だいぶ遅いなぁと思いつつもそれでも今を逃したらやらなくなってしまうだろうなぁと 思ってやることを決意。

別エントリに詳しく書きたいけど、うちの場合、本人と親兄弟のみで式と会食(お食事会レベル)という最小規模。それなのにそれなりに準備が大変で。一般的によくあるパターンを考えるとこれに披露宴と旅行が加わると思うと本当大変だと思う。前職はイベント制作会社だったけど、お金貰わないのにイベントディレクションなんかやりたくないなぁ😣

なんか海外の友人達がたくさん来る

結婚式のアレコレでわりと土日に用事があることに加えて、なんか示し併せたように海外の友人が日本に遊びにくるのが重なっている。すごい嬉しいことなんだけど。結婚式のこととコレと、1つの波だと思って、乗り越えるしかないこのビグウェーブを。

遊びにきてくれてあんまり沢山おごってあげれないので、もうすこし沢山稼げてたらなぁ、とほんのちょっぴり思う。僕は今までの旅の中でいろんな人に沢山助けてもらったけど、その当人達に全然恩返しできてない。だから日本に来てくれた友人達には楽しんでもらいたいし、助けてあげたいと思う。

みんな割と良いやつばかりなので遠慮するんだけど、決まって「自国で他国の人と会った時に親切にしてあげてくれ。僕はそうやってポジティブな助け合いをつなげていきたい」と伝えてる。そう、例えばあのトルクメニスタンのチャイハネで助けてくれた家族なんかに恩返しいくことは相当難しい。だからそうやって広い意味で恩返しをしてるつもりになってる。

ToDoアプリ的なやつ作ってリリースした

これについてもまた機会を見てちゃんと紹介記事を書きたいと思ってる。早い話「ぼくのつくったさいきょうのToDoアプリ」って感じ。実用的になるまではわりと楽しく作れてたんだけど、しっかりテスト書いたり、紹介ページ作るのが結構大変だった。

とはいえそれによって得れた知見はかなり多くて、こういう自分の欲しいものをガっと作る、ってのはこれからも実践していきたい。これによって仕事が捗るようになったかっていうのはまた別のお話なんだけど……

入力環境がわりと極まってきた

今は贅沢にもErgodoxを家と職場の両方で使ってる。職場ではまあわりと良いんだけど、家の環境がなんかしっくり来てない。多分机と椅子が上手く噛みあってないというか。ここに課題が残りつつもそれでも割と極まってきた感ある。

ソフト的な入力環境としても、みんな大好きKarabiner-ElementのカスタマイズとAquaSKK、Atomの環境を上手くならしたらだいぶ良い感じになってる。余談だけど、Markdownが浸透してきていろんなエディタが出現してきたけどなんでみんなそんなエディタを欲しがるのかがちょっと理解できない。編集は自分の使ってるカスタムしたエディタが一番良くない?補完もリントも思い通りに効くし。

というわけでそのうちViewer的なものに特化した何かを作りたい。編集はお好みのエディタでできるようなやつ。

ブログをなんとかしようと思う

これはけっこう前から思ってる。特にちょっと前にブログデザインをリニューアルした時、AMPに寄せたんだけどTumblrでは自動的にスクリプトが入るので現状としてオリジナルなAMPを実現するのは無理そうだ。かといって生成タイプのAMPはまったくやる気がない。

で、一応サーバーサイドエンジニアのはしくれとして、自分でブログ的なCMSを勉強も兼ねて作ろうと思ってた。そんなところから考えが二転三転していまはHexoでやろうかな、と思ってる。

俺の好きなフォントで読ませろ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;だけになるのもそう遠くない日だろう。

最近Emojiについて思ったこと

  1. 1. Emojiは「絵文字」だったから受け入れられたんじゃないか
  2. 2. その英訳を許していいのか、まあいっか。
  3. 3. 絵文字って漢字圏的だよね、って話
  4. 4. もっとEmoji を使っていきたい

Unicodeでまた絵文字が増えるそうな。もはや世界語になり、世界共通認識となった絵文字。なんか最近のエンジニア文化的にどんどん絵文字を上手く使っていこう、みたいな流れってあるよね。

Emojiは「絵文字」だったから受け入れられたんじゃないか

Emoji。Emo、っていうのが正直ポイントで、実際Emojiになる前はEmoticon(Emotion+icon)と言われた時代もあった。そう、Emoで始まる語だったから世界標準になったんじゃないかって僕は本気で思ってる。アスキーアート的な顔文字、すなわちfaceiconとかfacemarkとかだったらこうはならなかったんじゃないかな。Emoji,という字や響きから割と直感的にEmotionを連想できた偶然はデカい。

その英訳を許していいのか、まあいっか。

先日、zshプロンプトを絵文字つかってわかりやすく、ってやってて絵文字のバリエーションをじっとみてた。そしたら天狗👺となまはげ👹がいた。なまはげさんは「Japanese Orge」。うむ、日本にはいろいろな鬼がいるけど、まあこれはいいと思う。しかし問題は天狗様。「Japanese Goblin」ってどういうことや。実際の正統派ファンタジーの原典に当たってないのでアレだけど、ゴブリンって低級とか低俗な小鬼的なアレじゃないのかね?天狗さまやぞ、天狗の仕業じゃー、の天狗さまやぞ。その訳でいいのか!
と、いいつつも、世界的なemojiに日本妖怪が2柱も含まれておりますので、すごいと思う。

ちなみにそこで作った、叩いたコマンドがエラーだとなまはげさんが出るプロンプトについてはそのうち書きます。

絵文字って漢字圏的だよね、って話

漢字ってのは一つの文字として圧縮形態だと思う。例えば文字としては音にのっとったカタカナ、ひらがなだけでも通用する。例えばハングルのように。漢字って正方形的なマスの中に意味と音と関連性を内包してる象形表意文字で、一文字あたりの情報量は世界屈指なんじゃなかろうか。字や単語を知らずとも意味も音もだいたいわかるっていうのはすごいと思う。

マスが正方形であり、象形文字。これはまさに絵文字の原型でしょ。しかもEmojiは漢字と同じくパっと見て状況がわかりやすい。それに一役かってるのが、Emoji は色つきのも大きい。キキとブーバじゃないけど、形はもちろん、色によっても連想するイメージが絞られるでしょ。緑と赤ならわりと世界的にどちらが安全でどちらが危険か共通認識として成立してる。

もっとEmoji を使っていきたい

そんなこんなで、ここ最近のテクノロジー界隈のEmoji使っていこうぜ、の流れにもっとのっていきたいな。その昔、メールのやりとりで絵文字がなくて「おこってる?」とかたずねられた意味のわからない疑問はおいておくとして、やっぱりEmojiが良いかんじに出てくるとなんかちょっと楽しい。なんかちょっと楽しい、ってのは害なく得しかないので大事にしていきたい。

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を再起動すれば適用されている。

「アボ"ガ"ド」と言う料理研究家は信用できない

「アボカド」について。ここ日本ではなぜか「アボガド」と呼ばれることが多い。
一般レベルではなぜか濁音がつく使われ方が多い語の一つだと思う。

英語名「avocado」、原産である中米で使われているスペイン語では「aguacate」。そう、「g」ではなく、「c」。綴り覚えたら「アボカド」って絶対覚える。混同するわけない。

料理はサービスであると同時に技術とかエンジニアリングに近しいものだと思ってる。料理研究家って何を研究してるのかわからないけど、「アボガド」と言ってしまう料理研究家のみなさんにおかれまして何を研究してるのかと思ってしまう。
研究対象として海外のソースを目にすることはないのだろうか?自分の道具と扱う材料の呼称を把握してない技術者が信用できるだろうか?
(OSSなどのプロジェクトでどう発音するのかわかりにくいものがたまにあるけど、公式ドキュメントに発音記号とか読み方が記載されてるとそれだけでそのプロジェクトへの好感度が上がるのは僕だけだろうか。)

余談だけども、ベッドとベット、バッジとバッチ、ドッグとドッグ、バッグとバックとか外来語には濁音について曖昧に使われてるものがけっこうあるから、そういう時は綴りで覚えると絶対間違えようがないよね。

Markdownのリスト表記に「+」を使うことにした話

  1. 1. TL;DR つまりは要約
  2. 2. Markdownとそのリスト記法について
  3. 3. 「-」、「*」、「+」、どれが良いのか決定戦
    1. 3.1. 「-」の場合
    2. 3.2. 「*」の場合
    3. 3.3. 「+」の場合
  4. 4. 細かいストレスを潰すのは意外に大事

僕は文書は全部Markdownで書けばいいと思ってるクチ(リッチテキストは滅びればいい)なんだけど、記法の中でリスト表記について「+」を使うことに変えたという話。

TL;DR つまりは要約

  • Markdownのリスト記法は「-, *, +」の三種類使える
    • 僕は従来「Taskpaper.app」の影響で「-」を使ってきた
  • 「-」は全角と半角で違うので、日本語の文章の場合にいちいち切り変えないといけないので面倒だ
  • 「*」は強調記法でも使うので念のため避けておこう
  • 「+」なら他と被らないし、全角で使う理由がない
    • 全角の「+」は使うことがないので日本語中でも 半角直接入力にしてある
  • これでわざわざ切りかえがなくなったから少しだけ日々のストレスが減った

Markdownとそのリスト記法について

諸君、僕はMarkdownが大好きだ。そして、リスト記法が大好きだ。Markdownの好きなところは、可逆的に使えるところ。スタイル情報を埋めこまないプレーンなテキストなので、なんでも使える。だから編集に強い。今ではいろんなエディタで使えて、シンタックスハイライトも対応してるからそのままでも割と見やすい。目視パースも苦じゃない。

そしてリスト記法。箇条書きは正義だと思ってる。適切な箇条書きは理解しやすい。それだけで正義でしょ。アウトラインプロセッサ的な。僕は日記すら箇条書きで書いてたし、アウトラインプロセッサなので凄くわかりやすい。

で、Markdownでリストを書くときは行頭に記号を書くのが記法だけど、実は三種類の記号ならなんでもいい。「-」、「*」、「+」。Markdownにどっぷり漬かる以前、僕はずっとTaskpaperというMacのアウトラインエディタ的なものを使ってたので、そこから「-」を行頭に付けるのが慣例になった。

「-」、「*」、「+」、どれが良いのか決定戦

だけど、「 -」を入力するのが最近面倒になってきた。「-」って日本語入力中だと「ー」になるし、長音記号も超大事。これは合理的じゃないなァって思ったのがそもそもの発端。

「-」の場合

まあ上記の理由で入力にやや難あり。ただし、目視パース、脳内変換する場合においては個人的に一番リストとして認識しやすい記号だと思う。が、今ではシンタックスハイライトとかのおかげでどの記号でも割と遜色ないので、ご退場願う。

「*」の場合

ドキュメント系だと割と使われてる印象。もしかしたら世間ではリストの点記号に近いという認識なのかも。全角で使うこともないので、入力は楽なんだけど*em*とか**strong**とかで使うので一応避けておこうかな。余談だけど、*em*を斜体、**strong**を太字と言い切る輩がいたらソバットで一蹴していきたい。あくまで英字だと強勢が斜体、もっと強い強調が太字という慣例にしたがってるだけだから。見た目と論理的な意味づけを混同するのはだらしがない。

「+」の場合

パっと見、リストとして目視するにはいささか他より劣るけど、慣れとハイライトでそう問題ではない感じ。入力に関してはまったく問題なし。+の全角は特に必要性がないので、直接入力でも、日本語入力でも常に半角が入力できるようにしてる僕にとっては完璧(AquaSKKを使用してて設定可能、他は知らん)。

細かいストレスを潰すのは意外に大事

とまあ、こんな感じで「+」を使ってリスト表記にすることにした。わざわざ日本語入力中でも記号の時だけ切りかえる必要がなくなったので、少し毎日が平和になった。

PC云々に限ったことじゃなくて、日常の細かいストレスを潰すっていうのを僕は意外に大事だと思っていて、幸せになるアプローチの2つのうちの1つだと信じてる。もう一つは心地良いことを楽しむ。

心地良いことを楽しむっていうのは趣味だったり、欲求を満たすことだったりする。それはプラス要因を増やすこと。今回のように細かいストレスを減らすのはマイナス要因を減らすこと。

今日より楽しい明日を楽しむために。

日本語特化のBootstrapテーマ「Ayame」を作ってみた

  1. 1. きっかけ
  2. 2. やったこと
  3. 3. つまり
  4. 4. 実は
  5. 5. Ayame

Bootstrapテーマで日本語特化したものに「Honoka」というのがあって。
ちょっと最近Bootstrapテーマを使う機会があったため、HonokaをForkしてAyameというのを作ってみた。

きっかけ

現状でダーク系のテーマがみあたらなかったことがまず大きな理由。
それに加えてHonokaは凄く素敵なテーマだけど、個人的に日本語特化であればもうちょっと行間も調整すべきだし、
約物についても調整したい。さらにもっと個人的なことを言えば、日本語フォントは16pxだと少し小さいめな気がしてて、
できれば18pxぐらいが良いと思ってたから。

あいかわらずの自分で作ってしまえ精神。

やったこと

前述のとおり、行間、文字間の調整、YakuHanJPを使用、フォントサイズの拡大。がメイン。
色はダーク系にして、せっかくなので和風の配色をとりいれてみた。
「Ayame」は僕が大好きなゲームのキャラ、天誅から女性主人公の「彩女」より。
アヤメと菖蒲をかけて、メインの色を菖蒲色にした。

Fork元のHonokaはGruntでBower対応なんだけど、それはぜんぶぶったぎった。
Gulpにして、本当はnpmとかで配布したいとは思うけどまぁとりあえずそこはおいおいで。

Scssもぶったぎった。個人的にScssよりStylusのほうが好きだから。

つまり

つまるところ、かなりオレオレ仕様です。そもそも広く配布しようと思って始めなかったし、
なんかFork元とそのファミリーの命名が女性形なので、なんか適当に女性にするかー、
せっかくだから和風にするかー、日本語特化だし、みたいな感じ。

あと、リリースとかビルドとか配布とか関してももっと上手くやるべきだと思うんだけど、かなり粗削り。
まぁもともとがオレオレ仕様なものをついでに配布してみた、的なのでいいか。

実は

僕はBootstrapが嫌いだ。一番の理由はcol-6とかっていうクラス名を使うところ。
現状でのCSSフレームワークにおける最適解のひとつであろうことはわかってるんだけど、
クラス名というかHTMLのマークアップ側で確定したデザイン情報を持たせるのが良くないと思う。
マークアップは論理構造だけにすべきだ。

とはいえ、サクっとなんか作るときに、Bootstrap準拠のものがけっこうあったりして、
そこに労力を費やすべきじゃないこともしばしばあるので、今回のようにBootstrapを使うこともままある。

Ayame

忘れてました。リポジトリは以下。
一応リリースのところにCSSいれてあるので、そちらを使うか、Cloneでどうぞ。

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

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

貼り

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


あとは遊ぶだけ

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

「アフリカでは」の有用性と暴力性、思考停止の怖さ

今日ネットで見た言葉で

東京で10人死んだら日本中が驚く
ニューヨークで1000人死んだら世界中が震える
アフリカで4万人死んでも誰も驚かない
残念なことに命は平等ではないのです

とあった。

まぁ命は平等ではないし、人間そもそも生まれからして平等でないので、言ってることの本質的には同意なんだけども、
それよりみんなアフリカってなんだと思ってるんだろう。

この引用で言えば東京は都市、ニューヨークも都市、アフリカって大陸。規模が違いすぎるので引き合いに出すのおかしくない?
国越えて都市と大陸っておかしくない?
東京、ニューヨークってきたら、ケープタウンとかさ、キンシャサとかアフリカ大陸にある国の都市を持ってこないと。
もしくは、アジア、北米、アフリカ、と大陸単位で整理しないと。

そもそもアフリカでは、って表現が散見されるけど、せめて国ぐらいは指定してくれないと全然伝わらないよ。例えば南アフリカとエジプトとケニアとマダガスカルと南スーダンをいっしょくたにまとめたものをもってこられてもわかりにくいよ。

っていうかこういう時のアフリカという言葉の万能性というか、暴力性ってすごい。
命が平等ではないことより、一都市と大陸比べた文章に疑問の持たなささのほうが僕は怖い。