日付関連の小ネタ

片や。
PHPでstrotimeは割とよく使われる関数かなぁ、と思います(DateTimeクラスのコンストラクタに渡す引数、と読み替えてもよいです)。

片や。
善し悪しはとりあえず置いておくとしまして、MySQLを使っていると「0000-00-00」というブツが出てくることは、まぁ時々*1、あります。

んで。

<?php

$t = strtotime('0000-00-00');
var_dump($t);
echo date(DATE_ATOM, $t), "\n";
echo "\n";

$t = strtotime('0000-00-00 00:00:00');
var_dump($t);
echo date(DATE_ATOM, $t), "\n";
echo "\n";

$date = new \DateTime('0000-00-00');
echo $date->format(\DateTime::ATOM), "\n";

それを食わせてみると

int(-62170016400)
-0001-11-30T00:00:00+09:00

int(-62170016400)
-0001-11-30T00:00:00+09:00

-0001-11-30T00:00:00+09:00

なんとも味わい深い出力が得られるんですねぇ……エラー時、strtotimeならfalse、DateTimeなら例外を出して頂ける事を期待するんですが、その辺も特に出てこない orz

ちょっと(ある意味)興味深い事例だったので、めも。
………お願いすなおにエラーにして orz

*1:しょっちゅう？

リファクタリングとリメイクのあいだ

リファクタリングは、乱暴に言ってしまうと「大改造!!劇的ビフォーアフター」だよ、とかよく説明をします。
多分そんなに間違ってないんじゃないかなぁ。

で、安心したリファクタのためにはやはりテストが重要で。
なのでもしテストコードがないコードをリファクタする時は、「まず先にテストコードを、ある程度しっかり書いておく」と、安全に安心にリファクタをする事ができると思うんですね。

まぁ勿論、テストを書いている時点で「通常は気づかない、微細な(仕様を含む)バグ」が新たに見つかる事もあり、それはそれで「リファクタをして良かったよねぇ」のONE PIECEになるのではないか、と思います。

………で。
リファクタと称される案件にお会いした時に、時々、ごくまれに、僅かながら、全くないとは言えない程度に極小の確率で*1、遭遇するのが。
・リファクタをしたい
・テストを書きたい
・テストを書くために「現在の仕様」を理解したい
・現在の仕様が「誰にもわからない」
・だからといって「動いているコードが正解」とも言いにくいほどにあちこちに綻びがある*2

……さて。リファクタとは？

多分ここが分岐点で。
・多少綻びがあるにしても「仕様」がある程度明らかであるなら、リファクタリング
・そもそも「仕様ってなに？」状態だと、リファクタにはなり得ず、結果的にリメイク

ってのが、なんとなく「リファクタリングとリメイクのあいだ」なんじゃないかなぁ、と。

…………書いてて血ぃ吐きそうですが orz

*1:つまりしょっちゅう

*2:契約を管理するシステムで「入力した情報(PDF出力では使っている)の半分以上がDBに保存されず揮発する」システムが正常だとは、あんまり思えないんですよねぇ……(実話 orz)

仮想世界のお金のお話

今となっては割と普通になってきた感のある「なんで人はがちゃで散財をするのか？(極論)」というお話ですが。
比較的初期の頃に、この手のお話を大変に丁寧に書かれたこの書籍を、今日は紹介。

人はなぜ形のないものを買うのか

