自分を信じよう
自分の知識・経験をフル稼働させて出した答えを信じ、大切にしたほうがよい。
他人の方が優秀かもしれないが、自分ではない。
もっとも信頼できるのは自分自身であるべきだ。
自分を疑おう
自分の出した答えを疑ったほうがよい。
世の中には知らないことがたくさんあるし、自分よりも優秀な人もたくさんいる。
なにより、ほとんどの場合正解なんてそもそも存在しないのだ。
よりよい答えを、常に謙虚に探し続けなければならない。
自分の知識・経験をフル稼働させて出した答えを信じ、大切にしたほうがよい。
他人の方が優秀かもしれないが、自分ではない。
もっとも信頼できるのは自分自身であるべきだ。
自分の出した答えを疑ったほうがよい。
世の中には知らないことがたくさんあるし、自分よりも優秀な人もたくさんいる。
なにより、ほとんどの場合正解なんてそもそも存在しないのだ。
よりよい答えを、常に謙虚に探し続けなければならない。
職場の同僚に教えてもらったのだが、Surround selection on typing quote or brace を有効にするといいかもしれない。
括弧やクォートで括り放題になる。
括っている文字の置き換えもIDEAさんがいい感じにやってくれる。
これを。。
こうして。。
違う括り文字を選ぶと。。
こうなるのだ!
Editor > General > Smart Keys で、Surround selection on typing quote or brace にチェックを入れるだけ!
今日チームでモブプログラミングを初めてやってみたのだけれど、最高だったのでテンションのままにブログを書く。
ふりかえりでたまたまJoy.Incの話になり、あの会社は全部ペアでやってるらしく、ペアプロしたくなるという話をした。
そうしたら、なんとチームメンバー全員(自分含め3人)がちょうど本を持っており読んでいる、読もうとしているところだった。
メンバー全員ペアプロの経験は殆どないに等しく、全然わからない笑
でも、とにかく試してみようよという話になった。
ただしチームメンバーは3人のためペアが組めない。
そこで、Scrum Gathering で見たモブプログラミングでやってみよう、ということになった。
なお、モブプログラミングについても当然経験はなく、ペアより多い人数の場合はモブと呼ぶ、くらいの理解しか無かった。
git push
するので、続きからはじめる
緊張感もあったのだけれど、やってみるととても楽しかった。
ただ、チームメンバー間での信頼関係や、敬意の有無がとても大切になるだろうとは感じた。
協力体制になるので、他のことに気を取られる余裕がそもそもない。
これはある程度できあがった成果物ではなく、思考過程も踏まえた上で議論できるので、抜け漏れがなかったり、ブラッシュアップがしやすいからかもしれない。
時間的にはどうだったかという話だと、ソロでもできたかもしれないけど、せいぜいプルリクエストを出すところくらいまでだっただろうという肌感。
レビューしてもらって修正、マージまで同じ量終わらせるのは無理だったと思う。
これはたまたまだったけど、3人というのはとてもいいと思う。
2人だと意見の相違があったときに、対立構造っぽくなってしまう。
また3人より多いと、熟練度がないとどうしても濃度が薄まりやすくなるのではないか。
例えばデータパターンが必要なテストコードなどは、同時進行だとレビューコストがすごく下がる。
どうしてもコードから意図を汲み取るのが難しいものをリアルタイムで一緒にやると理解が早く、アドバイスの質も上がった。
他の人の作業を見られるのは、興味深いし刺激にもなる。
単純な成果物の質だけではなく、過程を見られるのは大きい。
どこから書くのか?みたいなこともそうだし、なぜそうするのか?というのも聞ける。
端末が別なのも、個々人で使ってるツールとか知られて、かえって良かったと思う。
完成度の話とも連動するけど、試行錯誤の段階から意見や考えがアウトプットされ、協力体制で作れるのは大きい。
集中度が高まって生産性は間違いなく上がると思うんだけど、疲労度は大きい。
また、ちょっと気になってることへの寄り道とかもしづらい。
(時にその寄り道が別のどこかで大きな効果を生むことがあるはず)
毎日1日中ずっと、というのは結構辛いだろうな、と思う。
少なくとも今は。
オフィスによるんだろうけど、自分のところでは数時間まとまった単位で場所を確保するのは難しい。
モブプロを実施する頻度を上げたいと思った時に、壁になるかも。
モブプログラミング最高だった。みんなやればいいと思うし、積極的に勧めて行きたい。
メンバーも好感触で、とりあえず週一は固定でやろう、やりたいタスクがあったら適宜でやろうという話になってる。
これが正しいやり方かは分からないし、一回やってみただけで何言ってるんだと思われるんだろうけど、それくらい大きな感動があった。
モブプログラミングいいですよモブプロ。
はやくまたやりたい。
org.springframework.beans.factory.annotation.Value
を使うとよい。
ただし、まとまった単位で管理したいときは @ConfigurationProperties
を使うのがよさげ。
@Configuration public class AppConfig { @Value("${spring.datasource.schema}") private String schemaName; public String getSchemaName() { return schemaName; } }
MyBatisのConfigをJava側で動的に書き換えられないか調べてみた。
結果できなかったんだけど、備忘録として。
org.apache.ibatis.session.Configuration
に値を突っ込むことでどうにかなりそう?
configuration.getVariables().put("global_param", "123");
SqlSessionFactoryとかSqlSessionTemplateはAutowiredできるので、SQLの発行直前にConfigを引きずり出して値を突っ込んでみるも、うまくいかず。。
mybatis-user.963551.n3.nabble.com
Jorge, make sure that config.getVariables().put() is called befor the mapper xml files are parsed.
I do not know if this behaviour is intentional but varable replacement work for mybatis-config.xml and also form mappers but just during loading time.
どうもmapper.xmlをparseする前とか、Config(ファイル)を読む前に突っ込めばうまくいく?
Spring-mybatisだとどこでやってるんだろう。。
たぶんSqlSessionFactoryの生成あたりでやってそうな雰囲気はある。
けど既存に影響を与えない形でうまくいく方法が浮かばない。。ので現時点では諦めることにした。
JavaScriptでargumentsオブジェクトは配列っぽいけど配列ではないらしい。 なので配列のメソッド呼ぼうとしてもエラーになる。
Array.prototype.slice.call
で配列に変換してあげるのがよいっぽい。
var args = Array.prototype.slice.call(arguments);
でもsliceするわけじゃないのに、sliceでやるのって違和感。。
Array.from
を使うのがよいみたい。
これは分かりやすくて良い。
let args = Array.from(arguments);
run.argumentsプロパティで渡してあげるとよい。
Sample:
./mvnw spring-boot:run -Drun.arguments="arg1, arg2"