逆引き！GoFデザインパターン入門 の研修コースに参加してみた | SEプラス 研修 Topics
今回の研修参加レポートは↓です。 逆引き！GoFデザインパターン入門 “オブジェクト指向を理解する” の続きでオブジェクト指向の実践的な活用パターンを学ぶコースです。 Javaプログラミング入門 (2) オブジェクト指向を理解する の研修コースに参加してみた “実践的な活用パターン” というと銀の弾丸っぽく聞こえるのですが、講師の矢沢さんから地味な話なんですよ、と冒頭に話があったように、地味でした。(笑) ただ、有名なアルゴリズム同様、知らないと思いつかないテクニックばかりで、実装上、どこに気をつけると依存性を排して書けるのか、幾つものヒントがある内容でした。 また、ご参加の方もオブジェクト指向プログラミングをもっと上手く書きたい、現場のコードで時折見る public class AdpterHoge ってなんだろう、のような疑問をお持ちの方がお集まりのようで、とても実装寄りの質問が多いコ
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
GoF デザインパターン チートシート - Qiita
ここまで読んでくださった皆さんに、ちょっとしたクリスマスプレゼント。マンガでわかる GoF デザインパターン 23 種チートシートです。これでもうデザインパターンは完全にマスターしましたよ。やったね! (注: ここからはあとがきポエムです) ところでみなさん、せっかくデザインパターンを学んだので、これを使ってプログラムを書こう、チートシートがあるからなんでも書けそうだぞ、なんて思っていませんか。ダメですよ。そんなことしたら 2000 年前後に起きた失敗を繰り返してしまいます。 実は GoF のデザインパターンは、ビジネス的には成功したけど、教育には失敗しました。最初に出版された本に「オブジェクト指向における再利用のための」という肩書が付いていましたが、これが本当に良くなかった。 あの頃 (ポール・グレアムが LISP と Ruby を褒めるまで) は、「オブジェクト指向様こそが良い設計のす
食べログの大規模なレガシーシステムを段階的に改善していく取り組み - Qiita
こんにちは、食べログシステム本部長の京和です。 今年の4月から本部長になりました。さらに4月に娘が生まれました 本エントリでは食べログで1年を通じて取り組んだ、大規模なレガシーシステムの段階的な改善について紹介します。[翻訳] Shopifyにおけるモジュラモノリスへの移行 に続いて2記事目のアドベントカレンダーになります。 どのように段階的に進めるか 食べログは今年で15年目のサービスで、Railsになってからは13年が経過しています。これだけ歴史があればあちこちにガタが来ているのは当然で、無数にある課題に対してどこからどのように取り組んでいくかを最初に決める必要がありました。 まず最初の前提として以下のように考えました。 既存のビジネスや開発を止めるような悪影響を与えない。むしろなるべく早くポジティブな影響を与えていきたい。 これだけ歴史のあるシステムを改善していくのは長い時間がかかる
バッチ処理について考える - Qiita
TL;DR ひとくちにバッチといっても色々ある 夜間バッチをもう作るな オンラインバッチはSQL以前にDB設計がんばれ はじめに Twitterのタイムラインで以下のようなツイートが回ってきました。 バッチ処理をみんな舐めてかかったり、ショボイとか思ってる人多い印象なんだけれども、数十万～数千万件規模のデータを処理したことあるのかな。テンプレ通りのコードじゃ動かないよ？ネットに本にも答え載ってないよ？低レイヤも意識しないと動かないよ？ 2020年1月10日 ツイートされたわだっしーさんの意図がどこにあるかは確認してないですが、極限の世界でテンプレート的な処理では対応出来ないのはあるよな、と思いつつもある程度はバッチの作法としての書き方があると思っています。 このツイートとその関連ツイートを読みながら、そういえばバッチ処理に関して書いてある記事はあまり見ないなぁ、とおもったので他のネットや本
バックエンドに興味を持つ学生にオススメするクラウド系メインのリンク10選 - y-ohgi's blog
概要 学生氏に適当なことを言い過ぎ反省しているので、バックエンドのいま覚えてる良かった記事の共有です。 まっさきにみるやつ Web 系エンジニアの学習ロードマップです。 とりあえずこのロードマップにのってる"紫のチェックマーク"がついたものを順番にこなしていけば良いとおもいます。backend のロードマップを紹介しましたが他にもfrontend やdevops などもあります。しかも毎年更新してくれます。 この記事はこのロードマップ以上の情報は提供できません。おわり。 roadmap.sh その他 エンジニアリングについては雑に調べると歴戦のエンジニア各位が紹介してくださってるので、クラウド系をメインに紹介します。 一般的なやつ タイトルママ。 バックエンドというよりエンジニアリング全般。 japan.googleblog.com 技術記事に特化したキュレーションサービスです。 追いたい
Amazon Web Services, Inc.
AWS をはじめる 10 のことシリーズ「AWS でアーキテクチャ設計を検討する上で知っておくべき 10 のこと (+1)」 の資料ダウンロードサイト（動画解説付き）です。AWS ではクラウドのメリットを最大化させるために 11 のアーキテクチャ設計のベストプラクティスをご用意しています。本資料では、1 つ 1 つのベストプラクティスを分かりやすく解説し、皆様のクラウドへの最適化をご支援します。※本ウェビナーは2020にレコーディングされたものです。 ご利用できるもの 下記についての解説資料および、オンデマンド動画 スケーラビリティを確保する 環境を自動化する 使い捨て可能なリソースを使用する コンポーネントを疎結合にする サーバではなくサービスで設計する 適切なデータベースソリューションを選択する 単一障害点を排除する コストを最適化する キャッシュを使用する すべてのレイヤーでセキュリ
Webの仕組みをうまくつかう
ここ最近はクライアントルーティングで書くことが増えた。それにともなってWebアプリケーションの知見はブラウザ上に多く含まれるようになり、厚みが増した。 それまではデータモデリングからはじめ、パーマネントURLをつくり、サーバサイドルーティングをざっくり決め、画面要素を洗い出しつつ便利なツールを重ねていくという進め方をすることが多かった。今では画面要素でできる選択肢が多くあり、サーバサイドにDBを自前でつくらなくてもよくなり、APIも外部APIとの連携のなかでの1パーツとしての役割をうまく見出せばよくなった。工夫の勘所が変わり、UIに集中できるようになり、業務用件をUI主体で実現するスピードがすごくあがった。Webの仕組みでここまでユーザフレンドリーで、あらゆるシステムがWeb基盤の上で作れるなどと30年前には誰も考えられなかったのだろうか。 URLはクライアントサイドのための何かしらのKe
マイクロサービスアーキテクチャをあきらめないための、モノリスで始めるアーキテクチャテスト／JJUG CCC 2020 Fall 登壇レポート - RAKUS Developers Blog | ラクス エンジニアブログ
この記事は アーキテクチャテスト Advent Calendar 2020 - Qiita の 25 日目のエントリです。 qiita.com こんにちわ。株式会社ラクスで「楽楽労務」を開発している @kawanamiyuu です。遅くなりましたが、先月開催された JJUG CCC 2020 Fall の登壇レポートです。 イベント概要 プロポーザル 登壇資料 登壇に対する反応 登壇を終えて イベント概要 日時2020 年 11 月 7 日 (土) 開催形式オンライン（事前録画放送＋リアルタイムQ&A） 公式サイトhttps://ccc2020fall.java-users.jp/ タイムテーブルhttps://confengine.com/jjug-ccc-2020-fall/schedule タイムライン#jjug_ccc since:2020-11-07_00:00:00_JST u
DDDとORMのEntityを混同しないための考え方
２つの ”Entity” ある種の ORM では RDB のテーブルスキーマモデルとなるクラスのことをEntityと呼んでいます。例えば PHP のDoctrineや TypeScript のTypeORMなどがそうです。 そういった ORM を採用したプロジェクトで DDD に取り組むとき困るのが用語の衝突です。ORM の Entity は RDB のための定義を含むため当然 DDD の Entity とは異なるのですが、なにぶん同じ名前なので混同してしまいがちです。 本記事では両者を混同せず扱うための考え方をまとめます。 Entity の定義 まずは定義から確認します。 DDD での定義 エヴァンス本の日本語訳から引用します。 主として同一性によって定義されるオブジェクトはエンティティと呼ばれる Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edi
Connascence：コードの結合度を測るもうひとつの指標 - snoozer05's blog
構造は、凝集度が高く、結合度が低い場合に安定する - Larry Constantine 私たちプログラマーは、その仕事において、できる限り良いコードを書きたいと考えます。しかし、「良いコードとは何か」という問いに対して答えるのは、そう簡単ではありません。「良さ」を測るには、「何に対して」という軸が必要であり、その軸は一つではなく、さらには、コードを書いている状況に応じて、大事にすべき軸が変わるということも往々にしてあるからです。そうしたとき、私たちは何らかの尺度でもってコードを測って、そのときのコンテキストにおいて良い落とし所を定めます。 そのようなときに、コードの品質を測る軸としては、有名なものには「凝集性（Cohesion）」と「結合度（Coupling）」があります。ここでは、そのうちの「結合度」を測る指標の一つとして「コナーセンス（Connascence）」を紹介します。 コード
レイヤードアーキテクチャ - kawasima
POSAでの定義 レイヤードアーキテクチャを、体系だって書いたのは「Pattern-Oriented Software Architecture, Volume 1, A System of Patterns」だろう。まずはその原典に立ち返って、レイヤードアーキテクチャとは何かをみてみる。 コンテキスト ソースコードの変更がシステム全体に波及させたくない。それが1つのコンポーネントに閉じられ、他に影響を与えないようにすべきだ。 インタフェースは安定している。標準化団体によって規定されている場合もある。 システムの一部は交換可能である。コンポーネントはシステムの他の部分に影響を与えることなく、実装を入れ替えることができる。 現在設計しているシステムと同様の下位レイヤの課題をもつ他のシステムを、将来構築することがあるかもしれない。 理解のしやすさと保守性のために同じ責務はグルーピングしておきた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
杉本啓 on Twitter: "継承に関しては90年代から危うさが指摘され「継承よりコンポジション」と言われてきた。 現代ではそれを踏まえて、継承する場合は、それを意図した抽象基底クラスを作り、継承不可のメソッドはfinalとするという風になってきていると思うの… https://t.co/oSWzvg2F7a"
「なんとなく理解した」で終わりやすいMVCをゲームにたとえて解説する【プログラミング】
LinkedIn、システムの複雑性低減のためにLambdaアーキテクチャを廃止
地下アイドルとアイドルオタクを疎結合にしてみたら、夢も希望もなくなった〜デザインパターンのObserverを考える〜 - Qiita
system-design-primer#system-design-interview-questions-with-solutions
shiodaifuku.io
shiodaifuku.io
WEB アプリケーション設計入門 / Introduction to web application design
