Magnolia Tech

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

MultiSync LCD-EA271U-BK気になったところ

NEC 27型4K対応3辺狭額縁ワイド液晶ディスプレイ LCD-EA271U-BK

NEC 27型4K対応3辺狭額縁ワイド液晶ディスプレイ LCD-EA271U-BK

  • 発売日: 2018/11/29
  • メディア: Personal Computers

ファームウェアのアップデートが終わり、日常的に使い始めたMultiSync LCD-EA271U-BK。

画質は、非常に良い。今まで使ったディスプレイの中でも最高に良い。ムラも無く、隅々まで明るい。 けど、気になる点も多い。

  • ファームウェアのアップデートをしないと最新のmacOSのType-C接続が動作しない
  • ファームウェアのアップデートには修理扱いでメーカーへ送付する必要がある(着払い)
  • 有効な接続が一つでもないと、なぜかOSDメニューが表示されない
  • 出荷状態ではUSB機能が無効化されていて、OSDメニューから有効化する
  • つまり、Type-C接続しかできない場合、USBを有効にする手段がない!
  • Type-C、HDMIケーブルは付属しない(DisplayPortケーブルは付属する)

色々と不満はあるけど、普通に使い始めると気にならないので、安く入手できるならオススメ。

ただし、そろそろ売り切れで、スペック上はほとんど何も変わっていない後継機が4月下旬に出る。 メニュー周りの不思議な挙動は直っているといいのだけど…

『ドメイン駆動設計』…そもそもドメインに駆動されない設計って有り得るのか?

10年前に初めて読んで、数年おきに読み返すようにしているのだけど、読むたびに自分の中でも感想が変わる一冊……エリック・エヴァンスの『ドメイン駆動設計』

世の中そこまで悪く無いというか、別に「ドメイン駆動設計を取り入れました!」と高らかに宣言しなくても、いにしえの時代からみんなちゃんとドメインと向い合ってきたし、相応の価値あるシステムを作り上げてきた。派手に失敗した(廃棄された)システムよりも、ちょっとトラブルが多い、なにか改修しづらい、影響が調べづらい…みたいな、アジリティが低いことは問題となったとしても。

そのアジリティの低さをドメイン駆動設計の概念により少しでも高めて行こう、というならば分かるけど、「ドメイン駆動設計を取り入れないと上手く行かない」となると違うんじゃないか。

メインフレームCOBOLって世界だって、きちんと設計はされていたし、ドメインと向かい合っていたわけで、ただその方法論に良い名前がついてなかったり、妙に原理主義的な主張だったりするから、一部の人の関心しか引かなかったわけで。

未来を見据えてコードを書こうとすればするほど、ドメインと向かい合う時間はおのずと長くなるはずなんだよね。

人間同士のコミュケーションを始めるにもハンドシェイクのプロトコルが必要なんだよね

最初にハンドシェイクのプロトコルを使って正しくコミュケーションを確立させるためのやり取りにもっと意識的でありたい。

その時にアイスブレイクのさらに次のステップが必要で、そこを探ってる間は性急に結論を出そうとしてはいけないと思う。

その曖昧な状態で結論も出口も無い瞬間を否定しちゃいけないんだよね。

一家に一冊『体系的に学ぶ 安全なWebアプリケーションの作り方』

紙の方が、さっと取り出して、「ほらここに書いてある」って言い易いけど、一方で600ページ超えなので、「読んでおいてよ」って物理的に渡すとプレッシャーになるなーって思った。

でも、拾い読みしておくと、ぱっと取り出せて便利だなって、改めて思った。

20年代に『人月の神話』を読むのなら、”第16章 銀の弾などない”と”第17章 「銀の弾などない」再発射”から読むのが良いのではないか

システム開発のオフィスの本棚によく置かれている率が高そうな本と言えばご存知『人月の神話』。

それが読まれているか、読んだ人なりの感想が有るか、更には実践されプロジェクトに反映されているかは、ここでは……あえて聞かないでおきましょう。

