えいのうにっき

a-knowの日記です

Java Cloud Meeting 2010 in Kansaiに行ってきたよ!

行ってきました! スピーカーのうちのお一人である(そしてのちにベストスピーカー賞ともなった)@shin1ogawaさんのツイートを見て、今回のこのミーティングがあると知ったのが開催日2日前のこと。近い開催地であるとはいえ大阪であるということと、ここんところ休日をゆっくり過ごせていなかったこともあり、15分くらい迷ったんですが・・・。ひがやすをさんをはじめとしてこれだけの方々のお話を聞ける・これだけの規模の会が、行こうかどうか迷えるロケーションで開催されるということ自体が今後何度あるだろうか?・・・ということで、参加を決めましたー。

結果、やっぱり行ってよかったです!!こういう会に参加すること自体初めてで、いろんな心配があったんですが、いろんな知識も吸収できたし、新鮮な刺激を頂くこともできました!

せっかく行ったんでってことで、当日お話を聞きながらPCでメモってたことをここでも載せておこうかなと思います。当日のスライドがないと何のこっちゃわからんことだらけかもしれませんが・・・。 (あと、聞きながらのメモだったのでおかしいところや足りないところが多分にあるかと思われます・・・ゴメンナサイ)

**ミーティングの詳細について は、こちらをご覧下さい〜。 あと、Twitterハッシュタグは「#jcmk2010」です。けっこーいろんな方が呟いてたので、見返してみてもおもしろいかも!


**第1セッション「Google App EngineはTDDに向いているんだぜ」The Seasar Project チームコミッタ ひがやすをさん

【概要】 GAE開発は、test-driven development(テスト駆動開発)に向いてるんだぜっていうお話を、実際に目の前で簡単な開発をしながら。 ※テスト駆動開発・・・1ロジック・1機能を組み込む毎に、そのロジックに対するテストを行う、そのサイクルを繰り返していく、的な開発の仕方。僕も趣味では似たようなことをやります。業務ではやってないなぁ・・・。 ひがさんだったか誰だったかの「リズミカルな開発」という言葉が印象的だった。 <<

-GAEだと,DBはRDBではなく,bigtableという分散kvsに分類されるデータベースを拡張したもの=データストアを使用する。これがなかなかイイ。RDBと概念が変わるので慣れが必要だが。 -例えば,本番後のスキーマの変更を全ロジックに反映・チームメンバ全員に知らしめるのは困難。RDBMSでテストデータのロード&抹消は時間がかかる、面倒くさい。 --KVSだとこの問題はある程度解決できる!スキーマの変更・・・KVSだとソフトスキーマスキーマの構造定義がデータそのものが持っているようなイメージ)、データ量がおおいときにもソフトスキーマは有効! ---本番後のテーブル変更ってのは、できるだけ避けたいが発生しうる。RDBMSでのデータのimp&expも大量だと時間がかかる ---ソフトスキーマ採用だとスキーマのバージョンで処理を分岐させることができるのでロジックへの反映も容易。

(ここで、ひがさん自らが簡単なWebアプリを実装・テストしていく。プロジェクタに投影しながら。&TDDを実践してみせる。  テンプレートでプロジェクト・サーブレットのガラを作成 → すぐテスト。  サーブレットのガラにテキストフィールドと送信ボタンを追加 → すぐテスト。  送信内容をデータストアに記録するロジックを実装 → すぐテスト。   ・・・これがTDD!) (プレゼン中,Webサーバが応答しないというトラブルに見舞われるも,  ちょっとしたジョークを交えつつ華麗に回避する姿はかっちょええ。) <<

-ちょっと書いたらすぐ確認する、というスタイル、step by step programming。 --人間、たくさんコードを書いてまとめてテストをしようとするといくつか間違うもの、ある間違いがどのコードに対応しているかを探すのは大変。 --書いたコード一個についてすぐテスト、というスタイルをすることでデバッグの時間を出来る限り減らすことができる、そういう実感がある。

-slim3 --BeanUtil.copy(request,tweet);←共通するフィールドがあればコピーしてくれる --SQLサービスも予定されているが、これを味わうと逆に面倒くさくて戻れないw

**第2-1セッション「今さら聞けないJavaクラウド」関西Javaエンジニアの会 谷本心さん

【概要】 「“クラウド”ってなんぞや?」という点にフォーカスしてお話くださった。 <<

