Git で特定のサブコマンドの出力の結果にlessが挟まるのをやめたいときに見るやつ

前提

git version 2.19.1

調べたこと

Gitのバージョンを上げたらGitのサブコマンドの結果がlessを介して出力されるようになってしまった。 git branchで数行出すのにlessを使ってほしくないので、調べた。

Git - Git の設定

上のページを読むと以下のことがわかった。

  • core.pagerという設定がある
  • デフォルトではlessが設定されている
  • 空文字を設定することでページャーを無効にできる

更に調べるとbranchtagのサブコマンドは別にページャーを指定できることがわかった。v2.16からの挙動っぽい。そして、git branch --listで標準出力に出せるみたい。

git/2.16.0.txt at master · git/git · GitHub terminal - Git branch command behaves like 'less' - Stack Overflow

やったこと

今回はgit branchだけで十分だったので git config --global pager.branch false

を設定して解決した。

Fun Done Learnでふりかえりをしていた

今所属しているチームでは、2週に1度のスプリントミーティングでふりかえりをしている。 去年まではKPTAを使っていたが、今年はじめからFun Done Learnを使ってふりかえりをしてみようという事になった。きっかけは特になく、こんな手法もあるから試してみるか。くらいの雰囲気だった。

www.ogis-ri.co.jp

手順

やり方は上のブログ記事に大体則っている。

準備

3項目ベン図を描き、それぞれの円にFun、Done、 Learnの名前をつける。 メンバーごとに色の違う付箋とペンを配布する。

できごとを書く

チームにスプリントでの出来事や、やったことを付箋に書く。

貼る

書き終えたら、一人づつ付箋を読み上げてどの領域に属するか、付箋を書いた人以外のメンバーが決めて貼っていく。このとき、貼っているうちにFun、Done、Learnの意味がメンバー内で定まっていく。 全部張り終えたら、改めてチームでのFun、Done、Learnの領域の意味をチーム内で合意し、領域がずれていそうな付箋の領域を改める。

重心を取る

メンバーごとの付箋の領域を見て重心をとってマークする。

今回はめっちゃDoneしてるねー、あんまりFunなことなかったねーといった偏りがあったりする。チーム全体の付箋でも重心を取っておく。

次の重心を決める

次のスプリントで目指したい領域を決める。

今回LearnなかったからLearnなこと増やしたいなー、次のスプリントはリリースがあるからDoneを増やせそうなどの会話が発生すると思う。

改善テーマを決める

メンバー全員で改善できそうな付箋にシールで投票する。自分は社の理念から「もっと面白くできる付箋」と勝手に呼んでいる。 良かったこと、イマイチだったところ問わずに投票して、投票された付箋に対してどう「もっと面白くできるか」チーム内で話し合う。話した結果が次スプリントでのアクションアイテムになる。

やってみて

  • ふりかえり最中の対話量は増えたように思う。
    • KPTAやってるときも十分な対話があったと思うがそれ以上。
  • KPTにありがちなProblem多くてお通夜になるということにはなりにくそう。
    • YWTみたいに無理に負の感情を出す必要が無い。
  • 出来事や、やったことなど、起きたイベントに対しての振り返りになるので、「これから起きそうなんじゃないか」等の「予兆」に対してこの時間で対策を取りにくい。
    • 課題と思える出来事については「〜〜が起きて〜〜ということに気づいた」というように無理やり出来事としての付箋を作れるのだけれども…

3ヶ月続けて

やってみて、課題としてメンバーが思っていることや、不穏な予兆をふりかえりで残しにくいなと感じて、ふりかえりのふりかえりを実施した。

  • 「チームとして各領域のどの位置にいるのかはわかるが、どの領域にいるのが正解なのかわからない」
  • 「Pが連なったとしても、今のチームならお通夜になることなく改善を積み重ねていける」

という意見がでて、元のKPTAに戻ることになった。

Fun Done Learnの手法が悪いというわけではなく、今のチームではKPTAでも十分回る。という結論だった。Fun Done Learn自体は進めてて楽しかったので、別の場所でなんかの企画が終わったあとでも試してみようと思う。 あとFun Done Learnでの課題管理をどうしているかアイデアがあったら教えてほしいです。

Developer.IO CAFEに行ってみた

有給とって適当に行く場所考えてたら最近できたDevelopers.IO CAFEの存在を思い出したので、行ってきた。

