トップ 最新 追記

2012-06-10 [長年日記]

_ テーブルを置いて Mac mini を簡単に使えるようにした

以前から MacBook のディスク不足をごまかすのに必死だったのに疲れて、いろいろ考えて実は 4月に Mac mini をポチってあったんだけど、やっと使える場所を確保した。

ここに至るまでに本棚1本とユニットシェルフ1本組んで片付けるというか、平面を立体にして容積率を上げるという取り組みも行っていた。言ってみれば小さな書斎のようなスペース。

これでいろいろ捗るはず。頑張るべ。

残った宿題は

  • OSX 10.7 にとりあえず慣れる
  • iTunes のデータを Mac mini の方に統合して ホームシェアリングを理解する

辺りが大きいかな。

ここんところだいぶ無印に世話になってるなぁ。無印の収納用品て安くない*1けど、ケースと組み合わせ収納を作っていくのに便利なのと、場所が近いこともあってよく使ってる。悔しいけどやられてるなぁ。

Tags: 日々

*1 それでいてすごく品物がいいかというとそうでもない


2012-06-13 [長年日記]

_ J!NS PC カスタム買った

J!NS PC カスタム & スタンド

気になっていたブルーライトをカットするとかいう J!NS PC にようやく度入りが出たということで先日注文して、今日受け取ってきた。

Air Frame のいちばん軽いやつで、耳や鼻の当たり方がまだやさしいものをチョイス。色は今のものとあまり違和感がなく、かつある程度派手なものということで黄緑にしてみた。

掛けてみた感想としては思っていたよりレンズが黄色いが、思ったより慣れる。数分掛けているとほとんど気にならなくなる。疲労度合いがよく分からないが、鼻当ての調整の自由度がないせいか、どこかしらちょっと痛い。とは言え、これで1万円なら高くないので、最悪「授業料」になっちゃってもいいかなと思って買ってるので十分納得できるレベル。

ただ、そんなことより J!NS じゃないメガネのレンズが実はクリアじゃないことに気づいて(白んで見える)、ちょっとそっちの方にショックを受けている。汚れているとかじゃなくて傷んでるだな、これ。

[2012-06-30 追記]

しばらく毎日のように掛けていたが、以前よりちょっと目が乾く感じが和らいだように思う。これが疲労ってことなのかな? だとすると効果はあると言っていいんじゃないかな。

Tags: 日々

2012-06-16 [長年日記]

_ WDF Vol.5 に参加してきた

WDF Vol.5 - 2012年6月16日(土)ITビジネスプラザ武蔵で開催!

行って来ました。勉強会としては 3月の kanazawa.js 以来かな。全部感想書こうと思えば書けるんだけど、それはアンケートで書いたので一部だけ。

WDF は今まで知ってはいたけど参加はしてきませんでした。興味がなかったわけじゃなくて、単にタイミングの問題。基本的にはあまり連チャンでは勉強会に出ないようにしてるのです。疲れちゃうし、普通の生活も大事にしたい。仕事がきつかったら勉強会には行きません。

全体

今回の内容は

  • デサインセオリー
  • コミュニティ
  • テレビ
  • コミュニケーション(聞き方)
  • 閲覧環境の広がりと今後の制作の考え方
  • レスポンシブデザイン

だいぶ面白いラインナップ。

その中で自分がいちばん興味を持って臨んだのはレスポンシブ。もう一つ、実際に聞いて「あぁこれは」と思ったのは聞き方の話でした。

レスポンシブ

レスポンシブでまとめちゃったけど、たにぐちさんとこもりさんの話のハイブリッドの感想で。

最近一番悩んでいたレスポンシブデザイン。シングルソースマルチユースはどこまで可能なのか、利用する技術要素は分かるけど、万能解のわけないよなぁと思っていました。

で、話を聞いた限りでは、やはりコードを分かったうえで、その制約を考慮しながらモバイルファーストで設計できないと難しそうだなぁという印象ですね。先にがっつりPC向けのデザインを全力でやり切ってしまうとだいぶ難しい。

