ここ最近技術系のイベントいっても記事に起こさない事が多いので何の為にメモとってんだろうな となりつつあったし、

今まとまった時間とりやすいので、久し振りに書いておきます。

こないだ『サーバーサイドエンジニアオールスターズ in 関西』にも行ったので、何か書けばよかったな。

ディスプレイの位置的に割と見づらくなってしまったので失敗した。

左右の画面つかないのかなぁ。

畳スペースにいたヒヨコ けっこう固くてしっかりしていた

スライドは多分そのうち上がるので、感想的なものが中心。

音声認識におけるサーバーサイド開発　市村さん

クローバのサーバーサイドで行っている音声処理とその下地になる音声解析のモデル作成(機械学習)の話し。

○音声認識

まず最初に引数として 音声と単語列を突っ込んでる式が示されてて、最初の段階で単語列なんて定まってるもんなの？ っと思ったんだけど、

「単語列」って言葉から想像するような規模感のものではなくて、想定される単語全部の莫大なリストっぽい。

入力された音声は、音響モデルを使って 個々人の個性を削ぎ落した特徴量のデータに変換され、そこからアルファベット1音ずつの音素に分解され、

前後の音と組合せた tri-phone というデータにして言語モデルに渡す。

最終的にその言語モデルが、「日本語らしいもの」を導き出すのだが、これを機械学習で学ばせていくのが音声認識揮発の主体になるようだ。

音響モデルのほうは、マイクとか背景音がかわらなければアップデートされないし年に2度程度。1回の生成には1週間以上かかる。

一方、言語モデルは新語なんかも取り込むので毎週アップデートされていく。

言語モデルの中身は数千万オーダーの単語列。

1工程に1日とかかるし、分散処理がしずらいのでhadoopを使えない部分もある。

評価用のテストデータもめちゃくちゃ多くて、並列化しててもそこだけで1～2日かかる。

結果として1週間に1度更新するスケジュールはかなりカツカツらしい。

○デコーダー

機械学習は莫大な時間をかけて莫大なデータを処理するが、実際にスマートスピーカーに音声が投げられた時に処理するのがデコーダー。

こちらはユーザーにすぐ反応を返さないといけない為、最長数百msecオーダーの音声認識を低レイテンシで返す。

性能と速度はトレードオフな部分があるので、速度を優先して精度を下げる事もあるみたい。

・性能改善

モデル再学習で副作用が大きい物は別処理する。

→ドメイン（専門用語）モデルなんかは別でやったものをマージする。

