あーありがち

過去の日記 2018-07 2018-06 2018-05 2018-04 2018-03 2018-02 2018-01 2017-12 2017-08 2017-07 2017-06 2017-05 2017-04 2017-02 2017-01 2016-12 2016-10 2016-09 2016-08 2016-07 2016-06 2016-05 2016-03 2016-02 2016-01 2015-12 2015-10 2015-09 2015-04 2014-10 2014-07 2014-06 2014-05 2014-02 2014-01 2013-12 2013-10 2013-09 2013-08 2013-07 2013-06 2013-05 2013-04 2013-03 2013-02 2013-01 2012-12 2012-10 2012-09 2012-08 2012-07 2012-06 2012-05 2012-04 2012-03 2012-02 2012-01 2011-12 2011-11 2011-10 2011-09 2011-08 2011-07 2011-06 2011-05 2011-04 2011-03 2011-02 2011-01 2010-12 2010-11 2010-10 2010-09 2010-08 2010-07 2010-06 2010-05 2010-04 2010-03 2010-02 2010-01 2009-12 2009-11 2009-10 2009-09 2009-08 2009-07 2009-06 2009-05 2009-04 2009-03 2009-02 2009-01 2008-12 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ Panther ほしい

http://www.apple.co.jp/macosx/panther/

あぁ Panther. かつて使っていたフィルムはエクタクロームパンサー100X. いやまぁどうでもよいのですが。来年こそは OS X の年になるか？

_ 定型じゃないの？

ThinkPad がヤヴァイので、とりあえず保守マニュアルをゲット。必要な部分を印刷してみようと思ったのだが、、、

なに、この縦長のフォーマット？

しかも妙に小さいし。92 * 216 ? うまくすれば A4 1枚に2ページ分入るけど。。。どうすればいいんだ？ こういうの。

_ 芸が細かい

IBM のサイトはサポート＆ダウンロードだけ favicon の色がちょっと違う。なんでかは知らんけど。

_ ThinkPad を救え

保守マニュアルの必要な部分

これはマニュアル上に印刷されてるページ番号じゃなくて PDF ファイル上のページ番号。

IBMサービスセンター

祝日はやってないけど、第2を除いて日曜はやってる。

他の番号は IBM相談窓口 で。

_ みんな好きだなぁ

from ITmeaid

有花たんが。

まぁ読んだけどさ(笑)

_ 全然平均じゃないと思うけど

Slashdot JapanやSourceForge.JPに集うユーザーの属性とは？ （ITmedia）

おかしいって。

• 回答者の平均

は、

• アクセスしてくるユーザーの平均
• /.-j アカウント持ってるユーザーの平均
• sf.jp アカウント持ってるユーザーの平均

どれとも違うと思うけど。

なんで /.-j と sf.jp をいっしょくたにしてんだか。

_ ブロードバンド難民

ADSL の接続事業者を変更しようとした。

接続の切れる期間をいちばん短くしたかったので正確な工事日が分かったら教えてほしいとお願いして、了承された。

変更先の業者の方では日付が分かればその日に合わせて手配します、ということだったのに、何の音沙汰もないまま、いきなり切れた。

マジ困るんですよ、nifty さん。

むー。まぁネタにはなったけど。現在ダイヤルアップ中。

_ 酔っぱらった

最近外で飲んで帰ってくるとうちに着いてから記憶がない*1。

あ、前からか。単にひどくなってきただけなんだな。

あー。

だめだなぁ。

そして起きてまずすることが酔っぱらったと日記を書くことだっつーのもどうだ。なんかかなり間違ってるな。他にやることあるだろう。

_ find -mmin で1時間以内に変更のあったファイルを取り出す

ずっと思っていたことがあったんですよ。

なんで find の -Xtime オプションて time と言いつつ日数を引数に取るんだろう？ 数時間以内の変更ファイルとかどうやって抽出すればいいの？

-Xmin で簡単にできました。

例えば

find ~ -mmin -60

ってすればホームディレクトリ以下で 1時間以内に変更のあったファイルが取り出せます。（主にブラウザのキャッシュが引っかかるでしょう。）

2009-06 現在で現役の BSD find も GNU find も同様に動きます。なんてこった。全然知らなかったよ。いつからある機能なんだろ。

関連つぶやき

