NeverBlog::Likk::Unexistable;

見なかったことにして下さい

YAPC::Kansai 2017 に行ってきた

先日開催された YAPC::Kansai 2017 OSAKA に行ってきました。

今回の記事ではトークについては触れません。別途書くかもしれないけど未定。
懇親会で飲みながら会場について思うことを2・3話していたら
「@karupanerura 氏 に言えば良いんじゃね 」とか
「ブログに書けばいいんじゃね」みたいなことを言われたので記事にしました。
思ったことを思い出しながらつらつら書いてるので非常に読みにくいかもしれないので先に謝っておく。
あと、単に感想であって要望では無いので「そういう意見もあるのかー」ぐらいに捉えてくれると嬉しい。

会場について

会場はこちら MOTEXホール
前夜祭の場所とYAPC当日の建物(入り口)が一緒というのは非常にありがたかった。覚えることが少なくて済む
前夜祭が10F, YAPC当日が1-4F。
前夜祭が食事付き。たこやきと、肉まんごちそうさまでした。大阪ついてすぐご当地グルメできたのは良いですね。
カフェスペースが良い雰囲気を出していたので、リラックスしながらトークを聞けました。


YAPC当日は2-3Fホールにテーブルが無かったのが少し残念。
持っていったPCが Surface だったため、膝を台にすることもできず(できなくはないけど、たまにディスプレイが外れて前方に落ちる)キー入力にもかなり手間取った。
MacBook なら大丈夫だったのかもしれませんね。MacBook ください。
キー入力なんかしてないで、しっかりトーク聞けよって計らいなのかもしれません。


B,C 会議室はほとんど利用しなかったけど、電源もありデスクもあり。あることが普通だと思ってたけどありがたいことなんですね。
セッションによってはキャパオーバ気味だったけど、想定よりトークを聞きに来る人が多いとかは割りと毎年あるし、よくあることなので気にしない。


会場 Wifi がなかったので個人端末の Wifiを有効にした。あることが普通だと思ってたけどありがたいことだったんですね。
スピーカーの方がパケ死しない程度に用意されてると良いのかもしれない。
スピーカー用に用意したら用意したで今度は個人のwifiが邪魔になってきそうではある。

次回の会場にあると良いなあと思うもの

  • wifi
  • デスク
  • YAPC::Hokkaido にあったA会場のミラー兼電源ルーム
    • いやあれ、すっげー良かったよ!!ミラーだから会場の空気が伝わりづらいし、スピーカに直接質問できないからあんまり利用者がいなかったかもしれないけど、人が少ないからリラックスして聞けたし電源豊富だし、ちょっと席を立って飲み物買ってくるのにスピーカーの方に対してなんか申し訳ない気持ちにならなくていいし、今回も欲しかったな!!きっとそういう感想を伝えたりブログに書く人が少なかったから今回無くなったんだな!!よし今回は書いたぞ!!

Perlで 'use strict;' をしない状態で 'return nil' をした時の挙動

こんばんわ、忘年会シーズンというにはもう遅いタイミングですね。

先日 gotanda-pm 忘年会の酒の席の話で
"Perlで 'use strict;' をしない状態で 'return nil' をした時どうなるか?" といった話が上がり
酒の席のせいか妙にテンションが上りツボに入ってしまい以下のようなツイートをしました。

ruby を普段書いてる人が perl を書くと起き得る事故ですね。

通常 `use strict;` をした状態だと `nil` ベア(裸の)ワードの最適化を制限してくれてコンパイルエラーを出してくれます。
ですが `use strict;` をしないどうなるか?
最適化の結果 nil は値が設定されてないし、関数も無いし予約語でも無いので偽が返すと解釈し上記のようなツイートにつながりました、
では、実際に実行してみるとどうでしょうか。

$ perl -E 'say sub { return nil}->()';
nil

おや、nil が返ってきますね。ツイートした内容と相違があります。
これは perl ではどのように解釈してるでしょうか

$ perl -MO=Deparse -E 'say sub { return nil}->()';
use feature 'current_sub', 'evalbytes', 'fc', 'say', 'state', 'switch', 'unicode_strings', 'unicode_eval';
say sub {
    return 'nil';
}
->();
-e syntax OK