現在出版されている「20周年記念増訂版」は、1995年に、オリジナルの出版(1975年!)に、1986年に発表された論文である”第16章 銀の弾などない”と、それ以降の議論が第17章〜第18章、第19章として加えられている。

つまり、一冊の本の中でも20年の時間が流れているのだ。

本書のタイトルにもなっている『人月の神話』は、この本の中では第2章で語られているに過ぎない。また、オリジナルの『人月の神話』で語られていることはどちらかというとマネジメント視点が強く、いきなり「エンジニアになるぞ!」みたいな人が読むには少し退屈かもしれない(読み物としては面白いと思えるけど)。


それより、今から、この20年代に読むなら”第16章 銀の弾などない”と”第17章 「銀の弾などない」再発射”から読み始めるのがお勧め。冒頭に書いた通り、元々この章の内容はオリジナルの『人月の神話』には含まれていない、独立した内容なのだから、ここから読んでも全然問題無い。

(ちなみに、第17章の冒頭に、”「人月の神話」はさかんに引用されても議論されることがなかった”と書かれているのが興味深い……おそらく面と向かって聞けば誰だって人と月は等価交換できないと言うに決まっている……ただ、それを回避するために正しい手段が取れているか?というだけで)

第16章では、正しくソフトウェアを作っていくためには近道はなく、地道に積み上げていくしかない、ということが理由と共に書かれている。そしてそこには現代においても相変わらず「銀の弾」を探そうとしている人や、「銀の弾」だと宣伝している人が多いことを気づかせてくれる。そういう意味でも現代においてこの章を読む価値は未だ色褪せていない。


きっと色んな場所の本棚に眠っているはずだから、探し出して、借りて、読んでみると良いと思います。貸してくれた本が凄く読み込まれている時は、感想とか、実践している内容を聞いてみるといいと思います。本が凄く綺麗だった時は……お礼だけを言っておきましょう。

レビューは「書かれていることが正しいか」だけでなく、「書かれていないことが書かれていなくて正しいか」を見ないといけない

初めてレビューなるものをやることになったとき、なにをどう見ればいいのか分からなかった、という経験の有る人は多いと思う。

そしてそのうち、「書かれていることが正しいか」だけでなく、「書かれていないことが書かれていなくて正しいか」を見ないといけない、ということに気づくことで一段階スキルが上がった感覚を覚えたりしませんでしたか。

ただ、その「書かれていないことが書かれていなくて正しいか」を確認し、漏れていれば指摘するためには、「全体を把握していること」「もとの構成に一貫性があること」など、さまざまな前提がある。誰にでもできるわけじゃないし、組織としてそれができる人を育てて、用意していかないといけない。

レビューがただの儀式になって、「レビューをおこなったこと」自体が意味を持つ場面も有るのかもしれないけど、本質的に正しい成果に近づくためには、上記のような観点で見ていく必要がある。

当たり前かな…とも思ったけど、案外当たり前のことが当たり前でなかったりするので、あえて書いてみた。

magnoliak🍧 (@magnolia_k_) | Twitter

アジャイル人材って、どんな人たちなんだろう?

アジャイルソフトウェア開発宣言”で書かれていることも当たり前と言えば当たり前だし。

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。

『みんなでアジャイル』は、開発組織だけでなく、企業のさまざまな組織が、アジャイルに対応できるように変わるためのヒントが書かれている。

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

  • 作者:Matt LeMay
  • 発売日: 2020/03/19
  • メディア: 単行本(ソフトカバー)

この本で書かれていることから一つアジャイルなスタイルが実践できているか否かの境目を取り出すとすれば、「不確実性を計画する」という概念かもしれない。

アジャイル人材の定義を知りたいけど、結局「サービスを届ける意思がある」「素早くフィードバックして変えていく」「ツールを使いこなす」というところに収斂していくのかもしれない。

みなさんの考える「アジャイル人材」の定義を教えてください。

magnoliak🍧 (@magnolia_k_) | Twitter