JUST FOR FUN

Twitter:@okwra Facebook:ayato.ookawara GitHub:@tearon4 other:@taiga006

perlでHashの一部分をテストで確認したいときにsuperhashof便利やん。

f:id:taiga006:20180509225412p:plain:w500
use Test::More;
use Test::Deep;

my $user = {
        name => '齋藤飛鳥',
        age => 19,
        height => 158,
        blood_type => 'O',
        center => '裸足でSummer',
    };

is $user->{age}, 19;
cmp_deeply $user, superhashof { name => '齋藤飛鳥', blood_type => 'O' };

done_testing;

[output]

₍ ᕕ( ‘ω’)ᕗ⁾ $ prove -lvf superhashof.pl
superhashof.pl ..
ok 1
ok 2
1..2
ok
All tests successful.
Files=1, Tests=2,  0 wallclock secs ( 0.03 usr  0.01 sys +  0.07 cusr  0.01 csys =  0.1
2 CPU)
Result: PASS

こける場合はこんな感じ。

use Test::More;
use Test::Deep;

my $user_2 = {
        name => '斉藤優里',
        age => 24,
        height => 157,
        blood_type => 'O',
        center => '13日の金曜日',
    };

cmp_deeply $user_2, superhashof { name => '齋藤優里', height => 157 };

done_testing;

[output]

₍ ᕕ( ‘ω’)ᕗ⁾ $ prove -lvf superhashof.pl
superhashof.pl ..
not ok 1
#   Failed test at superhashof.pl line 12.
# Compared $data->{"name"}
#    got : '斉藤優里'
# expect : '齋藤優里'
1..1
# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests

Test Summary Report
-------------------
superhashof.pl (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=1, Tests=1,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.05 cusr  0.01 csys =  0.08 CPU)
Result: FAIL

[参考]

Test::Deep - search.cpan.org

gitのfor-each-refで各ブランチで最後にcommitした人とその更新時刻を一覧表示させる。

普段はあまりそんな状況ないんですがふと今の作業ブランチだけでなくて、すべてのブランチを対象に最新のcommit情報をその更新時刻付きで表示したくなり「うーん、うまいやり方ないかなー」と思ってググったらgit for-each-refが使えるとのこと。知らなかった。

公式ドキュメント

Git - git-for-each-ref Documentation

【例】

git for-each-ref \
--sort=-committerdate \
--count=10 \
--format="
Date: %(color:red)%(authordate:iso)%(color:reset)
%(color:green)[%(authorname)]%(color:reset)
Ref: %(color:yellow)%(refname:short)%(color:reset)
Subject: %(subject)" \
refs/heads refs/remotes

上の例だと

  • 最新のコミット順
  • 10件
  • 日付とブランチ名とユーザ名とcommitメッセージ含め

て表示してくれる。 (色とかつけてるからごちゃごちゃしてるけど、整理すればシンプル。)

for-each-refは単体で使うよりこれを使ってブランチ一覧を取得してその上で何かする、みたいな状況で利用されることが多いらしい。

とはいえ、上の例を参考に上手く使えば
「さっき作業してたブランチなんだっけ?」
とか
「あのブランチって誰がいつ切ったの?」
みたいな調査が楽にできそう。

長いので.gitconfigにaliasを追加しておけば良さそう。

[alias]
    history = for-each-ref --sort=-committerdate --count=10 --format='Date: %(color:red)%(authordate:iso)%(color:reset)\t%(color:green)[%(authorname)]%(color:reset)\nRef: %(color:yellow)%(refname:short)%(color:reset)\nSubject: %(subject)\n' refs/heads refs/remotes

f:id:taiga006:20180504172346p:plain

RedashのRepo.で試しにやってみた図)


...と思ったらすでにこういうのがあるらしい。 まあ、誰かしら作ってるとは思ったけど。

github.com


参考

shuzo-kino.hateblo.jp

kakakakakku.hatenablog.com

「DNSをはじめよう」を読んだ。(技術書典4読書)

先日、秋葉原であった技術書典4で購入した本をこのGWに消化しようとしている。

最初に読んだのが@mochikoAsTech著「DNSをはじめよう」。

f:id:taiga006:20180429162526p:plain:w300

