PyCon JP 2014 Day 3 感想とノート #pyconjp

LINEで送る
Pocket

昨日に続いてPyCon JP 2014に足を運んできました。日本のカンファレンスながら、英語が飛び交う国際感高いものとなっています。実行委員の皆様、話者の皆様、お会いした皆様、大変お世話になりました。お楽しみ様でした!

それでは、今回もノートをアップしておきます。こちらは2014/09/14(日)に行われた3日目、カンファレンスとしては2日目のノートです。

IMG_2360

抽選会ではpepperが当選番号を読み上げていました。先進的!

2日間を通した全般の感想

  • 科学計算系、特に機械学習とそれに派生する話が他のカンファレンスに比べて多かった。自分がこれらに携わっている時に聞けていたら、もっと研究を楽に進められたはず。
  • PythonとITインフラ系の話を絡めたセッションは特になかった。というか、機会があれば自分が話せばいいのかとも考えている。
  • オフィスアワーが設定されていたのはとても良かった。実は、YAPC::Asiaの発表をしてから、質問したいけどkoemuを捕まえられなかったというコメントをもらっていて、何か申し訳ない気持ちになっていたからだ。実際、PyConの懇親会でもYAPCの発表の件で声をかけられてもいる。
  • Python 2と3の間にある溝をどう捉えるか、Pythonに入れ込んだ事がある人は考えなければならない課題となっている。ただ、僕の中ではまだ3にどっぷりという判断ができないので、辛い。
  • 懇親会は向き・不向きがある事を再発見した。当たり前の事だが、身内だとより現実的に捉える事ができた。今後は、懇親会に来てみたいんだが迷っている人の背中を押す事ができればと考えている。
  • 西尾さんの講演の後、ポスター展示を見てしまうと時間を持て余してしまって、さてどうしたものかと悩んだ。例えば、YAPC::Asia 2014のように、無限コーヒーコーナーを通じて交流を深められる場があると良いのかもしれない。
  • 相方とイギリスに旅行に行ってから英語がスムーズに話せる事の重要性をひしひしと感じていたが、今回さらにその認識を深める事となった。やはり、英語で質問・会話できないのはかなりの機会損失になっている。かなりやり込まないと行けない。もっと異文化交流したい。
  • 弁当やケータリングにハラル・ベジタリアンメニューがあるのは素晴らしい。そして、日本では本当に珍しい。海外のカンファレンスではよく準備されているので、日本人もそう言う意識は高めた方が良いと思った。

Keynote

  • @nishio さん
    • サイボウズラボ
    • 邪悪なPythonista www
    • Slide
  • 感想
    • ソフトウェア技術者の育成、これまで職人芸っぽいものがあってモデル化されていなかった所を、西尾さんが取り組まれているのはいつも感服する。
    • 西尾さんが持っているテーマを改めて棚卸しして伺っているように思った。
    • ソフトウェア工学とはまた違った、ソフトウェア技術者育成のモデルを作る事に、自分も加担していくモティベーションをあげる良い時間となった。
    • 「盲点」がみつかると思わず死にたくなるほど辛い気持ちになりますが、西尾さんの話を基準に考えるとそれは普通の事でそれほど気にする事でもないのがわかり、安心した。
  • 1行でPythonを書くwww ワンライナーの話
  • サイボウズラボ
    • 次世代のグループウェアを研究
    • 利用シーン
    • 自動化
      • 設定管理
      • テスト
      • Jenkinsスクリプト
    • インフラ
      • DRでのバックアップスクリプト
      • P2P automatic failure recovery system 月読
    • 解析
      • 収集
      • データクレンジング
      • 統計処理 NumPy, SciPy
      • 今日はここをクローズアップ
  • 解析について
    • 西尾さんの担当
    • kintoneとGitHubの比較: ソースではなく、データを溜め込む所が違う。
    • kintoneにはたまっているデータを見て、どのようにビジュアライズするか提案する機能がある。これはすごい。 詳細:「おすすめグラフ」の裏側
    • プロトタイプ、Flask + NumPy。
  • Groupware
    • Group + Software
    • Douglas C. Engelbart: Augmenting Human Intellect
    • Googleのある状態: 知性が強化されていると感じませんか?
    • コンピュータによって人間を強化する
    • モニタリング
      • 自分自身をモニタリングする事はできない。ダメな時にダメな自分でモニタリングしても、気づけないのではないか。
      • 他の人にモニタリングしてもらう: 精度は上がるかもしれないが、プライベートな情報等を渡さなければならず、人間関係が問題になる。
      • ではコンピュータにやらせてみよう。
      • やる気の出るアドバイス
        • 僕は前使った時にやる気が出ました!!!
    • 人間の情報を取り込む能力を強化するために、コンピュータを利用していく。
  • 人間の増強の4要素 (Augmenting Human Intellect)
    • Artifacts
      • Computer, Software …
    • Language
      • Design Pattern, 専門用語…
    • Methodology
      • 問題解決のための手順、戦略…
    • Training
      • これらを利用できるための育成・教育
  • Discover – 方法論
    • 詳しくなればなるほど、バイアスに縛られて見えなくなるものがある。
    • だからこそ視点を変えて行く必要がある。
    • Known <–> Unkonwn の間に「不明」な領域がある。
    • まずは「知っている領域」を明確にする。そうすると、盲点を理解できる。
  • 抽象的なものは、具体的なものに紐づける事で理解する事ができる。
    • 例えばTrueの定義の違いとPythonの事例
  • 歴史を追うことで盲点に気づく
    • 例えばなぜPythonにはNew-Styleクラスがあるのか
    • それは型とクラスを融合する必要性があったから
  • 経験をする事で理解する
    • 例えばPythonは 1 / 2 = 0.5 にならない
    • これってMediatorパターンって名前だったんだ!→経験に名前が付けられる事で言語化できる
  • 学びは必ずしもひとりでする事ではない
    • 経験の異なる他人と会話する事で盲点に気づく
    • オフィスアワー、ブログ、メールでのコミュニケーションしましょう!
    • 今後、情報は英語化を進めます。
      • 僕もやろう。
  • 質問
    • Q: 認知的不協和
    • A: U理論 (どう書くか後で西尾さんに聞いた、ありがとうございました!)では7つのステップに分解されている
      • 自分以外の他人を自分が啓蒙するのは、良い思考ではない。自分が変わる方が良い。
    • Q: CEで成功するポイントを挙げていると思う。モデリングをどう考えるかもポイント思うがどうか?Abstraction自体が大事なのではないか?
    • A: とても大事な話だと思う。 エンジニアの学び方─効率的に知識を得て,成果に結び付ける の第3章にまつわる話。
      • 試作して試して確認して…を繰り返して精度を上げる。
      • 人文系のような実験が難しい場合は、Grounded TheoryやKJ法を適用する。

