YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

「高熱隧道」読了

はじめに

こんにちは。Go界の日本電力です。年末に買った本を年末年始で読めなかったので、昨晩一気に読み終えました。

高熱隧道 (新潮文庫)

高熱隧道 (新潮文庫)

仙人谷ダムと黒部ダム

プロジェクトXで取り上げられてたのは、黒部ダム(通称「黒四ダム」、黒部第四発電所のためのダム)で、この高熱隧道の舞台になっている場所よりもさらに奥地に建設されています。黒部ダムの建設に関する逸話は小説をはじめ、映画、ドラマやドキュメンタリーの形で取り上げられているため、名前を知っている人も多いし、自分もプロジェクトXではじめてその壮絶な工事を知ったときには圧倒されたことを覚えています。工事での殉職者が171人にも及んだというのは、高校生の自分には衝撃的な内容でした。黒部ダムの難工事に関する物語としては「黒部の太陽」が有名でしょう。

黒部の太陽

黒部の太陽

しかし、その20年以上も前、まだ戦時中に同じ黒部川水系で、黒部ダムに負けずとも劣らない難工事が行われていたことをこの小説で初めて知りました。その内容が本当に壮絶で、真の意味でデスマーチと呼びたくなるものでした。

本当のデスマーチ

どういう意味でデスマーチだったのか、ある程度ネタバレにはなりますが書いてしまうと

  • そもそも工区にたどり着くまでの道が切り立った岩場を繰り抜いた程度のもので道幅がわずか60cm程度。資材の運搬を行うボッカが工事着工前にあっという間に5名転落死する。
  • 工区そのものが温泉湧出地帯のまっただ中を通過することが工事着工前の地質学者による調査では明らかになっていなかった。
  • 掘削する岩肌が開始30m地点ですでに摂氏65度を超え、掘り進めるにしたがってどんどん加熱、最高地点では摂氏166度に。
  • 掘削中の隧道内はサウナ状態であり人夫が切端で作業を行える時間がたった20分に。それですら、失神する人夫も数多くいた。
  • 人夫を冷やすために渓谷から汲み上げた水を人夫にかけるが、その水が隧道内にたまり人夫の膝まで、ひどい時には腹までたまるほどに。しかも岩肌に暖められて水温が摂氏45度まであがることも。
  • 岩肌がダイナマイトの発火温度を超えるほどになってしまい、設置と同時に爆発。担当していた人夫が死亡。

まだまだこれは序の口で、最終的にこの工事による殉職者が300人に迫るほどになるわけですが、それに至る過程が緻密な描写で淡々と語られていくのがこの小説の恐ろしいところです。多数の犠牲者を出しながらも工事が中止とならなかった背景には、工事の発注元の日本電力の社運をかけた工事だったことと、当時電力が国家的に求められていたこと、しかも天皇からも恩赦がでるほどであったため辞めるに辞められなかったという状況があるようでした。

吉村昭氏の綿密な調査により、工事中の隧道の様子が細かな部分まで伝わってくる、素晴らしい「記録小説」でした。小説に登場する人物や企業はフィクションではあるものの、実際にそれに対応する人物や企業がいるようです。実際に小説中の各事件での殉職者数は現実の事件と一致しています。

デスマーチ」という言葉を職業柄よく聞きますが、真の意味で「デスマーチ」の物語でした。

YAMAGUCHI::weblogの2015年を振り返る

はじめに

こんにちは、Go界の北陸新幹線です。今日でまた1歳を歳を取りました。例のやつ貼っておきます。

関連エントリ

振り返り9年目です。

ymotongpooの2015年

昨年立てた目標

まず昨年立てた2015年の目標を振り返ります。

  • Go関連情報の継続的なアウトプット
  • Android開発の技術力の向上
  • 「通知」に関する研究
  • 英語力の向上
  • 仏教について学ぶ
  • 経済について学ぶ
  • RAWデータの現像技術の向上

Go関連情報の継続的なアウトプット

今年は特にGo関連のイベントも数多く開催され、アドベントカレンダーではGoのものが3つも満員になるなど、ますますGoが普及してきたことを強く感じています。

2年前からは考えられないほどの広がりを見せていて、自分がなにかするまでもなく多くの情報が共有されています。なので去年の暮れに立てた目標は、すでにコミュニティによってなされていたなあという印象です。

Go Conferenceも去年までは自分が主催でしたが、いまはもう完全に @tenntenn に引き継ぎ、自分も一参加者として楽しませてもらっています。

今度はまた新しく、よりディープな集まりを企画したいなあと考えています。

Android開発の技術力の向上

これはこの1年でぼちぼちかけるようになった感があって、楽しくなってきたなーと思います。(外に出せないやーつが多い)

来年はAndroid Wearの開発あたりをちょっと盛り上げていきたいなあと思います。

「通知」に関する研究

これは広いテーマなので1年でぱっと何か見つかるというものでもないと思いますが、自分のなかで「コンテキスト」と「コンテンツまでの距離」というキーワードで通知に関する考察が進んだ一年でした。

そのテーマについては、対外的なイベントで話したりもして、少しずつですが整理ができてきた感じがします。

「通知」は過去2年間関わってきていますが、これからはより「通知」のデザインや体験というものが重要になってくると感じているので、2016年はより多くの方から意見を聞きながら考えを深めていきたいと思います。

