http://php.pcoach.jp/ PHPアカデミー ja Nucleus CMS v3.24 ｩ Weblog http://backend.userland.com/rss http://php.pcoach.jp/images/php/logo.gif http://php.pcoach.jp/ http://php.pcoach.jp//item/3669 http://php.pcoach.jp//item/3669 http://blog.shibu.jp/article/28983162.html

A:きれいな設計
一次創造　二次創造というアプローチで解決説明できます。

世の中のモノや行動には一次創造と二次創造によって説明できます。
一次創造とは、「チャーハン作ろう」とか「字を書こう」とかプランを作成すること。
二次創造とは、「フライパンに油を引くこと」とか「字を書いているとき」といった実行すること。PLAN-DO-SEEフレームワークで言う、PLANとDOです。


テーマとなるソースコードは、プログラムを書くという一次創造による二次創造の結果です。二次創造によってできたソースコードが綺麗に書かれているためにはその一次創造である設計がきれいでなくてはなりません。

要は、こうなる。
きれいなPLAN -> きれいなDO -> きれいなPLAN -> きれいなDO -> きれいなソースコード

大本となるビジネスプランが綺麗であり、その次の要件定義や設計が綺麗であり、それを綺麗に実装すれば綺麗なソースコードができあがると思います。]]> General http://php.pcoach.jp/index.php?itemid=3669 Thu, 14 May 2009 16:15:40 +0900 http://php.pcoach.jp//item/2726 http://php.pcoach.jp//item/2726
詳細はこちら：http://jp.php.net/error_reporting

今回は、E_NOTICEのエラーレベルを出力するか否かについて議論したいです。
E_NOTICEはすごい細かい情報を出してくれて、バグの混入リスクを下げる利点があるのに対し、PHPの利点でもあるコードの柔軟性（適当なコードでも動く）が失われてしまい、開発スピードが低下したり、コードが見づらくなってしまいます。

では、周りではどうなっているかを調査してみます。

php-5.2.5のphp.ini-recommended

error_reporting = E_ALL

php-5.2.5のphp.ini-php.ini-dist

error_reporting = E_ALL & ~E_NOTICE

はてなーのみなさん

多い方が、「E_NOTICEを出していない」

Unohラボは出してる見たい

http://labs.unoh.net/2006/11/e_notice.html

なんかばんざい（E_NOTICEを出すのに反対しているみたい）

http://tt25.org/blog/20080510/php-e-notice

次に、E_NOTICEを出したときの利点と欠点を整理します。

利点

• 未定義変数を発見できる

欠点

• 定義されていないhashのキーを参照するとエラーになってしまう。定義されているかわからないキーを使うときには、変数へアクセスするためのwrapperが必要になるだろう。

（追記があったら教えて下さい）


上記の反論：
未定義変数の発見→PHPEclipseなどのエディタを使うことで発見できるから、コンパイラでチェックしなくてもいい。


まとめ：いまのところ、E_NOTICEを出力する決定的な強みはないのでプロジェクトの好みで使えばいいと思う。

考察：E_NOTICEの回避方のノウハウなどがほとんど無いから、一般ではあんまり使われて無いだろうなぁ。PHPのデフォルトでもE_NOTICEは無効になっているし。
]]> General http://php.pcoach.jp/index.php?itemid=2726 Fri, 26 Sep 2008 11:09:27 +0900 http://php.pcoach.jp//item/1581 http://php.pcoach.jp//item/1581


洋書の日本語訳です。amazonの評価が高かったので買ってみました。

今日は、いいフレーズを見つけたので紹介します。
「複雑さへの対処は、ソフトウェア開発における技術面での最も重要なテーマである。」

構築するシステムが大きくなってくると実装する項目も多くなってくる。また、ソフトウェアへのも複雑になってくる。

設計で一番重要だと最近思っているのは、
複雑な要求をシンプルに設計する。
こと。複雑な要求をそのままシステムへ落とし込むことは簡単。だって、要求をそのままコードに落とせばいいだけだから。しかし、要求の本質、今後の拡張性、他のコンポーネントとの依存性、重複性、その機能自体の役割、といったいろいろな視点でソフトウェアを考え、設計することはとても難しい。

一度だけ設計して、システムをくみ上げるのと、日々機能を拡張するソフトウェアでは、100倍ぐらい後者の難易度が高い。

建築にたとえると、前者は「10階建てのビルをくみ上げる」。　後者は、最初は「2階建ての建物でいいけど、今後、増築する可能性がある」ということで、増築の内容は不明である。5階分の増築があることを見越して設計しても、10階分の増築があると大変だ。基礎から作り直すことになってしまう。

ソフトウェアの設計は奥が深い。]]> General http://php.pcoach.jp/index.php?itemid=1581 Thu, 31 Jan 2008 00:29:22 +0900 http://php.pcoach.jp//item/1575 http://php.pcoach.jp//item/1575 そのトランザクションを使うときの定義を一言でまとめると、

「外部キーが張ってあるテーブル間で、deleteかupdateを発行するとき」
と定義できます。

トランザクションの説明は掲載されていますが、トランザクションを使うときの明確な定義が記載されていない場合が多いため、記載しておきます。
]]> General http://php.pcoach.jp/index.php?itemid=1575 Mon, 28 Jan 2008 18:41:30 +0900 http://php.pcoach.jp//item/1293 http://php.pcoach.jp//item/1293 http://dev.mysql.com/doc/refman/5.0/en/year.html

