先日のこのエントリーがバズりました。 「奨学金返せず自己破産15000人」のニュースを隅々まで掘ってみよう 朝日新聞が「奨学金は貧困ビジネスだ」みたいな感じで攻めてくるので、「そもそもDQN親が保証人になってる場合に個人破産が多い。機関保証の人たちはみんな返済してる」というデータを付けまして、 保証機関保証にすれば全て解決!! という提案をしたわけです。しかし有利子といっても非常に低い利息で、384万円借りても毎月たったの16561円の返済。 これが返済できなくて自己破産って、そこに至るまではおそらくずーーーーーっと支払いをバッくれていたら「もう猶予できないからまとめて返済しろ」というのが来て、それは払えないから自己破産ってことじゃないのと推測する次第です。 そしたらまた朝日新聞がぶっ込んで来ましたよ。 奨学金受けた息子亡くし８年、夫婦に２６５万円の督促状 前半部分はこのタイトルと関係ない

まえがき 前提として、しっかりとコーディング規約やコーディング手順などが整備されている現場ではあまり関係ないかもしれません。 そういうのを整備して実践していことが難しい現場、スタートアップからインクリメンタル開発を経て、成長していくサービスを長期間作り上げていく事業会社が主なターゲットの話かもしれません。 既存コードに if 文がありました さて、あなたが開発現場に途中から参画しました。すでに A と B という別の人が作った画面があります。 あなたは C を作ります。C は A と B と似ています。 「さあ、作ってください」 と言われました。どうしますか？ ... まあ、普通に考えたら、A と B を参考に作りますよね。ここに甘い匂いがします。 A と B には、とある定型の if 文による制御がありました。C では一見、要らなそうに見えますが複雑でよくわからない。 C でも if 文

独自フレームワークのPHP7対応に絡んで、認証 および CSRF対策周りを再設計したいので予備調査の結果を軽くまとめる ハッシュ関係 password_hash関数 パスワード認証用のハッシュ生成に使う password_verify関数 タイミング攻撃を回避するための文字列比較関数(password_hash専用) hash関数 通常のハッシュ生成に使う(MD5とか、SHA256とか) hash_equals関数 タイミング攻撃を回避するための文字列比較関数(汎用)、== や === はタイミング攻撃が可能 パスワード認証と、それ以外で用途により使い分ける形がベストか？ 暗号関係 mcrypt_encrypt, mcrypt_decrypt PHPのコンパイル時にmcrypt対応のオプションが必要 openssl_encrypt, openssl_decrypt PHPのコンパイル時にO

クソコードについてここ数日で考えたことを書いてみる。 技術的負債まわりのえらいひとたちの議論を眺めてて、技術的負債って言うとなんかプロっぽいけど、クソコードって言ったほうが示したいモノを素直に表してるし分かりやすいきがしてきた。 クソコードを書くなとは思わないけど、クソコードをいつまでも放置するのはやめようって思う。 クソコードは次なるクソコードを生み出すし、バグを隠蔽するし、メンテナンスコスト増大の悪循環のキッカケになるし、新人の教育上良くないので無くて済むならもちろんないほうがいい。 ただ、ギークな人たちを除いて、さらっと60点*1のコードなんて書けない。僕を含め大多数のエンジニアは自分自身が書いたクソコードをリファクタリングして60点以上のコードを目指すための時間が必要になる。 そのうえ、そういうコードを書いてもだいたい時間経過に伴って事情が変わって、60点のコードの挙動を壊さないよ

詳しい調査はしていないが、HTTP 1.1 でサーバ側から自前でレスポンスを返した場合(200応答以外の404などのレスポンスのときに起きた)に、クライアント側の file_get_contents() の返りが遅いという問題が起こるようだ。 原因は HTTP 1.1 では KeepAliveがデフォルトで有効になるが、file_get_contents の側ではTCPコネクションのクローズまで待ってしまうことにあるようだ。 これは本来、リクエストしている file_get_contents の側で何とかするのが正しい対応かと思うが、どうも方法がよくわからない･･･ というわけでとりあえず、サーバー側で header('Connection: close'); として明示的にセッションのクローズを宣言することで回避できた。 後で調べたところ、サーバ側からレスポンスする HTTP のバージョ

