@kyanny's blog

My thoughts, my life. Views/opinions are my own.

最近思ったこと

ここ数ヶ月、十数年のソフトウェア開発者人生で初めて、悪名高いExcel方眼紙に書かれた仕様書というものに触れる機会を得たのだが、悪評の理由が身を持ってわかった。

  • 装飾過多。長過ぎるフローチャートや謎のテーブル風定義一覧の「見栄え」ばかりよくて肝心のデータの見方・読み方がわからない。
  • おそらく装飾にパワーを取られすぎているからだと思うが、仕様の説明に不足がある。フィールド文字列長が何バイトとか書いてあるが超過したとき何が起こるか明記されていない、など。
  • そのシステムが実現するビジネスにおける仕様について(仕様書なのに)触れられていない。ドキュメントの書き手が読み手に対して「機械のように指示に忠実に実装だけすればよい」と考えているのが見え透いている。
  • 実装例・サンプルコードの類に乏しい。コードを見ればすぐ理解できる類のことを無理にコード無しで伝達しようとするので情報の劣化が激しく、資料として不完全。

などなど。普段使い慣れないMicrosoft Excelに苦労してようやく仕様を読み込み、いざ実装し始めると次から次へと「仕様書に書いていないが不明のままだとプログラムを完成できない微妙な疑問」が湧いてきていちいち仕様策定者に質問しなければならない(そして仕様を書く人を仲介してコードを書く人同士の伝言ゲームが始まり、時間をかけて劣化した情報を交換するはめになる)

自分はそういう「いわゆるSIer」の世界をどうにかしようとか崇高な気持ちは一切持ちあわせておらず、かといって積極的に憎悪を燃やすほどの強い想いもなく、そういう風習が滅んでくれるならそれに越したことはないが、自分は必要最小限しか関わらずに済むようにうまいことやるし必要最小限は我慢もできるので、ぶっちゃけどうでもいいんだけど、ともかく長年「都市伝説では?」と思っていた疑問が一つ解決してすっきりしており、貴重な体験に感謝したい。

Contents is king

学習サービスのソフトウェア開発に二年半ほど携わってきて、「主役は教材コンテンツである」ということが、ペンキを重ね塗りするように最初はうっすらと、徐々にくっきりと、心の底から納得するというレベルで「理解」できてきた。自分が作っているソフトウェアはコンテンツを利用するためのツールに過ぎない、ということだ。

ツールがヘボいせいで教材が利用しづらくなり、結果的に教材そしてサービスの価値を毀損してしまうことは十分ありうる。しかし、ツールがどれほど素晴らしくても、教材コンテンツがヘボかったら価値はゼロだ。ダメな教材で勉強したいとは思うひとは誰もいない。ツールたるソフトウェアは価値を殺さず・より引き出すための引き立て役なのだ。

その前提に立ってようやく、あの「UI・UX」というやつが、限定的ながら理解できた。主題が明らかになって初めて、引き立て役が「何を」引き立てるのか、という議論が成り立つ。価値あるコンテンツが利用しやすいユーザーインターフェース、コンテンツの価値を毀損しないユーザーエクスペリエンス。これなら合点がいく。

主題なきまま引き立て役を論じるのは意味がない。「何の」インターフェースなのか、「何への」エクスペリエンスなのか、をぼかしたまま一般論を語る「UI・UX論」のようなものは、詭弁といっていいだろう。

「UI・UX」について考えるときは、「主題は何か?」と自らに問いかけよう。それに答えられないうちは、引き立て役のことは一旦脇においておこう。それよりもっと重要な、最も重要なことをやらなければいけないということが、いままさにわかったのだから。

yasnippet

Emacs を使い始めて何年にもなるが、その間一度か二度しかトライしたことがなかった yasnippet に再び、そしてついに手をだした。

Emacs で JavaScript を書いているとき、なんともいえない書きづらさ、リズムの悪さを感じていた。 CoffeeScript を書き慣れているから括弧が鬱陶しいのだろう、と思っていたのだが、どうもちょっと違うようだ、という気もしていて、長年悶々としていた。

先日ふと、「苦手な言語だからリズムが悪い、のではなく、リズムが悪いから苦手に感じるのではないか?」と逆転の発想をひらめいて、いつもより少し注意深く自分のコーディングを意識してみたら、どうやら無名関数 function() {} を書くときのリズムの悪さが乱れの原因だった。

自分の Emacs は主要なプログラミング言語のメジャーモードでバッファを編集中に、開き括弧を入力すると自動的に閉じ括弧が補完されるようになっている(これが electric-pair-mode によるものだ、ということは今これを書きながら調べて知った)これが js-mode でも有効になっているため、無名関数のコーディングの打鍵は、

f u n c t i o n ( C-f SPC {
f u n c t i o n ( C-e SPC {

のいずれかになっており、無意識に運指しているものの非常に窮屈だった。その窮屈さを「リズムが悪い」と感じていたようだ。

そこで無名関数を自分で全てコーディングするのはやめて、 Emacs に補完させようと考え、 yasnippet 導入に踏み切ったわけだ。タブで展開できる略語を覚える気はハナからなかったので helm-c-yasnippet もインストールしてもっぱらそちら経由で使い始めているが、 RSpec の desc など、ものによっては略語がいい感じにタブを打てるタイミングに合うのでスムーズに使い始められそうだ。

まだほんの使い始めなのでこれから徐々に使いこなしていきたい、というレベルだが、一点だけ、 RSpec の desc は yasnippet 標準のものだと Class の補完(置換)結果が1222222222222222222222壊れてしまうことがあった。自作のもっと単純なスニペットを作ったが、同じ desc というキーワードだとタブでの補完・展開時に選択候補が二つでてきてしまい、その選択がなぜか矢印キーでないとできなくてちょっと嫌だった。 yasnippet 標準のほうのスニペットを無効化する方法がわからなかったので、深く考えずに元からあったスニペットのファイルを削除して乗り切った。


yasnippet にあんまり乗り気でなかったのには、「インテリセンスみたいな賢いものと比べると思想も機能も実用的ではあるが原始的でちょっとダサい」と感じていたのもある。要するに長年の IDE コンプレックスの産物なのだが、去年「ヌーに左手の小指を呪われた運命」だと観念した身なのだから潔くあるべし、と心を入れ替えた。

ブリーチバイパス風

RICOH GR シリーズのブリーチバイパス風の画像設定を GXR でもやる、という設定例を参考に、メーカーは違うが自分のカメラでも試してみた。

GXRで撮り続けるよ - ザリガニが見ていた...。

社員奮闘記 | リコー公式ブログ GR BLOG | リコー

ピクチャーコントロール「スタンダード」設定そのまま JPEG で撮影。 f:id:a666666:20160130161915j:plain

ピクチャーコントロール「ニュートラル」の設定を変更して JPEG で撮影。 f:id:a666666:20160130161158j:plain

RAW+BASIC で撮影した JPEG のほう。はてなブログにアップロードしたら、何度アップロードしてもなぜか RAW 現像したほうの JPEG と同じ URL になってしまって表示できなかった。不便。 dsc_0202 1

RAW で撮影して Nikon Capture NX-D で現像。 dsc_0202a

おまけ。カメラの写真は iPhone で撮影。

父親がカメラにつけてる水平の測りつきのキャップの余りをもらった