Magnolia Tech

いつもコードのことばかり考えている人のために。

プログラミング用フォントを選ぶための覚え書き

プログラミング用フォントについて調べたので、そのメモ

2024/09/08: Cascadia Codeを最新バージョンに合わせて記載の見直し

Apple社製が提供する「SF Mono」

developer.apple.com

  • San Franciscoというシステムフォント用のバリエーションの一つ

  • Terminal.appXcodeのデフォルトフォント

    アプリケーションに内蔵されているので、他のアプリケーション(iTerm2とか)のフォント一覧には表示されない。

  • 0(ゼロ)には斜線が入ってO(オー)と区別し易いデザイン

    一方で、l(エル)と1(いち)は、他のプログラミングフォントほど極端な差をつけていない

  • グリフに漢字などは含まず、含まれていないグリフはシステムフォントが利用される

    グリフ数は1628(イタリック系は1324)

  • プログラミング系記号の合字(リガチャ)対応や、Powerline対応フォントは含まれていない

Microsoft社が提供する「Cascadia Code」

github.com

  • Windows Terminal用にリリースされたフォント

  • SIL OPEN FONT LICENSEというライセンスで配布されていて、他のアプリケーションや、OSからも利用可能

    github.com

  • 0(ゼロ)は斜線が入ってO(オー)と区別し易く、l(エル)はセリフの向きを変えて区別し易くデザインされている

  • グリフに漢字などは含まず、含まれていないグリフはOSのシステムフォントが利用される

  • プログラミング系記号の合字(リガチャ)対応のCascadia Codeと、対応しないCascadia Monoの2種類がある

  • GitHubからダウンロードできるバージョンには、更にPowerline対応版(フォント名の後ろにPLがつく)と、NerdFont対応版(フォント名の後ろにNFがつく)が含まれる


その他

Source Code Pro

  • Adobeがリリースしているプログラミング用フォント

    github.com

  • デザインの背景は以下のブログエントリが詳しい(READMEに全然フォントの特徴が書いてない!)

  • blog.typekit.com

  • グリフに漢字などは含まず、含まれていないグリフはOSのシステムフォントが利用される

  • ライセンスは、SIL OPEN FONT LICENSE

  • プログラミング系記号の合字(リガチャ)対応は無いが、Powerline対応フォントが含まれている(ただし、基本の7文字のみ...拡張は含まない)

Source Han Code JP

  • Source Code Proと、漢字も含む「源の角ゴシック」を合成したフォント、つまり漢字も含む

    github.com

  • 半角文字と全角文字の幅の比率が1:2ではなく2:3になっているところが特徴

    ccjktype.fonts.adobe.com

  • ライセンスは、SIL OPEN FONT LICENSE

Monaspace

  • GitHub社から発表されたばかりの等幅フォント

    github.com

  • 5種類の書体ですべて幅を揃えてので、重ね合わせて、組み合わせで利用できる

  • 隣り合う文字の組み合わせによってmやiといった文字の幅を変えることで読みやすさを向上させている(Text Healing)

  • グリフに漢字などは含まず、含まれていないグリフはOSのシステムフォントが利用される

  • ライセンスは、SIL OPEN FONT LICENSE

  • プログラミング系記号の合字(リガチャ)対応(ただし、スタイルとして、dlogを指定しないといけないので、VS code以外のたいていのエディタや、ターミナルソフトでは有効にできない)

  • Powerline対応は無し


Powerline対応フォントについて

UNICODEの私用領域(つまり外字)の領域に、コーディング用に見栄えをよくするための記号(ブランチなど)を追加したもの

個々のフォントが対応していなくても、iTerm2は独自のグリフを提供している(ただし、フォントによっては見栄えが合わない場合もある)

合字(リガチャ)について

同じ合字(リガチャ)対応のフォントでも合字が、スタイルにdlogを指定した時に有効になるのか、caltを指定した時に有効になるかはフォントのデザイン次第。

たいていcaltはデフォルトで有効、dlogはデフォルトで無効

