プログラマ向けMacの不要なファイルを削除するためのコマンド

git や homebrew などに言及しているので「プログラマ向け」と書いてますが、別にプログラマじゃなくても人によっては有用と思います。

現在のドライブ使用量の確認

コマンドじゃないけど、グラフィカルに全体の使用量とその内訳をみたい場合はGrandPerspectiveというソフトが便利。

ドライブ全体
$ df -h
現在のディレクトリ以下の合計サイズ
$ du -sh
現在のパス以下の全ディレクトリを容量順にソート

ファイル数が多いとそこそこ時間がかかる。

$ du | sort -n
現在のディレクトリの全ファイルを容量順にソート
$ ls -lShr

ファイルの圧縮

現在のディレクトリの全ログファイルを gzip 圧縮
$ for file in `ls *.log*`; do 
gzip -c ${file} > ${file}.gz
done

キャッシュや古いファイルなどの削除

※実行は自己責任で。

Maven のリポジトリを削除
$ rm -rf ~/.m2/repository
Git の不要なオブジェクトを削除
$ git gc
homebrew でインストールしたファイルの古いバージョンを削除
$ brew cleanup

brew cleanup -n で dry-run 実行できるので、まずはこちらを実行した方がいい。
パッケージを最新版にしていないと cleanup できないので、普通は brew doctor → brew update → brew upgrade → brew cleanup とする流れになる。
全部のパッケージを一斉にアップデートして古いバージョンを削除するのはリスクがあるので十分注意すること。
慎重に実行するのであれば brew <コマンド> <パッケージ名> などで一つづつ作業していった方がいい。

最終手段

個人情報を巡る政府と企業の関係

前回の記事で紹介した、The Economistの政府対企業の特集の記事の1つに、個人情報関連の記事があったのでこれも要約してみました。


個人情報関係の情報を追いかけている人にとっては目新しい内容ではないですが、「政府と企業」という特集の中でわざわざ一つの記事として扱っていることから、The Economist もこの問題が非常に重要だという認識なのでしょう。


翻訳ではないので結構省略したり別の表現に変えたりしています。
興味のある人は原文を読みましょう。


原文: http://www.economist.com/news/special-report/21596668-governments-relationship-tech-sector-hideously-complicated-looking-both-ways

インターネットは、かつてないほどの偉大な個人情報バンクを生み出した。
多くの人々は、初めはインターネット上で買い物をするのを嫌がっていたが、今ではすっかり慣れてしまい、自分の好き嫌いや、写真、名前、友達の詳細をソーシャルメディアに公開するまでになった。
このようなデータはターゲティングのようなマーケティングを行いたい企業にとっては非常に貴重である。技術の進歩のおかげで、企業はどのような傾向をもつ人でも見つけ出すことができる。


しかし、誰がデータの安全性に責任を持つべきか、そしてデータの用途に制限をつけるべきかどうかという重要な問題も生まれてきた。
インターネット黎明期に政府はこの問題に注目したことがあったが、最近の欧州における新しい法律のドラフトはその当時に比べてはるかに重く厳しい内容である。
この法律の対象となる全ての企業は、概算で8万ユーロはかかるデータ保護担当官を任命しなければならなくなる。
5000点以下の個人情報しか扱わない会社は免除されるものの、たとえ小さな顧客メーリングリストでさえこの制限を超えてしまうだろう。
ドイツでは、16の州それぞれが独自のデータ保護の理事会を持っていて、それぞれ別の法律を施行している。バイエルン州では全てのwebサイトはユーザが匿名のままでいることを許容しなければいけないが、これはFacebookのユーザにとっては問題である。自分の名前でログインしないといけないからだ。