英語力の向上

漠然と目標として書いていたけれども、担当するプロダクトが増えたりして、本社とのやり取りも増えたので、英語でのやり取りが増え、結果として去年よりも確実にコミュニケーションが楽になっていると感じました。ただそれはあくまで日常的な業務をこなすレベルであって、逆にだいぶ本を読んだりするのがしんどくなってるんで、来年はもうちょい英語のブログなり記事を読む機会を増やしていこうと思います。

仏教・経済について学ぶ

ここに時間が割けなかったなーというのが今年の反省点。特に経済に関しては、2016年は家計の整理や運用などをしながら、理解を深めていこうと思います。

RAWデータの現像技術の向上

今年はイタリアに旅行に行ったり台湾に旅行に行ったりと写真を撮る機会が多い1年でした。それにともなってLightroomを使う機会も増え、だいぶ使い勝手がわかってきた感じがします。

ただクロッピングはまだ苦手なんで、より素材を活かせるよう、2016年も写真撮りまくっていこうかと思います。

今年特によくやってたこと

仕事など

あまり外に書くことがないので、改めてここに書こうと思います。自分はGoogleでDeveloper Relationsという組織の中で、Developer Partnersというチームに所属していて、ざっくり言うと、大きめの企業がGoogleの技術を利用してアプリの機能向上をする支援をしたり、そういった機能の普及を行うということをしています。関わった程度の大小はありますが、今年は外に出たもので言うと、次のような事例の裏で関わっていました。

直接、表に出る機会が減っていますが、多くの優秀な開発者と関わることができて楽しい1年でした。テーマとしている「コンテンツまでの距離」と「コンテキスト」を軸として、これからも多くの企業に機能を採用してもらえるよう、お手伝いできればと思います。

ffmpeg

今年は特に動画のトランスコーディングにはまった一年でした。毎日トランスコードをしまくっているわけですが、そのなかで徐々にffmpegのオプションを変えながら、いかに良い画質で小さいファイルサイズにするか、というところを突き詰めていくのが楽しくて仕方ありません。2015年中は、以前使っていたマシンを使いまわしていたわけですが、静音化を図るために、2016年は新しいマシンを組もうかと考えています。

またVP9やH.265など新しいコーデックもそろそろ普及に関しての動きが見えてきそうなので、興味がある人を探して情報交換をする機会を作れたらなあと思います。

360度動画に関する調査

今年のGoogle I/Oでは Google JUMPProject Spotlight などの360度動画に関連する発表がありましたが、ここは今後の静止画・動画の発展の方向として確実に広がる分野なので興味を持って仕様や各社の製品などを見ていました。

特にInterBEEや各企業の展示会などで360度動画カメラなどが多く出展されていたことからも、2016年は360度動画撮影の年になるんじゃないかなと感じています。

来年に向けて

  • 動画関連技術で遊ぶ
    • 特に自宅の動画トランスコーダの新設をしていろいろとコーデックを試したい
  • アクションカムと360度カメラで遊ぶ
    • GoPro HERO4とTHETA Sを手に入れたので動画撮りまくろう
  • Androidで遊ぶ
    • 遊ぼう
  • 資産運用を真面目に考える
    • もっとよく資産をうまく運用しないと

QNAPのTurboNASが吹っ飛んでtestdiskに助けられた話

はじめに

こんにちは。この記事は pyspa Advent Calendar 2015 の22日目の記事です。Go Advent Calendarとまったく同じ日に登録したことにあとで気づいて、すごく後悔しています。そんなわけで、今日は自宅のTurboNASが吹っ飛んでtestdiskに助けられた話をします。最後提灯記事っぽいけど、1ユーザとして便利なので書きました。

TL;DR

  • TurboNASは便利だけどデータが吹っ飛ぶ危険はある
  • testdisk超助かる
  • Google Apps for unlimited storage and vaultで安心を買った

QNAPのNASは素晴らしいです

2012年2月に買ってから自宅のNASとして活躍していたQNAPのTurboNAS(TS-659+ Pro、いまは売ってないっぽい)なんですが、こいつがなかなかすぐれもので、RAID 0/1/5/6/10なんかを簡単に組めて(ソフトウェアRAID)、イーサネットポートも2口、iSCSIでも使えて、CIFS/AFP/NFSでもマウント可能、他にもメディアトランスコーダーや、DLNAサーバー等々、各種サービスもWebのGUIでちょいちょいっと簡単に設定できる。Mac使ってる人にはTimeMachineにもなってくれる便利なやつです。

f:id:ymotongpoo:20151222171138p:plain

で、写真などのメディアや必要書類をスキャンした電子ファイルの保存など、結構重要な役割を果たしていました。そんな中、今年の10月末にHDDの警告が出ていたので、新規HDDに換装しようとしたところ、久しぶりだったため手順を誤ってしまいました。

ホットスワップができるというのが製品の売りなので、とりあえず前のHDDにもどして、再構成が終わるのを待ってたんですが、なんかいやな予感がするわけです。で、再構成が終わっても、RAID5の仮想ディスク領域をマウントできない。個々のディスクは認識してるので、まさかと思って確認してみるとRAID5のパーティションテーブルがぶっ壊れてました。

すでにその時ディスクには6TB-7TBくらいのデータがあったのでかなり冷や汗モノでした。

