Pelletkachels.nl
Pelletkachels waren ooit eenvoudige apparaten voor verwarming, maar ze hebben een opmerkelijke evolutie doorgemaakt sinds hun bescheiden begin in de jaren ’80 van de vorige eeuw. In dit artikel duiken we diep in de geschiedenis van pelletkachel, bespreken we de belangrijkste mijlpalen en ontwikkelingen op het gebied van subsidiemogelijkheden en werpen we een blik op de transformatie tot moderne en
OrePANとcpanmでCPANの部分ミラーを作ってCPANモジュールを管理する - blog.nomadscafe.jp
これまでサービスで使うCPANモジュールの管理と言えばrpm/debパッケージが主流だと思いますが、最近ではperlbrewで使いたいバージョンのperlをインストールすることもあり、rpm/debでは対応できなくなってきています。 perlbrewのperlに対してプロジェクトが依存しているCPANモジュールを入れる際、 $ perlbrew switch perl-5.12.3 $ cd /path/to/MyProj $ perl Makefile.PL $ cpanm --installdeps . などと cpanm —installdeps が使えます。 しかし、これではサーバを新規セットアップするたびに、最新のモジュールが入ることになりサーバ間でモジュールのバージョンの差異が生まれる可能性があります。 そこで対応策として考えられるのが開発サーバで—installdepsを実行
perlモジュールのinstallにcpanmを使う - Perl - @OMAKASE
当サイトのblogのエントリーで検索ワードが多いのはCPANなんですがこの古い記事はperl5.6時代に書いた記事(多分10年近く前だと思う)で今時のperl使いにお勧めできるものではありません。 2010年2月にあの miyagawa さんが書いた cpanminus が非常に素晴らしいので CPAN::shell を捨てて App-cpanminus を積極的に利用しましょう。 と言うことでcpanに関連して新しい記事を書いてみました。 CPAN::shell の欠点 設定が面倒 動作が遅い(cpanmと比較して) 多くのメモリが必要(制約のきついレンタルサーバで使うのは無理) 依存するモジュールが多い 基本root権限が必要 cpanm の利点 一枚岩のプログラムで可搬性に優れる 高速で小メモリでも動作可能 pluginで拡張できる local::lib と組み合わせるとユーザーラン
Shibuya Perl Mongers 2代目リーダーの竹迫 良範さんの記事 - 初心者だけどPerlが大好き
正しいPerl/CGIの書き方 Webプログラミング初心者からの脱出の手引き より http://itpro.nikkeibp.co.jp/article/COLUMN/20071011/284280/ 多くのプログラムは，書くのにかかる時間よりも，他人に読まれる期間のほうが圧倒的に長いものです。 自分の書いたPerlプログラムの可読性を高めるためにはどうすればよいのでしょうか。 その答えの一つがDamian Conway氏の著書「Perlベストプラクティス」（オライリー・ジャパン発行）にあります。Perlでプログラミングを行う際の200のベスト・プラクティスが著者の豊富な実体験を基にまとめられており，とても参考になります。これからPerlを勉強しようとする人，今までPerlを使っていた人の両方にお勧めできる本です。 Perlの有名なスローガンにTMTOWTDIという言葉があるのを聞いたこ
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
Perl テストスクリプトの書き方 - nDiki
Perl ではコンパイル時に発見できない/発生しないエラーを含むプログラムを書いてしまいやすい。 robust なプログラムを開発するには、テストファースト開発といった開発手法を用いることや、リグレッションテストの整備したりするといったことが重要である。 Perl では標準でテストスクリプトの作成や実行を支援するモジュールが用意されており、これらを利用することで効率的にテストを行うことができる。 以下、準備中。 Test::More Perl でテストスクリプトを書く際の基本となるモジュールが Test::More である。 通常はこのモジュールで定義されているテストサブルーチン(ok、is、……)を使用して、テストケースを書くことで Test::Harness のプロトコル (TAP) に準拠したテスト結果を出力するテストスクリプトを書くことができる。 例については「Test::More
Perlプログラムのコードカバレッジ解析
Perlプログラムのコードカバレッジ解析 真実32 充分テストをしたとプログラマが自信を持つソフトウェアでも、全パスの50〜60%程度しか網羅していない。 パス・カバレージ・アナライザのような自動化ツールを使うと、網羅率が85〜90%に上がる。しかし、100%のパスを網羅するのは不可能だ。 真実34 ツールを使わないと、不良除去はうまくいかない。デバッガはみんな使うが、カバレージ・アナライザは、ほとんど使わない。 ソフトウエア開発 55の真実と10のウソより。 ということで、Perl 用のカバレッジ分析ツールを探してみる。 CPAN にある Devel::Cover が良さそげ。 Debian BOX にインストール apt-get install libtest-differences-perl \ libpod-coverage-perl \ libtemplate-perl してから
Devel::Bayside - コードカバレッジ
コードカバレッジというのは、ソースコードの何％が実行されたかという指標のことです。たとえば、以下のようなコードがあったら、 sub is_devide_100 { my $value = shift; if ($value % 100 == 0) { return 1; } else { return 0; } } &is_divide_100(1); と &is_divide_100(100); を呼ぶと、すべてのパスを通るので is_divide_100 のコードカバレッジは100%になります。 CPAN に Devel::Cover というモジュールがあります。このモジュールを使うと、Perl のコードカバレッジが計れます。Catalyst アプリでコードカバレッジを計るには、以下のようにします。 $ sudo cpan Devel::Cover $ cd myapp/script
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