政府はこうした問題に対し、消費者の権利を示す一方、安全保障のために企業がデータを提供することも期待している。
さらにはメールや電話なども直接監視している。こうしたデータはテロリストや脱税を監視するのに便利ではあるが、反体制派を監視することもできる。
また、データを盗み出されるリスクもある。この問題についての議論はスノーデン事件によって激化することとなった。
国家が信用できないのであれば、民間企業もまた信用できない。
民間企業の中にはサイバー攻撃を受けたり何らかの事故によって大量の顧客情報を流出した企業もある。
企業は信用の失墜とブランドイメージの毀損を避けるため、こうした問題を解決する必要がある。
また、企業は政府からの情報公開の要請に歩み寄ろうとしている。
Appleは昨年31組織もの政府機関から情報の要求を受けたことを公開した。その大半は米国政府である。


(原文には2013年上半期の先進諸国政府による、主要webサービス、GoogleやAppleなど、への情報開示要求についての表がある)


インターネットが人々の生活により深く浸透するにつれ、このような問題は急激に重要になっていき、多くの疑問を生み出すことになる。
Twitterのようなサービスプロバイダは攻撃的なメッセージに対して責任を持つべきなのだろうか？
オンラインでの児童虐待に対し、それらの懸念されるサイトの多くがオフショアで運営されていることを鑑みたとき、何ができるだろうか？


インターネットはグローバリゼーションの究極の事例である。
常に新しくサイトがどんどん生まれていくインターネットを監視するのは非常に困難である。
そして反政府主義者から企業の名前に傷をつけたい不満のある消費者まで、誰もが武器として使用することができる。


インターネットとは、言論の自由、プライバシーの権利、そしてイノベーションの自由などの異なる原理が衝突する場所である。
これらの原理のトレードオフはそれぞれの国や個人によって話し合われなければならないが、相互接続した世界では誰もが満足のいく答えは出ないだろう。

The Economist で企業対政府についての特集

The Economist の2月20日号で、企業対政府についての特集がありました。

以下、ざっと要約してみました。自分なりの解釈も入ってるので、原文にない情報が含まれている可能性があります。

正しく引用したい場合は原文を参照してください。

企業と政府の関係は敵対的になりつつある。しかし、両サイドとも互いを必要としている。


米国政府はセオドア・ルーズベルトの時代から、強くなっていく企業を制限していくような流れを作っていった。
こうした敵対的な雰囲気は増加の一方をたどるが、しかしあまりに強い制約は経済の活性化を阻害するため、政府は企業を必要以上に圧迫できない。
一方で企業も政府を必要としている。政府は、法システムや基本的な安全保障だけではなく、企業の根幹をなす労働者を教育したり、交通などの社会インフラを整えたりしてくれる。
それだけでなく、インターネットや人工衛星など、企業が商用製品を作るのに必要な多くの科学的研究を行ったりもする。
多くの業界において、政府は主要顧客でもある。防衛産業は典型例であるが、製薬業界なども国民厚生サービスなどが大手の顧客である。建設業界も政府の活動に強く依存している。


もしかすると、現在一番厄介な関係はハイテク産業と政府かもしれない。企業の顧客の一部が、政府がその企業のデータにアクセスしたり、企業のデータの使い方に制限をかけることに不安を感じている。
企業は顧客の側に立つのか、それとも政府の側に立つのか？


もう一つの複雑な問題は、企業と政府の両方によって市民に提供される福利厚生である。例えば、多くの政府は産休を拡大することを要求しているが、これは大企業には実現できても、中小企業にとっては実現がより困難なことである。有権者は税金の増加を嫌がるので、政治家は企業負担で福利厚生の向上を行おうとする。


大企業は政府とうまく付き合っていく必要があることを認める一方、政府は一部の大企業、例えば航空会社などを他国の買収から保護するなど優遇措置をとっている。


このレポートでは富裕国における企業と国家の関係について報告する。税金の役割、規制、競争についての政策、ハイテク産業がなぜ特別なのか、ロビー活動などについて議論する。


ここ最近、企業対政府という構図について特に興味を持っていたので、このレポートは非常に興味深いものでした。
多国籍企業は金銭的にも入手できる情報量も平均的な国家を上回っていて、しかも地理的制約が非常に緩いため、いずれ企業は国家を凌駕するのではと思っているのですが、やはりそう簡単にはいかないようですね。

