映画で思い知る子供の頃と大人の今の獲得情報量の違い
風邪を引いてしまい、超楽しみにしていた後輩との飲み会をキャンセルして家に帰って寝込み始めた頃合いに、テレビをつけると「紅の豚」が金曜ロードショーでやっていた。
体調の悪さとテレビの内容からにわかに幼稚園〜小学校低学年の時代を思い出した。
その時代は頻繁にひどい風邪を引いて、昼間は家で寝こんでいるということも多かった。
ベッドの側には小さなテレビとビデオデッキがあって、父が趣味を兼ねて撮り溜めたビデオテープが山ほど積まれていた。
小さい自分のお気に入りはジブリ映画だった*1。トトロとかナウシカとか魔女の宅急便とかをそれこそ飽きるほど見た。もちろん紅の豚も。
だからストーリー全編は一通り頭に入っている。
そのはずなのだけど、いまになって改めて腰を据えて視聴すると、細かい描写とかセリフから得られる情報量が天と地ほども違うことに驚いてしまう。見ている映像はもちろん当時と寸分違わないはずなのに...。
勘違いしていたこと、いまさら気づいたこと
1930年代くらいのイタリア
銀行員に愛国債券をセールスされるシーン、「札束が紙くず並みの値打ちしかない」、「ファシストの秘密警察」、「アドリア海/ミラノ」といったキーワードから舞台がファシスト党の時代のイタリアだということが示唆されている。
が、子供時代はそういうのをよく分からないので、たぶん 海外のちょっと昔の話なんだな？ くらいの認識だった気がする。
女性ばかりで飛行艇をこしらえること
フィオが設計すると言い出したときに難色を示すポルコ、ぞろぞろ工房に入ってくる女性たちに面食らっていたり、「女の手を借りて戦闘艇を作ることをお許しください」というお祈りの文句から女性が飛行艇を作るというのはイレギュラーなことである、そして男たちが出稼ぎで居ないからだという説明がされているが、小さい頃は全然そういうことは疑問に思ったりとかしていなかった。テキパキ食事の支度がされたり飛行艇の部品を作っていくシーンはすごく好きで覚えている。だが、そもそもそれらが女性たちばかりでこなす仕事にしてはイメージが真逆という示唆だと思う。おそらく戦争のにおいが強いとか、野蛮(? めっちゃロマンがあって良いな〜と個人的には思うところだが、世間一般的にはそんな感じなのだろうか)とか、エンジニアリングの要素が強いとか。昔はそういうことをまっっったく気づいて居なかったけど、そういう空気感を読み取れるようになってしまったんだなぁと感じた。
カーチスは空賊の用心棒
てっきりカーチスは空賊の一味だと信じ込んでいた。久々に視聴してちょっと混乱した。
たしかにただの仲間にしては浮いているし青いし雰囲気が違いすぎるし行動がよく分からない。
用心棒という単語を昔は知らなかったんだと思う。
あと今更ながら、むちゃくちゃ惚れっぽいなこの人...なんて感想を抱いた。
フェラーリンさん
映画館でポルコの隣に座って不機嫌そうな感じだった人と、空軍から逃げる方法を教えてくれた人と、最後にジーナに馬鹿騒ぎをやめさせるように連絡した人が全部同じ人だったということは小さい頃は本当に気づかなかった。 それどころか、覚えているのは「映画館でポルコの隣に座って不機嫌そうな感じだった人」で、逃げる方法を教えてくれたシーンは「よく分からないけど手信号で豚に真珠と言い残していった謎の人」で、「ジーナは通信を自分で傍受して危機を察知した」ものと思っていた。小さい頃の自分まじで映画全然見てないじゃん...だめやん...。フェラーリンさんごめんなさい。
最後のシーンはかなり未来
「あれからいくつかの動乱があって」と最後にフィオが静かに語り、その後のホテル・アドリアーノの様子を眺めて映画は終わる。 動乱というのはおそらく戦争とかのことを指しているし、集まっている面々の姿をみると結構老けている。これ10~20年くらい経っているんじゃないだろうか...。しかもフィオの会社のピッコロ社の名前のついた飛行機がよく見たらめっちゃ進化したデザインに変わっている。細かい映像のディテールに小さい頃は気づけなかったのか、病気の時ばかりに見ていたもんで最後は寝落ちしていたかもしれない。改めて気づいた。
その他、会話の端々細かく挟まれる皮肉とか絵に出てこない情報
なんか海外ドラマとかでありそうな皮肉とかが入ってくるけど、子供の頃は基本的によく聞き流していたと思う。 ポルコが怠惰な豚である罪とか猥褻物陳列罪とかひどい余罪をふんだんに付けられていたりとか、会話の中の面白い要素はすべて受け取り損ねていたように思う。
こどものころ、分かった気になっていたけど、まず語彙と経験が足りなかった
昔ベットの中でテレビ画面をじっと見ているしかなかったときは、この映画の隅々まで楽しみ尽くしていたような気がしていたけど、世界は狭かった。あのころ、母にイギリスはどこにあるか知っているかと聞かれて、「イギリスは大国だからきっとこの辺」とアフリカ大陸を指差していたらしい。本当に語彙も経験も何もかも不足していた。 いまの自分も、5年後10年後の自分からみたら、語彙も経験も何もかも不足している状態なのかもしれない。
初心を忘れずがんばらなきゃなぁと思いつつ、いまは風邪をとっとと治したい。
config/localesの中身を考える(小分けが好き)
ソースコードが増えていくにあたって、1ファイルがどんどこ伸びていくか、ファイル数ががんがん増えていくかの2択があるが、自分は後者のファイル数を増やす方がいいと考えている。長いファイルの一部を編集するのはインデントとかのミスのリスクが高いと感じる。
えいやでRails開発していて、I18nを利用していると、config/locales 以下にどんどこファイルができる。 次のようにconfigに設定しておけば、ファイル群を階層化しても読み込みしてくれる。
参考: Rails国際化 (I18n) API | Rails ガイド
# config/application.rb config.i18n.load_path += Dir[Rails.root.join('config', 'locales', '**', '*.{rb,yml}')]
中身のYAMLさえ形式に則っていれば、ファイル名はなんでもよいので、あえてルールでしばらないと1ファイルの中身がもりもり増えていく。例えば開発超初期はモデル数が1,2個だったりして、まぁ分けるまでもないかと思ってこうしたとする。
config/locales
└── models
└── ja.yml
# config/locales/models/ja.yml ja: activerecord: models: user: ユーザ book: 本 attributes: user: name: 名前 book: title: タイトル price: 価格
まだこの時点ではいいかもしれない。では今後開発が進んだらどうなるだろう？
永遠に肥大していく ja.yml とどこかで決別することを迫られることになるはずだ。
config/locales
└── models
├── user.ja.yml
└── book.ja.yml
# config/locales/models/user.ja.yml ja: activerecord: models: user: ユーザ attributes: user: name: 名前
# config/locales/models/book.ja.yml ja: activerecord: models: book: 本 attributes: book: title: タイトル price: 価格
小分けにしておいたほうが参照もパッとできて良さそう、と考えている。
ちなみに、Railsガイドの例では config/locales/models/book/es.rb 、config/locales/models/book/en.rb というようにモデル名をディレクトリ名としてその下に言語別のファイルを格納しているが、基本的にいま自分が関わっているプロジェクトがjaしか見ていないので、ディレクトリ化していない。もしenとjaを併用しなければいけないシーンになったらRailsガイドの通りにネストしたほうがよさそうだ。
オフィスが出来て変わったこと/ごみ処理券
コワーキング時代は気にしなくて良かったものとして、事業系ゴミ処理券の存在がある。 事業をやっているところはゴミを出す際にゴミ袋にこの券を貼って出す必要がある。(これは中央区の例)
20Lゴミ袋用の券が1束10枚綴りで1520円。
10L、20L、45Lと種類も色々あって、サイズによってお値段とシールの色が違う。
普段家庭ゴミもマンションのゴミ捨て場に出すだけなので、事業としてこのようにゴミ処理券が必要という事実を改めて知って、ゴミ削減を意識することが増えた。 コワーキング時代はゴミはまとめて施設の方で対応してくれたので気にする必要がなかった。 色々助けられていたんだなぁとしみじみ感じる...。
とりあえず毎回事業者名のところに名前を書くのが超面倒なのでそろそろ気軽に使える会社名のハンコ欲しくなってきた。
困難は分割せよ(diffを減らしてmergeしていく話)
超小規模エンジニアチーム*1とはいえ、ときにはでかいリリースの必要性に迫られることがあります。 今回取り組んだ機能実装では、3つのmigration、4つのcontrolller、たくさんのviewとテストのファイルを新規作成しました。
ぼっちにしてはめちゃくちゃでかい機能リリースが控えていて胃がｷﾘｷﾘｷﾘｷﾘ
— べーた (@beta_chelsea) 2018年10月23日
ぼっちでやるにあたって、でかいプルリクはでかいというだけでリスクです。見直しにも集中力が必要でしんどいです。 ちょっとでもまともにリリースするため、自分は全体像が完成したら、切り出せそうなところを抽出して先にリリースするようにしています。困難は分割せよという言葉が合いそうだなぁと思います。
多種多様な意見がありますし、将来の自分が見たら考えが変わっていて後ろから刺される可能性もありますが、現時点での自分のやり方を挙げてみます。
まず master ブランチからfeatureブランチを生やします。featureブランチを育てるだけ育てます。このときcommit名とかにはあんまり気を配りません。とにかく80~90%くらいの完成度を目指してcommitを積みまくります。 ほぼほぼ完成に近づいたら全体を眺めます。全体の中から既存の機能に対する変更や、単体で更新できそうな機能(child_a, child_bとします)を考えます。
masterブランチから改めてchild_a, child_bを生やし、抽出できる機能を移植します。
移植には $ git checkout ブランチ -- ファイル名 を使うと便利です。
$ git checkout -b feature master $ git commit -m "バリバリ開発" ... $ git checkout -b child_a master こうするとfeatureブランチから app/models/hoge.rb をとってこれる。 とってきたデータはステージされている状態となっている。 $ git checkout feature -- app/models/hoge.rb $ git status On branch feature Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: app/models/hoge.rb $ git commit -m "hoge.rbだけ取り出して先にリリースするぞ"
この時点でchild_aのdiffを眺めて、もうちょっと良くできないか考えます。 大抵の場合、膨れ上がったfeatureブランチでは見つからなかった問題点や不足していたテストなどに気づき、この時点で手を入れます。 その後、納得できたらmasterに先にmergeします。
$ git commit -m "さらにリファクタしたぞ" $ git checkout master $ git merge child_a
ここで child_a は feature に含まれるものよりもだいぶ変わっている状態です。 変更を取り込むとき、merge派とrebase派がいるような気がするんですが、自分はrebase派です。 何回も繰り返してコンフリクトを修正するのが面倒なので、自分はfeature ブランチに積み上がったコミット群をひとまとめにしてからmasterにrebaseします。
# featureに移動して10件のcommitをひとまとめにしてしまう $ git checkout feature $ git rebase -i HEAD~10 # 全部squashする。歴史はあとで改変する。 # ひとつにまとまったらmasterへrebaseする $ git rebase master # おそらくコンフリクトするので、うまく修正する。
これをfeatureブランチを機能が分解できなくなるまで繰り返し、最後にfeatureブランチの歴史を整えなおして全機能のリリースが完了します。
一通り書き出したけどあんまり分かりやすいとは言えない説明になった。 うーん、図解とかが入れば良かったかもしれない。 Gitで歴史をどうにかするごにょごにょは別途記事にしようかな。
超細かい作業ログをとっている話
1ヶ月で終わると見込んでいた仕事が終わらなかったのを機に、いったい自分は仕事として8時間をどんな風に使っているのかを考え直すことにした。 本当はいい感じのツールでかっこよく整理できたらよかったのだが、自分が求めるものにジャストフィットするものが見つからなかったため、Spreadsheetに頼った。
求めていた機能として、
- 突発的に発生したタスクを書き留めることができる
- タスクに何時間かかったのかを振り返りできる
- タスクの順序をいつでも入れ替えることができる
というのがあるが、うまくSpreadsheet でカバーできてしまったので、ここ1ヶ月はこのまま運用している。
決まったことを決まったようにこなせる日はなかなか無い。都度、新しく発生した問題やら何やらを片付けつつメインの開発に取り組むという形で進めている。何時間で終わらせるぞ！という目標のあるものは見積もり時間項目に値が入るが、想定できないものや突発的タスクについては入っていない。 記録をつけたことで、自分としては次のような見直しができた。
- 平均して毎日3時間は雑務をこなしている。
- 月に3~5日はまったくコードが書けない日が発生する。
- ...ということを見越して、機能の完成時期を予想する。
あとログを書き込むようになって、作業に詰まったときにどれくらい時間を使ってしまったのかを時間単位で把握できるようになった。結果、諦めたり方針を変えたりするきっかけ作りとしても効いていると思う。
GitHubのソースコード参照リンクを残すときはmasterを避ける
tl;dr
GitHub参考URLをmasterを参照したものにしていると数年後に見直したときに泣くぞ！気をつけろ！(経験談)
こんなときあるよね
GitHubを使っているときなど、ソースコードへの参照URLを残したい場合がある。 このとき、リポジトリからそのまま素直に目的のコードを探しにいき、特定の行番号をクリックすると次のようなURLとなる。 (pluckが好きなのでその部分の実装のリンクを貼ってみる。) https://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/enumerable.rb#L124
しかしこのURLには問題がある。 ソースコードは生き物みたいなものなので、masterは日々更新されてしまう。 数ヶ月経った後のこのファイルの124行目は果たしてpluckの実装を指しているのだろうか？ これを誰かが読んでいるときは、すでに全く別の行だか空行だかを指しているかもしれない。 せっかく参考にと残したURLが別の場所を指していては意味がない。
手段1: tagの指定
将来的にも確実に意図した指定を残す方法として、branchやtagを指定してから行番号リンクを獲得するようにしている。 自分としてはどちらかというとtagのほうがバージョン指定がURLに入るのでわかりやすいかなと感じている。 (あっ、v5.2.1の時点ではpluckは114行目なんですね...) https://github.com/rails/rails/blob/v5.2.1/activesupport/lib/active_support/core_ext/enumerable.rb#L114
手段2: Copy permalink
特にバージョン指定も関係ない場合、行を選んだ時の左側の「…」を押すと手っ取り早くCopy permalinkができる。 このときURLは次のようになる。 https://github.com/rails/rails/blob/5431e17733366da1fd10f2cd3039d66a56012683/activesupport/lib/active_support/core_ext/enumerable.rb#L124
おまけ
1行選択したあと、Shiftを押しながら別の行を選ぶと、範囲指定ができる。URLとしては L数字 を - で繋げればよい。
https://github.com/rails/rails/blob/v5.2.1/activesupport/lib/active_support/core_ext/enumerable.rb#L107-L121
