Team Geek を読んだ。

2013年に出た本ですが、今さら買って読みました。 読み物として読んだのであまりしっかり読んでいないですが、大事な話は1章に集約されている感じだったので、そこだけまとめようと思います。

ミッションステートメント

本書の目的は、プログラマがソフトウェア開発を効果的かつ効率的にするために、他人の理解・コミュニケーション・コラボレーションの能力を向上させることである。

というのがこの本の内容です。はじめに が来る前に書かれてあるのでそれぐらい重要な内容です。ここを理解してから本書を読み進めたほうがいいです。

全部で 6 章ありますが、進み方としては初めに自身の振る舞い良くする方法を提示し、2章でチームの文化を良くする方法、3章でチームリーダー、4章では害悪の人をなくす方法（人を排除するわけではない）、組織操作の方法、最後にユーザの扱い方を説明しています。

1章で説明されている HRT を基本としているので、他の章を読む前に 1 章を読むほうがいいでしょう。

天才プログラマの神話

世の中には、スゴいエンジニアがいるけど、その人たちのスゴさはエンジニアリングスキルではなく（もちろんそれ自体もスゴい）、チームをリードする力がスゴいという話。ソフトウェア開発は一人でするものではなく、チームで行うもの。チームスポーツなのだという。

世の中には、一人で隠れて開発したい人が多い。その人たちは自分の書いたコードやアイデアを人に見せるのが恐い。コードを見てバカにされないか、誰かにマネされて自分より先にプロダクトを世に出さないかが恐い。でも、公開されないソフトウェアは失敗する。相談する相手がいないので、過ちを犯しているのに気づかずに開発を進めているから。

早期発見

早い段階で、高速に、何度も失敗せよ

コードを書くときに全て書いてからコンパイルするだろうか？ 少し書いて、コンパイル。少し書いて、コンパイル。失敗を早く見つけることで早く修正できる。これをコードだけでなくプロジェクトでも行う。環境は唐突に変わる。それに合わせて設計、計画を変えないといけない。じゃあこの失敗を早く気づくにはどうすればいいか。チームで仕事をするといい（人の数だけ早く気づける！）。

バス係数を高める

バス係数とは、プロジェクト関係者がバスにひかれても、そのプロジェクトを続けられる係数のこと。値が高いほどプロジェクトを続けられる。

これは、チームの文化、人の採用を強化することで高めることが出来る。人の採用はただ闇雲に集めればいいわけではない。本書の 3 章を参照。

集中する時間

エンジニアが開発するには、集中する時間が必要。誰にも邪魔されずにコーディングに集中できる時間が必要。邪魔して欲しくないときのルールを作ると良い。ただし、それ以上にチームとの高速で高帯域な連携は重要（たぶん 2, 4 章あたりの話）。

HRT

• Humility（謙虚）
• Respect（尊敬）
• Trust（信頼）

人間関係の衝突は、この HRT の欠如によって起こる 。コミュニケーションの中心に HRT を心がけることが重要。

例えば、個人のエゴをなくす。自分の意見を押しつけない。集団のエゴを考える。それは、チームの功績や誇りなど。

例えば、批判をするときの言葉を選ぶ。相手のコードが間違っていると判断しても、相手に間違っていると言ってはいけない。提案をする。採用されないくてもいいような風に言うと良い。また、性格に対する攻撃的な非難をしてはいけない。コードはその人自身ではない。逆に批判を受けたときに非難されたと思わないこと。自分が書いたコードは、自分自身ではない。これをお互いに理解しておくことが大事。相手を尊敬していれば、非難しようと思わないはず。

信頼については、リーダーやユーザの話を参照（3 章、6 章）。

失敗から学ぶ。反復学習

過ちを犯したら文書化（ポストモーテム）する。文書化するときは、謝罪や言い訳を書かない。何を学んだか、何を変更するかを書く。見えやすいところに置いて、変更を継続できるようにする。
以下のことを書くと良い。

• 概要
• イベントのタイムライン
• イベントの根本原因
• 影響と損害の評価
• すぐに問題を解決するための行動一式
• 再発を防止するための行動一式
• 学習した教訓

文書化されることで、同じ過ちをする人をなくすことができる。歴史を繰り返してはいけない。

チームの文化

チームの文化を強化することで、外部からの悪い文化を排除することができる。その悪い文化は、主に新来者が持ってくる。文化はリーダーが作るのではなく、メンバーたちが作るもの。メンバーたちが持つことで、新来者へ継承できる（バス係数が高まる）。優れたチーム文化は、ソフトウェアを届けることに集中している。

効率的なエンジニアリング文化は、同期コミュニケーションを減らし、非同期コミュニケーションを増やす。会議（同期コミュニケーション）には、必要な人しか集めない。早く終わるように工夫する。決まったことは、メーリングリストで報告する。電話、ビデオ通話、チャット、メールなど（非同期コミュニケーション）を駆使する。あらゆるツール、あらゆる手法を使ってコミュニケーションを強化し、効率的に開発を行えるようにする。

ミッションステートメント

そのプロジェクトのミッションステートメントを決める。何をして、何をしないのか。これを決めないと永遠に肥大化する。また、ミッションステートメントは変化するときがある。会社の環境やプロダクトの方向転換があれば、ミッションステートメントもそれに合わせて変える必要がある。

おわり

この本、ページ数が少なく200ページにも満たないので軽い気持ちで読めました。何か役立てるために読むというより、読み物として読んでいましたが、楽しく、興味深い内容でした。ここにまとめたのは、1章、2章が主ですが、3～6章も大事なのでいつかまた読みたいです。とりあえず HRT を意識できるようにならないといけないかなと思ってここにまとめてみました。

とても上手に翻訳していただいた角 征典（かど まさのり）さんに感謝です。

今回からここに載せている元の文書を Github で管理するようにしてみました。 github.com

ブラウジング回りを整理した

雑記。 今まで Google Chrome を使っていたけど、 Firefox に変えて、ついでに情報収集のためのツールも整理した。

昔（スマフォ普及前）は、Firefox を使っていたけど、だんだん重くなって Chrome に移行した記憶がある。スマートフォンも持つようになってますます離れられなくなった。そのあとVivaldi が出てきて、ちょっと触って消して、入れて、消してと3回ぐらい繰り返して、去年ぐらいに会社で使う分には便利だったので使っていた。勤務先が変わったタイミングで使うのやめたけど。今は仕事では Firefox を使っている。一応 Web 系の仕事をするようになったので Firefox が適切かなと。Chrome は英訳用に入れている。英語スキルがあれば必要ないのだけど……。

Vivaldi も Chrome も Firefox もそれぞれに良いところがあって、これが最強とか決められない。他のブラウザは使ったことがないので知らない。Vivaldi はブックマークのアイコンのみ表示（Edge でも出来る！）とか、URL表示の切り替えやサイトのダウンロード状況表示などが魅力的なのだけど、スマフォで使えないのが痛い。ブックマークの共有が出来ない。この点で日常で使うのは無理だなと思った。

Chrome は特に不満はないけど、強いて言えば閉じたタブを復元するのにタブを右クリックしても最初は選択出来ないのが謎。自分の環境だけなんだろうか。タブの復元は Vivaldi が便利だった記憶。Firefox も特に問題ない。Chrome は、やっぱり Android ユーザとしては離れづらい。Android の Firefox は使いにくく感じる。上のタブの占有率が高いし、下にスワイプして更新が出来ない。Android では、まだ Chrome を使いそう。こうなるとブックマーク管理が面倒臭くなる。ブックマーク部分は独立して別アカウントで管理出来るようにならないだろうか。

