emacsの思想
松山朋洋氏の「Emacsは死んだ」を読んだ。
UNIX界隈では、ソフトウェアの哲学が語られるころが多いし、ストールマン御大が開発者として名を連ねているEmacsも何らかの哲学や思想をもってしかるべきだ。しかし現在のEmacsの実装からは、パイプ入出力をほとんど持たない独立した環境を持ってしまっているぶん、いさいさか異形の存在である感がある。
このあたりの話はまつもとゆきひろ氏の記事が詳しい。
まつもとゆきひろのハッカーズライフ：第4回 Emacs対vi (2/2) - ITmedia エンタープライズ
歴史をひもとくと、Emacsは実はUnixの思想のもと生まれたものでなく、Lispの思想から生まれたものらしい。これは他のツールとの親和性があまりないEmacsの、かなり納得のいく説明だと思う。
すると、そういったUnix哲学の中にあるEmacsは、独立した「孤島」の存在であり、今後のバージョンアップの方向はより孤島になっていく事が、予想される。しかし松山氏は、やはりEmacsは外部プログラムに依存し発展すべきだと主張している。
要はSemanticで実現された価値がEmacsに閉じてしまい、社会的価値の増大が図れないのが問題になります。これは「Emacsの思想」に相反するものであり、Eclipseに至る危険な一歩を踏み出した証になります。
Lispのみで完結する環境はひいてはUnix文化への貢献度が下がることを意味する、という主張だ。
僕はWindows、OS-X、LinuxでそれぞれEmacsを用いている身である。その視点からすると、昨今のEmacsの「閉じた」肥大化は非常に歓迎するものがある。外部プログラムにたよるとなると、Windowsでの利用はほぼ絶望的なものになってしまう。なので、むしろ僕はLispで閉じたプラグインを好んで使っている。まさかこのような主張があるとは考えてもみなかった。
自分はEmacsの魅力は全く別のところにあると思っているし、ひとつにはマルチプラットフォームで用いることができるという点も軽んじられるべきではない。まつもと氏の言及するような、Unixの中のLisp思想として独自の進化をしてほしいと願っている。
nonoloop
Androidだと以下が利用可能だ。
nanoloop - Google Play の Android アプリ
だが、Androidだと、いきなり購入に踏み込まずとも、一旦無料で試す方法がある。Gameboyエミュレータを用いる方法だ。もともとnanoloopはGameboy用のシーケンサとして開発されたようだ。そのため、本家からGameboyのROMを入手し、Google Playより別途エミュレータを入手すればすぐに遊ぶことができる。
たとえば、Gameboyだと下記ページより「Demo ROM」をダウンロードすることが可能である
また、エミュレータはJohn GBC Liteを使っている。端末内から自動的にROMファイルを拾ってくれるため、ダウンロード先などを意識しなくても、使うことが出来る。
John GBC Lite - GBCエミュレータ - Google Play の Android アプリ
プレイ動画も数本見ることができる。これらを見る限り、やはりGameboy実機でのプレイはやはりガジェット感満載で、見てるだけでなかなかおもしろい。
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はプロセスのメモリリークを疑った場合に最初に見る値としては最も使いやすい。
