AMAgrammar <> PROgrammer

Linuxで定期的にプログラムを動かす時にはcronと呼ばれる仕組みを使う。また、デスクトップ上に通知バルーンを出すには`notify-send`というコマンドが使える。これらを組み合わせれば、画面上に定期的に通知を出せる筈だ。

ところが、コレがなかなか上手く行かない。 `crontab -e` で直接`notify-send`を指定しても、`notify-send`を呼び出すシェルスクリプトを指定してもダメ。調べてみると、単純に`notify-send`を使うだけではダメなようだ。cronで呼び出されるプログラムは、古き良きCUIプログラムである事が前提で云々。

ググると何通りかの回避策が出てくる。が、試した幾つかは上手く行かなかった。もしかしたら同じように悩んでいる人が居るかもしれないし、以下に纏める。

何時の間にか、この季節になってしまった。とりあえず気になる Advent Calendar のリストアップ。

大量にリストアップしているが、全てのcalendarの全ての記事を読むつもりという訳ではなく、とりあえずフィードリーダーに突っ込んでおいて、琴線に触れるタイトルの記事のみを読んでいく予定。

本当は、何処かの奴に参加したい所だが、仕事がクソみたいな忙しさの所為で執筆時間取れないので、参加は出来なそう……

自宅PCにはOS(ディストリビューション)としてLinux (Fedora 22) を入れている。Linuxはそれを構成する各種ソフトウェアの独立性が高く、WM――ウィンドウマネージャ。GUI環境下で表示しているウィンドウの管理を行う――も入れ替えることが出来る。

今回、Awesomeというタイル型WMを導入してみた。「タイル型WM」とは、各ウィンドウを画面上にタイル状に敷き詰めて表示するタイプのWMだ。 Windows 8 (或いは Windows 10 のタブレットモード)で画面上に複数のモダンアプリを表示した時のような表示方法で、原則、ウィンドウ同士が重なる事がない。なお、 Windows 10 や、それ以前のデスクトップアプリでのウィンドウ表示の方式は「スタック型WM」とか「コンポジット型WM」という。

タイル型WMの良い所は、まさに「ウィンドウ同士が重なる事がない」という点に尽きる。考えてみれば、同時に使いたいソフトだから同時に起動している訳で、それぞれのウィンドウを並べるのは道理であるように思える。メーラーのような例外は、別の仮想デスクトップに配置しておけば問題ない。むしろ、自然と役割毎に仮想デスクトップを使い分ける癖がついて好都合とも言える。大体のタイル型WMはキーボードショートカットが充実しているのも、実に素晴らしい。

AwesomeはLuaというプログラミング言語で設定をカスタマイズ出来る。設定ファイルを0から作る事も出来るが、/etc/xdg/awesome/rc.luaに在るサンプルに手を加える事にした。というか、Luaを勉強した事がないので、サンプルが無いと何も出来ない。今の所の私の設定ファイルはこれ。サンプルはデフォルトの挙動を再現するコードで構成されているようなので、それらを削ればもっと短くなるだろう。

参考にしたページは以下の通り。

• awesome wm のミュートスクリプト改善(ヘッドホン&beep 対応等) | matoken's meme

  ただし、手元の環境だとアイコンファイルのパスが異なっていたり、ミュート解除時に-cオブションを付けると上手くいかなかったりしたので、その部分は変えている。

• PulseAudio/トラブルシューティング - ArchWiki
• Freedesktop autostart way (Autostart - awesome)
• Ubuntu - 【備忘録】タイル型ウィンドウマネージャawesomeの設定 - Qiita
  • キーボードショートカットについて
  • ウィンドウの配置ルール

現状、かなり満足している。不満点は、キーボード操作のウェイトが増した結果ファイラであるnautilusの使い勝手が悪くなった事、GnomeのActivityのようなGUIソフトを選んで実行する仕組みが無い事ぐらいか。前者は代替品を探すとして、後者はどうしたものかなぁ。