復旧作業

最初mdadmでRAIDから外れてるディスクを追加しようとしたものの、そいつ自体のパーティションテーブルが壊れてるということで弾かれ、しょうがないのでmke2fsでスーパーブロックのアドレス見てから、e2fsckで修復試みてみたものの全然状況が変わらないんで、これ以上手をいれるのはまずいということで、RAID自体の復旧は断念しました。

しかしディスク自体はまだ生きてるようなので、上書きされてしまう前にデータのサルベージを行うことにしました。諸々探してみた中で最も信頼性が高かったのが testdisk でした。

www.cgsecurity.org

testdiskはパーティションの復旧などをTUIでサポートするというのが主な機能ですが、復旧可能パーティションに対して、拡張機能(Advanced)の中にある List メニューを選択すると、読み取れるファイルがすべて表示されます。幸い中を確認したかぎりではファイル自体は生きてそうなので、急いで3TBの外付けHDDを購入し、TurboNASに接続、testdiskで2週間かけてほぼすべてのファイルをサルベージし、事なきを得ました。

Google Apps with unlimited storage and Vault

ところで、Google Appsには「Google Apps with unlimited storage and Vault」というプランがあります。これは5名以上いれば、月々1200円で容量無制限のGoogle Driveが利用できるというものです。(もちろん他のGoogle Appsの機能も使えます)

apps.google.com

閲覧用の写真のJPEGデータはいまはGoogle Photosで管理しているので、容量を心配することないんですが、オリジナルサイズやRAWデータはやはりデータが大きく、かと言って今回のようなことがあるとせっかくの思い出が全部消えてしまうのでなかなか扱いに困ってしまいます。これまではNASですべて管理してたのですが、今回の事故を期に有志を募ってこちらのプランを契約しました。先ほどの3TBの外付けHDDが14000円弱だったので、こちらのプランのほぼ1年分の価格です。その価格で安心を買えると思ったら安いものだなと思います。

また副次的に、ウェブでもスマホでもいろいろなクライアントがあるので、どこでも中身を簡単に確認できたりするのがとても楽です。スキャンしたPDFなんかを外で楽に閲覧できるのが地味に助かっています。

おわりに

やっぱりでかいファイルが多くなるとふっとんだ時のリスクがでかいので、大人しくストレージサービス借りたほうが結果的に安いですね。

Goで良い感じに日時をパースするライブラリdatemakiの話とGo 1.6

はじめに

こんにちは、Go界の京成舎人ライナーです。このエントリは Go Advent Calendar 2015 の22日目の記事です。

今回のアドベントカレンダーに向けて、タイトルとは別のことをいろいろとやってみてたんですが、OS X 10.11 (El Capitan) でのみ発生する謎事象の原因をいろいろ調べてたらどうもGoと全然関係ないことのようで、まったくGo Advent Calendarに関係ない記事になりそうなのでやめました。

というわけで、今回はGoでの日時のパースについてです。

Goにおける日付のパース処理

いうまでもないおさらいなのですが、念の為に。Goでは日付の処理は timeパッケージ で行っています。他のプログラミング言語とは異なるフォーマットなので、初めて使うときは少々戸惑いますが、慣れてくると「2006年1月2日3時4分5秒」という決まった時刻のどの数字がどこに来るかを書くだけなので案外覚えやすいものです。

http://play.golang.org/p/wq8jrZKLjq

package main

import (
    "fmt"
    "time"
)

func main() {
    s := "2015/12/22 10:00:30"
    layout := "2006/01/02 15:04:05"
    t, err := time.Parse(layout, s)
    if err != nil {
        panic(err)
    }

    layout2 := "06年01月02日 15時04分05秒"
    fmt.Println(t.Format(layout2))
}

実行するとこのようになります。

15年12月22日 10時00分30秒

相対時間と絶対時間

timeパッケージのパース関数やフォーマット関数は上記のような数字だけの絶対時間を扱うのはとても楽なのですが、文字が入った日時などを扱おうとすると面倒です。たとえば "2015 December 21st" とかです。

また相対時間を扱うときも結構面倒だったりします。たとえば "yesterday" とか "3 days ago" とかそういうやつです。

いろいろなパターンについて @shibukawa がgistにまとめてくれています。

これを眺めるだけでも「うぁあああああ」という気持ちになるのですが、「うぁあああああ」とばかりも言ってられないので、とりあえずなんとか力技でもいいから扱えるようにしとくかー、と思ってライブラリを数カ月前に作ったのを忘れてたんですが、今日切羽詰まって思い出しました。

datemaki

なんとなく「dateが入った名前がいいなあ」と思って、伊達巻にしました。いまの季節にぴったりですね!

github.com

datemakiを使うと、日時をパースするのがどう楽になるのか、サンプルコードでご覧ください。

package main

import (
    "fmt"

    "github.com/ymotongpoo/datemaki"
)

func main() {
    exps := []string{
        "3 days ago",
        "2015 Dec 22nd 23:00:00",
        "yesterday 14:00",
    }

    for _, e := range exps {
        t, err := datemaki.Parse(e)
        if err != nil {
            fmt.Println(err)
            continue
        }
        fmt.Println(t)
    }
}

これを実行するとこのような結果になります。

