 
|
はてなキーワード: 検索エンジンとは
自称SEO対策屋のはてなブログで上位表示【SEO対策屋】(http://seoes.hateblo.jp/)はスパム屋と思われます。
id:koragon
http://b.hatena.ne.jp/koragon/のブックマークを調べてみる。
アメブロでYahoo Googleの検索エンジン上位表示をめざす (http://ameblo.jp/seoisland)内のページがとても多い。
赤ちゃんの名づけ応援団・ぴよぴよクラブ(http://www.naduke.com/)へのブックマークが見られます。
右下にSEO上位対策My Island(http://myisland.jp/)のバナー
http://myisland.jp/より、Amebaブログ上位対策屋のバナーが。このバナーはhttp://ameblo.jp/seoisland/へのリンクとして張られています。そういうわけでぴよぴよクラブ(http://www.naduke.com/)へのブックマークはセルフブックマーク。どうみても上位対策目的と思われます。
第6条(禁止事項)
6.ユーザーは、本サービスの「はてなブックマーク」を利用するに際し、以下のような行為を行ってはなりません。
某サイトに掲載されたコラムが発端となり、ブログ・ＳＮＳに飛び火し、基本的に若者は恵まれているというスタンスで進んでいる論調。
現在の社会はインフラが高度で合理化され、過去の自分たちが費やした苦労や時間とは比較にならない容易さで、クリック一回で実行できる社会。
そこで高い代償を支払わずに、ゆるい連携を持って生活する若者は恵まれている、しかし熱が感じられないので、過去の経験から「夢」と「積極性」を持つことをアドバイスする。
という点、過去は苦労したが未来は明るいという楽観的な先入観はもう通用しない時期に来ているのに、発展した未来のインフラや生活様式に気を取られ新たに発生した問題が見えていない。
見えていないというより「更に発展した未来で解決可能」又は「過去の苦労に比べればやさしい問題」と考えているのでしょうか。
社会基盤が発展すれば、価値観や生活水準が変わりますと言えば、誰もが同意するでしょうが、負の発展（規模の縮小）は誰も経験していないのです。
例えば90年代まで若者のアイテムとして誰もが持っていた車、車離れが叫ばれて久しいですが、都市に住んでいる若者における車の必要性が低下し、代わりに携帯電話とＰＣを持つようになっただけです。
しかし車の購入・維持に比べれば遙かに購入が容易な端末なのに、ＰＣを持っていない人が大勢いる。00年代初頭における我が国のＩＴインフラ整備率は世界一位ですが、現在は目も当てられない状況です。
ＰＣ購入するだけの収入がない若者は携帯で何をしたか、現在ではスマートフォンでかなり情報収集が便利になりましたが、ガラケーと呼ばれる国産端末におけるネット探索能力は前者と比べると劣悪で、利用者は検索エンジンで何かを調べるというより、遙かに狭い範囲でしか活動できなかった。新聞も購入していない、ＴＶも見ない、社員として収入が確保できる30代以上は例え不慣れでもＰＣ位なら即金で購入する事が出来るので、ある程度のリテラシーを培う事が出来ますが、その機会さえも与えられていない。結果情報を持つ人と持たない人の間の格差が広がる。所得が低くなっても相対的な幸福度は昔より高いという人は、かつての新聞とＴＶから情報を得ていた経験から言うのでしょうが、インターネットで必要な情報を素早く調べて理解するというのが基本となった世の中で、流動的な情報ニュースより固定化されている公的・私的な各制度のアクセスにおいて絶望的な差が生まれている。利益が１与えられるか９９与えられるかの差でなく、０か１００かの差で生きなくてはいけない。この問題に最初に晒されたのが現在の２０代後半。
今の大学生はＰＣを所持することを半ば義務化されていますが、業務で使用できるレベルでOfficeを使えると認定される資格を持っている人は、２割居ないでしょう。ですが、職安に出されている求人のほとんどはOfficeを最低限使える人間を求めている、でも資格を取れるレベルで教えてくれる高校や大学はほとんどない。高卒は自力で学ばないとスタートラインにさえ立てない。しかし採用基準は厳しくなったのに、現在働いている社員になんら教育を施さない、Excelで文章作成する事の何が悪いかのかさえ分からない。
収入は、小泉改革以降合理化され、事務職は派遣で構成され収入は捨扶持レベルの１５万円程度、それでも仕事があればマシと言えるかもしれませんが、今後は労務環境の国際化によって事務職そのものが国外に外注されるのは確実。そして発生する人口減による国内市場の縮小、７０年代に隆盛を誇った着物業界の現状の様な事態が各分野で発生するでしょう。
中年が考える未来は必ず発展し、解決されうるものとして存在していますが、今後の日本が進む道はその真逆としか言いようがない。中流のホワイトワーカーは営業を除いて全滅し、高所得者は移民の導入を要求する、対して単純労働者は仕事を取られまいと反対に回る、すでに同じ事が発生している会社もあるでしょうが、これが社会全体で常識となるのに何十年もかからないでしょう。
更に合理化され、余計な費用を払わずに生活できる世の中、しかし収入は少ないのに、最低限のインフラをそろえないと就職さえままなならない世の中、企業では仕事を一から教えてくれないので、自費で各種の専門校に通い勉学する日々、収入のすべてをつぎ込んで遊びなんて全くできない２０代、当然お金が足りないので脛を齧れる人は脛をかじり、齧れない人は何年もアルバイトをして費用を捻出して、職歴なしというハンデを背負い戦う。大人は新卒ですぐ就職することが全てでないと高説を垂れるが、そんな人間を雇う気は無い。
昔あった問題と今の問題、問題という意味では等価値で、その大きさは当人には判別できない。過去にとらわれているのはどちらだと。
戦前に生きていた人達は、次の世代に多くの機会を与えましたが、その世代は次の世代に機会を与えない。というのは言いすぎですかね。
これは、「事務職リーマンがwebサービスを作ってみた話」のトラックバックに対するトラックバックです。
もちろん、この手のアルゴリズム処理に「完璧」は存在しません。
ですが、拾った結果の品質を数百個ばかり、サンプリングで調査した範囲では、商品サイズを拾える商品のうち、９割を大きく超える率で、正しいサイズを拾えていますので、
もちろん、検索できる商品数が尋常じゃないので、サイズ抽出をミスっていそうな商品を狙い撃ちで探すと、結構見つかったりはしますが。
ちなみに、上記の「商品サイズを拾える商品」という表現には、レトリックがありまして、結構、楽天ではサイズが画像のみで記載されている商品もありまして、そういうものは、当然、検索できない商品となっています。
まあ、これは仕方が無いところです。
サイズは、正しくサイズを拾えるよう、複数の書き方パターンでサイズ候補を抽出しています。
おおまかには、
・幅×奥行×高さ（単位センチ）・・・・・・XX × YY × ZZ
の２パターンで、このパターンを軸に、さまざまな派生に対処しています。
この派生（というかノイズ要因）が滅茶苦茶いろいろなパターンであって、相当手を焼きました。
実はこれも、簡単そうに見えて、結構、面倒なところでした。
・サイズ記載部分から遠く離れた部分に（単位：ミリ）とか書いてある場合がある
など、さまざまなパターンがあり、結局、サイズ記載箇所の前後を見て、距離などから重み付けを調整して、サイズ単位を拾っています。
また、そもそもサイズ単位が記載されていない（意外とよくある）場合は、サイズ値の大きさを見て推定したり、（例えば、家具カテゴリのサイズ表記に小数点があれば、それはきっと、ミリではなくセンチだろう、など。）全く見当が付かん、というときには、決めで処理したり、仕方なくあきらめたり・・・といった処理をしています。
サイズを拾うだけでは、梱包サイズとか、引き出し内寸とか、ノイズが多いので、これらは、重み付けを行い、一番重み付けが高いものを外寸サイズとして拾っています。
この辺の重み付けは、ある程度、作りこんでいますが、もちろん、完全ではないので、今後のブラッシュアップが必要な部分です。
こちらは、型番等で誤反応を起こしやすい、W/D/Hでの記載サイズのレーティングを少し下げて対処しているのですが、初めのほうにトラックバックを頂いた方もご指摘されているとおり、それでもある程度引っかかっちゃいます。
タイトル中の型番を検索外すとかの手も無くはないのですが、型番って意外と本文中にも多くて、例えばテレビ台とかで、本文中にテレビ型番をズラズラ列挙されて、それが反応した時もあります。
一応、異常値についてはレーティングを下げたり、サイズ数値取れずで処理はしています・・・みたいなところではありますが、検討すべき改善箇所です。
ex)「幅800×奥行400×高さ100センチ」の棚・・・など。
こちらは、最終的なサイズ数字を見て、「サイズ単位の書き間違い・拾い誤り推定」の判定を入れておりまして、判定に抵触したサイズについては、正しいと思われる単位に変更・救済しております。
もちろん、フォローにも限界があったり、フォローを行って二重遭難する場合もあるんですが、検証してみたところ、ほんのわずかな二重遭難よりも、誤り救済を行ったほうがはるかに結果がよかったので、処理を入れてます。
ただ、結論から言うと、サイズ情報に対する、楽天市場側の動きはほとんど無いと読んでおります。
なぜなら、圧倒的にニーズが高く、ハードルも低いと思われる、送料込み価格検索すら、彼らは実現できてないからです。
恐らく、楽天側では、出店側に登録させる情報を、いじりたくないと思っているのではないでしょうか。
しかも、サイズ情報は、楽天が扱っているほとんどのジャンルの商品にとっては、それほど重要性の高くない情報です。
ごく一部のジャンル向け以外は重要性の高くない追加の登録情報なんて、楽天はあまり実装したくはないのではないでしょうか。
・・・と、そういう読みをしてますし、さらに、読みが外れて楽天が対応を行ったとしても、別に私は片手間でやっているだけなので、それほどペナルティが大きい訳ではありません。
以上、カグサイズのページ処理の内容部分の説明でした。
それではー。
----------
Web上を探しても情報が見つからなかったので、ここにメモしていきます。
FireFoxやChromeな皆さんは、Operaをインストールしてからまた来てね♪
＜手順＞
1. このページの一番上にある増田の検索窓を右クリックし、検索エンジンの作成を選びます。
2. 名前に「英辞郎」、アドレスに「http://eow.alc.co.jp/%s」と入力。キーワードはお好きなもので。
4. おしまい。
英辞郎はなぜか右クリックから直接登録できないので、自分でアドレスを入力して追加しなくちゃいけません。
この時、検索エンジンの編集で新規に追加すると文字コードがiso-2022-jpで登録されるんですが、異なる文字コードを使っているサイトに対応させるにはsearch.iniっていう設定ファイルの該当部分をちょこっと直してあげなきゃいけません。（ちなみに英辞郎はUTF-8。）
設定ファイル探して、テキストエディタ開いて…ってのはちょっとした手間です。
だったら文字コードが一緒の所で先にダミーを作ってあげて、アドレスだけ直した方が手っ取り早いよね、ってことです。
文字コードがUTF-8の所であればどこでも同じように登録できます。Google翻訳やニコニコ動画でもOK。
ちなみにDMM.R18は違いました…。
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 練習問題
しね。
少し前までは Google インスタント検索をオフにしてもサジェスト機能が使えていたのに、今ではオンにしないと使えない。
仕方ないので Google インスタント検索をオンにしてしばらく使ってみたが、
何なの、コレ？
嫌がらせか？
など、ネガティブな反応が多いようですよ、Google さん。
broco
flipback
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
［場所］タブをクリックして、［移動］
Dドライブにあらかじめ作成したフォルダー「My Documents」を選択し、［フォルダーの選択］
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
パーティション分割
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
jane style
↑ 現在の板を閉じる
→ 新着チェック
← 新着までスクロール
wheeldown すべてのタブを閉じる
wheelup すべてのタブを閉じる
leftclick これより右を閉じる
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
ポート開放
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
クイック起動
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
Googleのトップページを開いたら、「+あなた」というメニューが追加されていて、
ご丁寧に「こんな新サービスができましたよー！」とアピールせんとする青矢印のアニメーションまで付いている。
正直、これはやりすぎじゃないか？
今まで何かの記念日にGoogleのロゴが記念日にちなんだものに変わっているのは、一種のユーモアやジョークとして楽しいが、今回のこれはあまりにも自社のサービスの宣伝という意味合いが露骨で、嫌悪感を覚える。
Googleのいいところは、Yahooや他の検索エンジンみたいにゴテゴテと余計なものがない、シンプルなUIだったのに、これではその良さが台無しになっている思う。
「Facebook」とかの新手に危機感を募らせているのかもしれないけど、これじゃ結局Googleが嫌っていた邪悪な存在になってしまう気がしてならない。
2週間ほど前に、ブログを作った。
一般的に興味が持てる記事を集めているつもりではあるが、
まぁニュースまとめなんてゴロゴロあるし、まだ特別差別化を図ってるわけでもないので
欲張りといえば欲張りかもしれない。
それでも、見てくれたらどれぐらいリピーターになってくれるのか知りたいし、
ちょっとしたコメントとかもらってみたい。
では具体的に何をすればアクセスアップになるのか？
アフィを狙ったアクセスアップブログみたいのが山ほど引っかかり、
何が本当に使えるのか、よくわからない。
ので、やってみたこと、やるべきだろうと思うことをまとめてみる。
★とりあえずやってみた
■サイトの見やすさ
こういうサイトだったらまた来たいなーっていうのを意識して作った。
■検索エンジンへの登録
Google先生に登録した。
■pingの設定
いくつか設定した。
取得した。
★足りない
デザイン等は別にしても、ニュースのまとめとコメントのみでは独自性が出せない？
#関係ないけど、よくはてブされる記事のタイトルで「～されるたった○つの～」とかいう似たようなタイトルには飽きた。
■被リンク
こればっかりはサイト自体がもう少し広まらないと他サイトにお願いもできない。
自分で他サイト作ってリンクさせるとかは楽しくないのでやらない。
★できたらいいな
まぁニュースサイトだし、難しいよなぁ。
こう見ると、なんだかんだでやっぱり独自性出して行かないとだめなのかなー。
どうやっていこ。
いや、あなたの言ってることは合ってるし、自分も基本的に同じことを主張したつもりだが。
を、わざわざ砕いて”リッチなインターネットコンテンツを、非常に簡潔にスマートに記述できる”と文系チックに書いたのに、なぜ、わかりにくいバズワードで言いなおすのか。
そもそも「セマンティックな記述」って意味がわからない。文章の意味構造を記述できるようにして外見と分離する事を指すのなら、それは「非常に簡潔にスマートに記述できる」という事じゃないのか（さすがにあいまいに書きすぎてるとは自分でも思うが）。「実現できることが格段に増えた」事は、リッチなインターネットコンテンツを記述できるって事じゃないのか（意味構造を記述によって検索エンジンに適した情報になるってメリットは、論旨がブレるので書いてない）。
その当たり前の事ができなかったHTML4。HTML5になればできるようになるとでも言いたいのなら、あなたもネットに向いてない。
問いかけてる以上、答えがあるようなので、ぜひ模範解答をご教授頂きたい。「無限の可能性があります」という厨二病な答えしか思いつかない。
ちゃんと書いたつもりけど、代表格は2D描画。あと複雑な処理（クラスのおかげ）。ブラウザ間OS間の互換性。ネイティブなXML処理。プリミティブな音ストリームの操作なんてのもある。
現状、Flashを必要としてるのは何処？ 誰？
Flashを必要としてる人なんていないと思ってる。ただFlashの方が制作環境とかも含めて使いやすいから使ってるだけのこと。
いやいやいやいや。iPhoneで表示されない広告に何の意味があるのか。ゲームは一理あるけどFlashは外部コントローラに対応してない。3Dなら現状Unity。一概に言えない。
スパム行為という内容が出ているが、これは語意と内容が合っていない。無差別に多額の請求になるように故意に送付するものと聞き及んでいるが、もし問題があるなら、その部分は管理者がカットすべきだと思う。
http://anond.hatelabo.jp/20110601132716 より、多数のブログに似たような記事をポストしているのは明らか。こういうのはスパムブログと呼ばれます。また、必要以上に多数のブログを作成すること自体、検索エンジンにインデックスさせる行為であり、検索エンジンスパムと呼ばれます。
http://taikenkun.at.webry.info/
http://blog.goo.ne.jp/taikenkun
http://taiken01.at.webry.info/
http://taikenkun.cocolog-nifty.com/blog/
http://plaza.rakuten.co.jp/taikenkun/
これも似たような記事。多数のブログサービスを使ってマルチポストしてる模様。スパムでしょう。
サブアカウントを4個まで取得できます。これにより、5つのアカウント（はてなID）を使ってはてなを利用することができます。
http://anond.hatelabo.jp/20110601132716 より、アカウントの取得は限度を超えてる。一法人であるタイケン学園がその関係者を何人か名義として使って不正にアカウント取得したのでしょう。九州電力かよ。
馬渕教室、新生ホームサービス株式会社、日本eリモデルなどのSEOを担当していると思われる株式会社マイスタンダード（代表取締役 武智建樹）は、ブラックな企業らしいです。
日本のブラックハットSEO会社一覧に株式会社マイスタンダードが掲載されています。
インデックス削除URL タイトル サービス名称 会社名 代表者名 住所 備考 http://www.seo-rankup.com/otameshi.html 業界最安値！関連検索ワード削除１キーワード１万円 関連検索ワード削除 お試しプラン 株式会社マイスタンダード 武智建樹 大阪府大阪市淀川区西中島7-7-3-702
ブラックハットSEOとは、SEO（検索エンジン最適化）における用語で、悪質な（非倫理的な）手法を駆使して検索結果ページ（SERP）の上位に表示させる技術または施策のことである。
ブラックハットSEOの典型的な手法としては、ユーザーに気づかれないようにWebページ内にSEO目的のキーワードを大量に埋め込んだり、ユーザーがアクセスしてきた際にWebクローラが巡回したWebページとは異なるWebページを表示させるような仕組みを埋め込んだり、コメントスパムなどの強引な手法で大量のバックリンクを獲得しようとしたりする方法がある。検索エンジンの多くはこうした手法はポリシーに反するものとしており、通常は何らかのペナルティが課されるが、悪質なWebサイトと判断されず検索結果ページの上位に表示される場合がある。
http://www.sophia-it.com/content/%E3%83%96%E3%83%A9%E3%83%83%E3%82%AF%E3%83%8F%E3%83%83%E3%83%88SEO
http://anond.hatelabo.jp/20110525100731の続き。
http://unkar.org/r/juku/1244229651
>>126-128
126 ：名無しさん＠お腹いっぱい。：2011/04/19(火) 03:14:05.63 ID:p+48ZCyR0 ・馬渕教室 ・企業データベース ・馬渕教室 ・馬渕教室 ・馬渕教室 ・WEBシステム開発 ・検索エンジン登録 ・SEO対策 ・誹謗中傷対策 ・馬渕教室 ・馬渕教室 ・馬渕教室 ・株式会社マイスタンダード 127 ：名無しさん＠お腹いっぱい。：2011/04/23(土) 16:35:37.80 ID:jZz2a5VR0 >>126 株式会社マイスタンダードが 馬渕教室の SEO対策や 誹謗中傷対策を行っているってこと？ 馬渕教室でぐぐると自作自演の変なブログが並ぶのも マイスタンダードが頑張っているからなんだね 128 ：名無しさん＠お腹いっぱい。[sage]：2011/04/24(日) 16:38:46.57 ID:X3v01BlU0 >>127 馬渕教室 ２ちゃん で検索すれば無問題w
キメこな問題についてのツイートのまとめを見た。
いつか来ると予測されていた問題がついに表面化。
しかしこれは梅ラボ本人一人が気分的に凹むということ以外は実害がなくてよかった。
災難だったね、としか言いようがない。
そして※欄の予想通りすぎる人格攻撃っぷりは、見てて少し虚しくなった。
ふたばという「歪な形で維持し続けられる楽園」の脆さを住人自体がいまだに把握できてない。
そんな場所の住人であるということがアイデンティティと不可分レベルに融合してしまった多くの
「としあき」たちにとってどうしたって不快であり、許しがたい行為だということは分かるが、
前提として招待制SNSでもなんでもなく「匿名掲示板」なんだから誰もがやってきてしまう、
ということはシステム上仕方ないのに彼らは「この中のルールを守ることで新参の訪問は最小限に抑えられる」
という幻想を持っている。まるで「９条さえ守っていれば戦争は起こらない」と信じる9条信者のようだ。
「外」の人間はそのルールを知らないし、意に介することさえないかもしれないのに。
今回の件は若干違うか。例えが悪い上に無駄なツッコミどころになったかもしれない。どう違うかは後述する。
ふたばはある意味、かつてのアンダーグラウンド系掲示板の文化の匂いを残したまま現在まで存続しているという
ちょっと珍しいサイトだが、哀しいかなシステム上でなんらかの方策を講じているわけではなくWeb上に
置かれたものは大概がフラットに消費される可能性を抱えている。それを作った人間の快・不快という感情的な
問題とは別個に。アンダーグラウンド、という領域が存在し得たのはGoogle以前でしかないだろう。
検索エンジンが未発達な時期には確かに「見つかりにくい領域」はあった。もう、昔の話だ。
ふたばが２ｃｈと違ってちょっと面倒なのは、「としあき」という名に仮託された奇妙な選民意識の
存在がある。だが、梅ラボ自身もブログで「２年ROMってた」ということを表明している。
（古参住人にとってはその理解はまったく足りないものに映ったのだろうとしても）
「不定形匿名人格の一部」である自分の立ち位置と自らの「表現欲求」やどうにも抑えようのない「作家性」
（「人のもんの貼りあわせだけで何が作家だ」とかいう意見もあるだろうがそこはひとまずおいといて）
の間で引き裂かれ、今回の件で梅ラボは苦しんでいる。かつて同人誌「カオス*ラウンジファンブック」にて
仲山ひふみに「著作権問題が発生したらどうなるのか」という問題提起があったので、冒頭の一言が
あるわけなんだが、感情的な「許す」「許さない」の問題はもうどうしようもないんだろうと思う。
少なく見積もっても1000の意見が表明された。それが1000人なのか一人なのかということも実際のところ
わからない。まあTogetter見てる分には流石に一人ではないだろうということは分かるが、ふたばのスレでの
そして多くの人間がいればその構成員の「許容の基準」だってバラバラだろう。もうこれは仕方がない。
だが、「絶対許さない」とか言ってる人間だって別になにかできるわけではないのだ。
それに、時間が経てば忘れられる。「絶対許さない」とか言ってる人間だってずっとこの件だけを
考えつづけることはできないだろう。出来るような人はちょっと常人離れしたなにかである。
それはそれである意味すごい。もしかしたら現人神「絶対許早苗」かもしれないｗｗｗ
うむ、早苗さんに許してもらえないのは東方厨である梅ラボにはキツいなー。
冗談はさておき。
結局のとこ諸行無常、ってね。不変なものってのはなくて物事は相互に影響しあう。
水の上に油をたらす。油の粒は水の力によってその形を変える。しかし逆に見れば
油が垂れてきたことで水全体の形も変わったと言える。ネット上の出来事も基本的には
大して変わらない。ちょっと私見になってしまうが「キメこな」はともかく海外での
「Moetron」の成長において梅ラボの作品の特徴が全く影響がなかった、というのは
ちょっと考えにくいのだ。多くの作品で「いくつかの別のキャラの顔のパーツをひとつの
顔であるかのように構成した」構造が見られる。梅ラボの作品はTumblrなどを通して
かなりの拡散をしており、カオスラウンジはよくも悪くもそれなりに一部で目立つ存在と
なっていた。それに刺激された４Chanの人間が「Moetron」と梅ラボ作品に共通するエッセンスを
感じ取ったということはありうると思う。もっとも、根拠がないので妄想ととらえてくれて
一向に構わないが。
文化という言葉がこの件で多く出てきた。自身のコミュニティの文化に誇りを持ち、
それを保護する姿勢もわからんではないが、そんなに過剰に護らないと壊れてしまうほど
脆弱な文化なのか？ふたばは、二次裏とは。そうではないのではないだろうか。
「見ろ また奇妙なやつが出てきたぞ」
くらいの気持ちで興味をもって動向を捉えていればいいのではないだろうか。
キメこなは生まれてさほどの時間が経っておらず、成長途中のキャラである。
だからこれもまた、成長の一過程だと捉えることはできないだろうか。
なんのまとまりもないが、思いつくまま書いてみた。
異論は大いに認めたい。むしろ読みたい。
うまくまとまらないので、箇条書きにする。思考メモみたいなもんなので、結局何が言いたいのになってるかもしれない。
価値付け→目新しさ、ためになる、需要のある事実、歴史的に重要な事実、リスペクトしてる発信者からの情報、etc、色々な価値があるけど、まとめて｢情報の重さ｣ということにする。
時事問題や災害等、事実自体が重いケースは除き、情報の一次発信者によってある程度重さの初期値が左右される。
既存メディアでは、大手マスコミなど、情報を加工し提供している所で重さが操作される。
ネットでは、情報の受け取り手がバズによって重さを加算していく。
http://anond.hatelabo.jp/20110307103006 自分の書いたものから一部
TL に出てきたものを RT するとき→自分がフォローしている人が回してきた情報→フォローしてるってことは信用や友好や情報価値などがあるということ→情報の価値や精査の連鎖がある
工作アカウントが RT する→こういうアカウントはスパムっぽかったりするのであまりフォローされない（単純につまらん）→フォローするのはフォロワー数が欲しいだけの人や自動フォロー→そういう人のツイートはまたつまらないのであまり有意義なツイートをする人にフォローされて無い→情報価値が上がらない連鎖
てな感じで、Twitter の場合、ツイートが RT されて自分の TL に来るまでに｢信用の連鎖｣や｢情報の精査｣がある。だれが RT したか調べなくても TL という経路を伝わってくる以上、それがあるわけ。
ところが、はてぶのような仕組みにはそれがない。数字にしか意味が無いのがまずい。クソみたいな工作員の3ブクマでも、3ブクマなわけよ。これが Twitter なら全然フォロワーいない奴の 3RT には意味ないじゃん。そうはならないのがはてぶ。
情報を重くする。情報にメタデータをつける。情報に信用度をつける。または下げる。色々が処理がされて、再発信される。受け取り手は発信者でもある。発信者と受信者の区別がなくなっていく。ゆるやかな情報の共有。
同時性が必要。
情報を重くするには人の判断が必要→判断をするにはリテラシーだけでなく感情もかかわる。同じ瞬間に共有していることで一気に意思や感情がかかわりやすくなる。
リアルタイムで中東からの声を聞いた人達が、国内の発信者と同じ距離感でそれを捉えて、革命自体を身近に感じたように。
さらに同時性がどれだけ高いかということ自体が情報に重みを加算する。
シーケンシャルなメディアって他に言い方わからないので俺俺用語。
シーケンシャルでないメディア。検索エンジンや過去のログや Wikipedia や書籍等。いつでもどれでもどこからでも見れるメディア。これらは人の好奇心や知識欲がある限り、ずっと生き残るだろう。
例えば、アニメは初放送の時はシーケンシャルなメディアで、放送後に発売された DVD はシーケンシャルじゃないメディア。
最大のシーケンシャルなメディアは現実世界。現実世界は万人と共有している。
現実世界の時間軸とリンクした仮想世界も同等の同時性がある、MMORPG など。
ニコニコ動画は、動画の中にコメントの時間軸を入れる事で、仮想的に同時性を演出している。ニコニコ動画のどの動画をいつ見ているかというのは、現実世界の時間軸での同時性だし、これにも大きな価値があるが。（世界の新着動画や生放送など）
今サッカーの放送を見ている、今人気アニメの第何話を見ているという同時性。それと相互に依存する情報の重み付けと共有。
今の日本のテレビの一番のネックはこの情報の重み付けと共有が外部に依存していること。
ネットでは境目がない。内包されている。
テレビでは、分離されている。テレビで発せられた情報がネットで重みを加算されることも多い。
（俺俺メモ。そー考えると、昔ながらのライブやイベントというのは、テレビよりむしろネットにずっと性質が近い気がする。いや、もっと昔ながらの口コミや言い伝えにはネットと同じように情報を重くする仕組みが受け取り手自身にあった。テレビというメディアが逆に異質なんじゃないか？）
情報の重み付けと共有は、同時性によって加速されるから、同時性のないシーケンシャルなメディアは段々価値がなくなっていくか、ウケが悪くなっていくだろう。
海外メディアでは新聞局や通信社やテレビ局がネットの利点を生かした発信をしている。ライブブログなど、ほぼリアルタイムで更新される情報群。テレビ側では、ネットのゆるやかな共有、重み付け、同時性を放送の中に取り込む動き。
http://wiredvision.jp/news/201103/2011030719.html wiredvision アルジャジーラの「ソーシャル・ネットTV」
この差を解決できないメディアはただのインフラになっていくと考えている。（百年スケールだろうが）
まともな考えなら、それもメディアに取り込もうとするから、アルジャジーラのような取り組みはとめられないだろう。（日本国内はしらん）
この差を解決できないメディアはただのインフラになっていくと上で書いたけど、そのインフラこそがテレビの強さ。同時性、共有、これが巨大になっていくと今のネットワークでは帯域幅が足りない。テレビにはそういう問題がない。
そう考えると、ネットがインフラとしてテレビを利用するようなものが今後増えてくる。アルジャジーラの取り組みはまさしくそれ。
ネットの情報は信用できない、だからネットはと言われるが、情報に重みをつけるのは俺ら自身だ。そのために出来る事は、リテラシーを育てること。
http://anond.hatelabo.jp/20110307054102 俺の書いたもので申し訳ないけど、伝えたいことは大体書いてある。
http://anond.hatelabo.jp/20110308023901
http://bit.ly/ie6countdown これ見て仕事仲間と色々話したがね。金盾がある中国や途上国はともかく、日本どうなの？と。
本当は漢字に何の罪もないです。僕は漢字廃止論者でもなんでもないし、漢字はすばらしいですよ！
ツイッターでも｢英文がついてるリンクは怖いから絶対ふまない｣｢うっかり英語のサイトに行ったらウイルスかもしれないからあわてて戻る｣｢外国人にフォローされたらなんであれ怖いからブロック｣そんな人がわんさかいます。
Flickrあるじゃないですか。あれに僕写真アップしてるんですけど、綺麗な風景の写真のリンクをツイッターで張ったら話が通じない女の子がいてね。聞いたらなんだか危ないサイトだと思ったからFlickrをフィルタしてるって。ええー、フィルタ設定するような知識もあるのに、英語読む必要のないただの写真サイトでも英語だってだけで拒否です。
英語みたら逃げてしまう英語アレルギー。インストールの途中でちょっとでも英文字があると拒否反応というユーザー。
日本語情報しか見てないから情報アンテナ感度が低い。検索エンジンのグーグルのシェアの低さも世界では日本が特異的。とにかく何をやってもガラパゴス。
IE6を早期に切り捨てたリッチなWebサービスも大抵英語から。サービスに乗り遅れるからIE6切る必要性もない。ツイッターが流行ってやっと第一歩というところ。
仏教と関係あるのではという社員もいたが、どっちかと言えば儒教。
新しい仕様や技術に明確な利点があっても、新しいというだけで導入を拒まれる。
どんな無駄な労力をかけても、古きを尊び対応するのが正解だと妄信している。
社内システムや管理アプリがIE6ベースなので変えられない、変える予算もでない。
ちょっとでもリスキーでやらなくてもいいことは、利点がわかっていてもやらない。
IE6しか使えない事にしておけば、いろんなサービスが不便だからインターネットの悪用もついでに防げるだろう（ぼうよみ
っていうか社員各自はろくにインターネットに繋がらないなんて会社も未だにあるのが日本。
とにかく禁止禁止！
アンテナ感度の低さ、古いものへの妄信、金がない、これらが合わさって会社規模でも開発規模でもアジャイル性がとことん低くなっている。
極端な話だと、ネットだけの子よりも、テレビだけの子の方がいい子に育つ。
・情報を選んで手に入れる事ができる
・最新の情報が手に入るかもしれない
・ソーシャルフィルターのかかった情報を手に入れる事ができる（ようになってきている）
→ソーシャルフィルターも広告に企業の広告により、フィルタリングの作用がない
・取捨できるので、好みの娯楽に際限なく時間を費やしてしまう（ニコ動とかね
ステルスマーケティングとか話題になったけど、
もはや堂々とマーケティングに使われて、ネットの信頼性はかなり下がってきてる。
そこでソーシャルのフィルタリング、もっと言うと実名でのFacebookでのフィルタリング。
今後は検索エンジンは死んでいき（もちろん無くなるわけはないけど）、
それぞれ「これはもっと早い・遅い時期じゃないの？」という指摘はあると思うけど、今回は個人的な主観で振り分けた。はてブや SNS で見かけるあの人や、身近なあの人がどの辺りに属するだろうと考えながら読むと面白いかも。
2011年時点の今書くとこんな感じだけど、それぞれの時期にどのインターネット上のサービスを使っているかというのは着目点ではないと思う。昔は SNS も RSS も、さらに検索なんて無かった時代でも、それが別のものに置き換わるだけで「知識を蓄え段々と発信者になっていく」という流れは大筋でずっと変わっていないのではないかと。逆に言えば、それぞれのフェーズに適したサービスがうまくこのインターネットの流れに溶け込めているんじゃないかと。
インターネットに初めて触れる。
本業はWEBプログラマだが、仕事の合間に、アダルト動画の検索エンジンを作ってみた。制作期間４日間（笑）
品ぞろえがいいので、何かエロ動画見たい！って時に、私はDMMを利用することが多いのだが、検索がへぼくてなかなか欲しい動画が見つからなかったりするので、自分でほしい動画を探し出せるようにデータベース化しようと思ったのが最初のきっかけ。
で、キーワードとか、女優のスリーサイズ、ジャンルなどから検索することができ、一覧と一緒にサムネイルとか文章も表示されるので、欲しい動画が探しやすいかな、と。後、自分が単体女優の出演作しか購入しないので、それも検索条件に含めることができるようにしました。
ただ、目立った機能よりも、より使いやすいようなインターフェース作ったり、快適に検索できるように内部的なシステムの調整したりするほうが先かな。
一応、安価なレンタルサーバーなので、いろいろ分散処理したり、ブラウザキャッシュを調整したりしています。