(特にスマートスピーカーは音楽関連の機能豊富だから、アーティスト名なんかの芸能関係の名詞はゴリゴリにやってそうよね

間違えやすい単語や発話に対する処理（デコーダー側でスコアをみて切り分ける

ノーマライゼーション(乃木坂フォーティーエイト→乃木坂48のような表示のノーマライズ

誤認識をどこの問題か切り分けてフィードバックする などなど

○質疑応答

Q. 吃音症とかもひろえるの？

A. 特徴的な人や子供の表現が難しい

モデル化されてる元データが平均的な男性のボイスを元にしているので、そこから大幅にズレるものは精度が落ちる。

（これ元のセット複数持って、初動であてるモデル切り替えたりみたいなのできたらいいんだろうけど、現状でもリソースやばいの考えると何個もモデル持つのはきつそうだなぁ

っと思ってたらその質問出てきた

まず初動で子供どうか とか知るのが結構大変っぽい（ステップ増やすとレイテンシに影響でるだろうしな

特徴量にする前に捨ててる情報をつかえばできるかもしれないとの事。

(声紋みたいな認識あるけど、あれって速度どうなんやろな。

(個人的にはスマートスピーカーって不特定多数の人が使うシーンよりも、同じ端末からは特定のグループの人しか話しかけない気がするので、そこでパーソナリティ絞るみたいなのはできるんじゃないか？(抜本的な話しではある)

(実際 google アシスタントとか、本人以外の声からの命令は無視する機能とかあった気がするし、ドアの開錠とかセンシティブな機能を提供する時には必要よねぇ

「サーバーサイド」って銘でいきなりアカデミックなサイドの話しになったなぁと感じたが、

確かにクライアントでやらない事は全てサーバーサイドなんだよな......という意味ではくくりが難しいのかもしれない。

infra@line　クリス・ピッケルさん

途中は英語でやるっぽいので、みよたさんが翻訳しながら。

基本的にはクリスさんが何故サーバーサイドが好きなのかと、LINE のサーバーインフラが何で構成されているか のお話し。

別のイベントでお聞きしたことがあったので、メモは取らず。

docker はいいぞ！みたいな感じ

Kubernetes の話しもっと聞いてみたくはあるけど、技術的に興味あっても個人的に触る事はなかろうな と思うので難しい。

liffのバックエンド　アダムさん

クリエーターズマーケットとかやられてたらしいのでお世話になっている。

箱ペンギン - LINE スタンプ | LINE STORE (宣伝)

今はLIFF(LINE Front-end Framework)のバックグラウンドをやれらてるそうです。

フロントエンドフレームのバックグラウンドという表現の複雑さ。

まったく知らないでもないので、あまりメモらなかったけど LIFF は LINE 上で動く web アプリのプラットフォームで、

LINE の画面にオーバーレイして動く小さなブラウザみたいな感じで、HTLM と JS と CSS で動く。

普段クライアントは talk サーバーの通信してるけど、その間で LIFF のサーバーが動く感じ(？)で、LIFF サーバーがトークン取得したりメッセージ投げたりの API を叩くっぽい。

(これLIFFサーバーにアクセスしてるけど、開発がアップしてんのは静的なファイルだから js が動くのはクライアントよな、悪意があるスクリプトとか動かないのかな

(そもそも動いてるjsのバージョンがどんなもんで、どんくらいサンドボックスかされてんだろうか

→懇親会で聞いてみたけど、普通に WebView で動いてるっぽいので、JS のバージョンは端末に依存するし、破壊的な事されても View だけの事っぽいかな。

LIFFに許可可能な権限はユーザー情報の取得とメッセージの送信の２つだけ

(友達とかは追加できないんだな（悪用されたら怖いが「最大ｎ名の友達を追加する許可」みたいなのできればおもしろそう。 その人数追加しきった所で権限失効する感じで

・Kotlin

ここから kotlin の話し

スライドあったけど null 安全最高！みたいな話し以外はほぼ全部はしょられた

kotlinのコードについていろいろしゃべりたかったが　全部はしょられたけど、軽く Coroutine にもふれた

ロギングの話しにちょっと触れたあと LIFF の v2 の話し。

まずブラウザで動かす事ができるようになったので、開発が凄い楽になる模様。

権限的に許可している人のリストから個人やグループにメッセージ投げれるデモ映像が出ててすごかった。

また、今までモバイルクライアントでしか動いてなかったけど、これだと PC 版でも使えそうとの事。

11月くらいに公開予定

全体の感想

サーバーサイド広いな......

あと、懇親感で色んな人と話した感じ、サーバーサイド専門って人ばっかりじゃなくて けっこう広範囲の人が来てるっぽかった

まぁそもそもインフラやってる人もアプリケーションやってる人もサーバーサイドなわけだし広いわなぁ

今後は9月にオフィスが移動するとして、8月はインターンとかあって お忙しいそうなので、次に何かやるとしても 旧オフィスさよなら会じゃなくて、新オフィス お披露目会になるかも？との事。

ちょうどインターンで8月から来られる という方ともお話したけど、オフィスの移動のタイミングでジョインするの大変そうだなぁ。

イベント行ってきたので、久し振りに更新。

今日梅田でやってた FRONTEND CONFERENCE 2016 に行ってきました。

最近はインフラ8割バックエンド2割みたいになってフロントエンド触る事もほぼ無いのだけど、

もはや js だけやれる事が増えてて、フロントエンドの敷居も広くて楽しそうよね。

興味はあるけど、ガッツリなんか勉強しようと家に帰ると ff14 を起動しちゃう というような毎日には、こーゆー腰すえて参加できるイベントがあると助かる。

友人が関わってるプロダクトだったので、ちょっとビックリした(というか中継先の別室で一人ふきだしそうになった) 

自分もシャツつくってみたけど、T シャツのクラウドファンディングみたいなサイトなので、元々の知名度の無い個人プロダクトだと

身内イベントに絡めるか、広範囲に売る前提でプロモーションしていかないとな感じはするけど、スタートが気軽にできて楽しい。

ここからは いつものスタイルで、セッションを聞きながらとったメモをベースに感想を。(詳細な内容は資料読めばいいと思う。

会場のアンケートに3セッション分の感想欄があって調度いい感じだったので、興味を持った3セッションほど。

大型フロントエンド開発における TypeScript と DDD

(奥野 賢太郎さん - 資料 )

チャットワークの方なのでチャットワークの紹介から

導入企業92k...200地域... すさまじい...

前半はノンフレームワークな現行の WEB 版チャットワークを変えていく話し。

レガシーなコードを書き換える上で、フロントエンドチーム全員がES2015を習得済み という環境は羨ましくある。

AngularJS をプロトタイピングで採用していたので、そちらの導入もスムーズ。

どんどんチームで作業をする時の問題点の解決の話題に。

コメントは指針をもつ/意図を残す

→　そう書かざるを得なかった理由を明確にする

コーディングスタイルの統一は自動化(tslint)

・デザイナー連携

JS側にはスタイルを書かない

デザイナーがテンプレートをさわることがない

→ロジカルな設計にする必要があるので エンジニアがテンプレートを書く

(うちだとここまで切り分けできるテンプレートをエンジニア側が書けんな...

メンテしやすいよう BEM のライブラリを採用

axross/bemmer: BEM-like simple classname builder.

・デザイン仕様書の取り扱い

GitHub Wiki 全文検索できない　更新に気づけない

Markdown にして　プルリク必須

（デザイナが git 使いこなしてる環境うらやましい

・単体テスト

盲目的なカバレッジ100％はめざさない

→変更の度に修正が必要なテストは　メソッドのロジックが切り分けられていない

テスト内の負債を無視しない

・タスクランナー

gulp　属人化に気を付ける / 記述者を分散する

差分が見やすいように ファイルを分割、ワンライナーにせず改行をいれていく

・環境の構築

保守、ダミー、更新...だれが？

Ciが回る度に容量が許すかぎりデプロイして実行できる状態でのこしていく

非エンジニアも確認しやすい、バグも追いやすい

（おぉ...これやりたかったやつだ...

ストレスなくビルドできるように改善していく

・TypeScript と DDD(ドメイン駆動設計) が必要に

TypeScriptの型はチーム内で設計を共有するのに役立つ

大規模なシステムは覚えないといけない事が増えていく

→共通言語の定義

・型の恩恵

→一ヶ月後の自分は他人（あるある

コンパイラはドキュメントと違い嘘をつかない

＠param に型をかかない　　短いコメントをつけるくらいなら型で

型名厳格にすると IDE が活きる

テストで型を意識せずといいので　ロジックの振る舞いに集中できる

・ドメイン駆動設計

完璧な実践は難しい（重い

→活かすために触れる

ユビキタス言語の定義

人によるブレを無くす

・フレームワーク

どれがオワコンか？ という考えを捨てる

フレームワークの隆盛に影響されないアーキテクチャ

フレームワークを捨てられる状態を保つ

ロジックをapplicationドメインに

二槽式アーキテクチャ

フロントエンド内をフロントとバックエンドにわける

（ビューによったもの　　コアやアプリケーションによったもの

チーム全体がうまく回る　仕組み作り

管理がおいつかなくなる　→　機械に頼ろう

-----------

うちはそこまで大型な開発ではないけど

チームで作業する上で導入したい事がやま程ある

チーム規模小さくても、その辺のフットワークが重いのは自分の力不足だなぁ...

HTML5 の API 群を ただひたすらに触ってみた記録

(花谷 拓磨さん / http://webrunner.jp/ に後日関連する記事が上がるそうです )

タイトル通り HTML5 に存在する様々な API を使ってみた話し。

(色々触った中でも絞っての紹介)

冒頭は webstorage,indexedDB,webSQL あたりで、自分でも触った事がある範囲のお話。

webSQL は廃止されるので、それ以外の話しだが、まぁ個人開発の規模感だと webstorage が使いやすくていいよね。

・WebRTC

ブラウザ同士でリアルタイム通信をする為のAPI

(サーバークライアト間ではなくクライアントクライアント通信

IE/Safariは使えないが Edge は対応している

クライアント間通信の前にサーバーに相手を問合せないといけない為，シグナリングサーバーが必要になる

(ロビーサーバー的なやつね

実装範囲が低レイヤーなため スキルが求められる

シグナリングサーバーを作るのがそもそも大変

WebRTC をラッピングしたSkyWayでだいたいやってくれる(PC間だけじゃなく、スマホまでやってくれるらしい

その他類似事例(ちょうど3/3に GIGAZIN Eに記事が出た． ファイルの相互送信とか，ビデオ通話ができるサービスとか

自身でつくったもの(音声通話とかの実験用

PeerJS のラッピングを利用、PC/Android では動作できた(iOSはダメ

PeerJS 用の無料のクラウドサーバーが使える

peerJs に頼る形で 100行程度のコードで実現している

(接続の確立のネゴシエーション部分がよくわからなかった

ある程度ラッピングされてるので ハードルは下げれる

iOSが対応してないので，ファイル共有とかPC/PCをメインターゲットにできるところだと利用できるかも

・notifications

push api とは別物で，ブラウザからの通知を一元化して扱えるというもの

(tiarraMetroにいれてみるか

・実験的なAPIについて

Chrome/Firefox でしかうごかないものがおおい

iOS が使えないのがおおい ので iOS で使えるかどうかにひっぱられる

SSL 以外禁止になってどんどん使えなくなっていくので https で動かしましょう

localhost で動いても、本番環境に持っていくと通信制限の問題で動かなくなる事があるので気をつけて

日本は iPhone のシェアが高いので厳しい

まだパフォーマンス論争以前に機能が足りてないものがおおい

よいところとしては Web 技術ですべてかける

-----------

昔、Firefox に実装された加速度の API とか geocoding の API とかは、何かの勉強会で見て弄ってみた記憶があるが

HTML5 になってほんとに出来る事が多彩になっていて、それを WEB の技術で制御できるのが面白い。

個人的にはスライドの最初にリスト表示されていた D&D API とかも気になったし、

個人的に自作して使っているプロダクト(tiarraMetro)とかで気軽に導入できそうなものもあったので為になった。

push はちょっとハードル高そう。

Webサイトパフォーマンス管理の基礎知識

(竹洞 陽一郎さん 資料 126ページ！)

前半は統計学がいかに大事で、日本が統計学教育でどれだけ遅れてるかという話し。

今は高校の数I に入ってるみたいだし、最低限教育課程でやられてる範囲くらいは自習しとかないと 共通言語が扱えない みたいになって追いていかれるのかもしれないな。

・配信品質の話し「速さはなぜ大事か？」

我々が思う以上に一般の人は、サイトロードの遅さに対してシビア

最初に行って遅いサイトにはもうアクセスしない、っという人が半数近く居る。

「サイトパフォーマンスの大事さは分かるけど、他の優先事項が出来てない...」

というのは間違いで、サイトパフォーマンスを上げておかないと 優先で実装されたものを見てもらえない。

チャンスは一度きり。

こっから人の感覚の不確かさの話しとか。

・手法のはなし

ハイパフォーマンスwebサイト、9年たった今も通用するのか？

→通用しないよ

そもそも事象の背後にある原因が違うと解決策は変わる、ベストプラクティスとか辞めませんか？

(個人的にはハイパフォーマンス WEB に載ってる内容は使っているのだが

(結局そのまま当て嵌める何て出来ないし、要は参考にする指針程度のものだと思って使っていたので、柔軟性の問題よな...と思う

ベストプラクティスはそこら中にころがってるが，それは「健康法」みたいなもん

問題は特定の事象から発生しているもので，それは「健康法」で解決できるわけじゃない

ちゃんと医師の診察を受けろ。

・PPDACサイクル

(ニュージーランドでは小学校でやるらしい、何か基本情報かソフ開でやった気がする。

診察(実行可能データの計測)→手術

「健康法」をどうこうするのではなく，エンジニアは「医師」であるべき．

ベストプラクティスやめましょう

(まぁ参考にするくらい でいいよな っと思うし，エラー対応はまずログを見ろ！！！！みたいなのと同じかな

・計測の仕方

サーバーサイド / 合成 / リアルユーザー

リアルユーザ→エラー率が分からない(欠損値)

ランダムの欠損なのか，パターンの欠損なのか

また何の環境に依存しているかも分からないから統計的には扱えない。

・品質管理の原則

コントロール可能な範疇に中力

→なので合成計測でやっていこう

実験計画法 三原則

• 局所管理化 (オッカムの剃刀やな
• 反復 サンプル数を増やして 誤差をのぞく (1～2回じゃだめ！
• ランダム化 パターンに陥った計測は統計的に意味がない

表示速度，どれくらい確かか？

→サンプルをふやしていかないと 正しい情報がえられない

ラプラスの魔 → 全てを知る事はできないので，確率的に近づくしかない

母集団と標本 → 神しか知らない真の平均値(μ) 標本から得られる人間が知れる値x_

3回とか5回で何が分かるのか？ 統計学的に最低20～回はやろう

平均はバラつく、偏差をとる

6σ(製造業は100万個に1個のレベルで管理している

平均が全部4秒のグラフ

(品質がいいのは まとまってるやつ という話しだが、まとまってても4秒だと品質とは という気持ちになるな

=======この辺で時間切れで駆け足

パフォーマンス改善の手順

主要動線でのページ遷移計測

(これは合成計測の短所になってた部分でもありそうだが

分散の加法性

例外が発生しているものは、エラー値かパターン値か？ これはサンプルの期間を増やすしかない

chrome の開発ツールではそんなに取れない ツールの限界は知るべき

PageSpeed Insights では今上げてきたような問題が計測できない

google は自社の計測ツールではなく catchpoint のを使ってる

サンプルに出してるような接続ホスト数(40とか)だと、http2 にした方が ssl を接続数が大量になって重い

(最近 DeNA の H2O でリンザンプション使えばその限りじゃないよ みたいな記事を読んだのでタイムリー

-----------

ちょうど今仕事でやってるような範囲に近かった(こちらの程度はかなり低いのだけど)ので、勉強になった。

仕事にすぐ活かせるかは分からないけど、計測に関しては まだ手を付けはじめた感じで序の口なので、

今回学んだ事を活かしていきたい所。

あとがき

最近はあまり個人開発のモチベーションが無かった(...というか家にいると無限に FF14 やってるというのがあるが、

とりあえず出来る所から何かやろうかな っと思って、手元の環境で初めやすいのもフロントエンドのいい所だと思う。(成果を見やすい

長らく触ってないものの、自分自身で利用は続けてる tiarraMetro に notification API を取り込む、なんて小さな所からでいいので ちょっと触ってみたくなりました。

あとイベントのランチマップがいい感じだったので、「お昼ここに行くぞ！」っと決めて 友人と約束してて梅田に戻っちゃったのはちょっと勿体無かった。

そして40分開始だと思って悠長に買い物して戻ったら、午後が20分からで聞きたかった。 

・JS フレームワークと年月- ExtJS, AngularJS, React -

を聞き逃したので、他の方のレポート blog なんかが上がるのを楽しみにしておくかな...っといった所。

LINE Developer Meetup #8 in Kyoto - connpass

仕事で触ってる範囲はフルスタックな感じなんだけど、規模がとても小さいので自分みたいなのが行っていいのかなーっと思ってたけど、興味深い話しばっかりで凄く面白かったので行って良かった。

会場は京都駅から南に下った所の京都テルサの会議室。

テルサはスポーツ施設しか利用した事がなかったので、ちょっと新鮮な感覚だった。

こっからは会場で取っていたメモベースにまとめたもの。

すぐ纏めないとすぐ忘れるのでとりあえず書いとかないと。

起きたら読み直して変な所はなおします...Zzz...

あと今回はノート持ってくの諦めて、z ultra と BTキーボードでメモ取ってみた。

WKWebViewはデキる子か @tarunon

LINE のインターン生で未踏プログラマーな @tarunon さんによる、iOS8 で追加された WKWebView は従来の UIWebView と比べてどうなのか...というお話。

といった感じで、最初はまず UIWebView でサードパーティーブラウザを実装するのがどれくらい大変なのか...というお話から。

WEBビューをアプリに組込むって時に使われるコンポーネントとしては最低限の機能は持ってるんだろうけど、ブラウザを実装するにはあまりにも機能が足りない...

そこで3つの拡張手法でブラウザの必要な機能を実装していく。

「JS による拡張」「ネットワークによる拡張(NSURLProtocolによる)」「プライベート API (!)で頑張る」

特に NSURLProtocol でコンポーネント側でサポートされているスキームのリクエストまでフックして色々弄れるって話しは面白かった。

(しかしこれを時前でやるのはキツいな...

この辺一通り、どーいった機能が足りなくてどう制限を回避していくのか、というのが各機能の表で見やすく整理されて解説されていて面白かった。

んで、WKWebView はデキる子か？という話しで、上記の UIWebView がサポートしていなかった機能の大半をサポートしている！

素晴しい！

でも NSURLProtocol が上手く動かないので使えない！残念！

WKWebView のが便利なシーンはかなりあるけど、サードパーティブラウザを開発するには適材適所で今後も UIWebView と付き合っていきましょう...というちょっと寂しい感じの締めだった。

質問し損ねたけど、「NSURLProtocol が上手く動かない」部分がブロックされた機能なのではなく不具合であるなら将来的には WKWebView に移行してく事もありうるのかな。

「この先」の話しもちょっと聞きたかった。

LINEバックエンドとマイクロサービスアーキテクチャ @小野さん

最初は LINE の運用規模のおさらい。

ググれば出てきそうな情報ではあったのでメモってないけど、ユーザーは日本に偏ってるのかと思えば案外台湾やタイが多い。

popもかなり世界中に散ってて、サポセンの拠点も今では世界4箇所に。

・マイクロサービスアーキテクチャ

サービスを広げると、システムはどんどん巨大化していく。

低コスト・スピード重視で開発を続けていくと、いずれ巨大なモノリスが出来あがる。

結果コストは増大し、スピード感が落ちる。

全てを把握しないと何もできなくなり、新しい事に挑戦できないエンジニアのモチベーションは低下していき山手線を彷徨う。

・LINE は？

複数の独立したコードベースでチーム単位に動ける。

→コミュニケーションコストが低い。 新しい技術もサービス単位でガンガンいれれる。

→もちろんチームによって差があり、コアな所はとてもコンサバ。

データ管理なんかもチーム毎に違う手法をとるので、採用DBもバラバラだったり。

(HBase,Redis,MySQL,MongoDB,InfluxDB...

→ビルド、デプロイ、モニタリング、ログ収集なんかの基盤部分は専門のチームがやっている。

・API

サービスごとに API セットができる。

→インターナルな API で json on http とか必要なのだろうか？

自由度が高すぎるとサービス毎にスタイルがバラバラになる。

それを統一する為にはドキュメント等で縛らねばならないし、それすら従わなかったりする。

その為採用したのが serialization/RPC フレームワーク 『Apache Thrift』

まず、Thrift IDL で定義ファイルを書いて、各言語ごとに必要なコードをそこからジェネレートする為、API の定義ファイルがドキュメント代わりになる。

→ WIKI を管理する必要がなく、また多国籍なエンジニアが開発に参加し多言語化している環境でも翻訳を意識する必要がない。

line ではこの定義ファイルを git で管理し、API の更新時はブランチを切って更新していき、利用するサービス側はそれを見て実装を進める。

主要の言語はサポートされている為、開発言語から違うチーム間でもやりとりが可能でプラガブル。

何より話し聞いててでかいなと思ったのがエラーハンドリング。

json だと手法が固まってない所為で割りと適当にバラつきがちなエラーハンドリングだけど、Thrift だと各言語に最適な形でエラーハンドリングができ、例外が扱える言語ならちゃんと適切な例外が飛んでくる。

便利！

・マイクロサービスのトレーサビリティ

複数のシンプルなサービスをいくつも介してサービスを提供している。

マイクロサービスのいい所は、サービス単体の完成度をあげていけば 全体で何が起きているか把握しなくてもいい所だ。

ほんとうに把握しなくても大丈夫なのか？

実際に何が起きているのか。

(この時のぐちゃぐちゃした感じの図が大変わかりやすかったｗ

クライアントまで到達する間に複数のサービスをいったりきたりしている。

結果、「何か」が起きた時に原因を究明したくても、どこのサービスが原因なのかが分からないし、それを調査する責任者が誰なのかすら分からない。

詳細を把握しなくてもいいのはいいが、パフォーマンスのボトルネックが可視化できない。

そこで登場するのが Google の論文を元に Twitter が作った『Zipkin』

単体サービスでボトルネックになっているものを Firebug で探すように、結合されたサービスの中からボトルネックになっている部分をタイムライン形式で表示して可視化できる。

また非同期的なものを可視化できる。

（実際にキューを積んで処理してる図がわかりやすかった。

どのように動くのか？

サービス間のやりとりをスパンとして木構造で集約していく。

実際にはクライアントと各サービスのリクエスト・レスポンスのタイミングでロギングしていく。

またデバッガーにブレークポイントを仕込むように、コード上の任意のタイミングでのロギングも可能な為、サービス内の処理も切り分けて視覚化できる。

構成としてはサービスからScribeでログを受け取るコレクタ、コレクタが受け取ったデータを溜めるストレージ、ストレージから検索機能を提供するクエリサーバー、そしてそれらの集計した結果を表示するWEB UI で構成される。

ストレージは Twitter が最近まで使っていた Cassandra が一番テストされていて熟れているが、運用実績を考慮して HBase に。

また各サービスに zipkin-collector とのやりとりを実装してもらうのはコストが高い為、サービス間で Thrift によるリクエストを受けたタイミングでフィルタに通す形でログに保存するデータを収集して Scribe プラグインをいれた fluentd 経由でログを送信している。

今後は収集したログをよりインテリジェントに分析できるように、またトレーシングの導入コストをより軽減させるライブラリをつくって可能であれば公開したい とのこと。

というような事をまとめがてら、記憶の不確かな部分を調べる為に検索していたら、本家の記事があったので、こちらを読みましょう。

LINEのマイクロサービス環境における分散トレーシング « LINE Engineers' Blog

図もあって大変わかりやすい。

懇親会と二次会

現在のエンジニアさんの分布だとか福岡の新オフィスの話しとか、福岡のサポセンの話しとか、他言語化初期のサポセンの苦労話しとか、社内言語の話しとか、なぜ京都開催になったのかとか色々とお話が聞けた。

なんでテルサになったの？というか「なんではてなじゃないの？」みたいな会話が面白かった。

あとは大手サービスの裏側を支えるエンジニアみたいな話題で某大手動画配信サイトの話しなど聞けたのが楽しかった。

勉強会で色んなエンジニアが集まれば色んな繋がりがあるもんだなぁ。

最後まで居たら終電逃して途中駅から歩く感じにはなったけど、ほんとに面白い話題しかない みたいな感じで過せたので とても楽しかったしモチベーション上がる感じでした。

次回もし関西(大阪でも)開催されたら参加したいな。

はてなオフィスだといいなー。

宣伝

それはそれとして、明日(というか今日10/18)の夜22時からプログラマーズナイトというイベントがあります。

プログラマーズナイト第5夜 - connpass

プログラマーやらエンジニアが集まって、素敵な音楽が流れる中お酒を呑みながらあーだこーだ話したり、しゃべりたい事をLTしたりするイベントです。

LT する人も現地でまだまだ募集してるし、「こんなサービスつくったぜ」みたいな宣伝がてら技術解説するLTとかでも歓迎...のはず。

夜22時から朝4時までのオールナイトイベントなので、近くで飲んでで帰りそびれた人なんかも ふらっと立ち寄ると楽しいかもしれません。

まぁなんか聞かせたい人も聞きたい人も、だらだらだべって酒のみたい人も是非。

90年代の思い出がまた1つ消える―Winamp、15年の歴史に幕 | TechCrunch Japan

15年かぁ...

これをきっかけに身内のチャットで懐しいフリーソフトの話題が出てたんだけど、

『自分が今使っているので一番歴史の古いのは何だろう？』 ってのと 『一番長く使ってるのは何だろう？』 みたいな話題に発展していった。

vim っていつからあるのってなったりもしたが、Windows 以外をいれたら そっちの話しで終わってしまうので Windows に制限しようとなった。

(ちなみに Vim は87年に出来たらしい。

そもそも OS 入れ直して最初にいれるフリーソフトってもう殆どなくなってる。

当時は大量にダウンロードしてフォルダ分けしてランチャに登録してたが、今となっては

Firefox,Chrome,iTunes,Putty,terapad,Lhaplus,GOMPlayer,Launchy,X-Finder,skkime

あたりか。

最初の3つはかなり大手だし、後半の方は比較的最近。

なんかしっくりこないが、Firefoxが一番歴史は古そう。

一番長く使ってるのは多分 Lhaplus と terapad 。

解凍は explzh 使ったり WinRAR使ったりもするが。

開発目的に都度いれてるフリーソフトもいくらかあるが、FFFTP以外でそんな長く使ってるのは無いかな。

FFFTP,cassava,tksqlite,WinMerge,Namery

VS Express とか Windows Live 系とかフリーソフトって感じじゃないけど、一応フリーソフトの範疇なんかね。

そんなような事を考えてたら、一番古いのは Adobe Reader なのではないか？ という疑問が出されて、

調べてみると 1993年初出で、自分が今使ってるソフトで一番歴史が古いものに該当しそう...

うーん何かしっくりこない。

使ってきたもの

これ使ってたなーって話題も尽きなかった。

皆が色んなソフト使ってるのと比べて、俺は移行を面倒臭がるのであまり触ってないような気がする。

(流れ上、シェアウェアも入っている)

ブラウザ

IE6 -> Lunascape -> Firefox -> Opera -> Firefox(Vimp) -> Firefox(Vimp) & Chrome

回りが Sleipnir を使う中、かなり長い事 Lunascape を使っていた。

Opera もかなり愛用していたが、Vimperator を使う為に Firefox に戻った。

変わり種だと、一時期『ほぼテキストブラウザ』というのを一部の場所で使っていて、MSの メモ帳 みたいな見た目で面白かった。

他にも2ch用に『A bone』とか『JaneStyle』とか、ブラウザにaddonが少ない頃は、専用品もけっこうあったな。

ダウンローダー

普通に使ってると用のないツールかもしれないが、『うめ～このみかん』とか『璃樹無』『らるちー』なんかの名前にピンとくる人にはお馴染だろう。

iria, FlashGet, DCさくら -> Irvine -> Chrome

今はもうブラウザのDL管理機能が充実しているし、そもそもファイルを保存する機会も殆ど無くなってしまった。

こうやってリッチな環境に統合されて使わなくなったものは、かなり多い気がする。

オーディオプレイヤーとリッピングツール

話題元である所の Winamp も勿論使っていた。

Winamp -> KbMedia Player -> Winamp -> iTunes

CD2WAV32 & 午後のこ～だ -> CDex -> iTunes ->

昔は取り込みも別ソフトでやってたけど、今は iTuensに任せっぱなしというか、

そもそもデータで購入できるようになって、ノートPCからドライブすらついてないというか...

CD関係だと『CD Manipulator』とか『DAEMON Tools』とか『CloneCD』とか『DVD Decrypter』とか色々お世話になりましたね。

変わり種で『Virtual CD-ROM Case』ってソフト使ってて、大量にあるCDを管理するのに便利だった。

画像ビューワー

Susie -> Leeyes -> マンガミーヤ -> ComicGlass -> PerfectViewer

今でも MangaMeeya の実行ファイルは残ってるんだけど、利用は iOS の『ComicGlass』やAndroidの『PerfectViewer』に移った。

WindowsMobile ですら マンガミーヤCE 使ってたシンパではあるんだが、滅びてしまったのが寂しいソフトだなぁ。

メッセンジャー

学友との連絡やらゲーム仲間との連絡にと、色々と活躍してくれたもの。

ICQ -> MSN Messanger & Yahoo Messanger -> Regnessem -> Skype & LimeChat

グループによって使っているメッセンジャーが違って難儀したが、Regnessem の登場はそれを解決する画期的なツールだった。

音声通話のしやすさから Skype へと移行したが、文字チャットの主体はコミュニティの影響で IRC になった。

今も一部で使っているので LimeChat と書いたけど、殆どの利用は 拙作ではあるが tiarra Metro を使っている。

少しズレるが、夜な夜なFPSをやってた頃は『TeamSpeak』なんかも使っていた。

その他 エディタ、メーラーなど

普通だとここもズラーっと並ぶと思うんだけど、俺は秀丸もsakuraエディタも使ってなくて、最初期に触った terapad を今でも使ってるので、遍歴がない。

(開発に使うIDEは右往左往しているが)

メーラーも今は Gmail なので殆ど使わないが、使う必要がある時も 昔と変わらず Thunderbird を使っている。

学生メアドの運用に持ち運びが効く nPOP を使っていた事もあったな。

書きながら当時の事思い出してたら『めもりーくりーなー』とか『伺か』とか『窓の手』やら何かどんどんと...

何か思い出話をどっかに書き殴りたいだけ、みたいなエントリになったが、そもそも実際思い出話をどっかに書き殴りたかったので仕方がないな...

シェアウェアも含めると、一番長く使ってるのはチューチューマウスな気がせんでもない。

ねずみかわいい。

使えない間に取り込めなかった写真を一気に取り込んで整理したが、やっぱり便利だ。

何か丁度 Adobe の15%オフキャンペーンを2/15から開始してるんだけど、それとは別に Amazon がキャンペーンを2つやっているので、それを適用すれば さらに1000円引きになる。

殺安！

※Lightroom4 だけじゃなく、PhotoShop Elements11 もキャンペーン対象だけど、とりあえず自分が買った Lightroom4 の話しに絞る。

アドビ 春スタート！キャンペーン | Adobe

アドビ側のキャンペーンはアドビの公式ショップはもちろん、家電量販でも価格適用されているので、ヨドバシやビックの方がポイントも含めると Amazon より少しだけ安い。

けど、Amazon はそれに加えて2種類のキャンペーンを以前から展開している。

Amazon.co.jp: アドビ製品とお好きな対象商品を一緒に買うと、その場で1,000円引

文字通り 一緒に買うと購入時に1000円引きされるというもの。

この対象商品はかなり幅広くて『Amazon.co.jpが販売かつ発送する商品』であれば何でもいいので、本でもCDでもマケプレや外部ショップのものじゃなければ大丈夫。

詳しくはリンク先参照。

Amazon.co.jp: アドビダウンロード版を買った方にクーポン1,000円分をプレゼント

文字通り ダウンロード版を買うとすぐにメールでギフト券がアカウントに適用された旨が通知される。

こっちは対象商品にしか使えないギフト券だけど、それも『Amazon.co.jpが販売かつ発送する商品』であれば何でもいいので 自由に使える。(ただし3月一杯までに使わないといけない

これ前者にだけ "※ 他キャンペーンとの併用はできません。" って注釈が付いてるので重複は出来ないのかな？

後述するけど、facebookで学割アップキャンペーンとは併用できるらしいので、この注釈がどの程度正しいのか分からなかったりする…

俺はキャンペーンに気付かずに買ってしまっていたので、DL版の方だけ自動適用されてたので検証はできなかった。

商品ラインナップと価格

そんなこんなで対象の『Lightroom4』のラインナップは以下。

まずパッケージ版。

左から通常版、アップグレード版、特別提供版(乗換用)、学生・教職員用アカデミック版。

1000円引きで、通常版で11500円くらい、アップグレード版や特別提供版で6700円くらいになる。

アカデミック版になると、Facebookでシェアすると10%オフになるキャンペーンが併用できるので、3800円くらいだろうか？

学生いいなぁ…

続いてダウンロード版のWindows用。

左から通常版、特別提供版、アカデミック版。

ダウンロード版にはアップロード版の取り扱いが無いらしい。

そしてダウンロード版のMac用。

左から通常版、特別提供版、アカデミック版。

パッケージが全部同じでややこしい。

価格設定は基本的にパッケージ版と一緒だけど、通常版だけ300円ほど高くなっている。

ダウンロード版には1つだけ難点があって、Windows/Mac が別扱いになっている所。

ただこれは多分システム上 ソフトウェアのダウンロード部分でどっちかしかダウンロードできないから切り分けているだけで、ライセンスキーは一緒なんじゃないかなと疑っている。

今回ダウンロード版を購入して、"既にインストールしていた体験版"にライセンスを登録する形で使えたので、Amazon からダウンロードする必要はないし、将来的にどっちかに移行するかもって人もダウンロード版で問題なかったりするのかな？

まぁ憶測なので保証はしません…

うちは乗り換え対象になるソフトがあったので特別提供ダウンロード版を買いましたが、7711円での購入後に1000円のAmazonギフト券が自動でアカウントに付与された形。

キャンペーン重複できるか試しておけばよかったなぁ…

しかし出来る事が今更分かったらそれはそれで悔しい。

以前から Nexus7 で nesne の録画番組を見るのに使っていた Twonky Beam がアップデートされたんだけど、新機能として動画をアプリ内に保存できるようになった。

これ割りと凄い事で、今迄 sony 製品くらいでいか受け取って外部で見たりできなかったのが、Android 4.0以上対応の端末であれば とりあえず持ち出せるようになった。

ただしこのアップデート以降はアプリ内課金でキー購入しないと、再生も含めて DTCP-IP を利用した機能が使えないらしいが、前々からのバージョン使ってる人は別に そのまま使えるらしい。

使ってて良かった。

あとはライブラリのトップに出てる「ダウンロード済み」から通信切ってようが再生できるという嬉しい感じですね。

あとサイズがどうなってんのか見てみたんだけど、

元々3倍で録画してる300MB程度の5分番組が、Nexus7 場では90MBくらいに縮小されていたので、

これ Vita とかに書き出す用のエンコードされたモバイル向けファイルを持ってきてくれてるみたいで、SDカードの無い Nexus7 としては大変ありがたい。

ただそれでも元データが30Gとかあるアメフトの試合は持ってこれんかったが...( ´-｀)

あと多分 Android の事だから、機種による相性とかもあるかもしれんが、この記事みて プレミアム版買ったけど見れねぇぞこらとか言われても僕は知りません。

とりあえずウチの Nexus7 ではいい感じで動作しております。

そういえば Twonky Beam と言えば、iOS 版でも DTCP-IP 対応して番組が見れるようになったので、iOS ユーザーも今のうちに入れておいた方がいいんじゃないかって感じですが、

なぜか Android 版では出来ないスクリーンショットの録画が iOS 版では(警告が出るにせよ)出来てしまうみたいで、

なんかネタとして fb とかに投げる時に それ使えると便利だなぁと思うけど、色々問題ありそうだなこれ...

これを使えば比較的簡単に ストアアプリを gyazo れる…筈。

gyazowinp 自体は Windows8 でも正常に動作するのですが、

ストアアプリで gyazo を利用するにはいくつか問題があります。

Windows8 でもデスクトップソフトウェアとして gyazowinp 自体は問題なく動作するのですが、

ストアアプリの表示中にはそもそも、デスクトップソフトウェアを起動する事ができません。

(起動すると画面がデスクトップに切り替わってしまう。

複数のディスプレイでの利用の場合は、一方の画面にストアアプリを表示し、

デスクトップ側でクリックしてキャプチャを開始すれば gyazo の範囲に指定する事はできますが、

結果としてデスクトップ側のゴミが入るし、アプリ内の一部分のみの投稿とかには向きません。

その為、Windows8 ではプリントスクリーンなどでキャプチャした後にペイントソフト等で開いて、

あらためてその画面を gyazo で切り出す といった事を ここ2日間ほどしていました。

が、正直めんどくさい。

解決策

gyazowinp の起動時にクリップボードに画像が入っている場合、画面上に表示する機能を実装しました。

つまり、プリントスクリーンをした後の切り出し動作自体を機能として盛り込みました。

これで、例えば alt+PrtSc でクリップボードに画像が入った後に gyazowinp を起動すると、

こういったキャプチャ画像の入ったウィンドウが表示されます。

このウィンドウは gyazowinp 終了時に勝手に閉じます。

今まで通りの感覚とは言い難いのがちょっと残念ですが、これには利点もあって、

例えば従来の gyazo ソフトでは、右クリックメニューなんかのフォーカスが外れると消えてしまうモノには使えませんでした。

ストアアプリ同様 プリントスクリーンを使うしか無かった訳ですが、その時の手順も少なくなってて、楽になると思います。

また クリップボードに何も画像データが存在しない場合は従来通りの動作をします。

っという事で実装したものがこちらになります。

--- download ---

なおこの機能は、デフォルトではオフになっていますので、有効化する場合は readme.txt に従って ini ファイルに設定してください。

その他のアプローチ

ちょっと実装コストが高そうなので僕は作る予定はありませんが、

一つアイディアが浮かんだのでそれを記載しておきます。

ストアアプリで動作するIME作成のガイドラインを見ていると、他プロセスから ストアアプリのウィンドウに所属するウィンドウを作成する事は可能なようです。

その為、起動時に画面表示が切り替わらない、ウィンドウの無いアプリを作る事が出来れば、ストアアプリ用の gyazo も作れるのではないかと思いました。

ただ、チャームを利用するにせよ何にせよ、アプリのランチャそのものを起動すると画面が変わってしまうというのがあるので、

もし gyazo を常駐アプリとして裏で動かしておき、何らかのモーションやキーフックで作動するようにできれば…

みたいな所までは考えました。

ただまぁアプリ間の独立がガッチガッチなので、そういうのキーフックとか MSさんが許してくれていない気はします…

なので未検証で、とくに調べてないので 誰か検証してみてくれるといいかな～

この辺、夜中に色々相談していたので、その辺まとめとく。

誰かメシどこか補足頼む。

最終的にどう初期化されるのかまでは元記事が追記で説明してしまってるのだが、

なんでこんなんあるのかみたいな所の話しがないので、個人的に到達した結論。

そもそも何でクラスとプリミティブな型の初期化時の構文を合わせる必要があるのか、だけど

クラスのメンバー変数の初期化リストを記述する時に、クラスのコンストラクタ呼出しと同じような記法でプリミティブ型も初期化できるようにする為だと思う。

class Test{ 
  int a,b; 
public: 
  Test() : a(5), b(){ 
  } 
}

こーゆーこと。

ここでは『変数名()』の形で記述する事が認められていて、クラスと同じように書けるようになっている。

統一感を出す為なのか、同様に宣言の所でも int x(n);で初期化できるようにしたが、

int x();

のように引き数を省いた初期化は変数の宣言と見分けが付かない。

(これは同様にクラスでも 明示的にデフォルトコンストラクタを呼び出す形に () を付けた宣言はできない。

しかしクラスは

Test x;

でコンストラクタが走る。

プリミティブ型はクラスと違ってインスタンス生成がないのでコンストラクタは走らないが、

int x;

で、スタック領域に配置される。

しかしこの段階では初期化が行なわれないので、変数の値は不定である。

この辺は C との互換を守る為にはどうしようもない部分。

そんなこんなで、『変数名()』 で 特定の場所だけ初期化できるけど全体的に統一感に欠けるのはその辺の互換絡みの しがらみの所為なのかな。

妄想に裏付けを

ここまでは全て想像で書いているので、裏付けとかが欲しいので明日もうちょっと調べてみようかなぁ。

誰か仕様策定の経緯に詳しい人がいたら、是非なんかブコメとかでもいいので教えてもらいたい。

「 こうゆう理由でプリミティブ型の初期化構文はクラスに合わす事を強いられているんだ！」みたいな感じで。