はてなブックマーク

某所というかまぁFacebookでなのですが。 接続数が多くて「too many connections」エラーが発生する場合。 PHPのプログラム（バッチファイル）側として何か対応すべきことや、 注意すべきことなどありますでしょうか？ という、大変に有意義で結構質問のありそうなあたりをいただいたので。 せっかくなので、Blogネタで書かせていただきました。 さて早速。 とりあえず直線的に状況を考えると、このエラーメッセージは「なんか接続数多すぎてさばけないヨ！」っていうMySQLからのクレームです。 悲鳴、って読み替えてもOK。 先に対象外である「PHP以外の角度からの」解法としては ・max_connections を増やして、もっと沢山接続できるようにする って方法があります。 あんまり無茶な数値にすると「DBサーバが落ちる」とかいう悲劇に直結しますので、サーバのリソースをしっかり監

以前から書こう書こうとは思っていたのですが、こんなツイートを拝見したので「あぁいいタイミングかなぁ」と思って。 https://twitter.com/kis/status/590760562654650370 「コードの意図はコメントではなくメソッドであらわすべき、細かすぎるコメントは実装と乖離して負債になる」っていう指摘があったけど、これそのまま「細かすぎるメソッドは実装意図と乖離して負債になる」とそのまま言い換えれるし、むしろメソッドのほうがメンテが面倒で負債としてでかい気がする。 追いかけて拝見をしていると http://d.hatena.ne.jp/nowokay/20150420#1429507297 http://d.hatena.ne.jp/nowokay/20150421#1429579125 コメントの話、ぽい感じではあるのですが。 まぁその辺はあんまり気にせず、書きた

元ネタっていうか刺激元は此方。 [db] 「O/Rマッパーがなぜ悪いか？」がなぜ頭悪いか？ kwatch.houkagoteatime.net/blog/2014/12/27/nabokov7/ 些か検証仕切れていない部分はあるんだけど。 現時点において ・本質的な部分 ・現在(っつか正確にはちょい前)の実装的な部分 のどちらでも、気になる部分が少なからずあるので、端的に書くとおいちゃんは「好まない」感じ。 ・現在(っつか正確にはちょい前)の実装的な部分 が単純なんで先に書いておくと「いらんSQL流しすぎで重すぎで結果DBに負荷かけ過ぎ」なのでお好まん。 ただ、これは「改良されつつある」話も耳にするし、きっと「改良されていくだろう」と思うので、現時点ですでに枝葉末節な気もする。 ・本質的な部分 で一個、物凄く大嫌いなのが「ORMを使えばSQLを知らなくてもイイ」って論調でなんて言うか「滅び

頂戴したデータがvalidなのかをvalidationするvalidatorの、どっちかってぇと「理屈」部分を、少し整理してみましょう的な備忘録。 実用一点張りなのと、とりあえず「PHPメイン」で書きますんで、適宜、他言語な方々におかれましては応用したりかみ砕いたりしてご覧頂ければ、と思います。 あとまぁ毎度のことではございますが。 以下はあくまで「おいちゃんの私見」なので、その程度にご覧頂ければ幸いでございます。 んで。 validationってのはつまり「データがvalidであるように」ってな感じで、validってのは「有効であったり正当であったり妥当であったり確実であったり」するようなほにゃらら、になります。 とりあえず「明らかにイカンdata様におかれましては、謹んでお引き取り願いたくここに抹殺いたします」的なノリ。 ただンじゃ「このデータ様は、有効であったり正当であったり妥当であ

軽く各方面とバトりそうなネタなれど。 まず。 ヨーダ記法(ないしNTT記法…って、うちのまわりではいってたんだけど、ググるとあんまりでてこない)ですが。 これは「if等の比較演算において、左辺に定数、右辺に変数を置く」記法です。 とりあえず幾つかネットで拾ってみる。 http://uchidak.net/yoda-notation このようにヨーダ記法とは、予期しない代入を防ぐために産み出された安全側へ倒すための書き方です。 しかしながら、現在はコンパイラがよしなにしてくれるため、あえてヨーダ記法で可読性を失うような書き方をすることをリーダブルコードでは推奨していませんでした。 http://qiita.com/moriturus/items/723eb17873381f94baf8 確かに、ヨーダ記法(1 == hogeのように記述する)は、発見しづらいミスを防ぐのに有用かもしれないが、

http://www.huffingtonpost.jp/rootport/post_5947_b_4139629.html 経由 http://rootport.hateblo.jp/entry/20130505/1367763730 まぁ内容は同じだと思う(diffとってないけど)。 「文章を「書ける人」と「書けない人」のちがい」という、blog。 いくつか抜き出してみましょう。 文章を書くという仕事は、ゼロを１にする作業だと思われがちだ。 しかし実際には、文章を書くというのは１００を１にする作業だ。文章を書けるかどうかは、このことに気づけるかどうかだと思う。 『狼と香辛料』を書くにあたり、著者の支倉凍砂はかなりの量の文献を読み込んでいたらしい。ライトノベルは、青少年向けの「軽い小説」と見なされることが多い。しかし、そのライトノベルでさえ、メガヒットの裏側にはきちんとした情報収集があっ

きっかけは本日の講義でもらった質問。 PHPで、ダブルクォート内の変数が展開される、ってのはあって。 {}を入れないと「$に続く、有効な変数名を形成することが可能な最長のトークンを取得する」ってのが基本ざんす。 なので、以下は… <?php $a = 1; $ab = 2; $abc = 3; $s = "$abcdefg"; var_dump($s); string(0) "" こうなりまふ。 なので、通常{}を使って「明示する」ほうが楽ができるんでござんす。 <?php $a = 1; $ab = 2; $abc = 3; $s = "{$ab}cdefg"; var_dump($s); string(6) "2cdefg" さて。質問があったのは、以下のパターン。参考書に書いてあるらしい。 <?php $a = 1; $ab = 2; $abc = 3; $s = "${ab}cde

元ネタは 「ソフトウェア開発」は「モノ作り」ではない http://www.gcd.org/blog/2006/07/91/ の、コメントのほう。 あ、勿論「本文読んでる」前提で。 ＆ 夜半に勢いで執筆しているので、口調その他は気にしない事ｗ 7. モノでも設計でもサービスでもなんでもいいけど、少なくとも頼んだモノは作って下さい。お金を決めて、それで作ると言ったモノは作って下さい。 作ると言ったものが作れない、いくらでできると言ったものができない。納期を守ると約束したのに約束が破られる。 詐欺ですか？ なんでもいいけど約束は守ろうよ。 コメント by 通りすがり ? 2006年7月28日 @ 21:41 14. ソフトウェア開発は設計である、という前提に一理あるかも知れません。その場合、クライアントが、そのように納得しているかどうか、が一番重要だと思います。 その上で、7.通りすがりさんの

