Season -No.87 朝活「適切なゴール設定の極意: 致命的な５つの設計ミスとその回避法」をダラダラ読む回
はい．第87回は 適切なゴール設定の極意: 致命的な５つの設計ミスとその回避法 https://note.com/kosukemori/n/nf5e5d9263580 という記事を読みました💁 ・適切だが野心的な目標を設定することができていること (Objective) ・目標に対する実行プランを描き、行動に移せること (Milestone) ・それを達成する能力、リソースを用意できていること (Feasibility) 冒頭のこの３つの要素が既に納得のもので，このときから一気に引き込まれましたw 実際に本文はよくある「ダイエット」を例にとても詳しく，かつ分かりやすく解説されており，学びあり読み応えも十分なとても素晴らしい記事です．是非皆さんもご一読ください❗ ではでは(=ﾟωﾟ)ﾉ SMART ゴール Objective Milestone Feasibility ゴール設定 自身でコントロールできる出来事 外的要因に左右される出来事 先行指標 (Leading Indicator) 遅行指標 (Lagging indicator) 明確な基準値 (Baseline) バーンアウト (燃え尽き症候群) 途中経過 マイルストーン 優先順位づけ トレードオフ Twitterでご連絡ください See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
Season -No.86 車輪の再発明について
はい．第86回は Web 業界でちょいちょい耳にする「車輪の再発明」について再度考察してみた話をしました💁（久し振りにナンバリングの配信ですw） 今の自分のスタンスとしては，車輪の再発明は割と肯定的で，それについてのお話ですのでもしご興味ある方は聴いていただけると嬉しいです！また，忌憚ないご意見もお待ちしておりますー． ではでは(=ﾟωﾟ)ﾉSee Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
Season -No.85 朝活「続・4 Design Patterns That Violate "Back" Button UX Expectations」をダラダラ読む回
はい．第85回は前回に引き続き 4 Design Patterns That Violate “Back” Button UX Expectations – 59% of Sites Get It Wrong https://baymard.com/blog/back-button-expectations を読んでいきました💁 前回と同じようなコメントをしてしまいますが，とても素晴らしい記事でした．細かい一つのボタンでしかないですが，ユーザー体験としてはかなり影響度が高いものでもある「戻る」ボタンについての考察が続きました． ブラウザバックすることも多いと思いますが，アプリやシステムだけでなく，ユーザーのコンテキストや仕様端末によってどこの画面に戻るのが正解なのかはつ都度しっかり考えて実装する必要があることを，改めて肝に銘じたいと思います❗ ではでは(=ﾟωﾟ)ﾉ UX usability accordion checkouts browser “Back” button technically the same page separate page time-consuming and troublesome new views states Multistep processes within a page Expanding content Anchor links Truncated content Variations on the product page length of the process separate URL lose overview “Back to top” kicked off the product page entirely no indication “Recently Viewed” items HTML5 History API history.pushState() 59% of sites that don’t support See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
Season -No.84 朝活「4 Design Patterns That Violate "Back" Button UX Expectations」をダラダラ読む回
はい．第84回は 4 Design Patterns That Violate “Back” Button UX Expectations – 59% of Sites Get It Wrong https://baymard.com/blog/back-button-expectations を読んでいきました💁（次回に続きます） 細かい（いわゆる atoms レベルの）コンポーネントですが，UX の観点ではかなり大事な「戻る」ボタン．確かに体験のことを加味するとこれ一つでユーザーが離れてしまう危険性もあるので，しっかり考えていきたいですね〜！ ではでは(=ﾟωﾟ)ﾉ usability studies very specific mental model breaks users’ expectations “Back” button cause of abandonment Overlays & Lightboxes Filtering & Sorting Accordion Checkouts Product Page to Product List navigation new view expanded element UX design process and workflow live chat offers site-provided “Close” element Deemphasize ‘Install App’ Ads or Avoid Them Entirely Product Lists & Filtering acts as an “Exit” link See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
Season -No.83 朝活「ソフトウェア設計について twada 技術顧問と話してみた」をダラダラ読む回
はい．第83回は ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 https://engineers.ntt.com/entry/2022/05/23/083118 を読みました💁 やはり技術レベルが高いお二人の会話ですので，私個人としてはかなり学びが多くありがたい記事でした❗是非皆さんも読んでみてくださいー😆 ではでは(=ﾟωﾟ)ﾉ John Ousterhout A Philosophy of Software Design @iwashi86 twada https://speakerdeck.com/iwashi86/understand-roughly-philosophy-of-software-design-in-30-minutes Change Amplification （変更の増大） Cognitive Load （認知的負荷） Unknown Unknowns （未知の未知） Dependency （依存性） Obscurity （不明瞭性） 複雑性の排除（たとえば、特別なケースを排除する） 複雑性の隠蔽（たとえば、難解な部分が見えなくても使えるようにカプセル化する 小クラス主義 と 大クラス主義 Gang of Four Java Ruby Deep Module（深いモジュール） Shallow Module（浅いモジュール） 認知的負荷 utc_offset 田中 哲(akr)さん APIデザインケーススタディ ――Rubyの実例から学ぶ。問題に即したデザインと普遍の考え方 プログラマが知るべき97のことの1つ プログラミング作法 似た機能でちょっと違うものの実装 ポリモーフィズム リファクタリング Strategyパターン 差分クラス Template Methodパターン ユニットテスト 抽象 継承 fukabori.fm See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
Season -No.82 朝活「フロントエンドのTech Twitterの言説は死んでいるか，死につつある」という連続ツイートをダラダラ読む回
はい．第82回は Tech twitter especially frontend discourse is dead or at the very least dying and becoming increasingly disconnected. 👇 https://twitter.com/PKodmad/status/1518388413396754432?s=20&t=gIq5fFlVczgAfz0dQ4NiZQ から始まる連続ツイートを読んでいきました💁 非常に共感の多いツイートではありましたし気持ちも理解できますが，業界全体とまでは言わないまでも，目の前のコミュニティからでも何かしら改善しつつ，フロントエンドエンジニア界隈のさらなる活性化や相互作用を生み出していきたいなーと思いました❗ ではでは(=ﾟωﾟ)ﾉ twitter frontend Open source burnout community Great resignation salary disparity lack of growth bad management Senior leaders getting into management Flood of beginners Web 3 Death of conferences Low engagement State of the world , covid and war See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
Season -No.81 朝活「続・いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。」をダラダラ読む回
はい．第81回は前放送に続き いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 https://note.com/fmkpro1984/n/n09a2f5b01f33 を読み終わりました💁 繰り返しになりますが，とても素晴らしい記事でした❗ドキュメントや仕様書に関するツールや技術は変化はあれど，それを使う人自身は今後もそれほど進化することはないと私は思っていて，だからこそこの記事は長く輝き続けると予想しています．是非皆さんもご一読いただければ❗ ではでは(=ﾟωﾟ)ﾉ プロジェクト 仕様書 ローンチ 検証結果 チームメンバー リリース UIUX リニューアル 開発仕様：バックエンド側 ブリーフィング 仕様レビュー会 開発規模 開発仕様：フロントエンド（クライアント）側 開発仕様：トラッキング イベント名 プロパティ名 発火条件 QA プラン 工数 備考・関連部署 周知スケジュール エッジケース メンバーリスト 面倒臭がらずにやるかどうか 定石の項目を抑えているかどうか 優先順位 P1 （必ず必要） P2（ちょっと無理をしてでもできれば欲しい） P3（余裕があれば開発しても良いかも） 頻繁にアップデート 情報の鮮度を保てるか 太古のレガシー仕様 仕様修正・仕様追加 Slack / 口頭で変更を決定した仕様 See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
Season -No. 80 朝活「いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。」をダラダラ読む回
はい．第80回は いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 https://note.com/fmkpro1984/n/n09a2f5b01f33 を読んでいきました💁 プロジェクトにおけるドキュメントの大事さについて書かれた記事は数多存在しますが，仕様書についてここまでキッチリと，かつ幅広く言語化されたものは中々なく，読み応えも十二分な記事でした．ぜひ皆さんも読んでみてくださいー❗ ※今回マイクの設定が誤っており，音質が悪いです💦 ではでは(=ﾟωﾟ)ﾉ 仕様書 フリッツ 5 つの効果 重要性が増していく 2 つの理由 14 の項目・実戦編 作成時に心に留めたい 3 つのこと 仕様書フォーマットに正解はない PdM PM エンジニア QA プロダクト チーム メンバー リリース One fits for all = 全ての場合に適用できる理想の仕様書 「含めたほうが良いもの」の最大公約数 コミュニケーション・サーチコスト 関連ドキュメント Slack の海 仕様変更 終盤のカオス One True Source （ここに行けばすべての真実が書かれている） 機能 エッジケース 在宅勤務 時差出勤 グローバル開発 仮説 実験用フラグ名 バリアント情報 振り分け% See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
Season -No.79 朝活「エムスリーで学んだことを言語化する」をダラダラ読む回
はい．第79回は，エンジニア界隈では有名（と個人的に思っている） エムスリーで学んだ事を言語化する https://note.com/vaaaaanquish/n/nf4182bfe183e ばんくし王さんの記事を読んでみました💁 ビジネス的な観点の記事でしたが，とても素晴らしく，この観点や視点はエンジニアにはとても大事だなと改めて感じるとともに，ばんくし王さんの視座の高さに刺激もいただきました．しっかり精進していきます！ ではでは(=ﾟωﾟ)ﾉ 視座 成長 エムスリー株式会社 ビジネス書 共通言語 @m_nishiba 採用基準 ハンターハンター 本気で叩いても壊れないオモチャ ソフトスキルの成長論 CADDi アイデアを100個出す あり得ない道 @imaimai0 プロダクト 数を打つ See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
Season -No.78 朝活「Testable Frontend- The Good, The Bad And The Flasy」
はい．第78回は Testable Frontend: The Good, The Bad And The Flaky https://www.smashingmagazine.com/2022/07/testable-frontend-architecture/ というフロントエンドにおけるテストについての記事を読みました💁 僕が読んできたテストに関する読み物の中でも１位２位と言ってよいほど素晴らしい記事でした．よくまとめられており，よく言語化されており，フロントエンドエンジニアの皆さんには是非ご一読を，と申し上げたい（個人の感覚ですw）． ではでは(=ﾟωﾟ)ﾉ Front-end Testable Unit tests Integration Tests E2E React Testing Library Tools Processes Cypress MSW Jest Playwright TDD testim.io API subsystem UI Components UI BUILDING BLOCKS APP WIDGETS Web Platform Tests See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.