文字列 "nil" と解釈してるのが分かります。
perl は文字列を真として扱ってくれますので、結果としてツイートの内容が"偽" であるというオチがついてしまいました。

ということで以下の締めになります。



以下蛇足:


`print nil;` が何も出力されないので、nil が undef っぽい挙動になります。

$ perl -e 'print nil';
$

これはどう解釈してるか同様に見てみるとすぐに分かります。

$ perl -MO=Deparse -e 'print nil';
print nil $_;
-e syntax OK

nil をファイルハンドルとして扱ってそこに print してるから。
つまり`print nil $_` として解釈をしてるので何も出力されない挙動となります。

use strict!

Acme::Kiyoshi でっちあげた

元ネタ

だいぶ出遅れてる感じがあるけど Perlで書いたのでgithubに上げた。

github.com


インストールしたら

perl -MAcme::Kiyoshi -E 'kiyoshi'

で実行できます。今のところ最短タイプ数であなたもZUN DOKO KIYOSHI!ができます。
以下、実行結果。

$ cpanm https://github.com/Likk/Acme-Kiyoshi.git
Cloning https://github.com/Likk/Acme-Kiyoshi.git ... OK
--> Working on https://github.com/Likk/Acme-Kiyoshi.git
Configuring /tmp/R_aUbFiUCB ... OK
Building and testing Acme-Kiyoshi- ... OK
Successfully installed Acme-Kiyoshi-
1 distribution installed
cpanm https://github.com/Likk/Acme-Kiyoshi.git  2.02s user 0.34s system 52% cpu 4.508 total
$ perl -MAcme::Kiyoshi -E 'kiyoshi';
ZUN ZUN DOKO DOKO ZUN DOKO ZUN DOKO ZUN DOKO ZUN DOKO DOKO DOKO ZUN ZUN ZUN DOKO ZUN DOKO ZUN DOKO ZUN DOKO DOKO ZUN ZUN ZUN ZUN ZUN ZUN ZUN ZUN DOKO KI.YO.SHI!


久々にブログ書いたかと思えば何をやってるんだ自分は。

Gotanda.pm #6 で飛び込みLTしてきた。

Gotanda.pm #6 2015/09/17 (木) からかなり時間が経ってからのブログ書き込みだけど気にしない。

テーマは「障碍」でしたので何かやろうかなと思っていたけどスライド用意している時間がなくて、LTするつもりは無かった。
全てのプログラムが終わり、同会場内で懇親会を始めるタイミングだったのですが、
懇親会側の準備が終わってなく時間が余ったので肉が焼けるいい匂いの中スライドもなしにTLしてきました。


障碍というテーマにそって「リアルで障碍が起きたとき通知をするbotを以前作ってましたよー、リアルな障碍とは何か、例えば電車遅延だったり、地震だったり、台風だったり、あるいはYAPCでLTした雨雲通知だったり、そういうの。」とい内容で話してきた。
情報を取得するライブラリはgithubに全部上がっるので自分のgithubリポジトリを紹介するだけのLTになった。スライド無いしね。以下のリポジトリはその時に紹介したリポジトリ

Likk/WWW-JMA-EarthQuake · GitHub
Likk/WebService-TenkiJp-RSS-WeatherNews · GitHub
  • tenki.jpのRSSから、天気概要を取得する
Likk/WWW-TrainInfo · GitHub
  • 鉄道各社のサイトの遅延情報をスクレイピングして何線が遅延・運休してるかを取得する
Likk/WebService-TenkiJp-Typhoon · GitHub


ただ、「以前作ってましたよー」と言うだけの話であるとおり、今はメンテしてないので今は動かないと思う。メンテを再開したりする予定はないです。
理由としては、公式のbottwitterにあるので今はそれを見たほうが早いから。
あと、意外と気象庁や鉄道会社の公式の発表より、ニュースサイトの方が早く情報が得られたりします。
更に言うとニュースサイトよりも、ニュースサイト公式twitter botの方が速報早かったりもします。

どっちかというとリポジトリ供養LTというのが正しい。
あと、飛び込みLT楽しかった。スライドが無くても、失敗しても「飛び込みだし!!」と思えば気負うものはなにもない。(言い訳もできる!!)

お疲れ様でした。



