00:04
はい、7月24日日曜日、時刻は朝9時半を回ってしまいました。
はい、東京は平気ですね。
はい、おはようございます。今日も朝活を始めていきたいなと思います。
えー、ガッツリ寝坊しました。ごめんなさい。
起きたら9時27分で、お、やばいじゃんってなってる感じですね。
はい、おはようございます。
七夕先生なんですね。ご参加ありがとうございます。
はい、じゃあ今日もやっていきたいと思います。
えっとですね、タイトルにある通りですけど、
えーっと、なんでしたっけ。
ソフトウェアエンジニアですね。
The Soft Parts の JSer.info
あー、じゃあわ。
ソフトパーツという記事と、えっと、今日多分終わると思いますので、
JSer.info の方ですね。の記事も読んでいきたいかなと思っています。
はい、えー、昨日、えー、どこにやったっけ。
昨日から、えーっとですね、タイムマネジメントのセクションに入ったんですね。
タイムマネジメントのセクションが終わると、最後はコンクルージョンしかないので、
えー、そこに行くんですけど、
今タイムマネジメントの称号で、えーとセクションで、
ほぼほぼ終わったので、えーっと、
まあ今日はそのまま続きを読んでいこうかなと思いますね。
はい、じゃあ早速読んでいこうと思います。
ただ昨日どこまで読んだっけっていうのはちょっと僕、
もう昨日のことなりに結構曖昧なので、もしかしたらかぶってたら大変に申し訳ないですね。
はい。
では行きましょう。
昨日はそのいろんなタイムマネジメントのチップス的なところを読んでいって、
えーと最後、えーと続きのほうですね。
いきたいと思います。
問題に対する理解が深まれば見積もりを更新しましょうというところですね。
はい。
ある種の仕事の顧客であったり利害関係者っていうのは、
プロジェクトやタスクをいつまでに提供できるか、
このコスタミアムなのかっていうのを知りたがるものなのです。
まあこれは妥当だと言ってまして、
時には納期に合わせたい場合もありますし、
他の場所に依存関係があり、
エンジニアリング作業をサポートするために計画が必要な場合もありますと。
で、ソフトウェア納期っていうのは、
正確に予測することが難しいことで知られています。
見積もりに基づく納期っていうのは、
プロジェクトが特定の段階にあるときのみ与えられるべきですと。
で、時間が経過すると、
チームの問題解決能力に関する情報が与えられるので、
もしくは得られることができるので、
見積もりは更新されるはずですよと。
そういうのをインフォームの見積もりと言ったりします。
で、最初の見積もりっていうのがサイジングで、
これは最も信頼性が低いことで多いんですけど、
ここが出発点であり、
時間の経過とともに改善されていきますと。
製品の要件やUX依存関係が不明かけた場合は、
その最初のサイジングですね。
ざっくりした見積もり的なときには、
より保守的な見積もりが有効ですよと。
いわゆるバッファーどんどん積みまくったりとか、
いろんなリスクで違って、
割と大きめな見積もりをしていく方がいいかもしれないですね。
私はこのような見積もりをPMと共同で行って、
全員同じ考えで見積もりを改良することで、
最近の最高の成功を収めることができます。
03:00
この辺読んだ気がしましたね。
昨日読んだ気がしますけど、
せっかくなのでこのまま読んでいきたいと思います。
ソフトウェアの見積もりで厄介なのは、
最初の楽な見積もりが最初のドラフトではなくて、
記録された計画として固まってしまうことです。
その通りですね。怖いなと思いますし、
ほとんど情報がないまま、
サイジングのままで作った見積もりが、
そのままプロジェクトの計画にガッと組み込まれていくという、
危険な話はよくある話なので、
それは良くないですよね。
クリティカルパスのチームがそれを採用しても、
見積もりの調整をエンジニアリングに一時的なものとみなすと、
最初に基づいた見積もりのステップですね。
N分の1と比較して、これが問題になることがあります。
プロジェクトに誤差引が出たら、詳細を把握することです。
これは何が要件に対応するのかをより深く理解することで、
3ヶ月の見積もりから2ヶ月または5ヶ月になることを意味するかもしれません。
可能であれば、見積もりがスケジュールを動かすのではなく、
スケジュールが見積もりを動かすようにしたいものです。
私のチームでは動かせない期限、例えばカンファレンスなどがあります。
そういう場合もありますけど、見積もりがその期限をオーバーシュートしても、
多くの場合は問題はありません。
変更、もしくはプレビューですね。
フレーミングとか将来の延期など、
常にリーダーシップと話し合いごとができるオプションですよと。
もちろんこれがいつも簡単なことではないことは承知しています。
スケジュールを引っ張られる場合は、
仕事を必要なものと必要でないものに分けて、
これらを将来のスプリントに移動させて、
必要なものが起き上がるかどうかを見出すことができると言っています。
この辺までが機能4だなというのを、
今ちょっとずつ思い出してきました。
ではそのまま続き読んでいきたいと思います。
それでもスケジュールが難しい場合は、
このプロジェクトにエンジニアスケア追加できないか、
スコープを幅に縮小して物を切り回らなくてはいけないか、
など様々な質問をすることができますと。
ちょっと翻訳が遅いので読んでみますね。
続いていきますね。
プロジェクトのキャンセル的な話ですね。
これは嫌なことですけど、キャンセルすることがチームや組織にとって、
長期的に最も健全な話になることはありますよ。
時にプロジェクトを立ち上げる前にキャンセルした場合ですね、
このプロジェクトに関わるスタッフが維持できなくなったりとか、
最終的には必需書になる可能性もあります。
一度目に私はKilled by Googleというのをやりました。
昨日僕もツイートしましたけど、
いわゆるGoogleが辞めることを意思決定したとか、
Googleが作ったプロジェクトによって
止まることになったみたいなものがガーッとまとまってますね。
いつなくなったのかと、
06:02
それがどういう理由でなくなったかというのが一覧になっているというのが
Killed by Googleというサイトですね。
確か267個だったかな?
サービスがKilled by Googleですね。
いろんな理由もありまして、
いろんなビジネス的な判断によって
サービスとかサイトを辞めることになっているんですけど、
その辺、まとまってあるのが結構ありがたいし、
何で辞めるかという理由的なところとかを読むと、
そこそこ反省点とかもありますし、
自分たちのビジネスにも結構通ずる話だなと思いました。
ただやっぱりGoogleが書いているので規模感が大きいのと
見ているものが大きいなという感じもありましたので、
プロジェクトがキャンセルされるような状況は
できるわけで少なくすることを目指しましょうと。
最近数年かかりのプロジェクトを
このエンジニアの方もキャンセルして大変な応援をしました。
どのような場合に起こるかというところですけど、
新しいプロジェクトの投資についてある時点では
正しい決断を出すことができる。
その時点では情報とか保持が一列に並ぶことですね。
市場的合成だったり、組織の賛同だったり、スタッフの確保だったり。
1年後には市場やリーダーシップ、プロジェクトの重要性など
様々なことが変化している可能性があります。
プロジェクトの開始に設定した前提条件が
期間中に継続して正しいかどうかを
定期的にチェックすることが重要だと言っていました。
プロジェクトって変化するものだし、見ずものなので
常に見直しをすることが大事だと思います。
その前提が正しいかどうか、確信を持てれば持てることを
プロジェクトの立ち上げに成功して
サポートを受け継ぐことができる可能性が高まります。
キャンセルするには余裕がありますが、
特に立ち上げを期待して投資してきた生身の人間が
生身の感情を持っていることが挙げられます。
リーダーとしてキャンセルされたプロジェクトから
立ち上げに成功した他のプロジェクトへと人々を導くことは
メンタル的に複雑ではありますが、人々を信頼
もしくは幸福の場所に戻すためには重要だよと言っています。
顧客ではユーザーの信頼と
プロジェクトに影響を与えるかを意識してください。
続いて、
休憩やワークライフバランスを取らないアドバイアチームは
燃え尽きる可能性があります。
09:08
大きな組織では実行に時間がかかると感じることがあります。
これを乗り切る方法はありますよという話から
いきたいと思います。
私はエンジニアとなぜ
大きな組織でXムーンショットを出荷するのは
そんなに難しいのかという内容の会話を何度もしてきました。
Xムーンショットってなんだ?
ちょっとよくわからないですけど。
Xムーンショットを出荷するのはそんなに難しいのかというのを
特に大きい組織で何度も何度も話をしてきました。
アレックス・コモルスキーという方がいらっしゃるらしいですね。
大きな組織を年金に与えた素晴らしいアナロジーがあります。
つまり単純なことであっても
その実行は調整による逆風によって
予想以上に遅く感じられるようになるということです。
組織には複雑なシステム、構造、力学があって
プロジェクトで調整しなければならない人の数が増えると
逆風が強くなりますよと。
ここには他の人のタスクの難しさを過小評価する。
例えば依存関係を構築している場合などですね。
など多くの力が働いていますよと。
これはでもやりがちですよね。
逆に言うと自分のタスクがどれだけ難しいかというのが
他社からすると過小評価されるということもあります。
こうした問題もすることはできませんし
機能不全が広がってしまいますよと言っていますね。
このような逆風を切り抜ける方法の一つは
物事をできるだけディカップリングして
OKなタイムラインに着地させ、最終的に
そのXの出荷に向けて収束させることですよと言っています。
最初からXのすべてに取り組むのではなくて
ムーンショット、大きなリスクのある取り組みのことをですね。
そういうことをムーンショットと言うんですね。
大きいリスクのある取り組みのことですね。
まずルーフショット、価値を引き出す安全なステップ
というのを定義することで目標に近づけることができます。
そういう言葉があったんですね。
ムーンショットとルーフショットですね。
この問題に心当たりがある場合は
そのアレックスのデッキを読むことを強くお勧めしますと言っています。
そのアレックスのデッキって言われている
スライムモールズっていうのが
モールズかなっていう記事がありますので
リンクがあられていました。
続いて、プロジェクトではなくて問題にフォーカスをしましょうと
フォーカスオンプロモレルズバーサスプロジェクトです。
あなたのユーザーが未解決のニーズ、問題などを持っているとします。
あなたが特定のプロジェクトに所属するエンジニアになる場合
その特定のプロジェクトがどのようにこの問題を解決するのかを
尋ねるのが普通ですと。
ローカルとかマキシマムとか局所最大地位みたいなところですね。
似たような形のプロジェクトが集まる大きな組織では
複数のエンジニアが独立してこのような考え方ですね。
12:01
私のプロジェクトはこの問題をどう解決するかっていうのを
話したり議論することはよかることですと。
しかしプロジェクトのポートフォリオを所有している場合
これは明確ではないかもしれません。
もしユーザーがあなたのプロジェクトの多くを
一緒に使うかもしれないとしたらどうでしょう。
それぞれのプロジェクトが互いのアプローチに気づかず
それぞれの方法で問題解決しているとしたら
それは奇妙なことではありませんかと。
そうではなくこの問題に対する正しいエンドとエンドの
ソリューションはないかという問いかけが必要であり
どのプロジェクトや一連のプロジェクトの変更が
このニーズに最も統合的に対応できるのか
というものに立ちものですと。
そのためには関連する複数のプロジェクトで働く人々に
より深くコラボレーションしてもらう必要があるかもしれません。
しかしその結果最終的にユーザーにとって
より困難しないストーリーを作ることができるのです。
結局人との関係性関わり性とか
その裏にある背景とかを理解して
ソリューションのあたるストーリーを
しっかり作っていくことが重要ですよね。
これは本当そうで
真理に近いところはありますけど
進んでいったりするとなかなか難しかったり
パッティングしたりすることもあるので難しいですけど
とはいえ今やっていることとか
作っているプロジェクトがやっぱり何のために
やっているのかというのに立ち戻るのがいいのかもしれないですね。
以上でタイムマネジメントはここまで読みました。
最後、コンクルージョンですね。
コンクルージョンは結構短いのでサクッと
言っちゃいたいなと思います。
卓越した人たちに囲まれ
その分野で最高の人たちと一緒に働きましょう
というのがブライアン・ストゥフェン・フィリーズ
読めないすみません。
僕が英語を読めなくてごめんなさいね。
という方がおっしゃっていたことらしいですね。
卓越した人たちに囲まれその分野で最高の人たちと
一緒に働きましょうと。
あなたが学ぶことのできる人々との友情と関係に
彼らの指導や上限、もしくは成功や失敗を素直に
受け入れましょう。
助けや洞察を求めることを決して忘れてはならない。
多くの場合、質問すればすぐに解決してくれたり
答えてくれたりすることが多いですよと。
どの段階においても、ある組織における技術
ビジネス領域、人材に対する熟練は
時間をかけて培わなければならないことを忘れてはなりません。
ある組織が他の組織からマスターを雇い
それから生産性を上げることを期待することはできません。
優秀なエンジニアであれば、組織の成長に貢献することができます。
その見返りとして、新しい道が開かれ、新しいスキルを見つけ
自分自身を成長させることもできます。
最後に、この記事に対して
いろんな方々のフィードバックがあったり
聞こえいただいたことに大変感謝しますということで
15:01
締めています。
実に5日間にわたって読んできました。
改めてこれは僕が読んだ
考えや感想がありますが
皆さんご自身でも読んでいただきたいなと思いますし
とても資源というか
資産に富んだ記事だったのでぜひ読んでいただきたいし
チームメンバーにも添加してもいいんじゃないかなと思いました。
というところですね。
じゃあ今日の残りの時間ですね。
意外と残り時間は12分で半分ぐらい言ってましたので
アズさんはいつも通り
困った時のJSERインフォを読んでいこうと思います。
アズさんの書かれたJSERインフォの
7月20日の更新ですね。
今回はちょっと短いかもしれないですね。
今回の更新ですけど
一つ目、ノードJSの18.6がリリースされました。
気づいたら18.6まで行ったんですね。
18.6ではエクスペリメンタルで実装されている
--ローダーのオプションの挙動が
ちょっと変更になってますよと言ってます。
複数のローダーを指定した場合の順番を
変更にしてますと。またローダーの実装は
ショートサーキットを返すのが必須となってますと言います。
そのため既に公開されているローダーが動かなくなっている
場合がありますのでその辺は注意してくださいということでした。
詳しくは次のイシューと記事で解説されてますと言いますね。
イシューはそのノードJSの
リポジトリのプルリクエスト
42623番ですね。
そこに一応書いてますよと言ってます。
もう一個の方は記事でCustomESMLoaders
という記事をDevCommunityの方で書かれてますね。
この2つあるので見てみてくださいということでした。
JSONinfoはさすがに記事のリンクが
たくさんあるので今回読んだJSONinfoの
記事のみの情報をツイートします。その中にいっぱい
記事のリンクが貼られているのでぜひ見てみてください。
続いてリアクトネイティブのJavascriptエンジンはJSC
Javascriptコアがデフォルトでしたけど
次にリリースされる0.70
デフォルトが
Hermes
本当に英語弱くてごめんなさい。
これ多分Hermes
Hermesですかねの比較
と変更される予定ですということでした。
リアクトネイティブの要はJSNの
エンジンがJSCからHermesへと変更される予定
予定ですというふうになってますね。
一応これもリアクトネイティブの公式ブログに
記事が書かれてますね。
この記事ではJavascriptコアとHermesの
比較もしくはABI非互換性の問題もしくはHermesの
ECM ECMAScriptの
i18nのAPIサポートについて以上書かれてますよ
ということでした。
エンジンを変えると結構デカいんですけどリリースされる
バージョンは0.70なんでメジャーバージョンではないんですね。
18:02
リアクトネイティブやっている
プロダクトある方はこの辺は
見てみてもいいかもしれないですね。
バージョンアップは絶対に待ってくれない話ですので。
続きまして
AWSのデザインシステムである
クラウドスケープデザインシステムが公開されてますよ
ということでした。
デザインシステムの原則を書いたドキュメント
リアクトコンポーネントが利用する時のパターンから構成されてます。
原則についてのドキュメントもよく書かれているので
読んでみると面白いかもしれません。
ファウンデーションですね。
先ほど見てたクラウドスケープデザインシステムの
リアクトコンポーネントも公開してますので
面白いかもしれないですね。
両方見てみてもいいかもしれないですね。
AWSのデザインシステムって全然見たことないし
あまり知ったことがなかったので
それを公開してくれると嬉しいなと思いましたので
これは僕はちょっと後で見たいと思います。
じゃあヘッドラインに行きますね。
ヘッドライン。一つ目はNode.jsのバージョン18.6のリリースですね。
続いて
MOMENTですね。
MOMENTスラッシュルックソンか。
ライブラリの話ですね。
ルックソンかラックソンかわからないですけど
メジャーバージョン3.0.0がリリースになりましたよってことでした。
一応ジェンジログがリンクを貼られているので
興味ある方は見てみてください。
MOMENTって言ってるのは
オーガナイゼーションがMOMENTっていうところにいますと
MOMENTのリポジトリラックソンですね。
続いて
NestJSのバージョン9がISNOWAVAILABLE
リリースになりましたよってことでした。
今回はREPLの追加と
コンフィギュアラブルモジュールビルダーの追加になりましたよ。
あとはデュエラブルプロバイダーの追加になったよとか
その辺の変更があります。
以上メジャーバージョンアップになっているので
ぜひ見てくださいってことでした。
続いて
RELEASE 5.8.0
UNDEC
NodeJSのUNDECのバージョンが
5.8.0がリリースになりましたよと。
本当に詳しくないんですけど
そんなものがあるんですね。
これはCRLのインジェクションとクッキーの扱いに関する
セキュリティの修正が行われてましたよという話です。
NodeJSのモジュールの話なので
普通にNodeJSがバージョンアップした時に
これも一緒に含まれてくれるんじゃないかと思いますけど
コアモジュールじゃないかもしれないので
意図的にインストールしなきゃいけないかもしれないですね。
全然使ってないものなのでこんなのあるんやって今初めて知りました。
続いて
21:01
Node-REDのバージョン3.0がリリースになりましたよということです。
エディターのアップデートだったりとか
ACに代わってモナコエディターというのがデフォルト化になりましたよと。
あとランタイムステートオプションの追加になったりとか
Diagno Sticksというオプションが
追加になったよということだそうです。
全然知らないオプションです。
Node-REDを使っている方でメジャーバージョンアップになったので
そこも見てみてくださいということです。
いきなり上げてガンと使えるかどうかというのはいつも通りのリスクがあるかもしれないので
お勧めでもいいと思いますけど少なくともバージョンアップしたので
その辺軽く見てもらってもいいんじゃないかと思いますね。
続きまして
ESLintのバージョン8.20.0がリリースになりました。
Pluggable JavaScript Rinterですね。
とりあえずバージョン20.0がリリースです。
今回はプリプロセッサーにおける
パースエラーなどをリンターエラーとして報告するようになるなど
いくつかの変更でも入ってますよということでした。
ESLintはさすがにちょっと気になるので
僕もバージョンを上げてみようかなと思います。
手元に持っている適当なプロジェクトで勝手に上げてみて
使ってみようかなと思いました。
続いて
ヤコブ123という方の作られた
ハガナというライブラリですかね。
それがどうだったんだ。
そういうものがあったんだということですね。
これ何かというと
まず英語のタイトルは
Node.js Runtime Protection for Supply Chain Attacksですね。
読んでみますと
Node.jsのfsだったりとか
ChildProcessModuleなどを上書きして
アクセスできるネットワークや実行できるコマンドを制限するライブラリです。
デフォルトではNode.jsモジュール以下に含まれる
サードパーティーのライブラリに対して制限を追加するようにしてます。
サプライチェーンアタックに対する
Node.jsのRuntime Protectionですね。
読んだ内容よりもどっちかと
タイトル的には割とセキュリティに関するものなのかなというところで
ちょっと見てみようかなと思いました。
続きまして
アーティクルですね。記事の一覧です。
今回の貼られている記事は
一つ目ですね。
リアクトとソリッド原則についてという記事の
リンクが貼られていました。
これはもう僕が読みます。
続いて、先程のリアクトネイティブの話ですね。
これがそもそもブログだからブログとして読んでみてください
というのが一つでした。
最後、Beatさんが採用したCJS Pro機種における
デュアルパッケージ構成というところの記事ですね。
これは多分日本語の記事っぽいかな。
Beatが利用しているCJSとESMの
ESMをデュアルパッケージに
対応する手法について書かれています。
24:01
CJSからESMを扱うために非同期な関数の
エクスポートというのはダイナミックインポートを含むラッパーを公開して
同期的な関数のエクスポートというのは
ESビルドなどでバンドラ済みのものを公開するようにしています。
なるほどね。
あまりBeatを僕は使ったことがないんですけれども
この辺の話は割と面白そうだし
CJSとESMとかその辺のコアな技術の話になるので
読んでいたらすごく勉強になりそうなので気になりました。
もしくは明日読むかもしれないです。
物によっては明日読むかどうかは決めたいと思いますけど
一旦今日はそういう紹介でと思います。
続いてスライドもしくは動画関係のところです。
今回はRETIのライブコーディング
without the stressというところを払っていますね。
これはGitHubのリンクなので
どっちかというとスライドかな?
今回は動画じゃないですね。
今回はTexTarareなどに対する
読み方は合ってるか知らないですけど
TexTarareに対するエコーディングの動きを記録して
リプレイできるライブラリーですと。
プレゼンテーションなのでライブコーディング的なデモを行う用途で
作られていますよと言ってました。
それを記録しておいてリプレイできるのは結構大きいですね。
特にライブコーディングを動画とかで残しておけるのは
すごくいいことだと思いますので。
続きましてサイトサービスドキュメントの項目ですね。
一つ目はクラウドスケープですね。
クラウドスケープデザインシステムで
AWSのデザインシステムが公開になってますよということですね。
二つ目はDefensive CSSの
これまたサイトかな?
Defensive CSS.devというドメインだから
これはサイトですね。
CSSで幅を変えたときにデザインが崩れる問題の
対応をまとめたサイトですと。
フレックスボックスだったり画像サイトだったり
折り返し文字列だったり、アイコンと文字の被りだったり
背景画像の繰り返しだったり、ビューポートのサイズなどの問題について
まとめなどについて書かれていますと。
これは筆読ですね。
Defensive CSSでした。
本当にデザイン崩れる問題がよくあるので
ウェブフロントエンドのエンジニアは絶対
毎回毎回纏っていると思うので、これをまとまっているのは
すごくありがたいですね。
ではラスト、ソフトウェア・ツール・ライブラリ関係ですね。
一つ目ですけど、また全然読み方が分からない人の方の
Number.fmtという
ライブラリですね。
Number Formatting Using a Text Pattern and Native
Intl.NumberFormat
Intl.NumberFormatという
先ほど言ったIntl.NumberFormat
ベースの数値の整形ライブラリですね。
数値の整形ライブラリか。
確かに毎回ガリューというか、みんなガリガリやってますけど
これがライブラリ化されているのはすごくいいなと思いました。
27:00
ローダー集に似たようなものもある気もしますけども
そういうNumber.fmtというライブラリが
出てましたよということでした。
続いてMagic RegExpo
Magic RegExpoというライブラリの
紹介ですと。
コンパイルドアウェイ、タイプセーフ、リーダブルレグエクスポ
オルタネイティブと書かれてますね。
正規表現の話ですね。
正規表現を組み立てるビルダー関数を提供するライブラリですと。
正規表現リテラルへと変換するNuxTBとNext.js
向けのプラグインも公開しているということでしたので
正規表現はよく使うので
ここも気になりますね。
アズさんがピックアップしてるんだからそこそこ有用性は高いんだろうなと思いつつ
気になったので
これも軽く見てみようかなと思いました。
というところで今回のJSERインフォの記事を読んでいきましたけど
こんなところで以上にしたいと思います。
ちょうど10時超えましたので
今日の朝勝は以上にしたいと思います。
今日は完全にいつも以上にグダグダして大変に申し訳ないなと思いつつ
タイトルがだらだら読む回になっているのでご了承いただければ嬉しいです。
明日は先ほどピックアップしたいくつかの記事を読んでみて
その中で良さそうだなというのを改めて
ここで読もうかなと思いますので
もしくは皆さんの方でこれ読んでくださいみたいなのがあったら
ピックアップしていただけるとすごく嬉しいなと思いますけど
というところです。
今日は朝勝終了したいと思います。
日曜日ですね。ゆっくり過ごしていただきまた影響を養っていただいて
明日からの仕事を頑張っていければなと思います。
では以上にしたいと思います。ご参加いただきありがとうございました。お疲れ様です。
