EmacsでSMTPの設定を変更をする
メールアカウントのパスワードを変更したんだけど、EmacsのSMTPの設定の方法がわからずうなってた。IMAP側はmu4e使ってるから、すぐわかったんだけどね。。SMTPはinit.elみてもパスワードの設定なんて書いてなかった。
ここには、設定するときにプロンプトが出ますよ、ってなことが書いてあったが、一度設定してしまうともう出てこないので、うーん、と悩んでいた。ちゃんと読むと、
$(HOME)/.authinfo or $(HOME)/.authinfo.gpg
に設定ファイルが書き込まれている、とのことだったので、ここを参照して変更したら、解決。
-
- -
最近Emacsの話ばっかり書いてるな。ちょっとでも仕事の話が絡むと記事にできないんだけど、Emacsはその点直接は関係ないから、書きやすいのだ。
バグ
Hacker Newsみてたらこんな記事が。
The Mark I Computer at Harvard
昔、「バグっていうのは、機械が動かなくなったときに原因を調べたら、虫がはさまってたっていう話が起源なんだよ」ってのを聞いた気がしていて、それをなんとなく信じていた。でも、この記事読む限り、それ以前から電気機械の故障を「バグ」って呼んでたみたい。
そうすると、逆にその「バグ」は一体何由来のものか気になるが..
こういう黎明期のコンピュータは何かそそられるものがあるねえ。当時の最先端の技術が垣間見れるからなんだけど、実際にリレー式のコンピュータがガチャガチャと音を立てて動く様は感動するものがある。動作としては一個一個のからくりはわかるんだけど、それで計算結果が出力される不思議といったら。
今のCPUは完全にブラックボックス化されているから、それを感じることすらなかなかないんだな。
Windows8にVMWare PlayerつっこんでCentOS 7.2 を入れた話
掲題のとおりなんだけど、うまくいかなくて、無理やり解決させたので、メモ
前座
VMWare Workstation Playerなるものがあって、これをWindows8につっこんで、Cent OS 7.2を入れようとした。んで、割りと途中まではうまくいっていて、Windows側からVMにディレクトリ共有して、マウントしようと思ったら、ハマった。なぜか解決策がなかなか出なかった、
エラー詳細
ディレクトリを共有させるんだけど、要はvmware-install.plを動作させる。以下がまとまっていて、わかりやすい。
VM上のCentOSとホストOS(Windows7)とでファイル共有したメモ - MofuMofuFarm
色々むにゃむにゃ動くんだけど、ここで以下エラー。
/tmp/modconfig-CXZXGV/vmhgfs-only/page.c:1649:23: エラー: 関数 ‘wait_on_bit’ への引数が多すぎます
TASK_UNINTERRUPTIBLE);
^
In file included from include/linux/mmzone.h:9:0,
from include/linux/gfp.h:5,
from include/linux/mm.h:9,
from include/linux/pagemap.h:7,
from /tmp/modconfig-CXZXGV/vmhgfs-only/page.c:28:
include/linux/wait.h:1044:1: 備考: ここで宣言されています
wait_on_bit(void *word, int bit, unsigned mode)
^
make[2]: *** [/tmp/modconfig-CXZXGV/vmhgfs-only/page.o] エラー 1なんかライブラリの生成に失敗しているようだ。
同様のエラーは以下記事でも報告されている。
CentOS 7.3 & VMware Tools でファイル共有機能の不具合 « minor tranquilizer
解決
で、自分は上記記事でなくて、こちらを参考にした。
CentOS 7 安装 vmware-tools-懂客-dongcoder.com
中国語なので、超訳（原文は何言っているかわからないが、試行錯誤した結果）。
ソースを取得する。
以下を解凍する。
vmware-tools-distrib/lib/modules/source/vmhgfs.tar
すると、vmhgfs-onlyを入手できる。
ソース修正
vmhgfs-only/page.cの1639行付近を以下のように修正
- #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 19, 0) + #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 10, 0)
保存しておく。
もとの場所にもどす。
vmhgfs-onlyをvmhgfs.tarに固め（ファイル名に注意）、lib/modules/source/vmhgfs.tarに上書きする。
あとがき
普段Windowsに寄生するタイプの仮想環境なんて使わないから、ビビりながら使ってたが、こんなところでハマるとは。。あんまり日本語の情報でてこないってことはVMware自体のユーザが少ないってことなのかなあ。みんなVirtualBoxにうつったのか、もしくはクラウドなんかをホームコンピューティングの目的で借りちゃったりしてるのかもしれないな。
Team Geakを読んだ。
Team Geek - Googleのエンジニアたちはいかにしてチームを作るのか
を読んだ。
内容をざっと把握するなら、以下の投稿参照。客観的にうまくまとまっている。
『Team Geek ―Googleのギークたちはいかにしてチームを作るのか』まとめ - Qiita
この本で一貫して主張されているのは、謙虚、尊敬、信頼のHRTを重んじろということだった。というと、かなり当たり前にように聞こえるが（実際当たり前でもあるが）、この本の根底には、昨今の規模の開発では個人プレイをあまり重視を重視すべきでないということがあるように感じる。
冒頭にある天才の神話が興味深く、ドキリとするエンジニアは多いのではないだろうか。
最高のギークファンタジーがあればこんな感じだ。最初に素晴らしいコンセプトを思いつく。そして、バットケイブに数週間～数か月こもり、アイデアを完ぺきな形で実装する。それから、そのソフトウェアを「大放出」する。誰もが君の天才っぷりに衝撃を受ける。同僚たちは君の頭のよさに感服する。誰もが君のソフトウェアを使うようになる。自然と富と名声が集まってくる。
これはエンジニアを目指す人間なら、あてはまる願望ではないかと思う。幼少からコンピュータや勉強が好きな子どもたちというのは、得てして人とのコミュニケーションが苦手であったり、軽視しがちだったりするものだ。また、自尊心が高い傾向があるかもしれない。そういった人たちにとっては、個人プレイによって得ることのできる富や名声は非常に抑えがたい衝動だ。
自分の好きなようにやればいいじゃん。そう思っているかもしれない。
それが違うんだ。ここでは君が間違っている。その間違いこそが大きな問題だ。
オープンコミュニティであれ、企業内の仕事であれ、ソフトウェアエンジニアリングにコミュニケーションやコラボレーションが必須であるのはもはや歴然たる事実である。世にでている「プロジェクトマネジメント」や「ソフトウェアエンジニアリング」と名のつく教科書は、だいたい人同士のコミュニケーションをどう定量的に扱うかについての議論に多くの紙面を割いている。ソフトウェア開発における最大の課題はコミュニケーションそのものなのだ。
多くの天才をかかえるGoogleがそのような考えを持っていることに多少の驚きを感じつつ、また共感を覚えた本だった。
- -
ところで、最近こういったチーム運用の本を読むと、採用の話が頻繁に出てくる。いかに能力が高い人材を確保するかに多くの紙面を割いているし、この本でも同じ文化をもつ人材をどう採用するかの記述があった。新卒一括採用をしている企業ではあまり馴染みはなく、採用した集団の中央値がより大きくなるよう、また、最小値がある一定以下にならないように採用しているように思う。これは、採用後に配属をきめるという風習に起因していると考えられる。どこへ配属しても文句の出ない人材を採用する必要があるためだ。極端にコミュニケーション能力を欠いていてもだめだし、極端に礼儀がなっていなくても不採用だ。すべてが平均か、それ以上であればいい。逆に、例えば数理モデルに相当精通していて、たとえ担当部署がそれを必要としていても、あまり魅力的ではない。
Googleの採用方法は当初は奇抜さにフォーカスがあたっており、当時としてはその過剰ともいえる福利厚生や労働環境の厚遇が注目されていた。しかし、最近日
本であっても、スタートアップ等では、エンジニアは財産と考え、出来る限り厚遇するという企業はもはや珍しくなくなっている。
一方日本古来の企業や多重請負い構造をとる企業は、内部のエンジニアは人月をとるための人材でしかない。現場で日々強く感じることだが、彼らはプログラマというより、もはやコーダに近いのではないかとおもう。
彼らの技術力の高さというのは生産性が高いということなのであるが、これは、単に行数が多くかけるということであったりする。一見すると悪くないし、取引先や上司にも定量的に説明しやすい。だが、本当に優秀なコードというものは行数は少ないものになるはずだし、もはや行数ではなにも語れないであろう。一時間に多くの行数
がかけるからといって、必ずしも生産性が高いとはいいがたいし、ましてや技術力の高さを測るバロメータとしては明らかに不適切であろう。
採用の話では、採用後の教育のコストなどを考えた場合に、優秀な人材を逃すより、下手な人材を誤って入社させたほうがコストが大きく、リスクになるということが議論される。似たような話はJoel on Software日本語版記事でもあった。一旦採用した人材を教育し解雇するとなると非常にコストが高くつくためだ。日本の社会構造だと、更に解雇しづらい環境になるわけで、すると、より現場にあった人材を厳しく試験したうえで入社させるべきなんでないかと思った。
Windows 7でVPNを接続すると、Emacsが遅くなる
背景
出張中、VPNで社内LANに繋いで作業していると、WindowsのEmacsが非常に低速になってしまった。VPNを有効にした途端、やたら重くなってしまうのだ。とくにdiredやファイル読み出し、書き込みなど、ファイルI/O関連で遅くなってしまっているように思える。よくある問題だと思うんだけど、何故か日本語解説が全く出なかったのでメモ。
（特に外に出て行くSEなんかは、WindowsでVPN使ってるなんてよくある状況に思えるんだけど、なんでほとんど情報が出なかったのか、不思議だ。。）
調査
StackOverFlowでは、以下が有効そうに思えた。
windows - Emacs creates buffers very slowly - Stack Overflow
ので、以下試した結果。
解決法
recentf-auto-cleanup
(setq recentf-auto-cleanup 'never)
を init.elもしくは .emacsに書き込んで 、eval-buffer。が、パフォーマンス改善せず。
w32-get-true-file-attributes
(setq w32-get-true-file-attributes nil)
を評価。すると、パフォーマンスがもとにもどって、これでヨシ。
コレは何か
GNU Emacs Manual: Windows Files
ここに解説があるように、Windowsのファイルシステムに対して、権限の制御などをうまくやってくれる設定のようだ。これを有効にしておくと、理由はわからないけど、VPNでのパフォーマンスに問題が出るようだ。これにnilを設定した場合、上記の制御がきかないので、UNIXとDOSのファイルシステム差分をうまく制御できなくなるはずなんだけど。。ido-modeやdiredはきちんと動いているように見えた。逆にこれを設定するメリットがわからないほどなんだけど、僕は基本内勤で、VPNは頻繁には使わないので、VPN使うときだけ手動でOFFに設定にするようにしよう。
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実機でのプレイはやはりガジェット感満載で、見てるだけでなかなかおもしろい。
