個人的におすすめしたいFeature-Sliced Designというフロントエンドアーキテクチャ設計方法論
Feature-Sliced Designというフロントエンドアーキテクチャ設計方法論をプロジェクトに導入してみたところ、 個人的には良いと感じているので、どのような設計方法論なのか、具体的にどのような部分が良いと感じたかを紹介していきたいと思います。 Feature-Sliced Designとは？ Feature-Sliced Designは、フロントエンドアプリケーションを対象としたアーキテクチャ設計方法論です。公式サイトでは、「コードを整理するためのルールと規約の集大成」と記載されています。 Feature-Sliced Designの設計方法論 Feature-Sliced Designでは、プロジェクトはLayerで構成され、各LayerはSliceで構成され、各SliceはSegmentで構成されます。 Layer Feature-Sliced Designの第一階層をLay
Product Opsの力: プロダクトマネジメントを変革する新たなアプローチ - Techtouch Developers Blog
こんにちは、PdM（プロダクトマネージャー）の shu です。 最近は暖かくなり、散歩が気持ちよくなってきた季節ですね🌸 自分のおすすめの散歩コースは、日比谷駅付近から丸の内方面へ歩いていくコースです。 b8ta Tokyoでおもしろい製品を見て・試してみたり、KITTE の屋上から普段とは違う角度で東京駅をみてみたり、皇居の近くで桜を見てみたりと、「都会と自然」両方を楽しめるコースになっているのでおすすめです。 さて今回は、プロダクトマネジメントチーム（以下PMチームと略します）が取り組んでいる「Product Ops」についてご紹介します。Product Ops は、PMチームが抱える組織課題に対する実践的なアプローチです。その目的は、PMチームの生産性と開発品質を確実に高めていくことにあります。 本記事では、Product Ops の具体的なアプローチや進め方を、できる限り分かりや
Four Keys にはどうやら2つの意味があるらしい - bonotakeの日記
先日、スクラムフェス福岡でこういう話をしてきました。 speakerdeck.com 特に国内ではここ1, 2年界隈を騒がせている "Four Keys" と呼ばれる4つの指標についての話で、乱暴に内容を一言でまとめるなら、「Four Keysをちゃんと使いたかったらまず出典の本を読もうぜ」というものでした。 元々、Four Keysとか、それを包含する「開発生産性」と呼ばれる分野の世間での使われ方に妙な違和感をずっと感じていたのでこういう話をしに行ったのですが、講演後に現地で議論したりとか、あとこの資料を公開した後の反響を見たりしていて、1つ気づいたことがありました。 それは、世の中でいう "Four Keys" に実は2つの意味があって、その2つがひたすら混同され続けているのでは ということでした。 その2つというのはこれ↓です。 デリバリのパフォーマンスを測る指標 組織のパフォーマン
Feature Flag Deep Dive
チーム勉強会で Feature Flag とトランクベース開発の話をしました （追加訂正と書かれているスライドは、勉強会後議論した結果を反映したものです）
CS 6120: The Self-Guided Course
Syllabus Schedule Lessons Zulip Discussions Blog CS 6120: Advanced Compilers: The Self-Guided Online Course CS 6120 is a PhD-level Cornell CS course by Adrian Sampson on programming language implementation. It covers universal compilers topics like intermediate representations, data flow, and “classic” optimizations as well as more research-flavored topics such as parallelization, just-in-time com
GitHub's Engineering Fundamentals program: How we deliver on availability, security, and accessibility
EngineeringGitHub’s Engineering Fundamentals program: How we deliver on availability, security, and accessibilityThe Fundamentals program has helped us address tech debt, improve reliability, and enhance observability of our engineering systems. How do we ensure over 100 million users across the world have uninterrupted access to GitHub’s products and services on a platform that is always availabl
大神 祐真 (Ohgami Yuma) (サークル名:へにゃぺんて)
→ PDF版(PDFファイル直リンク(表紙画像リンク先と同じ),技術書典オンラインマーケット) 紙版(BEEP) 初版発行日: 2023/05/20 (技術書典14) 「SimH」というシミュレータを用いて、「PDP-7」という1960年代のコンピュータをアセンブリ言語で直接制御するベアメタルプログラミングを行う本です！ 基本的な計算の行い方から始め、テレタイプによる入出力で「HELLO WORLD!」や「エコーバック」のプログラムを作ったり、シミュレータ上で動作するベクタースキャンディスプレイを制御したりします！ サンプルコードは↓で公開しています(GitHub) https://github.com/cupnes/pdp7-baremetal-programming-with-simh-samples 追加・訂正情報 Scrapboxに追加の情報などをまとめています 「セキュリ
テストの学習へようこそ！ | web.dev
テストの学習へようこそ！ コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このコースでは、ウェブ用のテストの概要と探索について説明します。 このコースで学習する内容は次のとおりです。 テストの基礎 自動テストと手動テスト テストを実施する場所と方法 ベスト プラクティス 何をテストすべきか、誰に責任があるのか、目的そのものとしてではなく、目的を達成するために手段をテストすることを検討する方法など、テストの理念。 このコースには、学習に役立つ簡潔で実用的なサンプルコードも含まれています。 コースのスコープには、Node.js などの環境で実行される、フロントエンドの JavaScript とドキュメント モデル、バックエンドでのライブラリ テストが含まれます。テストの経験はありませんが、JavaScript の基礎知識と Node.js などに関する経験が必
カジュアル面談 逆質問テンプレ - yuiseki
御社のミッション、ビジョン、バリューを教えて下さい 御社では、日々の業務でどのようなソフトウェアを作っていますか？ 御社の主要な顧客のカテゴリーとマーケットを教えて下さい 御社の事業が、顧客にどのような価値を提供してどのように対価を集めているのか教えて下さい 御社の事業の立ち上げの経緯や意思決定や試行錯誤のプロセスについて、もしご存知でしたら、なるべく詳しく教えてください 御社の事業の今後の展望や計画について教えてください 御社の日々のソフトウェア開発で、ソフトウェアエンジニアとして、夢中になれる魅力や醍醐味を教えて下さい 御社の技術構成や開発プロセス、開発スタイルについて教えて下さい 会社のことは忘れてください あなたが最近、話を聞いたり自分で触って、驚いたり熱中したり感動したりしたソフトウェアがあったら教えて下さい あなたがこれまでの生涯でソフトウェアを開発していて一番愉快で面白くて最
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
ソフトウェアに関わる人が知っておくといいかもしれない法則10個
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
runnチュートリアル