Firefox に移行するついでにブックマークを整理した。フォルダに分けて、タグをつけてみた。今まで Qiita とか調べ物で見つけたちょっとしたテクニック的な記事はブックマークしていたけど、それは Pocket に移行しようかなと考えている（ブックマークしていると切りがないし、探すのに苦労する）。その点で Firefox は Pocket が標準で機能に入っているので良いなと思ったのだけど、Pocket のリストを表示 がPocket のマイリストをタブで開きに行くだけの機能で残念。Pocket にログインしておけばブックマークみたいに Firefox 上に表示されるのを期待していた。

あと RSS を使い始めた。Twitter する前はちょっと使っていたけど、最近まで使ってこなかった（サービスとしてほぼ終わっていると思っていた）。ニュース系のサイトを回るのだけど、自分が読みたいような記事が少ないサイトはだんだん見なくなっていた。あとは更新が少ないサイト（postd とか）も見るの忘れてしまったりで、情報収集としてこれはまずいなと感じていた。それを打開するために RSS が優れていると感じたので使ってみた。まだ２日しか経っていないけどなかなか良い。 Inoreader が特に良い。PC はブラウザで済むし、Android のアプリもある。日本語だし、GUIも気に入っている。ただジャンル分けしたいのだけど、そこら辺はまだ使い方がよく分かっていない。RSS はブラウジングとして強力なツールだと思った。

Slack を昔から使いこなしたいと思いつつ、全然使えていない。情報収集ツールとして便利そうなのだけど。今年使えるように検討中。

今までは、いろんなブラウザを使っているとブックマークがごちゃごちゃしていたのが、今回で落ち着いたので次からは気軽にブラウザを変更できるはず。Pocket はどうなるか……。

以上、雑記でした。

Google Cloud OnBoard In Osaka に行ってきた。

cloudplatformonline.com

GCP の無料トレーニングがあったので、行ってきました。 内容は入門的な内容で GCP 触ったことがない人にはぴったりな内容でした。 ただ、サーバの負荷分散に使われる技術（ツール）とかの用語がびゃびゃっと出てきて理解できないところが多々ありました。

内容は、

• GCP の概要
• 事例紹介
• GCP のサービス概要
• コンピューティング
• ストレージとデータベース
• 機械学習
• 今後の学習方法
  といった内容でした。

ここでは、ストレージとデータベース、機械学習、今後の学習方法の紹介はしません。
本人が理解しきれていないからです……

GCP の概要

まとめると

• Google は完全なサーバ管理不要な環境を作ろうとしている
• GCP は、Google が長年培ってきたインフラを提供している
• GCP のインフラは Google が提供しているサービス（Gmail や Gmaps）と同じ環境で動いているので、セキュリティも同じ。
• お金の計算は、自動で最安になるようになっている。
• GCP のネットワークは、Google のプライベートネットワークと同じなので高速。

事例紹介

• Abema TV は、GKE（Google Container Engine）, GCLB（GC Load Balancing） を使っている
• Spotify は、独自のインフラから GCP に移行。
• airbnb は Cloud Translation API を活用している。
  などなど

GCP のサービス概要

GCP には、大量のサービスがありますが、カテゴリに分けると6個になります。

• マネジメント - 権限やログ、リソースなどの管理ツール
• コンピューティング - インフラの提供。
• ネットワーキング - 負荷分散や VPC などを提供
• ストレージとデータベース - MySQL や NoSQL、ストレージの提供
• ビッグデータ - BigQuery, データ解析のサービスを提供
• 機械学習 - TensorFlow, 学習済みモデルの提供

GCP を利用するときは、3つのアクセス方法があります。

• Cloud Console - Web ブラウザ上で GCP にアクセスできる。人用
• Cloud SDK / Cloud Shell - PC に Cloud SDK を入れて使う。機械的作業用
• Cloud API - REST 形式の API インタフェース。プログラム用

ちなみにCloud Shell は、毎回インスタンスを立てているので、前回入れたものは消えるそうです。あと 5 GB まで使えるようです。