OpenCVのpythonインターフェース入門

  • Masaki Hayashiさん
    • 機械学習の画像認識の研究に従事 (D3)
    • 人物姿勢推定を動画から解析する研究をしているらしい
    • Slide
  • 感想
    • がんばってC++を書く事が減るのはとても良いですよね。今度からPythonで書く。
    • CUDAとかはサポートしていないそうですが、これが直ちに問題になるのは限られた状況かなと理解している。
    • (話とは関係ありませんが)会場設営をもっと早め、せめてもう10分早くやるといいと思った。ポスターセッションが長く続いていたので、入場待ちの人が廊下に溢れていた。
  • 概要
    • OpenCVのPython I/Fのチュートリアル
    • C++で時間を損している人もいる!ぜひPythonでも触ってほしいなー
    • Scikit-learnやPandasが使える人が画像認識も使えるようになるといいな
  • OpenCV
    • Python, Java用のラッパーもあり、C++と同じように使える。
    • 現在は 2.4.9、先日 3.0.0のα版も出た。
  • 応用モジュール
    • 機械学習のライブラリは、OpenCVではなくscikit-learnの利用をお勧めする。実際、連携しやすいそうです(pandasも)。
  • 画像の可視化
    • matplotlib,PIL,scikit-imageはRGB画像で保持するのに対して、nnOpeCVはBGR画像がデフォルト。変換処理が必要。
  • あとは、実際の使い方を解説。
  • HOG, SVMを使って人の検出がOpenCVで検出
    • 詳しい話は GitHub リポジトリにて。
  • 質疑応答
    • Q. デメリット
    • A. 計算速度が遅い
    • Q. 2.4.9か2.5か?
    • A. anacondaで入るのが2.4.9なのでこっち
    • Q: GPUアクセラレーション対応のラッパはあるか
    • A: ラッパがない

Pythonによる非同期プログラミング入門

  • Hironori Sekineさん
    • アライドアーキテクツさん
  • 感想
    • 非同期なコードを書きやすいというだけでもPython 3.4に移行するのはありなのではと考えた。
    • サンプル、あまり実感が沸かなかった。もう少し現実に即した例だと嬉しい。
  • Agenda
    • 同期・非同期のおさらいと違い
    • Pythonの非同期F/W
    • asyncio概要とサンプル
  • 同期・非同期のおさらいと違い
    • 非同期はCPUバウンドな処理には有効ではない
  • Pythonの非同期F/W
    • twisted
    • tornado
    • gevent
    • そして thread, multi process (これはライブラリという訳ではないけど)
  • Twisted
    • イベントドリブン型 NWプログラミングF/W
    • 2003年〜
    • defferedを駆使して書く
  • Tornado
    • FriendFeedが作り始めて今でもメンテされている
    • Web F/W + 非同期通信ライブラリ どちらかを選択する事も可能
    • 非常に高速 アドテクでも使われているくらい
  • さて
    • 選べるけど、どれがスタンダードかわかりづらい。
  • asyncio
    • PEP 3154 のリファレンス実装
    • Python 3.4 から標準ライブラリとなった
    • 各種プラットフォームサポート
    • 既存のF/Wを保管している
    • アーキテクチャ
      • Event loop: プラットフォームに最適なI/O処理を提供する
      • Corutines: PythonでいうGenerator
      • Future, Task: 非同期実行をカプセル化

NOCツアー

  • NOCのみなさん
  • 感想
    • 最高のカンファレンスは最高のITインフラに支えられている。
    • カンファレンスネットワークと、携わっている人はもっと評価されていいと思う。
    • 敷設、及びトラブル対応の手際の良さはハンパない。普段相当取り組まれているのだろう。
    • NOCツアー、仕事の差し障りがあるはずなのであまり大々的にできないかもしれないけど、話がこうして聞けただけでも良かった。そして、いきなりお邪魔してすいませんでした…。
  • See also: PyCon JP 2014 開催前レポート 第3回 会場・パーティについて :CodeZine
  • プログラムになかったけど、急遽(?)開かれていた模様。
  • ネットワーク機材、NOCの模様、及び各部屋への配線の事例について解説。
  • 設計
    • 事前に建物の配置等を確認していた。
    • 綿密に設計書を書かれていた。特に配線。
  • ゲートウェイ
    • Flet’s Nextをこのために引き込んでいる
      • (ONUはいつも家で見るそれそのもの)
    • DualStack-lite
      • IPv4はv6をトンネルしている
      • v6のIPが降ってきているのはそのため
      • IPv4は局側のLS-NATを使って外に出ている
    • カンファレンス2日目は最大110Mbpsをマークしたそうだ(カンファレンス1日目はもっとあったらしい)
  • Macのifconfigの結果
$ ifconfig   # 一部省略
en0: flags=8863 mtu 1500
	ether 84:38:35:??:??:?? 
	inet6 fe80::8638:35ff:fe44:8584%en0 prefixlen 64 scopeid 0x4 
	inet 10.1.0.25 netmask 0xfffffc00 broadcast 10.1.3.255
	inet6 2409:10::504:8638:35ff:fe44:8584 prefixlen 64 autoconf 
	inet6 2409:10::504:5481:e39:453e:628f prefixlen 64 autoconf temporary 
	media: autoselect
	status: active
  • DHCP
    • 約1,000個確保
    • 500〜600個程度リースされている実績を確認している
  • 機材
    • 事前に別の場所で設定、稼働テストを実施。 (これはLTで聞いた)
    • 機材の死活は Dead Man で監視。
      • Interopでも使われていたもの。確かにShowNetで同じものを見たな。
      • Pingのみでシンプルだがいいソフトっぽい。
    • YAMAHAさんから提供を受けている
    • Wi-Fi AP
      • YAMAHA WLX302 がメイン。
      • 予備はIIJのWi-Fi APがいくつか。
      • 大ホールは5台。
      • メディアホールは 2台。
      • 各会議室は1台。
      • 急遽、懇親会会場や1階のテラスに増設。
    • スイッチ
      • 動画送信だけ、品質が落ちないようQoSで優先して使えるようにした。
      • スイッチをリピーターとしても使っている。
      • 急遽AP追加もある程度見据えて設置。
      • 看板の裏等に隠してあまり目立たないようにしている。セキュリティ、及び景観を考慮。
  • ケーブリング
    • 3時間で構築 ただし事前の設計は綿密だったようだ。
    • 機材は看板の裏に隠して置いている。
    • 3階から4階は階段経由。隙間をうまく使ってケーブルをショートカットさせている。
    • メディアホールは3階から直接接続しづらかったため、調整室の窓から出している。なので3→4→3階と経由している。
    • 断線を考慮して、その可能性がある部分は部分的に取り替えられるようにメス・メスのコネクタでケーブルを分離。
      IMG_2357
    • その他の配線の様子はこちら。足の踏み場や防火扉をうまくかわして配線されています。
      IMG_2359
      IMG_2356

Python Quest in Taiwan

  • Keith Yangさん
  • 感想
    • 台湾、ソフトウェア開発教育に積極的だ。
    • 教材にPythonが使われているケースが増えているような気がしている。
    • ローカライズしてまで使ってもらおうとする組織力、すごい。日本ももっと大きな集団でやれたらいいなと思っている(実際ちょっとやってる)。
  • 変化・チャンス・そして挑戦
    • 教え、学び、書き、そして教育する
    • Pythonは学びやすい(と思う)
    • イギリス: Code Club
      • 放課後教育で9〜11歳に教えている
      • BBCがソフトウェア開発教育に関する番組をはじめているらしい
      • (前にLondonで聞いた話と同じだった)
    • CheckIO
      • 体験の共有?交換?
    • PyCon Taiwan (2014)
      • CheckIOを中国語で
      • 地元での挑戦
      • 英語から中国語に訳さないと
      • カスタマイズしたゲーム
      • 旧来の教科時間とぶつかってしまう
        • あー、とりくめなくね?これだと。
    • geekpy.org
      • 優秀者にはpycon taiwan 2014に参加できる
      • 楽しさを拡散させて行く
      • モティベーションを持つのが大変
  • PyCon Taiwan 2014
    • 100枚の学生チケットが売り切れた
  • 教え学ぶ勉強会
    • Taipei Python Workshop
      • 朝: setup games
      • 昼: チームプレー
        • Web, GUI, Mobile, Data
      • 良い結果を得られた
  • その他のイベント
    • PyLadies Taiwan
    • Django Girls Taiwan
    • Raspberry Pi Workshop
LINEで送る
Pocket

PyCon JP 2014 Day 2 感想とノート #pyconjp

LINEで送る
Pocket

2014/09/12(金)から始まっている、PyCon JP 2014に来ています。今は3日目の朝に行われる西尾さんの基調講演を待っている所です。楽しみです!実はPyConは初めてなのですが、YAPC::Asiaとまた違った趣があって楽しいところです。

それでは、今回もノートをアップしておきます。こちらは2014/09/13(土)に行われた2日目、カンファレンスとしては1日目のノートです。

オープニング

  • 感想
    • しょっぱなから英語
    • 海外から人を招聘しているんだ感が高かった

Keynote

  • Kenneth Reitzさん
    • Heroku
    • PSFの中の人
  • 感想
    • 安定と変化のバランスの難しさを再認識させられる話だった。
    • Python開発の中心にいる人たちは早めにPython 3に移行してもらいたいいのだろう。
    • 言語を選ぶより、言語の中のコミュニティを選ぶ方が、開発の時に幸せになれそうな気がしている。
    • Self
    • Time
    • Other
    • Space
  • そもそもLanguaeだよね
    • Pythonの前に集っている
    • 自然言語のように今日は扱ってみる
  • 言葉の歴史
    • 言葉を通じて考えている事を人に伝えている
    • 時間とともに考えを保存して伝承できる
    • とっても素晴らしい事だよね!
    • 人というハードは変わっていないけど、スキルを通じてソフトウェアをアップデートしている。
  • 1-to?1
    • 実際ではもっと多くの人とコミュニケーションしている
    • エジプトの石盤
  • 1-to-many
    • 印刷機の発明
    • ひとりが何千の人とコミュニケーションできる、これは革命。
    • 新聞、本、テレビ、ラジオ、等。
  • many-to-many
    • the Internet !
    • 全ての世界から情報にアクセスできる。
    • 大規模だ(huge)
  • 空間(space)
    • 知らない間に、たくさんの人とコラボレーションできる空間。
  • 軸をまたぐもの
    • 様々なツールがある
    • テクノロジーがあるように言語がある
  • Pythonの未来に恐れを抱いている、怯えている。
    • これは世界の将来が危ぶまれている。
    • 2と3の分断された世界
    • (挙手の状況が2の方が比較的多かった)
    • 3はみんな怖がっている、話者も使ってない。
    • Flask開発者によるとUnicodde ,Codex, and Friendsの物事をどれだけ破壊したか長い話があった
    • Standard Libraryが壊れていて辛い(僕自身も辛い)
    • こりゃ残念な事だ
    • 改善は毎日進んでるけどね
  • なぜ?
    • Python 3のユーザが少ないから
    • (挙手の状況を見てもわかるよね!)
    • PyPi, pipに変更が加わった→利用しているPythonのバージョンによって切り替える仕組みができた
    • 2週間で、2は81百万、3百万ダウンロード。偏りがあるのがわかるよね?これが現実。
    • (動かない→使わない→改善されない、悪循環っぽい。)
      -
  • Python 3
    • 新しい人が、Python 3を選び始めている。
    • 初めてだから、選択する事ができる。
    • 既存の確立されたコミュニティとは違う。
    • 開発者、Pythonのコミュニティの間にも断絶がある。
    • 製品を開発する時のマーケットの問題。
    • 2と3で2倍のメンテコスト。辛い。
    • 分裂が促進されている。
  • これは貴方の問題です
    • 同時にあなた方がソリューション。
    • 2つのものが1つになる。
    • 知識と愛。
    • 直接体験して自分で決めてほしい。
    • Python 3を使って、何かあればブログを書こうぜ。体験を共有しよう。
    • Python 3の食わず嫌いはやめよう。
    • 静かに、何かを待っているのは良くない。
  • 質疑
    • Q: Perl5/6の問題とにてるけど、あっちはPerl6は別のものとして分かれた。Pythonは分かれずに収束していこうとしているけど、どうして?
    • A: 変換はできるパワフルなツールはあるけど、それだけでは間に合わない。だから、多くの人がどちらにも対応できるコードを書くようになってきた。でも、それって良くない。Python 3の利点が活かせない。
    • 同時にみんながPython 2をやめて3に移行するならいいけど、そんなわけにはいかない。
    • PSFでは2.8はないと決めている。ただ、もっといいソリューションがあればいい。
    • ご自身の意見をみんな持ってほしい。
    • Q: 同時にどっちもサポートするのは辛いのは知ってると思う。で、Python 3で書くメリットとは?
    • A: ない…な(ここで一同爆笑)。でも、いろいろいいものは入ってるよね。他の言語でできる新しい事もできる。エキサイティングだ、でも、同時に…ここで2をきっぱりやめる事もむずい。
    • Q: 自然言語処理をやってるんだけれど、C, C++のような標準化は行われるの?Pythonの標準化活動ってあるの?長期的なPJでは、そうあったほうがいい。
    • A: Python 2.7は今後10年変わらない(多分RedHatがサポートする事は踏まえられているんだと思う)から、それを選ぶのはどう?2系がいいと思うよ。
    • Q: 2つ目の質問に近いんだが、Python 3を使おうと言いながら2を使っている。クリアなコミュニケーションが行われていない、3の方向性もよくわからん。悲観主義的な話を唱えているのではなくて、クリアなビジョンも難しいと思う。ダウンロード数を見りゃわかるでしょう。
    • A: コア開発者と話をすると、10年かかるかもしれないが対した事はないさ、と話題になっている。参加して、発言して行くことが必要。コア開発者は数値をあまり気にしていない。言語の改善を考えている。その対立が分断を引き起こしている。私が理想的な状況とは、みんなが2.7を使い、3は忘れるってのがいいと思う。ただ、公式な意見は確立されて行く必要はあるよね。
    • 私は3を嫌いになってもいいと思う。
    • Q: 2と3で違う見方なのだが、1年前に3が選択肢となる話が出始めて、ここ最近互換性が問題になってきた。Ubuntu, Debianが3がデフォルトになって増えたっぽい。2から3に必要なものをポーティングすりゃいい気がするけど。
    • A: それでいいと思う。
    • Q: RubyとPythonの比較
    • A: Rubyの場合は1.8→1.9の変化は急だった。RubyとPythonはだいぶ違っていて、Pythonはこれまでstableで後方互換を保つようにしていて、安定していた。この歴史が、科学的な背景があった。Rubyの変化はとても早い、ポイントリリースも違う、パッチりリースでも違う、でもそう言うのに慣れているから大きな変化にも慣れている。それがRubyの文化。でも、Pythonではそんな変化にあまり対応できない。Rubyは変化を楽しんでいるのはいいし、Python 2,3でもそれができればいいなと思う。僕らも慣れて行く事も必要だと考えている。

