「WebVR/ARのはじめかた」「WebXRの現状2018Autumn」を読みました

技術書典"4"で購入して読んだものの要旨が書けてなかったものに加え、続編のWebXRの現状2018Autumnも読んだのでメモ。

taimen.jp

WebVR/ARのはじめかた

  • はじめに
  • 第1章 VR、AR、そしてWebVR、WebARとは
  • 第2章 WebVRコンテンツの開発
  • 第3章 WebARコンテンツの開発
  • 著者紹介

はじめに

本書は技術書典2で頒布した「A-FrameではじめるWebVR【導入編】」をベースに、より網羅的にWebVR、WebARの「はじめの一歩」を解説した技術同人誌。2018年4月現在の状況を踏まえた本。

第1章 VR、AR、そしてWebVR、WebARとは

  • VRとは、その歴史、日本バーチャルリアリティ学会について。
  • VRの日本語訳として「仮想現実」が用いられることが多いが、誤り。学術的には「人工現実感」。前述の日本バーチャルリアリティ学会のウェブサイトに解説があるので、興味のある方は参照。→ 日本バーチャルリアリティ学会 » バーチャルリアリティとは
  • ARとは、「拡張現実感」。
  • WebVR/ARとは、「ウェブブラウザを通して体験できるVR/AR」。一般的なウェブ技術で作られる。
  • WebVR APIとWebXR Device APIについての解説。
  • 各プラットフォームの対応状況。
  • WebVR、WebARのメリット・デメリット
    • かんたん(体験・開発)
    • リッチなコンテンツ開発は難しい。ただし、ブラウザの進化とともに差分はなくなるかもしれない。

第2章 WebVRコンテンツの開発

  • WebGLを操作するためのライブラリ、フレームワークを使用して開発するのが一般的。
  • WebVRコンテンツを開発するための選択肢として、下記が挙げられている。
    • Three.js
    • A-Frame
    • React VR
    • そのほか(開発が止まってる)
  • WebVRを公開するプラットフォームについて、
    • PlayCanvas
    • Amazon Sumerian (AWS)
    • STYLY Suite
  • ゲームエンジンを利用したWebVRについて、UnityとUE4に触れている。

第3章 WebARコンテンツの開発

WebARもThree.js、A-Frameなどのライブラリ、フレームワークと組み合わせて作成することが多い。

ARに興味が薄いため割愛。

WebXRの現状2018Autumn

  • まえがき
  • 第1章 VR、ARとは
  • 第2章 WebVR、WebARとは
  • 第3章 ウェブブラウザ要件
  • 第4章 WebVRコンテンツの開発
  • 第5章 WebARコンテンツの開発
  • あとがき

まえがき

本書は過去頒布したWebXR本のアップデート版という位置づけ。重複する箇所もあるが、描き下ろしとなる新しい情報も含まれている。

重複しているところは割愛していきます。

第1章 VR、ARとは

  • VRの歴史について。
  • VR元年という言葉が流行したが、学術的には50年以上研究されている歴史ある分野。
  • VR元年というよりはVR Ready元年。
  • ARの歴史ついて。
  • ARの教科書が2018年7月に出版された。ARに興味をお持ちの方は手にとって見ることを強く推奨。

これかな。

ARの教科書

ARの教科書

第2章 WebVR、WebARとは

  • WebVR APIはバージョン1.1で更新が止まり、今後更新されることはない。WebXR Device APIがその機能を置き換える。
  • ミルグラム「複合現実感の連続体」
  • 現在はWebVR/ARと呼ばれているが、いずれはImmersive Web(没入型ウェブ)と呼ばれるようになるかもしれない。

第3章 ウェブブラウザ要件

各ベンダーのウェブブラウザをその使い方からかなり詳細にレビューしている。すごい。SUPERMEDIUMはあとで試す。

第4章 WebVRコンテンツの開発

