Don't DRY Your Code Prematurely
TotT 98 GTAC 61 James Whittaker 42 Misko Hevery 32 Anthony Vallone 27 Code Health 27 Patrick Copeland 23 Jobs 18 Andrew Trenk 12 C++ 11 Patrik Höglund 8 JavaScript 7 Allen Hutchison 6 George Pirocanac 6 Zhanyong Wan 6 Harry Robinson 5 Java 5 Julian Harty 5 Alberto Savoia 4 Ben Yu 4 Erik Kuefler 4 Philip Zembrod 4 Shyam Seshadri 4 Adam Bender 3 Chrome 3 Dillon Bly 3 John Thomas 3 Lesley Katzen 3 Ma
実況中継シリーズ Vue.jsで実現するMVVMパターン Fluxアーキテクチャとの距離 - Re.Ra.Ku アドベントカレンダー day 13 - Re.Ra.Ku tech blog
前説 丸山です。Re.Ra.Ku. アドベントカレンダー13日目の記事です。前日はiOSアプリのUIをコードで書いてみる話でした。明日はおそらくScalaの話になると思います。 さて、以前も話題にしましたが、builderscon2016が先日開催されました。チケットは3hでSOLD OUT。プラチナチケットと化した参加権ですが、発表する側ならば実質無料で参加し放題！これはいっそ申し訳ないレベルでは！？ というわけで、せっかく発表したのでその内容をなるべく多くの手段で共有したい。そう思い、今回も実況中継シリーズを弊社テックブログで行います。実況中継シリーズというのは、プレゼンをブログで再現するアレです。なお、実際のプレゼンは動画になってYoutubeにアップロードされております。builderscon公式サイトのセッション詳細ページからもご覧いただけますので、よろしければそちらも合わせてご
レイヤードアーキテクチャを振り返る - Sansan Tech Blog
こんにちは、Sansanプロダクト開発部の清水です。 ある程度のアプリケーションの大きさだと当たり前に使われる事が多い「レイヤードアーキテクチャ」の自分が考える設計のポイントや、実際に運用する際のポイントについて書いてみようかと思います。 基本的な話なので「今更かよ」って感じがしますが、実際に設計、運用する際には様々な考慮事項のあるものだと思うので、知ってる人にとっても復習にでもお役に立てればと思います。 そもそもレイヤードアーキテクチャって何? 概要 一言でいうと、アプリケーションを作る際にそれを構成する部品を、それぞれ責務が定義された論理的なグループにまとめて整理し、それぞれのグループ間のやり取りの仕方を決めておこうという事です。 このグループ間のやりとりにおいて、一方向かつ隣接するグループとしかやりとりを行えないようにする事が多く、層状になるのでレイヤードアーキテクチャと呼ばれます。
Cloud SpannerとCloud Pub/Subとで実装するTransactional outboxパターン | メルカリエンジニアリング
Credit Designチームでバックエンドエンジニアをしている@iwataです。主にメルペイスマート払い関連の開発をしています。 Merpay Advent Calendar 2021 の21日目の記事をお届けします。 メルペイスマート払いの開発においてもご多分に漏れず、マイクロサービスアーキテクチャを採用しています。マイクロサービス開発において避けては通れない問題として、分散トランザクションによるデータ整合性の担保があります。メルペイスマート払いマイクロサービスでは一部APIにおいて整合性担保のために、Transactional outboxパターンを用いた実装をしています。 本記事ではテーブル設計を含めたその実装の詳細を紹介したいと思います。 tl;dr Transactional outboxパターンを使ったSpanner, Pub/Sub間での整合性担保 Spannerならでは
DI（Dependency Injection）に関するメモ - Shin x Blog
PHPの現場 にて、DI 談義を行うので、頭を整理しておくためのメモです。 DI についてきちんと知りたいのであれば、参照に挙げたリンク先に有用な記事があるので、そちらを参考にして下さい。 PHP を念頭に置いてますが、Java など他言語でも大枠は同じだと思います。この内容は、いずれ整理するかもしれませんし、そのままかもしれません。 DI という言葉 「DI」が差す意味合いが、依存オブジェクトの注入だけなのか、DI コンテナによる注入を含んでいるのか、DIP まで意識しているのかが、人やコンテキストによって違っていそうで、そこを揃えてから議論しないと。— Masashi Shinbara (@shin1x1) May 19, 2017 DI について話す時に、何を差すのかが異なると話が噛み合わない。そこで、それぞれに名前を付ける。 DI パターン = 依存オブジェクトを注入することを差す
マイクロサービスアーキテクチャをあきらめないための、モノリスで始めるアーキテクチャテスト / #jjug_ccc_b #ccc_b8 / JJUG CCC 2020 Fall
JJUG CCC 2020 Fall（ https://ccc2020fall.java-users.jp/ ）の登壇資料 プロポーザル https://confengine.com/jjug-ccc-2020-fall/proposal/14766 当日のタイムライン https://twitter.com/search?q=(jjug_ccc_b%20OR%20archunit)%20since%3A2020-11-07_17%3A00%3A00_JST%20until%3A2020-11-07_18%3A00%3A00_JST&f=live 登壇レポートブログ https://tech-blog.rakus.co.jp/entry/20201225/jjug
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブジェクトが小さな機能単位で生まれて統一感が無くなる。 状態を持つ値が大量に散在して副作用を起こしバグを生む。 これらの問題の結果、小さな単位ごとに個人のノウハウで"良い"設計がされ、機能を追加しようとしたときにどういう方針で行えばよいか分からなくなる。 解決
メールのトランザクション設計 - Qiita
3日目で息切れしてきたので、今日は軽めな内容です。 データベース更新とメール送信の一貫性 商品購入の完了ページなど、よくデータベースを更新して、メールを送信してデータベースをコミットするという仕様があります。 データベース登録出来てないのに、完了メールを送るわけにはいかないので、これらを1トランザクションにできなきゃいけません。が、SMTPプロトコルにコミット/ロールバックの概念はありません。 さて、どう設計しましょうか、というお話です。 方式 A.DBトランザクション後にメールを送る 同一トランザクションはあきらめ、データベースを先にコミットし、その後でメールを送る、という設計です。 メール送信でエラーになったら、データベースには書き込めているので、メールだけ再送するように仕組みを作ったりします。 以下のようなイメージです。 public class OrderController {
脱RESTful API設計の提案
3. フロントアプリ スタンドアロンゲームの構成要素(例) グラフィック アニメーション サウンド レベルアップ戦闘ルール 評価・報酬 シナリオ ゲームシステム・基本ルール 演出 セーブ・ロード 全ての機能はフロントアプリに実装される 4. ソーシャルゲームになって構成要素が増えた 各種 マスタリソース 追加シナリオ イベント配信 アカウント 引き継ぎ 会員登録 多端末 同時利用 運営から アカウント凍結 アプリ上データ アカウント関連機能 会員 セーブデータ データ管理機能 各種ログ管理 フレンド 登録管理 （準）課金機能 その他運営機能 連続ログイン 報酬 課金管理 アイテム ガチャ管理フレンド連携 報酬管理 報酬付与 グラフィック アニメーション サウンド レベルアップ戦闘ルール 評価・報酬 シナリオ ゲームシステム・基本ルール 演出 セーブ・ロード どの機能をゲームサーバに持たせる
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
Kong を使った Microservices Architecture API Gateway Pattern の実現方法 - Qiita
Kong を使った Microservices Architecture API Gateway Pattern の実現方法Dockermicroservices この記事は、Kong - API Gateway Pattern速習会＠Wantedlyの資料として作られたものです。 サービスが大きくなるとやりたくなってくること より高速な実装に置き換えたい APIを複数のサービスに分けて開発したい マイクロサービス化 何故マイクロサービスか James Lewis/Martin Fowlerの"Microservices"日本語訳 State of the Art in Microservices by Adrian Cockcroft - Qiita いろいろ理由は言われてるけど... 人が扱える大きさの限界 「明確な」境界が必要 名前空間やスコープなど、プログラミング言語でも使用してい
若手が知らないメインフレームと銀行系システムの歴史＆基礎知識
若手が知らないメインフレームと銀行系システムの歴史＆基礎知識：FinTech時代、銀行系システムはどうあるべきか（1）（1/2 ページ） 本連載では、銀行系システムについて、その要件や歴史を整理しつつ、スマートフォンを使う銀行取引やブロックチェーンなど、新しい技術が及ぼす影響を考察していきます。初回は、メインフレームと銀行系システムの歴史と基礎知識についてです。 「Finance（金融）」と「Technology（技術）」を足した造語である「FinTech」。その旗印の下、IT技術によって金融に関わるさまざまな業務や処理を利便化し、ビジネスの拡大を図る動きが国内金融業界から大きな注目を浴びています。特に金融業界の中心である“銀行”が運用するシステムについては話題に事欠きません。 例えば、ブロックチェーンによって銀行の勘定系システムが変わるという話があれば、2016年10月から日本でも利用可
綺麗なAPI速習会 - Qiita
Wantedly Engineer blogに本速習会資料を閲覧向けに再編しました！ ぜひご覧いただけると幸いです！ 本記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可
マイクロサービスアーキテクチャにおけるオーケストレーションとコレオグラフィ - Qiita
マイクロサービスアーキテクチャの4章にオーケストレーションとコレオグラフィという話があります。 マイクロサービスを使ってアプリケーションを組み立てる側の、サービスの呼び出し方の違いです。 「マイクロサービス的に作ってるよー」というシステムでも、ここに特に疑問を持たず、ふつうにWeb APIたちを呼び、受け取ったデータでHTMLをレンダリングするというオーケストレーション方式で作られているのが多いのではないでしょうか? Sam Newmanは、それだと呼び出されるサービス側がドメインモデル貧血症になりがちで、呼び出す側にロジックが集まっていくことになると、書籍の中で述べています。 いったいどういうことでしょうか? 書籍中の例をちょっと変えて考えてみます。 マイクロサービスアーキテクチャでECサイトを作る(オーケストレーション編) ECサイトをマイクロサービスアーキテクチャで作ることを考えてみ
Isomorphic Survival Guide
isomorphic tokyo meetup http://nodejs.connpass.com/event/13363/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
議論によるソフトウェアアーキテクチャの拡張 - アドバイスプロセス
モノリスの分解において、マイクロサービスは必然ではない - QCon LondonにおけるSam Newman氏の講演より
Log in with Atlassian account
Webアプリケーションのキャッシュ戦略とそのパターン / Pattern and Strategy of Web Application Caching
RIA Architecture