hirapi's blog

駆け出しwebエンジニアのなんでもないメモ書き

builderscon tokyo 2018 聴講メモ #4「lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話」by Rui Ueyamaさん

(スライド公開されたら貼らせていただきます)

※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される(?)公式動画をご覧ください。

lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話

@rui314

テーマ

  1. lldの紹介
  2. 開発を始めた経緯
  3. 速くてシンプルなコードを書くためのポイント
  4. 具体的な高速化のテクニック

テイクホームメッセージ

  • 問題についてよく考えて、自分が良いと思うやり方を勇気をもって試してみよう
    仮にアンチパターンであっても
  • 存在しない問題を作り出さない。もともとの問題を直接解決できないのか、をよく考えよう
  • Unixの開発環境の標準リンカになる」という大きな目標も、誰も挑戦しないだけで意外と実現可能だったりするので、挑戦してみよう

内容

  • リンカ:オブジェクトファイルを1つの実行ファイル・DSOにまとめるもの
  • 何もしないプログラムのソースコードを、既存のリンカに入れて、出力されたバイナリを印刷して読んだ
    → 1bitだけ変えてみたりして理解していった。
  • 当時、Linux, Windows, mac OS すべてファイル形式違うのにひとつのリンカでやっていた
    → スクラッチで書き直し。Windowsだけターゲットとするようにした
    • 「書き直したくなる気持ちはわかるけど」「リファクタリングでいいのでは」などの意見
      → 無視して書いたら10倍早くなった。 いちいち対応してると 無い問題を解決しようとすることになる
    • 遅いプログラムを構造によって早くすることはできないが、構造によって自然と早いプログラムが書ける
      構造が先、コードは後
  • 他の人が、同じデザインでLinuxのリンカを作った → 4バージョンに対応することに
    • デザイン構造は共有するが、ソースコードは共有しない
      アンチパターンのように見えるが、トータルで見ると早い
      最適化する箇所を最小限にする
  • OSSとして、オーナーシップを持っておく
    • 1回しかコントリビュートしない人が、自分の(狭いスコープで)達成したいことのためにプルリクを出してくる
      → 送ること自体は良いが、それを取り入れるかはオーナーが判断する
      きれいなコードはオーナーが保つ
  • 2回書く ← 1回目から学ぶ。できれば3回書く

質疑

  • 「コードを2, 3回書き直してみる」:最初のコードに引きずられそう
    1回目書いてるときに思った「ここをこうしてみたら」を次に実践してみる、思いつくものは全部試す感じ。
    しっくりくるものを探す。
  • 「コードを共有しない」:改修コストがある反面、共通化するとif文が増えたりする。どう選んだ?
    勘です。
  • 次の目標は
    Linuxディストリビューション全体が10秒でビルドされる、とか?w

カーゴ・カルト・プログラミングはやらない。
80年代に決められたデフォルト値に従う理由は無い。

感想

さいしょわかんないとこ来ちゃったーと思いながら聞いてて、終わったときにはエンジニアとして何かを叩き起こされたような感じで、まだうまく言葉にできない……。
すごく素敵なセッションだった。動画公開されたらまた改めて聴いてみる。それでできれば改めてまとめてみる。

builderscon tokyo 2018 聴講メモ #3「機械学習を用いず数学でゲーム内の需要予測をする」by @nessie_seseinさん

speakerdeck.com

※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される(?)公式動画をご覧ください。

機械学習を用いずに数学でゲーム内の需要予測をする

@nessie_sesein

カヤックのゲームレベルデザイナー

テーマ

  • 純粋数学の見方・考え方を理解する

  • 分析の重要性と問題

  • 数学について
  • ゲーム内の需要予測

テイクホームメッセージ

なぜの追求、数値と言語の行き来

  • 理論ベースで需要予測を行うと、機械学習とは違って未来を最適化するアクションが見えやすい
  • データが少なくてもいける
  • 時間が経つと予測がズレるが、原因を見つけやすい

