紙の技術書を開いたままの状態にして、参考にしながらコードを書きたい時ってありますね。ただ、本を開いた状態にしておくのが結構大変です。ブックスタンドなどもありますが、けっこう大きいし、持ち運びには向いていないです。
そんな時には、ステンレス製のクラスプ クリップがおすすめです。ペンケースにも入るサイズなので持ち運びもできます。
(写真の本は、最近読んでいる『Learning Go』です)
紙の質にもよりますが、150ページくらいまでは止めておけるし、それ以上のページになれば自重で本全体は開いたままの状態になるので、めくれないように手前のページを数ページ軽く挟んで押さえておけばいいだけです。
一番大きなサイズでも275円なので、試しに買えるレベルなのもオススメの理由の一つです。
ブックスタンドみたいに立てかけて見たい場合は向かないですが、ちょっと押さえておきたい、という用途にはいいと思います。
「何もしていないのに、壊れました」から「何もしていないから壊れました」に時代は変わりました、という話をしました
— magnoliak🍧 (@magnolia_k_) 2022年6月24日
と、書いてみたのだけれど、本当にそうなのだろうか。
今までだって本当に”何もしないのに、壊れずに使い続けられていたのか？”
その見える部分が変わった時に違和感を感じているだけだったりしないですか？ あの手この手で、全体の挙動を押さえている人を雇用継続することで、維持できていて、そのためには知らず知らずのうちの不断の対応が有ったんじゃないでしょうか？
ということを、真夏のような気温の夜に考えてみました。
ぜひ感想をお待ちしております。
A Tour of Goにチャレンジしたことがあるくらいで、Goをちゃんと勉強してこなかった。
さすがに、ISUCONの問題がGoが最初に作られている時代に、やっぱりちゃんと学んだ方がいいかなと思って、買ったまま積んであった『Learning Go』を読んでいる。
Go固有の、キャッチーな所を先に説明するようなことはなく、淡々とリテラルから始まり、制御構造や、struct、goroutineなどの解説に進んでいくので、あまりつまみ食いしながら読む感じでもなくて、１週間くらいかけて最初から最後まで読む、みたいなスタイルの読み方の方が良いかも。
随所に機能の経緯や、背景、他の機能との関連が差し込まれていて、単に機能解説書になっていない点もよかったです。
”プログラミング自体”への入門本ではないので、最低限一つは他の言語で一通り書けるくらいのスキルはないと読みこなすのは難しいのと、演習問題が無いので、学んだことの確認がしづらい、みたいなところはありますが、他にGoで書かれたコードの事例を見ながら一緒に見ていくとか工夫が有れば、このくらいの記述量で十分ですね。
年に一度のお楽しみ、設計ナイトを6/14に開催しました(去年はお休みしてしまったので、2年ぶりの開催でしたが)。
今回のテーマは「トランザクションスクリプト」...マーチン・ファウラーさんの「エンタープライズアプリケーションアーキテクチャパターン(PoEAA)」で紹介されたアプリケーション構造に関するパターンの一つです。
当日の資料もアップされています。
今回珍しく(?)、『トランザクションスクリプト起点の開発は、“なぜ”生まれるのか？』というタイトルで、登壇もしました。
スライドはちょっと当日のコンテキスト次第なところもあって、そのままアップしてもアレなので、割愛しますが、要はトランザクションスクリプトって”分かり易い”んですよね、という話をしました。
ユーザーからヒアリングしたユースケースをそのまま機能に写像し、機能単位に実装する要員をアサインできると、”分かり易い”ですね（誰にとって？） しかも、よりたくさんの人を同時並行でアサインできる
ドメインモデルや、共通設計を最初に作り込めば作り込むほど、コミュニケーションパスが増加し、相互の影響によるアジリティの低下が有るよね、という流れで話をしました。
それが良いか、悪いか、現代に合うか否かは別として、現実そこに存在する「価値観」は否定しすぎてはいけないのではないかな、と。
何かの意思決定は、何らかの価値判断に基づいて行われるものなので、それが何なのかは常に考えておくといいですね
過去・現在・未来における普遍的な話ではなく、環境の変化に伴って価値観が変わってきていて、変化の方向性としてはそっちだなっていう
— magnoliak🍧 (@magnolia_k_) 2022年6月12日
トレードオフの関係にある二つの選択肢が有った時に、そのメリット・デメリットは、技術や環境（ビジネス環境や、コスト構造）の変化と共に変化していくので、「○○は何年も前に通った道だ、結論は出ている」とはならないなーとかなんとか https://t.co/JwQY3VDrx0
— magnoliak🍧 (@magnolia_k_) 2022年6月12日
環境の変化で、その二つの選択肢のどちらか？という課題設定そのものが消失している可能性だってあるしね
— magnoliak🍧 (@magnolia_k_) 2022年6月12日
それはもう主要な課題じゃないので、どっちでもいいです、みたいな話はあるよね https://t.co/sLKrP5Udd7
ということを、しんぺいさんのツイートを読みながら考えた。
ソフトウェアエンジニアは、コードを書いている時間よりもずっとコードを読んで理解しようとしている時間の方が長いとはよく言われるけど、ここから言えることのひとつに、「修正箇所がひとつで済むけれど、その修正箇所が影響を与える場所の特定にはすごく時間がかかる」よりも、
— しんぺいくんさん (@shinpei0213) 2022年6月11日
「修正箇所は複数あるが、それぞれの修正箇所が影響を与える場所は明確である」のほうが優れている、ということがありそう
— しんぺいくんさん (@shinpei0213) 2022年6月11日
つまり、理想的には高凝集疎結合を目指すべきであるが、「低凝集だが疎結合」と「高凝集だが密結合」だったら前者の方がマシなのでは、という仮説
— しんぺいくんさん (@shinpei0213) 2022年6月11日
何に価値が有ると見做されるか、というのは極めて流動的なもので、絶対的な真理、みたいなことは無くて、だからこそそこに期待と実態の差異から発生する驚き、みたいな話が出てくる（良い・悪いではなく）
— magnoliak🍧 (@magnolia_k_) 2022年6月12日
だって、差異が有るってことは、相手も差異が有ると思っているわけで
— magnoliak🍧 (@magnolia_k_) 2022年6月12日
すいません買ってきたばかりで、まだ全然読んでないんですけど、これが言いたかったので、エントリを作りました。
買ってきた、ご利益（予選参加できる）あるかなぁ… pic.twitter.com/GGqJb4tVrI
— magnoliak🍧 (@magnolia_k_) 2022年6月10日
ご利益がありました！（予選参加登録できた！） https://t.co/f8rfv5ZGoi
— magnoliak🍧 (@magnolia_k_) 2022年6月11日
あと、冒頭の第1章のメッセージがめちゃめちゃ良かったので、引用しておきます。
あと、何と言っても、Webサービスを高速化できるエンジニアはかっこいいと思いませんか。高速なWebサービスを実現する、パフォーマンス問題をバシバシ解決する、パフォーマンス問題を起こさないシステムを実現できるエンジニアに筆者は憧れますし、尊敬します。
「こんな小さな売り場の本屋だと無いかも...」と思いながら、ぱっと入った本屋にも置いてあったので、けっこう幅広く配本されているようです。とにかく近くの本屋へ行って買いましょう。
この手の本は、読み終わったら誰かに貸したくなったり、あげたくなったりするタイプの本なので、紙の本で買った方がいいんじゃないかと思います。
今年参加登録できなかった人も、来年に向けて買っておいて１年間素振りして、臨んでいきましょう。
今年参加登録できた人は、もう１ヶ月後なので、さっさと素振りしましょう。
データとコードと運用のそれぞれの時間軸を総合して初めてビジネスドメインが完成すると思っている
— magnoliak🍧 (@magnolia_k_) 2022年5月24日
ドメインに関するコードのテクニックの話の時に、同時に運用やデータの話がセットで語られないのはいつも違和感が有る...実際の開発だと常にセットで語ってない？