これ実はなんとなく分かっていました。なんでかというと、URL を PC版と 1:1 対応させたスマホ版を作ってみたことがあるからです。これだけで実にめんどくさい。実際には現在は一部破綻していますが、URL の対応付けだけで難しいのに、そのうえでデザインを破綻させずに両対応というのは至難の業だなぁと思うわけです。

実際やるとやっぱり大変らしい。

これが分かっただけで一つ安心。もう一つは、PC版をそのままスマホにも提供する際にできる工夫がある、というのは新たな発見でした。

例えば PC + マウス環境向けに最適化した画像を用意しない、というだけで HTML のソースはシングルではないけれど画像はシングルリソース、というやり方もできる。スマホ向けに用意したタップしやすい画像をそのまま PC でも使っちゃう。PC の画面で見ると多少「ゆるく」なるけど、別にそれで不都合は起きない。従来の感覚だと「それはなんか変だからダメ」になるけど、それでは判断基準を出し切ってない。画像を複数用意しないことでランニングコストを抑えつつPC/スマホ両対応のサイトを運営し続けることができる。どっちを採るか。モバイルパーツファーストって言葉が出てましたね。

これにはあーそういやそうか、という感じ。レスポンシブという一言で思い浮かぶ「にょりにょり感」は実は大切なことではなくて、いろんな手法、いろんな要素があって、何を組み合わせて目の前のサイトを作るか、そのための判断基準は何か、ということが大事なんだなーということが分かりました。

ざっくり言葉は知ってる、って程度だとよほどシンプルなものでないとだいぶ難しいですね、これ。

コミュニケーション

クライアント・コミュニケーションて言ってたけど、別に社内外問わず通じる話。まぁ、お互いがこの手法を知ってるとちょっとあーやってるやってるという感じはあるかもしれないけど、別に知ってて悪いもんでもない。

普段あまりキチッと考えずになんとなく経験で詰めていた部分を手法として分かりやすく説明してもらったのでとてもためになりました。

話にばっかり集中していたので、懇親会でお会いしたときに全然ご本人と認識せずに挨拶してしまうという失態をやらかしました。ごめんなさい。顔を覚えるのもコミュニケーションの基本ですね(すげー苦手)

まとめ

技術寄りの話が後ろに来ていたので個人的には体力的に楽でした。前半でいろんな話が来て疲れたところには、ある程度分かる話の方が助かります。

そのある程度分かる話の中にも、前半の様々な話の中にもたくさんの気づきがあり、とても面白かったです。kanazawa.js v1.7 で大放出してちょっとなんかもうしばらくいいや、みたいな感じになっていたり、仕事でずっと裏側の CI やらテストの修正やらやっててだいぶすり減っていたのですが、少し元気になりました。

ありがとうございます。

その後

やっぱりおなかが緩くなった。あと喉痛い。懇親会は喋るのも飲むのも食べるのも忙しいからちょっと身体にはつらいですねということを改めて思いましたとさ。がっついていけるのはもうあと数年かもしれませんなぁ。

Tags: Study Web

2012-06-24 [長年日記]

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

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

ざっくり

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

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

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

ちょっと安心した。

第1部 建築

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

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

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

第2部 ソフトウェア開発

OOPSLA が何か初めて知った。

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

脱線した。

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

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

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

第3部 Wiki

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

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

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

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

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

まとめ

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

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

Tags: Wiki Book

2012-06-29 [長年日記]

_ 『リーダブルコード』を読んだ

良い。

簡単なものが大半を占めているのがとても良い。簡単でそれで効果がある。簡単だから続けられる。リファクタリングとかおおげさな言葉を使わなくても可読性向上のためにできることがたくさんあり、それらをきちんと説明してくれている。

変数名一つ、コメントの修正やコメントの追加による段落分けだけでも可読性は大きく向上する。難しい理屈やデザインパターンなど知らなくても、それらを知っている、大幅に構造を整理し、シンプルで強力なプログラムを作ることのできる力のあるプログラマを、コメント一つで助けることができる。

ざっくり

とりあえずあいまいな名前、tmp, length, limit などは今すぐコードを検索して見直したらすぐに効果が出そうだ。

3章「誤解されない名前」では自分でも悩んでいた first/last, begin/end の使い分けに明確な指針を示してくれて、とても助かった。boolean を返す場合に is, has, can, should を使うというルールは確かに自分も使っていた。これはオープンソースのコードや各言語、ライブラリ、フレームワークを読んでいるうちになんとなく身に付いたものだろう。

