Time Flies

fckey's Tech Blog

PyCon JP 2014 2日目参加レポート #pyconjp

PyConJP 2014 2日目のレポート。

1日目はこっちPyCon JP 2014 1日目参加レポート (コメントを頂きましたが、 記事に書いてある通りPython3はとりあえず使いましょうね!)

今日は想定外のサプライズ(?)的なものもなく穏便に終わった。

Keynote Speech @nishio

今日のKeynoteは西尾さん。

講演は今回のPyConのテーマであるRe-discover。

人間の認知状態には3通りあり、知っている状態、知らない状態の2つに加えて知らないことを知らない状態である”盲点”があり、この盲点を認識することによって再発見が可能になるというお話。

そして、盲点を認知する過程において比較、経験、歴史*1、抽象、対話の5つの要素が重要となるということだった。 これには、なるほどと思うと同時に自分の中ではこれらには順序関係があるのではという疑問が生じた。

そもそも、比較や抽象化を試みるのは何か問題意識があるからではないだろうか。 そして、その問題意識がどこから来るのかというと自らの経験や他者との対話からが多いのではないかと思う*2。 また、問題意識を持てなかったものから発見は永遠にできないのだろうか*3

このような疑問を抱えつつOffice Hour*4中に西尾さんとお話をしてみようと思ったがお昼休みに西尾さんのgihyoの連載 エンジニアの学び方─効率的に知識を得て,成果に結び付けるを読んだらしっくり来る答えが見つかった気がした。

極端に表現すると”必要になったらやればよい”である。時間は有限であり実際あるかどうかわからない盲点のために時間は割けない。

目標が明確化したら何かしらの行動が始まり、知識の3つの軸と定義された「広い視野」軸,「深い理解」軸,「応用対象」軸を学びのフェーズごとに行き来する。 そして、学びが軌道に乗りそれぞれの軸を育てていく中で、課題も広く深く現れてくる。その中で試行錯誤することで再発見的なものも増えていくのだろう。 また、最初に上げた5つの軸は必ずしも順序関係があったり切り分け可能なものではなく、それぞれ重複したりもするものだろう。

一応の整理はついたものの、せっかくの機会なので西尾と雑談*5をさせて頂いたが、引き出しの多さがすごい。疑問は消化したつもりだったので質問とも言えないまとまりのない話をぐだぐだしてしまったが話を広げて頂き恐縮しきりだった。

あと、昨日も今日もKeynoteにすら話に来る人が全然居ないみたいだったので*6、機会があったら何でもいいからもっと話しに行ってみるべきだと思う。人との出会い大事。

Improving code quality through static analysis for Python @1zq

1日目のリファクタリングツールあれこれに近い内容で、新たに紹介されたツールとして以下のものがあった。

マーケティングに活かせるPythonライブラリ @iktakahiro

一般的なマーケティングの手法の紹介と共にPythonのライブラリを使うことで効率よく値が算出出来るというお話。 statistics moduleはPython3.4からなのでPython3のBenefitもあるよということ。使用したのは以下のライブラリ

Pythonではじめる野球プログラミング @shinyorke

個人的に楽しみにしていた発表。 利用したのはやはりSean Lahman DatabaseからのMLBのデータ。NPBもとっとと情報を公開して欲しい(小声)

SQLAlchemyのModel生成はsqlacodegenにより自動で行い、描画ではレスポンシブデザインにこだわり、グラフ生成(折れ線、棒グラフ)はmorris.jp、散布図はHIGHCHARTS を利用していた。 作成当時PyMySQL3MySqlへの接続が不可能な状態でバージョンを落としたら解決したらしい。

トピックはOPSかな?と思ってたらBABIPだったけど、LTのアダム・ダン率までの流れを考えると非常に秀逸*7

紹介がかなり適当になってしまったが、PyCon面白かったです。

Python文法詳解

Python文法詳解

*1:著書 コーディングを支える技術より

*2:プレゼンの例でもあったように対話から突然のアハ体験みたいなのもある

*3:それはそもそも人生に必要のないモノかもしれない

*4:スピーカーと話せる場

*5:西尾さんはPython3のBenefitを1つ思いついたらしい

*6:日本人ぽさを感じる

*7:アダム・ダンアダム・ダン率100ではない

PyCon JP 2014 1日目参加レポート #pyconjp