初参加の技術書典で750冊も売れたらしい。すごい。

表紙にもあるように「試しながら学べる」、いわゆるハンズオン形式の200ページもない本である。

具体的に本書で何を試すのかといえば

①お名前.comで好きなドメインを購入

②作ったドメインのネームサーバをAWSのRoute53に変更

whoisやdigを駆使してDNSを詳しく学習

と行った具合である。

スクショ画像が多く、この辺素人の人でもスムーズに手順を終えると思う。

また、本書はハンズオンの合間合間に具体的なシチュエーションが設定されたクイズが差し込まれており「なるほどそういうケースのときのためにこうしておくのか」みたいな学びが多い。

個人的には「ネームサーバ=電話帳」、「フルリゾルバ=秘書」の例えがわかりやすかった。

このおかげでいわゆる名前解決のトラブルってのがどの辺で起きるのか理解できた。

付録のAWSアイドルソング「愛はわがままサンシャイン」は専門用語の多いAWSから初心者には難しいワードをふんだんに盛り込んだ迷曲?そろそろ誰かがボカロに歌わせそう。

ふたりの思い出Redshihftって節が好き。


さて、以下は本書を読んでまだわかってないこと

  • 基本オープンリゾルバをフル活用でよくない?

  • /etc/resolv.cnfはどういうタイミングで書き換わっている?

  • nslookupdigの使い分け(今後はdigだけ使えれば特に困らない?)

  • TTLってどうやって更新するの?

この辺は追って自分で勉強しよう。


参考

mochikoastech.hatenablog.com

mochikoastech.hatenablog.com

技術書典4に行き当たりばったりで参加してきた

技術書典4に参加してきました。

戦利品は以下の通りです。

f:id:taiga006:20180422212822p:plain

  1. DNSをはじめよう ~基礎からトラブルシューティングまで~

  2. WordPressで始めるGoogle Cloud Platform本格入門

  3. radiberry pi! 構築手順書(ver 2.00)

  4. ZIP、完全に理解した

f:id:taiga006:20180422212927p:plain

  1. KbD C93 DECEMBER 2017

  2. もっとわかるVue (Better understanding of Vue in Vuetify)

  3. Firebase + React.js リアルタイムアプリケーション入門

  4. イヌでもわかるhyperapp

  5. たのしいGitオブジェクトの歩き方


(一部、友人のために買った本が含まれています。)

もともと技術書典というイベントについては「名前は聞いたことあるけど…」レベルで、興味はあるものの足を運ぶつもりはありませんでした。ただ今回前日になって「行かない?」と先輩に声をかけてもらったので「おぉ…まじか」となりつつほとんど前情報なく参加することになりました。

 

以下一般参加者として気がついた点をまとめておきます。(後学のため)


1.大きめのトートバックなどを持って参加すべきだった

こういうイベント自体に慣れていないため普段使いのバッグで参加したんですが購入した本の出し入れなどで周りの人に まじで迷惑 だったと思います。ごめんなさい。イベント内で販売していた公式の手提げ袋みたいなのは入口一箇所で販売しており気がついたときには遅かったです。

 

2.後払いシステムが超便利

いやこれ自体は当たり前のことなんですが、思っていた以上に多くのサークルが後払い決済を導入していて朝の東横線並みに混んでてもスムーズに冊子の購入やりとりが可能でした。

 

3. 見えないスタンプがよくわからなかった

お昼頃に行ったんですが想像以上に混んでおり「うげえまじかよ」と一瞬戦意喪失しかけたんですが、運営スタッフの方々の的確な指示のおかげで思っていたより早く整理券GET&会場入りができました。ただ、整理券と一緒に手の甲に押された透明のスタンプは結局なんだったのかが疑問。ああいうイベントではデフォなのかな?

 

4. 次回はもっと大きな会場がいいな(小声)

まだ公式のトータル参加者人数は出ていないようですが一部Twitter情報によると5000人はゆうに超えたとのことで、そうなると次回はもう少しスペースに余裕のある会場が…いいな...なんて思ったり思わなかったり。


