読者です 読者をやめる 読者になる 読者になる

Time Flies

fckey's Tech Blog

2015年に読んだ好みのIT本まとめ

今年読んで印象に残った・良かったと思った本をまとめてみた。IT以外の本も入っている。

今年は人工知能がバズり、特にディープラーニングに注目が集まった。ディープラーニングは学習の過程で特徴を導き出し、自ら概念を作り出せる。Googleの猫の認識が有名。

この本では基本的な人工知能の仕組みやディープラーニングのアルゴリズムも紹介し、著者の人工知能に対する認識 ー タイトルの通り人工知能は人類を越えるのかについて書かれている。その答えには是非この本を読んで触れて欲しいし、著者の想いを感じた後に自身でも考える価値のあるテーマだと思う。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

おそらく多くの人は既に知っているドメイン駆動設計の本。ドメインはアプリケーションのコンポーネントの担当エリアのようなものであり、ドメインの中でモデルと設計・実装は相互に密接に結びつきお互いにフィードバックを与えあるべきであること、言葉は共通に使える”ユニバーサル言語”を仕様するべきであること、またドメイン間のやり取りは基本的に特定のインターフェース意外では行わないこと(e.g.車ドメインのハンドル、運転設備だけが人ドメインから見えエンジン等のコンポーネントは隠されている)等ソフトウェアを設計思想が詳しく書かれている。

厳密なDDDを行わないとしても、ソフトウェアアーキテクトとしてレベルを上げるためには必読の本。

コンサルタントの秘密―技術アドバイスの人間学

コンサルタントの秘密―技術アドバイスの人間学

コンサルタントとして持つべきマインドセットが書いてある。 コンサルタントと言ってもいわゆる経営コンサル的なMECEやWhy So? So What?的な考え方ではなく(これらも学ぶ価値のあることでありロジカル・シンキング―論理的な思考と構成のスキル (Best solution)考える技術・書く技術―問題解決力を伸ばすピラミッド原則が良本)、エンジニアやその他の職種にも当てはまる共通の問題に対する考え方やあるべき姿勢が書いてある。以下のキーワードが気になるなら読む価値あり。

  • 問題の本質は常に人にある - 技術的問題に直面しているとしても元をたどれば人にある
  • 問題の提示 - 問題を指摘することで同時にマネジメントの失敗を暴いてはならない。コンサルタントに依頼するということは何かしら問題・課題があるということ。
  • オレンジジューステスト - 問題解決方の提示と同時にそのコスト・価格を提示する。出来る/出来ないのだけを答える人は信用出来ない。
  • ゴーマン法則 - 欠陥を転じて機能とする。見つかった欠陥は必ずしも負ではなく、活かす道もある。

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

技術者として学ぶ姿勢や、これから出会う困難との立ち向かい方へのアドバイスが詰まった本。 師弟関係の考え方をベースとして、1. 自らの置かれている状況 2. 本来はどうあるべきか 3. 問題を決するために取るべき行動という形で「パターン」として紹介されている。

デッドライン

デッドライン

トム・デマルコによって書かれた、ソフトウェアプロジェクト管理についての小説。主人公はアメリカで仕事を辞めた後、美人に会ったと思ったら東欧の共産国でのプロジェクト運営に巻き込まれれる...小説。(大事なことなので二回言いました)

短すぎる納期、わからず屋の上司、メンバーの衝突など、プロジェクト運営でよくぶつかる共通の問題を物語の中に上手く取り込み、その対応方法や考え方を主人公トムキンスの学びとして紹介している。最後のオチも意外(?)で物語としてもIT本としても面白い。

心理学、意思決定についての本。ファストアンドスローというタイトルの通り人間の思考には2通りあり、1つめのファストな方が直感、2つ目のスローな方が論理という考え方。

人は何かを見聞きした時、まずファストな思考が機能し、経験等から無自覚のうちにに答えを導き出す。対して、スローな思考が出てくると注意深く物事を観察、理解し順序立てて物事を考える。しかしこれらの思考は必ずしも独立して働かなかったり、アンカリングによる印象操作、ファストな思考に働きかけるハロー効果等などがあり、実験を通して人の考えや印象に影響をあたえるものは何か、人の解釈はどう働くのかについて研究されている。 UIやマーケティングの人は特に読む価値あり。

ポーカーの大会に参加してみた

今年の始めからテキサス・ホールデムというカジノでよく行われている形式のポーカーを始めた。 手元に2枚のカード、場には最終的に5枚のカードが公開され計7枚の中から好きな5枚を使用して役を作る形式のものだ。

ルール自体は簡単だが、チップの掛け方や相手との駆け引きなど奥が深い。

先日行われていた全日本ポーカー選手権(AJPC)に参加した所、あと10人いなくなったら入賞というところまで残って結局脱落してしまった。

