機内持ち込みオンリーで海外旅行する人の荷物Tips

出張で一週間フィリピンに行きました。ここ数年、毎年一週間ほど海外に行ってるんですが、常に機内持ち込みのバックパックのみです。そこら辺のノウハウが溜まってきたので共有します。

そもそもなぜ機内持ち込みのみで頑張ってるのか？

  • どのサイズのスーツケースを買うか悩みすぎている
  • スーツケース無しでなんとかなってるし、今回も買わないでいいか、という結論に達してしまう
  • 荷物待ち無しは気分が良い
  • 荷物が少ないのも気分が良い

荷物

バッグ

これです。35L。

f:id:fujimuradaisuke:20140819164555j:plain

特に不満は無い。PCも入るし。普段から使ってる。35Lが機内持ち込みの限界サイズだと思う。縦に長いと持ち込めないので気をつけて。

衣類

仕分けケースに入れる。それを圧縮袋で圧縮する。ZiplocでもOK。汚れた衣類はZiplocに入れて、圧縮する。そのために空のZiplocを数枚持っていく。仕分けケースは無印にいい感じの色のがある。Ziplocはフリーザーパックのほうが強い気がする。

下着は速乾のもの。ホテルのバスルームで一日で乾きます。 綿100%の洋服は着ない。なぜなら、乾かないから。デニムとか履きたくなるけど諦める。Tシャツも綿ポリのを選ぶ。シャツは必要がなければ持っていかない。

靴はお気に入りを履いて行くとテンション上がって良いです。サンダルはゴミ袋に入れて持参する。ゴミ袋は多めに持ってると何かと便利。

本

フィジカルな本が必要な場合はフライト中の時間を潰せそうな量だけ持っていく。もし暇になったら…とか考えちゃダメ。そんな事は起こらない。旅先で気合いを入れて読書する予定があるなら別だけど（今回はあったのでこれを持っていった）。軽めの純文学がページあたりの消費時間量も多いのでオススメ。Kindleに読みたい本があるならそれがベスト。

今回はこれでした。面白かった。Los Pepesの話とか出てこなかったな…。

紙

ホテル・フライトの予約はプリントアウトしておく。直前に家にプリンター無くて困るってパターンが多いので、早めにやっておくべし。パスポートのコピーもしておく。

パスポート

空港ではチケットと旅程のプリントアウトを挟んでポケットに直接入れる。それ以外はコピーを持ち歩く。

お金

ちょっとだけ両替しておいて、あとは現地のATMでキャッシングする。

個人用の名刺

常に持ち歩く。あらゆるところで。予期せぬ出会いがあるので。

サングラス

日本より日差しが強い国はけっこう多いのでマスト。

財布とかを入れる小さいバッグ

これは今回の反省。水着にポケットがなくて財布・携帯・鍵が入れられませんでした…。 こういうので良いんじゃないかなと。

化粧水

空港の無印良品で小さい化粧水を買って持って行ってます。全身に使う。ホテルの石鹸が強い時に役に立つ。日焼けした時も使える。

もう一つの財布

国内用と別のを持っていくと詰め替えが楽。激安のを買う。

耳栓

安眠の友。フライトもだし、ホテルがうるさい場合もあるので。カナル型イヤフォンがあっても、音楽を聞きたくない時もあるので、別途持っていたほうがよい。空港で買えます。

アイマスク

フライトが長い場合はあると良い。耳栓とアイマスクして入力を減らすとかなりリラックスできます。空港で買える。

RSpec実行にまつわる小ネタとDSLについてのボヤキ

変更されたファイルのみ実行

$ bundle exec rspec `git diff --name-only`

インタラクティブに対象を選んで実行

peco便利。

$ bundle exec rspec `git ls-files | peco`

そういえば、最近GuardやListenで自動実行しなくなってしまった。理由は特にない。

RSpecの変化が速すぎてついていけない。常にRubyを書いているわけではないので（JavaScriptが多くて常にRubyを書いているわけではないので、rspec-mocksも含めると気がつけばAPIが変わっていて、毎回ググっている。APIが安定しないライブラリは辛い。

そもそも、凝ったDSLを覚える事自体が辛い。特定のDSLの理解は再利用性が低いのが良くない。覚えても、そのライブラリ・フレームワークを使えるようになるだけという応用の効かなさが悲しい。逆に言語仕様への理解は再利用性が高い。当たり前だけど。書かれたコードをより深く理解できるし、自分で書くにあたっても、その表現力を活かせる。

ということで、凝ったDSLの学習は最小限にしたいなー、と思っております。

『パーフェクト Ruby on Rails』は本番Railsアプリの完成度UPに良いと思う

"Startup Java"と揶揄されるくらい定着したウェブアプリケーションフレームワーク、Ruby on Rails。情熱的なRubyコミュニティ、スタートアップ業界中心の圧倒的な需要が合わさって、巨大なエコシステムが形成されました。チュートリアルや入門書も充実して、すっかり始めやすいフレームワークになった感じです。

けど、プロダクション・クオリティのものを作るに当たって完成度を上げていくための情報って案外まとまってなかった印象があります。例外通知とか、CIの整備とか、プロビジョニングとか、モデルを整理する方法とか。『パーフェクト Ruby on Rails』はそこら辺がカチッとまとまってます。 ガチRailsエンジニアのいないスタートアップでコードの品質あげる、とか、ぴったりだと思う。

あと、RubyもWeb開発もある程度わかるんだけどRailsが巨大過ぎて手を出せてない人。Railsの概要、Rails的なMVC、実際のアプリケーション開発の流れ、周辺ツールがギチギチっとまとまってるので、全容を把握するのにはちょうどよいのではないか。

あと9章。昔こんな事をつぶやいていたのを思い出した。

これまじです。非ActiveRecordなフォームを作る時は絶対やったほうがいい。最近はActiveModel::Modelがあるから楽なはず。

Service Classについては、意味的にしっくり来る名前が見つかった or 自分以外のModelに副作用を起こし始めた場合に切り出す、ってのが個人的なルールかなあ。リソース名に収まるまでよい抽象化（要はネーミングですが）を諦めない、とか。

って感じで、とても楽しく読ませて頂きました。@udzura さん献本ありがとうございました！

トレードオフの罠

デザイナーとかプログラマーという職業の特殊なところは、創作活動に近い面を含んでいる、ということだと思う。完全にその言葉が相応しいとは思わないけど、アーティストに近い面があるとも言える。実際、高い完成度や生産性を目指して、単なる仕事の枠を超えた情熱をもって手を動かし続けている人がけっこうな数いる。そして、それが往々にして本人や組織の強みの源になっていたりもする。

実際の事業の中では、クオリティと時間・人・予算の間のトレードオフが常に発生する。あくまで事業としては、製品の品質はそれ事業の中で果たす役割を全う出来る程度であれば良い。専門家として目指しているクオリティに達する必要がない場合もある。グリッドが多少狂ってても、やたらアドホックな実装が残ってても、必要な役割を果たせていれば十分なのである。

ここにジレンマがある。トレードオフだ何だと言ってクオリティに妥協し続けていると、そのうちクオリティに対する感度が麻痺してくる。何が良いものなのかわからなくなって、良い物を作れなくなってしまう。麻痺するとそこそこの物を作るのが上手になるかというとそんな事もないので（理想がないとトレードオフはできない）結果的にアウトプット全体の平均点が下がっていってしまう。

うーん。これはどうすればいいのか。

最近読んだ本 2014/06

柚木麻子『終点のあの子』

青春時代にあるちょっとしたボタンの掛け違えで人生のものすごく大切な何かを失う出来事が描かれる。 で、今自分には30台独身男子の目の前にある限りの人生しか見えなくなっているのに気がつく。あのころ視界に広がる空間は、見えているものが何なのか、よくわかってはいないけど、とにかくあっけらかんと広かったような。 回収が、ベタだけど美しい。

マイケル・オンダーチェ『名もなき人たちのテーブル』

数週間の船旅の中でいくつもの人生が交わる様子が描かれる。思春期を迎える子供ってこういう風に全てが鮮やかに見えるんだよな。静かな文体のわりに一気に読ませるので策士。

エンリコ・モレッティ『年収は「住むところ」で決まる 雇用とイノベーションの都市経済学』

クリエイティブ資本論の焼き直し。

岩本繁『経営分析の知識』

財務諸表をもとに経営を分析するためのツールと実例が展開される。地味だけどタイトで好感の持てる本。サラッとでも財務諸表が読めると、転職時に会社を調べるのにすごい便利。あと、経営に近い所で仕事をしていた人は実感をもって面白く読めると思う。ただ一切会計の知識がない状態だと辛いかも。

ファイル毎の総追加行数・総削除行数を出すGitのサブコマンド、git-freqをリリースしました

プロジェクトが一段落して「どの機能が一番大変だったのかな？バグが多かったのは？」という情報を知りたくなりました。ということで、ファイル毎の総追加行数・総削除行数を出すGitのサブコマンドを作りました。

https://github.com/fujimura/git-freq

http://hackage.haskell.org/package/git-freq

$ cabal install git-freq でインストールできます。Haskellの環境が必要なので、お持ちでなかったらHaskell Platformをインストールしてください。

結果はcsvでファイル名、追加行数、削除行数の順に出力されます。 Lensの2587bb01だとこんな感じです。

$ git freq | head
src/Control/Lens.hs,5365,5263
src/Control/Lens/Fold.hs,5885,3471
src/Control/Lens/Internal.hs,4205,4123
src/Control/Lens/Type.hs,3493,2869
src/Control/Lens/TH.hs,3530,2066
src/Control/Lens/Setter.hs,3097,1846
src/Control/Lens/Internal/Zipper.hs,2432,2436
src/Control/Lens/Traversal.hs,2846,1628
src/Control/Exception/Lens.hs,2646,1697
src/Control/Lens/Plated.hs,2395,1715

本来は機能ごとに変更を計測したくて、GitHubのタグをAPI経由で取得して…と夢は広がったんですが道のりが遠そうなので、とりあえずファイル別に見れればよいかなと思い。

実装はgit log --numstatを合計してるだけです。 IOを型クラスで抽象化してテスタブルにする、ってのが出来たのが嬉しいです。

たぶんドキュメントとかサードパーティーのライブラリとか、測りたくないファイルが結果に出ちゃうと思うんですが、そういう場合はこんな感じで絞ればOK。Ruby on Railsのa6c8cde、ActiveRecord部分の様子です。

$ git ls-files activerecord |grep -v html |xargs git freq
activerecord/CHANGELOG.md,12854,12126
activerecord/lib/active_record/base.rb,10026,9703
activerecord/lib/active_record/associations.rb,9331,7615
activerecord/test/cases/migration_test.rb,5384,4486
activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb,4829,4085

CHANGELOGが一番更新が多い。しっかりしてますね。

問題点としてはファイルを移動すると変更量がリセットされてしまう点です。仕方ないか。あと歴史の長いリポジトリだとgit log --numstat自体が結構時間かかるので、遅いです。 次は日付毎に変更量を取れるようにしたいなって思ってます。

ファイルごとでも合計が取れると結構面白いですよ。あ〜ここが辛かったんだな、とか。プロジェクトが一段落したらgit freqして、振り返ってみてはどうでしょうか。