表参道フォークウヱル別館（旧）

こんにちは。Forkwell の中の人、大岡（おおか）です。

Forkwell にアクセスしてまず目につくのが、トップページに敷き詰められている、スキルに紐づく各種プロダクトのカラフルなたくさんのロゴ。
「Pi○terest のパクリ」と言われたりもして、今さらそれを否定する気もありませんが、でもこれらのロゴ画像がどうやって作られているか気になりませんか？
今回の記事は、そのスキルのロゴ画像について。

各種スキルのロゴ画像については、内容的に2種類のグループに分かれます。

1. 固有の画像があらかじめ用意されているもの
   
2. 固有の画像がなく、CSSのタイポグラフィが動的に当てられているもの
   

今回は、1の「固有の画像があらかじめ用意されているもの」をご説明したいと思います。
技術的に面白いのは2のほうなのですが、それはまた次回の記事にて。

Ruby、Python、Java、MySQL といったスキルのロゴについては、220x220のPNG画像があらかじめ用意されており、それが表示されています。
用意されている画像は、2012年4月18日現在、59個。
つまり59種類のスキルには人の手によって作られた画像が当て込まれているわけですが、実はこれらは全て、大岡が加工・編集したものとなっています。

GIMP と Inkscape を駆使して（※大岡のデスクトップOSは Linux Mint なので）、開発元がベクター画像を用意して提供してくれているものはそれを使用し、そうでないものは似たフォントを探してきたり、イメージに合う写真を加工したりして作っています。
なぜデザイナーに作ってもらわないかというと、単純に手が足りないからです（苦笑）

プロのデザイナーさんが見れば拙い仕上がりかもしれませんが、でもエンジニアが作っているからこそ、そのプロダクトのバックグラウンドまでを考慮した画像にできている部分もあるのではないかと思っています。

たとえば Haskell のロゴ。
公式に配布されているのは「λ（ラムダ）」をモチーフにしたシンボルのみ。白の背景にこれを置いただけでは味気ない。
ですのでまず、ラムダのイメージにあったフォント探し。Black Chancery というフォントがしっくり来そうだったので、このフォントで「Haskell」のテキストを作成。

さらに「Haskell」の名前は、論理学者の Haskell Curry に由来しています。（関数言語の「カリー化」も彼の名前からとられています。苗字も名前もちなんで技術の名前に使われるなんてすごいですね）
よって、Curry（カレー）にちなんでロゴの背景は香辛料にしてみました。

こんなふうにして59種類の画像は作られています。

ちなみに本日3つの画像（bitbucket、JIRA、Confluence）が増えたのですが、これは Atlassian Software の大澤さんから「公式にロゴのベクター画像を用意してあるので使ってほしい」との依頼を個人的にいただいたので、それを使って作成した画像を追加したのでした。

今回のように、オリジナルロゴのベクター画像ファイル（.svg/.eps/.aiファイル）さえ用意していただければロゴ画像は作れますので、ウチのこのプロダクトを公式のロゴを使ったものに置き換えてほしいという依頼には積極的に対応していきたいと思います。

また、依頼がなくても大岡の手が足りる範囲で、少しずつロゴ画像は増やしていく予定です。
将来的には、ユーザーの方が自分で作ったロゴ画像を Forkwell にアップして、既存のものをユーザー投票で上回ればそれにロゴが差し変わる、みたいな仕組みを考えています。

それはまだ先の話になりますが、その前でも自分の作ったロゴ画像を Forkwell で使ってほしいという要望がもしありましたら、大歓迎ですので順次応じさせていただきます。
ただ、その際には素材画像の著作権には、くれぐれも注意していただけますよう。

たとえば Ruby on Rails のよく見かけるロゴ、あれは DHH に権利があり、彼は第三者に使用を認めていないため、勝手に使うことはできません。（ですので Forkwell では、Rails のロゴ は、線路の写真を加工したものになっています）
またフォントやクリップアート、写真といったものも購入済みでライセンスをクリアしたものか、商用利用可のフリーのものをご使用ください。

