10年でどう変わった? はてなブックマークでのPerlの使い方2019-11-03 YAPC::Nagoya::Tiny 2019 https://yapcjapan.connpass.com/event/146727/
開発メモ#3 : レガシーなCGIアプリケーションのリファクタリング - naoyaのはてなダイアリー
開発メモその3です。今回は Perl のおはなし。 何年も前に作ったウェブアプリケーションのコードを開いてみたら黒歴史なコードが出てきて憂鬱な気分になる、そんな経験ありませんか。私はあります。ずっとそんな現実から目を背けて生きてきました。 さて、先日 Perl + CGI で書いて Apache::Registry で高速化している、実行環境が Apache に癒着した CGIアプリケーションを発見しました。おえ〜っ。一から作り直したい気持ちをぐっと堪えて、これを Plack 化したりとリフォームしていくとしましょう。その過程を以下記します。劇的ビフォア・アフター! ･･･とかは期待せず、地道な変更を積み重ねていくのがコツです。 方針 いきなりコードをがりがり書き換えていくというよりは、試行錯誤のしやすい環境に移行させていきながらリフォームを進めます。遠回りですが、結果的にその後の運用が楽
Fukuoka Perl Workshop #17 開催のお知らせ
津留です。 お疲れ様です。 YAPC::Asia2010のチケットが発売を開始しましたね。 私は今回もいけそうにないですが、今から行かれる方の土産話を楽しみにしていようと思います。 さて、Fukuoka.pmの開催の準備が整いましたのでご連絡差し上げます。 日時：2010/09/04(土曜日) 14:00〜18:00 会場：株式会社 ヌーラボ （福岡市博多区中洲5丁目5-13 KDC福岡ビル7F） 内容： • YAPC::Asiaにて発表内容について Fukuoka.pmとしてYAPC::Asiaにて発表することが予定されています。みなさんの経験談などを元に作成できたらと思います。 • Fukuoka.pm活動内容について • 福岡のPerl事情について • Perl活用例などお聞かせください。 • 今後のFukuoka.pmの運営について • 主催者の明確化について • サイトなどの管理
いまからでも間に合う開発者テスト - mixi engineer blog
はじめまして。開発部じゃない加藤和良です。 最近、mixi では Buildbot をつかった継続的インテグレーションをはじめています。安定版の mixi のソースコードにコミットすると Buildbot がそれを検知し、自動的にテストが走るようになりました。 ここでの「テスト」は Test::Simple や prove(1) をつかった、Perl でかかれた開発者テストを指しています。mixi の開発者テストをとりまく環境は、ここ数年でかなり改善されました。今回はその歩みをふりかえりながら、テストの無いコードベースをどこからどうやって変えていったかという話をしたいと思います。 開発環境 はじめに、前提となる mixi の開発環境について説明します。mixi では複数人の開発者がひとつのマシンで作業を行います。それぞれの開発者は、あらかじめ割り当てられたポートで Apache を起動し、
Perlのローカルプロキシ紹介と見せかけてJS開発環境紹介 - KAYAC Engineers' Blog
齢27にしてNirvanaをまともに聴き出したtaiyohです。 最近、ベースの他にギターも始めてみたのですが、本当に難しい… （個人の方含め）ブログ書くの本当に久しぶりです。 ちょうど今JavaScriptをがっつり使った案件に関わっているので、開発周りで小ネタを一つ。 JSの割とポピュラーな開発方法として、ローカルプロキシ経由でアクセスし、開発中のファイルを読みこませてチェックするという方法があります。 その最に使う代表的なローカルプロキシとして、Mac OSXやLinuxの場合はCocProxyがありますし、Windowsの場合、FiddlerやProxomitronがあります。 さて、僕の開発方法はといいますと、ローカルプロキシを使用しているという意味ではあまり変わったことはしていません。 ただ最近、ひょんなことから、PerlのHTTP::Proxy::Selectiveというモジ
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