内容めも

  • 分析の重要性と問題
    • 分析は地道な「数%の改善」であって、いきなり大金持ちにはなれない
    • 毎年「ビッグデータ元年」みたいに言われてる
    • ゲーム:コンシューマー向け買い切りから長期的なソーシャルゲームへ → 分析の重要性
    • 因果関係の分析を誤ると適切なアクションが取れない(e.g. 疑似相関)
  • 純粋数学
    • 証明するまで正しさを認めない、見える範囲の事実にだけ言及するのが数学
    • なぜの追求:事実以外の認知をしたとき、なぜ自分はそう考えた? を追求する
    • 数値と言語の行き来:数値による根拠を元に認知する。バイアスを取り除く
  • ゲーム内の需要予測
    あるある:「新規ガチャ売れた → 復刻ガチャでも売れるでしょ!」← なぜ主観的予測がこうなるのか?
    もし売上構成が「課金上位者10%が売上の90%を占めていた」場合、その人達がガチャをコンプリート・カンストしたら買わない
    → 残りの課金下位90%(売上の10%を占めていた)の人達だけが復刻ガチャに課金しうる
    1. 前提条件とゴールの設定
    2. データを眺める
      サンプル500くらいあればいいと統計学的には良いと言われるけど、高々有限なんだから全部見ればいい。
      自分は5,000くらいは眺める
    3. 仮説作成
    4. 仮説を数値に落とし込む
      ゴール(ユーザーがガチャを何回回すか)と相関がありそうなものから順番に処理。
      「レベル5になったら何人かのユーザーは満足しちゃうかな」→ とりあえず8割くらいガチャやめるとする
      端点さえ合っていれば中身はどうとでもできる
      = 相関係数を元に一度 y = ax + b を用意して、例えば上側にふくらむ非線形の式にしたいのであれば、上側にふくらませるf(x)をかける
      → y = (ax + b)・f(x)
    5. 例外処理・微調整
      土台の式ができても、3割くらいはズレている → 外したり、影響を小さくする関数をはさんだり
      ゴールと相関のある部分を求めて、例外をつぶしていく
  • 施策
    改を出す前に、☆5の排出率を上げて、改を欲しがりそうなユーザーを増やしておく → 売上144%
  • 機械学習
    ユーザー数はあっても、1ユーザーあたりの試行回数が少ないと処理する例外が多くなる。
    前処理しやすい、DBが機械学習用に整っている、データが多い、というケースでは機械学習が適用できる。
    そうでなければ理論で予測したほうがいい。

質疑

  • 今のお話に必要な数学的素養を身につけるのにおすすめの本
    普段から「なぜ?」を考える癖をつけてみるといいかも
  • ドメイン知識・仮説
    自分が「なぜ」を追求して、誰にでもそれを説明できるように用意する。
    自分がユーザーにもなって、行動経済学や心理学の知見ともあわせながら説明できるようにする。

感想

面白かったあー!
言葉の端々に数学徒感が出てて楽しかったw 「高々有限なんだから全部見る」は名言。
定理・公理や数式ではなくて、なんていうか「"数学的"なものの見方」にこだわって話を進められていた。
質疑にあったように日常的な習慣づけで数字の扱い方を変えていけるんだなって素直に思った。

でも別に知識が何もいらないということではなく、普段からなぜを考えていくことで知識の身につけ方も変わっていくのかなあとか。
大人になったあとの勉強の仕方もあるかもしれないと思った。

builderscon tokyo 2018 聴講メモ #2「開発現場で役立たせるための設計原則とパターン」by @shinpei0213さん

(スライドもし公開されたら貼らせていただきます)

※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される(?)公式動画をご覧ください。

開発現場で役立たせるための設計原則とパターン

by Shinpeim

『WEB+DB vol.91』データ構造特集がおすすめ

テーマ

  • このケースで何が最適か、どうやって判断するの?
    「適材適所」「ケースバイケース」は何ら回答になっていない