Programming the Performance Co-Pilot toolkit

  • Nathan Scottさん
    • RedHatのなかのひと
  • 感想
    • PCP知らなくて不勉強だったことを反省する。
    • Pythonで拡張できるのはなかなか良い。
    • そしてリモートホストからのデータも取得できる点も非常にいい。
    • 検証時のメトリクス取得にもってこいと思われる。
  • 今日のお話
  • PCPとは
    • オープンソースの ツール集
    • システムアナリシス
    • ライブで履歴をとれる
    • 拡張性が高い
    • 分散できる
  • アーキテクチャ
    • pmlogger
      • 各種ミドルウェア、カーネルから拾ってくる。
    • pmchart
      • ビジュアライズ
    • pmie
      • インタフェース、こねくり回す時にはこいつを使う。
  • メトリック
    • pminfo コマンド
      • データ拾う時に使う
      • Sensuメトリックを拾う時の名前ににてるっぽいな
    • Collector extentions in Python
      • 目標: new dmcache metrics
      • dmcacheの推移がわかってキャッシュあたりの追跡をするのによさそう
      • かなり密な単位でとれるっぽいな 1秒単位がある
    • git clone git.pcp.io/pcp からどうぞ。
    • プログラミングガイドブックもあります
    • pmchartはJavaっぽい
  • 質問した
    • Q: リモートシステムからデータは取れるの?
    • A: できます。Ciscoのルーターとかのデータを、TCP/IP経由でとれます。
    • 英語の質問緊張した

Gunicorn, the thundering herd and other concurrency programming challenges

  • Benoit Chesneauさん
    • gunicorn開発者
  • 感想
    • gunicorn開発者本人から話が聞ける事が貴重。
    • 英語で後で話に行けないの、いろいろ損している気がしている。
  • gunicorn = じゅにこーん
  • デザイン
    • prefork-workerモデル
    • ソケット共有 (spawn-share sockets)
  • ソケット共有
    • arbiterがworkerにspawnする、よくある話。Unicornと変わらん。
    • copmetiton to accept (競合管理)
      • バックログに溜め込む
      • 同期ワーカーは1接続まで
      • 非同期ワーカーはいくつものコネクションを支えられる
    • ワークフロー
  • なんでいろいろなワーカーが?
    • 同時接続の戦略
    • 違うプラットフォームのサポート
    • WSGI以外にハンドルしてほしい
    • いろいろ
  • The thundering herd problem
    • 重たい処理が引っかかると全ての処理が引っかかってしまう
    • 対策
      • 792 参照
      • パイプを通じてシグナルをやり取り Workerプロセスの状態を聞いてまわっている模様
      • arbiterがソケットの読み込みが可能かチェック
  • One command to rule them all
    • gunicorn_ほげほげ とか書かなくていいよ!
    • プリロード問題は直しました
    • ?paste, ?pythonpath, ?env をサポートしました
    • 20個の引数です (非推奨は勘定していない)
  • Enhance the user experience
    • 837 参照
    • plugin everywhere: logging, workers
    • more embeddable: the gunicorn engine
    • https://github.com/gunicorn/ に移ります
    • 2014/12までにやります!!!

Data collection, analysis and optimization with python

  • Shinji Iwakiさん
    • @shinji071
    • 構造計画エンジニアリング
    • Python歴 1.5年
  • 感想
    • iPythonのデモンストレーションとして見ていても非常に興味深かった。
    • Pythonが書けるなら、無理にRでデータ分析に取り組まずとも、データ分析に取り組める事がわかった。
  • 膨大なデータの計算どうすっぺ
    • まず、全体の構造及びライブラリ構成を紹介。
    • 最適化
  • データ収集
    • HTMLをかき集める
    • BeautifulSoup4で解析(スクレイピング)
      • 時間・タイトル・出演者をとる (価格.comのテレビ番組欄)
      • 出演者の出演頻度を出してみる
  • データ分析
    • pandas
    • skleam
    • そしてビジュアライズwww
    • k-means法による出演者のクラスタリング
  • 最適化
    • pulp
      • LP modeler
      • 線形計画法を解くライブラリ いろいろあるんですなー
      • ナップサック問題を解くとか
  • 質問
    • Q: GAのライブラリって?
    • A: scipyとか、でもあんまつかってないな。

Effective numerical computation in Numpy and Scipy

  • Kimikazu Katoさん
    • Egg technology に勤務
    • CSのPh.D
    • Python暦 2年未満
    • 科学計算歴は10年以上っぽい
  • 感想
    • 行列圧縮を自力で実装していた事があるが、もうそんな事をしなくて良いのは助かる。
    • 自然言語処理の研究を手伝っている時に、これがあればどれだけ楽だったかと想いを馳せた。
    • 講演中、もっと抑揚がある話し方があると注意を引きやすくて良かったのではないか。
    • 1つ後のセッションと入れ替えた方が、より理解が深まったのではと考えた。
  • 流れ
    • NumMyについて
      • 展開
      • インデクシング
    • スパース行列
    • ケーススタディ
  • 数値計算をなぜPythonで?
    • プロダクティビティの高さ: 書きやすい・デバッグあすい
    • ビジュアライズしやすい
    • Webシステムとつなぎ込みやすい
  • だけど、Pythonは遅い!
    • CとPythonでは80倍違う計算があった
    • だけど、numpyを使うと…Cに近いくらい速度が出た!
    • まあ、PythonからCに書き換えるってのは大変だしな、こう言うのがあるならいいね。
  • パフォーマンスの肝
    • forなどのループを減らす
    • 良いライブラリがあれば使おうぜ
    • メモリコピーのコストとか、忘れてません?(確かにヤバい)
  • スパース行列
    • 行列の圧縮のメリット→メモリ空間の削減、計算量の削減。
    • 3つのメソッド→[lil,scr,csc]_matrix
    • ある計算において 1000×1000 のsparse matrix でlil は11.7 sec, cse 0.06 sec
    • ただ、性質を熟知している場合は、自力で書いた方が早い 場合 もある。

