人力検索でPerlの開発環境はどんな感じ?という質問があがっていて、にわかに盛り上がって(?)いますね。僕も回答してみました。 一般的にPerl使ってる人はWindowsで開発する人が多いんですかね?サーバにログインして、ターミナル上で開発をする人って結構少ないのかなぁ。 自分なんかローカルで一応Active Perlをインストールしているけど、ほとんど使わないし…。普段はサーバにログインしてそこでemacsで開発、ローカルでやるとしたらcolinuxにログインしてそこで開発って感じです。Windows上にソースを置くということはしてませんねぇ(あ、colinuxはWindows上か…) その感想として Emacs とか vi 使わないの? っていう話。mixi なんかを見てても僕の周辺で同じ感想を持ったひとが多かったようで。 やっぱり Perl は PC-UNIX を含む UNIX との
近年のWebアプリケーション開発は大規模化が進み、基幹システムなどの一角を担うまでになってきています。また、Webアプリケーション開発はレガシーなシステム開発に比べて手間のかかる部分が多いにも関わらず、開発にかけられる工数は短縮化の傾向にあります。 そのため、案件の大規模化で開発に携わる人数も増える傾向にあり、開発チームの各々がWebアプリケーションのライブラリを別々に制作してしまい、同様の機能を持ったライブラリが複数存在してしまったり、またUIを担当するデザイナーとビジネスロジックを担当するプログラマが、いざそれぞれの部分を組み合わせようとしたらうまく機能しなかったりといった様々な問題が出てきます。 このような背景から、それらの問題に対するソリューションのひとつとして現在、開発現場ではWebアプリケーションフレームワークを用いた開発スタイルが注目され、実際に多くの開発会社がWebアプリケ
フレームワーク対決は、Perl、Ruby、GaucheからそれぞれSledge、Ruby on Rails、Kahuaというウェブフレームワークを発表するというセッションだ。まずセッションに先立ち、ウェブフレームワークとはどういったものか、それがもたらすものは何かといった説明があった。 ウェブフレームワークといえばJavaのStrutsが有名だ。現在では次期ウェブフレームワークとしてJSF、Struts 2、Hibernate、Spring、Seasar2なども開発にしのぎを削っている。最近ではP言語(PHP、Python、Perlなど)と呼ばれることが増えているが、P言語はウェブフレームワークが弱いと言われることが多い。しかし1999年にはPHPでフレームワークが使われているなど、LLにおけるフレームワーク採用の歴史は意外と長いのだ。 Sledge(Perl) ライブドアの池邉智洋氏から
一応、先のエントリで、Sledge の API について詳細に解説し、末尾に書いたんですが、miyagawa さんに「最後まで読む奴 1%」とか身も蓋もないことを言われてしまい、まぁたしかにそんな気もするし、折角頑張って 10 分の壁に挑戦したのに注目されていないのも淋しいことこの上茄子だなーと思い、別エントリへ昇格させました。 ということで、Sledge API 解説に続く Sledge 実践編として、10 分で作る Rails アプリ for Windows やら、10 分で作る CakePHP アプリ for Windows あたりにインスパイアされ「10 分で作る Sledge アプリ」というテーマで、無謀にも挑戦してみました。 漢の挑戦をとくとご覧あれ いや、ぶっちゃけ無理っす。 先に結果言いますけど、10 分なんて無理っす。 ちゃんとはかってないですけど、多分 13 分ぐらいか
現在もっとも注目されていて評価もかなり高い MVC フレームワークとして Ruby on Rails ってのがあります。Ruby on Rails って方は、「【レポート】Lightweight Language Day and Night - フレームワーク対決 (MYCOM PC)」にスマートにまとめられていますが、 Ruby on Railsの特徴はいくつもあるが、必要になるファイルが自動生成されるという点が興味深いところだ。railsコマンドを実行すると必要になるファイルが自動的に生成される。標準的な利用であれば、設定ファイルを書くだけでウェブアプリケーションとして動作させることも可能だ。 Ruby on RailsにはDRY(Don't Repeat Yourself)というポリシーがあり、できるだけ同じことはしないようになっている。DRYを実現する方法として、規約重視、言語重視
CPANに Toolkit っていう粋なモジュールがあります。これは、emacsとかvimのカスタイズ性が持つ楽しさに近いラブリーなモジュールです。どういうモジュールなのか、順に説明してみます。 まず前提として、なんで Perl を使うの? というと、そこには中央ライブラリCPANがあるからさ、というのが大きいと思います。 ようするに、何やろうと思ってもたいていはなんかを use すればすんじゃうわけです。 ところが慣れてくると、useがずらーっと並んでしまうという弊害が。 例えばまあ最初に use strict; use warnings; とかで始めるのは基本として、DBに問い合わせ処理をしつつ、ファイル変換をし、メールで最後通知を送りたいよみたいな場合、 use DBIx::Simple; use File::Slurp; use Template; use MIME::Lite::
最近、お仕事で悩ましいのがデータベース負荷。結局のところ、Web サービスでボトルネックになるのは、バックグラウンドの DB 処理。特にどうしようもないのが、更新系リクエスト。つまりはマスターDB。 既に多くのところが採用している構成と思いますが、MySQL とかでよくやる手段といえば、 参照系は、レプリケーション機能を使って参照系DBを用意して負荷分散。マシンを増やせば負荷に対応可能。 更新系のクエリーだけは、できる限り高スペックなマシンを用意してマスターDBを構築して一手に引き受ける。増設困難で悩ましい。 もうちょい頭をひねれば、機能毎にマスターDBを分散させたり、ユーザ ID とかでパーティショニングしたりと、アプリ層で振り分ける。MySQL に限らず、Oracle とかでも同じようなことが言えます。 で、マシン負荷を監視という運用業務が必須な日々を送っていた(いや、実際にはPJのメ
2008-10-21 追記 いまだに(ありがたいことですが)検索で飛んできたりブクマされたりというのがちょいちょいあるので,最新動向を書いておきます。 id:tokuhirom さんが Lingua::JA::Regular::Unicode という Pure Perl Module をリリースなさいました(→ http://d.hatena.ne.jp/tokuhirom/20081018/1224300947)。 あなたが作っているアプリで文字列まわりを Unicode::Japanese インスタンスですべて持ちたいわけでなければ(そして,たいていのばあい,持つ必要はないのですが),この Lingua::JA::Regular::Unicode を使うのがベターです。依存性もなく,とても軽量ですので。 2008-10-21 追記おわり ウェブアプリを作っていると,ユーザが入力した半角
2006年06月16日00:00 カテゴリLightweight Languages書評/画評/品評 perl - 自動で /a|b|c/ を /[abc]/ にしてくれたら... 正規表現においては、/a|b|c/(alteration)は[abc](character class)にすべし、というのは、perlに限らない常識です。 Mastering Regular Expression Jeffrey E. Friedl [邦訳: 詳説 正規表現] qootas.org/blog - perl regex performance"|"(パイプ)を使った正規表現はめちゃくちゃ遅いから使わないように、ということです。確かにベンチマークを取ると32倍速いです。 どうせならPerl自身が内部で/a|b|c/を[abc]にしてくれたらと思ったことありませんか? 少なくとも、正規表現を仕事で使う
Perlには、日時の加・減算を扱うモジュールが標準でついてきません。僕の仕事場ではずっと、同僚が作ったオリジナルモジュールを皆で使いまわしていたのですが、今になって、世間的 (CPAN) にはどんなものがあるのか気になって調べてみました。※参考になったのは miyagawa 氏のメールマガジンの過去記事と、perl.com の The Many Dates and Times of Perl なるエントリでした。 今回は数ある日付関連モジュールの中から、Dave Rolsky氏の DateTime モジュールについて、その基本的な使い方について簡単にまとめたので共有してみます。 同氏は上記 perl.com 記事の執筆者であり、この前の YAPC::Asia で DateTime project について講演してくれていた人です。気合の入ったモジュールを作ってくれた事に感謝。 目次 基本
日付の表記方法は、文化的な背景の違い、また用途の違いによって様々なフォーマットがあります。多くの場合、特に断り無く使っても問題なく正しい日時を伝えることができますが、文脈や利用者の環境によっては、意外な落とし穴にはまることもあります。誤解なく、かつ効率的に処理しやすい日時表記方法としては、2001-08-02T10:35Zというスタイルの、ISO/W3Cフォーマットがあります。 文化と日付表記 日時表記の国際標準とW3Cノート W3Cの日時フォーマット XML Schemaの日時データ型 タイムスタンプのインターネット標準 そのほか広く用いられる日時の書式 ピリオド区切りによる日付 電子メール、HTTPヘッダなどの日時表記 継続期間の表記 ISO 8601の期間表記 Dublin Coreの期間表記 読みやすさと処理しやすさのバランス 参照文献 文化と日付表記 よく見かける日付の表記法とし
前回のエントリ 「Perlで日付・時間操作 - DateTime モジュールの使い方」で書いたとおり、とっても便利なDateTimeモジュールですが、強いて難点をあげるとすれば、必要な依存モジュールが多いこと = インストールが面倒くさい事かと個人的には思います。shell と make コマンドが使える環境ならば、"$ perl -MCPAN -e 'install DateTime' " で自動インストールしちゃえるのですが、これができない状況: telnet 禁止の環境で cgi 作りたい場合 (無料ホームページサービス等)(顧客のサーバ環境での開発で、クライアントに信用されていない状況とか) サーバの保守・セキュリティ体制がうんちゃらで make コマンドの利用が規制されている場合 (出くわした経験あり) こんな状況下だと、とたんにDateTimeモジュールを利用する事は難しくなっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く