Confluenceの稟議書機能を使う

Confluenceには稟議書というブループリントがあります。
何らかの意思決定をしなければいけないときに、議論をするためのページを作るためのテンプレートですが、地味に便利です。

意思決定に必要な情報が多い場合、チャットだけではそうした情報を正しく把握しながら議論するのが困難なので、私のチームでは稟議書ブループリントを活用しています。

以下のような情報を入力して作成しています。

  • ページタイトル
    • 「◯◯するかどうか」「◯◯の対処方法」など、意思決定に対する質問形式で作成する
  • 背景
    • 「◯◯するかどうかを決定するにはいくつかの問題について検討する必要がある」「◯◯の対処方法にはいくつかある」などの概要を書く
  • 選択肢とメリット・デメリット
    • 「選択肢1: 実行する」という形でいくつかの選択肢を並べ、それぞれについてメリット・デメリットを記載する。
  • 論点
    • 選択をするにあたって、どの部分が論点になるのかをまとめておく。


意思決定に参加する人はコメント欄で以下のような形式で入力していきます。

選択肢1に賛成。なぜなら、(以下論点についてのの主張を説明)


もちろん、議論の中で新たな選択肢や論点、それに既存の選択肢や論点の不備などが出てきますので、その都度説明を修正していきます。


注意点は2つ。

  • 意思決定するまでもないことについて、周囲からの承認を得るためだけにするような稟議は無駄なので上げない
  • 関係者以外は意思決定の場に呼ばない

2013年面白かった本

雑記

今年面白かった本をあげてみました。
専門書は省いています。
あとここに紹介してない本でも面白い本はたくさんあったのですが、さすがに全部は書ききれないので一部にとどめます。

果て無き渇望

本当にいい本でした。私が果て無き渇望アドベントカレンダーに参加したことからも、どれだけこの本に感銘を受けたか分かるでしょう。(アドベントカレンダーの記事)

文庫　果てなき渇望 (草思社文庫)

文庫　果てなき渇望 (草思社文庫)

カラシニコフ

先日亡くなったばかりのカラシニコフですが、製作者ではなくAK-47カラシニコフ銃によって引き起こされている様々な問題(アフリカの少年兵など)を書いたノンフィクション。
カラシニコフがなぜ広まったのか、広まったことでどういう問題が起きているのかなどが書かれています。
実はこの本を読むまで、カラシニコフって第二次大戦中に開発された銃だと思ってました……。

カラシニコフ

カラシニコフ

なぜデザインなのか？

デザインとは何か、ものづくりとは何かということについて語る、原研哉と阿部雅世の対談。
こう書くと芸術の話ばかりにように思うかもしれませんが、ほぼ全ての仕事してる人に役に立つ話だと思います。
大抵の人は、何らかの成果物を出すことを仕事に求められますからね。

頭の中にあるイメージを外に出す、感じたことを外に出すということを、抵抗なくスムーズにできるのがドローイングでありスケッチなんです。
「自分がしでかしてしまうこと」に対して、平気になれること。
(p.23)

なぜデザインなのか。

なぜデザインなのか。

東京至極のレストラン2013年版

やはりこれは外せません。とにかく私のツイートまとめを読んでください。

東京 至極のレストラン 2013年版 (SEIBIDO MOOK)

東京 至極のレストラン 2013年版 (SEIBIDO MOOK)

ロボット兵士の戦争

単に「ロボットが戦争で使われているんですよ」で終わるのではなく、ロボットが戦争に必要とされるようになった経緯、ロボットの投入によりどう戦争が変わるか、それも戦場だけでなく戦争を行う政府、戦争を「観戦」する一般市民などがどう変わるか、ロボット兵団の指揮官に求められるスキル、戦時国際法の変化などについて書かれています。
分厚いですが読み応えはあります。

ロボット兵士の戦争

ロボット兵士の戦争



援デリの少女たち

