21万6000個のサイコロを簡単に振る方法
はてブコメントで
216000D6とか一度でいいから振ってみたい
悲しいことにGoogle先生は99個までしか振ってくれない。
と有りました。気持ちはわかる。 さすがに現実に振ること叶わなくても簡単に多数のダイスを振る方法を一つ思い出した。
Perl のモジュールには 「Games」という名前が付けられていてモジュールがが数多く有り、その名の通りゲームに関連したモジュールが登録されています。
そのうちの一つに、その名の通り Games::Dice というモジュールがあります。これを使って 216000個のダイスを降ってみましょう。
cpanm が入ってれば cpanm Games::Dice で簡単に入ります
$ cpanm Games::Dice --> Working on Games::Dice Fetching http://www.cpan.org/authors/id/R/RJ/RJBS/Games-Dice-0.045.tar.gz ... OK Configuring Games-Dice-0.045 ... OK Building and testing Games-Dice-0.045 ... OK Successfully installed Games-Dice-0.045 1 distribution installed
あとはワンライナーでいけます
$ perl -MGames::Dice -E 'say Games::Dice::roll(q{216000D6})'
755615
一回試したときの出目は755615
ダイスロールの表記 nDm のルールを知っていれば個数、面数幾らでも変更できます。 nがダイスを振る個数、mが一個あたりのダイスの面数(最大値)になります。 21面ダイスのように現実ではそうそう手に入らないダイスでも振ることができます。
合計値ではなく、各ダイスの出目を知りたいときは roll_array メソッドを使いましょう。さすがに 216000個の出目を記事に並べる気はしないので各自試してみてください。
わざわざモジュールインストールしなくても perl -E '$c += int(rand(6))+1 for (1..216000); say $c' で一発だし、何ならPerlじゃなくてもいいんだけどね。
Let's enjoy perl
YAPC::Fukuoka 参加してきた（当日編）
YAPC::Fukuoka 参加者側としての記事。当日分です。
先日分:http://likk.hatenablog.com/entry/2017/07/04/170842
発表者分:http://likk.hatenablog.com/entry/2017/07/02/092721
オープニングの途中から参加。過去の参加では昼から参加したり、オープニング後から参加したりが多かった。
会場での禁止事項・諸注意などがあるので実は結構重要なんだなと認識しました。でも途中参加。
以下、聞いて印象に残ったトークと感想。
レガシーperl と今
- https://speakerdeck.com/pyama86/regasiperlto-jin-wozu-mihe-wase-kai-fa-woji-sok-sisok-kerufang-fa
- 諸事情で perl.5.8 のまま頑張ってる。
- セキュリティ的な要件がなければ無理に上げる必要はない。
- テストの密結合の場所を減らす
- 外部API要因はmock化
- DB要因はTest::Mysqld を使う
- デプロイ周りで手動でやってた所を https://github.com/capistrano/capistrano を使ってオートメーション化した
どうしてもバージョン固定で動かしたい現場のノウハウ。
とっととバージョン上げたいけど、やんごとなき理由でできない。そういう局面は発生しうるよなーと思いながら聞いた。
最後の「流行りだけではなく、チームマッチングも考えた選択をしよう」というひとことにグッと来た。
稼働中の Web サービスの Perl 処理系バージョンアップをしていく話
https://speakerdeck.com/astj/jia-dong-zhong-false-web-sabisufalse-perl-falsebaziyonwoshang-geteiku
- 上げるのではなく、上げ続けられるようにする体制をつくる
- パッチバージョンはとっととあげよう
- マイナーバジョンは2年経ってもう1年使いたいなら上げる
- どっかの検証環境でバージョン上げて caton insatll おちたら cpan test を見る
- perlのバージョンアップより、CPANのアップの方で挙動変わる可能性が高いので先にCPANあげる
- 一度実績があると二度目は楽
ゴールがバージョン上げる話ではなく、バージョン上げる体制をつくる話なのが素敵。
上げる基準や対象も明確になって、聞く人が着手しやすい状態になってるの凄い。
ウェブセキュリティの最近の話題早分かり
- https://www.slideshare.net/ockeghem/yapcfukuoka2017hakata
- 別人問題(CDNキャッシュ)
- wordpress の脆弱
- Struts2脆弱性事故
- movable type plugin
- Webdav put を許してたゆえの事故
- SSI + XSS
実例を挙げ、再現デモをしながらの説明で非常に理解しやい構成。
設定の不備をなくすのと、アプリケーションの脆弱性を潰すのが大事だそう。
脆弱性をキャッチした時点で、場合によってはサービスを止める勇気も必要だそうです。
ドキュメントよく読もう。必用に応じてテストしよう。
分散ユニークID採番機katsubushiとWebアプリケーションへの応用例
katsubushi を利用するかどうかは別として、nginx に振られた時点で一意の ID 発行して引き回すのは使いたい。
katsubushi では発行された一意の ID を元に時間を知ることができるのも便利だ。
はてなブログ最近の開発テクニックと最新の開発風景のご紹介
移行について「連続的に移行できるか、一般的な概念であるか、失敗したら戻せるか」という観点で観ていてグッと来た。
あと、(非エンジニア環境の)エラーと、deploy 促す slack-bot 欲しい。
Web application good error messages and bad error messages
- https://speakerdeck.com/moznion/web-application-good-error-message-and-bad-error-message
- 良いエラーメッセージと悪いエラーメッセージ
- エラーには次元と方向性がある(情報量と5W1H)
- 短寿命と長寿命がある(姑息対応、根本対応)
- そのエラーメッセージは誰が読むのか
良いエラーメッセージと悪いエラーメッセージの話。
エラーメッセージを出す際は、それは誰が読んでどう対処して欲しいかを考えながら出そう。それができてないのは悪いエラーメッセージと理解した。
時間がないと後者になりがちなので反省している。
cpm
制作過程で一旦立ち止まって、シンプルに機能分解して考えた話を聞けてよかった。
cpm については、そろそろプロダクトで使いたい。少なくとも個人ではガンガン使っていきたい所感。
P6W に基づく Perl6 に於ける Web 開発の基礎となる Crust
perl6触る予定が無いのに聞いてしまった。でも、こういうトークがきけるのもYAPCの醍醐味。
かなり息抜き気分で聞いてしまった。
スペシャルセッション
- 何故、今福岡か。福岡企業の話。
- 開発拠点としての福岡とその魅力
- 5年ぐらい前から徐々に盛り上がってきた
- 技術的なアピールがしやすくなってきた
- 採用難しい/優秀な人に来てもらうしかない/中途採用送り込む
- アジア圏のエンジニアとコンタクトを取る
- ソフトウェアの開発なら場所関係ない
- コミュニティ、母数が少ない代わりに緊密
- 義理堅い/仕事変える人(job-hopper)少ない/人材が硬直化
- 特化した人ほしいけど、中で教育するので特化した無くても良い
- 専門にこだわり過ぎなくていい/フレキシブルに挑戦できるマインドがあればいい
福岡の魅力と、福岡に来て欲しい人材の話と、採用の苦労・課題の話を聞けた。
以外と地方でも給与テーブルが東京都変わらない企業もあるので、環境が許されるならそれもありかな。
新時代のテストフレームワークTest2
- https://speakerdeck.com/akiym/xin-shi-dai-falsetesutohuremuwakutest2
- perl 5.26 から Test2 使える
- Test::Builder を置き換える
- test::builder にモンキーパッチあててるとコケる
- cartonでバージョン固定してない/依存モジュールがTest2に依存
- 急にテストがコケるまえにTest2に移行しよう
- Test2でのテストの書き方と便利情報
Test2でのテストはまだ試してない、Testのバージョン上げた際にコケるところありそうだから事前に例を聞けてよかった。
スキップしていいテスト、スキップしてはいけないテスト
- https://speakerdeck.com/mackee/need-for-speed-of-testing-in-perl5-web-application
- 局所的にスキップではなく、スキップするなら全部
- 現状あるテストの改善/ドメイン特化/perl5のテスト
- テストを書こうという時代はすでに過ぎてる/テストし易い環境の話
- 一日一回はデプロイする/リリース前にフルテスト
- デプロイできるタイミングが限られている
- master データは別でテストする
- マスタデータはキャッシュする
- 時々コケるコード -> 時々コケないように治す
- 差分がなければテストはスキップする
- DBに突っ込まず、CSVのままテストもできる
- 速さのためにテストしたいことがが歪まないように気をつける
- N+1 検知/このメソッドを叩くときは、この prefech が叩かれないといけませんよ。という modifire
- テストだと壊さないので思い切ったことできる
- フローの改善にもなる
割りと近いところがあると思った。心に刺さるものがいくつか合ったので、パクら参考にせてもらいます
LT
- 牛向けウェアラブルデバイス
- 今日のブラウンの帽子はラリー帽子。Perlエンジニア募集中
- バグ報告者への敬意を払う。適切と思う範囲で上限設定
- 次回は YAPC::Okinawa 2018 3/2, 3/3
- ツイートできないエディタはエディタじゃない
- MySQL Blackhole Engine でうけて、各スレーブに分ける
前夜祭のLTとは違って、比較的真面目なLTが多かった。
やっぱり雰囲気が違う。この雰囲気のなかで、前夜祭で発表したLTは出しづらいなーと思った。
（そもそも応募してないし、応募したとしてもリジェクトされてた可能性ある）
keynote
- NTで働く @dragon3 さんの話。
海外で働くことの大変さ。家族・家賃・従業員・チーム体制・求人 など色々な話が聞けてよかった。
海外に拠点を設けるのには、拠点に行く本人だけでなく、施設や給料(日本の給与水準ではNYでは住めない)・現地スタッフ・チーム・含め会社全体のかなりの負担があることを知ることができた。
また、海外で働く苦労の話は、それがそのまま、今、社内で働いている海外出身の従業員に当てはまるということも考えさせられた。
帰路にトータルで20時間かかったらしい。大変だ。東京から福岡遠いとか思ってすいません。
全体を通して
まずは会場提供のLINEさんならびに、運営スタッフの皆様有難うございました。毎回楽しく参加させて頂いています。
とにかく広いスペース(会議室というよりは普段はランチ・カフェスペースなのかな？)。カフェもある。スライド写す箇所が複数ある。
スタンディングしながら聞きやすい場所もある。ほわーラインさんすげーわ。あとテンガロンハットのブラウンかわいい。
フリードリンクサービスとにかく飲みまくった気がする。ごちそうさまでした。
今回、比較的Perlセッション多かったのでYAPCにしては珍しいみたいな変な感想を抱いてしまった。いや全然問題ないんですが。(でもベストトーク賞がperlじゃないのはお約束)
毎回ベストトーク賞のセッションのタイミングで別枠のセッションを聞いてて聞き逃すという自体が発生するのですが、今回は聞くことができてよかった。
次回は沖縄らしい。沖縄行きたい。
YAPC::Fukuoka 参加してきた（前夜編）
YAPC::Fukuoka 参加者側としての記事
当日と合わせると無駄にながくなりそうなので分けた。当日の話は明日書く。
前々夜祭 (非公式)
前々日のイベントかとおもいきや、「当日の、前の時間帯」のイベント。
とはいえ、本編が始まる前にワイワイできて非常に温まったと思う。
会場の提供とイベントの実施ありがとうございます。ビールごちそうさまでした。
トークの中で印象に残った箇所は以下。
@linyows Linux認証 octopass の話
github のAPI を使って Organization/Team で名前を解決し、githubの公開鍵を用い、github の Token でPAM認証するらしい。
自分はサーバ管理者側ではないので使う機会が無いと思いますが、小規模チームで構築する機会があれば参考にしようと思いました。
github が落ちていても(初回以外は)キャッシュを用いて使える状態にでてきているのが素敵。
@songumu Mackerelのプラグインの話
mackarel-plguin バイナリが BusyBox になっているらしい。
恥ずかしながら、BusyBoxというのをよく知らなかったので認識できてよかった。
前夜祭
ここから公式のYAPC::Fukuoka
若干迷いやすいロケーションだったと思ったけど、付近で見渡すとYAPC前夜祭案内が通りから見えるところにあり、迷わなかった。
会場は100人ぐらい入る広い会議室で、お酒も料理も種類豊富で、食いまくってた記憶もある。ありがとうごちそうさまでした。
自分のトーク枠もあったので緊張をほぐしつつ、酔っ払いすぎないようにガンガン飲んでた。ありがとうごちそうさまでした。
ざっと覚えてる限り以下な話があったと思う。
pawooの話
- 会場にpawoo 知らない人いなかった
- リリースからのパッチ時系列まとめ
最初から時間内に終わらない前提のLTもありか。
ぼっちの話
- 自分しかいないTimeline 時々botが返事してくれるらしい
なんか近いものを Slack の自分宛てdirect message やってるけど、ミニブログライクにする発想がなかった。
なお、この後自分のトークがきて、終わった安心感から飲みまくったせいかよく覚えていないしメモがあるけど
「Text::Cabocha!!」 とか、「帰ったらゼルダやりたい」とか断片的すぎてひどい。
LTでも話す側として参加すると、緊張したり、緊張の糸が切れたりするので、ちゃんと聞けないときあるんですよね。
他の参加者さんとかはどうなんだろう。
もっとスピーカー経験積んで、なんともないぐらいになるしか無いのか。
YAPC::Fukuoka 前夜祭で「夏の夜を涼しくするPerlの話」というタイトルでLTしてきた
言いたいこと。
1. YAPC::Fukuoka 前夜祭でLTしてきた
2. Acme::Undead について
3. 場が温まってたのもあってそれなりに笑ってもらえた
4. 参加できなかった人にも伝えたいこと
5. トーク内容の感想とか全体の感想は別途書くよ
以下詳細という名のｇｄｇｄな何か
YAPC::Fukuoka お疲れ様でした。ブログに書くまでが YAPC::Fukuoka だそうです。
前述の通り、前夜祭で「夏の夜を涼しくするPerlの話」というタイトルでLTしてきました。
aizen.likk.jp
もともとは、某slack のチャンネルでゾンビとアンデッドの違いは何かという話をしていたときに、なんとなく思いついて、Acme::Undead を書いた感じです。
github.com
git log の initial commit を見るとわかりますが、今年始めのころ大体の挙動はできてました。このタイミングで微調整したり、LTのネタとして発表したりしたのは、どうせなら夏に話したいと思って放置していたせいです。そのままお蔵入りになりそうだったのは秘密です。
実装につきましては、use すると use したパッケージに Acme::Undead の _die() _bless() (と _sleep()) をそれぞれ die(), bless() (sleep()) という名前で export している形です
。例えば main パッケージで use して die を呼ぶと core の die を呼ぶのではなく Acme::Undead::_die() を export した main::die() を呼ぶ形になっております。
あまりないと思いますが、別の目的で元から main パッケージに sub die {} や sub bless {} があるとそれも上書きしてしまいます。(別の目的で書いてある実装があったら目的知りたいのでご連絡いただけると幸いです。)
実にしょうもないAcmeモジュールで、しょうもないネタLT だったので、ウケがとれなかったら、スライドのタイトルの涼しいを通り越して寒い感じになって耐えられそうにないなと思いましたが、場が温まってたこともあり、大ウケまでは行かなくてもそれなりにウケてもらえたようで何よりでした。結局暖かいのか涼しいのかよくわかんない。
スライドの中で、今回、前夜祭に来れなかった人にもどうしても伝えたいページがあります。
http://aizen.likk.jp/slide/acme_undead/#/step-6
JRPG的アンデッド
死者(アンデッド)
L 肉体がないよ派(ホーント)
L 幽霊・ゴースト
L レイス(生前は高位の者/死神)
L ポルターガイスト // 現象の方を指すケースが多い
L 肉体はあるよ派
L あるけど腐ってるよ派
L ゾンビ(操られた死体) // 本来はゴーレムに近い
L グール(死喰鬼)
L レベナント(死に戻り) // 我々のイメージするゾンビはこっちに近い
L あるけど本体は肉体じゃないよ派
L ワイト(肉体を覆う光が本体)
L あるけど骨だけだよ派
L スケルトン
L 実は死んでないよ派
L 元は妖精だよ派(でもアンデッドのような特性があるよ)
L デュラハン
L バンシー
L 最初から生きて無いよ(アンデッドじゃないよ)派
L 材料が肉や骨なだけだよ派
L ボーンゴーレム
L フレッシュゴーレム
じゃなくて、こっち。
http://aizen.likk.jp/slide/acme_undead/#/step-20
last/next/redo は無名ブロックも対象になる
どうしてそういう実装になっているのかは分からないですが、以下のようなコードを書くと意図と違う挙動・あるいは実装者の意図と違う理解をメンテナがする可能性があるのでお気をつけください。（そもそもループの中で無名ブロックが必要なケースが出てきたらメソッド分けましょう）
for (1..10){ say $_; { last; #ここでループから抜けたい(実際は無名ブロックから抜けるだけ) } }
逆にそれを意図してハックっぽい感じのコードを書くとに書くといい感じに混乱を誘えそう
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 書いた
以下経緯と言う名のｇｄｇｄな何か
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さんをフォローして、
何気なーく
Slack::RTM::Bot コケる原因 Protocol::WebSocket::Message の max_message_size かー。これを外からどう手を入れようかなー。
— likk (@likk) 2017年3月23日
って呟いたら、音速でレスポンスがきて超速でパッチの用意までしてくれました。有難うございます。
正確には完全移行しておらず、ちょっとした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(ドメイン駆動設計) を取り入れる
ドメイン駆動設計自体まだ余りなれていないので、導入事例とDDDの解釈とどの分を選択的に取り入れるかが参考になった。文字コード周りやガラケー対応で仕事を思い出して頭ｇ
Perl ウェブ開発の中世 〜CGI と Plack の間〜
客観的にPerl の歴史が語られていて、懐かしくもあったど、fastcgi など自分が触れてない分野も聞けてよかった。SpeedyCGI はまだ個人的には使ってる部分があります、すいません。
最後に
YAPC::Kansai 開催してくれて有難うございます。北海道から引き続き参加できて良かったし、次回の福岡も参加する予定です。
また幾つか不満を漏らしたり件について、会場、ならびにスタッフへの配慮が足りず非常に申し訳ございませんでした。