React VRは React 360に名称が変わったらしい。割愛。

第5章 WebARコンテンツの開発

Appleが発表したAR Quick Lookについての節が大幅に追加されている。割愛。

感想

実態や現状をつかみにくいXRの世界において、WebVR/ARについてこれだけ網羅的かつわかりやすくまとめてくれた本はないのではないか、と思います。WebでXRはフロントエンドができればとっつきやすいジャンルだと思うので、私のような「これからVR開発試してみようかな」という方へのガイドとして、この本はおすすめできます。

「わかる!ドメイン駆動設計」を読みました

技術書典"4"で購入して読んだものの要旨が書けてなかったので書きます。

booth.pm

TOC

  • はじめに
  • プロローグ
  • 目次
    • DDDってなに?
    • ユビキタス言語ってなに?
    • ドメインモデル
    • 境界づけられたコンテキストって?
    • コンテキストマップ
    • コンテキストマップを活用する
  • エピローグ
  • 著者紹介

はじめに, プロローグ

  • 本書はドメイン駆動設計(DDD)の解説書。
  • 入門に必要な知識をわかりやすく、物語を通じて理解できる
  • 主人公もちこちゃんが出会った問題について、ソフトウェアモデルを設計していく

DDDってなに?

  • ソフトウェア開発手法で、ソフトウェアモデルを設計する手助けとなる手法。
  • どのように設計していくかという理論、考え方、概念。特定の技術的なパターン集ではないし、明日から使えるノウハウ集でもない。難しい
  • この本はDDDの概念を正しく理解し、噛み砕くことを助けるためのもの。本書だけではDDDを理解できない。エリック・エヴァンスのドメイン駆動設計や実践ドメイン駆動設計も読もう。

用語についての解説やコラムあり。省略。

ユビキタス言語ってなに?

  • ドメインエキスパートやソフトウェア開発者を含めたチーム全体で作り上げる共通言語のこと。
  • チームで共通する言語として最善の用語を見つけていくことで、同じものを指しているのに異なる呼び方をされているものが存在することを防ぐ。
  • ドメインエキスパートの話す言葉を観察し、用語やフレーズを発見していく。
  • 発見した用語について議論し、ユビキタス言語として確立する。

ドメインモデル

  • ドメインを適切に表現したもの。コードに落とし込む前の、より概念的なモデル。
  • チームメンバー全員が同じものを思い浮かべ、同じ解釈をするもの。
  • ドメインを反映したものとしてドメインモデルがあり、ドメインモデルを表現したものとしてソフトウェアモデルがあり、ソフトウェアモデルを実装したものとしてオブジェクトモデルがある。

ドメインモデル貧血症

  • ドメインモデルがただのgetter, setterの集まりになってはいけない。意図を反映する。

境界づけられたコンテキストって?

  • ドメインとはユーザーがプログラムを適用する業務の領域や業務を進めるための方法。
  • ドメインサブドメインに分割される。会計のソフトウェアが簿記の機能、印刷の機能、グラフ表示の機能を持つようなイメージ。
  • 境界づけられたコンテキストとは、ユビキタス言語が成り立つ範囲のこと。この文脈ではAはBを意味する、といったときの範囲にあたる。この境界はドメインモデルがどこに属するかを明示的に示す。
  • この境界を見つけ、ドメインモデルの所属する範囲を定める。

コンテキストマップ

  • 境界づけられたコンテキストとそれらの関係性を描いたもの。
  • 現状を正しく表現することが重要。理想的な地図を描くことが目的ではない。

コンテキストマップを活用する

  • ドメイン駆動設計では、境界づけられたコンテキスト間の関係性として8つのパターンが紹介されている。
    • これは元の本を参照したほうが良さそう。

エピローグ

次回に続く。次回、あるのか?楽しみ。

感想

