全然ロックがわからないのに、
ライジングサンロックフェスティバルのチケットを買ってしまいました。

→Pia-no-jaC←とスガシカオのステージが観たいのです。渋さ知らズやスカパラも観たいです。
ひとりで参加するtwitterのfollowerさんにテントサイトを使わせてもらえそうなので、お世話になる予定です。

「ライジングさんおひとり様の集い」を開催することになりました。当日はお気軽に声をかけてください。
http://twitter.g.hatena.ne.jp/webbingstudio/20090725

で、これだとただの日記です。
カテゴリー、「Webdesign」になってますよね？

表題の通り、本題はライジングサン公式サイトの話です。
エリアマップやタイムテーブルを印刷できないのです。

「RISING SUN ROCK FESTIVAL」は日本屈指のライブフェスです。
サイトは皆がワクワクするような、オサレでグルーヴしてるデザインじゃなければいけません。

今年のサイトを担当した制作会社は技術力が高いようで、個性的なデザイン、透過PNG・JavaScriptを駆使した演出、論理的なコーディングと、デスクトップで閲覧する分には充分なサイトです。
参加してみたくなるワクワク感いっぱいです。

なのですが…いざチケットを買って、情報を集めようとすると問題が出てきます。

↓これ、エリアマップです。

グロカワデザインに突っ込みどころ満載ですが、それは置いといてw

エリアマップはFlashで作成されており、IEの仕様に対する対策としてスクリプトで呼び出されています。
なので、スクリーンショットを撮らないと印刷ができません。

また、各スポットに関する説明は「マウスオーバー」に反応するため（昨年のエリアマップもそうです）、例えスクリーンショットを撮っても詳しい情報までは紙に写りません。

↓で、タイムテーブルの方ですが

今年のRSRのタイムテーブルは、2分を1pxに見立てて、div要素に時間分のheightやmarginを指定することで生成しています。デスクトップで見る分にはステージの時間軸が分かりやすいですし、おそらくCMSでの作成・変更がしやすいものと思います。

ですが、ブラウザの印刷ではテーブルが崩れてしまいます。
しかも全部ベタ塗りなので紙はインクでブヨブヨですw

高度なCSSレイアウトを正しく印刷するには、専用のソフトが必要です。
フジロックのタイムテーブル（tableとrowspanを使ったオーソドックスなスタイルです）もやっぱり印刷できないし仕方ないですが、それだったらPDFを用意してもらえると助かるってものです。コンビニやWESで紙のパンフを配ってるので、それを貰ってきた方が良さそうです。

印刷以外でも、違う立場だと感じる不便があったりします。

例えば、先日会った友人は
「アーティスト紹介が暗くなって詳細が出るのだけど、閉じ方がしばらくわからなかった」
と言っていました。

アーティスト紹介のモーダルポップアップにはThickboxが使われていますが、これのインターフェースは一般の人がイメージする「端に×がある」形式ではなく、英文で書かれています。
画面外をクリックしても閉じられるのですが、その説明はありません。
そんなにWEBサービスを利用しない人だと迷ってしまうのです。

私も最近はyuga.jsに含まれているThickboxを使っているのですが、ただ「かっこいい演出」を取りいれるのではなく、実際に使ったときのことを考慮しなくちゃいけないのだなあと、またひとつ勉強になりました。

インパクト重視のサイトデザインは、ライジングサンの伝統のようです。
「History」のページでは過去11回の公式サイトが全てアーカイブされていて、WEBデザインの歴史をリアルに語る貴重な資料となっています。

http://rsr.wess.co.jp/2009/guideline/history/

なかなか面白いので、デザイナーコーダーの方はいちど見てみてください。

Twitterで記事を紹介して下さい（-人-）

10日前に公開したパブコメ、Tumblrなどでたくさんの方に転載してもらったようで、ありがとうございます。
こういった政治的な話題は苦手としているだけに、新鮮な経験でした。

楽天から来た報告によると、まぁ予想通り強行となったようです。
パブコメは「経過措置は時間の無駄」「経過措置以前に今回の流れ自体に反対」という意見が多数だったにも関わらずです。

