NeverBlog::Likk::Unexistable;

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

Salck::RTM::Bot を使ったら error message too long が出たのでパッチを用意してもらった

言いたいこと。

1. WebService::Slack::WebApi から Salck::RTM::Bot に乗り換えたら error message too long が出た
2. 原因が Protocol::WebSocket::Message の max_message_size を超える受信量だった
3. Twitter で呟いたらパッチ当ててもらった
4. WebService::Slack::WebApi と同様に コマンドラインから slack見るだけの gist 書いた

以下経緯と言う名のgdgdな何か

2年ぐらい前 http://likk.hatenablog.com/entry/2015/05/08/194754 に書きましたが
slack の内容を拾ってくるのに `WebService::Slack::WebApi`
github.com
をずっと使ってました。
が、業務で使うチャンネルが増えすぎたせいか、全体の発言量が増えたせいか、あるいはAPI側で変更が入ったせいか、今年の2月頃から Groups, や Channels の内容が取り切れなくなりました。正確には取れるのだが、次に取るまでの時間が制限されてしまう感じになってしまいました。

groups や channel のAPIは大量のデータを取得するような内容であれば、次の request までの interval が長く要求され(intervalを無視して取りに行ってもエラーで返される)取得するデータを少なくすれば interval が短くなります。このバランスにたいして、参加している全チャンネルの時間あたりの発言数の方が完全の越えており全てのデータを拾ってこれない量になりました。そのため、API を定期的に叩くのをやめ、Real Time Messagingを取りに行く方法に変えようと考えてました。

今まで使っていた `WebService::Slack::WebApi` にも Real Time Messaging を取るAPI はありますが、得られたwssに対して、自分でsocket 通信を開始し、
event を管理する必要があります。あと、定期的に ping を送らないとslack側から切断されたり、自前で書くつらいそうだなーと思って後回にしてました。
下記に紹介するブログでも頑張ってる感じが窺い知れるます。
hiyoko91.hatenablog.jp

slack がでたばかりの2015年から2年ぐらい経ってるし、良い感じのモジュール新しく誰かが作ってないかなーと思ってググったら、約 11,700 件 (0.38 秒)で TOP に
github.com
が挙がっていたので、それを試す事にした。
中でやってることはやっぱり同じなんですが、そこらへん全く意識せず使えるIFになってたので非常にありがたかった。

が、使ってみたらやっぱり時間辺りの発言量のせいか `error: message too long` が出てしまった。
エラーを出してる箇所を追うと、Protocol::WebSocket::Message の max_message_size を超えるとエラーがでるようになるのがわかったので、
何気なーく`Salck::RTM::Bot` の作者の @duck8823さんをフォローして、
何気なーく


って呟いたら、音速でレスポンスがきて超速でパッチの用意までしてくれました。有難うございます。

正確には完全移行しておらず、ちょっとしたAPI叩いたり、発言周りは `WebService::Slack::WebApi` のままです。
PerlでslackやるならRTMを流したり、発言に対してリアルタイムに反応したければ `Slack::RTM::Bot` をそれ以外の目的では `WebService::Slack::WebApi` が今後も良さそうですね。

あと毎回似たようなことやってるけど、コマンドラインからslack見れるツールを作りましたが、まあこれはどうでもいいですね。

YAPC::Kansai 2017 行ってきた2

先日開催された YAPC::Kansai 2017 OSAKA 行ってきました。
前回の記事ではトークに触れなかったので、印象に残ってたのを幾つか書きます。
基本的に記憶の揮発性が高いので旅行中にある程度まとめておけば良かったなと若干悔やんでます。

前夜祭

@__papix__ さん alias 作りまくって大変なことになるのは昔やったこと有るので、ある有るーと思いながら見てたけど自分の数倍 alias 作ってたので真顔になった。
「このエイリアスの中身なんだったっけ」ってなりますよね。
あと「下のレイヤでできることは任せる」は vimプラグインが太っていかないので良さそう。


@charsbar さん 左手だけで完結するの凄い、真似したいけど右手でペンで何か書きながら左手でエディタ操作は多分自分の脳の処理を越えてます。WZ Editor という名前が懐かしすぎて涙出た。


@sago35tk さん Windows 使いなので大変ためになった。紹介したツールは片っ端から試します。ThumbSense はタッチパッドに意図せず触れてしまって誤作動するケースないのかが気になります。

当日

深沢 千尋さん
書籍が何度か世話になった覚えがある。ワンライナーや社内向けツールが自分としても書きたい分野ではあるので自分のためのトークみたいでありがたかった。自分で書いたワンライナーをテンライナーにするのは他人に渡しやくすなりそう。


2017年春のPerl
sssslide.com
自分が変更を追いきれてなかった、あるいは理解が足りてなかったのが多くあったので、まとめて説明されてるのが助かりました。個人的には @INC の . 問題が一番やばそう。個人で使ってるライブラリ系がまとめて死にそう。


レガシーな Perl システムに DDD(ドメイン駆動設計) を取り入れる

www.slideshare.net
ドメイン駆動設計自体まだ余りなれていないので、導入事例とDDDの解釈とどの分を選択的に取り入れるかが参考になった。文字コード周りやガラケー対応で仕事を思い出して頭g


Perl ウェブ開発の中世 〜CGIPlack の間〜
客観的にPerl の歴史が語られていて、懐かしくもあったど、fastcgi など自分が触れてない分野も聞けてよかった。SpeedyCGI はまだ個人的には使ってる部分があります、すいません。

最後に

YAPC::Kansai 開催してくれて有難うございます。北海道から引き続き参加できて良かったし、次回の福岡も参加する予定です。
また幾つか不満を漏らしたり件について、会場、ならびにスタッフへの配慮が足りず非常に申し訳ございませんでした。

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: リロード忘れました。というか回線が不安定でリロードする勇気がありませんでした。スライドはローカルにおいておくべきでした。

オチ