トーナメント形式は初めてだったが、初心者でも打ち回し次第で経験の長い人と対等に渡り合えるのがポーカーの面白いところだと思う。(根拠のない手を打った方がだいたい負ける。)

出ているカードとポッドサイズ(掛けられたチップの量)から期待値を計算したり、これまでの相手の動きから相手の強さを予想して勝負するか引くか考えていく感じは、理屈で考えつつも感覚的なものも大切にするプログラマ好みの遊びなんじゃないかと勝手に思っている。

もっと一緒にやる人が増えたら嬉しいので気になったら試しに遊んでみて欲しいし、一人で勉強しづらいなら声をかけて欲しい。 ちなみに海外で行われているポーカーの大会は数億円という賞金がもらえるものもあり、日本の大会で勝ち進むとそういった大会に出れたりもする。

用途別で以下の本がオススメ

ルールを勉強したい人に

ポーカー教室

ポーカー教室

ルールは知っているがなかなか勝てない人に

フィル・ゴードンのポーカー攻略法 入門編 カジノブックシリーズ

フィル・ゴードンのポーカー攻略法 入門編 カジノブックシリーズ

トーナメントの戦い方を知りたい人に

アグレッシブポーカー トーナメントを制覇しろ

アグレッシブポーカー トーナメントを制覇しろ

オンラインポーカーで稼ぎたい人に

フィル・ゴードンのデジタルポーカー

フィル・ゴードンのデジタルポーカー

後輩プログラマに入社する前に身につけて欲しい考えと技術要素

はじめに

組織でチームとして開発をすることは、趣味で行うプログラミングをや学生が研究のために開発をするのとはまた異なる知識やスキルが必要となる。本文ではチーム・業務環境での開発に明るくない人を対象としてその考え方の違いや、身につけて欲しい知識としてCI、テスト、DB周りの事を紹介する。

プロフェッショナルとして組織で開発するということ

学生や個人で開発をすることと、企業で開発をすることの大きな違いとして、金銭等を対価にシステムの運営を期待されていることや不特定多数との共同作業が求められることなどが挙げられる。

プロフェッショナルとして

企業で開発をするということは基本的にはお金を対価に製品・サービスを提供することだ。「僕の変更でちょっとシステム止まっちゃった、動くまで1時間待って」では済まないのである(最近たまに見る光景ではある)。"Don't Ship the Shit"だ。貴方の研究のアルゴリズムが間違ってたせいでプレゼン資料に誤ったデータを載せて教授に注意されるのとはわけ違うわけだ。

こういった問題を防ぎ、プロフェッショナルとして製品やサービスを提供するにはコードクオリティの向上が必要だ。今回紹介する技術要素は全てここに関わってくる。

チームとして

組織における開発はとにかく関わる人が多い。大学等での開発はほとんどが個人、もしくは先輩後輩で密にコミュニケーションの小さなチームで異なる部分に着目しての開発だろうか。 その点企業での開発はほとんどがチーム、多きなものでは数十、数百人がひとつのプロダクトを開発するために関わるだろう。 更に貴方のチームメイトは今一緒に働く人達だけじゃなく、将来入ってくる人々も貴方の加える変更の影響を受けるチームメイトなのだ。

この様に企業では不特定多数の人が関わり一つのものをつくり上げることを意識しなければいけない。

身につけて欲しい技術要素

CI (継続的インテグレーション)

CI (継続的インテグレーション)はソフトウェアのビルドやテストを継続的に行い、ソフトウェア品質の維持を保つための仕組みである。ここではgit、svnなどのバージョン管理システムから継続的デリバリなどの一連の流れを含めてCIとして挙げてある。

VCS (バージョン管理システム)

最近は学生等にも広く浸透していると思うがgitやsvnなどのバージョン管理システムは安定した開発を続けるために非常に重要だ。 既存のコードに変更を変更を加えて何かを試したいときにファイルの名前を変えたりコードをコメントアウトするのは筋が悪い。 行うべきはコードのコミットであり、後はツールが履歴の記録やdiffの生成を簡単に行ってくれる。

また、VCSを利用することでコードの共有が圧倒的に容易になる。チームで開発をするときにはひとつのリポジトリからコードを取得しメンバーの開発した成果は最終的にひとつのリポジトリに入れられる。この際は自分の成果が他のモノを壊していないか充分に確認してから行うべきだ。 自分の変更が他の人に共有される事を意識してコミット時のコメントは他のチームメイトや将来自分が見返した時に意図が伝わりやすいものを意識しよう。

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

Subversion実践入門:達人プログラマに学ぶバージョン管理(第2版)

Subversion実践入門:達人プログラマに学ぶバージョン管理(第2版)

コードレビュー

