Developing evolutionary architecture with AWS Lambda | Amazon Web Services
AWS Compute Blog Developing evolutionary architecture with AWS Lambda This post was written by Luca Mezzalira, Principal Solutions Architect, Media and Entertainment. Agility enables you to evolve a workload quickly, adding new features, or introducing new infrastructure as required. The key characteristics for achieving agility in a code base are loosely coupled components and strong encapsulatio
最近、DRY原則のやりすぎや安易な共通化は良くないと聞きます。しかしその解決策が後のことや目的、ドメインを考えるなど曖昧です。明確な基準はないのですか？
回答 (9件中の1件目) 単一責任の原則です。 Clean Architectureでは次の言い方をしています。 > 単一責任の原則(SRP)は、アクターの異なるコードは分割するべきという原則だ。 悪い例として出てくる図ですが、まずEmployeeクラスに3つのメソッドがあって、CFO、COO、CTOがそれぞれ使います。 それに対して「コードが重複しているから」とアルゴリズムを共通化しました。 そしてcalculatePayを使うCFOチームがregularHoursのアルゴリズムを変えました。するとreportHoursを使うCOOチームの使うデータが壊れました。 この単一...
はじめに 最近、ゼロスクラッチからiOSアプリの設計・開発をする機会がありまして、その構成を色々妄想しております そこで、ゼロからスクラッチでiOSアプリ開発をやるとしたら、どういう構成やツールを使うかなー、というのを妄想していて、自分なりの考えをまとめてみました。 誰向けの記事？ アプリ開発の勉強を一通り終えたんだけど、実際にアプリをゼロから作る場合にどういう作りにすればいいか悩んでいる初心者の人 ゼロから新しいアプリの設計を検討している人 既存アプリの構成を変更したい人 アーキテクチャ アーキテクチャ選定については、アプリの開発規模にもかなり依存すると思います。 規模が小さく、開発者の人数も少ないアプリなら、 MVC（Model - View - Controller） MVP（Model - View - Presentor） あたりが候補になるでしょう。 多少大きくなってくるのであ
この記事は、イベント 【PERSOL（パーソル）グループ Tech Talk #3 - 技術負債との向き合い方 - 】を開催しました。 の発表内容です。 桑田です。よろしくお願いします。 改めまして、パーソルプロセス&テクノロジーという会社のSEEDS COMPANYという部署の桑田と申します。 リファクタリングの理想と現実と泥臭さということで、今までの方々は割と現場寄りのお話が多かったと思うんですけど、私はちょっと経路を変えてプロジェクトマネジメント寄りというか政治寄りの話をしようかなと思ってます。 自己紹介です。私は2018年にSEEDS COMPANYにジョインしまして、エンジニアリング兼、スクラムマスター兼バックエンドアーキテクト兼みたいな感じでやってました。 最近はSEEDS COMPANY全体の技術責任者として会議漬けの人生を送っております。 好きな技術領域はGoを中心にみたい
リンク connpass: 【再放送】t-wadaさんが後世に残したい、実録レガシーコード改善 - connpass t-wadaさんの資料 実録レガシーコード改善 / Working with Legacy Code: the True Record - Speaker Deck 会社で、「t-wadaさんのこの発表すごいよかったですよ」と聞いたので興味が湧いて再放送を見ることにしました。Findyさん、t-wadaさん再放送ありがとう… 特に個人的に面白かったポイントを書きます。 ソフトウェア開発の三本柱には優先度がある ソフトウェア開発の三本柱は、Version Control, Testing, Automationの3つです。今回t-wadaさんが取り組んだコードはどれも備えていませんでした。優先度順に手をつけたいけどどこから手をつけるべきか。 ここでVersion Contro
はてなブログ独自の集計による人気記事のランキング。6月12日（日）から6月18日（土）〔2022年6月第3週〕のトップ30です*1。 # タイトル／著者とブックマーク 1 邦楽から影響を受けた台湾のバンドが多い件について - オトニッチ by id:houroukamome121 2 死なないために - 宮田昇始のブログ by id:miyasho88 3 「論文入門」というより「学問全般への入門」・小熊英二『基礎からわかる論文の書き方』 - そういちコラム by id:souichisan 4 山下達郎がサブスク解禁しないことを自分が現時点で100％支持する理由について - オトニッチ by id:houroukamome121 5 日本人にかかる性淘汰圧と、その行方を想像する - シロクマの屑籠 by id:p_shirokuma 6 PTAに3000円の寄付を強要されたという話につい
内製ソフトウェアアーキテクチャでレガシーシステムを刷新し技術的負債を削減するまでにやったこと - LIFULL Creators Blog
事業基盤ユニットアーキテクトグループのyoshikawaです。 今回のブログではLIFULL HOME'Sを構成するレガシーシステムのリアーキテクティングについて書いていきます。 2年前にリアーキテクティングプロジェクトが発足し、ソフトウェアアーキテクチャのベースにClean Architecture、言語にTypeScriptを採用し 新たなAPI(Backend For Frontend)を開発してきました。 「コードの品質」と「プロダクト開発エンジニアとのコミュニケーション」が鍵となっていた本プロジェクトですが、 このブログ記事では「コードの品質」を主題として取り組みをオムニバス的に紹介していきます。 この記事で伝えること 想定する対象読者 過去のブログの紹介 データフローに注目したLIFULL HOME'Sのシステム概観 リアーキテクティングプロジェクトについて アーキテクトチーム
チーム立ち上げから1年半で8名体制に。フロントエンドチームのみなさんに今とこれからについて聞きました - BASE Book（ベイスブック）
社長室の米田です。 今回は、フロントエンドチームのみなさんに座談会という形でお話を聞きました！ BASEでフロントエンドチームが発足したのは、2018年12月。かつてはフロントエンド専任のエンジニアがいなかったところから、いまではマネージャーを含めて8人のフロントエンドチームとなりました。 それぞれのメンバーが入社したきっかけ、いま携わっているプロジェクト、チームで取り組んでいること、いまある課題などを話してくれました！ （WFHの方針により、今回はオンラインにてインタビューを実施しました。） フロントエンドチームのみなさん まずはそれぞれ自己紹介をお願いします。前職でやっていたこと、BASEに入社したきっかけ、BASEでの印象的なプロジェクト、いま携わっているプロジェクトを教えてください！ 松原（写真2段目中央）：前職ではレストラン予約サイトのフロントエンド開発をやっていました。iOS開
関数型プログラミング言語"Clojure"が「私たち」と「あなた」にもたらすもの | 株式会社AGE technologies
こんにちは、株式会社AGE technologies CTOの黒川です。 この記事では、私たちがシステム開発のほとんど全ての場面で使用しているClojure（クロージャー）という言語について紹介します。大きく下記の3点をトピックとして、弊社のテクノロジースタックに理解を深めていただくことを目指します。 なぜClojureを選定したのか / Clojureが「私たち」にもたらすものClojureが「あなた」にもたらすもの未経験のチームメンバーがどうやって適応していったか前提私は、現代のシステム開発のユースケースにおいて、特定の言語でなければ実現できない機能はほとんど存在しないと考えています。とはいえ、「じゃあCOBOLでもいいよね」といった極論は必ずしもベターな解決方法ではなく、選定する技術に応じたトレードオフは理解しておく必要があります。 この前提に基づいて、本記事では私たちの技術スタック
In Layered Architecture (e.g., Clean Architecture, or Hexagonal architecture), the key idea is to use the dependency inversion principle. This blog post provides the dependency inversion principle in Rust, skipping the details of Layered Architecture. The sample in this blog post is a news app which gets news asynchronously. I will illustrate the dependency inversion principle with three layers: U
はじめに PythonでDDDでクリーンアーキテクチャで実装してみました。 良くも悪くも、"Pythonでは"あまりネット上で見かけない構成になったので共有しようと思います。 つくったものは、めちゃ簡単なTodoアプリです。 経緯 DDDについて全く知らないので、とりあえずPythonで軽量DDDやってみよう ついでにクリーンアーキテクチャも全く知らないのでコレもやろう という軽い気持ちで始めました。 参考 nrslibさんの記事を最も参考にさせていただきました。 （というより、実装していくとほぼPythonに書き直しただけのようになりました） 使用ライブラリ 今回作成したものは使用ライブラリに大きく依存するため、先に使用ライブラリを記載しておきます。 DDDのため 今回、メインで紹介する部分です。 pydantic 型チェックや設定管理に富んだライブラリ 個人的にすごくお気に入り inj
ターゲット クリーンアーキテクチャ 初級者~中級者 概要 WebAPI開発時はバックエンドのアーキテクチャを考えて実装すると思いますが、取り入れるアーキテクチャの一つにクリーンアーキテクチャがあります。 私自身もなんとか少しずつ考え方を取り入れようとしているのですが、UseCaseのInput Dataに関してはずっともやもやがあったので、「単に自分の理解が間違っているだけなのではないか？」「一回考え方を見直した方が良いのではないか？」という思いから今回見直してみることにしました。結果、見事にわかっていなかったようです。今でも理解しているかと言われると怪しいですが。。 参考文献は、クリーンアーキテクチャの原本である**Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Mar
はじめに 2019年は、設計の年でした！ Unity３種の神器 ・UniRx *1 ・UniTask *2 ・Zenject *3(Extenject *4) これらがないと開発できない体になってしまった。 MV(R)P期 UniRxといえばこれ！というくらいよくある書き方。去年から学び始めて今年の5月くらいまではずっとこの書き方をしていました。 using System; using UniRx; using UnityEngine; using UnityEngine.UI; namespace ProjectName.Scripts { // Modelは、ScriptableObjectにするかPresenterないでnew して生成していた public class Model : ScriptableObject, IDisposable { private readonly
「ユースケース(use-case)」を理解するために、その歴史をたどる - mob-mob-village
「ユースケース」って言葉はよく見聞きしますよね。「まずはユースケースから考えよう」とか「ユースケースの洗い出しが甘いよね」とか「あー、あの棒人間と楕円をつないだやつね」とか。 しかし、どうもその実態というか意味がつかめていません。あるいは、ユースケースがもたらす嬉しさや悲しさもあまり体感できていません。ユースケースという言葉の解釈や使い方は、人によってバラバラな気がしてなりません。みなさんはどうでしょうか？ ユースケースはどうやら有用な考え方らしいのですが、どうもしっくりこないんですよね。一方で、これを理解することができたらとても嬉しい気がするのも事実です。ムズムズしてもどかしい。 というわけで、ユースケースについて勉強していくことにしました。まずは、その定義から。つまり、歴史をたどりましょう。 ユースケースの歴史をざっくり 提唱したのは Ivar Jacobson 名前がついたのは198
iOSアプリの基本構造 - Qiita
Xcodeで新しいiOSアプリのプロジェクトを作成すると、勝手にStoryboardやらViewControllerやらが生成されて、 何もしなくても真っ白な画面のアプリができると思います。 これそもそもどういう構造になっているんだ？ というのをずっと曖昧なままやってきたので、整理する意味でこの記事を書きます。 丁寧に書くと、本当に1冊の本になるくらいの内容なので、説明が足らない部分や英文直貼りになってしまう箇所はご容赦ください。 ドキュメントについて 昔は「iOSアプリケーション プログラミングガイド」なる日本語ドキュメントがあったっぽいのですが、 Swift化あたりで焚書されたみたいです。 検索したところ、アーカイブにも見つからないです。。。 About App Development with UIKit 多分この内容が、それに相当するのだと思われます。 基本的には公式ドキュメントに
PHPカンファレンス関西 2024【参加レポート】 - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに 配配メール開発課moryosukeです。 2024/02/11(日)にPHPカンファレンス関西 2024が開催されました。 ラクスはブロンズスポンサーとして協賛させていただいています。 2024.kphpug.jp ラクスからは5人が登壇した他、多くのメンバーが参加しました。 そこで今回は参加者によるレポート、そしてラクスからの登壇者本人によるレポートを紹介させていただきます。 はじめに 参加レポート はじめてのOSSコントリビュート Laravelでミニマム開発からスタートして個人サービスを利益化するまでの経験談！ RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド 令和最新版 PHP メモリ管理術 「"品質"が高いコード」って何？ CodeRevieweeが求められること アプリケーションエンジニアこそ「監視」だよね！と私が考える訳 コードを自在に操るためのPHP文法
主旨 Clean Architectureに登場するユースケースと外界とのアダプターとなるRepositoryとGatewayという概念について、実際に使う場面になった時にどちらをレイヤ名として使用するのが正しいのか？が気になったので、備忘録としてまとめておこうと思いました。 （個人的解釈なので、誤りがあればご指摘いただけると嬉しいです！） 結論 結局のところ、「ユースケースと外界とのアダプターとなる責務を果たしている」なら、どちらでも良さそうという結論に至りました（雑ですみません） そもそも気になった経緯 Clean Architectureといえば以下の図が有名かと思います。 緑色の部分にあるInterface AdapterにはGatewayと書かれていますが、実際に開発する時やWebでサンプルコードを見たりすると、Repositoryという命名で主にDBとの接続を責務とするレイヤが
この記事は iOS #2 Advent Calendar 2019 の12日目です。 今年の1年間、ぼくが興味を持ち続けてきたiOSアプリのマルチモジュール化について、検討したことをここに書き出します マルチモジュール化とは タイトルからさらっと「マルチモジュール化」という言葉を使ってしまいましたが、ここでは、ライブラリの仕組みを使って複数のモジュールで構成されたiOSアプリにすることを、マルチモジュール化と呼ぶことにします。逆にマルチモジュール化していないアプリをモノリシックなアプリと呼ぶことにします。 ライブラリと言えば、OSSとして公開されている汎用的で再利用可能なものが真っ先に頭に浮かびますが、ここではそういったものを使っているどうかは関係なくて、開発中のアプリの処理を積極的にライブラリとして切り出して（＝モジュール化）、そのアプリ内で利用してゆくことを考えます。 モジュールの分割
The VIPER architectural pattern is an alternative to MVC or MVVM. And while the SwiftUI and Combine frameworks create a powerful combination that makes quick work of building complex UIs and moving data around an app, they also come with their own challenges and opinions about architecture. It’s a common belief that all of the app logic should now go into a SwiftUI view, but that’s not the case. V
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
今、iOSアプリをゼロスクラッチで開発する時の構成と利用ツールを考える - Qiita
リファクタリングの理想と現実と泥臭さと / SEEDS COMPANY｜miidas_tech
【再放送】t-wadaさんが後世に残したい、実録レガシーコード改善 を見た感想
今週のはてなブログランキング〔2022年6月第3週〕 - 週刊はてなブログ
Dependency inversion in Rust Web Application
Python x DDD x Clean Architecture
クリーンアーキテクチャのUseCase Inputについて見直してみた
2019年をふわっとまとめる 〜Unityにおけるアーキテクチャの自分なりの解〜 - Qiita
Clean ArchitectureにおけるRepositoryとGateway
iOSでもマルチモジュール化したい！ - Qiita
Getting Started with the VIPER Architecture Pattern