hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

App::PRTで大規模なプロジェクトをリファクタリングするときはgit grep --name-onlyで絞り込むと早い

App::PRTはPerl Refactoring Toolで、クラスのリネームや、ネームスペースのリネームなど、便利なコマンドが集まっている。
単純にrename_classやrename_name_spaceすると、リポジトリ内の全ファイルを1ファイルずつ順番にPPIでパースして見ていくので、大きなプロジェクトで実行すると時間がかかることがある。
以下のように、git grep --name-only で対象ファイルを絞り込むと、そこそこの時間で終わる。

prt rename_name_space Foo Bar $(git grep --name-only Foo)

いつも「時間がない」あなたに 欠乏の行動経済学

リソースが足りない状態の人間について研究した本。そのリソースは時間だったり資金だったりする。
スラック、つまり余裕があることが大事で、100円のおやつとか買うとき、それによって財産が100円減ることを考慮する人は居ない、毎月使えるスラックから支払われることになる。しかし、本当に切羽詰まってると、少しのお金を作るために借金し、次の入金は利子の返済に当てることになる。
人間、気になることがあると、判断に使うためにリソースを奪われていって、能力が下がっていく。貧しい状態の人は生まれ持った能力が低いわけではなく、お金や時間の心配をしていることで能力が下がっていくことが実験によって確かめられている。という本。
現代日本で考えると、テレビに繋いでるレコーダーが残り1時間とか3時間とかで、毎日、次の番組を録画するために、歌まつりを早送りで見続けたり、古いバラエティ番組を消すかどうかで議論したりして時間を使っていき、その間に部屋が散らかっていく、という場面が容易に想像できると思う。もし10時間余裕があれば、他にやるべきことがあるのに8時間ある歌まつりを1時間かけて早送りで見ていったりはしない。
ふだんソフトウェアを開発しているので、日々の暮らしに余裕を作らないといけない、逆に、自分が活躍できてたときは余裕があって好きなことをしている、人と自分との違いを考えると、余裕があることでメインタスクをすばやくこなせて、あとは好きなことをやっていることにある、なので余裕を作らなければならない、というのを思った。あとは、開発プロセスが持つ余裕というものを考える必要があって、重厚なオペレーションで、今よりやることを増やせれば、それは出来れば素晴らしいに違いないのだけど、そのオペレーションのために毎日の判断リソースが奪われていくと、だんだん本来は持っていたはずの余裕が失われていくことになる。
個人の暮らしに関しても、毎日の判断する回数を減らすのは大事で、最近は毎日同じ服を着られるように同じものをたくさん買ったりしている。ユニクロのカシミヤセーター気に入ったので6枚くらい買っとこうと思ったけど売り切れてた。いい感じのカシミヤセーター知ってる人いたら教えてください。毎年の型の変化がなく、安定して買えて、首周りチクチクしないとうれしいです。

いつも「時間がない」あなたに: 欠乏の行動経済学 (ハヤカワ・ノンフィクション文庫)

いつも「時間がない」あなたに: 欠乏の行動経済学 (ハヤカワ・ノンフィクション文庫)

  • 作者: センディルムッライナタン,エルダーシャフィール,Sendhil Mullainathan,Eldar Shafir,大田直子
  • 出版社/メーカー: 早川書房
  • 発売日: 2017/01/07
  • メディア: 単行本
  • この商品を含むブログ (6件) を見る

ボヘミアン・ラプソディ

ボヘミアン・ラプソディを観た。若い頃のフレディはオシャレな感じだったのがだんだんQueenに対するパブリックなイメージであるスーパーマリオブラザーズみたいになっていくのがおもしろかった。ライブのシーンではピアノにペプシとビールが置いてあるとか、演奏始める前にちょっと音量調節するとか、そういう細かいところまで再現されているようだった。

このくらいの時期のミュージシャンにとっては酒やドラッグにHIVが3点セットが必ずついてまわっている印象がある。

キッチンボード

冷蔵庫の上に電子レンジを置いてたのが、冷蔵庫をリプレースしたことで電子レンジの置き場がなくなり、電子レンジおけそうなアイテムを探していた。

家にぴったりな幅のものを買おうとすると、ニトリで買うしかないという状況。しかし、ぴったりの幅で買ってしまうと、引越し先で使えない。

4万円くらいだったので引越し先で使えなくてもまあいいかということになった。4万円のコートはしゅっと買うけど4万円の家具を買うのは緊張感があり、値段の割にでかいため、とか、捨てるのが大変、とかそういうことだと思う。400円で買えるとしても慎重になる。値段の他に、家にほうっておける度みたいな概念があり、服はクローゼットにしまえるという設計でコンポーネント化されているので中身を自由に入れ替えられる。

ニトリや無印やアクタスなど見に行ってニトリで買った。

https://www.nitori-net.jp/store/ja/ec/CupboardApplianceBoard/ApplianceBoard/ApplianceBoard80w/4701350s?ptr=item

エンジニアアルバイト氏受け入れテクニック