-電気自動車向けクラウド型充電システム、なんてのもありますがー。 --「クラウド」と付ければ認知されやすい,というような風潮があるように思うのも確か。(それだけ市民権を得てきた言葉である、とも言える?) -その種類について --SaaS=webでサービスの提供 --PaaS=ネットワーク上の開発環境、実行環境・・・今日のメイントピックになるのかな? --IaaS=amazon ec2 さくらクラウド(今年12月からアルファ、来年3月からサービスイン) --エンジニアならPaaS、IaaSをクラウドと認識すべき。実際、SaaSクラウドとして話されることは殆どなかったように思う@アメリカ。

-クラウドが普及してきた背景 --サーバ側の性能の成長が追いついてない、7,8年前からクロック数は変わらず。昔ほど、マシン買い換え時に体感差なし。 --- → スケールアウト。大量のサーバを前提としたインフラ・ミドルウェアに。 ---例えば仮想化。 ---例えば分散KVS(RDBMSはスケールアウトしにくい) ----CAP定理、一貫性・可用性・分散耐性 ---Map/Reduce 大量のデータに対して分散して並列処理する仕組み

-「Googleを支える技術」は読んどけ

-クラウドの利用例 --継続的インテグレーション・PROMA−C --並列ビルド(各ノードに分割したビルド作業の実行を依頼)、多環境でのテスト、長時間の静的解析

-自分たちの「今の仕事」もクラウド化できるんでない?ということを、一度見直してみる価値はあるんじゃないか?

**第2-2セッション「AWS Free Usage Tierを使ってみる」関西Javaエンジニアの会 奥清隆さん

【概要】 Amazon Web Serviceの無料枠を活用してみましょ、というお話。 <<

-ec2とはなんぞや? --Amazon Elastic Compute Cloud -サーバインスタンスを提供 -稼働時間やデータ転送量によって課金 -AMIを選択してサーバを起動

-AMIとは --Amazon Machine Image --OSやパッケージをまとめたサーバのテンプレート(cent osとか。OSから選べるんだー・・・Winは高いんだってさ。) --数千のAMIが公開されている ---独自のAMIを作ることも可能(既存のAMIを土台に、ももちろん可)

-regionの選択を忘れずに(データセンタの地域)

-DNSの切り替えにまごつくのを解消 --elastic IP、基本無料、常にどれかのインスタンスに割り当てておかないとだめ。

-elastic load balacing って? --ロードバランサ。 --無料枠ではあまり意味が無い ---2つのec2インスタンスを立ち上げることは可能、ただその場合、消費する時間も2倍(インスタンス毎の起動時間で見る) ---トータルで750時間を超えると課金発生

-EBS --amazon elastic block storage --ec2上にマウント可能なストレージ --スナップショットを保存できる --ec2インスタンスを再起動した場合、HDD(そのインスタンスの、かな?)に格納したデータは消えるけどEBSにいれておけばインスタンスを切り替えたときでもおk

-簡単にawsを利用するサードパーティサービス、ってのもあるよー --cloud foundry・・・java webアプリケーションをawsにデプロイできるPaaS

-cloudを開発環境として使う --cloudbees・・・java製 --ビルドをする度に新しいインスタンス

-課金枠を超えたら止める、処理を落とす、それ以上させないようにする・・・ということはできる? --できない。課金に突入する。(この点はGAEのが安心かも!)

**第3セッション「分散Key-Value Store "okuyama"の機能とその仕組み」神戸デジタル・ラボ 岩瀬高博さん

【概要】 OSS分散キーバリューストア「okuyama」を自作した方のお話。 <<

-なぜNOSQLなのか? --「NO SQL」ではない、「Not Only SQL」、RDBと補完しあう存在 -なぜ必要になったか? --インターネットの普及に伴う個人ユーザの台頭、主役に ---個人にフォーカスしたアプリケーション、生み出される情報量の爆発、DBがデータ総量に耐えられなくなってきた ----スケールアップの限界、分割しにくい特性、高い技術力要。わざと正規化しないとか、ユーザIDで格納DBを分けるとかいった工夫 -----全てのデータを高度なデータモデルを有するRDBMSに格納する必要はある?・・・簡単なデータモデルで完結するストレージ ------利用状況に合わせて柔軟に対応できるモデルが今後は必要・・・柔軟に対応できる仕組み -------NOSQLの登場!

