「qpstudy 2014.04 ~俺の屍を超えて行け、でも踏まないで~」をニコ生で観た

140文字にきれいに収まらないかもしれないので(きれいに収まっていないのはいつもだけどw)、こっちに感想を残しておこう。

qpstudy 2014.04 ~俺の屍を超えて行け、でも踏まないで~」がニコ生で観られるとのことだったので、昨日観てました(途中からですが)。

こういう勉強会をニコ生で観るのは初ですが、視聴環境も快適でした。ドワンゴさんまじドワンゴ

僕は開発よりの人間ですが、#qpstudyは動向をネットで追っかけるくらいのことはしていて、ちょうど今回、

初心者とは、インフラエンジニア業務2年未満、もしくはインフラエンジニアでは無い方を指します。

とのことだったので、インフラエンジニアでは無い立場の初心者として視聴し、勉強させてもらいました。途中ほとんど理解できない部分もあったけど、それを知ることができたのもまた勉強。その辺は僕の知識不足で、全体通してとても分かりやすく、楽しい発表でした。ライトスルー、ライトバックとか、情報処理技術者試験(タイムリーなネタを話題に出しておこう)くらいでしか聞いたことなかったしね。

あとは、作ったアプリケーションがリリースされてから、インフラエンジニアが何を考えて、どんなことをしてるのかとか、あまり普段の業務で知る機会がなかったし、割とリアルな声を聞くことができてよかったです。自分の立場は、完全にアプリケーション開発というだけではなくて、APサーバ、DBサーバみたいなミドルウェア周りとか、シェルスクリプトをがりがり書くみたいなこともやってたりだけど、ネットワークやOSのレイヤも含めての全体像はなかなか見えてなかったので、いいきっかけになりました。

アプリケーション開発する際でも、ユーザはもちろんのこと、インフラエンジニアのことも考えてアプリケーションは開発しないといけないなってことと、(流行りのツールやフレームワークも大事だけど)やっぱり基礎は大事だなってことを考えさせられました。

DropwizardでWebアプリケーションを作る

調べものをしていたらたまたまDropwizardを見つけたので試してみました。

Dropwizardとは?

Dropwizard is a Java framework for developing ops-friendly, high-performance, RESTful web services.

公式サイトにある通り、「運用に優しく、ハイパフォーマンスな、RESTful Webサービスを作るためのJavaフレームワーク」のようです。

依存関係としてdropwizard-coreを一つ追加すると、Jetty, Jersey, Guava, Logback/slf4jなどのよく使うライブラリが含まれます。

単純な実行(アプリケーションの起動)なら、Javaがインストールされている環境なら、ビルドしたjarファイルと設定ファイルがあれば、 java -jar {jar file} server {configuration file} で終わりです。現実的にdaemonizeとかサービス起動したい場合は少し手を加える必要があるかも。

作ってみた

Getting Started」を写経してHello Worldアプリケーションを作りました。ただし、ビルドはMavenではなく、Gradleで行うようにしました。

https://github.com/tq-jappy/dropwizard-example

Dropwizardのバージョンは0.7.0です。

できあがったものは、@hina0118さんの「DropwizardのHello World - Qiita」のほぼ焼き直しになった(ただし@hira0118さんの例はバージョン0.6.2)ので、0.6.2と0.7.0の間の差分だけメモしておきます。

リポジトリ

build.gradle

  • 0.6.2
  compile 'com.yammer.dropwizard:dropwizard-core:0.6.2'
  • 0.7.0
  compile 'io.dropwizard:dropwizard-core:0.7.0'

パッケージ

com.yammer.dropwizard -> io.dropwizard

一部クラス名やAPIの変更などもあります(公式が最新バージョンに追随しているのでそちらを参照)

起動ポートを変更

デフォルトの設定では8080番ポートでアプリケーションが、8081番ポートで管理メニューが立ち上がるのですが、このポートは何かと被ることが多いので、設定ファイルを以下の通り変更しました。

