YAPC::Fukuoka 2017 HAKATAでロリポップのAPIについてトークしてきた

僕にとって、YAPC::Fukuoka 2017 HAKATAは非常にロングランで濃いものだった。まずは前日に自社のオフィスで開催された、全然野菜に始まる。 これは元々同僚である @hsbt さんが社のSlackで下記の投稿をしたことから全てが始まった。 現在ペパボ@福岡はオフィス改装中で、ペパステというステージを設けて、登壇イベントをパッケージングしているのでほとんど準備することなく飲み物の準備をするくらいで、当日 #全然野菜 がバズるくらいには盛り上がって大変良かった。 YAPC::Fukuoka 前々夜祭(非公式) きた、ペパステという空間がおしゃれ #全然野菜 #yapchttps://t.co/lrA4cM89lL pic.twitter.com/vk1nglSPiE — うずら (@uzulla) 2017年6月30日 その後は公式の前夜祭に移動し、 @udzura が酔って変なテンションになりながらも、Perlと称してClangのライブコーディングをやり遂げるさまを眺めたりしていた。 こんにちは〜 pic.twitter.com/zpXDzk926t — SHIBATA Hiroshi (@hsbt) 2017年6月30日 そんなこんなでLTソンも終わり、 @hsbt と談笑していると、後ろから肩を誰かにぐわっと捕まれ、 「魚っ!おすすめ!」のような検索ワードか!!という勢いで @songmuさんに声をかけられたので、前夜祭のあとは次の日のトップバッターが両方存在するというチキンレースのような面子で鯖郎へ。 これが管理職ですよ — songmu (@songmu) 2017年6月30日 今年もとても良い YAPC だった! #yapcjapan pic.twitter.com/Mw27xOHh4s — 大沢和宏

More

Perlでテストを書く

Teams

どうもー。 最近はひたすらRailsの開発ばっかりやってるので、 Perlの書き方を忘れないようにテストコードの書き方でも。。。 ちなみにRailsのアプリは今やっとログイン周りが仕上がった感じ。 本題に戻って、、今回は以前書いた素数を表示するプログラムの テストコードを書きつつ、パッケージ化してみたいと思います。 今まで仕事でシステムのテストを自動化することは多くありました。 しかし、コードそのもののテストを自動化することってなかったんですよね。 背景としてはバッチ系の処理を書くことが多かったので、そんなに更新が入るコードって なかったんです。 次の職場ではフロント系の開発もやることが増えてくると思うので、 この辺のテストコードのお作法は抑えておきたいですね。 ついでになぜテストを書くのかって話を立ち返ると、例えばずっと更新が入るコードが あって、それになんかしらの修正を入れる度に、人が手でテストするのってアホらしい じゃないですか。 なので機能毎に正常系、異常系の試験を書いておいて、 何か改修した時はそのテストコードを実行して、それがクリアできれば その改修はこれまでの機能を有しているといえるわけですね。 #クソみたいなテスト書いてるとそう言えないけども 今回の実装としてはパッケージとしてUseできること、素数の計算ができることを コア機能と捉えてテストコードを書いてみました。 元ネタのsosu.pl [Perl] #! /bin/perl -w use warnings; use strict; use utf8; binmode(STDOUT, “:utf8”); #引数取得 my $hiki=$ARGV[0]; $hiki =~ /[^0-9]+|^$|^0/ and die “input data is please number!\n”; #素数結果配列 my @s=(2,3); #素数処理用一時変数 my $pnum=3; #無限ループさせる ROOT:while(1){ #処理する素数候補 $pnum+=2; #これまでの素数で割り切れたら次のループへ for(@s){ next ROOT if($pnum % $_ == 0); } #割り切れなければ push @s,$pnum; if(defined($s[$hiki-1])){ print $hiki . “個目の素数は” . $s[$hiki-1]

More

追記〜perlで素数を表示する

