【感想】『マイクロサービスパターン 実践的システムデザインのためのコード解説』：前編 - Rのつく財団入り口
「未来はすでにここにある。まだむらなく流通していないだけだ」←グッとくる 最初のエモワードがSF作家ウィリアム・ギブスンの引用でイイ！ サイバーパンク2077遊んでみた～い……じゃなかった、CloudFoundry.comのファウンダーでありMicroservices.ioの運営者、経験豊富なソフトウェアアーキテクトであるクリス・リチャードソンさんによる『Microservices Patterns』の翻訳本。 タイトルのようにアーキテクチャパターンやデザインパターンのようにマイクロサービスをパターンで体系化し、サンプルストーリーを元にした事例やコード例、OSS紹介を交えつつマイクロサービスを実践する設計方法を探求した本となっています。 Java文化圏で長く活動してきた方とのことでサンプルコードはほぼJava、Springフレームワーク、ご本人らによるマイクロサービス用のフレームワークEv
排他制御の基礎の基礎
はじめに システムに存在するリソースには同時にアクセスしてはいけないものが多々あります。身近な例を挙げると、Ubuntuのパッケージ管理システムのデータベースがあります。aptコマンドの動作によってこのデータベースは更新されるのですが、同時に2つ以上のaptが動作できたとすると、データベースが破壊されてシステムが危機的状況に陥ります。 このような問題を避けるために、あるリソースに同時に1つの処理しかアクセスできなくする排他制御というしくみがあります。排他制御はOSが提供する重要な機能の一つです。 排他制御が必要なケース 排他制御は直感的ではなく非常に理解が難しいのですが、ここでは比較的理解が簡単なファイルロックというしくみを使って説明します。説明には、あるファイルの中身を読みだして、その中に書いてある数字に1を加えて終了するincというという単純なプログラムを使います。
要件定義～システム設計ができる人材になれる記事 - Qiita
はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間
要件定義～システム設計ができる人材になれる記事 - Qiita
はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間
SREやクラウドエンジニアが読むと良さげな本まとめ - Qiita
一年半ぐらい前にアプリケーションエンジニアからSREにコンバートした筆者が、いま役に立ってるなぁっていう本を紹介します。アプリケーションコードを書いてるときは下のレイヤの技術に興味なかったんですが、改めて勉強してみると楽しいです。 コンピュータシステム クラウド全盛とはいえ、コンピュータの仕組みはおさえておくと役立ちます。コレ系の本はわりと小難しいものが多いですが、個人的に楽しく読めた本を紹介します。 Raspberry Piで学ぶコンピュータアーキテクチャ Raspberry Piと銘打たれてますが、コンピュータアーキテクチャの歴史的な背景も踏まえて解説されています。プロセッサ・メモリ・ストレージ・ネットワーク・OS・プログラミングなど、コンピュータ単体の基本的な知識を学べます。 歴史をあわせて知ることができるため、知的好奇心がおおいに刺激され、楽しく読むことができます。この本が難しく感
仕事を任せられるエンジニアになるために意識してほしいこと - 食べチョク開発者ブログ
皆さんこんにちは。エンジニアの西尾です。 今日は仕事を任せられるようなエンジニアになるために意識してほしいことをまとめましたので、ここに公開いたします。 もともとは社内向けに公開したものです。 この文章は私がビビッドガーデンに入社する前の、前職での経験を踏まえて書いています。 今の食べチョクエンジニアが意識できていない、という話ではありませんのでご注意ください。 意識面 作業の見積もりができる 技術力が低い（コーディングができないなど）よりも敬遠されるエンジニアは、作業の見積もりができない方です。 第一線で活躍している方は、作業見積もりが他の方に比べて正確です。 見積もりをするためには、どういう設計をして、どういう機能を作り、どういう影響範囲があるのかを正しく理解する必要があります。 見積もりができないということは、作業内容を正しく理解できていない、技術的な困難性を理解していない、不確定要
ドメインオブジェクトの責務について - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 設計するとき、「このオブジェクトの責務は何だろうか？」とか「この責務に名前をつけるなら何か？」とか、責務について考えることがよくあります。そもそもその責務とは何か、という根源的な疑問について再確認すると共に、ドメイン駆動設計の観点からドメインオブジェクトの責務についても考えてみたいと思います。 責務とは 困ったときの古典引用。もう絶版になった、オブジェクトデザインという、書籍を紐解いてみましょう。DDDからの引用が多い書籍で、DDDの設計スタイルは、この書籍で紹介する「責務駆動設計(responsibillity-driven desi
クラウド設計パターン - Azure Architecture Center
これらの設計パターンは、信頼性の高い、スケーラブルで安全なアプリケーションをクラウドに構築するために役立ちます。 パターンごとに、そのパターンで対処する問題、パターンの適用に関する考慮事項、Microsoft Azure に基づいた例を説明します。 ほとんどのパターンには、Azure でのパターンの実装方法を示すコード サンプルまたはスニペットが含まれています。 ただし、パターンのほとんどは、ホストが Azure か他のクラウド プラットフォームかにかかわらず、分散システムに関連しています。 クラウド ワークロードでは、分散コンピューティングに関する誤解が生じやすくなります。 クラウド設計に関する誤解の例を次に示します。 ネットワークは信頼できる 待機時間はゼロである 帯域幅は無限に存在する ネットワークはセキュリティで保護されている トポロジが変更されることはない 管理者は 1 人しかい
書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだので大事なポイントを自分のためにまとめてみた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだ。 なぜソースコードを綺麗に書くのかから始まり、オブジェクト指向、コンポーネントの原則、アーキテクチャと体系的にまとまっている良い内容だった。 この記事では、本書の内容の引用を踏まえながら自分の考えの振り返りをまとめたものである。 実際にGoで実装したりしたので、なにか間違いなどあれば指摘していただきたい。 クリーンアーキテクチャの書籍を読んだのでAPIサーバを実装してみた 対象読者 ・Clean Architecture 達人に学ぶソフトウェアの
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
リスクを見積もれる人、見積もれない人 - Feel Like A Fallinstar
システムでもウェブサイトでも共通ですが、何かしらプログラムというか制作を行う場合に、見事にプロジェクトを炎上させてしまう人と粘って何とか持ちこたえて納品に間に合わせる人が必ず出てきます。 もちろんそこにはスキルの差とか経験とか色んなものが絡んでるのですが、もうひとつ大きいと思うのが、いい意味で「臆病に」なれる力なんじゃないかと思います。 スケジュールを、希望ベースで引く人がいる 制作にはトラブルがつきもの。 相思相愛なんじゃないかと思うくらいの頻度で制作をしたらトラブルがやってきます。 にもかかわらず、こんなスケジュールを引いてしまう人が結構います。 ○月○日までにクライアント確認が取れて、そこから1週間で設計できれば、ちゃんと間に合います いや、それってあなたの勝手な仮定がうまく行くことが前提ですよね？ そんなに世の中自分の思い通りには動いてくれません。 大体こういうことをすると、土日に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア設計のすすめ
Design paper of the home server（公開版）