今日はPyConJP 2014に参加してきた。

プログラミング言語系の会議に参加するのは初めて何だけど雰囲気としては学生時代に参加した学会とだいたい同じ。PyConの場合はほぼPython関連の話題だった。(まあ当たり前なんだけど会議によってはそうでもないらいしい) ちなみに今回の会場では電源は絶望的に少なかったので苦しんだ。

どれも勉強になる発表だったが、以下では特に印象に残った発表について触れる。

Keynote Speech @kennethreitz

CH01 Opening~Keynote: Kenneth Reitz - YouTube

1日目のKeynote SpeechはHerokuのPythonプロダクトオーナーでPython Software FoundationのKenneth Reitz氏。 プレゼンではそもそも言語とは何かという話題から入りPythonの2系と3系の話に。曰く、我々がPythonと呼ぶものはPython2系の事を指しており、Python3はPython3で別の言語との事。

Python3のユーザーま未だに伸びておらず、2014年1月の最初の2週間パッケージのDL数を計測したところPythonは80k程あったのに対して、Python3は3kほどでこの差から言うとPython3は無に等しいよねという言い振りだった。 まあ端的に言うと彼はPython3が好きではなく使う気もない。質疑で出たPython3を使用する利点は何かという質問に対して「No Benefit (hahaha)」の答えには震えてしまった。

ただ今後のPythonの行末はFundationの人々にとっても見通しが立っておらず、そもそもPython3のフィードバックがまだまだ少ないから多くのユーザーに実際に使用してその感想を公にして欲しいということだった。 良い点を共有できたらそれはそれで良いだろうし、悪い点が目につくようならPython3など使われず潰せるかもね(hahaha)という感じ。

Pythonは内輪で揉めてそうだなという印象を受けて今後が多少不安になる発表だった。

Pythonの実装系総ざらい @Masahito

次に印象に残ったのはPythonの実装系総ざらい。 CPython (普通の解釈系), Jython, PyPy, Cython, Pystonが紹介された。CPython、PyPy、Pystonのフィボナッチ数列の計算によるベンチマークも取られており、再帰ではPyPyかPystonが良い結果を残していたが、forループではPystonの結果が絶望的に悪く、高速処理系は現状PyPyに軍配が上がるかなといった感じ。

PyCharm活用術 @shimizukawa

自分はぬるいPythonしか書かないのでエディタは基本的にemacsかWinだとSciTEとかで済ましてしまうが、最近はかなり高機能なIDEも出ているらしくPyCharmがその一つ。PyCharmはIDEAから出ているエディタで、最近自分はJavaでもeclipseからIDEA IntelliJに乗り換えたのでやっぱいいよなと思った。

今のところIntellijPython pluginとPyCharmの違いはこれによるとJythonのSupport強度で、JavaPythonのインテグレーションがあまり無いならよりシンプルなPyCharmから始めるのが良い。

リファクタリングツールあれこれ @tell_k

個人的にかなり有用だった発表。

まずはPythonの書き方を整えるためのツールの紹介。コードを整え無駄を省くには、Pythonにおいて望ましいコードスタイルであるpep8に則ったフォーマットであるかをチェックするpep8と文法チェックをするpyflakesを併用したflake8を利用するのが良さ気。

ただいちいち人手でコードを整えるのは面倒なので、まず整形はpep8に準拠したスタイルを自動生成するautopep8に頼るのが良さそう。 また、利用されない変数やimportを削除しコードの無駄を自動で省くにはautoflakeが使える。 ただ便利なコードの自動整形ではあるが必要なモノを削ったりすることもあるようで結局最後は人の手が必要。

関数の抽出等リファクタリングツールにはRopeが有用。ただ個人的にはPyCharmのような優秀なIDEがあるんだからそっち使ったらいいよねとは思う。 RadonではコードメトリクスのをABCの3段階評価で見ることが出来る。*1

銀の弾丸などないという台詞をまた見ることになり40年前から相変わらず。 開発過程における偶有的難しさを倒す武器として確実に銃の性能は上がり連射速度も向上しているのだけれど、本質的な問題の一撃で仕留める弾丸はまだしばらく見られそうにない。

Party

知人が全くいないので心配していたが、たまたま来ていた友人を見つけたり何人か新しい人と話が出来て楽しい時間を過ごせた。Pythonアイドルの存在を知った。*2