最近ひたすらperlのOOPを学んでいる今日この頃。 なんか委託先の人とかってやっぱりコードがすごく綺麗で、 「LL結構かけますよー」 なんてさらって言うためにとっかかりに歴史の古いperlを。 ある程度書けるようになったらrubyやらjavascriptやらもうちょっと 掘り下げて勉強していく予定です。 #仮想テナント構築が止まっているのは仕様です。 さてさて、N個目の素数を表示するコードを書く機会があったので書いてみたのです。 素数そのものの記憶がなかなか怪しくてとっかかり苦労しましたが、 なんとか形になった模様です。。 [Perl] #! /bin/perl -w #引数取得 $hiki=$ARGV[0]; $hiki =~ /[^0-9]+|^$|^0/ and die “input data is please number!\n”; #変数定義 $filename=”./sosu_cache.txt”; my $sosu=2; my $flg=0; my $scnt=0; my $fcnt=1; my $h=(); #キャッシュファイルの読み込み if(-f $filename){ open IN,$filename; while(){ chomp; $h->{$fcnt}=$_; $fcnt++; } close IN; }else{ $h->{1}=2; } #キャッシュに存在すれば回答して終了 print “$hiki個目の素数は$h->{$hiki}\n” and exit if($h->{$hiki}); #キャッシュファイルを追記モードでオープン open OUT,”>> $filename” or die “can’t open cache file!”; #キャッシュが存在すれば if($h->{1}){ $knt= keys $h; if($knt==1){ print

More

PerlでFacade

写真 3

昨夜は素敵なBBQでした。 毎年ビール・ワイン・チューハイ・日本酒・シャンパンをチャンポンしてしまうので 二日酔いは必須です。 iPhone 5s (4.12mm, f/2.2, 1/30 sec, ISO40) iPhone 5s (4.12mm, f/2.2, 1/1001 sec, ISO64) 夏休みも終盤にさしかかり、最近はひたすらオライリーを読破してましたが デザインパターン最後のFacadeを書いてみたのです。 Facadeの特徴は複数のクラスを束ねて一つのクラスで制御できるようにするという シンプルなものですが、これってかなり使いますよね。 んー、僕なんかがよくやるのはOracleとかのDBと組み合わせて処理をする必要があるときに いちいちつないで、SELECTして、ファイルに吐き出してとかが面倒なんで、 一つクラス作って、クライアントからは呼び出すだけにするような設計にします。 今回のサンプルコードははSayWowと猛る処理にしてみました。 ファイルは毎度このへんに。 GitHub Facade ファイル構成は・・・ ・Each.pm 個々のクラスを記述しています。 ・Facade.pm Each.pmのクラスを束ねるクラスの記述です。 ・Client.pm ユーザーの処理を記述しています。 では個々のコードを見て行きましょう。 [Perl] use utf8; #———————————- # Name:Each.pm #———————————- use warnings; use strict; package ClassA; sub new{ my $self=shift; bless {},$self; } sub sayWow { print “Everybody\n”; }; package ClassB; sub

More

PerlでCommandパターン

書いた後 ブログに認め 省みる はろー! 顔だけがとりえの山下です。 そんなわけでコードを書いてはいちいちブログに書いて 自分の中に落としこむ作業が続いています。 でもこれって大事ですよね。 結構書くだけだとその時は炸裂的にわかってるんですけど エンジニアって色々触るから次々に忘れちゃうんですよね。 そんなわけでCommandパターン。 Commandパターンは何らかの操作や要求そのものをオブジェクト化してしまって、 その先で何があるかわからないけども、とにかく操作や要求が出来てしまうという 状況を作れるようなパターンですね。 今回サンプルで書いたのはペーストするコマンド、削除するコマンドなのですが、 その要求をカプセル化してレシーバーとなるファイルやディレクトリに渡して います。 ユーザーはペーストコマンドをファイルやディレクトリに渡すわけですが、 ファイルやディレクトリがどのようにペーストされるかは関知していません。 あとはコマンドそのものをオブジェクト化するのでどういったオペレーションが 行われたかを保存することができるので、Undo(やり直し)を実装できるという 利点があります。 コードはこのへんに GitHub ka-yamashita コード構成 ・Client.pl  ユーザーコード ・Command.pm  コマンドクラス ・Invoker.pm  コマンドを登録して実行するクラス ・Receiver.pm  コマンド内容を実行するオブジェクトのクラス イメージ的にはClientがCommandをInvokerに登録し、Invokerが実行命令すると Receiverがせっせと処理を行う感じです。 この場合、何をやったかはInvokerが管理するのでUndoやRedoをやるのであれば、 Invokerに実行依頼をした処理を管理する仕組みが必要です。 ではCommandクラスから見て行きましょう。 [Perl] use utf8; binmode(STDOUT, “:utf8”); #——————————– # Name:Command.pm #——————————– package Command; use Receiver; use Moose::Role; requires ‘execute’; has ‘receiver’ => ( is => ‘rw’, isa => ‘Receiver’, ); no Moose::Role; sub set_receiver { my ($self,$receiver) = @_; $self->receiver($receiver); } package PasteCommand; use Moose; with ‘Command’; __PACKAGE__->meta->make_immutable(); no Moose; sub execute { my $self=shift; $self->receiver->paste(“をペーストしました”); } package DeleteCommand; use Moose; with ‘Command’; __PACKAGE__->meta->make_immutable(); no Moose; sub execute { my $self=shift; $self->receiver->delete(“をデリートしました”); } 1; [/Perl] コマンドクラスではPaste,Deleteのコマンドクラスが存在し、 各々set_receiverで設定されるレシーバーに対して、ペーストとデリートを要求する という記述になっています。 次にその要求を受けるReceiverクラス [Perl] use utf8; #——————————– # Name:Receiver.pm #——————————– package

