社内ドキュメント共有ツールとして Slite.com がイチ推しだと思うこれだけの理由

Slack ? いいえ Slite です。

https://slite.com


Slite はいわゆるメモアプリ、ノートアプリ、ドキュメント共有ツール、ナレッジマネジメントサービスなどに区分される SaaS プロダクトです。2018年4月に $4.4M の資金調達を発表したことでも注目が集まりました *1

プロジェクトマネジメントツール同様 *2、数多のドキュメント共有ツールを試してきた経験を踏まえ、Slite を紹介したいと思ったというモチベーションで本エントリを投稿します(今回は比較表は書きません!)。

以下、Slite のすごい点を紹介していきます。

デザインコンセプトがすごい

Landing Page からして The 良い感じ風のプロダクトであることがひしひしと伝わってきます。ひしひしと。

f:id:iktakahiro:20180719021118p:plain:w800
https://slite.com/features より

Slite は "Slack を生産性向上に活用しているチーム" を重要なターゲットとして設定しているようです。認証も Slack に対応していますし、ドキュメント分類の最上位カテゴリに該当する区分けは Channel となっています。

左サイドの縦に Channel 一覧が並び、右サイドにエディタスペース、と一見チャットツールのようにも見えるレイアウトです。Slack と Slite を行き来するユーザーの視線をスムーズに誘導するかのような設計です(導線のくだりは適当に言っています)。

ショートカットがすごい