それから、これは後学のためでもなんでもないですが、「わざわざ暑い中、秋葉原まで足を運んで技術者が本買うの?笑」みたいなツイートを見て思ったのは(まあ真剣に言ってる人はいないと思いますが)わざわざ足を運んだんだから自分の趣味じゃない本にも手を出してみようかな?みたいな偶然の出会いチックなものが、やはりこういうイベントの醍醐味なんじゃないかな、ということです。

今回で言えばHyperappの本なんて普段サーバーやインフラ周りのことしか見ていない自分が一人で勉強してたら絶対買わなかっただろうと思います。それを、たまたま立ち読みして「ほーん面白そう」ってだけで買えてしまうのがリアルイベントの良さなのかぁ、と改めて思いました。


以下、買いたかったけど買えなかった(買い忘れた)書籍。

『Swiftで書いておぼえるTDD』

『流体計算で覚えるPython3』

『公務員の文書改竄防止システムをブロックチェーンで作ってみた』

『Effective 量子コンピュータ

『趣味のFPGA入門』

電子書籍版とかそのうち出るかな(もしくはもう出てるのかな)


買った本はGWにゆっくり読もう。

表紙ははずいが役に立つ ~良書紹介「雅なPerl」~

「初めてのPerl」の第7版が今年の1月に出ていたらしい。

初めてのPerl 第7版

初めてのPerl 第7版


これこそまさしく「ザ・Perl入門書」ではあるとは思うけど、今日は「雅なPerl」という一風変わった本を紹介したい。

全体で200ページ程度の量で、難しい背景や言語の仕組みに関わる話はすっ飛ばしてPerlを使って如何に書きたいことを書くか、その方法が章立ててまとまっている。 (しかもラノベ調で)

初学者(あるいは基礎がガバガバな半端者=僕)みたいな人が分厚い参考書を手に取る前にサクッと読みながら時々写経してみるのにぴったりな本だと思う。

表紙から溢れ出る同人誌感はさておいて、この本はPerl入学式なんかでも立派な一参考資料として紹介されるくらい、その道の人も認めている本なのだ。

(本当に?)

github.com

ラクダ本やリャマ本と並べて紹介されてるぞ..!?

良い点

  • 雅が初学者目線で常に語ってくれるのでどこまでを一読で理解する必要があってどこからが応用(今後勉強していきましょうねー)な内容なのかがわかりやすい。

  • Perlが得意とする文字列操作、特に正規表現に関する解説が特に充実している。 今でもリファレンスとして時たまペラペラとめくる。

  • 200ページくらいでサイズもコンパクトで持ち運びしやすい。 まあ電子書籍が主流の現代において「重さ」「デカさ」はあまり重要視されないパラメータではありますが...。

悪い点

  • オブジェクト指向の説明に関しては12章まるまる使ってるとはいえPerlで、この短さで、なんとかしようとなるとやっぱり厳しい印象。

  • この表紙だと外出先で開きにくい。うぅ...試されている…。

  • 非売品

近くのPerl Mongerおじさんに持っていないか聞くのが吉。

ちなみに僕が持ってるのは第1版だけど第3版(Perl6の話とか追加)まであるらしい。
第2版の表紙が一番好き。

それから、この本に限ったことではないけどPerl後方互換性が強いので古い参考書でも全然現役で勉強になることがたくさん書いてある。

これが他の言語ではそうはいかない。
先週見たQiitaの記事がすでに過去の遺産だったりする。 きゃー大変。

まあPerlでもあんまり古い本とかサイトをみるよりは公式ドキュメント見ろよ、ってのはもちろん正論なんだけど。

kazhiramatsu.hatenablog.com

書評のようなもの ++ 雅なPerl入門 | koji_magi::*

チームの朝会運営の仕事が怠いのでSlackのBotにしたよ

...まあ1年前の話なんですけど。

github.com

朝会のスピーチ管理がこれまで手動管理だったのをGASで自動化したぞい、というものです。

Google Spreadsheetで発表者のスケジュールとテーマを管理しています。(こんな感じ)

f:id:taiga006:20180415153327j:plain:w600

トリガーをセットして定時にSlackの特定のチャンネルに投稿されるようになってます。

f:id:taiga006:20180415153229j:plain:w500

朝会の運営を新卒の子に引き継ぐに当たって「これ、便利ですね!」って言われて嬉しかったので共有です。