# 実行時の日時は 2015/12/21 23:16:49
% go run main.go
2015-12-18 23:16:49.782843129 +0900 JST
2015-12-22 23:00:00 +0900 JST
2015-12-20 14:00:00 +0900 JST

Parse() という雑な関数に投げただけでちゃんと返してくれました!

datemakiの今後

最初の実装はかたっぱしから正規表現かけたり、序数のサフィックスを持ってるかを適当に判定したりして、漏れがかなりありそうです。テストケースも結構雑なので多分バグります。またいまは実行時間からの相対時間などしかとれないですが、ログを解析するなどの場合はログの取得時からの相対時間もとれないといけないので、ちゃんと状態管理用の構造体を持たせないといけないなあと実装しながら思いました。

Pull Requestなどは随時募集してますが、気が向いた時にしか反応しないと思います。ごめんなさい。(先に謝っていくスタイル)

Go 1.6でのtimeパッケージの変更

ところで、みなさんGo 1.6 beta1はすでにチェケラしてますかぁ~!?Go 1.6のリリースノートをチラ見すると超下の方にちっさくtimeパッケージについての変更予定が書いてあります。(まだリリースしてないので変更しないかもしれない可能性もある。たぶんそんなことないけど。)

  • Go 1.6 Release Notes DRAFT - The Go Programming Language

    The time package's Parse function has always rejected any day of month larger than 31, such as January 32. In Go 1.6, Parse now also rejects February 29 in non-leap years, February 30, February 31, April 31, June 31, September 31, and November 31.

書いてあるままを読むと「Go 1.6ではこれまでエラーにしてなかったうるう年でない2月29日等々もエラーにしますよ」って書いてあります。試しに次のコードをGo 1.5.2とGo 1.6 beta1で実行してみます。

package main

import (
    "fmt"
    "runtime"
    "time"
)

func main() {
    fmt.Println("Go version", runtime.Version())
    s1 := "2015/04/31 10:00:00"
    s2 := "2015/04/31 25:00:00"

    layout := "2006/01/02 15:04:05"

    t1, err := time.Parse(layout, s1)
    if err != nil {
        fmt.Println("[s1]", err)
    }
    fmt.Println("[s1]", s1, "->", t1)

    t2, err := time.Parse(layout, s2)
    if err != nil {
        fmt.Println("[s2]", err)
    }
    fmt.Println("[s2]", s2, "->", t2)
}
  • Go 1.5.2
% PATH=/opt/go/go1.5.2/bin:$PATH GOROOT=/opt/go/go1.5.2 go run main.go
Go version go1.5.2
[s1] 2015/04/31 10:00:00 -> 2015-05-01 10:00:00 +0000 UTC
[s2] parsing time "2015/04/31 25:00:00": hour out of range
[s2] 2015/04/31 25:00:00 -> 0001-01-01 00:00:00 +0000 UTC
  • Go 1.6 beta1
PATH=/opt/go/go1.6.b1/bin:$PATH GOROOT=/opt/go/go1.6.b1 go run main.go
Go version go1.6beta1
[s1] parsing time "2015/04/31 10:00:00": day of month out of range
[s1] 2015/04/31 10:00:00 -> 0001-01-01 00:00:00 +0000 UTC
[s2] parsing time "2015/04/31 25:00:00": hour out of range
[s2] 2015/04/31 25:00:00 -> 0001-01-01 00:00:00 +0000 UTC

そのようになってます。しかし、俺が一番ほしいのは時刻の部分の繰上げです。たとえばテレビ欄とかに出てくる「25:30」みたいなのをパースする機能なので逆方向に行っちゃってますね。

というわけでこの辺ちょっと本家にパッチ送るモチベーション湧いてきました。とりあえずdatemakiを良い感じにしつつ、ぼちぼちやってきます。みなさん、お正月に伊達巻見たらdatemaki思い出してください。

明日のラインナップは次の皆さんです!!

(訂正)2016.01.05 完全に1.6のリリースノートを逆に読み違えてました。1.6では日付のチェックがより厳しくなりました、というのが正です。

次世代Webカンファレンスに参加しました #nextwebconf

はじめに

こんにちは、Go界のエビスビールです。今日、法政大学外壕校舎で開催された次世代Webカンファレンスに聴衆として参加してきました。

以下自分のメモです。

server_perf (10:00-11:00) #405