『HATENA TECH BOOK Vol.2』を読んだ

技術書典15で『HATENA TECH BOOK Vol.2』を入手したので、その感想エントリです。

techbookfest.org

はてな社の有志が集まって作られた技術同人誌、その第2弾。

いくつかの記事を拾い読みした段階での感想

序文

大西さんによる序文。

他の会社であるような「あのプロダクトの裏側大公開」みたいな内容ではなく、「あなたの推しの技術を教えてくだささい」というテーマが設定されているそうで、メンバの興味に任せて色々なテーマが扱われているのが「個性」が見えていいですね。

あと、今のはてな社には、電子・紙書籍制作ツールのRe:Viewの作者、kmutoさんが在籍されているんですね。

reviewml.org

Perlの未定義動作110連発

papixさんによるPerlの記事

その場で「Perlの記事、この会場でも他に無くないですか?」と思わず言ってしまった。

Perlに限らず、言語の未定義動作って、未定義ゆえに「これは未定義です」と親切に書かれていることが少なく、意図せず使ってしまうことがありますね。 この記事でも、「未定義動作とは、毎回挙動が変わるのではなく、未来のバージョンでは変わるかもしれない」という意味での未定義なので、その場では困らないことも多いので。

そういう意味ではとても良い啓蒙記事だと思います。

あと、どうやって同人誌で110もの未定義を紹介するか、という点については本誌を読んでみてください。

ラムダ計算で遊んでみよう

todays_mitsuiさんによるラムダ計算の入門記事

たった3 + 1の計4つの構成要素だけで計算機としての機能をすべて実現できるラムダ計算という考え方についての解説記事。

おそらく自然数の定義のところで、「は?」となること間違い無いけど、よく考えるなーって思ってしまった。

ラムダ計算の実行環境を作って提供されているそうなので、遊んでみると面白いと思います。

mogul-lang.mudatobunka.org

人事をささえる技術

人事部長onishiさんの、人事としての活動を技術を使って改善する話。

社員採用の問題点をそれぞれの日数の経過から分析するアプローチは面白いですね、さすが!

採用活動、ほんと早く動かないと良い採用は決してできないので、この手の定量的なアプローチがすごく有効なんですよね 採用にどのくらいの優先度をつけるかは、まさに経営ですね!


と書き始めるとキリが無いのでこの辺で終わりにしますが、技術書典15はオンラインでは2023年11月26日(日)まで開催中なので、気になる本は早めにゲットしましょう!

『GitLabに学ぶ 世界最先端のリモート組織のつくりかた』- 意識的に”設計”されないとリモートワーク中心の働き方は実現できないということがわかる1冊

紹介された本はなるべくその場で注文して実際に読んでみる、というのを実践するように心がけています。この本もそうやって紹介されたので、すぐに買って読んでみました。

当たり前ですが、単にリモートワークにすれば全ての問題が解決する、業績が上がる、リモートワーク最高!という内容ではありません。

この本の中心は、GitLab社が作った「GitLab Handbook」をベースに、組織の価値観、それをベースにした仕事のやり方、評価のやり方を定義、可視化することで、よりみんなが満足して、より高い成果を出すための環境作りの方法が解説されています。

  • GitLab社はオールリモートで運営されていて、2,000名を超える従業員が特定のオフィスを持たない
  • 仕事のやり方は、3,000ページを超える「GitLab Handbook」にまとめられている (3,000ページというと驚くけど、ちょっとしたコミュニケーション主体のタスクをルールに書き起こしてみるだけでも簡単に10ページとか行くので、逆に「少ないな」くらい思ってしまった)
  • コミュニケーションが円滑にいくためのガイドラインやツール選定の方針などが書かれている

GitLab Handbookは、以下のサイトにすべて公開されています。

about.gitlab.com

仕事のやり方を作るためにはそれだけの手間をかけて、「設計していく必要がある」、ということなので、「じゃあ明日からそのGitLab Handbookの通りに仕事をやってみよう」と始めてもきっと上手くいきません。