(スピーチスキップとかのときの機能追加する、追加するって言っておいてやってないな...)

日付・時間の文字列操作にはDATE_FORMATよりEXTRACTのほうが便利そう。

チームメンバーの書いたクエリで見覚えのない関数が使われいたので調査。

MySQL :: MySQL 5.6 リファレンスマニュアル :: 12.7 日付および時間関数

EXTRACT関数を使うとDATE値の結果から一部を抽出できる。
よく見るDATE_FORMAT関数を使うより文字列を解釈せずに必要な部分を抽出できるため早いらしい。

mysql> SELECT EXTRACT(HOUR_MINUTE FROM now());
+---------------------------------+
| EXTRACT(HOUR_MINUTE FROM now()) |
+---------------------------------+
|                            2353 |
+---------------------------------+
1 row in set (0.00 sec)

mysql> SELECT EXTRACT(DAY_MINUTE FROM '2012-04-13 21:10:41');
+------------------------------------------------+
| EXTRACT(DAY_MINUTE FROM '2012-04-13 21:10:41') |
+------------------------------------------------+
|                                         132110 |
+------------------------------------------------+
1 row in set (0.00 sec)

グループ化する際に特に便利。

qiita.com

qiita.com

以下、適当なテーブルを作って検証。

mysql> SELECT * FROM user LIMIT 1;
+----+-------+------+------+------------+---------------------+
| id | name  | age  | sex  | city       | created_at          |
+----+-------+------+------+------------+---------------------+
|  1 | illum |   43 | male | Wolffmouth | 2007-12-30 07:13:59 |
+----+-------+------+------+------------+---------------------+
1 row in set (0.00 sec)

mysql> SELECT sex,
       EXTRACT(YEAR
               FROM created_at) AS YEAR,
       COUNT(*) AS COUNT
       FROM USER
       GROUP BY sex,
         EXTRACT(YEAR
                 FROM created_at) HAVING COUNT(*) > 10
       ORDER BY extract(YEAR
                 FROM created_at);
+--------+------+-------+
| sex    | YEAR | COUNT |
+--------+------+-------+
| female | 1977 |    14 |
| male   | 1984 |    14 |
| female | 1984 |    13 |
| male   | 1990 |    11 |
| female | 1991 |    11 |
| female | 1998 |    11 |
| female | 2006 |    13 |
| male   | 2006 |    11 |
| male   | 2011 |    16 |
+--------+------+-------+
9 rows in set (0.00 sec)

最後にEXTRACTで使えるunit値を載せておく。

unit 要求される expr 書式
MICROSECOND MICROSECONDS
SECOND SECONDS
MINUTE MINUTES
HOUR HOURS
DAY DAYS
WEEK WEEKS
MONTH MONTHS
QUARTER QUARTERS
YEAR YEARS
SECOND_MICROSECOND 'SECONDS.MICROSECONDS'
MINUTE_MICROSECOND 'MINUTES:SECONDS.MICROSECONDS'
MINUTE_SECOND 'MINUTES:SECONDS'
HOUR_MICROSECOND 'HOURS:MINUTES:SECONDS.MICROSECONDS'
HOUR_SECOND 'HOURS:MINUTES:SECONDS'
HOUR_MINUTE 'HOURS:MINUTES'
DAY_MICROSECOND 'DAYS HOURS:MINUTES:SECONDS.MICROSECONDS'
DAY_SECOND 'DAYS HOURS:MINUTES:SECONDS'
DAY_MINUTE 'DAYS HOURS:MINUTES'
DAY_HOUR 'DAYS HOURS'
YEAR_MONTH 'YEARS-MONTHS'

Test::Mock::Guard ~テスト用にお手軽にstub化~

今日も今日とて、これまでなんとなくで使ってたモジュールを再度見つめ直す回です。

github.com

Test::Mock::Guardはテストで使えるモジュールとしてメジャーな模様。既存のクラス挙動を簡単にオーバーライドできる。

use strict;
use warnings;
use Test::More;
use Test::Mock::Guard qw/ mock_guard /;

package Discord;

sub new { bless {} => shift; }
sub solo { "長濱ねる"; }

