進・日進月歩

IT, Jazz, study, engineering, すべての真実とクリエイティビティのために

Archive for the ‘雑記’ Category

twitterとmixiやめてみた

  • Filed under: 雑記
Monday
Aug 16,2010

twitterとmixiをやめてみました。

実はtwitterは2回、mixiも2回ほどすでにやめたことあるんですが、その度になんとなく復活してました。
やっぱり友達に連絡するには便利ですよねアレ。

twitterとかは割りと積極的に発言したりしていて760くらいフォロワーがいたりもしたんですが、自分があまり気のきいたこと言ってないのもあるかもですが、おもしろい発言とかからみが帰ってくるわけでもなかったです。

あんまり面白く無いしtogetterやまとめページを見る方が早いし有益だなぁと思いました。

自分が書くにしても、twitterとかで適当な釣り発言しているよりは、blogとかできちんとまとめて書く方がきっと有益だろうなという気もしました。

ご連絡の際は、facebookかskype, メッセンジャーでどうぞ。

  • Comments Off
  • 自宅サーバでgyazoをしよう

    • Filed under: 雑記
    Tuesday
    May 18,2010

    実際はホスティングなんですが。

    gyazoって知ってますか?masuiさんが開発された驚異的な便利ツールです。
    実はこれGPLでオープンソースになっています。

    自宅サーバでgyazoを運用するためのtipsです。
    当方macなので、クライアントがmacでserver側はrack(rubyのアプリケーションコンテナ)を使うようにしています。

    さて、自宅サーバでgyazoをするメリットとは。

    • 情報漏洩リスクが低い
    • basic認証かけたりできる
    • 社内の情報共有ツールとして使う
    • ログがとれる

    などなどでしょうか。

    情報漏洩リスクは、低いと言えば低いんですがgyazo.comは本質的には情報漏洩リスクがあります。
    どっかの会社ではあまり気にしないで使われてるんですが、twitterがコンプライアンス違反ならこっちの方が余程リスクが高い気もします・・・・(細かい話はまた別で

    だから、自分で運用するgyazoをたてましょうということです。

    ちょっと運用上の問題からオリジナルのgyazoから多少の変更をしています。

    手順は

    1. 私のgithubからチェックアウト
    2. クライアント側のパスワードとサーバのアドレス設定
    3. サーバ側にrackをデプロイ

    こんな感じです。

    githubからチェックアウト

    私のgithubからチェックアウトするかフォークするかしてください。

    git clone git://github.com/harajune/Gyazo.git

    するとソースが落ちてきます。

    クライアント側の設定

    ほとんどの人はwindowsなんでしょうけど、自分はmacなのでmacの説明。
    一応windowsもソースみたんですが多分簡単に出来そうな気がします。

    以下の要領でクライアントの設定をしてください。

    cd Gyazo.app/Contents/Resources
    cp config.sample.rb config.rb
    vi config.rb

    viじゃなくてもいいですが。config.rbを以下のように編集します。

    HOST=”your.domain.com”
    CGI=”/upload”

    CGIの方はアップロードの時に使うパスです。一応デフォルトがこれです。

    これでクライアントの設定は終了。

    サーバにrackを設置

    アプリケーションコンテナは好きなのを使ってください。私はpassengerを好んで使っています。

    Serverディレクトリ以下を適当なrackコンテナの場所に設置してください。basic認証とかしたく無ければこれで終了。

    終わり

    以上です。open Gyazo.app とかしてgyazoってみてください。
    たぶんちゃんと動くはずです。

    実はちょっとだけ改造してあります

    本家gyazoはCGIでの運用が前提になっているので個人的には扱いにくいです・・・・
    ので、harajuneバージョンではrackに対応させてあります。

    まぁ大した差はないんですが、ほとんどのrubyアプリケーションコンテナがrackに対応していますし、cgiって個人的には運用が面倒なのでこちらの方がいい気がしています。

    というわけで、楽しいgyazoライフを!

    redmineをruby1.9で動かす

    • Filed under: 雑記
    Tuesday
    May 11,2010

    とりあえずな対応ですが・・・・

    使ってる環境がruby1.9.2trunkとrails3.0betaなんですが、残念ながらredmineはrails2.3.5とruby1.8.xでしか動かない。

    とりあえず動かしてみたところ、基本的にひっかかるのは文字コード周りであることがわかったためちょっと修正してみたらだいたい動く感じになりました。

    ポイントは

    • gitを使う
    • rails2.3.5をvendor/railsに入れる
    • Stringを拡張する
    • Encoding.external_encodingをUTF-8にする
    • postやgetの値paramsを全部force_encoding("UTF-8")する

    です。

    gitを使う

    redmineを直接いじるのでバージョン管理する方がおすすめです。

    git clone http://github.com/edavis10/redmine.git

    このgitリポジトリはofficialミラーだそうです。

    rails2.3.5をvendor/railsに入れる

    git submoduleが便利です。

    git submodule add http://github.com/rails/rails.git ./vendor/rails

    そして、railsの中身をv2.3.5にします。

    cd vendor/rails/
    git checkout -b v235 v2.3.5

    これでok。

    Stringを拡張する

    String.eachが1.9では無くなっています。代わりにeach_lineを使えばいいんですが、全部書き換えるのが面倒なので、config/environment.rbに書いちゃいます。

    config/environment.rb

    CODE:
    1. class String
    2. def each(*args)
    3. self.each_line(*args)
    4. end
    5. end

    class String
    def each(*args)
    self.each_line(*args)
    end
    end

    Encoding.external_encodingをUTF-8にする

    いらないかもしれない。config/environment.rbに書き込みます。

    config/environment.rb

    Encoding.default_external = "UTF-8"
    postやgetの値paramsを全部force_encoding("UTF-8")する
    ここ一番きもです。app/controllers/application.rbにparams全部にutf8を設定します。

    app/controllers/application_controller.rb

    CODE:
    1. before_filter :params_filter
    2.  
    3. def params_filter
    4. self.utf8nize(params)
    5.  
    6. end
    7.  
    8. def utf8nize(obj)
    9. if obj.is_a? String
    10. obj.force_encoding("UTF-8")
    11. elsif obj.is_a? Hash
    12. obj.each {|key, val|
    13. obj[key] = self.utf8nize(val)
    14. }
    15. elsif obj.is_a? Array
    16. obj.map {|val| self.utf8nize(val)}
    17. else
    18. obj
    19. end
    20. end

    だいたいこんな感じでruby1.9でもredmineが動くようになりました。

    とりあえず動かないところ見つける度に直してるのであまり網羅的ではないかも。

    一応githubでコードは晒してあります

  • Comments Off
  • Sunday
    Apr 11,2010

    ポールグレアムの「知っておきたかったこと」に引っ掛けて、すごく卑近な就職活動について知っておきたかったことをまとめようと思います。

    あまり具体的な企業名とか自分のスペックについて書かないのであまり面白くは無いかもですが、誰かの役に立つかもしれないと思い書いておこうと思います。

    1, 就職活動は戦略が大事

    思いつきでうけると間違いなく泥沼化します。
    思ったよりもガンガンお祈りメールが来るものなので、わかってても結構落ち込みますし周りが内定で始めると焦ります。
    そうした時に慌てて適当にES書いて出したりすると、時間も取られるはお祈りメールは増えるはでいいこと皆無です。

    企業によっては(公的には言わないものの)OB訪問が事実上必須になっているところもあります。知ってる範囲でも生保は新入社員が事実上のリクルータになっているところがありますし、どこぞやの有名企業はOB訪問の結果を人事に提出させられるところもあるそうです。
    OB訪問に参加しないと出れないイベントがあったり、イベントに出ないとうけられない選考があったり・・・・どんだけ隠れルートがあるのか想像もつきません・・・・・
    だからこそ、思いつきでうけることはできるだけ避け、行きたい会社の情報をいかに集めるかが重要になっていきます。
    ある程度就職活動が始まる前に、どういう企業をうけるか程度は考えておきましょう。

    2, 友達は大変重要

    OBの共有したり、隠れイベントの情報を共有したり・・・・・本当にこれ重要です。
    ネットに書いてあることは情報が遅かったり、そもそも公開できる情報しかなかったりしますし、そもそもググる時間がかかって面倒です。
    自分たちは友達同士でグループチャットを作り、「あそこの選考どうだった?」とか「ESこういうのは通ったけどアレはダメだった」といったことを即時共有していました。
    こういう情報は、ネットで調べるよりも100倍信用できますし情報も早くていいです。

    3, webテストは必ず対策しよう

    あんまり具体的には書きませんが、どこの会社がなんのwebテストを利用しているかというのは市販の書籍にまとめられていたりします。びっくり。

    しかも、そのwebテストもひどいもので、問題の数があまりにも少なく3,4回うけると問題が重複しはじめて問題文読まなくても解けたりします・・・・・・
    webテスト対策本は過去の問題を再構成していたりするので、ぜひともやっておくことをお勧めします。
    また、webテストの練習のためだけに何社かうけておくのもいいかもしれません。本命をうける頃には知ってる問題だらけに・・・・とかいうこともあり得ます・・・・・

    テストによっては、紙でうけてもwebでうけても問題が一緒だったりすることもあり、webテストはやればやるほどお得になります。

    4, コネ重要

    例えば、入りたい会社でアルバイトとかしてると筆記免除になったりします。
    会社によってはそのままいつのまにか採用で終わります。友達でも何人かはこのパターンがいます。
    自分も、就職人気ランキングに入るような商社で「もしうちにきたいなら人事部長紹介するよ」と言われたことがあります(結局お願いはしませんでしたが)
    そういう感じで、一番理想的なのは興味のある業界や会社でアルバイトしたりインターンしておくのが一番いいと思います。
    一応念のために言っておきますが、そういうコネで何かお願いして内定取ったらちゃんとその会社入りましょう。その後の人間関係に響きます・・・・・
    断るかもしれないなら最初からお願いするのはやめておくのが人の道という気がします(※個人の感想です)

    とは言っても就職活動なので、向こうも「そういうものだ」という心づもりでOB訪問受け入れてるところもあるので、そういう常識的な判断が出来ないならお願いしておいた方が日本企業全体としては正解な気がします。

    5, 学生時代は「仕事しながら遊ぶ」のが一番いい

    周り見てると、自分も含めベンチャーでお仕事したり会社作ってつぶしたりとかしてる人の方が就職活動うまくいっているように思います。
    結局は相手の言ってることがわかったりとか話が通じることが重要なんだなと。
    自分もなんか結局IT関連企業以外もいくつかうけてみましたがサッパリでしたし・・・・・逆にITの企業だと談笑して特になにか面接するわけでもなく通るんですよね。
    グループディスカッションとかしても、結局打ち合わせとかに慣れているかどうかで出来が全く違うように思います。

    なにか、課題が出された時もその業界で何かしてれば過去に使った資料とかを使ってそのままやれば大概通ります。

    プログラマがプログラム書いたら負けですよね(キリッ

    とか言っても通ります・・・・・こういうネタが通るくらいまでよく事情知ってれば通るんじゃないでしょうか。

    6, グループディスカッションのコツ

    グループディスカッション3回しかしてないですが、全勝してます。自分の何が良かったのかはよくわからないですが、自分がグループディスカッション中に指摘したり気になったりしたことをいくつか。

    • 大抵の場合、まとめ役がいない
    • 大抵の場合、目的が達成されていない
    • 大抵の場合、みんな意見を曲げない

    大抵の場合、まとめ役がいない

    まとめようとする人はいるんですけどね。ファシリテーションの本とかを読むと大抵書いてあると思いますが、まとめ役に重要なことはとにかく「受け入れる」ことです。
    ホワイトボードでも紙でもいいので、誰かが言ったことは必ずどこかに書き留めましょう。不思議とこれだけで発言者に納得感があるようです。

    次に、意見を戦わせては行けません。やってみればわかりますが情報少ないので「どちらが正しいかを論理的に説明する」とか不可能です。
    まず考えるべきは、単純に2つの意見をくっつけます。日本語はだいたい文が長くなっても読めます。違和感がないレベルではどんどんくっつけましょう。
    その次は、場合分けをしましょう。「これこれこうだったらAが正しいね」「これこれこうだったらBが正しいね」という感じにします。
    私はこの発想の元に、結論をでっかいワークフローにまとめて発表したことがあります。誰も文章にしろとはいってないわけでセーフです(もちろん通りました)
    こういう思考フレーム(笑)は、最近勝間和代という人が色んな本でまとめてるそうですが、普通にファシリテーションとしてはよくある話で、学生団体とかで不毛な議論に辟易してる人は読んでみるといい気がします。(実際自分はそういう理由でちょっと勉強したりして、地味に色々やってました)

    大抵の場合、目的が達成されていない

    大抵の場合、お題に対する結論が出たところで満足して終了することが多いようです。
    けど、ほとんどの場合与えられた課題は「発表しなさい」ですよね。
    だから常識的に考えるとプレゼンテーション作るところまでがお仕事です。

    全員がそこまでの全体感をもってGDできないと時間が無くなってしまうので、ほとんどの場合は無理なんですが、1回だけ時間が余ることがあったのでプレゼンテーションの内容検討まで全部やってみました。
    そしたら社員の人に「突っ込むところがない・・・・・」と言わしめるクオリティにまではなりました。余裕があったらここまでやってみたらいい気がします。

    時間が余ったからプレゼン内容について検討しようよ(キリッ

    実は言ってみたかっただけです(ぉ

    大抵の場合、みんな意見を曲げない

    これは最初のと一緒ですが。
    とにかく他人の意見を受け入れることを最優先しましょう。とにかくどっかに書くだけでも納得してくれます。どっかに書いておけばその人は同じことを二回も三回も言いません。
    その人の思考を1ステップすすめてあげることが重要です。

    脳はそんなにたくさんのことが考えられないため、とりあえずその人の考えを脳の外に出してあげるとその人の考えが前に進みます。
    「なんだこいつしつこいな」と思ったら、意見を否定するのではなく、その人の考えを脳から出して思考を前に進めてあげることを考えましょう。

    7, 就活だけでなく学生生活全般について。就社ではなく就職。

    実はこれが一番難しいんだと結果的に思うのですが、要は自分のやってみたいことをやってみるということです。
    留学行きたい人はさっさといってくればいいし、ゲーム作りたい人はゲーム作れば言い訳です。

    自分は最初IT関係でプログラミングしてみたいと思って、大学一年の頃にプログラミングのバイトを探してプログラミングを覚え、起業とか面白いかなと思って学生ベンチャーに入って、これだったら俺でも出来るだろうjkとか思ってさっさと独立してやってみたけどなんか違うかなぁと思って今に至っています。
    結果的にIT好きでプログラムも組めるんですが、プログラマとか開発者ってなんか違うなぁと思い、最近はプログラミングをする傍らひとつメタレベルでの活動をしています。フレームワーク導入したりデプロイ方法を工夫したりチケット管理をやってみたりetc,etc。

    結局そういう感じで色々やってくうちに就活の時期にやってくると、それなりにやってることにあった会社に入れるんではないかなという気がします。

    結局いつかは働かないと行けないわけですから、研究者になるにしても営業になるにしても自分の興味のあることをさっさとやってみるのがいいのかと思います。

    学生団体なんかやってると「就活に有利になるから」とかで入ってくる人もいるんですが、結果を見ると確かに有利になってるのかなという気もします。
    けど、学生団体やってない人も結局似たような結果になっている気がするので、あまり関係ないのかなトイウ気もします。
    正直わかりません(ぉ
    それよりは、環境に興味があるとか国際関係に興味があるとか、ちゃんとそういう理由があってそういうところに参加する方が結果的にうまくいくように思います。

    それに、いずれにしても社会の歯車として働くことになるわけです。で、あれば、自分で歯車を回す原動機付き歯車として職業に就く方が会社の歯車として回されるよりもきっと楽しいんじゃないかなという気がします。

    Css Spriteを自動生成しよう

    • Filed under: 雑記
    Saturday
    Mar 13,2010

    css_sprite01

    Css Spriteという手法をご存知ですか?
    画像の部品をひとつの画像にすることで、セッション数を節約したり圧縮効率を上げたりする手法です。
    こうすることによりwebページがより素早く表示されるようになり、ユーザはハッピー!ということらしいです。
    ものすごい負荷がかかるほどの大規模サイトじゃない限り、大抵の人には関係ない代物ではあります。

    この画像を作るために通常はデザイナが苦労して画像を合成するらしいです・・・・お疲れさまです・・・
    何が大変かというと、デザインが変更になる度に画像を合成しCSSを書き換え・・・・死にたくなりますね。

    そこで例えばこんなツールがあります。CSS Sprite Generatorは、画像一式をzipで圧縮して投稿すると冒頭の画像のように合成してくれその上CSSまで作ってくれるという優れものです。
    けど、結局デザインって画像とか文字色とかを微調整することがなんどもあり、その度にここにアップロードしてチェックしてとか大変ですね。

    はい。そこで作っちゃいました。普通に作ったwebページを放り込めば勝手にCSS Spriteをしてくれるスクリプト。
    まだベータで凄く単純にケースにしか対応していませんが、作り込めば大抵のサイトで使えるようにできる見込みがあります。
    またとりあえずの実験ということで画像の配置に関しては最適化をしていません。(余談ですがこれは長方形詰め込み問題として知られており、いわゆるNP困難な問題です。しかし結構歴史ある問題でさまざまな解放があります。)
    作り込むかどうかは様々な要因(就職活動とかバイト先との兼ね合いとか)と気分で変わります。

    今回は、mixiさんの会社概要ページで実験させてもらいました。
    まず、wgetでソースを丸っととってきます。

    wget -k -p http://mixi.co.jp/

    すると、index.htmlと関連する画像やCSSが取得できます。
    つぎにこれを作成したスクリプトに突っ込みます。

    ruby css_spriter.rb src/mixi.co.jp/index.html dest

    すると、スクリプトが自動的にHTMLを解析し、imgタグをdivに置き換えるとともに画像合成まで行い、CSSを作成しそれを読み込んだHTMLを作成してくれます!
    before/afterのソースコードとか晒せたらよかったんですが、一応他人様のサイトなので自重して結果と部分的なコードだけ示します。

    まず、これがビフォア。

    mixi_before

    で、こちらがアフター。

    mixi_after

    えぇっと違いわかりませんね(^^;;;;  ほぼ完璧な置換が出来ています。

    詳細を見てみましょう。結合した画像はこんな感じ。とりあえず今回は最適化を行わず並べるだけにしてあります。これは長方形詰め込み問題を解くことで効率よく並べられることがわかっています。

    次に自動的に作成されたCSSを部分的に。

    #globalnavi_company001_off_gif{
    display: block;
    width: 178px;
    height: 36px;
    background-image: url(../images/sprites.png);
    background-repeat: no-repeat;
    background-position: -0px -107px;
    }

    これはちょうど「会社情報」と書いてある画像の部分になります。

    具体的にどういう風に置換されるかというと、

    <img height="36" width="178" alt="会社情報" src="http://mixi.co.jp/wp-content/themes/mixicojp2009/img/globalnavi_company001_off.gif">

    という部分が、

    <div id="globalnavi_company001_off_gif">&nbsp;</div>

    こんな感じに置き換わります。
    つまり、画像ファイル名をもとにidを生成して、それに対してcssを設定しdivに置き換えてるわけですね。
    大変便利です。

    これを使うことによって、デザイナーさんはがんばって画像を合成する手間を省くことができ、従来のツールで従来と同じようにウェブ製作を行うことができます。
    しかも、最近流行のアジャイル開発とかで頻繁にデザインが変わったとしても、このスクリプトさえあれば簡単にストレス無くデザイン変更が行えます。

    大変素晴らしいですね!

    機械が出来ることは機械で!人間がやるべきことを人間で!

    ついかっとなって2時間くらいで作った割には有益なものが出来たな。

  • Comments Off
  • git diff を VimDiff で見よう

    • Filed under: 雑記
    Wednesday
    Feb 24,2010

    git-vim

    最近、自分ががしがしコミットしていたソースツリーを他人と共有する必要があり、人がどういう変更をしていたのかを確認する必要が出てきました。
    コンフリクトを避けるのはもちろんですが、互いの空気をソースから読み取るというのは重要です。

    要は git diff を見ればいいんですが、git diff はぱっとみよくわかりませんね・・・・

    git-diff

    世の中にはスーパーハカーがいたりするのでこれでいいのかもしれませんが、超一般ピープルである私にはちょっときついです。そこでGitVimDiffです。

    motemen さんの git.vim をベースにさせていただきました。これはmoteます・・・・!

    スクリプトを.vim/pluginsにコピーしてvimを起動します。
    そこでいきなり:GitVimDiffと入れてみます。するとHEADからの差分が表示されます。

    さて、今回の目的は他人のコミットとの差分を表示することです。git logでハッシュ値を確認してそれとworking ソースの差分を表示してみましょう。
    例えば、 :GitVimDiff cb110a2a9c1532b8737ed37953aeaaa48436351c とか入れてみます。すると、このコミットの時のソースコードとの差分が出ます。これが冒頭のスクリーンショットです。

    git diffよりも大分見やすくなりましたね!すばらしい。

    vimscript歴2時間で作成したコードなのでまだまだ改善の余地はあるのではないかと思いますが、突っ込み改善歓迎です。

    Friday
    Feb 12,2010

    最近コンセプトとかビジョンとか言ってる人がたくさんいます。
    正直、何を言っているのかがさっぱりわからない人が多かったため、今まで完全にスルー対象でした。
    しかし、最近のcookpadやpixiv,mixi,gree,DeNAを見たり戦略コンサルに就活するにあたり色々勉強している流れで、ほんのり理解できた気がしたので書き散らかしてみようかと思いました。

    コンセプトの代表格と言えば自分の中では高須賀さんです。
    詳細な理屈はあまり腑に落ちていないので覚えていないのですが、常々コンセプトの重要性について説いて回っており、新しいコンセプトに出会いたいと真剣に思っているようです。

    一方でビジョンの代表格はMITメディアラボで石井教授のNIIでの講演の言葉を今でも覚えています。

    technologyは一年で古くなる。
    needsは10年で古くなる。
    しかしビジョンは100年続かせることができる。

    すごく抽象的で概念的な言い方をすれば、よく学生が言うような「本質」だとか「軸」だとかそういうものであるような気がします。(これに関してまた色々と言いたい事は無いことも無いのですが、また暇な時に・・・・)

    自分もwebサービス作りに絡んで4,5年経つのでぼんやりとその重要性に関しては認識していました。
    実に色んな種類のサイトやらシステムやらを作りましたが、明確に流行るものと流行らないものには差があった様に思います。
    簡単に言えば、見ればすぐに誰が使うかわかるものと、一体誰が使うのかが謎なものです。
    もちろん謎だけど流行ってるものというのもありますが(自分は絵をかかないのでなぜpixivが流行ってるかは理解しがたい)、ユーザ的には何らかの共通点を見いだすことができそうだなと漠然と感じています。
    きっとこれがコンセプトやビジョンに当たるのではないだろうかと思います。

    さて、コンセプトやビジョンというものはwebサービスにおいて重要なんでしょうか?おそらく答えはyesです。

    webサービスとは読んで字のごとく「webを通じてなんらかのサービスを提供」するものです。
    pixivならイラストを見たり描いたり。mixiなら友達との交流。ECサイトなら買物。そいういう感じです。
    色々なサービスについて色んなことが言えるのですが、今回は議論をわかりやすくするために特にSNSについて取り上げたいと思います。

    SNSは、少なくとも日本に関して言えばmixi・gree(前期)に始まり、OpenPNE系などのSNS乱立時代を経て、メジャーなところではモバゲー・gree(後期)・pixiv等にいたっています。
    モバゲーもgree(後期)もpixivもSNSなのかと疑問を持たれる方もいると思いますが、それはもっともですし、しかもそこがキーポイントです。

    SNSは、先発組と後発組で明確に戦略が変わっています。
    皆様ご存知の通り先発組の代表格はmixiとgree(前期)です。
    この両者の争いに関しては他に譲りますが、基本的にはどちらがデファクトになるかという争いでした。
    機能やデザイン面での多少の差異はありますが、どちらも日記・コミュニティ・足跡など非常に似た機能を持ち合わせており利用目的も非常に似ていました。
    どちらが先にデファクトになるのか。デファクトになりインフラとして機能するようになるか。これがとにかく重要でした。

    一方で後発組をみてみると、pixiv, gree(後期),モバゲーなどがあります。
    これらはSNSという体裁がある一方で、ゲームやイラストといった特定のコンセプトを明確に打ち出しその地位を不動のものとしつつあります。
    pixivといえばイラスト、gree・モバゲーといえばゲームという形です。
    (携帯ゲームは携帯固有の大人の事情があるためgreeとモバゲーはデファクト争い以外の色々な要素がありそうです)
    非モテSNSやゲイSNSなどOpenPNEをベースとしたSNSのうちある程度流行ったものもコンセプトを明確にしているものと言えます。
    個々でのポイントは、後発組はコンセプトを明確にしているという点です。

    これらの事例からわかる通り、先発組は汎用的な用途でマスをとりデファクトをとる戦略、後発組はコンセプトを打ち出し特定の用途に特化する戦略が有効であることがわかると思います。

    実は、この傾向は動画サイトにもある程度言えます。代表的な例としてyoutubeとニコニコ動画を考えてみましょう。
    youtubeは動画配信サイトとして不動の地位を築いている先発組です。youtube動画の埋め込み機能を使い(違法動画ではありますが)PVのまとめサイトやネタ動画サイトのインフラとして使われるようになっています。
    一方で後発組であるニコニコ動画は、ご存知の通り初期段階ではyoutubeをインフラとして利用しており、その上にコメントでのコミュニケーションというコンセプトを上乗せして成功しました。

    他にもフリーメールにおけるgmail(大容量化)、検索におけるgoogle(膨大な対象ページ)など多くがこうした後発組は「あるコンセプト」に従っているという例に当てはまります。

    コンセプトはwebサービスにおいてなぜこうまでに重要なのでしょうか?
    それはユーザがそのwebサービスにたどり着くためにはコンセプトが必要だからです。

    例えばレシピを探そうと思ったとしましょう。図書館に行く、googleで探す、NHKを見るなど色んな方法が考えられます。
    こうした様々な方法の中からあえてcookpadにアクセスする理由とは何でしょうか?
    検索エンジンからたどり着くということもあるでしょうが、そうでなければ、「cookpadはレシピサイト」というコンセプトのサービスであるからです。
    webサービスにたどり着くためには、現実の行為に対応されたコンセプトが必要なのです。

    そしてそのコンセプトの中でナンバーワンであることがさらに重要です。

    レシピと聞いてどのwebサービスを思い出すでしょうか?居酒屋なら?クーポンなら?多くの人が同じようなwebサービスを思い浮かべることでしょう。
    しかしそれ以外のサイトについていくつあげることができますか?ググっちゃダメですよ。
    たいていどんなサイトに関してもググってみれば似たようなサイトを見つけることができますが、最初に思い浮かぶサイトは大抵の人が同じモノです。
    この立ち位置を築くことがwebサービスにはとても重要です。

    これらを一言でまとめてしまうと、「適当な大きさのニッチでナンバーワンになればおk」なんですが、このことは本当に多くのwebサービスに当てはまっているということがわかります。

    さて、コンセプトとビジョンの重要性についてはある程度ご納得いただけたでしょうか。
    当たり前すぎることを連ねた感じはありますが、webサービスで起業したいという人でもこの「コンセプト」や「ニッチNo1」の重要性をあまり感じていないように思います。

    長文となりましたが、webサービスにおいてビジョンやコンセプトというものがいかに重要であるかということが少しでも感じ取れていただけたら幸いです。

    ここからは蛇足。

    学生しつつプログラミングを通して、ある程度の分析を加えつつ、時々気分でアドバイスしたりして来てるんですが、戦略コンサルを就職希望しているのはこういう話が好きだというのが一番です。
    全体から傾向をつかむとか、なにかの本質的な原因を探るとか好きなんですね。好きだからこんな長文がかけます(ぉ

    平均よりはITのことしってますしきっと経験もあるんだろうと思いますが、元はと言えば会社とか経営とか絡んでみたいと思って全て始まってますし、それだけのモチベーションで(学生でかわいがってもらってた可能性はあるにしても)個人名で仕事もらえる程度にはなりました。

    戦略と技術のどちらの方が貢献できるのかと聞かれると非常に答えずらいのですが、世間の人から技術的な点を聞かれることが多い一方で、私は戦略的な穴の方が気になって気になってしょうがないと思っていたりもします。
    技術的にgoogleにはいれるほどなのかと聞かれるとかなり微妙ですが、それなりになんとかしますしなぜかいつもそこの人員が足りていないので実務上そっちに回ることが多いのですが、ここらで1回技術屋さんやめて戦略を専業でやってみたいものだなぁというふうに思っています。

    この文章はとりあえず過去の事例をいくつか上げてみた程度なので、あまり戦略的な分析ではないですが、なんか適当な目的を考えていつか書いてみたいなぁと思います。

    蛇足でした。こういうのは就職活動始める前にやるべきだな。

    ※コンセプト重要ですが、トライアンドエラーを認めてないわけじゃないです

  • Comments Off
  • rubygemsのtwitterを拡張

    • Filed under: 雑記
    Monday
    Feb 8,2010

    rubyからtwitterを便利に使うgemにtwitterというのがあります。
    デフォルトだとand検索しか出来ないのですがor検索したいですね。
    と、いうだけの簡単な拡張を書きました。

    CODE:
    1. #extend_twitter.rb
    2.  
    3. module Twitter
    4.     class Search
    5.         def ors(query)
    6.             @query[:ors] = "#{query}"
    7.             self
    8.         end
    9.     end
    10. end

    こうやってつかうと、twitterとついったーのor検索が出来ます。単純だけど便利。

    CODE:
    1. root_dir = File.dirname(File.expand_path(__FILE__))
    2. require "rubygems"
    3. require "twitter"
    4. require "#{root_dir}/extend_twitter.rb"
    5.  
    6. tweets = Twitter::Search.new.ors("twitter ついったー").since(nil).per_page(100)
    7. tweets.each do |tweet|
    8.     puts "#{tweet["from_user"]}:\t#{tweet["id"]}\t#{tweet["text"]}"
    9. end

    rubyの拡張性は異常。

  • Comments Off
  • twitterをキーワードを通してみる

    • Filed under: 雑記
    Saturday
    Jan 23,2010

    twitter_streaming

    twitter streaming apiというのをご存知ですか? twitterをリアルタイムに見るためのAPIです。
    このAPIにはキーワードを使って、自分の好きな情報だけをリアルタイムに取得するためのfilterという機能があります。
    これを使ってコードを出力し、表示したのが上の画像です。
    「ruby」「pixiv」「pixpedia」「hrjn」「harajune」というキーワードでtwitterをリアルタイムに監視しています。

    色々試したのですが、どうも日本語はうまくtokenizeできていないらしくうまく表示できません。
    ただ、アルファベットの単語はうまくいくようで、ほぼ100%見つけ出すことができます。

    この仕組のいいところはいくつかあります。

    • 本当に最先端の情報を得ることができる
    • followしてない人の発言でも見ることができる

    「リアルタイム性」が協調されるtwitterですが、所詮自分がfollowしている範囲を監視していたところで、最新の結果なんか得られません。
    本当に最新の情報を得たいと思うなら、twitter全体を監視すればいい!
    簡単ですね(ぉ
    なのでやってみました(ぉぉぉ

    twitterは人物ベースの情報共有を行うものですが、このtwitter streaming apiを使えば話題ベースで情報を得ることができます。
    どんな小さな、どこの誰が言ったものであろうと、twitter上で発言さえされていればそれを取得することができます。

    もちろん欠点もあります。例えば「iPhone」で探すと情報が大量すぎてものすごいスピードで流れて行ってしまいます。
    さすがにこれを人力で監視するのは無理なので、何らかの方法で話題を分類する必要があるでしょう。

    仕組み

    あまり詳細には書きませんが。

    情報収集には、このブログのスクリプトをほぼそのまま流用させてもらいました。
    これを、ターミナルで起動します。例えばこんな感じ。

    ruby twitter_stream.rb >> twitter_stream.log

    こうしてtwitterから特定のキーワードだけをリアルタイムに取得します。
    そして表示部分はgeektoolを使います。
    geektoolはコマンドの実行結果をデスクトップに表示するためのツールです。
    geektoolをつかいこの検索結果をデスクトップに表示します。
    例えばこんな感じ。

    tail -n 5 twitter_stream.log

    すると、この記事の冒頭のような感じになります。

    簡単ですね。

    geektoolの使い方等を覚えたりしたので多少時間がかかりましたが、全体で一時間少々でこれを作れました。
    本当に簡単ですね!!素晴らしい時代だ。

    では、みなさん。楽しいtwitterライフを!

  • Comments Off
  • Thursday
    Dec 31,2009

    今年はさりとて目立つことはしていないのですが、色々とITや技術に関しては思うことがありました。

    2009年を総括すると「コンテンツ」の年であったように思います。
    それの筆頭がmixiアプリやfacebookアプリを始めとしたソーシャルゲームであったように思います。
    色々と細かいこと言えるんですが、正直私の興味の対象外なのであまり言及しません。
    こういってしまうと、正直今年ほどIT的につまらなかった年はないなーと思ったりもします(ぉ

    今年感じた感想意見を書いてみたいと思います。

    • だんだんと難しいITに注目が集まってきた(機械学習とか並列計算とか
    • テーマのはっきりしたサイトがウケル
    • 毎年いってるけど、やっぱりどんどんプログラムかける人は増えている

    また、関連して、来年はこうなるだろうなということを書いてみます。

    • ソーシャルを超えた 1 to 1
    • プログラマはメタプログラマへ

    だんだんと難しいITへ

    難しいというと語弊がありますが、単純に言うと「その分野の知見やノウハウ」が試される時代へと変わってきました。
    わかりやすく具体的に言うと「mapreduce(Hadoop)」や「機械学習」などがそれに当たるでしょうか。
    ここ数年こういった事をテーマとした勉強会や読書会が多かったように思います。

    今までも大規模サイトを扱う上でのノウハウなどは普通にあったわけですが、より数学やアルゴリズムに対して焦点が当たるようになったと思います。
    こうした、map reduceや機械学習といったものは、教科書通りに実装すれば確かにうごくものです。
    しかし、必ずしも望んだ結果がでるとは限りません。精度が悪かったり計算に時間がかかりすぎたりすることもあります。
    このとき個別の事情に合わせてチューニングするテクニックがあります。
    こうしたチューニングテクニックやノウハウを持ってる人材が今年求められ始めたような気がします。

    テーマのはっきりしたサイトがウケル

    具体的に言えば cookpad や pixiv などでしょうか。
    「cookpadにいけばレシピが見つかる」「pixivにいけばイラストが見れる」こういうブランディングが大変効果的であることがはっきりと見えてきました。

    これに気づいたのは、彼女にあげたPCの使い方を見ていたときです。
    彼女は、「今日は餃子が食べたい」といってPCを開き食べログを見ます。「鍋にしよう」といってPCを開きcookpadを見ます。
    彼女にとっては、PCは本や辞書と一緒なのです。使わないときは棚にしまっておいて、「鍋のレシピをみたいなー」と思ってPCを開くわけです。

    携帯ゲームのメインターゲットであるような中高生は24時間携帯触っているかもしれないですし、私みたいなプログラミングばかりしてるような人種は24時間PCの前にいるでしょうが、ほとんど大多数の人はそんな状況にはありません。
    想像に固くはないと思いますが、ずっとtwitterが垂れ流されてたりとか、skypeやメッセでガンガン連絡がくるような生活をしている人は大変稀です。
    ほとんどのひとは、日中営業で外まわっていたり、買い物していたり、子供の送り迎えをしているわけです。
    そんな人達がダラダラネットを見てるなんてことは基本的にはないでしょう。

    結局そうした大多数の人達は、どうやってwebサイトを見るのか。
    答えは至極当たり前で、「必要なときにPCを開き、必要なwebサイトを見る」です。
    ネットニュースとかにも興味がない大多数の彼女ら / 彼らにとっては、テーマがはっきりしておりそれが必要とされることが重要なのです。

    すごく当たり前なことなのですが、実際目の当たりにして目が覚めた気分でした。

    毎年いってるけど、やっぱりどんどんプログラムかける人は増えている

    某社でコードを書いているわけですが、インターン生が何組かきました。
    PHPもSQLも書いたことがないという20歳にも満たない人たちが一週間でそれらを覚えて画像掲示板を作ったりしてました。
    セキュリティとか、コードが汚いとか、細かいことはたくさん言えますが、立派に動いています。(それどころかハーディ君のセンスにはみんな驚愕

    (別にプログラミングがそれほど難しいと感じたことはないのですが)正直プログラム書くだけならそんなものです。
    正直いままでは、サーバが高いだとかPCが高いだとか本が高いだとかモテないだとか、そういう(中高生にはキツイ?)参入障壁が多少なりともあったわけですが、もうそんなのはありません。
    やっぱりこれからは、どんどんプログラムかける人たちが増えていくんだなーと感じました。

    今年のまとめ:

    と、いう感じで、結局は毎年思ってることでもあるんですが、もう「プログラムが書ける」とかいう基準がすでにゴミ化してるんですよね。

    むしろ、技術者としては「経験」「ノウハウ」が求められるようになっていっています。
    またウェブのマーケティングとしては、いかにユーザの日常に入り込むかが求められています。じゃないとwebサイトなんて開いてもらえません。彼女ら / 彼らは、PCを開いてすらいないのですから。

    というわけで、こっからはちょっとした予言?

    ソーシャルを超えた 1 to 1

    個人的な見解を言えば、webはもともとソーシャルでした。
    パソコン通信なんてものも含めて考えれば、地域ごとのホストでオフ会するとかよくありましたし、掲示板作って身近なひとと連絡とるというのがデフォルトだったように思います。
    (私も、KCLという茨城のパソコン通信のオフ会に小学校の頃いったり、高校の友達と掲示板とかやってました)
    もともとあるコミュニティを前提としたソーシャルと言えるかもしれません。
    時期的には前後しますが、mixiやgreeもどちらかというとこの種のサイトであるように思います。

    yahoo / googleなどの検索エンジンの登場があって、はじめて1 to 1のつながりというものができました。
    友達のウェブや紹介無しに、ダイレクトに必要な情報にアクセス出来るようになったのは、大変革命的なことでした。

    それが、今またソーシャルに戻ってきました。
    巨大掲示板を始めとして、OKWebや食べログやcookpadなど多くのサイトが生まれました。
    これは、共通の話題やテーマを提供することで、知らない人同士でコミュニティを形成させるというソーシャルの形です。

    そして、私は再び 1 to 1への革命が起きると考えています。
    検索エンジンは、必要な情報へのダイレクトアクセスの方法を提供しました。CGM / UGMサイトはそのサイト内限定で知らない人へのダイレクトアクセスの方法を提供しました。
    ひょっとしたら、特定のサイトに閉じずに、特定の知らない誰かにダイレクトでアクセスするような 1 to 1が次世代のあたらしいサービスになるのかもしれないと考えています。

    プログラマはメタプログラマへ

    すごく簡単に言うと、フレームワークを作るエンジニアという感じでしょうか。
    先程「プログラミングなんて誰もでもできる」といったことへの答えのひとつがこれであるように思います。

    Gaucheで有名な史郎さんがこの前講義で言っていた言葉でもあります。

    プログラムは書くだけなら誰でもできますが、可読性や保守性を考えたコードを書くことはそれほど簡単ではありません。
    これをLisperである史郎さんはマクロで拡張しまくってやるようですが、普通のphpやrubyでもこれは可能です。
    適度な抽象化とカプセル化を行うことで、割と簡単にコードはすっきりします。

    確かに、最初からすべての可能性を盛り込んで抽象化を行うことは困難です。が、ウェブサイトであればMVCの分離という程度の抽象化は誰でもやるべきだと思いますし、データアクセスの抽象化はどんなプログラミングであっても必須であるように思います。

    よく、「綺麗なコードだからといっても意味がない」というはなしもよくききます。
    綺麗であることに時間をかけるよりは、さっさと完成して動いた方が嬉しいという話ですね。
    ただ、これは一人のスーパーエンジニアが全部どうにかするということを前提とした発想であり、早々に破綻します。

    そのスーパーエンジニアがやめてしまったらどうするんですか?そのシステムの保守は?運用は?
    そのエンジニアがインフルエンザにかかったら、サイトの更新を止めちゃうんでしょうか?
    そういうわけにはいかないでしょう。

    システムの規模が大きくなればなるほど、早々に他人にコードを見せたりいじったりしてもらわないといけない事態が発生します。
    それにスーパーエンジニアには、スーパーなことをしていただかないとしょうがない(給料高いだろうし)ので、細かい修正はスーパーじゃない人にしてもらうというのが健全というものではないでしょうか。

    これからのプログラマ / エンジニアは、コードを書くだけではなくプロジェクト全体を最適化することも考え、それをコードに反映することができる。
    こういう能力が付加価値として必要なんではないでしょうかと思います。

    まとめ:予言

    人と人とをダイレクトに繋ぐ仕組みというのがあれば流行る気がする。

    プログラマはメタプログラマになっていく

    まとめ:全体

    どうも今年は自分がボーッとしてたのもあるのでしょうが、あまりITサービスで面白いものはでなかったように思います。

    sekai cameraやソーシャルゲームは大いに盛り上がってましたが、もともとジオタグ関連には否定的なのと、ゲームに興味がないのと、儲かってもなんかしれてそうというのでいまいちでした。
    (yelpとかの話もされたことがあるのですが、yelpとその場に行かないとコメントが見れないseka cameraを単純に比較できるのはなぜなのか最期までよくわからなかった)

    来年の目標というよりは、個人的な願望として、もっと全体のことを考えて最適化するようなことをしていきたいというのもありメタプログラマという話をしてみました。

    また、ソーシャルは大いに結構だと思うのですが、インターネットの醍醐味は全く知らない何か/誰かを発掘出来ることであると思っている点から、知らない誰かへのダイレクトアクセスが今後なにか起こるのではないかなと言ってみました。

    何はともあれ、来年は色々と面白そうな予感がいまちょっとしています。

    駄文でしたが、読んでくれた人ありがとうございます m(_ _)m

    about me

    原田 惇

    応用数学や統計、ITなどを利用していろんなことをしています。
    自己紹介はこちら

    adsense

    amazonお勧め

    Recent Posts


    Recent Comments


    Twitter



    Archives


    Meta