cafe.classmethod.jp

場所は岩本町と日比谷線秋葉原の駅の間、川沿いにあって、窓からは神田川が見える。

完全キャッシュレスを謳う実験的なカフェで、決済はすべてスマートフォンのアプリから行う。実際にアプリからドリンクを注文すると、直ぐに店舗のウェィティングボードに注文内容と受付番号が反映されて、店員さんとのやり取りは商品を受け取る瞬間のみ。結構新鮮で面白い。ヨドバシ・ドット・コムで商品を買って店舗で受け取りする感覚。

お菓子のウォークスルーもあって、アプリに表示されるQRコードをかざしてお菓子を取って棚から離れると決済が行われる仕組みになっている。赤羽の無人キオスクを思い出した。あれは入場時と決済時にSuicaをかざす必要があったらしいけど、それよりも一手間省けている。仕組みを調べると、先の無人キオスクのように、追跡センサーで人の検知を行って、そのセンサーと商品棚についている量りで商品を取ったかどうかを判断しているっぽい。商品入れ替えられたら大変そう。

www.itmedia.co.jp

初回利用時の会員登録が必要なのは手間だなと思ったので、そこらへん、決済のプラットフォームでSSOできたら最高だなーと思うなどした。

2018年に買ったもの

みんな書いてるから書こうっと。

α7 II

3月に買って、オールドレンズと28-75 f2.8をお供にしている。70Dと比べるとだいぶ小さくなって荷物が減ったのはとても良いこと。バッテリーの持ちがよろしくないんだけど、そこはバッテリーの数でカバーしてる…

uvb-76.hatenablog.com

今年はほとんどの写真をこいつで撮っている。被写体がよく動いたり、望遠が欲しい時は70D使ってる。フルサイズの望遠は今の所買うつもり無いので、今後も70Dで頑張ってこってかんじ。

自転車

そう。自転車買ってたんですよ。RALEIGHのRSP RSW Special 新卒の初任給の前に買ったGIANTのESCAPEが結構ガタ来てて、オーバーホールに3万とか言われちゃったからそれだったら新しいの買うか~って思って買った。 最初はFUJIのHELIONいいなって思ってたんだけどなかなかなくて、店員さんに聞いたら「あれまじ乗りにくいからこっちにしなよー」とか言われてしっくり来たから買った。 今思うとかなり口車に乗せられている。

ドロップでミニベロでかっちょよくて最高。ただ、泥除けのおかげでミノウラの縦置きスタンドに入らなかったり、駐輪場のレーンに収まらなかったりすることが多々あってちょっと厳しい。 そこだけ目をつぶれば。

とのこと。なんだかんだ自転車の写真撮ってないからふらっと撮りたい気持ち。ちなみにこの自転車を買った前月に弊社CTOが同じお店で自転車を買ったことが判明し、一時社内で話題になった。

キーボード

  • Helix
  • Lily58
  • ErgoDash

uvb-76.hatenablog.com uvb-76.hatenablog.com

何枚作ってるんでしょうかね。ちなみに家ではMinila Airを使っていて、仕事ではHHKBJPを使っている。なんかおかしいね?Lily58は社内で内定が決まった若者に貸しているところ。ErgoDashはキーマップ入れかえて家か仕事で常用できるようにしたい。

作ったキーボードは社内の展示会で出したりもしていた。 medium.com

イヤホン

MA750 Wireless: Bluetooth®カナル型イヤホン | RHA を買っていた。前のJBLに比べると低音がしつこくなくてきれい。

技術書

メタプログラミングRubyは読み切れる量で良かった。

Switch

スマブラのために6月に買ってた。それまではクラッシュバンディクーとかアルティメットチキンホースとかで遊んでた。スマブラGCコンのタップ待ち状態。

Mac

f:id:uvb_76:20181231172707p:plain
アー
晦日の最後の最後にポチってしまった…

2019年は机周りの環境一新して本棚買おう。

プロを目指す人のためのRuby入門を読んだ

読み切った。メタプログラミングRuby読む前にこっちを先に読むべきだった。

どんな本だったか

解説が丁寧

筆者の解説がとても丁寧に感じた。一つの項目に対して関連した情報を続けて文章で解説してくれていて、覚えやすいと思った。

テストを書くことを意識させられる