コードレビューはその名の通りコードの出来を皆で確認するプロセスだ。ここに辿り着くまでにはたいてい幾つもの苦労があるが、これも大きな関門だ。ある意味自分のデキのshowcaseであり、実力が判断される場だ。見苦しいshitを皆の前に出さないように気をつけよう。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

CI (継続的インテグレーション)

個人での開発のレベルでCIをきっちりと行っている人は多くはないかもしれないが、CIは手間のかかるビルドをビルド自動で定期的に行う事を可能にし、その際ビルド結果に対するテストも可能にする。これを継続的に行うことでコードの異常を素早く発見することができ、自動化されているため一度設定してしまえば手間も少ない。多くの場合、JenkinsやTeamCityなどのツールが使われている。

環境にもよるが、共有リポジトリにコミットがあったらビルドを走らせるという設定をしている場は多いだろう。コミットは必ずビルド・テストが全て適切に行えるとローカルで確認してから行うようにしよう。(万が一共有のビルドをクラッシュさせた場合には直すまで鬼のように電話やメールがくるという可能性も否定出来ない。)

継続的インテグレーション入門

継続的インテグレーション入門

開発ツール徹底攻略 (WEB+DB PRESS plus)

開発ツール徹底攻略 (WEB+DB PRESS plus)

継続的デリバリ

企業文化にもよるだろうが、多くの場合は変更が出来たらすぐに変更をリリースというわけではない。 1週間や1ヶ月に一度プロダクションリリースの日があり、その日を目標にある機能を作成しQA環境でのテスト、ユーザを巻き込んだUATをパスし準備万端の状態でリリースを行うことが望まれている。 きたるその日に備えて我々プログラマは日々コードとにらめっこするのだ。

個人的にはチェックイン後のビルドが走る度に最新のコードがQA環境に自動でデプロイされ、UAT環境には基本的なテストをパスしたRC(Release Candidate)のみがデプロイされるというような設定が好きだ。 UAT後の変更は有り得る話だが、基本的にUATまでには出来る限り全ての確認を終えあとはリリースをするだけだという状態で臨みたい。 最後に急な仕様変更を求めてくるクライアントはクソ食らえだ!

Jenkins実践入門 ?ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)

Jenkins実践入門 ?ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

テスト

企業での開発はテスト!テスト!テスト!!だ。 学生時代に研究用のコードにテストを書いていた人はあまり見たことがないが、企業ではそうはいかない。 成果の出来を確認し、クライアントのもとに届けるまでにはユニットテスト、レグレッションテスト、インテグレーションテスト等々様々な切り口からのテストが必要となる。(それぞれのテストの意図がわからない人は今すぐググろう) テストを書くことは意図せぬ変更からチームメイトを守り、将来再びそのコードに訪れる自分を守ることに繋がる。

最近はコードの中で完結する従来のようなテストのみでなく、ユーザも巻き込んで仕様書をインプットとしたりテストケースをプログラムに詳しくない人にも書かせることを可能にしたFitnesseや、(マウス)ポインタをハイジャックして実際のGUIを用いてテストをするSikuliといったものまである。 テストに詳しくなって強固な開発基盤を構築する事を意識しよう。

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

DB (SQL)

ここではDBの設計等ではなく、SQLクエリの話だ。(余談だがEnglish SpeakersはSQLを”えすきゅーえる”と発音するのではなく"しーくる"と言う)

アドホックなクエリ、プログラムに組み込むクエリどちらの場合もとにかくパフォーマンスを意識するべきだ。 プロダクションDBでなにか探しものをするときに酷いクエリを走らせてCPUを専有しシステム全体のスループットを落としましたなどとなったら目も当てられない。

クエリの設計・実行を行う場合にはどのインデックスを使用するのか、クエリプランはどのようになるか、充分なフィルタはされているのか、ストアドプロシジャにするべきか否か等をよく考えてから行動をするようにして欲しい。

良記事:開発者のためのSQLパフォーマンスの全て

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

SQLアンチパターン

SQLアンチパターン

まとめ

以上で新人のプログラマに働く前に最低限抑えて欲しいことを挙げたが、実際に働き出したらここに挙げたような事でもわからないことに多くぶつかると思う。 そんな場合にはこんなことを聞いてもいいのかと思い悩まずにどんどん先輩に質問して欲しい。 多分先輩社員はなんだかんだ後輩が来るのが楽しみであるだろうし、新人の成長はチーム全体の生産性の向上につながるのでそのための協力は惜しまない。 この文を読んでくれた人が良いデベロッパとして楽しい環境で開発を続けられることを祈っている。

IDEA IntelliJにおけるGroovyの開発環境設定メモ

IntelliJでGroovyを導入しようと思ったら思ったより手間取ったのでメモ。

IntelliJでprojectを作ると最初にに[No library selected]というメッセージが出てSDRの指定を要求される。ここでSDKを見つけるのに時間がかかった。