元の本を読みたいと思っていたところだったので手にとってみました。エリック・エヴァンスのドメイン駆動設計や実践ドメイン駆動設計を読むための足がかりとしてよかったです。ドメイン駆動設計をなんとなくわかった気になれました。ただ、わかった気になれただけで全然わかってないので、やはり元の本を読むことは必須。

また、事例が非常にありがちで、読んでいて身につまされる思いです。

技術書典5行ってきました

ちゃんと起きられました。

今回は池袋サンシャインシティに会場が移って会場が広くなったこともあり、(サンシャインシティ内で迷子になったこと以外は)思ったよりスムーズに入場できました。ものすごい行列ではありましたが。会場内はいつもの満員電車状態でした。

会場をぐるっと一周してみた感じ、意外とハードウェア関係の本が多かった印象です。また、前回に引き続きReactとVueの本が多く、仮想化、gRPCの本が増えて来ていたように思います。AWSはもう前提と言った感じで言及されていて、GCPはあんまりなかったかな、と感じました。そしてやぱりVR,AR関連の本、というかVTuberになる本が目立ってました。VTuber、いち時代を築いたな、と感じます。

私が狙っていたのはXRとVTuber関連の本、あとはDevOps、モバイルアプリ開発、GO言語の本あたり。チェックしていた本は概ね買えました。まわっていたのは12時半から13時半だったのですが、その時点でけっこう完売している場所がありました。すごい。

手に入れた本は今日から合間の時間で少しずつ読んでいきます。電子版も昨晩のうちに全部ダウンロードして準備だけは万端、あとは読むだけ…技術書典3で買った本もまだ読み終わってないけど、とにかく読むぞ。

電子書籍ユーザーのひどく我儘な願いをここに書いておくと、電子版を用意してくれると本当に嬉しいです。同人誌は保存が難しいというのを痛感していて、また数に限りがある本だと思うと裁断するのもはばかられるので、自前で作るのもやりづらいのです。ずっと手元においておくためにも、ダウンロードさせるための準備は大変だというのは承知していますが、電子書籍としても用意してくれたらなぁ、と思うのでした。

PHPフレームワークLaravel入門を読みました

「これがいいらしいですよ」と雑に推したら仕事で使うことになったのでザーッと読みました。

PHPフレームワーク Laravel入門

PHPフレームワーク Laravel入門

TOC

  • はじめに
  • 1: Laravelを準備する
  • 2: ルーティングとコントローラ
  • 3: ビューとテンプレート
  • 4: リクエスト・レスポンスを補完する
  • 5: データベースの利用
  • 6: Eloquent ORM
  • 7: RESTfulサービス / セッション / ペジネーション / 認証 / テスト

はじめに

1: Laravelを準備する

2: ルーティングとコントローラ

世にあるフレームワークと一緒なので割愛。

3: ビューとテンプレート

Bladeというテンプレートエンジンで描画する、あとは難しいことはない。

4: リクエスト・レスポンスを補完する

  • ミドルウェアはリクエストがコントローラのアクションに届く前(または後)に配置されるプログラム
  • ミドルウェアを用いてアクションが実行される前のリクエスト・アクション実行後のレスポンスに指定の処理を実行させることができる
  • その他のリクエスト・レスポンス処理としてクッキーの利用、リダイレクトなどに触れている

5: データベースの利用

  • LaravelはMySQL, PostgreSQL, SQLite, SQL Serverに標準で対応している
  • DBクラスとEloquent(エロクアント)というクラスがある。DBクラスはシンプルなクエリビルダで、EloquantはORM
    • 業務で使うならいろいろ鑑みてDBクラスのほうかな
  • 本書ではSQLiteに接続して進める。GUIツールとしてDB Browser for SQLiteを紹介している
  • .envにDB接続情報を記載する
    • いい感じ。でもこれがOKで.NetのWeb.configを気持ち悪く感じるのはなんでだろう
  • DBクラス(クエリビルダ)の使い方は通常のプログラムなので割愛
  • マイグレーションとシーディングもできる
    • シーディングはLaravelで初めて聞いた。テーブルに初期レコード(シード)を作成する機能とのこと