Introduction to scientific programming in python

  • Olivier Hervieuさん
  • 感想
    • 科学計算ライブラリのサーベイ発表だった。
    • matplotlibがあればRを使わなくてもビジュアライズできるなと改めて理解した。
    • 今の本業で使う事はないが、以前は必要だったし、今後また必要になるかもしれないので、改めて動向は見ておこうと思った。
  • もうあんたらは科学計算プログラマだよ!こんなにセッションあるしw
  • 今日の話
    • 科学計算プログラマ必携のライブラリ・ツールを紹介するよ!
    • 製品化のための注意点を話すよ
  • iPython
    • Must Use だってさ〜
    • インタラクティブシェル
    • ブラウザベースで実行可能 いろいろサポートしてる
    • 簡単に使えて並列計算機でも高いパフォーマンスが出せる
    • Data collection, analysis and optimization with pythonでも使ってた
    • コメントはHTML, LaTeX, Markdown等等に保存できる
    • notebookのエクスポートも簡単
  • NumPy
    • (Effective numerical computation in Numpy and Scipyでも紹介されたもの)
    • 多次元オブジェクトをこねくり回せる
      • 行列計算のアルゴリズムを実装する手間が省けていいですね
    • フロントエンドはnotebookという
    • 線形アルゴリズムに最適化
    • ただしメモリを食う
    • Julia benchmarkの結果なんて信じちゃダメだ!!!(本当かはわからん)
      • numpy使っているか否かは言及してなかった
  • SciPy
    • 科学計算ライブラリ (名前の通りですね)
  • matplotlib
    • 2D, 3Dのハイクオリティプロッター
    • MATLABっぽくいける
      • 実際でもを見ると本当にそれっぽい
    • Introduction to Numpy and Matplotlib ってビデオを見るといいよ!4時間あるけど。
  • scikits
    • 機械学習
  • pandas
    • データ操作ライブラリ グルーピング、マージ、そしてインデクシング。
  • 注意点
    • numpy, scipy, scikit-lean をつなげて行くと、 Fortranレベルでいけるっぽい。
    • 再コンパイルは長い。(辛い)
    • パフォーマンス重視: numba, cython
    • DSL: sympy, nltk
    • bindings: rpy2
    • storage: pytables
    • 無料で利用できる
      • なんかあったら直そう、直します。

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

  • @tell-k さん
  • 感想
    • コーディング基準を守るんでなくて、コーディング基準に沿ったコードを自動的に生成する時代となった。
    • そして僕の前に狂戦士がやってきて殺される。
    • 心を入れ替えて.vimrcをアップデートします。
    • ごめんなさいごめんなさい。
    • 一方で、コードの見通しやコメントの良さはこれらではカバーできない事でもあるので、引き続き広い視野を持ってコードを書くのを忘れないようにしたい。
  • リファクタリングそのものの話はしない!
  • リファクタリング ツール の話をします。
    • vim中心に説明します!
  • pep8, pep257
    • 文法チェック
  • pyflakes
    • 文法エラー
  • flake8
    • pep8, pyflakes
    • pep257対応のために flake8-docstring を突っ込む
  • gofmtの代わり
    • autopep8
    • autoflake
  • 支援/リファクタリング
    • jedi
  • 特にリファクタリング
    • Rope
      • IDEに見劣りしない編集ができるようになる
  • Code Climate
    • 自動でレビューしてくれるサービス
    • ただRuby, PHPのみで、Pythonは使えない。
  • Radon
    • 2つの指標で評価
      • Cyclomatic Complexity: 循環的複雑度 6段階で評価
      • Maintainability Index: 保守容易性

Python を支える技術: ディスクリプタ編

  • Nozomu Kanekoさん
    • @knzm2011
    • 公式ドキュメント 翻訳担当者
  • 感想
    • いろいろはまった時に、この事を思い出すとコーディングでつまづかないのではと考えた。
    • ただ、自分自身で改めて人に説明できるほど深く理解できたとは思っていない。
  • はい
    • シリーズ物ってことではありません。
    • ドキュメント、ソースを読めば一通り書いてある。
    • Python 構文解説にディスクリプタの事が書いてあるwww かぶった。
    • 公式ドキュメント 翻訳担当者 大募集中!
  • 分類
    • データディスクリプタ
    • 非データディスクリプタ
    • 読み取り専用のデータディスクリプタ
  • 分類は属性アクセスの優先順位に影響してくる
  • プロパティはディスクリプタの一種
  • インスタンスメソッドの読み出しは、ディスクリプタによって単なる関数呼び出しに変換される。だから、第1引数にselfがある。
LINEで送る
Pocket

広げる話・収束させる話を使い分けて会話を楽しみたい!

LINEで送る
Pocket

人間、生きていると誰かと話をするものです。そんな中で日々思った事をまとめます。

今回は、広げる話と収束させる話、場に応じて切り替えると良いと思うし、特に仕事でもない時は収束させる話に持って行って結論を急がなくてもいいんでないの?というお話です。

広げる話と収束させる話

話を始める前に、この記事の中で使う言葉の定義をします。

まず「広げる話」とは、会話の場に登場した話題を発散させる方向の会話の進め方とします。例えば、アフタヌーンティを楽しみながらあーだよね、こうだよねと話を会話を通じて時間を過ごす事を楽しむ状況を想像して下さい。また、会話に参加している人同士で人となりを知り、そして快楽を得る事ができます。

続いて「収束させる話」とは、会話の場に登場した話題を収束させる方向の会話の進め方とします。例えば、仕事中に催される会議において、決まった時間の中で結論を導き結果を出す状況を想像して下さい。また、会話に参加している人同士で問題解決を行い、各自の使命をより明確にする事ができます。

仕事じゃないのに話を収束させてしまうのはつまらない

IMG_6084

ふとした会話なのに、話を収束させられてしまう事があります。言い換えれば「確かにあんたが言う事は正しいよ、でもその話がしたいんじゃないんだ僕は!」って状況です。これは、直接の会話ばかりでなく、 Facebook などのテキストベースの会話でも起きています。

「〇〇だから××、故に△△。」全くその通り。わかる。でも、それ以上続かなくないですかね。また、否定しちゃうともそこで終了です。例えば、「ベトナムはいい所だ、飯もうまいし旅費も安くてさ〜」と切り出したときに、「いや、私はいやだった。航空会社は〇〇航空に比べてサービスが悪く、現地は感染症も日本に比べて多い。」としたらどうでしょうか。もちろん論理的に反論する事はできると思います。しかし、ここではどちらかに結論を収束させるのが目的ではないので、僕がこの話題を切り出したならその会話は打ち切り、別の話題を出します。

僕が求めているのは、「ベトナムはいい所だ、飯もうまいし旅費も安くてさ〜」と切り出されたときに、「おお、フォーってのがあるらしいけど、あれはうまいのか?」や「そりゃいい、俺も行きたい!」と、話が広がるよう更に盛り上がるように掘り下げることです。さらに、近い経験をしたなら「実は俺も行った事があって、××ってのがよかったぜい。」とより話を豊かにしたり、論理的に「ベトナムは日本よりコーヒーが△割安くて良かったよ!」と話しつつ相手がより理解しやすい形になっていたら、更に楽しいなと思うのです。

その中で、会話の相手がどのような体験をして、価値観を持って生きている事を知り、そして楽しい時間を過ごせたら最高だなと考えています。

ちなみに僕の中で例外がありまして、その一つが思考実験です。例えば「情報教育において指導する先生が不足しているが、それを解決するにはどんな手だてがあるか?」という話題が当てはまります。これは、論理的に展開しつつ結論に向かって会話する事を楽しみにやります。とはいえ、人となりを知り、快楽を得る点は変わりません。