現代の援助交際「援デリ」についてのノンフィクション。こういう話が苦手な人は読まない方がいいです。
拠点を持たずにマクドナルドなどにたむろし、足のつかない携帯電話一つで組織的に「援助交際」を行う人達の話。社会の闇が描かれています。

援デリの少女たち

援デリの少女たち

ビッグデータの正体

仕事に関係のある本を紹介するつもりはなかったのですが、この本だけは例外。
著者は 2010年2月 に The Economist でビッグデータ特集を書いた人です。
この特集こそ、世界にビッグデータブームの火をつけた特集であり、私がこの業界に足を踏み入れることになったきっかけの特集です。その時の感想記事はこちら。

本の中身も素晴らしく、きちんと本質をとらえた内容でした。
「ビッグデータって何？」って人はまずこの本を読みましょう。

ビッグデータの正体 情報の産業革命が世界のすべてを変える

ビッグデータの正体 情報の産業革命が世界のすべてを変える

鬱ごはん

今年のベストコミックです。
「このマンガがすごい！2014」の第9位にオンノジがランクインした施川ユウキですが、私はこちらの作品の方が好きです。

就職浪人兼フリーターの鬱野たけしが、日々食べる食事について語っていくという話。こう書くと孤独のグルメに似ているように聞こえますが、孤独のグルメはどことなくかっこよさが見えるのに対し、こちらはひたすら孤独。また、出てくる食べ物が基本的にまずそうです。色々な意味で食べ物系の常識を覆してます。鬱野自身「何を食べてもおいしく感じない」と言っています。


表現が非常に秀逸で、この描写は一度クセになったらやめられません。

私が好きな話は、松屋の豚焼肉定食の話です。
就職浪人の状態を「毎朝、堕ちていく飛行機の中で目が覚める気分だ」と思いながら松屋に入り、豚焼肉定食を頼みます。そして出されてきた料理を「堕ちていく飛行機で出される機内食だ」と表現します。

初めて読んだときは本当にすごい表現だなと思いました。

興味があれば是非読んでほしい一冊です。

鬱ごはん(1) (ヤングチャンピオン烈コミックス)

鬱ごはん(1) (ヤングチャンピオン烈コミックス)

声に出して読みたい「果て無き渇望」名文10選

雑記

果て無き渇望アドベントカレンダー、15日目担当の shiumachi です。
本書の概要についてはymotongpooの素晴らしい記事があるのでそちらに譲ります。
ここでは、私が個人的に気に入っているフレーズをピックアップして紹介します。
トレーニング前に読むと元気が出る、そんな名文を拾ってきました。


「だれだって、トレーニングさえすればこんな身体になれます」
(果て無き渇望 p.11)

「いいですか、僕の言いつけを守ってください。ひとつは本気になってやること。ふたつは継続すること。三つ目は合理的に正しいトレーニングをすること。これさえ守れば、たとえ週二回でも必ず筋肉はつきます。あなたもいつかはこうなります」
(果て無き渇望 p.13)

運動生理学には「ルーの三原則」と呼ばれるものがある。筋肉は使うと発達する、使わないと衰える、使い過ぎても衰えるというものだ。
(果て無き渇望 p.346)

「いつも、トレーニングしている自分と別の自分がいるんです。そいつが、もう一回できるだろう、もう一回挙げてみろって応援してくれるんですよ」
(果て無き渇望 p.81)

ボディビルダーにとって減量や家族の犠牲、食事の苦労、社会性のなさなどは、それだけ自分がトレーニングに没頭しているという勲章ですよ。突き詰めれば自慢話なんです
(果てなき渇望 p.65)

「ボディビルダーにとって、筋肉がもたらしてくれる最大の意義は、自信ではないでしょうか」
(果て無き渇望 p.69)

自分の将来がどうこうとか、そんな先のことは考えてもいないし、考えられない。考えちゃうような人は、その時点で負けね
(果て無き渇望 p.134)

ボディビルにとってステロイド剤というのは、原爆みたいなものなんです
(果て無き渇望 p.257)

