タグ

Architectureに関するatsushifxのブックマーク (14)

  • アーキテクチャレベルで依存性を逆転させたら最高だった話

    はじめに LITALICO の @katzumi です。 2020 年に LITALICO へ Join して以来、ずっとレセプト業務の開発に携わってきました。 レセプト業務は複雑なドメインゆえミスが許されず、さらに3年に一度の大きな報酬改定があり、ロジックが大幅に変わります。 その改定作業は情報公開から実装完了までの期間が約 3 ヶ月と短いです。また、年々複雑化するシステムに対応する必要があります。 その複雑な業務に立ち向かった内容を過去にも以下の内容で開発業務の記事を書いていました。 今年 2024 年は法改正の年になっており、取り組みの結果、その後どうなったのか?を振り返っていきます。 今回も壮絶だった法改正 私自身の大規模法改正の経験が今回で 2 回目となります。 チーム構成としては私ともう一名を除いて前回の 2021 年度法改正を経験したメンバーがいませんでした。前回は 3 種類

    アーキテクチャレベルで依存性を逆転させたら最高だった話
    atsushifx
    atsushifx 2024/12/19
    かっけえ。指定年度のレセプト業務をコアコンポーネントにして、パターンで繋いでる。DDDの実践としても一流の資料
  • Guide to "kurashiru android" app architecture vol.1 概要編 - dely Tech Blog

    はじめに こんにちは。クラシルのAndroidアプリチームのテックリードのうめもりです。 android-developers.googleblog.com 12/14に新しいアプリアーキテクチャガイドがAndroid公式からアナウンスされました。読まれた方もいらっしゃると思いますが、非常によくまとまったアーキテクチャガイドであり、新しくアプリを作る際も、既存のアプリのアーキテクチャを整理する際にも役に立ちそうな文章です。 クラシルのAndroidチームは去年の2月にAndroidアプリをリアーキテクチャしたのですが、そのアーキテクチャがアプリアーキテクチャガイドと似通った個所が多く、クラシルのアプリアーキテクチャを説明するのにもちょうど良さそうな文章だと思いました。 ですので、今回は新しいアプリアーキテクチャガイドとほとんど同じ構成で、クラシルのアプリアーキテクチャについて解説してみよう

    Guide to "kurashiru android" app architecture vol.1 概要編 - dely Tech Blog
  • 【後藤弘茂のWeekly海外ニュース】 GPUのメモリ帯域を1TB/secに引き上げるHBMが準備完了へ

    【後藤弘茂のWeekly海外ニュース】 GPUのメモリ帯域を1TB/secに引き上げるHBMが準備完了へ
    atsushifx
    atsushifx 2014/12/22
    SAMSUNGが次世代メモリ規格としてHBMを採用したと。高速なメモリ転送を必要とするのはGPUだけではなくネットワーク機器やHPCでもで市場が広くなりそうなほうを選択したと。PCなどのバスもHBMにあわせた新しいのが出そう
  • Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ

    @@ -0,0 +1,37 @@ +http://martinfowler.com/bliki/SacrificialArchitecture.html + + +会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたはどんな気持ちにするだろう? + +多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 + +ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 + +私たちは長命なソフトウェアとして偉大なコードを思

    Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ
  • パイプとフィルタ ~ソフトウェア工学における有用なアーキテクチャ~ | POSTD

    パイプライン は、最近のソフトウェアエンジニアリングにおいて、非常に便利な(そして驚くほど活用されていない)アーキテクチャパターンです。ソフトウェアでデータの流れを制御するためにパイプとフィルタを用いる考え方は、最初のUNIXシェルが作られた1970年代からあります。もしターミナルエミュレータでパイプ” | ”を使ったことがあるなら、”パイプとフィルタ”を活用できていることになります。以下の例を見てみましょう。 cat /usr/share/dict/words | # Read in the system's dictionary. grep purple | # Find words containing 'purple' awk '{print length($1), $1}' | # Count the letters in each word sort -n | # Sort l

    パイプとフィルタ ~ソフトウェア工学における有用なアーキテクチャ~ | POSTD
    atsushifx
    atsushifx 2014/11/20
    see https://uec.usp-lab.com/ 日本だとここがシェルスクリプトで良品計画のシステムを構築したはず
  • テスト駆動開発(TDD)はもう終わっているのか? Part 2 | POSTD

    前編はこちらです 4:テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が

    テスト駆動開発(TDD)はもう終わっているのか? Part 2 | POSTD
    atsushifx
    atsushifx 2014/10/08
    プロジェクトや言語、フレームワークによって代わるので場合によるというKent Beckの言葉は正しい。問題はリファクタリングが普及していないことだろう
  • マイクロサービスとSOA

    ここ数年,小規模なサービススイートで構成されたアーキテクチャを表現することばとして"マイクロサービス"という用語が拡がっている。QCon San Francisco 2012でもThoughworksのJames Lewis氏が,このテーマでプレゼンテーションを行った。氏はMartin Fowler氏と共同で,同じテーマの記事も書いている。これに対して,マイクロサービスは一部の人々が考えるような新しい概念ではない,所詮はSOAの焼き直しに過ぎないという意見を持って,最近この議論に加わったのがSteve Jones氏だ。その中で氏は,Lewis氏とFowler氏の記事の分析を順に追いながら,両氏のマイクロサービスの定義をOASIS SOA RM(Reference Model, 参照モデル)と比較する,という作業を行っている。 サービスによるコンポーネント化: OASIS SOA RMによる

    マイクロサービスとSOA
  • 「技術的負債」をコントロールする定量評価手法への期待

    「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - delirious thoughtsにて、追記でコメントいただけたので、外野として好き放題言わせてください。すばらしいスライドありがとうございます&いつもすみません。 僕が興味がもつとすると、それは「技術的負債」の定量評価手法についてです。 なぜ、そういう前提を置くかと言うと、それは、たとえばKrutchenによる「技術的負債」の定性評価は、とてもわかりやすいものの、技術を取捨選択するツールとしては使えないからです。 スライドでは、技術評価における将来の不確定性を象徴する問題としてSSDの普及前夜にシャーディングをがんばって実装してしまう例をご紹介いただきましたが、実際、そのような不確実性を織り込んだ正しい決定を我々が日々のエンジニアリングで下すことができているのか疑問に感じるこ

    atsushifx
    atsushifx 2014/03/18
    アジャイラー的には先送りとスモールステップといいたいけどアーキテクチャやフレームワークの部分は難しい。レガシー化は避けられない以上、ドキュメントやAPIの整備といった調達コスト削減が一番の解だと思う
  • lambda-architecture.net

    lambda-architecture.net 2024 著作権. 不許複製 プライバシーポリシー

  • Ansibleのアーキテクチャー: 構成管理を超えて — そこはかとなく書くよん。 ドキュメント

    Ansibleのアーキテクチャー: 構成管理を超えて¶ すでに2月ほど経っていますが、2013/11/29にAnsible WorksのCTOであるMichael DeHaanさんが、 Ansible’s Architecture: Beyond Configuration Management という記事を書いています。 この記事はAnsibleのアーキテクチャを説明するのにとても良い記事だと思いましたので、DeHaanさんの許可を得て、翻訳したものを公開します。 ただ、いかんせんこの人は一文が長いのと言い回しが詩的で意味が取りにくいのとで、うまく訳せていないところが多々あります。間違っている箇所がありましたらご指摘ください。 Ansibleのアーキテクチャー: 構成管理を超えて¶ Ansibleがなにものなのか、というあまりよろしくない議論があり、とても奇妙 だったので、ここでAnsi

  • その選択、ちょっと待った!NoSQLデータベースへ乗り換える前に検討すべき3つのポイント

    最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い!!絶対にだ!!」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの

    その選択、ちょっと待った!NoSQLデータベースへ乗り換える前に検討すべき3つのポイント
    atsushifx
    atsushifx 2013/12/01
    DBエンジニアとか設計をするなら当たり前の話。NoSQLは個人認証のような、正規化がほとんど必要ないけど大量のデータを裁く必要のあるデータを使うための技術だから使いどころが違う。
  • 日本語テストメソッドについて

    「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事(コミット、ブランチ、マージ、リベース)について解説します。

    日本語テストメソッドについて
    atsushifx
    atsushifx 2013/09/15
    そもそもスライドのメソッド名がいけてない。後半で指摘しているようにnamespaceなどを用いてテストを適切に書けばすむ。テストコード自体の読みやすさ、Readbilityなどの品質が問題で、日本語にすれば解決するわけじゃな
  • スケーリング Dropbox

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    スケーリング Dropbox
  • 超高速開発 体験談 - 職業プログラマの休日出勤

    数日前に日で話題になっていた「超高速開発」について記事を残したいと思います。ニュース記事 超高速開発はスクラッチ開発の3倍から10倍の開発効率が条件、競合するベンダ13社が利害を超えて「超高速開発コミュニティ」を設立 - Publickey の はてなブックマーク に寄せられたコメントを見る限り「わず嫌い」な方が非常に多いように見受けられたので、これは体験談の需要は高そうだなと思い、書き始めた次第です。 ネタ記事を書いた直後に真面目な記事を書くのは、少し気が引けるものではありますが…。 私は2006年初頭から2012年初頭まで、インフォテリア社製の開発ツール「Asteria」を使用していました。この製品には冒頭で紹介した記事からもリンクが張られていますが、超高速開発を実現するためのツールの一つです。もちろん、私がAsteriaを使用していた頃は「超高速開発」などという言葉は見たことも聞

    超高速開発 体験談 - 職業プログラマの休日出勤
    atsushifx
    atsushifx 2013/08/11
    コード生成ツールはコードを修正したときの相性の悪さが問題。それに自動化できるならフレームワークをつかうなり、リファクタリングしてコードをまとめることができそう。あとは現在はリリースの自動化が重要
  • 1