Engineering the Architecture Behind Uber's New Rider App
Mobile, EngineeringEngineering the Architecture Behind Uber’s New Rider AppDecember 20, 2016 / Global Why Uber Started Over Uber is based on a simple concept: push a button, get a ride. What started as a way to request premium black cars now offers a range of products, coordinating millions of rides per day across hundreds of cities. We needed to redefine our mobile architecture to reflect and sup
Ruby Midwest 2011 - Keynote: Architecture the Lost Years by Robert Martin
Robert C. Martin (Uncle Bob) has been a software professional since 1970. In the last 40 years, he has worked in various capacities on literally hundreds of software projects. He has authored "landmark" books on Agile Programming, Extreme Programming, UML, Object-Oriented Programming, C++ Programming and Clean Code. He has published dozens of articles in various trade journals. Today, he is one of
コスパの良いiOS開発を求めて
こんなチームならRedux + Passive MVP + Clean Arch(Essence) が今のところ筋が良いのでは？って試行錯誤して実践している話
なぜ iOS アプリ開発でも Redux なのか
こんにちは、アプリケーション共同開発部のみなみです。 初代 iPhone が発売されてから今年で10周年を迎えました。これまでに多数のアプリが開発され、傾向としては、以前と比べものにならないくらい大規模・複雑化してきています。フェンリルでも毎年多数のアプリが開発されていて、開発の日々の中で今後もその傾向は加速していくと感じます。 大規模・複雑化する開発で出てくる問題 スコープの広い状態の扱いの難しさ 画面間やモデル間で共有されるスコープの広い状態をどうするかは、アプリ開発において最も厄介な問題の一つです。 例えば・・・ 開発者が頑張って小さい責務だけ持つようにした、それぞれ 200 行ぐらいのクラスを5つ作ります。突然の仕様変更でこの5つのクラスが A という状態を共有するようになりました。共有するのはたった1つの状態なのですが、これだけで全てがぶち壊しです。この5つのクラスは、1つの共有
まだiOSアプリのArchitecture選定で消耗してるの？ - Qiita
去年はiOS Clean ArchitectureについてまだMVC,MVP,MVVMで消耗してるの？ iOS Clean Architectureについて色々書いてみたのですが、MobileアプリのArchitectureは色々あって何を採択するか結構悩んでいるんじゃないかなと思います。 Clean Architecture自体も学習コストが高くて理解するまで時間がかかるので、色々あるArchitectureの中からどうゆう基準で採択するのが良いかまとめてみることにしました。 書こうと思ったきっかけは、以下に影響されていたりします。 今から新規でAndroidアプリを書き始めるなら。 今から新規でiOSアプリを書き始めるなら。2016年冬 iOSのArchitectureについてはiOSアプリ設計大全集 2016にまとまっているので、それ以外のことについて書きたいと思います。 Clean
iOSアプリ設計大全集 2016 - Qiita
iOS関係の勉強会に参加するとほぼ間違いなく、設計に関する発表があるように思います。 「RxSwiftを使ってMVVM...」「Clean Architectureを導入...」, etc... 色々話を聞く中で、自分は以下のような課題があるなぁと感じています。 いろいろな設計方法があるけれど、結局何を使うべきなのかわからない 名前は聞いたことがあるけれど、それぞれがどのような設計で、何がメリットなのかわからない 勉強した時は分かったような気がしたけれど、もう忘れた この記事はこれらの解決の一助になればと思って書いたものになります。（設計へのモチベーションを上げたい） サンプルコードを交えながら、5つの設計について考察してみます。 ※ RxSwiftの名前を出しましたが、ライブラリに関してはこの記事では言及しません。 そもそも、なぜ設計に拘る必要があるのか iOSアプリ開発において、このよ
Webアプリケーション開発者から見た、MVCとMVP、そしてMVVMの違い - Qiita
RubyOnRailsを触れる過程でMVCという概念を学び その後、他のフレームワークでMVCやMVP、MVVMというものを知ったのですが Railsで語られるMVCと他で語られるMVCのニュアンスが若干違うので そこを基点にMVCの違い、そしてMVP、MVVMとは何なのかをまとめてみました。 MVC(Model,View,Controller) 定義としてのMVC 上記でも挙げた通りMVCは使う場面やフレームワークによって ニュアンスが異なっています。 そのため根本的な「MVC」の一般的な定義は一体どんなものなのかを見てみました。 Wikipediaからまとめると以下のとおり。 アプリケーションソフトウェアの内部データを ユーザーが直接参照・編集する情報から分離する。 そのためにアプリケーションソフトウェアを 「Model」「View」「Controller」の3つに分割する。 ・Mod
RxSwift? いやClean Swiftっしょ - Qiita
いつもiOS開発で悩むこと MVCやMVVMで作ってると、最初開発するときは自由度の高くて楽に実装できるのだが、 ViewControllerやModel層は改修を重ねるごとにどんどん肥大化し、複雑化してしまう。 どんどん肥大化するソースは、情熱がない限り結局誰もリファクタリングしないので、 どんどん負の遺産が増える悪循環になってしまう。 ここ数年ではFlux ArchitectureベースのRxSwiftやReactive Cocoaが流行っているのだが。。。。 使ったことはないが聞く感じ単純にKVOでしょって感がいなめない。。。 データの画面更新は遷移等考えなくても楽だからすごく魅力的だが、イベント数が増えれば管理が大変だし、イベントは非同期だから予期せぬ画面更新が起こりそうだしっていうので少しマイナスイメージが多い感じ なんかいいものないかと色々見てみるとQiitaに面白い記事が。
中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
まだMVC,MVP,MVVMで消耗してるの？ iOS Clean Architectureについて - Qiita
＜この記事は「Money Forward Advent Calendar 2015」の22日目の記事です＞ この記事は、iOS Clean Architectureと実際にコードへ適用した内容について紹介します。 コードについては、改善の余地があるため随時修正していくと思います。 → github: https://github.com/koutalou/iOS-CleanArchitecture iOS開発においてよくある問題点 「ビジネスロジックはModelに置くべき」と言うが、開発者によって理解や意見がバラバラで統一的な実装ができない 度重なる仕様変更や複雑な仕様に対応するためにViewControllerや特定のModelが肥大化し、ビジネスロジックの本質を見失う MVC,MVP,MVVMだけで考えると、どこかのレイヤが複数の責務を持つことになり依存度の高い複雑なコードが生まれてし
CPUに関する話 | GREE Engineering
こんにちわ。せじまです。スティック型PCの購入は、 Core M版が出るまで見送ろうと思っている今日このごろです。 弊社では「Mini Tech Talk」という社内勉強会を隔週で開催しているのですが、それとは別に、「Infra Tech Talk」という社内勉強会を、半年くらい前から毎月開催しています。わたしはそこでほぼ毎月、45-60分くらいのスライドを作って話をしています。今までどういう話をしてきたかといいますと、TCPに関する話を二回、SSDに関する話を二回しました。（InnoDBに関する話だと軽く5-6時間くらいできるんですが、いささかマニアックなので、もっと幅広い人を対象に話をしています） 今までの話はちょっと社内向けの内容だったんですが、前回開催された Infra Tech Talk では、社外の方にも幅広く読んでいただける話ができたと思いましたので、その資料を slides
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
YAPCでおもしろ発表してきた - hitode909の日記
YAPCでおもしろ発表してきた． はてなブログの開発を振り返って設計の進化と最高の設計を紹介するという話． speakerdeck.com なぜか大人気発表みたいになってて，会場満員で，すみませんこんなところに来ていただいてすみませんというかんじだった． 紹介した本はこちら．予約投稿で仕込んであって，発表終わったら，こちらから買ってくださいとかやろうと思ってたけど，すっかり忘れてた． YAPCの発表で紹介した本 - hitode909の日記 質問たくさんいただいて，よいかんじにおさまったと思う． 「難しくて挫折するという問題がありますよね」「歯を食い縛って実装しろって書いてあった」 #yapcasiaE— そらは (@sora_h) 2015, 8月 21 Q: 「コメントの良い書き方は？」 A: 「オブジェクト指向入門下巻に書いてあります」 ↓ 「買って読みます。」 #yapcasiaE
「レイヤードアーキテクチャを意識したPHPアプリケーションの構築」を発表しました
2015/06/27 に開催された PHPカンファレンス福岡2015 にて、「レイヤードアーキテクチャを意識したPHPアプリケーションの構築」という発表をしてきました。 MVC フレームワーク（CakePHP / Laravel）で構築したアプリケーションをレイヤードを意識して改善したという内容です。参加いただいた皆さんの顔ぶれを見ると歴戦の勇者みたいな方ばかりでしたが、和やかな雰囲気でセッションを進めることができました。ご参加ありがとうございました。 発表資料 発表資料は以下です。 MVC にサービスレイヤを追加して、それぞれの役割を意識して作る。レイヤ間の依存を明確にする。サービス（ドメイン）を中心に考える。よく言われていることなのですが、実際に実践する中で、ハマりがちなことや実際に実践してきた中で感じたことを紹介しました。もちろん、これで ok ということはないので、今後取り組んでい
ソフトウェアアーキテクトが知るべき97のこと
ソフトウェアアーキテクトが知るべき97のこと大人気の書籍『ソフトウェアアーキテクトが知るべき97のこと』のエッセイを無料で公開中！すべてのソフトウェアアーキテクトにおすすめの本がウェブで読めるようになりました。 エッセイ一覧システムの要件よりも履歴書の見栄えを優先させてはならない本質的な複雑さは単純に、 付随的な複雑さは取り除け最大の問題は、たぶん技術的なことではないまずコミュニケーション、そのための明快さとリーダーシップパフォーマンスの決め手はアーキテクチャー要求仕様の本当の意味を探れ立ち上がろう!すべてのものは、かならずエラーを起こすそれは交渉だということに気付け定量化を求めよ500行の仕様書より1行のコードフリーサイズのソリューションを求めるなパフォーマンスの検討に早過ぎるということはないアーキテクチャーとはバランスをとること犯罪的なコミットエンドラン
世界最強のソフトウェアアーキテクト
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ
@@ -0,0 +1,37 @@ +http://martinfowler.com/bliki/SacrificialArchitecture.html + + +会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたはどんな気持ちにするだろう？ + +多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 + +ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 + +私たちは長命なソフトウェアとして偉大なコードを思
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