いま社員エンジニアが何人かに加えてエンジニアアルバイト2人、くらいのチームで働いていて、その中でアルバイト氏のメンターもやっている。
前のチームでも何年かアルバイトの面倒を見たり、何回かインターンのメンターをやったりしていた。
手癖でいろんなことをやってしまっていて、属人性が高まってしまっていると感じたので、どんなことをやっているか書いておく。

  • 1日に何回か口頭で会話する
    • 実装ができててから方針がまずかった、となると時間がもったいない
    • 方針書いたくらいでレビュー依頼に出してね、とお願いしてもやってもらうの難しいので、こちらから聞きに行くほうがうまくいきやすい
  • レビュー依頼になったらすぐに見る
    • 社員は明日も要るけど、アルバイト氏は週に数回しか来ないので、その日帰るまでにレビュー完了して打ち返しもしてもらえるように動けると良い
  • レビュー依頼になってなくてもPull Request見に行く
    • 方針よさそうだったら、よさそうってコメントしておくだけでも
  • 何をやりたいか聞く
    • 興味があるジャンルの技術のタスクを渡してあげられると本人にとっても楽しそう
    • 無茶振り感もあるので、もしやりたいことあったら書いといて、くらいの温度感
  • 知らない技術を触ってもらうときにはちょっとペアプロする
    • この辺にこういう事が書いてあるよ、みたいな、あるき方とか、プロジェクト固有の情報は伝授する
  • おもしろタスクを渡せるとさらによい
    • アルバイト氏はMTGとかレビューで割り込みがないので、着々と新機能の開発をやってもらったりしていた
    • 得意分野がある人、たとえばフロントエンド得意な人には、フロントエンド周りの新機能作ってもらったり、JSのビルドを良くしてもらったり
      • うまく渡せないと、難しくない雑用をひたすらこなしてしまうことになり、働いていて面白くないと思う
    • インターンの場合は、最終日にチームごとの投票があるので、投票、便利さや、実装可能性や、優勝できる度などが求められる
  • チーム内でメンター決めておけると良い
    • 決まった社員とペアで常に動いてる、みたいな感じになると、社員じゃないと見れない箇所に突入した瞬間に手伝ってあげたり、各所への連絡をさっとやってあげたりとか、待ち時間なく動ける
    • 毎回、どなたか教えてください! みたいな感じだと、毎回誰かつかまえてもらうのはアルバイト氏にとっても、呼ばれる社員側にとっても、疲れることが多いと思う
    • リモートじゃなくて物理的に同じ場所に居るほうが望ましくて、もっと言うと席が隣になってるとより良い。テキストでやりとりして、おやと思ったら椅子をくるっとまわしてすぐに話せるのが一番便利
  • 手元環境をDocker化しておく
    • いま触ってるプロダクトではDocker化しておいたところ、セットアップが簡単になってよかった。夏に1ヶ月インターンに行ってきます、みたいなこともあるので、戻ってきたときにまたすぐにセットアップできると楽
  • 丁寧に作ってもらう
    • 週1か2で作っていることもあり、締切があまりきびしくないので、レビューで細かいところまで丁寧に直してもらっている。リーダブルコードのこのページ読みましょうとかよく話している
    • プログラミングの楽しいところをやってもらって、技術力上がってもらうことを期待している
    • 学生のうちに、重複のなく、テストも揃って、ちゃんと動くものを丁寧に作れるようになってないと、そこから社会に出てから、学生の時より丁寧に作るのは難しいのではないか
      • 社会に出て毎日働くということは、時間単位でこれくらいの進捗が求められる、という話になって、スピードを上げることを求められることのほうが多いと思う

最初は丁寧めに見ておいて、慣れてくると、複数タスクを同時にやってるからレビュー待ちの時間に別のことやってもらったり、勝手に気になるところ直してくれたりするので、慣れてくるにしたがって自然と放置度が上がっていくモデル。
インターン生の受け入れもこんな感じで、ただし習熟する前にインターン期間が終わると思われるので、毎日丁寧にやっていくとよい。

よくある質問

  • 丁寧に面倒見すぎると、面倒見てる時間のほうがアルバイト氏に開発してもらえう成果物の価値を上回って、バイトが居る意味ないのでは?
    • 社員がMTGに出たりリリースとかやっている間も実装を進めてもらえるので役立っていると感じます
    • インターンはあまり戦力としては見ていなくて、うまいこと得意なことをやってもらえたら、やってもらえてよかった、となる印象がある
      • 昨年の夏の人たちはフロントエンド得意な人と器用に何でもこなす人のペアで、うまく分担できて良い成果を出してもらえた
  • メンタリングテクニックを学べる書籍


もともと社内グループに書いたけど、他社の皆さまの様子とかどんな感じか知りたい。
弊社で一緒にやりたいという方はこちらからご応募ください。

ターミナルにãが出たらuse utf8;しましょうって教えてくれるやつ

Perlでテストを書いてるときに、テストではuse utf8;してるけど実装側でuse utf8;し忘れてると、isの左右でフラグが立ってるやつと立ってないやつを比較してしまい、ãがよく出る、って話をしていて、iTermのフックでアラートを出すようにしてみた。
use utf8;し忘れてるとãがかならず出るわけではないので雑。
f:id:hitode909:20190111184651p:plain

f:id:hitode909:20190111184712p:plain

雑じゃない手法

akiym [6:46 PM]
SVのflagsも一緒に比較すると便利そう、utf8 flagあるかどうかとか文字列か数値かまで厳格にチェックするとか
というアイディアがでました

kga [6:46 PM]
よさそう