実際のところ、全体の85%、8,333件という「反対」の半分は感情的な意見や脊髄反射だと思いますし
（4,000件でも過半数ですが…）
三木谷氏が報告している
「撮影しようとしたカメラ部隊がやんわり脅迫されて追い出された！」
というくだりも、被害者的表現で同調できるものではありません。
（そりゃ反対多数の状況なら議長は追い出すでしょ…）

それでも厚労省が、予算と時間を消費して国民から集めたパブリックコメントをろくに活用せず
「とりあえずまとめに入った」
ことだけは間違いないようです。
新型インフルエンザの件で忙しいんですかね。

会合が終わってしまったので、この後、6月1日にどうなるかわかりませんが、
厚労省のお偉方が
「数の問題ではなく、いままで気がつかなかった論点を見つけるためのもの」
と言うなら
我々下々の消費者も、そうしてみるのがいいのではないでしょうか。

楽天が公開している、最後の会合の資料へのリンクを貼っておきます。
脊髄反射でない賛成・反対双方のパブコメ、
ネット通販側・薬局側・医療従事者側・置薬業界側それぞれの意見が、中立的にまとめられています。
Web業界に従事する人、しない人も含め、多くの方に読んで欲しいところです。

※PDF、紙の資料なので少し読みにくいです

• 資料1
  「薬事法施行規則等の一部を改正する省令の一部を改正する省令案」の概要
• 資料2
  「薬事法施行規則等の一部を改正する省令の一部を改正する省令案」に関する意見の募集結果について
• 資料3
  これまでの議論を踏まえた検討項目について（再々改訂版）

ひと通り資料を読んで、改めて、薬品業界・通販業界が協力して、薬品通販に対して厳格な法規制と販売ルールを作り上げるのが最善の方法だと感じました。

個人情報保護の問題もあるかもしれませんが
「薬品が人体に直接関わるものである」
「今のネットでの薬品購入はザル」
という意見は全くの正論なので、少し便利さは犠牲になりますが

1. 販売業者の免状・罰則の法制化
2. 担当薬剤師の情報開示・電話による365日対応の義務付け
3. 購入履歴の永年確保・業界間のDBフォーマット共有
4. 薬品関連の購入フォーム画面の全面改装・入力必須項目の増加（購入した薬品に添った注意文を明示する）
5. 副作用のある薬品購入時の、保証人を含む身分証明書（保険証のコピーとか）提出の義務付け

などの、ネット通販業者の歩み寄りは必要と思います。
技術的な面だけなら、不可能ではない気がします。

これから2年の間にミキティがやってくれれば万々歳なのですが…
2年後に向けて評価を上げる努力をするのか、
ただ「じいさんだからネットが使えないだけだろ」的揚げ足を取るだけなのか。

今後の楽天側の対応を、しっかり見ていきたいところです。

Twitterで記事を紹介して下さい（-人-）

こちらの議事録を読んで呆れかえっていたところ、厚労省がまた「全然パブリックじゃないパブリックコメント」を店開きしているというので、いい加減キレてパブリックコメントを提出しました。

政治に疎い素人の意見ですが、追記以下に全文公開します（公開・非公開の義務はないようです）。
極端に偏った内容にならないようにだけ気を遣いました。

賛成、反対を問わず、もっと見識あるブロガーさんの建設的意見で、厚労省のデータベースがいっぱいになってくれますよう。
あと6日しかないのですが（´Д｀；

5/23追記：続きを書きました。

「厚生労働省に薬事法改正の件でパブリックコメントを提出した」のその後

パブコメと提出方法については、Web屋のネタ帳さんが説明してくださってます。

厚生労働省に「医薬品のネット販売禁止はおかしいだろ」とパブリックコメントを送ろう（締め切り5月18日）

薬事法施行規則等の一部を改正する省令の一部を改正する省令案について

「医薬品新販売制度の円滑施行に関する検討会」の参加者議事録を拝読し、その内容に呆れかえっております。

少なくとも、検討会参加者が個々の主張・権益を守ることにとらわれ、話し合いの中から有益な面を取り出し改善していくという「検討」の構図ではありません。

率直に言いまして、完全な時間と予算の無駄であります。
猶予期間の二年もこの調子ではあっという間でしょう。