-okuyamaとは? --SPOFの存在しない機能 ---※SPOF・・・Single Point of Failure。システム上のあるコンポーネントが異常を来たすと、そのシステム全体が障害に陥ってしまうようなコンポーネントの総称 --オールJava --全て一から実装、全てオリジナル

-okuyamaのクライアント --javaphp実装済み、プロトコルBase64で単純エンコード、keyとvalueそれぞれをエンコードエンコードした値をカンマで連結、エンコーダ&デコーダは、色々見てみて最も高速だったJavamailのものを使用

-Masterノードコンポーネント --クライアントからのI/F、memcachedもサポート、ルーティングに必要な情報を保持するだけ --データ入出力、データ保存場所の決定は2つのアルゴリズムから選択(Mod、ConsistentHash) --生存監視(起動時のデータリカバリ) --制限大数なしに冗長化可能

-ネットワークメカニズム --接続ごとにWorkerスレッドを生成するとCPUに高い負荷。Workerを予め生成していると負荷はないが、クライアントが接続を切断しないとWorkerが枯渇する ---処理別キューイングメカニズムを考案。タスクキュー+Workerプール。 ---処理を切り分けて段階的に処理。各Workerの処理終了後はキューに返却。内部ではこの仕組を多重化。   -datanodeコンポーネント --データの保存を実現 --データ保存方式を選択可能 --最大3ノードにデータを保存 --アクセスバランシング --連鎖的ダウンの予防 ---各ノードで処理できる割合を予め設定することで真のバランスを

-ストレージの仕組み --データの保存形式を選択可能。 ---1.全てのデータをメモリに保存 ----key-valueの両方をメモリ上で管理、格納先はConcurrentHashmapを使用 ----key,valueともにBYTE配列で格納するため、オリジナルクラスにラップ ----最も高速に動く。ノード停止でデータも消滅。保存できるデータ量はメモリ量に依存 ---2.データ操作履歴のみファイルに保存 ----データへの操作を全てファイルに時系列に書き出し ----ファイルに書き出し後、メモリに反映filestreamは基本closeしない ----時系列ファイルからデータを復元 ---3.データ本体をファイルに保存 ----valueをファイルに持つ。メモリ上にはキーのみ、バリューとしてはファイルの行数(バイト位置) ---4.全てをファイルに保存 ----メモリへのアクセスなし、メモリ量を気にせず利用可能 ----高速ストレージではなく、少ないストレージで

-データ一貫性は大丈夫? --複数のノードに同一の値を保持していると、データに異なる時間が発生する。 ---一貫性の性質を選択(弱一貫性(無視)・中(常に最後に保存したデータノードからアクセス)・強(データノードの値を検証))

-スケールアウトによる性能向上 --ノード追加による性能向上、key値をハッシュ値に変更して保存先を決定 --データ移行中は2つのサークルを使用、登録は新しいサークルに、検索・更新は古いサークル→新しいサークル。

-SPOFの発生しない構成 --別のマスターノードに再接続 --自動データリカバリー機能

-ユニークな機能 --タグをデータに追加することができる(キー・バリューの他にタグ) --JavascriptをDatanode側で実行 --データロック機能

-性能 --1台でも非常に高いパフォーマンスを発揮

-RDBとKVSの使い分けの線引きの目安があれば教えてください。 --一概にこうとは言えないが。アクセス数とメモリ容量がひとつの目安。

**第4セッション「Androidの人が、App Engine/Jに挑戦したよ」有限会社シーリス 有山圭二さん

【概要】 普段はAndoroidアプリ開発に従事している方が,GAE/Jでの開発に取り組んだ際の所感。 <<

-サーブレットを使うまでの作業(マシン準備・OSインストール・Webサーバ設定・DBサーバ設定・サーバ連携・・・)、そう頻繁にやるものではないのでよく忘れる --GAEは手軽!

-GAEの欠点は、GAEそのものを自社で運営できないこと。(それがメリットでもあるのかもしれないが) --開発したサービスを自社サーバーで運営できる選択肢はほしい。・・・サーブレット+DB版と並行で開発できないか。 ---※GAE上で動作させることを前提として開発すると,どうしてもデータストア依存の記述が入り込む。 --サーバーをバックグラウンドとしてもたないと競争力として弱い部分がある、という思いもあります

-サーブレットとappengineとの違い --データストア。概念の違い。操作には3つの方法がある(JDO、JPA、Low-level) ---low-levelがおすすめ。何をやっているのかわかりやすい。一度はきちんとやったほうがいい ----Androidのコードとの親和性が高い。 ----AndroidにはSQLiteが含まれ、データの永続化に利用できる。

