WordPressの「アップロードファイルの最大サイズ」に関するメモ
WordPressでアップロード可能なメディアファイル（画像、動画、サウンド、PDF等）には、容量制限がある。
「制限＝100MB」といった設定箇所が１カ所なら何も難しいことはないのだが、複数の設定が関係し合い、最終的な容量制限が決まるためややこしい。なのでちょっと整理してみた。
WordPress 3.2.1で確認。
アップロードファイルの最大サイズの基本ルール
アップロードファイルの最大サイズについては、「メディア＞新規追加」で表示される「アップロードファイルの最大サイズ」で確認できる。ここで表示される数値は、以下のルールに基づき決定される。
- 以下の「★」をつけた箇所のうち、もっとも小さな値
- もし下記2-a「サイトのアップロード容量」で、サイト全体の容量制限が設定されている場合の残り容量が、★のいずれの値よりも小さい場合は、その残り容量
1. php.ini（Webサーバのphpの設定ファイル）
- memory_limit = 66M ; Maximum amount of memory a script may consume ※例では66MB。スクリプトが使用するメモリの上限（下2つの設定値以上である必要がある）
- ★ post_max_size = 65M ; Maximum size of POST data that PHP will accept. ※例では65MB。PHPが受け取るPOSTデータの上限（アップロードするファイルとフォーム等の入力データ全部合わせての数値。下の設定値以上である必要がある）
- ★ upload_max_filesize = 64M ; Maximum allowed size for uploaded files. ※例では64MB。ファイルアップロードの上限（あくまでファイルだけ）
- max_execution_time = 300 ; ※単位は秒。タイムアウトにならない程度に適宜。
- max_input_time = 300 ; ※単位は秒。タイムアウトにならない程度に適宜。
php.iniを編集できない環境の場合、またはPHP全体の設定を変更したくない場合は、WordPressインストールディレクトリ直下の .htaccess に以下を追記することで変更できる。php.iniと.htaccessでは、値の大小に関わらず後者の設定が優先される。php.ini も .htaccess もいじれない環境の場合は諦めてサーバの設定に従うしかない。
2. WordPressの「ネットワーク管理者＞設定＞アップロード設定」
a. サイトのアップロード容量 ★
ここにチェックを入れて xxx MB とすると、1ブログ当たりの「アップロードファイルの合計」容量を制限できる。外すと無制限。
→設定は、各サイトのダッシュボードの「現在の状況」に「保存スペース」という表示欄に反映される。「xx%使用中」など出る。欄自体がなければこの設定がOFFになっているということ。
b. アップロードファイルの最大サイズ ★
上記設定のすぐ下。１個のアプロードファイルの最大容量を設定する。単位はKB。32MBとかにしたいなら 1024KB * 32 ＝ 32768KB などと設定。
→設定は、各サイトの「メディア＞新規追加」の「アップロードファイルの最大サイズ」に反映される。
容量制限を変更した場合の注意
アップロード可能容量を増やした結果、処理のタイムアウトが頻発することを防ぐために、上記1でも少し触れたが、以下２つのパラメータの設定値を忘れずに確認すること。単位は秒。
- max_execution_time スクリプトがパーサにより強制終了されるまでに許容される最大の 時間を秒単位で指定 →（アップロードとその他の処理を含め）xx秒経過したらタイムアウトで処理中断する
- max_input_time スクリプトが POST、GET そしてファイルアップロードなどの入力を パースする最大の時間を、秒単位で指定します。→（アップロードだけで）xx秒経過したらタイムアウトで処理中断する
以上です。
Evernote整理してたらありがたいクオートがいっぱい出てきたので晒す
新年明けましておめでとうございます。
今年もよろしくお願いいたします。
さて、昨年のまとめも今年の抱負も華麗にすっとばしまして表題の件。
かつて本やネットで拾った格言チックなものを集めてた時期があるのだが、このたびそれを発掘したので載せておく。今風に言うと晒しとく。Web2.0風にいうとシェアしとく（よしこれで「Web2.0」という言葉を世界で最後に使ったのはオレ）。
メジャーリーガーからアルファブロガーまで、こんなにたくさんのクオートが一度に読めるのはジャンプだけ！
・・・というほど多くないが（むしろ「集めてた」とか偉そうに言う割に少ないが）子育てからITまでごった煮で、それでは参ります。
思考に気をつけなさいそれはいつか言葉になるから。
言葉に気をつけなさいそれはいつか行動になるから。
行動に気をつけなさいそれはいつか習慣になるから。
習慣に気をつけなさいそれはいつか性格になるから。
性格に気をつけなさいそれはいつか運命になるから。
（マザーテレサ）
真実はそれゆえに自ずと勝利する。
（インドの国是）
サンスクリット語では satyameva jayate サッティヤメーヴァ・ジャヤテというらしい。よかった「マハーポーシャ」とかじゃなくて。
糸井重里の「ほぼ日」で知った。
不安というのは自分の中だけにあるもの。現実には存在しません。
（野茂英雄）
部分的に尊敬できる人というのは結構いるが（それでもすごいことだが）野茂は安心して全部を尊敬できる。
愚痴を言うな。愚痴をいうと自分の器を小さくする。
（孫正義）
ITでお金が欲しいならまずはPVを出せ。
PVが欲しいなら特定の人を呼べ。
特定の人を呼びたいならコンテンツを絞れ。
コ ンテンツが作れないなら更新すれ。
更新できないならネタを探せ。
ネタが見つからないなら見つかるまで今探せ。
今この瞬間探しも調べもしない奴はWEBでお金が欲しいというな。
（「ホームページを作る人のネタ帳」より。 http://e0166.blog89.fc2.com/blog-entry-722.html）
記事を書いた人の師匠の言葉だそうです。面白い。
ただ現在において正しいことを行ったらば人として立派なものであると信じておる
（実業家・日本資本主義の父 渋沢栄一）
先のインドの国是と通じるものがある。坂の上の雲じゃないけど、明治の日本はこれで身を立てられた幸せな時代。。。なのかな？
人生は5つのボールをジャグリングしているようなものだ。その5つとは、仕事、家族、健康、友達、精神だ。
このうち、仕事のボールだけがゴムで出来ている。落としたとしてもちゃんとあなたのところに同じ強さで戻ってくる。
しかし他の4つは違う。これらはガラスのボールだ。落としてしまえば傷がつくかもしれないし、最悪割れてしまうかもしれない。決して元のままにはならないのだ。
ジャグリングて。。。。難易度高！
胸を張って負け犬になれない者は、勝者にもなれない
（米女優ハル・ベリーの母）
ハル・ベリーはラジー賞を受賞してしまったとき、この母の教えに従いセレモニーに出席し、尊敬を集めたそうだ。
神は細部に宿る
（建築家 ミース・ファン・デル・ローエ）
神が宿ったせいかどうかは知らないが細部まで行き届いているモノはどんなジャンルでも見ててわくわくする。
Less is more.
（建築家 ミース・ファン・デル・ローエ）
レスイズモアーーー。レスイズモアだけ気にして神は細部に宿るを気にしないと目も当てられないことになります（実話）。レスイズモアとはなんもしないことじゃないよーーー。この２つを同じ人が言ってるところが味わい深い。
子供が出来たら胸を離すな（乳児期）
胸を離したら手を離すな（幼児期）
手を離したら目を離すな（少年期）
目を離したら心を離すな（思春期〜）
（出展不明 ググると2chまではたどれるがその先が不明）
子離れ、これ大事。
リズムがいい。
（インタビュアに「電球の発明では14000回も失敗したそうですが、苦労しましたね」と問われて）私は失敗を14000回繰り返したのではありません。成功しないやり方を14000回、発見し続けただけなんです。
（エジソン）
たしかに！クライアントにはこんなこと言えないですが。
ジョン・ラセターはすごい人。ピクサー映画は「神は細部に宿る」を完璧なまでに実践してるのでクリエイターなら全作品最低３回ずつ見ておきたい。メーキングも面白いよ。
随所で主人公たれ
（禅語 瑞巌和尚）
出展怪しい
神に祈ったか？
（京セラ 稲盛和夫）
やるべきことをやりつくしたと思ってもまだやることがあるぞと。
Memento mori メメントモリ（死を想え）
（ラテン語の慣用句）
古代ローマでは凱旋将軍の後ろでmemento mori memento moriと唱える人がいて「オイコラちょっと勝ったくらいで調子のんなYO！」と戒めていたそうです。怖！
私は事業のために映画を作っているのではなく、映画を作るために事業をしている
（ウォルト・ディズニー）
「プロダクトアウト」というと矮小化しすぎだけどその言葉が頭に浮かんだ。
富める人がその富をどんなに自慢していたとしても、彼がその富をどのように使うかがわかるまで彼を褒めてはならない
（ソクラテス）
子供に伝えたい。
他人と過去は変えられない。自分と未来は変えられる。
（高塚猛 同名の書籍タイトル）
まぁこの人自身は間違った方へ「変わって」しまったんですけどね。。。ソクラテスの言葉を送りたい人。
孤独は山になく、街にある。1人の人間にあるのでなく、大勢の人間の『間』にあるのである
（三木清「人生論ノート」）
オレ言ったった感が強い格言。
「いじめはなくならん」「いじめは無理矢理なくそうとするんやのうて、必ず起こる事として正面から向き合えばええと思うがどうじゃ」
（ボクシング元世界チャンピオン 竹原慎二）
竹原慎二のボコボコ相談室に書いてあって感心した。そうそう、いじめは無くなりません。ゼロを目指すものではなくて、起こったときはきちんと対処するぞという覚悟が大人には必要だと思います。
私の業績の中で最も輝かしいことは、妻を説得して私との結婚に同意させたことである。
（ウィンストン・チャーチル）
夫婦げんかしてご機嫌取りたかったのかな？
苦しいこともあるだろう 言い度いこともあるだろう 不満なこともあるだろう 腹の立つこともあるだろう 泣き度いこともあるだろう これらをじっとこらえてゆくのが 男の修行である
（山本五十六）
山本五十六はカッコイイ！
やっている、姿を感謝で見守って、信頼せねば、人は実らず
（山本五十六）
話し合い、耳を傾け、承認し、任せてやらねば、人は育たず
（山本五十六）
やってみせ 言って聞かせて させて見せ ほめてやらねば 人は動かじ
（山本五十六）
製品だ！
（スティーブ・ジョブズ）
97年倒産寸前のアップルに復帰したジョブズ。社員を前に「何が問題か？」問いかけたあと、答えを叫んで。実際のところマーケティングも営業もマネジメントも全てが問題には違いなかったのだが、製品だと（単純化して）言い切れるところが偉い。
なくしてしまえ
（スティーブ・ジョブズ）
iPod Shuffleのディスプレイについて。エッジが効いてるとはこういうこと。
以上です。ジョブズのみ最近読んだ伝記本から。
あらためて見直すとなかなか面白い。また来年やろうかな。
「よくわかる日本の教育費」を立ち上げました
子どもの教育費をざっくり試算できるサイトを立ち上げました。HTML5とCSS3をこっそり使ってます。就学前から、小学校、中学校、高校、大学と、子どもが独り立ちするまでに必要なトータルの教育費を、簡単に求めることができます。
よくわかる日本の教育費（EducationalCost.com）
人生の3大支出は「住居費、教育費、老後生活費」といわれていますが、このうち住居費と老後生活費の試算が比較的容易であるのに対し、教育費は私立公立／文系理系／仕送り額など変数が多くて試算が面倒でした。
本サイト「よくわかる日本の教育費」は、子どもの教育費について「だいたいでいいから手っ取り早く知りたい」というニーズに応えるサイトです。
年末もいよいよ押し迫ってきたこの時期に、年賀状も大掃除も子供の世話もせずにいったい何をやってんだという嫁の視線に耐えてやってきましたので、ぜひ見てやってほしいと思います。
IE7以上で利用可能ですが、作者としてはSafari、Chrome、Firefox、Operaなど、角丸、ドロップシャドウに対応したブラウザで見て欲しいなと。そういうわけで、よろしくお願いいたします。
▼スクショ。いずれスマホに最適化したUIも持たせたい。もちろん今でもPC同様には閲覧可能です。
よくわかる日本の教育費（EducationalCost.com）
iCloudのバックアップ機能は使えるか？バックアップしてくれるものとしてくれないものをまとめた。
iCloudにはバックアップ機能がある。iOS5対応デバイスでiCloudのアカウントを持っていれば、誰でもバックアップ機能を無料で利用できる。バックアップには気を遣いたくない。普段はまったく意識せずにいて、必要なときにだけ「やっててよかった」となるのが理想だ。iCloudはそんな使い方ができるのか、考えてみた。
iCloudバックアップ。これが出来ればオーケー。
- 日常のデータ保全
- 緊急時の復旧
- 買い換え時のデータ移行
2と3は、1ができていれば問題なかろう。というより母艦なしで復旧や移行ができたりと、従来の母艦バックアップ方式よりも、利便性があがっている。私は試したことがまだないが、まあネット上でも「でけたｗ」という報告を聞くし心配しても始まらないので、ここではまあ良しとしたい（なんだそりゃ）。
問題は1。従来の母艦バックアップ方式と比較して気になる点は「すべてのバックアップを取るわけではない」という点。バックアップを取らないデータについては別途ケアする必要があるのか？そんなのは面倒だ。しかしすべてのバックアップをクラウド上に保存してしまうとストレージやらトラフィックやらが大変なことになることも想像に難くない。そのへんどうなっているのか。
iCloudがバックアップしてくれないもの
iCloudがバックアップしてくれないものはいくつかある。それぞれについてその妥当性を考える。
音楽、動画
まず、iTunesで購入した音楽、動画。これはバックアップはしないが、購入情報を元に再ダウンロードできるので問題ない。iCloudストレージの容量制限外でもあるため、どれだけ大量に購入しても大丈夫。
次に、iTunesで購入していない音楽、動画。自分でCDからリッピングした音楽、ビデオカメラ等他のデバイスで撮影して取り込んだ動画など。これらはマスターデータが母艦にあるはずなので、母艦自体のバックアップがなされていれば問題ない。
さらに「カメラロールにある写真、ビデオ」はバックアップ対象になる。つまりiPhoneで撮った動画（もちろん写真も）についてはバックアップされるので大丈夫。
結果として、音楽、動画に関してデータが失われるといったケースは想定しづらい。
カメラロールにない写真、動画
1の内容と少し重複するが、iPhoto等からiTunes経由で同期していた写真、動画はバックアップされない。しかしこれも前述のとおり、母艦自体のバックアップがしっかりとなされていれば、iCloudでバックアップされなくても問題はない。
メール
IMAP対応のメールを使用すれば問題なし（mac.com、me.com、Gmail、ソフトバンクのi.softbank.jpなどなど、最近の多くのメールサービスはIMAPに対応している）。
アプリケーション、本（iBooks）
これも1で触れた「iTunesで購入した音楽、動画」と同じ考え方で、アプリケーションや本そのものはバックアップデータに含まれない。AppStoreから再ダウンロードする形をとることで、バックアップ時間と容量の節約に一役買っている。アプリケーション、本の設定や保存データはバックアップされるので、結果として、ゲームのセーブデータや各種設定なども含めて、すべて復元できる。よってこれも問題なし。
ボイスメモ
どうなんでしょうか？普通に考えれば「アプリケーションの保存データ」ということならバックアップとってくれていそうだが。
iCloudバックアップの留意点
次に留意点をいくつか。
iCloudのストレージ容量
デフォルトかつ無料の5GBだと足りない場合がある。私は3つのデバイス（iPhone×2、iPad）の合計で6.3GBだったが、その場合は追加のストレージを有料で申し込む必要がある。足りないままだとバックアップが完了せずまったく用をなさないので注意が必要だ。ただ母艦か端末のiCloudの設定画面でちゃんとバックアップできてるかは確認できるし、アラートも出るので見落とすことはないと思われる。ちなみにこの設定画面で調べたら6.3GBのうち、5GB以上がiPhoneのカメラロールだった。ということはカメラロールの中身をマメにiPhotoに取り込むなどしてすっきりさせておけば、無料の5GBでも全然いける。またカメラロールのうち静止画については「フォトストリーム」をONにしていれば自動的に母艦と同期できる。動画を撮らないまたは撮ってもマメにケーブル繋いで取り込むよーという人は、iCloudバックアップ対象からカメラロールを外すという手もありだ。私は細かな設定や取り込みが面倒なので「全部入り」バックアップにしている。
母艦（PC、Mac）のバックアップはしっかりと
繰り返しになるが、iCloudは「他の場所にマスターデータあるよね」という類のデータはバックアップしない。音楽、カメラロールにない写真・動画、メール、アプリすべてこのポリシーに基づいてバックアップ対象のデータが選別されている。したがって、音楽、映画などの動画、アプリなど、iTunes StoreやApp Storeから再ダウンロード可能なものはともかく、自分の母艦に保存しているデータは、そちらはそちらでしっかりバックアップをとる必要がある。
MacならばTimeMachineでバックアップしておけばよいだろう。私はさらに万全を期すために、TimeMachineのバックアップ先をRAID1に対応した外付けHDDにしている。余談だが、TimeMachineバックアップはホントに素晴らしい。積年のバックアップに対する不安がほぼ無くなった。とにかく「何も気にしなくてもいい」。これに勝る利便性はない。復旧もボリュームまるごとでもできるし、1ファイルだけさくっと復活もできるので、間違って削除や上書きしてしまって困るということがない。
POP3にしか対応していないメールサービスを利用している場合
POP3メールを使っていて、iPhone/PC/Macで送受信したメールは、それぞれが壊れれば、失われる可能性が高い。IMAPと違って元のデータは（原則として）サーバに保存されないからだ。はやめにIMAPメールに移行するのが最善なのは言うまでもないが、なかなかそうもいかない場合もある。その場合は、POP3で送受信したメールをiCloudで取得したme.comのIMAPメールボックスに移動すればよい。他にGmailなども利用しているのであればそちらでも構わない。
まとめ - iCloudバックアップを使うか否かの判断
以上から、iCloudのバックアップは、必要十分な仕様となっていると言えそうだが、考えてみれば、従来の母艦バックアップも必要十分ではなかったか？iCloudにバックアップするのと母艦にバックアップするのにはどんな違いがあるのかまとめる。
ケーブルレスで勝手にバックアップしてくれる
ケーブルに繋がなくても、知らないうちに勝手にバックアップしてくれる。今までは母艦に繋ぐとまずバックアップが始まり、データ量が多いときには結構待たされた。キャンセルしないとケーブルを外せないため、急いでいるときには断腸の思い出キャンセルしたものだが、そういうことに気を遣う必要がなくなった。上のTimeMachineのところでも触れたようｒに「気にしなくていい」ところが素晴らしい。
母艦のディスク容量が気になるならiCloudバックアップ
従来の母艦バックアップ方式だと、母艦上に平気で何十GBものバックアップファイルが作成される。私はMacBookをSSD（120GB）にしてからというものこれに悩まされてきた。MacBook Airなどを使っている人も同様の問題を抱えていることだろう。そんな場合にiCloudのバックアップは助かる。
母艦なしで復元したいならiCloudバックアップ
WiFi回線があればどこでも復元できるので、出先で緊急事態に見舞われたときは助かりそう（もちろん母艦にしかないデータは復元できない）。
データをクラウド上に保管すること自体のリスクをどう考えるか
一般的には、個人ユースのMac/PCよりも、しかるべきデータセンター内のiCloudの方が、さまざまな面でリスクは少なそうではある。いくら「TimeMachineでMacのバックアップは完璧」と言ってみたところで、家が災害等に見舞われれば、データを失う可能性は高い。自宅がどうにかなってもデータを守れそうなのは、クラウド上にバックアップしておくメリットのひとつだ。デメリットというのか留意が必要なのは、iCloud自体の情報漏えいや改ざん・不正使用などのトラブル。可能性としては当然ある。もっとも母艦がノーリスクというわけではもちろんないので、双方に相応のリスクが存在することを認識して利用するしかない話である。
そんなわけで、以上のような検討（？）の結果、iCloudのバックアップ機能を利用することにした。iCloudは発表からリリース前後までに色々な情報が飛びかい、国によって対応サービスも異なるなど少し複雑になってしまうかと危惧したが、バックアップに関しては、結局は「おまかせプラン」で大丈夫ということが判明したのでひと安心。
半月ほど経つが、今のところ何も問題はない。バックアップのことを意識したのは、最初に「容量足りねーYO」と怒られたときだけ。バックアップ中に端末動作が重くなるような気配も特に感じられなかったし、万一のときは平然と復旧してくれるのだろうという（昔のApple製品では考えられないような）安心感がある。
MobileMe（というより.Mac）から引き続き利用している、連絡先／カレンダー／ブックマークの同期機能も快適。「Macで編集した情報が一瞬にしてiPhone、iPadに同期されている」というキモさも相変わらずで頼もしい限りだ（その逆も然り）。余談だが、キーチェーン／Dock／ことえり辞書が同期しなくなったのは困る人もいるんじゃないかと思う。。。私も以前は「会社←→自宅1号←→自宅2号」でのヘビーシンクロナイザーだったが今はMacBook1台体制にしたのでなんとか事無きを得た。
シルク・ドゥ・ソレイユ『ZED』に感動し、常設公演を続けて欲しいと願うエントリ。
※このエントリは、2011年11月13日、Twitterに連続ポストした内容を繋げて一部編集したものです。
素晴らしいショーとは裏腹な赤字事業
ZED。たまたま機会があって行って来ました。家族をおいてこっそり一人でリピートしてしまいたいレベル。舞浜エリアのクリエイティブ偏差値高過ぎワロタw
Wikiの記事に深く頷いてしまったので引用します。「演者としての人間を強調」「大道芸、サーカス、オペラとロックの要素をふんだんに取り入れ」「衣装は非常に多彩でそして創造的であり、祝祭の雰囲気を醸し出している」
あとこれに付け加えるなら舞台と照明の素晴らしさ。さらには劇場もそれを堪能できるつくりになっていて、全体として非の打ち所がありませんでした。
現在シルク・ドゥ・ソレイユのレジデントショー（常設公演）は世界4都市9公演。舞浜のZEDもそのひとつで非常に名誉なことだが、残念ながら今年末で終了。以降の予定は未定（！）ちなみに米国以外での常設公演は舞浜のほかには中国マカオのみ。
オリエンタルランドのリリースによると終了の理由はずばり「赤字」。世界有数の可処分所得と、世界ダントツNo1の都市圏人口（3500万人）を抱えて赤字とは・・・。東日本大震災の影響だそうですが。
» オリエンタルランドのリリース（PDF）
シルク・ドゥ・ソレイユ社とオリエンタルランド社のアンバランスな関係
（以下余計な詮索が続きます）事業性無しの判断に至るということは収入が減るか支出が増えるかですが、収入が減るというのはシルク・ドゥ・ソレイユの場合は主に集客減でしょう（昨日は大盛況でしたが）。広告収入、グッズ収入など副収入は集客あってのものです。
支出面では、TDRチケットとのセット売りや各種提携などによるプロモーションコストの増加が考えられます。普通はそれらコストを織り込んだ上でチケット価格を決定するわけですが、当初見込み以上にかかったのだとしたら、それも集客力の低下ということです。
そしてオリエンタルランドとシルク・ドゥ・ソレイユ両者の収益配分で折り合いがつかない事態が生じたか。事業環境が変われば双方の力関係も変わります。お互いブランド力の高いコンテンツを抱えてますし、極めて下世話ながら、ありそうな話ではあります。
双方の立場にたつと少し分かる。オリエンタルランド（OLC）からするとシルク・ドゥ・ソレイユ（CDS）は別になくてもよい。劇場が2170席で1日2公演でも4340人。つまりTDRの圧倒的な集客の前には（残念ながら）雀の涙。
対してCDSにとってOLCの力は不可欠です。現状、舞浜なんかに劇場建設してしまったばかりにOLCに頼らざるを得ない状況だと推測されます。もしこれが都心やお台場あたりのホテルで常設公演を行なっていたら。。。勝手ながら非常に悔やまれます。
つまりはじめからOLCとCDSのタッグは不平等条約だったんじゃないのと。そう思ってWikiを見直すと、やはり常設公演のほとんどがホテル内専用劇場で開催。CDS程度の集客に吊り合うのはホテルだということです。相手がホテルならCDSも対等に交渉できそうです。
唯一米国ディズニーワールドに常設公演があるのは、舞浜と同じ構造です。どうなることやら。
シルク・ドゥ・ソレイユのレジデントショーを都心で見たい！
そろそろ締めます。来年以降まだ不透明ですが、CDSにはOLCと手を切ってもらって是非都内で常設公演を継続して欲しい！ちょうど赤プリの跡地にまた性懲りも無くホテルが建つみたいなのでそこでオケー。計画変更してでもCDSを入れたげてください。お願いします。笑
都心再開発も、昨今の再開発ラッシュとデフレ不況で大変だと推測する。知らんけど。だがCDSなら集客できる！平日2000人、休日4000人の安定集客コンテンツ。。いや、そんなことはどうでもよくって私が打ち合せ帰りに見に行くために（そしてホテルには金を落とさないｗ）。
最後にこんなの見つけた。読むと、震災は格好の理由扱いで「CDS at 舞浜TDR」の事業構造に問題があったのだと思わざるを得ない。10年の契約が3年で打ち切られるのは、OLC側にそういうオプションがあってそれを行使したということだと思われるが、こんなところもCDSの立場の弱さか。連投失礼しました。おしまい。
» http://ja.wikipedia.org/wiki/シルク・ドゥ・ソレイユ_シアター東京
Webデザイン。イラレは出来る子。フォトショなんかに負けないもん。
2015年7月11日、追記。
このページ、いまだによくアクセスされているようですが、その全員が「なんだよ2011年の記事かよ、クソが！」と不信感を抱くことと存じます。あらためて確認しますと、CC2015でも通用する内容ですのでクソとかいわずにご一読ください。
本編ここから
釣り気味のタイトルですみません。中身も釣りなのでご査収のほどよろしくお願いいたします。さて、この記事↓にリスペクトかつインスパイアされ、勢いで記事投下してみる。
Webデザインの1pxを作るためのPhotoshopのレイヤースタイルいろいろ
Webデザインをするにあたって、巷ではPhotoshopを使う人が多いようなのだが、ベクターデータの軽快さや自由自在の拡大縮小の便利さもあって、私はIllustratorを使っているため、日頃から虐げられている。ことWebに関しては、Photoshopがたけのこの里なら、Illustratorはきのこの山であり、フォトショがAKB48ならイラレは浜崎あゆみだ。仕事だってドタキャンしたくなるのである。
本稿について
そんなわけで、Illustratorが実は出来る子ということを少しでも広めるために、本エントリーを書く。Web Design Recipesさんの元記事はPhotoshopのチュートリアルではあるが、主旨としては「1pxにこだわってクオリティの高いデザインしましょうね」というフォトショ、イラレを問わない有意義なものなので、ぜひ読んでみてください。で、私の記事は、上でWeb Design RecipesさんがPhotoshopさんで作ってるボタン（あくまでも最初に出てくるボタンだけ）を、Illustratorで作ってみようという車輪の再発明なのだ。Photoshopをディスってるわけではないのでフォトショ派の人はお手柔らかにお願いしますね。喧嘩上等！
CSS3もマスターしちゃいたい欲張りなアナタに♪
さて、少しまじめな話をすると、今回のボタン作成に関しては、コツを分かってる人ならば、他方でもすぐに似たようなことができると思われる。そして後ほど触れるがCSS3を活用するときにも大いに役立つ。もちろんボタン作成に限らず、さまざまなデザインエレメントに応用可能だ。なので、本記事でも元記事でもよいが、ぜひ守破離していただければと思う。所要時間だが、慣れていれば15〜30秒、このエントリーを見ながらコツコツやって10分〜20分といったところだろうか？（追記：大嘘でしたｗ このあと試しに何秒か測ったら1分半かかった。しかも「角丸」「パスのオフセット」「ライスタライズ」「ドロップシャドウ」はよく使うので全てキーボードショートカットを設定しており、グラデーションもスウォッチ登録しておいてこのザマである）
下準備
普段イラレでWebやらない人は、こちらを見て初期設定を。ぜんぶ読むのがベターだがとりあえず本エントリーを追っかけるだけなら、「まずはイラストレーターの環境設定」の段落だけでOK。記事はCS4ベースだが、CSシリーズならいけるでしょう。
Illustratorでピクセル単位の作業を奇麗に行うための方法（イラレのピクセルずれ問題） - Memento Mac
さてそれでは実際の制作作業に入る。
Step1. 線幅1pxの線を描く
つまらない初期設定が済んだところで、さっそくこんな感じで四角を描く。変形パネルでピクセルが整数値になるように注意。前段の初期設定がなされていれば、どのように四角を書いても整数値になるはずだ（訂正：表示＞ピクセルプレビューがオンの場合は左のとおりだが、オフの場合は100%表示の状態で四角を描く必要がある）。CS5では「ピクセルグリッドに整合」機能があるらしく、このへんだいぶ楽になった模様だが、詳しくは知らない。
このとき、線が滲んで見えるはずだが気にしない。実はここがイラレでのWebデザインの勘所であり、関ヶ原であり天王山なのだが、天王山にあまりにもすぐ出くわしすぎて、多くの人がここで挫折し「やっぱWebはフォトショでしょ」となる。ラダトームの城を出たらいきなり死霊の騎士に出くわすようなものだ。この滲みを回避するのが次のステップだ。
↓このように1pxのはずの線が実質2px分の線になって、しかも色は薄くなる（下の出来上がりイメージと比べてみると、上のパスがいかにシマリなく滲んでいるか分かる）。アンチエイリアスがかかっているだけで内部的には1pxのデータには違いないのだが、Webなどのディスプレイ出力が前提のメディアでは大問題となる。
で、クリアにする方法。
Step2. 線をクリアにする
滲んでいる線をクリアにするのは意外にも簡単で、「パスのオフセット」を以下のように設定して使う。それだけだ。たびたび手前味噌でなんだが、理屈や応用編は説明すると長くなるのでこちらに譲る（Illustratorでピクセル単位の作業を奇麗に行うための方法（イラレのピクセルずれ問題）。
CC以降では？：パスのオフセットではなく「線パレット＞線の位置＞内側」でOKです。カンタン！（CS時代のこの機能は謎のにじみが発生して使えなかった）
↓
Step3. 角を丸くする
ここからは何も難しいことはない。「できる！イラストレーター」でも買ってきて読んでも間に合うレベルだ。こんなかんじ。
Step4. 塗りにグラデーションを設定
さらにこんなかんじ。説明することなさ杉。SEO対策上等！
Step5. ハイライトあてます
ドロップシャドウ効果を使うんだけど、光があたるべきところに光をあてるのでやってることはハイライトです。このへんもPhotoshopと同じ。これでほぼ完成！関係ないけど、ドロップシャドウを本当に影として使う場合、距離をとる場合（影を大きくする場合）はうすーく、距離が近づくにつれて濃くする。なぜかというと現実世界でもそのようになっているからだ。
Step6. 文字入れる
完成!!
バンザーイ。てかこんなスカスカなチュートリアルでここまで辿りつけた人はいるのでしょうか？
CSS3でも同じことできます。
直近のWebデザイン界では一番ニーズがあり、アツい分野であるHTML5＋CSS3。このCSS3を使っても、今回のようなボタンを作れるし、既にその手のチュートリアルもたくさん見かけるようになってきた。というとじゃあもうデザインソフトいらないじゃん、とはならなくて、たとえば塗りや線を複数重ねたり検討段階でのトライアンドエラーがサクっと出来ないので、餅は餅屋でデザインソフトの出番がなくなることはまずないだろう。
ただそのようにして作成した「凝った」パーツが、最終的にはライトウェイトなCSS3やSVGとして吐き出されるという方向には向かうと思われる。「CSS3かデザインソフトか」ではなく「デザインソフトでデザインし、CSS3やSVGを吐き出す」という関係だ。
話を戻して、簡単なボタンならば、そして上にも書いたようにコツがわかっていれば、CSS3のコードを手打ちしてもこのようなボタンを作れる。詳しくは将来書くかもしれない次のエントリーにゆずるが、たとえばこんなボタンも一切画像パーツを使用せずに作れる。てかリンク先ではCSSソースも見られるので将来書くかもとかなんとかもったいぶる意味あんのかと（ｒｙ
2015年追記：ここに書いたとおり、この程度のボタンなら既にCSSで実装するのが当たり前になった。アピアランスを積み重ねていくイラレの操作性は、CSSでborder、background、text-shadow、border-radius、box-shadowなどを積み重ねていく作業と全く同じである。
おわりに
というわけで、元記事の一番最初に出てくるボタンだけをマネしてみたが、その他のパーツについても、ほぼ同じものをIllustratorでも作成できる。なのでこのエントリーで、普段Photoshopを使っている人が、少しでもIllustratorに興味を持ってくれたら本望だ。あとIllustratorというとすぐに「ベジェ曲線がぁぁぁ」とか言う人が多いのだが、あれを主要ツールとして使うのは文字通り「イラストレーターさん」等だ。Webのデザインするとき使わないとは言わないが、使うシーンとしてはPhotoshopのときのそれとおんなじである。同じWebを作るのだから当たり前といえば当たり前の話だ。
関連エントリ
Illustratorでピクセル単位の作業を奇麗に行うための方法（イラレのピクセルずれ問題） - Memento Mac
いまさらながらThe new iPad のイラストレーター（ai）形式テンプレートをシェア - Memento Mac
「社内の厳しい競争環境に身を置かなくても良い社員」とは？ CAのC職創設について。
サイバーエージェントの社内組織改革について。
http://ameblo.jp/shibuya/entry-10954637766.html
上のCA社長ブログによると、管理職、専門職だけでなく、貢献度に応じた評価がなされるC職（貢献 Contribute 職？）を設置するという話。ピラミッド型かつ一本道の出世コース、そこから外れたら基本的にはキャリアアップはおしまい、という旧来型の組織を変えていこうとする試み。
C職は「社内の厳しい競争環境に身を置かなくても良い社員」。一般（Common）職と言ってしまうと身も蓋もないが、サイバーエージェントとしては意地でもそういうことではないと主張したいところだろう。求める人材像としては「出世の階段を駆け上っていくだけでなく、落ち着いて長く働いてくれる人」でそのような社員も「大切にするというメッセージ」としてC職創設を決定した。
組織構造がピラミッド型ということは、要するにトーナメント戦と同じで、日々の業務は「敗者を決める戦い」にならざるを得ない。いくらキレイごとを言ったところで、同じ会社にとどまる限りは、入社から退職までのどこかで出世は頭打ちとなる。
社員全員にこの出世レースを強いて、現場でバリバリやりたい専門職向きの人をも、不向きな管理職に「出世」させた結果、大量の「無能な管理職」を生み出してきたのが古いタイプの組織だ（この辺りは『イノベーションのジレンマ 日本「半導体」敗戦』(光文社ペーパーバックス)
C職創設は、ちょっと意地悪な見方をすると、有能な社員に潤沢なポストを用意できなくなることを見越した策ともとれる。旧来の組織はそのような場合、形式上の役職や子会社、天下り先を用意してポストをあてがい、組織の非効率化（簡単に言うと人件費の無駄な増加）とひきかえに、組織秩序や社員のモチベーションを維持してきた。
これから海外に出て行こうとするCAとしては、このようなトレードオフは望んでいないだろうから、本音の本音で言えば、トーナメント戦に敗れた社員は解雇したいのかもしれない。もちろん日本ではそう簡単には解雇できない。「C職も大切な社員」というメッセージだが、実際問題として、C職の報酬及び役職は低め安定路線で設定されるのではないだろうか？そして低い報酬を受け入れてもらう代償として、安定的な地位を約束する。
ここまでだと「なんだCAさんもついに終身雇用か」で終わってしまうし、CA側のリスクが少々大きいので「貢献 Contribute 度」という尺度を新たに持ち出す。これで安易にC職に安住することを許さない仕組みとするのが本制度の要諦であろうと推測する。はたして貢献度という可視化しづらい尺度がきちんと機能するかどうか（あれ？「安定的な地位」と「安住できない仕組み」が矛盾してる・・・ここはCAの種明かしを待ちたい）。
この問題はCAに限らず、組織の普遍的な問題といえる。解雇規制如何で難易度が大きく左右されそうだが、欧米の老舗企業やアメリカのベンチャーなど海外企業はどのように取り組んでいるのだろうか？
最近ツイッターでだらだら書いてばかりで文章作成力が落ちていたので、ブログできちんと書いてみた。
