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 やらテストの修正やらやっててだいぶすり減っていたのですが、少し元気になりました。

ありがとうございます。

その後

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

まず maintainer が変わって、official repository が変わってた。もう半年前の話だった。

• archiloque's rest-client at 1.5.1 - GitHub
• rest-client | RubyGems.org | your community gem host

archiloque's fork is now official

そんでもって 0.9 からの違いで言うと

• jeweler で gem を作るようになった
• rspec でテストを書くようになった
• mimetype の取り回しは mime-types に依存するようになった
• cookie 周りで CGI を呼び出すようになった

こんな感じ¹。

一度 1.4 で response が String でなくなって、あれ、既存のスクリプト書き直しか？と思ったら 1.5 でまた String に戻った²。ということで 1.4 を華麗にスルーしていた自分は慌ててスクリプトを書き直す必要はなかった。

rest-client を使って cache 付きの downloader のようなものを書いて動かしてるんだけど、最近は

crohr's rest-client-components at master - GitHub

Rack Middleware を透過的に使おうとしているものもあるらしい。実はここら辺からもうよく分からなくなってきてるんだけど、Rack ってサーバサイドの話じゃないんだっけ？ Rack Middleware を client サイドで使うこともできるのね。まぁ rest-client の投げる request を受け取って処理するんだから Rack でいいのか。

で、Rack::Cache は Rack とは別 gem なので注意。中身は軽く見たところ

• Marshal を使ったファイルベースの cache
• memcached
• GAE

に対応しているらしい。なるほどなぁ。

DVD が「シャーロックホームズの帰還」シリーズに入ったら¹ワトソンが別人になってた。あーそうかー。なんか「冒険」の最初の方を見たときにあれーワトソンてこんなだったっけかと思ったけど、その感覚は正しかったのだな。小説の方のシリーズと同じようにドラマも別シリーズとして放映されていたのかな？ オープニングの音楽も若干だけどテンポが遅くなった気がする。

帰還のワトソンの方が生真面目そうだな。冒険の方はちょっとお調子者感が強い気がする。でもあの笑顔はよかったよな。うーん、どっちも捨てがたい。

しかし。前から思っていたけどモリアーティが宿命のライバルって、単に作者がホームズを殺したがってただけの後付け設定だっつーのがよく分かるな。ドラマの方は最初から分かってるんだからもう少し伏線張っとけばよかったのに。

ここでは sysprep を単純にシステムのコピーに利用するという話だけに限定する。sysprep では mini-setup 時に自動的に追加コマンドを実行するなどの機能があるが、それは利用したことがないので関係する用語には触れていない。

sysprep

Windows の deploy ツール。実際に行えるのは以下の操作。イメージファイルの作成やコピーなどは sysprep の守備範囲外なので、実際には sysprep だけでは大量のセットアップを行うことはできない。あくまで sysprep がやるのは Windows をコピー可能な状態にすることと、コピー後のセットアップを自動化すること。

• SID の削除
• SID の再生成
• mini-setup などの最小限のセットアップの予約とその実行。その後、Sysprep の削除。

sysprep を使ってシステムのコピーが行える条件

• ハードウェアが同一 HAL を保持していること
• ACPI サポートの条件が同一であること
  • マスターとコピーの両方がサポートしていない、あるいは両方がサポートしている状態でないとダメ。

SID

コンピュータ名、ユーザー名、グループ名などを内部で管理するための ID. これらは完全にユニークでなければいけないため、SID を保持したまま Windows システムをコピーすることはできない。（正直、コピーしたことないからどうなるのかは知らない。）

イメージ

「イメージファイル」のことをつい連想してしまうが、単にその時点でのディスクの snapshot という程度の意味。あるいは snapshot としてコピーできるように sysprep を用いて SID を削除した状態。

Windowsへようこそ

reseal 後の起動で現れる画面の一つ。通常、買ってきた Windows で最初に現れる画面と基本的に同じ。アプリケーションのインストールウィザード画面より若干フレンドリーな雰囲気になっている。sysprep を用いた deployment では「mini-setup を使用しない」をチェックするとこの画面が現れる。これを利用した場合、Administrator のパスワードを保存しておくことができなかったり、追加でコマンドを自動実行させることができないなど、独自にカスタマイズした Windows の deployment には若干力不足な感じではある。また、この画面では Administrator 以外の管理者アカウントが存在しない場合、ユーザーの作成を要求される。Windows のログオン画面であるところの「ようこそ画面」とはまったく違うことに注意。

mini-setup

reseal 後の起動で現れる画面の一つ。「Windows へようこそ」ではなく通常のウィザードダイアログのような形で行われる deployment 時に必要な最小限のセットアップ。Administrator のパスワード保存や自動的に追加のコマンドを実行するなどの比較的高度なセットアップが可能。Administrator 以外の管理者アカウントがなくてもユーザーの作成は要求されない。

factoryモード

簡単に言うと SID の削除だけを行うモード¹。コンピュータ名の付け替えや所有者の設定、追加コマンドの実行などを一切しないが、他のコンピュータと SID がかぶらない状態を作り出すことができる。SID を再生成する以外は通常使う Windows の状態との違いは感覚的には分からない。ログオンなどの操作もフツー。何度この状態で起動しても Sysprep のバイナリは削除されない。作業マスタとしてこの状態のディスクを保存しておくとよい。