詳しくは本を読んでください、GitLab Handbookを読んでください、としか言えないのですが、なかでも特に良かった箇所は以下の二つです。

  • 経営陣のデフォルトリモートにする

    現場のマネージャーでも同じですが、「意思決定をする人の影響力」はやはり無視できないので、この層の人たちが率先して実践することで組織が変わるのは間違いないですし、逆にいえばこの層を変えないで組織は何も変わらないですからね

  • リモートワークに共通して発生する問題 働きすぎる

    『リモートワークの達人』でもこれがすごく強調されていました。仕事と生活の境目が曖昧になり、物理的な出社・退社という区切りが無くなることで、際限が無くなってしまい、働きすぎになり、最後はバーンアウトになってしまう...「成果」でしか測れないからこそ、そこにどれだけの「時間」を使っているか、ということに意識的にならないといけないわけです。


あと、この本を読んで特に思ったことは、自分で「GitLab Handbookに相当する文書が書けるだろうか?」という点でした。

意外と自分たちが普段やっていることを言語化することは難しく、それはきっと「言語化しなくてもできてしまっているから」からだと思うのですが、まずは「名前をつけること」で見えてくることがあります。

「名前をつけて」「その手順を定義し」「特性は何かを考え」「より良いやり方に昇華」させていく……これは完全に普段のプログラミングでやっていることそのものであって、決して特別なことではないのではないかと思います。

ただ、それが普段の自分たちの仕事のやり方になると、そこに投資することが後回しになってしまうだけで。

つまり、スケールさせたい組織は「仕事のやり方も常にリファクタリングが必要」という発想を持てるか否か、に尽きるのかなと。


書かれていることの本質は、10年前、コロナ禍に入る前に書かれた『リモートワークの達人』と変わらないのですが、世界中の色々な状況がアップデートされているのと、より実践されてきた結果が書かれている点が違います。

『リモートワークの達人』はもう少し”啓蒙書”っぽい雰囲気が強かったですからね。


すべての企業や、組織がこの本に書かれている通りのことを実践して、フルリモート組織になる必要は無いですし、できるわけもないのですが(物理的な制約はどうしてもありますから)、自分たちの仕事を振り返って、変えていくためのきっかけには良い1冊だと思います。とにかく後半の記載はどれも具体的だし、実際にやってみよう、という気にさせてくれますね。問題は、この本が散々強調している「ドキュメント化」の稼働が取れないことじゃないかと思いますが......


GitLab社といえば、昔、本番データベース障害からの復旧するまでの様子をストリーミングで生中継したのが印象的でしたね。

www.publickey1.jp

このオープンマインドがあるなら、確かにこの本に書かれている世界観に到達するなーと納得しました。

(でも心臓に悪いので、動画は見ていません!!)

KEEBMATを導入

これまで使っていたデスクマットがだいぶ汚れてきたので新しいのを探していたら、XのTLで流れてきたKEEBMATという小型キーボード向けのキーボードマット製品が気になったので買ってみた。中国からの配送で、注文から1週間ほどで届いた。

keebmat.com

Xの公式アカウント、ピン留めのツイートが日本語で日本のファン向けのメッセージになってたりして、TLに流れてくる写真も比較的日本の人が多い。

https://twitter.com/keebmatcom

小型キーボードの大きさに合わせた5種類のサイズが用意されていて(40%、Alice、60%、65%、75%)、色は7種類から選べます。

自分が使っているキーボードに合わせて60%を注文。

早速セットアップしてみると...あまりにぴったり作られているので、キーボードを置くと全然見えないですね。

打鍵時の音は……使っているキーボード自体がかなり重くてがっしりしているので、そこまで変わらないかな……ただ普段使っている机が平ではないので、この手のマットが無いと安定しないので、必須なのです。

表面

裏面 ゴムでコーティングされているので、机の上で滑らないようになっています。

パッケージ