-Androidのモデルを無理なくappengineへ、またはその逆も可能なのではないか? --データ実態は共通クラス、データの永続化に関する部分をサブクラスで実装

-ハマったところ --Android(ローカルエミュレータ)からローカルappengineへの接続・・・通信できない! ---Androidエミュレータのネットワーク空間は独立。エミュレータ内部で指定する127.0.0.1エミュレータ自身を表す ----エミュレータが動作するコンピュータのローカルへアクセスするには「10.0.2.2」を指定。 --ユニットテスト ---Androidではユニットテストは実行可能、appengineでもユニットテストしたい ---基本のテストケースの作成、データストアテストの作成、でできる、と日本語マニュアルにはある ----ApiProxyLocalimplがインポートできない -----英語マニュアルで解決。マニュアルは英語のを参照するようにしましょうw

-Junitのバージョンが違う。Androidは3,appengineは4(3はメソッド名で識別、4はアノテーションで識別) --何かいい方法はない??

-人気のあるアプリケーションは、たいていバックにサーバがあるもの。 --サーバのデータをコンテンツとして表示するAndroid端末・アプリ、ユーザにとって息が長い

-開発環境や細かい違いが多いので、Javaという共通点はあってもすぐに熟練はできるものではない、というのが率直な思い --Javaで開発できるのとAndroidアプリの開発が出来るのが同義ではないのと同じ理由

-GAEもAndroidも、単体で開発する上での不満点は改善しつつある。その上で、双方の技術者の参入を円滑にする為にも、googleにはプロジェクト横断で仕様を揃えて欲しい

-AndoroidとGAE,プロジェクト自体をひとつで作れる? --共通部分をまとめてはいる。全部を一つに,という発想はしたことがないが・・・。。

-AndroidとGAEの通信にはHTTPですか? --そうです。

**第5セッション「Google App Engineプラットフォームの勘所」株式会社トップゲート 小川信一さん

【概要】 GAEを用いての開発の際に注意しておきたい「勘所」の紹介・説明。 <<

-gaeはPaaSに分類。自動でスケールアウト。スケールアウトサーバの管理は不要、アプリケーションのデプロイがメイン。 --gaeは基本的には自分で細かい設定ができない・する必要がない(メリットでありデメリットである)

-使いどころ --ただhtmlを表示するだけ、といった静的サイトも可能 --特定期間・特定の時間帯のみ負荷がかかるようなサイトには向いているかと。 --規模が大きい、クリティカルなシステム(基幹系)はgaeに向いていないと思われる。 ---設計が困難だし、GAE自体まだベータ版と思うべき。

-開発環境 --Java向けのSDKユニットテスト要にも各機能のスタブが提供されており、テスタビリティがとても高い。 ---アプリケーション開発に専念できる

-負荷に対してappserverのインスタンスが足りなくなってきた場合は、新しいappserverを起動する。・・・spin up -負荷が少なかったり、一定のリクエスト数を処理した場合はappserverが終了する。・・・spin down -平均レスポンス時間が1000msを下回るアプリのみ、インスタンス数の上限が30を超えることができる=無限スケールアウトする! --性能が良い実装を心がけ、努力しよう!

-GAEのインスタンスが違うということは、JavaVMが違うということなので注意

-スケールアウトするということは、複数のVMで実行される、ということ。 --変更が前提の変数をstaticに使うと・・・?・・・消えちゃう。 --memcacheサービスを使おう。 -ファイルアクセスやスレッド、ソケットの使用等が禁止されている。JDK内で使用できないクラスもある。 --依存するフレームワークやライブラリがそれを使っているかもしれない。 ---whitelistも参考に!!

-GAE特有の、常に発生する可能性がある例外がある。 --コントローラの大本などでも、念のためまとめてハンドルしておくこと! ---これらで落ちる場合、GAEが悪いのではなく、これらをハンドルしないアプリケーションが悪い。

-リソース使用量的な注意点 --API的な制限