仕事なのにだらだら会議も良くない

逆に、仕事中にダラダラ会議をしてしまう人がいます。これは、話を収束させるために論理的に物事を整理する事が足りていないのが一因ではと考えています。

時々、論理は相手を攻撃するための道具だと誤解されている事があるようです。僕は、論理は会話する相手に対して再現性を持って伝えるために必要だと考えていて、攻撃に使うものではありません。また、人は一人一人違う事を考えていますから、自分が何を考えていてどうしたいと伝えるためには、感情だけでは理解されるものでもありません。

会議はコミュニケーションを楽しむ場ではなくて、集団で物事を推進するにあたって意識をあわせて次の段階に進むために必要な工程だと、僕は理解しています。その中で、漫然と話を広げて会話をするのはあまり賛成できません。とっととコード書くなり、企画を熟成させるほうに力を注ぐほうが生産的です。

尚、効率の良い会議の手法自体は様々な所で語られており、ここでは述べません。

やばかった自分の20代

実は、平時の会話を収束させてしまう状況は、20代の自分によくありました。どうしてかなと、今振り返りますと次の点があったのだなと思います。

  1. コンプレックスが強かった
  2. 会話には勝敗があると思っていた
  3. 日々を楽しむ視点がかけていた

1は、その頃は高卒でして、大卒相手に仕事をする際に絶対に負けたくない!という気持ちが強すぎたのでしょう。だから、会話中に負けないように「私はあなたよりも〇〇を良く知っている(という趣旨の話)」や「いやそれは違う」などと言ってしまいがちでした。ちなみに、大学院を出たときに、これはなくなりました。

2は、1にも続いてやってしまっていました。だから、相手が腹立ったからこいつの鼻っ柱をへし折ってやろう!となったときに、逆に悔しい思いをして会話を終えてしまった事もありました。

3は、仕事ばかりの事を考え、そして休み無く仕事をしていたせいか、一緒にいる人と楽しく時間を過ごそうという視点に欠けていました。これでは、少しでも僕の事を面白い人だな!と感じてもらえたとしても、その後にテンションをダダ下がりにさせてしまっていたかもしれません。

あと、こうしていると、なぜか疲れてしまうんです。気を張っているし、楽しんでいないからなのでしょう。勝ち負けだけで物事を捉えてしまうと、辛いだけですね。

そんなこんなで、仕事こそちゃんとやっていたつもりですが、私生活ではあんまよい感じじゃなかったなー、と33歳になって振り返っております。まだ、残ってたら指摘してやって下さい。

平時は会話を楽しもうぜ

IMG_9683

では自分が広げる話と収束させる話を意図して切り替えるようになったのは、昨日今日ではありません。よく行くバーで飲みながら他のお客さんと話したり、普段とは違う領域・組織の人と付き合う中で、徐々に醸造されたものです。

そうしていると、特に私生活では自然と疲れづらくなった気がします。というのも、悪い人じゃないんだけれど無理に付き合う事も無いかなー的な人と、話してて楽しいし自分が気持ちよく付き合える人が自然と見えてきて、やりやすくなりました。

あと、僕の場合だけかもしれませんが、気持ちよく付き合える人と仕事をすると、不思議とうまく結果が出せるように感じます。単に恵まれているだけかもしれませんが、その率が上がっているのは僕にとってとても有益です。そして、相手にとっても有益であって欲しいと願います。

なお、改めて申し上げますが、どの場面においても論理的思考・説明を否定するものではありません。広げる話の場合と、収束させる場合で、使い方を変えるといいんでないの?と言いたいのです。

ということで、広げる話と収束させる話を使い分けて、特に仕事以外の平時では広げる話を通じて交流を深めるのが楽しくてよくね?というお話でした。

LINEで送る
Pocket

YAPC::Asia 2014 に参加してトークして飲み切ったら夏が終わった #yapcasia

LINEで送る
Pocket

YAPC::Asia Tokyo 2014に参加された皆さん、お楽しみ様でした!僕は今回初参加、そして初トークでした。まるで、お祭りで神輿を担がせてもらえているような感覚がありました。2日経った今でも、思い起こすとその興奮が蘇ってくるようです。

当日のノートは「1日目」「2日目」それぞれに記録しています。僕のセッション中のTweetは「YAPC::Asia Tokyo 2014 Day 2 「突然ITインフラを任された人のための…監視設計入門」 ツイートまとめ #yapcasia – Togetterまとめ」にまとめました。また、技術評論社さんのサイトでも「YAPC::Asia 2014 スペシャルレポート:レポート|gihyo.jp」としてまとめられています。あわせてご覧ください。

ブログを書くまでがYAPC。ということで、「トークへの質疑応答」「トークの感想」そして「全般の感想」をまとめておこうと思います。

トークへの質疑応答

突然ITインフラを任された人のための…監視設計入門」と題してお話しさせていただきました。2日目の朝イチというのに、満員御礼でございました。お越し頂いた皆様、ありがとうございました!

このエントリーをはてなブックマークに追加

2014-09-29追記: ビデオがアップされました。スライドとともにご覧ください。YAPC::Asiaビデオ担当の方、ありがとうございました!

せっかくですので、会場, Twitter, そしてはてなブックマークで頂いた質問に対して回答をまとめます。漏れていたり、追加で質問がある方は、Twitterにて @koemu までお願いします。

  • 質問0: スライドを埋め込みたい
  • 回答0: 次のコードを書いて下さい – <iframe src="http://www.koemu.com/etc/yapcasia2014/" style="width: 480px; height: 320px;"></iframe>
  • 質問1: NTPの監視項目はどうしているの?
  • 回答1: ntpdのプロセス監視、及び親となっているNTPサーバとの時差が1秒以内かを監視しました。
  • 質問2: 監視サーバの監視はどうするの?
  • 回答2: 例えば、監視サービス(New Relic)に監視サーバを監視させる方法はどうでしょうか。
  • 質問3: Heroku等のPaaSの監視はどうするの?
  • 回答3: 多くのPaaSではサーバに監視プラグインが入れられません。従って、自分で監視サーバ用のプラグインを書くか、探す必要があります。
  • 質問7: ラズパイが監視サーバなの面白いですね!
  • 回答7: 本番はダメだよん!わかってると思うけどw
  • 質問8: ハートビーツで働きたい
  • 回答8: ハートビーツのサイトからご連絡下さい!
  • 質問9: iPhoneのリモコンは何を使ってる?
  • 回答9: Mobile Mouse です。

逆に、こちらから質問した点について、書き残しておきます。割合は、僕の感覚値です。

  • 質問A: 昨日 懇親会へ行った
  • 回答A: YES: 2割
  • 質問B: どうしてこのセッションに来たの?
  • 回答B: 会社の先輩に勧められた、監視をやらなくてはならなくなった、監視のしかたをさらに学びたい、など。
  • 質問C: 業務での主な役割は? (複数回答可)
  • 回答C: 企画:3割・開発:ほぼ全員・運用:6割・制作: 1割・それ以外: わずか
  • 質問D: サーバの監視に携わっている
  • 回答D: YES: 6割
  • 質問F: AWS CLIツールを使った事がある
  • 回答F: YES: 3割
  • 質問G: 「非機能要求」という意味を知っている
  • 回答G: YES: 3割
  • 質問H: (講演の最後) これで明日から監視できそう?
  • 回答H: YES: 1割