6: Eloquent ORM

使わないので割愛

7: RESTfulサービス / セッション / ペジネーション / 認証 / テスト

具体的な実装手順についてなので割愛。

ページネーション以外は確実に使うので開発するときに読み返します。

所感

この手のフレームワーク入門本はどの程度端折る⇒入門要素として取り上げるかに筆者の個性が出ると思うんだけど、こちらの本はインストール、ルーティング、描画、データストアの基本機能の説明のバランスが程よく、用語の説明も簡潔かつ丁寧で、また脇道にそれないのですっと内容を飲み込めて非常にわかりやすかったです。1時間くらいで読めたのでWAF自体の入門者でもそれなりの時間でやりきれて力がつくと思う。とてもよかった。

ライフゲーム作った

f:id:Cormorant:20180617132349p:plain

ホームページのコンテンツが思いつかなかったのでライフゲーム作りました。

サイトのコンテンツがない

先月、https://u.chimata.org/ をVuePress化したのだけど、そのときは単純に今までのサイト構成を再現するにとどめていて、これといったコンテンツがなくて寂しいホームページになっていた。寂しいホームページは10年近く続いてたんだけど。

そうだ、ポートフォリオサイトにしよう

「せっかくVuePressで簡単に静的サイトを更新できるようになったんだから、ちょっとした文章とサーバーサイドの処理が不要なコードが出てくるものを作ろう」と思い、じゃあデザイナーとかフロントエンドエンジニアがやってるポートフォリオサイトにしようということに。エンジニアもすなるポートフォリオサイトというものを端くれとしてかいてみんとてするなり。

物足りないので動きがほしい

とりあえず第1段として、自己紹介と自分の連絡先になるSNSサイトへのリンク、そしてエンジニアっぽくよく使う技術をリストにしてみたらあっというまにできてしまった。Markdownを書くだけでウェブサイトになるので静的サイトジェネレータはほんといい。でもこれだけだと面白みがないし、なによりエンジニアーって感じがしないので、トップになんかワチャーっと動くものがほしくなりました。そしたらじゃあ作ったことないけどライフゲームやってみるか、となった。

ライフゲームについて

ライフゲームの仕様を大雑把に書くと、格子状のセルを用意して、それぞれのセルに生存/死亡の状態を持たせ、初期値としてどちらかを与えた上で、

  1. 生存しているセルに対して
    1. 周囲8マスのうち、生存しているセルが2つまたは3つある場合は次世代でも生き残る
    2. それ以外の場合は死亡する
  2. 死亡しているセルに対して
    1. 周囲8マスのうち、生存しているセルが3つある場合は新たに生存したセルが誕生する(セルを生存状態にする)

というルールで世代交代をひたすら繰り返していくというものです。そうすると上記のようなセルがうねうねする画像が手に入ります。

そんな感じで初めてライフゲームを作ってみたんだけど、思いの外あっさりできてしまった。ライフゲーム、見た目は複雑っぽく見えるので、昔はもっと難しいプログラムだと思ってたんだけど、やってみると大したことない。上の仕様を実装するのはそれほど難しくなくて、それをどう絵にするかが悩みどころだなと思いました。JavaScript+HTMLならCanvasがあるのでググりながらで簡単に行けると思います。

以上です

あまりにも手が動かないためどこかに晒しながらやるかと思い、年始頃VTuberを目指して準備した配信環境を使ってニコ生で作業配信して作りました。抱きまくら(嫁)のブログ見ましたとか言われて恥ずかしかった。

抱きまくら買った

カバーに嫁が書いてあるやつじゃない方の抱きまくらの話です。

眠りの質が悪い

