コード

インデントにタブではなくスペースを使う理由

コードを書く際によく話題になるインデント。タブを使いますか？スペースを使いますか？それともほかのなにかを使いますか？

私はスペースを使います。 それはインデントが見易さのためのものだからです。

タブは制御文字

タブは制御文字で見易さの調整に使われるものではありません。確かに昔はタイプライターの位置調整のために使われていたそうですが、今はそういった使われ方はしません。もしタブ文字がタイプライターにおける水平タブと同じ意味を持つのなら、タブ幅を個人で変えられるようにはしなかったでしょう。

TSV では、 タブは異なる属性だとか、異なる種類だとかいう意味を表すための区切り文字になります。 タブでインデントを行ったソースコードをコピーしてExcelに貼り付けると、タブでインデントされた文字は別の列に貼り付けられます。 そういった情報の制御文字として タブは使われています。

ありがちな誤解

このようにタブを制御文字として扱うと、「インデントは情報の深さを表すものだから、タブでインデントしてもいいじゃないか」と考えてしまうこともあるかもしれません。 たしかにタブを使っていれば、先ほど例に挙げた Excel にコードを張り付けるケースでは、インデントされた行はそれだけ右のカラムに貼り付けられます。

しかし、情報の深さはインデントだけで決まるものではありません。 そのため、仮にすべてのコードがきれいにインデントされているとしてもタブを使うべきではないです。

下に情報の深さをインデントを使って表した例を示します。 (都合上 下の例ではインデントをスペース2つで現しています。)

インデントを情報の深さとしてとらえると、1つ目では特に深い情報がなく、2つ目では1行に書ける関数でも、仮に引数が1つでも改行とインデントが必要になります。 また2つ目ではカンマの存在意義がありません。

最後に

最初に書いた「私はスペースを使います。 それはインデントが見易さのためのものだからです。」というのはわかっていただけたでしょうか。 インデントは見易さの問題を解決する目的があるので、見える文字であるスペースを使っています。

コード

Android アプリ Your Place のコードを公開します

、東京メトロ オープンデータ活用コンテストがありました。 そのとき私が応募したアプリのソースコードを公開します。

概要

東京メトロの駅の中から行き先を決めてくれるアプリです。 家にいたくないけれど行き先が決まっていないときに使えます。 Android Wear とも連携し、 Android Wear で行き先や周辺スポットを見ることもできます。

理想

開発に使える時間の制約などから、単純に「行き先を決めてくれるアプリ」になっていますが、次の機能も実装したいと思っていました。

  • 気学を用いて運勢のいい方角のなかから行き先を決める。
  • 運勢のいい方角と現在地をマップ上で見られるようにする
  • 行き先を決める中で、そのときの気分を考慮する。
  • 行ったことのある東京メトロの駅を記録し、全駅コンプリートしたらなにかを出す。
  • 目的地の駅や乗り換えの駅に接近したら、 Android Wear に通知を出す。
  • 複数人で出かけるときの設定項目を考える。
  • タップだけでなく、 シェイク して行き先を決められるようにする。

要するにパーソナライズして本当におすすめの駅を探すということです。

振り返って

初めて作った Android アプリ にしてはそれなりによくできたのではないでしょうか。

class の名前などは知識不足もあり、 修正した方がいいものもあります。

Windows, コード

pik でバージョン管理

pik といえば、 windows で使える ruby の複数バージョン管理ツールです。 記事執筆時点で pik は github で No longer maintained と書かれていまが、 私は使い慣れた pik を使います。

落とし穴

Windows 7 32bit で検証済み。

msi インストーラ を実行して windows にインストールするのですが、 そのままでは使えません。 ある意味バグが残っているので一部修正して使います。

まずは インストーラのページ から 記事執筆時点での最新版 pik-0.3.0.pre.msi をダウンロードして実行し、そのままインストールします。

設定を変更していなければ C:\pik に pik に関するファイルがインストールされます。 その中の C:\pik\pik.bat の 7行目 で %HOME% になっているところを %USERPROFILE% に変更します。

