use 5.019009; use autodie; use feature 'signatures'; no warnings "experimental::signatures"; package Foo { sub new($class, $n) { bless {n=>$n}, $class; } sub bar($class, $a) { $a+3; } sub baz($self, $a) { $self->{n} * $a; } } sub add($left, $right) { return $left + $right; } say add(1,2); say Foo->bar(4); say Foo->new(5)->baz(4); みたいな感じでつかえる。 【追記】 use 5.019009; use feature 'signatures'; no warning
perlに関するmyfinderのブックマーク (242)
-
myfinder 2014/02/24
-
第23回 Perlアプリケーションのテストと高速なCI環境構築術（3） | gihyo.jp
（1）はこちら、（2）はこちらから。 CIを高速に回す手法 今回は、CIをより高速に回す手法をまとめます。 なぜCIに速度が求められるのか 作り始めのプロダクトは小さく、テストはすぐに終わるかもしれませんが、テストコードの量や種類が多くなっていくにつれ、全体の実行時間は延びていきます。また、開発メンバーが増えていくと、さまざまな開発が並行で走ることになり、CIサーバが実行するテスト量が急激に増えます。1回のフルテスト実行が仮に30分かかるとすると、同時に開発しているプロジェクトが3件あると、最長1時間30分ほどCIの実行を待たなければ結果がわからないといったことも起こります。 個別のテストを高速化する手法は先述した『Perl徹底攻略』の記事でも取り上げられています。個別のテスト実行の高速化も重要ですが、それだけでは限界があります。ある程度規模が大きくなる場合には、スケールするしくみを用意
-
第23回 Perlアプリケーションのテストと高速なCI環境構築術（2） | gihyo.jp
前回の（1）はこちらから。 PerlアプリケーションのCI 前回の（1）までで、Perlアプリケーションのテストとその実行に関して基本的な内容を紹介しました。アプリケーション開発にあたっては多くのテストが書かれると思いますが、都度すべてのテストを実行するのは手間がかかりますし忘れてしまうこともあるでしょう。同じことを繰り返すのであればCI環境を作り、テストを自動的／継続的に実行するのが確実です。 Ukigumo::Serverによるテスト実行結果の可視化 Ukigumoはtokuhiromさんが作ったCIを支援するWebアプリケーションです。Ukigumo::Serverはテスト実行結果をPOSTすることで、一覧化してWebブラウザから見ることができるアプリケーションです。 Ukigumo::Serverの導入はcpanmで簡単に行えます。導入と起動は次のように行います。
-
第23回 Perlアプリケーションのテストと高速なCI環境構築術（1） | gihyo.jp
本連載では第一線のPerlハッカーが回替わりで執筆していきます。今回はmyfinderこと久森達郎さんで、テーマは「Perlアプリケーションのテストと高速なCI環境構築術」です。テストに利用するさまざまなモジュールから、CI（Continuous Integration、継続的インテグレーション）環境の構築、そして増えたテストを高速に実行する枠組みの構築までを紹介します。 なお本稿のサンプルコードは、本誌サポートサイトから入手できます。 テストの目的 まずはテストを行う目的を整理します。 コードを壊していないことを確認する 1人で開発するものであれば、どんな状況であれ責任を負うのは自分だけですが、チームや組織が複数にまたがる場合にはテストが重要になります。プロダクトが大きくなるにつれ、自分の開発によって想定外の機能にも影響を与えることが多くなります。逆にほかの開発者が行ったコミットによって
-
Perl5 の CVE-2013-1667 - Important rehashing flaw についての見解 - tokuhirom's blog
Perl5 の CVE-2013-1667 - Important rehashing flaw についての見解 あまり触れる気もなかったのですが、日本語でふれている人がいなかったので。 Perl 5.8 〜 5.16 で DoS の security fix がでています。OS の system perl をつかっている場合には問題がありませんが、そうでない場合には自分できっちりとアップデートをおこなった方がいいです。 Hash の rehashing flaw に関するコアの問題ですが、ウェブアプリケーションを外部から攻撃可能な場合があります。また、このケースは、ミドルウェアなどでの防御は困難そうです。 セキュリティフィックスのあたった、Perl 5.16.3 または 5.14.4 にアップグレードしてください。 それより以前の Perl に関してはこの問題を fix する patch
-
CPAN Testersの紹介 - Islands in the byte stream (legacy)
最近Perlのネガティブな話が話題ですが、ちょっとCPANまわりのサービスの自慢をさせてください。それは CPAN Testers です。 CPAN Testers *1 とは、CPANに公開したモジュールがどの環境で動きどの環境でどういうエラーがでるのかを集積するサービスです。 よく「Perl/CPANは枯れている」といいますが、それを支えているのはPerlの歴史とかPerlerの性格といった形のないものではなく、この CPAN Testers なのです。これがすごくいいんですよ。 特徴をざっと並べるとこんな感じ: Social testing service for CPAN Testerたちがモジュールを手元の環境でテストしてそのレポートをサーバに送る CPAN.pm のプラグインとしてレポートモジュールが存在する 同じ環境でもビルドオプションが違うパターンもあるので、自分ひとりで様
-
Data::Dumper が壊れているという惨事 - Islands in the byte stream (legacy)
あるいは PERL_CPANM_OPT=-n は危険だという話。 それはこのtweetから始まった。 結局これは Data::Dumper 2.143 が壊れていたからなのだが、そこに至るまでがちょっと大変だったので記録しておく。 まず、再現スクリプトは以下のものだった。 # executed in perl 5.10.1 use strict; use warnings; use Data::Dumper; use Text::Xslate; my $tx = Text::Xslate->new({ syntax => 'TTerse' }); my $template = <<TMPL; [% value | dump %] TMPL my $value = +{ 'ab' => 'c', }; print Dumper($value); my $ret = $tx->render_s
-
おそらくはそれさえも平凡な日々: CPANモジュールのパッケージングの歴史
最近同僚が次々とCPAN Authorになってて良い流れだなーとか思っています。 ただ、CPANへのモジュールの上げ方がわからないとか、M::Iを使えばいいのか M::Bを使えばいいのか、それらがそもそも何やってるのか分からないという話も 聞くので、僕自身もその辺の知識を整理してアップデートしました。 とりあえず、今はModule::Buildを使っておけば良いんじゃないかと 思っていますが、そこに至る歴史的経緯をまとめてみます。 大体、以下に書いてあることに加えて、最近の動きを書いています。 Module::Build：MakeMakerの後継者を目指して PerlでCPAN形式のモジュールを配布する場合は、Makefile.PLなりBuild.PLなりを モジュール作者が用意して、それがインストールに必要なファイル類を自動生成 するという流れになっています。 既存の雛形を使うと色々ファ
-
なんてこった…CPANモジュールをnode.jsで動かしてしまうライブラリ「node-perl」 - tokuhirom's blog
なんてこった…CPANモジュールをnode.jsで動かしてしまうライブラリ「node-perl」 https://github.com/tokuhirom/node-perl/ ここ最近、プログラミング言語同士の壁が徐々に破壊されている気がします。あるプログラミング言語上で別なプログラミング言語を動くようにしたり、置き換えてしまったりするような類です。今回はその一つ、CPAN moduleをnode.js上で動かすという、かなり無茶な気がしなくもない、そんなソフトウェアnode-perlを紹介します。 var Perl = require('../index.js').Perl; var perl = new Perl(); perl.use('LWP::UserAgent'); var ua = perl.getClass('LWP::UserAgent').new(); var res
-
Perl QA Hachathon 2012に参加してきました - Charsbar::Note
報告が遅くなりましたが、2012年3月30日から4月1日にかけて、パリのシテ科学産業博物館で開催されたPerl QA Hackathon 2012に参加してきました。今回のイベントでは渡航費から現地での宿泊費、会場での朝食、昼食、そして会期中の夕食＝懇親会の費用に至るまで、ありがたいことにすべてスポンサー様からの出資で賄っていただきました。収支の概要については以前からサイト上に公開されていますが、過去最大規模となったイベントを支えてくださった運営チームおよび企業・団体スポンサーの皆様（Cité des sciences & de l'industrie、Diabolocom、Dijkmat、DuckDuckGo、Dyn、Freeside Internet Services、Hedera Technology、Jaguar Network、Shadowcat Systems Limited、
-
Parallel::Benchmark というモジュールを書きました - 酒日記 はてな支店
プロセスを並列に立ち上げて負荷を掛けるようなベンチマークを実行することって、よくありますよね。(例 : クエリキャッシュを切ったほうがいイカ？ ベンチマークしてみた - 酒日記 はてな支店) Perl で Parallel::ForkManager を使うとそういう処理も簡単に書けて便利なのですが、何度も同じようなコードを書くうちに、これもうちょっと抽象化したら使いやすいかも、と思って Parallel::Benchmark というモジュールを書いてみました。 リポジトリはこちらです。 https://github.com/fujiwara/p5-Parallel-Benchmark たとえばフィボナッチ数 fib(10) を求めるベンチマーク。 use Parallel::Benchmark; sub fib { my $n = shift; return $n if $n == 0 o
-
perl ♡ tests - Articles Advent Calendar 2011 Test
こんにちはとみたトミールです。先日会社の勉強会で枠をもらいまして、「あまりperlによる開発をしていない人へのperl紹介」的な話としてperlのカルチャーとしてのテスト、という紹介をしました。わりと評判がよかったのでほかのトラックと内容かぶるところありますが気にせず書き起こし的に書いてみます。 dev w/perl select modules write tests ... perlを使った開発の特徴として、モジュールが充実してる話はわりと有名とおもいますが、実際のコード書き始める前にまず使うモジュールを選ぶ作業があったりします。そのへんはそのうち話すとして。 ほかに、テストを大事にするというかテストを書いてから実際のコードを書くという文化があるのが誇れる点だとおもっていて、 perl's test code = just simple perl script perlのテストコードは
-
use Test::Attribute::AutoLevel - Articles Advent Calendar 2011 Test
こんにちは、ｶﾜ(・∀・)ｲｲ!!アイコンで有名なnekokakだよ。 今日はｶﾜ(・∀・)ｲｲ!!僕がつくったTest::Attribute::AutoLevelという イカしたモジュールを紹介してみたいと思うんだ。 僕はテストを書く時にテスト用の便利関数を定義することがよくあるんだ。 そのテスト関数の中でTest::Moreのテスト関数を実行するんだけど、 そこでテストがコケたときに表示されるエラーメッセージがおかしなことになるんだ。 例えば use strict; use warnings; use Test::More; sub test_cute_icon { my $icon = shift; is $icon->{state}, 'cute'; } { package My::Icon; sub new { my ($class, $opts) = @_; bless $op
-
perl でテストを始めよう！！ - Articles Advent Calendar 2011 Test
はじめに こんにちはこんにちは！最近会社のモニターが二枚になって持て余している xaicron です。 さて、Test Track と称して始まった本トラック。全部よめばあなたもテストを書かずには生きていけない、そんな身体に大変身していること間違いなしです。 とりあえず今日は初日なので、perl でテストを書くときに必ずと言っていいほど利用する Test::More を使ったテストの書き方を書こうと思ます。 また、「テスト」とざっくりといってもいろいろなものがありますが、その辺の細かい話はきっと ikasam_a さんが書いてくれるのでスルーします。 Test::More チートシート まず、More というだけあって、結構機能がいっぱいあるので、チートシートを先にあげておきます。perldoc Test::More のほぼコピペですが、きっと皆さんは perldoc Test::More
-
DBIx::Handlerで安心DB生活 - Articles Advent Calendar 2011 Dbix
こんにちは！nekokakです！ 今年はボクが作ってるDBIx::Handlerというものを紹介してみる。 DBIx::HandlerはDBIのラッパーでありDBのコネクション周りの管理に重点を置いたモジュールである。 ORMを使わずにDB周りの処理を行いたい場合はこのDBIx::Handlerを使うことをおすすめする。 自分でDBIのインスタンスを生成し利用する場合どこまで正しくコネクション管理をあなたはできますか？ そもそも親プロセスで接続したdbのインスタンスを子プロセス側でも利用することの問題を正確に把握していますか？ そこまで正しく細かく理解し自分で実装できたとしてもだ、新しいプロジェクトを作るたびにそのコードをコピペするのか？ そこでDBIx::Handlerの出番だ。 DBIx::Handlerはそのあたりの処理をすべて面倒みてくれる。 もうあなたは いつDBとの接続が着られ
-
Config::ENV - 環境変数で config を切替えるためのモジュール - Articles Advent Calendar 2011 Hacker
前置き こんにちは。cho45 です。みなさん、意識は高まっていますか？ 僕は上々です。今回は拙作の Config::ENV というモジュールを紹介させて頂きます。 アプリケーション開発をするとき、開発用・テスト用・本番用で、設定を変えたいわけですよね。だいたいのウェブアプリケーションフレームワークでは、環境変数にある値を設定することで、複数の設定を一括で切替えられるような機能を提供していると思います。Config::ENV は、その機能を1つのモジュールとしたものです。 Config モジュールを書く とりあえず簡単な使い方を紹介します。まずは以下のように設定を保持するモジュール (MyApp::Config) を作ります。 package MyApp::Config; use Config::ENV 'PLACK_ENV'; # (1) common +{ # (2) api_key
-
rbenvの切り替えの仕組み…と、他言語での実験 - すぎゃーんメモ
rbenvを使ってみる - すぎゃーんメモの続き。 現時点でのrbenvのバージョンは0.2.1。 rbenvを使っていると.rbenv-versionファイルの有無でrubyコマンド打ったときに実行されるrubyが違うものになる、というのがちょっと新鮮で、これはどういう仕組みで動いているのだろう？と思って少し調べてみた。 上記記事のようにrbenvの設定をした環境では、 $ which ruby /Users/sugyan/.rbenv/shims/rubyとなり、${RBENV_ROOT}/shims以下のrubyを指すことになる。ここへのPATHは$HOME/.rbenv/libexec/rbenv-initに echo 'export PATH="'${RBENV_ROOT}'/shims:${PATH}"' と書かれているので、eval "$(rbenv init -)"してあれ
-
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
-
-
第9回 高速なWeb APIの実装とテスト―Mobage APIを支えるノウハウ（1） | gihyo.jp
本連載では第一線のPerlハッカーが回替わりで執筆していきます。今回のハッカーはDeNAの嶋田裕二さんで、テーマは「高速なWeb APIの実装とテスト」です。 Web APIの基礎知識 はじめまして、DeNAでMobageオープンプラットフォームのWeb API（以降Mobage API）を実装しているxaicronです。Mobageオープンプラットフォームは、Mobageの機能をWeb APIを通して外部の開発者に公開することにより、ソーシャルゲームをユーザに提供するサービスです。 簡単に説明するとWeb APIとは、HTTPを利用してネットワーク越しに処理を行い、結果を返すしくみです。最近ではJSON（JavaScript Object Notation）というフォーマットを利用してデータのやりとりをすることが多くなっており、Mobage APIも基本的にはJSONを受け取って処理を行
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました