「UNIXという考え方」を読んだ
電子書籍がなかったので久々に物理で読んだ
- 作者:Mike Gancarz
- 発売日: 2001/02/01
- メディア: 単行本
UNIXの定理への感想
小さいものは美しい
小さいとわかりやすく、保守しやすい、組み合わせやすい、計算機のリソースにも優しいということ。僕はプログラム単体でこれを意識していることはないけど、関数単位ではほとんどのプログラマがこの定理は大事だというだろう。
一つのプログラムには一つのことをうまくやらせる
いわく関心の分離。やりたいことの本質のみを行うことが柔軟性につながる。lsコマンドも本来は複数の列に整理して出力すべきではないらしい。 これもプログラマならまず意識していることだと思う。一つの関数、一つのモジュールには一つの機能、わかりやすい変数名と共にコードの基本な気がする（かつ難しい）。
できるだけ早く試作をつくる
これもアジャイル的な言葉で最近のエンジニアは重視している考え方だと思う。ソフトウェアはつくるのではなく育てて行くものだという考え方。
この本ではUNIXの成長過程と共にこの考え方が紹介されていた。ソフトウェアには3つの段階しかなく、若年期、成熟期、老年期しかない。最近だとrailsは老年期にはいってきているのだろうか。
最近、自分の仕事でも早期の試作の利点を体感することがあった。新機能を開発で議論をする時に、チームメンバーがそれぞれの頭の中の機能で話しすぎてそれぞれの議論が噛み合わないという問題があった。けれど、デザイナーの方がモックを作ってくれるようになった途端議論がスムーズになったという体験だ。具体的な図面はチームで議論する上で強力な標識となることをこのとき認識した。
この定理でのドキュメントに関する考え方も面白かった。ドキュメントを詳細に書くことが正義だと思っていたが、ドキュメントも育てるものであり、ちょっとしたことでも芽を残すことを意識して「気楽に」ドキュメントを残したほうが結果的に良いのかなとも考えた。
効率より移植性
ハードウェアは日々移り変わるので移植しにくいソフトウェアは長生きしないというもの。Webで色々やっているとHTTPでソフトウェアを配るのが現実的になってきていると思う。それこそChromeBookが体現していて、HTTPとその解釈ができるブラウザさえあれば他のサービスは全てブラウザを通して使える。サーバー単体のハードウェアではなく通信規格にいかにのっかれるかという時代に突入している気がする。いつかHTTPを超えるなにかが出て人々はそれをつかって情報をやり取りするようになるのだろうか。
数値データはASCIIフラットファイルに保存する。
「効率より移植性」と同様の感想をもった。
ソフトウェアを梃子として扱う
車輪の再発明は良くないというもの。そして人類全体でソフトウェアを複利させていこうとい考え方だと思う。なにも開発にOSSを使っていくだけじゃなく日々の作業で人のソフトウェアを使っていこうという気にさせられた。
シェルスクリプトによって梃子の効果と移植性を高める
「ソフトウェアを梃子として扱う」と同じ
過度の対話的インターフェイスをさける
なるほど言われてみると確かに、という話には感じる。ユーザーを束縛するインターフェイスはソフトウェアを組み合わせにくくし、バックグラウンドで実行させたりもできない。コマンドをつくる側からするとこれも重要な観点の一つなんだろう。RESTがステートレスを基本に作られてなければこれほど世界でWebサービスは流行らなかった気がするし納得。
全てのプログラムをフィルタとして設計する
それはそう。フィルタとしての機能を単独にするべきということにつながる。
まとめ
特に前半の「小さいものは美しい」、「一つのプログラムには一つのことをうまくやらせる」、「できるだけ早く試作をつくる」、「効率より移植性」は全てのソフトウェア開発で役にたつ考え方だと感じた。
あとアジャイル開発で「ユーザーの価値を考える」をそのまま「ユーザーにとっての価値を増やす」にすると機能を増やしすぎてユーザーの価値がぼやけるという問題もこれから起きるのかなぁとか思ったりした。
一人暮らしリモートワークで本当に捗るもの、それは沼
一人暮らしのリモートワークで困るもの、それは食事である。
会社であれば周りのコンビニや社食で買えばいいが、一日家にいるとなると話が違う。
また、出社していれば「通勤のついでに何かを買う」という行為ができたのでコンビニやお店に行くのも対して手間ではなかったが、リモートだと外にでるのすら億劫になる。
全て家の中で解決させたい。そんなあなたにおすすめの食事がある。
沼
沼です
沼とは色々なものを十合炊き炊飯器にいれて水分量たっぷりでつくるおかゆみたいなものである。 マッスルグリルというYoutubeチャンネルで広まった料理。
必要なものは
- 鶏肉(ささみ or 胸肉) 754g
- 生米 277g
- おくらちゃん 10本
- 干し椎茸 おもむろ
- 乾燥わかめ おもむろ
- カレー粉 適当
- 塩 適当
だけである。作り方は動画を見てほしい。めちゃめちゃ簡単。 これと卵２個でだいたい2000kcalである。
沼のいいところ
簡単
材料放り込んで炊飯器のスイッチを押すだけである。
これで明日の朝には一日分の食事が炊飯器の中にある。非常に体験が良い。
そして沼の材料はいちいち買いに行かなくてもAmazonで買えるものばかりである。肉、おくら共に冷凍のものがプライムNOWで手に入る。解凍する必要もなく、そのまま炊飯器にほうりこめばOK。その他の材料は普通のAmazonでも買える。
また全ての材料が保存がきくので、材料を腐らせてしまう一人暮らし自炊あるあるも発生しない。
安い
一日分あたり鶏肉がだいたい550円、オクラ100円、その他の材料は多めに見積もっても300円分くらいだろう。これで一日分の食事が出来上がる。水をたっぷり入れるので量もかなり多く、4~5回にわけないと食べきれないくらいである。
美味い
見た目からは想像もできないほど美味しい。干し椎茸とわかめの旨味がたっぷり溶け込んでいる。動画の通りに作ると少し薄めなので塩とカレー粉は多めで良い
栄養バランス
水をたっぷりいれるので低カロリー。カロリー計算もしやすい。タンパク質もしっかり取れる。
可搬性
リモートワーク時には役に立たないかもしれない利点だがこれも沼の強み。なにしろただのお粥なのでタッパーに詰め込めば簡単に持ち運べる。盛り付けなど必要なし。後述するが冷めても美味しいので保温したりする必要はない。
沼の悪いところ
見た目
名は体を表す。
沼ワンポイントアドバイス
もしこの記事を読んで沼を作ってみようと思った方にアドバイスを残したい。
意外と冷めても美味しい
保温して放置することで美味しくなる沼だが、冷める過程でも味が入るのかまた一段と美味くなる。筆者は朝になったら保温を切っている。
卵のとり方
沼だけだと脂肪が足りないので全卵を取ると良い。最初はゆで卵にしていたが、ぶっちゃけ生卵のまま沼に混ぜてしまうのがいちばん簡単なことに気づいたのでおすすめしたい。最近薊さんはオリーブオイル入れているらしい。
鶏肉
冷凍のささみが一番オススメ。本数で考えれば計量の手間もないし皮を剥がす必要もない。だいたい12本で760g。また冷凍なら肉でも日持ちがするので、「明日は会食の予定があるからを作るはやめておこう」に対応しやすい。
炊飯器
できれば十合炊きを買った方が良い。五合だと水の量が足りないし成人男性ならば一日分作るのも難しい。 どうしても五合炊きで作りたいならばマッスルグリルのこの動画を参考にするべし。
まとめ
筆者は沼生活を二ヶ月ほど続けている。朝飯もしっかり食べるようになって体の調子が良くなった。簡単だし安いし美味いし満腹感もあるのでリモートワークで自炊を始めようと思っている方全員におすすめしたい。
Ginza.rb#80でLTをしてきた
当日の概要
Ginza.rb#80でLTをしてきた
LT
イベントの空気感的にはかなりカジュアルよりだったけど、社外でのLTは初めてでガチガチに緊張していた。当日のスライドは以下。
speakerdeck.com OSSへのコントリビュートを一年やってきて思ったところを発表した。koicさんが引用してくれたりyagiさんにいい話きけたといってもらったりして嬉しかったです。
他の人の発表も、「2.7からのパターンマッチは実は右辺代入だった！？」とか「同じシステムってなんだ？」とか「rubocop-minitestのリアルタイムリリース」とか「自分の一年間やってきたこと」とか「fill_inがモーダル開閉のfocus()でうまく機能しなくなる」とか「Kaigi on RailｓはRubyKaigiと初心者向けの中間くらいの難易度で開催したい」とか色々な話題のLTがあって面白かった。
まとめ
Ginza.rb、毎回willnetさんやy-yagiさんのためになる話がきけるのでRuby好きの人にはオススメの勉強会。
graphql-rubyにコミットした
業務でgraphql-rubyを色々いじってたら「おや？」と思う挙動があった。調べてみると同じ内容でissueを立てている人がいた。
graphql-rubyでは_idといった引数を受け取った時にloadsオプションを指定しているとHogeSchema.object_from_idを呼んでレコードを取り出す動作を簡潔に書くことができる。
だけど実はこれはinput_object(いくつかの引数の型をまとめて定義したもの）として定義しないと使えなかった。（Mutaionでも引数につかえるのだけれどMutationの引数は実質input_objectの定義なので同じ。）
前回graphql-rubyをふんわり読んで色々脳内地図があり、issue内でもオーナーのrmosolgo氏が修正することに前向きそうだったのでPRを出した。
内容はinput_type内の処理をそのままfiledの引数の処理に持ってきたのと、内部で使っているload_application_objectが呼び出し元の@contextのリーダーメソッドに依存していたので外部から注入できるように変更したというもの。
rmosolgo氏が色々レビューをしてくれてありがたかった。（最後に氏みずからinput_object内の処理も少し書き換えるコミットを積んでくれた。不要にlodasに対して実行されていたコードが減ったので、PRの主目的以外の恩恵もあると思う）
GraphQLは仕事で使い始めたばかりだけれどテストコードやらみると色々勉強になって良い。
みんなのコンピューターサイエンスとプログラマの数学を読んだ
最近以下の二冊を読んだ
- 作者:Wladston Ferreira Filho
- 出版社/メーカー: 翔泳社
- 発売日: 2019/01/15
- メディア: Kindle版
数学、コンピューターサイエンスに関する本を読んだ。
本を読んだ理由
僕は文系卒であり、新卒で入った組織もソフトウェアエンジニアリングとはあまり関係ない場所だった。
自分がコンピューターサイエンスの基礎がわかっているとは思えないし、アルゴリズムをものにしているとも思えない。実際AtCoderにはちょくちょくでているものの未だレートはこんな感じ。大体ABCのCまでなんとか解いてDには歯が立たない感じだ。
だいたい良いプログラマーとは？みたいな記事をみるとコンピューターサイエンスを学ぼう、アルゴリズムを学ぼうと書いてある。
Matzもいってるので多分正しいのだと思う。誰がいっているのかで判断するのは良くない
海外の企業も採用時にはまずアルゴリズムについてしっかり確認する印象がある。
そういった記事を読んでとても不安になり本に助けを求めた。
なんにもわからない
論理、確率、帰納法、動的計画、データ構造は、説明できるほど理解できる時が来るのだろうか、競プロをやっていけば（周りよりスピードはゆっくりだろうけど）ついていくのだろうか。
「再帰はスタックに構造をいれていく」とか「５つのユニークな要素から３つ取り出す順列は5 * 4 * 3で60通りあるとか、順序を考えないと順序考えた分を割って5 * 4 * 3 / 3 * 2 * 1で10通り」とか読んでなんとなく意味はわかっても日本語が少し変わって問題を少しひねられたらなにもできない気がする。
根本は難しいことをできるだけ細分化して考えるということだと思う。しかし与えられた問題に適切なアルゴリズムを出す自信が全く無い。一歩ずつ頑張るしかないのだろう。
その他
「コンピューターサイエンス」と仮想メモリとかレジスタ、スレッド、プロセス、I/O、(メモリの方の）ヒープ、(スレッド毎の）スタック、カーネル、ソケットといった（多分）UNIXからつらなる概念は別扱いなのだろうか？ この他にもHTTPだったりRDBMSだったりなんにもわからんなと思った2020年1月22日だった。
RustでGithubのissueひっぱてくるCLIアプリを書いた
Ruby、Elixirときて完全に別軸の静的型付け低級言語としてRustで遊んでいる。
お正月に泣きながらRustのコンパイラといろいろしてた。
ユーザー名とレポジトリ名を下のように渡すと
github-issue rails rails
number |title |created_at | 38237 |Update caching_with_rails.md |2020-01-15T02:29:53Z | 38235 |Move advisory lock to it's own connection |2020-01-14T17:54:27Z | 38234 |Rails 6 : config.require_master_key=true doesn't raise an error if key does not exist |2020-01-14T15:49:12Z | 38229 |Prevent `has_one` `build_association` from `touch` parent record if the record isn't committed |2020-01-13T22:11:50Z | 38226 |Active Record unit tests fail with MySQL 8.0.19 |2020-01-13T14:59:02Z |
という感じで標準出力するアプリを書いた。プログラミングElixirの題材をRustで書き直したやつ。まだまだテストでのモックとかやるべきことはいっぱいある。
Rustつまづきポイント
そもそもコンパイラになんとか通してもらうために無理した書き方をしている自覚があり、しかもきれいにする方法がわからないので書くたびに自分の無力感が高まって泣いていた。
文字列型の種類が複数
Rustでのいわゆる文字列には、メモリ長が決定されている組み込みの&strと、メモリ長が固定されていない標準ライブラリにあるString型がある。String型はヒープ（スレッド間で共有できるメモリ領域）に格納できて可変。 実際にコード内で
"string"のように書くと&str型になるのでGithubからのレスポンスをStringとして扱う時に色々変換しなくてはならず辛かった。多分もっといいやり方があると思うので助けて。
Result型とOption型
つまづきポイントに入れてるけど同時にRustの優れてるポイント。多くの関数がこの2つのうちどちらかを返すことが多い。
OptionはNoneもしくは値を返すという型。 Noneはnullのようなもの。 返り値書くときにはSome(1)やNoneという書き方をする。
Resultは例えばrunみたいな関数があったとして
pub fn run(args: Vec<String>) -> Result<i32, Box<dyn Error>>
ようにエラーを返すかもしれないことを明記できる型。
返り値書くときにはOk(1)やErr(ParseError)という書き方をする。
これらの型で返された値はunwrap()をするか
process(args)?のように末尾に?演算子をつけて例外やNoneが出たら関数全体としてエラーやNoneを返すということを明示することができる。しかしどんな形がベストなのかイマイチつかめない。ここではめったにエラー起きないだろうってところはunwrap()でそれ以外は?という感じで使えばいいのだろうか。
ちなみにNoneやErr()に対してunwrap()するとpanicする。unwrap_or_else()なんかもあるのでやりようはありそう。
所有権
もう全然スマートな解決方法がわからない。無理やりclone()したりして逃れている。
rows.as_array().unwrap().to_owned()
こんなコードも書きながらもっといいやり方ないのかと泣いていた。
Rustのよかったところ
よかったところというとおこがましいという気持ちになるくらいには使いこなせてないんだけど書く
パターンマッチ
最高of最高
Result型
コードを読む側、使う側としてResult型はとても便利。エラーを?でキャッチできるしこの関数にエラー処理が任されているんだなというのがひと目で分かる。 そもそも型というものがコールドリーディング時に便利。
たぶんOptionとResultは慣れると余計なエラーやNullの処理挟まなくて良くなるので便利そう。
クロスコンパイル
最終的に機械語になって人に配布できるというのがRubyから入るとかなり画期的に感じる。 一応このアプリもタグ付けしたらGithubActionで複数OSでバイナリをビルドしてzipにしてリリースするということができた。（linux環境だと何故かOpenSSLがないと言われてリリースビルドが通らない。libssl-devを直接入れても再現するので困ってる）
cargo
Elixirのmixと同じで、ライブラリやテストが言語に組み込まれているのもモダンな言語感があってよかった。リンターもしっかり搭載。
ビルド通ったときの安心感
僕はCとかの低級言語はなにも触った事ない。けれどよく未定義動作の処理に困る話は聞く。その中でRustでコンパイラ通るということはメモリを贅沢につかってこそすれ危険に利用してないことなので安心感がある。
俺は今Rustというかっこいい言語で開発しているという謎の興奮
これが9割
まとめ
Rust本当になにもわからん。でも実践Rust入門は良書です。
2019年を振り返る
はじめてのふりかえり
1月
- エンジニアとして働いてなかった。2月に転職することがわかってたのでソワソワしていた気がする。新卒から一年と十ヶ月の短い期間だったけど迷惑かけまくったなぁと反省しています。
- 東京に引っ越した。
- 有給消化中にOSSにはじめてコミットした。嬉しくて書いた記事が思ったより反響があり、別記事内で言及してくれる人もいて嬉しかった。同時にQiitaの拡散力怖いと思ったのでメインはブログにしようと思った。 qiita.com
2月
- 業務委託として今の社で勤務を始めた。出社時間が自由すぎてカルチャーショックだったのは覚えている。自分のかいたコードがチームのリポジトリのmasterにマージされた時の感動は忘れられない。
- 読んだ本の中だとこれが印象に残っている。 sasa5740.hatenablog.com
3月
- 業務で一つリリースがあった。といっても僕はアプリケーションのコードを書いただけなのだが。
- 初めてエンジニアとして稼いだお金が口座に入った。こんなんでもらってええんかという気持ちになった。
- この頃から読んだ本をアウトプットしようと思って色々やった。
- Ruby2.7で追加されるパターンマッチに関してブログを書いたら実装した人から反応をもらえた。ブログ書くモチベの源泉となる体験だった。
4月
5月
- 仕事して本を読んでいた。
特に大規模サービス技術入門はすごい良書で、この後にプロセスとかメモリとかの勉強に触れようと思ったのはこの本のおかげだ。
6月
- SQL実践入門を読んだ。これも良書でもっと早く読んでおけば良かったなと思った。
7月
- 自分のPCをThinkPad X1 Carbonにした。Ubuntuのほうがコスパ良いじゃん！とイキってUbuntuにしたのだが、職場がMacBookの状態で更に別の環境を手入れするのは面倒だった。次はMacBook買うと思う。
とはいえUbuntuをいれていろいろトラブルシューティングしている内にUNIXコマンドの知見がたまったのでそれはそれで良かった。開発環境も設定さえちゃんとすれば不満なく使える。
- 新しいPCを勝ってモチベ爆上がりしたのでGemを書いた。Pryを頑張って読んだ気がする。面識ない人からPRをもらって飛び跳ねたのも覚えている。エイリアスで十分なことに気づき特に使ってない。
8月
- 引き続き別のGemを書いた。
rails consoleコマンドの実装を頑張って読んで書いた。ローカルではしっかり動作するの確認したんだけど職場のDocker環境でうまく動かなくて困っている。あとRailsのバージョンへの依存も激しすぎる。名前はかなり気に入っている。
9月
- ポエム書いた
- この頃Ruby以外の言語もちゃんとやらなきゃなという気持ちが高まりElixirを学習し始めた。
Elixirについて社内LTで発表したよ - Tallman
tokyo.ex#13 elixir本体ソースコードもくもくリード会に参加してEnum.tally書いてみた - Tallman
10月
- 株式会社グロービスに正式にジョインした。
- 応用情報技術者試験を受けた。これも無事に受かったので嬉しい。
- ElixirへのPRがマージされた。大きめのOSSへのコミットはこれが初めてであり、ましてやプログラミング言語だったので相当嬉しかったことを覚えてる。強引感が否めなかったのでちょっと反省している。
11月
- Punditにコミットした。仕事での困りをOSSへの貢献に変えるというのは一度やってみたかったので良かった。今年一番のPRだったと思う。
- 社内でLearning GraphQLの読書会をやった。自分で始めた最初の勉強会だった。英語の本しかでてなかったりで最終的に参加者が二人になってしまい進め方を反省した。
12月
- 会社のアドベントカレンダーにPumaのノンブロッキングI/Oについて調べた記事を投稿した。今年一番頑張って調べて書いた記事かもしれない。
- 静的型付け言語もやりたいなぁと思って最近Rustを書いてる。とりあえず型ジェネリクスというやつを完全理解した。所有権とライフタイムで脳が爆発している、メモリ管理を学ぶのに良さそう。
- 会社でReal World Httpの読書会を始めた。これを写経しているだけでFindyで一人前のGopherと認定されるぞ!
まとめと来年の抱負
今年のはっきりとした成果は基本及び応用情報技術者の取得とElixirのコミットくらいだろうか。
2020年は
- なにかしら外部の勉強会で登壇
- 大学院に進学
の2つを達成したい。
JAISTの社会人コースの見学にいった。年始に願書をだそうと思っている。
僕はエンジニアとして一緒に働きたいと思っている人がいる。その人に少しでも近づけるようやっていきたい。
