Magnolia Tech

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

定期的に知識をリフレッシュする

IT系に身を置いていると、つい新しい知識ばかりを追いかけがちになるけど、CS的な基礎知識や、Linuxのコマンドとかの(もちろんソラでコマンド10個のオプションを言える必要は、無い)も当然大事なわけです。というか、土台となる知識が無いと、新しい知識がちゃんと身につきません。

だけど、普段使わない、手を動かさない分野のスキルはどんどん忘れていきます。歳をとると加速度的に忘れていきます。

そしてヤバいのは、分かっていることと、分かっていないこと、できること、できないことの区別がつかなくなることです。

人は分かる範囲でしか物事を理解しないので、「分かっていないことを知る」という行為を行なって「分かる範囲」を広げる、または最低でも維持する営みを続けていかないとどんどん判断する時に必要な材料が狭まっていきます。

Java 1.5の知識で、Java17時代の判断はできないですよね、10倍以上違うんだから(それも違うけど)

そんな時定期的に、過去の知識をリフレッシュするための営みをやっていくには、入門書を改めて読んでコードを書く、ハンズオンをやってみる、ISUCONの問題を解いてみる、みたいなとにかく手を動かすと結果が帰ってくるコンテンツを試してみることではないでしょうか。

(ただ、マネジメント系はなかなか、’試してみる’というわけにはいかないですね)

書名を間違えてしまいましたが『初めてのSQL』、いい本ですね。前半はそれほど密度も難易度も高くないのでさらっと読めるし、後半もトピックごとに読めばいいテーマで拾い読みし易い。SQLは集合が頭の中に上手く描けないと、さらっと書けないけど、その感覚を掴むためにはやっぱりがんがん書くしかないんですよね。

というわけで、みなさんの「スキルのリフレッシュ方法」のおすすめが有ったら、教えてください!!!(ブクマのコメントに書いてください!)

ソフトウェアの再利用性について

ソフトウェアの再利用性、過去から散々研究されてきた大事なテーマだけど、それはどういうコードを書けば汎用性が高まり、再利用性の高いコードを書けるか?という話であって、適合性が検証されていない箇所に雑に当てはめても大丈夫な仕組みが発明されているわけではなくて、結局一つずつ検証していかないといけないし、その検証には相応のコストがかかる。

今動いているものが新しい環境で、それっぽく動くようにできてはいないのだから。

モデルを作っていく、ということについて考えた

モデリングの思考の過程、みたいな時に、関連する要素としてどこまでを考えるか?というのはぜひモデリングの達人に聞いてみたい。当たり前だけど、モデリングする人が純粋にモデルだけを考えられることはなくて、何らかの振る舞いが前提に有って、それがユースケースとして描かれたり、描かれなかったりする中で、どうやってその暗黙知形式知に変えていくか?というところが大事だったりするんだよね。

Software Design 2021年9月号

Rustを題材にしたメモリ管理の特集、でもそもそもメモリ管理とは?他の言語での実装は?など、基礎的なところから入って行ってRustにおけるメモリ管理の考え方と、実際のミドルウェアにおける事例まで一気に進むお腹いっぱいになりやすい充実の内容。

ISUCON11に参加した

isucon.net

一人参加だったとはいえ、かなりのいきあたりばったり感で進めてよくなかったなーと後で反省。

それでもDBサーバを別サーバへ分離したり、インデックスを貼って行ったり、クエリのやり方を変えたりする程度でも初回ベンチより倍以上のスコアが出てちょっと嬉しかった。

事前の準備が全然できていなかったので、直前に『Software Design 7月号』を片手にISUCON10予選問題を少しやった程度で突入してしまったけど、過去問を2〜3回解いてからチャレンジしていればまた手数も変わったんだろうなぁって思った。

そういう意味では基本に忠実にやるだけでもスコアが上がって、その先に色々な方法でスコアを上げる選択肢が有る、奥の深さがISUCONの魅力なんじゃないかって思った。素直にリアルな課題に向き合った結果がフィードバックされて問題が作られているのがよく分かる。だからみんなISUCONの問題は解いた方がいいって言うんだなって改めて実感した。

あと、やっぱり8時間という時間が全然短いし、緊張感が凄まじい。途中全然他のことに気が取られなかった。

また、問題を解く環境としてのホスタピリティというか、気持ちよく、スムーズに競技に参加できるようにするためも環境整備が凄まじくて、競技環境のセットアップとかマジでよく作り込まれている。あの運営ノウハウだけでも凄まじい価値が有る。

本戦にはほど遠い点数だったけど、ぜひまた参加したいな。

『入門 老眼』の出版が待たれる

計画の解像度を上げていく

2021/8/15: 最初の言説のところ、微妙に何が何だかって記述だったので少し見直しました。


システム開発は最後まで分からない、常に変更が続くのだ!だから詳細な事前の計画は無意味、やってみないと分からない!」という言説があり、まぁそうだなーと思う反面、個人的な活動ならばそれでいいけど、それなりのステークホルダーが存在する事業の場合は、「見通し」が無いと投資できませんって話にもなる。

結局計画である以上は常に未来の不確定さに、一定のリスクがあるわけで、「完全完璧な計画を求める人」も、「やってみないと分からないと言う人」も、どっちもその不確実さが自分に降りかかることを忌避して、リスクコントロールをしない人にも見える。

アジャイルは無計画ではなく、「計画をするタイミング、詳細度」をコントロールする方法論だと理解していて、「Perlがスコープをコントロールする言語」なのと同じくらい直感的でなく、一回やってみないと分からないけど、非常に実務的な発想だな、とも思う。


少し話は変わって、「その日やることをその日計画する」のと、「その日やることを前日までに計画する」では同じ計画でも意味合いが違ってくると思っていて、「その日やることをその日計画する」というのは得手して「やれることをやる」に陥りがちになる。一方で「その日やることを前日までに計画する」は、「やるべきことをやる」がやり易いやり方だと理解している。

それは計画に対する解像度の違いで、「やれることをやる」の場合、ゴールに向かうために、抜き差しする要素が限定されてしまうのに対して、「やるべきことやる」の場合、要素の抜き差しができるからだ。つまり、「余計なことはやらない」。

「余計なことはやらない」と言っても、単純に「止めちゃえばよかった」なんてことはあんまり無くて、「止めるなりの準備や、調整」が有って初めてやめられる。「止めるために新たにやらないといけないこと」が出てくるわけで。


計画の粒度、どこまでできていれば納得するかは、極めて個人の経験や資質、組織文化に由来することなので、絶対的な正解が有るわけではないけど、「計画の解像度を上げていく」という行為に意識的になっていくといいんじゃないかと思った全然まとまりの無い話。


追加