template: Hello, %s!

defaultName: Stringer

server:
  applicationConnectors:
    - type: http
      port: 18080
  adminConnectors:
    - type: http
      port: 18081

この辺の設定の仕方も0.6→0.7で大きく変わっています。

ちなみに、server.type: simpleを指定した以下の書き方はうまく動きませんでした…。

server:
  type: simple
  applicationContextPath: /application
  adminContextPath: /admin
  connector:
    type: http
    port: 8080

ビルド

ビルドしたjarファイルのサイズは約10.2MBでした。軽い。

感想

Hello Worldでのつまみ食い程度ですが、第一印象はとても可能性も感じるものでした。(一部では)2014年大ブレイクと囁かれているみたいで、今後の発展に期待です。

Java EEの機能をフルに使う必要がなく、とにかくサクッと開発を始めたいなら、とてもいいですね。

あと、以前作ったJavaアプリケーションをポータビリティの高いものにしたいというのはずっと悩んでいたところだったので、Dropwizardを使えばうまくフィットしそうです。元々は、Jenkinsのように java -jar jenkins.war でアプリケーションが立ち上がる実行可能WARファイルを一から作ることを考えてました(JenkinsはWinstoneを中に持っていたんだっけ…?)。この辺りの起動の仕組みは、スクラッチで作るより、Dropwizardを使うほうがずっと簡単にできそうですね。

現実的なWebアプリケーションを作るにあたってはいくつか懸念事項(フロントエンド周り、DI、ORMはDomaを使いたい、とか)があるので、少しずつ消化していきたいです。

VeeweeでCentOS6.5のboxを作る

ただの作業記録です。

  • 以下のGemfileを作って bundle install
source 'https://rubygems.org'

gem 'veewee'
  • CentOSのテンプレートを探す
# bundle exec veewee vbox templates | grep CentOS
  • CentOS6.5が見つからないため(veewee 0.3.12時点)、CentOS6.4を選択
# bundle exec veewee vbox define centos6_64 'CentOS-6.4-x86_64-minimal'
  • boxファイルのビルドを実行
# bundle exec veewee vbox build centos6_64
  • 実行するとエラー(どうやらファイルがなくなっている模様)