思いつきだけどリポジトリ供養LT大会やると楽しそう。github url伝えるだけなので、みんな頑張ってスライド作る必要ないしね。
(「スライド頑張った時点でもうL(ightning)Tじゃないよね。」という面白い意見も懇親会で頂きました。)

YAPC::Asia 2015 でLTしてきた

一日目のライトニングトークにて『YAPC?雨事情』というタイトルで発表させていただきました。
スライド中で紹介したライブラリは以下です。git log たどると実は2012年ぐらいからありましたgithub.com

YAPC初LTでしたし、1000人超の前で話すことも初めてでしたので、めちゃめちゃ緊張しましたが結果的よかったと思います。



YPACには2007年から参加してましたが、毎年視聴者側で今年もLTで出る予定はありませんでした。基本的に引っ込み思案なのです。
開催一週前にたまたまGaiaXさんとモバイルファクトリー合同勉強会があり、
そこでLTする機会があったので、大体同じ内容で発表し、その勢いで応募しました。
五反田界隈のみなさまありがとうございました。


実際のLTの最中は緊張していて反応が良く分からなかったですが、
twitterや懇親会で質問や、コメントや、ツッコミを頂いたりしました。
案ずるより産むが易しのことわざ通り、一旦発表してしまうと、あと5年早くやっておけばと過去の自分を責め続けます。
来年も何らかあるのであれば、何かしらトークできるといいかなと思います。



以下、頂いた質問やツッコミに対する回答。

Q: ametto とLTとの関係。
A. 誤解を与えないよう、LT中でもお伝えしたつもりですが、アプリ ametto の機能には今回のLTで発表した内容に関わることは一切含まれてま
せん。ただのCMです。

Q: 雨通知アプリ(ammeto)があるならその機能使えばいいのでは
A: 通知基準が違います。ametto は「"降水確率"という同じ気象条件下なら統計学的にどれぐらい雨が降る確率があるか、それが一定値以上なら通知する」というにアプローチ対して、雨雲通知botは「気象レーダを使い雨雲が現在どこにあるか地図上に表示する画像を解析し、特定地点の色が晴天時と差異があれば通知する」というアプローチです。今日の品川区の降水確率が100%だからといって、今現在五反田駅周辺で降ってるとは限らないということです(どっちにしろ、傘持って出る必要はありますが)。ついでに言うと雨雲通知botのほうが歴史が古いです。

Q: 残り時間がGame Overだ
A: リロード忘れました。というか回線が不安定でリロードする勇気がありませんでした。スライドはローカルにおいておくべきでした。

オチ

String::Slack でっちあげた

github.com

使い方は簡単で

say String::Slack->new("message")->bold->italics->stringify; #_*message*_

となる。


きっちりとslack.com に投げるところまで書く場合のsampleコードもつけた。

use strict;
use warnings;
use Furl;
use JSON::XS              qw/encode_json/;
use HTTP::Request::Common qw/POST/;
use String::Slack;

my $message = 'hoge';
my $url     = 'https://slack.com/api/chat.postMessage';
my $token   = 'xxxxx-XXXX-XXXX';
my $channel = 'XXXXXXX';

my $data = {
    channel => $channel,
    text    => String::Slack->new($message)->bold->italics->stringify,
    as_user => 1,
};

my $request = POST($url,
    Content_Type => 'form-data',
    Content      => [
        token => $token,
        %$data,
    ]
);

my $res = Furl->new->request($request);

こんな感じで簡単にslackに投げる文字に装飾をつけることが出きる。

DBIx::Skinnyのトランザクション観測したい。

実装書いてるうちに、どのタイミングでcommit/rollback が発行されるのか確認したくなったんだ。
そしたら。


正確にはBEGIN/COMMIT/ROLLBACK

txn_scope を使わずに、search_named() を使うと BEGIN/COMMIT/ROLLBACK はきちんとDBIx::QueryLogのログに吐かれる。かと言ってトランザクション自前管理はしたくない。どうにかDBIx::Skinny::Transactionを観測する方法はないだろうか。普通にwarnするか。



蛇足。
ソースコード見てるうちにちょっとイタズラしたくなった。



#下書きのまま放置していたので公開。
#結局 Test::Mock::Guard 辺りで観測する事に落ち着いた。