package main;

{
    my $guard = mock_guard "Discord", +{
            solo    => sub { "平手友梨奈"; },
        };

    my $song0 = Discord->new;
    is $song0->solo, "平手友梨奈", "mock化されてる";
}

print "------(OUT OF SCOPE)--------\n";
my $song = Discord->new;
is $song->solo, "長濱ねる", "mock化されない";

done_testing;
〓 ~/perl_study
₍ ᕕ( ‘ω’)ᕗ⁾ $ prove -lvf discord.t
discord.t ..
ok 1 - mock化されてる
------(OUT OF SCOPE)--------
ok 2 - mock化されない

1..2
ok
All tests successful.
Files=1, Tests=2,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.06 cusr  0.01 csys =  0.09 CPU)
Result: PASS

無駄にネストが深くならずに済む。

よく聞くスタブとモックの違いについて。

厳密に正しいかはあれですが、この記事が参考になりました。

perl-users.jp

スタブの場合は、それを利用する部分がテスト対象になります。

( 中略)

一方、モックの場合は、適用する部分そのものがテスト対象です。

( 中略)

ですので、今テストしたい部分がどこかを的確に認識できれば、 モックとスタブのどちらを使うのがよい状況なのかを判断できるようになります。

ちなみに最近よく聞く?Test2にもメソッドをモックしてくれる君としてTest2::Mockというのがあるみたいなんですがこいつだとモックしたメソッドを何回呼ばれたかを知るcall_count同等の機能がない様子。

techblog.kayac.com

Test2についてはまた記事を書きたいと思います。

参考記事

mihyaeru21.hatenablog.com

blog.yuuk.io

d.hatena.ne.jp

Acme::Keyakizaka46をリリースした。

TL;DR

  • Acmeモジュール群の存在を知って、Acme::Keyakizaka46を作った。

  • 公式サイトからメンバーの情報を引っ張ってくる適当なスクリプト(Python)を書いた。

  • Minilaを使ってCPANAcmeモジュールを公開したら簡単すぎて肩透かしを食らった。

github.com

経緯

普段から仕事でPerlを書いている僕がAcmeの存在を知ったきっかけはつい最近で隣の席のエンジニアリーダー氏の机にあったAcme大全2015を見たことだった。

donzoko.booth.pm

知らない人のためにざっくりと紹介するとこのAcmeモジュールとはPerlの世界におけるジョークモジュールの名前空間でまさに「技術の無駄遣い」そのもの。詳しくは、

qiita.com

あたりを見て欲しい。

Acmeモジュールのくだらなさにはまった僕は、色々と調べているうちに面白いモジュールたちに出会った。それが

blog.kentarok.org

perl-users.jp

secondlife.hatenablog.jp

syohex.hatenablog.com

といったキャラクターや実在のアイドルのデーターベースの役割をなすモジュールたちだ。なるほど、こんなに 実用性のない 単純で面白いモジュールが出ているなら僕でも作れるなーと思い、

「よしAcme::Nogizaka46作るかー!」

となったのが今から1週間ほど前。

..........

しかし、すでにAcme::Nogizaka46は存在していることがわかった。

d.hatena.ne.jp

なるほどー、アイドルネタは諦めて某クソマンガAcmeモジュールでも作るかーと思った矢先、上のブログで引用されているこの文章が目に止まった。

Acmeシリーズは二つ、Acme::MorningMusume と Acme::AKB48 があります。その Acmeが存在するアイドル2ユニットに共通していえることの一つに、どちらも紅白歌合戦に参加したことがあることが言えます。つまるところ、日本のAcme::アイドルが作られたのユニットは100%紅白出場している

なるほど、そう言う経緯でAcme::MomoiroCloverやAcme::Nogizaka46が作られているのであれば彼女たちのがあっても良いな、と思い作ろうと思ったのがAcme::Keyakizaka46というわけだ。

(彼女たちの場合は出場願掛けではなく、すでに出場しているが…。)

準備

ベースとなるメソッドはAcme::MorningMusumeやAcme::Nogizaka46を再利用させていただくことにするとは言え、メンバー一人一人の情報はこちらで集計しなければいけない。