http://yum.singlehop.com/CentOS/6.4/isos/x86_64/CentOS-6.4-x86_64-minimal.iso:
404 Not Found
  • CentOS6.5のminimal.isoはあるみたいなので、ISOファイルの取得情報が書かれているファイル definitions/centos6_64/definition.rb を書き換える(isoのMD5http://yum.singlehop.com/CentOS/6.5/isos/x86_64/md5sum.txt を参考にしましたが、veeweeのmasterブランチにはCentOS6.5用のテンプレートがあるみたいなので、それと差し替えてもよいと思います)
   # :iso_file => "CentOS-6.4-x86_64-minimal.iso",
   # :iso_src => "http://yum.singlehop.com/CentOS/6.4/isos/x86_64/CentOS-6.4-x86_64-minimal.iso",
   # :iso_md5 => "4a5fa01c81cc300f4729136e28ebe600",
   :iso_file => "CentOS-6.5-x86_64-minimal.iso",
   :iso_src => "http://yum.singlehop.com/CentOS/6.5/isos/x86_64/CentOS-6.5-x86_64-minimal.iso",
   :iso_md5 => "0d9dc37b5dd4befa1c440d2174e88a87",
  • リトライ
# bundle exec veewee vbox build centos6_64
  • 成功
The box centos6_64 was built successfully!
  • box作成
# bundle exec veewee vbox export centos6_64

補足

気軽にVagrantを使うのであれば、Vagrantbox.esにて公開されているものを使えばよいと思います。
今回、CentOS 5.10/6.5のそれぞれについて、x86/x86_64の組み合わせで、合計4つのboxを用意したかったのです。どのパターンのboxも公開はされているのですが、boxファイルの出処がバラバラで、「要するに何が入っているか分からなくて管理するの怖い」状態だったので、自前で素の状態のboxを用意したいと思ったのでした。

vbox build は10分ちょっとで自動で終わりますし、boxファイルは一度作っておけばずっと使えるので、許容できる範囲の手間だと思います。

Jenkins×Capistrano3×Chef×serverspec×Dockerを使った一気通貫な開発

ここ最近、タイトルの通りのことをやろうとしていて、そのための雑記(記録)を書いていこうと思います。

目的

自動化できるところは可能な限り自動化し、テストできる(すべき)ところは可能な限りテストする、といった当たり前のことを当たり前にやって、開発業務を効率化する、というのが目的。

以下のようなアプリケーションをターゲットにします。ビルド職人、デプロイ職人への依存度を小さくし、なるべくシンプルで統一的なフローにしたいと思います。

ツールの検討

ツールは目的ではなく手段なので何でもよいのですが、Jenkins, Capistrano3, Chef, serverspec, Dockerといったツールを選ぶにあたっての評価ポイントは以下。

  • 使い慣れているかどうか
  • 情報量が多いか、公式のドキュメントが整理されているか
  • オープンソースであること(調査やカスタマイズのしやすさ)

あとは、Capistrano3、Chef、serverspecという組み合わせにすると全部Rubyで統一できるので、学習コストが低くて済むだろうと(安易に)考えました。

なお、このエントリを書いている時点では結論が出ていないので、後になってダメそうだったら別のツールを選んでいるかもしれません。逆にこなれてきたらroundsmanとかを使ってみるかも。

ツールの棲み分け

それぞれのツールは会社or自宅で使ったり試したりしているので、概要は理解しているつもりなのですが、これらのツールを一気通貫で使う場合、以下の点をきちんと考えていくことが重要だと感じます。

  • Capistrano3とChefの棲み分け
  • ChefとDockerの棲み分け
  • Capistrano3とJenkinsの棲み分け

どのツールもやろうと思えば色々できてしまうので、きちんと役割分担を考えていかなければ、ツールに使われるようになってしまうので危険(これまでの経験上)。いきなりroundsmanを使わないのも、その辺りを危惧しているためだったりします。

また、指針はあっても絶対の正解が無い部分だと思うので、プロジェクトにフィットさせていくのが腕の見せどころなのかなぁと。

DockerとChefの棲み分け

Dockerで用意するのは、「必要最低限の設定がされたイメージにする」ことを念頭に、Chefとの役割を分担します。

そうすると、Dockerがやることは、基本イメージに対して「SSHでリモートから接続できるようにする」+αくらいのことだけになるのかなぁと。とは言え、SSH接続させるためだけでも Dockerfile にユーザの追加、鍵の生成、等々が必要になるのですが…。

アプリケーションが利用するミドルウェアのインストールなんかはChefが担当します。

Capistrano3とChefの棲み分け

当初この棲み分けが頭を悩ませたのですが、capistrano-railsがやってくれることから逆算して、考えると道を大きく外すことはないかなぁと思いました。

capistrano-railsでデプロイすると、以下のあたりが実行されます(rake db:createはされないんですね)

  • アプリケーションのダウンロード
  • bundle install
  • rake assets:precompile
  • rake db:migrate
  • アプリケーションの起動・停止

cap staging deployで実際に何回かデプロイしてみると、切り戻しが簡単にできるように、デプロイ先のディレクトリで複数のアプリケーションが存在していることが分かります。

複数のバージョンを残しておくCapistranoと、冪等性によってある状態に収束させるためのChefとでは根本的に用途が違うものなんだと、理解がちょっとだけ深まりました。

最後、Docker、Capistrano3がカバーしない中間の部分はChefが担当します。
とは言え、DB作成をChefでやるのは微妙な気がするので、Capistrano3でやります(うーん…)。デプロイしないと rake db:create 実行できないですしね。

Capistrano3とJenkinsの棲み分け

ここの棲み分けはあまり悩まなかったのですが、一応考えた内容について言及。

JenkinsにもDeploy Pluginというものがありますし、Capistrano3を使わずに、デプロイツールとしてもJenkinsを使うことも可能だと思います。

「複数サーバへデプロイする」という点を取っても、例えば、Jenkinsのマルチ構成プロジェクトでできると思います。

今回の棲み分けとしては、ビルド~パッケージ作成までがJenkins、以降のデプロイはCapistrano3が担当するようにしました。

「あらゆる環境へのデプロイ方法を統一させる」という継続的デリバリーの原則からすると、開発環境へのデプロイは下のようなコマンドを実行するジョブをJenkinsで作って実行させる予定。

# cap development deploy workspace=${WORKSPACE} ... その他パラメータ

Qiitaとの棲み分けを考えるテスト

ブログでは最近の活動とか、Qiitaで書いた内容を紹介してみたらどうだろうか?というものです。

読んだ本

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術

なぜ、システム開発は必ずモメるのか?  49のトラブルから学ぶプロジェクト管理術

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術

通勤中に読んでました。頭から順番に読むのではなく、その時の気分で興味のあるところをつまみ食いする感じで。

「当たり前じゃん」みたいに感じる点ももちろんありましたが、法規面での記述とか、過去の判決の事例とかは参考になる点が多かったです。

本の中の登場人物の会話が馴染めるかは、人によって分かれそうですね。

Everyday Rails - RSpecによるRailsテスト入門

今までテストを書いていても、「この書き方でいいんだろうか?」とか「コピペばっかだなぁ…」みたいな、モヤっとした感覚が払拭できなかったんですが、この本を読んで多くの部分がスッキリ解決しました。

「コントローラのテストはこんな感じでこのレベルまで書く」といったさじ加減が分かってくるので、人によってバラバラのテストコードになることも抑えられるし、メンテナンスしやすいテストコードが作れそうです。

あと、翻訳も素晴らしいと感じました。違和感のない読みやすい文章でした。

トレンド

内製アプリケーションのインストールのテストをCIで回すべく、Dockerserverspecを試してます。

WEB+DB PRESS伊藤直也さんの記事にはかなりお世話になってますね。

当面のゴールは、Jenkins, Capistrano, Chef, Docker, serverspecを一気通貫で通すことです。

Qiita

3月はこれまでに2件書きました。

はてなブログに移行しました

はてなブログに移行しました。移行したのにあまり理由はありません。強いて言うなら、Markdown記法が使えるということと、タイトルが浮かんだことくらい。

ただ今後は、整理したトピックはQiitaに書くようにしていくかもしれないです(この辺の棲み分けは試行錯誤中)

とは言え、このブログも今まで通りひっそり続けていくつもりなので、よろしくお願いします。

Enterprise × HTML5 Web Application Conference 2014に行ってきた

2月28日は、会社に許可をもらって、終日Enterprise × HTML5 Web Application Conference 2014明星大学 日野キャンパス)に参加してきました。

