トミールの技術系日記

忍たまはじめました

metacpanに++しよう

https://www.facebook.com/n.tomita/posts/10151588193792010

めんどくさいことはいつまでたっても面倒なので、簡単なところからまず

perlのエコシステムであるcpanについては、ひごろ search.cpan.org ではなく https://metacpan.org/ を使うようにし、一案件終わったら(もしくはなんとなくイイネと思ったらすぐ) 該当モジュールを ++ すると良いんじゃないか。

Makefile.PLとかcpanfileからモジュール抜いてまとめて++する君があってもいいかもね

gemなどにもいえることだけど、モジュール検索エンジンは一番いいのを出すというところまで進化するのむずかしい。モジュールの更新量はなんだかんだでハンパないし、世の中的にどんどんキラキラネームが増え名前だけじゃ何をしたいものなのかわからないことが増えつつあり、ふつうにgoogleすると古い情報がおおい。

前に本を書いた時にきにしていたことはこのへんに書いたけど いまだと metacpan.org の ++ がそんだけでだいぶ良いんじゃないか。(search.cpan.orgにも★5方式のratingがあるのだがamazonとかitunes storeみたいにその方式だとありがちな★1つけて文句を言う場を兼ねているのであてにならない)

ログインして++すると公開情報となるので、++が増えたあとも++主によるスコアリングとかやりようがある。

https://metacpan.org/favorite/recent

※watcherに、あの会社あらたにあのジャンルを取り組み始めたーなどがわかる場合もあり、そういうのがセンシティブな職場の人はまとめてやるとかそういう方が良いかも知んない。これはbookmarkにもいえる

ここまで書いておきながら、ぼくがけっきょく(まだ誰も++していなかった!)サイクロンさんのGCMのやつにしか++していないことがわかっちゃいます。てへ

エクセルと私 2013 春

DBにつっこむ元データ、「1行1レコードの感じで作ってくれればいい感じにとりこみます〜」、とだけ言っておいたもののうっかり放置していたら驚きの、大量複数シート、セルの結合などを駆使したリッパなエクセル出来上がってしまっていてOMG

xlsのパースを・・・ 2013年にやることになるとは。 何が良いのだろう・・・ (google docsに上げてそっちのAPIを使う手もあるがね。)

IRCで聞いたら他部署で PHPExcel とやらを使った事例があったとか。
見てみたらなんと! ドキュメントがわざわざword形式でできているww
なかなかのこだわりですねww ウケた

pypiみてたら、超かっこいいキラキラネームがあった
https://pypi.python.org/pypi/excellent/0.0.2

エックセレントゥゥ!

ステキ (・◡・ 人)
ただしこいつwrite用だけだ。そんなにエクセレントじゃない

けっきょくcpanみてたらExcel::Tableというのがある。こいつはラッパーモジュールで、どうやらxlsについては今でもなつかしのSpreadsheet::ParseExcelが、そしてxlsxについてはSpreadsheet::XLSXというのを使っている。

use strict;
use warnings;
use utf8;
use lib "extlib/lib/perl5";
use Data::Dump qw/dump/;

use Excel::Table;

my $excel = Excel::Table->new;
my $book  = $excel->open('DB/おさっしください.xls');

for my $sheet ($book->worksheets) {
    warn $sheet->get_name;
    dump $excel->extract($sheet->get_name, 0); // disable title_row
}

フツーにうごく。よかった。

ただし

_人人人人人人人人人人_
> 突然のLog4perl! <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y ̄

まあいいけどね。

あと https://metacpan.org/author/JMCNAMARA Spreadsheet::ParseExcel の作者のアイコンが怖い ( ;д;)

f:id:tomi-ru:20130409184450p:plain

こっちを何かが見ている!

これからブログやるなら

Tumblrが一番いいと思う

  • 独自ドメインが使える
  • もともといいデザインがそろってる(比べてみるといい)
  • HTML/CSS/Javascriptを編集できる
  • 自由に「ページ」を追加できる
  • Markdownが使える
  • 複数ブログを使う前提でつくられている
  • とはいえパッと見はたくさん書けるtwitter的になっている

あたらしくブログ系サービスつくるところはちゃんとTumblr研究したらいいとおもう

use feature qw/dot/;

perlが、featureっていうプラグマモジュールをつかって新機能をついかするってのを5.10からできるようになってるのですが、

use feature 'say';