そもそも多数の購買弱者の反対を受けながら、頭から禁止する方向で議題が進み、このパブリックコメント自体も全く一般に告知されることのないまま一週間足らずしか募集を行わないというのは、どういった「公開意見募集」なのでしょうか。

私はIT業界に従事し、三木谷氏が募集しています「薬事法施行規則等の改正反対」の署名に参加しておりますが、現状の通信販売形式が薬局・置き薬に取って替わるとは考えておりません。
身体に直接関わるものは対面購入をしていますし、購入しようとしていたものより症状に適した薬を薬局の方に勧めていただいたこともあります。
三木谷氏の孤軍奮闘を強調するような振舞いもまた、ネット通販を支える方々の権益を守る目的があるのでしょう。

それでも私が反対意見を書いておりますのは、何よりも今回の改正が過疎地在住者・身体障害者・高齢者に対する「生存権」の侵害とも取れるものだからです。

私は現在、近所に数件の薬局が立ち並ぶ都会にいますが、二十年前は、過疎化が進みつつあった夕張市に住んでおりました。
当時でもスーパー・薬局は山の麓にしかなく、大人でも往復３０分かかる坂道を上り下りして買い物に出かけるのは、特に冬は大変なものだったことを記憶しております。

さて、政令指定都市と地続きの夕張市は、猶予対象となる「離島地域」に含まれるのでしょうか。

今回の改正案はあまりにやっつけ仕事、面倒ごとを最低限避けようとする姿勢が見え見えであります。
このような愚策を許した推進派の方々が、通信販売市場が駆逐された後、残された購入弱者のカバーを昔のようにつつがなく行ってくださるというのでしょうか。
残念ながら私は議論・政治に疎い一般人ですので、そのような様子を感じ取ることは不可能であります。

また、「対面販売は様子の怪しい購入者がわかる」といいますが、これは「大量服用による自殺を考えたり、中毒症状を起こしている人間は必ず不審な様相を呈している」という明確な誤解、差別的考えの現れであります。

実際には、社会で働くごく普通の人々が薬物依存の悩みを抱えているという事実、ネット販売がなかった頃でも、都市部の依存者が複数の薬局を回って同じ薬を買い集めていたという事実は、見識をお持ちの方々なら周知であるはずです。
むしろ購入情報の統一規格化・複数年保管を義務付ければ、ネット販売の方が抑止力があるというものです。

消費者としての私の理想は、通信販売事業者・薬局・置薬業界がこれを機に連携しあい、新しい薬品流通体制を模索していただくことです。

対面販売での薬剤師の知識・安心感はこれまでのように充実していただき、
人的介助ではカバーできない、マイナーな商品取扱・不審な購入履歴の管理にIT業界の先端管理技術を積極的に取り入れてもらいたいと思います。

つまりは、年齢だの立場だのと言った互いの揚げ足取りはやめて、もう少し歩み寄りをしていただきたいのです。

置き薬販売も、元々は当時の大衆の要望に添って確立した、日本ならではの体制と思います。
時代が大きく変わっている今、置き薬文化を支えた政治家の皆様に、ネット販売への理解も同様に深めていただけることを願って止みません。

Twitterで記事を紹介して下さい（-人-）

このブログは釣り堀です – やねうらお－よっちゃんイカを食べながら年収1億円稼げる(かも知れない)仕事術

考えるきっかけを与える釣り記事ありがとうございます。
また、ブコメに☆ありがとうございます v_v

私の名刺には「Web Designer」と書かれています。
言語としてとらえると、HTMLもCSSもJavaScriptも、JavaやC++などと比べるとはるかに人間が読解しやすく、融通のきくものです。だから、やねうらおさんが「この辺の本を丸一ヶ月読めばマスターできるんじゃね？」と考えるのは至極もっともなことで、この点でWebデザイナーなめんな、とは思いません。

ですが、やねうらおさんの記事と、記事中にある本を全て読破しても、Webデザイナーにはなれません。
Webデザイナーに求められるのは「読書力」ではないからです。

プログラマは、提示された案件を検証し、決定した仕様通りに動き、納期までに作成でき、かつセキュリティがしっかりした「解」を出すのがお仕事です。
そのためには、各言語の仕様を知りつくし、構築する「読書力・理解力」が必要になるのだと思います。