一方で「経済学の准教授」という側面と、もう一方で「かなりギリギリのゲーム廃人」という側面が大変にナイスに融合した、素晴らしい論調の内容です(笑

ただ、ものすごく残念な事に、書かれている方はすでにお亡くなりになっています。
gallu.hatenadiary.jp

この本も「一読の価値はまちがいなくある」ので。
残念ながら、電子書籍になっていない上に新刊がないので中古オンリーになってしまいますが、是非、手に取って読んでみてください。

成功もいいけど、失敗もね

失敗学、ってぇのがありまして、端的には「失敗に学ぼう」というものでございます。
成功は、とかく「運や偶然やまぐれ」が介在しやすいのと、また成功した時に「どこが本当の"成功の要因"だったか」の検証は、なかなかに難しいものなのですが。

一方で失敗は「これをやったら、運がよっぽどヨクナイ限りは同じような目に遭うよねぇ」と考えやすく、他人の失敗から学ぶのは、とても大切なものでございます。

この手のお話で、まずトップに出てくるのがこちら。

失敗の本質―日本軍の組織論的研究 (中公文庫)

よい書籍……なのですが、幾分、読みにくさでも定評が以下略。
なので、

「超」入門 失敗の本質 日本軍と現代日本に共通する23の組織的ジレンマ

こちらを読んでおくと、大変に読みやすいかと思います。

また、失敗学自体について、読みやすい書籍を1～2冊読んでおくとよいか、と思います。
「これでなければ」ではないのですが、おいちゃんの手元にはこれがあり、そこそこ読みやすかったと思います。

失敗学 (図解雑学)

また、同じ方が書いているこの書籍も面白かったので、合わせて。

失敗学実践講義 文庫増補版 (講談社文庫)

こういった「失敗」という切り口をどれくらい活用できるか？ は、割と死活問題な気がするんですよねぇ。

プロジェクトはマネジメントしませんと、されませんと

プロマネのスキルは。
勿論「プロマネになりたい」のであれば必要なのですが、「がっつり現場でがりごりとプログラム書きたい」人も、最低限くらいは踏まえておいたほうがよい、と思われるスキルでございます。

世界一わかりやすいプロジェクトマネジメント 第4版

「世界一わかりやすい」かどうかは知りませんが、読みやすくわかりやすい書籍だと思われます。
一つポイントなのは「実はこの本、"プロジェクトマネジメントの本"ではあるけれども"システム系のプロジェクトマネジメントの本"ではない」、って所。
読んでて9割がた普通に「あるある」な内容なので結構気づきにくいのですが、実はこの本「プロジェクトマネジメントの本」なので、別に「システム開発用」ではないんですよね。
どこも「同じような感じなんだなぁ」ってのを、切実に感じるところでございます。

もう一つ。
PMBOKはやっておいたほうが良いと思う、ってんで、この本をよく勧めます。

プロジェクトマネジメント標準 PMBOK入門: PMBOK 第6版対応版

割合とあっさりと読めるので、入り口用にオススメです。

PMBOKもまぁ色々と「……ちょっと」とか言われたりすることもあるみたいですが、それは「PMBOKをちゃんと踏まえたその先」のお話なので。
まずこの辺くらいは、しっかりと踏まえておきたいものでございます。

ドラッカー……を、ちょっと手加減して

一度は読んでおきたいドラッカー。
ただ、いきなり「マネジメント」から行くと少々歯ごたえがあるので。

図解で学ぶ ドラッカー入門

いや別にこの本でなくてもよいのですが、いわゆる「入門」とか「初心者向け」とか「ｎ日でわかる」とか「図解」とか、その手の「敷居の低い本」を読んでから本編(マネジメントとか)に行くと挫折しにくいので、オススメでございます。
ちな、「とりあえず入門書だけ読む」のであれば、「異なる著者の初心者本を、2～3冊」ってのをオススメしておりますので、合わせて覚えておいてもらえれば。

その後ですが、「実践するドラッカー」シリーズを読んでみると、割と「身近なお話」になりやすいので、身になりやすいか、と。

実践するドラッカー【行動編】

実践するドラッカー【チーム編】

とりあえずこの2冊を紹介しました。

ホスピタリティ

お次の話題は「ホスピタリティ」でございます。

リッツ・カールトン 超一流サービスの教科書 (日経ビジネス人文庫)

持っているのは文庫版ではないのですが、今、どうも絶版っぽいので、こちらで。
出た当初は、一瞬、バズってた書籍だったように記憶をしています。

帝国ホテルの不思議 (文春文庫)

こちらも同じく「持っているのは文庫版ではないのですが以下略」です(苦笑

2つのホテルの方法論は、びっくりするくらい「違う」のですが、「お客様のために」って方向性は一緒なんですよね。
勿論、システム開発なので「全く同じ」ではないのですが。
それでも、システム開発の向こう側には「お客様」がいて、開発の中であっても(おいちゃんはプログラムが多いので一端プログラマベースの目線でいくと)インフラ屋さんやDB屋さん、デザイナーさんや営業さんやマーケティング屋さんがいて。

そういう人達と「いかに協業するのか」ってのはとても大切なので。
その方法論の一端を考える上で、とても面白い書籍なんじゃないか、と思っています。

＆

リッツ・カールトン一瞬で心が通う「言葉がけ」の習慣

をはじめとする「リッツの名を冠してる書籍」は割と色々出ているので、いくつか読んでみても面白いかもしれません。