次回の記事は、冒頭の2の「固有の画像がなく、CSSのタイポグラフィが動的に当てられている」スキルロゴについての説明です。
普通にロゴは全部が画像だと思っているユーザーの方も少なくないようですが、実は違うというお話。お楽しみに。

こんにちは。Forkwell の中の人、大岡（おおか）です。

前回の記事「なぜ Forkwell はリリース初日にサーバダウンを繰り返したのか」の反響が大きく、一時はホッテントリに入るほどで正直驚きました。
Twitter や ブックマークコメント でご意見も多くいただいたので、今回はそれに対するフォローの記事を書きたいと思います。

一番多かったご意見は、

• 本当に Unicorn が悪かったのか。worker_proccesses の設定値が小さすぎただけじゃないのか。
  
• ちゃんと原因究明してないのに、Unicorn を悪者にするのは Unicorn がかわいそうです(´；ω；`)
  

といったものでした。

500エラーが頻発し出した午前11時すぎから、Passenger への入れ替えを決断した午後5時くらいまでの約6時間、私たちが行っていたのは Webサーバ、アプリケーションサーバ、DBサーバの設定値を片っ端から試してみて、エラーが起こらない最適値があるのかといった試行錯誤でした。

アプリケーションサーバである Unicorn ももちろんその対象であり、最初の worker_proccesses 値は4でしたが、この間に2〜128までのほとんど全ての2の乗数は試してみました。

それでも MissingAttributeError は、一向に止む気配すら見せませんでした。
それでも唯一効果があったのは、前回書いた通り Nginx の同時接続数を絞ったときに多少マシになったこと。
スタックトレースを見れば原因はわかるだろうと言われるかもしれませんが、低負荷時に全く起きなかったありとあらゆる全ての Model において脈絡なく上がってくるエラーの中身を読んだところで、何の見当もつきません。

また、「復旧後になぜそうなったのかちゃんと調査したのか」という疑問の声も聞かれました。
Unicorn にデバッグコードを入れて、JMeter 等で高負荷をかけてひとつひとつ紐解いていけば、それも可能かもしれません。
しかし正直なところ、Passenger でちゃんと動いているのでそこまでして Unicorn での不具合の究明にリソースを割けないというのが弊社の事情です。

Forkwell は必要最小限の人員で開発・運営していますので、日々のバグ修正、機能改善、新機能の追加、その他プロモーションのための施策等で現状は手一杯です。
それでも「自分なら原因を究明してみせる！」という方がいらっしゃいましたら、ぜひ弊社までお越しいただき、秘密保持契約を結んだ上で各種ログをお見せしますので（DBは見せられませんが）、どうぞお申し出ください。

次に Passenger について。

• Passenger に変えてうまくいったというのは結果論ではないのか。無条件に Passenger を奨めるのはどうかと思う。
  

というご意見がありました。
これについては、ユーザーの方からご紹介いただいたページが参考になると思います。

■ apache,nginx × passenger,unicornのベンチをとってみた - CubicLouve

こちらのページでは Nginx + Passenger の組み合わせは再ビルドが発生するので見送ったそうですが、Unicorn の worker_processes を60、Passenger はデフォルト設定で、

Apache + Passgenger ＞ Nginx + Unicorn ＞ Apache + Unicorn

というベンチマーク結果が出ています。
ここから推測するに、おそらく Nginx + Passenger の組み合わせがこの4つの中では最もパフォーマンスが高くなるものと思われます。
もちろんマシンスペックやその他の設定値によってこの結果が変わってくる可能性も否定できませんが、このような結果が出ている以上、Passenger に一日の長があるのはほぼ間違いなさそうです。

さらにこのベンチマークに使用したのはシンプルなアプリだったということですが、現状の Forkwell のような1アクセスで膨大なクエリーが発生するアプリでは Unicorn は単純なパフォーマンスの話だけでなく、DB接続周りに不具合が出てしまうのではないかというのが、今回のことから推察されます。

今回の Forkwell のような事態が起きたときに、ちゃんと原因を追求できるリソースが確保でき（理想としては専門のインフラエンジニアがいること）、サーバのリソースにも十分な余裕があるのであれば、Unicorn を使用するのも妥当な判断なのでしょう。
ただ弊社のようなスタートアップで全てのリソースに余裕がない場合、チューニングなしのデフォルト設定でそれなりのパフォーマンスを発揮する Passenger が無難なのではないかというのが大岡の言いたかったことです。

あと、どうも誤解を招いている点について補足説明したいと思います。

現在、Forkwell はいちおう安定運用できているのですが、「まだ重い」という声もちらほら聞こえます。
計測するとHTMLページ自体は400ms〜500msで返しており、速いとは決して言えませんが「重い」と言及されるほどのレベルではないようです。

これについて、「Forkwell 重いよ。ユーザーの声が信じられないのか」「『重くない』って、対策する気はないの？」のようなご意見がありましたが、そんなことは全くありません。

wget でトップの index.html（そんなファイルはありませんが、ここは便宜的に）をダウンロードしたときにかかるのが400ms〜500msということで、それ自体はエンジニアとしては遅いと思うが一般ユーザーとして考えるなら、他のサイトと比較してもそれほど「重い」とは言えない。

ただしブラウザでページが表示されるまでは早くて2500ms、遅ければ8000msもかかることがあり、それは単純にサーバが負荷に耐え切れずにパフォーマンスが落ちているからとか、膨大なクエリーをさばききれずに時間がかかっているからという問題ではなく、Facebook からのプロフィール画像のリダイレクト含みの読み込みや、各種静的画像やWebフォントおよびJSやCSSファイルの読み込み、レンダリングに使用している JavaScript ライブラリの実行等が大きく影響しているので、それについてはひとつずつ順次対応していくと。

そう申し上げたつもりだったのですが、言葉足らずで伝わらなかったようです。
Forkwell はこれからもパフォーマンス改善に向けて随時対応していきますし、それによりトップページももっと快適に閲覧できるようになるはずです。
先述したようにリソースが不足しているため、今日明日で目に見えて改善していくということはありませんが、それについてはどうか長い目で見ていただけましたら。

前回のお話のフォローはこのへんで。
私も忙しさにかまけて負荷テストを忘れてしまうような人間なのでこれからも至らぬ点が目につくかもしれませんが、ユーザーの方々にご意見いただくことでいっしょにこのサービスを育てていけたらと思っています。

こんにちは。Forkwell の中の人、大岡（おおか）です。

本日は、お恥ずかしながら Forkwell リリース初日の失態について、詳細をお話しようと思います。
当初からのユーザーの方はご存知かもしれませんが、先週4月3日（火）に Forkwell がリリースされた際、殺到するアクセスの負荷に耐え切れず、深夜までサーバダウンを繰り返しました。

なぜそんなことになったのか。
端的に言えば、ロクに負荷テストを行ってなかったからというのが真相という間抜けなオチなのですが。

初めての慣れないディレクター業務で連日サービスリリースのことで頭が一杯になっていた大岡は、負荷テストのことがすっぽり頭から抜けていました。
私も過去、Apache Bench や JMeter で負荷テストを行った経験はもちろん何度もあったのですが、今回はウソのようにきれいさっぱり忘れてしまっていました。
ディレクター業務に加え、システム設計やサーバ構成等も大岡の担当でしたので、そのあたりの責任は免れません。

システム構成の詳細を説明すると、Forkwell のサーバは全てAWSを使用しています。
当初、Amazon EC2 のラージインスタンスをWebサーバ用に3台、DB用に1台を用意。
Webサーバは Nginx、アプリケーションサーバに Unicorn、DBは MySQL。

3台のWebサーバは、Amazon Elastic Load Balancingで分散され、始まったばかりのサービスなら誰もが十分過ぎるスペックだと思ったでしょう。私もそう思ってました。

インターネット上にサービスを公開したのはだいたい午前9:30ごろ。そして10:30をもって正式リリースの告知を行いました。
当初は大量に画像を読み込むトップページこそ多少重かったものの、サービスは順調に稼働していました。

ところがお昼前に立て続けにTechCrunchの記事、@ITの記事が公開されるやいなや、アクセスが殺到。そして500エラーが頻発。血の気が引きました。
Webサーバ、アプリケーションサーバ、DBサーバの再起動を行うことで一時的に改善するのですが、すぐにまた同じ現象が起きてしまいます。

どうもアプリケーションサーバに問題があるらしく、Unicorn のログを見ると「ActiveModel::MissingAttributeError」という謎の例外が大量に発生しています。

こんなエラーは、チームの誰も見たことがありません。

しかしDBサーバのCPU使用率は全く上がっていなかったため、まず行ったことは MySQL 設定のチューニング。
Unicorn のDBとの接続のところに問題があるために、ActiveRecord のインスタンスが不完全になっているのではとの推測のもとに、MySQL の同時接続数を増やすことで対応できるのではないかと思ったのです。
しかし状況はあまり変わらず。その後も色々と試行錯誤を重ねましたが、Nginx の外部コネクション数を制限することで、束の間の小康状態を得ることができました。

しかしそれでも、アクセス3〜4回に1回は500エラーが発生する状態でしたので、ゆっくりしているわけにもいきません。
この時点で午後5時。このままではサービスを一時閉鎖してごめんなさいするしかないのでは、という空気が社内に広がっていました。

でもその前に、大岡には試してみたいことがありました。
アプリケーションサーバを Unicorn から Phusion Passenger に変更することです。

前々から Nginx + Passenger の組み合わせは最強という話は聞いていましたし、自分のブログでも2年以上使っていてその安定性に驚愕していました。
当初はこの組み合わせでいくつもりだったのですが、担当エンジニアのリソース不足で慣れないものを入れる余裕がなく、開発環境と同じ Unicorn のままリリースしてしまっていたのでした。

ここは当初の予定通り、多少の時間をかけてでも Passenger に変更すべきだと思いました。
馬場くんにNginxでアプリケーションが動くか検証してもらい、その環境をEC2に展開、それを AMI (Amazon Machine Image) に保存し、本番のサーバを1台ずつ落として入れ替えるという作業に、およそ4〜5時間を要しました。

希望が見えたのは、Webサーバの1台目を Passenger に入れ替えたとき。
Unicorn 環境では Load Average がすぐに5とかに上がってどうしようもなかったWebサーバが、Load Average 0.1〜0.2 付近に収まり、しかもそのサーバに振られたリクエストでは一切500エラーが発生しなかったのです。

大急ぎで全てのサーバを Passenger に入れ替え。するとウソのように500エラーは影を潜め、ブラウザからのレスポンス速度も目に見えて改善しました。
これには開発チーム全員が、声を上げて喜びました。

私も人生の中でこれほど安堵した瞬間はなかったほど。Passenger のおかげで、その日はチーム全員、終電までに帰宅することができました。
（しかし実は、Nginx + Passenger の SSL のリダイレクト設定に問題があり、Passenger に変更してからユーザー登録ができない状態になっていたらしく、そこから翌日の午前10:30くらいに対応するまでそれが続いてしまっていました。申し訳ありません）

ただ、Unicorn も Rails でアクセス数トップランキングに入るようなサービスで普通に使われていますし、携帯ソーシャルゲームでも Unicorn を使用している会社が多いようです。
ですので、ちゃんと設定を細かく詰められるインフラエンジニアがいて、それなりの台数を用意できるのであれば問題ないのでしょう。

しかしそうでない場合は、Passenger にしておいたほうが無難のようです。
Passenger に変えてからは、アプリケーションサーバがネックになることは全くなくなりました。むしろたまにDBサーバのほうが足を引っ張ることがあるくらい。

Forkwell のシステムはトップページが一番重く、コンテンツを組み立てるために尋常ではないクエリー数が発生しています。
これについてはクエリーの最適化が行われていないためであり、現在に至るも対応中です。
PVそのものは数万という、Webサービスとしては大した規模ではなかったのですが、この1アクセスで大量のクエリーが発生するという特性が、Unicorn と相性が悪かったのではないかというのが、開発チームの見解です。

あと「どうして Heroku にしなかったのか。Heroku ならそんな心配はなかったのに」というご意見を多くいただいたのですが、それについては以下のような理由です。

まず、サービスを日本で見てもアメリカで見ても、レイテンシのストレスが極力少なくなるようにしたかった。
世界展開を見据え、シリコンバレー周辺で見たときに最も快適に使えるようにしたいと考えていました。
ですので、サーバの物理的な設置場所は米国西海岸リージョン以外に考えられませんでした。

次に、日本語全文検索のソリューションを必要としていたこと。
将来的に Forkwell では、スキルタグのページにそのスキルに関連する情報を外部のものも含めて集約したいと考えているため、今はそれほどでなくてもその内に日本語全文検索が必要になってきます。

Heroku にしなかった主な理由はその２つ。
あと、私は古いタイプのエンジニアなので、中で何が起こってるかよくわからない PaaS を本番のサービスに使うのはまだ何となく不安があるというのもありました。

現在、Forkwell はいちおう安定運用できているのですが、「まだ重い」という声もちらほら聞こえます。
計測するとHTMLページ自体は400ms〜500msで返しており、速いとは決して言えませんが「重い」と言及されるほどのレベルではないようです。

何が重く感じさせているのかというと、トップページの各スキルのアクティビティに付随するユーザーの Facebook プロフィール画像。
これが読み込みにかなりの時間を食っています。リソースURLに毎回リダイレクトがかかるため、いちいち時間がかかる。またリダイレクトのせいで、ページに同じユーザーの画像が10回出てきても、キャッシュされず10回リクエストをかけてしまう。

これがページのレンダリングを非常に遅くしている原因です。
ですので本日、トップページの Facebook プロフィール画像を読み込む箇所に Lazy Loading 対応を行いました。
ページのレンダリングを先に行い、画像は適宜読み込むようにしましたので、これにより体感的にはいくらか改善されているはずです。

また先に挙げたクエリーの最適化、プロフィール画像のキャッシュ、静的ファイルの置き場所をCDN対応する、等の施策を行っていく予定であり、今後さらに改善されていくものと思います。

以上が、Forkwell リリース当日の不始末の概要です。
これをご覧の優秀なエンジニアの方々はこんなミスをすることはまずないと思いますが、他山の石とでもしていただけましたら。

【2012/4/16 追記】
続編を書きました。
お寄せいただいた意見や質問に対してお答えしています。

こんにちは。Forkwell の中の人、大岡（おおか）です。

Forkwell のステッカーが完成しました！
ホワイトとシルバーの2種類。シルバーのほうは、主に MacBook に貼ってもらうことを意識したアルミヘアライン調の表面となっています。

中の人が言うのも何ですが、かなりかっこよく仕上がっています。
特にシルバーは MacBook に貼ると、狙い通りにうまく溶けこんでくれていい感じです。
ヘアラインが横に入っていて、MacBook のスモーキーなアルミ表面と合わないのではないかと心配したのですがそんなことはなく、近くで見たときにはむしろいいポイントになっています。

このステッカー、基本的には無料でお配りしてどんどん使っていただきたいと考えています。

とは言っても無差別に街角で手渡すわけにもいきませんので、 大岡を始めとする弊社のスタッフが何らかのイベントに参加したときに配布する形にしたいと思います。

直近では、

• 4月13日（金） Tokyo Rubyist Meetup “Heroku and Travis CI”
  
• 4月14日（土） 第153回 Asakusa.rb（お花見会）
  
• 4月28日（土） 超エンジニアミーティング〜Happy Hacking!〜 in ニコニコ超会議
  

が大岡が参加するイベントとなってますので、そこで配布の予定です。（※Ruby関係に偏っててすみません…）

【4月12日追記】
4月20日（金） Heroku JP Meetup #4 に開発メンバーの馬場くんが参加することになりましたので、そこでも配布致します。

またそれ以外にも、スタートアップ系のイベントには積極的に参加していきますので、そちらでもお渡しできたらと考えています。

ステッカーの話はここまで。
ところで今日、Forkwell にログインされた方は「おやっ？」と思われたのではないでしょうか。

本日、初めての「称号」の再付与を行いました。

これまではユーザー全員が「Novice」という一番格下の称号だったのですが、+1 されたポイントの合計数により、7種類の異なった称号があらためて付与されています。
（※「あれ？ 自分は +1 されてるのに、Noviceのままだけど」という方は、お手数ですがログアウトして再ログインしてください。次回からは再ログインなしで称号の再付与を行います）

称号の説明のページにもありますが、称号は全部で9種類。下から、

1. Novice （ノーヴィス）
   
2. Apprentice （アプレンティス）
   
3. Craftsman （クラフトマン）
   
4. Journeyman （ジャーニーマン）
   
5. Artisan （アルティザン）
   
6. Master （マスター）
   
7. Grandmaster （グランマスター）
   

となっており、最上位2つはまだヒミツです。
なお、まだ今回は最上位2つの称号は付与していません。

勘のいい方はピンと来るかもしれませんが、これは中世のギルドの職人制度をモチーフにしています。（「Novice」は少し毛色が違いますが）
MMORPG等ではこれらの名称がよく使われるようですが、別にそれを意識したわけではありません。

過去に名著『ソフトウェア職人気質』や『アプレンティスシップ・パターン』を読んで感銘を受けたからというのが、本当のところです。
（ちなみに「職人気質」は「しょくにんきしつ」ではなく「しょくにんかたぎ」と読みます。当初ずっと「きしつ」と読んでいて、真実を知ったときは恥ずかしかった思い出があります）

ソフトウェア工学なんてSucksだ（いやそこまで言ってませんでしたが）、ソフトウェア開発は熟練技能者による工芸品に近いという主張は、当時の私にとって衝撃でした。
アジャイルを深く理解する手助けにもなると思うので、読んだことがないという方はぜひ読んでみてください。

話は逸れましたが、Forkwell の称号の再付与は週1回定期的に行われます。
ネットサービスでよくあるバッジは一度もらったものが消えることはありませんが、Forkwell の称号は査定のたびにランクに合わせて入れ替わるものです。

ですので油断していると、最初高い称号を得たとしても、どんどん降格していってしまいます。
これを読んでくださっているユーザーの方々がそうならないよう、願っています。

こんにちは、Forkwell プロダクトマネージャーの大岡です。
本日の記事は Forkwell のメイン機能のひとつ、他人のスキルへの「+1」について書きたいと思います。

現在、全ユーザーにおける +1 ポイントの総スキル合計数、また Ruby および Ruby on Rails 個別スキルにおける +1 ポイントの合計数においても、ぶっちぎりのトップが Forkwell の技術顧問である松田明さんです。

松田さんの +1 ポイントは、Ruby on Rails で +25、Ruby では +23 となっています。
この数値は多いか少ないか。全ユーザー数を勘案しても、運営側としては少ないと感じています。

どうも Twitter でつぶやかれる感想等を見ていても、「+1していい基準がわからない」というユーザーの方が多い様子。

ですのでここで、私がどういう方々に +1 しているかをご紹介したいと思います。

たとえば我らが「Ruby の父」、Matz。
彼の Ruby スキルの現在のポイントは +16。いや少なすぎるでしょう、いくらなんでも（笑）

Rubyコミッタの松田さんとか村田賢太さん（Cookpad）は Ruby スキルには一切 +1 せず、C に +1 しているという状態。
彼らとしては、「Matz の Ruby コードとかほとんど読んだことないし。自分たちが普段見てるのは C のコードだし」ということなのでしょうが、それはあまりにも生真面目に過ぎるというもの。

ちなみに大岡は、もちろん Matz の Ruby に +1 しています。

確かに Matz の Ruby コードを読んだことはないですが、Ruby という言語をデザインしたのは他ならぬ彼ですし、その仕様もなぜそうなったかの背景も含めて誰よりも把握しているはず。
それよりも何よりも、Ruby という素晴らしい言語をこの世に送り出してくれたことに一ファンとして感謝の気持ちを込めて +1 しているわけです。

たとえば jpmobile。
Ruby に詳しくない方のために説明しておくと、jpmobile とはガラケー対応のための Rails 用プラグインです。

私はフリーランス時代にドリコムでゲームを作っていた時を含めて、3年くらい jpmobile のお世話になっていました。（またお世話になるかもしれませんが）
ですのでその感謝の気持ちを表して、現メインコミッターの小川伸一郎さん（イオレ）と最初に開発された設樂洋爾さん（えにしテック）に +1 しています。

たとえば、最近メディアでよく見かける閑歳孝子さん（ユーザーローカル）。
彼女は個人でスマートフォン用家計簿アプリの Zaim を開発したことで有名な方です。

私は彼女のコードを読んだことはありませんが、あれを Titanium Mobile で作ったことは何かの記事で読んでいて、これほどのアプリを作れるのなら彼女の Titanium Mobile の腕はまちがいないのだろうということで、ミーハーな気持ちも若干ありましたが +1 しました。

あとはたとえば N88-BASIC とか。
もはや誰のコードを読むことも望んでも適わぬ、いにしえのプログラミング言語ですが、これがついている知人は親近感から問答無用に +1 します（笑）

さらに Redbull とかのネタタグも笑ったので知人に +1。

ちなみに、ふざけたネタのタグは運営に消されるかと懸念している方がいるかもしれませんが、こちらとしては誰かの誹謗中傷とかプライバシーを侵害しているかでもない限り（あとは単なるタイポやスペルミス）、タグそのものを抹消することはありません。
それを言うならそもそも Beer タグは、うちの松田さんが最初に作ったものですし（笑）

というわけで、私はこんなふうに +1 しています。
そして公式に運営側としても、+1 する基準は人それぞれであっていいと考えています。

「その人のコードを読んだことがない限り +1 しない」という人がいてもいいし、もっとざっくばらんな基準の人がいてもいい。
たくさんのユーザーがそれぞれの基準で +1 すれば、マクロ的な視点からそれは平均的なところに落ち着くものと思っていますので。

ですので、最初の「+1 していい基準がわからない」と言われていた方々には、「あなたが +1 したいと思った人に +1 すればいいですよ」と答えてあげたいです。

ネットサービスなんて、「こう使ってほしい」と開発者が思っていてもユーザーが勝手に使い方を決めて自由に使うものじゃないですか。
ポケベルの数字メッセージとかもそうですし。喩えが古いですかね（笑）

…と、ここまで書いてきたのですが、+1 に躊躇される方が多い理由にひとつ心当たりがありました。
私が@ITの記事で西村さんにしゃべったことです。

誰かが自分のスキルとしてRuby、Ruby on Rails、Clojure、jQuery、Titanium、vimなどとタグでリストアップしていくと、これを見たリアルな知り合いがそのスキルを認めている場合には+1していく。実際に同じ職場で働いたことがあるエンジニア同士であっても、実際にコードを見たことがないとか、自身に評価できるだけのスキルがない場合には、+1をしないという。「相手のスキルを知っていれば、推薦文を書くよりも気軽に+1できる」（大岡氏）のがポイントだが、“すごいと聞いている”という程度では押さない、というわけだ。

西村さんも本職は記者さんながら、自身もコードを書かれる「ギーク」なので、まあ話の勢いで確かにそんなことも言ってしまった記憶があります。

でも当の開発者でも“すごいと聞いている”程度で押してるので、みなさんも遠慮せず +1 してくださってけっこうです。
そもそも、「レピュテーション（評判）を可視化する」のが Forkwell の +1 の狙いです。「すごいと聞いて、すごいと思った」というのも評判の内じゃないですか。

ちなみに、明日は初めて「称号」の査定を走らせます。
先週のリリースからずっと、全てのユーザーは「Novice」という一番下の称号だったわけですが、明日はそれが昇格する方が大量に出るということです。

ですので今日の内に、取りこぼしがないように +1 してあげてください。
明日の称号査定、お楽しみに。