Webデザイナーは、提示された案件を把握し、効率が良いと考えられる「解法」を複数提示するのがお仕事です。
それはターゲットとする第三者から見たデザインであったり、今後のサイト展開であったり、先方の好みであったり、納品後の更新担当者が自分でない場合、先方の技術レベルを見越したコーディングルールであったりします。
これらは技術としてのデザインではないので、本には載っていません。

つまり、「ディレクション＝検索力・交渉力・応用力」が均等に求められる総合芸術なのです。
…まぁ、ざっくり言うと「空気嫁」です。

この辺の能力を、本を買うより確実に養う方法があります。
自分のウェブサイトや、ブログのデザインを定期的にメンテナンスすることです。

このとき、

1. 自分はこのブログにどういう方向性を持たせたいか
2. 閲覧者がこのブログをどう感じるか
3. 閲覧者がこのブログを快適に読むことができるか

を考えるようにします。

例えば、現在のこのブログは、一からオリジナルの構築をしたいのですが、生憎時間がありません。
しかし、デフォルトテーマとか工事中のままでブログを運営して、訪問してきた人が「Webデザイナーとしての私」をどう捉えるかを考え、既存のテーマセットをベースに見た目重視のカスタマイズをしています。

また、これはどのサイトを作る時もそうですが、

1. 各段落の行間アキ
2. 文字のジャンプ率
3. 字面が揃っているか（グリッドデザイン等）
4. 閲覧者が迷わないか

を特に考慮します。
DTPデザインに近いですが、Webデザインは文字の増減、伸縮、読み込み速度も考慮します。

やねうらおさんが「学習したことを実際の仕事で見せてみろ」と言われてしまったのは、
よっちゃんイカを食べながらのデザインそのものが、説得力に欠けていたからです。

自分のブログデザインを第三者が見ても快適なもの（美しい＝快適とは限りません）にすることで、記事にも説得力が出ますし、これを繰り返すことで、実際に閲覧者やクライアントに求められているものもある程度は掴むことができると思います。

いろいろ書いてますが、私自身は空気嫁は不得手です。
Webディレクターには転身できそうもありません。
大体理解できるようになるのに三年近くかかりましたんで、一般の人なら、一年というところでしょうか。

このような記事がなくなったときが、Webデザイナーが本当の地位を得られるときなのかもしれませんね。

Twitterで記事を紹介して下さい（-人-）

MovableTypeをCMS的な構築に利用する場合、左の図のような階層カテゴリー構成にすることがよくあります。

このとき（ビジネスシーンでは少ないですが）上層カテゴリーのページで、下層カテゴリーに書いた記事も含めてリストアップする場合には

<mt:Entries include_subcategories="1">　～　</mt:Entries>
か
<mt:EntriesWithSubCategories>　～　</mt:EntriesWithSubCategories>
を利用します。

しかし、こちらの記事でも書かれているように

ハマッたケース1つ目。Aカテゴリのアーカイブに1件も記事が出てこない。記事一覧の表示方法に、「include_subcategories」という子カテゴリの記事も含む指定があるが、Aに属する記事が1件もない場合、たとえAAに属する記事が存在してもそれすら出てこない。これは全く理解不能。バグではないのか。

ブログ記事へのカテゴリ設定の注意点 – tech.ludicmind.net

上層（図ではCategoryAとCategoryB）に指定された記事がひとつもない場合、下層に記事が100件あろうとも上層カテゴリーには何もリストアップされません。

追記：2009-2-8
categoriesモディファイアのAND指定を利用して上層・下層カテゴリー名を直接明示する方法もありますが、カテゴリーアーカイブでは有効になりません。

これは、バージョン3の頃から連綿と続いている仕様という名の不具合のようで

小粋空間: 親カテゴリーアーカイブにサブカテゴリーのエントリーを表示する

当時はプラグインで対応できましたが、バージョン3.3以降はサポートされていないぽいです。
（なんか他にプラグインあったら誰か教えてください）

そんなわけで対策を考えてみました。まだ作業前なんで検証してませんが…

1.ダミー記事を書く

上層に属するダミー記事を一件書いておき、
mt:Entriesでリストアップするときに、その記事だけid指定で除外。
件の記事で、harryさんが提案されていた方法です。
ただし、そのページでの新着件数よりダミー記事が古くなった場合に表示されるのかという点と、
アーカイブリストが対象外なのが悩ましいところです。

2.PHPを使う

強引ですが…

1. mt:SubCategoriesなどで「現在より下層の新着記事」を多めにリストアップ
2. HTMLとして表示せずにPHPの「配列」に入れ込む
   （このとき、ソートできるように日付はUNIX変換する）
3. PHP側で日付順ソートして出力する

という方法です。もちろんPHP化が前提です。

もうね、アホかとバカかと。
Perlで処理したのにまたPHPかませるのかと。確実に重くなります。
WordPress信者にdisられそうです。

また、この方法もやっぱり見せかけなので、カテゴリー月別アーカイブまでは対応できません。

やっぱり後者しかないですかねー。他のお仕事しながらまた考えます。

Twitterで記事を紹介して下さい（-人-）

CORESERVERは、XREA無料版→XREA広告免除版と通して、四年以上利用していました。

月500円でサブドメイン・マルチドメイン・cronまでカバーしているサービスはなかなかありません。
データベースのUTF-8対応や、PHP5へのバージョンアップも早かったので、長いことお世話になりました。

しかし、このところPHPの「セーフモードON」でいろいろと苦労することが多くなりました。
安いサーバーとなると、セーフモードをONにして、ファイルの自動生成などにかかわるプログラムに制限をかけるのは当然のことなんですが、ブログやCMSの重要な機能にブロックがかかるのはかなり辛いです。

PerlベースのMovableTypeは全く問題なく使用できますが、PHPベースのWordPressはファイルアップロード関連の一部の機能が使用できません。
（.htaccessによるCGI化である程度は対応可能なのですが…）
MODx・Joomla等の割とマイナーなCMSは、設置の段階でことごとくつまづいてしまいました。
>> 旧ウェビンブログ：一週間でCMS7種をインストールしたレポート

また、ロリポップやYahoo!メールなどにメールをブロックされてしまい、仕方なくプライベート用のメールアドレスに送信してもらうこともたまにありました。

そんなわけで、これまでの4倍というサーバー料金はちょっと痛いのですが＞＜
ほぼ同仕様で、セーフモード制限のないエックスサーバー（X20プラン）への移転を決心した次第です。

エックスサーバーは仕事で利用した経験があり、機能面では信頼しています。
今試用期間中ですが、WordPressはぼちぼちいい感じ。
MySQLのユーザー名・パスワードを自分で指定できるのも、少し面倒ですが安心感があって良いです。
サーバーも今のところ重さを感じません。
はずれサーバーにあたったときに移転できる特例措置もあるらしいので、まぁその辺は大丈夫だろうと思います。

…実はサーバー移転をためらういちばんの理由が、移転作業が面倒くさいということだったりwww

Twitterで記事を紹介して下さい（-人-）

今のブログは、「Sandbox for MovableType」テンプレートセットを一部改編したものです。

Sandboxはもともと、WordPressのカスタマイズ用テーマでした。
最近の個人ブログツールのシェアは、MovableTypeから、このWordPressに大きく流れている状況です。
欧米では、既にシェアは逆転しているのですが、バージョンアップに伴って、日本でも本格的になってきたようです。

• MTからWPへ。2008年カイ士伝まとめ – カイ士伝
• SeesaaからWordPressへ引っ越し中です。Seesaa側の作業メモ。 | 本質思考道場
• 固定リンクを変えずにスムーズにMovableTypeからWordPressに移行するまでの作業ログ | IDEA*IDEA

ほぼ毎日、仕事で両方を利用している私としても、

MovableType＝小規模→中規模の企業向けCMS
WordPress＝個人→小規模のブログ

という住み分けが最適だろうと思います。

なので、このブログももっと更新しやすくて、PHPで気軽に拡張できるWordPressに切り替えた方が良いのではないかと考えはじめていますが…

個人的に苦手なのです、WordPress。
WordPressへの不満などグダグダ書き出してみます。

内蔵の関数がひどい

HTMLタグのような書式で記述したものを内部変換させるMovableTypeに対して、WordPressはPHPのプログラム（ユーザー関数）をそのまま記述します。