2日目のレポートは未定。

Python文法詳解

Python文法詳解

人月の神話

人月の神話

*1:Aの評価が甘い気がする。

*2:アイドルだった

Elasticsearch 101

Elasticsearchを使う機会があったのでBasicsをメモ。

Elasticsearchとは?

ElasticsearchApacheプロジェクトの一つである検索用サーバでApache Luceneの上に構築されている。RESTfulなインターフェイスで分散型の構成や全文検索が可能であり、基本的に取り入れるデータの定義、検索クエリ共にJSONで記述される。

仕組み?

ESの導入や基本的な構成はこのあたりのページを見たらだいたいわかると思う。

http://code46.hatenablog.com/entry/2014/01/21/115620 http://engineer.wantedly.com/2014/02/25/elasticsearch-at-wantedly-1.html

基本的にESで重要なのは以下の2点である。

  1. 取り込むデータの定義
  2. 検索の詳細の定義

これらの中でも特にキモとなりそうな点を以下にメモ。

使用方法?

以下では実際にElasticsearchを動かしながらIndexの設定と簡単なクエリの発行を行う。 なお、今回使用した全てのJSONここにある。

取り込むデータの定義

Elasticsearchのインデックスは基本的にはスキーマレスではあるが、取り込むデータのフィールドの定義やdelimiterをmappingにて定義しなけれな成らない。 以下ではデータ整形とフィールド定義の2つのパートに分けて説明する。

データの整形フォーマットの定義

まずここでは取り込むデータの整形フォーマットの定義を行う。以下のJSONmappingの前半部分である。

整形方法の定義はanalyzerに記述され、このanalyzertokenizerfilter の組み合わせによって定義される。 tokenizerは文字列の分割方法を定義し、以下の例にあるngram_tokenは最小2文字、最大3文字のngramを利用する。 filterは分割後の文字列の整形処理を定義するのだが今回は利用しなかった。 analyzertokenizerfilterを組み合わせて複数定義することが可能であり、それぞれのfieldで異なるanalyzerを利用することが可能である。

  "settings": {
    "analysis": {
      "analyzer": {
        "ngram_analyzer": {
          "tokenizer": "ngram_token"
        }
      },
      "tokenizer": {
        "ngram_token": {
          "type": "nGram",
          "min_gram": "2",
          "max_gram": "3",
          "token_chars": [
            "letter",
            "digit"
          ]
        }
      }
    }
  }
フィールドの定義

以下のmappingの後半ではインデックスとして登録される各フィールドのデータ型、使用するanalyzerを定義する。

今回作成するmappingの"sushiya"では、それぞれのフィールドは寿司屋の名前、住所、緯度経度情報を保持する。 ここでは、nameはスペースごとに文字列を分割するデフォルトanalyzerである”whitespace”を使用し、addressに対しては上記にて定義したngam_analyzerを使用した。

 "mappings": {
    "sushiya": {
      "properties": {
        "name": {
          "type": "string",
          "analyzer": "whitespace"
        },
        "address": {
          "type": "string",
          "analyzer": "ngram_analyzer"
        },
        "location": {
          "type": "geo_point",
          "store": "yes"
        }
      }
    }
  }

以上にて定義した寿司屋情報保持用のmappingをsample_mapping_sushi.jsonとして保存し、以下のコマンドにてrestrantインデックスとして定義する。 curl -XPOST localhost:9200/restaurant -d @sample_mapping_sushi.json

データの登録

今回はお気に入りの寿司屋を以下のように定義し登録する。_bulkはまとめてデータを登録するためのパラメータである。

curl -XPOST localhost:9200/_bulk -d ' 
{ "index": { "_index": "restaurant", "_type": "sushiya", "_id": "1" } }
{ "id": "1", "name": "鮨水谷", "location" : [35.66836,139.761106], "address" :"東京都中央区銀座8-7-7" }
{"index": { "_index": "restaurant", "_type": "sushiya", "_id": "2" } }
{ "id": "2", "name": "すきばやし次郎", "location": [35.672614,139.764037], "address" : "東京都中央区銀座4-2-15" }
{ "index": { "_index": "restaurant", "_type": "sushiya", "_id": "3" } }
{ "id": "3", "name": "久兵衛", "location": [35.672614,139.764037], "address" : "東京都中央区銀座8-7-6" }
{ "index": { "_index": "restaurant", "_type": "sushiya", "_id": "4" } }
{ "id": "4", "name": "かねさか", "location": [35.667989,139.762643], "address" :"東京都中央区銀座8-10-3"}
{ "index": { "_index": "restaurant", "_type": "sushiya", "_id": "5" } }
{ "id": "5", "name": "鮨 なかむら", "location": [35.662347,139.729366], "address" : "港区六本木7丁目17−16" }
'