明星大学は初めて来たのですが、のどかで落ち着く所だなと思いました。気温も寒くなく、普段のように窮屈なスーツである必要もなかったので、リラックスして聴けました。

セッションの内容をレポートしてみたいと思います。例のごとく、ほとんどはスライドが公開されると思いますが…。

パネルディスカッション「HTML5エンタープライズITの向かう先」

開会宣言(エンタープライズにおけるHTML5 3つのニーズ)
パネルディスカッション(過去と現在を振り返る)

パネリスト3人(白石さん、春日井さん、川田さん)の発言が混ざっていて分かりにくいですが、ご了承ください。

HTML5はなぜウケたか

  • canvas, videoなどによる表現力
  • WebSocketなどのAPIが充実してきた
  • Webは心理的に受け入れやすい(⇔Adobe)。Web画面をリッチにしたいというニーズに標準が追いついた

現状

  • 東証一部上場している約2,000社のうち、HTML5マークアップされているサイトは約9.4%
  • 同、スマートフォン対応(レスポンシブ、専用サイト)しているのは14.9%
  • 普及しているのが少ない理由
    • 費用対効果が見えにくい?
    • 技術的なハードルが高い?

これからどう変わっていくか(設計・開発・運用)

  • HTML5はオープン系の技術。ベンダ系からオープン系へのシフト
    • ベンダ系とオープン系での「ツール」に対するアプローチの違い
      • ベンダ系ツールでは細かいカスタマイズがしにくい(画面上での繰り返しや条件分岐など)
      • ベンダ系の場合、全部ベンダのせいにすることができる
      • オープン系の場合、責任はすべて自分(全部Red Hatのせいだ、とも言えたりするが…)
      • W3Cに加盟して意見を言う、なども必要
      • オープンな技術を使っているのにツールがベンダのものに囚われている感覚への抵抗
      • オープン系かベンダ系かは宗教論争みたいな側面もある
    • Web Component(コンポーネントUIの技術)ができつつある
    • Microsoftでは、HTML5 Labsがある。どういう形でVisual Studioに取り組むかなどを検討している。
    • WebGL
      • Adobe Atmosphereなどがすでに10年前に存在し、ポシャった歴史
  • 運用
    • ブラウザのアップデートが早い(Chromeは6週間に1回、アップデートが一番遅いIEでも2年に1回)
      • サポートするかしないか、検証するかしないかのラインを決めないと追いつかない
      • セキュリティアップデートはよいが、機能改善がネック
      • Microsoftブラウザのサービスパックの仕組みが変わった。
        • XPまでは、ELの10年間はIE6のサポートを保証していた。
        • 8では、Service Packが上がると強制的にアップデートされる。
        • 一応ブロッカーツール、IEAK(Administration Kit)というのがあり、強制アップデートをブロックすることは可能。