11:07:34 >wtnabe< find は分とか時間単位で直近のファイルを探せたら便利な
                  んだがな。その場合は基準になるファイルを用意しなきゃ
                  いけないのが面倒。
13:09:27 <showchan> @wtnabe -atimeとかじゃだめすか
14:20:17 >wtnabe< @showchan あ。最近のものは単位を与えられるのですか。
14:22:05 >wtnabe< @showchan ん？ GNU find には単位を与える方法はないよ
                  うな？
14:24:30 <showchan> @wtnabe -atimeとか-aminとかあるみたいですよ。man
                    find によると
14:26:27 >wtnabe< @showchan あー -amin -mmin か。これは便利そう。ありが
                  とー。
14:28:57 >wtnabe< 基本的なツールだったり、すでに使い込んでるツールでも
                  たまに changelog とか man とか読み込まないとダメだなー

_ 今さら『パターン、Wiki、XP』を読んだ

3年前に買ってそれっきり積んでました。ごめんなさいごめんなさいごめんなさい。読み始めたら一気に読んでしまった。

ざっくり

面白かった。最近こういう本をほとんど読んでいなかったけど、丁寧に資料を集めた丁寧な仕事だ。

これまでパターンという言葉は実はあまり好きじゃなかった。意味がよく分からなかったから。その理由が本書を読んで分かった。要するにソフトウェアの世界で「デザインパターン」というパターンの中のごく限定的なものが有名になりすぎたからだったようだ。

省略せずに「オブジェクト指向における再利用のためのデザインパターン」という言葉を使っていれば「オブジェクト指向」「再利用」「デザイン（設計）」と三つも限定条件が入っていることが分かる。例えば極端な話、再利用性のないものならパターンは無用だ。「デザインパターン覚えてないしソラで書けないし、オブジェクト指向なんか分かってないんじゃないか」とか、変に萎縮する必要もないわけだ。

ちょっと安心した。

第1部 建築

以下、ざっくりと心に残った言葉。

• 「セミラティス構造」
  • トップダウンのツリー構造で抜け落ちる様々なものへの気づき
• 「漸進的成長の原理」
  • オレゴン大学の実験における建築プロジェクトで適用された原則の中から。
• 親方の仕事はあとで修正がきく
  • パタン・ランゲージを引用した言葉の要約だけど、アジャイルとか言わなくても昔からモノを作る仕事のコツは変わらないんだなぁという印象。
• 「パターン形式」
  • ノウハウなどの記述形式ってよく悩むことがあるので、フォーマットを決めるときに参考になると思った。フォーマットについては Wiki の話でもモードという言葉で出てくる。

観察からボトムアッププロセスへ繋がっていくアレグザンダーの思考を鮮やかにトレースできて、そうだよなぁと次々に納得が押し寄せてくる。

第2部 ソフトウェア開発

OOPSLA が何か初めて知った。

こういう論文というかアイディアの発表というフォーマットがあり、議論し、そのくり返しによってより良いものを目指すというアプローチがなんというか、プラグマティックな学会のような感じで面白かった。日本だと何になるんだろう、学会そのものとは違うだろうし、各種カンファレンスも何か違うような…。デブサミはいろいろボーダーがないので位置づけとして近いのかもしれないけど、この本で読んだ限りでは OOPSLA みたいな動き方とは違うような気もする。

脱線した。

• デザインパターン
• プロセスパターン
• XP

が見事につながっていき、20世紀最後のソフトウェア開発の英知が具現化されていく歴史を追えるのは単純にとてもわくわくする。XP の解説ではなく、生まれた歴史が読めるのがとても面白い。今さらだけど XP 本読んでみようかな。（できっこないと思って当時スルーしていたのだ。）

またここで、あぁ、デザインパターンに固執しなくていいんだと気が楽になった。

第3部 Wiki

ここまで来ると聞いたことのない言葉でも「パターンブラウザ」が出てくるとキターって思えるようになっている。

そして Wiki の極端な考え方がある意味分かりにくさや使いにくさを生んでいることもよく分かる。

自分の Wiki に対する理解はまだ浅かったというか、運営するという意味においてはやはり「何を目指すのか」を絶えず共有し続けるというとてもつらい作業を通じて、より良い成果を残せるのだろうなぁと、Wiki にハマって 10年経ったいま思う。

