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 を利用していた。 作成当時PyMySQL3はMySqlへの接続が不可能な状態でバージョンを落としたら解決したらしい。
トピックはOPSかな?と思ってたらBABIPだったけど、LTのアダム・ダン率までの流れを考えると非常に秀逸*7。
紹介がかなり適当になってしまったが、PyCon面白かったです。
- 作者: 石本敦夫
- 出版社/メーカー: オライリージャパン
- 発売日: 2014/09/18
- メディア: 大型本
- この商品を含むブログ (1件) を見る
コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)
- 作者: 西尾泰和
- 出版社/メーカー: 技術評論社
- 発売日: 2013/04/24
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (31件) を見る
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に乗り換えたのでやっぱいいよなと思った。
今のところIntellij のPython pluginとPyCharmの違いはこれによるとJythonのSupport強度で、JavaとPythonのインテグレーションがあまり無いならよりシンプルな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日目のレポートは未定。
- 作者: 石本敦夫
- 出版社/メーカー: オライリージャパン
- 発売日: 2014/09/18
- メディア: 大型本
- この商品を含むブログ (1件) を見る
- 作者: フレデリック・P・ブルックス Jr.,滝沢徹,牧野祐子,富澤昇
- 出版社/メーカー: ピアソン桐原
- 発売日: 2010/12/14
- メディア: 単行本(ソフトカバー)
- 購入: 10人 クリック: 91回
- この商品を含むブログ (50件) を見る
Elasticsearch 101
Elasticsearchを使う機会があったのでBasicsをメモ。
Elasticsearchとは?
ElasticsearchはApacheプロジェクトの一つである検索用サーバで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点である。
- 取り込むデータの定義
- 検索の詳細の定義
これらの中でも特にキモとなりそうな点を以下にメモ。
使用方法?
以下では実際にElasticsearchを動かしながらIndexの設定と簡単なクエリの発行を行う。 なお、今回使用した全てのJSONはここにある。
取り込むデータの定義
Elasticsearchのインデックスは基本的にはスキーマレスではあるが、取り込むデータのフィールドの定義やdelimiterをmappingにて定義しなけれな成らない。 以下ではデータ整形とフィールド定義の2つのパートに分けて説明する。
データの整形フォーマットの定義
まずここでは取り込むデータの整形フォーマットの定義を行う。以下のJSONはmapping
の前半部分である。
整形方法の定義はanalyzer
に記述され、このanalyzer
は tokenizer
と filter
の組み合わせによって定義される。
tokenizer
は文字列の分割方法を定義し、以下の例にあるngram_token
は最小2文字、最大3文字のngramを利用する。
filter
は分割後の文字列の整形処理を定義するのだが今回は利用しなかった。
analyzer
はtokenizer
とfilter
を組み合わせて複数定義することが可能であり、それぞれの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の検索はquery
とfilter
によって行い, 抑えるべき点は
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 (アスキー書籍)
- 作者: Rafal Kuc (lにストローク符号、cにアクサン・テギュ付く),Marek Rogozinski (nにアクサン・テギュ付く)
- 出版社/メーカー: KADOKAWA / アスキー・メディアワークス
- 発売日: 2014/03/25
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
Apache Lucene 入門 ~Java・オープンソース・全文検索システムの構築
- 作者: 関口宏司
- 出版社/メーカー: 技術評論社
- 発売日: 2006/05/17
- メディア: 大型本
- 購入: 5人 クリック: 156回
- この商品を含むブログ (31件) を見る
アルゴリズムと人、数式と鮨。
アルゴリズムが世界を支配する。
検索エンジンのインデキシングやページランク、高頻度取引、商品のレコメンドエンジンなど今やありとあらゆる所でアルゴリズムが利用されている。もちろん人より精度も速度もアルゴリズムが圧倒時に優っている。
これからは人がアルゴリズムを”使う”というよりは、アルゴリズムが人の意思決定をする事の方が多いだろう*1。
そもそも人は考える行為を他に任せるのが好きな生き物だと思う。その一例がインターネットだ。
インターネットは偏在している知をへのアクセスを可能にした。一部の学会所属者のみが読めた論文、海外の情勢や景色、普段は接することのない高齢者と話すことでのみ知り得た戦争の話、職人的技能。そういうものを多くの人間の手が届くものにしたのがインターネットだ。
しかし、インターネットを通して情報を利用し多くの人が思考を加速させるはずだったのだが、人は考える事をすらも外部に頼るようになった。ハードディスクだけでなくCPUすらインターネットの向こう側に任せてしまった。大学生のWikipediaのコピーレポートがいい例だろう。
そして人は他人に頼るだけでなく無機質で感情のないアルゴリズムにも頼っている。映画評論家の勧める映画ではなくアルゴリズムが選んだ自分の好みの映画を選び、編集者が構成した新聞記事ではなくアルゴリズムが選んだニュースを嬉々として読む。
人の役割は次第にアルゴリズム取って代わられ、より正確で素早い結果が得られるようになる。
Google、Amazon、Facebookなど一部の優秀な人々が作っている大きな流れにのり、世界はアルゴリズムに支配される。 良い記事、良い商品は人ではなくアルゴリズムが選び我々に選択肢は与えられない。
一方で、人はアルゴリズムに負けていい部分とそうでない部分があるらしい。その違いなんだろうか。
例えば、Lispで書かれた作曲家エミー。デイヴィッド・コープ氏によって作られたこの作曲家はバッハの曲を学習データとして使用し、多くの曲を生み出した。 エミーが作曲した曲は出来がよく、あるオーケストラ様に作った曲はあまりに感動的でアルゴリズムが作った曲だとはわからない音楽家が居た。 しかし、そういった曲達がアルゴリズムによって出来たものだと知ると「魂がこもっていない」などと避難し、冒涜しているとコープしを殴るものも居た。 楽曲の質は良くとも人に作られたか、アルゴリズムにより作られたかで評価はがらりと変わってしまう。
将棋電王戦ではコンピュータ側が人間のプロに勝ち越した。将棋に詳しくないプログラマからするとコンピュータが勝つのは妥当のように思われる。単純なソートもダイクストラの最短経路も人は速度でコンピュータにはまず勝てない。 それと同様にこの完全情報ゲームで一流のプロ達はコンピュータに負けた。 棋士は歳をとると思考力は落ちるが、積み重ねた経験からくる直感で最善手が見え強者で居続けるという*2。 しかし、多くの解法パターンの中から最適解を見つけ出すコンピュータの側は、ある意味力技で直感力で戦う棋士達に勝った。 これは人類のコンピュータに対する敗北のようにも感じられ、計算能力からすると当たり前のように思われるのだが、同時に何か悔しい気持ちがあるのは自分だけじゃないと思う。
アニメPSYCHO-PASSもコンピュータによる支配と人間による支配の受け止め方に対する示唆に溢れている。 このアニメでは人の犯罪を起こす可能性が数値として表されており、その犯罪係数の高低によって可能な就職先や生活基準が決定さる。さらに係数が一定数を超えると実行していなくても逮捕されてしまう。 作中でこの数値はコンピュータの演算で行われているとされているが、実際は多数の人間の脳をつなぎあわせて導き出されていた、という展開がある。このことが公表されるとまずいという描写があるが、何故だろうか。 アルゴリズムで犯罪者と宣言されることと、人の脳の連結体にそう言われることは何が違うのだろう。
アルゴリズムは合理的な選択をする。疲れは感じず余計な情報にも影響されない。そして人も何かを選択をするとき、突き詰めていけばアルゴリズムと同じ選択をするだろう。 違いは何か。人とアルゴリズムの違いは”無駄”を重要視することじゃないだろうか。 伝統や感情、偏見、見栄など功利的に考えたら省くべきものを人は時に重要視する。本来必要ではないこれらの無駄たちがこそが人を人たらしめているのだろう。
伝統を重視するからこそ機械的に並べられた音符は受け入れられず、単調に動く機械には人は負けたくない。 同時に、人を判断するのは偏見やしがらみを持つ人ではなく、情報を黙って無感情に処理するコンピュータでないと納得がいかない。
無駄を省き正確で素早い意思決定が可能なアルゴリズムはこれから先も我々の生活を確実に向上させるだろう。
それでも僕は生産管理されたネタと機械的に生産されるシャリで作られる鮨より、職人が自身で見分けた魚を捌いたネタと手で重みを感じながら握られたシャリでできた鮨を食べつづけていきたいと思う。
記事に関連した筆者のオススメ
4Gamer.net ― 「ひろゆき」みたいな人間が増えていくと,人類は滅亡する!――川上量生氏との対談企画「ゲーマーはもっと経営者を目指すべき!」年末特別号
世界を支配する10種類のアルゴリズム : ライフハッカー[日本版]
- 作者: クリストファー・スタイナー,永峯涼
- 出版社/メーカー: 角川書店
- 発売日: 2013/10/08
- メディア: 単行本
- この商品を含むブログ (6件) を見る
- 作者: ジョン・マコーミック,長尾高弘
- 出版社/メーカー: 日経BP社
- 発売日: 2012/07/19
- メディア: 単行本
- 購入: 15人 クリック: 437回
- この商品を含むブログ (19件) を見る
アルゴリズムトレーディング入門 (ウィザードブックシリーズ)
- 作者: ロバート・パルド,山下恵美子
- 出版社/メーカー: パンローリング
- 発売日: 2010/06/11
- メディア: 単行本
- 購入: 3人 クリック: 22回
- この商品を含むブログ (1件) を見る
Web系企業のビジネスモデルと収益構造 (印象派)
Web系企業のビジネスモデルについて聞かれたのでWeb系企業関係者でもなんでもない自分がなんとなく考えてみた。
収益モデル
ぱっと思いつくのは以下の感じで、それぞれBtoBとBtoCでモデルに多少違いがあって*1表にちょっとまとめてみるとこんな感じかな。
モデル | BtoB | BtoC |
---|---|---|
広告 | 掲載 | アフィリエイト |
EC | 物販 | 物販 |
手数料 | 仲介サイト | オークション |
サービス提供 | プラットフォーム(ショバ代) | プラットフォーム(User向け) |
コンテンツ内購入 | - | ゲーム |
- 広告
- EC
- 手数料
- BtoB 転職や住宅情報を掲載して取引成約したら取引先の企業から手数料をもらう。
- BtoC オークションだったりマーケットプレイスみたいにユーザが商品を提供して取引があった場合に手数料をもらう。モデルとしては場を提供して利用者の取引からピンはねする点ではBもCも同じ。
- サービス提供
- コンテンツ内購入
- ゲーム等でその中でしか使えないアイテムを販売するモデル。ユーザからしたらお金を使えば使うほどコンテンツから離れ難くなる心理が働くからいい商売だど思う。
今後
現場の人間じゃないから詳しく知らないけどどうなんでしょ。クラウドファンディングなんかはこれから広がっていきそうだと思う。開発者の立場からするとRailsを始めとしたフレームワークが多くあるので学習コストが格段に下がりWebサービスを立ち上げることは簡単にできるようになったけど、これはどうマネタイズするんだろうっていうサービスも多々ある印象。そういうのの大半は広告で小銭を稼ごうとするのかな。
企業がサービスを立ち上げるならこれからはWebのみでなくやはりスマホ等のネイティブアプリも平行して展開して行かないと戦えなさそう。家に帰ってPCを開かずスマホで完結する層が増えたと思うけど、スマホのWebブラウジングってめんどくさいからWebだけだとなかなか使ってもらえないだろうな*2。
以上、非Web関係者の印象。
Web開発の基礎徹底攻略 (WEB+DB PRESS plus)
- 作者: 小飼弾,田籠聡,近藤宇智朗,並河祐貴,赤松祐希,井上誠一郎,ミック,天尋左石,和田裕介,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2013/07/23
- メディア: 大型本
- この商品を含むブログ (6件) を見る
Web業界 受注契約の教科書 Textbook for Business Contracts in the Web Industry
- 作者: 高本徹,藤井総
- 出版社/メーカー: レクシスネクシス・ジャパン
- 発売日: 2013/11/01
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
- 作者: 濱川智
- 出版社/メーカー: 翔泳社
- 発売日: 2006/12/14
- メディア: 大型本
- 購入: 1人 クリック: 5回
- この商品を含むブログ (3件) を見る
オフィスのGoogle化を試みる投資銀行
Banks ‘Googlize’ Their Offices to Land Tech Talent (投資銀行が優秀なITエンジニアを惹きつけるためオフィスをGoogle化する)
投資銀行も優秀なITエンジニアの確保に本気になってオフィス環境から変更していくらしい。
外資系投資銀行といえばアルゴリズムによるHFT *1に力を入れているためコンピュータサイエンスや数学・物理学の専門家を多く雇っている。所謂ロケットサイエンティストというやつである。
近年の投資銀行の利益の大半はM&Aや引受業務などの手数料ビジネスよりトレーディングによるサヤ取りによって生み出されるため、より早くより多くの取引を可能にするためのシステム構築に特に熱心になっている。 また、取引に関わる部分以外でも決済システムやドキュメント自動生成などあらゆる面でITに関わり仕事をするため技術力の差がファームの位置づけの差になると言っても過言ではなく、投資銀行は優秀なITエンジニアの確保に余念が無い。
しかし、近年は欲しい人材がシリコンバレーに流れてしまう傾向があるようだ。以前なら給与面でウォール街が人気だったのだろうが、金融危機後はウォール街での給与が落ち込み、逆にシリコンバレーにあるようなスタートアップでは(プチバブルもあって)給与水準が高まっている*2。 この傾向はFacebookやTwitterの台頭以降顕著であり、さらに自分の好きなことをして一発当てるアメリカンドリーム的な側面もある。
給与の面では最終的には差はなくなるのだが伝統的で保守的な投資銀行と新興のスタートアップでは労働環境がかなり異なり、お堅いオフィスでスーツを着て働くのとビリヤード台を横目にカジュアルな服装で自由な雰囲気で仕事をするのとでは仕事へのモチベーションが変わってくるだろう*3。
特に、GeekでTechyな連中というのはカジュアルでオープンな雰囲気を好む傾向にあるようで、投資銀行でもそういった人材に魅力的に思われる環境づくりを進めていくらしい。 自分の知っている限りでも投資銀行で働くエンジニアは優秀な人が多いと思うので良い人材良い労働環境に囲まれて働きたいのなら選択肢の一つとしてオススメである。
日本のSIerなんかもこういう面から労働環境を改善して優秀な人材に魅力的に感じてもらえるように成れたらと思うのだけどね。(そもそも彼らはGeek的な優秀さは求めてないかもしれないけど。)
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
若者をプロフェッショナルへと導くのがプロフェッショナルの役目である。
- 作者: Robert C. Martin,角征典
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2012/01/27
- メディア: 大型本
- 購入: 12人 クリック: 645回
- この商品を含むブログ (36件) を見る
- 作者: Robert C. Martin,花井志生
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2009/05/28
- メディア: 大型本
- 購入: 27人 クリック: 914回
- この商品を含むブログ (80件) を見る
アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技
- 作者: ロバート・C・マーチン,瀬谷啓介
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2008/07/01
- メディア: 大型本
- 購入: 18人 クリック: 586回
- この商品を含むブログ (71件) を見る