  |
はてなキーワード: XHTMLとは
キミたちがすでにReactやVueやTypeScriptを鮮やかにコーディングできることはよく知っている。
だが、弊社が運用更新保守業務を請け負っているサイトの中には、いにしえの「XHTML」で書かれたものがまだちらほら残っている。10年以上リニューアルしていないような古めかしいサイトに多い。
そのうちのどれかを、君たちの誰かが担当することがあるかもしれない。
その時はぜひ気をつけてほしい。
＜img /＞、＜br /＞ のように自分で自分を閉じるスラッシュを必ず書くのがXHTMLのルールだ。
もちろんこんなルールに丁寧に従わなくても表示は正しくされる。
だが、ソースをバリデータに通せば閉じスラッシュのない空要素はすべて文法エラーとされる。
納品先の意地悪な情シスがいちいちバリデーションして結果にケチをつけてくることだってある。
そういう隙のない納品物を目指してくれ。
なお、いくつかのXHTMLサイトは君たちの先輩が組んだものだ。CSSには君たちの知らない謎のテクニックがたくさん書かれているだろうが、それを参考にする必要はない。当時はそうするしかなかったが、もはや無用のものばかりだ。
だが、それを見てキモいとかダサいとか大きな声で嘲笑してはいけない。それを組んだ人は案外近くの席に座っていたりするからだ。傷つくんだ、けっこう。
Macを使ってるデザイナーが作ったデザインをウェブ（当時はXHTML+CSS)に起こすことをやってたけど、
そのマシンにしか入ってない＆Mac専用品のフォントをデザインで使って、
それはXHTMLでは再現できないのでよく似たフォントで代用したら、デザインを完璧に再現していないと全リテイクになったことがあったなぁ。
仕方ないのでXHTMLで書くのを諦めて、デザイナーのイラレデータを細かくスライスして、各画像にALT文章を仕込むような作り方に変えたけど、
9割完成したところで、「区切り線を1px下にずらしましたので全ページ修正お願いします！」ってのが5回10回と発生したので、
そのうちめんどくさくなって、1枚画像を無加工で貼って、ホームページビルダーでイメージマップ貼るだけの作り方にして最終的に納品した。
検索エンジンからは本文がなにもない画像だけ貼ったページにしか見えないので、SEO対策としては最低最悪のクズ品質だけど、
社内からも顧客からも（デザインの良さだけで）大絶賛、いい仕事をしたと拍手喝采だったので、非常にアホくさくなった思い出。
例えば「AB」という概念があった時, 「ABAB」「ABのAB」「ABに関するAB」という概念も成立しうる場合, その概念は「メタAB」と呼べそうである.
あたりがぱっと思いつくけれど, 身近な例でも応用できないだろうか.
意外と難しい.
元日本マイクロソフトの古川享さんブログより。このブログかなり前から消えてるんだけど、復活の目処は無いのだろうか
http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry
https://web.archive.org/web/20061105065656/http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry
さて、この話をいつかはちゃんと記述しておかねばと常々思っていたのですが、それに取り掛かろうと思うと胸の古傷が疼くというか、平常心を保って書こうと思ってもキーボードを叩く手に自然と汗が滲んでくるのです。しっかり深呼吸をして、書きます。（またまた長文にて、失礼）
まず、1999年5月24日発表の郵政省資料「地上デジタルＴＶ放送方式について電気通信技術審議会から答申」に記述のある以下の文章をご査読ください；
「また、昨年９月の暫定方式や既に答申がなされているＢＳデジタル放送方式、ＣＳデジタル放送方式の技術的条件において、実証実験を必要とする映像の表示方法とされていた720p（有効走査線数720本の順次走査による映像表示方法）について実験を行った結果、その性能が確認されたこと等が併せて報告されました。 この中で、720pは技術的にＨＤＴＶ放送と位置付けることが可能である、と結論付けられています。」（同上答申より引用）
関連記事は、日経産業新聞(1999年5月25日PP.3)、日本経済新聞(1999年5月25日PP.11)、電波新聞(1999年5月26日PP.2)などにも掲載されています。
今となっては、720pや1080pのプログレッシブ方式はプラズマや液晶テレビとの親和性、映画やCGなどの映像制作に有利なバリアブル・ピッチによる撮影、パソコンによる編集や再生環境においてその優位性を疑う人は居ないと思うのですが...1998年からこの1999年5月24日までの間、この720pを日本の放送業界から抹殺しようとする「ありとあらゆる活動を展開した集団」がおり、その軋轢の中で多くの人が傷付き市場から去ることになったのでした。
私個人の主張、そしてマイクロソフトの立場は、1080iと720pどちらが良いか、どちらかひとつを採択するかではなく、仕様の中に1080iと720pを併記して頂きたいというものでした。 米国の放送方式はATSCによるHD放送に向けた放送の標準フォーマットとして早くから1080i、720p、480p、480iが規定されていました。50年以上前に発明されたテレビ放送が米国に合わせてNTSC方式を日本は採用し、ヨーロッパ・中国・ロシアなどがPAL方式を採用してきた背景からすれば、日米のテレビ方式がデジタル・ハイビジョン（HD放送）の時代になっても米国と同様の1080i及び720pを両方サポートするということは自然なことと思われました。日米間の互換性だけではなく、当時よりブラウン管チューブを使った重たいテレビ受像機は、急激な勢いでプラズマTVや液晶テレビに取って変わることは明らかであり、走査線が走り一本ずつの光るスダレを交互に表示して人間の眼の残像を利用してひとつの映像に重ね合わせるという飛び越し走査よりは、一つ一つのセルが自ら発光する、もしくは遮光をオン・オフして光源を反射もしくは直視し映像を表現するフラットパネルの時代には、プログレッシブ（順次）方式が有利と思われました。さらに、映像圧縮に採用されたMPEG2方式においては、1080iは22Mbpsでは最高品質の映像を表示するも、その転送レートを15Mbps以下まで落としてくると映像が破綻するという現象も既知のことでした。720pはMPEG2による映像圧縮でも15Mbpsでほぼ最高品質を達成し,12Mbpsでもほぼ実用の域を保ち、さらにMPEG2以外の圧縮方式MPEG4、H.264、WMV（現在のVC1）などを使えば8Mbpsから12MbpsでHD放送を伝送できるというのが、私たちの主張でした。
当時の私の主張をまとめると、「HD放送は1080iもしくは720pいずれでも撮影、記録、編集、伝送、受信、視聴できることとする。映像圧縮に関してはMPEG2に限らず、将来の斬新な圧縮技術を随時採択できることにする。コンテンツ保護技術や、個人の認証、課金技術は特定技術一つに限らず、複数の技術をそれぞれもしくは組み合わせて提供可能とする。放送と通信の融合（連携）サービスを記述するメタ言語はHTMLをベースに各種プラグインそしてXMLに対応する。XHTMLをベースにしたBMLはそのサブセットとして組み込む。」
それに対して、1080i擁護派は、「1080iが優れた方式で、議論の余地は無い、プログレッシブの話をするなら帰れ!!」（実際に砧の某研究所で当時の所長に言われた言葉ですが...今の所長さん（E並氏）はとても紳士ですので、私は尊敬しております。決して誤解のないように）郵政省の会合でも何度となく放送のプロ達に諭（さと）されたものです。｢君はPC業界に都合の良い方向へ持っていこうとしてるんでしょ｣「崇高な放送の世界を邪悪な世界に引き込もうとしている」と..多くの人が同席する会議の場で私は名指しで糾弾されたものです。
将来のデジタル放送の規格に720pは絶対入れないという強い意思とあらゆる活動は「1080iと720pを併記したらどうか」と主張する陣営を徹底的に痛めつけました。
当時、松下電器産業殿は720pの優位性を説きながらDVC Proをレリースされ、1080iと720pの両用機能を持った松下電器産業のHD D5という放送局用ビデオデッキは、AJ-HD2700やAJ-HD3700という型番で欧米の放送局でも沢山採用され、放送業界の権威あるエミー賞をDVC ProもHD D5も受賞されています。このD5というビデオデッキはNHK殿に納入する時、720pの機能が付いているなんてことがバレると殺されるので、本体に点在するボタンを11個以上押さないと、（つまり二人の人間の指を駆使してボタンを押さないと720pの機能はアクティブにならないように細工がしてあったそうです。）..まるで隠れキリシタンが隠し絵にキリスト像を描いていたような話でありますが..この類（たぐい）のプレッシャは日々激しいものになってきて、魔女狩りに駆り出された狂信的な信者が、誰彼となく次々と火あぶりに挙げるような行為が続いたのです。
480pと720pの実験放送をやっていた日本テレビのSさんとKさんの受けた仕打ちは、某放送局のEB沢さんから直接日テレ社長のUJ家氏に電話をかけてこられて、「お宅の技術のトップの人間は、ウチに対抗して何かやっているようだけど、けしからん話だ。そんなことではデジタル・ハイビジョンの映像をウチから供給できなくなるけれど、それでも良いのかねぇ」と迫ったそうです。その結果Sさん、Kさんは当然将来取締役が約束されてもおかしくない何十年にも渡る業界に対する貢献がありながらいつのまにか表街道を去ってしまうことになりました。
テレビ朝日殿が新しいスタジオを作るにあたり、1080i/720pの両用ビデオ・スイッチャーを東芝から導入された時、某放送局のキツイお達しがテレ朝と東芝に飛び、720pの機能は殺して納入するようにとの指示が飛んだそうです。そして、BS-iのスタジオ導入で,1080iのカメラと720pのカメラを性能評価したという話を聞きつけて、「まさか720pのカメラを導入するなんてことはありませんね？」という問い合わせが某局から入ったそうです。
TBS殿も全く同様にメインスタジオへのHD機材導入にあたって1080iと720pの両用システムの導入計画は純粋な技術的観点の選択肢だけではなく、それ以外の見えない力に奔走されておられました。「魂の報道」を標榜するTBS殿の報道部門が、DVC Pro 720pを採択されたことが、唯一の救いと感じられました。
NAB98の会場にて明日から開場というまさに前日のこと、某放送局のY氏、会場を事前に巡回されJVC殿の会場にて1080iと720pの両用カメラを発見、JVC殿に対して「好ましくない表示は控えるようにと一括」結果としてNAB98の初日には無残にも綺麗にできた展示パネルの1080i/720pの文字列の720pの部分にはガムテープが張ってありました。
毎週のようにこのような話を耳にするにつけ、これは魔女狩りでも特高警察の検閲でもあるまいに…現代の話なのに本当にそんなことが起っているのだろうかと自分の耳を疑っていました。そしてそれが、とうとう我が身にも降りかかったのでした。
1998年のNABショウでマイクロソフトは初めて放送関連のコンベンションで技術展示をすることになりました（関連記事）。松下殿より当時500万円程したHD D5デッキをマイクロソフトは購入し、1080iと720pの映像を左右1対で比較デモ表示し、どのように優位性が表示されるか比較デモを予定していました。1080iの標準的な撮影は1440x1150の1080i標準ビデオカメラによる撮影結果を1920x1080の映像に計算しなおし（アップスケール）、それをスダレのような偶数・奇数のフィールドに振り分け送出するという方式を取っていました（現在のデジタル・ハイビジョン放送の標準撮影方法です。）。そして同じ映像を1280x720の720p標準カメラで撮影しD5デッキに録画した映像をそのまま720ｐで再生するというデモ内容でした。映像の再生には当時の最高品質のCRTスタジオ・モニター(8000ドルクラスのSONY製品を2台)をマイクロソフトの展示会場に用意しておりました。比較展示用デモ映像は同じスタジオ環境で撮影した1080iと720pのそれぞれの映像データをお持ちの松下電器産業殿からD5の録画テープをお借りして、初日のデモへ向けて全ての設営と映像チェックが終わった時のことです。某放送局の方が、マイクロソフトのブースを垣間見るや、とても渋い顔をしておられます。
私は夕方の6時過ぎに会場の設営も終わり、ホテルに戻ろうとしていたところ、松下殿から緊急の連絡が入り、展示に使っていたビデオテープを持って松下殿の技術担当役員のホテルの部屋まで来て欲しいとのこと..部屋に入るとその役員さんは、ベッドの上にあぐらをかいて、その両脇には15人を超そうという松下の方々が壁沿いに2列にずらりと並んで座っているではないですか..その姿はまるで、新入りの囚人（私）が牢名主の親分に「今日からお世話になります」と仁義を切るのかい、というような雰囲気でありました。
そしてその親分さんが言うには、「そのテープ黙って置いて、帰ってくれ」とのこと..「冗談じゃない、そんなことしたら明日の展示は何も映像が表示できないではないですか？何故そんな唐突な話をこの期に及んでされるのですか」と問いただしたところ、松下がマイクロソフトに協力して720pを推進するのはけしからんと、某放送局からお叱りを受けたと..それだけでも絶句の出来事なのに…「とにかく松下から映像を貸し出すなどとんでもない..即効撤収してくるように」との具体的な命令を受け私は必至に食い下がり、「その映像作品は全て松下殿の著作物であり、某放送局に文句を言われる筋のモノでは無いはずです。それを何故ゆえに引き上げなければならないのですか？」と伺えば..「その中のヨーロッパのお城のシーンはARIB加盟各社がテスト映像として皆で利用するために松下が供出したもので、そのテスト映像をARIBの会員でもないマイクロソフトが勝手に使うのは如何なものか？」とのこと..私はさらに一歩も引かず交渉を続け…もしそれが現実になるのなら「明日の朝は急遽説明のパネルを書いて、某放送局の名前を実名で明らかにした上で、この名前の会社の不当な介入でマイクロソフトでは展示ができなくなりました」と張り出しますよとまで迫りましたが担当役員は首を立てに振りません。最期に私は「判りましたこのテープはここに置いて行きますが、夜中に誰かに盗まれたということにして私が犯人になりますから..盗難届けを出してください!!それでは如何でしょうか？」と交渉は3時間を越える押し問答となりました。
その結果最後に明らかにされた背景は、某放送局の方から松下の役員に語られた厳しい言葉でした。それは、「君、僕らは今年50億円くらい君の会社からモノ買う予定だよねぇ、そんな態度でいると、50億円のビジネス失うことになるよ、君ぃ!! それでも良いのだね!!!」というもので、担当役員は縮み上がってしまったのだそうです。技術担当の役員がマイクロソフトの展示に協力をした結果、50億円のビジネスを失うことになったら営業担当の役員との軋轢を生むことは必至であり、そこまでのリスクを負ってまでビデオテープをマイクロソフトに貸し出すわけにはいかないとの判断、私はビジネスの交渉でこんなに困り果てたことは一生に何度も無いというぐらい意気消沈しきっておりました。
夜10時にならんとするタイミングで、日本からシアトル経由でラスベガスに到着後、時差から回復する間も無く会場の設営を手伝っていた私はもうダウン寸前…そこで思いついた解決策は「判りました、このテープはお返ししましょう。その代わり今から新規に撮影を開始しますから、必要な機材と人を朝まで貸してください」と何とも無謀な提案を申し出たのでした。 NABのメイン会場からマイクロソフトの借りていたヒルトンホテルの部屋まで、HDカメラ（当時は100kg以上あったと思います）とD5のデッキを担いで深夜に部屋へ持ち込みスイッチャーや編集機もないままイッパツ撮りでデモ映像を仕上げなければなりません。私はそれまでにいくつかの放送スタジオに見学に行ったことはあるものの、映像プロデュースも撮影も全くのシロウトですので、カメラのライティング、撮影のオペレーションに付き合ってくれる人たち3人ほどに朝まで付き合ってもらいました。
途方に暮れて困ったことは、深夜の12時にラスベガスのホテルで撮影できる生素材など有りはしないのです。それも著作権、肖像権を侵害せず、HD映像の違いが際立って表現できる素材、なおかつ1080iより720pの方が綺麗に見えるという素材（多くは、風にそよぐ木々とか波打つ水面、キックされたサッカーボールなんてものが使われるのですが..残された時間に日中でロケハンに出かけることもできず、全てはラスベガス・ヒルトンの部屋で深夜、朝までの6時間以内に解決しなければなりません。
まず、深夜のルームサービスで果物の盛り込みを頼みました。そしてその果物の表面に霧を吹いて光るリンゴの表面に張り付く水滴なんてものを撮影しました。本格的なスタジオと違って光の回り方も映像のモニタを視ても、思ったような映像にはなりません。
夜も更けて3時を廻り4時にならんとした頃でしょうか、雑誌のカラーグラビアをメクりながら、この際著作権の許諾を無視して雑誌に写っている写真を撮影してしまおうか？こんな深夜にマトモに著作権の許諾などできる素材など有りはしないし、と途方に暮れていたところ、あるアイディアが湧き出てきました。「そうだ、ドル紙幣を撮影すれば手彫りのエッチングで表現された人間の顔やお札の文様はHD撮影すればビックリするほど細かい映像として撮影対象になるに違いない、誰でもそのパターンが何か理解できるはずだし、何よりもお札の縦横無尽に走っているストライプが際立って720pと1080iの違いを引き立ててくれるに違いない」と確信するに至ったのです。ドル紙幣をビデオ撮影しても肖像権や著作権を主張する人もあるまい、という点が一番大事なポイントだったのです。
壁に貼り付けた50ドル札（私の持っていたピン札はそれしかなかったので）にバッチリとライティングを施し、撮影した結果は「キタ、キタ、キターッ」という感じ!!カメラをパンして右へ左へ振りながらお札の表面を舐めるように撮影した720pの映像は細かい線の1本1本を明確に表示して、1080iの映像は実に見事にモアレ縞が出まくり画面にチリチリと汚い映像が糸を引きます。これでこの映像をそれぞれディスプレィに表示した上で、 Permalink | 記事への反応(0) | 11:32
※マネージャを多少悪者気味に書いていますが、マネジメントの大変さはわかっているつもりです。
マネージャ「たぶん2週間ぐらいでできますよ！wordpressなら学生のころバイトとかでもよくインストールしてたから楽勝です！」
デザイナ「完全オリジナルのwordpressデザイン2週間か、なんとかなるかな?」
.... 略 ....
上司「あれから2週間だけど、こんなにバグ多すぎじゃリリース無理じゃない？」
マネージャ「違うんですよ！デザイナーが全然テンプレートの使い方覚えてくれないし、あのプログラマ人PHPわからないとか言って仕事中にPHPの本とか読んでるから遅れたんです！たぶん自分だけだったらこんなに時間かなりませんよ。」
デザイナ(「XHTMLになってない！」とか余計な所に口突っ込んできやがって！）
プログラマ(PHPなんて簡単だよとか言ってJavaプロジェクトからコンバートさせたのテメーだろうが！)
原因
マネージャ「このスケジュールなんだけど、テスト期間長過ぎじゃない？」
プログラマ「え、でも機能もこれだけありますし10日程度は妥当かと」
マネージャ「いやいや、画面たったこれだけじゃない、通しのテストなんてみんなでやれば1日ぐらいで終わるでしょ？」
マネージャ「俺がレビューしてるんだからそんなでかいバグ出るわけねえだろ。ナメてんのか」
.... 略 ....
プログラマ「セキュリティ周りのバグもあるので、修正には3日程かかると思いますが」
マネージャ「ふざけんな！テストは今日で終わるスケジュールだろ！」
原因
プログラマ「前のプロジェクトでgitを使って便利だったので、今回のプロジェクトでも使いたいのですが…」
マネージャ「バージョン管理とか使ってるの?あんなの効率悪くなるからやめたほうが良いよ」
マネージャ「前に俺がやってたプロジェクトではフォルダで日付ごとに管理してた。同じ風にすれば大丈夫だろ」
マネージャ「古いフォルダからファイルをコピーすればいいだけだろ。馬鹿か」
.... 略 ....
デザイナ（間違ってファイル上書きしたのは黙っておこう）
プログラマ（ローカルにgitリポジトリあるのは黙っておこう）
原因
マネージャ「何このCodeIgniterっていうの？」
プログラマ「あ、それ最近流行ってるPHPのフレームワークで、URLのルーティングが…」
マネージャ「はぁ！？フレームワークとか使わないと開発できないわけ？これだから最近のゆとりはダメなんだよ。」
プログラマ「でも、便利ですよ？」
マネージャ「俺のプロジェクトではそういう怪しいやつは使わないから。バグがあったらお前責任取れるの？」
.... 略 ....
マネージャ「どう、俺の書いたURLルーティングライブラリすごく便利じゃない?」
マネージャ「あー、それは仕様だからしょうがないよ。mod_rewrite使えば問題無いでしょ？」
プログラマ（他人が再発明した車輪のバグを修正するのって本当に不毛だな…）
原因
（記事が長すぎたので前編・中編・後編に分けました）
僕ももう、リストラされそうなとあるおっさんなんですが、先日Webサービスを公開しました。
きっかけになったのはこの記事です。
http://anond.hatelabo.jp/20101203150748
こんな事できたら良いなぁと思っていると、他にもやっている方たちがいました。
http://matome.naver.jp/odai/2131952812556433001
http://anond.hatelabo.jp/20120318122617
Rails3 と jQuery で、真面目にオシャレなエロサイトをつくってみました - h300
http://d.hatena.ne.jp/inouetakuya/20120331/1333192327
http://anond.hatelabo.jp/20120914214121
http://blog.ropross.net/archives/99
これらを読んで自分もやってみたくなり、
先日の家入さんの折れずに挑戦を続ける姿を見てモチベーションも高まり、
７月２１日～８月１９日の３０日でWebサービスを作りました。
最後の一週間はお盆休みでしたが、それ以外は平日は仕事をしながら土日をフルに使っています。
と言っても、いきなり高度な事をするのは大変なので、
本当に自分が作りたいサイトをやる前に、一度シンプルなサイトを作ってみる、という所までです。
やってみて改めて分かったのは、「自分でWEBサービスを作りたいと思っている人へ」の中の人はかなりがんばったんだなぁ、と。
かなりの熱意とモチベーションをもって、効率良くやらないと、一から勉強してあの短期間であのサイトは作れません。
プロ顔負けの技術とおもしろいアイデア、情熱をもって短期間でそれをやってしまった中の人は凄いです。
だから、Webサービスに夢を見る人(僕)も、Web業界の人も、あとＨな人もブクマするのでしょう。（賞賛）
それでは、一般人が一般的ながんばりで確実にやれるだろう手堅いラインをお届けします。
偏差値40の僕が最低限ここまで出来たので、きっとあなたならもっと出来るはず。
ステップ７まではサクサク進めて、分からなくてもどんどん次に行きましょう。
今回ぼくが作ったサイトはこちら
■ステップ０：準備
・パソコンを用意
・ブラウザはChrome,IE,Firefox,Safariあたりをインストールしておく。Chrome便利。
・作りたいサイトのアイデアとデザインのイメージ、ドメイン名(○○○.comとか)のイメージ。
・作る理由とやる気
・はてブ便利、Web業界の皆さんの空気感を知るため、なるべくＰＣかスマホでチェック。
ブラウザを右クリックして「ソースを表示」すると出てくるアレです。
Yahoo!とかのソースを見るとかなり長いけど、全部書くわけじゃないから大丈夫。
ネットで調べても良いけど、やっぱり基礎知識は本が良いと思います。
メモ帳で書いてブラウザで表示して、メモ帳で直してブラウザF5で更新して確認、
何となく分かってきたら、より具体的に理解するためにこの本を読みます。
PHPについて調べる。
初めはこの本が勉強になりました。
書いてある通りロカールサーバー(XAMPPかMAMP)を入れて、自分のマシンでPHPが動くようにします。
データベースの使い方も一緒に書いてあるので入門に最適です。
次はこれを読みます。
普通に読んでいくと中盤のフレームワークを作る所で挫折するはずなので、一旦そこまででOK。
パーフェクトPHP
PHPの他の選択肢としてRubyやPythonもあるみたいですが、学習コストがかかりそうなのと、そのままでは動かないサーバーがあったりで、
最先端のプログラマーになる必要はないので、レガシー＆枯れたPHP一択です。
カッコつけずにモチベーションが持続するうちに勝負です。
VPS(専用サーバーを仮想的に分割して安くしたサーバー)が流行ってますが、
学習コストがかかるのと勉強する事が増えるので割りきって始めは普通のレンタルサーバーにします。
VPSを借りるとLinuxの知識やWebサーバー、メールサーバー、及びそれらの保守管理などの知識が必要になります。
レンタルサーバーならある程度マネージドで、作ったプログラムが動かない時の原因の切り分けもしやすいです。
おすすめは「さくらのレンタルサーバー」のスタンダードプランです。データベースの使えない「ライト」プランは止めましょう。
その他、ロリポップ、CORESERVERなどいろいろあるので最低限PHP,MySQLが使えるサーバーを選びます。
サーバーを契約したらアカウント情報を確認して、FTPでログインしてみましょう。
http://sourceforge.jp/projects/ffftp/
ログインできたら、ステップ１で練習したファイルをアップロードしてブラウザで表示してみたり、
ステップ２で作ったPHPファイルをアップロードしてブラウザで実行してみたりします。
慣れてきたらFileZilla FTP Clientが便利です。
Webサービスのしくみを理解するために、WordPressを借りたサーバーに入れてみます。
WordPressはPHPで出来たCMS（コンテンツ管理システム）で、ステップ１～３がどう組み合わさって動くのか理解できます。
ブログや会社案内のサイト程度は作れてしまうので触れておいて損はないです。
テーマをいじったり、プラグインで遊んでみると理解が深まります。
オススメはこの本。
プラグインのまとめはこの辺りが親切。
2011年版！絶対にインストールしたいWordPressプラグイン45個
http://vanilla-stone.com/blog/wordpress/2011-edition-45-wordpress-plugin-pieces-install-absolute/
TwitterやInstagramと連携するプラグイン入れたり、CRONで自動化したりすると楽しくなってきます。
ここまでで何となくWebサイトのしくみが理解できると思いますが、
自分の作りたいサイトを一から書いていくと思うと心が折れると思います。
そこで、CakePHP(ケーキピーエイチピー)というフレームワークを勉強します。
フレームワークというのはWebサイトの開発で必要になることが多い色んな機能をまとめてくれている枠組みソフトです。
PHPの文法で、フレームワークの書き方のルールに従うだけで、様々な便利機能を簡単に使用でき、
フレームワークは他にRubyのRuby on Rails、PHPだとSymfonyやYiiなどかなりの種類があります。
CakePHP 1.3によるWebアプリケーション開発―オープンソース徹底活用
あと、余裕があればこれも購入。
注意したいのは、現在CakePHPのバージョンは1.3系と2.0系がありますが、1.3を使うという事です。
2.0系は新しい機能が付いたりパフォーマンスが良くなったりしていますが、2012年9月現在、
バージョンアップが激しく、関連書籍は２～３冊程度、Webの検索でもヒットするのは1.3の情報が圧倒的に多いです。
ＭＶＣというデータ処理・表示処理・それらのコントロール処理を分離して記述するルールや、
ステップ２では踏み込んでいなかったクラスが出てきますので、慣れるまではかなりの心折設計です。
難しすぎて僕は理解できなかったので、ここで一旦CodeIgniterに浮気しました。
CodeIgniterはCakePHPと同じPHPで書かれたフレームワークで、インド方面で良く使われてるらしい。日本だとまだマイナー、かな。
ライセンス問題で下火になっていますが習得の容易さとパフォーマンスが良いのでフレームワークという概念の把握にはオススメです。
僕はこれを読んでCodeigniterだけじゃなくてCakePHPも理解できました。
CodeIgniter徹底入門
ただ、CodeIgniterは簡単・高速で習得しやすいけど、
その分シンプルで機能が少ないので、ちゃんとしたサイトを作ろうと思うほど自分で書く部分が増えていきます。
セキュリティやユーザー認証なども素人が自前で一から作るのは危険なので、やっぱりCakePHPお勧めです。
開発する時はgitHubに上がっているデバッグキットを入れると便利です。
cakephp / debug_kit
https://github.com/cakephp/debug_kit/tree/1.3
http://codezine.jp/article/detail/5105
NetBeansを使う時のCakePHP用の追加モジュールはここ
https://github.com/evilbloodydemon/cakephp-netbeans/tree/autocomplete
中編はこちら
http://anond.hatelabo.jp/20120731231313
このエントリで「この4つの条件を満たした電子書籍ストアを作れば成功する」的なことを書いたんだけど、
epubは、XHTMLで構成されているのだが、数十年後にxhtmlが読めなくなるとはとても考えられないので、
数十年後も確実に読めるだろう。
不安材料として、試しに海外の写真集を購入し、拡張子を.zipに変えてjpgファイルを取り出してみたらPCで普通に見れたのが、
日本の漫画を購入し、jpgを取り出してみたら「破損されてて読めない」と表示された（当然kobo Touchでは普通に読める）事があるが、
多分、まだkobo Touchのみにしか対応していないからそうなっただけで他端末に対応されたらこういう事もなくなると思う。多分。
もしかしたら、koboでダウンロードした書籍はkoboが用意したアプリを使用しないと読めない仕様でやっていくのかもしれないと思ったが、
それは流石にないだろう。
koboのランキングや「美術・建築」カテゴリを見ればわかるが、海外の無修正エロ写真集が普通に販売されている。
また、漫画の「歴史フィクション」カテゴリでは、「ヒストリエ」「三国志」等の隣に、「ウルトラくのいち Ｍ汁開拓史」というエロ漫画も販売されている。
ジョブズみたいなエロ嫌いの野暮な人間と違い、三木谷先生はエロを規制する気が一切無い。
これはかなり難しい事だが、楽天なら可能だろう。
毎日1000冊以上コンテンツを増やすと名言し、7月中に3万冊以上のコンテンツを確保するとも言っていた。
Webサービスになるんじゃないかなーってことを思いついたので、自力で作ってみよう思う。
プログラマとして社会人約三年経験後、無職半年目。別業界に行こうと思ってた。
でも思いついたからやってみるって言うのは有りだと思うんだ。
機能拡張とかばっかりだったから、どうしていいのかいまいちわかってない。
・レンタルサーバを借りる
・余裕があればドメイン取得
・開発言語はPHP（とはいえ独自フレームワークばっかりだったのでCakeとか使えないぞ……）
・MySQL実は使ったことがないんだよな。関数をチェックしておく必要性あり。
・UIはHTML5を意識したXHTMLで書いておけば将来的な移行がしやすいのかな。最初からHTML5で書くというのも手か？
・CSS3使ってもいいのかなあ
・関連商品の表示のために何をすればいいのか（DBに閲覧履歴を保持するのか？）
・他にも思いつき次第追記
・ここがわからないのであった
・twitterとかなのかな
まあ、作れないかもしれないけど、その時はその時。
http://anond.hatelabo.jp/20111113010022
こちらに触発されて書いてみる。辞めてからかなり時間も経ったのでそろそろ書いてもいいかなと。
訓練内容はAdobeのCS4の操作方法→自主制作というのがだいたいの流れとなっていて、それぞれのアプリケーションのテキスト（フォトショ、イラレ、DW、Flash）とHTML+CSSの本という感じ。
このテキストを選定しているのは教室を運営している会社のようで、（伝聞で聞いたので定かではない）もし運営してる会社がWEB制作を知らないとか知っててもテーブルレイアウトだった場合にはあまりいい本は選ばれないようです。また運営会社同士でヨコの繋がりで話し合って本を決めてる部分もある（複数の教室で同じ本だった）のかな？と予想しました。
実際の訓練内容はハローワークで決めているのか運営会社で決めているのかは解りませんが、講師は訓練スケジュールやテキストに関してなにも言えない、わからないまま講義が始まります。
HTML5時代だというのにFLASHにえらく時間を割いたりするスケジュールで、受講生から「せんせーFLASHってどうなんすか？」と物凄く困る質問をされたりします。
また受講生はAdobe製品をアカデミックで買えるというナイスな特典があったりしますが、授業で使ってるのはCS4だけど買ったのはCS5.5みたいな微妙だけど重要なアクシデントが発生します。
HTMLの本もXHTMLならまだしもHTML4.01（しかもStrict）で書いてる本だったりすることもあります。
受講生はテキストを実費で購入しているため、ないがしろにするわけにはいかないので「これいらんだろ」とか思ってもとりあえず本の通りに進めなければなりません。（例えばHTMLの本を早めに終わらせてXHTMLの話をして余計混乱させたりとかあった）
ここで問題なのは受講生は基本的にお金に余裕がある人は少ないです。
AdobeのWebプレミアムがアカデミックで買えるとはいえ10万以上の余裕があるなら基金訓練なんかコネーよ！という人が半数以上いるんじゃないかと。
体験版はあるけど1ヶ月で終わるし、訓練自体は半年あるわけです。
なのでGIMPとかInkscapeとかもサラっと存在を教えておいたりします。
あとはフォームのHTMLだけ教えて肝心のPHPやらPerlやらには基本触れないのでそこも工夫が必要です。
教科書3冊くらいクリアするころには生徒からこれで本当にWEB屋さんになれるの？とか疑問を持たれますので、フリーでやっていく方法とか自分の経験談の話をすると人気の講師になれますが、会社からはいい顔されないかもしれません。職業訓練なのでどこかに就職するのが大前提なんです。
指導要綱みたいなものはキホンないので講師の思うとおりに教えられますが、上記のテキストの縛りとスケジュールの縛りがあるので本が変わる前にグループを作ってもらって共同作業させることを取り入れました。実際にWEB屋さんにいったら分業しますしね。
さて、各アプリケーションのテキストがいいものだったらよいのですが、そうでない場合は自分で課題とかを作る必要があります。
フォトショやらイラレはいいんですが問題はHTML+CSSとFLASH。FlashなんかはASがゴッソリ抜けてたりすると生徒から「やりたいことができない！」と嘆かれます。CSSなんかも「やりたいことができない！」と言われがちです。
実際は一人の講師が２コマやることがザラなんじゃないかと思います。
AM9時からお昼を挟んでPM3時まで+PM3時からPM9時まで。若干ズレはするでしょうがこんな感じなんじゃないかと。
これで課題を自作していたら睡眠時間は3～4時間くらいになっちまいます。ああ祝日ってステキ・・・。とか思い始めます。フリーランサーは普段の仕事は全部お断りしないとイカンかもしれません。
テキストの内容とスケジュール（ｘ月ｘ日からｘ月ｘ日までFLASHとか書いてある）なんか完全に合わないので苦悩します。
事前に用意できればいいのですが先に書いたようにスケジュールやテキストは開講数日前にコレでヨロ！的に渡されますので初めてやるひとは対応難しいでしょう。
とりあえず今日はここまで。
もう、いいおっさんの年齢なんですが、先日、とあるWEBサービスを公開しました。
5年ほど前からぼーっと考えていたんですが、如何せん、事務職の自分には”創る技術”が無かった。
優れた若い技術者（id:amachangとかうらやましい）や、チャレンジ精神あふれる経営者（id:hiroyukiegamiとか）が出てくる中うつうつとしている自分に嫌気がさし、4か月前の7月頃からHTMLやプログラムの勉強を始めた。
本屋で立ち読みしたら、まずはHTMLを勉強する必要があると、書いてあった。同時にCSSを学んだ。
プログラムを作りたかったので、次にJavascriptをやった。
jQueryがすごい。「プログラムって誰でもできるんだ。」この時そう思った。
検索システムを作りたかったので、本屋に行ったらCGI/Perlの本がいっぱいあったので、Perlを勉強した。
しかし、HTMLテンプレートが使いたかったのでPHP+Smartyを勉強した。
作りたかったWEBサービスは大手サイトのデータの検索サイトだったので、自動でデータを集める必要があった。
PerlのLWPを勉強したが、データを集めた後に加工する必要があった。簡単そうだったRubyとMechanizeを勉強した。
Rubyはものすごくきれいにプログラムがかけることを知った。話し言葉に近い気がする。
プログラムを作っている時、最初は自分のパソコンの中でやっていて気付かなかったが、実際に公開するときはレンタルサーバーを使うというのを知って調べると、Linuxのサーバーが多いということを知った。
だから、今度は自宅のあいているパソコンにLinuxを入れた。
Linuxを入れたはいいものの、全く使い方が分からず四苦八苦してRubyのインストールをした。
世界中でメインで動いているWEBサーバーがApacheということも3か月前に知った。
Apacheの設定がテキストファイルなのも驚いた。cd,ls,vi,mv,cp,chmod等、基本的なUNIXコマンドを覚えた。
例の図書館の事件があったので、クローラーを動かすのをためらったが定期的にちょっとずつなら怒られないんじゃないかと、Crontabを勉強した。
自宅のサーバーが壊れてしまい、構築が大変だったので今度はVPSサーバーを借りた。
同じように構築はしたがかなり苦労した。このとき、始めてmakeというコマンドを使った。コンパイルというらしい。
クローラーが自動的にデータを集めていたが、動かし始めて2カ月目でデータファイルが1GBを超えていることに気がついた。
このとき、テキストファイルでデータを扱おうと思っていたが大きすぎて動かない。
最終的にデータ量は5GBを超えた。
11月も後半、本稼働用のサーバーを探していたら、丁度カゴヤがVPSサーバーのベータ版を募集していた。
すごく、快適です。まだベータ版ですが、本番稼動でも、50GBで900円という激安プランです。
http://www.kagoya.jp/cloud/vps/
ベータ版では、3つまでOSのインストールができます。もちろんそれぞれにIPアドレスが振られます。
このVPSにサーバー管理システムをインストールし、もろもろの環境も作って、11月末についに、公開。
AV女優をスリーサイズから検索できるシステム、「完全に一致」です。
類似検索機能付きで、2次元と3次元をつなげる夢のシステムです。はい。
真剣に作ったんだ。仕事をしながらよく頑張ったと自分をほめてあげたい。
----------------------------------------------
インターフェース：jQuery+selectToUISlider
-----------------------------------------------
サーバー上にある静的なHTMLは1ページもなく、mod_rewriteですべてPHPが処理しています。
一番大変だった事は、、、
このサイトのデータはDMM社のデータを使わせてもらったのですが、AV女優の顔写真をそのまま使うのは、肖像権的にNGらしく、AV女優の作品の中からその女優の顔が一番大きく写っているパッケージを使うことにしました。
しかし、女優データは約5万件。作品データは12万件。とても手作業でやるわけにもいきませんでした。
結局どうしたかというと、Face.com（http://face.com/）という、画像の顔認識ができるAPIを無料で提供しているサービスを利用しました。
同様のことができる、OpenCVというソフトがあるのですが、最初から付いているパターンデータでは人の正面の写真しか顔として認識しませんでした。
それに比べて、Face.comの認識精度は驚くほど高く、横だろうが斜めだろうがかなりの精度で顔を認識してくれました。
データをJSON形式で返してくれる（JSONもこのとき初めて知った）為、取得したデータを後で加工しやすかったです。
1.このAPIを使い12万件の作品データをすべてスキャンするプログラムを書く※1
2.顔の縦の長さと横の長さを取得
3.縦×横で顔の面積を計算
6.その女優の作品の中で顔面積が一番大きなパッケージ写真をその女優の顔写真として代用しました。※2
※1 APIの制限が1時間1000リクエスト迄だったので、これまたCronで・・・
※2 実際には女優テーブルと作品テーブルを繋ぐ中間テーブルのフラグをONにした。若干の間違いはあるものの、かなり正確に出ました。
長々と書きましたが、ズブの素人から約4ヵ月でここまで出来ました。
勉強する前、SEをやっている友人に話したら、「3年はかかるんじゃないか？」と言われましたが、できたものを見せたら褒めてくれました。
WEBサービスを作りたいと思っていて、技術がないからとあきらめている人は、とりあえずやってみてください。意外に簡単にできますよ。
あと、クローラーが動いていると、全能感を味わえるので楽しいです。
-----------------------------------------
19:30追記
サーバーソフトからアラートが上がって、見てみてたらなんかすごいアクセス貰ってまして。
＞カゴヤの中の人乙ｗｗｗｗ VPSといったらさくらかServersManくらいしか選択肢が無いのは現状当然の認識であるはずなのに！
カゴヤの人間じゃないですよー。広告してるつもりもないんですが、ベータ版だからかもしれませんけど、すごい快適ですよ。今は。
何よりタダなので。
本当に月額900円のまま本公開になったら、環境構築もめんどくさいのでそのまま契約しちゃうかもです。
＞カゴヤはOpenVZだからなあ。俺としてはより自由度の高いさくらのVPSをお薦めしたい。
そうなんですか。2週間のお試し期間はつかったのですが、正直どっちがいいとかわかりません。
どんな風に自由度が高いんですかね？あと、アダルトOKなんですっけ？
＞組み立てるプログラミングは本当に簡単だよ。 みんなで入り口を隠しているだけだよ。 #組み立てるだけじゃなくて、アルゴリズムを練ることが真のプログラミングかもしれない
サンプルプログラムの組み合わせで作ったようなサービスですので、プログラムのソースとかぐっちゃぐちゃです。
もともと、作ろうと思ったきっかけなんですけど、
椎名舞さんがですね、すでに引退しちゃってるんですよ。ずいぶん前に。
それで、検索エンジンで検索したんです。でも、なかなか出ないんですね。
欲望のままにやってたら、次から次に壁にぶち当たって、そしたらいつの間にかできました。
結果、このシステム使って椎名舞さんのプロポーションに似たAV女優を探すと、
雛乃つばめさんとか、果梨さんとか、佐伯さきさんとか既にDVD持っている女優さんばっかりヒットしちゃうんですね。確かに似てるんです。スタイル。
とくに最近の細い子は。
あ。デザインは、某企業をパｋ、じゃないリスペクトさせてもらいました。
-------------------------------------
23:55追記
寝てたらサーバーからアラートメールが携帯に飛んできておこされました！
こんな瞬発的なアクセスを考えていなかったので、とりあえず再起動しました。
-------------------------------------
12/4 01:45追記
何度再起動してもサーバーが反応しなくなるので、うぎゃーってなってたのですが、
親切な方が「MySQLサーバーが原因じゃね？デフォルトだろ？query_cache_sizeを設定したらいいよ。」とわざわざお問い合わせからアドバイスくれました。
設定してみたら驚くほどつながりやすくなりました！
同じSQLクエリーを保持してくれるらしく、実際にデータ検索を行わないので高速になるそうです。こんなの知らなかった。ありがとうございました！
プログラムはサンプルがあるからどうにかなるんですが、サーバー周りの事が全然わかりません。。。。ぐうぅぅ。。。。
おやすみなさい。
-------------------------------------
ブックマークコメントもらっていた事を別の日記で説明しました。
http://anond.hatelabo.jp/20101206224349
-------------------------------------
今までSOHOでやっていたWeb制作の事業を法人化することになったので、
使用CMS:不明、まさかのベタHTML？ブログからのRSSのみで更新
使用アクセス解析：独自PHP＋Google Analytics
===所感
たぶん業界最大手の風格。電話番号のゴロあわせがいまいち意味不明。
全体的なデザインとしては流行に左右されない白ベース。おそらくYahooの
リニューアルされた頃に流行った900px周辺のデザインの頃に作られたもの。
仕方ないことだが中年の男性の証明写真みたいな顔が並んでるのでちょっと怖い。
使用CMS:不明、まさかのベタHTML？ブログからのRSSのみで更新
===所感
ランディングページ万歳！といった作り。JQueryの必要性がいまいち見えない。
SEOにかなり力を入れている→その効果もクライアントへのフィードバック。
個人情報保護方針の記載の中の「クッキー」がカタカナなのがかわいい。
使用アクセス解析：Google Analytics、Lapis、mogura。多い。
===所感
ランディングページとコーポレートサイトの中間みたいなデザイン。
というか途中から方針変更したのか？パーツによって質にバラツキ有り。
○総評
他にも色々みてみたけどなんか全体的にあんまりWEBに力を入れてなさそうな
雰囲気。外注先に投げました！納品されました！OK！って感じ。
そういうもんなのかしら。
まだあまり話題になっていないようだけど、とんでもない事態だと思う。
米Apple社、ユーザー自作のePub電子書籍もiBooksアプリで自由に閲覧できることを明らかに
http://hon.jp/news/1.0/0/1477/
EPUB（いーぱぶ）とは米国の電子書籍標準化団体の1つであるInternational Digital Publishing Forum（IDPF）が普及促進するオープンな電子書籍ファイルフォーマット規格。
http://ja.wikipedia.org/wiki/EPUB
単なるテキスト形式(XHTML)なので、形式さえ守れば誰でも書ける。
これが見本。
http://www.kobu.com/docs/epub/index.htm
DRMがかかっていない電子書籍の読み込みを許可したってことは、ePub形式が音楽で言うMP3にあたるものになるはずだ。
つまり近い将来、現在zipでばらまかれているような漫画などの出版物が、さらにキッツいことになる。
単なる画像の集合体で、解凍や閲覧ソフトのインストールなどの敷居があったzipではなく、リーダーと標準仕様が出来てしまった場合、一般層に恐ろしい勢いで普及するはず。
iPadは単なる点火台でしかなく、数年後には３千円とかのレベルで電子書籍リーダーがその辺のTSUTAYAなどで売っているような事態になるだろう。まさにmp3プレーヤーと同じ流れだ。
スキャナ→OCR(文字認識)→ePub形式にフォーマットを整え、配布出来る状態にするような一連の流れを自動化するソフトもあっという間に整うと思われる。
そして違法アップロードに対抗するために国内出版社は電子書籍にガチガチのDRMを掛け、消費者にそっぽを向かれる。
しかし結局DRMの掛けようがない紙による出版をやめるわけにもいかず、結局流出は止まらず、出版業自体が沈没して行く。
この辺は音楽CDと同じ流れ。
混乱Loverなら喜ぶのかもしれないが、本屋としては死刑宣告をされたようなもの。困ったもんだ。
生き残るには自らが破壊者側に回るしかないというのもなあ。
最近マークアップエンジニア志望の若者と話す機会が多いのだけれど、そこで気づかされるのは、彼らの中に過去のHTML（特に90年代以前の仕様）を読んだことのあるという人が、驚くほど少ないことだ。
例えば「マーク・アンドリーセンをどう思う？」と聞くと、「アンドリーセンって誰ですか？」という答えが返ってくる。「ヨスケの独自要素で何が一番好き？」と聞くと、「見たことがありません」と言われてしまう。「ではきみは、昔のHTMLを見たことがあるの？」と聞くと、たいていが「とほほでやっていたものくらいなら……」という答えしか返ってこない。
今の若い人の間では、HTMLを体系的にとらえようという人は少ないようだ。見るのは専ら近年の話題仕様ばかりで、歴史を辿ってみたり、系譜をひもといて標準化団体ごと理解しようとする人はほとんどいない。
これは、ちょっと由々しき問題だと思わされた。HTMLは、もう長いこと（90年代の早い時期から）インターネットの王者としてあらゆるWeb関連技術の上に君臨してきた。だから、Webを作ることを仕事にしたいなら、何をするにせよ避けて通ることはできない。
HTMLは、表・画像・フォーム・音楽・デザイン・フレーム・動画など、さまざまな分野においてその時代々々に達成された最新の成果を持ち寄るようにして作られてきたところがある。だから、HTMLを読まずして現代のインターネットは語れないと言ってもいいくらいだ。
もし何かクリエイティブなことをしたいのなら、HTMLを読むことは欠かせない。また、単に読むだけではなく、それを包括的・体系的にとらえることも必要だ。なぜなら、HTMLを包括的・体系的にとらえることによって、現代のインターネットそのものを、包括的・体系的にとらえられるようになるからだ。そしてそうなれば、Webを作ることの道理や筋道が理解でき、何かクリエイティブなことをする上で、大きな助けとなるからである。
そこでここでは、昔のHTMLをほとんど見たことがないという人や、あるいはHTMLそのものもあまり見ないという人のために、これを見ればHTMLを体系的に理解でき、現代インターネットの成り立ちや実相までをも包括的にとらえることができるようになる、7本の仕様を紹介する。
ここで紹介するHTMLは、いずれも後のWeb業界に決定的な影響を与えたものばかりだ。これらが、HTMLという標準のありようや方向性を決定づけた。この7本を見れば、HTMLというのはどのようなきっかけで生まれ、どのような変遷を辿って、どのような足跡を残してきたかというのが、体系的に理解できるようになる。そしてそれが、世界のインターネット利用シーンにどのような影響を及ぼしてきたかということも、知ることができるようになるのだ。
まず最初は、ちょっと強引かも知れないけれど、第一次ブラウザ戦争前のHTMLをひとまとめにするところから始める。
80年代末にティム・バナーズ＝リーの発明したHTMLというメディアは、その後『HTML 1.0』（1993年）『HTML+』（1994年）『HTML 2.0』（1995年）などの仕様で次第にそのスタイルを確立していき、マーク・アンドリーセンが一大産業として発展させた後、『HTML 3.0』に行き着く。そして幸運なことに、ここに集大成されるのだ。
ブラウザ戦争前のHTMLは、これ1本だけ読めば良い。このHTMLに、戦前のHTMLの全ての要素（属性）が詰まっている。このHTMLを見れば、HTMLのインターネットの王者としての風格、スターという存在の大きさ、作者以上にブラウザが重視される「産業」としての側面、お尻Pから終了タグ省略可へ・文字情報から画像付きへと移り変わった技術革新の変遷など、戦前のHTML史やWeb業界のありようが全て分かるのだ。
このHTMLの魅力は、説明し始めるといくら紙幅があっても足りないので、ここではその一端を紹介するにとどめておく……といっても、気の利いたことを言えるわけではない。『HTML 3.0』の魅力を知るには、まずは読んでもらうこと――これに尽きるからだ。そして、もし一度でも読めば、その魅力はたちどころに理解できるだろう。
『HTML 3.0』を見て驚かされるのは、現在のHTMLと比べても全く遜色ないところである。破棄されてから14年の時が経過しているが、現代人の読解にも当たり前のように堪えうるのだ。それは、逆にいえばHTMLというものは、今から14年前、つまりこの『HTML 3.0』が作られた時点で、様式として一つの完成を見たということでもある。
『HTML 3.0』は、HTMLという標準が到達しようとした一つの極みである。それゆえ、HTML史というものは、『HTML 3.0』以前と以降とで分けられるようになった。これ以降に作られたHTMLで、『HTML 3.0』の影響を免れたものはないからである。
iモードが世界のHTML史に与えた影響というのは、一般に理解されているよりもはるかに小さなものである。日本人というのは、「日本の技術が世界に影響を与えた」というと、なぜか鼻高々と聞いてしまうところがある。「日本はガラパゴス」という言葉は聞いたことがあっても、「それって日本人が過小評価しているだけじゃないの？」と、眉に唾をしてとらえるところがある。
しかしiモードは、真に日本のHTML史を塗り替えたサービスの一つである。特に、このサービスの後世に与えた影響には、本当に計り知れない大きさがある。
iモードは、ドコモのメインストリームだったポケットベルが、それまでの栄華の反動で深刻な低迷期に陥っていたPHS流行後すぐの時期、そんなポケットベルに取って代わって、日本で最も輝いていた携帯サービスであった。それゆえ、広末に見蕩れた世界のHTMLファンたちは、iモードのWebサイトを見ることによって、失われかけていたWeb制作の魅力を再発見することにもなったのである。
iモードは、没落したHDMLに変わってモバイルWebの命脈をつなぎ止めた、言うならば救世主のような存在であった。海外のモバイル陣営が営々と築きあげてきたそれまでの栄光を切り捨て、日本の後代へと引き継いだ重要なリレー第一走者としての役割を、HTML史において担ったのである。
そして、そのバトンを受け取った日本の若きWebデザイナーたちが、2000年代に入って雨後の竹の子のように現れたことで、モバイルWebは鮮やかな発展を遂げる。だから、もしiモードが存在しなければ、HTMLの様相は今とは違ったものになっていたかもしれないのだ。
そんなiモードHTMLのバージョンはいくつもあるのだが、中でも特に多くのHTMLファンを――取り分け日本の若きWebデザイナーたちを魅了したのが、この『Compact HTML』である。この仕様の一番の魅力は、なんといってもその大胆に構築されたW3C Noteであろう。HTML史において、これほど拡張多く適当なディテールで構成されたNoteは他にない。そのためこのNoteは、これ以降無数に手本とされ、真似され、拡張されることとなるのである。
正字正仮名の影響を受けた日本の若き日記書きたち――言うなれば「CSSコミュニティ」――が頭角を現す直前のW3Cで、HTML史に乾坤一擲の巨大な爪痕を残した1本の仕様が誕生する。
この時期、情報技術の進歩によって、HTMLにもさまざまな新しいテクノロジーがもらたされていたのだが、それらを十全に取り入れたばかりではなく、縦横に駆使することによって、これまでとは全く違った国際化、全く違ったアクセシビリティ体験を生み出すことに成功したのが、この仕様『HTML 4.0』を勧告したWorld Wide Web Consortiumである。
『HTML 4.0』は、HTML史において最も革新的な仕様の一つとなった。この仕様に初めて触れた当時のWebデザイナーたちは、そのあまりの目新しさに度肝を抜かれた。そこでは、これまで全く見たことのないマークアップがくり広げられていた。そのため、これまで想像さえしたことのなかった全く新しいHTML体験を、そこで味わうことになったからである。
W3Cの果たした一番の功績は、テクノロジーとHTMLを見事な調和をもって融合させたことだろう。例えばそこでは、「スタイルシート」という新しい技術のデザインと、それでレイアウトされたページが閲覧者に与える独特の感覚というものを、双方ともに熟知していた。だから、それらを効果的に融合させることによって、全く新しいHTML体験を生み出すことができたのである。
この仕様『HTML 4.0』には、そうしたテクノロジーとHTMLとの融合が、至るところに散見できる。その数の多さとクオリティの高さによって、HTMLはここに、新しい時代の幕開けを迎えるに至ったのである。
先に述べた「CSSコミュニティ」がWeb日記業界に論争をもたらすのは、2000年代に入ってからのことである。そして、そのきっかけとなったできごとの一つが、1947年生まれの非政府組織で、IECとも協力した生粋の工業標準化団体であった国際標準化機構が、この仕様『ISO/IEC 15445:2000 (ISO-HTML)』によって成功を収めたことである。
このHTMLは、単にJIS的に標準化しただけではなく、文化的な意味においても、フラットでリニアな構造の力を広く世界に知らしめることとなった。この仕様の成功によって、世界の人々は、レベル付けされた見出しの魅力の大きさを知る。そしてそれが、やがて見出しのレベル分けが世界のスタンダードとなり、誰もが当たり前のように使う状況を育んでいくのである。
またこの仕様は、CSSコミュニティそのものにも大きな影響を与えた。この仕様の成功に刺激を受けた才能ある若きコミュニティ住人たちが、その後立て続けに台頭し、いくつもの名サイトを生み出していくからである。
それらが相まって、やがてCSSコミュニティは空前の黄金時代を迎えることになる。その端緒となり、道筋を切り開いたのが、他ならぬこの『ISO-HTML』なのだ。
『HTML 4.0』で繁栄の足がかりを築いたW3Cは、この仕様『XHTML 1.0』によって、ついにその栄華の頂点に達する。そして、それを成し遂げたメタ言語も、W3C勧告のの一つであり、また『HTML 4.0』を作ったSGMLの改良でもあった、Extensible Markup Languageであった。
この勧告は、史上最も商業的に成功した仕様となる。そのためこれ以降、この勧告にならって商業的バズワードを盛り込んだ仕様が数多く作られるようになり、しかもそれらが、実際に大きな商業的話題を集めていくのだ。すると、そこで生み出された多くの意見は、やがて再びW3Cに還元され、さらなる発展をもたらすことにもつながった。
そんなふうに、この仕様がきっかけとなってW3Cにもたらされた意見は、HTMLという言語を変革させていくことになるのだが、それに伴って、HTMLそのものにも大きな革新をもたらすことになる。
その変革も、他ならぬW3Cの手によってなされた。ここで『XHTML 1.0』の成功によって手にしたメンバーをもとに創設した文書マークアップの開発集団「HTML Working Group」が、より魅力的な拡張性を追求していく中で、やがてM12n（モジュール化）という技術の開発に至るのである。するとそれが、これまでのHTMLを一変させたのだ。
M12nは、HTMLに魅力的かつ効果的な特殊語彙を、DTDでしかも複雑怪奇にもたらすことに成功した。おかげでそれは、あっという間に世界から見捨てられていった。そのため今では、M12nの使われているHTMLを探す方が難しくなったくらいだ。それくらい、この『XHTML 1.0』がWeb業界にもたらした変革には、大きなものがあったのである。
2000年代以降、繁栄を謳歌したW3Cは、しかしその栄華の大きさゆえ、00年代中盤に入るとそれを存続させることに力をそがれてしまい、革新的な仕様はなかなか生まれてこなくなった。
しかし、そんな時代が5年は続いた00年代の後半になって、今度はその栄華のただ中で育った新しい世代のHTML WGメンバーたちが台頭してくることにより、再び変革の時を迎えることとなる。
その新しい世代のHTML WGメンバーとは、マイクロソフトやモジラ・ファンデーション、オペラらに代表される「ブラウザベンダ」と、無関係な編集者たちであった。
彼らに共通するのは、文書構造に不必要なものなら全て――とるに足らないガジェット的なものまで含めて――残らず切り離そうとする「オタク的な性質」を持っていたことだ。
彼らは、それまで見過ごされがちだったHTMLの些末な要素にスポットを当て、それを別仕様に押し出すことで、従前とは一風変わった、新たな魅力を持った草案を生み出していった。そして、その真打ち的な存在として00年代の後半に登場したのが、XHTML2 Working Groupだ。
XHTML2 WGは、特に99年に最後の草案が作られたこの仕様『XHTML 2.0』によって、オタク的なHTMLの楽しみ方が、一部のマニアだけにとどまり、それ以外の多くの人たちには受け入れられないことを証明してみせた。この失敗が、デ・ファクト的な新生HTML WGにさらなる脚光を浴びせることになったのはもちろん、それに影響を受けたWeb WorkersやDOM Level 3 Eventsといった、次世代のWeb標準たちの誕生にもつながっていったのである。
最後は、第二次ブラウザ戦争の集大成ともいえるこの仕様である。
『HTML5』は、HTML史においては『HTML 3.0』と同じような意味を持つ。つまり、それまでのHTMLの要素が全て詰まっているのだ。この仕様を見れば、それ以前のHTMLの歴史というものが全部分かる。
『HTML5』には、HTMLのあらゆる要素が詰まっている。ここには、『HTML 3.0』のような歴史的な仕様としての「総合性」があり、『Compact HTML』のような「実装の実在さ」がある。『HTML 4.0』のような「マルチメディアとアクセシビリティの融合」があり、『ISO-HTML』のように「セクション構造の魅力を全世界に知らしめ」た。また、『XHTML 1.0』のように「バズワード的に成功」したのはもちろん、『XHTML 2.0』が別仕様に押し出した「オタク的ガジェット」にも満ちている。
全て詰まっているのだ。なんでもあるのである。つまりこのHTMLは、『HTML 3.0』と全く同じ意味合いを持っているのだ。HTML史というものは、『HTML5』以前と以降とで分けられる。これ以降に作られるHTMLで、『HTML5』の影響を免れるものはないであろうからである。
以上、これさえ読めばHTMLを包括的・体系的にとらえることができる7本の仕様を、制作された年代順に紹介した。
こうして見ると面白いのは、歴史的に重要な仕様は、必ずしも定期的に現れるのではなく、あるところでは連続しているし、あるところでは長らくなかったりすることだ。それはまるで「素数の分布」のようだ。一見規則性はないように見えるものの、何かしらの法則が隠されているようでもあり、興味深い。
それから、ここに挙げた仕様は、いずれも「読むことによって他の仕様にも興味が移行する」ということを念頭に選んだ。
例えば、『HTML 3.0』を読んだならば、ブラウザ戦争前夜の独自HTML拡張に自然と興味がいくだろうし、『Compact HTML』を読んだなら、iモードのそれ以外のバージョンのHTMLも見たくなるだろう。CSSコミュニティについてもそれは言えるし、『ISO-HTML』を読んだなら、このHTMLを流行らす土壌ともなった「フラットでリニアな構造」というムーブメントにも自然と興味がわくはずだ。さらには、『XHTML 1.0』はXMLオタクになるきっかけになるだろうし、『XHTML 2.0』はその他の「オタク的なXML EventsやXForms」の仕様も見たくなるという効果を持っている。
ただし、最後に選んだ『HTML5』だけは、こうした例とは別に考えなければならないかも知れない。なぜならこのHTMLは、完成度があまりにも高いために、これを見た後に他のHTMLを読むと、どうしても物足りなく感じてしまうからだ。
しかしいずれにしろ、これらの仕様を読むことによって、HTMLをさらに愛さずにいられなくなるのは疑いない。そしてまた、これらの仕様を読むことによって、HTMLを包括的・体系的に見る目を養ってもらえれば、その後のクリエィティブな活動にも、大きな助けとなるはずだ。
上に挙げた仕様への理解は、以下に紹介する著作を読むことによって、さらに深まる。これらを読むことによって、ぼくは「HTMLを体系的に見るとはどういうことか」を学んできた。
高校時代に読んだこのサイトによって、「リソースとは何か」ということを、ぼくはを知った。
「HTMLはSGMLの応用だ」ということが、このサイトを読むことでよく分かる。何気なく見ていた省略記法でも、その裏には、実にさまざまな技術や、それを開発してきた歴史というものが隠されていた。
世界がCSSコミュニティの何に驚かされたかといえば、それはやっぱり精緻に書き込まれた正字正仮名にだ。ノジタンの日記には、HTMLの本質が詰まっている。だからこそ、あれだけ多くの日記で多くのコミュニティ住人に、言及されたり模倣されたりしたのだ。
ここでは取りあげられなかったのだが、とほほ氏がHTMLというジャンルに及ぼした影響にも、本当に大きなものがある。そして、ぼくが上に挙げた感想のいくつかは、このサイトに書かれていたばけらさんとの「スタイルシート論争」を参考にしたものなのだ。
これらのサイトを読めば、どんなHTMLが素晴らしく、どんなHTMLがそうではないというのが、よく分かる。その判定基準を知ることができ、審美眼を養うことができるのだ。なにしろ、あのCSSコミュニティ住人の言うことなのだ。これにまさる教科書は、他にはない。
【元ネタ】
フリーター生活を終わらせるため、
用意したものは、
勉強したことは、
・HTML(XHTML含む)、CSS、Javascript、フラッシュ（基礎的なことのみ）、
PHP（基礎的なことのみ）
・色彩検定
・MTとWP（基礎的なことのみ）
バイト先のパソコンにフォトショップとワードとエクセルがインストールされていたため、
こっそり勉強させてもらった。
イラストレーションや、Macは触る機会が得られなかったのでちょっと不安。
で、面接は大成功。準備したかいがあったなー・・
と思ってたら、面接官が時間があるなら社内見学しないか？って誘ってくれた。
凄く嬉しい。もう採用決まったようなものだ！と思った。
で、社内見学したんだけど、何か色々ひどい。
webデザイナー、ディレクターとされる人がHTMLの参考書見ながら打ってる・・
フリーソフトかよ・・ドリバを使うんじゃなかったっけ？・・
真面目そうな人と思ったらニコニコ動画みてた・・
最後に面接官が、
とりあえずXHTML+CSS、フォトショ、イラレ、Fireworksは問題無く使える。
それに加えて、PHPとJavascriptとFlash(ActionScript含む)は、
簡単な物であればとりあえず困らない程度使える。
一応このへんは引き続き強化していきたいとは思っている。
デザインセンスは、「目的に合わせた」デザインが出来る…と自分では思っている。
正直なところ、目を惹くタイプではない自覚がある。
色とかレイアウトとか、センスよりも勉強してやってる感じだと思ってくれればいいと思う。
今20代後半なんだが、この先もこの職で食っていく為には、何を勉強したらいいだろうか。
プログラムも楽しいけど、どちらかというとデザイナ寄りで食っていきたい。
ちなみに、余程どこかで変化があればわからないけど、
http://takahashifumiki.com/others/480/
まぁまぁまともな生活ができる楽園なんだからさー。
アンタのような頑張り屋さんで能力が高い人が
わんさか来ちゃうと、居場所なくなってしまうでしょ。
しーえすえすないと見ればわかるでしょ？
俺らがスイーツ(笑)だって。
これを知らなきゃ始まらない。
当然一度くらい仕様書読んでるよね？
「・・・」
クソプログラマがわけわかんねぇ実装するから
俺たちはこんな苦労してんだ。
あー忙しい忙しい。
うんそうだね。でもあと5年もすれば
そんな知識ほとんど必要なくなるけど
ほかに何ができんの？
「・・・」
見てみろよこのきらきら感。
同じようなレイアウトで違いがわからないんだけど？
「いろいろサイト見て参考にしてるんで・・・」
まぁ0->1を生み出せる人間なんてほとんどいないわけだから
君たちは1を1.1にしてくれればいいよ。
「・・・」
・・・じゃあなんでこの位置にこのボタン置いたの？
「・・・なんとなく」
wwwwww
なんとなくって何だよwww
クリエーターが自分の作ったもの説明できなくてどうすんだよwww
見た目だけパクってんじゃねーよ。
結構絵を描いてきてるんだよね？勉強してるんだよね？
この画像パース狂ってるし光源がわけわからなくて気持ち悪いけど？
「・・・」
アナログできねーやつが
色についてちゃんと勉強したの？
「イキル。なんかクールじゃないですか？？」
色の本は1冊くらい読もうよ。
うんうん重要だね。
「・・・」
多くの人に見てもらいたいんすよ。
うんうん。そうだね。
で、ガイドラインは当然読んでるんだよね？
「・・・」
おぉさすがクリエーター。センスあるね。
ところでさっき言ってたユーザビリティ、
アクセシビリティとか考えているんだよね？
「・・・あぁまぁ一応」
で、どこクリックすればいいの？
「・・・」
半端な知識で設計されても後々困るからやんなくていいよ。
無茶な要求しやがって。こういうわけわかんねぇ
「・・・？」
別に.confには触れなくていいから、
.htaccessくらいは設定できるようになろうよ。
興味ないの？死ぬの？
「イキル。でも興味はありません。」
内容が同じファイルUPしたのに動かない・・・
パーミッションが違うよ。
どういう意味か調べないの？興味ないの？死ぬの？
「イキル。でも興味はありません。」
フォームなんていろいろあるから
適当に選んでUPするだけでだろ。簡単簡単。
え？確認画面がほしい？
「無理です。」
別にアプリケーション作れとは言わないけどさ
単なる問い合わせメールフォームくらいつくれない？
簡単なカスタマイズもできないようじゃ
顧客の要求にこたえられないだろ。
やっぱ今はAjaxだよね。スクロールしてもサイドバーがついてくるんだぜ！！
ライブラリ読み込んでるだけじゃね？
しかもDOMってるだけだよ。
アプリケーション作れなんて言わないから
君らクリエーターならこのナビゲーション
俺ならこうするって思うことないの？
「・・・ライブラリで充分です。」
またバカなクライアントから修正きたよ。
まぁ俺がサービス名間違ってたんだけど。
確認しないの？
ふーん。ちなみにIE6でレイアウト崩れてるけど？
「・・・」
で、なんでその誤字の修正に3時間もかかってんの？
「だって100ファイルもあるんですよ？俺じゃなきゃ1日あっても終わらねっす。」
君らが大好きなDreamweaverで多少正規表現使えなかったっけ？
1分で終わるよ。自分使うツールの機能に興味ないの？
忙しい忙しいって無能なだけでしょ？
「興味ないです。CSSをダイアログで設定する機能くらいしか使わないです。」
これまでのようにやっぱり自分が満足できる
うんうん自分が納得できるものを作るのは大事なことだね。
サイト見てるユーザが全然満足してないんじゃない？オナニーなの？
「・・・でもクライアントはきっと満足してますよ。俺のオナニーすごいし。」
売れるサイトが欲しいんだよ。
なんとか売るのがてめぇらの仕事だろが。
一流プログラマ様が作ってくださった物をまったく理解しようともしないで
いじくってるバックボーンなきスイーツ(笑)なんだからさレベル高い奴はくんな。
こんな程度のスキルで4、500万は稼げちゃって
やっすいキャバでもオークションのやり方教えてとかブログのやり方教えて、
とか言われてお家行ってにゃんにゃんできちゃうわけだから出たくねーよこんな楽園。
しかもこんな能力じゃ楽園でたらどこも行くとこないよ。
努力しないでそこそこの金がもらえて
おしゃれって思われる仕事を用意するのが政治だろって訴えますよマジで。
残らないだろうけどなwww
オワタwww
// ==UserScript== // @name anond // @namespace http://anond.hatelabo.jp/ // @include http://anond.hatelabo.jp/?page=* // ==/UserScript== function anond(doc) { $X(".//div[@class='section'][.//h3/a[2][starts-with(@href, 'http://anond.hatelabo.jp')]]", doc, Array).forEach(function(node){ node.style.display = "none"; }); $X(".//h3/a[1]", doc, Array).forEach(function(node){ var a = document.createElement("a"); a.name = node.pathname; a.href = "#" + node.pathname + "/footer"; a.innerHTML = "V"; node.parentNode.insertBefore(a, node); }); $X(".//p[@class = 'sectionfooter']/a[1]", doc, Array).forEach(function(node){ var a = document.createElement("a"); a.name = node.pathname + "/footer"; a.href = "#" + node.pathname; a.innerHTML = "^"; node.parentNode.insertBefore(a, node); node.parentNode.insertBefore(document.createTextNode(" | "), node); }); } anond(document); if (AutoPagerize.addDocumentFilter) AutoPagerize.addDocumentFilter(anond); // by http://lowreal.net/blog/2007/11/17/1 // $X(exp); // $X(exp, context); // $X(exp, type); // $X(exp, context, type); function $X (exp, context, type /* want type */) { if (typeof context == "function") { type = context; context = null; } if (!context) context = document; var exp = (context.ownerDocument || context).createExpression(exp, function (prefix) { var o = document.createNSResolver(context).lookupNamespaceURI(prefix); if (o) return o; return (document.contentType == "application/xhtml+xml") ? "http://www.w3.org/1999/xhtml" : ""; }); switch (type) { case String: return exp.evaluate( context, XPathResult.STRING_TYPE, null ).stringValue; case Number: return exp.evaluate( context, XPathResult.NUMBER_TYPE, null ).numberValue; case Boolean: return exp.evaluate( context, XPathResult.BOOLEAN_TYPE, null ).booleanValue; case Array: var result = exp.evaluate( context, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null ); var ret = []; for (var i = 0, len = result.snapshotLength; i < len; i++) { ret.push(result.snapshotItem(i)); } return ret; case undefined: var result = exp.evaluate(context, XPathResult.ANY_TYPE, null); switch (result.resultType) { case XPathResult.STRING_TYPE : return result.stringValue; case XPathResult.NUMBER_TYPE : return result.numberValue; case XPathResult.BOOLEAN_TYPE: return result.booleanValue; case XPathResult.UNORDERED_NODE_ITERATOR_TYPE: { // not ensure the order. var ret = []; var i = null; while (i = result.iterateNext()) { ret.push(i); } return ret; } } return null; default: throw(TypeError("$X: specified type is not valid type.")); } }