振り返ると、WWW を加速させる可能性に興奮した Wiki によって地方のデメリットも強く意識するようにもなった。 自分は「Wikiばな」には一度も参加していない。今、様々な勉強会は Ust ブームを過ぎ、直接会うことによって生まれる何かを最大化させる方向に向いているものが多い。

参加とはなんだろう。難しいんだよなぁ。

まとめ

軽く読める読み物にまとまっているんだけど、これはコンピュータサイエンスの現代史として教科書に採用していいんじゃないかと思う。いやマジで。少なくともいま実際に起きている世の中の動きについてその背景の一端をかなり理解できると思う。

オススメ。は、みんな3年前にしてますね。はい…。

_ ~/.netrcの使えないCI上からGitHubなどのprivate repositoryをprivate package代わりに使う

前提

• deploy 先で build プロセスを動かすことのできないプロジェクトであること
• ~/.netrc が無効な git クライアントが動いている

※ 今回の方法は依存パッケージを記述するファイルを強引に書き換えてしまうので、Gemfile と Gemfile.lock が揃っていないとそもそも build できない Heroku x Rails のような環境では使えないはずです。試してないけど。

方法

• 環境変数に token を持つ
• package を install する前に依存先の URI を token 付きのものに書き換える
• yarn を使っている場合は yarn install --no-lockfile オプションを使う

コード

以下のようなコードを事前準備の段階で実行すれば実現できる。

#! /bin/sh

if [ -n "$CIRCLE_SHA1" -a -n "$GITHUB_TOKEN" ]; then
    perl -i.bak -pne "s/git\\+https:\\/\\/github\\.com\\/wtnabe/git\\+https:\\/\\/${GITHUB_TOKEN}\\@github\\.com\\/wtnabe/" package.json
fi

npm install や yarn install の前段階で package.json をゴリっと書き換えてしまっている。

また、単に https://github.com から始まる URI を書き換えるようにするといろいろ誤爆しそうなので git+https を入れたり工夫してある。

課題

• private repository のコードを依存 package として指定したい
• 通常の開発時は開発者は自分の認証情報をもとに GitHub などにアクセスしており、各自がいい具合にキャッシュとかさせているので問題ない
  • CI 上ではそういうわけにはいかない。なんらかの方法で認証をパスしなければいけない

試したこと

1. ssh key
   • 最も素直な方法だが、GitHub には同一の鍵を複数登録できないので、CI のアクセスする repository の数が増えれば増えるほど扱いが大変
   • CI の機能で自動的に生成される鍵なら問題にはならないが、CircleCI では自動セットされる deploy key があるとそれを他の repository にも適用しようとするみたいでうまくいかない（そらそうか）
   • GitHub machine アカウントなら一つの鍵を使いまわせるっぽいけど、まだ試せていない
2. ~/.netrc
   • 以前試した ~/.netrc を利用する技は CircleCI 上では使えないっぽかった。Heroku のように deploy 先で build プロセスを走らせることができない場合は build をすべて CI 上で動かす必要があるが、そこで使えないのなら別な方法を考えるしかない

GitHub/BitbucketからAccess Tokenを使ってdeployする - あーありがち(2017-04-17)

_ RSpec 3.5のRequest Spec使ってみた

おじさんのためのRSpecとRequest Specの歴史ふり返り

• RSpec にはもともと Request Spec はあった
• Capybara 1.x 時代は Request Spec + Capybara という組み合わせはアリだったが、Capybara 2.x 時代には Feature Spec と組み合わせてくれという話になり、そっちが流行った
• Feature Spec の登場は RSpec 2.14
• この頃同時に RSpec 3 へ向けて should が expect なるぞーなど RSpec に疲れた人が増える（脱線）
• RSpec 3.5 で Request Spec は以前に比べて高速化したのを期に Controller Spec じゃなくて Request Spec オススメだよ宣言

使ってみた感想

• いくら速くなったとは言え、Controller Spec よりは明らかに重い
• ただし多少の遅さは我慢のうえで Request Spec を使うメリットはある
  1. view の render が自動で走るので response body も何の前準備もなしに取得できる
  2. Feature Spec ではないので Capybara の語彙に縛られずにいきなり Post できる

ごく簡単に言うと まず API を叩いて response を確認するといったことが普通にできる。地味かもしれないけどこれが助かるシーンは確かに今後増えそうだ。