ここでデータの定義について軽く説明すると以下の通りである。

{ "index": <-インデックスの情報について
    { "_index": "restaurant",  <-どのインデックスを利用するか
      "_type": "sushiya",  <-どのマッピングをを利用するか
      "_id": "1"          <-keyとなる任意の文字列
    } }
{ "id": "1", <-先に定義したidと一致するように定義
 "name": "鮨水谷", <-ミシュラン三ツ星(高い)
"location" : [35.66836,139.761106], <-geo_point typeの形式に沿った緯度経度情報
"address" :"東京都中央区銀座8-7-7"   <-銀座は高値の象徴
}

検索の詳細の定義

Elasticsearchの検索はqueryfilterによって行い, 抑えるべき点は

  • queryはscoreに影響する。
  • filterはscoreへの影響はないがキャッシングの有無の選択が可能

という点である。詳しくは公式のリファレンスを追って欲しい。

クエリの定義

ここではまず、簡潔なクエリの定義を行う。以下のクエリは鮨という単語を全てのフィールドに対して検索している。

{
  "query" : {
    "simple_query_string" : {
      "query": "鮨",
      "fields": ["_all"],
      "default_operator": "and"
    }
  }
}  "default_operator": "or"
}

そしてその返り値が以下の通りである。店名に"鮨”をもつ水谷となかむらが含まれている。

  "took" : 4,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "failed" : 0
  },
  "hits" : {
    "total" : 2,
    "max_score" : 0.067124054,
    "hits" : [ {
      "_index" : "restaurant",
      "_type" : "sushiya",
      "_id" : "1",
      "_score" : 0.067124054,
      "_source":{ "id": "1", "name": "鮨水谷", "location" : [35.66836,139.761106], "address" :"東京都中央区銀座8-7-7" }
    }, {
      "_index" : "restaurant",
      "_type" : "sushiya",
      "_id" : "5",
      "_score" : 0.067124054,
      "_source":{ "id": "5", "name": "鮨 なかむら", "location": [35.662347,139.729366], "address" : "港区六本木7丁目17−16" }
    } ]
  }
}
Scoreの定義

さらに、Elasticsearchでは検索スコアの重み付けがクエリ内で可能である。

見ての通り、以下のクエリでは店名に”鮨”が入っていればscoreを10倍し、場所が一定範囲内(六本木駅から2km)の場合はスコアが100倍される。

また他にもアクセスカウントによるsortの定義や、自身で定義した計算式によるscoreの計算も可能であり、非常に柔軟なクエリを記述する事ができる。

{
  "query" : {
    "function_score" : {
      "query" : {
        "simple_query_string" : {
          "query": "鮨 銀座 六本木",
          "fields": ["_all"],
          "default_operator": "or"
         }
      },
      "score_mode": "multiply",
      "boost_mode": "multiply",
      "functions" : [
        {
          "filter" : { "term" : { "name" : "鮨"}},
          "boost_factor" : 10
        },
        {
          "filter" : { "geo_distance" : { "distance" : "2km", "location" : [35.66, 139.73] }},
          "boost_factor" : 100
        }
      ]
    }
  }
}
"sort" : [{ "access_count" : {"order" : "desc", "missing" : "_last"}}]
"script_score" : {
        "script" : "doc[\"access_count\"].value * 100"
      }

おわりに

以上に上げたとおり、Elasticsearchはデータの取り込みもクエリの組み立ても非常に容易に出来る。

最近良く見られるのがElasticsearchとKibanaの組み合わせであり、例えばfulentdで得られたログ情報をElasticsearchに取り込むことでログの整形を容易にし、Kibanaで可視化することでログの分析が簡単に行える。

