素人になりたい

「自分はプログラマとしてやれてきただろうか」というと、それはそうだろうなと思う。実際、そうやって税金を払い続けてこられているのだし。
ただ、それでも満足はしておらず貪欲さは持ち合わせており、「もっと周りに影響を与えるようなプログラマになりたい」「深い思考と美しい説得力を持ちたい」などと思っていたりする。自分の中での「ちゃんとやれている」を持ちたい。

どういう状態になれれば、この先も生存していけそうか?というのを考えて現時点で浮かんでいる大まかな方針は2点。
なお、これらは「今後も未来永劫変わることのない黄金律だ」というものではない。今までの長期スパンでの経験や直近数ヶ月足らずに見聞きした自身の経験・・・そういったものを足場として導出した「仮説」に過ぎない。常に検証と批判に晒し続け、適宜アップデートしていくこと。

  1. インプットとアウトプットの量を増やす主体は自分である。他人に甘えたり依存していると限界がある
  2. 自分のやる気が落ち込むのは周りとの折り合いが悪い時。他人を障害点とするのを避けるために、自己とチームのために動く

ここ数年を振り返ると、敢えて強烈な言葉で叩きつけるならば、「凄く傲慢で天狗になっていたな」と思う。
それは環境がそうさせた部分もある。 自分より上手くPHPを書く人間がいなかった という思いが、自分の中の権威を増長させてフラストレーションを爆発させた。
もちろん、世界にはまだ、遥かに先を行く人や強靭な知識体力を持つ人がいる。世界、といっても何も遠い大陸のことを想起しているのではない。同じ言葉を喋り同じタイムゾーンで暮らし、同じ電車を乗る人の中にですらそれは居る。

なのに自分は何をこんな所で停留しているんだろう、そんなおかしな話があるのか?という想いから、居る環境を変えた。
実際、新しい職場では何度も衝撃を受けた。思ったとおりだ、凄い人がいる。そういう人たちと同じチームに受け入れられたのは、自分にとって誇りだと思っている。
感嘆したのは彼らの「案の定」の知的で深い思考だ。なんでも知ってる、随分とかっこいいものを作る。それができる強力な力を持つ。
が、それにも増し、何よりショックだったのは、その人達は「とんでもなく勉強している」ということだった。暇があれば本を読んでいるのか?いや、暇でなくても本を読んでいそうだ。しかもそれを咀嚼し、体系化しているのか?
恐らく、常に課題や疑問を持ち続け、そこに対しての解を自力で探求し続けているように見えた。単純に言うと「気になった本があったら読んでみよう」だ。学ぶことに対して手をこまねいたりしない。

なるほどな、自分は「何かを考えている」ようで、全然その足元にも及んでいないな、と思った。ここまでやれてきたつもりだったのに、ショックだった。
技術や研鑽の話で、「一生懸命やる」という事は、した試しもあるし出来る自信もある。「プログラマとして雇われ、たくさん働いたことがある」というのが自分にとってのそれ。把握できている(手元に記録が残っている)だけでも月に380時間ちょいほど働いたこともあるし、恐らく400時間を超えている時もあると思う。
それは鎖自慢・・と確かに大差ないが、ただ「我武者羅にやったことがある」というのは自分の力を養成するのに間違いなく与した。それによって身についた実践知は今を作っている。良い未来を持ってきてくれた。

そうやって、会社や職場が「自分を伸ばしてくれた」と思っている。
別に何かを講義してくれたり指導してくれたという話ではなく、壊れたピッチングマシーンのごとくただただボールを放ってくれた。永遠に打席に立つことを繰り返してきた。
そういう経験があるから、自分が凄い人になるには、「凄い珠が飛びかっていそうな環境」に行くのが正解だろうと考えた。それが、自分の選ぶべき道だと。

