近年のソフトウェアプロダクト開発組織の活動単位としてよく言われるのは、「少人数で安定したチーム」であろう。表現は違えど、どの文献でもそのように述べられる。 それでは、「少人数」と「安定」の2つの要件を満たせば高パフォーマンスなチームが設計できるかと言えば、そんなはずもない。他にも要件があるはずだ。 そこで、チームに共通して必要だと考える要件を、設計に関わったこれまでの組織から抽出して言語化し、原則としてまとめてみた。それが、「安定」「アトミック」「非兼務」「少人数」「流動性」「イテレーティブ」の6つだ。 初期に携わった組織には欠けていた要素もあるが、何度も失敗を重ねるうちに見いだしたものだ。組織設計のプラクティスとしてよく聞くものもあるが、いずれも実体験を経て必要だと感じたものばかりである。 なお、本記事で取り上げる6つのチーム設計原則だけでは、組織設計として不十分だ。チームにどういった機
JavaScriptのコードには、こんな書き方もある
この記事はコードの書き方について、書き方そのものを推奨するものではなく、このような書き方も出来るという紹介です。コメント欄まで一緒にみていただくと学びになります。 ※記事はいただいたコメントを反映しましたので、当時のコメントと記事の内容に差分があります 1.破壊的メソッドを避ける 破壊的メソッドとは、元の配列の要素を変えるメソッドです。以下の例ではconstで宣言した変数numbersが、pushメソッドにより更新されています。 対応前 const numbers = [1, 2, 3] numbers.push(4) console.log(numbers) // [1, 2, 3, 4] この場合、元の配列の要素を更新するのではなく、スプレッド構文を使って新しい変数に代入します。変数はなるべくイミュータブルにしておくと、意図しない不具合やプログラムの可読性や保守性が向上します。push
【バックエンド】駆け出しエンジニアが目指すジュニアレベルのエンジニアとは【2024年版】 - Qiita
はじめに こんにちは。 普段はフロントエンドの開発をメインでやっておりますmamiと申します。 最近バックエンドの方の勉強や、少しずつですがDB設計やAPI作成などの業務もやらせてもらえるようになったので、自分のエンジニアとしてのレベル感や、この先目指すべき道筋を明確にしたいな〜という思いでこの記事を書いております。 これは自分のための記事であると同時に、同じように駆け出し中のエンジニアさんや、ミドル層を目指す手前のエンジニアさんにも刺さる内容になっているかと思います。 今、自分がどのようにキャリアアップしていくべきなのか、どのような道筋でスキルを磨いていけばいいのか。そんなふうに悩んでいる方は是非読んでみてください。 ※内容はバックエンドエンジニアが対象になりますが、フロントエンドの方もなにか通じるものがある…かもしれません。 ちなみにですがフロントエンドの方の記事は下記で執筆しています
Wevoxのフロントエンドエンジニアをしているタガミです。最近はmonorepo構成に移行中のWevoxフロントエンドのテストやデザインシステムなどをいい感じにしようとしています。 この記事では、WevoxというSaaSプロダクトのフロントエンドにおける自動テストの話をします。Wevoxはリリースから5年以上が経過し、チームのメンバーも増え、またソースコードも巨大化しています。そんな中でフロントエンドも"式年遷宮"をして、改善を繰り返しています。中にはソースコードをガラッと変えるようなリファクタもあり、担当するエンジニアにとってはデグレの心配が付き纏います。そんな日々変化するフロントエンドを支えるのが自動テストです。 Wevoxの開発チームは決して大人数ではありません。そんなチームでも品質の改善のために一歩ずつ改善しつつある経験をもとに、フロントエンドの自動テストポイントをいくつかお伝えし
最近、若手のプログラマと仕事をしていると、フレームワークやライブラリの知識はあるのですが、常識が欠けているのではないか、と思う事があります。 業界経験の長い私たちから見ると、ほぼあり得ないようなことを、論理的な正しさだけを基準に決めつけてしまい、結果として営業が苦しむことになったり、クレームに発展するようなケースも見聞きします。 私たちにとって「当たり前」に判断できることを経験不足で判断できずに、同僚から疎まれたり、会社にマイナスの影響をおよぼしているのだとすれば、非常にもったいないことです。 今回は、業界歴20年におよぶ私が、若手プログラマの成長の一助になることを期待して、この業界のごく一般的なマナーをケース別に紹介、解説したいと思います。 商談編 Q.お客様が「Instagramに投稿された写真のうち当社の製品が写っているものを自動的に当社のHPに掲載したい」と仰ったので、「それは出来
「どのように開発するか」だけでなく、上流からプロジェクトに携わり「何を開発するか」から検討したい、と考えているエンジニアの方は少なくないでしょう。 一方、実際の開発現場では「WHAT（何を開発するか）」がすでにある程度検討され、エンジニアはその実現方法を具体化させるフェーズから参画し「HOW（どのように開発するか）」を考えるケースが多いのではないでしょうか。 「WHAT（何を開発するか）」を検討するフェーズからボトムアップでアイデアを出し、プロダクトの成長にコミットしたいーー。そんな思いを強く持つエンジニアにとって、理想的な環境とも言えるのがリクルートです。 今回、同社を代表するプロダクトである『SUUMO』のレコメンドAPIのインフラを、機械学習エンジニア（以下、MLE）とデータエンジニア（以下、DE）が連携して改修したプロジェクトを参考に、事業成長にコミットするエンジニアの姿を伝えます
2022年上半期に読んだ技術書
2022年上半期はとある都合もあってかなりの数の技術書を読んだので、その中でも良かったものとかの感想をまとめておきます。 2022年上半期で一番良かった技術書 A Philosophy of Software Design ソフトウェア設計の目的は複雑さを軽減することであるとして、その複雑さの定義と軽減する手法が書かれています。最近まで2年ほどフリーランスで色んな会社の開発に参加して、DDD的な設計やクリーンアーキテクチャを採用している現場が多かったもののそれらが逆に開発効率を低くしているのではという感想を持っていました。そこでこの本を読み、それらの目的であるはずの「複雑さを軽減する」という視点が抜けていたのかなと気付かされました。コードを読み書きしていて複雑さを感じなければモノリスでもMVCでもいいケースは多いと思います。複雑さを軽減する手法を解説する章では、やりすぎると逆効果であるとは
アンチパターンで学ぶDB設計 - Qiita
はじめに データベース（DB）の設計は、システムの性能や保守性に大きな影響を与えます。 この記事では、最低限パフォーマンスの低下や管理の複雑化を引き起こさないようにするために覚えておくべきことを、アンチパターンとしてまとめました。 本記事は、 現在仕事でデータベースを扱っており、データ設計について今一度おさらいしたい データベースについての基礎知識やお作法を身に付けたい という人を対象として想定しています。 これらに当てはまる方はぜひ一度確認してみてください！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 DB設計アンチパターン 早速、DB設計におけるアンチパターンを紹介します。 それぞれアンチパターンのテーブルを見て
優れたテストスイートの4本の柱を学ぶ - 「単体テストの考え方、使い方」を読んだ - $shibayu36->blog;
良いテストケースの作成手法を学ぶ - 「はじめて学ぶソフトウェアのテスト技法」を読んだ - $shibayu36->blog;に引き続き、ソフトウェアテストの知識について言語化を進めたいと考え、「単体テストの考え方、使い方」を読んだ。 単体テストの考え方/使い方 作者:Vladimir Khorikovマイナビ出版Amazon この本では優れたテストスイートの4本の柱を「退行に対する保護」「リファクタリングへの耐性」「迅速なフィードバック」「保守しやすさ」と定義し、これらの観点で優れたテストスイートを作る方法について教えてくれる。またこの4つの柱はトレードオフの関係にあるため、単体テスト・統合テスト・E2Eテストがそれぞれどの観点を重視すべきかなどについても言語化してくれている。 自分はこの本は非常に勉強になった。なぜなら単体テスト・統合テストの指針が明快に記述されていて理解しやすく、また
最近、小〜中規模のプログラムを保守性高く記述するにはどうすればよいかが気になっていて、 ソフトウェアのアーキテクチャについて調べていました。 本を読んでみる 以下の本を浅めに読み通してみました。どの本もそれぞれ学ぶべき点があって興味深かったです。 .NETのエンタープライズアプリケーションアーキテクチャ第2版 https://www.amazon.co.jp/dp/B00ZQZ8JNE C#での設計の話。ドメイン駆動設計など、設計に関わるトピックが広く触れられていて良い。 Adaptive Code C#実践開発手法 第2版 https://www.amazon.co.jp/dp/B07DJ2BL4Y C#での実装の話。SOLID原則を中心に、実装に関わるトピックが広く触れられていて良い。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 https://www.a
ソフトウェアアーキテクチャ・ハードパーツ
ソフトウェアアーキテクチャに絶対的な正解は存在しません。むしろ、さまざまな妥協点の中から選択を強いる難題、すなわち「ハードパーツ」が多く存在します。そのため、ソフトウェアアーキテクトには常にトレードオフを見極め、状況に合った選択をすることが求められます。本書は、読者が自身のアーキテクチャ上の難題に対して効果的なトレードオフ分析を行い、より良い決定ができるようにするための書籍です。 本書では、サービスの粒度やデータの所有権、コードの再利用やワークフローの調整、可用性や信頼性の実現といった現代のソフトウェアアーキテクチャの難題と、それに対するさまざまなアプローチやパターンを紹介します。そして意思決定を難しくするトレードオフについて、モノリスを分解しマイクロサービスアーキテクチャに再構築する例を通して詳しく説明します。 『ソフトウェアアーキテクチャの基礎』の著者らによる現代的なトレードオフ分析と
『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』 - snoozer05's blog
翻訳を担当した書籍『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』（オライリー・ジャパン）が明日（2024年1月24日）発売となります（電子書籍はオライリー・ジャパンのサイトでの購入となります）。本書は、2022年10月に出版されたChristian Ciceri, Dave Farley, Neal Ford, Andrew Harmel-Law, Michael Keeling, Carola Lilienthal, João Rosa, Alexander von Zitzewitz, Rene Weiss, Eoin Woods 著『Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture』（O'Reilly Media）の全
本記事では、ソフトウェア開発手法の一つであるDDD（domain-driven design）を使って要件定義〜実装を行う際のプロセスやポイントについてまとめていきます。 （書籍「ドメイン駆動設計モデリング/実装ガイド」の内容を大いに参考にさせていただいていますが、独自の内容・考察も記載しているつもりです。） DDD とは？ DDD（domain-driven design）は日本語に訳すとドメイン駆動設計で、ソフトウェア開発手法の一つです。 ドメイン駆動という言葉から、ドメインというものが重要そうだということは伝わってくると思いますが、そもそもドメインという言葉が抽象的でわかりにくいですよね。 ドメインは直訳すると「領域」ですが、DDD で指している「領域」とは「ソフトウェアで問題解決しようとする対象領域」です。 そして、① ドメインについての理解を深めてモデルを作成し（DDD では、後
はじめに 有用な知識の特性 Google SRE リソース Site Reliability Engineering: How Google Runs Production Systems The Site Reliability Workbook: Practical Ways to Implement SRE Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems SLO Adoption and Usage in SRE Creating a Production Launch Plan Training Site Reliability Engineers: What Your Organization Needs to Cre
【React/Vue.js】コンポーネント設計の（個人的）ベストプラクティス | Offers Tech Blog
概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。今回は、React や Vue.js などの SPA フレームワークにおけるコンポーネント設計について紹介します。 昨今のフロントエンド開発では、コンポーネント指向での開発がスタンダート化しつつありますが、コンポーネント設計には厳格なルールが無く、どのように設計すればいいか悩む方も多いのではないでしょうか？（筆者は沼にはまりました） コンポーネントの単位はどの程度に分割すべきなのか、状態管理はどうすればいいのか、API 通信はどこですべきなのかなど、一言にコンポーネント設計と言っても考えるべき項目が多いです。チーム開発では、認識があっていないとコードが魔境になることもしばしばあると思います。（筆者の経験談より） そこで今回は、数々
経営者：「インフラも見ることができる、良いITエンジニアがなかなかいないんですよ」 ITエンジニア：「インフラ？ 勘弁してください。二度とやりたくありません……」 これは、経営者とITエンジニアの間に見られる乖離（かいり）である。筆者の経験では、特に「地方都市」でこの傾向が強い（具体的な都市名を挙げると無用な波紋を生み前向きな議論が進まないため、あえてぼかすことをご理解いただきたい）。 両者の溝はどのようにして生まれるのか、どう向き合うべきか。今回はこのテーマについて考えてみたい。 「開発ありき」「作ってなんぼ」、そもそもインフラ業務が認知されない Webサイトやアプリケーションを作っておしまい。サーバーやデータベース、ネットワークなどバックエンドのことは気にしない。あるいは意識から漏れる。いわば、「フロント重視」「バックエンド軽視」の状況を悪気なく作り出す。 その背景には「見えないものを
Googleに存在するコードを読みやすく保守しやすい形に保つ取り組みを行うグループ「Code Health」が、「DRYを早まって適用しないこと」と題した記事を公開しました。 Google Testing Blog: Don't DRY Your Code Prematurely https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html DRYは「Don't Repeat Yourself」の略称で、コードを重複させないことを重視する考え方です。重複するコードが存在していると、特定の機能を変更しようとした時に同じ機能を持つ部分を全て探して同時に変更する必要があり、見落としやミスが発生する危険性が高まります。一方、コードの重複を防げていれば一カ所だけを変更すればOKというわけ。 一見DRYを厳しく適用
DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡です。 本記事では、DDDに関する疑問で頻出な、複数集約間の整合性を確保する方法について、具体的なコードを交えて紹介します。 実装方法は、主に以下の3つに分かれます。 ユースケースで複数集約に更新をかける ドメインサービスを使用する ドメインイベントを使用する 目次 目次 集約の定義について 題材とする事例 実装方法1. ユースケースで複数集約を更新する メリット・デメリット 実装方法2. ドメインサービスを使用する メリット・デメリット 改善案 実装方法3. ドメインイベントを使用する ドメインイベント作成に制約をつける メリット・デメリット まとめ 集約の定義について詳しく知りたい方は 現場での導入で困ったら 集約の定義について 集約自体の説明については、本記事では割愛します。詳しくは下記の書籍「集約」の章をご覧ください。 little-hands.booth.p
![DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/e19eb6aae8a33a9c7d58ab11012b9b1e4fd3dc14/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20210306%2F20210306230551.png)
純文学に関する雑感
純文学に関する雑感。 # 純文学とは 純文学は芸術の一種なので新規性が必要。逆に新規性がある小説作品を純文学という。 純文学における新規性とは、主に作品で取り扱う題材の新しさと表現の新しさ、そして作品に通底する美意識の新しさ。それらの新しさを開拓することにより文学で表現できる領域を拡大する作品を純文学と呼ぶ。 とはいえ個々の作品についてそれが純文学かどうかをきちんと判断するのには時間がかかるので、純文誌（文學界、新潮、群像、すばる）によく掲載される作家の小説が純文学と呼ばれる傾向がある。 # 純文学というジャンルについての現在の課題 市場規模が小さいことが最大の課題。平たく言えば食っていけないので担い手がおらず、ジャンルの魅力自体が縮小している。 村上春樹以外の存命の純文学作家は？ と尋ねられても普通の人はなかなか答えられない。 過去の一時期においては小説新聞や文芸ジャンル以外の雑誌、たと
3万2768時間が経過して発生した石巻市戸籍情報システムの障害についてまとめてみた - piyolog
2024年2月14日、宮城県石巻市は2023年9月に発生したシステム障害について原因がSSDの重大なファームウエア不具合であったと公表しました。ここでは関連する情報をまとめます。 重大な不具合情報が共有されずシステム障害発生 2023年9月当時にシステム障害が発生したのは石巻市本庁内で稼働する戸籍情報システム。システムが稼働するサーバー上で使用していたSSDの不具合によりバックアップサーバーを含めてシステム停止が起こり、市役所やコンビニなどで戸籍証明書の発行が行えない事態となった。2日後には最新の戸籍証明書の写しは発行できるようになった*1ものの、完全復旧（除籍や改製原戸籍の証明書発行）には約1か月（2023年9月20日～2023年10月18日）を要することとなった。 障害影響が長期化した理由として、市は当該システム上で取り扱うデータが戸籍にかかわるもので、復旧方法および突合などに万全を期
プログラマ、テスト駆動開発者 和田卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ power-assert-js 作者。 講演や執筆などを通じ、日本におけるテスト駆動開発のエバンジェリストとして知られる和田卓人さん。 TDDとは何かを改めて言語化してもらった前回の記事では、「テストを書かずに進むのが合理的といえるときはある。でも、後からテストを書くのって難しいしつらい」とのお話がありました。 テストが書かれないまま
こんにちは、delyコマース事業部エンジニアの小川です。 先月11月に入社し、エキサイティングな毎日を過ごしています。 この記事はdely Advent Calendar 2019 - Qiitaの24日目の記事です。 昨日はSREの松嶋さんが「AWS RunCommandを使ってEC2上に監視ダッシュボードをサクッと作る（Ansible+Terraform+Grafana編）」という記事を書いてくれましたので是非そちらも読んでみてください！ tech.dely.jp コマース事業部では、現在「事業開発」と「ソフトウェア開発」がほぼ同時に進行しており、プロジェクトにおける確定要素と不確定要素が複雑に絡み合っています。 スピード重視でゴリゴリ実装していくのも興奮しますが、変化に耐えづらい実装をしてしまうと、その後の開発スピードに影響していまい、事業のスピードが落ちるなんて事にもなりかねません
この記事で伝えたいこと（忙しい人向け） 新人ほど「保守していく」ことの感覚が腹落ちしにくいのではないか説 我々は保守しやすいコードを書くべきであり、保守しやすいコードを達成するための手段として原理原則やデザインパターンが存在している 保守ってなんで必要なんだっけ？という体系的な理解を持ったうえで、具体的なテクニックを学んでいくことが大事 // 追記（2023/12/9） なんとミノ駆動 さんにコメントいただけました。 もちろん良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方は読んで影響を受けてます。 とってもうれしい。 想定読者 新卒 ~ ２年目くらいまでのプログラミング初心者 Webアプリの保守開発をしているエンジニア 3ヶ月前くらいの自分（未経験からエンジニアになって１年くらい） こんなことないでしょうか 先輩などから原理原則の観点を共有してもらったり、
このように、層ごとに関心事の分離を行うことで、保守性の高い（変更容易性や再利用性等）アプリケーションを実現できます。 しかし、「トランザクション」においてはどうでしょうか。 トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。 そういう曖昧なものは「ひとまず usecase 層に入れてしまえ」という方針になりがちです。 ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。 そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。 前提 1. クリーンアーキテクチャを採用している（オニオンアーキテクチャやレイヤードアーキテクチャも含む） そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。 そのため、オニオンアーキテクチャ
DDDにおける値オブジェクトの位置付け(モデルとコード事例あり)[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 最近、値オブジェクトに関して書かれているブログ記事を見ますが、 SNSなどにおいてDDDにおける値オブジェクトについて誤解されているような反応が見受けられました。 そこで、この記事では「DDDにおける値オブジェクトの位置付け」について解説し、具体的なモデル・コードを用いながら誤解を解いていきたいと思います。 なお、値オブジェクトに関する詳細な説明はここでは行いませんのでご了承下さい。 DDDの目的 まず最初に、DDDの目的について確認します。 DDDの目的は、モデリングを通じてソフトウェアの価値を大きくすることです。 これに関しては、こちらの記事で詳細に解説しているのでこちらをご覧ください。 ドメイン駆動設計は何を解決しようとしているのか - little hands' lab ここで大切なのは、モデルは一回のモデリングで完成形
![DDDにおける値オブジェクトの位置付け(モデルとコード事例あり)[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/d6ececc2d05edbf2c4b45bcb603bdecda34fde46/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20220815%2F20220815005816.png)
逆に教えて欲しいんだけど、なんで海外旅行好きの女って
あんなに性格悪いんだろうな 海外旅行に行くと性格悪くなるのか 性格悪い女は海外旅行好きになるのか 海外旅行好きの女って、ギャンブル好きの男みたいな印象のレベルだよね なんだろう 金がかかるとかかからないとかではない、その手前で忌避感がある これはなんというか処女性というか保守性というか 「あー、こいつ日本や俺(共同体としての家族）に危機が迫ったら、気安く捨てて他国や他の男のところに行くんだろうな」 という思いを抱いてしまうからだろうか 事実、海外旅行経験ってのは 「あぁ、私はどこに行っても生きられるんだ！狭い日本の世界で生きなくてはいけない理由はないんだ！」 と思わせてしまうものがある気がするんだよな。 それは勘違いでもあり、女性にとっては勘違いではないというか、 男に対しては「客として訪れただけでなに勘違いしてるんだ。実際住んだら差別もあるし大変だよ。」って言えるんだけど 女だとけっこう
Pull Requestを小さくする戦略 - 開発チームのパフォーマンス向上のための第一歩 - Agile Journey
Agile Journeyをご覧の皆さん、こんにちは。ZOZOの御立田です。 私が所属する株式会社ZOZOは、「世界中をカッコよく、世界中に笑顔を。」を企業理念として掲げ、ファッションEC「ZOZOTOWN」、ファッションコーディネートアプリ「WEAR」などの各種サービスの企画・開発・運営や、「ZOZOSUIT」「ZOZOMAT」「ZOZOGLASS」などの計測テクノロジーの開発・活用をおこなっています。また、カスタマーサポート、物流拠点「ZOZOBASE」を運営しています。 ファッションコーディネートアプリ「WEAR」やショップスタッフの販売サポートツール「FAANS」を手がける、私が所属するブランドソリューション開発本部では、「開発生産性を3倍に」を目標に掲げ、多くの改善を進めています。 「開発生産性」をどのように定義するかには議論がありますが、まず私たちが向き合ったのは「仕事量の生産
なぜグローバルな Store を作るのか React アプリの設計論では、複数のコンポーネントで利用する値をどのように管理するか、というテーマがよく話題になる。 前提として、コンポーネントは小さく分割すべき、という考え方がまずある。 これは React に特有のものではなく、プログラミングの一般論として、ひとつひとつの関数は小さくするのがベストプラクティスだとされる。それには様々な理由があるが、単一責任の原則、疎結合、テスタブル、などがよく理由として挙げられる。 React のコンポーネントも同じで、肥大化しないように管理することが、保守しやすいアプリへの道だ。いかに適切な粒度でコンポーネントを分割できるかが、React を使いこなす上で重要となる。 だがコンポーネントを分割していくと、複数のコンポーネントで共通の値を扱う、という状況が発生しうる。 それにどのように対処するか、というのが、
こんにちは、AIチーム所属の@shidoです。CRE (Customer Reliability Engineering) 領域でMLを扱っています。 みなさんはPythonで本番コードを書くことについてどうお考えでしょうか。「研究/分析以外には使いたくない」「遅い」「動的型付け言語を本番用に使いたくない」といった声が聞こえてきそうです。 しかしながら機械学習サービス(または機械学習サービスのためのサービスなど)を作りたい場合、「学習に利用したPython用のライブラリを使用したい」「Pythonでやっていた分析と同じことを本番環境内でもやりたい」など、Pythonでバックエンドを実装したくなることがあると思います。 この記事ではtype hintsを付けながらPythonを書くことで、GoやJavaのようなサーバーサイドでよく使われる言語と可読性や保守性、場合によっては型安全性も同じレベ
DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 ドメイン層のオブジェクトを設計する際に、重要な基本方針があります。 ドメインモデルの知識を対応するオブジェクトに書く 常に正しいインスタンスしか存在させない この2つを守ると、非常に保守性の高いコードにすることができます。 以下、詳細に解説します。 ドメインモデルの知識を対応するオブジェクトに書く ドメイン知識(ルール/制約)を表現する実装を、ドメイン層のオブジェクトに寄せていきます。 この判断は、「ドメインモデル図に書かれた吹き出しの内容が、どの層で実装されているか」という基準に基づき行います。 この基準はコード設計の指針として非常に役立ちます。 設計の良し悪しというのはさまざまな基準があるため、レビューをしていてもいわゆる「俺の考えた最強の設計」同士が戦ってしまうことがあります。 しかし、「ドメイン知識はドメイン層に書く」と
![DDDにおけるドメイン層オブジェクト設計の基本方針[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/cf7c2977c5538fe370d1ff60a78958464a9e1f3f/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20220125%2F20220125074432.png)
CSS Gridを使用して、Webページでよく使用されるレイアウトやコンポーネントの実装で起きる問題を解決する実装テクニックを紹介します。 Modern CSS grid solutions to common layout problems by Kevin Pennekamp 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに 動的な中央揃えのレイアウト レスポンシブ対応のマルチコラムのグリッドシステム 2方向のカードレイアウト まとめ はじめに レイアウトと構成は、CSSにおいて最も難しいポイントに一つです。特にレスポンシブを考慮する場合は、なおさらです。最近では、メディアクエリを使用しない実装が増えています。これはさまざまなブレイクポイントを使用することで、CSSの保守性が低くなるからです。 しかし、CSS Gri
はじめに 新年早々に面白そうな記事を見つけました。ReactでのAPI呼出しを最適化するために「部分的にサーバサイドで実行するコンポーネントを作る」というもののようです。 あるいは去年の記事ですが気になってたものとしてBlitz.jsでReactベースのFWであるnext.jsに永続化層を持たせてRailsのようなFWにしようというアプローチもあります。 どちらの記事も書かれてる内容自体は分かる気がするものの 「それをフロントエンドでやる意味あるの？」 というのが拭えずイマイチ腑に落ちなかったんですが、単純に 「私と最前線でやられてる方々で期待してるものがたぶん違う」 という気がしてきたので、その辺を整理のために書いてみます。 注意書き Vue.js/Nuxt.jsは少し触ったことがありますが、React Server ComponentsやBlitz.jsを触ったことは無いです 「なんで
Terraform入門資料(v0.12.0対応) ~基本知識から設計や運用、知っておくべきtipsまで~ - Qiita
Terraform入門資料(v0.12.0対応) ~基本知識から設計や運用、知っておくべきtipsまで~AWSIaCTerraformインフラのコード化 はじめに 今日は体調がよろしくないので、大人しく勉強会用のTerraform入門資料をしこしこ作る。。オライリーのIaC本読み返しながら — nari@BOOTHで好評発売中「GoとAWS CDKで作る本格SlackBot入門」 (@fukubaka0825) October 6, 2019 こんにちは。[Wano株式会社] (https://wano.co.jp/)の[nari](https://twitter.com/fukubaka0825)と申します。 本日、WanoグループでTerraform入門をテーマとした勉強会を行いました。 その際使用した勉強資料を、Qiitaに一般公開いたします。 対象参加者(読者) インフラのコード化
大阪オフィスのYuiです。 ジョインブログでも書いた通り、今までは主にアプリケーションプログラマとして仕事してきました。 インフラ周りの知識は趣味でAWSを触ったりする程度だったので、クラスメソッドから内定が出てから、「とりあえず勉強しないと！」ということで技術書を読み漁りました。その期間で読んだ11冊をインフラ初心者の目線で紹介したいと思います。 インフラエンジニアの教科書 インフラエンジニアの教科書2 絵で見てわかるITインフラの仕組み 絵で見てわかるOS/ストレージ/ネットワーク インフラ設計のセオリー ネットワークはなぜつながるのか マスタリングTCP/IP 入門編 第5版 図解まるわかり セキュリティの仕組み 入門監視 Infrastructure as Code Raspberry Pi で学ぶコンピュータアーキテクチャ インフラ全般 インフラエンジニアの教科書 概要 インフラ
うちの会社には技術的なCXOとして、CTO、CIO、CISOの3パートがあります。何が違うねん、という話なのですが、ここにはのっぴきならない事情と仕組み化の流れがあって、3つのロールに分けました。このあたりの話を今日はつらつら書いてみたいと思います。 CTOの責任昔はCTOこそ全てのバランスを有し、社長よりも俯瞰したロールであれ、的な思想を持っていました。というのもマーケットを理解し、P/L、B/Sも理解しながら先日書いたG/Pを最大化しろ、また負債をいつどのようにどうやって減らしていくのかを考え、説明責任を果たし（その間機能開発力が落ちるかもしれないし）、実行しなければならない。これらは、短期的な収益と中長期的な投資をバランス良く、柔軟に判断しなければならない、という意味で、できりゃいいのですが簡単ではありません。特に簡単ではないのが、結局社長なり、トップの視点、視野にこの広大さと深さが
【ソフトウェア設計】モジュールをどう分割するのか？
はじめに 前々回や、前回に引き続き、ソフトウェア設計の指針に関する話をしたいと思います。 関数やクラス、そしてサービスなどシステムの塊の単位をモジュールと呼び、モジュールを作る事で、認知負荷を下げ複雑性と戦うという話をしてきました。では、モジュールは「いつ」分割するのが良いでしょうか？ また、他にも共通モジュールを不用意に作ってしまって苦労した人も多いのでは無いでしょうか？ 今回はそのあたりの話をしていきます。 TL;DR 以下があればモジュール設計を見直す 単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い 分割 is NOT 正義 - FizzBuzz Enterprise Edition 複雑性を排除するためにモジュール分割をすることは重
SOLID原則を理解し、JavaScriptで実践するためのガイド - deve.K's Programming Primer - プログラミング初心者のための入門ブログ
ソフトウェア開発者にとって、堅牢でテスト可能で拡張性があり、保守性の高いオブジェクト指向のソフトウェアシステムを設計することは重要です。 そこで登場するのがSOLID原則です。 SOLIDは、ソフトウェア開発中に生じるかもしれない特定の問題を解決するために5つの設計原則が組み合わさったセットです。 この記事では、SOLID設計の原則について詳しく学んでいきます。 具体的には、SOLID原則が何を意味しているのか、各部分がそれぞれ何を表しているのか、また実際のプログラム例を挙げながら現役のプログラマーが説明します。 さらに、JavaScriptを使ってこれらの原則を実装する方法も紹介します。 SOLID設計原則とは？ 単一責任原則 (SRP) Open/Closed原則 リスコフ置換原理 (LSP) インターフェース分離原則 (ISP) 依存関係逆転の原則 最後に SOLID設計原則とは？
転職・求人情報サイトのtype エンジニアtype 働き方 「プログラマーの本質に立ち返る時が来た」コードを書き続けてきたアラフォー世代に迫られるAI時代の自己変革【伊藤淳一×遠藤大介】 2023.04.18 働き方 プログラマー生成AIAICTO 過去に何度か訪れたAIブーム、ノーコードツールの普及……新しいテクノロジーが登場するたび、「プログラマーは不要になるのでは」という議論がなされてきた。 ただ、どこか現実味に欠けたその議論を何となく受け流してきたプログラマーにとっても、ここ最近の生成AIの進化は無視できないものがあるのではないだろうか。 特に、10年以上ものづくりの現場でコードを書き続けてきたアラフォー世代のプログラマーにとっては、これまでのやり方をどう変えるべきか、そもそも変えられるのか……という不安がよぎる。 そこで、開発現場の最前線で長年プログラマーとして活躍してきた伊藤淳
React＋Reduxによる状態管理とフロントエンドの技術的負債 ─ 長く継続するサービスのアプリケーション設計｜ハイクラス転職・求人情報サイト AMBI（アンビ）
React＋Reduxによる状態管理とフロントエンドの技術的負債 ─ 長く継続するサービスのアプリケーション設計 遷移なく表示コンテンツを変更できるシングルページアプリケーションでは、ページの状態管理が重要になります。現在はReactによるUI構築とReduxによる状態管理を選択しているChatworkは、jQueryなどの技術的負債と共存しながら、フロントエンド設計の見直しを重ねてきました。クライアントサイド・アーキテクトの火村智彦（@eielh）さんと、エンジニア採用広報の高瀬和之（@guvalif）さんによる解説です。 クラウド型ビジネスチャットツール「Chatwork」は、2011年3月にローンチされて10年以上にわたり開発を継続してきました。このように長く続くサービスがユーザーに価値を提供し続けるには、時間経過による変化に適応するため設計の見直しが必要になります。 しかし、設計を
タイミーのRailsアプリをシニアなエンジニアが採点したらだいぶ辛口だった - Timee Product Team Blog
この記事はTimee Advent Calendar 2023シリーズ 1の1日目の記事です。 はじめに こんにちは、タイミーでバックエンドエンジニアをしている須貝（@sugaishun）です。昨年は弊社でアドベントカレンダーに取り組んだか覚えていないのですが、今年はなぜかいきなり3トラックで臨むということで、非常に勢いがあるなと思いました。量と勢いで攻めていくところが弊社らしいなと感じています。全て完走できると良いですね。 さて私はその中のひとつのトップバッターということで、タイミーのRailsアプリケーションについて弊社のシニアなエンジニアたちと雑談した内容を座談会風にお伝えできればと思います。事の発端は弊社Slackのバックエンドエンジニアが集まるチャンネルで「タイミーのRailsアプリケーションの健康度はどのくらいなのか？」という会話をしたことでした。その時の私の感想は「人によって
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog
フロントエンドの"ちょうどいい"自動テストのはじめかた - Atrae Tech Blog
プログラマのためのビジネス・マナー講座 - megamouthの葬列
データエンジニアが事業成長をリードする。『SUUMO』のレコメンドAPIはこうして進化した - はてなニュース
ソフトウェアのアーキテクチャについて - threecourse’s blog
DDDでの要件定義〜実装までの流れについて解説します
このSRE本がすごい！2024年版 - じゃあ、おうちで学べる
インフラ担当がいない、地方で根深い「バックエンド軽視」の闇
「コードに早まってDRY原則を適用しないこと」とGoogleが呼びかけ
t-wada氏に聞く、テストを書き始めるための「はじめの一歩」 - レバテックラボ（レバテックLAB）
~OSSから学ぶ~ MVCフレームワークの保守性がモリモリ上がるクラス設計 - dely Tech Blog
新人プログラマ アンチパターン：原理原則多すぎて脳みそOOMエラー - Qiita
どのレイヤー（層）でトランザクションを実装すべきか
React の状態管理についての論点整理 - 30歳からのプログラミング
PythonとType Hintsで書くバックエンド | メルカリエンジニアリング
Webページでよく使用されるレイアウトに役立つCSS Gridの実装テクニックのまとめ
React Server Componentsに感じたフロントエンドの消失
インフラ未経験の私が内定から入社までに読んだ技術書11冊 | DevelopersIO
CTOの頭の中：技術と組織と牽制関係｜Shin Takeuchi
「プログラマーの本質に立ち返る時が来た」コードを書き続けてきたアラフォー世代に迫られるAI時代の自己変革【伊藤淳一×遠藤大介】 - エンジニアtype | 転職type