Masteries

技術的なことや仕事に関することを書いていきます.

#プログラミング原体験

blog.utgw.net


※ 以下, 自分語りをしています.

プログラミングに興味を持ったのは, 根源をたどると幼稚園児の頃に父親が確かIBMのパソコンを買ったのがきっかけ... だった気がします. Windows 3.1が動いていて, 「A列車で行こう4」とかで遊んでいた記憶があります.

小学生になると, Windowsは95や98を使うようになっていて, 「Age of Empire」シリーズやRPGツクールのゲームで遊ぶようになっていました. そこから, 「こういうゲーム, 作ってみたいなあ...!」と思ったのが, プログラミングに関心を持ったきっかけでした.

中学校, 高校と, 引き続きそういった領域に対する興味は持っていたのだけれど, 自分の持ち前の悪い方向の怠惰さが影響してか, 実際にプログラミングを書いてみよう! 動かしてみよう! ということにはならなかったのですよね. RPGツクール2000を親に買ってもらって, ゲームを作ったりはしていたけれど(既存のゲームを参考に, オリジナルの戦闘システムとか作ろうとして頓挫するタイプの子供だった), そもそもとしてプログラミング言語を扱う環境を作る, というところで諦めてしまっていました(確か当時は適当に調べていたので, 「プログラミングするにはLinux? っていうやつがいるんでしょ? なんかめんどくさそう...」とか思っていた気がする. 今からすれば「四の五の言わず, やれや!!!」って感じなのだけれど...).

...後は, プログラミングには興味を持ったものの, なんというか, 「興味」で留まっていて, 「具体的な夢」にはなっていなかったので, とりあえずいろいろやってみよう! の精神があったのかもしれません. ということで, 高校まではそういう感じで, 割と普通な(そして若干オタクな)学生として過ごしていました.


というわけで, 本格的にプログラミングを始めたのは大学に入ってからでした. 結局, 高校までの時間を過ごして「(職に繋がりそうな方向性で)やってみたいな」と思えたのがプログラミング(情報科学)だけだったので, 指定校推薦で関西学院大学の情報科学科に入り(当時の成績かつ関関同立の情報系学部で行けるのがここしかなかった!), 講義でC言語を触ったのがちゃんとした(?)プログラミング体験の第一歩でした. 「自分の書いたコードが動く」というのがとにかく最高の体験で, 授業はめちゃくちゃ楽しかったのを今でも覚えています.

...というわけで, 「#プログラミング原体験」の最初のエントリを書いた id:utgwkk さん達みたいに, 小学校や中学校など, 幼い頃からプログラミングをしてこなかった... というのは, 割と自分の中ではコンプレックスというか, 「みんなちゃんと経験積んでいて凄いな」とか, 「ショボくてすいません...」みたいな気持ちを時折呼び起こすのですよね... まあ逆に言えば, 大学からプログラミングを始めたような自分でも, 今なんとかコードを書いてメシを食えているので, 「大学からプログラミング始めたんすよね...」という人も「まあなんとかなるぞ!」と言えるのかな... と思っています.

話を戻して... 通常研究室配属は4年のところ, 一部学生は3年から仮配属が出来る, という制度があったので, 講義が面白かった教授(石浦 菜岐佐教授)のところに配属してもらいました. そこで出会ったのがPerlです. 授業ではC言語など, 型がある世界でコードを書いていたところ, Perlの型のない世界が逆に斬新で, ハマりました. なんというか自由さを感じたんですかね...? あとはシュッと書いてシュッと動く, という体験が良かったのかもしれません.

研究室でPerlを使ってあれこれ研究しつつ, 趣味でCGIを使ってTwitterクライアントを書いたり(まさに自分もprint "Content-Type: text/html\n\n"とか書いてた!), 友達が遊んでいたブラウザゲームのデータを分析するツールを作ったり... いろいろコードを書いていた気がします. そういえば, PlackやAmon2と出会った時に, 「えっ, こんなに簡単にウェブサービスが書けるの!?」って感動した記憶がありますね.