しかし蓋を開けてみれば、「どんな球が飛んできているかは関係なく、凄い人は凄い」のだ。
別に過去に書いた話が間違っていて、嘘だったとは思っていない。「プログラミングやエンジニアリングについての向上心があり、それをプロダクトに反映できる事」も「 一緒に働くメンバーや社内にいる人から技術的な刺激を得られる事」も重要だ。
ただ、自分より凄い人が居る環境に行けば「その空気を吸うだけで僕は高く跳べると思っていた」ような面はあったかも知れない。
確かに、そういう人らがグランド・デザインから関わっていて思想が毛細血管のごとく隅々まで張り巡らせている・・・という場に立てれば、普通に仕事をしているだけでも得るものは多いかも知れない。だが、「凄い人がいる」 = 「その人達の思想や思考が浸透している」ではないのだな、と知った。
問題は、「そうではなかった」のに、ちゃんと武器を持ち強みを磨いている人がいるということだ。その力こそ、自分の成長を保証するものではないか・・?

改めて、「みんな素人」という言葉の意味を知った気がする。
この数年、「CakePHPを上手く使える」という自負が、いつのまにか自身の殻となり首を絞めていたなぁと思った。「俺はもう素人ではない」という傲慢さだ。
選んだ会社のスタックがCakePHPだったからこそ、「自分は全然通じる」と「それだけでは物足りない」と「会社から与えられたものに規定されていては駄目だ」というのを味わえた。
職場環境や自チームの力が、自身の成長の天井になっていると考えて転職した先で、自分の天井を破れていないのいは自分のせいだと思い知らされる・・という結末になったのは何とも皮肉ではあるけれど。

どうやって自分を伸ばすか・・・やっぱり「素人になり切れるか」ということだ、と感じている。
自分は実践から学ぶ。高校も大学も座学のほとんどには退屈していたが、受験勉強とかレポート作成とかの「独学」のターンになった瞬間に、これは自分のフィールドだと感じた。そもそも、プログラミングを始めて企業から雇われるに至るまで、それには「野良プログラマ」としてやってきたのが自分の成長の源泉だった。
自分は実践から学ぶ、そうである以上は手を動かし続けることを自身に課さなければならない。座学や与えられただけの教義には感動できないのだから。ただ「未熟なことをやるのが怖い、恥ずかしい」?なら「プロ」なんてやめてしまえ、素人に戻れる方が遥かに逞しい。

前職で終盤には上司になった人の話が、今読み返してみると凄く良いと感じた。
30代から始めるwebフロントエンド入門 - Speaker Deck
あるいは、初めて読んだ時から強烈に感銘を受けた記事。
移住することにしました | NEW GAME @kunit

かつて野良プログラマだった何でも出来る(出来ない)自分との差分として、今だからこそ一言だけ加えれば、「須らく必要なことだけ学ぶ」というのを改めたほう良い。その態度は、「今やれているから、そんなに必死に学ばなくていい」を連れてきたと思っている。歩幅の大きな一歩を進めようとする時に、頭を使う必要はあるが賢くあろうとする必要はない。
自分が目の当たりにした「凄い人」の「凄さ」は、学びの姿勢にあった。圧倒的にインプットしているし、そうやって考えるべき視点・考え方を取り入れ更新し続けているからこそ、彼らには今の凄みがある。
もちろん、他のタイプでドンドン道を歩み行く人もいるとは思うが・・・ただ、1つ言えるのは、「凄い人にあって自分にないもの」が見えたなら、自分の天井を打ち破れる可能性がある。今はその事に気づいてワクワクしている。自分は実践から学ぶ。なので、こんな面白そうな事実に気づいたからには、試してみたい。

「素人」になることの最大のメリットは、学ぶことに対してオープンになれることだと思っている。
今更これをやってみて、またLv.100まで持っていくにはどんな果てしない時間がかかるんだろう・・とか。既にこんな武器を持っているのに、こっちをやってみても、自分が提供できる価値ってのはそこじゃないよな・・とか。
「使い物になりそうなことをやる」「もっといえば、プロなのだから、自分の持ちうる価値を最大化する方が良いし求められている」なんて考え方が、新しい世界を阻害する。学ぶとは本来、かっこ悪さや恥を恐れない姿勢なのだ。
「凄い人になるには凄いインプットを食い尽くすことだ」と気付いたのだ、そのためには素人になる必要がある。謙虚に向き合う必要がある。

