従来のWindowsアプリをWindows Storeで配れるようになる話――Project Centennial個人的まとめ
Microsoftの開発者カンファレンスBuild 2015初日の基調講演で、Windows Store AppではないアプリをUniversal Windows Platformに移植するためのツールキット群がアナウンスされた（Universal Windows Platform Bridges - Windows app development）。本記事はそのツールキット群のうち、旧来のWindowsアプリからの移植を可能にするProject Centennialについて個人的にまとめたもの。筆者による誤解が含まれるかもしれない。
Project Centennialについては、John Sheehan氏とAndrew Clinick氏のセッション動画が現時点で手に入るもっとも詳しいリソースかと思う。本記事でも内容の全ては拾いきれていない。英語が分かる人はこれらを見たほうが早い。本記事中のことは明示しない限り1番目の動画がソース。channel9.msdn.com
channel9.msdn.com
このほか、下に挙げるトークセッションでProject Centennialの話が登場する。channel9.msdn.com
概要
Windows 8から導入された、いわゆるWindows Store App（現Universal Windows App）は、旧来からのWin32や.NETとは全くことなるモデルのプラットフォームであり、既存のアプリを移植する方法が文字通り「書き直す」しかないというひどい有様だった。
Windows 10になってようやく、デスクトップアプリ (Classic Windows App) の救済に乗り出すようだ。
デスクトップアプリからUniversal Windows App (長いので以下UWA) への橋渡しとして現在開発されているものがProject Centennial (以下Project C) である。Project Cでは、.msiファイルをWindows Storeで配れるパッケージに変換するツールが提供される。デスクトップアプリをパッケージ化するためにソースコードを書き換える箇所は少なく済む。ただし、パッケージ化しただけでPhoneやIoTやHoloLensで動くとかいう旨い話ではないことに注意。
Project Cでパッケージ化したアプリは、OS XのApp Storeで配布されているアプリのような特徴を持つ。
デスクトップでしか実行できず、デスクトップ向けのAPIが呼べ、起動から終了までのライフサイクルもデスクトップアプリと同じ。ただしよりアプリらしくなる。つまり、インストール・アンインストールは簡単になり、アップデートは自動化される。
また、特権昇格が禁止されるが、OS Xのものと違ってサンドボックスで動くわけではない (Full trust)。
もう一つ重要なこととして、パッケージ化されたアプリはデスクトップAPIに加えてUWA向けAPIが呼べるようになる。Microsoftとしては、デスクトップアプリ開発者たちにUWAとしての利点を活用してもらい、段階的にクロスプラットフォームで動くアプリに移行してほしいようだ。ただし、詳しい開発フローはまだアナウンスされていない。
プレビュープログラムもまだオープンではない。おそらく細かい仕様も固まっていない。
パッケージ＆デプロイ
Project Cで提供されるツールは、MSIが行うレジストリやファイルシステムへの書き込みを全て記録して一つのパッケージ (.appx) にまとめ上げる。作ったパッケージは、ストアで配信するか、サイドローディングで他のマシンにインストールすることができる。ちなみに、グループポリシーで制限されていなければ誰でもアプリをサイドローディングできるようになる模様。
このパッケージ化でうまくいかない例があって、その一つが基調講演で紹介されたAdobe Photoshop Elements。Photoshop Elementsは、違法コピーされていないか確認するため、システム情報を集めて暗号化したものを保存している。そのために、出来上がったパッケージが他のシステムでは使えなくなる。こういった場合にはソースの書き換えが必要とのことだ。裏を返せば、そのほかは普通に動く。
このあたりはLinuxディストリ向けのパッケージ作成を想起させる。だが、パッケージの展開のされ方はLinuxディストリ向けと大きく異なる。Linuxディストリ向けではパッケージの中のファイル群が生のファイルシステム上 (/optなり/usr/shareなり) に展開される。いっぽうProject Cのパッケージでは、アプリごとに隔離された仮想環境にファイルやレジストリが展開される。その上で、実行されているアプリにだけそのアプリとともにインストールされたファイルやレジストリのエントリーが見えるようなハックがシステムレベルでなされる。
ちなみに2番目の動画によると、アプリをリムーバブルメディアにインストールすることもできる。
もう一つ、よくあるパッケージシステムと異なるのは、依存関係の解決方法。よくあるパッケージシステムでは、各アプリで共通の依存関係があるとき、その共通部分をパッケージとして独立させてアプリのパッケージとの依存関係を決める。Project Cで作成されるパッケージでは、そのアプリで必要なあらゆるDLL類を同梱することになっているようだ。これは大きな無駄と思われるかもしれないが、同じDLLファイルを同梱している複数のパッケージをインストールしてもインストールされるそのDLLファイルはただ1つである。これはNTFSハードリンクで実現すると3番目の動画でSheehan氏が述べている。
デスクトップアプリがProject Cでパッケージ化されることはユーザにとって大きなメリットだ。アンインストールでアプリは確実にシステムから除去される。レジストリやファイルシステムが汚される心配もいらない。アプリのアップデートでOSの再起動が要求されることも無くなる。
Apple Swiftのmutabilityの謎
昨晩WWDCの基調講演で発表された、Appleの新しいプログラミング言語Swift。公式ドキュメントを読んで、現時点でいくつか気になったところを書いてみる。
Stringはimmutableなのか
SwiftのString型はimmutableなのかが気になった。JavaやC# ではそうだから、Swiftでもそうなのだろうと考えていた。Stringの説明の後半部分にちょうど「String Mutability」という名前の節があったので、以下に引用する。
You indicate whether a particular String can be modified (or mutated) by assigning it to a variable (in which case it can be modified), or to a constant (in which case it cannot be modified):
1 var variableString = "Horse" 2 variableString += " and carriage" 3 // variableString is now "Horse and carriage" 4 5 let constantString = "Highlander" 6 constantString += " and another Highlander" 7 // this reports a compile-time error - a constant string cannot be modified(The Swift Programming Language: Strings and Charactersから引用)
つまり、varで束縛したときは変更出来る、letなら出来ないと書いてある。いや、自分が知りたいのはそういうことではない。自分が知りたいのは
var s = "some string" s[4] = '_'
のようなコードがエラーとなるかどうかなのだ。引用した節はこの例もエラーにならないかのようにも読めるが、サンプルコードはString自身のmutabilityとは関係がなく、確信が持てない。なぜなら
a += b
は
a = a + b
の略記法であることが述べられており、通常+演算子はオペランドのどちらの値も変更しないからだ。実際、引用したコード例ではStringを別の型に置き換えても同様のことがいえるだろう。
もやもやした気持ちを抑えて次の節に目をやった。
Strings Are Value Types
(引用元上に同じ)
Stringが値型とかなかなかマゾいぞこれ
— 0x0fb766 (@lefb766) 2014, 6月 2値型というのは、オブジェクトをコピーするときに参照のコピーではなく値(中身)のコピーが行われることを指す。これは予想外だった。長大な文字列を扱おうとするときは気を付けるべきだ。同時に、Stringがimmutableであるという予想を怪しいと思い始めた*1。なぜなら、もしimmutableなら値型である必要がない(変更されない保障があるなら参照だけコピーすればよい)からだ。
結局、同章の以降の説明を読んでもStringがmutableかどうかは分からなかった。処理系が手元にあれば早いのだが。
Mutability of Collections
コレクション型の説明をしている章でもmutabilityについての節が存在した。
Arrays and dictionaries store multiple values together in a single collection. If you create an array or a dictionary and assign it to a variable, the collection that is created will be mutable. This means that you can change (or mutate) the size of the collection after it is created by adding more items to the collection, or by removing existing items from the ones it already contains. Conversely, if you assign an array or a dictionary to a constant, that array or dictionary is immutable, and its size cannot be changed.
For dictionaries, immutability also means that you cannot replace the value for an existing key in the dictionary. An immutable dictionary’s contents cannot be changed once they are set.
Immutability has a slightly different meaning for arrays, however. You are still not allowed to perform any action that has the potential to change the size of an immutable array, but you are allowed to set a new value for an existing index in the array. This enables Swift’s Array type to provide optimal performance for array operations when the size of an array is fixed.
varで束縛したときはmutable、letのときはimmutableというところはStringと一緒だ。しかし、Stringのときより少し詳しい説明が入っている。immutableなとき、コレクションのsize(要素数？)を変えることはできない、と。さらに、今あるキーに対する値の更新がimmutableなDictionaryでは出来ないがimmutableなArrayでは出来る、とある。これはどういうことなのだろう。オブジェクトが占有するメモリのサイズを変更できないということなのだろうか。だとすれば、このエラーはコンパイル時ではなく実行時に出るのだろうか。それともメソッドに特別なアノテーションでもつけるのだろうか。
Arrayにはこのほかにも謎の仕様があるようなので、このページのAssignment and Copy Behavior for Arraysという節のコード例には目を通したほうがよさそうだった。Swiftの他にArrayが同じような仕様の言語ってあるのだろうか。筆者は寡聞にして知らない。
Xcode6 beta入れるか迷う。
*1:3日15時頃訂正。元文→「同時に、Stringがmutableなのではないかと思い始めた」
書評 - チューリングの計算理論入門
- 作者: 高岡詠子
- 出版社/メーカー: 講談社
- 発売日: 2014/02/21
- メディア: 新書
- この商品を含むブログ (1件) を見る
書籍の概要と目次は
http://bookclub.kodansha.co.jp/bc2_bc/search_view.jsp?b=257851
から参照していただきたい。
本書の魅力は、「計算とはなにか」について読者を説得する部分である。人が普段行っている計算が「分岐」と「反復」を含んでいることを丁寧に説明しており、おそらく専門外の人間にもわかりやすいだろう。
中でも次の部分は個人的には気に入っている。
人間のあらゆる作業を「計算」として定義することができる
(p. 24)
このようなことを序盤からぶっぱなしている。ドン引き食らいそうな一文だが、理解できなくもない。
一方で、理論の話になると怪しい説明が目立つ。特に非決定性計算の説明は誤解を生みそうだ。
(前略) 厳密な答えではないかもしれないけど、条件により近い答えの候補をいくつか出すことができればよいではないですか！このような、 (中略) アルゴリズムを「非決定性アルゴリズム」と呼びます。
(p. 173)
他の細かい言い間違いには目をつむるとしても、この説明は看過しがたいほど酷い。非決定性のプリミティブな意味(複数の状態に遷移できる)は一応説明してあるが、この誤解を生みそうな説明も繰り返し行われる。こういった説明を読んだ読者は正しい理解ができるだろうか？僕が専門外の読者なら、非決定性アルゴリズムというよりはヒューリスティクスのようなものを想像したか、もしくはプリミティブで正しい意味との食い違いに混乱しただろう。この点は残念だ。
ひとまずは、ブルーバックスでも数少ない計算機科学の新書に新たな一冊を卸してくれた著者の高岡詠子氏に感謝したい。こういうチャレンジはとてもありがたい。
「Skypeに『既読』機能が追加される」は誤報です
GIZMODOのこの記事をソースにした情報が各所に出回って，「SkypeにLINEのような既読機能がつく」と思っている人がいるようですが，それは誤解です．
結論から言うと，Skypeで新しくなった「既読」は
「相手がメッセージを読んだかどうかがわかる」
ではなく
「ある端末で『既読』にしたメッセージが他の端末でも『既読』になる」
というものです．
元の記者がこれを正しく解釈していたかどうかは定かではありませんが，漠然と「既読」機能などと名付けて具体的な機能を説明しなかったりタイトルに「不安」とつけていることからはやりLINEと同様のものを想像して書いたのかもしれません．僕を含め多くの人がこの記事を見て「LINEと同じような機能だ」と思ったのでこれは誤報と言っていいと思います．
このGIZMODOの記事は，こちらのブログエントリーをソースにしています．このエントリーから「既読（read）」に言及している段落を引用します．
We know that as users have started using Skype on multiple devices, they’ve had difficulty keeping conversations in sync, or they’ve missed messages and seen “read” messages on one device that are still marked as “unread” on another. We’ve been working hard to solve these issues while adding other experiences to make an improved Skype chat.
ユーザーが複数の端末でSkypeを使うようになって，会話をデバイス間で同期することを困難に思う，あるいはある端末で一度見た（「既読」にした）メッセージを他の端末で（「未読」となっているために）もう一度見たりメッセージを消失するケースがあったことを私たちは知っている．Skypeチャットを改善するほかの機能を追加する間，これらの問題を解決するべく私たちは励んできた．
We also understand the importance of knowing that messages you send have been delivered and that you receive all of the messages sent to you. Now you can have peace of mind that your friends will receive messages even if they’re not on Skype at the time you hit “send,” and, if you’ve read a Skype message on your phone, it’ll show as “read” when you check your messages on your laptop later in the evening.
送ったメッセージが相手に届いたかどうか，自分に送られたメッセージを全て受け取ったかどうかを知ることの重要性もまた私たちは理解している．これからは「送信」ボタンを押した時間に相手がSkypeにいなくとも相手がメッセージを受け取ると安心してよい．また，電話で受け取ったSkypeメッセージは夜にノートPCでメッセージを確認するときには「既読」として表示される．
ここで二つ目に挙げた段落の「送ったメッセージが相手に届いたかどうか……を知ること」の部分がLINEのあの機能を連想させますが，あとの文を読むとこれが「送ったメッセージを相手に"読まれたかどうか"を知ること」でないことは明白です．これまで相手がオフラインだとメッセージが届かなかったのをこれからは届くようになるということを言っているだけなのですから．つまり，メッセージが届いたかどうかわからないという不安を，相手がオンラインかどうかに関係なくメッセージが届くと保証することで解消しようと試みた，という解釈です．の直後に，僕が冒頭で述べた「既読」の新機能に触れています．
追記: オフラインのユーザーに送ったメッセージが未達になるという以前までの仕様は，1次ソースとなったブログ記事からは読み取れず，事前知識として知っている必要がありました．
複数の事柄が短くまとまったややこしい文章ではありますが，これをいい加減に翻訳して書くと立派なデマになります．
イラッとくる通知，あるいは通知作る時に気を付けたいこと
今回は愚痴エントリーです．
イラっとくる通知
もはやスマートフォンでの生活には欠かせないほど便利な通知．しかし，中にはイラッとくるような通知を送ってくるアプリもあります．今回は，僕のiPhoneの数少ないインストール済みアプリでウザいと思った，行儀の悪い通知を紹介します．なお，執筆時点で今回紹介するアプリの通知はLINEを除いて全て設定でオフにしています．よって，僕の感知しないうちに改善されたものがあるかもしれません．
Twitterのタイムライン通知
自分へのリプライなどを通知してくれるもの，だと思っているのですが．全然関係ないツイートが通知されてきたり，よくわかりませんでした．設定でフィルタなるものがon/off出来るようだけれども，切り替えてどうなるのかイメージが湧かず，切り替えてもどうなったのか分からず．
はてなブックマークの「○○をブックマークする」
クリップボードにURLをコピーしているとこの通知が出てきます．しかも，時間が経っても消えない．同じことが何度でも通知されます．
通知というか単なるプロモーションなのでウザい．
LINEの新着スタンプ・公式アカウント・お知らせ
アプリ内限定のバッジ通知．ツールバーに表示されます．
プロモーションであり，バッジを消すのに必要な操作も多いです．
これは通知センターの設定で消せないので，バッジの類は消化しないと気が済まない僕泣かせ．
新年明けましておめでとうございます2014
皆さん、新年明けましておめでとうございます
— 可視性 Enumeration (@lefb766) 2013, 12月 31kitiの皆さん、新年明けまして☝( ◠‿◠ )☝
— 可視性 Enumeration (@lefb766) 2013, 12月 31新年にネタを投入したつもりが，年明け直後の高速あけおめTLに紛れて反応なかったので悲しかったです(´･_･`)今年最初のつらぽよ
Twitterばっかりでエントリー少なすぎたことが昨年の反省点．
今年は頑張って週1くらいは記事書いていきます．年間50本以上を目標に！*1
2014年も本ブログをよろしくお願いします！
*1:もちろんこの記事もカウントに入れて...だめですかそうですか...
デスクトップからアイコンをなくした
家で使っているWindowsのデスクトップからアイコンを一掃しました．理由は以下の3点．
- 普段はウィンドウを全画面表示ないしは左右分割で使うことが基本で，もともとデスクトップにはアクセスする機会が少なかったこと
- Winキーの無いキーボードを使い始めてWin+Dが使えなくなったことで，デスクトップがアプリランチャーとしてはもはや使い物にならなくなったこと
- ストアアプリとデスクトップを並べて使ったときに，デスクトップ上のアイコンが移動されて自動で元に戻らない*1ことが不快だったこと
「ごみ箱」が消せるかどうかが不安でしたが，調べてみるとこれも「個人設定」→「デスクトップアイコンの変更」で表示しないように設定できるようです．
XP時代，アイコンが散乱した醜悪なデスクトップを晒していた僕ですが，このたびこうしてアイコンを完全に除去できて大変すっきりしました．なお，今ではデスクトップの代わりににDownloadsフォルダが混沌としている模様．
余談
そもそもなぜデスクトップにファイルアイコンが置けるのかと昔疑問に思いました．その答えは他でもなくウィンドウベースのGUIシステムにデスクトップ（机上）というメタファを付けたからですね．GUIの黎明期であった当時は，メタファをつかうことでコンピュータに不慣れな一般人を取り込むことが目的だったのでしょう．個人的にはデスクトップよりもウォールのほうがしっくりくるのですが．デスクトップに貼る画像を「壁紙」とか言いますし．
デスクトップのファイルマネージャとしての機能は疑問視する声が他にもあったらしく，オープンソースなGUI環境群においては，ちょっと前にデスクトップに関するいくつかの動きがありました．KDEでは4.xのデスクトップ*2がウィジェットを置く空間に変わりました．これは旧来のデスクトップの役割を発展させたものと言えます．結局，全画面使う派の僕にとっては有用な機能ではありませんでしたが．一方GNOMEでは，3のデスクトップ上からアイコンが消え去りました*3．デスクトップの機能をなくしてただの壁にしてしまう大胆な変更です．
そうしたOSS界のデスクトップの変化があった数年後にMicrosoftがデスクトップの将来的廃止を匂わせる変更をWindowsに施したのは驚きでした．スマートフォンやタブレット端末が普及する中，デスクトップがどうなっていくかが楽しみです（小並感）．