homebrewを利用してインストールしてした場合には"/usr/local/Cellar/groovy/"がインストールパスとなり、IntelliJでは"/usr/local/Cellar/groovy/[version]/libexec"をSDKのパスとして指定。

しばらくはPythonを離れてGroovyで精進しないと。。。

プログラミングGROOVY

プログラミングGROOVY

Groovyイン・アクション

Groovyイン・アクション

2014年に出版された好みのIT関係本まとめ

2014年に読んだ本の中から主に2014年(及び2013年)に出版された自分好みの本をざっとリストアップする。

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

タイトル通りAPIデザインについて詳しく書かれた本。読者としてはJavaデベロッパを想定しておりJava特有のJDKのバージョン互換性やソースコード互換性に言及しているが、OOPの素養がある人なら読み進められると思う。なおカバーの隅には「※本書はプログラミングの初心者向けではありません。」などと書いてある。

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

Javaエンジニア養成読本 [現場で役立つ最新知識、満載!] (Software Design plus)

最近のJava事情についてエンタープライズ用から普通?のJava、またJava8で導入された機能についてざっと書かれている。普段Java以外の言語でプログラミングをしている人にオススメ。普段からJavaを扱っている人も立ち読みですましたら充分だと思うけど一度手にとって眺めてみたら新しい発見があるかも。

Javaエンジニア養成読本 [現場で役立つ最新知識、満載!] (Software Design plus)

Javaエンジニア養成読本 [現場で役立つ最新知識、満載!] (Software Design plus)

人月の神話【新装版】

銀の弾丸でおなじみ人月の神話。本来ならこの本は10年前に出版されているのだが新装版が2014年に出ているのでここに挙げる。 このバージョンでは最初の人月の神話が出版されてから20年が経ち、初版からの反省点やより主張を強めた点が述べられている。 今日では初版の発行より40年が経っているわけだがこの本で述べられた内容は未だに実際の現場でも当てはまる点が多く、ソフトウェア開発の本質に多く触れられている。 (銀の弾丸、欲しい。)

人月の神話【新装版】

人月の神話【新装版】

おもしろいゲームシナリオの作り方 ―41の人気ゲームに学ぶ企画構成テクニック (GAME|DEV|LAB)

FFやひぐらしの鳴く頃に、GTAなどの実際のゲームで例を挙げつつストーリーのインタラクティブ性や分岐によってゲームを5つのタイプに分けて説明している。自分は普段ゲームを作るわけでもなくプレーもそこまでしないがなるほどと思いつつ、ついつい見入ってしまった。 また、シナリオの組み立て方として"ヒーローズ・ジャーニー"のフレームワークを紹介しており、ストーリーは旅立ち、通過儀礼、帰還の三幕に分けられ、各幕はさらに細分化される。これはシナリオを作ってみたい、作り始めたばかりという人には必見だろう。 三幕構成についてはこのブログがおすすめ。

ちなみに、友人曰くクロノトリガーをやってない人には人権が無いらしい。

おもしろいゲームシナリオの作り方 ―41の人気ゲームに学ぶ企画構成テクニック (GAME|DEV|LAB)

おもしろいゲームシナリオの作り方 ―41の人気ゲームに学ぶ企画構成テクニック (GAME|DEV|LAB)

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

この本にはこちらの記事でも触れたが、アルゴリズムは進化を続け私達の生活にどんどん入り込んでくる。その実例にこの本で触れ、今後の超情報社会との付き合い方を考える切っ掛けにしたら良いだろう。

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

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

ルールを変える思考法 (角川EPUB選書)

角川ドワンゴ会長の川上量生氏のインタビューをまとめた本。自分は元記事ゲーマーはもっと経営者を目指すべき! - 4Gamer.netをずっと追っており、Webの削られてない部分にも大事なものが含まれているので個人的にはWebで読むのがオススメ。川上氏独特の世界観により解釈された、次世代のコンテンツ業界およびインターネット全体の行く末を考える上で重要な要素がそこら中に散りばめられている。

本が出た後の元記事でも特に以下のものは必読。

電王戦は,21世紀を生きる人類を映し出す鏡なのかも――将棋棋士・谷川浩司氏がゲストの「ゲーマーはもっと経営者を目指すべき!」第16回 - 4Gamer.net

人類は「機械が生み出す知財」にどう向き合うべきか――SF作家・藤井太洋氏がゲストの「ゲーマーはもっと経営者を目指すべき!」第19回 - 4Gamer.net

任天堂・岩田氏をゲストに送る「ゲーマーはもっと経営者を目指すべき!」最終回――経営とは「コトとヒト」の両方について考える「最適化ゲーム」 - 4Gamer.net

2014の読書関連ではこのブログ 2014年に読んだ技術書で良かったもの - うさぎ組 も俺好みでした。

感想・意見ありましたらTwitterでご連絡下さい。現場からは以上です。

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:アイドルだった