More

PerlでMediator

ホークスを 出てから打つのが ペーニャです どーも、みんなのアイドルやまぴもです。 今日はPerlでMediator。 Mediatorの活用としては多くのオブジェクトが相互に作用して動く場合に、 Mediator(ディレクター)クラスを準備して、ユーザーはそのクラスに対して オペレーションをすることでユーザーから複数のオブジェクトの相互作用を 意識させないようなパターンです。 GoF本の例だとダイアログウィンドウの中にチェックボックスやらテキストボックスが あって例えば、チャックボックスにチェックを入れたらテキストボックスがアクティブになる といったような制御をディレクターがよろしくやってくれますよという感じですかね。 この場合の動きとしてはチェックボックスに何らかの変化があった場合に、 チェックボックスが自身の挙動が変わったことをディレクターに通知して、 その通知を元にディレクターがテキストボックスをアクティブにするといった具合です。 ソースはこのへんに GitHub ka-yamashita 今回のコード構成は ・Main.pl ユーザー操作コードです ・Mediator.pm Medietorの記述 ・Parts.pm Mediatorを介して操作したいパーツの記述 と言った感じです。 Partsから見て行きましょう。 [Perl] use utf8; #——————————————- # Name:Parts.pm #——————————————- #パーツの抽象クラス package Parts; use Mediator; use Moose::Role; #ディレクターの参照変数 has ‘director’ => ( is => ‘rw’, isa => ‘Mediator’, required => ‘1’ ); #自身の名前格納変数 has ‘name’ => ( is => ‘rw’, isa => ‘Str’, ); #自身の値格納変数 has ‘value’ => ( is => ‘rw’ ); no Moose::Role; #オブジェクトの値が変わった際にディレクターに通知するメソッド sub change { my $self = shift; $self->director->parts_change($self); }; #値の設定 sub setvalue { my $self = shift; $self->value(shift); $self->change(); } #文字列を扱うクラス package Parts::Parts_String; use Moose; with ‘Parts’; has ‘+value’

More

PerlでCompositeパターン

スタバにて コード書き書き 梅雨の明け どもー。 やましもです。 今日はCompositeパターン。 このパターンはLeafとComposite(Leafの集合)の処理の差異がない場合に 適用可能性があるパターンです。 よく言われるのがファイルとフォルダを上げた具体例ですかね。 ファイルの名前を変えるのとフォルダの名前を変えること、 ファイルの削除とフォルダの削除。 こういった共通のオペレーションをユーザーに枝なのか葉はなのかを 意識させずにコーディングしたい場合に適用出来ます。 今回の実装例としては擬似ファイルを扱うことで実装しました。 #擬似ファイル=実際にファイルやフォルダは作成しないが、オブジェクトとして作成する コードはこの辺。 Github ka-yamashita ファイル構成はディレクトリとファイルをか使うクラス一式がDirectoryFile.pm ユーザーコードがComposite.plです。 早速中身を見て行きましょう。 まずはComposite.plから。 [Perl] use utf8; #——————————————– # Name:DirFile.pm #——————————————– package DirectoryFile; use Moose::Role; requires qw(list remove); has ‘target’ => ( is => ‘rw’, required => 1, ); no Moose::Role; package File; my $self = shift; use Moose; with ‘DirectoryFile’; __PACKAGE__->meta->make_immutable(); no Moose; sub list { my $self = shift; print “/” . $self->target() . “\n”; } sub remove { my $self = shift; print

More

デザインパターン PerlでChain of Responsibility