Windows では %HOME% という環境変数は定義されていません。 (インストール先ディレクトリ から考えて) %USERPROFILE% に変えればうまくいきます。 Windows 8.1 でも同じです。

生活の知恵, 社会

会議でしゃべらない人の巻き込み方

会議ではしゃべらない人がよく出てきます(全員意見を言う職場はとてもいい職場だと思います)。 そういった人に意見を言ってもらう方法をいくつか紹介します。 (アイスブレイクは全体的なものなので省きます。)

前提

会議の目的を明確にするなど、基本的な準備はできているものとします。 何人かは発言しているのだけど、1、2人ほど発言しない人がいる状況を想定します。

(全然まともな意見が出てこないという状況は、会議の準備含む進行に問題があることが多いです。)

なぜ意見を言ってほしいのか

意見を言わない人がいるとどんなことが起きるでしょうか。

  • 後から「本当はXXがいいと思っていたのに」と言われる。
  • 全員の合意がとれないのでどこかに歪みが出てきて最適化が進まない。

簡単にいうと、会議の存在意義が崩れるということだと私は考えています。

まずは会議の人数を適正にしましょう。 一般的に10人を超えると全員が意見を言うのは難しくなってきます。 私は過去の経験から、6人程度が最適だと考えます。 会議の形式や内容に合わせて考えてみてください。

それではここから 全員に意見を言ってもらうために、意見を言わない人を巻き込むためにどのような方法があるのかを書いていきます。

方法

役割を割り当てる

「実は次の会議で Aさんには XXXといった視点から意見を言っていただきたいのでご参加をおねがいします。」

立場によって言い方は異なりますが、上のようにして”なにをしてほしいのか”をあらかじめ伝えておきます。 このようにすると 意見の出し方、 会議の見方がわかりやすくなり、 意見を言いやすくします。

事前に考えを聞いておく

事前にそのメンバに「XXについてどう思いますか？」と個別に聞いておきます。 すると、もし会議で意見が出なくても「AさんはXYZという考えをお持ちでしたよね。」という切り口で話を広げていけます。

事前課題を与える

なにもないところで考えても拠り所がないので何も出てきません。そこで事前課題を与えます。「XXについて2つ、3つ解決法を考えてきてください。」といった課題を出しておきます。 会議の中では事前に用意した意見をもとに話を深めていくことができます。

事前に資料を読んで準備をするのは当たり前じゃないか、と思うこともありますが、言われないと一切準備をしない人もいるものです。

少人数ワークショップ

人数が多いときに特に有効です。 3人1組にして(または各個人単位で)ポストイットに意見を書いてもらいます。 こうすると、全体の中ではなかなか発言できない人でも意外と意見を書いたりします。 書いてもらったポストイットはホワイトボードに貼るなどして 議論を深めていきます。 ツールの名前でいうと、親和図というのにつながっていきます。

それぞれの意見(または選抜もしくはカテゴライズされた意見)について議論を深めることができるので、なかなか話さない人からも「これってどういうことですか？」というように話を引き出すきっかけを作れます。

ポストイットに書く方法は 3人1組 で話しながら意見を書いていくスタイルもありますし、 各個人で書く時間を作るスタイルもあります。

専門領域のことを聞いてみる

いろんな部署の人が集まっているとします。 そういった場合に「Aさん これはXXXの観点からみるとどうでしょうか。」と聞いてみます。 答えが得られたら「ありがとうございます。なかなかこの専門知識のある人がいないので助かりました」と伝えます。 こうやって参加しない人を巻き込んでいきます。

使える会議の種類は限られてくるかもしれません。

ルールにする

「全員発言する」というルールを作ります。 言えと言われて言えるものではないので効果は薄いと思っているのですが、 ルールにすることで「自分も言わなきゃ」という意識を持たせることができます。

次回に期待

手を尽くしても発言が出てこなかった場合、その人に対して「ちょっと会議での様子が変だったのですが何かありましたか？」と聞いてみます。 言い方に気をつけないと危ないのですが、このようにして会議で発言してほしいという気持ちをソフトに伝える方法です。