...今にして思うと, ここでRubyやPythonと出会っていたら, 多分自分の人生は大きく変わっていたのではないかなー, と思います. 多分はてなに入る事もなかったのではないか. 一方で, 自分はPerlと, Perlを通じて知り合った人たちと出会えて本当に良かったと思っていて, そういう意味で石浦教授は最高の恩師だと思っています.

後はなんやかんやあって修士まで石浦研究室でお世話になり, その間にKansai.pm/Kyoto.pmやYAPC::Asiaに参加したり, Perl入学式を立ち上げたりしてから, なんとなく就職して, 今に至る... っていう感じです.


改めて振り返ってみると, やっぱり自分は「動くもの(Webサービスとか...)を作る」というのが好きなのかな... っていう感じがします. だからコードを書くのは超楽しいし, 「チームで」サービスを作るための道具(?)として, アジャイルやスクラムとかにも関心を持てたのかな..? という気がします. id:onishi の「手を動かした者だけが世界を変える」の通り, これからも様々な形で手を動かしながら, Webサービス開発に携わっていきたいな, って改めて思いました.

「吉祥寺.pm 25」でmisspellについて話しました

kichijojipm.connpass.com

「Kichijoji.pm 25」で, misspellというツールについて話しました.

github.com

実のところこのツール, 先週くらいに知ったのですが, 「めっちゃ便利やん!」となり, 今業務で触っているツールに勢いよく適用してミススペル(typo)を撲滅, 更にreviewdog/action-misspellを導入して, 自動的に指摘してくれるようにしたりしていました.

ちなみに, reviewdog/action-misspellを含む, CI/CD関連のTIPSについて, 来週TECH PLAYのイベントで話すことになりました. 興味ある方はこちらもぜひ. 業務でやったGitHub Actions化や, GitHub Actionsを使った便利な自動化などのTIPSについて話す, 予定です.

techplay.jp

小ネタ: Perlで関数の返り値の一部を無視する

例えば, func という関数があって, これが次のような実装になっていて, 3つの返り値を返すとします.

sub func {
    ...
    return ($x, $y, $z);
}

func を呼び出す際, 「返り値の1つ目と3つ目は利用するけれど, 2つ目は利用しない」という時は, undefを使って次のように書けます:

my ($x, undef, $z) = func();

ここでのundefは, Go言語におけるアンダースコア変数みたいなもの... と捉えると良さそうです.

x, _, z := func()

myundef組み合わせるの, 実は未定義動作だったりしないかな...?」と一瞬思ったのですが, perldocでも,

perldoc.jp

my ($x, $y, undef, $z) = foo(); # Ignore third value returned

...という形で紹介されているので, 普通に使える小技(?)と思って良さそうです.

不必要な変数は宣言しないに越したことはない(例えば2つ目の返り値を, 使わないのに$yとして定義すると, 後で$yはどこで使っているのだろう...? と混乱してしまう)ので, 使えるシーンがあれば積極的に使っていきたいところですね.

今だからこそ「リモートワークの達人」読んだ

昨今このような情勢で, そろそろ1年近く在宅で勤務しているので, 今あらためて「リモートワークの達人」を読んでみました.

読書メモ

- 毎日4時間はみんな同じ時間に働いたほうがいい
- 週に一度「最近やっていること」というテーマで話し合いの場を設けるとよい
-- 1週間でやったこと, 翌週やることを手短に書き込む
-- 作業の調整は不要で, 一緒にやっているという感覚を持てると良い
- リモートワーカーが孤独になりやすいのは事実. だから意識的に外に出た方がいい
- リモートワークにおいては, 働かないより働きすぎる方を心配するべき
-- 気がついた時には完全に燃え尽きている可能性がある
- リモートワークをうまくやるには?
-- こまめに成果を見せる
-- いつでも連絡が取れるようにする
- リモートワークでは, オフィスで働く以上に人の繋がりが重要
-- 文字だけでやり取りする時, 人は悪い方に流されやすくなる
-- 前向きな人間を集め, チームメンバーを思いやり雰囲気を盛り上げるタイプの人が必要
- 「嫌な言葉」, 「感情的な対立」, 「悪いムード」を徹底的に排除していくことが大切
- メールやチャットや掲示板で話し合いをするので, リモートワークには文章力が欠かせない
-- 採用するなら, 判定基準に入れた方が良い
-- 文章がうまくなる方法は読むこと. 文体は二の次, まずは明晰さ
- 2ヶ月に1度のペースで1on1を実施する. 毎月出来るといいが, 2ヶ月でうまくまわっている
-- ゆるく話をする. やる気は脆いので, ちょっとした不満で仕事が進まなくなる. 1on1で定期的にチェックする
- リモートで働いていて, 一向に手が動かないと思ったら注意信号
-- 今の仕事の問題点を明らかにして, 改善する必要がある