UDIDの話は先日書いたわけなのですが( http://d.hatena.ne.jp/gallu/20130415/p1 )。 そうすると次は「んぢゃMACアドレス」という話が耳に入りまして。 ってなわけで第二弾「MACアドレスでの認証やめれ」をお送りいたします(拍手＠サクラの群れ)。 先に結論を書くと「UUIDv4使おう」になりますので、そのように認識をしつつ以下をご覧くださいまっしょ。 UDIDなんで一端「iPhoneの話」をしますが、Androidでも大して変わりゃしませんので、そのようにご認識いただきたく。 さて。 簡単に、MACアドレスを使うのを止めるべき理由は ・プライバシ(名寄せ)にまつわる問題 ・クラックしやすいぢゃん問題 の２つになります。 ちと経緯的に「下の状況」が発生しているので、そちらをメインに話を進めさせていただきます。 プライバシ周りは、例えば「固有IDのシンプ

ちょいと今日話が出ていたので、多分今後も「出るだろうなぁ」との予想込みで、Blogに。 (余談。タグに「プライバシ」とか追加しようかしらん？ どう思います？) ん…直接的には、あぽー様がすでに「おら受けトンねぇ」宣言をなさってるでごわす。 ちなみにそれって2011/08/19のお話( http://techcrunch.com/2011/08/19/apple-ios-5-phasing-out-udid/ )。「最近」とか騒いではいけません。 AppleのApp Store、Retina非対応／UDID採用アプリの登録とアップデートが不能に　5月1日から ( http://www.itmedia.co.jp/news/articles/1303/22/news041.html ) Apple、5月1日からUDIDにアクセスするアプリ・非iPhone 5最適化アプリはリジェクトと発表。 (

某所でこんな質問をもらいまして。 うん確かに「ビット演算がわからない」と、それ以上に「なにに使うのかがわからない」って話はよく耳に目にするところなので。 せっかくなんで、Blogで返答をいたしますｗ 質問は、これ。 ビット演算子のこの部分が $a = 0xFF; $b = 0xF0; $c = $a & $b; var_dump($c); echo sprintf("%08b\n",$c);　//2進数で出力11110000 よくわかりません。 この11110000って、16進数だとF0、10進数に戻すと240になります。なので、直接F0を2進数にすればいいのに。。。（2進数にするやりかたわからないのですが＾＾；） $a & $bは教科書には$a及び$bの両方にセットされているビットをセットするって書いてあります。なんですかこれ＾＾； ビット演算子についてあまり理解ができていないからかもし

割と気に入ってる書籍達。 某所で本の話をしている時に切り出したので、だらりんこんと。 １年くらい前のやつのはずなので、最近の本とか結構漏れてるけど、まぁ参考程度に。 UNIXという考え方―その設計思想と哲学 http://www.amazon.co.jp/dp/4274064069 マンガ式 IT塾 パケットのしくみ http://www.amazon.co.jp/dp/4774128430 小悪魔女子大生のサーバエンジニア日記 ――インターネットやサーバのしくみが楽しくわかる http://www.amazon.co.jp/dp/477414522X [改訂3版] 図解でよくわかる ネットワークの重要用語解説 http://www.amazon.co.jp/dp/4774138215 UNIXシステム管理 第3版〈VOLUME1〉 http://www.amazon.co.jp/dp/4

んとぶっちゃけると「str_getcsv使うな」って感じ。 サンプルとか見てるといかにも「いけそ〜」な感じなのですが。実は「改行」を全く意識してくれないので、二次元配列を期待しているのに、ふつ〜に一次元配列でreturnしてくれやがります。 $s = "1,2,3\n4,5,6\n7,8,9\n"; $awk = str_getcsv($s); var_dump($awk); っつわけで考えてみました。 結論からいうと「メモリ上に一時ファイル作ってからfgetcsv」がよろしげな感じ。 …っつか、str_getcsv、同じ挙動しろよ orz 「php://memory および php://temp」については、マニュアルを参照。 php.net/manual/ja/wrappers.php.php php://memory および php://temp は読み書き可能なストリームで、一時デ

元ネタは、某所の書籍でみた、こんなコード。 foreach($data as $key => $val) { $$key = $val; } 見た瞬間から色々気になってはいたんだけど。 ふと思って試した実験コードの内容が、思ったよりもちょっとアレゲだったので共有。 まずは、初手の実験コード。 <?php $data = array(); $data['test'] = '1'; $data['_test'] = '2'; $data['0test'] = '3'; $data['te-st'] = '4'; $data['te-st'] = '5'; foreach($data as $key => $val) { $$key = $val; } $awk = get_defined_vars(); unset($awk['_SERVER']); unset($awk['_POST']);

いやまぁいろいろあちこちで議論が出てきたので、まとめて。 もちろん当然ながら、以下は「おいちゃんの見解」であって、それ以上でもそれ以下でもありませんので、その辺は踏まえたうえでご覧くださいませ。 端的に「おいちゃんが個人で自分用の物を作る」んなら議論の余地もなくMagicWeapon一択で終わるのですが(笑 つまりは「おいちゃんでない人」や「個人じゃないところで」とか「他人用のものを作る」場合、それ以外の選択肢の可能性も、十分にあるわけです。 ただンじゃ「選択基準」ってのもいろいろとあろうかと思うので、その辺の指針を考える上での、考察状のポイントを少しまとめたいなぁ、と。 とりあえず「一番多くて」「一番痛い目にあう」のが「＊＊ってフレームワークは有名だしよく目にするから」。 類似品として「＊＊さんがいいって言ってたから」。「＊＊のイベントで」とかそーゆーのも同根。 なんで駄目な論拠なのかは

あちこちのフレームワークでは「何してるんだろう？」って思ったので。 以下のフレームワークを調査してみますた。 CodeIgniter_2.1.2 cakephp-cakephp-e0b6f86 symfony-1.4.18 Symfony2 FuelPHP 調査は、サーバに入れてからgrepでini_setを探すという高難易度調査ｗ で、その中から興味があったモノを抜き出してみました。 ini_set('unserialize_callback_func', 'spl_autoload_call'); http://php.net/manual/ja/var.configuration.php unserialize() が未定義のクラスを使おうとしたときに、ここで指定したコールバックをコールします。 あぁなるほろ。 ん…いらんかなぁ。 ini_set('html_errors', 'On

一度整理したかったんだけど…思った以上に魔窟でした orz 大分とメモ書きなところもあるので、適当に脳内補完しつつ読んでみてください。 「理屈はえぇから設定みせろや」な場合(…まぁエンジニアとして妥当な姿勢かどうかには果てしなく疑問が残るところではありますが)、マルチバイト周り基準のphp.ini 設定草案( http://d.hatena.ne.jp/gallu/20120726/p2 ) をごらんくださりませ。 では早速。 default_charset = 出力文字コード PHP_INI_ALL header() PHP は、デフォルトで常にContent-type:ヘッダで character encodingを出力するようになっています。charsetの送信 を無効にするには、これを空にしてください。 この辺は、個人的にはviewクラスで処理したいなぁ。 だから、offをお勧め。

開発手順の草案とか考えてみました。 色んな手順あるかと思うのですが、一度、自分の手順を色々と「揉んでみたい」なぁ、って思ったので。 目的 ある程度低コストで、かつ「複数のエンジニア＆デザイナ」が存在していることを前提に。 運用が楽で、且つある程度の安全性が保てるような「開発手順」について、それを定めることを目的とする。 注意 マニュアルっぽく書こうと思ったのでなんか断定的な書き方がありますが、基本的にこれは「草案」です。 検討して議論してもむための「素体にする」ため、程度のものなので、色々とご注意ください。 事前準備 サーバは、物理的には２台用意する(仮想マシン２台でもOK)。これがミニマム。 論理的には、以下の役割がそれぞれ存在する。 gitサーバ(ないし、適切なバージョン管理用サーバ)：redmineなどを合わせて載せても良い 個人用開発Webサーバ(個人毎なので複数) 個人用開発DB

Windows系の人には「ショートカット」って言うと通じるのかしらん？ 割とおいちゃんは多用するのですが、あんまり使わない人が多いぽいので、備忘録。 前提条件 シンボリックリンクの説明はよいよね？ ln -s コマンドで作るアレでおま。 sつけないハードリンクは…そも、多分見たことないぞい？(笑 その１：インフラでシンボリックリンク使いやがれ daemonのinstallなんかでよくつかいます。 実例。 例えばapacheをinstallします。デフォだと /usr/local/apache2 とかになるのかな？ おいちゃんは、configureで指定して、これを、例えば /usr/local/apache2.2.22 とかいうディレクトリにしておきます。今時は2.4系だろうって？ まぁ気にしない。 んで、installした最後に ln -s /usr/local/apache2.2.22

MagicWeaponには「tokenizer」という「一意のトークンを発行する」クラスがあります。ちょっとしたDBのPKに死ぬるほど便利なのでよく使います。 一方で、以前に書いたのですが( http://d.hatena.ne.jp/gallu/20120402/p2 )、違うトークンの作り方もあります。 で。おいちゃんは「使い分けてる」ので、その辺の話をもやもやと。 「ぢぢぃの世間話を聞いてる」くらいの生ぬるいスタンスで読んでくださいｗ 大まかに結論先に書いちゃうと。 tokenizerは「一意であることを保証したい」ケースで使って、もう一個のトークンは「推測困難性がほしい」時に使います。 ん…まず、うちのtokenizerの仕様から。 前提として「62進数」ってのを使ってます。 62進数表記にすると、0-9とa-zとA-Zで表現できるので、ま〜ま〜便利です。素直にbase64でもよか

発端はまぁまた色々あるのですが、他でも出てくる切り口で「非常に気になる」話があったので。 前提として http://takagi-hiromitsu.jp/diary/20120504.html を読んでおいてもらえたりすると、色々と話がスムーズな気がいたします。 とりあえず直接的な考察のきっかけとしては、 https://twitter.com/#!/TakaFlight/status/198666924425625600 にある https://www.facebook.com/hhokamura/posts/329492283788026 の内容。 ログインせんでも見られたので「公開情報」だとは思うのですが。「後で改変または削除」の可能性も一応念頭に入れて、念のために全文引用。 あちこちで話題になっているが、またその多くで見られる典型的オプトイン国民の言動が悲しい。 まだ行動を起こす

おおむねこんな感じを想定。 ベースになるのは /dev/urandom なので。「環境ノイズが以下略」的な話は、きっとなんとかなるだろうしてくれるだろうだからある程度暗号的に安全な擬似乱数であろう、ことを、期待(笑 shaが1ぢゃなくて512なのは、おおむね、おいちゃんの癖。長いほうが推測しにくいっしょ？ で、ハッシュにはどうしても「ハッシュのbit数よりもでかいのを渡しておきたい」ほうなので、少し大きめに。 「処理にかかるCPUコスト」は、比較的軽視の方向で。 というような思考回路を経て作った、超ざっくりなトークン生成。 $token = hash('sha512', file_get_contents('/dev/urandom', false, NULL, 0, 128), false); var_dump($token); でもまぁ、ワンタイムトークン用で、かつ「ンなに長い寿命を持