なんか、色んな意味でやり直しだな〜・・・と感じている。
「チームを良くする」みたいなのをやり切れず、逃げてきたはずだったんだけど、今ならそれもやってみたい気はするなぁ。

自分は常に無知であるというスタンス

散々言い尽くされて陳腐化している事かもしれないが、「自分は無知である」と自覚していることは謙虚な振る舞いに繋がるかも知れない。

まず普段の生活において、自分より上手い人・詳しい人に対しては「丁寧に接する」というのは違和感ないと思う*1
例えば部活など、先輩に対して横柄な態度を取らないようにするのは「目上だから」というのを差し置いても、自然と心から「教わりたい」と感じる部分もあるのではないか。

もし自身がプロフェッショナルとして扱っている分野でも、往々にして「無知である」ことは重要だと考える。無知の知というのに繋がるかも知れない。

例えば、利用している言語やフレームワークについて、知れば知るほど「主語がデカい」ような批判はしなくなる。
1つのWeb FWだけを使っただけで「MVCはファットモデルになりがち、だからイケてない」というのは、もしソレが客観性を持って真実にかすってはいれど、「芯を食っている」という事にはならないかも知れない。
「○○がダメだ」と言った場合は「自分が○○について理解していて、使いこなしている」という事に胸を張れるか?そう思うと、必ず不安はつきまとうのではないか。その結果、「こういう使い方をしたいので、こういう書き方をしているが、そうするとああいうアンチパターンを誘発する」など、情報の解像度を高めるようになりそう。
多くの場合、欲しているのは個々人の要求(これは自身の中にしか無い)とその実現方法である。「Aという機能を使うこと」自体ではないだろう。なので、もし「無知である」ことを自覚していれば、「描いているユースケースに対して、そもそもAを使うのが適切なのか?」というところを疑ってみるところから始まる。結果的に、「Aを悪者にする」ようなコミュニケーションを行うことがなくなる。

謙虚さとは「自らより他者から学ぶことを是としている」という姿勢だと思う。
そのためには「他者と極力正確なコミュニケーションを取るようにする」という必要性が生まれる。客観的な、独りよがりではない発話だ。相手の存在を意識した客観 = フェアであるということ。

どれだけ「フェアになれるか」は重要な能力だと思うので、私はどんな時でも「無知である」ということを始発点としていたい。

*1:接する相手に態度を変えるな!!という話は別としてね

「エリック・エヴァンスのドメイン駆動設計」と「ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本」を読んだ

読み終えたんす

元々、Clean Architectureを読んだ後に読むぞ〜〜!と思っていた本として、エリック・エヴァンスのドメイン駆動設計を想定しており。
ってことでReal World HTTPの後に(発売日を迎えてホヤホヤのモダン・ソフトウェアエンジニアリングを間にはさみつつ)、週末を中心に読み進めてたら5/23-6/16・・・と1ヵ月弱、なかなか苦戦しながら読み終えた。*1

また、「まずこの本を読んで、多分難しくて理解度が低いだろうから、間を置かずに次はコレを読もう」と決めていたのが 「ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本」。

ひるがえってコチラは、昨日読み始めてサクサクと進み。今日には終わったので、とても読みやすかった印象。
「こんなに日本語の本を読むのが遅くて大丈夫なのか自分。。」と凹みかけていたので、リハビリではないけど、読める本はちゃんと読めるんだな良かった!とも思った。

ということで、一段落したので #phpgenba のエピソードを復習しながら読書メモをまとめてみる。*2 php-genba.shin1x1.com

読んで見る順番としては個人的にはこれで良かった

最初にDDD本を読んだよ

最近は「まず原典にあたる」のが正しいスタンスかな〜という風に感じており、それもあって"まずは1番難しそうな"本から取り掛かった。
ということで、「エリック・エヴァンスのドメイン駆動設計」だ(長いので、以下「DDD本」)。