例によって同僚に、ON DUPLICATEを使ってる時の、LAST_INSERT_IDの挙動がなんかおかしいという話を受け調査を開始した。 複数の同僚に手伝ってもらいながら検証した結果次のような現象が起こることが分かったため、メモしておく。 ON DUPLICATE でプライマリキーに「文字」を利用する場合、LAST_INSERT_IDの値が 0 に変化し予期せぬ更新がかかったり、更新が失敗する問題がある。 これは、LAST_INSERT_ID が数値 しか扱えないことが原因と思われる。 次に検証手順を記す。 とりあえず、MySQLのバージョンは 5.5.19 ■一つ目のパターン「数値」の場合 このパターンは想定通りに動くので、特に問題は起こらない 1.まずは簡単なテーブルを作成する mysql> CREATE TABLE IF NOT EXISTS fff ( -> id VARCHAR

↓の続き 誤報 APC の apc.include_once_override で動的な include_once 等が失敗する問題 http://d.hatena.ne.jp/narusase/20121030 どうも同僚の調査によると、動的なinclude_onceが原因ではないようだ ･･･というわけで、極限まで単純化したサンプルコードを書いてテストしてみた。 ファイルその1. /home/htdocs/test.php <?php function include_test($x = array()) { include_once('hogehoge.php'); } echo '1'."\n"; include_test(); echo '2'."\n"; include_test(); echo 'end-'."\n"; ファイルその2. /home/lib/hogehoge.

とあるよくわからないエラーを調査したときPEARのMail.php の@ 指定を解除したところ下記のようなエラーが発生したのでちょいと調べて見た。 結果としては先に設定したAPCの apc.include_once_override = 1 の設定が悪さをしていた事が分かったので一応メモっておく PHP Fatal error: include() [<a href='function.include'>function.include</a>]: Cannot redeclare class mail_smtp in /省略/Mail.php on line 52ネット上をいろいろ探してみるといくつかのサイトで引っかかる既知の問題のようだが、PEARのMail.phpの下記のようなコードが駄目らしい。 static function &factory($driver, $params =

きたーーーメモリ使用量減った！！ 以前から悩んでいたPHPのメモリ使用量が高い問題だがようやく対処方法が分かった php.iniに下記の設定を追加することで、とあるプログラムでは14MB食ってたのが4MBまで減少した(1プロセス当り) apc.include_once_override = 1 apc.lazy_classes = 1 apc.lazy_functions = 1 この設定は関数やクラスの遅延読み込み的なことをする設定のようなので、実際には走らないコードを多く含むものについてはそこそこ効くと思われます。 なお、include_once_override の設定はコードの書き方によってはトラブルになることが多いとのことなので、使うならしばらくテスト環境などで寝かせておいてテストした方が良いかもしれません。 また、lazy_classes、lazy_functions は遅延読

知り合いから教えてもらったのだが、PHPでは /** から始まるコメントが、require_once実行時に無駄にメモリを食う問題があるらしい･･･ということで調査してみた まずは、確認用のコードとして test.php を書く <?php echo ' peek usage'."\n"; echo 'pre = '.memory_get_peak_usage().' / '.memory_get_usage()."\n"; $x = '0123456789'; for ($i = 0; $i != 12; $i++) { $x = $x . $x; // 適当にメモリを使ってrequire_once 時に新たにメモリを確保する必要があるようにしておく } $before = memory_get_peak_usage(); echo 'before = '.$before.' / '.m

最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ

これはだいぶ前にネタにした↓の超遅い続編です http://d.hatena.ne.jp/narusase/20091204 職場で(当人はまったく中の人が私だということに無自覚に)上記エントリがさらされたので、ちょっと、気になって調べてみた。 そしたらなんだか、1年半ほど前に下記で直ってるっぽい･･･ http://svn.php.net/viewvc/php/php-src/trunk/ext/standard/html.c?r1=304713&r2=304882 ネタにしたのが2009年12月だから、大体それから10ヵ月後くらいに直された模様 まあ、何はともあれ直ってよかった 超がつくほど遅い話だけど、一応報告までにエントリあげておく罠

いろいろと、問題になっているUIDやUDIDの使用に関する話をちょっと書いてみる。 ガラケーではキャリアからひとつしか発行されないはずのメールアドレスによりある程度仮の個人の識別ができていたけど、メールアドレスは変更が出来たので、必要十分な個人の識別には使えなかった。 したがって、メールアドレスの変更によって強制退会にされたユーザーが復活することが出来てしまっていた。 ･･･で、対策としてUIDをつかって「携帯」を一意に識別することで。仮に「個人」の識別を行っていた。当然、別の携帯を使えば、別の「個人」と識別されることから携帯をまたいでの個人の識別は難しい。しかし、まあ荒らしとかするようなまずい連中がそう頻繁に携帯を変えられるわけではないので、それで一般的な相手には必要十分な個人の識別が出来ていた。(資金力のある、つまり、携帯をどんどん変えられるような業者には無力だったともいえる) まあ、

簡単に言うとPUTされたコンテンツが読みだすと消滅する問題 POSTや、PUTでHTTPのリクエストを送った際、ペイロードとして$_POSTでは扱えないひとつながりの文字列を送る場合がある。 その際、$_POSTでは取得できないため、file_get_contents('php://input') を使って取得するのが通例になっている。 しかし、どうやらHTTP的にPOSTした場合と、PUTした場合で挙動に違いがあるようだ。 具体的にはPOSTした場合、file_get_contents('php://input') を使って複数回取得しても値は消えないが、PUTの場合1回だけしか取得できないバグ？ 仕様？があることが分かった。 ちなみに発生した環境は PHPのバージョンは PHP 5.3.6 ApacheのバージョンはApache/2.2.19 また、POSTやPUTする時にはfile_

この書き方はまずいからあとで直そう→直さない あとで拡張する必要がありそうだ、必要になったら設計を変えよう→まずい設計のまま他人に使われる コミュニケーションしなくても正しい判断ができるようにする 正解がないことは、走りながら臨機応変に変えなければならない。でも、始まった時から正解がわかることがある。そういうものについては、最初からよく考えて正解を選ぶ。 どちらか迷ったら、変えやすいほうを選ぶ。AからBとBからA、どっちが変えやすい? 初期に書くコードはすごく重要。後から参加する人は既存のコードにスタイルを合わせる。 軌道を修正するコストは早ければ早いほど小さい。 仕組みを変えることにはコストが伴う。心理的コストも。 走り出したら何も考えられない。よく考えてから走る。あるいは、走ってない人が考える。 一度動き出した仕組みを変えるときは、移行コストが小さくなるようよく考えた上で、無理やり変え

インターネットなんつーものはね、許可なんか求めていないクレージーな人たちによって作られてきたんだよ。それによって社会はすごくよくなったんだ。もし彼らが許可を求めていたら何も起こらなかった。そんな社会を我々は求めているのか。そーゆーことだと思う。許可を求めるな。謝罪せよ。 http://twitter.com/#!/hyoshiok/status/33183999060873216 この「許可を求めるな。謝罪せよ」というフレーズは@kawagutiに教えてもらったのだが、彼は@hiranabeから３Mの社是として聞いていて、その心はというと、ともかく試してみてうまくいかなかったら、その時また考えるというような趣旨の行動規範ということらしい。*1 関係各位の許可を求めていたら絶対物事は進まないし、何も始まらない。何かをやってうまくいくこともあれば失敗することもあって、その試行錯誤によって人は学

http://www.nytimes.com/2011/01/28/world/asia/28generation.html 敬称略。 東京 ― ホリエケンイチは有能な自動車エンジニアだった。日本ではこのような若い人材が、ハングリー精神あふれるライバルの中国や韓国と渡り合い、現在の地位を保つために必要とされている。30代前半のとき、彼は主要自動車会社に勤めており、先進的バイオ燃料のデザインによって評価を得ていた。 しかし、多くの日本人のように、彼は非正規労働者だった。時限付き（temporary）契約のもとで、雇用保障もほとんど無く、そのほとんどが40代後半である正規労働者に比べて半分の給料しかもらっていなかった。彼は10年以上正規労働者になろうと努力したが、ついに辞めた。時限付き契約だけではなく、日本そのものを、である。 2年前、彼は中国語を習うために台湾に移り住んだ。 ホリエは語る。「

愛知県警生活経済課のサイバー犯罪担当コタニ氏と，二日に渡って電話で話した内容をかいつまんで載せておきます。 要点だけ洗って載せたうえでさらに強調したので，目に痛くなってしまいました。すまん。 被害届が出る前に，図書館と MDIS エンジニアは状況を確認していた エンジニアは「中部支社ではこのような事例がない」と言っていた 警察は相談を受け，「事件として捜査して，処罰を求めるのなら被害届を出してください」と説明していた 図書館は MDIS と相談したうえで，図書館単独で被害届を出した MDIS は CMMI Lev5 を達成しており，「ソフトウェアの保守サイクルについて，そのプロセスを継続的に改善できる」はずである。 岡崎の事件より前に発生した，大阪府貝塚市，広島県府中市，石川県加賀市の三件の事例がフィードバックされていないとは考えられない 警察は最初から「ネット犯罪」「(偽計)業務妨害」と