質疑応答

  • Q1) HTML5が普及していないのは、メジャーなブラウザがIE8だからな気がする(IE8はHTML5非対応)。Webシステムの開発者として、サポートブラウザについてはどのようにアプローチしていけばよいか?
    • 関わっていたプロジェクトでは案件ごとにサポートするIEのバージョンがバラバラだった。
    • IE8以下はIE依存が強い
    • ドキュメントモードが有効であるがゆえに、かろうじて動いているサイトも多い
    • IE11はGood Jobなブラウザ
      • 過去のIEの互換を保ちつつも、今後を見据えた戦略的なバージョン
      • ドキュメントモードを非推奨とすることで、意図して部分的に動かないようにしている
    • 2020年 Windows7がEOLの時、確実にドキュメントモードはなくなっているだろう。
  • Q2) HTML5で基幹システムを作りたいが、ユーザ企業の中で日本で1番先進的な企業はどこか教えて欲しい?
    • 立場上オープンには言えない(Microsoftの春日井さん)

業務系Webアプリケーションに求められるUIとUX

  • UXの根本=体験
    • 会社、サービスがもたらすエンドユーザのあらゆる部分を包含するインタラクション(Webアプリケーションならば、ブラウザを開いてから閉じるまで全てが対象)
  • UXにおける中心の概念は「価値」
  • 真のニーズを拾うことが重要
  • 本格的に取り組むのは難しい
    • 意識から変えていく
      • 常になにか一つ改善しようという意識
    • 一人ではできない。そこから文化にしていく
  • (公共系を除き)実現性+金額だけでは競争に勝てない
  • お客のことを考えた根拠のある「思い込み」
  • 「技術的な仕様です」ではなく、そこから解決策・妥協案を示す
  • 仕様通り動けばよいというわけではない。どのような操作が行われるか(利用シーン)を考慮する
  • プロセス(※ 例として出したのはペルソナ・シナリオ法)は道具であり、盲信しないこと