例えば　<?php bloginfo(‘name’) ?> というのは
「name」という引数を渡すとブログ名を返す、「bloginfo」という関数
という意味です。

PHPを勉強している人にはわかりやすい仕様なのですが、いろいろな人の手を経て何度も拡張を繰り返してきたためか、関数の仕様に一貫性がありません。

bloginfoのような、引数がほとんどないものはいいのですが、何個もの引数を要求し、しかも順番が間違ってると動作しない関数も多く、あとでテーマファイルを見ても、引数だけだとそれで何をしようとしたのか、さっぱり見通しがききません。

「&lorem=TRUE&ipsum=0」のように、必要なモディファイアだけ指定する「クエリ式」が使える関数も増えたとはいえ、このクエリ式が使える・使えない関数もまたバラバラで、新しい情報をまめにチェックしなければいけません。

文章整形フォーマットが使いにくい

WordPressの本文自動成型は、かなり融通がきかないことで有名です。
普通の文章なら問題ないのですが、改行込みのHTMLタグを書いたり、アフィリエイトバナーを貼ったりすると、大抵思うようにいきません。

最新版の2.7で向上するかと思いましたが、過去のバージョンとの互換性が足を引っ張っているからか、あんまり良くなっていません。

この辺りはプラグインの追加でも何とかなるのですが、できればデフォルトの方を何とかしてほしいものです。

2009/01/08追記：
WordPress2.7になって、自動整形機能はだいぶ改善されてきました。
正確にマークアップしたHTMLの改行タグを削除するようなふざけた挙動はなくなりましたが、コメントなどの連続ハイフン、textarea内のHTMLソースなどはやっぱり正確に表示できません。

独自タグの範囲内を成形させないRaw HTML、カスタムフィールドの内容を本文に入れ込むContent Ex等の併用が無難です。

本文と追記を別個として扱えない

MovableTypeをはじめ、HTMLを編集できるレンタルブログなどは「本文」と「追記」に対して、別個の独自タグが提供されています。
これは使い方によっては便利なもので、本文と追記に別の役割を与えることで、特殊なウェブサイトを簡単に構築することができます。

ところがWordPressは、更新を簡単にすることに重きを置いているからか、本文と追記の扱いが非常にあいまいで、また、本文だけ・追記だけを自由に切り出すことはできません。

excontentプラグインを作ったのも、そのような経緯からです。

区切りが本文中の<!–more–>だけなので、うっかりHTMLタグで囲んでしまうと、一覧ページが大変なことになるのも悩みです。

コーディングの融通が利かない

WordPressは、1つの命令文で大きな固まりのHTML群を書き出す関数が多くあります。
すぐにブログを構築したいときにはとても良いのですが、デザイン上の理由でコーディングを細かく修正しようとすると、コアファイルを参考に、追加の関数を自分で作成しなければなりません。

静的ファイルが残らない

WordPressは、アクセスするたびにページを生成するのが基本です。
サーバー内にページの実体はありません。
このため、頻繁に更新するブログほど、どんどん表示が遅くなっていきます。
（MovableTypeは再構築が遅くなるのでどっこいどっこいですが）

現時点ではWP Super Chacheプラグインがよく紹介されていますが、キャッシュ生成はWordPressのコアに関わるため、バージョンが変わると動かなくなってしまったり、サーバーとの相性が悪くて最初から動作しないということも多いようです。

安全性に難がある

初期状態でインストールすると、ユーザーIDはかならず「admin」になり、管理画面のURLはブログのルートと同じ階層になります。
これだと、推測ができないのはパスワードだけなので、セキュリティ面ではかなり危ういです。
WordPressの中の人にはもっと、この辺を啓蒙していただきたいものです。

もちろん、私はWordPress設置時は管理画面の階層、IDのどちらも変更しています。

中の人々の態度がでかい

すいませんすいません主観です。

和訳のせいかもしれないですけど、なんか偉そうじゃないですかあの人たち。

「2.7にはコルトレーンという偉大な名前を冠しましたよー」
「私たちはこーんなスバラシイツールを無償で提供してますよー」

ああなんかいやだむずむずするかゆいうま。

需要があるのは確かだし、ある程度は妥協して、いい点をガンガン伸ばしていくしかないですね。

Twitterで記事を紹介して下さい（-人-）