  |
今年は大変暑いですね、営業マンの私は昼間はせっせと汗を流し、夜はその汗を風俗嬢に舐め取ってもらってます。しょっぱぁい美味しいとか言ってるし、きっと喜んでくれているに違いない。
さて、世の中にはたくさんの2ちゃんねるの画像まとめサイトがありますが、もっと一つのサイトに2ちゃんねるの画像がまとまっていれば楽なのにな、、、と常日頃エロ画像巡りをしながら勃起しつつ思っておりました。
Google先生に逐一聞きながら夜なべをして、やっとできたのがこのサイトです。高卒で右も左も分からなくても何とかなるね、そうGoogleならね。
ero.にちゃんぴっくす
コンセプトは2ちゃんねるのエロ板のスレッドにある全ての画像を集め、いい感じで閲覧できるようなサイトです。
スレッドの内容はもとより、やはり画像だけを見てとにかく抜きたいときってあるじゃないですか、そんな男の抜き用途にはベストマッチしていると自負しています。
もともとは自分用に使っていたのですが、せっかくなのでみなさんに見てもらいたくて公開することにしました。
2ちゃんねるのエロ板にグロ画像を貼る不届き者がよくいるのですが、機械学習を駆使してなるべくそれを表示しないようにしました。
今回のようなサイトを作るには一体どんなことが必要なのかを、作り始める前に考える必要があったので、調べてみたら以下のようなことが特に必要だとわかりました。
正直言ってやることは多いし、内容は難しく途中で折れそうになりましたが、快適なシコライフのためちんこを奮い立たせ必死こいて完成させました。
そう、僕は中折れはしないのだ。
そもそもサーバーとは、、、というレベルからはじめたので、調べてみるとWindowsとLinuxが使われることが多いみたいでした。
Windowsはどこを見ても高く、毎月の風俗通いに影響を及ぼしそうでしたので、格好もいいということでLinuxを使うことにしました。初心者向けとのことで、ディストリビューションはdebianを使ってます。
プログラミング言語については後述はしますが、クローラーはPython製のscrapyを、サイト表示側はRuby製のSinatraを使ってます。
言語を分けた点については賛否両論はあるかと思いますが、結果的には良かったと思ってます。
データベースはNoSQLのMongoDBを利用することにしました。もちろんMySQLなどのRDBの使用も検討はしたのですが、スレをテーブル構造に落とし込むとあまりにも正規化が複雑になります。
一方でMongoDBの構造は、スレッドの構成をそのまま突っ込むにはとても適しているかと思います。これについても後述します。
Webサーバー、アプリケーションサーバー、リバースプロキシにはそれぞれ、Nginx、Unicorn、Varnishを使っています。NginxとUnicornについては特に複雑な使い方はしておりません。
Varnishはキャッシュするためにリバースプロキシとして、Nginxの前においております。
サーバーはAWSがいいよとは言われていたのですが、なにせ高いです、風俗代を圧迫します。特に画像メインのサイトに転送量従量課金は死活問題です。それにあんなに高機能なのは必要ないです。
AWSで言うところの、S3とLoad Balancerが機能として提供されている他の安価なサーバー会社は無いかなと探していたところ、Linodeという海外の会社を見つけたのでそれにしました。
これを2つとロードバランサとBlock Storageと呼ばれるS3のようなサーバーを借りて運用しています。これで毎月$120です。
クローラー部分はデータ処理に優れたPythonという言語を使うことにしました。numpyやらscipyといった数学のライブラリも充実しておりとても便利です。
クローラーについてもscrapyというPython製のライブラリがあり、それをゴリゴリにカスタマイズして使ってます。他の言語だと実装が大変な機能も最初から備わっており、それをカスタマイズして使えるので正直クローラー開発についてはこれ以外は考えられません。
scrapyは画像ダウンロードもある程度面倒見てくれるので本当に楽です。MD5ハッシュも自動的に吐き出してくれるので、画像が貼られているスレッドも一覧表示できるようになってます。
つまり画像そのもの単位で管理をすることで、グロや無修正などの有害な画像も比較的対応しやすくなってます。
データベース部分にMongoDBを使用することで、ネストしたデータ構造も簡単に実装できるので柔軟性がものすごく高いです。これのおかげでレスの内容を相当詳しく保存しておいても、とてもわかりやすくなりました。
またトランザクション機能もついたようですし、今後はどんどん使っていこうと思いました。
こちら側はPythonではなく、Ruby製のSinatraを使いました。Rubyはとにかくメソッドチェーンによる処理がわかりやすいこと、hamlやscss、coffee scriptなど、web向けのものが充実しています。
本来ならばRuby on Railsを使用するべきところかもしれませんが、表示に関しては比較的シンプルなのでSinatraにActive Supportを使うことで、かなりサクサクと開発することができました。
今回作るにあたって重要なのはデザインだと思い、個人的にはかなりこだわりました。Twitter Boostrapを使用してはいますが、かなりカスタマイズすることでそれらしさをかなりなくしていると思います。
デザインについてはTTP戦略（徹底的にパクる）で、とにかくパクりました。どこのサイトとは言えませんが、若い女性向けの雑誌であるCa○○amというサイトです。
単純にパクるとは言っても、なかなか難しいかもしれませんので、僕は色、余白、フォントに気をつけてパクりました。
こういうサイトにありがちなデザインのダサさはかなり軽減できたと思います。
ほとんどスマホで見る人がほとんどだと思いますので、モバイルファーストでレスポンシブ対応をしました。
今回NginxとUnicornについてはそこまでチューニングすることなく使用しています。Rubyはそもそもそんなに速度に優れた言語ではないですし、データベースのupdateやcreateすることも殆どないため、リバースプロキシであるVarnishに任せています。
Varnishを使うことで、すでに他の誰かがアクセスして返したHTTP Responseについては、NginxにHTTP Requestを送ることなくVarnishが返せるようになります。
こうすることでNginxはもとより、MongoDBやRubyになるべく処理をさせることが無いようにできます。特にメモリ上にキャッシュをしておけば、通常の100倍以上の高効率が実現できるので、やってない人は今すぐやりましょう。
こうした機能はNginx単体でもできるにはできるのですが、Varnishは設定ファイルがプログラミング言語的（C言語に似ています）なので、複雑な設定も比較的プログラマーにもわかりやすく設定できるのです。
また、Thundering Herdと呼ばれる問題も簡単にかつ細かく設定ができ、さすがリバースプロキシ専用のソフトだな、、、と驚きを隠せません。ピンサロ嬢のフェラーリくらい驚く。
SEOは内部対策として、タイトルとディスクリプションと画像のaltに検索されやすいワードを自然に入れました。altは忘れがちなのでちゃんといれましょう。昔のようにalt属性を詰める人がいますが、あれは逆効果です。
また画像の個別ページについては悩みましたが、noindex, follow属性を入れています。正直コンテンツが少ないページはインデックスさせないほうがいいですし、画像個別ページをユーザーが検索するとも思えません。こういう思い切りは大事だと思います。
なお、unfollowではなく、followなのはリンクは辿ってほしいからです。
外部対策をどうするかについてはすごく悩んでいます、、、これを見た誰かが紹介してくれたらすごく嬉しいです。。。
いろいろ書きましたが、全文検索にElasticSearchを入れたい（今は正規表現での検索のみ）とか、関連するスレッドの表示とかまだまだやりたいことはあります。是非長い目で見てもらえるとすごく喜びます！！！
僕と個人的に連絡が取りたいという稀有な方がいれば、下記までメールをいただけると嬉しいです！
こういうステマってたまに見かけるけど、なんか意味があるからやってんの？ 内容はまともだからこそ気になる。
無修正ばっかじゃねーか、早く逮捕されて氏ね、アフィ野郎が。
phyten またステマか 
13