また、クローリング用のプラグインや、日本語の形態素解析用のプラグインが既に出回っており、Elasticsearchを取り巻く環境は確実にに発展している。 Elasticsearchは簡単に設定ができ強力であるため新しく検索エンジンが必要になった場合には使用をおすすめしたいフレームワークである。

高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍)

高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍)

Apache Lucene 入門 ~Java・オープンソース・全文検索システムの構築

Apache Lucene 入門 ~Java・オープンソース・全文検索システムの構築

アルゴリズムと人、数式と鮨。

アルゴリズムが世界を支配する。

検索エンジンのインデキシングやページランク、高頻度取引、商品のレコメンドエンジンなど今やありとあらゆる所でアルゴリズムが利用されている。もちろん人より精度も速度もアルゴリズムが圧倒時に優っている。

これからは人がアルゴリズムを”使う”というよりは、アルゴリズムが人の意思決定をする事の方が多いだろう*1

そもそも人は考える行為を他に任せるのが好きな生き物だと思う。その一例がインターネットだ。

インターネットは偏在している知をへのアクセスを可能にした。一部の学会所属者のみが読めた論文、海外の情勢や景色、普段は接することのない高齢者と話すことでのみ知り得た戦争の話、職人的技能。そういうものを多くの人間の手が届くものにしたのがインターネットだ。

しかし、インターネットを通して情報を利用し多くの人が思考を加速させるはずだったのだが、人は考える事をすらも外部に頼るようになった。ハードディスクだけでなくCPUすらインターネットの向こう側に任せてしまった。大学生のWikipediaのコピーレポートがいい例だろう。

そして人は他人に頼るだけでなく無機質で感情のないアルゴリズムにも頼っている。映画評論家の勧める映画ではなくアルゴリズムが選んだ自分の好みの映画を選び、編集者が構成した新聞記事ではなくアルゴリズムが選んだニュースを嬉々として読む。

人の役割は次第にアルゴリズム取って代わられ、より正確で素早い結果が得られるようになる。

GoogleAmazonFacebookなど一部の優秀な人々が作っている大きな流れにのり、世界はアルゴリズムに支配される。 良い記事、良い商品は人ではなくアルゴリズムが選び我々に選択肢は与えられない。

一方で、人はアルゴリズムに負けていい部分とそうでない部分があるらしい。その違いなんだろうか。

例えば、Lispで書かれた作曲家エミー。デイヴィッド・コープ氏によって作られたこの作曲家はバッハの曲を学習データとして使用し、多くの曲を生み出した。 エミーが作曲した曲は出来がよく、あるオーケストラ様に作った曲はあまりに感動的でアルゴリズムが作った曲だとはわからない音楽家が居た。 しかし、そういった曲達がアルゴリズムによって出来たものだと知ると「魂がこもっていない」などと避難し、冒涜しているとコープしを殴るものも居た。 楽曲の質は良くとも人に作られたか、アルゴリズムにより作られたかで評価はがらりと変わってしまう。

将棋電王戦ではコンピュータ側が人間のプロに勝ち越した。将棋に詳しくないプログラマからするとコンピュータが勝つのは妥当のように思われる。単純なソートもダイクストラの最短経路も人は速度でコンピュータにはまず勝てない。 それと同様にこの完全情報ゲームで一流のプロ達はコンピュータに負けた。 棋士は歳をとると思考力は落ちるが、積み重ねた経験からくる直感で最善手が見え強者で居続けるという*2。 しかし、多くの解法パターンの中から最適解を見つけ出すコンピュータの側は、ある意味力技で直感力で戦う棋士達に勝った。 これは人類のコンピュータに対する敗北のようにも感じられ、計算能力からすると当たり前のように思われるのだが、同時に何か悔しい気持ちがあるのは自分だけじゃないと思う。

アニメPSYCHO-PASSもコンピュータによる支配と人間による支配の受け止め方に対する示唆に溢れている。 このアニメでは人の犯罪を起こす可能性が数値として表されており、その犯罪係数の高低によって可能な就職先や生活基準が決定さる。さらに係数が一定数を超えると実行していなくても逮捕されてしまう。 作中でこの数値はコンピュータの演算で行われているとされているが、実際は多数の人間の脳をつなぎあわせて導き出されていた、という展開がある。このことが公表されるとまずいという描写があるが、何故だろうか。 アルゴリズムで犯罪者と宣言されることと、人の脳の連結体にそう言われることは何が違うのだろう。