ボディビルは数学の方程式を解くのに似ている。正しいやりかたで順序だてて解析すると、必ず正解にたどりつく。
(果て無き渇望 p.246)

「自分はただひたすらに大きくなりたい。天から与えられた身体を、自分の意志の力で変えていく。筋肉を一センチ肥大させることで自分が神に近づけるわけではありませんが、少なくとも自分の肉体という小宇宙を創造することができる。たとえ後遺症が襲ってきてもかまわない。どんな手段を使っても、限りなく肥大した筋肉を手に入れたい。ただ、それだけなんです」
(果て無き渇望 p.229)

文庫　果てなき渇望 (草思社文庫)

文庫　果てなき渇望 (草思社文庫)

HBase 0.96 で導入される新しいコンパクション「Exploring Compaction」

雑記

Hadoopアドベントカレンダー2013、3日目を担当する @shiumachi です。
今回は HBase 0.96 の新機能を一つ紹介します。

要約


HBase 0.96 は賢くなったのでみんな使おう。

コンパクションのおさらい


HBase では、Log Structured-Merge tree (LSM-tree) というデータ構造を使っています。
LSM-tree を簡単に説明すると、入力されたデータをログとメモリ上のデータストア(Memstore、メモリストア) に書き込みます。
メモリストアがいっぱいになると、まとめてディスクにフラッシュし、新しいストアファイルを生成します。
このストアファイルがたまってきたときに、少しづつ一まとめにしてなるべくファイル数を少なくするようにします。これがコンパクションです。


コンパクションを実行することにより、ファイルは一つにまとまります。これにより、ディスク上の連続した領域にデータをまとめることができ、ディスクシークの回数を少なく保った上で予測可能にできます(最大でストアファイルの数と同回数だけ)


しかし、このコンパクション操作は非常に重い処理になります。
コンパクションを単純に説明すると、ディスク上のストアファイルを読込み、新しいストアファイルに書き出してマージしていくというものです。これだけで多大なディスクの負荷がかかることが分かるでしょう。
また、HBaseは普通HDFSを始めとした分散ファイルシステムをストレージとするため、ネットワーク転送も発生します。
かといってコンパクションを実行しなければ、ストアファイルが多くなり、一度のキーのルックアップに必要なディスクシークの回数が増え、やはり性能が劣化します。
現在のディスクIOと将来のディスクIOのトレードオフを考えることが、コンパクション戦略に必要となります。しかし、将来どれだけのディスクシークが発生するかは誰にもわかりません。そのため、ヒューリスティックな手法で現実解を求めていくことになります。

HBase 0.94 までのコンパクションアルゴリズム


コンパクションには2種類あります。メジャーコンパクションとマイナーコンパクションです。
メジャーコンパクションは、全ストアファイルを読み込んで一つのストアファイルに書き出していく(まとめる)処理です。このとき、以下の条件に当てはまるキーバリューのみを書き出します。

  • tombstone マーカーがついていない ( delete されたときに付与される、論理削除のマーカー)
  • TTL (生存時間) が残っている
  • バージョンが最大バージョン数を超えていない。例えばバージョン保持数が3のとき、4つ前のバージョンのセルはこのタイミングで物理削除される


もう一つはマイナーコンパクションです。今回の記事ではこちらの方に注目します。
マイナーコンパクションは、たくさんあるストアファイルのうち、あるアルゴリズムに基づいて抽出されたファイル群のみを一つにまとめます。このとき「なるべく小さいファイルを(ディスクIO低減のため)、なるべく多くの数(将来のディスクシーク数低減のため)コンパクションする」ことが重要となります。

