#devsumi 会場で買ってきた『アーキテクチャとクラウド—情報による空間の変容』をちょっとだけ読んでた。おもしろい。 / カバーの装丁があまりに目立たず、書名すら読み取りにくくて。見つけるのに苦労したのよ。書店を歩き回ってたら手に取ることはきっとなかった。もったいない。 posted at 01:00:31 #article 読む: 「タグ「devsumi」のTwitterまとめ」<http://togetter.com/t/devsumi > #devsumi posted at 01:08:20 #article 読む: 「Developers Summit 2011 (講演資料集)」<http://www.slideshare.net/event/developers-summit-2011/slid... > #devsumi posted at 01:08:32
#index 「Developers Summit 2011 1日め (2011/02/17)」参加メモ <http://twilog.org/nsiena/date-110217/asc > #devsumi posted at 00:15:57 「アーキテクチャとは、ソフトウェアとは何か: プロセス/行動 ←→ 内部構造 ←→ 外部/振舞い ←→ 利用時(複数) (JISX129-1 ソフトウェア製品の品質 第1部) #18C1 #devsumi posted at 10:16:20 「アーキテクチャ: 基本は分割と統治。システムは、制約(環境)下でミッションを持つ。多数の利害関係者は、各自の関心事からみたビューがモデルとして述される。その関心事を整合させ、ライフサイクルまで意識した構造。 #18C1 #devsumi posted at 10:16:31 「マネジメント: マネージャは物事を正しくする (目標と目的, どうやって, いつ)。リーダシップは正しいことをする (ビジョン, 何を, なぜ)。 #18C1 #devsumi posted at 10:22:13 「PM は記事になるけれど、アーキテクトはなりにくい。事前的な活動であり、危機を救う物ではないためか。そもそも危機に陥らないための活動。 #18C1 #devsumi posted at 10:22:58 「PM とアーキテクチャ。アジャイルマネジメント: 変化ヲ抱擁セヨ。イテレイティブなタイムボックス管理 (要求と実装のずれを限定) とリスク主導 (不確定部分から着手、プロトタイミング、継続的統合)。 #18C1 #devsumi posted at 10:25:17 「全体計画は正しくなくても良いが、正しい物を見つけて行くプロセスは必要。プロセスを決めるには要求まで遡る必要がある: プロセス←構造←作りたいもの←要求。アジャイルはアーキテクチャ設計を内包している。マネジメントはアーキテクチャ設計を前提としている。 #18C1 #devsumi posted at 10:28:29 「アーキテクチャが安定ならマネジメント主導はやりやすい。トヨタの自動車設計の事例から。しかし、ソフトウェア開発では新しいアーキテクチャによる効率化が、繰返しによる効率化を上回ることがある。どちらで主導するかは要求に合わせて判断。 #18C1 #devsumi posted at 10:34:45 「変化を許容するようなマネジメントには、土台となるアーキテクチャ設計が重要。即ち、アーキテクトがいないと計画を立てられず、何をマネジメントするかを定められない。正しさを見つけるための方法を見つける。アーキテクトとマネジメントとの職能の違い。 #18C1 #devsumi posted at 10:37:16 「アーキテクトは PM に WBS 作成のために情報を提供せねばならない。立てられた計画の下で設計をするのは、高々フレームワーク設計が限界。アーキテクトは PM は分業しながらも、相補的である。 #18C1 #devsumi posted at 10:40:29 「ユーザとアーキテクトの関係。ユーザとビルダの間には越え難い壁がある。使うこと=ビジョン・要求・要件を外圧、作ること=戦術・設計・実装を内圧のせめぎあい。これを繋ぐこと=アーキテクチャ・戦略・バランスを与えよ。中立の立場からバランスを取る。 #18C1 #devsumi posted at 10:45:04 「繋ぐ手法: アーキテクチャ設計ではDDD。ドメインエキスパートとドメインモデルが大切。何が作られるべきかを考える。/ マネジメントではスクラム。プロダクトオーナとスクラムマスタ。アーキテクチャ主導のアジリティに適応する。 #18C1 #devsumi posted at 10:50:24 「スクラムやDDDは、ユーザとビルダの関心事をリンクさせる枠組 = プロジェクトのアーキテクチャ、ではないか。アーキテクトがプロジェクトのあり方すら決めていくのではないか。"プロジェクトアークテクト" の可能性。 #18C1 #devsumi posted at 10:54:08 「アーキテクトはビジョンを語りながら価値を提供して行く。アーキテクトは父、マネジメントは母。両者が DDD や スクラムで協力し、ユーザとビルダを繋ぎつつ、ソフトウェア開発を主導していく。/ Qcon Tokyo 2011 もよろしく! #18C1 #devsumi posted at 10:57:18 「Oracle の公式見解: "Oracle は今後も積極的に Java に投資していきます"。Larry Ellison: "Java は私達が今までに取得した中で最も重要なソフトウェア資産です"。Javaなしで地球は回らない。 #18C2 #devsumi posted at 11:18:31 「11億: デスクトップのインストール数。9.3億: JRE ダウンロード数/年。30億: Java対応携帯電話数。100% Bru-lay プレイヤ実装。14億: Java Card 製造数/年。その他、STBやプリンタ等。もはや捨てられない。 #18C2 #devsumi posted at 11:22:15 「Javaプラットフォーム = Java VM + Java言語 + Java APIs。今後は、Java,Ruby,Java FX,Java Script,... と多言語展開を本格化する。Java7 の InvokeDynamic の導入など。 #18C2 #devsumi posted at 11:25:22 「日本オラクルの関わり方: OTN で和訳も含めた情報提供を開始予定。無料のオンラインセミナー。OTN でアンケート実施中 (先着200名に景品もあるよ)。ご意見に、日本オラクル・Oracle本社で対応する。 #18C2 #devsumi posted at 11:29:31 「Java はオープンであり続ける。コミュニティには誰でも参加可能。Java も Glassfish も、GPLv2 か CDDL で利用可能。もちろん、fork も可能。今後も write once run anyware は維持したい。 #18C2 #devsumi posted at 11:33:06 「Oracle になったから Apache が JCP から脱退したわけではない。まだ Sun であった 2007年頃から方針の相違があり、タイミングが今になっただけ。 #18C2 #devsumi posted at 11:35:43 「Java言語仕様は、従来通り JCP で。Oracle は JCP の PMO として活動。特許も保持するが、あくまでも他と連携しての活動の一環。 #18C2 #devsumi posted at 11:37:16 「Oracle のビジネス。1. Oracle の従来の Java 上に構築したミドルウェア, 2. Sun の頃からの組込機器におけるへのライセンス販売とプレミアサービス。→ コミュニティ運営・収益モデルとも、Sun の頃と一切変えていない。 #18C2 #devsumi posted at 11:39:56 / Java SE 7 は 2011/07/28, Java SE 8 は 2012年後半にリリース予定。HotSpot VM と JRocket VM は短期的には両方継続し、中長期的には長所を合わせて統合の可能性あり。 #18C2 #devsumi posted at 11:42:22 「OpenJDK: Java SE 7, 8 の新機能の一部がサブプロジェクトで開発されている。Java SE 7 は多くの新機能があり、大きな変化になる。 #18C2 #devsumi posted at 11:43:58 「プロジェクト Coin では言語仕様の変更: 1. switch での文字列比較, 2. バイナリ表記リテラル 0b0101 と '_' 区切り 1_000 の導入, 3. 複数の例外補足の一括記述, #18C2「 #devsumi posted at 11:49:27 「4. 例外ハンドリングの改良, 5. Genericsインスタンス生成における型推論の改善によるコードの簡潔化, 6. finaly 句での Closable オブジェクトの自動 close() #18C2 #devsumi posted at 11:49:43 「Java EE 7 は、方針を定め始めた段階。テーマはクラウド対応。今分かっている候補は、JPA 2.1, JAX-RS 2.0, JMS 2.0, JSF 2.2, WebTier (HTML5, WebSocket, JSON API)。 #18C2 #devsumi posted at 11:58:09 「アーキテクチャ: IEEE Std 1471-2000。校正要素とその間の動的・静的な関係を定義しいた "構造"。校正要素はインタフェースを持ち、入れ子の関係を取る。範囲 (システムコンテキスト) が重要。 #18C3 #devsumi posted at 13:27:43 「アーキテクチャの特徴: 見えない構造のかしかで解釈は一義的, 設計・実装上の判断の拠り所, 設計・実装・アセット化され再利用される。 → 構成要素を並行して設計・実装可能に, 整合性・長期稼動・低コスト化の源泉 #18C3 #devsumi posted at 13:27:51 「利害関係者の観点ごとのビューに応じたモデルを図記法で表現。内部構造を知りたい人 → 機能モデル/機能ビュー/クラス図・シーケンス図、配置・運用する人 → 配置モデル/配置ビュー/システム構成図など。 #18C3 #devsumi posted at 13:43:49 「基本・横断的ビューポイント: { 要求, 機能, 配置, 妥当性確認 } x { パフォーマンス, セキュリティ }。各組合せに対して各種の成果物が位置付けられる。 #18C3 #devsumi posted at 13:47:54 「アジャイルの観点から、重厚長大なアーキテクチャ記述を毎回行なわねばらないのかという問いがあるが、場合による。対象システムの特徴により充填は異なり、めりはりを付けたアプローチ (再利用, 専門家の組織化, 構想実証による検証) が重要。 #18C3 #devsumi posted at 13:50:16 「OpenUp : { 要求, アーキテクチャ, 開発, テスト, } の活動における { 方向付け, 遂行, 作成, 移行 } の各フェイズについて、詳細活動を定義した手法 (かな?)。詳しくは本を参照。 #18C3 #devsumi posted at 14:01:10 「GAE でスケールするコツを紹介したい。初リリースから 3年。2ヶ月程度の間隔でリリースされている。GAE へのアクセス: 10万開発者/月, 15万アプリ/週, 10億PV/日。 #18C4 #devsumi posted at 14:25:18 「データストアの設計: 1.非正規化により結合処理を避ける, 2.必要な索引のみ作成 (索引更新での同期書込みによる速度低下, 容量増大), 3.最小限ンおエンティティグループ (トランザクションベースが必要な箇所), #18C4 #devsumi posted at 14:42:54 「4.できるだけ高速なアクセス (query < keys_only query, query < get, 複数get < batch get), 5.一部のプロパティだけ必要なら kind の分割が有効, #18C4 #devsumi posted at 14:46:37 「6.分散・多ノードゆえ確率的に 0.3% 程度は失敗するので多少の失敗を許容できるアルゴリズムにする (再試行, デッドライン指定) #18C4 #devsumi posted at 14:48:13 「最小限の仕事: 外部から届くユーザ向き要求は 1sec 以内で。速い手段を: query < keys_only query, query < get, datastore < memcache, memcache < 静的大域変数 #18C4 #devsumi posted at 14:51:41 「1sec で足りないなら: task queue に投げる (chanel API)。一つのエンティティやエンティティグループへの書込みを 1回/秒に抑える。エンティティグループを小さくする。シャーディングカウンタなどを使用するなど。 #18C4 #devsumi posted at 14:56:53 「500qps の制限があるので必要なら解除申請をする。/ Tablet Server の split を避ける。自動採番や、開始文字が同じ name は split しやすいので注意。 #184 #devsumi posted at 15:09:49 オライリーの本を買いたくなったけれど。今から買うのは電子版にしたいのと、どれを持っているかわからなくなってたのとで諦めた。電子版が出るまで待ってしまおう。/ そしていつまでも電子版が出ない罠。買い控えちゃうから、全部、印刷版と同時に電子版を刊行してよ。 #devsumi posted at 15:26:03 「今日販売される『Amazon Web Servies ガイドブック』の著者 (出版社が違うということで会場で販売できなかったw)。AWS は、柔軟・スケーラブル・セキュア・コスト効率の高いインフラをオンデマンドにサービスとして提供。 #18C5 #devsumi posted at 15:32:00 「使う理由: 総所有コストの削減。AWS のコアコンピテンシは HWプロビジョニングではない。信頼できるプロバイダ。理想的な瞬時の HW調達。 #18C5 #devsumi posted at 15:37:04 「Amazon社内システムの AWS移行の考え方: Amazon自身が AWS のユーザ。Amazon 特有のカスタムソリューションは避ける。可用性遅延に関して現状を超えるものを。セキュリティ要項を厳守して顧客の親鸞を得る。倹約を徹底する。 #18C5 #devsumi posted at 15:39:09 「イノベーション推進: 有能なエンジニア,環境整備,イノベーションを尊重,オンデマンドにインフラ調達可能な環境,障壁を無くし開発を簡単に,高いモチベーションの維持,やってみると誰にでも,成功がエキサイティングな雰囲気作り,だめならやめればいい #18C5 #devsumi posted at 15:39:40 「HW 運用オーバヘッドの削減: SW だけでなく、HW やインフラも重要。必要なだけ必要なハードウェアを → ユーティリティコンピューティング。数分での HW 調達を可能にすることで大きな変革に繋がる。 #18C5 #devsumi posted at 15:42:21 「Amazon IT でのステップ。1.prepare: 移行体制を整備, システムを査定, サードベンダと協業。2.experiment: S3を利用開始し、EC2中でパイロットを走らせる。3.migrate: 段階的に移行、AWSの利用を簡単に。 #18C5 #devsumi posted at 15:54:52 吉田「クラウド採用時の壁: 1.費用 (値段勝負という印象を受けてしまって提案が適正に評価されない→何を求めるのか使う側が押さえられていない?),2.セキュリティ (印象のみの漠然としたセキュリティへの不安感→何のどのようなセキュリティ?), #18C6 #devsumi posted at 16:45:07 「3.人材 (IT徒経営を理解している系営巣・スケールを理解しているアプリエンジニア・大規模インフラを理解しているインフラエンジニアの不在 →オープン化の波の時と同様の構図) #18C6 #devsumi posted at 16:45:24 渡辺「セキュリティに関しては従来と大きく変わることはない。」仲山「費用面では、必要な性能を後から変更できる。アプリの調整をするまで併用できるのがクラウドの強み。 #18C6 #devsumi posted at 16:49:17 久保田「ぶっちゃけちゃってくださいw」大石「他者クラウドとニフティクラウドの違い。豊富な AWSの利用経験から比較。ニフティクラウドは高いけれど速い!? 同程度の性能差で Superπで 6倍差。両者 64bit CPU に設定して再計測予定。 #18C6 #devsumi posted at 16:55:41 大石「使い分けポイントを提案: CPU を多用する場合はニフティクラウドの方が、一般的なウェブシステムでは CPU 有休時間が多いので AWS の方が向いているかも。#18C6 #devsumi posted at 16:55:57 渡辺「iPhone や Android との直接の関係はないが、バックグラウンドのシステムとして利用できる。」吉田「infoSoop のテストをするためにちょこっと使ってすぐに落としたら、たった 12円。素敵。 #18C6 #devsumi posted at 17:06:07 仲山「クラウドのパフォーマンス。必要な性能を必要なだけ使える。利用状況に応じて性能を落として運用しつつ、アプリの改善をして再チャレンジしたりできる。定常時の負荷とピーク時の負荷の両方を計測しておく。いろいろな指標・パターンで計測する必要がある。 #18C6 #devsumi posted at 17:14:13 久保田「各社の性能特性が違い、ニフティクラウドは当初は I/Oが非常に遅かった」仲山「その調査をした。利用パターンとの相関などから何が起きているか推測できることも。見えにくくはなったが存在するのは物理サーバであるので深い知識は役に立つ。 #18C6 #devsumi posted at 17:14:23 仲山「インフラの詳細な情報を公開してほしい」渡辺「CPU を効率的に回すためにメモリの多いプランが欲しい」大石「AWS はボトルネックの情報とサポートプランを用意している。ニフティクラウドにも欲しい」 #18C6 #devsumi posted at 17:18:51 久保田「苦情があれば適宜対応してきた。これからもどしどしご意見をよろしく」吉田「RDBMS でなく KVS を試す等、ソフトウェア構成を変えるのも容易。コストパフォーマンスがいい。」 #18C6 #devsumi posted at 17:19:05 久保田「パートナープログラム始めた。一緒にクラウドビジネスを行ないたい企業からの応募を待っている。REST の仕様を開示したりできるかも? #18C6 #devsumi posted at 17:20:37 野村「価値創造のハブとなるフューチャーセンターの芽生え。未来創造のための対話の場で企業を改革する。様々な "複雑" な問題の解決を目指す。」市谷「DevLOVE の想いと非常に似ている。」対話セッションの開始。 #18B7 #devsumi posted at 17:55:16 #index 「Developers Summit 2011 2日め (2011/02/18)」参加メモ <http://twilog.org/nsiena/date-110218/asc > #devsumi posted at 23:14:52
|
last update 06/04 08:59
ツイート検索
Recent
Archives
Friends
Hashtags
Stats・Feed |