この記事はPerl Advent Calendar 15日目の記事です。 qiita.com さて 様々からの現実逃避とISUCONに向けたPerlのリハビリでmustache template engineをちまちま自作してたんだけどついにmustache/specなどから作ったテストが全部通ってしまった— かるぱねるら (@karupanerura) December 12, 2023 ということで、ひさしぶりにCPANizeしました。なんか早速bug fixが見つかって早々に0.02です。 metacpan.org 今のPCでは初めてのCPANizeだったようで ~/.pause がなくてちょっと焦った。 なんで？ 人生色々。様々があります。 たとえば、やることに追われたり、悩ましい考え事に苛まれたり、やることに追われたり、やることに追われたり、様々があります。 一方でISUCONも

3年前、2020年の2月にこんな記事を書きました。 blog.perlassociation.org まだその脅威の全貌が明らかにならないままに刻一刻とタイムリミットは迫り、 YAPC::Kyoto 2020のために積み上げてきたものとそれをその状況下で実施することのリスクを直視して、頭を抱えました。 自分たちの本業は当然ながらイベントの運営ではありません。 その一方で、イベントの開催には様々な準備が必要になってくるため、それなりの労力と時間がかかります。 それを誰もが持て余しているわけがないように、スタッフも暇だからそれをやっているわけではないのです。 では、それをどこから捻出するかというと、趣味や大切な家族との時間を削ったり、睡眠時間と体力を削ったり、業務調整をして同僚に助けてもらうなど、人によってその程度の差はあれど全く何も犠牲にしていないという人は少ないでしょう。 そういった、掛け

YAPC::Japan::Online 2022が終わりました。 JPA代表あるいはYAPC::Japan::Online 2022の主催としてのコメントはこちらに書きました: blog.yapcjapan.org ここでは、個人的に考えていることを書いてみます。 コミュニティ主催のカンファレンスの価値はなんだったのか なぜ、ぼくたちはカンファレンスに参加(した|していた)んでしょうか？ なぜ、ぼくたちは、どこかの誰かがやってくれる大きなカンファレンスではなく、自分たちのカンファレンスを作っているのでしょうか？ 人それぞれいろいろな答えがあると思いますが、はっきり「これだ」といえる理由がある方はおそらく多くは無いのではないかと思います。ぼくも、なんとなくカンファレンスに参加するのは好きだし、得られるものが多い気がしているだけで、あまりうまく言語化できないです。 自分の場合はどうだろうと、自

用語 レビュアー 対象となるコードをレビューする人のことを指します。 レビュイー レビューを受ける人、つまりレビューする対象のコードを書いた人のことを指します。 tl;dr アプリケーション開発業務におけるコードレビューはコードの正しさや質そして一貫性を保ち、それらと同時にコードに対するチームとしての共有知を作り上げる良いプラクティスだと思います アプリケーション開発チーム内でのコードレビューにおいてPull Requestを使ったレビューのスタイルは一般的ですが、Pull Requestの承認は実際にはほとんど意味がないのではないでしょうか？ ほとんど意味がないにも関わらず、承認の有無によって業務フローが左右されることでそれが権威的に扱われてしまいオーナーシップを希薄化させ、結果的にコードレビューのコストが増加したりそれを行う目的を見失ってしまっていることはないでしょうか？ Pull R