$ echo 'a' 'b'
↓
a b
$ export CMD="echo 'a' 'b'" $ $CMD
↓
‘a’ ‘b’
‘は文字となってしまっている。そのため、例えば以下の文は記号含む「'want-to-exclude.txt'」に一致するファイル名のみを除外してrsyncするコマンドになる。
$ export CMD="rsync -rtv --delete --exclude='want-to-exclude.txt' src/ dest/ $ CMD >> rsync.log
$ eval $CMD
double scoreによる脆弱性に注意。
$ echo $PARAM1 $PARAM2 $PERMANENT_PARAM
最近SEO対策に関する作業をしているが、実は全然知識がなく試しに一冊本を買った。 技術者向けの参考書ではなかったが、いくつか要旨を得られたのでメモする。
内部対策のスキル
外部対策のスキル
コピーライティングのスキル
キーワード理解のスキル
エンジニアとして関わりそうなのは前２者。（たぶんWEBディレクターとかアフィリエイターになったら全部有用なんだろう）
ひとまず、買ったのは内部対策についての本。 www.amazon.co.jp
（今のところ、外部対策はどうも流行り廃れが激しく、ちょっと量を当たらないと理解できそうにない印象がある。） （情弱？うるさい。）
業務妨害にならない程度に。
私は悲観的な人間だ、ということに数時間前に気づいた。 そこまでの所以は、長い人生語りがあるので省略するとして、何より、これまで志していたエンジニアリングがその価値観に基づいていることに気づいたのだ。
ネット越しに聞く良いエンジニアリングとは「良いサービスを」「快適なUIを」「良質なユーザー体験を」などプラスのイメージを持った言葉で語られる。 どうも私はしっくりこなかったのだが、この日に私はとうとう「ユーザーの不幸をなくすこと」を優先的に考えるエンジニアであることに気づいた。
言葉にすれば「なんだ」と終わってしまうような気がするが、ここはひとつ私が体験したことを交えて不幸福を知るエンジニアリングについて持論を展開してみよう。
都営大江戸線、清澄白河駅ホームの壁をご存じだろうか？ ユニークなことに、工業製品のスクラップをぺしゃんこにして埋め込まれているのだ。
（参考） yaplog.jp
オシャレといえばそんな気がしてしまうが、数時間前の私はひどく悪いの印象を受けた。 元は恐らく立派だったであろう脚立が、見るも無残な姿に押しつぶされている。 それは効率的で意図があった形で、大小なりコストをかけて形にしたものが、台無しにされている。
「工業スクラップだから」と前もって説明を受ければ先入観が多少あったかもしれないが、何も聞かずの初見で目にした時はかなりショックだった。
これは誰かの意図とならないこと─不幸福を先に連想する私の意見だ。 発想の順序が違うかもしれないが、「これは幸福である」である前提でとらえるならば、このアートはどう見えるだろう？
見た目の重厚さやアートとして成立している、といった表面的な褒め方もあるが、「同じく元の形があった」という先ほどと同じ観点から、色々前向きな意見が出てこないだろうか。
前の形がつぶされている事実から、平面的でありながら立体として元の形が頭に活きる。 元の形があったからこその規則性、美しさが浮き出ている。
先ほどの私の頭からはこの言葉がひとかけらも出なかった。 （出たといえば、これも現代アートなんだな、と表面的な感想ぐらいだった） 本当に、私は悲観的だ。
この例えでの悲観的な捉え方は生産性の全くない話だが、 次の２つの捉え方ではどうだろう。
・今より良い機能を提供するのは、ユーザーにとっての幸福である ・より良い機能を提供できるのに今できないのは、ユーザーにとっての不幸である
命題では同じだ。 しかし、方向性でいえば、前者は発散し、後者は収束する。
エンジニア各位が何となく察する通り、目指す方向が違えば手にかけて形作る指向が生まれる。 幸福のためのエンジニアリングが謳う結果があれば、 不幸福を知るエンジニアリングが求める結果がある。
前置きが長くなってしまった。
前述の通り、私はどうやら不幸福を知るからこそできるエンジニアリングに長けている。 バグやユーザーが不快となる動線への嗅覚、 運用上の障害やプログラムを長期でメンテするうえでの問題点の予知。
これは、一般的に安定したソフトウェア開発で求められるベーシックな能力だが、 先ほどと同じように言い換えてみよう。
ユーザーがより良い体験をするための気づきと発想力、 メンテナンス性をより高める仕組みの提案力。
前者はやはり収束、後者は発散だ。
この手の話を巡って、よく本質は何だろう、と考える。 ネットには、よく幸福を謳うような情報が流れているが、そのほとんどが不幸からも語ることができて違う方向性を持ってしまうとすれば、では本質はどこにあるのか。
共通のインタフェースとする、ある事実のことをいうのだろうか。
だがおそらく、その本質を語る前に本稿で呼ぶ幸福のエンジニアリングと不幸福のエンジニアリングがある。 無形からアーキテクチャを提案するならば、その尚更だ。
次の現場でDB2からOracleへの乗り換えをしたいという話を聞いて、そういえばOracleはちょっと触ったけどDB2ってよく知らないなーとういことで、色々調べまわる。
すごく長いトランザクションAがあったとする。そのトランザクションが走っている間、他の短かったりするトランザクションが必要なテーブルをいっぱい更新したりすると、SELECTを投げるたびになんか値が変わって、トランザクションAの処理が超面倒くさかったりする。その対策として「トランザクションAが開始したときの状態をとれるように値を保証する」メカニズムを参照一貫性保証と呼ぶ。
https://www.ibm.com/developerworks/jp/data/library/dataserver/pdf/session6_introduction.pdf
次の現場でDB2からOracleへの乗り換えをしたいという話を聞いて、そういえばOracleはちょっと触ったけどDB2ってよく知らないなーとういことで、色々調べまわる。
すごく長いトランザクションAがあったとする。そのトランザクションが走っている間、他の短かったりするトランザクションが必要なテーブルをいっぱい更新したりすると、SELECTを投げるたびになんか値が変わって、トランザクションAの処理が超面倒くさかったりする。その対策として「トランザクションAが開始したときの状態をとれるように値を保証する」メカニズムを参照一貫性保証と呼ぶ。
https://www.ibm.com/developerworks/jp/data/library/dataserver/pdf/session6_introduction.pdf