-データベース機能 --bigtableという、分散kvsに分類されるデータベースを拡張したもの=データストアを使用する --bigtableの一行:キーとバリュー --bigtableではデータは主キー以外はバイナリで保存されるので、RDBのようにフィールドの値をみてフィルタを、という動作はできない。 ---検索用インデックスを保存する領域を容易、アプリケーションがデータを書き込んだ際に「データの書き込み」「インデックスの書き込み」の2つの領域へ書き込みを行う。 ---インデックスを作れないような条件は、検索ができない! --bigtableでは、ひとつのトランザクションで一行のデータしか処理できない。 ---それでは不便なので、行の親子関係を構築することで、同じ家族内の行であれば一度のトランザクションで処理することができる。 ----エンティティグループという。ひとつのトランザクションでひとつのエンティティグループを処理できる。 ----slim3のグローバルトランザクションはこれをも超える

-スキーマの設計について --どれとどれをエンティティグループとして構成するか=ひとつのトランザクションで処理したい対象は?が重要 --集計するような導出項目、カウンタは別途保持する --ジョインが必要ならジョイン済みのデータを作成する

-エンティティグループの設計とどこまで非正規化して保持するか?がキモ!基本的には書き込み時に頑張る方針。

-memcacheサービス --メモリにデータをキャッシュする ---保持するときにキーとバリューを指定して、取得するときはキーを指定。 ---全インスタンスから参照できるMapのようなイメージ。 ---クエリ結果などをキャッシュしておくと、datastoreよりも高速 --ただ、いつでも結果がそこにあると思うな!

-taskqueueサービス --処理をキューに追加するとバックグラウンドで次々に --処理が失敗すると成功するまで延々とリトライ

-cron --スケジュールバッチ処理。エラー終了でもリトライされない。

-まとめ --制限があるように感じられるかもしれないが、スケールすることを前提としているため、従来のアプリケーションとは別物、仕方ない。 --制限ではなく制約として受け止め、その制約を正しく理解することが大事 --新しい時代の設計・実装手法を学ぶための手段(養成ギプス)とも捉えて。

-Google Apps Marketplace --GAEでApps Marketplace向けのサービスを提供する・・・企業向け開発の経験豊富な場合に選択肢のひとつになるのでは?

**スペシャルセッション「Amazon Web Service」株式会社Abby代表取締役 米林正明さん

【概要】 Amazon Web Serviceについて。 <<

-AmazonAWSAmazon Web service)と称して,非常にたくさんの有用なサービスを提供してるよ! --S3:simple storage sevice、無制限のストレージ --RDS:relational database service、mysqlエンジン --simple db:分散database,Erlangで書かれている --SNS:simple notification service、通知サービス --SQS:simple queue service、メッセージをキューイング、無制限 --ELB:ロードバランサー --cloud watch:生存監視 --auto scaling:インスタンスを自動で増加減 --Elastic MapReduceHadoop,s3をつかってデータ入力

-AWSの特徴 --豊富なサービス、選べるロケーション --reserved instance:まとめ買い --RRS:稼働率の小数点以下○桁の打ち切りの違いで安く。 --クラウド操作をプログラムで行える

-AWS SDK for java --サーバ上にインスタンスを立ち上げるためのコードはたったの3行 --simple dbはeclipseプラグインあり。

**第6セッション「App Engineとソーシャルアプリ」The Seasar Project チームコミッタ ひがやすをさん

【概要】 コンシューマ向けWebアプリケーションの方が,GAEには向いている。そういった話を。 <<

-ソーシャルアプリで技術的に重要なこと --データベースがスケールアウトすること ---一般的に、データベースがボトルネックになりやすい ---Webは横に並べて負荷分散すればなんとかなる --Webが自動的にスケールアウトすること ---手動でインスタンスを増やしていると間に合わなくなるリスクがある

-ソーシャルアプリで金銭的に重要なこと --安い従量課金 ---インスタンスの時間課金だと使っていない分も必ず課金されてしまう。そして不慮の事態に備えて多めにインスタンスを用意したりしちゃうもの。 ---例えばGAEだと・・・630万PV/day で 15$/day --運用に関する人的コストが安い ---課金の設定以外することなし ---使った分しか課金されないので多めに設定しておけばおk ---念のため一日数回ダッシュボード(GAE上のアプリの動作状況が確認できる画面)をみればおk --無料のQuota ---500万PV/月 ぐらいまでは無料でいける ----インフラの初期コストが掛からない

-問題点 --年5,6回定期メンテナンスがあり、1,2時間ほどread-onlyになる ---日本時間の早朝に行われることが多く、意外と問題にならない --年に3,4回Datastoreが数時間不調になる ---タイムアウトを設定し調子が悪い場合でも必ずレスポンスを返せるようにしておく --アメリカにデータセンタがあるのでファイルの読み込みが遅い ---国内CDN(Contents Delivery Network)を利用する