基本用語

まずは、クラウドサービスで基本となる用語だと思います。

• リージョン
  特定の地理的な位置。日本だと大阪や東京にリージョンがあります。
• ゾーン
  リージョンの中にさらに区分けしたロケーション。リージョンによって数は違いますが、大阪と東京にはそれぞれ3つのゾーンがあるようです。
  GCP はリージョンを超えてもプライベートネットワークを維持出来るそうです。
  リージョン間は海底ケーブルで繋がっているため、回線は速いそうです。
  以下は、GCP で使われる用語です。
• プロジェクト
  GCP のサービス（Compute Engine, BigQueryなど）やリソース（お金に関係する部分）の作成、管理（有効化や停止、削除）を行う。
  まとめると、プロジェクトの中に、リージョンがあり、その中にゾーンがあるイメージです。

また、リソースという用語の意味が理解しきれていないですが、たぶんお金に影響する部分のことだと思います。例えば、Compute Engine だと CPU, メモリ, ディスクであり、BigQuery だと ストレージや長期保存、クエリ（分析）のことだと思います。

サービスは基本的にゾーンごとに作成されますが、モノによっては、プロジェクト単位で作成されるサービスもあります（Cloud Load Balancing）。

管理

Cloud IAM というサービスによって、誰が、どんな役割を、どのサービスに持つかを設定できます。
このサービスは無料で使うことが出来ます。

cloud.google.com

コンピューティング

主なサービスは以下の4つです。

• Google Compute Engine (GCE)
• Google App Engine (GAE)
• Google Kubernetes Engine (GKE)
• Google Cloud Function (GCF)

GCE (Google Compute Engine)

cloud.google.com

以下、特徴です。

• VM 上で動く
• 自由度が高い（普段のサーバと変わらない）
• 低コスト、自動で継続利用割引が適用されます。
• メンテナンスでも自動で VM が移動し、再起動が不要（ライブマイグレーション）。
• ネットワーキング機能（Cloud Virtual Network: CVN）の結合

ストレージの SSD は二種類あり、ローカル SSD の方が速いですが可用性は下がります。もちろん普通の HDD もあります。
Cloud Virtual Network というサービスのおかげで、リージョンを跨いだ Virtual Private Cloud ネットワークが構築できます。内部 IP アドレスや、ファイアウォールを自由に設定出来るようです。

GAE (Google App Engine)

cloud.google.com

• インフラ部分が完全に抽象化
• アプリの使用状況に応じて課金
• バージョンが異なるアプリも簡単に共用できる

お金は、2 インスタンスからかかります。インスタンスの数は自動で変化するので、リクエストが全くないときは、インスタンスの数が 0 になります（お金がかからない）。サーバ管理は一切不要です。

GKE (Google Kubernetes Engine)

cloud.google.com

• コンテナオーケストレーションシステム
• GCE や CVN と連動して動作
• GKE 自体にお金はかからない（GCE や CVN にかかる）
• 管理する環境を提供（アプリのデプロイ、更新、管理が簡単。自動スケーリング、アップデート）

GCE をコンテナで動かし、管理するサービスです。Docker や Kubernetes を使って、コンテナ管理することが出来ます。

Google Cloud Function (GCF) Beta

cloud.google.com

• サーバレスアプリケーション
• コードが実行される時間に対してのみ、最も近い 100 ミリ秒単位で課金
• 複数のクラウドサービスを関連付けて拡張
• Firebase のようなサービスと統合できる

まとめ

コンピューティングの 4 つのサービスを紹介しました。それぞれ特徴が異なり、どういうときにどれを使ったらいいか迷ってしまいますが、発表者の方は以下のように分けるといいと話していました。

• GCE -> 現在、物理や仮想上で動いている既存のアプリの移動。
• GAE -> 新しく Web アプリサービスを作る場合におすすめ。
• GKE -> 社内のセキュリティ上 GAE が難しい場合、こちらを使う。