Slite を使ってみて最初に感じた不満は、「Markdown をそのまま書きたい」というものでした。Slite では、ハイパーリンク[[https://google.com](Google)] のように直接 Markdown として記述することができません。Slite の エディタ部分の UI は Medium っぽいといえば伝わる人には伝わるでしょうか。

しかし、Slite にはショートカット機能が搭載されています。

f:id:iktakahiro:20180719021603p:plain:w400

キーボードショートカット一覧(一部)

Slite のショートカットの配置はすばらしく、この操作に慣れると、Raw Markdown の入力が却って苦痛に感じるほどです。

「直接 Markdown として記述することができません」と説明しましたが、先頭を # で始まると見だしレベル1になり、先頭を「1.」で始めると順序付きリストになる、というようなレベルの Markdown 記法はサポートしています。Markdown エディタとリッチエディタのハイブリッドといったところでしょうか。海外の同カテゴリツールでこの UI を採用しているものが多いように感じますが、その中でも完成度は群を抜いています。

同時編集がすごい

Slite は 単一のドキュメントに複数人で更新をかけることが可能です。Google DocsDropbox Paper のようにです。

リアルタイム性が求められる議事録共有などは Google Docs で、その他の一般ドキュメントはなんらかのドキュメント共有ツールで... といったような使い分けをしているチームもあると思います。Slite なら1つにまとめられます。

f:id:iktakahiro:20180720005822p:plain
リアルタイム編集ができることがわかり盛り上がる弊社

この機能については動画で紹介するのが分かりやすいのですが動画を録っていないのでぜひ試用してみて欲しい部分です。

/ コマンドが凄い

これは最近実装された機能です。「見出しにする」「箇条書きにする」などはショートカットですべて行えることを説明しました。ただ慣れないうちはショートカットキーを覚えられず、何度もヘルプを見てしまいます。

そんなライトユーザー向けに、先頭を / で始まるとマークアップに使えるコマンドが一覧で表示される機能が用意されています。

f:id:iktakahiro:20180719020105p:plain:w400

/ コマンドも Slack を意識した機能なのかなと推察します。

コメントの管理がすごい

他のツールを使っていて感じる問題として、1つのドキュメントに対してコメントで延々と議論が続いてしまうというものがあります。ときには本文より長くなることも...。未解決事項なのかどうかも管理できませんし、何より最も重要なはずの本文が読みにくくなります。

Slite のコメントはサイドバーに配置されており、例えコメントが多くなったとしても視認性を下げないのが良い点です。そのうえコメントに対して Resolve フラグを立てられます。

f:id:iktakahiro:20180719025445p:plain:w400
ドキュメントに添えられるコメント

これにより、解決していないコメントだけを一覧に残せます。

通知の指定がすごい

ドキュメント更新時に Slack 通知が送信されるといった連携機能はいまや必須と言えます。Slite の場合、通知は完全に任意で、好きなときに、なんならドキュメントを更新していなかったとしても、当該ドキュメントのリンクと本文付きの通知を Slack に送信できます。

f:id:iktakahiro:20180719020946p:plain:w600

通知先 channel を都度選択できるので、あらかじめ設定された Slack channel にしか通知されないということも、わずかな更新の度に毎回通知が飛んでしまうといったこともありません。

逆に言えば、都度操作をしないと通知されないということでもあります。Google Docs のようにドキュメントは随時保存されていくので、書いているだけでは明確に「更新をした」というタイミングがないのも関係していると思います。

更新履歴は追うことができますし、このくらいの距離感のほうが良いのかも知れないと感じます。

いくつかの不満

褒めてばかりだったのでいくつか改善して欲しいと思っている部分について列挙します。

  • テーブル表現が辛い。テーブルに日本語入力すると挙動が怪しい。直接 Markdown で書きたくなる(結局!)
  • Markdown のインポートができない。既存の Markdown ドキュメント全体をコピペするとレイアウトが崩れて厳しい
    • 開発ロードマップには含まれている模様。Markdown としてのエクスポートは可
  • カテゴリー分類やタグ付け機能については従来の課題(階層分けとかをちゃんと管理しないと雑多になってしまう問題)を解決できていない
    • とはいえその課題を解決するために生まれたツールではない
  • デスクトップアプリがあるにはあるが、いかにも Web アプリを元に Electron でやりました感がある(違ったらごめんなさい)
    • ので結局ブラウザから使っている。iOS アプリなどもリリースされていく計画のよう

まとめ

上述したような不満はあるものの、Slite は Slack 登場以後の UI/UX をよく研究してつくられたプロダクトだなぁという印象を受けます。リアルタイム編集など、技術的にも良いトライをしているように感じられ、今後の機能拡充にも期待が持てます。

www.youtube.com

ドキュメント共有ツールをお探しの方は一度試してみるとよいのではないでしょか!

あらかじめ添えておく補足事項

Slite の他に、国内外問わず非常に多くのドキュメント共有サービス・ナレッジマネジメントツールやサービスが存在する昨今、チームにより合う機能、UI/UX を備えたツールを選定するのがベターです。そのため、Slite 以外にも素晴らしいプロダクトが存在すること、Slite が必ずしも皆さんのチームにとっての "イチ推し" とはならないことをあらかじめ申し添えておきます。

*1:Slite raises $4.4M to create a smarter internal notes tool | TechCrunch https://techcrunch.com/2018/04/23/slite-raises-4-4m-to-create-a-smarter-internal-notes-tool/

*2:スクラム向けプロジェクトマネジメントツールを比較した結果 Zube.io を推してみる https://iktakahiro.hatenablog.com/entry/2018/07/12/192213 を参照

スクラム向けプロジェクトマネジメントツールを比較した結果 Zube.io を推してみる

Agile なみなさんこんにちは。みなさんは Scrum プロセスを実施するにあたり、プロジェクトマネージメントツールとして何をお使いでしょうか。

最近当社で使い始めている Zube.io を推してみるというエントリです。

f:id:iktakahiro:20180712022238p:plain

Zube.io の話に入る前に、Agile/KANBAN/Scrum なプロジェクトマネジメントツール(SaaS型)についておさらいします。

我々に与えられたおもな選択肢(おさらい)

比較表というほどのものではないですが、使用したことのある主だったサービスを列挙します。SaaS で提供されていないものや、KANBAN でないものは今回選外です。

サービス 特徴
Jira やりたいことは(設定がうまくいけば)なんでもできる。 ただ設定がうまくいかない
Asana 優れた KANBAN ツールとして使えるが Scrum 向きではない
Trello 人気の KANBAN ツール。Scrum 向きではない
Pivotal Tracker 割と厳格な Scrum 向け。使っていたのが2014年頃なので最新の状況は分かっていない
Targetprocess 意外に(?)優等生。$20/user という価格がネック
YouTrack 性能の良い Jira 感。 JetBrains プロダクトでまとめたいならアリ。(設定がうまくいけば)なんでもできる。
Planio Redmine ベース。Redmine でできることは基本できるので色々と柔軟。Agile Plugin (独自実装?) 搭載により Scrum をサポート
GitHub project boards 簡易 KANBAN としては良いが Scrum 向けではない
GitLab Issue Boards GitHub より機能が多いので柔軟な利用ができる。Scrum を回すには工夫が必要か
ZenHub GitHub Market Place で見つかるツールではおそらく一番メジャー。最低限の機能でいいなら選択できる。$5/user と価格が良心的
issue.sh Chrome 拡張をインストールすると GitHub の Web UI が強化される的な
Codetree 複数リポジトリを1つの画面で横断的に管理することにフォーカスしたサービス。UI がよく Issue Tracker として有用。 KANBAN も使えるが Scrum 向きではない
物理カンバン ホワイトなボードこそが真の Scrum Master への道。エディタ界における Vim 的なポジション

有名所が漏れていたらこっそりご指摘ください。

"Scrum 向け" の定義

おおむね以下の要件を満たすものが Scrum に適したプロダクトであると定義しています(個人の見解です)。

  • Sprint の設定ができる(end だけではなく start / end の両方の日付を指定したい)
  • Story Point (または Business Value)の指定ができる
    • Story Point に基づいた Velocity の測定が行える
    • Story Point に基づいた Burn down/up chart が参照できる
  • KANBAN UI が実装されている

選定のポイント

今回選定するにあたり以下を要件としました。

  • GitHub Issue と 容易に integration できること
    • 開発を行う上でなんだかんだ GitHub Issue はつくられてしまうので、チケットの2重管理が辛い(かといって GitHub 単体では厳しいという前提)
    • この時点で候補がかなり絞られてしまう。
  • Scrum に向いていること(何をもってかは上述のとおり)
  • 複数のリポジトリをまとめて管理できること
    • 1つの Scrum チームが複数のリポジトリを管理していくことがあり得るのでこの要件は必須
  • できるだけロックインされないこと
    • GitHub Issue とは別のところで状態が管理されないほうがよい
  • 複雑な設定なしにワークフロー/プロセスを開始できること

結論として、要件を満たすのが Zube.io のみとなりましたので消極的(ということもないですが)Zube.io 推しという結果になりました。

Zube.io とは

前置きが長くなりましたが、Zube.io のはなし。

zube.io

Zube.io は GitHub Issue の Wrapper として機能する プロジェクトマネージメントツール です。概念としては上述の ZenHub や issue.sh、Codetree と同等です。

料金体系は 4ユーザーまで無料で、5ユーザー以上の場合は $10/user の有料プランを選択することになります。料金の詳細は下記ページを参照ください。

Scrum 向けツールとしての Zube.io

Zube.io は、そこかしこから Scurm イズムを感じる仕上がりとなっています。

f:id:iktakahiro:20180712015205p:plain:w800

Sprint、Epic、Story Point、Burn down/up など Scrum に必要な機能が揃っています。設定項目が豊富なわけではないのですが、デフォルトで充分に使いやすい状態で提供されている点が好印象です。

f:id:iktakahiro:20180712030941p:plain:w400

Scrum プロセスの振り返りにおいて重要な各種レポートを特別な設定なしに取得できます。Burn down はあるけど Burn up はない、というサービスはままあるので、嬉しいポイントです。

続いて pros/cons を掲載します。

pros

  • それなりにフォーマルな Scrum プロセスをサポートする。
  • GitHub リポジトリの Issue と連動した KANBAN (KANBAN Board) および Scrum用 KANBAN (Sprint Board) を利用できる。KANBAN 上に Card を作成すると Issue にも作成される。
    • Card のステータス(Ready なのか In-Progress なのかとか)は Issue のラベルで管理される
    • Issue に情報が残っているので脱出しやすさがある。ステータスについても Zube.io 内部管理ではなくラベルという形で記録されているのが安心
  • UI が洗練されている。動作が軽快
  • 複数リポジトリ対応。Zube.io 上の プロジェクト1つに対し、複数のリポジトリを紐付けられる。Card 作成時にどのリポジトリの Issue とするかを選択可能(どのリポジトリの所属ともせず、Zube.io 上のみで管理することもできる。ただこの場合ロックインになるのでお薦めはしない)
  • Pull Request を InReview の Card として作成するといった GitHub Wrapper ならではの細かい気遣いがある
  • Burn down だけでなく Burn up chart が見られる

cons

  • 読み方が分からない(今度中の人に聞いてみる)
  • 開発がアクティブなのかどうかよく分かっていない。Twitter は全然更新されていない
  • 周りに使っている人がいない。います?
  • $10/user という価格は特別高くはないが GitHub の課金に On されると考えると費用対効果をどれほど見出せるかにかかっている
  • よくある swim lane の設定がそういえばできない
  • Slack への通知はできるが最低限の機能。GitHub 本体の Issue 通知とうまく組み合わせる必要があるかも

まとめ - 自然な形で Scrum のプラクティスを実践できるのが Zube.io

Zube.io は機能の端々から、Scrum を良く理解した開発チームによって設計されたプロダクトであることが窺い知れます。既に(フォーマルな)Scrum を実践していて、Issue 管理に課題を感じているようであれば Zube.io は有力な選択肢になるでしょう。

Zube.io のユーザーが増えて開発がより活発になれば幸いです!

React Component ライフサイクル ひとめぐり (CodeSandbox 付き)

書籍『はじめてのフロントエンド開発』が2018年5月9日に技術評論社さまより刊行されております。

執筆プロジェクトでは React のパートを担当させていただいたのですが、執筆にあたり作成した React Component ライフサイクル に関する図 をこのたび CC0 ライセンスで公開しました。

React Component ライフサイクルに関する図

.ai および .svg フォーマットも取り揃えておりますのでどうぞご活用ください。

ところでお気づきの方もいらっしゃると思いますが、書籍執筆時点では React v16.3 のリリース前であったため、上記のダイアグラムも v16.3 で追加されたライフサイクルについての情報が盛り込まれていません。

更新版を作成する意思を見せつつ(言い訳)、今回は、React Component ライフサイクルのメソッドについて改めて整理しようという目的で筆を執りました。

Sand Box 的な何か

本エントリで登場するメソッドたちを利用したごく簡単なサンプルアプリを公開しています。

codesandbox.io

あらためて、React の Component ライフサイクルに関するメソッドについて

"React の Component ライフサイクルに関するメソッド" についての情報は公式ドキュメントにまとまっています。

reactjs.org

詳細は公式ドキュメントをご覧いただくとして、各メソッドについて簡単に整理します。

componentDidMount()

componentDidMount() は Component が Mount された後に実行されるメソッドです。用途の例は以下のとおりです。

  • Ajax を使ったデータフェッチを行う(初回)
  • DOM に対する処理を行う(初回)
  • タイマーをセットする
  • イベントリスナのセット

fetch() を利用してデータフェッチを行う例です。

fetchUser = (name: string) => {
  fetch(`https://api.github.com/users/${name}`)
    .then(res => res.json())
    .then(json => this.setState({ gitHubUser: json as GitHubUser }));
};

componentDidMount() {
  this.fetchUser(this.props.name);
}

SandBox では GitHubAPI を利用して指定したユーザーの Avatar を表示とタイマーのセットを行っています。

componentDidUpdate()

componentDidUpdate() は、Component の props または state が変更されたときに実行されます。用途の例は以下のとおりです。

  • Ajax を使ったデータフェッチを行う(二回目以降)
  • DOM に対する処理(二回目以降)
  • その他諸々

componentDidMount() は一度のみ実行されます。初回のデータフェッチは componentDidMount() に記述し、props ないし state の変更に応じて再フェッチする場合 componentDidUpdate() にも処理を書くことになります。

componentDidMount() {

  // 初回のフェッチ
  this.fetchUser(this.props.name);
}

componentDidUpdate(prevProps) {

  // props.id が変更されたら再フェッチ
  if (this.props.name !== prevProps.name) {
    this.fetchUser(this.props.name);
  }
}

SandBox では Select Box の 状態が変更された場合、GitHubAPI を再び呼び出す処理を記述しています。

componentDidMount() に無限ループするようなロジックを書いてしまいがちですので注意します。

// 無限にアップデートされ続ける
componentDidUpdate(prevProps: Props, prevState: State) {
  this.setState({ count: prevState.count++ });
}

componentWillUnmount()

componentWillUnmount() は Component が Unmount されるときに実行されます。componentDidMount() で行った処理の解除を行うことが多いでしょう。

  • タイマーを解除する
  • イベントリスナを解除する
  • 非同期処理を中止する
componentWillUnmount() {
  clearInterval(this.timerId);
}

getDerivedStateFromProps()

v16.3 で新設のメソッドです。戻り値とした Object の内容で state が更新されます。戻り値がない場合は state は更新されません。

static getDerivedStateFromProps(nextProps: Props, prevState: State) {
  const name = nextProps.name.toUpperCase();
  if (prevState.name !== name) {
    return { isDerivered: true, name };
  }
  return;
}

上記のサンプルはかなり苦肉の策感がありますが、実際、props の値をレンダリングに使うだけという場合、わざわざ state として管理する必要はありません。「初期値を props から求める + ユーザーの操作に応じて state の値が変更される」ような場合に利用します。

getDerivedStateFromProps() は static method のため、メソッド内で this.props.hoge !== nextProps.hoge のような比較処理は行えません。この点において componentWillReceiveProps() の代替ではない点に注意します。

shouldComponentUpdate()

shouldComponentUpdate() は、不要な再レンダリングを抑制してパフォーマンスの低下を防ぐ目的で利用されます。

shouldComponentUpdate(nextProps: Props, nextState: State) {

  // isVisible が変更されたときだけ再レンダリングを行う
  if (this.state.isVisible !== nextState.isVisible) {
      return true;
  }
  return false;
}

// shouldComponentUpdate() により props.text が更新されただけでは再レンダリングされない
render() {
  return <div>
    {this.state.isVisible && <p>{this.props.text}</p>}
  </div>
}

ただし、レンダリングに利用する値かどうかを shouldComponentUpdate() で判断してレンダリングのコントロールを行うことは適切ではありません。レンダリングに使用しない(が状態が変更される)ものは Class のメンバ変数として扱い state として管理しないようにします。

shouldComponentUpdate(nextProps: Props, nextState: State) {

  // (動作上は問題ないが) render() 内で利用しない状態をここで比較しているということは
  // そもそも state では無い説
  if (this.state.timerId !== nextState.timerId) {
      return false;
  }
  return true;
}

getSnapshotBeforeUpdate()

v16.3 で新設のメソッドです。getSnapshotBeforeUpdate() は、Component の再レンダリングが行われる直前に実行されます。戻り値がある場合、componentDidUpdate() の第三引数に値が渡ります。

getSnapshotBeforeUpdate() の用途としてスクロールポジションの管理に使う例が提示されています。

componentWillReceiveProps()

v1.7 で廃止予定。これまで componentWillReceiveProps() で行っていた処理は getDerivedStateFromProps() ないし componentDidUpdate() に移管できるはず。

componentWillUpdate()

v1.7 で廃止予定。同様に getDerivedStateFromProps() ないし componentDidUpdate() で代替できるはず。

componentWillMount()

v1.7 で廃止予定。使用しない。

書籍について

冒頭で言及した『はじめてのフロントエンド開発』は、パンダの表紙が目印の通称パンダ本です。

本エントリで触れた Component ライフサイクルを始め、React の "さわり" を眺めつつ、React を使った SPA を実装する流れです。TypeScript + React に挑戦してみたい方にもお勧めできます。

React、Angular、Vue.js、React Nativeを使って学ぶ はじめてのフロントエンド開発

React、Angular、Vue.js、React Nativeを使って学ぶ はじめてのフロントエンド開発

特徴としてはパンダが可愛いことです (語彙力)。

書籍で解説しているコードは下記の Repository で公開しています。あわせてご参照ください。

github.com

共著者のブログ

massa142.hatenablog.com

taisablog.com

以上です。

SQL がはじめてのひとも、ニガテなひとも - 技術評論社『これからはじめる SQL 入門』

昨年から執筆していた書籍『これからはじめる SQL 入門』(以下、本書)が 2018年5月2日に技術評論社さまより刊行されます。今回はその紹介記事を投稿します。

これからはじめる SQL入門

これからはじめる SQL入門

どんな本か

本書はいわゆる一つの SQL 入門本です。SELECT文、INSERT文、UPDATE文... にはじまり、JOIN や GROUP BY、データ型や関数などの基礎知識をひととおり解説しています。

本書では PostgreSQL 10 がサポートする SQL の構文を解説の対象としていますが、MySQLSQL Server など他の RDBMS でも通用する知識が得られるはずです。

本書はSQL の基礎知識をひととおり学ぶことを目的として書かれた一冊です。データベースとはなにか、SQLとはなにかといったことに触れつつ、SELECT文やINSERT 文などのSQL の構文を中心に解説を進めていきます。はじめてSQL を学ぶ方を対象としていますので、プログラミングやシステム開発に関する知識を前提としない内容になっています。同時に本書は、読者が本書を通読したあとに「SQL入門者」のレベルを脱していられるような情報量と難易度となっていることを狙って書かれています。

(はじめに より)

なぜ書いたのか

企画段階で編集チームよりオファーいただいたのが本書執筆のきっかけです。

また、SQL を日常的に使っているけれども苦手意識をもっているソフトウェア開発者の層が一定数いるものと認識しており、そういった方々があらためて SQL を学びなおす本があったら良いと考えたというのが動機の一つです。

ゼロから SQL を学びたいと考えている人がいるときに「これ読んでおいて」と言える本が一冊あるといいなと考えたということもありました。

本書は、筆者が初心に戻り「自分がSQL を学び始めたときにこのような解説書があればよかった」と思える一冊に仕上げようという思いで筆を執ったものです。

(はじめに より)

誰のための本か

本書は以下の方に向けて書かれています。

  • これから SQL を学ぼうとしている方
  • SQL に苦手意識をもっている方
  • 普段 O/RM に頼っていてじつは 素の SQL には自信がないという方

本書がSQL をはじめて学ぶ方の学習の手助けになること、SQL に対して苦手意識をお持ちのかたが再入門するきっかけになることを願っています。

(はじめに より)

書名のとおり初心者向けではあるものの、SQL を基礎から改めて学び直したいという方も対象としています。

こだわりポイント1 : 反復

本書を読み終えたあと、SQL が以前より肌に馴染むようになっていて欲しい、ということが本書の構成を考えるうえでこだわったポイントです。

SQL を身につけるコツとしてお勧めしている方法を本書より引用します。

筆者がSQL初心者であったころの悩みは「それぞれの意味はわからなくないけど、なかなか覚えられない」というものでした。筆者の経験を踏まえて、1 つアドバイスがあります。それはコピー& ペーストに頼らず、自分の手でタイプして体になじませるというものです。

(84ページ 章末コラムより)

具体的な方法として以下を提案しています。

  1. SQL を書き写してみる(写経)
  2. 書き写したSQL の列名や絞り込み条件を変更してみる
  3. エラーが発生することを恐れずに、期待どおりの結果がでるまで書き直す
  4. 別のSQL を書き写してみる

(84ページ 章末コラムより)

この思想にもとづき、本書では多くの SELECT文 に ORDER BY句 や LIMIT句 が付与されていたり、INSERT文 実行結果を確認するための SELECT文 を添えたりしています。

  • 解説対象外であっても ORDER BY句 や LIMIT句 を使用している例
SELECT id,
       isbn,
       user_id,
       ROUND(score)
  FROM rating
 ORDER BY id ASC
 LIMIT 3;

SQL とその実行結果を一致させるという意味においては特別な配慮ではないかも知れませんが、冗長であっても実際に頻繁に使用するであろう SQL の構文をくり返し学んだほうがよいという意図をもってサンプルコード群が構成されています。

  • INSERT文のあとに SELECT文を使用している例
INSERT INTO b2 (published_at, id, title)
VALUES ('2017-09-14', '3', 'Angular アプリケーションプログラミング');

-- INSERT文 実行後の結果を確認
SELECT *
  FROM b2
 ORDER BY id DESC;

本書では INSERT文や UPDATE文 などのテーブルに対する更新処理を行ったあと、SELECT文 で処理内容の結果を確認するようにしています。

こだわりポイント 2 : ベン図

本書では図表による解説は必要最小限にしていますが、AND句 と OR句 の解説箇所ではベン図を多用しています。

f:id:iktakahiro:20180416233438p:plain:w300
(67ページより)

f:id:iktakahiro:20180416233455p:plain:w300
(72ページより)

図解書ではないのでメインはコードと文書ですが、JOIN や WHERE句 など、初学者にとって概念が難しいと思われる部分では図説を取り入れた解説を行っています。

サポートサイト公開中

本書に関するサポートサイトとして以下のリポジトリを作成しました。本書中で利用している主要な SQL コードも公開しています。

本書中では諸般の事情により VirtualBox を使って PostgreSQL の学習環境を構築しているのですが、上記リポジトリでは Docker を利用した学習環境の構築方法を解説しています。(ここだけの話ですが、著者としては Docker 利用を推奨します...!!)

コマンドラインが苦手な方は PostgreSQL と pgweb をセットで構築できる docker-compose.yml を使ってみると幸せになれるかも知れません。

f:id:iktakahiro:20180430141529p:plain:w600
参考: pgweb を使った PostgreSQL へのアクセス

レビュー記事(随時追記)

本書のレビューにご協力いただきました @t2y さんが素敵なレビューを書いてくださっています。

t2y.hatenablog.jp

『Python エンジニアファーストブック』- Python活用 の "さわり" がコンパクトに詰まった一冊

2017年9月9日に技術評論社より『Python エンジニアファーストブック』が刊行されました。

Pythonエンジニア ファーストブック

Pythonエンジニア ファーストブック

  • 作者: 鈴木たかのり,清原弘貴,嶋田健志,池内孝啓,関根裕紀
  • 出版社/メーカー: 技術評論社
  • 発売日: 2017/09/09
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

本書は以下の構成からなります。

  • 第1章 Pythonの動向 - その特徴、歴史とコミュニティの紹介
  • 第2章 最低限知っておきたいPython言語の基本 - Pythonで開発を始める前に知っておくべきこと
  • 第3章 開発環境とチーム開発 - チーム開発で使われている開発環境とツール
  • 第4章 スクレイピング - PythonによるWebスクレイピング
  • 第5章 PyData入門ガイド - Pythonによるデータ分析のはじめの一歩
  • 第6章 Webアプリケーション開発 - Webフレームワークを使ってWebアプリケーション開発に挑戦

さまざまな場面で利用される Python の魅力のエッセンスともいうべき情報がコンパクトにまとめられた内容になっています。

その中で今回「第5章 PyData 入門ガイド」の執筆を担当いたしました。Python 本の執筆としては 2014年に『Pythonエンジニア養成読本(以下、養成読本)』の執筆チームに参加させていただいたのが初めてでして、今回はその大幅改訂版ということで個人的には感慨深くもあるプロジェクトでした。

いっぽう、これだけデータ分析業界のタレントやプレーヤーが増えてきた中で、改めて僕が本章の筆を執ることに若干の躊躇いもあったのですが、「Data Engineering のはじめの一歩」を伝える内容になれば意義もあろうというモチベーションで取り組みました。

なお、本エントリでいう「Data Engineering(データエンジニアリング)」とは、いわゆる Data Science(データサイエンス) とは異なるもので、この定義も実際容易ではないわけですが、データ収集や前処理などの工程や、ある程度フロー化された統計解析への取り組み、分析プロセスの高度な自動化(より具体的にいうとバッチ処理化やプロトタイピングのプロダクションコード化)などの領域を指しています*1

第5章は Data Engineering 領域の一部の入門的内容を取り扱っているという(自分の中での)位置づけです。

第5章 PyData 入門ガイド の読みどころ

それでは、担当章の読みどころを簡単に紹介してみようと思います。

構成

第5章の構成(= 節見出し)としては次のとおりです。

  1. PyData とは
  2. はじめての Jupyter Notebook
  3. 実践 レゴデータ分析[データ探索編]
  4. 実践 レゴデータ分析[データ可視化、分析編]
  5. Anaconda環境の利用
  6. PyData パッケージガイド

養成読本では、PyData パッケージのいくつかについてダイジェストで紹介した上で、最後にオープンデータを可視化してみるという構成でした。こんにち、パッケージの使い方的な情報はすでにありふれており、養成読本のデータの可視化はおまけ程度の内容でしたので、抜本的に改訂が必要であろうということで大方の内容を書きかえました。

メインコンテンツ紹介

「第4章 スクレイピング」で収集したレゴのデータを利用して、データの読み込み、集計、簡単な統計解析、可視化に取り組むというのがメインコンテンツです。ツール的には Jupyter、pandas、SciPy、Matplotlib が登場します。統計解析的な要素としては単回帰分析を用いています。

f:id:iktakahiro:20170922230632p:plain:w400
pandas を使ったデータ探索の解説(本書200頁)

f:id:iktakahiro:20170922230803p:plain:w400
pandas (Matplotlib) を使ったデータ可視化の解説(本書207頁)

本書全体をとおして読むと、

  1. Python の使い方がわかり
  2. スクレイピングで Web からデータが収集でき
  3. PyData パッケージを使ったデータエンジニアリングの初歩が学べる

という流れになっています。

こぼれ話

データ可視化は主に pandas の plot() メソッドを利用して行っています。

theme_ranking10 = count_theme.sort_values(ascending=False).head(10)
theme_ranking10.plot.bar(figsize=(10, 5))

さまざまな方法を検討しましたが、簡単にグラフ出力したいならたぶんこれが一番楽だと思います。Matplotlib を直接触っているところもあります。

すごく余談ですが、最近僕の中で、Python データ可視化パッケージのキャラ付けは以下のようになっています。

  • 論文書くなら Matplotlib 先生
  • 実務に手堅い Seaborn 中尉
  • お一人様なら pandas くん
  • よそゆき Bokeh さん

この話はまた別のどこかでしたいと思います(しません)。

あと執筆期間中に発覚した衝撃(?)の事実として matplotlib は固有名詞としては先頭大文字始まりの Matplotlib だったというものがありました。ロゴが小文字なので小文字と思い込んでいたのですが*2、公式ドキュメントではしっかり大文字表記でした。

回帰分析には SciPy を使っています。scikit-learn のほうが良かったという説がありますが、機械学習以前の領域を取り扱いたいということもありましたのでご容赦ください。

Anaconda と すばらしき PyData パッケージたち

Python の環境としては公式インストーラーの Python を利用する前提の解説ですが、補足情報として Anaconda の conda コマンドを紹介しています。

また Appendix 扱いで、PyData パッケージガイドとして NumPy や scikit-learn、TensorFlow などの超メジャーなものから、比較的あたらしめの PyTorch などを一覧で紹介しています。本書中でも触れているのですが、PyData 関連パッケージも日進月歩ですので、Awesome Python で探すといいよ、というのが本音ですね。

まとめ

次の書評ブログがとても端的に本書の特色を示していると思います(まとめを人様のブログに委ねるスタイル)。

massa142.hatenablog.com

本書は Python を活用してくための情報がコンパクトに詰まった一冊です。@checkpoint 渾身の Django 解説も見所です。

サイズ的にも気軽に手に取れる仕上がりですので、ぜひご覧いただければと思います。

あわせて読みたい

拙著で恐縮ですが、Jupyter や データ可視化についてもっと詳しく知りたい方向け。

PythonユーザのためのJupyter[実践]入門

PythonユーザのためのJupyter[実践]入門

4章でスクレイピングに興味をもった方へ激しくお勧めな一冊。Scrapy の詳解あります。

Pythonクローリング&スクレイピング -データ収集・解析のための実践開発ガイド-

Pythonクローリング&スクレイピング -データ収集・解析のための実践開発ガイド-

じつは Python 文法よくわかってなかったわ… という方はこちらをどうぞ。

みんなのPython 第4版

みんなのPython 第4版

*1:Data Engineer ≠ Data Scientist

*2:https://matplotlib.org/_static/logo2.svg

PythonユーザのためのJupyter実践入門 - JupyterユーザーによるPython ユーザーのためのJupyterの本

2017年9月9日に、書籍『PythonユーザのためのJupyter[実践]入門』(以下、本書)が発売になりました。僕含めた4名の著者による共著本です。

PythonユーザのためのJupyter[実践]入門

PythonユーザのためのJupyter[実践]入門

何の本か

書名に Jupyter とあるとおり、Jupyter Notebook を取り扱った書籍です。同時に、pandas 基礎、Matplotlib および Bokeh 詳解をメインコンテンツとした書籍でもあります。

jupyter.org

本書の見出しを以下に記載します。

  • 第1章: Jupyter Notebookを導入しよう
  • 第2章: Jupyter Notebookの操作を学ぼう
  • 第3章: pandasでデータを処理しよう
  • 第4章: Matplotlibでグラフを描画しよう
  • 第5章: Matplotlibを使いこなそう
  • 第6章: Bokehでグラフを描画しよう
  • 第7章: Bokehを使いこなそう
  • 第8章: Jupyter Notebookをカスタマイズしよう
  • 第9章: クラウド上でJupyter Notebookを使おう
  • 第10章: Jupyter NotebookでRubyとRを使おう
  • Appendix: ipywidgetsとJupyterLab

なぜ書いたのか

Jupyter Notebook は IPython Notebook という名称であった時代から人気のツールで僕自身もよく利用しており、何らかの形で書籍にできればよいとかねてから考えていました。

Jupyter Notebook は最低限の機能を使用するだけならマニュアルが必要ないほど簡単に利用できるツールです。それ故に、キーボード・ショートカット機能や設定ファイルの活用などより便利な用法を知らずに使われがちであると考えていました。

Matplotlib は可視化ツールとしてよく知られていますが、歴史が長く、かつ多機能であるため公式ドキュメントを手繰ったとしても機能の要所を掴むことは容易ではありません。

これらの状況を踏まえて、和書として Jupyter Notebook と可視化 について詳しく取り扱った書籍があれば有意義なのではないかという理由で執筆プロジェクトがスタートしました。

見所

著者視点で本書の見所をいくつかピックアップします。

カラーページを使い可視化例を豊富に掲載

本書では、データの可視化を中心に取り扱った一部の章について、カラーページを採用しています。

f:id:iktakahiro:20170912131735p:plain:w700

f:id:iktakahiro:20170918001405p:plain:w500

単色で表現できる簡単なグラフから、透過や重ね合わせを組み合わせた複雑なグラフのどちらもカラーで紹介しているので、具体的なイメージを確認しながら学べる内容になっています。

サブプロットが使いこなせるようになる

本書は Matplotlib の ここがわからない という疑問を解消できるように配慮して構成されています。1例として、複数のグラフを並べて 1つのプロットとする サブプロット の解説に紙面を割いています(本書144頁)。

# フィギュアの生成
fig = plt.figure()

# フィギュア内にサブプロットを3つ配置します
ax1 = fig.add_subplot(221) # 2行2列の1番
ax2 = fig.add_subplot(222) # 2行2列の2番
ax3 = fig.add_subplot(223) # 2行2列の3番

plt.show()

上記のコードに含まれるような、add_subplot(221) という記述を見たたけでは、サブプロットのコードとグラフの関係は判然としません。本書では、コードと図説を交えて、サブプロットについての解説を行っています。subplots() 関数についての言及もあります。

f:id:iktakahiro:20170918001850p:plain:w400

本書を読むことで、なんとなく利用していたサブプロットを使いこなせるようになるでしょう。

コーディングスタイルについて言及

本書では、Matplotlib のコーディングスタイルとして、通称 MATLAB-style と、オブジェクト指向スタイルである OOP-style という2つのコーディングスタイルを紹介し、後者のほうが明示的なコードであり望ましい、という意見を表明しています。

MATLAB-style のコードと、それに言及した一文を本書 252 - 253頁より引用します。

%matplotlib inline

import matplotlib.pyplot as plt

x = [1, 2, 3]
y = [3, 6, 9]

plt.bar(x, y)
plt.title('Sample Bar Chart')
plt.xlabel('X')

— 略 — まず、グラフを作成するために、pyplotモジュールのtitle()やxlabel()を直接呼び出して利用しています。このコードをアレンジして複数のグラフを描こうと考えたとき、どのようにすればよいか手がかりがありません。

また、グラフの描画について暗黙的な動作をしています。plt.xlabel(‘X’)を実行するとグラフが描画されますが、plt.xlabel(‘X’)を削除するとplt.title()の実行後にグラフが描画されます。

このトピックは公式ドキュメントにも Coding Styles*1 として解説があります。本書ではなぜ「OOP-style がいいのか」「OOP-style のどこが明示的なのか」という点をコード例を交えて解説しています。

Matplotlib のユーザー、あるいは PyData 関連パッケージのユーザー構成の特長として、いわゆるソフトウェアエンジニアではない層が一定数存在するということが挙げられます。ソフトウェアエンジニアが前提として持っている(あるいは持っていて欲しい)コーディング規約やコーディングスタイルに関する知識および関心をあまり持たないユーザーに対して、Zen of Python の設計思想を伝える意図を持って、この一節が盛り込まれました。

なんだか見所紹介が Matplotlib 推しみたいになってしまいましたが、実際推しメンなので*2 紹介してみました!

謝辞

本書の刊行にあたり、共著者のほかに、出版社のみなさま、編集プロダクションのみなさま、レビューにご協力いただいたコミュニティのみなさまの多大なるサポートをいただきました。特に、今回はレビュワーのかたのご協力なしには完遂できなかったプロジェクトでした。裏を返すと、僕の進行の拙さにより執筆チームに負担を強いる結果となり、反省も多い企画となりました。お世話になりましたみなさまには、この場を借りて心よりの御礼を申しあげます。

経過はともあれ、成果物としての本書の善し悪しは読者のみなさまにご裁定いただくものと考えています。本書がわずかでもお役に立つことを願っています。

*1:https://matplotlib.org/faq/usage_faq.html#coding-styles

*2:といいつつ、執筆箇所でいうと僕はおもに Jupyter 周りの担当でした

Python プログラミングを学ぶための準備運動 - 翔泳社『スラスラわかる Python』

このたび、縁あって『岩崎圭、北川慎治 著書、寺田学 監修 (2017). スラスラわかる Python, 翔泳社』(以下、本書) を恵贈賜りました。

著者並びに出版社の皆様にお礼とご慰労をかねまして、僭越ながら本エントリにて一読後のレビューを兼ねたブログを投稿いたします。

スラスラわかるPython

スラスラわかるPython

総評

本書は、これからプログラミングや Python を学ぶための 準備運動 として最適な一冊に仕上がっています。

初学者が Python を学び進めるにあたり、本書には次の良い点があるでしょう。

  1. ボリュームが適度
  2. Python 文法の中で重要な点が抽出されている
  3. 図説、コード、解説のバランスが良い

「1.」および「2.」について、本書が構成されるにあたり、多くの取捨選択がなされています。例えば本書では「リスト型」の説明をするにあたり Python の特長の 1つでもある「リスト内包表記」の説明はなされません。リスト型や辞書型の説明はありますが集合型の説明は省略されています。当然のようにクラスの解説も登場しません。

まず Python を知ってもらう、プログラミングが動く楽しさを体験する という観点でこの取捨選択は妥当と言えます。反面、網羅性は犠牲になっていますので、Python の基礎レベルに到達するためには最低でも別のもう1冊の書籍から学びを得る必要があります。その意味で、準備運動のつもりで本書に取り組む姿勢が望まれます。

本書を通読したということは、充分に体がほぐれたことを意味します。

その自信をつけたうえで別の−−網羅性の高いものが望ましい−−入門本を手に取り、プログラミング学習という長い道のりを走り出すのがよいでしょう。

雑感: 例外処理と型について

例外処理について改めて感じたことですが「Python の例外の仕様がわかる」と「Python で適切な例外処理が記述できる」という両者には隔絶の差があります*1。比較的平易であるとされる Python の言語仕様において例外が例外なのか (※ 駄洒落ではない) 例外処理そのものが難しいのか……。

本書でもこのことは考慮されており、入力チェックについて例外処理を濫用せずに if 文でチェックを実施する方法が参考情報として解説されています。

# 114ページのコードを一部変更したもの

def add_10(num):
    if not isinstance(num, int):
        print('Invalid num')
    
        return False

    add_num = num + 10
    print('add_num is {}'.format(add_num))

    return add_num

Python としては普通の感じですが (Early Return していて好き) 、型があればよりシンプルにな制御で済むし、False または int が戻る関数というのも少し収まりが良くありません*2。これはコード例が悪いということではなく例外処理難しいですねと思ったということです。

おそらく説明平易性を維持するために Type Hints*3 には触れられていないのだと推察しますが、こうも書けるでしょうか。

def add_10(num: int) -> int:
    add_num = num + 10
    print(f'add_num is {add_num}')

    return add_num

ただ Type Hints を付けたからといって データ型にまつわる例外処理や条件分岐を無条件で省略可能になるわけではないです。

型論争みたいなところに首を突っ込むと Python だけに藪蛇 (※ 注釈略) になりそうなので深い言及は避けたいですが、適度な制約は学習曲線向上の手助けになると感じています。つまり Python を初学者に教えるにあたり Type Hints は積極的に推していくのがよいと思っています。ただしこの考えはおそらく本流ではないです。

雑感でした。

*1:これはどんなものもそうだと思いますが、例外処理が特に、という意味です

*2:Go に慣れた今では特に。error を常に返したいと思ってしまう

*3:typing — Support for type hints https://docs.python.org/3/library/typing.html