恐らく、「原典」が最初にあり(もしくはターニングポイントとなるくらいの爆発力をもたらしており)、その後に出た「解説書」「攻略本」というのは、その著者の大いなる編集力によって情報が微分&クローズアップしているものでは?と思っている。

当然ながら、その様な後発本が出るのは「オリジナルが難解だから」という何よりの証左だとは思うし、初手でそこに当たるのは高コストだなという風に感じる。

なので、目的としては「理解して血肉とする」や「高解像度なインプットを得る」という風に設定せずに、「地図を広げる」というところを意識している。具体的な道筋やどこにどんな建物が立っているか?までを正しく理解できる事は望まず、「なにをどこまで取り扱っているか、どのくらい風呂敷が広がっているか」の感覚を得られればOK〜というもの。
重要な概念はその登場頻度によって「感じる」ことができるし、朧げでも話の流れを追ったり逆に1発で理解できる箇所もあるかも知れない。そうやって、頭の中に薄いINDEXを作るようなイメージ。
(ちなみに、これによって出来ることの1つとして「索引を眺めるだけでも目に入る単語が増える」し「気になったページを読みに帰ることが出来る」というものがある。何となく、1回とりあえずクリアしたRPGのような感覚がある。行きたい町に好き勝手に戻れたり、取り逃したアイテムを回収しにダンジョンに戻ったりね)

これが、自分が「まず1回は原典を読んでみよう」というモチベーションを持っている理由だ。

実際に、今まで何となく耳にしたような言葉たちは「単語の定義としては」レベルで言えば説明を得ることが出来た。
ドメインモデル、ユビキタス、境界づけられたコンテキスト、値オブジェクトやエンティティ、知識の蒸留・・・これらに「耳馴染み」が出来た。

読み切るのに相応の時間を費やしたことになる。
が、ここ最近は「インプットに掛ける時間・量を大事にしていこう」と決めているので、多少コストが高かろうと意味の有りそうな順番を求めて読む本を決めていこう・・というのが自分の中では重要。

次にDDD入門を読んだよ

(実はかなり最初に買ってたんですよ)

その一方で、追っかけて読んだ「ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本」(長いので、以下「DDD入門」)については、やはり「物足りなさ」を感じるかなというのは正直な所。

が、決して「だから良い本ではなかった」というものではなく、寧ろ目的を履き違えなければ「見事な本だった!!」という感想。

何が「物足りなかった」かといえば、「ちゃんと削ぎ落としてる」という部分だ。
DDD本の難しさの1つはその抽象さにあるように感じており、それは「組織の形とコミュニケーション、コミュニケーションと実装、アジャイル開発やイテレーション」というとても広大な範囲を扱っている事に良く現れているように思う。・・これをワンストップで解決しようという「DDD」のコンセプトはやっぱマジやべぇな、となるのだが。

一方で、DDD入門はこの「難しさ」に立ち向かった。自分の感覚では、極めて「コードに近い位置」に軸足を置きながら話してくれているのがこの本の「優しさ*3」だ。
DDD本は「どうモデリングしていくか」という点に常に脳みそのリソースを30%以上喰われている感覚があったが、DDD入門は基本的に「どういうコードになるのか」に終始しているのではないか。

本書中で「ボトムアップドメイン駆動設計」という概念に触れており、まさに「"具体"や"卑近"から、着実に一歩ずつ積み上げていく」という読書体験に近い。

本書のアプローチもまたボトムアップです。ドメイン駆動設計の構成する要素のうち、もっとも根底にあるものからひとつひとつ解説してきました。そして、その解説自体も、トップダウンにそれが何であるかを紹介するのではなく、必ずそこにある問題を提示し、紐解く作業を添えています。本書はドメイン駆動設計のパターンを伝えると同時に、その実践の手本として、新たな知識との向き合い方を伝えているのです。ある知識を得るために、前提となる知識が必要となることは多くあります。なるほど知識は連鎖するものです。ボトムアップに知識を積み上げていけば、必ずや理解へ到達することでしょう。

