Ruby会議2009 1日目レポート［更新完了］ | gihyo.jp
本日から東京都千代田区の学術総合センターにて3日間にわたり、RubyKaigi2009が開催されます。本ページでは、1日目のレポートを随時掲載していきます！ ※今回のレポートは、一橋記念講堂でのセッションを中心にお送りします（全セッションを回れておりません。ご了承ください）。 イベント開始前 開場は12時30分からですが、スタッフの皆さんは8時30分に集合しました。 まずは、スタッフ専用のTシャツが配られました。イベント開催期間中、スタッフはこの専用のTシャツを着用します。 本日午前中は、スタッフ総出で、慌しく、会場の準備にあたりました。 準備中の中、会場の入り口から各会場へ、通しで簡単に撮影したものが以下の動画です（なお、撮影の後に、掲示物が貼られたもの等もあります）。 ニコニコ動画：https://www.nicovideo.jp/watch/sm7657153 オープニング
zshで究極のオペレーションを 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
モバゲータウンのノウハウ満載！ フレームワークMobaSiFを使おう！ 記事一覧 | gihyo.jp
第4回MobaSiF に含まれるケータイ向け処理モジュール 能登信晴，川崎修平 2008-09-12
第10回 Class::Meta::Express：もっと読みやすく、周囲への影響は最小限に | gihyo.jp
「シュガー関数＝モダン」ではありませんが 「モダンPerlがわからない」と言われる大きな原因のひとつが、MooseやJiftyに見られるシュガー関数、ドメイン特化言語（DSL）の氾濫にあることは衆目の一致するところでしょう。 前回紹介したJiftyでは、スキーマとアクション用にそれぞれひとつ、ディスパッチャ用にひとつ、テンプレート用にひとつ、という具合に都合3系統4種類のドメイン特化言語が使われていましたし、Mooseの場合も、アトリビュートや型の定義にメソッドモディファイアと、さまざまなところで独自の記法が用意されています。Catalystも、テストの際には独自のシュガー関数を使っていました。もちろん探せば似たような例はいくらでも見つかることでしょう。 このようなシュガー関数は、1998年にリリースされたPerl 5.5でコアに導入されたTestモジュールなどを見てもわかる通り、本来はモ
第9回 Jifty：一足早いクリスマスプレゼント | gihyo.jp
Perl 6チームからのクリスマスプレゼント この連載でも何度か名前が出てきたPerl 6ですが、「クリスマスまでにはリリースされることになっている」という話はみなさん先刻ご承知のことと思います。 もちろんこの話には「どのクリスマスかは秘密です」というオチがつくわけですが、2000年の設計開始以降、これまでにも何度か「今年こそはひょっとするとひょっとするかも」という期待を持たれた年がありました。 オードリー・タン（唐鳳）氏がHaskellの勉強がてらわずか2ヶ月でPerl 6の処理系（Pugs）を実装して話題になった2005年は、まさにその筆頭格といってよいでしょう。 実際、この年はPerl 6とその関係者にとって非常に大きな意味を持つ年になったのですが、この年はまたRuby on Railsが本格的にブームになった年でもありました。ただでさえPerlからRubyに転向する人が後をたたな
Webフレームワークの新しい波 Waves探訪記 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
第7回 小規模Webアプリのためのフレームワーク、Sinatra | gihyo.jp
はじめに あなたは「Ruby」と聞いて最初に何を思い浮かべますか？ オブジェクト指向スクリプト言語であること、プログラミングの「楽しさ」を重視して設計された言語であること、最近新しいバージョンである1.9.1がリリースされたこと……。 Rubyにはいろいろな特徴がありますが、Rubyという単語からすぐに「Ruby on Rails」を思い出す方も多いのではないでしょうか。Ruby on Rails（以下Rails）は2004年に公開されたRuby用のWebアプリケーションフレームワークで、その生産性の高さから注目を浴び、Rubyの名前を広めることにも大きく貢献しました。 ですが、Java、PHP、Perl、Pythonなど、他の言語の世界ではいくつものフレームワークがしのぎを削っているのに対し、Rubyの世界においてはRailsの完成度の高さから、長らくライバル不在の状況が続いてきました。
第9回 SinatraとSequel・Hamlで掲示板アプリを作る | gihyo.jp
はじめに 第7回はRails以外のWebフレームワークの簡単な紹介と、SinatraでHello Worldアプリケーションを動かすところまでを解説しました。今回はSinatraで実際のアプリケーションを作り、SequelとHamlという2つのライブラリを紹介します。 Sinatraの特徴は、CGIスクリプトのようにファイル一つからアプリケーションが書ける気軽さです。CGIスクリプトといえば、代表的なものは何と言っても掲示板（BBS）です。そこで、今回はSinatraで掲示板アプリを作ってみました。ソースコードが少し長めなので、githubにて全文を公開しています。適宜参照しながら読み進めて下さい。ファイル構成は以下のようになっています。 start.rb アプリケーションの本体。 model/comment.rb 掲示板の書き込みを表すモデルの定義。 view/index.haml トッ
ついに出た！最新Perlフレームワーク「Ark」徹底解剖：第1回 Arkって何だ？ -Ark が生まれるまで｜gihyo.jp ... 技術評論社
はじめまして。面白法人カヤックの村瀬と申します。ArkというWebアプリケーション作成用のフレームワークを開発しました。今回から4回にわたって、このリリースしたばかりの「Ark」について紹介させていただきます。 Ark（アーク）とは Arkは、Perlで作られたWebアプリケーションフレームワーク（WAF）です。 Arkの特徴としては Catalystに似たインターフェース CGI／FCGI／mod_perlなどさまざまな環境で実用的に動作する CGI用モードの存在 日本製であり、日本語ドキュメントが充実している などが挙げられます。 Catalystに似たインターフェース Catalystは、Arkと同様にPerl製のWebアプリケーションフレームワークで、現在、Perlのフレームワークでは標準となりつつあるものです。 Arkは開発動機の1つが「CGIでも実用的に動作するCatalyst
第8回 Reaction：CatalystをもっとDRYに | gihyo.jp
アプリケーションの枠組みを越えた再利用 前回は、Catalyst 5.7で登場したチェーンドアクションを利用して適切なベースコントローラをつくれば、CRUDのような定型処理は再利用できるようになる、という話をしました。これはコンテントマネジメントシステム（CMS）のように同じようなインタフェースを持つ画面が多いシステムをつくるときには特に効果的なのですが、その再利用を、ひとつのアプリケーション内だけで完結させてしまうのはもったいない話。自社でつくるアプリケーションにはどんどん使い回していきたいものですし、コピー＆ペーストを避けるためには、なんらかの名前空間上にその共通コードをまとめていく必要があります。 もちろんそのコードが小さく、十分に一般化できるものなら、Catalyst、あるいはCatalystXという名前空間に入れてもかまいませんが、コントローラの部品だけでなく、モデルやビューまで
第7回 Catalyst::DispatchType::Chained：チェーンドアクションはむずかしい？ | gihyo.jp
モダンPerlの世界へようこそ 第7回Catalyst::DispatchType::Chained：チェーンドアクションはむずかしい？ 5.7系列の目玉だったチェーンドアクション 3年前に登場したCatalyst 5.7系列で導入された機能のひとつに、チェーンドアクションと呼ばれるものがあります。これは慣れると非常に便利な機能なのですが、それまでのURLとクラスの対応を根底から覆してしまう大転換だったわりにドキュメントが不足していたため、活用の仕方がわからないという声もありました。 今回はCatalyst 5.8系列で導入された新しいツールを使いながら、このチェーンドアクションの使い方を紹介していきます。スペースの都合でCatalystの基本はある程度理解しているものとして話を進めますので、わからないことがあったらCatalyst本体のドキュメントやCatalyst::Manualなどを
第4回 Test::Perl::Critic, Test::Pod, Test::Pod::Coverage, Test::Exception, Test::Warn, Devel::Coverの紹介 | gihyo.jp
Happy Testing Perl 第4回Test::Perl::Critic, Test::Pod, Test::Pod::Coverage, Test::Exception, Test::Warn, Devel::Coverの紹介 モバイルファクトリーの小林です。今回は今までに紹介しきれなかったPerlのTestingモジュールで良く利用されるものをいくつか紹介したいと思います。 Test::Perl::Critic このモジュールはテスト対象のコードがPBPに準拠しているかどうかをテストしてくれるモジュールです。 PBPとはDamian Conway氏の提唱するPerl Best PracticesというPerlのコードを書く際のスタイルです。 http://www.oreilly.co.jp/books/4873113008/ Perl Best Practicesについての詳細
そろそろLDAPにしてみないか？：第1回 まずは使ってみよう｜gihyo.jp … 技術評論社
案外身近な？ LDAP 古くから存在するのですが、使用する機会がないとなかなか概念を理解することができないプロトコル、そのひとつがLDAP（Lightweight Directory Access Protocol）ではないでしょうか？少なくとも数年前の筆者はそうでした。LDAPは「エルダップ」と発音します。 HTTPクライアント、HTTPサーバがあるよう、LDAPにもサーバ、クライアントという概念が存在します。LDAPサーバとは一言で言えばデータベースサーバなのですが、同じようにデータベースに分類されるPostgreSQLやMySQL、OracleなどのRDBMS（Relational Data Base Management System）と比較すると、一長一短があるため、管理対象のデータによって両者の使い分けを行うのが賢い選択です。 たとえばLDAPとはデータ追加や削除よりも検索を重
memcachedを知り尽くす 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
第6回 Catalyst::Upgrading：検証はお早めに | gihyo.jp
3年前の大混乱 モダンPerl界を代表するウェブアプリケーションフレームワークといわれるCatalystが2006年半ばに5.6系統から5.7系統に移行したとき、創始者のゼバスティアン・リーデル氏を追い出す形で集団管理体制に移行した開発チームが最初にしたことは、プロジェクト開始当初から使われてきたCatalystという名のディストリビューションはそのままに、Catalyst-Runtimeという新しいディストリビューションをつくることでした。 このようなディストリビューション名の変更は、CPANクライアントを使っている分には（内部でモジュール名からディストリビューション名への変換が行われるので）問題にならないのですが、外部のパッケージ管理者たちには少なからぬ負担をかけました。なにしろ突然100を越す関連パッケージの依存が変更になるのです。基本的にはメタ情報だけ書き換えれば済む話とはいえ、従
第5回 Pod::Perldoc：ドキュメントはどこに？ | gihyo.jp
もっとも、これがそのままPerlの人気と連動していたかというと、そうとも言い切れないのがむずかしいところ。2005年以降の退潮にバブル的な人気を誇ったRuby on Railsの影響があったのは間違いないでしょうが、内外から500人近い参加者を集めるYAPC::Asiaのチケットがわずか3日で売り切れてしまうくらいの需要はあるのですから、これまで「モダンな本」がなかなか出てこなかった原因は、むしろ20世紀末から続く出版界の不況とそれによる出版傾向の変化や、日本のPerlユーザがブログという個人メディアで旬の話題を消費することに慣れてしまった結果、最低でも2～3ヶ月のタイムラグが生じてしまう出版コストに不満を感じてしまうようになった（2002年というのはMovable Typeの日本語化パッチが出回り始めた年でもあります）、等々の問題の方が大きかったようにも感じられます。 単行本10冊分
第4回 Any::Moose：なにがどうでもムースはムース | gihyo.jp
CPANTSは情報の宝庫 Perlを使う最大の利点といわれるCPANですが、CPANは単なるモジュール置き場ではありません。CPANはまたPerlの利用状況を知るうえで不可欠な統計情報を得る場でもあります。そのような統計情報のいくつかは、いわゆるCPAN検索サイトからも確認できますが、より突っ込んだ情報が欲しい場合はCPANTS（CPAN Testing Service）と呼ばれるサイトを確認するのが便利です。 国内ではnipotanこと谷口公一氏が始めた「輝け！全日本最強 CPAN Author 決定選手権」のネタ元として知られていますが、このサイトでは個々の作者やモジュールの品質だけでなく、そのモジュールが実際にどこで使われているかという情報を得ることもできます。 たとえば前回取り上げたロール関連のモジュールの利用状況を調べてみると、古き良きExporterを依存モジュールとして取り上
第3回 Moose::Role：役割単位のクラス分け | gihyo.jp
多重継承しないほうがよい場合 前回は多重継承を利用してクラスを拡張するときにありがちな問題と、そのひとつの解決策を見てきましたが、クラスにいくつかのメソッドを追加したいだけであれば、むしろ継承を利用しないほうがふさわしい場合もあります。 たとえば「コウモリ」というクラスを実装するとき、「乳を出す」というメソッドのために「ほ乳類」というクラスを、「空を飛ぶ」というメソッドのために「鳥類」というクラスを継承するのは――たしかにそれで当座の問題は解決するかもしれませんが――違和感が残ります。 use strict; use warnings; use Test::More tests => 4; package Mammal; sub new { bless {}, shift; } sub produce_milk { print "I can produce milk.\n"; } pa
第4回 Mojoの歴史と展望 | gihyo.jp
MojoとHTTP::Engine ここまでMojoとそのサンプルフレームワークであるMojoliciousについて見てきましたが、国内でもYappoこと大沢和宏さんとtokuhiromこと松野徳大さんが中心となって、HTTP::Engineという同じような趣旨のフレームワークが開発されていることをご存知の方も多いと思います。今回はそのHTTP::EngineとMojoを比較しながら、Mojoの歴史や展望を見ていきましょう。 HTTP::Engineの誕生 HTTP::Engineも、もとをただせばMojoの作者ゼバスティアン・リーデル（Sebastian Riedel）氏が4年ほど前にリリースしたCatalystというフレームワークから派生したものです。だから、Mojoとは義理のおじ、あるいは いとこ・はとこ くらいの関係になるでしょうか。 CatalystもCPANモジュールをつなぐ「
第2回 mro：次のメソッドはどこ？ | gihyo.jp
モダンなクラス／オブジェクトのあり方は？ Perlではそもそもオブジェクトという考え方自体が、Perl 5（Perl 7歳）ではじめて登場した、後付けのものでした。また、その実装も非常におおらかなものだったため、より「本格的な」オブジェクト機構を備えた言語のユーザからはしばしば批判されてきました。 ただし、転んでもただでは起きないのがPerlハッカーたちのよいところ。そのような批判を糧に、「モダンPerl」の世界でもっとも激しく、多様に進化してきたのがこの分野です。 今回はそのようなクラス／オブジェクトの進化の一例として、クラスの継承とメソッドの解決順序にまつわる話題をまとめていきます。 継承によるクラスの拡張 伝統的なbaseプラグマを使ってクラスを拡張する場合、継承元と継承先に同名のメソッドがあれば継承先のメソッドだけが優先的に実行されます。 use strict; use warn
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
