org-modeで日記やブログを書こう
org-modeってのがEmacsの機能にバインドされている。以前にも言及した。
はじめてのorg-mode - Meblog
あれからしばらく使い続けているが、やはりこの機能は素晴らしい。
org-modeはもともとはmark-downのような構造化文書だ。org-modeはEmacsの一つの機能として実装されている。非常に多くの機能を有し、例えば、todo管理にも使えるし、クロックイン、クロックアウトを利用して一日の作業内容を細かにログをとるのにも使える。site-mapの機能を使えば、インデックスつきの立派なブログになってしまう。しかも、当然構造化文書なので、Emacsで閲覧するときには、シンタックスハイライトの効いた、リーダブルなプレーンテキストで扱うことができる。
僕は常々日々の日記をorg-modeで書いている。で、オフラインでhtmlに吐き出して、org-publish-projectってやつでサイトマップを自動生成している。んで、cssで適当に見た目を整える。今のサイトマップの見た目は以下のスクリーンショットみたいになっている。
ただ、あまり日本では人気がないのか、使用例があまり見当たらなくって、elispの設定に苦労する。
と今まで思っていたのだけど、結構身近に使用例を発見した。
Wurly氏の個人ページ
Wurly's HOMEPAGE
Emacs for Windowsのバイナリを配布してくれる親切な人（と書くと誤解があるんだけど）。
なかなかのorg-modeっぷり。このサイトのかなりの部分がorg-modeで書かれている（画面下部postambleを見れば、org-modeによる生成だということがわかる）。
この人はブログと日記を別アプリで行っているようで、日々の日記をorg-modeで書いているようだ。Monotypeによるブログで、ある程度まとまった記事を書こうとしている傾向がつかめる。だが、org-modeのほうもまとまった記事量は多く、結果、あまりブログのほうは更新されていないよう..
こういう人のelispスクリプトは参考になる。僕はelispがかけないからね。。
http://cha.la.coocan.jp/doc/OrgMode.html:OrgMode | Wurly's HOMEPAGE
もちろんこのページ自体もorg-modeで書かれているわけで、非常にお手本になる。
あとはお手本といえば、こことか
Blogging using org-mode (and nothing else)
非常にelispの記述量が多くて参考になった。特に複数の系を扱っているのは、なかなか珍しい例だ。
そういえばるびきち氏のブログもorg-modeベースだった気がする。見た目は完全に何かのブログサービス使ってるんじゃないかと思ってたけど。
「org」タグの記事一覧 | るびきち「新生日刊Emacs」
githubにソースが公開されていて、検索が容易にできるようになっている。これを見ると、org-modeで書かれているのが一目瞭然だ。
GitHub - rubikitch/daily-emacs-jp
htmlに吐き出して、それをペタペタと貼り付けてるのかなあ。結構複雑なスクリプト書いてそうだ。
-
-
- -
-
自分もあまりに散文的な内容だとHatenaなどのブログサービスよりもorg-modeのほうが書きやすいと感じている。
以前もHatenaでより散文的な内容にしてみたいとさけんだこともあった。。
無題 - Meblog
ブログで見かけるのは、みんな割とかっちりした文書ばっかり。もしくは技術的なメモとか、そんなの（今はQiitaに書くのかな）。僕はそれよりも日記的な、もっと日々のログを残したいし、皆様も残せばいいと思うのだ。
でも、あまりブログサービスは散文的な内容に向いているとは思えない。
入力機能からしてHatenaをはじめとするブログサービスはそのWebのUIに文書作成機能も頼ってしまうことになるので、どうしても文書編集機能が貧弱になりがちだ。
また、最近のブログはテーマ重視の設計になっているのか、ナビゲーションのUXが日々の散文向けになっていない。一昔まえのブログって、そういう日記調の構造でも割りと見やすい設計になっていたと思うんだけど、最近あんまり流行らないのかね.. かといって、昔ながらのブログはあんまり垢抜けてなくって使う気が起こらない。
その点、org-modeなんかだと、自分で色々カスタマイズして、散文を書くことが出来る。スクリーンショットを見てもらえばわかるんだけど、ナビゲーションもこういうのが好みなのだ（Radium Softwareのアーカイブページとかね..）。体裁も気を使わず、ひたすらキーボードを打てばいいからっていうのもなかなかの強みだと思う。
今はローカルのみでひっそりと書いているorg-modeによる日記。しっかりスクリプティングすれば、インデクシングもしてるわけだし、僕もgithubなんかにもあげられると思う。でも、流石に上げるほどの内容でないわけで。妄想で終始しそうだなあ。
Unsupported major.minor なんとか
Android Studioにて、GitやらSubversionからimportしたときに
Cause com/anroid/build/gradle/AppPlugin Unsupported major.minor version 52.0
なんて出た時の対処メモ。
ReactiveCocoaでiOSのエンターキーが押されたことを検知する
前座
そして連続投稿。
iOSでエンターキーでフォーカス移すのって鬼門だなー、なんか簡単な方法ないかなーと探してた矢先見つけたもの。
Enterキーを検知する
以下コードで簡単にEnterキーを検知することができる。
ただ、これだけだと、バージョンによっては、なぜか期待動作とならない。画面遷移時にフォームにフォーカスがあたった状態になってしまうのだ。これを改善するのは以下。
Thank you, lukeredpath 氏
AndroidアプリからiOSアプリに移る君たちへ
前座
とある担当アプリがバージョンアップすることになった。自分はAndroid専門なんだけど、上司がやってきて、
「Androidアプリの設計がわかるなら、ｉPhoneアプリもわかるよね^^ じゃあ、次から担当ね！」
なんていうふうに言われ、まんまとiOSの担当になってしまった。
そんな同じような境遇に置かれた悲しき君たちへ贈る。
前提
今回はスクラッチではなく、バージョンアップ。
なので、過去の遺産がある。あるんだけど、残念ながらObjective-c。慣れてくれば悪い言語じゃないが、今更モチベーションの上がらない言語ではある。
Object-c自体は学生時代に少しいじった記憶があるんだけど、もうさすがに忘却してしまっている。まあ、それでも、OS-Xもいじったことのない周りの方々よりも幾分かマシなスタートが切れそう、っていう目論見もあったんだろう。
AndroidからiOSへ
せっかくAndroidの心得があるんだから、ある程度はショートカットしたい..
さすがに今から「はじめてのiPhoneアプリ」みたいなのをやる気はない、というより、間に合わない。
写経
とはいえ、やはり感覚をつかむための「何か」がほしい。
この目的でApple公式資料を用いて写経した。ところが最近はSwiftに移行し、Appleのドキュメントもそちらよりになってしまっている。そのため、少し古めの資料を使うしかなかった。土日を使って写経したが、やはり資料が古いところもあり、結構時間がかかった。それゆえ、全て写経はできなかったが、それでもかなり役に立ったと思う。特にX-Codeの使い方とか。
http:// https://developer.apple.com/jp/documentation/SecondiOSAppTutorial.pdf
Java → Objective-c
JavaからObjective-cに入るQiitaが何件かあった。正確なところはわからんのだけど、ノリを理解するには十分。こういうのが欲しかったんですよ。
visible true: Java脳でもわかるObjective-C入門
qiita.com
Reactive Cocoa
こうして、X-codeとObjectve-Cのノリをなんとか掴んだのだが、なんと要所要所にReactiveCocoaが使われている。これがなかなか理解を妨げる。
確かに非同期通信するには相当便利なんだけど、Objective-cがままならない時期のReacitiveCocoaは相当きついものがあった。参考資料以外にも色々読んだが、かなり参照したのが以下に示したもの。
qiita.com
以下の記事は公式の翻訳。うまく翻訳されている。
qiita.com
以下が公式のドキュメント。もうObjective-cはLegacyフォルダに入ってしまっている。
github.com
X-code
あと、おまけでX-Codeのショートカット集。X-codeって通常備えておくべき機能が微妙に隠されてたりして、わかりにくいんよね..インデントとかさあ..そのあたりを解決した。
Xcodeでショートカット覚えてないと効率低すぎ | iii ThreeTreesLight
おわりに
で、このプロジェクトはなんとか終焉を迎えた。ReactiveCocoaがReactiveなプログラミングでほとんどはじめてだったので、いい経験だった。Javaだと、こうは書けないよねっていう。
AndroidでもRxJavaが使われていたんだけど、通信部分は違うライブラリが使われてたりして、あんまり運用されていない様子だった。ボタンも全部インタフェースだったし。一方でiOSはボタンのイベントや通信部分まで至るところにReactiveCocoaが使われていた。ふうむ、親和性が高いのかねえ。
今回は、Androidアプリの対応をし、iOSアプリの対応をこの順で行った。上司はAndroidユーザなので、iOSアプリには興味を示さなかったというオチ..
VSS RSS PSS USS の説明
android - Is this explanation about VSS/RSS/PSS/USS accurately? - Stack Overflow
StackOverFlowより
Androidのメモリ消費量を調査したいとき、毎回困るのが、このvss,rss,pss,ussの概念だ。Linuxにおいては一般的な概念らしいんだけど、Linux開発なんて通らずにAndroid開発にいったものだから、この概念については全くの門外漢だった。
メモリ調査
メモリ調査に関して、軽く触れておく。
参考
まずは公式サイト
Investigating Your RAM Usage | Android Developers
日本語だとatmarkITが詳しい
Androidで動く携帯Javaアプリ作成入門（49）：Android 4.4のメモリ使用状況を把握する3つのツールの使い方 (1/2) - ＠IT
ルートをとってやると、procrankなんかを使うこともある
Android Memory Usage - eLinux.org
VSS RSS PSS USS の説明
で、掲題の話題。
PSSが何なのか、を知るためには結局他のRSSやUSSなどの算出方法を知っておく必要がある。件の記事では、それを非常にうまく説明してくれていた。
以下に訳をおいておく。
-
- -
Androidのprocrankと呼ばれるツールがある。これはLinuxのプロセスのメモリ使用量を多いものから順に出力してくれる。メモリ使用量はVSS, RSS, PSS, USSの値をプロセス毎ごとに出力する。
ここでは簡単のために、Byteではなく、「ページ」という単位を使うことにする。LowレベルのLinuxのシステムでは4096Byteを単位とするページがよく用いられる。
VSS（psコマンドではVSZと表現される）はプロセスがアクセスできるアドレスの総和である。このサイズはプロセスがまだ使用していない領域もふくむ。例えばmallocされて割り当てられたものの、まだ書き込まれていないようなメモリだ。したがって、VSSはプロセスの実メモリの使用量としては、あまり使われることはない。
RSSはプロセスが実際に使用しているRAMの総メモリ量である。RSSは誤解を招くことがある。RSSはプロセスが使用しているものと、共有ライブラリが使用しているものを合計し算出するからだ。共有ライブラリは、それを使用するプロセス数とは関係なく、一度しか読み込まれないのにもかかわらず、だ。RSSはある単一のプロセスのメモリ使用量としては正しい表現とはいえないだろう。
PSSは共有ライブラリを適切なサイズに分割し算出する点がRSSと異なっている。例えば、3つのプロセスがある30ページのメモリをもつ共有ライブラリを用いている場合、各プロセスのPSSには、10ページの使用量として計算される。PSSはとても扱いやすい数値だ。システム中の全てのプロセスのPSSを足しあわせた場合、それは実際のシステム中のメモリ使用量に相当するからだ。あるプロセスをキルした場合、各PSSに当分して計算されている共有ライブラリは、依然としてライブラリを用いている他の残っているプロセスの等分に分配される。この場合、PSSはわずかに誤解をまねく。プロセスをキルした場合にシステムに戻るメモリ量としてはPSSは正しい指標ではなくなってしまうからだ。
USSはプロセスに完全に一意であるようなプライベートなメモリ使用量である。USSは動作中のプロセスが使っている真のコストを表しているため、かなり使いやすい数値である。プロセスがキルされた場合、USSで表されたメモリ量はシステムに還元される。そのため、USSはプロセスのメモリリークを疑った場合に最初に見る値としては最も使いやすい。
風立ちぬ
「風立ちぬ」が好きで何度か鑑賞している。
色々なところで色々な風に言われている「風立ちぬ」だが、僕がこの作品を好きな理由は、堀越二郎のエンジニアとしての美しさだ。
-
- -
この作品は宮﨑駿が引退すると宣言したものであってか、公開前から相当盛り上がっていた記憶がある。特に、試写中に宮﨑駿氏が涙ぐむ場面もあり、感動作という印象もあるのだけど、涙もろい僕だが特に感涙はしなかった。
僕がこの映画を好きなのは、儚い結核文学であるからではなく、メロウなラブストーリーであるからでもない。単にものづくりに携わっている人がもつクリエイティビティへの畏敬の念が、この作品にはこもっているからだと思う。
-
- -
要するに作中の堀越二郎に自分を重ね合わせているんだと思う（非常に恥ずかしい話だが！）。
モノを作っていくエンジニアリングってのは、クリエイティビティを伴う行為だ。彼はエンジニアとしてのクリエイティビティを具現化した存在だ。それゆえ、二郎は”呪われた夢”である美しい飛行機を夢見て、あまつさえ作ろうと奮闘している。
「エンジニア」というと、どうも泥臭いイメージがつきまとう職業なのだけど、実のところ、技術的な視点に立脚し、意見を出さないといけない場面も往々にしてある。自分としては、この想像的な面こそエンジニアの本質であると考えている。二郎の存在は、エンジニアの泥臭い面を隠蔽し、創造的な面のみを押し出した存在としても見ることができる。
自分もエンジニアの端くれとしていくばくか創造的な仕事を求められることがある。しかし、それは泥臭い面を持ったエンジニアだ。理想的であるとは言いがたい。
この映画を見ると、ある意味で最高潮を迎えようとしている航空技術に、創造力で打ち克とうとする二郎の姿から、やはり純粋なエンジニアはかくあるべき、という理想像を夢見ることができるのだ。
-
- -
ところで、興味深いのは、同僚である本庄の言葉だ。
現在の日本は技術立国とも揶揄され、技術力の高さでは世界を席巻しているとも言われている。しかし、個人的には、その技術には国際的な競争力が欠けているように思う。流れの早い分野では依然として世界についていけていないセンスや技術があるように思う。
特にソフトウェアの分野では、日本の実情に合わせたガラパゴス化が顕著である、と肌感覚であるが、思うことがある。本庄の作中の言葉で引用すると次のような感じか。
俺達がExcelで管理しているバグを、やつらはAsanaで管理している。
俺達は10年は遅れているんだ。
恐るべき後進性だよ。
Androidアプリにおけるプライバシー
App privacy controls still missing from Android 5 / Lollipop There is a lot of…
Androidアプリをダウンロードするとき、必ずその権限についてきかれる。
実装としてはAndroidManifest.xmlにuses-permissionでアプリに権限を与えているんだけど、この内容の確認はGoogle Playからダウンロードするときのポップアップによって行われる。ユーザに注意喚起するためだ。セキュリティ上のリスク回避手段だと考えられる。
しかし、これには色々まずい問題を含んでいる。
まず、UI上の問題が挙げられる。ユーザによるポップアップの内容の無視だ。これはどのアプリで言われていることだが、どんな重大な警告であろうと、あまりに何回も出るとユーザは慣れてしまうのだ。とりあえずどんな問に対しても'はい'を押してしまうように学習し、内容を熟読しなくなる。
件のポップアップは毎ダウンロード時に出現する。これではユーザはいちいちポップアップを確認はしないだろう。
2つ目には、警告を理解しても、取るべき手段が非常に限られているということだ。使用したいアプリであっても、セキュリティ上の問題があれば、全機能がつかえなくなってしまう。これは上記記事でも触れられている。
インストールしたアプリの全ての機能が動くわけではないが、自分でリスクを細かくコントロールするか、現在の「全てを受け入れ、インストールする」か「インストールしない」の完全なクロとシロの選択肢しかないか。
例えば、電話帳アプリがあったとしよう。素晴らしいUI・UXを持ち、検索機能もシンプルで使いやすい。デザインもクールで申し分ない。ただ、クラウドに自動同期してしまう。そして、この機能が好ましくなかったとする。これはもちろん、この機能自体をoffにすることはできるだろう。しかし、ポップアップの’はい’をクリックし、ダウンロードすると、クラウドとの同期がはじまってしまう可能性がある。一部の好ましくないと思っている機能のために、ダウンロード自体を諦めなければならないのだ。
アプリのパーミッションの粒度を（多少煩雑になるのは覚悟の上）細かくすれば、これはすこしマシになると考えるかもしれない。しかし、警告だけではどんなリスクをはらんでいるのか十分に予想できない問題は残る。事前にリスクの具体的内容がわからないのだ。電話帳の例だと、「電話帳へのアクセス」と「インターネットへの接続」権限が求められた場合、これがクラウドとの同期のことを指しているのか、アプリベンダーのサーバーに送信することを指すのか、はたまた勝手に全世界の人間の連絡先がダウンロードされるのか、見当がつかない。
やはり使用の際に、どのようなアクセスがなされているかを知り、コントロールすることが必要に思われる。
これに対し、googleは「App Ops」*1なるツールをかつてAndroidプリインの機能として提供していた。この機能はアプリごとに権限をコントロールできるツールだ。しかし、現在このアプリは提供されておらず、Android5.0の現在も復活の兆しがない。
どうもGoogleはこういったプライバシーの問題にあまり積極的でないように思える。おそらく彼らのビジネスモデルがまさに「個人プライバシーを売る」行為だからなのだろう。Gmailの内容だって実はコンピュータによって解析がされている*2。
我々のプライバシーを売ることにより、たくさんの金をかせげる方法がある。それこそが、あなたのプライバシーを侵すアプリ開発者のビジネスモデルだ。