成瀬 允宣. ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本 (Japanese Edition) (Kindle の位置No.5427-5432). Kindle 版.

あるいは、「はじめに」から引用すると「モデリングはいったんさておき」というスタンスだ。

そこで本書はモデリングについてはいったん棚上げにして、具体的なコードをベースにパターンを集中的に解説し、全体を通して最終的なコードを提示します。どこかへ行こうとするとき、目的地がわからないということはとても不安を覚えます。本書が提示するコードは明確な形をもった目的地としてあなたの道しるべになるものです。

成瀬 允宣. ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本 (Japanese Edition) (Kindle の位置No.49-52). Kindle 版.

DDD入門はどんな本でした?

まずは「読みやすい」本だなぁ〜(ありがたい〜〜〜!!!!)という感想。
他方で、全く未学習の状態からこの一冊で「DDDは何かという肌感を掴めるか」というと少し不足があるかも知れない。

「なぜDDDをするのか」という部分、第1章で取り扱っている内容が「軽い」かも?と思ってしまった。・・・これはDDD本を先に読んだから、かも知れないけれど。
そういう意味では性急に「本題」に入ってしまっているのか?とも。それによって「抽象的でわけが分かりにくい話」を掻っ捌けているので、一冊の本としてのバランスは良いなぁ〜と感じているのだけど。
その辺りは、何か別の文献(web上に「DDD入門」みたいなものがあるかも知れない。探してみると。)で補ってからこの本に入る、という準備が出来るといいのかな〜

視点を変えて、「どういう人が読むといいか」「読むことでどういうことが期待できるか」という点。

前者については、自分のように「DDD本をとりあえず読んでは見たものの」もしくは「読もうとしたけど挫折した人」などはまさに。その他には、「DDDというものに向き合う必要が出てきている、が、いまいち理解できていない・・・」という人など。 難しい単語たちを優しく説明してくれてるのは間違いないので。

後者の方に関して言えば、「とりあえずDDDで書かれたコードを読めるようになる」というゴールが近いように思う。「自身が先導してDDDを導入したり土台のデザインをする訳ではないが、チームとしてDDDを採用しているメンバー」などはドンピシャなのではないだろうか。明日から働きやすくなるんじゃない・・・?って気がする。

例えば目次を見てみると、この本が「いかに具体的・現場的な問題を取り扱っているか」という意志が匂ってくるのではないか。
特に端的に顕れている(と感じる)前半部分の章立てを引用する。

  1. ドメイン駆動設計とは
  2. システム固有の値を表現する「値オブジェクト」
  3. ライフサイクルのあるオブジェクト「エンティティ」
  4. 不自然さを解決する「ドメインサービス」
  5. データにまつわる処理を分離する「リポジトリ
  6. ユースケースを実現する「アプリケーションサービス」
  7. 柔軟性をもたらす依存関係のコントロール

すごくないですか、「モデリング」や「コミュニケーション」から焦点を外したDDDの解説は、こんなにも足早に実装的な話に入れる・・・・DDD本だと「値オブジェクト」「エンティティ」を主題として取り扱うのは、第2部:第5章「ソフトウェアで表現されたモデル」まで時間を要しているというのに!

このアプローチの違いから、「自分自身が率先してDDDをやっていくという立場」には不足でも「DDDを採用している現場のいちメンバー」に薦めるには充分に有用性があるな〜と感じる次第。ゼロからデザインをするのは厳しかったとしても、他の人のコードを読みとったりソコに乗っかってコードを書いたりはできそう、という印象。

良い塩梅だったなぁ〜〜〜と思った。

読了後に読んだ筆者の「あとがき」を見ると「どういう本か」は伝わってくる気がする。

nrslib.com

あとはなんだろう、コードがC#だけどソコは自分的には全く問題なかった。
変に擬似コードを使うよりは(実世界のコードだし)洗練されているから良いし、本書に出てくるサンプル程度であれば言語の癖みたいなのも感じることはなく「オブジェクト指向だと大体こういう雰囲気じゃんね」というノリで読めたという感じ。