アルゴリズムは合理的な選択をする。疲れは感じず余計な情報にも影響されない。そして人も何かを選択をするとき、突き詰めていけばアルゴリズムと同じ選択をするだろう。 違いは何か。人とアルゴリズムの違いは”無駄”を重要視することじゃないだろうか。 伝統や感情、偏見、見栄など功利的に考えたら省くべきものを人は時に重要視する。本来必要ではないこれらの無駄たちがこそが人を人たらしめているのだろう。

伝統を重視するからこそ機械的に並べられた音符は受け入れられず、単調に動く機械には人は負けたくない。 同時に、人を判断するのは偏見やしがらみを持つ人ではなく、情報を黙って無感情に処理するコンピュータでないと納得がいかない。

無駄を省き正確で素早い意思決定が可能なアルゴリズムはこれから先も我々の生活を確実に向上させるだろう。

それでも僕は生産管理されたネタと機械的に生産されるシャリで作られる鮨より、職人が自身で見分けた魚を捌いたネタと手で重みを感じながら握られたシャリでできた鮨を食べつづけていきたいと思う。

記事に関連した筆者のオススメ

4Gamer.net ― 「ひろゆき」みたいな人間が増えていくと,人類は滅亡する!――川上量生氏との対談企画「ゲーマーはもっと経営者を目指すべき!」年末特別号

世界を支配する10種類のアルゴリズム : ライフハッカー[日本版]

アルゴリズムが世界を支配する (角川EPUB選書)

アルゴリズムが世界を支配する (角川EPUB選書)

世界でもっとも強力な9のアルゴリズム

世界でもっとも強力な9のアルゴリズム

アルゴリズムトレーディング入門 (ウィザードブックシリーズ)

アルゴリズムトレーディング入門 (ウィザードブックシリーズ)

*1:もしかしたら知らないうちに

*2:評価関数の精度と探索エンジンの性能が優れているということだろう

Web系企業のビジネスモデルと収益構造 (印象派)

Web系企業のビジネスモデルについて聞かれたのでWeb系企業関係者でもなんでもない自分がなんとなく考えてみた。

収益モデル

ぱっと思いつくのは以下の感じで、それぞれBtoBとBtoCでモデルに多少違いがあって*1表にちょっとまとめてみるとこんな感じかな。

モデル BtoB BtoC
広告 掲載 アフィリエイト
EC 物販 物販
手数料 仲介サイト オークション
サービス提供 プラットフォーム(ショバ代) プラットフォーム(User向け)
コンテンツ内購入 - ゲーム
  • 広告
    • BtoB 広告を掲載する場の提供をしてお金を貰う企業で広告代理店とかかな。FaceBookなんかは企業広告で稼ぐので我々ユーザーは顧客と言うよりむしろ商品なんだよね。e.g. GoogleFacebook
    • BtoC 広告を掲載するだけじゃ駄目でやりとりがあって初めて利益が発生するモデル。アフィリエイトとかかな。BtoCと言うかは微妙だけど。
  • EC
    • ECに関して物を売って稼げたらという点では企業でも消費者でも同じかな。企業向けだと量が必要そうだし個人向けならマニアックなものを集めてロングテールでやるとか販売戦略は違いそう。e.g. Amazon
  • 手数料
    • BtoB 転職や住宅情報を掲載して取引成約したら取引先の企業から手数料をもらう。
    • BtoC オークションだったりマーケットプレイスみたいにユーザが商品を提供して取引があった場合に手数料をもらう。モデルとしては場を提供して利用者の取引からピンはねする点ではBもCも同じ。
  • サービス提供
    • BtoB 手数料と被りそうだけどプラットフォームを提供してコンテンツの提供者から場所代として売上に応じてピンはね。やっぱりプラットフォーム提供者になれたら強い。e.g. DeNAGREE
    • BoC ユーザがサービスを利用するために課金するモデル。月額制、従量課金制、頭金のみと色々あるけどWebだとやっぱりフリーミアム形式が多い印象かな。 e.g. ニコニコ、Hulu
  • コンテンツ内購入
    • ゲーム等でその中でしか使えないアイテムを販売するモデル。ユーザからしたらお金を使えば使うほどコンテンツから離れ難くなる心理が働くからいい商売だど思う。