個人的には、Web アプリサービスを作りたい、サーバ管理したいような学生が使うと良いのではないかと思いました。登録一年は、$300 無料で使えるし、ちょっと試すぐらいならお金はかかりません。チュートリアルも丁寧で、何も知らなくても言われたとおりにするだけで動かすことが出来ます（もちろん理解した方がいいですが）。

ここでは、ストレージとデータベース、機械学習を紹介しませんでしたが、これらを使うことで作りたいサービスに必要な技術の壁をなくすことができます。ぜひ、GCP を使って遊んでみてはいかがでしょうか。

cloud.google.com

Python のパッケージ管理ツールの簡単なまとめ

最近寒すぎて歩くのがつらく、走って帰っています（これはこれでつらい）。
Python を始めてまだ1ヶ月か2ヶ月ほどですが、始めたときに？？？ってなったことをちまちまと整理していきます。

今回は、パッケージ管理ツールの回りをまとめたいと思います。
先に断っておくと、詳しい話は他の詳しい方に任せてます。自分と同じように Python 始めたけど専門用語が飛び交いすぎて訳が分からない！となっている人に向けて、道しるべになるような簡単な解説にとどめたいと思っています。

パッケージングツールとパッケージインストーラ

パッケージ管理ツールを大きく分けるとパッケージングツールとパッケージインストーラの二つになります。

• パッケージングツール
  自作したライブラリを外部へ配布する際に使用するツール。PyPI で配布されているパッケージは、全てパッケージングツールを使ってパッケージ化されたものです。ツールは複数あり、 wheel, setup.py sdist（コマンド）, setuptools, distutils, distribute などがこちらに当たります。現在は、wheel が普及しています。

• パッケージインストーラ
  PyPI などで公開されているパッケージをインストールするためのツール。一度は使ったことがあるかもしれません。pip, easy_install などがこちらに当たります。現在は pip が普及しています。easy_install は、setuptools のコマンドラインツールだそうです。

パッケージングツールは複数あります。現在使われているのは、 wheel ですが、そこまで行き着くのにややこしい問題があったようです。特にややこしいのは、setuptools と distribute です。setuptools が登場し（2011年？）、そのフォーク（派生のようなもの）が distribute です（2012年？）。一時期は distribute を使うべきでしたが、2013年に setuptools にマージされます（がっちゃんこ）。

Python 3.3 までは pip がスタンダードで入っていなかったので自分で入れる必要がありました。そのため、setuptools （easy_install）を使って pip を入れていた時期があったようです。3.4 では pip は標準で入っていますので、setuptools（easy_install） を触る必要はありません。

distutils は、標準のパッケージ管理ツール（パッケージングもインストールも可能）です。setuptools や pip はこれを拡張したものだそうです。

さて、整理しましょう。最新の Python（3.4 以上）であれば、インストールするものは wheel だけです。そしてパッケージをインストールする際は、pip を使いましょう。以上です。

パッケージの配布形式

wheel と egg です。
昔は egg が使われていましたが、この egg にはいろいろ使いにくいところがありました。それを解決するために現れたのが wheel です。現在では、wheel が一般的に使われています。wheel 形式でパッケージするには、同じ名前のパッケージングツール wheel を使います。

異端児 Anaconda

（実際に使ったことがありませんので、間違いがあるかも……）
さて、さっきまで pip と wheel だけを使えば問題ないよと書いてきました。しかし、この Anaconda というやつには conda という便利なツールが存在します。こいつは、パッケージの管理と 仮想環境管理とバージョン管理が出来るようです。つまり pip, pyenv, virualenv の代わりを一人で担っています。また、パッケージングも行えます。ただし、wheel との互換性はないようです。研究で使う分には問題ないですが、開発となると今後扱いづらいかもしれません。

おわりに