しかし、もうちょっと名前は何とかならなかったものか。検索しにくいぞ。

最近、お仕事でNode.jsを使っている。Node.jsは、いろいろな処理が非同期処理を前提とした作りとなっており、「ある処理を行った後にする処理」を、「ある処理」を行う関数のコールバック関数として書く必要がある。例えば、ファイルに何か書く場合は、こう。

require('fs');  // ファイルのIOを行うfsモジュール読み込み。

fs.readFile('foo.txt', 'utf8', function(error, data) {
	// エラーの場合は、コールバックの第1引数にエラーを表すオブジェクトが入る
	if(error) {
		console.log("error!");
		return;
	}
	console.log(data);  // ファイルの内容
});

わお! ファイルを読むだけで1つコールバック関数が出てきた。

例に挙げたような単純な物ならば特に問題にはならないだろうが、大体のプログラムは、こんなに簡単ではない。ファイルを読んで、DBのAとBとCテーブル読んで、それらでゴニョゴニョした結果を別のファイルに書き込んで、そんな処理が2つも3つも在って……とやっていくと、出来上がるのは深い深ーいコールバック関数の「谷」である。人はコレを「コールバック地獄」と呼ぶとか呼ばないとか。

コレは拙いよね、どうにかしないとね。という訳で使われるのが、async.jsというライブラリ。というか、その中のwaterfallやseriesか。

この内、waterfall関数の効果的な使い方が、イマイチよく分からない。

いま関わっている仕事でC#を使ってる。この案件で初めてマトモにC#触って、割と言語の勉強と業務を並行してやってた。今度この案件から離れる事になったので、とりあえずC#の所感を書いておこうと思う。開発環境が Visual Studio 2008 だから、 C# 3.0 かな。去年の9月からだから、9ヶ月くらいの経験という事になるか。もっとも、その期間の半分以上は、何故か Visual Basic 6 を触ってた気がするが。

パーシャルクラス

C#の言語仕様として一番興味を惹かれたのがパーシャルクラス。これは、1つのクラスの定義を複数のファイルに分散できる仕組み。VSのGUIデザイナが吐いたコードと、それで定義した各種GUIコンポーネントのイベントのコードを分離させる為に使われていたり、明らかにツールが自動生成したコードとユーザーが手で書くコードを分離する為の機能。言語仕様にツール連携の仕組みを入れるとか、IDE作ってる所らしいアイディアだと思う。

変数に対する「読み取り属性」の貧弱さ

個人的には、C#最大の欠点だと思う。ローカル変数とメソッドの引数に対して「読み取り専用属性」が付けられない。ので、少数の行数のコードを適切にメソッド分け出来る技量が無いと、アッという間に魔窟のようなコードが誕生する。チーム全員がそのレベルに達していれば良いんだけれど、残念な事に現実はそうとは限らない訳で。メソッドの引数は基本的に参照渡し(という言葉は正確でない気がするが)なので、ある変数の内容がメソッドの呼び出し前後で同じである事が保証されない。そのメソッドの役割的に不変の筈だと思えても、そうでないかもしれない。不具合対応の時に気をつけるべきコードが増えて閉口した。

もっとも、これはC#開発コミュニティも問題だと認識しているようなので、将来は解決されるんじゃないかなとは思う。

usingステートメント

usingで宣言したオブジェクトは、そのスコープを抜けた時に、オブジェクトが管理しているリソースが破棄される。詳しくはMSDNを参照。

いや、分かる。そういう仕組みが必要な理由は分かる。でもガベコレ積んだ言語でこの仕様は正直キモイ。というか、ある型(の、オブジェクト)に対して、それがusingが必要か、そうでないか気をつける必要が在るという仕様は、あまり利口に思えない。型毎にデストラクタの実行タイミングを指定できるようにすれば良かったんじゃないだろか。スコープを抜けた時か、ガベコレに掃除された時か。

拡張メソッド