最近夜中に途中で何度も起きてしまって、掛け布団が毛布しかないのでクソ暑いせいだなと思い掛け布団無しで寝ているんだけど、そうすると「何かに包まれてる」という幸福感が薄れてしまい、睡眠の質が下がった気がしていた。でも暑いので掛け布団は嫌だからどうしようかなと思っていました。

はやくこれになりたい

そうしたらAmazonのタイムセールで抱きまくらが売っていて、「要は何かに触れていれば幸福感が高まるのでは」と思い、ポチポチと抱きまくらの関連商品を眺めていたらこの画像に出会った。

f:id:Cormorant:20180608055926j:plain
はやくこれになりたい

抱きまくら買った報告

うれしそうですね。

一晩寝てみて

一晩寝てみた感じ、なにかに触れてると安心感があり、すごく心地よく眠れて大変よかったです。ただあんまりがっつり抱きついてると寝返りが打てないので体が痛くなるかもしれない。そのあたり注意しないといけない。

あと衝動的に買ったので置き場のことを考えてなかった。スペース確保できて抱きつく相手がいない場合はおすすめ…ウグッ(息が詰まる音)。まあつまりこれは抱きつくための動かない死体を買ったということであり、動かない死体としての抱きまくらならそれはカバーにWaifuが描かれているタイプの抱きまくらと実質同じではというところに思い至ったのでこの話はおしまい、おしまいなんです。はい解散!

Qiitaで週間ユーザーランキングに載った

滅多に話題になることないので記念になってよかったですという話です。

おもいのほか伸びてビビった

先週末、Dockerfileを書くときに気をつけていること10選という記事を書いたところ、想定の10倍くらい伸びて、一時トレンドのトップ、3日で週間ユーザーランキングの4位に載りました。はてブも160ちょっとついてて、昨日一昨日は「こんなこと初めてだわ…」ってずっと言ってた。

普段はなかなか技術記事なんて書かないので、ふと書いてみたらあたっちゃったものだから、伸び始めたあたりではいつマサカリが飛んでくるかとかなりヒヤヒヤしてました。現在の段階でまったく飛んできてない。優しいインターネットでよかったですね。

なんで伸びたのか

ありそうでなかったところに偶然ハマったというような印象。Dockerは割と人気のタグにもかかわらず、それほど投稿数が多くないというのと、Dockerfileの書き方という記事はネットに結構あるけど「こういう場面ではこう対処する」といったようなTipsの記事が多く、具体的な書法、書き方の記事が少なかったため、そこにポッと出てきた私の記事が人気になったのかなというように見えました。Dockerfileを書こうと思っているもののどう書いたものか悩んでるエンジニアが結構いたのかなと思います。実際はてブもコメント全然つかないしタグも"あとで試す"が多いので、みんな結構悩んでたんだなーと。あと、「〇〇を〇〇する10の方法」ってやっぱり好きなんですね。

内容について

とりあえず10個挙げよう、と思って書き出したらさっと8個くらい埋まったので、3時間くらいかけて10個に整理して公開しました。記事に挙げた気をつけていることは、実は初めてDockerfileを書き始めて1ヶ月くらいで調べて身につけたもので、その後1年かかって「これで間違いはなさそうかな」と思える様になってきたので記事にしました。なので全然難しいことは書いてない。だからこその当たりかもしれませんが。ベストプラクティスからあまり大きくは外れてないはずです。

Qiitaの問題点

ぶっちゃけそんな大したことを書いているつもりはなかったんだけど、それでも伸びるのは、あの手の具体的な技術知識をまとめた記事が不足している側面もあるんじゃないかなと思っています。最近のトレンドを見ていると、どうしてもポエムとか和訳とかライフハックみたいな記事が多くて、技術についての知見を整理したものがあんまり当たってない印象を受けます。悲しい。Qiitaがポエムを許したんだからまあそうなるよな。

おしまい

f:id:Cormorant:20180607021116p:plain
記念撮影
✌('ω' )✌