Techいつもコードのことばかり考えている人のために。単行本この商品を含むブログを見る週末のTwitterのTLで「リスコフの置換原則」が話題に上がっていて、改めて色々と学びが有った。Architecture」を読んでないことに気がついて早速注文して、今日届いたので、ずっと読んでた。読みどころとしては...まずは「設計とアーキテクチャ」に出てくる生産性のグラフ!極端な例だとは分かっていつつも、割と直感的にそうだなって思うし、ああゆうふうに数字に出ていない場合は、やはりどこかに無理が生じている(暗黙のうちに、プロセスが省略されるとか)。その次の、プログラミングのパラダイムとして「構造化プログラミング」「オブジェクト指向プログラミング」「関数型プログラミング」を駆け足でまとめている所も、少々強引だなーと思わせる所も有りつつ、振り返りにちょうど良かった。続く第III部で設計の原則について語られる。この辺は最近設計的な発表がカンファレンスでも増えてきたので、そこで聞いたことと照らし合わせて読むとより理解が深まると思います。「単一責任の原則」のように語感から得られる印象とは全然違う原則であることが丁寧に書かれていて、この辺は知識を棚卸しするためにも読んだ方がいいですね。読み終わって思ったことは、「これは一人で読むより複数人で読んで、感想を言い合う、経験を共有し合うきっかけ」にした方が良い本だな、と思いました。この本を深く読み込むことで得られることはきっと有るとは思うんですけど、これを完璧に暗記したら良いコードが書けるか?といえば当然そうではないですし、これだけを信じ過ぎるのも危険です。設計原則はあくまで自分が書こうとしているコードを、何の指針も無く書こうとするとさすがにマズいな!という時に参考にするものであって、それに従えば自動的に良いコードができあがるルールではないですからね。2019次の設計Nightに向けたネタの整理ドメイン知識から、コードへDBの寿命はアプリより長いハードウェアの寿命(5年〜7年)に合わせて全面的にシステム更改を行ってアプリケーションがかなり書き換わっても(もしくは全部違うパッケージに入れ替わっても)、それまでのデータは捨てられることなく、移行しつつ使われ続ける。すると、今のシステムの要件だけでなく、明示的、または暗黙的に過去のシステムの要件が入り込んでいて、それを階層的に理解しないと「データを理解した」という状況に至らないのではないか。アプリケーションはアドホックに改修され続けるコード自体は無くなるかもしれないが、コードが実現していた機能や、たくさんのコードの集合が表現していた「プロジェクト固有の設計原則」「隠れた仕様」みたいなものはずっと残っていく(所謂、現行踏襲)。そのコードだけでなく、あるコードが他のコードへ与えた影響だけは残っていく。歴史は運用と改修の積み重ねデータは運用されることで積み重なり、機能は改修されることで積み重なる。今あるシステムは、データと、コードと、その改修の歴史の積み重ねという3次元で構成されているので、本質的に理解するのは難しいのではないか?で、本質的に難しいと考えて、どうすればいいのか?という事を考えていくわけです。本件について、皆様のコメントを頂けるとうれしいです。本エントリは、BGMに「僕らが旅に出る理由」を流しながら読んで下さい。2019へ参加してきた。builderscon.io特定の言語やフレームワークに特化したカンファレンスが多い中、buildersconは特定のテーマに縛られることの無い幅広さが魅力ですね(自分は見れていませんが、スーパーカミオカンデの発表はかなりTwitterのTLが盛り上がっていましたね)。PHP系のカンファレンスのように、間口が広い分、メインテーマのPHP以外の、設計や開発プロセスに関する話題もけっこう充実してきていて、必ずしもその言語を使っていないからといって最初から対象から外すのももったいないイベントも有ります。その言語、ライブラリに100%振り切ったカンファレンスもたくさんの学びが有ります。(今年初参加だったScalaMatsuriはなかなかのディープなScalaトークだらけで、堪能しました。分からない悔しさが有りました)この手のテックカンファレンス、無料も有りますが、たいていは参加費が5千円から1万円近くはかかるし、けっこう前からチケットを押さえないといけないので、それなりの覚悟はもって参加しないといけないわけですが、それでも参加するのはみんな自分の知見を惜しげもなく公開してくれるからです。ゆう気づきがあるわけです。2019その発表で触れられた知見が、直接今自分の課題につながること無いかもしれないし、実はずっと無いかもしれないけど、それでも「何を課題と捉えたか?」「その課題をどう特徴付けたか?」「その課題を解決するまでの道筋をどうつけたか?」といった話は、絶対に役に立つと思うんですよ。それが一人一人やり方は違うけど、ちゃんと発表できるところまで整理されているって、日常の中ではなかなか無いと思うんですよね。本を書いてる人とか、有名人とかだけじゃなく、普段は全然名前を見かけない人だってたくさん発表していて(むしろそうゆう人の方が圧倒的に多い)、その人たちが「どう考えて、どう行動したか?」って所を短時間でなぞっていけるって意味の有る時間の使い方じゃないかなって思います。合間の時間とか懇親会では直接そのスピーカーに話しかけ放題って考えると、更にお得感が増しますよね。色んな人の思考の過程が辿れる...これが僕がカンファレンスへ行く理由です。みんなテックカンファレンスへ行った方がいいです。単行本(ソフトカバー)この商品を含むブログを見る今年の夏休みの課題図書、「データ指向アプリケーションデザイン」をざっと読んだ。ところどころメモを取りながら進めては行ったけど、さすがに600ページ超えの厚さで全部を同じ集中度では読めなかったので、あまり馴染みのないストリーム処理あたりはかなりの流し読みになってしまった。書籍全体としては分散型のデータ処理基盤を設計するにあたり、どのような課題が有り、現実のソフトウェア(ここが重要!)がどのようにそれを解決しているのか?ということをありとあらゆるテーマについて語り尽くした本。これ以上は、もう実際に運用してみないと分からないレベルだと思う。分厚い本だけど、まずは第一章「データシステムの基礎」だけでもぜひ読んだ方がいい。「信頼性」「スケーラビリティ」「メンテナンス性」という現代のソフトウェアに求められる要素がコンパクトにまとめられている(ここだけなら20ページくらい)。エンコーディングと進化」を先に読むと入りやすいかも。Bufferなどのアプリケーションレイヤーの人に馴染みのある話題が出てきます。夏休みシーズンももう終わりですが、数週間かけて少しずつじっくり読むには最適な本なので、秋の夜長に向けてぜひ読んでみて下さい。annotationが追加された時々メソッドのインタフェースを揃えるために、わざと使わない引数を定義することが有る。Scalatraでもインタフェースを揃えるためにServletのRequestとResponseをペアで定義しているが、必ずしも使っていない、みたいなコードがあり、ビルドの度に未使用パラメータの警告が出てしまう。annotationが追加された。scala.annotation.unusedドキュメントに全然コード例が無いので分かりづらいけど、テストコードにコメント付きで使い方が書かれているので、こちらを見た方が理解しやすいと思います。2.13以降なので、後方互換性の観点からすぐに使うわけにはいかないけど、ライブラリ作ったりする人は知っておくといいと思いました。Classi」での自分の登壇内容がログミーTechさんにて文字起こしされました!logmi.jplogmi.jplogmi.jpブクマも改めて80近く行きました。PD対応のモバイルバッテリー、なぜかAnkerは充電器付きばかりがラインナップされているし、さすがに容量が20000mAhを超えてくるとなかなかの大きさだし、重量だし...ということでこっちを選択。今見ると値段が6000円を超えている...先日まで4000円台だったはずなのに...もう少し小さいモデルだとこっちがある。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。