7章「制御フロー」、8章「巨大な式」については本当にしょっちゅう話題にのぼるので、おさえておくとよいと思う。

心に留まったもの

仕事しない行
if ( cond )
  ;    # 何もしない
elsif ( cond )
  ;    # 何もしない
else
  ...  # 何かする
end

を否定していない。

この書き方、たぶんきらいな人はきらいだし、コードチェッカは杓子定規に弾いてくる可能性の高い書き方だけど、個人的にはアリだと思っている。その方が書きやすく読みやすければそれでいいと思う。同じ考え方の人がいて嬉しい。

目立ちすぎる値、多すぎる値はテストコードを見にくくする

プロダクトコードよりもテストコードの方が荒れやすいが、特に境界値をいろいろやろうとしてひどいことになることはよくある。

そうしたときになぜそうなってしまったかを考えると、たぶん上の理由が多い気がする。

ライブラリを知る

書かなくて済むことを書かないためにも、言語、ライブラリを知ることが大切だ。リファレンスを読み、サンプルコードを読み、実装を読もう。

レビューのお供に

『リファクタリング:Rubyエディション』の序文にこうある。

私は、会議やコードレビューの席にはハードカバーの『リファクタリング』をかならず持ち歩いて、武器としても防具としても活用した。私は自分の仕事と(より強く)ソフトウェア開発の技に情熱を注ぎ込んでいたので、同僚のデベロッパたちの多くは、私がこの本を抱えて彼らのキュービクルに向かってやってくるのを見ると戦々恐々としていたようだ。もっとも、会議でたびたびこの本の内容を参照して発言していたわけではない。

以前、自分は後輩のコードを逐一レビューしていた。その際、指針が自分でもしっかりしていなかったので、なんとなく気持ち悪いとか、単に長いとか、そういう感じのレビューになってしまい、結局役に立っていたのかよく分からないとか時間が掛かる割に効果を感じてもらえていない*1、仕事の進め方や分担が変わったなどの様々な理由で現在はあまりレビューはしていない。

『リーダブルコード』に出てくるポイントははじめにも書いたがとても簡単で効果の出るものが大半なので、特にコードのバラツキに悩んでいたり指導に悩んでいたりするならレビューのお供に使えると思う。ほぼ言語は関係ないノウハウだし。

この本には以前なら大量のコードを読んで初めて気づいたような良い作法が、とてもコンパクトにまとまっているので、自信のない人には特にオススメしたいし、自分が良いと思っている作法を効果的に後輩に伝えられずに悩んでいる人*2にもオススメしたい。

もう一度。本書の内容の大半は簡単なことだ。だから良い。

これからは以前よりは納得がいって効果の高いレビューができるかな。

Tags: Book

*1 コードが良くなるわけでも実装のスピードやデバッグのスピードが上がるわけでもない

*2 つまりオレだ!


2012-06-30 [長年日記]

_ メガネのレンズを注文した

今使っているメガネのレンズのコーティングがところどころはげてきていて、白っぽく見える場所が多くなってきた。気づいてはいたが先日 J!NS PC カスタムを購入して以来、この白っぽくなっているのがすごく気になるようになってしまったので、常用メガネのレンズも換えることにした。

とりあえずフレームには満足しているので、レンズだけ換えるために買ったお店へ。伝票によると今のメガネを買って5年経っているらしい。その前のメガネは5年でレンズ交換1回したうえで今のメガネに換えているので、以前のものよりはだいぶ保ちがいいみたいだ。ただ、もう部品がないので、壊れたらもう無理ですよとは念押しされた。

まぁ物保ちはいい方だと思うので、もうしばらくはこれでいけるんじゃないかな。どれくらいが平均的な寿命なのかよく分かってないけど。

一応簡単に検査したけど作ったときと変わらず(もしかしたらよりクリアに)見えているので、同じ数字のレンズで、1ランクコーティングなどが丈夫な新製品をお願いしてきた。

というわけで1週間程度でクリアな世界が手に入るので楽しみ。

Tags: 日々