まず、ストアファイルが一列に並んでいるとします。左のファイルの作成時刻が一番古く、右に行くにしたがって新しくなるとします。

  1. 1番左のストアファイルを選択する( F0 とする )。F0 のファイルサイズを S0 とする。
  2. F0 より右の全ストアファイルのサイズの和 S(1_N) を求める。
  3. もし S0 > S(1_N) * hbase.hstore.compaction.ratio (デフォルト 1.2) なら、選択ストアファイルを1つ右にずらし、同様の手順を実行する。
  4. もし S0 < S(1_N) * hbase.hstore.compaction.ratio (デフォルト 1.2) なら、F0 の一つ右のファイルから最大 hbase.hstore.compaction.max 個(デフォルト10) のストアファイルをコンパクション対象とする。
  5. もしコンパクション対象数が hbase.hstore.compaction.min 個 (デフォルト 3) より少なかったら何もせずに終了。
  6. コンパクション対象のファイル群をコンパクションして終了。


具体例が hbase bookのコンパクションのページ に載っています。


たとえばストアファイルのサイズが 100、50、23、12、12 と並んでいる場合、23、12、12 がコンパクションされます。
ここで注意しなければいけないのは、ファイルのソートはあくまで「作成日時」です。サイズではありません。
このアルゴリズムは、「ほとんどの新しいファイルは古いファイルより小さい」という前提に基づいています。


ストアファイルはメモリストアのフラッシュによって作成されます。このフラッシュ上限は決まっていて、hbase.hregion.memstore.flush.size (デフォルト64MB) * hbase.hregion.memstore.block.multiplier (デフォルト2) = 128MB となります。
古いファイルはコンパクションされていて大きくなっているはずなので、この前提は多くのケースにおいて成り立ちます。


しかし、当然成り立たないケースもあります。
例えば HBase のバルクロードは、ストアファイルを直接 HBase のリージョン内に配置する方法で、非常に高速にデータをロードできるのですが、新しいファイルなのに非常に大きいストアファイルをロードすることになり、上記の前提を崩してしまいます。
先程紹介したアルゴリズムは、あくまでコンパクション対象の最初の一つしか判定を行いません。アルゴリズム内で条件を満たしたストアファイルがあれば、そこから一定数のファイルを自動的に取り込みます。
これにより、この大きなストアファイルがあると、より古いファイルはコンパクション対象として判定されてしまいます。こうして大きいファイルがマイナーコンパクションの対象になってしまう可能性が高くなるわけです。

新しいコンパクションアルゴリズム


そこで 0.96 からは、Exploring コンパクションポリシーという新しいアルゴリズムをデフォルトアルゴリズムに採用しました。(HBASE-7842)



基本方針は単純で、「可能性のある組み合わせ全部計算して最適なものを選ぶ」です。
コンパクション対象を検索するところまでは既存のアルゴリズムと変わりません。
検索した後、以下のようなアルゴリズムで最適解を選んでいきます。

  1. コンパクション対象となった最初のストアファイルを F1 とする。
  2. F1から右に min 個以上 max 以下の連続したストアファイルを全て吟味していく。(デフォルトだと3〜10個) つまり、F1〜F3の組み合わせ、F1〜F4の組み合わせ、……というように吟味していく。
  3. このうち以下の条件に当てはまるものを選択する。
    1. 最も対象ストアファイル数が多い
    2. もしストアファイル数が同じものが複数ある場合、最もファイルサイズが小さい


これにより、バルクロードを用いている環境でも無駄なIOを生じることなくマイナーコンパクションを行うことができるようになりました。
この機能は、プラガブルコンパクションポリシーという HBase 0.96 から導入された新しい機能を前提として実装されています。(HBASE-7516)


今後、より効率のいい、あるいは特殊な状態に特化したコンパクションポリシーなどが実装されていくことでしょう。

おまけ: CDH の話


CDH5 では HBase 0.96 ベースになると思われますので、Exploring Compaction はデフォルトでオンになっています。
実は CDH4 でも使用することができます。CDH4.4 で、HBase 0.94 に Exploring Compaction をバックポートするパッチが入っています。(HBASE-8283)

githubのコミットログ


HBase 0.94 にはプラガブルコンパクションポリシーがないため、コンパクションのコードにそのまま追加しています。
デフォルトはもちろんオフです。
hbase.hstore.useExploringCompation を true にすると使うことができるため、興味のある人は試してみてください。

参考文献