今後

現場の人間じゃないから詳しく知らないけどどうなんでしょ。クラウドファンディングなんかはこれから広がっていきそうだと思う。開発者の立場からするとRailsを始めとしたフレームワークが多くあるので学習コストが格段に下がりWebサービスを立ち上げることは簡単にできるようになったけど、これはどうマネタイズするんだろうっていうサービスも多々ある印象。そういうのの大半は広告で小銭を稼ごうとするのかな。

企業がサービスを立ち上げるならこれからはWebのみでなくやはりスマホ等のネイティブアプリも平行して展開して行かないと戦えなさそう。家に帰ってPCを開かずスマホで完結する層が増えたと思うけど、スマホのWebブラウジングってめんどくさいからWebだけだとなかなか使ってもらえないだろうな*2

以上、非Web関係者の印象。

Web開発の基礎徹底攻略 (WEB+DB PRESS plus)

Web開発の基礎徹底攻略 (WEB+DB PRESS plus)

Web業界 受注契約の教科書 Textbook for Business Contracts in the Web Industry

Web業界 受注契約の教科書 Textbook for Business Contracts in the Web Industry

Web ビジネスのためのユニバーサルデザイン成功の法則65

Web ビジネスのためのユニバーサルデザイン成功の法則65

*1:BtoB、Cの分け方はかなり雑。モデルの違いが理解できたらok。

*2:エロくらいかな

オフィスのGoogle化を試みる投資銀行

Banks ‘Googlize’ Their Offices to Land Tech Talent (投資銀行が優秀なITエンジニアを惹きつけるためオフィスをGoogle化する)

投資銀行も優秀なITエンジニアの確保に本気になってオフィス環境から変更していくらしい。

外資投資銀行といえばアルゴリズムによるHFT *1に力を入れているためコンピュータサイエンスや数学・物理学の専門家を多く雇っている。所謂ロケットサイエンティストというやつである。

近年の投資銀行の利益の大半はM&Aや引受業務などの手数料ビジネスよりトレーディングによるサヤ取りによって生み出されるため、より早くより多くの取引を可能にするためのシステム構築に特に熱心になっている。 また、取引に関わる部分以外でも決済システムやドキュメント自動生成などあらゆる面でITに関わり仕事をするため技術力の差がファームの位置づけの差になると言っても過言ではなく、投資銀行は優秀なITエンジニアの確保に余念が無い。

しかし、近年は欲しい人材がシリコンバレーに流れてしまう傾向があるようだ。以前なら給与面でウォール街が人気だったのだろうが、金融危機後はウォール街での給与が落ち込み、逆にシリコンバレーにあるようなスタートアップでは(プチバブルもあって)給与水準が高まっている*2。 この傾向はFacebookTwitterの台頭以降顕著であり、さらに自分の好きなことをして一発当てるアメリカンドリーム的な側面もある。

給与の面では最終的には差はなくなるのだが伝統的で保守的な投資銀行と新興のスタートアップでは労働環境がかなり異なり、お堅いオフィスでスーツを着て働くのとビリヤード台を横目にカジュアルな服装で自由な雰囲気で仕事をするのとでは仕事へのモチベーションが変わってくるだろう*3

特に、GeekでTechyな連中というのはカジュアルでオープンな雰囲気を好む傾向にあるようで、投資銀行でもそういった人材に魅力的に思われる環境づくりを進めていくらしい。 自分の知っている限りでも投資銀行で働くエンジニアは優秀な人が多いと思うので良い人材良い労働環境に囲まれて働きたいのなら選択肢の一つとしてオススメである。

日本のSIerなんかもこういう面から労働環境を改善して優秀な人材に魅力的に感じてもらえるように成れたらと思うのだけどね。(そもそも彼らはGeek的な優秀さは求めてないかもしれないけど。)

*1:High Frequency Trading - 高頻度取引

*2:新卒アナリストの場合、ウォール街のエンジニアは$70k前後、シリコンバレーなら$100kくらい貰えるらしい。

*3:個人的にはスーツでカッチリとキメたビジネスマンもカッコイイとは思う

Uncle BobがCTOなったら開発者にプロフェッショナルとして求めるもの