感想/考察

週に一度「最近やっていること」というテーマで話し合いの場を設けるとよいというのは, 異動前のチームで「成果発表会」という催しがあり, 1ヶ月単位でやったことや所感などを共有して, フィードバックをしあっていたので, 割と良かったので納得度がありました. 今のチームはチームの人数が多いこともあってそういった催しはないのですが, 人数が多くてもやれる良い方法はありそう, と思ったので模索していきたいですね.

「リモートワークでうまく仕事をするには?」のところで, コツとして「こまめに成果を見せる」, 「いつでも連絡を取れるようにする(反応する)」というのが書かれていて, これは最近意識していることなので裏付け(?)が得られた気持ちになりました. こういう振る舞いが安定して出来ると, 信頼貯金を貯めやすくなるように思います.

あとは, (「あわせてよみたい」で紹介しているshibayuさんのエントリでも触れられていますが)「嫌な言葉」, 「感情的な対立」, 「悪いムード」を徹底的に排除していくことが大切というのは本当にそうですね. オフィスで働いている時より, リモートワークの方がそういった状態に陥った時のリカバリーコストが高い気がしているので, そうならないように割れ窓理論的に先手打って対応していくのが大事そう, と思いました. チームでは割とシニア寄りなので, そういったところ俯瞰して気付けるようになれると良さそうです.

元々, 京都/東京という2拠点で仕事をしていたこともあって, 昨今のコロナ禍で在宅勤務になっても, 割とスムーズに移行できたのではないかと思っています. うまいことやっていくための暗黙知? みたいなものを, この本を通して改めて文章化できたなーと思います.

あわせてよみたい

blog.shibayu36.org

LWP::UserAgentのタイムアウトがうまく効かなかった事象の調査 (序章)

皆様, メリークリスマス! この記事は, 「Perl Advent Calendar 2020」の25日目の記事です.

qiita.com

昨日は, id:hitode909 さんの「Perlアプリケーションの依存モジュールの更新についてWEB+DB PRESS vol.120のPerl Hackers Hubに寄稿しました」でした.

blog.sushi.money


さて, 本題です. Perlにおいて, HTTPリクエストを送る時のデファクトスタンダードと言えばLWP::UserAgentではないでしょうか.

metacpan.org

LWP::UserAgentには, timeoutというオプションがあります. 2020年12月25日現在の最新版は6.50ですが, このバージョンではtimeoutのデフォルトは180秒となっていて, この場合HTTPリクエストを送って180秒経過するとその通信を打ち切ってくれます(リクエスト先のサーバーで処理に時間がかかり, 180秒で返せなかった場合など).

先日, ある特定の状況下でこのタイムアウトが効かず, しばらく処理が続いてしまうという事象に遭遇しました. LWP::UserAgentのログを手がかりに調査した様子を紹介することで, 「Perl Advent Calendar 2020」の25日目の記事としようと思います.

...ただ先に述べておくと, 今回は時間の制約上「こうかな...?」という仮説を立てる所で力尽きてしまいました. なので, どちらかというと, 「ログを参考にして実装を追う」時の一例, として見てもらった方が良いかもしれません.

LWP::UserAgent

該当のリクエストにおいて, LWP::UserAgentは以下のようなリクエストを出力していました:

500 Can't connect to example.com:80