メモ

  • パフォーマンスの勘所としてクライアント側の変化があると思う
    • @mirakui: スマホのWebとアプリの比率があがってる
    • @xcir: デスクトップからのリクエストは減って、スマホのネイティブアプリでの処理が増えている。APIアクセスが主。
    • @cubicdaiya: Webからのリクエストが1割もなくて、ほぼネイティブクライアントからのリクエスト。15000qps。
    • APIリクエストが主になったことによりJSONのやり取りだけの単純なものになったが、リクエスト数は増えた。
  • 高速化しにくい部分をどうパフォーマンスさせる?
    • @cubicdaiya: 非同期処理できるところはできるだけやっている。APIサーバになるべく負荷をかけさせない。
      • キャッシュの作成、DBのインデックス作成など。IOの処理を上げる場合には札束で殴るしかない。
    • @xcir: 自分でコード書いていないことが多いので改善しづらい。仕様を変えることで改善するしかない。
  • キャッシュ戦略
    • @xcir: キャッシュ生成コスト vs 閲覧数。どのレイヤでキャッシュを作るか。
    • @cubicdaiya: 各レイヤで共通の部分で使うデータをキャッシュする。(
  • 文化
    • @mirakui: ログインしてるとキャッシュしない。(A/Bテストの妨げになる)
  • 言語
    • @mirakui: Rubyは運用しやすい言語である、と思うことにしている。
    • @xcir: PHPにしてる。理由付けができればなんでもいいと思う。
    • @cubicdaiya: GoとかCとか。ずい分前からCPU1コアでの性能は頭打ちでマルチコアで処理しようとしているので、それに対応した言語が良い。
    • @cubicdaiya: APIはルーティングだければできればいいと思っているので、軽量な物を使っている。
    • @xcir: キャッシュできないものをどうやって処理するか
  • ミドルウェア
    • @xcir: VernishでESIやってます。ngx_small_light使ってます。
    • @cubicdaiya: nginxではモジュール書いたりとか、Luaやmrubyで簡単なアプリケーションサーバを書いてる。
    • @cubicdaiya: 私はngx_small_light使ってません。あれはApacheのmod_small_lightの移植で、Apacheはrequest per childで制限できるのでImageMagicが多少リークしてもメモリ死しない安心感がある。nginxはそれがない。
    • @cubicdaiya: nginxはマルチプロセスシングルスレッドなので、できるだけノンブロッキングにしないと死ぬ。
  • 海外展開
    • @cubicdaiya: 国土の広さが関係することが結構ある。TLSハンドシェイクを早くする、証明書の失効確認を早くする
    • @xcir: 「AWSさんよろしくお願いします」
    • @mirakui: 「us-eastに置いておけば大体どこからでも等しく遅い」
    • @mirakui: 海外はネットワークがすぐに切れる。大雨でネットが断線とか。
      • @xcir: ベトナムではカジュアルに海底ケーブルが切れる
      • @cubicdaiya: 東南アジアだとアプリのサイズが大きいと全然ダウンロードされない。
      • @mirakui: Opera Turboはすごい。勝手に画像を縮小。JSを展開。なぜか動いている。開発者はデバッグ地獄。
  • CDN
    • @xcir: 使ってます。
    • @cubicdaiya: 使ってるし昔は自社でCDNを使ってる会社にいた。画像など。
    • @mirakuri: 次世代CDNが来ると思う。CDN内で処理を完結させる。(画像変換や動的キャッシングなど)
  • 録画はあとで公開されます。

話題に出たもの

ui/ux (11:10-12:30) #407

メモ

  • このセッションの「ui/ux」という表記について
    • @kotarok: 僕は「UI/UXと言うな派」だったんだけど皆がどう思うかが気になる。
      • UIというのは表層にあるものであって、直接ユーザが直接触ることができるもの。
      • UXはユーザが感じた体験。直接設計できるものではないと考えている。
    • @manabuueno: 言葉の定義=プロトコル。相手に伝わるのであれば良いかなと。
      • 例:UX/UI, UI/UX, UI+UX, UIUX
      • デザインする対象は個人的には「UI」でいいかなと思っている。
    • @yukio_andoh: 僕は言ってもいい派。
      • ただし一緒に働くなら、それぞれをどういう意味で使っているかをちゃんと見極める必要がある。
      • 唯一気になるのは「求人の時にUI/UXデザイナー募集」という文言。別の仕事だからね。
    • @theodoorjp: 僕は転向派。「いうな派」→「いいよ派」
      • 「ユーザ体験」という言葉が表すものが難しい。
      • エモーショナルデザイン
  • 「ユーザ」とは
    • @yukio_andoh: 「使う前の人」「いつも使ってる人」「使ったけどいまは休眠してる人」全部ユーザ。
      • エモーショナル・デザインの表紙のレモン絞り器はとても美しいけど使ってみるととても使いづらい。使いづらいというのも「経験」
    • @manabuueno: 「ユーザ」っていうのがいま流行っている。(eg. 山手線ユーザ)
      • コンピュータ用語が日常的に使われるようになった。(ユーザ、フラグ、デフォルト)
      • 以前は「ヒューマン」という言葉が使われていた。アメリカでは顧客というぐらいの意味合いで使っているのだろう。
  • 現世代と旧世代の境目は?
    • @theodoorjp: iPhoneの登場によって変わったと思う
    • @yukio_andoh: 直接的なタイミングはiPhoneの登場だと思う
      • 緩やかな行こうとしてはURLが意味を持たなくなってしまった
    • @manabuueno: 若い社員は自分の会社のサイトすらググってる
    • @yukio_andoh: 10代の人間はもうブックマークすら使わない
    • @manabuueno: 自分が感じる変化のタイミングとしては「iPhoneの登場」「APIを公開し始めたころ」
      • 自分の感覚で「ブラウザ」と「ウェブ」が対応してる時点で旧世代
      • 今はウェブと言ってもクライアントはネイティブで持っている
    • @kotarok: 「ハッカーと画家」が書かれたころはネイティブアプリを更新するのが難しい前提でHTML UIを押している。
      • いまはGoogle Play StoreやAppStoreがあるおかげでそれは解消されている。
      • そういう意味で逆行している気がする
  • いまあるネイティブとHTMLの揺り戻しを踏まえて次は何が来るか
    • @theodoorjp: スマホのネイティブアプリのUIはある程度もう定跡化してしまっている。あれが最高系だとは思わない。
      • Google NowやSiriをはじめとする人工知能的なインターフェースは新しいなと感じている。
      • Facebookで個別コメントができるようになっているのはヘビーユーザーだけ。
    • @yukio_andoh: 理想形は楽器のように「だれでも簡単に音を出せるけど、使いこなすのは難しい」
      • 個々人でUIが異なると操作を伝えづらい
    • @kotarok: インターフェースの学習曲線というものを考えないといけないと思う
  • ハイパーリンクハイパーテキストという大発明
    • @kotarok: インターフェースとコンテンツの同化
    • @manabuueno: 「文字が押せる」というのはわかるが課題がある。
      • 対象の文字の長さが短いと押せる領域が減る=重要でないように見える
    • @kotarok: 現世代Webは文章を起点にしているのでリンクは動画や音声といったコンテンツに対してのポインターとして無理がないか
  • 文章に依らないウェブ性
    • @yukio_andoh: リンクを自分で辿らないといけない、というのが次世代ではなくなるのではないか。
      • YouTubeのおすすめのようにどんどん提示されてくるもの
    • @theodoorjp: 「リンク」はいま「人間が読めるもの」と「機械だけが読めるもの」が半々ぐらいになっている気がする。
      • もうちょっとルール付けが合っても良いと思う。
    • @yukio_andoh: rendorman formatやMIDIのような30年持つ規格を定義するというのは大変なこと。
  • URLの軽視
    • @kotarok: あるコンテンツの塊に対して一意なURLを振ることをもっと考えたほうがいいのでは
    • @manabuueno: 1つのURLに対して動的にコンテンツが変化するのは?
    • @manabuueno: 製作者側が良いと思うものを1つのURLに対応させればよいのではないか
  • いまのインターフェース
    • @kotarok: かつてiPhoneが出た頃にすべてHTML5で行くとJobsが宣言した。Facebook
    • @manabuueno: いまこの会場にいる人は何ができて何ができないか知ってるのでほっといていい。そうじゃない人を考えていかないといけない。
      • ネイティブのアプリみたいに「アイコンを押すことですぐにTwitterが使える」という状態をユーザが近く感じるのではないか。
      • そういう意味でブラウザがメインでなくなっているいまの状況は「半分ウェブが死んでるのでは」
    • @theodoorjp: 次世代はブラウザがメインでないのだとしても、いまの通信プロトコルは使われ続けるのだと思う。
    • @manabuueno: 我々が「次世代Web」のようなテーマで語るときは「人類愛」のようなテーマを感じる
  • コンテンツの保存
    • @yukio_andoh: 残そうと思うものはほっといても残る。そうでないものをどう残すか。
      • 本はずーっと残っていく。どうでもいい日々の発言こそ残したい。
    • @theodoorjp: 僕は逆で忘れたい。それをどう設計するか。
    • @manabuueno: たかだか5年前のウェブページが見れなかったりする。
      • 自分とコンテンツの距離が保存される限りにおいてはすべて保存すべきだと思う。
  • さいごに
    • @manabuueno: iPhoneなんだよ。Appleは神。
      • iPhoneが出る前にまったく議論されなかったマルチタッチの話が出た直後に活発になされた。
    • @theodoorjp: いまのスマートフォンのUIから脱却していくんだと思う。
    • @yukio_andoh: スマートフォンの登場によって、「使いやすい」「使いにくい」という感覚が研ぎ澄まされて、評価がなされ、みんながUXの人になっていく。
    • @manabuueno: ウェブの多様性多態性があるので、次世代も大丈夫。

話題に出たもの

webrtc (13:30-14:30) #407

メモ

  • WebRTCってぶっちゃけいまどうなの
    • @tonofo: ひとことで言うと割と辛い。過去の資産を無理やり使ってる。非常に多くの知識を必要とする。
    • @voluntas: 割と辛い。
    • @iwashi86: 本当に辛い。よくあるのは「つながらない」「SDKほしい」。RFCの山。
  • なぜつながらないか
    • @voluntas: ChromeFirefoxとEdgeで全部仕様が違う。さらに6週間でブラウザが自動更新されて死ぬ。
      • クライアント側で頑張ってやる場合はJSで頑張るしかない。
  • 辛い話
    • @tonofo: SDPとCandidateが読めないと絶対運用できない。運用環境で何が起きてるかはCandidateしかない。
      • @voluntas: ブラウザの世界にテレビ会議SIPでやってたことが降りてきただけ。
      • @tonofo: 繋がる最強のやつはLTE回線。社内ネットワークは結構厳しい。
      • @voluntas: 企業内のネットワークはUDPに関してかなり厳しい制限がある。TURNでやる場合は中央サーバが必要になってしまう。
        • NAT超えのためにTURNやSTUNをちゃんと理解していないといけない。
    • @voluntas: 利権に合わせていくしかない。
    • @iwashi86: 現状Firefox以外は独自仕様。
  • ORTC
    • @iwashi86: 期待している。
    • @voluntas: 期待してない。Skypeのために策定しているようにしか見えないので1.0の間は傍観。
    • @tonofo: どこまで仕様通りにできるようになるのかは疑問。
  • WebRTC 1.0の仕様がそろそろ決まろうとしている
    • @voluntas: WebRTCの残念なところとして1つの解像度の映像しか送れない。
      • 同時サイマルキャストが実装されないと厳しい。多人数テレビ会議
      • Chrome実装済みだが、オリジナル実装なので独特なSDPを書かないといけない。
      • SFUで辛いのは暗号化が重い。
    • @tonofo: GPUを使ったMCUなどハードウェア側で頑張らないと辛い。
    • @voluntas: 「WebRTC = RTCP何じゃないかと思ってる」
    • @tonofo:
  • テストどうするんですか、あるいはクライアントの話
    • @tonofo: 社内であればChromeのバージョンもコントロール
      • Electronはとても良い
      • クライアントのバージョンはネイティブで固定できる。ただしOSバージョンは固定できない。
    • @voluntas: Firefoxは仕様にすぐに追従するし素晴らしい。Chromeはつらい。
  • 組み込み
    • @tonofo: RasPi2超速い。H.264のハードウェアエンコーダ積んでる。
    • @voluntas: エンコーディングだけでCPUパワー持ってく。
  • 使っていく話
    • @voluntas: プラットフォーマーは辛い。運用をするのが辛い。
      • ただそれに乗っかればプラットフォーマーが各種スタックを用意してくれているのでそれが良い戦略。
    • @iwashi86: 正直付加価値としてWebRTCを使っていくというのが正攻法。
      • これまで他のことでやっていたものを置き換える、補強するという感じ。
    • @tonofo: SDK側が辛い部分を吸収するので、SDK使ってる分にはある程度楽。
    • @voluntas: 動画や音声みたいな簡単に見えるものの裏側にある困難な部分をいかにプラットフォーマーが吸収するか。
    • @tonofo: WebRTCってこれまでのウェブの形と違う形になっているので面白いと思う。
  • これからの想定ユースケース
    • @voluntas: たとえばSFC/MCU前提でやってみてだめだったらP2Pに落ちるとか
    • @tonofo: Facebookチャットも一度TURNで繋いでから様子をうかがってP2Pに落としたりしている
    • @iwashi86: SVCについても触れたい
    • @voluntas: MCUではSVCのメリットないんで、結局SFU頑張れっていうことになる。
  • あらためてWebRTC 1.0が12月までに決まる
    • @voluntas: サイマルキャストが入って仕様が落ち着けば結構期待できる
    • @iwashi86: 海外ではWebRTC系のビジネスが結構活発。資金調達も結構大型のものもある。
      • 日本でも遅れてブームが来ればいいな。

話題に出たもの

identity (14:40-16:00) #407

メモ

  • これからRP(Relying Party)は何を使ったらいいのか
    • @_nat: OpenID Connectに対応していればOpenID Connectのライブラリだけでいけるようになるはず
    • @nov: TwitterはずっとOAuth1.0で、更新の兆しなし。
  • リスク情報共有
    • @_nat: あるアカウントがある1つのサービスでアカウントテイクオーバーされた場合に他のサービスに即座に知らせて2次被害を防ぐ
      • 他のサービスにあるアカウントが所属している
  • OAuth PKCE
    • @_nat: 後方互換だし、IdPもRPも全部コレ使ってたらいいんじゃないの
    • @nov: 最終的に悪意の第三者にアクセストークンが渡らないように作った仕組みがPKCE
    • @_nat: ランダム文字列をチャレンジ時、それのハッシュをベリファイ時に送ることで、
  • Proof of posession token
    • @_nat: interpolやFBIの溜飲を下げるためには一段セキュリティの高い認証方法が必要
      • Bearar tokenは持ってったらすぐに使えるトークン(例: JRの切符)
      • Proof of posession tokenは使用時に所有者の確認を行うトークン(例: 飛行機のチケット)
  • @_nat: 「パスワードは公害」「パスワード税をかけたほうがいい」「総量規制をかけたほうがいい」
    • なぜパスワードでやるかといえば「安く導入できるから」
    • 税金と両壁をなすのは「保険」がある。情報漏えいした場合にどれくらい補填できるか。
    • パスワードが悪いんじゃなくて、実際にはヘボいパスワードシステムが悪い。
      • Googleはパスワードシステムに見えて他の要素も含めて判断している。300人チームでやっている。それだけのコストを掛けてやりたいのか。
  • ログインやログアウトってなんで必要なんだっけ
    • @nov: authenticatedされた状態が必要なだけだよね
    • @_nat: ローカルデバイス、特に個人デバイスであれば一度認証したらずっと使えていればいいはずだしそうあるべき
    • @mad_p: キオスク端末の場合は個人端末の認証情報を渡せる仕組みがあればいいだけのはず
  • 認証と識別
  • ユースケース毎のリスク評価

話題に出たもの

monitoring (16:10-17:30) #407

メモ

  • 監視とは何か
    • @mikeda: 稼働率を上げるもの。
    • @fujiwara: 落ちないようにするため。それは現在も将来も含めて。(キャパシティプランニングなど)
    • @songmu: 稼働率を最適にするだけでなく、キャパシティを最適にする
      • テストやコンフィグもコードになっていったのと同じように、監視もコードになっていくんだと思う。
    • @rrreeeyyy: サービス提供者側が提供されるべきレベルを保つためのもの
  • チェック監視とメトリック監視
    • @songmu: 最近の傾向としてメトリック監視が増えている
    • @mikeda: 昔に比べると細かい値を取り始めた
    • @fujiwara: チェック監視とメトリック監視は各々役割が違う気がする
    • @mikeda: メトリック監視で割といけることが増えてきたかなという印象
  • 監視の間隔
    • @fujiwara: 数日間は1秒単位のデータを取得したい。
      • 1分間隔だとたまに起きる短い間隔でのスパイクを拾えない。
  • 監視難しい問題
    • @rrreeeyyy: 言語によってどこを監視していいかわからない事が多い。
    • @mikeda: 監視テンプレートをもっと公開してほしい
    • @songmu: Chefが良かったのは個々人が秘伝のシェルスクリプトでやってたことが公開されてシェアされた
      • 管理もそういうふうになればいいな
  • アプリケーションエンジニアとインフラエンジニアの棲み分け
    • @rrreeeyyy: お客様によってはアラートごとに連絡ほしいという人もいれば、対応策まで考えてから連絡してほしいという人もいる
    • @fujiwara: アプリケーションエンジニアにもアラートを感じてもわらないとサービスはよくできないと思う
      • ただ一応段階をわけてアラートを出している
  • どういうチームを作ればよいのか
    • @mikeda: 少人数で24時間の監視体制を回すのは現実的ではないのに、それをやってるのがこの業界。
    • @fujiwara: 特殊なチームメンバーの状況に依存すべきではない。どうしても対応できないならMSPなどに任せましょう。
  • 監視周辺技術
    • @songmu: MackerelではGraphiteを使っている
    • @mikeda: オープンソースを使ってる人が多いのでZabbix使ってます
    • @rrreeeyyy: これからは監視とクラスタマネージメントはセットとなるのでConsulには注目してる。
    • @fujiwara: 時系列データベースどれつかったらいいですか
    • @songmu: Graphiteかと。datadog結構すごいと思う。
  • fluentdが与えた衝撃
    • @mikeda: アレのおかげで各社でログをどんどんあつめてグラフ化するという流れができた気がする
    • @fujiwara: どんどんログの処理がストリーム処理に近づいている
  • SaaS使ってる?
    • @mikeda: 一部datadog使ってるけど大した規模ではないです。(金銭的な理由)
    • @rrreeeyyy: MSPという事業の性質上、当然自前でやっているが、
    • @fujiwara: いまいまはZabbixで全部やってるけどいずれ外出ししたい。監視の監視までしたくない。
    • @mikeda: 他社の監視の事例を見てると、zabbixやnew relicが多いが、いまはdatadogやmackerelなどがだいぶ増えている。
  • 原因特定・未来予測
    • @mikeda: 未来予測系はまだやってない
    • @rrreeeyyy: あんまりやってない。ただやりたいと思う。
    • @fujiwara: アラート上げるときに0 or 1ではなくて「何か違うよ」を入れたい。
    • @mikeda: 未来予測や任意の異常値の検出などは難しいかもしれないけど、検知の自動化はしたい。
  • RDSのようなサービスを使うことによって監視は楽になったか
    • @rrreeeyyy: 管理は楽になったが、監視がどれくらい楽になったかはわからない
    • @fujiwara: クラウドベンダー内でブラックボックスにされたものは何も見れないのが良し悪し
    • @songmu: 自動修復をしてくれるおかげで監視をする部分が減ってるというのはある
  • 繋ぎっぱなしのサービスが増えてきた
    • @songmu: WebSocketやHTTP/2などが出てくればますます接続に関しての監視は難しい
    • @rrreeeyyy: 実際難しくなっていているが、どうするかは考えていかないといけない
    • @fujiwara: そういう場合はアプリケーション側がログを出してあげないといけない
    • @songmu: アプリケーション側だけでなくミドルウェアも考慮してあげないといけない
  • これからの監視
    • @mikeda: 目の前の監視を続けていきます
    • @rrreeeyyy: 次世代には監視業務はなくなればいいなと思うが当分なくならないので良くしていきましょう
    • @fujiwara: 要するに夜寝たいので、監視システムを育てていきましょう
    • @songmu: インフラエンジニアがなくなると言われた時期もあったが、なくなるどころか複雑化している。

話題に出たもの

感想

とにかくまず運営および登壇者の皆様お疲れ様でした。参加率はいかほどだったかわかりませんが、あれだけの人数を登壇者だけでつつがなくさばいたというのは本当にすごいです。事前打ち合わせなど何回ぐらいあったんでしょうか。いずれにせよ、カンファレンスの運営が次世代な感じでした。

内容に関して言うと、自分が想像していた「次世代」よりはずっと手前側の話になっていたような気がしますが、それもあれだけの参加者がいて聴衆に気を遣ってもらうとどうしてもそうなってしまうのかなとも思います。現に自分がIdentityのセッションに参加した時はRFCやISOのドキュメント番号がどんどん出てきて、話を聞きながらそれを追うのに必死という状況で、現状把握ですら大変なのに、それ以降の話となったら追いつけなかったと思います。

今後開催されるかはわかりませんが、久々に自分のフィールドにない話題をその道のプロから聞ける良い機会でした。一参加者としてとても楽しかったです。ありがとうございました。