初めてのYAPC
3/18〜京都に行って、YAPCとその前日祭を聴講しにいきました。
yapcjapan.org
前日祭では、LTが行われていて、特にPerl初心者が書いたコードのレビューについての発表が、共感できて好きでした。
空リストの判定の書き方とそのレビューが、あるあるだなーって思いました。
夜は、Helpfeel Techさんの懇親会に参加していました。
店について最初に頼んだ唐揚げが出てきたのが2時間後とかで、ここの注文はスタックなのか？？とか会話していたのが楽しかったです。
当日は、前日に聴講するものを全て選んでから行きました。
- 小さく始め、長く続けるOSS開発と貢献
- 売上と開発環境を同時に改善するために既存のPerl Web アプリケーションをどのようにリプレイスするか
- my$talk=qr{\b((?:ir)?reg(?:ular )?exp(?:ressions?)?)\b}ig;
- 入門 障害対応 「サービス運用はTry::Catchの繰り返しだよ、ワトソン君」
- マルチテナントの実現における技術選定の審美眼とDB設計 ~ PostgreSQLを添えて ~
- 4PB(ペタバイト)を超えるオブジェクトストレージをハードウェアからアプリケーションにかけて運用するノウハウ
- DNS権威サービスへのDDoSとハイパフォーマンスなベンチマーカ
- あなたの知らない(かもしれない)コアモジュール 2023
- 様々な環境へコマンドラインツールを提供する上での苦労とその対策
- my new error...
前日祭で、低身長だと後ろの方に座るとスライドの下半分が見えない、ということに気づいたので、当日は前の方に座るようにしました。
そうしたら夜首が痛かったです。
どっちにいくか迷ったら知り合いではない方を見に行きました。
今回、あとから配信がありそうなのが大変嬉しいですね。
YAPCの全体的な感想
直接的なPerlの話が思ったより無かったのが意外でした。
もっとPerlのニッチな話を聞くイベントだと思っていたら、Perlを心に秘めた人たちの話でした。
個人的に、Perlの話をしている人の話が特に面白いな、と思ったけど(なぜなら最近Perlを一番書いてるから)、それ以外の話も実用的な話が多くて楽しかったです。
次は何か話題を持っていきたいですね〜。
参加しての満足度は120%くらいです。
他の企業の方とかと喋るのが本当に久々だったので、すごく楽しかったです。
ひとこと感想的なコーナー
- 小さく始め、長く続けるOSS開発と貢献
- コードの多様性の話が面白かった。CNaanさんのコードは〇〇だね〜〜っていつか褒められたい！
- なんだかんだゆっくりでも仕事ができてしまうので、ゆっくり仕事してしまうけど、ショートカットが使えたら一回数秒の短縮になる、とかそういうちょっとの短縮もやっていくかあ、とモチベを上げられた(発表とはあまり関係ないかもな感想)
- my$talk=qr{\b((?:ir)?reg(?:ular )?exp(?:ressions?)?)\b}ig;
- 「多分ChatGPTはStack Overflowを読んだのでは」とみんなが思っていることを代弁したのが最高だった
- 絵文字やリガチャといった、Perlと書記素の話が興味深かった
- 入門 障害対応 「サービス運用はTry::Catchの繰り返しだよ、ワトソン君」
- 外型監視のアラートで原因がわからないときは挟み撃ち法を使っている、L7→L3→L6……みたいな
- 障害対応訓練と聞くと準備(エンジニア的な準備や訓練のための時間を貰う調整)にコストがかかりそう、というイメージだったけど、そんなに準備のかからない(準備に30分とか)訓練をやっている、とのことだった
- 4PB(ペタバイト)を超えるオブジェクトストレージをハードウェアからアプリケーションにかけて運用するノウハウ
- オブジェクトストレージの運用知見から自前で……となるまでのストーリーが面白かった
- あなたの知らない(かもしれない)コアモジュール 2023
- 前日の懇親会で知り合った方の発表だった
- use bigintとか、Benchmark、Term::ANSIColorとか、よく知らないコアモジュールの話が聞けて最高だった
- 貴重なPerlっぽい話
- 様々な環境へコマンドラインツールを提供する上での苦労とその対策
- my new error...
- アラートの監視の仕事だけをする、というのが大変そうだった。オオカミ少年問題を解決するために、ログレベルと使い分ける、といった参考になる話が聞けた
- 個人的に例外投げるよりエラーオブジェクト返す方が好きなので、全体的に共感できる話だった
展示とか
カヤックさんでおみくじを引きました。
大吉やった〜🙌
絵馬にもお祈りをして、無事お祈りは後日叶いました。ありがとうございます！！
DeNaさんのブースでコップをいただきました。
そのほか、さくらインターネットさんや、マネーフォワードさんのブースで色々お話できて楽しかったです。
YAPCの話はここまでです。
つぎのひ
月曜日、出社のついでに会社の人に連れて行ってもらって、カレーを食べました。
高校の同級生に会いました。桜が綺麗でした。
Perlでテーブル駆動テストを書くのにハマっている
この記事は、はてなエンジニア Advent Calendar 2022 - Hatena Developer Blogの45日目の記事です。
昨日は
id:cohalz さんのGitHub ActionsでJobやStepをデフォルトブランチだけ動かすようにする (2023年版) - Re:cohalzでした。
github.event.repository.default_branch、初めて知りましたが便利。
明日は
id:dekokun さんのGuardDutyの検知結果をslack投稿するアーキテクチャを考えた(あるいはAWSでイベントのフィルタを行うときに考えたこと) - でこてっくろぐ ねおです。
テーブル駆動テスト、使っていますか。
大体同じようなことをテストするけど、
- AとBでちょっとだけ違う処理をしたい
- AとBで結果を変えたい
といった時に、テーブル駆動テストの書き方は便利です。
CNaanがテーブル駆動テストを知ったのは、今から約4ヶ月前で、
id:papix さんが業務でリファクタリングのPullRequestを作成していて、そのPRをレビューしたときに「こういう書き方があるのか」と知りました。
id:papix さんはよくflaky testの修正やリファクタリングPRを作成しています。
姿勢を見習っていきたい。
それ以降、使えそうなところではできるだけテーブル駆動の書き方で書いてみることを心がけています。
私が思うテーブル駆動テストを書くことのメリット
1. リポジトリ内でテーブル駆動テストを使っている例を見つけやすい
大体下記の流れで書くので、$cases =とかで検索すると、他の人がどういうテストを書いているかが見つけやすい。
似たような書き方になるので統一感もある気がする。
my $cases = [ +{ description => '〇〇のとき', mock => sub { # サブルーチンも使える }, expected => 1, }, (略) ]; for my $case (@$cases) { subtest $case->{description} => sub { # 特定のcaseのみ実行する処理はcase経由で呼ぶ $case->{mock}->(); # 全てのcaseで実行する処理 sample(); (略) is, $result, $case->{expected}; }; } done_testing();
2. テストの冒頭で何をテストするかがまとまっていて見やすい
$cases = []の中を読めばこれから何のテストをやっているかがわかる。
テーブル駆動(ループ)を使わずコピー＆ペーストでテストを書いていたら、上から下まで見ていく必要がある。
コピー＆ペーストだと可読性が下がるし、一つの変更をする時に複数箇所変更する必要があって、変更し忘れなどの漏れが起きやすい気がする。
3. 新しいケースを追加するとき、簡単に追加できる
$casesに差を追加するだけで、増やせるし、減らしたい時はコメントアウトすれば良い。
4. 似た処理の流れをまとめられる
既に述べたメリットと似ているけど、やはり似た処理をまとめられるのが便利。
業務で書くテストでも、ユーザーを作って、とかしているけれど、それをテストケースの数だけコピー＆ペーストで書くのは、後々見返した時に見るのが辛い。
一つのサブルーチンに対してのテストで複数の条件分岐が発生しそうなときは、subtest; subtest; subtest;とするのではなく、for my $case (@$cases){subtest;}とテーブル駆動テストを使ってまとめるようにしたい。
なんとなく苦手意識があるテストファイルの行数を数えると1800行くらいでした。私は2000行近くなってくると苦手意識が生まれるようです。
したがって、条件を網羅しつつ、シンプルにテストを書けることが理想です。
おわり
さて、今はテーブル駆動テストな書き方にハマってますが、読者の好きな書き方を布教して頂けると嬉しいです。
CNaanのこれからの活躍にご期待ください。
こんな感じで書いている、という例を用意しようと思ったけど微妙な例になってしまったのでここで供養。
use strict; use warnings; use utf8; use Test2::V0; my $cases = [ +{ description => 'ゲストユーザーのとき', create_user => sub { create_test_user(); }, is_guest => 1, }, +{ description => 'ログインユーザーのとき', create_user => sub { create_test_user('test'); }, is_guest => 0, }, ]; for my $case (@$cases) { subtest $case->{description} => sub { my $user = $case->{create_user}->(); is $user->{is_guest}, $case->{is_guest}; }; } sub create_test_user { my ($name) = @_; if ( defined $name ) { return +{ name => $name, is_guest => 0, }; } return +{ name => undef, is_guest => 1 }; } done_testing();
$ prove sample.t
All tests successful. Files=1, Tests=2, 1 wallclock secs ( 0.00 usr 0.00 sys + 0.05 cusr 0.01 csys = 0.06 CPU) Result: PASS
平日休暇をとったときに、スマートフォンのSlackからサインアウトしてみた
こんにちは、はじめて源泉徴収票を貰い、社会保険料をこんなに支払ったんだなと思ったCNaanです。
入社してもう9ヶ月とかになろうとしているのか、とびっくりしています。
今日はタイトルにもある通り、平日の有給休暇でSlackからサインアウトする試みをしたことの感想です。
CNaanは休みの日でもSlackに未読があるとちょっと気になって読んでしまうタイプです。
ということで、試しにサインアウトしました。
つい癖でSlack見てしまいませんか
弊社は雑談チャンネルとかもたくさんあって、仕事の話、趣味の話、色々な話題が流れています。
つい、何か新しい話で盛り上がってないかなー、とか、同じチームの人たち元気だろうか、とか、streamチャンネル (Scrapboxや、GitHubでの議論が流れてくる場所) に面白い話題が流れていないだろうかとか、
手癖でSlackを開いてしまうことがあるんですよね。
そこで、休みの日にもSlackを見てしまうのはどうなんだろう、という話をチームでしていると、
「サインアウトしてみると良いのでは」という助言を貰いました。
※ 通知オフというのもありますが、通知オフだとSlackを見ようと思えば見れてしまうのでこれは選択肢から外しました。
というわけで、重要な用事があったら電話して下さい、と周囲に伝えた上で、サインアウトして休日を過ごすことにしました。
前日から、翌日の休暇の日にCNaanが実装したものがリリースされないように気をつけました(リリースするものは無かったけど)。
結果どうだったか
Good
- 会社のことを考えなくて済んだ
- スマートフォンを見る時間が減った(たぶん)
- Slackを見ていた時間を他のことに使えた
仕事が気になって悩む、ということがない一日を過ごせました。
Bad
- メンションが来ても気づけない
- 他の人がCNaanさん今日居ないですよってフォローしてくださっていたのでサインインしてから返信した
- まあこれはアンインストールではなく通知オフでも気付けないし、重要だったら電話くるはずなのでそんなにBadではない
- 出していたPRのレビューコメント通知のメールが来てしまった
新卒で入社して7ヶ月くらいが経過しました
こんにちは、
id:CNaanです。
3月に大学を卒業、4月から社会人となり、半年が経ちました。
という内容で先月書いていたのを出していなかったので、7ヶ月経ってしまいました。
そろそろ入社してからを振り返ろうと思います。
Perlは4月に入社してから初めて触りましたが、Rubyは触ったことがあったので、Rubyっぽいところは慣れやすかったかな、と思っています。
一方で、blessなどは中々理解できず(自分でblessを使って頑張ることには遭遇していませんが)、大変でした。
仕事でちょっと意識していたこと
小さい仕事を拾う
ちょっと空いた時間や、息抜きの時間に、非推奨となった書き方をリファクタリングしたり、ときどき落ちるテスト(Flaky Test)を直せそうだったら拾ってみたりしました。
ときどき落ちるテストの例だと、データがRedisに残っていて、そのせいでたまに落ちる、といったことがありました。
ほかだと、JSON::PP::falseはTest2::Tools::Compareで、T()とF()*1のどちらで比較してもテストにパスしてしまっていることを発見しました。JSON::PP::falseで丁寧に比較するように変更PRを出しました。
これによって、過去テスト用のサブルーチンでtypoしていて、存在しないものを参照していた(けどテストは通っていた)ことが判明したりしました(テストだけでよかった！)。
途中から入っているので、規模が大きくて完全に把握できていない箇所があったりするのですが、小さい仕事を拾うと、把握できていないところを簡単なタスクを通して見ることができるので楽しいです。
コミュニケーションでCNaanが意識していること
新卒チケットを積極的に使っていく
世間ではラストエリクサー症候群、という言葉があるらしいですが、id:CNaanは、新卒チケットは希少な消費アイテムではなくサブスクだと思うことにしています。
特に入社初期の頃などは、「多分新卒/チーム経験が浅い人視点の意見があると嬉しいかな」と思ってコメントを残す、などしていました。
最近では、障害対応などのときに「何もできませんが覚えたいのでちょっと書記しながら眺めます」というチケットの使い方をしています。(役立ってないですが新卒なので許してください！というのをもう少し続けます)
一人称をCNaanにする
これは本当にどうでもいい話ですが、一人称を自分の名前にした方が、主語がしっかりする気がしています。
「私はこう考えています」
↓
「CNaanはこう考えています」
なんとなく、一人称を名前にしておくと、受け取り手の「私」→「CNaan」の一回分の変換作業を減らせるんじゃないかな、と思ったりもします。
あとは議事録とか取る時に、そのまま発言を転載しても誰のことかがわかりやすくて良さそう、と今思いました。
そういう理由から、自分のことを名前で呼ぶように意識しています。
おわり
こんな感じで日々を生き抜いています。
毎日楽しく働けているので、同僚の方々には感謝しています！
さいごに、入社して最初の大きなリリースである、モーニング・ツーをよろしくお願いします！
morningtwo.com
Featuredな作品が動画サムネイルにする機能を実装*2しているところがポイントです！
(※ Safariの場合省電力モードにしていると動画が再生されません)
2022/11/4現在だとピアノの森/ザ・ゲームスターズ/恋じゃねえから/会社帰りのパ・ド・ドゥの4作品の動くサムネイルを見ることができます。一回クリックして見てください！かっこいいので！！
毎週動画がカッコ良いので、週の後半の楽しみです。これを見るために仕事を頑張れている、と言っても良い。
毎週木曜正午に更新されるのでお見逃しなく！
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
最近読んだおすすめ漫画です。気になる漫画、まだ全部読めてないのでどんどん読んでいきたい！
犬好きにはたまらない読み切りです。
comic-days.com
男子中学生と母の元カノたちの関係が素敵な作品。最終話まで配信されているので、一気に読めます。
comic-days.com
最近個人的に人外医療漫画が熱いです。
余談ですが、Viewerの埋め込み、かっこよくて好みです。
初見でひっかかったPerlのmapとハッシュと配列
こんにちは。
Perl歴2ヶ月ほどとなりましたが、Perlをはじめて1ヶ月の頃に躓いた話をします。
これから話す内容は、先日Perl未経験の新卒エンジニア1名に解かせてみたところ、引っかかったので、初心者*1は引っかかりやすいポイントだと思います。
同じ引っかかりをするかな(したら共感があるな)、という気持ちを込めて、本題までゆっくりと話していきます。
やっていくぞ
まずは、こちらをご覧ください。
use strict; use warnings; sub get_english_to_japanese { return +{ apple => 'りんご', phone => '電話', }; }
はじめにPerlが知らない人向けに言っておくと、strictとwarningsは、滅茶苦茶なソースコードの誕生を避けるために宣言すべきなものです。
これを宣言しないと、未定義の変数を突然利用できたりします。
get_english_to_japaneseは、英語と日本語の組のハッシュのリファレンスを取得するサブルーチン(関数)です。
( + は、ハッシュリファレンスであることを明示するためにつけている記号です)
大体他の言語をやっている人なら、「RubyのHashやPythonのDictみたいな感じね」という感じで雰囲気掴んでもらえるかと思います。
リファレンス とは、という話はここでは割愛します。
わからなくても問題ないですが、気になる人向けにperldoc.jpを置いておきます。
perldoc.jp
はてなキーワードもあるぞ。
リファレンスとは 一般の人気・最新記事を集めました - はてな
さて、実行すると、こんな感じで表示されます。
use DDP; my $hashRef = &get_english_to_japanese; # &は無くても良い。サブルーチンだと分かりやすいかなと思って書いた p $hashRef;
DDPを使うと、簡単に中身を見ることができて便利です。
% perl sample.pl
{
apple "りんご",
phone "電話"
}
printだと結果はこんな感じになります。
print $hashRef; > HASH(0x15580aa68)
リファレンス(ハッシュ全体を参照するスカラ)になっていて、そのままでは読めませんね。
後置デリファレンスを使ってデリファレンスします。
print $hashRef->%*; > appleりんごphone電話
DDPを使った結果と比べると読みにくいですね。
sportsを足してみる
さて、ここでget_english_to_japaneseに他のペアも追加したいと思いました。
スポーツ系の単語を追加したいと思ったので、スポーツ系の単語をまとめたサブルーチン(sports)を作成し、get_english_to_japaneseからsportsを呼ぶことにしました。
use strict; use warnings; sub sports { return [ { english => 'soccer', japanese => 'サッカー', }, { english => 'baseball', japanese => '野球', }, ]; } sub get_english_to_japanese { my $sports = sports; return +{ apple => 'りんご', phone => '電話', # ハッシュの配列を作成 ( soccer => 'サッカー', baseball => '野球' ) map { $_->{english} => $_->{japanese} } $sports->@*, }; }
実行すると、このような結果が得られます。
% perl sample.pl
{
apple "りんご",
baseball "野球",
phone "電話",
soccer "サッカー"
}
やった！実装できましたね。
colorsを足してみる
この調子で、色のペアも追加していきます！
sub colors { return [ { english => 'red', japanese => '赤' }, { english => 'yellow', japanese => '黄', }, ]; }
sub get_english_to_japanese { my $sports = sports; my $colors = colors; return +{ apple => 'りんご', phone => '電話', map { $_->{english} => $_->{japanese} } $sports->@*, map { $_->{english} => $_->{japanese} } $colors->@*, }; }
さっきと同じノリで、sportsの後ろにcolorsを足して、実行します。
ERROR
% perl sample.pl
Can't use string ("red") as a HASH ref while "strict refs" in use at sample.pl line 37.おや、怒られてしまいました(´･_･`)
37行目は`map { $_->{english} => $_->{japanese} } $sports->@*,`の行ですね。
mapが展開されて、↓のような結果で実行されると思ったのですが、何が問題なのでしょうか？
どうすれば意図した出力結果を得られるのでしょうか。
return +{ apple => 'りんご', phone => '電話', ( soccer => 'サッカー', baseball => '野球' ), ( red => '赤', yellow => '黄' ), };
ところで、「おや？ハッシュの中に配列が入っている？」と違和感を感じている人向けに説明をすると、Perlでは、配列の中の配列は展開・連結される仕様となっています。
配列の中の配列？はい、PerlのHashは、文字列がキーになった配列です。
また、次の二つは同じです。
(さらに、1の書き方の場合は、キーの文字列をクォーテーションで囲まなくても大丈夫です)
1. ( apple => 'りんご', banana => 'ばなな' ) 2. ( 'apple', 'りんご', 'banana', 'ばなな' )
ハッシュとして扱えばハッシュ、配列として扱えば配列になります。
{
apple "りんご",
banana "ばなな"
}
[
[0] "apple",
[1] "りんご",
[2] "banana",
[3] "ばなな"
]
ちなみに、 => のことをfat commmaと呼びます。
「Perl fat comma」で調べると、有益な記事が多く出てきます。
このあたりについては、O'Reilly Japan - 初めてのPerl 第7版で、2の書き方→1の書き方の順番で丁寧に説明しています。
Deparse してみる
では、実際どうなのか？そのことを調べるために、Deparseを使います。
% perl -MO=Deparse sample.pl
sub sports {
use warnings;
use strict;
return [{'english', 'soccer', 'japanese', "サッカー"}, {'english', 'baseball', 'japanese', "野球"}];
}
sub colors {
use warnings;
use strict;
return [{'english', 'red', 'japanese', "赤"}, {'english', 'yellow', 'japanese', "黄"}];
}
sub get_english_to_japanese {
use warnings;
use strict;
my $sports = sports();
my $colors = colors();
return {'apple', "りんご", 'phone', "電話", map({$_->{'english'}, $_->{'japanese'};} @$sports, map({$_->{'english'}, $_->{'japanese'};} @$colors))};
}
Deparseしたことで原因がわかりましたね。
つまり、下記のように、mapの解釈が意図と違って解釈されていた、というわけなのです。
一つ目のmapが取る配列が、二つ目のmapの結果の配列と結合しているんですね。
return +{ apple => 'りんご', phone => '電話', map { $_->{english} => $_->{japanese} } ( $sports->@*, map { $_->{english} => $_->{japanese} } $colors->@* ), };
mapのところを一部展開してみると、こんな感じですね。どうみてもおかしいね。
map { $_->{english} => $_->{japanese} } ( ( { english => 'soccer', japanese => 'サッカー' }, { english => 'baseball', japanese => '野球', }, ), ( red => '赤', yellow => '黄' ) ),
というわけで、解決策は、「(一番最後以外の)mapに明示的に括弧をつける」でした。
ただ、次にまたmapが増えるかもしれないことを考えると、統一感を出して全てに括弧をつけるようにすることが良いと思います。
括弧の付け方は二通りあります。
( map { $_->{english} => $_->{japanese} } $sports->@* ), map ( { $_->{english} => $_->{japanese} } $colors->@* ),
この状態でDeparseすると、括弧の位置が意図した通りになっています。
map({$_->{'english'}, $_->{'japanese'};} @$sports), map({$_->{'english'}, $_->{'japanese'};} @$colors)
おわり
というわけなので、mapとハッシュと配列を一緒に扱うときは気をつけましょう。
そして、DPPとか、Deparseとか、これらは困った時に役立ちますね。
はやくこういったツールを使いこなせるようになりたいと思います。
ところで、はてなキーワードにはPerl関係のキーワードが豊富そうで、書いていて面白いですね。
読んでいてわからなかったらキーワードに飛んでくれ！ってできそうなところが良い。
id:CNaanのこれからのご活躍にご期待ください( ˘ω˘ )
では。
Rubyでも同じようなことできるのかなって思って途中までやったけどPerlと全然違うコードになってきたのでやめた (¦3ꇤ[▓▓]
*1:特に既存のコードの雰囲気を真似て書こうとする人とか