reseal（再シール）

SID を削除し、「Windows へようこそ」か mini-setup の実行を予約することで、箱から取り出したばかりの状態の Windows を作り出すこと。²こうしてセットアップを行った後、Sysprep は自働的に再起動を行い、バイナリも設定ファイルも含めて削除される。³また、Microsoft のドキュメントによると reseal は同一イメージ上で 3回までという制限がある。このため、作業マスタには factory モードで sysprep を実行したイメージを利用すればよい、という話に繋がる。⁴

参考

• Windows XP Professional と Office XP の効率的な展開と構成
• ＠IT：Windows TIPS – Tips：sysprepで環境複製用のマスタ・イメージを作成する

Interop Tokyo 2005 - BoF BSDなひととき

低い方へ低い方へ流れていく自分。。。

たださんとこ経由で

• バージョン番号の衰亡

個人的にはバージョン管理システムのおかげでバージョン番号はむしろつけやすくなったと思うんだけど、違うのかな。

• 版番号という恐怖

を読んでも思うんだけど、こだわりがなくなるぐらいにたくさん作って、それをバージョン管理ソフト任せにしてリビジョン番号なんかわけ分かんねーよバーカ、くらいの状態に慣れちゃえば、細かいことは置いといて、タグ打つときだけ真剣に考えるってことでいいんじゃないか、なんてことを思う。

あぁ、問題はその状態に慣れすぎてバージョン番号をないがしろにしているってことか？（ほんとか？）

命名規則の問題は大きいですな。商用のパッケージ製品の場合は「目玉」が出た段階でメジャー番号上げるってのが基本だろうし、オープンソースものだと「作り直したとき」に番号上げるってのもよく目にする気がする。1.0 を避けたくなるのはよく分かるんだけど、逆に手離れをよくしておくという意味では 1.0 にしてある程度ドキュメントも揃えて区切りつけておいた方がいいかもな、と思うこともある。

※ 1.0 を特に意味もなく突破した gonzui はすごいなぁと思うけど、ユーザーからすると分かりにくいのは間違いないよな。

番号付けはポリシーの問題なんだなぁと勉強になったのは PukiWiki かな。書式変更まで入ったのに 2.0 ではなく 1.4 になったし、それも pre6 のあと rc4 まで行き、途中でプラグインのラインナップにも手が加わったり、大幅な変更が相次いだのはさすがに驚いた。自分の中では sarge よりも PukiWiki 1.4 の方がリリースされないもののように見えていた。PukiWiki はもう長いことお世話になっているんだけど、いろんな意味で勉強になった。本当に。

安定板と開発版の呼び方については、個人的には FreeBSD スタイルが気に入っている。これも FreeBSD を普段使わない人には分かりにくいみたいだけど、こと最新については release(あるいは stable)か current か、しか違いはない。メジャー番号の違いは大きな機能の違いで、細かいものは飾りみたいなもんだ¹。

逆に困るのは Debian で、potato とか woody とか sarge とか言われてもどれが新しいのかさっぱり分からない。いちいち順番覚えてろってか。なんて人間にやさしくないシステムだ。しかも番号があとから決まるとかいう訳の分からなさ。どーもこればっかりは好かん。

• PUKIWIKI URI/ 以下の2つのファイルのみで ok
  • index.php → pukiwiki.php へのリンクか include
  • pukiwiki.ini.php
  • skin/
    • この中で共通 skin を include するか、差別化したければ内容のある skin を置く
• PUKIWIKI本体/ ここは Web アクセスできる必要なし
  • init.php や plugin/ を含む *.php, *.lng など
  • attach/, backup/, cache/ など、skin/ も含めてここには置かない
• 共通 SKIN/ DocumentRoot 以下に1つ

これで、どんだけ PukiWiki サイトが動いていても、pukiwiki.ini.php のフォーマットが変わらない限り、内容に手を加える必要はあるが、PUKIWIKI本体ディレクトリのみアップデートするだけでよい。

共通 skin はお好み。レンタル WikiFarm の場合は不要だろうが、個人でテーマ別に複数のサイトを動かしているような場合は共通化してあった方が都合がよい。

変更の必要なファイル

• pukiwiki.ini.php
  • プラグイン格納ディレクトリ
  • agent 判別して skin を切り替えるところで *.ini.php のパスを付加
  • （必要なら $script, $page_title などなど）

• pukiwiki.php
  • require するプログラムの位置
• init.php
  • 言語ファイルの位置

あとは plugin も含めてお好みで。

たぶんこんな感じ。

はい、超有名サイト「日本の Linux 情報」の中の画像です。確認した段階ではトップページに貼ってありました。見るとデーモン君は塔にはなれていないようですが…。

ちなみに個人的にこのサイトでいちばん使うのはマニュアル検索だったりします。あとは FreeBSD の方のマニュアル検索。ちゃんと手元で日本語の man 読めるようにすりゃいいんですけどね…。

• http://ishii.s26.xrea.com:8080/x2/modules/bwiki/

1.4 化しました(^o^)

ご本人、もう 1.3 ベースの PukiWikiMod はめんどくさくなってきてる模様。ま、いいんじゃないでしょか。ってここで書いても意味ないですが。

でもなんか上の URL はそのうち消える模様。じゃー B-Wiki の玄関口はどこになるのか。謎。もう少し事態を静観しよう。