3章から「テスト自動化」を見出しにしていて驚いた。配列の前にテストを書く入門書は初めて見た。各章の例題でもテストを行うことを重点に置いていることがとても斬新で良かった。

Railsのこともフォローしている

Railsをやる前にRubyを知ろう みなさんが「Rubyをちゃんと理解しているRailsプログラマ」になれるように、Rubyの基礎知識から実践的な開発テクニックまで、丁寧に解説します。

と表紙にあるとおり、要所要所で、Railsの解説があるのが親切で良かった。名前空間のところであったり、例外処理のベストプラクティスであったり。特に付録AはRailsを扱う上で必要な情報や参考資料のリファレンスが一通りあってとても便利だと感じた。なにかあるたびに読み返すことになりそう。

思った

モジュールは気軽に組み込める

C+やC#をかじっていた身としてはModuleと聞くと、Interfaceやpartial Classが個人的に連想されたんだけども、全然そのようなことはなくて気軽にメソッドを組み込める機構であることを学んだ。

成果物は育てることができる

7章を読んで強く感じた。7章の「クラスを理解する」では駅間の改札のプログラムを例題にクラスの作り方を解説している。この改札機と駅名を私は「プロを目指すRailsエンジニアのための公開コードレビュー」という発表をしました #railsdm - give IT a try という企画で読んだことがあって既視感を覚えた。実際に、著者の解説を読むと、

ちなみにこの問題は2017年11月に発売予定の書籍「プロを目指す人のためのRuby入門」のために作った例題をRails向けにモディファイしたものです。

とあった。一度作った成果物はいろいろな場所でアウトプットしていって、そのたびに少しずつ変えたり、良くしたりするといいのだなという気持ちになれた。

DSLが読める

これはメタプログラミングRubyを読んだというのもあるのだけれども、Rakeタスクを始めとするDSLの記法が中の実装まで想像して読めるようになったのが嬉しい。

task :hoge do
  puts '何らかの処理'
end

とあったときに、「ハッシュとブロックを引数にとるtaskってメソッドが定義されているんだなー」とか

gem 'rails', '~> 5.2.0'

とあったときには「gem名とバージョンを引数にとる`gemってメソッドがあるんだなー、バージョン指定は内部でsplitしてるのかなー」とか想像しながら読めるようになって、ふわっとしていた書き方がきっちり理解できた感じ。

とても素敵な入門書でした。今後もお世話になりそう。

メタプログラミングRuby 第二版を読んだ

Rubyの言語について掘り下げたいときによく話に出てくる「メタプログラミングRuby」の第二版を読んだ。

構成

ストーリー仕立てで一つのプログラムに対してメタプログラミングのアプローチを行う1部とRailsActiveRecordについて深掘りしていく2部の2部構成になっている。

どのくらいかかった?

社の @ryuchan_00さんと二人で読書会を開き、本編を音読しながらクイズなどのコードを書いていたら全部で22時間で読み切ったという記録が残った。

面白かったところ

privateの仕様

  • self以外のオブジェクトのメソッドを呼び出すには、レシーバを明示的に指定する必要がある。
  • privateのついたメソッドを呼び出すときはレシーバを指定できない。 Rubyにおけるprivate methodはこの2つのルールを利用して制御されていることについて、シンプルできれいだなと感心した。

一歩右、それから上へ

メソッド探索の方法。書籍の序盤で叩き込まえて、忘れた頃に特異クラスの話で再開して感動した。

Procとlambdaの仕様の違い

  • Procの中でreturnを使ったときにはProcを呼んでいるメソッドを抜ける
  • lambdaの中でreturnを使ったときにはlambdaを抜ける

スコープをまたぐ場合、またがない場合

  • def, Class, Moduleキーワードはブロックを作り、その内部はスコープが変わる。
  • 同じスコープ内で、メソッド定義やクラス、モジュールの定義を行いたい場合は、define_method, Class.new,Module.newで実現ができる。

ActiveRecordの移り変わり

ActiveRecordが最初にできてから、実装が変化し、ActiveModelが分離し…といった歴史が語られていて良い。

総じて

読み進めていくごとにRubyの仕組みの奥底を覗いていくような間隔になってとても楽しく読めた。これらを使いこなせるようになるのはまだまだ先だと思うけど、内部を想像しながらコードを読めるようになっただけでも進歩だと思う。