まとめ
  • 価値に基づいた優先順位の判断
  • メンバー間での意識共有
  • メソッド化
  • 人に合わせるシステムを
  • 属人的な開発をやめる

リッチアプリケーション開発を助けるOSSのJSフレームワーク「AngularJS」の魅力

概要
  • 今もっとも伸びているJavaScriptフレームワークの一つ
  • API
    • Directive, Filter, Provider, Service, ...
  • DI
    • minifyした時に動かなくならないように、文字列で名前付けしておく
Enterprise × AugularJS
  • Yeomanのangular-generatorを使ったデモ
    • インターネット接続が必要なため、見れず(残念)
    • うまくいく場合、yeoman angularでscaffoldingし、雛形が作られる
  • Angularを使ったアプリのデモ
    • 入力値との双方向バインディングによるテキスト表示
    • フィルタ
    • バリデーション
      • キー入力ごとにバリデーションをして、余計なリクエストが飛ぶのを避ける(バリデーションOKでなければサブミットできない)
  • grunt serverでLive Reload
  • テスト環境
    • AngularJSチームが作ったKarmaというのがある
    • ファイルを保存した瞬間にテストを走らせる
  • Yeomanは無理に使わなくてもよい(特にエンタープライズでは)
  • エンタープライズにおいて、品質はどう担保するかが課題
  • AngularJS, Knockout.js, Ember.jsの比較
    • AngularJS → フルスタック、学習コスト高、自由度低
    • Knockout.js → シンプル、学習コスト低、自由度高
    • Backbone.js → シンプル、学習コスト高、自由度高
    • 自由度が低いことは、エンタープライズの分野ではむしろ品質管理の面で有効
    • AngularJSを使うとJavaScriptを書く量が少なくて済む

Webアプリ開発者のためのHTML5セキュリティ入門

公開されているスライドを見るのが最善だと思います。

サーバ側、クライアント側の両方に言及されており、Webアプリケーション開発者にとっては必見の内容だと思いました。

発表練習したら1時間30分になってしまったとのことで、時間の都合でCSP (Content Security Policy)の話は割愛されましたが、個人的には1時間30分でも聴きたいくらいの内容の濃いセッションでした。

オープンソースで始めるオフラインアプリケーション開発入門

注)スライドの中で、html5expertsをはじめ様々な役に立つサイトを紹介されていたので、そちらも併せて見たほうがよいと思います。

背景
  • 客先で自社製のアプリケーションを見せる必要がある。
    • リッチクライアントが必要
      • 下手が画面を見せるのも営業的にNGなため
    • インターネットにつながっていないと見られないのは論外
Single Page Application
  • メリット
    • JavaScriptのグローバル環境が維持される
    • WebSocketとの相性
  • デメリット
    • フルOSS
    • 技術要素が多い(JavaScriptフレームワーク、altJS、CSS Processor、開発環境、バックエンドとの通信、バックエンドの実装)
    • 面倒ならSenchaという手も
  • JavaScriptフレームワーク
    • 効率と保守性の観点で有効(ロジックを整理することができる)
    • Yeomanは好き
    • CSS Processor
    • モック開発
      • easymock or Stubbyを使い、フロントエンドだけをどんどん開発していくことができる
オフラインWebアプリケーション
  • 実行させるリソースをブラウザに保持する
    • 高速性やサーバ負荷の軽減のメリットもあるが、エンドユーザにとって、オフラインブラウジングが一番重要
  • キャッシュクリアは意外と簡単にできる
  • データの同期はWeb Workersでスレッド化

OSSのブラウザ自動テストツール「Selenium」を使った、開発・テストの効率化

Seleniumとは?
Selenium WebDriver
  • プログラミング言語での実行
    • 使い慣れた言語で
    • if, for, 変数が使える
    • 共通化によるメンテナンスコストの削減
  • JUnitでのデモ
  • その他
