先日の記事「PHPのジェネレータの実装を調べてみた」で僕は次のように書きました。 GeneratorクラスはIteratorインターフェースを実装しており、対応するPHPメソッドを持っています。また、Cで実装した場合のみ指定できるイテレータ関数も実装しています。このように両方が指定されている場合、foreachループではCの関数が呼ばれ、イテレータメソッドを明示的に指定した場合はPHPメソッドの方が呼ばれます。 ところで、イテレータに対応するPHPメソッドとC関数となぜ2つとも実装する必要があるのでしょうか。実は、PHPメソッドの方だけ実装すれば正常に動作します。C関数を実装する理由は速度面のメリットからだというのが僕の理解です。C関数は関数ポインタで単に呼び出せるのに対し、PHPメソッドの呼び出しは命令実行器の状態保存・復元の必要があるなど、呼び出しのコストがやや高いのです。 PHPのジ
PHPは最近の他の言語とは違ってシングルスレッドなので、一回のリクエストで複数の処理を同時に実行したりといったことは通常はできません。 非同期処理はできず、常に上から順に処理を進めていきます。 どうしてもやりたいなら`php hoge.php &`などと別プロセスで動かすといった手段しかありませんでした。 http://d.hatena.ne.jp/milktea_cg7/20130529/1369821459 ところでなにやらpthreadsとかいうモジュールを見つけたので使ってみます。 http://www.php.net/manual/ja/book.pthreads.php LinuxであればPECLからインストールしましょう。 Windowsではバイナリが落ちてたので拾ってきます。 http://pecl.php.net/package/pthreads https://gith
Dependency InjectionがPHPでも流行っているそうです。が、未だによくわからないので、わからないところを自分なりに考察してみます。 ※DIコンテナではなくデザインパターンとしてのDIを考えます。 Dependency Injectionとは Dependency Injectionはデザインパターンの一種です。日本語なら依存性の注入と訳されます。「Inversion of Control コンテナと Dependency Injection パターン」が原典でしょうか。 ざっくり要約すると「クラスの中でnewしてはいけない。必要なインスタンスは外から突っ込むべし」というところかな。 class Y { private $x; function __construct() { $this->x = new X; } //...$xを使ったコード色々... } 上記のYクラス
昨日のブログエントリ「PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)」にて、crypt関数の重大な脆弱性について報告しました。脆弱性の出方が近年まれに見るほどのものだったので、twitterやブクマなどを見ても、「どうしてこうなった」という疑問を多数目にしました。 そこで、このエントリでは、この脆弱性がどのように混入したのかを追ってみたいと思います。 PHPのレポジトリのログや公開されているソースの状況から、PHP5.3.7RC4までこのバグはなく、PHP5.3.7RC5でこのバグが混入した模様です。RC5はPHP5.3.7最後のRelease Candidateですから、まさに正式リリースの直前でバグが入ったことになります。 バグの入る直前のソースは、ここの関数php_md5_crypt_rから参照することができます。以下に、おおまかな流れを図示します。まずはバ
補足(2010/08/24 15:00)：rename関数について言えば、同一ファイルシステム上であればrenameシステムコールを利用するのでこの問題は起こりません。さらに蛇足ですが、ファイルシステムをまたがってrename関数を利用するとコピーしてから削除することになり、アトミック性を保証できないため、障害の原因にならないかどうかの検討が必要だと思います。 「AKIBA de: PHPのrename()関数はファイルシステム間で使うとメモリをバカ食いする」で指摘されている通り、PHPのcopy関数やファイルシステムをまたがってrename関数を使う場合に、PHPがファイルサイズと同じ大きさのメモリを消費してしまいます。環境によっては再現しないかもしれませんが、僕の手元のMacOSX 10.5+PHP5.3.3環境では再現しました。 <?php // 「dd if=/dev/urando
アカウント情報を管理するコマンド pit – 冬通りに消え行く制服ガールは、夢物語にリアルを求めない。 – subtechを見て，「あ，こういうのあるとサーバ中に散らかってるアカウント情報がまとめられていいなぁ」と思い，ぺちぺ版を作成． https://github.com/ha1t/php-Pit 1ファイルしかないけどPEARパッケージにした．あとspycに依存しているので一緒にインストールしないと動きません．デフォでYAML使えるRubyはいいよなー． 今回のコードはRubyで美しくかかれているものをPHPで書きなおすとこんなに泥臭くなるというお手本のような感じになりました． tempfile system(popen) to_yaml(YAMLLoad) あたりにライブラリの使い易さの差が見えておもしろいです． たいしてRuby読めない人が友人に聞いて回って実装したので実装漏れがた
こんにちは、小川です。たまには文句でも書いてみます。 先日ふと「スパイシーチキン」という単語を聞いて、昔のアシアルブログを思い出しました。 スパイシーチキンという単語を便りに検索をしてみると、スパイシーチキンの絶頂期は2006年から2007年の初めごろ。 僕は2006年の12月18日にアシアルにアルバイトとして入社したため、スパイシーチキン時代のアシアルを知っています。 むしろ、スパイシーチキンがあったからこそアシアルに入社したといっても過言ではありません。 しかし、今はどうでしょう。日常が垣間見えるのは、おおよそ月に1度投稿される阿部さんのブログくらい・・・。 symfonyの話しかしない人もいるし。そんなだからいつまでたっても彼女ができないんですよ！ ああ、、、あの頃のアシアルブログはどこへいってしまったのでしょうか。 やはりここはアシアルブログ再建のためにも、再度スパイシーチキンに登
Getting Started Introduction A simple tutorial Language Reference Basic syntax Types Variables Constants Expressions Operators Control Structures Functions Classes and Objects Namespaces Enumerations Errors Exceptions Fibers Generators Attributes References Explained Predefined Variables Predefined Exceptions Predefined Interfaces and Classes Predefined Attributes Context options and parameters Su
はてブコメントにて、「シリーズ化して欲しい」とあったので、もう少し書いてみます。 今回紹介するパターンは、Controllerパターン。 たぶん、デザパタ(GoFとかのヤツ)ではControllerパターンなんてものは存在しないのですが、よく見掛けるパターンなので紹介します。 よくあるControllerパターンは、FrontControllerパターンを使ったデータ遷移パターンですが、今回僕が紹介するパターンはCommandController(これもGoFとかのパターンにたぶん無いので勝手に命名)です。 何か実行したいCommandについて、Controllerが適切に実装を振り分けその後のActionを実行するためのパターンです。 よくある実装 例えば、以下にCommandインタフェースを実装した複数のクラスがあり、そのCommandによって、実行するActionを振り分けるCo
ITT-WEB - XOOPSCubeにおけるDelegateとは何か？というエントリが上がっているので、ちょっとだけDelegateについて触れてみたいです。 Delegateとは、そのままの意味で「委譲」を示します。(集約ではないです) とある処理をそれまで行っていたクラスから、ちがうクラスに対して処理を行ってもらうようにします。 Delegateと書くとちょっと堅苦しいですが、proxyやTemplate Methodに近い存在です。 Delegateは慣れてくると色々なパターンに適用しやすい便利なパターンなので、是非身に着けたいものです。 以下にファイルのデータを書き込む処理の例を示します。 class DataWriter { public function write(Data $data){ $file = new File($data->getPath()); if(
CakePHPを使ったMVC設計のベストプラクティス 個人的にはCakePHPはあまり好きではないのですが、CakePHP開発メンバーによるMVCデザインの記事 (CakePHP のおいしい食べ方)で紹介されていたBest Practices in MVC Design with CakePHP (php|architect’s C7Y)はMVCフレームワーク利用者にとってとても有用な情報だったので、訳してみました(php|architectの方には翻訳許可を頂いています)。 この記事を読んでドメインモデルに興味を持った方は、エンタープライズ アプリケーションアーキテクチャパターン(PoEAA)やDomain-Driven Design: Tackling Complexity in the Heart of Softwareに手を出してみるのもいいかも。他に、InfoQにユーザー登録すれ
このドキュメントは、Zend Framework に貢献してくださる開発者個人 (あるいはチーム) のためにコードの書式やドキュメント作成の指針を示すものです。 Zend Framework を用いて開発をする人たちにとってもこのコーディング規約は有用でしょう。 これに従えば、Zend Framework のコードとの一貫性が保てるからです。 そのためには、ここで完全なコーディング規約を示す必要があります。 注意: 詳細なレベルまでの設計指針を示すこと以上に、 それを標準規格として確立することが大切だと考えています。 Zend Framework コーディング規約の指針は、 これまで ZF プロジェクトでうまく回っていた方針をまとめたものです。 このライセンスのもとで、 そのまま使用するなり多少変更して使用するなりすることができます。 ZF コーディング規約では、次のような内容を扱います。
2008-10-05 製作著作 © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 ： The PEAR Documentation Group 目次はじめにこのマニュアルについてこのマニュアルの構成著者・訳者についてIPEAR について1 章 はじめに2 章 サポート3 章 標準コーディング規約4 章 PEAR2 コーディング規約5 章 PEAR2 Policies6 章 貢献7 章 FAQ - 頻出する質問8 章 Constitution9 章 PEAR グループの管理文書IIユーザーズガイド10 章 インストール11 章 コマンドラインのインストーラIIIメンテナ入門12 章 はじめに13 章 PEAR に貢献するための方法14 章 PEAR コミュニティーへの参加15 章 公式投稿採択プロセス16 章 メンテナンスされていないパッケージ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く