<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>日曜研究室 〜技術的な日常〜 &#187; PHP</title>
	<atom:link href="http://peta.okechan.net/blog/archives/tag/php/feed" rel="self" type="application/rss+xml" />
	<link>http://peta.okechan.net/blog</link>
	<description>技術的な観点から日常を綴ります</description>
	<lastBuildDate>Sat, 24 Jul 2010 18:32:06 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>XREAのレンタル共用サーバーに設置したWordPressでメディアの一括削除ができない</title>
		<link>http://peta.okechan.net/blog/archives/664</link>
		<comments>http://peta.okechan.net/blog/archives/664#comments</comments>
		<pubDate>Fri, 03 Jul 2009 05:34:22 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[技術]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[WordPress]]></category>
		<category><![CDATA[XREA]]></category>

		<guid isPermaLink="false">http://peta.okechan.net/blog/archives/664</guid>
		<description><![CDATA[WordPressのバージョンは2.7.1です。 いつも書いてる通りXREAのサーバーはあまり触りたくないのですが、依頼なので仕方ありません。 XREAでWordPressを動かす場合、モジュール版PHPではパーミッションの関連上ファイル操作に難があり、普通に設置しただけではWordPressから画像などをアップロードすることが出来ません。（PHPのセーフモードがらみの問題で、仕様ですね） そこで、管理画面は（もしくはアップロード用スクリプトのみを）CGI版PHPで動かす設定を.htaccessで施すことによってその問題を回避する方法があります。 まぁココまでは&#8221;XREA WordPress&#8221;などで検索すれば幾らでも出てくる情報なんですが、その設定をやった上で、今回新たに「メディアライブラリの一覧で、個々のファイルの左にあるチェックボックスを複数チェックして、一括して削除しようとしたときに、サーバーからの応答が無くなる」という問題が発生しました。 応答がなくても、実際によく調べてみると、ファイルの削除もデータベースの操作も完了してるっぽかったので正確には「削除できてる」んですが、削除ボタン（実際には適用ボタンですか）を押してから、ブラウザが延々といわゆる「読み込み中」のまま、という状態です。 HTTPヘッダも何も返ってこない状態。 該当部分のソースを読んでみたり色々テストしていくと、削除処理をした後のリダイレクト処理部分で&#8221;wp_redirect&#8221;という関数が呼ばれており、どうもその関数が上手く動いてない様子でした。 ちなみにモジュール版なら&#8221;wp_redirect&#8221;関数自体は普通に動作します。 一括削除処理だけモジュール版で動作するようにしようかと一瞬思いましたが、そのwp_redirect関数を含むファイルって、upload.phpなんですよね。 つまりupload.phpに表示・追加・削除の機能が一つにまとめられてるので、htaccessのfilesディレクティブで切り替える方法が使えません。 とりあえず今回はwp_redirectを呼んでる行をコメントアウトして、 &#60;html&#62; &#60;header&#62; &#60;title&#62;wordpress redirect&#60;/title&#62; &#60;meta http-equiv=&#8221;Refresh&#8221; content=&#8221;0; URL=$location&#8221;&#62; &#60;/header&#62; &#60;body&#62; しばらくお待ち下さい。 &#60;/body&#62; &#60;/html&#62; という内容を返すようにしました。 文字化けるかもしれないのでもっとちゃんとしたソースを返すようにした方がいいです。 他にもwp_redirect関数を呼び出してる部分があったのですが、それらはちゃんと動いてるようでした（ホントかな）のでそのままです。 一応調査の中で、 header(&#8216;Location: http://example.com/&#8217;); などと一行だけ書いたスクリプトをCGI版で動かしてみたりしましたが普通に動きました。 まぁ、これが動かなかったら大問題になりますけど。 原因は複合的なんでしょうね。]]></description>
		<wfw:commentRss>http://peta.okechan.net/blog/archives/664/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>cal_days_in_monthが無い！</title>
		<link>http://peta.okechan.net/blog/archives/400</link>
		<comments>http://peta.okechan.net/blog/archives/400#comments</comments>
		<pubDate>Wed, 10 Sep 2008 05:23:32 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[技術]]></category>
		<category><![CDATA[cal_days_in_month]]></category>
		<category><![CDATA[PHP]]></category>

		<guid isPermaLink="false">http://peta.okechan.net/blog/archives/400</guid>
		<description><![CDATA[久しぶりにphpやりました。文法がcに似てるのであまり迷うことは無いですが、foreachやif ～ elseの書き方で一瞬止まります。inだったかなasだったかなとか、else ifだっけelseifだっけelsifだっけとか。基本的過ぎてググるのもちょっと難しいです。（多分、それ”だけ”を説明してるページは多くないでしょう。）まぁそういうときは、誰かが書いたソースを見ればすぐ分かるので問題ないですが。 それより、cal_days_in_monthです。暦の種類（グレゴリウス暦やユリウス暦など）と、年月を渡すと、その月の日数を得ることができる関数です。例えば、 cal_days_in_month(CAL_GREGORIAN, 2008, 9) とすれば、2008年9月の日数である30が返ってくるわけです。うるう年の場合なんかもよしなにやってくれるので便利なわけです。 この関数はphpの標準関数だと思っていたのですが、どうも明示的with-calenderオプションをつけてphpをコンパイルしてないと使えないらしいです。以前はそんなこと無かったような気がするのですが・・・yumとかaptとかrpmとかportsとかで入るものがどうかは知りません。 たまたま今回使ったxreaのサーバーでcal_days_in_monthが使えなかったのです。 何とかする方法がないかとちょっとだけ調べてみましたが、調べるよりもcal_days_in_monthを独自に実装する手間の方が少ない気がして作ってみました。 if(!function_exists(&#8220;cal_days_in_month&#8221;)){ function cal_days_in_month($calender, $month, $year){ $year = (int)$year; $month = (int)$month; $year = ($year &#60;= 100 &#038;&#38; $year &#62;= 0)?(($year &#60; 70)?($year+2000):($year+1900)):$year; $isLeap = (($year % 4 == 0) &#038;&#38; (($year % 100 != 0) &#124;&#124; ($year % 400 == 0))); $days_in_month = [...]]]></description>
		<wfw:commentRss>http://peta.okechan.net/blog/archives/400/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>セキュリティおよびPHPいじめｗの話</title>
		<link>http://peta.okechan.net/blog/archives/227</link>
		<comments>http://peta.okechan.net/blog/archives/227#comments</comments>
		<pubDate>Sat, 02 Feb 2008 02:56:52 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[技術]]></category>
		<category><![CDATA[セキュリティ]]></category>
		<category><![CDATA[Concurrent Clean]]></category>
		<category><![CDATA[PHP]]></category>

		<guid isPermaLink="false">http://peta.okechan.net/blog/archives/227</guid>
		<description><![CDATA[最近なんか多いですねぇ。セキュリティに絡んだPHPとそのユーザいじめ。 でもさぁ、僕はPHPもRubyもPerlもPythonもやるけど、どれも似たり寄ったりだと思いますけどねぇ。 確かにPHPは標準関数のネーミングとかに行き当たりばったり的なものを感じるし、文字コード周りの妙な自動化処理は気に食わないけど、それって、関数に別名つければいいし（そうするだけの価値があるなら）、文字コード周りのこともその回避策を知ってれば済むはず。 逆に言えば、妙な挙動が文字コード周りに限定されるから回避もしやすいけど、言語仕様レベルでクラスの妙な挙動を許しているPerlとか、そっちのほうが問題かと。 なので実際には、「PHPのhtmlspecialcharsはけしからん！」と言えるだけマシだと思うんですよ。だって、他の言語で書かれたhtmlspecialcharsよりもけしからん名もないhtmlspecialchars的な処理が現実にwebサービスとして動いてるほうが怖いですよ。（もちろんPHP vs その他という構図ではなくて。） 啓蒙しづらいし、修正方法も教えにくい。 ただ、僕がPHP好きで他が嫌いかといったらむしろ微妙に逆です。上に挙げた4つの中では微妙にPythonが一番ですけど、でもPHPをVB5に例えるなら、他はVB6くらいにしか見えません。つまりどんぐりの背比べ。 どの言語でも等しく選択する機会が与えられればPHPは使いませんが、世の中の共用レンタルサーバってmod_phpは入っててもmod_perlは入ってないし、RubyとPythonは実行環境すらないのが普通なので、どうしてもPHPになってしまいます。 自分の好きな言語のユーザを増やしたかったら、ネガキャンやって足引っ張ってないで、どんな鯖管でも真っ先に入れたくなるような共有環境でも問題のない「素性のいい」mod_なんとかを作れば良いんですよ。 話は少し変わるのですが、こことかここをみて、もやもや感が晴れた感じ。 やっぱりまずは作ってナンボの世界ですよ。もちろん最初から最後までセキュリティ糞食らえじゃダメだけれとも、少なくともセキュリティのことを考えるのは設計してプロトタイプを作った後にするべきです。 セキュリティって画一的にこうしておけば良いってもんじゃなく、個々の場合に応じて考えられるべきなので、その「個々の場合」ってのがはっきりしないうちから考えるのは時間の無駄です。 僕にも昔ありました、セキュリティやオブジェクト指向のことばかり考えて悦に浸ってるけど、実際は何も生み出してない時期が。 それは今考えるとまったくの無駄って訳じゃないけども、まるで好きな人に告白する場面を何百回もイメトレしたけど、100万分の1の確立のことにまで考えを巡らせすぎて行動を起こせなくて期を逃すみたいな。 先に行動すれば、結果が良くても悪くても得るものはあるのです。結果が良ければその結果自体を、結果が悪ければ「その方法はダメだった」という事実を得ることができます。 学ぶ者としては、そのほうが学ぶスピードが格段に速いと思います。 PS. Web系に限らなければConcurrent Clenが最高だと思います。他の言語はクソですよ。本気でそう思います。 しかしそう表明することにどれほどの公的な価値があるでしょうか？]]></description>
		<wfw:commentRss>http://peta.okechan.net/blog/archives/227/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>phpで作成したバッチ処理をwgetを使いcronで自動実行してみた</title>
		<link>http://peta.okechan.net/blog/archives/149</link>
		<comments>http://peta.okechan.net/blog/archives/149#comments</comments>
		<pubDate>Wed, 08 Aug 2007 07:30:43 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[技術]]></category>
		<category><![CDATA[cron]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[wget]]></category>

		<guid isPermaLink="false">http://peta.okechan.net/blog/archives/149</guid>
		<description><![CDATA[お恥ずかしい限りなのですが、実は今までcronで何かを自動実行したことがありませんでした。 apacheのログをlogrotate?rotatelog?(どっちだったっけ?)したことはありましたが人の猿真似でしかなく、cronはなんか設定ファイルをゴリゴリ書く必要があるというイメージがなぜかあって、敬遠していました。 この前作った、SEO遊びのためのサイトにもバッチ処理があったのですが、手動で(！)実行していました。もちろん何の考えもなく手動という面倒な方法をとっていたわけではなく、まだ肝となる処理が不安定で、バッチ処理も確実に実行されるという確信がもてなかったので、モニタリングも兼ねて手動にしていました。 しかし今日、妙に複雑だったDB回りから全体的に作り直し、コアとなる処理の安定度が上がった(気がする)ので、バッチ処理も気合をいれてメールでエラーを通知する処理を組み込んだりなんかして、自動実行しようじゃないかという機運が高まってきました。(自分の中で) ということで、cronを使って定期的にwgetでアクセスすれば自動実行できるんじゃないかと思い、設定してみました。wgetじゃ無くてcli版のphpで実行することも考えたのですが、確かうちのサーバではcli版とweb版でphp.iniの設定が違ってた気がするので、無難にwgetにしました。 サーバはCentOS4なので、実は「1時間毎、日次、週次、月次」に関してcronの設定は終わっています。つまりどういうことかと言うと、上記のタイミングで実行する場合は、特に設定ファイルの作成や変更は必要ありません。日次で処理したければ、実行可能ファイルを/etc/cron.dailyに放り込んでおけばいいだけです。 今回は1時間毎に処理したかったので、wgetの1行だけのシェルスクリプトを/etc/cron.hourlyに放り込んでおきました。内容は以下のとおりです。 #!/bin/sh wget -p /dev/null http://path.to/batch/file 週次なら/etc/cron.weeklyへ、月次なら/etc/cron.monthlyへ入れておけはOKです。 ということで、無事自動実行されるようになりました。 この程度なら特に設定をする必要もなく、意外と簡単でした。]]></description>
		<wfw:commentRss>http://peta.okechan.net/blog/archives/149/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Webセルオートマトン &#8211; ページの取得</title>
		<link>http://peta.okechan.net/blog/archives/147</link>
		<comments>http://peta.okechan.net/blog/archives/147#comments</comments>
		<pubDate>Mon, 06 Aug 2007 05:24:42 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[技術]]></category>
		<category><![CDATA[セルオートマトン]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[Yahoo! API]]></category>

		<guid isPermaLink="false">http://peta.okechan.net/blog/archives/147</guid>
		<description><![CDATA[Webセルオートマトンについては、これから製作記ということで連載していきます。 Webセルオートマトンの概要については昨日のエントリを見てもらうとして、肝となる技術を攻略することから始めたいと思います。 Webセルオートマトンでは、Yahoo!の検索APIと形態素解析APIを利用し、「Yahoo!検索→結果の1件目のページの本文を取得→その本文を形態素解析」という流れが核となる処理になります。 その中で、Yahoo!のAPIに関しては、この前作ったSEO遊びのためのサイトで実際に使ったので(検索機能だけですが)、問題なく可能だと思うのですが、URLから本文を取得する処理を実装したことが無いので、その方法を調べてみました。 「php url 本文取得」でググってみると、どうもPEARのHTTPClientを使うと良いようで。 早速テスト的に最小限のコードを書いてみました。 < ?php //テスト require_once "HTTP/Client.php"; $client =&#038; new HTTP_Client(); $client->get('http://peta.okechan.net/blog/'); $response = $client->currentResponse(); echo $response['body']; ?> 最初、require_onceでClient.phpが無いよというエラーが出たので、 #pear install HTTP_Client を実行してHTTPClientをインストールしたら、普通に使えるようになりました。 便利な世の中になったものです。 これでテストプログラムも動作するようになり、意外と今回のWebセルオートマトンは作るのが簡単なんじゃないかという気がしてきました。]]></description>
		<wfw:commentRss>http://peta.okechan.net/blog/archives/147/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>CakePHPでいきなり詰まった</title>
		<link>http://peta.okechan.net/blog/archives/97</link>
		<comments>http://peta.okechan.net/blog/archives/97#comments</comments>
		<pubDate>Wed, 11 Jul 2007 05:49:51 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[技術]]></category>
		<category><![CDATA[CakePHP]]></category>
		<category><![CDATA[PHP]]></category>

		<guid isPermaLink="false">http://peta.okechan.net/blog/archives/97</guid>
		<description><![CDATA[宿の予約システムを作ろうと思い、オープンソースなシステムを探してたのですが、どれもイマイチっぽい感じがしたので、フレームワークでも使って自分で作ろうと思い立ち、以前から気になってたCakePHPを使うことにしました。 以前からテストサーバとして、CentOS4なサーバにApache2とPHP5とMySQLを入れて使ってたので、準備するのはCakePHPのみで、10分で作るCakePHPアプリ アプリケーション編を見ながら作業しました。 作業も終わり、ブラウザでアクセスすると、403 Forbiddenのエラーが・・・ 原因は何だろうと思い調べてみると・・・ CakePHPはmod_rewriteを使うので、そのあたりかと思い、アプリケーションフォルダ内の.htaccessにRewriteBaseをつけてみたりしたのですが、一向に改善しませんでした。 そこで、apacheのログをみると Options FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden: /usr/local/apache2/～ といったエラーログが記録されていました。 とりあえずエラーメッセージのとおり、httpd.confの今回作ったディレクトリに対応する＜directory＞＜/directory＞の間で、Options Noneになってた部分をOptions FollowSymLinksに変更し、apacheを再起動したら、無事CakePHPが動作しました。 基本的なミスでお恥ずかしい限りです。]]></description>
		<wfw:commentRss>http://peta.okechan.net/blog/archives/97/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Smartyで文字列を省略する方法</title>
		<link>http://peta.okechan.net/blog/archives/59</link>
		<comments>http://peta.okechan.net/blog/archives/59#comments</comments>
		<pubDate>Fri, 08 Jun 2007 02:41:56 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[技術]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[Smarty]]></category>

		<guid isPermaLink="false">http://peta.okechan.net/blog/archives/59</guid>
		<description><![CDATA[仕事でWebアプリを開発する際に、テンプレートエンジンにSmartyを使ってるのですが、長い文字列を簡単に省略する方法(たとえば、&#8221;あいうえおかきくけこ&#8221;→&#8221;あいうえお&#8230;&#8221;みたいな)がないかなと調べてたら、ありました。 「truncate」っていう関数がSmartyには用意されていて、その関数で前述のような問題はバッチリ解決です。 truncate関数の定義は以下のとおりです。 function smarty_modifier_truncate($string, $length = 80, $etc = &#8216;&#8230;&#8217;, $break_words = false, $middle = false) $string は、切捨て対象の長い文字列 $length は、切捨て結果の文字列の長さ(省略記号含む) $etc は、切り捨てられた場合に使用される省略記号 $break_words は、英単語の途中で切り捨てるか否か(たぶん) $middle は、省略記号を文字列の末尾ではなく真ん中に入れるか否か ($middle=trueの場合、&#8221;あいうえおかきくけこ&#8221;→&#8221;あいう&#8230;けこ&#8221;になる。という予想) 正直、$break_wordsと$middleを変えたときの挙動は未確認です。 使い方はいたって簡単で、 {&#8216;長い文字列長い文字列長い文字列&#8217;&#124;truncate:10:&#8217;(ry&#8217;} で 長い文字列長い(ry という結果になります。 日本語が文字化けする場合は、 SMARTY_DIR/plugins/modifier.truncate.phpのstrlenとsubstrをmb_strlenとmb_substrにするといいっぽいです。]]></description>
		<wfw:commentRss>http://peta.okechan.net/blog/archives/59/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>遅ればせながら、FizzBuzz問題を解いてみた</title>
		<link>http://peta.okechan.net/blog/archives/37</link>
		<comments>http://peta.okechan.net/blog/archives/37#comments</comments>
		<pubDate>Wed, 16 May 2007 11:23:34 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[技術]]></category>
		<category><![CDATA[FizzBuzz]]></category>
		<category><![CDATA[PHP]]></category>

		<guid isPermaLink="false">http://peta.okechan.net/blog/archives/37</guid>
		<description><![CDATA[どうしてプログラマに・・・プログラムが書けないのか? この文章の内容は別段驚きではなく、 (予想以上だったってのはあるけど) 簡単なプログラムさえ書けないプログラマ&#8221;志望&#8221;が たくさん面接に来て大変だという話です。 簡単なプログラムの例として、 1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに｢Fizz｣と、5の倍数のときは｢Buzz｣とプリントし、3と5両方の倍数の場合には｢FizzBuzz｣とプリントすること。 という「FizzBuzz問題」と名づけられた問題があったので、 phpで書いてみました。 < ?php for($i=1;$i 人にひけらかすようなコードじゃないですｗ 大学でのプログラミングの授業で 僕のプログラマとしての人生は好転したと思います。 なるべく自分の頭で閃くのを促すような授業で 基本的なアルゴリズムを習いました。 パスカルでGCDを再帰を使って求める事を学んだその2時間後には、 再帰で迷路の最短経路を求めるプログラムを作成していました。 「FizzBuzz問題」を解かせるのもいいですが、 「Cmagazine(今もあるの？)の巻末のパズルを 1つでも解いたことがあるか？」って聞くのもいいかもしれません。 こういう簡単な問題でふるい分けするってことを もっと沢山の企業の採用面接などで実施してもらいたいものです。 それによって、プログラマの地位が向上するように なって欲しいです。]]></description>
		<wfw:commentRss>http://peta.okechan.net/blog/archives/37/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