DDD本は難しかったネ^^

読むのに骨が折れた!読みにくくない??そうでもないのかな・・

やはりDDDに関しての肌感みたいなのを持っていない状態で挑戦するには強敵だな、と。
とはいえ、これで世の中にあるドメインが〜とかユビキタス言語って〜みたいな議論に付いていける土壌を耕せたと思えば、非常に価値があるコストだったと感じている。スタート地点に立てたはず・・・

もちろん、全くわからない!!何もわからない!!と終始叫びながら900ページ弱を読んだわけではないので、新しい知識もそれなりに入ってきたつもり。

  • 今まで「ドメインモデルを隔離するって一体なに??」という状態だったのが、言わんとしている事が分かった気がする
    • Clean Architecture(もとい、フレームワークやインフラ層を「些細なこと」として扱うような態度)での「本当に守りたいものは何か」を記述していくとこうなるのか、という感じ
    • これらについては、徹底的な(実装パターンとしての)DDDを採用しなかったとしても、着眼点として持っておくことは出来そうに感じた
      • 例えば仕様の隔離や誰がどんな責務を持つか、制御の流れをどうするか?など
      • DDDというかOOPで達成されるべきことについて、自分の中での練度が上がったかも知れない(勘違いの可能性もある^^)
  • 先行して概念だけ(何となく)知っていた「ユビキタス言語」、それ自体とても便利そうなもの〜という認識だったが、「ここまで徹底的にやるのか」といった感じで、確かにそうすると抜群に効果が出そうだな・・・という気がした
    • 例えば何かのIssueやPRのdescriptionを埋める時、もしくはインラインコメントを書いたりレビューをしたりする際の思考態度が変わる
  • アナリシスパターン is 何・・・
    • これはまた何か本を読んで知識を蓄えた方が良いのだろうか
    • もしくは、これに限らず「どう分析してモデリングしていくか」みたいな技法は知りたいと感じる。アナリスト的な機能なのかな、と思うが。
      • それらを無くして「どういう風にしたら良い設計たり得るか」については語れないのでは、、、、、という気がした
  • しなやかな設計 はメチャクチャ良い概念、好きぃって思った

↓ 好きだなぁと思った箇所。リファクタについて

  1. 困った時のリファクタリングをする際に、原因がコアドメインかコアと補助的要素との関係を含むものかどうかを調べる。そうであれば、歯を食いしばって、まずそれを修正すること。
  2. 自由にリファクタリングする余裕がある場合、最初に集中すべきなのは、コアドメインのより適切な括り出し、コアの隔離の改善、補助的なサブドメインから不純物を取り除くことによる汎用サブドメイン化である。

Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (Kindle の位置No.8807-8810). Kindle 版.

(DDDに限らず)往々にして、「リファクタをすべきか、そのままでいいか」「どうしたら成功するか」みたいなのは判断が難しい所。
カッとなってやった!!!という時にコードを書く瞬発力は上がると思っているが、気分駆動でやった問題は精度の面でブレが怖い。「時間取ってリファクタしてみたけど結局なにも良くなってないじゃん」というのは良くあるし、「よく出来ると思ったけど挫折した」も同等かソレ以上にあること。
なので「何故やるべきか」の尺度はあるに越したこと無いよね〜!と感じる。

アーキテクチャは方針」であるのだから、設計思想やパターンに密接に関わっているDDDの目指すものが、自ずと「リファクタリングかくあるべき」と語り始めるのはとても自然なことだなぁと感じる。

この後どうする?

まだまだ「薄く広く、全体的なINDEXを作ってみた状態」だと思っている。なので、この後には「脳みそのシナプスをつなげる」「より具体-抽象を結びつけながら、自身の持つ解像度を上げていく」ことが必要だという感じ。
とはいえ、概念的な部分についてはDDD本が一通り抑えてくれているだろうな・・という信頼はあるので、あとは「馴染んでいく」という部分だ。