テイクホームメッセージ

  • 複数の選択肢を用意する → 問題の「変わりやすいところ」を考慮して設計原則からレビュー を繰り返す
  • 設計原則

内容めも

  • 設計・パターンは抽象的な話が多く、空中戦になりがち

    • 「抽象化」って人による
    • 「責務」って考え方による
      「システム全体に責務を持つからSystemManagerクラス作ろう」← 反論できるか?
  • そもそも設計って?
    複数の分割構造の選択肢から 選び出す こと。設計原則・デザインパターンはその武器

    • デザインパターン:カタログ
    • 設計原則:良い構造かを判断する指針
      パターンを使って分割する ⇔ 目の前に立ち上がってきた構造に対して、原則を使ってレビューする
  • 例題:掲示板ウォッチスレ 投稿通知機能

    • 「なんであかんのか」を言語化できないのであれば、それは暗黙知
      → 「センスのある人」しかできないことになる
      エンジニア足りてないって言われてるなかセンスのある人でチームを組めるのは金と知名度があるとこだけ
  • 単一責任原則
    でも「責務」ってふわっとしてる……
    あるモジュールを変更する理由が2つ以上あってはいけない
    「なんとなく駄目」だったのが「コメント通知の仕様変更でもスター通知の仕様変更でもこのクラスに変更が必要になるから、駄目」になる

  • 開放閉鎖原則
    例題:引き落としできなかったらsuspend、3回引き落としできなかったら永久追放
    新しい機能を足す時に、既存のクラスを書き換える必要がある ← 拡張に開かれていない

  • 凝集度と結合度
    凝集度は高く、結合度は低く

    • Customerに関する操作をCustomerSuspenderにやらせてしまっている
    • Customerにとって他人であるCustomerSuspenderの処理をCustomerが何度も呼ぶ必要がある
  • 「なんかオブザーバーパターンっぽくね?」ってにおいを感じる

    • CommentObseverを作ると、そいつはスターというイベントは完全スルーできる
    • パターンに従ってCommentとCommentObsercerを分けてみたけど、分ける必要はあるのか?
      そもそもオブザーバーパターンて何だっけ、から「開放閉鎖の原則」を評価軸にする
      • 今回のケース、拡張される?(コメント発生時に通知以外のイベントが足されることある? オブザーバー足される?)
        → 結合度はOKだが、現実的な未来予測について見るとそもそも分ける必要があるのか不明
      • 今回のケース、修正に対して閉じなければならないの?(コメントの仕様が変わったとき、通知の仕様はそのままなの?)
        → むしろ凝集度がNG
    • パターンを使って構造化したとき、設計原則を使ってレビューすると「実は不適切では」ということもある
  • Commentクラスにひとまとまりにしてしまう
    単一責任原則はどうなる? まざっているのでは?

    • コメントの仕様が変わる(→ 通知の仕様もきっと変わる)ときに、Commentクラスだけの改修で足りる
      → 単一責任原則を満たしている
  • まずは問題を見極める = どこが変わりやすいポイントか
    コメント発生時に通知以外のイベントが足されるのであれば、オブザーバーパターンでよかった。
    どこが変わりやすいポイントかがわからないと、単一責任原則で設計のレビューができない

  • 未知の問題に対する解決
    どこが変わりやすい(やわらかい)部分で、どこが変わりにくい(固い)部分なのか、まずは問題と向き合う。
    KISS原則、YAGNI原則

質疑

  • 設計原則について適用フェーズによって分けられるかも?(← あまり聞こえなかった)
    SOLIDの原則のうちSとOが今日の話だった。KISSやYAGNIもやや抽象的なもの。
    LとかDは抽象度が低く、自分で構造を考えるときに使えるかも。
  • チーム開発で、設計レビュー時には一通りコードを書いてしまっている
    前職は採用時に絞っていて、暗黙知で通っていた。
    現職では設計レビューうまくできていない。

感想