パッケージ管理ツールをまとめると、通常は pip, wheel を使えばいいですが、考えるのが面倒くさい、さっさとコードを書く必要があるという人は、Anaconda をインストールして conda を使うという感じでしょうか。または、Anaconda でも pip は使えるので、パッケージ管理やパッケージングは、pip, wheel を使う（それ以外の環境回りは conda を使う）というのがいいかもしれません。

以上、つたない内容でしたが理解の一助になれば幸いです。

参考資料

歴史的な詳しい解説があります。とても参考になりました。 ymotongpoo.hatenablog.com

Anaconda（conda）の使い方が解説されています。 qiita.com

ちょっと情報が古いですが、よくまとまっているので、かなり参考になります。
Python パッケージ管理技術まとめ (pip, setuptools, easy_install, etc)

Python 3.6 から MySQL データベースへ SSH 接続を試みる

仕事中は、いろいろ書きたい記事を思いつくのですが、いざ書こうとするとネタが思いつかないことがよくあります。
メモ代わりにここに書きますが、カテゴリとしては、Python, MySQL, グラフ描画, ウィンドウハンドルを使った自動化。みたいな感じです。忘れないうちに書かないと……。

そうそう、Google Home を買ったので、それを使って遊んだりもしたい。今は、Python, MySQL が優先なので、そちらを身につけつつその間に Google Home について調べておこうかなと。

無駄話はこれぐらいにして、本題に入ります。
前回は、ローカル（PC 内に入っているデータベース（DB）への接続）な環境の話でしたが、今回は、ネットワーク上の DB への接続を試してみます。

以下を参考にしました。

blog.honjala.net

環境の準備

まずは、今回使うモジュールを落としてきます。

pip install sshtunnel

ちなみにモジュールは、Github に公開されています。

github.com

これで SSH 接続するための環境は出来ました。 次は、実際にコードを書いて接続します。

SSH 接続を試みる

以下のコードを実行すると、SSH 接続するためのポート番号（何のポート番号かは分かっていません……）が出力されます。

# -*- coding: utf-8 -*-
from sshtunnel import SSHTunnelForwarder
import mysql.connector

port_num = 22
with SSHTunnelForwarder(
    ('ip_address', port_num),
    ssh_username='user_name',
    ssh_password='user_pass',
    remote_bind_address=('127.0.0.1', 3306)
) as server:

print(server.local_bind_port)

ip_address には、接続したい DB がある IP アドレスを。port_num には、SSH 接続のポート番号を（通常は、22）。remote_bind_address には、DB がある IP アドレスとポート番号を指定するのですが、通常は、SSH 接続先にあると思うので、上記で問題ないと思います。

上手くいけば、ポート番号が表示されていると思います。 問題なければ SSH 接続が成功しています。with を使わずに open(), close() のような方法もあります。以下のようにして、接続します。

port_num = 22
server SSHTunnelForwarder(
    ('ip_address', port_num),
    ssh_username='user_name',
    ssh_password='user_pass',
    remote_bind_address=('127.0.0.1', 3306)
)
server.start()

# 処理

server.stop()

start() が open() 。stop() が close() の役割をしています。 では、次に出力したポート番号を使って DB へ接続します。 ここでは、前回使用したモジュール（mysql.connector）を使って接続しています。

前回 pickles-ochazuke.hatenablog.com

conn = mysql.connector.connect(
    host = 'localhost',
    port = server.local_bind_port,
    user = 'user_name',
    password = 'user_pass',
    database = 'db_name',
)

前回とほぼ変わりません。port のところに先ほど出力したポート番号を使っています。

おわり

以上です。とても簡単にできたと思います。

今回の SSH 接続の部分とは関係ありませんが、クエリを実行して、結果を取得する際に単純に受け取るとリストになると思います。一応これでも扱えるのですが、pandas のデータフレームというのを使うともっと便利に扱えるようになります。そこら辺も近いうちに書きたいと思います。