トークの感想

いやー、楽しかったです。でも、当日を迎えるまでは正直不安でした。1ヶ月ほど準備期間があるものの、検証や読み直しを繰り返しているとあっという間に当日です。正直、しゃべり始める直前まで緊張していました。

開始前に漫談コーナーをやったのですが、あれはいつか自分が講演をするときにやってみたかった事だったのです。数社前に勤めていた会社の社長が、講演前に30分前からお得なお話をよくしていて、あーこうやって場をあっためるんだなという記憶があったのです。やってみたら、期待通り場があったまって、本当に良かった。それに、思いがけず @yusukebe も入ってきてくれて、僕も良かったです!

また、講演中に質問したり、直接質問するのは、以前お世話になった板倉 雄一郎さんの講演のやり方を参考にしています。これで、一方通行になりがちな所を、少しでもインタラクティブにやって、皆さんと楽しい時間が過ごせれば良いなという願いを持ってやっていました。皆様はいかがでしたか?

ただ、「これで監視できそうですか?」という質問に、1割程度しか手が挙がらなかったときには、膝かっくん並みの衝撃を味わいました…。精神的な「不安」だけならとてもよくわかります。ただ、技術面でよくわからなかった所があるとすると、これは困りました。どのへんがわからなかったか、ぜひTwitterでMentionしていただけると嬉しいです。

そうそう、勤務先のハートビーツでは、対外発表や執筆が自由にできる社風があります。ITインフラやそれに関する開発に興味があって、発表をやってみたい人、当社はいかがでしょうか?尚、勤務先では対外発表前には上司である @netmarkjp さんに必ずレビューしてもらうルールがあります。この際、主に「誰かを傷付けていないか」と「明らかな誤り」のチェックが入ります。特に前者は気づかずにやってしまうこともあります。ですから、信頼の置ける人のレビューは重要だと思います。

全般の感想

今回の実行委員長は @yusukebe 、そしてコアスタッフの一人には @uzulla さんがいました。そう、彼ら二人は「Webアプリエンジニア養成読本」の共著メンバーです。ようやく自由に勉強会やカンファレンスに出入りできる会社に来れたし、共著仲間が活躍しているこの場ならめっちゃ面白いはずだ!と勇んで足を運びました。

実際、本当に楽しい場でした。ソフトウェアエンジニアの祭典と言って良いと思います。運営自体も滞り無く進み、かつおいしいコーヒーやDMMかき氷をいただきながらイベントを楽しむ事ができました。セッションもどれも聞きたいものばかり。ネットワークが安定していた事は、講演中にトラブルが起きる事も無いだろうと信じられるほど、心強いものでした。懇親会の会場やHUBで飲んだお酒と楽しいトーク、忘れる事ができません。

ただ、だからこそ目立ったことがあります。キャパオーバーです。もし可能であれば、多目的会議室2・3は机をどけて、電源タップを配った上でイスだけにしてしまう事ができたらどうだろう、と思いました。自分が聞いている時は体育座り状態でしたし、講演をしている時も色々心苦しいところがありました。とはいえ、これ以上大きな会場ってデブサミをやっている目黒雅叙園とかそういうところですものね…

とはいえ、のべ1,000人以上のイベントをこれほど滞り無く進行できているマネジメントは、本当に凄いと思います。僕は100人程度までのイベントの実行委員長の経験しか無いのですが、それでもしんどい思いをしました。この規模を回せるスタッフの皆さんを本当に尊敬します。

夏が終わった

ここまで、「トークへの質疑応答」「トークの感想」そして「全般の感想」を書いてきました。 yusukebe の言葉を借りますと「夏が終わった」、そんな気持ちです。

そして、帰宅した時にあったこのメッセージ。

私事で、すいません(相方は2日目午前の2つの講演を聴きに行っていました)。

最高の夏の終わりとなりました!

会場にいらした全ての皆様、お楽しみ様でした!またお会いできる日を楽しみにしています。

Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus)
和田 裕介 石田 絢一 (uzulla) すがわら まさのり 斎藤 祐一郎
技術評論社
売り上げランキング: 376
LINEで送る
Pocket

YAPC::Asia 2014 2日目の感想とノート #yapcasia

LINEで送る
Pocket

YAPC::Asia 2014、大変な盛り上がりの中で終了しました。スタッフの皆さん、お会いできた皆さん、そして講演を聴きにきてくださった方、どうもありがとうございました!

とはいえ、まだ気持ちが落ち着いていないな、というのが正直な所です。ほとぼりを冷まして、改めて振り返る時間を作りたいなと思っています。

その前に、記憶が消えないうちにまとめたいノート、今回もアップしておきます。

突然ITインフラを任された人のための…監視設計入門

半端なPHPDisでPHPerに陰で笑われないためのPerl Monger向け最新PHP事情(5.6対応)

  • uzulla さん

  • 感想
    • うずらさん全部持って行った!
    • 技術の内容で笑いを取るの、やっぱり高度な事だと思う。
    • ベストトーク賞 1位 おめでとう!!!

昼飯

  • 相方とぷぷくさんとHUBでカレーを食べた
  • うずらさんのセッションの説明をしていた
  • エンジニアを夫に持つ非エンジニアの妻対談を聞いてた
  • カメラのレンズの稟議がより厳しくなった

地域.pmミートアップ 2014

  • 感想
    • 1人じゃない!ってのは大切だなと思った
    • 各地の地域.pmに遊びに行って地酒飲みたい

モバイルアプリとAPIのありかたを考える2014

  • あらたまさん
    • OpenAPI, Proxyなど
    • アプリも作ってるよ
  • 感想
    • JSON RPCによるバッチ通信は積極的に使いたい
    • 早いのは感覚で凄く良くわかった
    • できれば数値で比較してもらえるとより良かったと思う
  • あるある
    • 通信時のブロッキング: ウザイ
    • たどたどしいサーバプログラム: 遅くて辛い
  • MBaaS
    • 知れ渡っているけどあまり使われていない感
    • 今回はParseを取り上げる
    • MBaaS + PaaS
      • Herokuっぽい
      • Heliosってどうなった?
    • アプリ開発に集中できる
    • データ同期が容易
    • DBはスキーマレス
  • Dropbox Datastore API

  • JSON-RPC 2.0
    • POSTのみ
    • URIは1つ(渡すデータで挙動を定義)
    • とりあえずたくさん送りつける際に、いい感じ。
    • 複数処理を組み立てやすい…バッチ処理しやすい
    • ひいては通信コスト(オーバーヘッド)を下げられる
      • ユーザを待たせない!
    • 言語の実装状況
      • Batchに対応しているものが思ったほどないらしい
  • まとめ
    • システム都合でブロックしない バッチ処理で
    • ユーザのための理想に近づきつつある現実