「なんかあかん」設計にデザパタ適用して、それをさらに設計原則からレビューする、ていうサイクルを実演してみせてた。
オーディエンスが例題見た時に持った「なんかあかん」をきれいに議論に落とし込んでてとてもスマート、聞いててテンションあがった。
自分のためにもチームのためにも、パターンと原則を武器として身につけねば……!
アニメと構成そろえてて、合間合間に息子さんのショットが入るの和んだw

builderscon tokyo 2018 聴講メモ #1「産業でガチ利用されるRaspberryPiの話」by @kazuphさん

speakerdeck.com

※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される(?)公式動画をご覧ください。

産業でガチ利用されるRaspberryPiの話

@kazuph

  • 日本で最初のスマートロックAkerun

テーマ

  • なぜラズパイ?
  • 利用実績
  • より強固なデバイスにするために
  • ラズパイで駄目な場合

テイクホームメッセージ

  • ラズパイが完全に品質面で他を圧倒している
  • ラズパイが完全にIoTレディーになった(Wi-Fi, Bluetooth対応によって)
  • ラズパイが同類では最安
  • 大量のソフトウェア資源があるので、試作・開発コストが低くて済む

内容めも

  • ラズパイ:高い品質・安価・汎用的な開発環境・安定供給

  • 利用実績

    • Akerunプロトタイピング
      秋葉原で買える、Pythonで書ける。買い出し含めて1日でできる。
    • 組み込み製品のデバッグ
      Node, Python, Golang
      Jenkinsでビルドしたイメージをラズパイ経由で組み込み製品に反映させる
    • 工場での出荷ツール
      状態をラズパイ経由で飛ばしてPCのブラウザから確認できる
      向上ツール開発祭り(治具祭り)← テンション上がらないので「祭り」として数日間実施
      工場でAnsible:物理的に組み立て → 検査 → 自壊プログラムを流し込む → Ansibleを流せなくする
      2016年から一回も交換なし
    • IoTゲートウェイ
      工場で実際に使っていて、大丈夫だと思った
      BLEが標準搭載になって、別途ドングルを買う必要が無くなった
      性能:1m離れたところで計測すると、旧製品が25%くらいだったのがラズパイで80%近く
      5m離れると差は小さくなる、これはBluetoothの仕様として当然
      • 電源まわり:
        ラズパイだけだと怖い。雷サージ対策済みのACアダプタ、拡張基盤で静電気対策
      • ログ:
        容量・I/O上限・接続できない(お客さんの環境に置いてあるので)
        → すぐ削除、できるだけオンメモリ、S3に日次アップロード
      • セキュリティ:
        大事なものはSDカードに置かない
        機密情報はすべて拡張基盤(nRF52)
        ゲートウェイ起因でクリティカルな処理が行われないように。乗っ取られても開かない(サーバーからの指示が必要)
        あくまでゲートウェイとして暗号化されたあれこれを仲介しているだけ、「開ける」という動作を起こせない
      • ソフトウェアアップデート
        nRF52でイメージ作成・更新してラズパイに反映させる(?)
  • ラズパイでは駄目なとき

    • 4,000円台でも高い
    • 電池駆動にしたい
      Wi-Fiや前世代のBluetoothは電池消費がはげしい
    • クリティカルな処理をさせたい
      nRF52など専用チップと併用するべし。破壊されて取り出されても意味は無い、まずいのは「動く状態でこっそり情報を抜かれる」こと

