org-mode で画面キャプチャをペタッとはりつける。
org-modeで画像貼り付けたい
org-mode使っていて、Evernoteなんかと比べたときに圧倒的に不便だな、と感じるのは、画像を取り扱っているときだ。さっくりメモをとったり、文章を構造化したりするときなんかには非常に役に立つのだが、何かの画像を切り貼りしたいときには、いちいち画像をimg配下なんかに保存して、そのパスを記述する、なんて面倒なことをしなければならない。
どうせ同じことで悩んでいる人がいるんだろうな、と思ってサーチしてみると、あっという間に見つかった。PCの画面キャプチャをorg-modeの画面にペタッと貼ってくれるelispだ。名前はそのままorg-attach-screenshot。
レポジトリ名はorg-screenshotだが、MELPAではorg-attach-screenshotで引き当てることができる。
M-x org-attach-screenshot で、適当にEnterを押下してると、Emacsがバックグラウンドになり、カーソルが十字になる。んで、範囲選択してキャプチャをとることができる。画像はデフォルトだと、編集中のorgファイルの下にdataフォルダが作成され、こんなかに入る仕組み。
これはこれで十分なんだけど、以下の点に不満が残った。
- HTML出力するときに、画像がサムネイル化されない
- Mac (OS-X)だと、imagemagickよりscreencaptureのほうがよさそう
改造
結論から言うと、ちょっと改造した。
差分は以下。
add thumbnail feature and adopt os-x. · medaka/org-screenshot@98ecee8 · GitHub
これで、HTML出力してみると、以下のような感じになる。
これだと普通だな。。オリジナルはサムネイル化されないんで、大きなキャプチャとると、全部はみでちゃうんよね。。
詳細
まあ、サムネイルに関してはいいでしょう。単に画像縮小してリンクはっただけ。
screencaputureに関して。オリジナルはimagemagickのimportっていうコマンドを用いてスクリーンをキャプチャするみたいなんだけど、同等の機能がOS-Xにはデフォルトでscreencaptureってのが入っている。importってのがサクっと動かなかったのと、screencaptureのほうがいちいちimagemagickを使わなくてすむということから、こちらに換装。
アジャイルとハイプ
全体の工程にウォーターフォールモデルを採用しているプロジェクトも未だ多いと思う。
こういったプロジェクトでは、設計・製造工程（プログラミング工程のこと）のあと、何段階かの試験工程がある。試験工程ではブラックボックステストを多分に含み、要望元のユーザテストのようなものも含む。そうすると、当然基本的な設計に関わるような不満も噴出する。こういった機能がほしいだの、ボタンはこういう配置がいいだの、そういう要望だ。
こういった意見はくだらないものもあるが、なかには耳が痛いものも多い。当然対応すべきだった事を指摘されることもあり、エンジニアとしては是非対応したいところだ。しかし、試験工程に移った段階で開発要員は絞られており、残ったリソースで修正するのは容易ではない。そもそもウォーターフォールの概念から言うと、禁じ手でもある。なぜなら、ウォーターフォールにおける各工程の終了とは、その段階での完璧な品質の担保を意味しているため、要望による修正は、全ての工程をやりなおしを意味するからだ。幾度となく言われていることであるが、これがウォーターフォールの最大の欠点である。
すると当然、アジャイルを導入するか、という話が持ち上がってくる。
simplearchitect.hatenablog.com
アジャイルであれば、途中の要件変更に強くなるはずだ、という目論見である。アジャイル自体もう新しい技術でなくなっているし、コンサバティブな職場でも幾度となく検討されていることだろう。しかしこれも何度となく挫折を味わうことになる。最近携わったアジャイル開発も例外ではなかった。この失敗は、人員の問題や企業風土の問題も確かに少なからずある。しかし、今回言及したいのは、それ以外の部分、「ハイプ」だ。
-
-
-
- -
-
-
ウォータフォールでは全ての機能を完全な仕様書におとしこみ、それを開発が順次実装していく。仕様書は開発工程開始時点では完璧であるはずなので、これをどれだけ忠実に実装していくかが問われるわけだ。しかしひとたびこれを「アジャイル」にしてみると、企画からしてみると、開発開始時点で仕様書は完成してなくてもよい、という解釈になる。企画からの要望はずるずると開発終盤まで変更される。開発終了時には、ぎりぎりまで要望変更の対応に追われるため、なんとか動くものはできる。しかし、品質も中途半端、工数も大きく膨らんでしまう。
企画が開発完了した製品を実際にテストする。すると、思った以上に齟齬が多いことにおどろく。齟齬を紐解こうと思っても開発途中には様々なバージョンの要求仕様書があり、どれが結論かも全く判然としないのだ（非エンジニアはいまだにバージョン管理には相当疎いことに留意しなければならない）。本来、いかなる開発においても、企画と開発が一体になっていない場合、ドキュメントは残すべきである。しかし、「アジャイル」という言葉を導入した途端、多大なコミュニケーションにより仕様を担保できると考えてしまい、完成したドキュメントはなくなってしまう。
簡単にいうならば
「なぜドキュメンテーションしなかったの？」 「アジャイル開発だったからです」
ということになる。アジャイルに過度に期待をよせてしまった「ハイプ」だ。
このハイプは、昨今の開発で、多く見られる現象のひとつのように感じる。例えばAIにしても中身や特徴、処理方法は別にして、とにかく「データ処理をうまくやってくれるもの」、VMは「サーバ上の処理をうまくやっていくれるもの」、先程のアジャイル開発はとにかく「開発工程をうまくやってくれるもの」、といった様にだ。ここでの教訓は肝心なのはハイプであるのは開発だけでなく、企画を始めとする間接部門にとってもハイプだということだ。開発には銀の弾などないということは、プロフェッショナルにとっては常識になっている。どれだけ便利な手法でもプラクティスを誤れば、全くうまくいかないアンチパターンになるリスクを孕んでいる。特に昨今の手法はこれさえやっておけばうまくいく、といった簡単なものではなくなっている。自分たちの状況に合わせたプラクティスの選択・構築が何より重大な命題になっていくだろう。この問題は、非エンジニアに説明するのは相当難しい。例えばアジャイルにとっても開発時のステークホルダーのスコープはどれだけか、開発規模はどの程度か、どの仕様が最低限必要なのか（これが一番むずかしい。少ない機能を実装しようとすると普通の人はサボっているとか生産性が低いなどと思ってしまうだろう）、などなど、様々なパラメータがあるが、これらが開発に影響にどのように影響するか。おそらく完全に理解してもらうのは不可能だろう。
-
-
-
- -
-
-
そんなわけで、僕の周りのアジャイルだとかAIとかのバズワードの信頼度は下がるばかりだ。実際にはそれら自体ではなく、その言葉を誤用している僕らやステークホルダーが悪いのだけども。こういったことで時代の潮流に遅れないようにしたいと願うばかりだ。
ソフトウェアとビジネスの狭間
Hackernewsみてたらこんな記事が。
ソフトウェア書きとしては気持ちのいい話だ。特にこのご時世、JASRACの話とも相まって、相乗効果的にその印象が強まってくる。
-
- -
まあ、音楽面の話はさておき、ソフトウェアを書くことの価値とはなんだろうかと思うことがある。実際会社でソフトウェアは書いているけれども、それを責任もって事業化し、売上げてくれるのは別の部署の人たちだ。我々開発者がそのソフトウェアについての価値について直接考える機会はほとんど失われてしまっている。逆に我々に求められているのは品質やコスト、納期であり、いかにバグのないソフトを安く早く作るかということに主眼をおいている。それはそれで開発に集中できるのでいいのだけれど、ときには俯瞰して考えたい。
そもそもソフトウェアの価値とはなんだろうか。
古来、というより、欧米でよく言われる「ドットコムバブル」の時代、あるいはさらにその前時代、ソフトウェアの価値は複製の容易性にあった。一度ソフトウェアを書いてしまえば、ほとんどコストの無視できるメディア代だけで価値を増幅することができたのだ。それまで存在いたあらゆる製品は、生産に大規模な設備を要し、流通経路を確保し、顧客に届けなければならなかった。これがソフトウェアではほとんど無視することができたのだ。
さらに現代、更にその仕組は強化され、ほとんど物理的な物流に依存することなく、ソフトウェアの価値を顧客に提供することが出来るようになった。顧客にはプラットフォームとなるハードウェアすら準備する必要がなくなったのだ。そのため、顧客はほとんど設備投資する必要なく、ソフトウェアを手に入れることができるようになった。
しかし、おそらくソフトウェアを開発する総コストは根本的に変わってないというところに注目しなければならない。
あらゆる技術の革新でより早く高機能なものを顧客に提供できるようにはなってきている。しかしそこに投入するエンジニアのリソースは変わっていないように思える。顧客の要望も技術的革新に追従し、ハイレベルなものになってきているためだ。結果として、ソフトウェアをビジネス化するには、より少ない生産量で、より多くの顧客をかかえることが重要度を増すようになってきたのだ。
ここで僕は自分を振り返りたい。自分は開発としてこのソフトウェアの優位性を理解し、仕事をしているだろうか。誰か特定の顧客のためだけに愚直に価値を提供してやいないだろうか。
- -
上記記事では、ほとんどの定形業務を自動化することにより極端に少ない人数での業務のオペレーションに成功している。言葉でいえば単純だが、自動化はソフトウェアの得意とする一分野であり、さらにそれをうまくスケールするところまで成功している。また、他のサービスと異なるのは、これが既存産業をおびやかしにかかっているところだ。強力な既得権を置き換えにかかるその様は、きっと開発者本人も予想しなかったことだろう。
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日本語版記事でもあった。一旦採用した人材を教育し解雇するとなると非常にコストが高くつくためだ。日本の社会構造だと、更に解雇しづらい環境になるわけで、すると、より現場にあった人材を厳しく試験したうえで入社させるべきなんでないかと思った。
