系図管理システム（仮）というものをSilex + SQLiteで作成していたんですが、SlimというSilex同様のREST APIを提供するマイクロフレームワークに書き換えてみました。 （SilexでもDoctrine2ではなくRedbean、TwigではなくPHPTALを使ってたので、フレームワークの利用範囲的にほぼ等価交換できるのではないかとの思いつきです） Slimの公式サイト http://www.slimframework.com/ には、Feature Listとして以下の項目が挙げられています。 HTTP routing Named routes Route passing Route redirects Route halting Middleware & Hooks Custom views HTTP caching Signed cookies Custom 404
ちょっと大げさなタイトルですが、あくまで私個人の環境構築手順をまとめたものです。WindowsからMacに乗り換えたばかりで、どうやってPHPの開発環境を整えるか分からないPHPerに向けの「開発環境を整えるためのガイド」と考えてください。 既にMacでAMP環境を構築したことがあるPHPerにとっても有用な情報を含めたつもりです。その例としては、php-buildとphp-versionで複数PHPバージョン環境の構築の手順、複数PHPバージョンとApacheの連携方法などがあります。 MacをUnix的に使えるようにするため、CUIで設定する手順を含んでいますが、怖がらずにやってみてください。ターミナルはあなたに噛み付いたりしません :) CUIに慣れてない方は、「難しい」と感じるかもしれませんが、きっとのちのちの財産になるはずです！ 2012年版では「PHPerがMacbookAir
PHPで画像処理といえば GD ImageMagick 辺りを使うのが一般的でしょうか。軽いノリで小さいアプリを実装する時はGDをが向いてると思います。 でもGDってなかなかクセがありませんか？何が違うのか分からない様な似た名前の関数があったり、半透明画像を扱う際は必ず呼ばないといけない関数があったり、テキストの描画が面倒、色の指定が面倒、など。 その辺のややこしい処理をラップして、よく使う機能を実装したライブラリ「DmImage」を作りました。 このライブラリを使うと色々出来ますが、 画像リサイズ ファイル出力 DataSchemeURI変換 ActionScriptやCanvasAPIの様な図形描画、色指定 Instagram風の画像加工 フォントのバンドルによる綺麗なフォント描画 辺りが特徴になるかと思っています。 では、早速使い方の説明です。 使い方 使い方1 〜 画像の表示 サイ
レガシーコードと戦っていると、「このコードのどこをどう通ってこういう結果になってしまっているのか」がわからなくなることがあります。 初見でコードを理解する能力は、コードを読んできた経験が多ければ多いほど、向上するものだと思います。 とは言っても、構造化やモジュール化が適切でなく、スコープの長大なコードなどは、人間の限界を超えているものもあるでしょう。 ステップ実行のできる IDE などを使う、という選択もあると思いますが、僕は重厚な IDE を好みません。 もっと楽にできる方法で、コードパスを解析する方法があれば、ということで作ってみました。 yuya-takeyama/code_path_analyzer 元になっているのは、仕事の時にコード中にベタ書きした関数です。 Gist に公開したところはてブが 10 ぐらい付いたのと、次必要になったときにすぐ使えるようにしておきたかったので、ラ
安藤です。下北沢オープンソースカフェで隔週火曜日に開催されているPHPのコミュニティ、Shimokita.phpでPHPのエラーに関するセッションを行いました。実際の開発やプロダクトのセットアップ時に目にする事の多いエラーですが、その種類や対処方法についてじっくり考える機会は意外と少ないのではないでしょうか。 今回のセッションでは下記のような点を紹介しています。 各種エラーの種類と原因 FatalやNoticeなど一見するとちょっとした違いに見えますが、残りの処理が実行されるかどうかや発生原因は大きく異なります。 エラーに関する設定項目 エラーメッセージが画面に表示されるかログに記録されるかといった挙動は設定によって異なります。正しい設定が行われていないと不適切な情報がユーザに表示されたり、運用環境で障害が発生している事に気が付かないといった問題があります。開発環境と運用環境に適切な設
昨日の ParallelHttp の話に引き続き、PHP でのバッチ処理のパフォーマンス改善の話です。 あと、昨日と同じく PHP 5.2 で使えるライブラリを開発した話でもあります。 バルクインサートとは ひとことで言えば「複数のレコードをまとめてインサートすること」です。 例えば MySQL で言えば、 INSERT INTO `users` (`name`) VALUES ('foo'); INSERT INTO `users` (`name`) VALUES ('bar'); INSERT INTO `users` (`name`) VALUES ('baz'); ではなく INSERT INTO `users` (`name`) VALUES ('foo'), ('bar'), ('baz'); というようにやることです。 これで何が嬉しいかというと、サーバにクエリを投げてその結
最近は Admiral Sir Cloudesley Shovell というバンドの 1st フルアルバム Don't Hear It... Feat It をよく聴いています。 Sir Lord Baltimore のような、骨太なリフと、ブルージーでドラマ性もある楽曲が魅力のバンドですが、現在進行形で活動中のバンドです。 ストーナーロックとか好きな人は是非。 ここから本題です。 あるところに、Web API を数十万回単位で叩きまくる、PHP で書かれたバッチプログラムがあったとしましょう。 処理件数が増えるごとに処理時間が増大するので、いつしか 1 日経っても終わらないようになってしまいました。 そのプログラムは HTTP リクエストを直列に行っていたので、それを並列化させれば何とかなるのではないか、と考えて作ったのが以下のライブラリ。 yuya-takeyama/parallel_
パラレルクエリの流れを確認する 「第1回：DBは習うより慣れよ！」（http://www.thinkit.co.jp/article/97/1/）では、サンプルコードにより簡単なパラレルクエリを体験していただきました。これを以下の流れに沿って、簡単におさらいしていきます。 1.あらかじめデータを細切れにする 2.処理を分割 3.手分けして同時に処理' 4.結果をまとめる 「1.あらかじめデータを細切れにする」は、サンプルのデータベースを作る段階で行っています。 サンプルでは、test0というテーブルをtest1とtest2に2分割しています。実際には、test1とtest2を作成してから、この2つをマージしてtest0を作りましたので、上記の流れとは順番が逆ですね。 このように、データを細切れにする実際の作業は、「先に全体像があって、それを細切れにする」のではなく、パラレルクエリを念頭に置
0.1を10回足してみた。 PHPの場合 PHPでの結果、１ //——————————————————————————– JavaScriptの場合 JavaScriptでの結果、 0.9999999999999999 //——————————————————————————– Python(Ver2.7)の場合 Pythonでの結果、0.9999999999999999 //——————————————————————————– Rubyの場合 Rubyでの結果、1.0 //——————————————————————————– Haskellの場合 Haskellでの結果0.9999999999999999 //——————————————————————————– 結論、PHPは神、その次、Ruby
AWS SDK for PHPには、DynamoDBSessionHandlerというセッションを管理するクラスがあるので、比較的楽に導入が可能。 Amazon Linuxでの環境設定 パッケージインストール(DynamoDBアクセス用のCacheとしてAPCも入れる) $ sudo yum install php php-pear php-xml httpd php-pecl-apc $ sudo pear channel-discover pear.amazonwebservices.com $ sudo pear install aws/sdk 次に、セッション管理ハンドラーを用意 $ sudo vi /var/www/html/dynamosessions.php $ sudo cat /var/www/html/dynamosessions.php <?php date_defa
PHPカンファレンス2012 | 日本最大のPHPの祭典 先日 9/15 に行われた PHP カンファレンスで、Git と Pull Request をつかったチーム開発について、発表をしてきました。 資料と補足 まず、発表資料です。 あらためてメインの主張をすると、「Git に移行する」というのは、「svn のコマンドに対応する git のコマンドを覚えること」や、「GitHub Enterprise を導入したら完了」するものではなく、Git を利用した最も効率的な、開発フローや業務フローを考え、チーム開発・運用に適用すること、です。 9/19 時点で、また Speaker Deck の embed が使えなくなっているのでリンクもおいておきます (そのうち対応してくれ、ということで↑は放置) Presentation Not Found // Speaker Deck あと補足っぽい
先週10/12の金曜に行われたPHP関西の勉強会に行ってきました（というかお手伝い＆LTしてきた）のでエントリに落としておきます。 会場提供してきました 今回で４回目くらいでしょうか。勉強会の会場設営もだいぶスムーズに出来るようになって来ました。今回は都合で少しつめつめのセッティングです。 発表メモ：今回はust係に集中してたので少し見れてない部分も多かったのですが。 @shin1x1さん 今時のCakePHP ちなみに自分はCakeは軽く触っただけなんですが、modelが配列じゃなくオブジェクトを返します！って発表時の会場のどよめき、一体感はすごかったなと思いました。 書籍も好評発売中でサインを求める人がわらわらとｗ @slywalkerさん CakePHPの移行ガイド 内容はCakeの人じゃないのでともかく、スライド面白すぎて吹いたｗこんなプレゼンが出来る人になりたいです。 @okon
PHP Error | error reporting for PHP PHPのエラー画面をリッチにしてくれるライブラリ「PHP Error」。 エラーが発生した際に、何行目がエラーというだけではなく、コードのこの部分がおかしいというところを示してくれ、更にコードのシンタックスハイライト機能などがついている模様。 エラーの行だけではなく、スタックトレースしてくれてコードをさかのぼって閲覧が可能。 それにしてもPHPという言語は年々進化しているわけですが、こういったところも標準でも、もうちょっと進化してもよいのかもと思いました。 関連エントリ Twitter風にエラーや通知をページ上部に表示させるjQueryプラグイン 簡単に使えるクールなPHP用デバッグコンソールライブラリ「PHP Bug Lost」
こんにちは、chatiiです。ちょっとまじめに記事書きます。 FuelPHPでけっこう（chatiiとしては）規模の大きい案件がきたので、開発環境をキチっと決めたいと思いました。その中で、今まで手作業でやりつつ、「これ自動化できるだろ」っていうところがあり、今回うまくいったのでご紹介。ちなみに、今回はFuelPHPは関係ないです。 開発会社さんから見たら普通のことなんだろうなぁ。野良プログラマーPHPerだからせけんしらず。 環境・条件 ソースコード管理はGitHub ひとりなのに！ひとりなのに！ LAMP構成 開発マシンにはXAMPP/MAMPを入れる。Linuxの場合はyum/aptで取得。 サーバーは 本番サーバー（www.hoge.com） テストサーバー （hoge.dev.example.com） テストサーバーは他人がアクセスできないようにね 他のプロジェクトもテストします
PHPWebSocket ChatはPHP製のWebSocketサーバによるチャットデモです。 WebSocketというとnode.jsというイメージがありますが、実際はそんなことはありません。他の言語だってWebSocketサーバになりえます。今回はPHPで作られたPHPWebSocket Chatを紹介します。 接続しました。 発言しました。 こちらはサーバ側。 PHPWebSocket ChatはHTMLファイルのチャット画面とPHP製のサーバスクリプトになっています。サーバをPHPコマンドで実行すれば後はHTMLを表示させるだけでチャットができる仕組みです。PHPプログラマーにとってはより手軽にWebSocketが使えるようになるのではないでしょうか。なおソースに最大接続数は100と設定されています。 PHPWebSocket ChatはPHP製のソフトウェア（ソースコードは公開さ
MacでHomebrewを使ってPHPの開発環境を作るまとめです。 HomebrewはMacPortsより圧倒的にコンパクトなのがメリットです。MacPortsでPHPをインストールすると、/opt/localに、Apacheを含め、すごい量のパッケージをインストールされます。PHPのビルドにApacheのライブラリが必要で、さらに、Apacheのビルドには...という具合。これだと、容量あたりの単価がかかるSSD搭載のMac bookがかわいそうですね。HomebrewのPHPは、MacOSにApacheがあるのを知っているので、依存が浅くて軽いです。 MAMP.appがあるじゃないかという人はちょっと待った。あのパッケージ構造、httpd.confとphp.iniとmy.iniがどこにあるかすごくわかりにくいんですよね。そのうえ、使っている拡張の最新バージョン追従が個別にできないのは辛
This document discusses using Nginx as a web server with PHP. It provides configuration examples for using Nginx with PHP-FPM to pass PHP requests. Benchmarks show Nginx performs better than Apache. It also discusses using Nginx as a reverse proxy cache, and provides configuration examples to cache content and pass caching controls from PHP.Read less
Editor's Notes\n\n\n\n\n&#x30E6;&#x30CB;&#x30C3;&#x30C8;&#x30C6;&#x30B9;&#x30C8;&#x306E;&#x8AAC;&#x660E;&#x306B;&#x524D;&#x306B;&#x672C;&#x8B1B;&#x7FA9;&#x3067;&#x591A;&#x7528;&#x3055;&#x308C;&#x308B;&#x30AA;&#x30D6;&#x30B8;&#x30A7;&#x30AF;&#x30C8;&#x6307;&#x5411;&#x3068;&
PHP Conference 2012で知ったのですが、PHP5.5にはfinallyが搭載される見込みだそうです。 搭載されるのはいいのですが、昔、「PHPにfinallyはないけどデストラクタがあるよ」と題してfinally不要説を書いたことがあるので、もう少し考察を行ってみたいと思います。自分で自分に反論を書いてるのもアレなんですけど。 ※RFCは追いかけてなかったので、本記事は想像で書いています。ツッコミください。 finally不要説 私が主張した内容を要約するとこんな感じです。 finallyの主な用途はファイルのクローズやDBの接続断などの「後始末処理」である。 後始末はデストラクタで行うこともできる。 PHPではデストラクタの動作が保障されている。（参照カウントによるGC） ゆえにデストラクタを正しく使えばfinallyは不要。 具体例を出すと、finallyのRFCでは例
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