質疑

  • 使う上で気をつけること
    正直あんまりケアしていない。濡れたり静電気とかは別だけど、雑に使っても意外と大丈夫。
    SDカードは耐久試験して使ってる。良いやつを使うべし
  • ゲートウェイとして使うとき、ラズパイがどこかに置いてあると思うと物理的なセキュリティが気になる(SDカードが抜かれていじられたり)
    レンタルというビジネス形態上、SDカードを抜けないようにはしていない。
    スマートロックの場合、基本的にラズパイは室内に置いてあるのでいいでしょうと思っている。
  • ラズパイの次のバージョンで改善してほしいところ
    今でもLinuxベースなので改善はしていけると思っている。
    IoTまわりの通信規格、新しいのが出てきている。範囲が広く、通信量も保てる規格が出たらそれに対応したくなると思う
  • 5GHz対応が必要になる場合というのは 企業ユースの場合、5GHzを必須で求められることがある
  • TensorFlow?
    うちでは使ってない、ファームビルドが対応してるよという紹介だった。最近ラズパイ用のビルドが出たので使ってる人もいるらしい
  • SDカード選定
    メーカーを選定 → 連続で書き込み・読み込み
  • ラズパイ0
    安価で小型で、良いなと思っている。
    ただ品質がまだ不安、有線LANに対応しておらずtoBだと合わないかもしれない。
  • SDカード
    T社じゃないですかねw

感想

使ってみたくなった!!
組み込み系ぜんぜんやったことなくて用語がたまにわからなかったけど、WEBなところもあって(むしろWEBとの境界が曖昧になっていて)意外とわかりながら聞けた。
セキュリティとログみたいに、WEB開発と同じテーマで前提の違う解決をしてるの知っとくとWEB開発にも活かせるところがある気がした。

夏休みの思い出に横浜でなんちゃって開発合宿してきた

書いてたら長くなっちゃったから一言で言うと↓↓

軽いノリで遠出をして、その中のアトラクションのひとつとして勉強・開発を入れてみたところ、心身を休めつつ充足感も得られて楽しかった という話。

なんちゃって開発合宿

ふと思い立って、東京23区内に住んでるエンジニア2人で「なんちゃって開発合宿@横浜」してきた。