Clean Codeの著者でありアジャイル開発の第一人者であるRobert Martin (Uncle Bob)がプロフェッショナルなエンジニアとして大切なことは何かを語った動画が面白かったので要点をまとめた。

SCNA 2012: Robert Martin - The Reasonable Expectations of Your CTO on Vimeo

  • We will not ship shit

エンジニアとして最低な制作物を提供するな。我々を雇う人々は我々のコードを読めないし、何をしているのかもわからず良し悪しを測ることも難しい。彼らに出来ることは締め切りを提示することだ。我々エンジニアだけが何が出来上がるのかを知ることの出来る唯一の存在である。自分たちが作り届けるものにプライドを持て。

  • We will Always be Ready

開発が完了しdeploy可能になったときには準備万端であるべき。一ヶ月や二ヶ月deployを待ったり、QAが終わることを待つ必要なんて無いだろう。また、安定化の期間なんて必要とするべきではない。そもそも開発されたコードは最初から安定していなければいけないのだ(一週間くらいの猶予は許すけれど)。

  • Stable Productivity

プロジェクトの開始当初は早く、順調に開発が進むが終わり際は減速するなんてだめだ。プロジェクトが遅延し生産性が落ち、顧客は更なるプログラマの追加を要求するがそれによりコードの質はどんどん低下する。私は常に開発者の生産性が一定であることを期待している。これはおそらく、汚いコードを書くなということである。なぜなら汚いコードは生産性の定価を増長するからである。

  • Inexpensive Adaptability

顧客が変更を要求した時には余分なコストを払うこと無く容易に適応出来るべきである。”Software”はなぜソフトウェアを呼ばれるのか? ”Soft”、つまり、変更が容易であることを期待されている。常にコードの変更が容易な状態に保つことは開発者の責任である。「新しい要求は私達の設計では適応出来ません。」なんていうクソみたいな言葉は聞きたくない。

  • Continuous Improvements

プロフェッショナルなら継続的はコードの質、プロセス、生産性の向上を行うべきである。

  • Fearless Competence

もしひどいコードを見つけたら自身の変更によりコードが壊れることを恐れること無く改善するべきである。プロフェッショナルならコードの変更に恐れを抱いてはならない。私の場合はテストを利用するが、他者には他者のやり方があるだろう。

  • Extreme Quality

汚いゴミを市場に出すな。素早い開発サイクルはゴミを作るためではない。可能な限り高い質のコードを維持できる開発スピードで開発は行われるべきである。

  • We will not dump on QA

QAはバグを見つけるためのものではない。実際のところQAではなにも見つからないべきである。QAはデバッガでもバグを見つけるための奴隷でもない。開発者は最高の質のコードを提供し続けるべきであり、コードが準備万端になるまでQAにdeployするべきではない。

  • Automation

マニュアルのテストなんてするな。ひどい量のマニュアルテストを抱えていたテスターがテスト予算を半減された時に「行うべきでないテストは何ですか?」と相談しに来たことがある (馬鹿げている)。システムは成長し続け、マニュアルテストの予算も大きくなり続ける。手遅れになる前にテストは自動化するべきである。

  • Nothing Fragile

「このコードを変更することで複数のバグが生まれるためコードの変更は行ってなならない」などということは聞きたくない。

  • We cover for each other

我々はチームである。時折プログラマが独立して開発をし誰も他人のコードに触れようとしないことがあるが、あるべき姿ではない。自分の書いたコードを仲間とシェアして欲しいしそれぞれカバー出来るべきである。スポーツでそれぞれのポジションが割り当てられていても状況に応じて柔軟にポジション変更をするのと同じである。プロフェッショナルとしてチームの1人が休暇で居なくなったからといってプロジェクトが止まるなどということはあってはならない。

  • Honest Estimates

締め切りの申し出は特定の日ではなく、幅をもたせて伝えるのが開発者自身のためである。

  • You to say ”No"

無理な要求にはNo.と応えるのがプロフェッショナルの仕事である。マネージャや顧客には無い知識とスキルがあるからこそあなた達は雇われており、その判断をしなければならない。Yes.なんて犬でも言える。

  • Continuous Aggressive Learning

プロフェッショナルならいつまでも同じようなレベルのことばかりしているべきではない。貪欲に学び続けろ。

  • Mentoring

若者をプロフェッショナルへと導くのがプロフェッショナルの役目である。

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道

Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技