Guide to "kurashiru android" app architecture vol.1 概要編 - dely Tech Blog
はじめに こんにちは。クラシルのAndroidアプリチームのテックリードのうめもりです。 android-developers.googleblog.com 12/14に新しいアプリアーキテクチャガイドがAndroid公式からアナウンスされました。読まれた方もいらっしゃると思いますが、非常によくまとまったアーキテクチャガイドであり、新しくアプリを作る際も、既存のアプリのアーキテクチャを整理する際にも役に立ちそうな文章です。 クラシルのAndroidチームは去年の2月にAndroidアプリをリアーキテクチャしたのですが、そのアーキテクチャがアプリアーキテクチャガイドと似通った個所が多く、クラシルのアプリアーキテクチャを説明するのにもちょうど良さそうな文章だと思いました。 ですので、今回は新しいアプリアーキテクチャガイドとほとんど同じ構成で、クラシルのアプリアーキテクチャについて解説してみよう
Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ
@@ -0,0 +1,37 @@ +http://martinfowler.com/bliki/SacrificialArchitecture.html + + +会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたはどんな気持ちにするだろう？ + +多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 + +ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 + +私たちは長命なソフトウェアとして偉大なコードを思
パイプとフィルタ ~ソフトウェア工学における有用なアーキテクチャ~ | 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
テスト駆動開発（TDD）はもう終わっているのか？ Part 2 | POSTD
前編はこちらです 4：テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が
マイクロサービスとSOA
ここ数年，小規模なサービススイートで構成されたアーキテクチャを表現することばとして"マイクロサービス"という用語が拡がっている。QCon San Francisco 2012でもThoughworksのJames Lewis氏が，このテーマでプレゼンテーションを行った。氏はMartin Fowler氏と共同で，同じテーマの記事も書いている。これに対して，マイクロサービスは一部の人々が考えるような新しい概念ではない，所詮はSOAの焼き直しに過ぎないという意見を持って，最近この議論に加わったのがSteve Jones氏だ。その中で氏は，Lewis氏とFowler氏の記事の分析を順に追いながら，両氏のマイクロサービスの定義をOASIS SOA RM(Reference Model, 参照モデル)と比較する，という作業を行っている。 サービスによるコンポーネント化: OASIS SOA RMによる
「技術的負債」をコントロールする定量評価手法への期待
「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - delirious thoughtsにて、追記でコメントいただけたので、外野として好き放題言わせてください。すばらしいスライドありがとうございます＆いつもすみません。 僕が興味がもつとすると、それは「技術的負債」の定量評価手法についてです。 なぜ、そういう前提を置くかと言うと、それは、たとえばKrutchenによる「技術的負債」の定性評価は、とてもわかりやすいものの、技術を取捨選択するツールとしては使えないからです。 スライドでは、技術評価における将来の不確定性を象徴する問題としてSSDの普及前夜にシャーディングをがんばって実装してしまう例をご紹介いただきましたが、実際、そのような不確実性を織り込んだ正しい決定を我々が日々のエンジニアリングで下すことができているのか疑問に感じるこ
lambda-architecture.net - このウェブサイトは販売用です！ - lambda architecture リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
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つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの
超高速開発 体験談 - 職業プログラマの休日出勤
数日前に日本で話題になっていた「超高速開発」について記事を残したいと思います。ニュース記事 超高速開発はスクラッチ開発の3倍から10倍の開発効率が条件、競合するベンダ13社が利害を超えて「超高速開発コミュニティ」を設立 － Publickey の はてなブックマーク に寄せられたコメントを見る限り「食わず嫌い」な方が非常に多いように見受けられたので、これは体験談の需要は高そうだなと思い、書き始めた次第です。 ネタ記事を書いた直後に真面目な記事を書くのは、少し気が引けるものではありますが…。 私は2006年初頭から2012年初頭まで、インフォテリア社製の開発ツール「Asteria」を使用していました。この製品には冒頭で紹介した記事からもリンクが張られていますが、超高速開発を実現するためのツールの一つです。もちろん、私がAsteriaを使用していた頃は「超高速開発」などという言葉は見たことも聞
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【後藤弘茂のWeekly海外ニュース】 GPUのメモリ帯域を1TB/secに引き上げるHBMが準備完了へ
日本語テストメソッドについて
スケーリング Dropbox