これを手がかりに, まずはLWP::UserAgentCan't connect toといったログを出力している場所を探してみました. ちなみにこういう時は,

  • metacpanでGitHubのLWP::UserAgentの実装があるリポジトリを探す
  • 見つけたリポジトリを, ghqで手元にclone
  • kazuhoさんのブログで紹介されていた「peco改」で探し, エディタで開く

... という流れが多いです.

github.com

blog.kazuhooku.com

さて, そうすると, LWP::Protocol::http に次のようなコードがあることがわかりました. LWP::Protocol::http は, その名の通りHTTPプロトコルによる通信を司るモジュールなので, ここを調べていくと良さそうです.

github.com

   # IO::Socket::INET leaves additional error messages in $@
    my $status = "Can't connect to $host:$port";

前後のコードを追いかけていきましょう. すると, この直前で $self->socket_class->new() を使って, $sock という変数を定義していることがわかります.

github.com

    my $sock = $self->socket_class->new(PeerAddr => $host,
                    PeerPort => $port,
                    LocalAddr => $self->{ua}{local_address},
                    Proto    => 'tcp',
                    Timeout  => $timeout,
                    KeepAlive => !!$self->{ua}{conn_cache},
                    SendTE    => $self->{ua}{send_te},
                    $self->_extra_sock_opts($host, $port),
                       );

LWP::Protocol::http における socket_class の実装は以下のとおりです.

github.com

sub socket_class
{
    my $self = shift;
    (ref($self) || $self) . "::Socket";
}

この場合, $selfLWP::Protocol::http のオブジェクト, もしくはLWP::Protocol::httpという文字列になるので, つまり $self->socket_classLWP::Protocol::http::Socket を返します.

続いて, LWP::Protocol::http::Socket を探します. するとLWP::Protocol::httpと同じファイルの下に, 以下のように定義されていました.

github.com

package # hide from PAUSE
    LWP::Protocol::http::Socket;

use parent -norequire, qw(LWP::Protocol::http::SocketMethods Net::HTTP);

余談ですが, hide from PAUSEについて. これは id:Songmu さんの以下のエントリにある説明を読むとよいでしょう.

songmu.jp

...話を戻します. ここまでをまとめると, $self->socket_class->new は実際には LWP::Protocol::http::Socket->new が実行されることがわかりました. そして, LWP::Protocol::http::Socket は, LWP::Protocol::http::SocketMethodsNet::HTTPを継承したものということもわかりました.

つまり, $self->socket_class->new を呼び出した時に実行されるnew メソッドは, LWP::Protocol::http::SocketMethodsNet::HTTPのいずれかに定義されているはずです. 結論から言うと(名前からも察せると思いますが), LWP::Protocol::http::SocketMethodsにはnewメソッドがなく, Net::HTTPnewメソッドが呼び出されていることがわかります.

github.com

package # hide from PAUSE
    LWP::Protocol::http::SocketMethods;

sub ping {
    my $self = shift;
    !$self->can_read(0);
}

sub increment_response_count {
    my $self = shift;
    return ++${*$self}{'myhttp_response_count'};
}

Net::HTTP

続いて, Net::HTTPを調べていきます. 対象は, 2020年12月25日現在の最新版, 6.19です.

metacpan.org

our @ISA = ($SOCKET_CLASS, 'Net::HTTP::Methods');
 
sub new {
    my $class = shift;
    Carp::croak("No Host option provided") unless @_;
    $class->SUPER::new(@_);
}

このコードを見ると, Net::HTTPもまた何かのモジュール($SOCKET_CLASS)を継承しており, $class->SUPER::new(@_);でそのモジュールのnewメソッドを呼び出していることがわかります.

$SOCKET_CLASSを宣言している部分はと言うと, 次のような実装になっています:

metacpan.org

use vars qw($SOCKET_CLASS);
unless ($SOCKET_CLASS) {
    # Try several, in order of capability and preference
    if (eval { require IO::Socket::IP }) {
       $SOCKET_CLASS = "IO::Socket::IP";    # IPv4+IPv6
    } elsif (eval { require IO::Socket::INET6 }) {
       $SOCKET_CLASS = "IO::Socket::INET6"; # IPv4+IPv6
    } elsif (eval { require IO::Socket::INET }) {
       $SOCKET_CLASS = "IO::Socket::INET";  # IPv4 only
    } else {
       require IO::Socket;
       $SOCKET_CLASS = "IO::Socket::INET";
    }
}

