タグ

ブックマーク / gihyo.jp (19)

  • 第13回 メタオブジェクトプロトコル入門(1) | gihyo.jp

    連載では第一線のPerlハッカーが回替わりで執筆していきます。今回はPerl 5上で先進的なオブジェクト指向を実現するためのフレームワークMooseなどの開発に関わっているShawn Moore(sartak)さんと、Japan Perl Associationの理事である牧大輔さんが、「⁠メタオブジェクトプロトコル」について解説します。 メタオブジェクトプロトコル(MOP)とは さまざまなプログラミング言語がオブジェクト指向機能を提供していますが、オブジェクトの構造を細部にわたって閲覧したり、デフォルトの挙動を拡張したりすることまでできる言語はそれほど多くありません。 このような操作を行いたい場合は「メタオブジェクトプロトコル」(⁠以降:MOP)と呼ばれる技術を利用します。MOPは、オブジェクトのメソッドやアトリビュートなどを含む内部構造そのものを、オブジェクトで表現するしくみです。P

    第13回 メタオブジェクトプロトコル入門(1) | gihyo.jp
    jamadam
    jamadam 2012/06/18
  • 第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を受け取って処理を行

    第9回 高速なWeb APIの実装とテスト―Mobage APIを支えるノウハウ(1) | gihyo.jp
    jamadam
    jamadam 2011/10/03
  • 第8回 Perlによる大規模システム開発・設計のツボ(3) | gihyo.jp

    技術的負債の「見える化」 どのようなソフトウェアにも設計上のミスはあります。設計時点ではサービスの発展性や日々変わりゆく要件を完全に予測することはできないからです。ある時点で正しい設計も、その次のサービスリリースでは設計上の修正を必要とするかもしれません。これらの変更への粘着性や複雑性のある状態を、「⁠技術的負債」と言います。 mixiでは技術的負債は長らく、コードレビュー技術力の高いエンジニアによる新機能リリース時の修正などで対応を行ってきました。しかし、これまでに紹介した「わかりやすいコードの指針」や「アーキテクチャパターン」をレビューや教育だけで維持することは、ソフトウェアが巨大になり、開発者数が増加するにつれて難しくなります。そのため現在では、ソフトウェアの設計品質評価を自動化するツール群を開発し、それらを用いて技術的負債を見える化し、計画的に解消していく試みを行っています。 コ

    第8回 Perlによる大規模システム開発・設計のツボ(3) | gihyo.jp
    jamadam
    jamadam 2011/08/03
  • 第8回 Perlによる大規模システム開発・設計のツボ(1) | gihyo.jp

    連載では第一線のPerlハッカーが回替わりで執筆していきます。今回のハッカーはmixiの広木大地さんで、テーマは「大規模システム開発・設計のツボ」です。 仕事やOSS(Open Source Software)プロジェクトPerlを用いた多人数開発をするにあたって気をつけるべきことや、品質を維持するためのノウハウを、国内最大級のPerlシステムであるmixiの事例をベースに紹介します。コーディング上の命名に関する考え方から、大規模アーキテクチャの設計や品質の数値化まで、ミクロからマクロに至るポリシーやテクニックを駆け足で解説します。 なお、今回の内容は(⁠株⁠)ミクシィの2010年度の新卒エンジニア技術教育メニューからの抜粋になります。これからPerl をはじめとするLL(Lightweight Language、軽量言語)を仕事で使うというフレッシュエンジニアのみなさんにも、ぜひご一

    第8回 Perlによる大規模システム開発・設計のツボ(1) | gihyo.jp
    jamadam
    jamadam 2011/08/01
  • 第43回 Text::Xslate:永続環境に特化したテンプレートエンジン | gihyo.jp

    TTの体を差し替える 前回はウェブ業界で標準的に使われているTemplate Toolkitをより安全に使うためのカスタマイズ方法をいくつか紹介しました。しばしば批判の対象となってきたエスケープの問題については、TTでも適切な拡張を施せば後発のモジュールと遜色ないか、それ以上に便利に使えることは確認できたかと思います。 ただし、エスケープの仕方ひとつとってもさまざまなやり方があったように、TTは、柔軟である代償として速度面ではかなりの不利を抱えています。 もっとも、不利といってもそれはいまの、しかもかなり規模の大きな現場の視点で見たときの話で、数年前、おもなライバルがHTML::Mason(と、機能面で大きな差があるHTML::Template)だった時代にはTTも十分に高速といえましたし[1]⁠、中小規模のサイトではいまでもTTで十分なレスポンスは得られます。 また、かれこれ10年近く

    第43回 Text::Xslate:永続環境に特化したテンプレートエンジン | gihyo.jp
    jamadam
    jamadam 2011/07/22
    コメントを入力してください (省略可能)
  • 連載:目指せ!iPhoneアプリ開発エキスパート|gihyo.jp … 技術評論社

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    連載:目指せ!iPhoneアプリ開発エキスパート|gihyo.jp … 技術評論社
  • 第42回 Template Toolkit:Perl製テンプレートエンジンのデファクトスタンダード | gihyo.jp

    組み合わせ自由なツールキット Template Toolkit、通称TTは、その名前からもわかるように、もともとは単なるテンプレートエンジンではなく、テンプレートエンジンをつくるためのツール群をまとめたものです。そのツール群を組み合わせた標準のエンジン、標準のフロントエンドと呼べるものもありますが、これはあくまでもTTのよくある利用法のひとつであって、そのすべてではありません。 たとえば、CPANにはApache::Templateという、TTのエンジン部分をmod_perl用にカスタマイズしたうえでmod_perl用のフロントエンドをかぶせるモジュールがありますが、これを使えば、最初に多少の設定は必要になるものの、あとはTTのテンプレートを適切なパスに置くだけで、パラメータの取得からルーティング、レンダリングまでよしなに計らってくれるようになります(TTの文法をサポートしたPHPのような

    第42回 Template Toolkit:Perl製テンプレートエンジンのデファクトスタンダード | gihyo.jp
  • 第41回 HTML::Template::Pro:テンプレートに極力コードを書かせたくないときは | gihyo.jp

    何でも埋め込めるのは楽ですが 前回紹介したHTML::MasonやText::MicroTemplateのように生のPerlコードを埋め込めるテンプレートエンジンは、Perlをよく知っている人が画面の設計からウェブアプリケーションのコーディングまでひとり(ないし、よく統制のとれた少人数のチーム)で行うときには非常に手軽で便利なものです。 ただし、なんでも書けるからといって、たとえばテンプレートの中でO/Rマッパのメソッドを直接呼び出すコードを書いてしまうと、そのテンプレートは(利用するO/Rマッパの性質にもよりますが)おそらく実際に動作するデータベースやそれに付随するテストデータを用意しないと、途中で「Can't call method "..." on an undefined value」などのエラーが発生してレンダリングできなくなってしまいます。また、アプリケーションの設定にあわせて

    第41回 HTML::Template::Pro:テンプレートに極力コードを書かせたくないときは | gihyo.jp
  • 第3回 サンプルフレームワーク:Mojolicious | gihyo.jp

    Mojoliciousを使ってみよう 前回はすでにできあがったアプリケーションにMojoを組み込んで移植性を高める方法を見ました。今回はこれから新しいアプリケーションを構築する際のベタープラクティスのひとつとして、Mojoのパッケージに同梱されているMojoliciousというフレームワークを利用する方法を紹介します。 まずはひな形から Mojoliciousのアプリケーションも、Mojoの場合と同じくまずはひな形をつくるところから始めます。今回は簡単なWikiもどきをつくってみましょう。例によってMojoをインストールしたディレクトリでこのようなコマンドを入力します。 > perl script/mojolicious generate app SimpleWiki > cd simple_wiki Mojoのひな形に比べていくらか余分にファイルが生成されます。開発用サーバの立ち上げ方は

    第3回 サンプルフレームワーク:Mojolicious | gihyo.jp
  • 第40回 Text::MicroTemplate:得意分野なんだからPerlを使えばいいじゃない、という方に | gihyo.jp

    モダンPerlの世界へようこそ 第40回Text::MicroTemplate:得意分野なんだからPerlを使えばいいじゃない、という方に テキストの整形はPerlの基 Perlは「Practical Extraction and Report Language」とも呼ばれるくらいで、正規表現などによる情報抽出機能と並んで、レポートの形を整えて出力する機能はPerlの根幹をなす部分といえます。もちろんそのもっとも原始的な形は二重引用符でくくられた文字列のなかにそのまま変数を埋め込むものです。 print "This report is created by $author."; もう少しこったことをしたければ、Cから受け継いだprintf系の構文を使えばよいでしょう。 printf "This report is created on %04d/%02d/%02d.", $year, $

    第40回 Text::MicroTemplate:得意分野なんだからPerlを使えばいいじゃない、という方に | gihyo.jp
  • 第25回 Module::Starter:モジュールを書くためのテンプレート | gihyo.jp

    モジュールを再利用可能にするためのツールたち Perl 4の時代まではいざ知らず、いまどきPerlのモジュールやアプリケーションを再配布しようと思ったら、CPANモジュールと同じ形式にしておくのがベタープラクティスです。たとえ一般には公開しない社外秘のモジュールであっても、Makefile.PLやBuild.PLを用意して、テストも書いて、できればREADMEやChangesなどの更新履歴もつけておけば、別のプロジェクトを立ち上げたときにコピー&ペーストする必要もなくなりますし、業務の引き継ぎなども簡単になります。 とはいえ、モジュールを書くたびにMakefile.PLなどを一から書きおこすのは面倒な話。メタ情報の部分はモジュールごとに異なるとはいえ、それ以外の部分は(特にひな形の時点では)大差ないのがふつうですから、できれば省力化したいところです。 今回はそんなときに使われるひな形作成ツ

    第25回 Module::Starter:モジュールを書くためのテンプレート | gihyo.jp
    jamadam
    jamadam 2011/02/04
  • Perl Hackers Hub:第5回 Xslate 次世代テンプレートエンジン(1)|gihyo.jp … 技術評論社

    連載では第一線のPerlハッカーが回替わりで執筆していきます。今回は藤吾郎さんで、テーマはXslateです。 はじめに PerlとWebアプリケーションとの相性の良さは周知のとおりです。そして、Web開発にはテンプレートエンジンが欠かせません。テンプレートエンジンは、プレゼンテーションとロジックを分離し、デザイナとプログラマの分業を可能にし、MVC(Model-View-Controller)のV(View)を担う重要な要素です。 今回は、そんなテンプレートエンジンンの一つであり、筆者が開発しているXslateを紹介します。Xslateは2010年4月に開発を始めた新しいモジュールですが、速度・安定性・機能ともに高い水準になってきました。また、牧大輔氏や松野徳大氏をはじめとしたShibuya.pmの面々に多くのアドバイスをいただき、既存のテンプレートエンジンを置き換えられるくらい実用的に

    Perl Hackers Hub:第5回 Xslate 次世代テンプレートエンジン(1)|gihyo.jp … 技術評論社
  • 第36回 SQL::Abstract:簡単なSQLはより簡単に | gihyo.jp

    DBIの泣き所 いわゆるLAMPないしそれに似た環境でウェブサービスばかり書いている方にはあまり実感がないかもしれませんが、あちらの現場ではOracleを、こちらの現場ではMicrosoft SQL Serverを、はたまた別の現場では組み込みのSQLiteを、といった受託系の仕事をしている人にとって、SQLの方言問題は避けては通れないもののひとつです。 典型的なところでは、たとえばSELECTで取得するデータの件数を制限したい場合、PostgreSQLなどでは「LIMIT ... OFFSET ...」のように書きますが、OracleではROWNUMを使いますし、MS SQL serverならSET ROWCOUNTやTOPを使います。また、いまでこそPostgreSQLとの互換性を確保するため「LIMIT ... OFFSET ...」と書けるようになっているMySQLにしたところで、

    第36回 SQL::Abstract:簡単なSQLはより簡単に | gihyo.jp
  • PSGI/Plack - [Perl Hackers Hub]

    連載では、第一線のPerlハッカーが回替わりで執筆していきます。記念すべき第1回は、WEB+DB PRESS誌ではVol.2から執筆しており、長らく連載も担当していた宮川達彦さんです。 はじめに PerlでWeb開発をするためのフレームワークは百花繚乱、人気を集めています。稿では、これらのフレームワークが共通して利用するためのインタフェース仕様であるPSGIと、そのエンジンとしての実装であるPlackを紹介します。 PSGIに至る道 PerlとWebアプリケーション開発の親和性 Perlは「インターネットのグルー(糊:のり)言語」とも言われ、CGIによる開発がメインだった1990年代から、Webアプリケーション開発に最も関わりのあるプログラミング言語の一つと言ってよいでしょう。2000年代に入っても、Ruby on RailsPHPなどの他言語からの影響も取り入れながら、Web開発

    PSGI/Plack - [Perl Hackers Hub]
  • 第30回 Test::Class:ユニットテストに使うだけでなく | gihyo.jp

    メタデータからテスト件数を取得する 前回はテストファイルやテストデータの数からテストプランを計算するモジュールを紹介しました。今回はその続きとして、テストファイルのメタデータからテストの数を求めるモジュールを紹介していきましょう。これらのモジュールの多くは1994年にケント・ベック(Kent Beck)氏がSmalltalk向けに書いたSUnitを祖先にもつ、いわゆるxUnit系のフレームワークに属するものですが、Perlにはそれ以前からTest Anything Protocolを使った独自のテスト手法が存在していたため、Javaなどで使われている同種のフレームワークとはやや毛色の違う部分もあります。一般的にはクラスをひとつ書くたびに対応するユニットテスト用のクラスを書くのがよいように言われていますが、ここではもっとゆるく、テストを自動的に検出してくれるだけでなく、テストの事前事後になん

    第30回 Test::Class:ユニットテストに使うだけでなく | gihyo.jp
  • 第2回 mro:次のメソッドはどこ? | gihyo.jp

    モダンなクラス/オブジェクトのあり方は? Perlではそもそもオブジェクトという考え方自体が、Perl 5(Perl 7歳)ではじめて登場した、後付けのものでした。また、その実装も非常におおらかなものだったため、より「格的な」オブジェクト機構を備えた言語のユーザからはしばしば批判されてきました。 ただし、転んでもただでは起きないのがPerlハッカーたちのよいところ。そのような批判を糧に、「⁠モダンPerl」の世界でもっとも激しく、多様に進化してきたのがこの分野です。 今回はそのようなクラス/オブジェクトの進化の一例として、クラスの継承とメソッドの解決順序にまつわる話題をまとめていきます。 継承によるクラスの拡張 伝統的なbaseプラグマを使ってクラスを拡張する場合、継承元と継承先に同名のメソッドがあれば継承先のメソッドだけが優先的に実行されます。 use strict; use warn

    第2回 mro:次のメソッドはどこ? | gihyo.jp
  • 第18回 local::lib:ふだんと違う環境でPerlを使う | gihyo.jp

    いつでも理想の環境を使えるとは限りません 「弘法筆を択ばず」ということわざもありますが、なんであれ手になじむまで使い込んだ道具を持っている人は、環境が変わってその道具が使えなくなるとやはりいらいらするものです。 Perlの場合もそう。日頃から自分の必要や興味に応じてがんがんCPANモジュールをインストールしていると、何らかの事情でまっさらに近いPerlを使わなければならなくなったとき、途方に暮れます。来のコードを書き始める前に、モジュールのインストールだけで一日潰してしまった経験をお持ちの方も少なくないことでしょう。 今回は、そんな「ふだんと違う」環境でもなるべくストレスなくPerlを使えるようにするためのモダンな努力をいくつか紹介してみます。 PERL5LIBという環境変数を活用する Perlはディストリビューションに同梱されているコアモジュールを保護するために、CPANからインストー

    第18回 local::lib:ふだんと違う環境でPerlを使う | gihyo.jp
  • 第17回 Padre:Perlで拡張できるコミュニティのための開発環境 | gihyo.jp

    Perlを入れたはいいものの ご存じのように、Perlには、簡単なコマンドであれば、いちいちスクリプトファイルを用意しなくてもコマンドライン上で実行できる-eというスイッチが用意されています。 > perl -e 'print "Hello, world!"' また、一行では収まらないような長さのスクリプトでも、使い捨てでよければ、perlコマンドをスクリプトファイルや-eスイッチなしで実行することで、コンソールからスクリプトを入力できるようになります。 > perl print "Hello, world!"; ^D とはいえ、まともにPerlを使おうと思ったら、何らかのテキストエディタが必要になります。Unix系の環境ではviとEmacsの系統がそれぞれ一大勢力を成していますが、Windows環境では、標準添付のメモ帳(notepad)があまりに貧弱なため、たいていの人は自分の好みのエ

    第17回 Padre:Perlで拡張できるコミュニティのための開発環境 | gihyo.jp
  • ソーシャルウェブテクノロジーに見る、Google Buzzの本当の意味 | gihyo.jp

    時間で2月10日午前3時。Googleがプレス向けのイベントを開催し、新たなプロダクト「Google Buzz」を発表しました。 事前の噂では、「⁠TwitterやFacebookに対抗することを目的とした、Gmailに追加される新たなソーシャル機能」と言われていましたが、Google Buzzは、Gmailが持つコンタクトリストをベースにし、Twitterを含めた各種ウェブサービスのフィードをアグリゲートするFriendFeedやCliqsetに近い、見た目としてはミニブログのようなサービスです。 図1 Google Buzz ウェブ上では既に「流行る・流行らない」「⁠Twitterに置き換わる・置き換わらない」といった評価が行われていますが、ソーシャルウェブのテクノロジーを追いかけてきた筆者には、サービスそのものを見ただけでは語り尽くせない、想像以上のコンセプトを持った意義深いもの

    ソーシャルウェブテクノロジーに見る、Google Buzzの本当の意味 | gihyo.jp
  • 1