さながら、その型のメンバメソッドであるかのように、非メンバメソッドを呼び出せる。

C++の Extension Member Function イディオムっぽい。通常のメンバメソッド同様「.」演算子で呼び出せるので、より自然。だけどそれは一長一短で、例えば「obj.method();」というコードが在ったとして、果たして「method」は「obj」のメンバなのか、そうでないのか判別付きにくい。「method」の内容を読もうと「obj」のクラスの定義を見に行ったら、そこには無かった、という若干イラッとさせられる場面に何度か遭遇した。Enumerableインターフェイスの拡張メソッドを考えると、有用なのは確かなんだけど……まぁ、IDEの機能で探せ、という事なのかもしれない。

LINQとEnumerable

C#というより .NET Framework の範疇だけど。

LINQ良いよね。Enumerableの拡張メソッドも良いよね。でも共存してるのは微妙。同じ用途で使えて、同じキーワードが割り振られてて、でも微妙に書き方が異なる、ってのがどうも。

あと、こいつらは、どうも遅延評価する事になってるらしくて、VSのデバッガでステップ実行してたら想定外の場所に飛んでビックリなんて事が何度か。

いや瑣末な点なんだけど、ね。

総合的には、良い言語だと思う。上で述べたように幾つか気になる点が在って、特に変数の読み取り属性の欠落がキツイと感じるけど。 .NET Framework のMac/Linux展開も加速しそうだし、今後が楽しみな言語かなと。

何時の頃からか、PCの電源を入れてFedora21をブートしている最中にエラーが発生するようになってしまった。 "Welcome to emergency mode" から始まり、"ext4_mb_generate_buddy"が "block bitmap and bg descriptor inconsistent" 云々……rootパスワード入力プロンプトでCTRL+Dしたり、パスワード入力後 「systemctl default」 を実行すると、今度は問題なくブート出来る(ログインユーザの選択画面に移行する)のだが、どうにも気持ち悪い。

「yum update」でkernelに更新が入ってから発生するようになった……ような気がする(うろ覚え)。journalって、たしかファイルシステム(ext4)関係の用語じゃなかったっけ……(適当な知識)

ググると解決法を発見。 「[SOLVED] boot into emergency mode and "dirty metadata" - FedoraForum.org」 の6つ目の投稿に拠ると、以下で解決するらしい。

1. boot into your LiveCD or LiveUSB
2. once logged in, open gnome-disks utility from the applications (I think its called Disks)
3. unmount all the /dev/mapper/fedora_XXX--root & home & swap
4. open a gnome-terminal (terminal)
5. type su -
6. enter your root password
7. type fsck /dev/mapper/fedora_XXX--root
8. if there are questions about fixing, ignoring, forcing, salvage, etc, always answer y (yes)
9. repeat step 7 & 8 with --home & --swap just to be sure"

Fedoraのバージョン違いに因る物か、以下のような多少のアレンジは必要だったが、見事に解決。良かった良かった。インターネット万歳。

• unmountの必要はなかった。
• ディスクデバイスのパスは、「/dev/fedora/ほげほげ」の形式。「ほげほげ」はrootとかhomeとか、或はswap。

……と、喜んだのも束の間。今度はhibernate出来なくなってしまった。電源を再投入した時、以前のセッションが復元されない。以前はhibernateは上手くいっていたので、状況的には悪化した事になる……うーん、これは何が拙いんだ? トラブル解決の道は遠い……まぁ、こういうトラブルを自分で解決していくのも醍醐味なんだけどね。

今仕事で関わっている某アプリ開発の話。次のように書かれているコードの、まぁ、多い事、多い事。言語はC#ね。

class Foo
{
	// 略

	void Bar()
	{
		var someObj = new SomeObject();

		// 例1
		Action<int> lambda = x =>
		{
			// 略。なんかすげー長いラムダ関数

			someObj.SetHoge();    // 引数のオブジェクトの破壊的メソッド呼び出してたりする。

			// この先も長い
		}
	}
}