つまり, Net::HTTPは,

  • IO::Socket::IPが利用可能なら, IO::Socket::IP
  • IO::Socket::INET6が利用可能なら, IO::Socekt::INET6
  • いずれも利用できないなら, IO::Socket::INET

...継承し, 利用するようになっています.

$ corelist IO::Socket::IP
Data for 2020-06-01
IO::Socket::IP was first released with perl v5.19.8

corelistコマンドによれば, IO::Socket::IPは, 5.19.8でコアモジュールとなっているので, 最近のPerlであればこれが使われる... と考えて良いでしょう. ということで, 次はIO::Socket::IPを調べていきます.

IO::Socket::IP

※この辺りから, だいぶ自信がなくなってきています. 間違ったことを書いていたら, 指摘頂けると幸いです...

IO::Socket::IPは, Family-neutral IP socket supporting both IPv4 and IPv6つまりIPv4とIPv6の両方に対応したソケット通信を提供するモジュールのようです. 今回は, 2020年12月25日現在の最新版である, 0.41を参照しました.

IO::Socket::IPのドキュメントを見ると, こちらにもまたタイムアウトのオプションがありそうです(Timeout). が...

If defined, gives a maximum time in seconds to block per connect() call when in blocking mode. If missing, no timeout is applied other than that provided by the underlying operating system. When in non-blocking mode this parameter is ignored.

  • connect()を呼び出すごとにブロックする最大時間をTimeoutで定義できる
  • 非ブロッキングモードの場合, このパラメータは無視される

This behviour is copied inspired by IO::Socket::INET; for more fine grained control over connection timeouts, consider performing a nonblocking connect directly.

  • もしタイムアウトを細かく制御したければ, 非ブロッキングモードで実行することを検討せよ

...といったことが書かれている, ように見えます. ちなみに"ブロッキングモード"は, Blockingというパラメータで制御できるらしく, 説明を読むと...

If defined but false, the socket will be set to non-blocking mode.

...つまり, デフォルトはブロッキングモードが有効で, 偽値を指定すると無効(= 非ブロッキングモード)になる... ようです.

ちょっと複雑なので説明を端折りますが, LWP::Protocol::http$self->socket_class->new()すると, 最終的にはIO::Socket::IPconnectメソッドが呼ばれます.

metacpan.org

ここで, Perlのconnect()関数が呼ばれているようなのですが, ここにTimeoutが渡っていない(渡せない)です.

というわけで, 万が一, 例えばリクエスト先のサーバが不調などの原因で, このconnect()関数の呼び出しに時間がかかってしまった場合, LWP::UserAgentに渡したtimeoutオプションを無視して待ち続ける... ということが起こりうるのでは...? という仮説を立てるところまで至りました.

ソケット周りの知識, 大学で学んだはずなのですが大昔すぎて忘れてしまったりということもあり, ちょっと中途半端ではありますが, 今回はこの辺りで一旦終了としようと思います... が, 流石に不完全燃焼なので, 本当にconnect()関数の呼び出しの部分に原因があるのか? であったり, IO::Socket::IPの非ブロッキングモードで回避する方法はあるか? といった所について, 改めて調べてみたいと思います.

...中途半端なオチですいません.


さて, このエントリで「Perl Advent Calendar 2020」も無事終了です!!! 最終日まで, だれ1人欠けることなく, 珠玉の25記事が集まりました.

qiita.com

2020年といえば, 開催を予定していたYAPC::Kyotoが新型コロナウイルスの影響で中止となってしまいました. しかしながら, 2021年に向けてオンライン形式でのイベント, 「Japan.pm」の計画が進みつつあります.

2021年が, Perl Mongerの皆様にとって実りの多い1年になることを祈りつつ, 「Perl Advent Calendar 2020」の25日目の記事を終えたいと思います.