-appengine向きのアーキテクチャ --htmlをブラウザにキャッシュさせAjaxでページの一部を書き換える ---ページ全体をクライアントにおくるのを極力避ける ---サーバ側のHTMLテンプレートはやめる ---Ajaxの呼び出しがエラーになっても動き続けられるように作る --携帯向けには静的なコンテンツは国内CDNを使い動的なコンテンツのみGAEを利用する

-HTML5がGAEに向いているわけ --ApplicationCache ---ファイルをローカルにキャッシュ ---ファイルの転送は一度だけ ---ネットが一時的に繋がらなくなっても大丈夫(携帯の圏外など) --ローカルストレージ ---Hashmapみたいなもん、ドメインごとにデータが永続化される・・・ブラウザをとじても残っている ---状態は全てローカルに持ち必要なタイミングでサーバに反映させる ---クライアントの状態が正。サーバはバックアップ。サーバに接続できなくても、そのうちsync出来ればOKと考える

-Slim3がいいかんじなわけ --Datastoreの操作が高速 ---EntityとModelの変換にリフレクションを使わない ----ソースコードを手書きで書いたのと同じようなコードをAPTが自動生成する(getしてset、みたいな) ----ソーシャルアプリはサーバで凝った処理はしないのでDatastoreの操作の高速性が最も重要 --Datastoreに特化した本が出ている ---世界で最もDatastoreについて詳しい ----ソーシャルアプリの開発をするのにもっとも重要なのはDatastoreの扱い --コミュニティが充実している ---仲間がいる、ということ!

-html5canvas、表示面積の広さに処理速度は反比例

-ハイリスク・ハイリターンでやらないと夢は実現できない --ただそうするにしても、ハイリスクの絶対値が低いものを積極的に選ぶ・・・この考え方はGAEとうまく結びつくところ。

-クライアント側とサーバ側との同期? --クライアント側のデータ構造をサーバ側のテーブルの構造に合わせると大変。やめたほうがいい --ローカルストレージを使う、バリューの中身をテーブルにそのまま突っ込む。みたいな。

-サーバ側は「クライアントがどう表示しているかは知らない」ぐらいに特化してしまってもいいと思う。

**感想! -「行ってもワケわからん言葉が飛び交ってんじゃないか」「すごくバカにされるんじゃないか」などと怯えていたけど・・・。 --話の内容がエントリー向け?ということもあり,「聞いてても何がなんだかサッパリわからん!」ということはなかった! ---むしろGAEは実際にいじったこともある・公開もしてるってことで、「進研ゼミをやったあとのテストを受けてるとき」の気分w -「休日にこれだけの人が自分の意思で集まって,熱心に耳を傾けている」という事実,雰囲気がとても刺激的。 --翌日の休日出勤がなけりゃ、懇親会にも参加したかったなー。 -やっぱ大阪遠いわ -Android開発やってみたくなった! --そもそもJavaがすきなら、iPhoneアプリ開発よりもAndroid開発に流れる方が自然だよね。 ---端末持ってないけど・・・。 -自分の会社としての仕事・業務に反映できる部分はあるか? --・・・うーん。 --やっぱうち(SIer、基幹系システム開発とか)がメインとしてる売り物にクラウドを適用ってのは考えにくいかも。 ---でも、GAEとかEC2とかを使ってのシステム開発の経験が(エンジニアにとって)非常にプラスな経験になりうるって思うことには変わりなし。 ----例えば。たしかにRDBは無くなることはないだろうけど、でももし「RDB禁止!」という制約が加わったときに果たして自分は,(有効な)代替手段を連想・提案できるだろうか?? ----そういったことをいちエンジニアとして養っておく必要性はあるなぁと実感。(今後技術的に方向転換を強いられる局面がないとはいえないと思うし!) -今回聞いた話は、基本的にどれも概要,導入どまり。今日聞いた話のいずれかをきっかけに「実際に手を動かせるか」,これだと思う! --(話を聞いてなんとなく勉強できたような気分になってるだけじゃー意味なし!)

・・・てな感じでしょうか。プレゼン資料が公開されればいいんですがー。

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

オープンソース徹底活用Slim3onGoogleAppEngineforJava

オープンソース徹底活用Slim3onGoogleAppEngineforJava