いや、うん、分かるよ? そう書きたくなる気持ちは。だが死ね。

要は、メソッド内でだけ有効なメソッドが欲しいって話だよね。意味ある処理の纏まり毎に別のメソッドにしたいけれど、そうやって切り出したメソッドが或る特定のメソッド内でしか呼ばれない時とか、しかも1度だけしか呼ばれない時とか、そう書きたくなるよね。でも死ね。

C#のラムダ関数/無名関数(以下、まとめて「無名関数」と呼ぶ)は、そのすぐ外のスコープのオブジェクトをキャプチャするようになっている(恐ろしい事に、他の大部分の言語でも、そういう仕様になっているようだ)。別のメソッドに分けられているように見えるが、完全なスコープの分離がなされていない。なので、ローカル変数が、それと同じスコープの無名関数内で書き換えられている可能性が捨てきれない。事実上、複数のメソッドに分けられる筈のクソ長いメソッドを作ったのとそう変わらない。

C++のラムダ関数みたいに、キャプチャする変数を明示的に指定する仕様ならまだマシなんだろうけどね。

void foo()
{
	auto i = 1;

	// C++のラムダ関数。デフォルトでは何もキャプチャしない
	auto lambda1 = []() {
		i = 10; // エラー
	};

	// iをキャプチャ。ただし値のコピーなので、foo()のiには影響しない。
	auto lambda2 = [i]() {
		i = 10; // OK
	};

	// iをキャプチャ。参照のキャプチャなので、foo()のiを書き換える。
	auto lambda3 = [&i]() {
		i = 10; // OK
	};
}

変数のキャプチャというよりも、無名関数が糞長い事が根本的な原因かもしれないけれど。無条件の変数のキャプチャと、糞長い無名関数が合わさると、ホント凶器になるので、そういうコード書いてるプログラマは今すぐ死んで欲しい。死ぬのがダメだというならば、もういっそ禁止令出したい。俺が死ぬ前に。

オープンソースカンファレンス 2014 Fukuokaに行ってきた。言わずと知れた、オープンソース・ソフトウェアの一大祭典。展示ありーの、セミナーありーのである。今回は初の二日間開催という話だが、私が行ったのは22日土曜日、2日目の方である。いや社会人に金曜とか無理だろ。業務の一環でこういうのに参加するタイプの企業ならともかく。

セミナーは、複数の物が同時開催され、受講者が好きな物を選ぶ形になる。以下、私が受けたセミナーに関して簡単なメモ。「blogにまとめるまでなんで2週間かかってんだよ」ってのは、うん、まぁ、お察し下さい……

/usr/share/doc/(ツール名)

某Linuxディストリビューションに付属している或るスクリプトが使いづらいので、手元で勝手に改造している。それを、出来ればGithubで管理したいと思ったのだが、そのスクリプトファイルにはライセンスが明記されていない。manしても「そんなん知らん」と言われる。ライセンスが分からなければ、Githubで管理できない(有料版ではないので、プライベートリポジトリが作れない)。

さてどうしてもんだべと思っていたが、ある日Synapticをつらつら眺めていると、そのスクリプトがパッケージマネージャで管理されている事を発見。プロパティダイアログウィンドウの「インストール済みファイル」タブを参照すると、/usr/share/doc/ディレクトリ以下にそのスクリプト名のディレクトリが在り、その下にchangelogとcopyrightファイルが在るらしい事が分かった。copyrightにライセンスが書かれてあったので解決。

いやまぁ、「無知乙」って話ではあるのだが、こんなディレクトリが在るとは知らなかった。どうもLinuxはWindowsに比べて、どこに何があるのかが把握しづらいように思える。名前と役割が一致していないように見えるディレクトリが沢山在ったりするし。ディレクトリの命名と、その分け方はWindowsの方が優秀だね。まぁ、一企業が完全にコントロール出来るOSと、OSSで成り立っている物を比べるのは間違っているんだろうけど。