DDD本が難しかったのは「もう少し具体例・実践例を知りたい」という所があり、あと「会計がさも分かりやすそうな例として取り上げられてるけどあんまり馴染みがなくて・・」「流通もゴメンナサイ・・・」という気がしたので、より実践的な話に触れてみたいと感じている。

ということで、これを読んで見る。

実践ドメイン駆動設計

実践ドメイン駆動設計

高いなぁ買うの日和ってたんだけど。2冊読み終わった勢いでポチったので・・・・・

なんとなく「1度読んだ本」はその後も行き来してパラパラと開きやすい気がするので、実践DDDを読みながらリファレンスとしてエリック・エヴァンス先生にもお話を伺いに行こうかな。

あとは、少し自分でも手を動かしてみたいよな〜。MVC&ActiveRecordなFWとも組み合わせられるかな?
CakePHP4を用いてDDDの実践、みたいなのをやってみたい気はする。

例えばshin1x1さんのサンプルを見た時、とても「cake的じゃない」と感じた記憶があるのだが、今見たらもう少し深く理解できそうかも知れない。
(とはいえ、今のところはやっぱり「折角cakeでやる旨味」みたいなものが薄そうかな〜という印象は持っている。コレが喰わず嫌いでしかないのか?は確かめてみたい。)

github.com

あとでよむ

少し復習してみましょう、くらいのノリで読みたい nrslib.com

*1:別のこの間の週末を全てこの一冊に費やしていたわけではなく、並行して読み進めている本があったり、趣味コードを書いたり諸々もあったんですよ!!という言い訳

*2:当日は会場で聞いていたが、壁の裏から漏れ聞こえてくるうずらさんの存在感が凄かったのを思い出す度に笑ってしまう

*3:「易」ではなくて

CakePHPのアップデートなどを眺めてる

Slackだったりメールだったりで、CakePHPの更新情報を適当に眺めてたりするのですが。

↓メールはこんな感じ f:id:o0h:20200612150628p:plain

観測してるのは、cakephp/cakephp, cakephp/app, friendsofcake/awesome-cakephp 辺りです。
タイトル見て気になったものとかはチラっと見に行ったりしています

で、折角ボーッと眺めてるなら簡単なメモとか気になったこととか書いてみていくのも良いかな?と思いました。

必要なのは

  1. 情報収集をやってほしい
  2. 拾った情報にリアクションしやすくしたい

というところなので、

  • 1については
    • 対象レポジトリのRSSフィードの購読をしてくれて
    • 個別のPR単位で「新着情報」「既に何か書いた」みたいなステータス管理できて
  • 2については
    • ポチ〜っとPRを押したら対象情報を取り込んでくれた記事作成が出来て
    • マークダウンとかの手軽に書ける感じ

みたいな事が出来ればよさそ〜って思い。

CakePHPアプリケーションを何か(ちゃんと使うやつ)ほしいな、と思ったのでサクッと作るのが良いかなーなんて気がした。

やろうかな〜

やったこと・書いたもの{2020,05}

OSS

github.com

cakephp/appには初めてのPR作成(多分)。
最近はエイゴ・テキスト・コミュニケーションを完全にDeepLに委託し始めた、煩わしさが減った。
(そもそも、抽象的な実装とか設計のblueprint的な話なんかじゃなければ、英文の内容あまり気にしなくていいよな〜という気はしていますOSS活動において。)

github.com see also: Connehito/cake-sentryのCakePHP4対応を終えた - 大好き!にちようび

勉強会・LT

その他

「モダン・ソフトウェアエンジニアリング」を読んだ

たまたま代休を取っていた5/29に発売だよ〜という事に気付いて嬉しかったので、積ん読消化順を差し込んで読んだ。
書籍のタイトルと翻訳者の名前を見て即買いした次第。

  • どんな本でしたか?
  • こんな人に良いんじゃない?
  • 読後の感想
  • 内容に関するメモ
  • まとめ
続きを読む