Selenium IDE
テストマネジメントにおける3つの誤解
  • 自動化でテストコストがかからなくなる
    • メンテナンスコストは発生し続けると認識すべき
  • 全てのテストをSeleniumで実行すればよい
  • 誰でもテストスクリプトが作ることができる
    • 安定したテストスクリプトを作るためには、スキルが必要であることを認識すべき
関連トピック
  • モバイルテスト
    • 公式(iPhone Driver, Android Driver)
    • サードパーティ製(Appium, ios-driver, Selenroid)
      • Appium
        • ネイティブなことが強み
      • サードパーティ製の方が使い勝手がよいので、公式にこちらが推奨になった
      • これらの3つを統合して標準化を進めている(Selenium3)
  • HTML5対応
  • 一緒につかわれることの多いツール類
    • DBUnit
    • Jenkins
    • Selenium WebDriverの大体としてのライブラリ
      • Capybara(Ruby)
      • Geb(Groovy)
    • Phantom
    • クラウドでの実行サービス
      • Sauce Labs
      • TestingBot
      • Scirocco Cloud

JavaエンタープライズアーキテクチャにおけるHTML5

アーキテクチャ
  • 4つの要素
    • プロセス
    • 構造/構成
    • 提供機能
    • 利用価値
  • バランスが大事
    • プロセス改善だけとか、今どきのフレームワークを導入するだけではダメ
    • 環境(制約)の中で利害関係者の感心事をどのように整合させるか
  • ユーザとITの関係
    • モノ的な利用(クライアントとサーバ)からサービスとしての利用(デバイスとサービス)へ
  • 統合と分散
  • 疎結合
HTML5の可能性
  • SPAには期待できる
  • 注意点
    • ただしイケメンに限る」問題
    • 「方法論」の誤解
    • ガチのアプリケーション開発になるため、生産性は低くなる
      • 似ているからといって同一視しない
    • 既存の手法とのミスマッチ
  • 今は混乱期
  • エンタープライズでの適用
    • 「技術に無理はさせない」こと
      • 「それ○○でもできるよ」は危険なサイン
    • 非推奨な領域
      • 複雑な業務アプリ
      • ネイティブ連携
        • ローカルファイルやデバイス間通信は不得意
    • 推奨領域
      • サブシステム的な扱い
まとめ
  • アーキテクトの始点からHTML5を捉えるべき
    • テクノロジー単体ではなく、よいITサービスのためにどのように適用できるか
質疑応答
  • Q1) タイトル的にJava8の話だと思っていた
    • Java CCC 2014(5/18)で寺田さんの話を聴いてください(笑)
  • Q2) 今ある業務アプリをそのまま適用できないとのことだが、デザインプロセスは今後改善されていくのか?
    • 今後できてくるだろうと思う
    • 新しいデザインの仕方を(UI/UX含めて)模索の最中
    • デザイナはデータの流出には興味があるが加工には興味が無い、一方で開発者はその逆、など思惑の違いなども要考慮

世界のビールが楽しめる、情報交換会!!

普段こういう懇親会には参加せずにすぐに帰ってしまうのですが、今回は参加しました。それだけ今日のセッションが充実してテンションが上がっていたのかもしれません。別にドイツビールと食事が目当てなわけではありません、多分…。

感想

ベンダ系、オープン系と分かれていましたが、上記の通り、終始オープン系のセッションを聴いていました。
今後どのようなことを頭に入れてHTML5に取り組んでいくかといったビジネス的な側面から、具体的な実現技術に至るまで、色々と濃い話を聞けたと思います。IEサポートへの取り組み、西村さんのセキュリティの話などは、HTML5云々に関わらず、有益なものが得られたと思いました。

まずは、フロントエンジニアとしての力を、チームメンバー含めて底上げしていく必要があるなぁと感じました。

オープンソースカンファレンスは明日(日付変わって今日)も続きますが、充実した1日になったことをここでお礼申し上げておきたいと思います。

スタッフの皆さま、発表者の皆さま、ありがとうございました。また、参加された皆さま、おつかれさまでした。