ドメイン駆動設計という救世主 - PHPでデータベースを扱う(2)
Userテーブルに対してデータをinsertするメソッドを考えます。愚直なこんなインターフェースはどうでしょうか？ class UserMapper { //... function insert( $nickname, $password, $firstname, $lastname, $birthday ) { //... } } …この引数を覚えていられる人はそう多くないと思います。もしプログラムを間違えて、nicknameとfirstnameを逆に指定してしまったら、本名がnicknameとして登録されてしまいます。本名が誤って表示されてしまうという致命的な事故につながります。危なっかしいプログラムですね。 では、順番を考慮しなくていいように連想配列にすればどうでしょうか？ class UserMapper { //... function insert(array $data)
PHP5.5で強化されたcURL拡張でHTTP Pipeliningを試す
先日、PHP5.5.0がリリースされましたね。さっそくビルドしてニヨニヨしているところです。 5.5の新機能と言えばGeneratorやfinallyなどですが、個人的に注目しているのがcURLの機能強化です。詳しい内容がまだ公式ドキュメントに書かれていないのですが、結構おもしろいので紹介してみます。 cURLとは何か かーると発音する人が多いようです。C言語で書かれたHTTPのclientライブラリであり、WebAPIやスクレイピング、クローラなどを扱うときに非常に便利です。PHP版のバインディングは標準でPHP本体にバンドルされているため、大抵のレンタルサーバーでも使えるようになっています。 ただ、オリジナルのlibcurlそのままの関数風インターフェースを踏襲しており、オブジェクト指向型のラッパーなどは用意されていないため、あまり使いやすくはありません。が、並列リクエストが可能であっ
URLで遊ぼう
と、いうタイトルで、LTをしてきました。(第62回PHP勉強会) 眠いので補足はあとで書きます あ、会場を提供していただいた株式会社VOYAGE GROUP様、いつもお世話になっております。水どころかお茶やビールまで飲めるなんてすばらしいですね！！ そして今回はEngine Yard様のおかげでタダピザにありつくことができました。一飯の恩は忘れませぬ。
protectedを乱用してパッケージメンバを作る
PHPではprivateと宣言したプロパティ、メソッドは、同じクラスのインスタンスであれば相互にアクセスできます。あまり意識することはないですが、たまにぎょっとすることになります。 <?php class Klass { private $data; function __construct($init) { $this->data = $init; } function get(self $o) { return $o->data; } } $a = new Klass('a instance'); $b = new Klass('b instance'); //echo $a->data; //これはエラーになる echo $b->get($a); //a instance //$bが$aのprivateメンバを読めた これはprotectedの場合でも同様であり、しかも継承したクラス
XMLとJSONの話(1) データフォーマットとしての比較
XMLとJSONの相互変換を行うライブラリはいくつかありますが、完璧なものはどこにもありません。そもそもフォーマットに互換性がないからです。 XML_Builderを作る中でXMLとJSONを比較したのですが、一旦まとめておこうと思います。 XMLは文書の電子化に源流があります。そのため長いテキストをベースに何か情報を付加していくのには非常に便利なフォーマットです。反面、含めることができるのはテキストのみで、integerやboolean、nullといった基本的な型は存在しませんし、バイナリデータを含めることもできません。(BASE64でエンコードするなどの工夫が必要です) 例えば、以下のような文章があった時、 PHPはPHP: Hypertext Preprocessorの略で、プログラミング言語の一種である。 リンクを張るなど、文章の一部にメタ情報を付与し、 <dfn id="php"
それでもPHPにfinallyが必要な理由
PHP Conference 2012で知ったのですが、PHP5.5にはfinallyが搭載される見込みだそうです。 搭載されるのはいいのですが、昔、「PHPにfinallyはないけどデストラクタがあるよ」と題してfinally不要説を書いたことがあるので、もう少し考察を行ってみたいと思います。自分で自分に反論を書いてるのもアレなんですけど。 ※RFCは追いかけてなかったので、本記事は想像で書いています。ツッコミください。 finally不要説 私が主張した内容を要約するとこんな感じです。 finallyの主な用途はファイルのクローズやDBの接続断などの「後始末処理」である。 後始末はデストラクタで行うこともできる。 PHPではデストラクタの動作が保障されている。（参照カウントによるGC） ゆえにデストラクタを正しく使えばfinallyは不要。 具体例を出すと、finallyのRFCでは例
GitHub markdown APIで遊ぶよ
markdownといえば各種言語に実装されていますが、GitHubがWeb API形式で変換ツールを出しているようなので遊んでみました。このAPIを通すと、markdownテキストがHTMLに変換されます。 JSONPで使える奴と、RESTっぽくmarkdownなテキスト自体をPOSTするとHTMLの断片が返ってくるraw APIの2つがあります。 利用上限は一時間あたり5000回と太っ腹。 とりあえず、PHP版：http://tojiru.net/markdown.php <?php if (isset($_POST['markdown'])) { $origin = $_POST['markdown']; $ch = curl_init('https://api.github.com/markdown/raw'); curl_setopt($ch, CURLOPT_RETURNTRAN
PDOの真の力を開放する - PHPでデータベースを扱う(3)
ちょっと遅れましたが、シリーズの第３回です。前回までに論じた内容をふまえて、簡単な実装を示します。↓前回までの内容はこちら。 DAOの悪夢 - PHPでデータベースを扱う(1) - 泥のように ドメイン駆動設計という救世主 - PHPでデータベースを扱う(2) - 泥のように 題材 「記事にタグを設定できるブログ」みたいなシステムを考えてみます。ブログ記事を示すEntryテーブル、タグを表すTagテーブルの二つを用意しました。MySQL WorkbenchによるER図(鳥足記法)は以下になります。 1つのEntryに対して複数のTagがある、１対多の関係です。同じTagが複数のEntryに関連するため、多対多の関係と見なすこともできそうですが、タグ程度だとあまり意味がないので、これ以上のテーブル分割はやめておきます。 Entryテーブルの主キーがentryIdと冗長な名前をしているのは、自
DAOの悪夢 - PHPでデータベースを扱う(1)
最近、昔の自分が書いたコードをメンテしているのですが、何というか、「ええい、誰じゃこのコードを書いたのは！！」と叫んでは「…4年前の俺でした…」とセルフツッコミを繰り返しています。すごく読みにくいコードで、ストレスたまりまくりです。そのため、「今ならどう書くか」をよく考えました。ちょっと長くなるかもしれませんが、アンチパターンとして解説したいと思います。 DAOパターンについて 私が鬱々としてメンテしているコードですが、データベースとのやり取りを行うためのクラスです。当時意識していませんでしたが、改めて見ているとDAOパターンを再現しているものでした。 DAO(Data Access Object)とはデザインパターンの一種で、データベースへのアクセスロジックを集約したクラスのことです。有名なGang of Fourによる23種の基本デザインパターンには直接含まれていませんが、Facade
PHPとgoto文 (PHP Advent Calendar 2011 24日目)
PHP Advent Calendar 2011の24日目です。 前日はbornknow108さんのPHPでIPMessangerでした。 何を書いてもいいとのことなので、PHPの黒歴史ことgoto文についてまとめてみます。 goto文とは goto文は、プログラム中の任意の位置にジャンプする構文です。処理を先に進めたり、戻ったりすることができます。 echo 1; goto third; echo 2; third: echo 3; //→13と表示され、2は表示されない gotoはとても低レベルな命令であり、これとif文さえあればほとんどの論理構造は書けてしまいます。要は強力すぎるため、gotoを多用して書くと大変読みにくいプログラムができあがります。 この件はDijkstra先生の論文「Go To Statement Considered Harmful」で有名になりました。プログラ
素のPHPをテンプレートエンジンとして使うときのコーディング規約
プログラムとしてPHPを書くときのコーディング規約は、PEARやZendなど代表的なものがたくさんありますが、テンプレートエンジンとしてPHPを使う場合にはそのまま適用しにくいものです。 テンプレートエンジンのコーディング規約って、検索してもあまり見つからなかったので、個人的に採用しているものを晒してみます。あんまり語る人を見たことがないので、「俺はこうしてるよ」とか「ここキモくね？」とかご意見いただけるとうれしいです。 目指すところ 複雑なロジックをテンプレートに書かない / 書けないように規約で縛る 少しでも読みやすさを追求する できあがりのHTMLの美しさも追及する <%= $this->doctype() %> <html> <head> <%= $this->headMeta() %> <%= $this->headLink() %> <%= $this->headTitle()
newを封印するべき4つの理由
ちょっと勢いに任せて書いちゃったので攻撃的な文章になってます。。 すごくわかりやすい解説記事を頂いたので、こちらも必読です。 new を不当に貶める陰謀と JavaScript におけるクラスの継承構造の話 - vivid memo (追記：2011/5/15) 前の記事「newを封印して、JavaScriptでオブジェクト指向する」が思いのほか反響が大きかったので、調子に乗って補足を書いてみますよ。 ブコメへの返信 「無用な複雑化に見える。」「俺俺オブジェクト指向な気がする。」といったご意見もいただいたんですが、普通たった１０行の関数でオレオレオブジェクト指向なんて作れないですよ…。JavaScriptの内部機構をほとんどそのまま使っているからこそ、この行数で済むのです。 それに、このプロトタイプ的継承の考え方をDouglas Crockfordが編み出したのは、もう５年も前の話です。E
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
