  |
はてなキーワード: リサイズとは
確定やね
ウンザリするのでやってないが
ウンザリするところ
・写真や画像のご用意頂けない。頂けても数枚かつ写真の画像のリサイズ／リデザイン(合成や色味調整)を無限に要求
・テキストをご用意頂けない＞何度も要求すれば最終的にはくれるが・・・
・SEOを期待される＞最終的にはホームページは看板や身分証明書であって広告と考えない方が良い。どうしてもなら別料金＞有料ならじゃあいいや
営業力のないワイ氏に舞い込む副業の仕事ってこういうのしかない
・レスポンシブWebデザインで、なんか1つTOPに動く絵があれば、凝っている必要はない
・WordPressでもhtmlベタ打ちのWEBサイトでもいい
・ドメイン取得などの作業も代行(ドメインやサーバー費用は請求可能)
・写真や画像のご用意頂けない。頂けても数枚かつ写真の画像のリサイズ／リデザイン(合成や色味調整)を無限に要求
・テキストをご用意頂けない＞何度も要求すれば最終的にはくれるが・・・
・SEOを期待される＞最終的にはホームページは看板や身分証明書であって広告と考えない方が良い。どうしてもなら別料金＞有料ならじゃあいいや で、ご納得は頂けるが・・・
表題の通り。
それまでデフォルトアイコンだったんだが、昨日の夜に変更した・・・はずなんだが、今朝見ても変わってない。
最初は http://profile.hatena.ne.jp/(ID)/ から 1024x1024px の画像をアップロード。
“変更が反映されるまで、多少時間がかかることがあります。” とのことなので10分程度待ってみたが、変わらない。
サイズが大きかったせいかと考えて、あらかじめローカルで 64x64px にリサイズしたり、形式を jpg・png・gif に変えたりしてみた（3〜8KB程度）が結果は同じ。
どういうことかというと、 http://profile.hatena.ne.jp/(ID)/ を見ると、ここの画像はちゃんと変更されてる。
はてブのエントリページ ( http://b.hatena.ne.jp/entry/〜 ) やはてブマイページ ( http://b.hatena.ne.jp/(ID)/ ) で表示されているアイコン画像の URL は、
? が付かない profile.gif (上の例の 3. )
(ただし、ヘッダの「マイページ」の左や、お気に入りユーザがずらっと表示されてる所の小さいアイコン
( https://cdn1.www.st-hatena.com/users/(ID)/(ID)/profile_s.gif ) はちゃんと変更されてる)
結論としては、「http://cdn1.www.st-hatena.com/users/(ID)/(ID)/profile.gif が、数時間以上経っても変更されない。」
これまで放置されてたってことは ID によって起こったり起こらなかったりするのかもしれないが、対応よろしくおねがいしますよ、はてなさん・・・。
プログラマにはデザインも拘る人もいれば、「デザインとかみれればどうでもよくね」って人もいる。
ウチでは後者の人が多い。
企業向けシステムを受託で作ってるんだが、これを売るのかってレベルで醜い。
webシステムなんだが、ボタンやテキストボックスがマージン0でくっついて並んでたり、
テーブルは枠に収まらないのではみでて全体にスクロールバーがついてたり、
ある程度までウィンドウをリサイズすると崩れるのに最低幅を指定もしてない。
マージンは揃えないのに、同系統は同じで別系統は別になるように作っていたところを全部同じに統一しろ言ってたりもする。
見た目には影響ないが、9割のタグがdivでできているプロジェクトもあった。
公開するwebサービスだったら一瞬で叩かれるだろってレベル。
勉強仕立ての学生に無茶な納期で押し付けてできたものと言っても信じられるほど。
私自身でも使わないだろう。
動作チェックなどで使っているときに見た目でストレスを感じていた。
もちろん納品先からはもっと統一してとか幅がおかしいとかマージンがどうとか言われてる。
ただ最低限の言われた部分しか対応しないし、言われたことに「こんなの別にいいだろ」なんて言ってる。
いや、どうみてもおかしいしこれでいいとか美的センスは大丈夫なのかと言いたい。
結局、納品先からの注文も途中でどうしようもないと思ったのか最低限見れる程度、になってる。
受託といえど、使うのがその会社だけでなく一般の人という場合もある。
それでもいつもどおりの残念な見た目だった。
自分で作るところは上記のようなものだと気持ち悪いからどうにかするが、全体で読み込まれるCSSのせいでどうにもできないこともある。
そこだけ上書きで何かしようとすると、一部だけ特殊なことはしないでと言われる。
プロジェクトを管理する人兼全体の枠を作る人がデザインに対するこだわりなんて全くない人だからどうしようもない気がする。
せめてマージンくらい揃えたいと思っても全体的にひどい（もちろんできるかぎり揃えてる人もいるが）ので他人の担当箇所まで直してられない。
たまたま見つけてデザイン的なズレのせいでバグにも見える挙動があったので、直すべきでは？と提案してみてもそのスタイル使ってるところ多いから全体的に影響多いし、とそのままにするらしい。
デザイナはいないのか、と思う人もいるだろうが、少し前まではいた。
いたところで、デザインを作ってという仕事が来たら担当していただけで、webシステムの場合は基本関わってこない。
プログラム書くひとがCSSもできるということでデザイナはそもそもプロジェクトがどういうものか知ってるのか不明というくらい。
ところで、プログラマについての愚痴を書いたが私も職業はプログラマ側だ。
ただwebデザインが好きで、もとはwebデザイナになろうと思っていた（就活中に日本だとCSSのスキルじゃなくてフォトショで画像作るのばかり求められていてやりたいことと違ったのでプログラマにした）。
今でも頻繁にこういうデザイン作りたいなと思ってはHTMLとCSS書いてるし、技術文書を読んで次に使えるようになる新しい機能を調べてたり、一部ブラウザで使えるようになればすぐに試したりしている。
デザインセンスについても、昔は絵を書けば何らかの賞はもらったし、学生時代のポスターでは、数百人の中からデザイン系で最優秀となったことがあるので、平均以上にはデザインもできるとは思ってる。
なので、デザイン苦手なら任せてくれればやるつもりだった。
しかし、そういった先輩方がいうにはおまえはデザインセンスがない、らしい。
「え、あなたがそれ言うの？」ってすごく言いたかったが仮にも先輩なので、「そうですか」とだけ言っておいた。
まあ、プログラマとして入社したんだし、変なセンスの上司からあれこれ言われながら作らなくて済むから別にいい。
ただ、センスない人が管理してるばかりにエンドユーザになる人達がかわいそうだなと思う。
デザイナがいなかったり重要視されてない会社ならどこもこんなものなんだろうか。
これで思ったのは、プログラマとして優れててもデザイン的な理解がない人を上にしてはいけないということ。
社長が取ってきたプロジェクトだと社長がチェックするからこういったひどいデザインだと厳しく指摘されてる。
ただそれ以外までチェックはしていなくて、プロジェクトの管理する人はあの見た目でOKしてる。
こういう人が上だとだめだなって思った。
12インチのiPad PRO使ってるんだけど、勢いでSmart keyboardも買ったのね。
パソコンの代わりになったらいいなって思って。
画面も大きいからご飯食べながら映画見たり漫画読んだりかなり捗る。
最初のうちはうれしそうに何でもSmart Keyboardで入力してたんだけど、やっぱりそのうち面倒くさくなってKeyboardを開く機会がちょっとずつ減っていったのね。
それで先日ご飯食べてる時に増田のネタ思いついたから、久々にSmart Keyboardで書いてみようかなって思って開いてみたの。
そしたらキーボード上に白い小さい点がてんてんてんてんって無数にあって、なんだろうってよく見たら全部虫。
まじまじと見ちゃったから目線の5cm先くらいでホコリサイズの虫が大量にわらわらとうごめいてやんの。リアルに悲鳴でた。ギャー。
速攻でウェットティッシュで全部拭き取って、外に持っていてバンバンはたいて。
食欲はなくなるはせっかく思いついたおもしろ増田のネタ（ブクマ1000は鉄板だった）は忘れるはろくなことない。
Smart Keyboardの裏側って毛が生えてるのね。画面を守るためだと思うのだけど。
キーボード部分をその毛が生えた内側に巻き込むから寝床にはもってこいな作りなわけ。
ご飯食べながら使ってたからそこにその食べかすやら汁やらが飛んでここなんてオアシス？状態。
しかも日中の室内は高温多湿。むしろ湧虫しないほうがおかしいわ。
それから一週間してこの増田を書いてるのだけど、なぜ今書いているかというと、一週間前の出来事を急に思い出して恐る恐るSmart Keyboardを開けてみたから。
やつらの生命力を舐めてた。
お金が無いのと、興味本位なのとでなんとなくな気持ちで出会い系に書き込んだ。
今まで友達と釣りで出会い系掲示板に通話アプリのIDを投げては食いついてくる脳内ちんこ男たちの必死さに笑っていたのに、今度はこっちが必死だ。
「○○駅で△時から話のわかる人で会える人」と呼びかけると釣りの時よりメッセージを送ってくる人は減った。
そりゃタダマンできないもんね。
送られてきたメッセージは色々だった。
○○駅でと言ってるのに遠い駅で会う前提で話を進めてくる人、
5時間生外出し目隠しレイププレイを条件にする人(7万円とか言われたけど流石に怖かった)とか印象に残っている。
結局あまりにも年上は嫌だと思い写真を見た感じほんとに普通っぽい29歳の会社員の人に通話アプリのIDを送った。
すぐに詳しい待ち合わせ場所、条件が決まる。
私はこの知らない人に2万円で処女を売ることになった。
駅で待ち合わせをするときが一番後悔していたし一番迷った。
本当にこういうことするのが悪いことなんて分かり切っている。
今なら連絡もせずすっぽかして何もなかったように家に帰っても遅くない、そうだ今すぐ派遣の仕事を探して面接に行こう。
それぐらい全身に汗かきながら迷った結果待ち合わせの時間までその場で動けなかった私は服装を教えてたのもあってすぐに声をかけられた。
軽く自己紹介して話しながらホテルへ、高校生の時ぶりに男の人と手を繋いだ。
道中名前とか大学とか色々聞かれたけど適当にフェイクを入れた。
口からでまかせみたいにぼろぼろ嘘をついてたら自分が自分じゃないみたいな気がしてきて、ここではもう嘘で作り上げた「女子大に通ってるけどサークルにもほぼ行かず、バイトしてるけどお金が足りない、エッチなことにちょっと興味があるみゆちゃん」になりきろうと思った。
実際きっかけは間違ってないし全部嘘ってわけではないけど。
ホテルでどの部屋が良いか聞かれたけどどれがどうとか分からなかったから普通のところでって言ったら、赤いベッドの部屋を選ばれた。
狭いエレベーターに乗り込んだら緊張してる？とかエロ同人で見たようなセリフを耳元で囁かれてものすごく逃げたくなった。
ドアの前のランプが光ってる部屋に入ると想像よりも狭い部屋だった。
小さい机とソファー、その隣にダブルサイズ？のベッド。あとシャワールーム。
そりゃセックスするための部屋だからそれ以外の機能が必要ないのはわかるけどちょっと怯む。
ドリンク1杯無料だったみたいで棚っぽいところを開いたら冷蔵庫がすっぽり入ってて感動したけどその上にオモチャの自動販売機まであって台無しだった(それまでラブホの自販機って概念がよくわからなかったからスッキリした)。
服は私と相手と同時に脱いだけどもう勃起してたし「好きにしていいよ」ってまたエロ同人で読んだようなこと言われたけどそんなこと言われてもどう触ったら良いかわからなかったし恐る恐る握ったけどどう触ったら正解なんだろう。
シャワーで風俗ごっこみたいに洗いっこして一緒のお風呂に入る。
こっちから今までの援交歴について聞いてみたところ、本当かどうかは知らないけどサクラとかとばっかり当たってて素人と当たったのは初めてらしい(これ2chまとめでみたやつだ)。
ベッドに入ってからは執拗に前戯された。乳首舐めるだけじゃなくて足舐め、アナル舐めまでされて内心キスしたくないと思ったけど諦めた。膣に指突っ込んでGスポット刺激しながらクンニとか執拗に私をイかせようとしてたのが分かったけど全然イけそうな感じがしなくて相手も疲れてきてるっぽかったから人生初演技をした。その人の名誉のために言っておくとちゃんと気持ちよかったけど、自分でするオナニーのほうが楽だなって感じがあった。挿入はほんとに痛くて演技する余裕もなくしばらく腰を振られてたけど、結局相手がイかないうちに「今日はもういいや」みたいなこと言って穴から抜いてくれた。なんかよくわからない申し訳なさをなぜか感じた。そのあとは初めてのフェラをして結局相手も発射しないまま終わった。
いわゆるピロートークをしてたらまた会いたいとか言われて、会うつもりはないけどいいよと返事をした。
流石に彼女になってほしいって話はそれはちょっとwと流したけど全く会うつもりもなくそのまま2万円もらってホテルから一緒に出て、駅の近くでお別れした。
ただ、人間は一度そういうことをしたらタガを外して繰り返してしまうんだと思う。
一回目で絶対もう援交しないという気持ちはあっという間にどっかにいき、それなりに気持ちよくマグロしてるだけで1万5千円はやっぱり楽だと思い2回目の約束をしてしまった。
今度は相手の家ですることになった。
特に面白いことは無かったけど今度は私がアナルを舐めさせられてその状態のまましごかされられた。
無心でやってるとイきそうになったみたいでストップ！って言われた。それと初めて電マを使われたけど刺激が強すぎて逆に気持ちよくなかった。挿入はまだ痛かったけど色々な体位を試された。唯一バックだけ気持ちよかったけどいくわけでもなくそのまま相手だけ射精して終了だった。一回目よりもむちゃくちゃされたから穴周辺がすごく痛かった。
そのあとは晩御飯をご馳走になってお金をもらって駅まで着いてきてもらって帰った。
多分また繰り返すんだろうなあと漠然と思った。
多分援交を繰り返してしまうのが最低時給に近い飲食バイトで悪い客層相手に走り回って得た、だいたいフルタイム2〜3日分の給料が3時間寝てるだけでもらえるお金と変わらなかったこと、
それと結局どんなお世辞でも褒めてもらえるのは嬉しいし気分が良いことだから可愛いねとか身体のあちこちを褒められた私は調子に載ってたんだと思う。
ただ2回目の行為のあともう死ぬかと思うぐらいに陰部の痒みに襲われた。
こんなに痒いことがあるのかと思うぐらい日中も夜中も掻き毟りたい欲を抑えながら耐え忍んだけどあまりの痒さにデリ○アなどの陰部の痒みに効く薬を塗ろうとした。
鏡で陰部を見て初めて異変に気付いたけど半端ないおりものが出ている。痒いしグロい、検索してやっと膣カンジダにかかったと気付いた。
幸い膣カンジダは感染というよりは自身の抵抗力の低下でも発症しやすい病気らしくて産婦人科で薬をもらえば一週間ぐらいで治るとネットで読んだ。
生理が来たら治療を中断しなきゃいけないらしいから生理が終わってから病気に行こうと思った。
そこから2日間は生理が来るまでの辛抱と思いがんばって耐えた恥ずかしい話だが誰にも見せないからとヨレヨレのパンツを履いていたらヨレヨレすぎて陰部と必要以上に擦れて余計に痒くなったからカンジダにかかってるときはピッタリサイズのパンツを履くべきです。
思い当たること全てで妊娠の可能性を検索してゴム有セックスで妊娠した人の体験談を読んで必要以上に怖がった。
そうこう怖がってるうちに下腹部が重く痛くなり体調も良くない気がする、頭も痛いしイライラするし生理前みたいな症状が出た。
これで生理が来たら安心だと思っていたのにその状態でさらに2日ぐらいなにも来なかった。
怖いし吐きそうだし夜も寝られないし、そういう症状が妊娠初期の症状とも当てはまると知って余計に恐ろしくなった。
彼氏相手での妊娠ならまだしも本名も知らないような人相手に援交で妊娠なんてどうしようもないし誰にも相談できないしと苦しんだ。
バイトの高校生が妊娠して辞めたり、生中出ししたけど大丈夫でしょwと話していたのを思い出す。
全然大丈夫じゃねーよ。
そうすると少し勘違いしていたのか28日周期で実際の予定日よりも1日過ぎただけだったと知った。
そしてその前の生理の日を見ると思いっきりズレていて、ここで初めて自分の生理が32日周期だと知った。
いつもだいたいでしか把握してなかったから周期を知ったのは初めてだった。
なので実際は生理予定日3日前で全然遅れてもなんともないことに気付いた瞬間スッと気分が楽になって吐き気も頭痛もお腹の重さも全部収まった。
嘘みたいな話だし自分もびっくりしたけどよくよく考えたら私はお腹が痛い気がすると思い込めばお腹を壊すし、試験当日には必ずお腹を壊すタイプの人間だったことを思い出す。
完全な想像妊娠だった。
実際にはそれでも不安で妊娠検査薬を整理予定日当日に使い陰性、その後結局3日ぐらい遅れたのでまた妊娠検査薬を購入しトイレで検査をしようと思った瞬間に生理になった。
安心と同時に毎月こんなめんどくさくて誰にも相談できない思い込みをしなければいけないなら援交しない方がマシと思って今に至る。
ボロが出る前に辞めれて良かったと思うけど、多分喉元過ぎれば熱さを忘れるからこうやってメモをしておく。
19歳のみゆはこんなしょうもないことで数日間ストレスで苦しんでこんな思いするなら彼氏もいらないと誓っているんだ。
実際彼氏は本当に欲しいとこだけどそれは置いておく。
今は生理が終わり知らないうちに治ったと思い込んでたカンジダが再発したので病院にいき薬を貰い飲んでいる段階だ。
援交をして分かったけど、援交してそのまま少し崩れたメイクのまま帰っても親になにも感づかれないし家族でしょうもない話をしながら晩御飯を食べれるし、友達とも普通に彼氏が欲しいと話ができる。
自分が何も知らない顔で援交してるように隣にいるあの子も裏では援交しててもおかしくないと考えるようになった。私がそうしているように。
今日も友達と昔の友達が出会い系で彼氏を作った話をネタに出会い系使うなんてあり得ないと話すし、親とニュースで出会い系がきっかけで事件が起きたら出会う神経がわからないと言うだろう。そうやって一生家族にも友達にも将来いつかできたら嬉しい彼氏にも言えないことをここで吐き出させて貰った。
でも援交なんてもう絶対にしないと宣言できる自分はいないし、何より貰った計3万5千円がかなり助かってることも事実だ。
でも想像妊娠のおかげで逆に風俗などにも落ちることにならなくて良かったと思う。
| VPSサーバ | AWS EC2 |
|---|---|
| 言語 | Ruby2.0p245 |
| フレームワーク | Rails4.0 |
| 画像のリサイズ | carrierwave |
| ストレージ | AWS S3 |
| DB | AWS RDS |
処理はRuby on Railsで実装。 ログイン処理はdevice 画像のアップロードやリサイズはcarrierwave carrierwaveってすごいのね。たった数行書くだけでアップロードした画像を複数サイズにリサイズし、S3に保存までしてくれます。 インフラ周りはAWSにお任せ、THE最小構成ですね。 同時に7人アクセスしたらあぼーんです。 本来ならELBとAuto Scalingでミディアム2台くらい使いたいところですが、我慢。 RDSもmicroインスタンスなんで、これもクソ遅いらしいですが、ゆくゆくはミディアムにはしたいです。 あと、前回作ったWebサイトのAMIを利用したんですが、本当に便利ですね！ 動くものを作るまでの時間がほぼ0でした！ AWSは個人利用者には少々割高かと思いますが、こういった便利なところがいいんですよね～。
色々書いたけど、ここまでの文はリリースしたときにテンションがあがってた時に書いた文なののよね。
ぶっちゃけローンチして一ヶ月たつけど、登録数４人。しかも全部知り合い。
興味があったらみていただければと・・・と思ったけど宣伝乙とか言うんだろ。
実装から今まで頭の中で思い描いたことの9割は裏目にでてるか失敗してるかうまくいってない。
こんな難しいのか、サイト運営って。
600万画素の写真1枚を受信するとしよう。ファイルサイズは約3MB、およそ24,000パケットだ。パケット定額のパケット代は1パケット0.0525円。これを計算すると、この写真1枚の通信料は1,260円になる。
仮に受信側が4インチRetinaだとして
1,136*640ピクセルあれば全画面表示できる。約72万ドット。
jpg圧縮すれば208KBぐらいにはなる。これはだいたい1700パケットで、90円ぐらいで送れるかな。
90円で目的達成できるのに、600万画素の画像をリサイズもしないで送る。
その嗜好品としての価値が1260円なんじゃないの？
＜!DOCTYPE html＞ ＜html＞ ＜head＞ ＜meta charset="utf-8"＞ ＜title＞Is it a bug?＜/title＞ ＜/head＞ ＜body onresize="alert('a');"＞ ＜h1＞Is it Ok?＜/h1＞ ＜/body＞ ＜/html＞
コピペ用→ http://pastebin.com/qwm8fqTN
IE9だと問題なく動作するし、
chromeだとご丁寧に「このページからのポップアップをこれ以上出さないか」聞いてくれます。
ぼくの環境だけの事例かもしれないので、みんなも試してくれると嬉しいな。
で、みんなの環境でも同じようなら、これはfirefoxのバグということなのかな？
ブラクラつくれちゃうと困るのでなんとかなるといいなと思います。
Webシステムとは縁遠い事務職のリーマンが、ある日思い立って、ニッチな用途の検索エンジンサービスを作ってみたので、ちょっと書いてみようと思います。
ちなみに、検索エンジンといっても、googleカスタム検索とかのお茶濁し系じゃなくて、apache Solrというオープンソース検索エンジンを、VPS上で動かしているという、それなりに本
気度の高いものです。
なんで素人がそんな物騒なものを動かす羽目になったかは、後述。
やりたい構想みたいなことを思いついたのは、もう6、7年前ほど前のこと。初めて独り暮らしを始めたときに、ひどく不便を感じたことがあり、こんなサービスがあったら便利だなあ、
ちなみにその妄想をふと高校の同期に話したとき、そのサービスはどこにあるのか？！と、えらくがっつかれたのを、覚えてます。まあ、俺と同じく偏執狂の奴だったからだと思います
が。
ただ、しがない事務職リーマンということもあり、当然、技術も無く、そのときは、やるならこんな名前のサービス名だろうなあ、とか、そんな妄想レベルで、話は終わっていました。
そんな感じで、5年ほど月日は経ち、なんとなくリーマン人生の流れも見えてきたところで、以前、妄想していたことを、ふと思い出しました。
5年も経ったら、さすがに自分が考えたようなこと、誰かがやっているだろうと調べてみたところ、意外なことに、競合になるようなサービスは存在せず。ちょうど異動があって、少し時
間が出来たこともあり、じゃあ、着手してみようかと思い立ちました。
やりたいことは、大手サイトの情報検索。ただ、商品ページ内の特定情報、それも、商品ごとに正規化されていない表記を、正規化して抽出する必要があったので、大手サイトの既設API
だけではとても実現不可能でした。
まあ、だからこそ、5年間、誰もやろうとしなかったんでしょうが。
ということで、とても一発では解決できなさそうな内容だったので、自分でなんとか実現できそうな機能に細分化して、各個撃破していくことにしました。
随分と考えた結果、
以上に区分できると考えて、これらを各個撃破していくこととしました。
また、技術もなく、プログラミングも出来ず、ましてやlinuxサーバのお守りをしたことなんて当然ないので、インターネット上に置くサーバですべての処理を完結させるのではなく、イ
ンターネット上に置くリソースは最小限に留め、できる限り、勝手がわかる自宅のwindowsパソコンで処理を行うことにしました。
ちなみにさらっと結論だけ書いてますが、ここまで至るまでに、いろいろと調べ続たり、考え込んだりしていたので、思い立ってから3ヵ月は掛かってます。。。
さて、やる方針を決めたあと、はじめに着手したのは、要の検索エンジンサーバです。
いろいろとググって調べて、mySQLというやつか、apache Solrというやつかに絞りましたが、結局、Solrを使うことにしました。
MySQLのほうが実績は多そうだったのですが、Solrのほうが検索専門で、滅茶苦茶動作が速いらしいということ、MySQLでも出来るが特に速度が遅いらしい全文検索機能も使いたかったこ
と、あとファセット機能がジャンル絞りこみに便利に使えそうだったので、というのが理由です。
ちょうどSolr本が発売されていたこともあり、それを参考に、自分が使うように設定ファイルを変更していきました。
しかし、初めは設定ファイルの内容も意味不明な上に、私の書き方も雑なのか、少しいじっただけでまったく動かなくなる。結局、設定ファイルを一文字ずつ変更しては動作検証、とい
った始末で、進捗は地を這うよう。ある程度思い通りにSolrを扱えるようになるまで、3ヵ月以上掛かったでしょうか。。。
さらに、検索エンジンのフロントエンド（Solrの検索結果を、htmlに変換するプログラム）も書かなければならない。プログラミングが出来ない人間には、これが本当に辛かった。
Solr本に、いろんなプログラミング言語でサンプルがあったのですが、迷った末に、わずか数行なら書いた（≒コピペした）経験があるという理由で、javascriptを苦渋の選択。
しかし、選択はしてみたが、基礎が本当に無いから内容がサッパリ頭に入ってこない。こちらも、わかるところから本当に1文字ずつ変えていくといった手探り状態。
プログラミングについては、今回のためだけだから、といった理由で、一切基礎をやらずに着手したのが裏目に出たのか、サンプルのソースをモノにして、書き上げるのに、ゆうに半年
以上。本当に時間が掛かりました。
さらに、Solr周りで計9ヶ月間ハマっていた頃、忘れもしない、kanzen21のおっさんが彗星のように現れて、衝撃を受けることになります。
大手サイトのページをクロールして検索エンジンを作る手法は、私と考えていた構想の枠組みとまさに「完全に一致」な訳で。。。
図書館事件に注目していたのも同じで、あまりの一致具合に衝撃を受けっぱなしでした。
その後の成り行き等も含めて、興味深く観察させて頂き、本当に参考になりました。
そんな感じで紆余曲折もありましたが、ようやく難題だった、プログラミング関連に目処が立ってきたので、あとはクローラと肝心のデータ処理です。ここからは、勝手知ったるwindows
まず、クローラですが、専用のクローラをwindows用に探してきたり、それを設定するのも大変なので、今回はテレホーダイ時代に使っていたような、フリーのweb巡回ソフトを利用する
こととしました。指定のhtmlをダウンロードしてくるだけなので、別に変に新しいものに手を出す必要もないので。
また、ダウンロードしてきたhtmlファイルについては、これまたフリーの日本語処理ツールでcsv方式に加工することにして、処理ルール部分を相当に作り込みました。
このあたりは、全体を通して見てもキモの部分なんですが、ある意味、ちょっとしたパズル感覚だったので、プログラミング言語の部分と違って、かなり楽しかったです。
あとは、msdosのバッチファイル（これは前から知っていた）で、これらの処理を繋ぎ、cygwinのcurlとかいうツールで、連続して検索エンジンサーバにcsvファイルをアップロードする
仕組みを作りました。
検索エンジンサーバには、容量は少ないが、安くて高性能という、今回の用途にピッタリだった、さくらのVPSを借りて設定。CentOSのサーバ構築ホームページを見ながら、サーバとか
Solr管理URLとかにセキュリティを掛けて、こちらも素人ながら、意外とすんなり設定。
ホームページは、vpsサーバに相乗りさせるのではなく、別にさくらのレンタルサーバを借りました。apacheの設定方法等を習得する必要がありませんし、vpsのリソースをapacheと分け
合う必要が無くなるので。ホームページのhtmlファイル、cssファイル等も調べながら設定し、画像も準備しました。
あと、構想を思いついたときに妄想していたサービス名の.comドメインは、すでに他者に取得されていたのですが、どうも使っている風にも見えなかったので、whoisで出てきたメールア
ドレスに連絡して交渉し、幾ばくか払って買い取りました。
結局、足かけ18か月。ようやく完成。
楽天市場の家具を、幅x奥行x高さ(家具サイズ)で検索できる、楽天市場・家具カテゴリ専門の検索エンジン
この商品数規模（データ収録約30万アイテム）で、1センチ単位で家具のサイズ指定検索が可能な手段は、商用サービスも含めて、ほかには存在しないと思います。
kanzen21と違って、エロじゃないから華はないけどね。。。
ちなみに冒頭で少し書いたきっかけですが、就職して独り暮らしを開始したときに、新しい家にピッタリサイズの家具が欲しかったのですが、これが楽天で探すのは至難の技でして。
楽天で家具を探してみようと思った人には判っていただけると思うのですが、楽天では、価格では範囲指定やソートができても、サイズでは検索出来ないんです。
これは、楽天では、商品のサイズ情報は商品の自由記述欄に記載することになっているためで、商品ごとにサイズの記載方法がバラバラのため、検索が事実上、不能となっています。
家電製品とかに関しては、種類が少ないこともあり、メーカーのホームページとかでサイズを確認した上で、商品型番で検索すればいいので、それほど問題にはならないのですが、家具
って、種類が非常に多く、型番もあったり無かったりで、家電のようにサイズを調べることができません。
・・・ということで、カグサイズでは、楽天の商品ページにいろいろな書式で書かれているサイズ情報を拾って解析して正規化し、範囲指定やソートして検索ができるようにしています
。
また、単に寸法サイズを拾うだけでは、梱包サイズとか引き出し内寸とかも引っ掛かってしまうので、それらは出来るだけ排除して、商品の外寸が優先して引っ掛かるよう、アルゴリズ
ムを調整しています。
単位（センチとミリ）に関しても、商品ごとにバラバラ（単に単位だけでなく、商品説明のどこに"センチ"とか"ミリ"と記載しているかについてもバラバラです。）なので、サイズ表記
の前後の状況をみて、正しいと思われる単位で拾うようにしています。
あと、変わった使い方としては、欲しい家具の価格比較みたいなこともできます。
家具は、同じ商品でも、店ごとに型番が違ったりすることがよくあり、簡単には価格の比較が行いづらいジャンルの商品です。
しかし、型番は違っても、同じ商品なら原則、サイズは同じですから、欲しい商品とまったく同じサイズで検索をかけると、同等商品があるのかどうか比較しやすい・・・といった使い
方もできます。
と、そんな感じで、しがない事務職リーマンが作ってみた、ニッチな用途の検索webサービスを、サービスインさせて頂きました。
一般に公開されていて、誰でもアクセスできる情報でも、ニーズが有りそうな切り口の条件で検索性を高めれば、新しい価値を創造できるんじゃないかという実験です。
もしよろしければ、ぜひ、使ってみてくださいー。それでは！
----------
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
覚えている限りの時間の流れの中から、世の中に存在するコンテンツを分けてみるテストです。
パソコンが外につながっていることが珍しかった時代。新大陸が見つかった状態。新し物好きかつパソコン好きが移民していった。パソコン通信くらいしか商売になっていなかった。作る人と使う人がイコールだった。何かをするにはコマンドを打つ必要があった。
最初は、学者さんの論文の発表やストックするのに使われていた。
イギリスのホストにつないでmozaicでなんて時代には、論文の延長のノリで研究室のメンバーの自己紹介ってのがあった。実は、実名うんぬんってのは、一番最初にやっていた。
ここで、実名を名乗るのかペンネームを名乗るのかの分かれ道。すでに実社会でしっかりと活動している人は、実名でやっていただろうし、ひとりで楽しむような趣味の人や背徳感がある人はペンネームやハンドルネームになったんだろう。
全国の日帰り温泉のまとめのような個人が足で調べた価値の高い情報が高い確率で存在した。
まめな人は自己紹介のついでに日記を書いていた。当時はコンテンツマネージメントシステムは一般に普及していなかったので、htmlを手打ちして、ftpコマンドで送信。量が増えると大変だった。メールをみるときはなんちゃらtermというソフトでコマンドを打ちながら見ていた。
デジカメが普及するまでは、写真を取り込んだりイラストを取り込んだりするのは、お金がかかることだった。まして、高価なグラフィックソフトなど夢のまた夢。デジカメが普及したあとは当たり前になった。
取り込むためには専用の拡張ボードが必要だった。カメラも高価だったし。2GBの壁があって、長い動画は編集できなかった。高画質な動画に仕上げるためには職人芸が必須だった。大容量の動画をあげるサーバーはほとんどなかった。
音楽を作る人は、midiの配布していた。有名な曲のコピーが多かったので、大人の事情でほとんど閉鎖。
無料のホームページとセットのような感じ普及。ホームページ自体散発的なもので、同じ趣味趣向の人たちで同盟とか組んでいたよね。
大量に生成されるコンテンツは個人の手を離れていった。新大陸はいくつかの勢力に分かれて群雄割拠の状態。広告枠として大きなお金が動くようになった。作る人と使う人が区別されるようになった。グラフィカルユーザーインターフェイス(GUI)が、あたりまえになり、コマンドを打つ必要はなくなった。
地図が見れるようになった。パソコンにインストールしていた時刻表やルート検索がwebになった。
コンテンツマネージメントシステムが無料開放された。htmlの作成もftpも必要なくなり、気持ちや感情の発露のみを文章や写真にすればよくなった。改行を大量に挿入してスクロールバーを有効にして、文章を読むためにマウスのホイールをまわして文章を読むときに指の動きを加えて、読んだ感を高める手法が流行る。
会員制の閉じたサービスが登場する。内容は日記、掲示板と基本は同じだが、個人が設定する必要はない。テクニカルな要素がなくなったので、気持ちや感情の発露のみを文章や写真にすればよくなった。携帯電話からコンテンツを作る文化の先駆者ともいえる。携帯しか使わないユーザー層があらわれる。
写真のアップロードも無制限になった。デジカメの画質が上がってもリサイズする必要もなくなった。
動画を受け止めてくれるサーバーも増えた。ブログやSNSのおまけ的存在だったが、Youtubeの登場で無差別級のサービスになった。カメラで撮影した時点で、パソコン用のファイルになっているのも参入障壁を下げた。
たとえば、全国の飲食店をすべて載せるとかそこに感想や評価を付けるようなサイト。個人が手弁当でまとめていた情報を商売にする会社があらわれた。
感情の発露がリアルタイムになる。「つぶやき」という概念が生まれた。新大陸を制覇しようとする勢力の攻勢が高まる。作る人と使う人に加えて踊らされる人が登場した。「更新されたよ」ボタンをクリックするだけで、ダラ見ができるコンテンツが優勢となる気配。
ゲームとかやることが多くなりすぎた。
発展期に登場した便利サービスの中で脱落するサービスがあらわれ始めた。
大きな掲示板のスレッドには、約1000個の書き込みがある。その中から文章を選んでコンテンツを作る手法。新聞の読者投書欄のように投書されたご意見の中から好きな意見を載せることができる。文章ロンダリングやソースロンダリングという言葉が生まれた。
コンテンツの提供形式として、素人作成風味の味付けをする企業・組織があらわれた。個人が大きくなったのかもしれないし、何者かに組織されたのかもしれない。この手の人たちは頼んでもいないのにどんどんコンテンツを作る。
midiサイトに対する警告に比べると2次元コンテンツはゆるい。コンテンツホルダーの手が回らないくらいにあふれいるのか、あえてあふれさせているのかはわからない。黎明期ならばまつりになっているような内容のものがあふれいる。包括的に権利処理されているのかもしれない。
趣味じゃなくて仕事の人が増えたのだろうか。仕事でwebに出るといっても会社の看板を背負うと個人ではなかなか発言できないはずなんだけど。よくわからない。
http://anond.hatelabo.jp/20110709223841
ラスタ画像の自動リサイズは画質劣化に繋がってうざい場合がある
見開き前提の漫画は見開きで読みたいし、1ページごと前提の漫画は1ページごとに読みたい
参考にしよう。
http://anond.hatelabo.jp/20110709234137
巻（章）の最終ページからの通常遷移（メージめくりで飛ぶ場所）は次巻（次章）の最初のページだとサクサク読めて嬉しい。
最終ページからの通常遷移が巻（章）の並んでる目次ページの場合がたまにあってそれだとすぐに続けて読めないし、
「あれ？次は何巻（何章）だったっけ？どこまで読んだっけ？」と（章も多いとスクロールして下の方を探さなきゃいけなかったりして）ちょっとイラっとする。
俺が想定しているWebコミックというのは、
こんな感じなので、そういった不満は出ないように考えてる。