「なんちゃって」なのはさして開発もしてないし別に合宿と呼ぶような距離でもないため(笑
他に呼び方が思いつかなかったから「開発合宿」と書いてみたけど、
あくまで余暇としての遠出で、その中のアトラクションのひとつがカフェでの勉強・開発 という感じ。

経緯&目的

  1. 夏休みを取った!
  2. 旅行でも行きたいねー
  3. でも雨らしいよ
  4. ひきこもるかー
  5. 出かけて開発しよう

前から1人か2人でビジホ開発合宿やってみたかったというのもあり、こうなった次第。

会全体の目的は、別に話し合ったわけでもないけどたぶんこんな感じ↓↓

  • 気分転換
  • やろうと思いつつやれてないことをやる

拠点

作業拠点

横浜ランドマークタワー地下1階にある BUKATSUDO さんのコワーキングスペース WORK LOUNGE を使わせていただいた。

WORK LOUNGE | BUKATSUDO

  • 最寄り駅は桜木町とみなとみらい
  • 電源・wi-fi完備
  • ドロップインは1時間500円、4時間以上2,000円
  • 初回利用時に会員登録が必要(300円)※ 要身分証明書
    申込書類には自分の住所等のほかに会社名も書く。
  • 利用中出入り自由
    利用開始時、会員カードと交換にセキュリティカードをもらい、ゲートにかざして出入りする。
  • WORK LOUNGE 内は原則おしゃべり禁止
    カーテンで区切られたソファスペースは商談・打ち合わせOK。
  • 飲食物持ち込み可
    ただし食事は WORK LOUNGE の外にあるフリースペースで。
  • コワーキングスペース以外にレンタルキッチンとかあるっぽい
  • 有料のコーヒー(おいしい)と焼き菓子がいい匂いしてる

横浜近辺には他にもいくつかノマドカフェあるみたいだったけど、土日に長居するのに勝手がよさそうだったからここに。
静かだしおしゃれだしソファだしでとてもよかった、正解だった!

宿泊拠点

新横浜のフジビューホテルさんにお世話になった。
連れの要望で大浴場が欲しいとのことだったので、温泉付きのここを予約。

新横浜フジビューホテル スパ&レジデンス|新横浜のホテル|新横浜スパ天然温泉・岩盤浴

  • 部屋(ツイン)きれい、満足
  • 温泉は弱アルカリ性、ややぬるぬるで良き
  • 浴槽が熱めとぬるめで分かれてるのも良き
  • サウナも良き
  • お風呂場のアメニティは必要十分
    ただシャンプーの質はさして良くない
  • 朝食バイキングは普通
  • 土日の1泊温泉朝食付きで6,000円
    予約プランによっては温泉・朝食がそれぞれ別料金かもしれない
  • wi-fiあったけどパスワードかかってなかった(から使ってない)
  • 従業員さんたちがにこやかで親切!

直前に予約したのがかえって良かったのかな? 総合的に見て満足度高いしコスパ良かったと思う、また来たい!

タイムテーブル(?)

綿密に計画立ててたわけではなく結果的にこうなった↓↓

  • 金曜
    • 22時 発案&催行決定&予約
  • 土曜
    • 10時 出発
    • 11時 到着&昼食
    • 12時 籠城スタート
    • 16時半 撤退
    • 17時 ホテルチェックイン
    • 18時 夕食
    • 20時 温泉
    • 25時 就寝
  • 日曜
    • 9時 朝食
    • 11時 籠城スタート
    • 15時 昼食
    • 20時 撤退
    • 21時 温泉
    • 25時 就寝
  • 月曜
    • 9時 朝食
    • 9時半 チェックアウト
    • 11時 解散

やったこと

とにかく各人でもくもく。
私は「katacodaで今度こそdockerに慣れる」を目標にしてたからこれをメインにして

www.katacoda.com

  • katacoda
    やっとやっとdocker使おうという気になった! 次はKubernetesやる〜
  • 『エンジニアリング組織論への招待』
    会社で個人的にメンタリングを求められたから、参考にするためにメモを取りながら。
  • ブログ記事執筆
    これはホテルで。最近やってることを自分の中で整理するため。(11月か12月に公開するつもり)

いつものことをぎゅっと集中してやった感じ。
「わざわざ遠出してやることか?」という疑問もあるかもだけど、katacoda毎日ちょっとずつだとなかなか進まなかったしちょうどよい内容だったと思う。

あと実は前に会社で開発合宿(こっちは温泉旅館の開発合宿プラン)行ったことがあって、そのとき個人的な反省として「一人で作業するならアイデア出し・設計・環境構築はNG」「ゆえに、開発するならコーディングに取り掛かれる状態を事前に作っておくべし」というのがあったので、今回開発は考えなかった。

あんまり詳しく聞いてないけど連れは仕事の開発をしてたらしい。

感想&反省

感想

休息と勉強・仕事を両立させられたのが何より良かった!!
のんびり休んだ感も何かがんばった感も両方得られた。

それ以外だと↓↓

  • 気持ち:
    • お金かけたしがんばらなきゃ、という思いがすこし生まれる
    • 作業拠点と宿泊拠点分けたの、個人的には良かった。メリハリつけられた
    • 観光的なことにあまり気を割かなくていい距離感で、今回の気軽な企画に合ってた
  • 宿泊拠点:
    • 洗濯もゴミ捨ても掃除も無いの最高
    • 浴場なんだかんだ必要な気がした。部屋のシャワーだと日常感が出る
    • 外に作業場を持つならホテルに作業環境はいらない
  • 作業場:
    • 出入り自由&飲み物自由&居眠り可なのが籠城要件な気がした
    • 近くにコンビニがあれば最高だった

あと合宿とは関係ないけど、一日集中するために今後続けようと思ったこと↓↓

  • 朝、作業に入る前に大学入試センター試験(の簡単な設問)を1問解く
  • 昼食は炭水化物メインの料理を避ける
  • 眠気で頭が重たくなってきたらあきらめてちょっと寝る

うしろ2つは前から気をつけてたけど今回改めて。
センター試験は試しにやってみたらちょうどよかったから続ける。数IAの簡単な計算でも頭を作業モードにするには十分だった。

反省

次はこうする↓↓

  • 土日月じゃなくて金土日にする
    金夜出発 → 土曜朝 〜 日曜夜で作業 → 日曜夜解散 のほうがどう見てもコスパよかった
  • 昼食・夕食の場所、できる範囲で事前に決めておく
    せめて外で食べるか買って食べるかだけでも
  • 折り畳み傘を持っていく
    買い物が発生すると開店時間まで待たないといけない

おわり

費用は交通費・宿泊費・コワーキングスペース代・外食代あわせて2万ちょっとだった。
またやる!

Geeks Who Drink in Tokyo -俺の!私の!ベストカレーEdition- でヌーラボTシャツもらった

nulab.connpass.com

backlogでいつもお世話になってるヌーラボさん東京オフィスにおじゃましてきた!
でなぜかカレーガチ勢のみなさんにまじってLTしてきたw

カレーLT - slideship.com

てんやわんやしてしまったけど、菊すけさんの山椒カレーうどんと湯布院の名湯が票を集め(笑)まさかの優勝を果たしてしまった↓↓

ご投票くださった方々ありがとうございました……!

メインのもうやんカレーものせとく↓↓
カレーとtechのいろんな話聞きながら食べるもうやん、良かった。

持って帰りたかったけど持てなさそうだったからその場で2杯食べた。仕方なかった。

それと、遅刻して最初のほう聞けなかったけど合間合間に流れてた動画を見るにヌーラボさんめっちゃ楽しそうだった……!
海外支社があると空気が自由なのかなあ、宮古島でリゾートワークうらやましい。

nulab-inc.com

司会者の方も言ってたけど何のためのイベントだったんだこれは……w
でもたくさんお話しできたしカレーにちょっと詳しくなれたしTシャツも頂けたし、参加してよかったです!!
またおじゃまさせてくださいーw

『UNIXという考え方―その設計思想と哲学』を読んだ

UNIXという考え方―その設計思想と哲学 | Mike Gancarz, 芳尾 桂 |本 | 通販 | Amazon

を読んだ。
自分にとって大切な本のひとつになる気がしたので、読んだという事実を世に知らせるために簡単な感想のメモを。

内容の核である「UNIXの定理」は

定理1:スモール・イズ・ビューティフル
定理2:一つのプログラムには一つのことをうまくやらせる
定理3:できるだけ早く試作を作成する
定理4:効率より移植性
定理5:数値データはASCIIフラットファイルに保存する
定理6:ソフトウェアの挺子を有効に活用する
定理7:シェルスクリプトを使うことで挺子の効果と移植性を高める
定理8:過度の対話的インタフェースを避ける
定理9:すべてのプログラムをフィルタにする

例えに出てくる固有名詞(マシンとか昔のOSとか)に馴染みがなくてイメージしにくい部分もあったけど、これら定理の正当性について展開される議論がとても鮮やかだった。
本の最後のほうで総括されているように、全ての定理は一貫していて、それゆえの説得力があった。

その一貫性の裏には「不確実性」というひとつの大きな前提がある。
本書ではっきり述べられているように、ソフトウェアの実行環境(ハードウェア)も、ソフトウェアに求められる機能も、きっと明日には変わっている。ただしどう変わっているかは今日の時点ではわからない。
だから移植性を重視するし、スモール・イズ・ビューティフルだし、世界中の車輪を使って新しいものを作っていく。
単語こそ強調はされていなかったけど、まさに「不確実性」への対処論だと思う。

どこかのレビューに「実用性が無い」って書いてあったけど、たぶんその人が求めているのはただのドキュメントなんだろうな。
「なぜそうなっているか」を理解しながら「どうなっているか」を調べるとそれを使いこなせるようになるまでの時間は格段に短くなるはずで、そういう意味ではとても実用的な本だと私は思った。

UNIXをよく噛んで飲み込んで消化できたらまたどこかに書く。