また、同じサイズ展開でフェルトエディションという種類もあります。

フェルトエディションの方にはデスクマットとして使える大きめのPLUSというサイズが有ったので、こちらも合わせて購入。

フェルトエディションの方は丸まって届くので、濡らした布を当てて、重いものを乗せてまっすぐにする工程が必要(アイロンでも可)です。

ちょっと面倒だけど、ちゃんとマニュアルに沿ってやった方が良さそう。

追記:けっこう頑張ったけど、重いものを載せる方式ではダメでした。スチームアイロン使ったらすぐに綺麗に伸ばすことができました。 最初からアイロン使った方がいいです。


小型キーボードにこだわる人向けのニッチな製品ですが、余計なスペースを取りたくないから小型キーボードを使っているわけで、確かにこのニーズはあるよなーと思いました。

『プログラミング勉強中の人にオブジェクト指向とは何なのかなんとなく伝えたい本』は、教える人と、教えられる人に配慮した気遣いの1冊です!

技術書典15で「かまずにまるのみ」という素敵な名前のサークルの『プログラミング勉強中の人にオブジェクト指向とは何なのかなんとなく伝えたい本』という本を入手しました。

boothで買えます

booth.pm

オブジェクト指向について、初学者のために勉強のとっかかりとなるキーワードをサクっと教えてくれる本です。

オブジェクトとは何か、クラスとインスタンスとは何か、なぜオブジェクト指向を使うのか、といったことが短いながらも、ポイントを絞って解説されていて、「このくらいの分量なら読む気になるかも」と思わせてくれるところが良いところ。


そして、なによりこの本が素晴らしいのは、「教える立場の人へ」というページが用意されていて、初学者がどんなところでつまづくか、どんなことに気をつけて教えると良いのか、というところがフォローされている点です。このページが用意されていることでこの本のパワーはおそらく530倍くらいにはアップしていること、間違いなしです。


当然、わずか26ページの本でオブジェクト指向のすべてが分かるわけではありませんが、貴重な第一歩を歩み出すには良いきっかけになる本だと思いました。


なお、この本をベタ褒めしているのは、この本を購入する際に、筆者のただあきさんから鳩サブレをもらったからでは決してありません。決して!!


ちなみに現代的なオブジェクト指向プログラミングを学んでいくために、WEB+DB Press 132号の特集はなかなか良かったので、次のステップに移る際にあらかじめ読んでおくと良い道標になると思います。

技術書典15オフラインへ行ってきた

techbookfest.org

ずっと一度は行ってみたいと思っていた技術書典、はじめてオフライン会場へ行ってみました。

とにかく会場が広いし、無限に興味深い本が有って見切れない!!

当日の午後、急遽行く時間を作って行ったのだけど、現地にいられるのが1時間くらいしかなかったので、とりあえず会場で知っている人を探してご挨拶し、これだけは!と思っていた本を確保。

今回の収穫は以下の4点。滞在時間が短かったのと、事前に全然下調べができていなかったので、無限に面白そうな本が有ったけど、最低限これだけは!という本だけ押さえました。

書評を書きますと宣言したので、それはまた後日。


次回はもっと時間を確保してゆっくり回って見ていこうと思いました。

『Software Design 2023年11月号 追悼 Bram Moolenaar Vimへの情熱と貢献を振り返る』を読んだ

gihyo.jp

長年お世話になっているVim、その作者である Bram Moolenaar 氏が亡くなった。その追悼記事をMattnさんがSoftware Design 2023年11月号に書かれている。

Vimの開発の歴史から、Vimの開発スタイル、Bram 氏の人となりがわかる、とても良い記事だった。

Vim Confに来たのが実は一回だけだったというのも知らなかった(行けばよかった...)

一人のエンジニアに対して追悼企画がされる、というのは、それだけ残したものが大きかったのだろう。

Mattn氏も含めたメンテナンスチームが開発を引き継いで、さらに開発が続けられていくのが、ソフトウェアの一つの良い点なんじゃないかと思った。