Changing the tires on a moving car: a case study in upgrading legacy architecture

  • Andyさん

  • 感想
    • 規模に応じてどのように泥臭く取り組むのか一つの事例として参考になった。
    • スケーラビリティを出す仕組みの選定はどこも苦しんでいるのを知って、自分が苦しんでいるのも不思議な事ではないのを理解した。
    • かなり密にパフォーマンス測定をやっていて、エビデンスベースで進める大切さを再確認した。
  • git
    • でかいオブジェクトのセットの中にある
  • リポジトリサーバ
    • リポジトリ1個なら楽勝
    • GitHubの規模の数値やばい
      • ファイルサーバ 27台
      • シンプルにはできない状況
    • 答えはいつも変化している
  • Grit
    • 2007年にできた。GitHubに近い。
  • GFS
    • スケーラビリティが出なかった
    • Smoke
      • Gritをオンラインでできるようにした
      • ただあまりうまくいかんやった
  • Gitの歴史
    • LinuxカーネルはBitkeeperで当初はバージョン管理されていた (OSSではない)
    • Shared Library ではない、エラーハンドリング、メモリ管理もやばかった。
    • JGit は…厳しい感じ
    • libgit2…Visual Studioなどで使える
    • Rugged
    • Git-Raw (Perl)
  • Plaggable wire protocol

  • Gitは何がstupidなの?
    • エンコーディングは気にしない(中身の種類に関知していない)
    • Smokeも同様
    • 日本語の自動認識はがんばって改善しています!日本企業スマン。
  • 一気に更改はできないけどいじらないといけない
    • Graphite を使って全コール記録(回数・所要時間)
      • パフォーマンスを確認
    • Recap
      • 同時に新旧のシステムを動かす(一度に入れ替えなくても良くする)
      • 仮説を立てて取り組んだ

Mobile Application Development for Perl Mongers ninjinkun x gfx

  • ninjinkun さん
    • Fablic (Fril) – 女性専用アプリ開発
  • __gfx__ さん
    • Cookpad
    • モバイルアプリのためのライブラリ開発・環境構築
    • 大人数・多くの会社での開発の生産性向上をどうするか考えている
  • 感想
    • デバイス毎、特にAndroidの移動機のテストはどうやっているのか気になった。(HUBで聞くんだった)
    • ユーザビリティテスト、感覚の言葉を論理的に整理する流れをより詳しく知りたくなった。
    • 自分がゲーム開発をやっている時はデバッガさんがテスト項目で表現しきれないパターンのテストもしていたけど、他の会社ではどうしているのかもう少し知りたい。
  • Client-Frontend Engineering (ninjinkun)
    • UIデザイン
      • UIはエンジニアが実装する
      • エンジニアがデザインに関わる
      • ペーパープロトタイピング
        • 合宿やりました!
      • モックを作ったらテスト
        • 開発は男が多いが使うのは女性
        • 女性スタッフから使ってもらって意見を聞く
        • 組織として重要視している
      • 難しい
        • 状態の同期 (例:ページの間)
    • フロントエンド技術
    • オープンソース
      • COCOAPODS
      • Magical Record
      • Active Android
      • Android Query
      • Android Bootstrap
      • Androidなら、Google Playにデモをあげてしまおう!
  • Client-Backend Engineering (gfx)
    • コミュニケーションコスト
      • 機能別で部署ができている
        • それをマージしないと行けない
        • 仕事が殺到 精神衛生上も良くない
      • 各チーム内である程度開発してもらう
        • アプリファースとチームは中枢の開発やリリースマネジメントに集中できる
      • 我々の冒険は始まったばかりだ!
    • リリースサイクル
      • Androidアプリはリニューアルした
        • やばいバグがあった
        • ロールバックできないので死ぬ
      • アプリの頻繁なリリースはユーザをいらだたせる
        • Webアプリのように随時とは行かない
        • 頒布方法が違う
      • 開発方法を変える
      • Branching Model
        • マスタブランチにマージ=いつでもリリースされる訳ではない
        • git-flowベースで、フリーズをするというプロセスを取る
      • PR Based 開発
      • KISS
    • サーバサイド開発との差異(CI)
      • UIのテストをどうするの?
        • 若干ツールを使っているけどTDDにはならない
      • リリース作業
        • 複雑怪奇: プラットフォームへのアップデートが手動
        • リードタイム 1〜2週間
      • クラッシュモニタリング
      • ビルドスクリプト
  • エンジニアは問題がないと生きて行けない Good Problem がある会社に

  • Talk Show
    • CI基盤はTravis(Fablic)
    • カバレッジ取ってる?とってないねー
      • OSのバージョン
      • カバレッジ有効にすると落ちる(Googleの人は使ってるの?)
    • Perlから移ったけどどうよ
      • フレームワーク
      • 成熟してないのかな?
      • AndroidはActivityがステートレスだけれどトランジッションがリッチ。これ合ってない気がする。
      • Androidの次のバージョンから改善される模様
      • アプリはステートフル
    • Perlコミュニティについて
      • モバイルアプリにもこの文化を持って行きたい!

そんなにビッグでもないデータ処理手法の話

  • tagomoris さん

  • 感想
    • データマイニングミドルウェアのサーベイ資料として凄く参考になった。
    • もりすさんの物事のモデリングスキル、いい意味で盗みたい。
    • 20分では惜しい。
    • 自分はJVMから10年前に逃げたけど、ここでまた対面する覚悟をそろそろ決める時期が来た。
    • ベストトーク賞 第2位おめでとうございます!
  • ログなどを何らかの処理にかけて分析しフィードバックする時の流れ
    • ストレージサイズ
    • スループット
    • 構造
    • 圧縮
  • データ量
    • 必ず上下する 正確には求めるな
    • 1回にどのくらい読んで吐き出すか
      • GB未満級: RDBでよくね?
      • GB〜TB級: これが問題
      • TB級: Hadoopで!専門家に任せよう (これがビッグデータ!)
  • GB〜TB級 (ビッグでもない)
    • うっかり取ってGB級
    • メモリに乗せるなら考えとこう
  • どうやって処理するの
    • 特性を見抜く
    • Hadoop
      • 全体のスループットを稼いでいる
    • Apache Spark
      • オンメモリ
      • 機械学習・グラフ処理
    • Apache Tez
      • Map Reduceを置き換える勢い
    • Stream Processing
      • Norikra !!!
  • JVMに支配されている!

  • ノウハウをどんどん共有して行こうぜ!注目している視点を明確にしてみよう。

  • DAG, RDD, MPP

LT

  • Perlハッカーズハブ、一緒に書きませんか?とのこと。
  • LTをどう進めると楽しめるか、参考にしながら聞いてた。

キーノート: エンジニアとして生きる

  • @typester さん
    • kamakura.pm
  • 感想
    • 話を聞きながら、僕の今置かれている状況は、実は自分自身で納得しているんじゃないかと考えたりした。
    • 仕事を請ける方式は、様々な技術に触れるチャンスと考えられる点、今の仕事を通じて痛感している。
    • 後半から前を向いて話してもらえるようになってよかった。
LINEで送る
Pocket