たとえばこうすると組み込みのsay関数が使えるようになる。みたいな。これなら普通に use 5.012; とかでまとめてONにする方がよかったのですが、すごい(いい意味で)変態なのが出てきておもしろい(まだbranchesで、どう?って状態

http://www.nntp.perl.org/group/perl.perl5.porters/2011/11/msg178772.html

use feature 'dot';
use HTTP::Tiny;
my $response = HTTP::Tiny.new.request('HEAD', $url);
say "Hello" ~ "world"; # => "Helloworld"

わーい  ->  のかわりに .がつかえるよー(^∀^) (文字連結は~)

でも思ったよりそんなに見やすくないですねwww

昔、perl始めたころ、こんなこと妄想したなあとおもって調べたら、ちょっとだけ残ってた。

http://clip.livedoor.com/page/547685/Elementary,%20...%20LLDN%E3%81%AE%E6%84%9F%E6%83%B3%20-%20use%20dot;%20%E3%81%A8%E3%81%8B%E3%81%A9%E3%81%86%E3%81%8B%E3%81%AA

2005年かあ。記事のブログの拡張子がphpであるところを見るとwordpressからの引っ越し時に消したみたいです。そのときは、たしかドットじゃないけど autoboxっていう近いのがあるよって誰かがおしえてくれたはず。6年のときをへてまさか現実的なものになろうとしてるとは。

Tumblrべんり

http://e8y.net/blog/Movabletypeなのだけど、次なんかブログやるときはホスティング形をつかおうと思ってました。今回、http://cpanbook.koneta.org/ つくるにあたり、比較したのはこのへん。

比較ポイントは、

  • そんなに重くない
  • 独自ドメインが使える(念のため引越しの可能性を残しておくため)
  • カスタマイズ性(HTMLやCSSレベルでいじれる)
  • 有料無料問わず

やー、Tumblrべんりっすね。なんか面白画像の投稿用にしか使われてないのだが、これは究極のホスティング型ブログサービスである。ごちゃごちゃしていないのに、すごいカスタマイズ性が高い。

独自ドメインまで無料で使える。テンプレートはイカすのがいろいろそろっているのにくわえ、HTMLレベルでもいじれる(独自の広告も貼れる)。テンプレートの管理はMTやWPに比べると格段にわかりやすい。つまり1ファイルによる管理だし、タグの情報もひとつのページにまとまっている。

あとPagesという機能がやばい

これは任意のドメイン以下のパスに以下のようなものを置ける。

  • エントリを作成する(通常のテンプレートを使う)
  • 完全にHTMLレベルでまったく違うものをおく
  • 外部サイトを含む別のURLへのリダイレクトとする

あと時限投稿や全体にパスワードをかける機能もある。一般ユーザーからの投稿窓口を用意する機能もある。投稿APIもあるし、きわめつけにさいしょからMarkdownがつかえるよ

これだけそろって、奥さま、無料! 無料でございます!

SLA的なものはどこも似たようなものだと思うので、外部ホスティング型が許される案件なら仕事でも使えると思う。

複数のブログを使い分けることもできる。ブックマークレットとかAddonを使ってる場合、設定で切り替えられるか、メインの(最初に作った)やつに投稿されるようなので、エロ画像を投稿している人はまじめはブログに投稿してしまわないように気をつけよう。

Pagesについての制限

リダイレクトの場合は制限はないようなのだが、ページを置く場合、

/foo/bar

までは行けるのだけど、

/foo/bar/baz

とか深くなると(作成はできるのだけど)404となる。これはサポートに問い合わせたら、About Me, Bio, Resume, Contact Info, etc.を使う想定であるため現状そうなってしまっているとのこと。作成できてしまうのはバグでは?と伝えたつもりなんだけど、最終的にありがとう!何かあったら言って!みたいな返事だったのでうまく伝えられたかどうかはわからんな。サポートはやたら反応が速かった。

この機能をむりやりつかって、e8y.net全部tumblrに持っていこうと思ったのだけど、あれすでにあるパーマリンクのパスが /blog/2011/03/18/p301.html とかなのでだめでした。パーマリンク変えていいならリダイレクト機能を使っても良いのだけど。まあいいやMovabletypeのままで。

Encode::Localeの話

http://d.hatena.ne.jp/tomi-ru/20101219/1292733779

Encode::Localeのlocale_fsで対応してくれたら楽になるなあと思ったんだけど、

https://github.com/gisle/encode-locale/pull/2#issuecomment-700995

コードをポータブルにしたいのと、受け取ったunicodeを勝手にNFC()したけりゃすればいいじゃない?ということで、確かにそうだなあと思った。

NFD()なunicodeもたしかにunicodeであることには変わらないのだものな。

Encode::LocaleではドキュメントにEncode::UTF8Macの存在を示唆してもらった。

Encode::UTF8Macは今漢字の例しかSYNOPSISにつけていないので、アドベントカレンダーにのせたみたいなlatin-1の例とかのせてアップデートしたい

http://perl-users.jp/articles/advent-calendar/2010/english/24

FormValidator::Lite 0.22

http://frepan.org/~tokuhirom/FormValidator-Lite-0.22/

いくつか取り込んでもらいました。tokuhirom++

いま某原稿で*1、基本いままでつかったことあるモジュールの説明を書いたりしているのだけど、テストアプリを書きつつ使ってない奴も検証して進めている。

webappのフォームバリデータ

はどうしようか、を考えていて、いくつか案はあったのだけどどれ一つグッと来るものがない。なおこれをやっているときに生牡蠣でノロにあたった。きつかったです。

  • HTML::FormFuタイプではなく、Requestに条件をぶつけるタイプで考える
  • Required、URL、Email、数字が最初から含まれている
  • カタカナ、ひらがなチェックを含んでいること(pluginでもよい)
  • ちょっとしたオリジナル条件をCodeRefで指定できる
  • チェックする前にtrimできる。もしくはその仕組み。
  • エラーテキストのセット
  • かんたんに説明できること(←重要)

検討したのはこんなところ。

これは2011/1月確認した時の話である。

  • FormValidator::Simple: 問題ないのだが、簡単なオリジナル条件を追加するのがめんどい。あとF::S::P::Japaneseが2006年を最後であり、いまだJcodeを使ってるというのがいろいろを語っている。
  • Data::FormValidator: 見た中では一番よい。requiredが他の条件と別なのはわかりやすい。filterがあるのもよい。ただ大量に関数エクスポートしてねという方式のconstraint_methodsより(古いスタイルとされる)constraintの方がぜったいいいだろ。validator_packagesとの組み合わせもいいし。ただ、日本語まわりのD::F::C::Japaneseがありえないほど古いコードである。(驚きのEncode::Detect。bytes/string混乱期のままだ。)あと、標準でURLチェックがない。RE_HTTP_URLを使えというのか。それhttps対応してないし。つうかRegexp::Commonは便利そうな風をしておいて実は使いにくいので嫌いだ
  • Brannigan: なかなかいいねえ。自由度があって。しかしURLとかEmailとか全部自分で書かないといけないのか。。。F::S発のように条件が大文字名ってのは今は小文字の方がかっこいいかも?と思ったのだけど、これのPOD見てフィールド名と明らかに違うとわかりやすいのだなと感じた。
  • FormValidator::Lite(バージョン0.21について): 速度は認めよう。F::Sを改良すればよいのではないかという気もするが、F::Sはたくさんに使われすぎているのでAPIはいじれないだろうし。これは(人のこと言えないが)PODがてきとうである。あとEmailがlooseしかないとか、やっつけ感が残っている気がする。
  • Data::RuledValidator: なんかわが道をいっている。個人的にはきらいじゃないよこのスタイル。ダミアン先生が好きそうだ。
  • Validator::Custom: 上記らと違いがわからない。こういう後発のものは、PODにモチベーションとかRelated Modulesセクションがあると良いとおもう。あと日本語系とかのプラグイン的なのは新たにつくるひつようがある。
  • もはやData::Validateみたいなチェック系をかってにくみあわせる?
  • なんとかX::Validator(MojoX::Validatorとか): 専用のは除外

うーむ、まさに一長一短である

YAMLのように実装が複数あるものもあるが、まったく同じことをしようとしているのにこれだけ実装が分かれているジャンルは1位アクセサ作成モジュール、2位がバリデータではないだろうか。

いずれにしてもどれか使ってみて、気に入らない点はパッチかpluginを書こう。

→ いちばん対応が速そうなFormValidator::Liteにいくつかパッチ、というかforkして改造をしたのを見てもらって今さっき対応してくれたみたいだ。

加えた改造はイカの通り

http://frepan.org/~tokuhirom/FormValidator-Lite-0.22/lib/FormValidator/Lite/Constraint/Default.pm

  • REQUIRED, FILTERの追加: D::Vからの移行が楽そう
  • MATCH: もともと自前チェックを追加しやすいのではあるが、その場でできると他のモジュールの機能を使いやすく良いと思う。
  • EQUAL: REGEXPでも良いのだけど。DUPLICATIONの書き方をよく忘れるので。passwd2 => EQUAL => $req->param('passwd1') と書ける。
  • あと、NOT_BLANKが機能していなかったのを修正

あと手が空けば、PODを丁寧な感じに書き直して、Messages::enちゃんと追加して、USとかで必ず使われるなんか(zipcode?)を追加したりするとよいな。

*1:まだやっている。今正念場です。取り上げる内容にご意見下さった方ありがとうございました。まだもう少し何か意見言いたい、という話は募集中です。メールとかもらえれば現在の目次をお送りします