Love💕LivePhotos
NGK2016Bでライブフォトの話をしてきた。
資料
関連資料
- 📷 mov/jpegからのLive Photo生成 - みずぴー日記
- https://github.com/mzp/LoveLiver
- AppleエンジニアにありすLive Photoを見せてきた話 / Story apple engineer meets arisu Live Photo // Speaker Deck
原稿
自己紹介
仕事ではMisocaというWebサービスを作っているが、これはスポンサーセッションではないので、まったく関係ない話をする。
具体的にはiPhoneの話をする。
ライブフォトの紹介
最近のiPhoneにはライブフォトという機能が搭載されている。 普通に写真を撮ると、前後が動画として記録される。
ライブフォトはロック画面に設定することもできる。 そのため、「動くロック画面」が実現できる。
理想
ので、こういうロック画面を作りたい。
問題点
ライブフォトはiPhoneのカメラで撮影しないと作れない。
それでは困るので、任意の画像・動画からライブフォトを生成する方法を探さないといけない。
調査内容
いろいろ調べた結果、movファイルとjpegファイルのメタデータに同じUUIDを書き込んで、Photosアプリに取り込めばライブフォトになることがわかった。
LoveLiver
これをアプリにした。
アプリ名はライブフォトを愛するという意味でlove liverと名付けた。動画ファイルを取り込んで、指定した箇所をライブフォトに変換できる。
その後
以上が一年前の話です。そして、そのあとの一年に起きたことを順番に話す。
題材
iPhoneは縦長かつ高解像度のため、なかなか適した題材がない。
デレステ 縦MV
奇跡的にデレステの縦MVバグ(?)が見つかる。 これは発見直後のまとめで、みんなが大喜びしているのが分かる。
大量のライブフォト
これにより大量のかわいいライブフォトが生成できるようになった。
ちょいちょい寿司の画像がまざっているのは気にしないでほしい。
WWDC
WWDCにはラボと呼ばれるAppleのエンジニアと一対一で会話する機会がある。
そこにLoveLiverのもう一人の開発者がいって、APIの有無を聞いた。ついでに生成されたライブフォトを見せて、coolと言ってもらった。
Tumblr
長い間、ライブフォトの共有方法はなかったが、先日Tumblrが対応した。
タッチバー対応
最近は、新型MacBookProを買ったので、タッチバー対応をしている。 どこをライブフォトにするかを選択できる。
まとめ
きときと
ゆるゆりの舞台訪問のために富山に行った。
ゆるゆり舞台
ゆるゆりなちゅやちゅみの舞台をメインに回った。場所等は以下のサイトを参考にした。
- つればし 『ゆるゆり なちゅやちゅみ!』 舞台探訪(聖地巡礼) ~富山県/高岡エリア~
- つればし 『ゆるゆり なちゅやちゅみ!』 舞台探訪(聖地巡礼) ~富山県/砺波・南砺エリア~
- ☆ ゆるゆり さん☆ハイ! 聖地巡礼(舞台探訪) エリア別ガイド【全話まとめ】 ☆ - nobu cafe♪
砺波平野
なちゅやちゅみのラストシーンのキャンプ場。 スキー場の上に登らないと見えない風景なので、がんばって登った。
らんぶる
序盤にでてきた喫茶店。 せっかくだし、ということであかりちゃんたちが座ってた席を選んだら、すぐ近くにポスターが貼ってあって良さがあった。
最高のカフェきた pic.twitter.com/mYAr9AtrLg
— mzp (@mzp) 2016年10月22日
— mzp (@mzp) 2016年10月22日
ついでに、豆とドリッパーを購入して、滞在期間中に飲むコーヒーも確保した。
その他
その他に高岡市内やココスに寄って、舞台訪問の実績を解除した。
Netflixに加入しておくと舞台で該当のシーンをその場で確認できてよい、という知見を得た。
宿
直前まで予約をさぼっていたら、Jalanで予約できるホテルがすべて埋まっていた。 なので、始めてAirbnbを使ってみた。
そしたらなぜか5階建ての一軒家を貸しきることになって異常に豪華だった。
本日の宿です pic.twitter.com/0gUOO4JYV9
— mzp (@mzp) 2016年10月22日
ゆるゆり聖地巡礼なので茶室もあります pic.twitter.com/bvZrd0lBS2
— mzp (@mzp) 2016年10月22日
いろり、あります pic.twitter.com/GmDkrKTyud
— mzp (@mzp) 2016年10月22日
発表できる雰囲気すらある pic.twitter.com/gZCIG79lhC
— mzp (@mzp) 2016年10月22日
完全にバーだわ pic.twitter.com/cMsl0TtXcD
— mzp (@mzp) 2016年10月22日
セミナールーム(?)でブルーレイが再生できたので、シンデレラガールズ 3rd LIVEのブルーレイをずっとみていた。
寿司
せっかく富山に来たので寿司を食べた。 海老がやたらうまくてびっくりした。
観光
高岡駅の近くに古い町並みが広がっていたので、普通に観光していた。 Wifi案内に大仏の絵が描いてあって徳が高そうだった🙏。
大仏見にきたら、wifiに接続できるようになった🙏🙏🙏 pic.twitter.com/GZKzRwY6LU
— mzp (@mzp) 2016年10月24日
その他
ハロウィンガチャをひく人がいたので、タイムラプスで撮影したらだいぶ楽しい感じになった。
「ハロウィンイベントやってないソシャゲーはないですからね」と言いながらガチャを引いてる人がいる pic.twitter.com/OqFRs6RsNb
— mzp (@mzp) 2016年10月24日
AquaSKK 4.4.[2-4]: JetBrains対応
要約
AquaSKKレベルでJetBrains製品に対応するのをあきらめた。C-j/l/q/L/Qを使用可能にするために、Karabinerを利用するようにした。
ダウンロード
https://github.com/codefirst/aquaskk/releases/tag/4.4.4
使い方
Karabinerのprivate.xmlに以下のように書く。
<?xml version="1.0"?> <root> <include path="/Library/Input Methods/AquaSKK.app/Contents/Resources/karabiner.xml" /> </root>
するとKarabinerの設定画面にJetBrains用の設定が表われるので、それを有効にする。
さらにAquaSKKの互換性で com.jetbrains
に対して「入力ソース同期」を有効にする。
制約
無理矢理やっているため、いくつかの制約がある。
- AquaSKK統合では動作しない
- 入力モードを切り替えたときにポップアップはでない
変更内容
JetBrains製品ではC-j/l/q/L/Qが使えないため、なんらかの回避策が必要となる。
これまでAquaSKK側でいくつかの回避策を取っていたが、JetBrains側の挙動に強く依存しているため、たまに動かなくなったりする。 これまでも何度か対応をしている。
そういった対応もそろそろツラつらくなってきたので、より低レベルな部分で対応できるKarabinerを使うようにした。
そのため、AquaSKK側に以下のような変更を加えた。
- JetBrains用の回避コードをはずした。
- Karabiner側の入力ソース変更にAquaSKKが反応するようにした。
Sierra
KarabinerはまだSierraでは動かないが、JetBrains製品も動かないらしいので、これでいいと思っている。
MacOS Sierra対応を現在進めております。JetBrainsのデスクトップ製品(IDE)をご利用の方は、対応が完了するまでアップグレードを保留していただくことをお勧めいたします
— JetBrains (@jetbrainsjp) September 21, 2016
ちなみにAquaSKK自体はSierraでも動く。
ファミコン エミュレータ
エミュレータを作ってみたいなぁという漠然とした思いがずっとあったので、ファミコンのエミュレータを書いている。スクリーンショットにあるような表示はできる。
ファミコンにした理由
エミュレータは作りたいが、よく知らない機械のエミュレータを作ってもつまらないので、多少は親しんだファミコンにした。
一番印象深いゲーム機はスーパーファミコンだが、スーパーがついてないほうが簡単かな、と思ってファミコンにした。
買ったもの
カートリッジからROMイメージを吸い出すために、吸い出し機をAmazonで購入した。
GAMEBANK-web.comオリジナル「FCダンパー」 / ファミコン ファミリーコンピュータ Famicom Kazzo DUMPER レトロゲーム 吸い出しツール [0217]
- 出版社/メーカー: GAMEBANK-web.com
- メディア: エレクトロニクス
- この商品を含むブログを見る
ゲーム自体は大須のレトロゲームを取り扱ってる店に行って買った。1200円くらいした。
進捗の様子
Hello world
NES研究所にあるサンプル。
最初はこれを動かすのを目標にしていた。作ろうと思ってから、これを動かすまで2週間ほどかかっている。
ギコ猫
ギコ猫でもわかるファミコンプログラミングにあるサンプルを一個づつ動かしていった。ギコ猫なつかしい。
スーパーマリオブラザーズ
一番最初にスーパーマリオブラザーズを動かしたときの様子。 空の色がおかしい。
だいたいの背景色が正しくなったが、一部おかしい。
空の表示はできるようになった。
Sprite 0の当り判定(ヒットフラグ)を実装したら、タイトルがでるようになった。
VRAMの読み込みがおかしかったので修正した。
スプライトの表示をちゃんとしたらマリオっぽいのが表示された。 が体がバラバラになっている。
スプライトの反転処理を実装したら、体がくっついた。
スプライトの背景処理をちゃんとした。
他の画面もそこそこ動く。
実装してないこと
実装してない部分を列挙すると以下のようになる。ゲームとして遊ぶのは無理だと思う。
- mapper 0以外のカートリッジの対応
- タイミング制御。普通に画面がチラつく。
- サウンド
つらさ
うまく動作しないときの原因の特定が、本当に大変だった。
エミュレータは任意のプログラムを入力とするので、許容する入力が圧倒的に多い。さらに、その内容は機械語で書かれているので意図を理解するのが難しい。 だいたいは、以下のような手順でデバッグしていた。
- ディスアセンブルしたコードを読んでなんとなくの動きを把握する。
- そして、その通りに動いてるかどうかをメモリを監視しながら確認する。
- 変な動きをしてるところがあったら命令のログもとって重点的に動きを追っていく。
Rubyで書かれたNESエミュレータであるoptcarrotと動きを比較してみることも多かった。
逆アセンブルしたコードを読んでたら、ジャンプ先がアドレスじゅなくて名前の世界、マジ最高、って気分になってきた
— mzp (@mzp) August 14, 2016
現状
さぼっていた部分がだんだんと致命的になってきてウワーとなっている。
- 上から順に1ラインづつ画面を更新していく、
- CPUとPPUのタイミング動機
がっつり直さないといけないけど、どうしようかな…。
レポジトリ
https://github.com/mzp/famicom/
そろそろGo言語を勉強するか、という気分だったのでGo言語で書いている。深い意図はない。
参考にしたページ
その他
AquaSKK 4.4.1
AquaSKK 4.4.1で設定画面で辞書を追加する際に file:// がついてしまう問題を修正した。詳細は、Issues #55に書いてある。 あとスクリーンショットの壁紙がかわいい。
ダウンロード
https://github.com/codefirst/aquaskk/releases/tag/4.4.1
経緯
デレステ辞書を作るのを手伝っている途中で指摘されたので、「すみません、すみません」と思いながら修正した。
この挙動はかなり前から認識していて、実際たまに困っていた。 ただ、たまになので手動で直して回避してしまっていた。
ちょうどいい機会なので、勢いで直した。
要約
生 産 性 が 上 が り S K K 実 装 の バ グ 取 り が 捗 る デ レ ス テ 辞 書
— マロニー (@mlny_c) 2016年9月2日
GithubとTrelloの連動
GithubのラベルとTrelloのリストを移動を連動させるprprのプラグインとして作成した。
https://github.com/mzp/prpr-trello
解決したい問題
Misocaの開発チームではタスクをTrelloで管理している。 そのため、タスクに対応するPull requestをレビュー待ちにしたら、Trelloのカードを「レビュー待ち」リストに移動するという運用をしている。
しかし、この移動を忘れがちでレビューに支障がでていた。
prpr-trello
この問題を解決するために、prpr-trelloを作成した。
これは、Pull requestのdescriptionの一行目にTrelloカードのURLが書いている場合、以下のようにカードを移動する。
- WIP用のラベルをつける: 作業中リストに移動する
- REVIEWラベルをつける: レビュー待ちリストに移動し、カードの説明にPull requestへのリンクを追記する
- Pull requestを閉じる: 完了リストに移動する
余談: 開発前夜
ぼく「....みたいなbotほしくないですか?」
@kokuyouwind 「あれ? 今でもそういう機能ありませんか? ほら、例えばこれとか」
ぼく「それはボクが毎朝、手動でやってるんです...」
論文紹介: The Evolution of C Programming Practices: A Study of the Unix Operating System 1973–2015
ICSE 2016勉強会に参加するために論文リストを確認していたら、40年間のC言語のプラクティスの変遷を追った論文がおもしろかったので紹介する。
対象の論文
- 論文: The Evolution of C Programming Practices: A Study of the Unix Operating System 1973–2015
- 論文中で使われれたデータ: https://github.com/dspinellis/unix-history-repo
要約
過去40年間のUnixのソースコードを分析し、コーディングスタイルの変化を調査した。その結果、以下のことが分かった。
分析対象
1972年以降にリリースされた計66個のUnixを対象とする。 これには以下のものが含まれる。
分析したリリースをタイムラインにまとめると以下のようになる。
(Figure 1: Timeline of indicative analyzed revisions and milestones. in Proc. of ICSE '16, p.754)
立てた仮説と結果
事前に立てた仮説と、分析によりその仮説が支持されたかどうかについて述べる。
なお以下に示すグラフは Figure 2: Long term evolution of programming practices. (Metrics appear in alphabetical order; the number following the metric name is adjusted R2). in Proc. of ICSE '16, p.755からの引用である。
H1: 技術の進歩によって、プログラミングプラクティスは変化する
画面解像度や通信速度などの向上にともない、識別子や行が長くなっていくと考えた。
分析の結果、以下の平均値が増加していることが分かった。
- ファイル行数 (FILINE)
- ファイル内のステートメント数 (FISTMT)
- 行の長さ(文字数) (LICHAR)
- 識別子の長さ (IDCHAR)
一方、関数の平均行数(FULINE)はこの仮説と関連しているが、途中から減少している。これは複雑になりすぎたことへの反応であると考えられる。これに関してはH6で議論する。
これらにより仮説は支持された。
H2: コードの規模とともにモジュール性が増す
コード規模が増えるにつれて、開発者はモジュール化を進めるのではないかと考えた。
分析の結果、可視性を制御するためのstatic(DSTATIC)が増加していき上限値に達していたことが分かった。最近、若干減少しているのは、カーネルモジュールや共有ライブラリといった言語外の仕組みが導入されたためと考えられる。
これらにより仮説は支持された。
H3: 新しい言語機能は一定数に達するまで使用が増加していく
unsignedキーワードといった新しい言語機能は、使用箇所が増えていき飽和点に達すると考えた。
分析した結果、以下のキーワードの使用は増加していることが分かった。
- const(DCONST)
- enum(DENUM)
- inline(DINL)
- unsigned(DUNS)
- void(DVOID)
- volatile(DVOL)
基本的に上昇傾向だが、 enumとinline は部分的に下降している。開発者が態度が変化した時期があると考えられる。
unsigned はここ数年で減少している。 これは以下の2つの要因が考えられる。
- size_t が導入され、それが使われる箇所が増えた。
- 64ビットアーキテクチャが導入され、扱える数値の幅を広げるために unsigned が使われることが減った
signed(DSIGN)はあまり使われていない。signedキーワードはchar型に符号付きの値を格納する際に利用できるが、現在では必要になることはない。
これらにより「その言語機能が便利ならば」という限定付きで仮説は支持された。
H4: 開発者はコンパイラのレジスタ割り当てを信頼している
コンパイラ技術が発展しレジスタ割り当てが改善するにつれて、開発者はコンパイラのレジスタ割り当てを信頼するようになっていったと考えた。
分析の結果、registerキーワードの使用(DREG)は1990年ごろから減少していることが分かった。
H5: コードの書き方は収束していく
Unixという一つのプロジェクトで作業してるため、共通のコーディングスタイルが採用され、コードベースは均一になっていくと考えた。
分析した結果、コードフォーマットのばらつき(FMINC)やインデントのばらつき(INDEV)は減少していったことが分かった。
これにより仮説は強く支持された。
H6: ソフトウェアの複雑性には自己修正機構が働く
ソフトウェアが進歩に複雑性は増し、人間の限界を越えてしまう。 そのため、成功したプロジェクトでは複雑性を減少させる自己修正機構が働くと考えた。
分析した結果、以下の項目が、いったん複雑性を増したのち減少に転じるというパターンを示した。
goto(DGOTO)についても同様のことが言える。 gotoは長期間減少しつづけていたが最近は増加している。 gotoの有用性に気付いたのかもしれない。
H7: コードの可読性は増す
開発者コミュニティで管理しやすくするために、可読性は増していくと考えた。
これを調べるために、以下の項目を分析した。
- インデントのためのスペースの平均値(INSPC)
- ステートメントの密度(DSTMT)
- コメントの文字数の密度(DCMCHAR)
- コメントの文字数の平均値(CMCHAR)
- コメントの密度(DCM)
- TODOコメントの密度(DKLUDGE)
コメントの密度とコメントの文字数の密度が増加したのち減少しているのは、より長い識別子が使えるようになって、自己文書化が進んだためと考えられる。
ステートメントの密度は減少傾向にあるが、2000年ごろから増加している。これはコメントのついていないステートメントが増えていることを示す。インデントのためのスペースの平均値も減少していたものの、最近は増加している。 そのため、Unixのソースコードの可読性が今も増加していることの確証は得られなかった。
まとめ
長年にわたるUnixの発展を追跡することで、Unixの開発者が以下のことを行なってきたことが分かった。
- ハードウェアの進歩にあわせてコーディングスタイルを変化させる
- 複雑度が増すにしたがいモジュール化を促進させる
- 価値のある新しい言語機能を採用する
- コンパイラにレジスタ割り当てをまかせる
- コードの書き方に関して合意に達する
また、ソフトウェアの複雑性と自己修復機構が関連していることと、文書によるコード構成の改善が頭打ちになっていることも発見した。