毎日が夏休み!!! どーも、やましもです。 Chain of Responsibility書いてみました。 恐らくよく使われるのは連鎖的に行う処理がある場合に、 ステータスコードのようなものを持たせて、あるステップが完了していることを 確認しつつ、連鎖的に処理するケースでしょうか。 今回の実装としては具象クラス内で自身が処理するものでなかった場合は 次のクラスへととりあえずメッセージを渡すような実装としています。 ファイルはこのあたりに。 GitHub – Chain of Responsibility ファイル構成 ・LogHandler.pm  ハンドラーの抽象クラスと、具象クラスを記述したコード  (各具象クラスに全く同じsearch_requestが書いてあるのは本来不要なのですが、  まああったほうがイメージ湧きやすいだろうななんてことであえて書いてます) ・CoR.pl  ユーザーの処理を記述したコード。   ポイントとしてはCoR.plの [Perl] my $handlers=SEARCH::LogHandler::Incoming->new( successor => SEARCH::LogHandler::Virus->new(

More

デザインパターン〜PerlでBridge〜

前回と同じくデザインパターンネタ。 今回はBridge。 このパターンの特徴としては実際の操作するオブジェクトと 処理内容を記述するオブジェクトを分離することです。 操作するオブジェクトは処理内容が記述されているオブジェクトに 処理を委譲しますが、ユーザーはその処理内容を意識することはありません。 今回もサンプルはメール受信クラスで書いてみました。 抽象クラス相当も同じくRoleで書いており、共通のパラメーターは Roleに書けることが判明したので書いてみました。 #Thanks > y_morimoto ファイル構成 ・Bridge.pl  −メイン処理を記述 ・Mailler_Receive.pm  −メール受信をする処理の記述 ・Mailler_Object.pm  −メール受信オブジェクトの箱の記述 Mailler_Receive.pmにはPOP接続クラスの具体的な記述、IMAP接続クラスの具体的な記述を おっており、Mailler_Object.pmには先のクラスを格納する変数を定義しています。 実施にはhasの定義にdoesという形で同じロールを持つこと、handlerで 実行可能なメソッドを記述しています。 Bridge.pl [Perl] use utf8; #——————————————— # Name:Bridge.pl #——————————————— use Mailler_Receive; use Mailler_Object; #Mailler_ObjectにPOP接続、IMAP接続を代入する my $pop = Mailler_Object->new( receiver => Receive_Pop->new( server => ‘サーバアドレス’,mailaddress => ‘メールアドレス’, password => ‘パスワード’)); my $imap = Mailler_Object->new( receiver => Receive_Imap->new( server => ‘サーバアドレス’,mailaddress => ‘メールアドレス’, password => ‘パスワード’)); #————————————– #

More

PerlでAbstract Factoryを書く

最近デザインパターンを勉強していることも有り、 perlでMooseを使ってAbstract Factoryを書いてみました。 Abstract Factoryはオブジェクトの生成、実装を使用者側に意識させることなく 使わせることが出来てまたオブジェクトの種類を増やす際も既存のコードに 影響をおよぼすことなく追加する事が可能です。 題材はメールの受信、送信のオブジェクトを生成する部分を 隠匿し、現状はPOP、IMAP、SMTPですが将来的に POPSやIMAPS、SMTPSを実装する際に現状の処理に影響なく 追加出来るようになっています。 #パッケージを一つのファイルで書いている、エラー処理が薄いのは 学習用途としてそっと受け止めて下さい。 実装としては抽象クラス相当は全てMoose::Roleを使っています。 受信オブジェクトの生成 [Perl] use utf8; #************************************** # Name:Mailler_Receive.pm #************************************** #————————————– # 受信の抽象クラス(ロール) #————————————– package Receive_Abstract; use Moose::Role; has ‘server’ => ( is => ‘rw’, isa => ‘Str’, required => 1 ); has ‘mailaddress’ => ( is => ‘rw’, isa => ‘Str’, required => 1 ); has ‘password’ => ( is => ‘rw’, isa => ‘Str’, required => 1 ); has ‘socket’ => ( is => ‘rw’, ); requires qw(connect getuidl getmsg disconnect); no Moose::Role; #————————————— #POPの具象クラス #————————————— package Receive_Concrete_Pop; use Net::POP3; use Moose; #ロールによって実装メソッドの制約 with ‘Receive_Abstract’; has ‘+socket’ => ( isa => ‘Net::POP3’ ); __PACKAGE__->meta->make_immutable; no Moose; sub

More