読者です 読者をやめる 読者になる 読者になる

Seaser2終了から学ぶフレームワークとの付き合いかた

Seasar2が終わってしまって、フレームワークとどう付き合うべきなのかなど思うところがあったのでまとめました。

2016年9月26日に終わりを迎えた

この日Seaser2が正式にメンテナンスおよびサポートが終了になった(ただし「DBFlute」「Doma」「Mayaa」など続いているプロジェクトはある。詳しくは公式サイトを参照 → http://www.seasar.org/ )。

この発表自体に驚きはなかった。その1年前から終わる告知みたいなものはされていたし、もっと前から積極的な新規開発は行われていなかった。なので数年前から徐々に使わなくなっていたし、そんな雰囲気は感じていた。

当時はそれがよい選択だった

心情的にはさみしさと感謝がある。私はSeaser2が流行っていたころに20代中盤で、数々のプロジェクトでお世話になったからだ。

Seaser2が流行っていた頃はStrutsによってフレームワークやOSSという概念が浸透してきた時期で、プロジェクトでどのフレームワークを選ぶのかが一つの大きな関心事だった。「Seaser2」「Struts」「Spring」あたりが有力な選択肢だったと思うが、その中でも「Seaser2」は人気だった。

国産であったことが人気の一番の理由だったと思う。日本語資料の充実などは国産ならではで、MLも中心は日本語だったのでなんかあったらすぐに直してくれそうという考えもあった。なんだかんだ安心感は大きかった。もちろんプロダクト自体もよかった。DIコンテナやAOPなど先端のモノは含まれていたし、個人的にはS2Daoはとても使いやすかった。

フレームワークの選定は難しい

ここでSeasar2を選択したことについてふりかえると、当時、2016年頃終わるかなぁと予想できた人はいなかっただろうし、文句なんか出なかった、妥当だと思えた。これが例えば今だったら「おいおい」ということになる。

継続されるフレームワークを選べなかったという点で言えば、結果的にはSeasar2を間違えであった。ただそれは予想しきれない部分も多いことなので、結果論でしかない気がする。新規開発が停滞してきたあたりに察するぐらいしかなかったのだと思う。

ただ、ここまでの規模感のSeasar2が終わる可能性があるということを真剣には考えていなかった気がする。そんな雰囲気もなかった。

こう考えて行くと、継続されるフレームワークを選ばなければいけないということが無理な話かもしれない。同じフレームワークでも下位互換が確保されないバージョンアップがされる可能性もある。なので選択自体に重きをおくより、フレームワークもいざとなったら切り替えるという覚悟が必要かも知れない。

フレームワークを含めたメンテが必要。それができないプロジェクトはアップデートしないことを覚悟させるor自分たちで直す。

こうなるとSeaser2資産が心配になるが、みんなどうしているのだろうか。私のように数年前から徐々に離れていったのだろうか。全社をあげて使っていくと宣言していた会社もあったような…。

基本的な考え方としては流行りのフレームワークであっても何らかの理由で終わることはある。終わらないにしても実質的に死んでしまっているような状態になってしまうことがある。なので、フレーワークを含めてメンテし続けてプロジェクトを運用していくのが正論なのだろう。

Seasar2ぐらいの規模感であっても終わるのだから、数年単位でフレームワークごと見直す機会を設けるべきなのだろう。予算は前もって確保しておきたい。フレームワーク変更なんて表向きに変化が現れないやっかいな作業だが、やるときはやらないとしょうがない。それがなんとかできるプロジェクトはそうとう必要とされているプロジェクトということ。

Webのフレームワークなんてもはや開発やメンテがいらないと思われるかも知れないがそんなことない。セキュリティ系のメンテは必要だし、スマホやクラウドなど新しいモノは出てくるわけだからそれに対応した新機能はやっぱり必要。

それができないプロジェクトは実質使わなくなったものになっているか、アップデートされないことを覚悟させなくてはいけないってことかな。いやいや、OSSの基本に立ち返って自身でメンテや開発するもの一つの選択肢。ソースは公開されているのだから。

Javaフレームワーク開発入門

Javaフレームワーク開発入門

「Illuminated Keyboard K740」は最高の有線パンタグラフキーボード

職業柄とてつもなく長い時間PCを使うことになるので、キーボードはいろいろこだわってきたつもりで、最近たどり着いたのが「Illuminated Keyboard K740」になります。今回はそのレビューを書きます。

LOGICOOL イルミネートキーボード K740

LOGICOOL イルミネートキーボード K740

レビュー

  • (USB接続の)有線であること
    • 電波状況の悪さや電池の残量を一切気にしなくていい
    • 線が邪魔に思えるが、机が整っていれば1本ぐらいであればそんなに気にならない
  • パンタグラフ式であること
    • これは好みかもしれませんが、メンブレン式より打感が低いのが楽
    • ノーパソはほとんどパンタグラフなので、それとも相性がいい
  • パームレスト付き
    • これは意外とうれしい。手首が楽。
  • キー配列
    • 大きなクセもなく問題ない
  • 価格もそこまで高くない
    • 執筆時の相場(2017年4月現在)で8,000円ぐらい
  • イルミネーション
    • あってもなくてもいい。そんなに暗い場所で作業しないので…。

有線のパンタグラフとしてはいままでで一番いいと思っています。

有線がいいとかパンタグラフがいいとかは好みの部分が大きいですが、やはり電波や電池のことは気を使いたくないので有線でパンタグラフを選んでしまいます。その中でも「Illuminated Keyboard K740」がベスト。

パームレストがついていることをはじめとして、長く使っていても疲れにくい工夫がされているところが感覚的に使いやすいことにつながっているのかなあと思います。うまく表現しづらいですが全体の総合点がとても高いです。キー配列も申し分ないので最近は手放せなくなっていて自宅と職場で使っています。

イルミネーションはあってもなくてもいいかな。そんなにくらい場所で作業することはあまりないので、まあ暗がりで光るのが最初は面白いですが…。

LOGICOOL イルミネートキーボード K740

LOGICOOL イルミネートキーボード K740

プログラムコメントはもっと書かないべき

「プログラムコメントはたくさん書くべき」の方が一般的かもしれませんが、リスクも考えましょう。この記事はプログラムコメントを極力書かないようにしている私のスタンスをまとめてみました。

プログラムコメントのリスクを考えると、書かない方がいい

私はプログラムコメントがリスクの方が高くあまり意味が無いと思うようになってから、なるべく書かないようにしている。例えば次のようなリスクがある。

  • コメントがメンテされず、コードと乖離してしまう
  • 書くこともないのにやっつけで書いてしまいただのノイズになる

「コメントがメンテされず、コードと乖離してしまう」については、他人の作成したコードを改修作業したことがある人なら理解できると思うが、コードを改修するとしてもそのコメントの方が改修しづらい。今行っている改修がこのコメントにどう影響しているのかが判断しづらいので、コメントは放っておきたくなる。そんなことを重ねていると、コメントとコードが乖離してしまってとても困った状況になっていく。

また「 書くこともないのにやっつけで書いてしまいただのノイズになる」もよくある。プロジェクトの決まり事でとりあえずかくとこんな感じになる。

/**
 * 口座クラス
 */
public class Account {
    …
}

クラス名をみればわかることをわざわざ日本語にしても仕方ない。ほんとにこれだけなら書かない方がいいのに、決まりだから書いたりすることがある。

このように考えていくと、プログラムコメントはとてもリスクが高くて意味の無いことが多いことに気がつく。

プログラミングでコメント機能を最初に教わるときに、こういったリスクの説明をおそらくされない。むしろ講師の人は「コメントはなるべく書きましょう」という言い方をする方が多い。それをずっと引きずる人が多いので、コメントをたくさん書きましょうという風潮になっている気がする。ただよく考えると、そんなにウェルカムなものでもない。リスクを考えるべきである。

コメントを書くより「コードを直す」を優先すべき

私はコメントを書きたくなってしまったら「コードを直す」ことを考えるようにしている。

コメントを書こうとしているときは「このコードでは他の人に伝わらないかもしれない」と考えているということなので、根本としてはコードが悪い状態なはず。なのでコメントに頼らないコードにすることを第1に考える。これはその状況になったときだけ考えるのではなく、常日頃から考えているし、考えておかないといけない。

コメントを書くぐらいだったら、ドキュメントを書く

コメントでは直近のコードの説明以外にも、全体像の説明であったり仕様の説明であったりを書きたくなることがある。ただこれはそもそもコメントに書くべき事ではない。ドキュメントにすべきことである。

ただドキュメントにしたところで、ドキュメントがメンテされないとコードと乖離してコメントと同じ問題を抱えてしまう。私はこの問題を「ドキュメントはそのとき(作成時時点)の考えのスナップショットとする」という考え方で対処している。時間が経ちすぎていれば参考にしないし、必要な物は何度も作り直すので、更新される。本当に更新され続けるのはほんの一部にしておけば、負担も少ない。

とはいえ、コメントを書くことはある

ここまでの書いたとおり私はコメントを極力書かないようにしているが、次の場合はコメントを書くことがある。

  • 言語の勉強

新しい言語や久しぶりに使う言語の場合はコメントを書きながら勉強することがあるし、ブログなどでコードを説明する場合には使う。

コメントを極力書かないスタンスの人が、どの場面はコメントを書くべきかはまだ研究中。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

  • 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2012/06/23
  • メディア: 単行本(ソフトカバー)
  • 購入: 68人 クリック: 1,802回
  • この商品を含むブログ (137件) を見る

「APIって全部覚えるの?」というプログラミング初心者の疑問にちゃんと答える

プログラミング講師をやっていた時期あり、そのころ聞かれた疑問をちゃんと答えてみたくなったのでまとめました。プログラミングをこれから始めますという人向けです。

A.「APIを全部覚えようとしてはいけません」

理由を上げるとすると次の2つ。 - 全部覚えられるモノではないので、全部を覚えている人はいない - 実際に使うモノは限られるので、全部を覚えようとしてはいけない

まずそもそも全部覚えることは不可能です。数が信じられないぐらい多いからです。例えばJava SE 8のAPIリファレンス(こちら→http://docs.oracle.com/javase/jp/8/docs/api/)を見ていただければわかりますが、覚えようとすると途方に暮れるレベルです。クラス名だけでも無理でしょう。これがある期間でアップデートされたり追加されたりするので無理なはなしです。

それに、実際に使う範囲はかなり限られます。というより標準APIなどは相当広い範囲をカバーしたいという考えがあるためかなりの汎用性を持たせています。ただそれが、使う側にとってはどうしても関係ないAPIになります。毎日プログラミングをやっていても一生使いそうにないなというAPIが山ほどあります。また使う側の側も毎日プロジェクトを移り変わるなんてことがないので、そのプロジェクトで扱わなければやはり使わないAPIになっていきます。ということを考慮するとかなり限られた範囲しか使わないので、全部を覚える必要はないということになります。

どんなAPI(クラス・メソッド・関数など)があるのかをなんとなく把握して、実際に使う時には調べる

実際には、こういうかんじです。

「使う時には調べる」とサラッと書きましたが重要です。まずは公式のリファレンスをしっかり見られるようして、確認するクセをつけましょう。人の記憶は曖昧なので使ったことあるものでも自信が無ければ必ず調べるようにした方がいいでしょう。学校の学力テストをやっているわけではないので、わからなかったらその場で調べればいいのです。

書籍の解説書などもいくつか机においておきたいところです。公式リファレンスも慣れていないとわかりにくい場合などあるので、書籍やWebなんかも頼っていきましょう。ただし、書籍やWebなどは書かれている文脈が違って通用しなかったり、間違えもあったりするので公式のリファレンスや実際に動かしてみて確認はするようにするのが原則です(書籍やWebの内容が間違っていても責任はとってくれません)。

また、全く存在すら知らなければさすがに使えるようになることにはならないのでなんとなく把握する必要はあります。初心者であれば入門書に出てくるようなクラスはなんとなくおさえるところからスタートしましょう。経験を重ねるごとに把握するクラス数は増えるし、必要になりそうなクラスもわかってきます。暇なときにリファレンスをうろうろするのもオススメです。いろいろな発見があって面白いです(人によりますが)。さらに実際にサンプルなど動かしておくと記憶に残りやすくなります。経験を積み上げた人であればバージョンが上がったときにリリースノートなどを確認して変更点をしっかり把握しておきます。

「JJUG CCC 2016 Fall」へ行った その2

先日参加したのでまとめを書きます。個人的に注目だったorまとめられるものだけ書いています。そして、登壇者の皆様に感謝。

その1はこちら ttomioka.hatenablog.com

F-3 メンバーのスキルアップ、どうしてる? -Java 100本ノックで新加入メンバーを鍛えてみた- 福嶋航(株式会社ジャストシステム)

資料: http://www.slideshare.net/JSUXDesign/java-100

  • Java100本ノックを用いたトレーニング事例
    • トレーニング内容
      • 毎日Pull Requestしてもらってそれをレビュー
        • 力を付けるにはレビューが大事
        • 1行ずつ、1文字ずつに意味がある
        • ほっておいても伸びない
        • 調べてわかったつもりになるだけでなく、なんでこうなるのかを理解する
        • オンデマンドで相談に乗る
      • レビューで鍛える
        • レビューの場はスキルアップの場
        • 指摘だけでは無く、よくできたところを伝える
          • 悪いところは違和感があるから発見しやすい
          • 良いところは違和感なく過ぎてしまうから発見が難しい
  • ソフトウェア開発アンチパターン7つ
    • シャイ・メッセージ
      • ログにメッセージを書かない
        • 例外をスローするときは何がおきたかをメッセージに入れる
        • ログ出力時にどこで何の処理ができなかったかを記述する
    • リ・インベンティング・ザ・ホイール
      • ムダな独自ロジック
        • 標準SDKやよく使われているライブラリを使用する
    • リーゾンレス・トラスト
      • nullチェックしない(実は、現場でおきている例外で一番多いのがNullPointerExceptionでは)
        • nullチェックする
    • デコイ・コード
      • ソースコードのコピペ
        • コードが重複しないように工夫する
        • リファクタリング前にテストコードを書いてデグレ防止対策する必要がある
    • ナム・トゥ・イエロー
      • 警告無視
        • コンパイラが出す警告は全て解消する
    • エングリッシュ
      • 奇妙な英語
        • 便利なサイトを利用する
        • ATOK F4
    • ミミック
      • おかしいコードの増殖
      • あなたが書いたコードはコピペであってもあなたのモノですから

AB-4 Spring CloudでDDD的なマイクロサービス作ってみる 椎葉 光行

資料: http://bufferings.hatenablog.com/entry/2016/12/04/135752

  • 境界づけられたコンテキスト
    • レイヤーをしっかり作っても4-5年経つとうまくいかない
    • データモデルがだんだんと大きくなっていって手が付けられなくなる
    • 境界の中だけでAPIだけのやり取りでやろうとしたらうまくできた
  • ユビキタス言語
    • 話した言葉がそのままコードになっている
    • 違和感があれば気づけるようになる

GH-5 クラウド、クラウドというけれどJavaのシステムにとってクラウドってメリットあるの?

資料: TBD

  • 日本のJavaクラウドは普及していない
  • 二つの文化に分かれる日本のIT企業
  • SIでよく使われるのはJava
  • クラウドのメリット色々
  • システムがクラウドに対応しなければならない
  • JavaEEシステムのクラウド化が困難な理由
  • アプリケーションサーバー
  • アプリケーションのクラウド化
  • バックエンド対応

「JJUG CCC 2016 Fall」へ行った その1

先日参加したのでまとめを書きます。個人的に注目だったorまとめられるものだけ書いています。そして、登壇者の皆様に感謝。

その2はこちら ttomioka.hatenablog.com

F-1 新人研修や本では教えてくれない Java!〜フレームワークの仕組みと実 務必須ツールを学ぼう〜 多田真敏

資料: https://speakerdeck.com/masatoshitada/wan-quan-ban-xin-ren-yan-xiu-yaben-dehajiao-etekurenaijava

  • 新人研修で教えるJava、教えないJava
    • Java SE 5以降の新機能をほとんど教えない
    • カリキュラムが15年ぐらい変わってないのでは
    • そもそもJavaは量が多い
      • 1-3ヶ月の新人研修で全部は教えきれない
      • 研修以上の自己学習が必須
      • 良書は多いので自己学習は可能
  • Maven
    • Javaオープンソースのライブラリが充実しているが、管理上の問題は多い
      • どうやってそれらのライブラリを集めるか
      • 依存性の管理
      • バージョンアップへの対応
    • それを解決してくれるMaven
      • XMLに必要なライブラリを書くだけ
      • Maven CentralからXML指定されたモノをダウンロードしてくれる
      • 公式サイトにいちいち行かなくていい
      • Javaの開発におけるデファクトスタンダード
    • Mavenでおさえておくこと
      • IDEにMavenが内包されているが、コマンドから使うことも多いので個別インストールすべき
      • pom.xmlの編集
      • Mavenプロジェクトのフォルダ構造は超重要
  • Webフレームワーク・DIコンテナ・ORマッパー
    • サーブレット・JSP・JDBCには問題がある
      • MVCを混在させることができてしまう
        • サーブレットにビューが書ける
        • JSPにロジックをかける
      • サーブレットの単体テストが困難
      • JDBCは似たようなコードを毎回書くことになりやすい
    • そこで3種の神器をを使う
      • Webフレームワーク
        • Spring MVC or JSFあたりがデファクトスタンダード
        • JSPは避けたい
          • セキュリティ的にもJSPは敬遠される
  • リフレクションとアノテーション
    • リフレクションを知っている必要はある
    • アノテーションとリフレクションは合わせて使われている
  • ロギングライブラリLogback
    • ログを新人研修でほとんどやらない
    • トラブル時はログが頼り
    • Logbackが 一番メジャー
  • これからどう学習するのか
    • 本による勉強が必要
      • 新人研修は期間が限られるので全てを扱うのは無理
    • 資格を目標にするのもいい
    • ブログ、スライド、勉強会も

GH-2 SIerもはじめる わたしたちのDevOps しょぼちむ / 阿佐志保

  • しょぼちむさん
    • 資料: http://www.slideshare.net/syobochim/sier-devops-jjugccc-69780604
    • SIerでもDebOpsは必要
    • ビジネスを加速するためにリードタイムを短くするしたい
    • 事例
      • アプリケーションの使用状況を収集してレポーティング
        • Kibanaでユーザーの行動を可視化
          • これで問題が見えてくる
        • エラー率から使い方を改善する
        • 仮説に合わせてログ収集の仕組み自体も変更
    • リードタイムを短くしなければ価値を届けられない
  • 阿佐志保さん
    • 資料: https://docs.com/asashiho/8906/jjug-ccc-2016-fall
    • 変化に強よいシステムとは変化することに強いシステム
    • Docker
      • 極めて高い拡張性
    • コンテナの運用には注意が必要
      • ぶっちゃけコンテナは良く落ちる
    • Googleはdockerではdocker+kubernatesが標準化され必須になっているらしい
    • Dockerは銀の弾丸ではない
    • エンジニア自身が変化に強くなければならない
      • 攻守が重要
        • 攻めていいシステムと攻めてはいけないシステムがあるはず

「QCon Tokyo 2016」へ行った その2

  • タイトル: QCon Tokyo 2016
  • 日時: 2016年10月24日(月)9:45~19:00
  • 会場: ベルサール新宿グランド コンファレンスセンター
  • URL: http://www.qcontokyo.com/index.html

先日参加したのでまとめを書きます。個人的に注目だったorまとめられるものだけ書いています。そして、登壇者の皆様に感謝。

その1はこちら

ttomioka.hatenablog.com

B-2 DDDとマイクロサービスの現実と可能性

現場からの実践報告 上坂 貴志

資料: TBD

  • オブジェクト指向をエンタープライズに展開がDDD
  • ユーザーとシステム開発側の双方が持つ暗黙知が悪さする
    • ユーザーの言葉を一緒に定義しなくてはいけない
    • 言葉は境界が違えば定義が変わる
  • モデル駆動が重要
    • モデリング→実装イメージができてなかった
    • 貧血ドメインになった
    • ER図がダメ
  • 最大のうまくいかない理由は恐らく不安
    • 「オブジェクト指向を勉強したけど役に立たない」という感覚
    • オブジェクト指向ができる = モデリングができるではない
    • モデリング = ER図 ではない
    • サンプルを用意。過去とのマッピングが重要。
  • モデルと実装が連動すればとりあえずはOK

DDD&モデリング導入のコツ 増田 亨

資料: http://www.slideshare.net/masuda220/ss-67660572

  • 利用者の満足するものではなく、技術者が満足していた
  • 習得したときはスピードが上がる
  • 会話が重要
  • 2つのブレークポイント
    • オブジェクト指向
      • データクラス+機能クラスの世界から脱却
        • クラスを作ったからってオブジェクト指向ではない
    • インクリメンタルな設計
      • 最初に綺麗に設計したがる
      • オブジェクト指向→インクリメンタルな設計の順番
      • オブジェクト指向に自信が無いとできない
  • 体で覚えるオブジェクト指向設計
    • 名前=何のためのコード化がわかるので重要
    • Getしているということはどっかにロジックを書いているはず
    • プログラムのしたいことをメソッド名を通して表現する
    • クラスとテーブルをぶった切りに行かないとダメ
    • リファクタリングを多用するので静的型付けが必要
  • インクリメンタルな設計
    • もっと速くコードを書こう
    • 最初からいい設計が見つからない
    • 設計書だって下書きしてからアウトラインができていく。コード一緒
  • できない理由はいくらでも考えられる。

DDD実践ベストプラクティス 加藤 潤一

資料: https://t.co/oNSqA6kLPX

  • CQRSとは
    • 質問をすることで回答を変化させてはいけない
    • DBを分けなくても、CQRSはありえる
    • 形式変換を行う。ドメインはライトだけにする
    • ライドでも状態を問い合わせることはありえる
  • イベントソーシング
    • 発生したイベントを全て永続化する
    • Updateはスケールしない
    • イベントが10万件あったら、Journalとsnapshotで解決
    • 今はAkkaだけ、Springもこの方向
  • マイクロサービスとコンウェイの法則
    • 複数サービスにまたがる変更がデリバリーコストを上げてしまう
  • コンウェイの法則とDDDの関係性
    • 言葉の持つ意味は使われ方によって変わる
    • 主語が一番見捨てられる可能性が高い

A-4 サーバーレスアーキテクチャ 伊藤 直也

資料: https://speakerdeck.com/naoya/serverless-architecture

  • サーバーレスアーキテクチャとは
    • 単純にはFaaSを使ったシステム
      • 必要になったときだけ計算する
    • ハード的な意味でサーバーがない
    • 常駐プロセス的な意味でサーバーがない
  • AWS Lambda
    • イベントごとにその関数を実行できる
    • コンテナで実行、終了時に破棄される
    • CGIに近いモデル
    • 基本的にステートレス(Shared Nothing)
    • AWSLambdaはスケールするし早い
    • EC2でたちあげっぱなしをAWSLambdaでやると安くなるのでは
  • 事例から
    • イベント駆動が結合
    • Bot常駐などで使える
    • 複数のイベントを連携させる
  • アーキテクチャの性質を解剖
    • CGIはShared Nothing で安全、簡単だった。
    • ただCGIはアプリケーション全体を毎回forkがとても非効率で
      遅くなった原因を調べると、アクセスカウンタなんてことも
    • Node.jsでは並行性のが高いが可用性に難。
    • よく考えると、起動に伴うオーバーヘッドが少なければ毎回実行で構わないのでは
    • AWSLambdaは毎回実行だが、コンテナで起動にともなうオーバーヘッドが小さいのが特徴。
  • LambdaからMicroserviceが見えてくる
    • Lambda 関数はイベントへの反応として記述する
    • 完全な疎結合になる
    • リアクティブである
    • FaaSは自然とMicroserviceになる
  • オーケストレーション(リクエスト、リプライ)
    • コレオグラフィ(イベント駆動)
      • パブとサブの間に関係はない
    • スターバックスは2フェーズコミットを使わない
      • トランザクションが失敗したらどうするのか?
      • スループットが最大化できる
  • Fassは自然とコレオグラフィを指向する
    • デバッグが大変
    • オーバーヘッドは少しかかる
  • サーバーレスアーキテクチャとはイベント駆動で系を設計した、 リアクティブでコレオグラフィなマイクロサービスのこと
  • ぶっちゃっけどうなの
    • はまれば強い
      • EC2より超安い
      • 自然と良いアーキテクチャに向かう
    • 開発工数はそこまで削減できないかも
      • FaaS特有の(バッドを含む)ノウハウが必要
      • ピタゴラスイッチになるのでデバッグが大変
      • 結合テストが難しい

A-5 HTML5/フロントエンド開発 白石俊平

  • Webはいまだに重要なのか
    • Web is Dead
    • ザッカーバーグ「HTML5を過大評価したのはわれわれ最大の失敗」
    • スマフォの利用時間の8割がアプリ
    • 昔はWeb100%だったのと比べると落ちた
    • Chromeアプリは2018年終了
    • 技術トレンドとしても減少傾向
      • HTML↓
      • W3C↓
    • HTML5は問題だらけ(特にAPI)
      • 2009-11年にAPIが増えた
      • ユースケース始動だった
      • ユースケースにはまらないと使いにくい
      • HTML5のAPIが使われない
        • APIの抽象度が高い
        • 低レベルのAPIをそろえよう→Extensible Web→盛り上がらない
    • Webの利用時間は減ってきている
      • Webの重要度は、以前に比べて下がっている。「モバイル・オンリー」という選択も珍しくない。
      • モバイル中心で考えると、Webはオプショナルな存在になった。
  • WebとWeb技術の利点を再評価
    • Webの利点を再評価
      • SLICE
      • Webブラウザ上のURLを踏んだらアプリを起動できる
      • Webとアプリをシームレスにつなぐ
    • Web技術の利点を再評価
      • クロスプラットフォーム
      • JavaScriptは世界で最も人気のある言語
      • まだまだ進化がやまない
        • AMP
          • 制約を守ると早く表示
          • グーグルがキャッシュしている
        • HTTP/2
          • 1つのサイトにつき1つのTCP接続で高速化
          • クライアントの差し替えなく導入可能
        • ES.next
          • トランスペアレント
          • クラスとモジュール
            • 今までは人によっていた
          • モジュールハンドラー
          • JavascriptはWebの性質上非同期
            • promise
            • async/await
            • let/const
          • オブジェクトリテラル
          • TypeScript
        • コンポーネント指向開発の本格化
          • これまでは基盤技術が足りなかった
          • Web Components
          • template要素
          • shadow DOM
          • HTML template
        • プログレッシブウェブアプリ