ということで、公式サイトから情報を引っ張ってくる簡単なスクレイピングスクリプトを書いた。

Pythonで書いたのはBeautiful Soupというライブラリが使い慣れていたから。

(コードは本当に書き捨てなので汚さとかは勘弁してほしい。)

という事でこれにて欅坂とけやき坂のメンバー情報はすぐに集められた。

実装?

特に新しいことはしていない。欅坂はまだ卒業メンバーも出ていない(要出典)ので、その辺のロジックを抜いたのとあとは誕生日から年齢の計算をするロジックをもっと単純にしたくらいである。あとselectメソッドでcenterを指定すると強制的に平手友梨奈の情報が返ってくる。

テストもいくつか追加した。欅坂で一番身長が高いのは羽生ちゃんで、これはしばらく更新されないだろうからベタ打ちで書いている。(笑)

[参考]

tech.nikkeibp.co.jp

Minilaでリリース

自分で書いたテストが無事通ればあとはCPANに上げるだけ。でも待ってくれ??ここからの知識がこの時点で皆無だった僕は一瞬途方にくれることになった。

が、さすがPerl、枯れ切った言語と揶揄されるだけあって少しググれば湯水のごとく情報が出てくる。

どうやらMinilaというモジュールオーサリングツールを使えば初心者でも簡単にCPANに自作モジュールをあげられることがわかった。

手順は以下の記事が参考になった。

keyamb.hatenablog.com

www.swipe.to

nukosuke.hatenablog.jp

要は完成したら minil testしてminil distして minil releaseすればよい。 エラーが出てもメッセージが親切なのでつまづくことは少ないはずだ。

一点。上の記事にもあるが ~/.pauseにPAUSSEアカウントのユーザ情報を載せておかないと上手くいかないことに注意。

Missing ~/.pause file or your ~/.pause file is wrong.
You should put ~/.pause file in following format.

    user {{YOUR_PAUSE_ID}}
    password {{YOUR_PAUSE_PASSWORD}}

(用意しておかないとこんなエラーが出る。親切。)

それから今回はPODの書き方が一番戸惑ったのだがMinilaを使うとtestの時点で文法チェックしてくれるのでありがたい。

あとはPAUSEからメールが来たりなんなりするけど特につまづくことはないはず。

寝てCPANに出てくるのを待つだけ。

metacpan.org

どーんっ!完成。

これから

制作期間5時間程度で作ったモジュールではあるが、欅坂というか坂道グループ全体で今年?来年?合同オーディションがあることが発表されたばっかりなのですぐに修正を入れる必要が出て来そう。

欅坂はもう良くないですか...

また、当初やろうと思っていたグループ内ユニットの情報をまだ入れていないのでこれもやりたいと思っている。

ゆいちゃんずとかゆいちゃんずとか。

www.youtube.com

さて、要領は掴んだので今度はクソマンガのクソAcmeモジュールでも作るかー。

最近聞いているおんがく①「brinq」

 

少し前にこんな記事が話題になった。

daily.bandcamp.com

 

いま日本には色んなジャンルの音楽があるけれど、EDM疲れしてしまった僕には日本の「Kawaii」と世界の「POP」が融合したような、そんな攻めすぎず守りすぎていない、ちょうどいい感じの音楽がすごくピンとくる。

 

ちょっと前まで本当に音楽を、知るのにも、作るのにも、聴くのにも疲れてしまった時期があったけどそれも嘘だったみたいに、元通り音楽の虜になれた。

 

そんなマイ「Kawaii」ブームの火付け役になってくれたのがユウ フジヤマを中心としたプロジェクトbrinq(ブリンク)

 

www.youtube.com

音圧低め・ミドルテンポ・クセのないKawaiiボーカルの三拍子

 

まだアルバムはMAGICAL BRINQ TOURの1枚しか出していないけどApple Musicでも聞けるらしいのでまだ聴いたことない人は是非。

 

いや、brinqとかその周辺の音楽は特に何か技術やジャンルが新しいってわけではないんだけど、もうとっくに新しいなんて求めていないわけで…

 

ただいい音楽であればよいんですよ。

 

soundcloud.com

 

サンクラにあった星野源の「恋」のカバー。

いや、サムネイルが…でかい!