0を文字列として入れると、2000になったり、99を入れると1999になったりするみたい。
予期しないバグが発生する可能性があるため、YEAR型は使わない方がよさげ。

年だけを保存するカラムは、unsigned medium intがよさげ。]]> General http://php.pcoach.jp/index.php?itemid=1293 Sun, 18 Nov 2007 20:22:16 +0900 http://php.pcoach.jp//item/1066 http://php.pcoach.jp//item/1066
生徒の方は、システム開発会社の経営者の方で、週に1、2回ほど遠方から足を運んでいただいていました。PHPアカデミー初の生徒だったので生徒が満足できる知識を伝えられるか心配でしたが、マンツーマンで教えることによって、生徒が納得するまでとことん教えられたと思っております。

最後にいただいた感想では満足していらっしゃるとの言葉をいただき、安心しました。IT業界のスピードはとても速いので日々新鮮な知識を得て、お役に立てるように引き続き精進していきます。]]> General http://php.pcoach.jp/index.php?itemid=1066 Wed, 26 Sep 2007 14:15:12 +0900 http://php.pcoach.jp//item/1019 http://php.pcoach.jp//item/1019
OSごとにベンチマークをとるのはかなりの手間なので役立ちます。

Comparing MySQL performance
http://www.linux.com/articles/41348


Net BSD2.0が一番早いですが、それ以降はLinux系があり、大きく開いてFree BSDがあります。特にNet BSDを使う理由が無ければLinux使っておけばいいっしょ。

]]> General http://php.pcoach.jp/index.php?itemid=1019 Thu, 13 Sep 2007 14:07:26 +0900 http://php.pcoach.jp//item/922 http://php.pcoach.jp//item/922 Yahoo UI

YahooUIでは以下のような機能たちがそろってます。
Web2.0的なWebを作る上で必要なユーザインターフェイスを簡単に構築できそうです。
* Animation Utility
* Browser History Manager beta
* Connection Manager (for XHR/Ajax)
* DataSource Utility beta
* Drag and Drop Utility
* Element Utility beta
* ImageLoader Utility [experimental]
* The YUILoader Utility beta
* The YUI Test Utility beta

確かにこれらのライブラリはすばらしいのですが、利用する側が書くコードも思った以上に膨大になることがわかりました。

利用者側のイメージとしては、必要最低限の記述をすれば使えて、高度な機能を使う場合は付加情報を与えるというのが理想です。しかしながら、毎回YahooUIではライブラリの初期化や、イベントハンドラに登録しなければ行けなかったり無駄な作業を多くしなければなりません。

費用対効果が見いだせませんでした。もっと利用者にとって使いやすい設計にしてほしいですね。
その点、Google Maps APIは利用者のことをとてもよく考えていて使いやすいです。]]> General http://php.pcoach.jp/index.php?itemid=922 Fri, 24 Aug 2007 17:25:15 +0900 http://php.pcoach.jp//item/851 http://php.pcoach.jp//item/851 「本を読み進めて勉強しているんだけど、何が要点かわからない。同じ事をやるのに2つ例が示されていて、どちらがいい方なのかわからない」

全体を把握していない、初心者にとっては、いろいろ示されてもわかりづらいと思います。
初心者に対しての本ならば、一本筋を通して書いて欲しいと感じました。
「これやって、あれやって、これを覚えて」とか。

そこで、おすすめするのがPHPの本家サイトにあるドキュメントです。
http://www.php.net/manual/ja/

比較的わかりやすく書かれています。　公式ドキュメントってなんだか取っつきにくいかもしれませんが一読の価値はあります。
サンプルコードとともにわかりやすく解説されています。


書籍を買うときは、amazonなので書評を読んでから買うことをおすすめします！
最近は、技術書の品質が悪い本も多く見受けられますので、事前に調査して購入することをお勧めします。

私が勉強し始めた頃は、PHPの本は2冊しか発行されていなかったので選択肢はありませんでしたが、品質はとても良かったです。何度も繰り返して参照しました。わからないことがあったら、速攻googleで調べていました。]]> General http://php.pcoach.jp/index.php?itemid=851 Mon, 6 Aug 2007 13:20:42 +0900 http://php.pcoach.jp//item/588 http://php.pcoach.jp//item/588
apache 2.2.4 +.PHP 5.2.2で挙動がおかしくなります。。。。
自分のところだけかもしれませんが、2台の別サーバで不具合が起こりました。

どんな具合だったかというと、不定期にプロセス数が増加してゆき、それにつられてロードアベレージもあがります。
そして、HTTPでapacheにアクセスしても応答が無くなります。

apacheにはエラーログははかれていませんでした。

解決策はapacheを再起動するのみです。



open sourceのソフトウェアはサポートも保障もないのでテストはしっかり自己責任で行わなければなりません。
PHPなどのオープンソースソフトウェアでの開発はPHPだけに精通しているだけではなく、PHPに関係するソフトウェアも把握しておかなければ問題が起きたときに対処ができなくなってしまいます。

運用環境へ不具合を持ち込まないためには運用環境にできるだけ近いテスト環境を構築するべきです。
上記のような、よくわからない不具合がたまーに発生します。それを回避するためには実際に使ってみるしかありません！

Linux,apache,MySQL,PHPこの4つがちゃんと動いてこそ、安定したプログラムを書けるようになります。]]> General http://php.pcoach.jp/index.php?itemid=588 Mon, 18 Jun 2007 02:34:49 +0900