正規表現マッチングのアラカルト(HTML編)

HTMLタグ

(?:<.*?>)

タグの閉じ忘れ

((?:<[^!].*<){1}?)    *ちょっち自信なし

 タグの閉じ忘れ２

(<(a|pre|div)\b(?:(?!<\/\2\b).)*(<\2\b|$))      *ちょっち自信なし

正規表現マッチングのアラカルト(数値編)

整数字(数値)

(?:0|(?:+-)?[1-9][0-9]*)

小数
(?:(?:0|(?:[+-]?[1-9][0-9]*))(?:\.[0-9]*[1-9])?)

カンマ区切りの数字(数値)

(?:[0-9]{1,3}(?:,[0-9]{3})+)

桁区切りのカンマを付ける(Perl)

s/(?<=\d)(?=(?:\d{3})+(?!\d))/,/g;

桁区切りのカンマを削除する(Perl)

s/,//g

野球部の女子マネージャーがドラッカーのマネジメントを読んだら

えぇ、私もこの本読みました。
そして、この本を読んで気づいたことがあります。
それはマネジメントはなにも仕事だけのものでは無いと言うことです。えっ？！知ってました？（汗

例えば家族を企業としてみた場合

• お父さん→社長
• お母さん→マネージャー
• 子供→社員

と置き換えてマネージメントを適用することが出来ますし、

• お父さん→パパ業の会社社長
• お母さん→ママ業の会社社長
• 子供→顧客

と置き換えることも出来ます。そして子供（顧客）がどうすれば言うことを聞いてくれるか、勉強してくれるか人として成長してくれるかマーケティングによって明確にすることが出来るのです。

恋愛においてもマネージメントは有効で顧客（意中の人）と契約を結ぶ（結婚や付き合うこと）ために、マーケティング（好きな物や休日の過ごし方をきくなど）をし顧客が欲しているサービス（デート）やアイテム（貢ぎ物）を提供するわけです。

そして、家族、親子、恋愛、その他人間関係すべてにおいて真摯さが重要だということです。
ただし、真摯さを利用しようとする輩も少なからずいますので気をつけなければなりません。

好みの色と年齢

色の好みは年齢とともに変わっていくようで、赤ん坊の時はビビッドな色（鮮やかな色）を好み年齢を重ねていくと共に淡い色を好むようになり、成人を過ぎて更に年齢を重ねていくとだんだん渋い色を好むようになるようです。
また、白、黒、赤、のように年齢に関係なく好まれる色も有るようです。

ディズニー等の子供に人気のあるキャラクターの色づかいを見ていると、なるほどッて思いますね。

ユースケース

ユースケース図は使ったことがないのですが、ユースケースは機能や処理の流れ分岐等を把握するのによく使います。

ユーザの登録
主アクター：スノウ 副アクター：なし 前提条件：スノウがユーザーとして登録されていない 目標：DB上のユーザーテーブルにスノウのユーザ情報が登録されること
メインパス 1.スノウがユーザ登録画面を表示する 2.スノウがユーザ情報を入力する 3.スノウが登録ボタンをクリックする 4.スノウのユーザ情報がDBに登録される 5.ユーザー一覧画面が表示される 純正常パス 3.1.1.スノウがキャンセルボタンをクリックする 3.1.2.ユーザー一覧画面が表示される 3.2.1.入力情報に誤りがある 3.2.2.誤り情報が表示される 異常パス 3e.1.DBの登録に失敗する 3e.2.登録処理がロールバックされる 3e.3.DB登録失敗の旨が表示される

カルダモンで集中力向上！

カルダモンっていう香辛料があるのですが、このカルダモンには集中力を高める効果があるようで、その効果は摂取1時間以内に起こり、かつ1時間以上持続すことが科学的に検証されています。
 参考文献

私は粉末をコーヒーに入れて飲んでいます。効果は・・・あるような、ないようなｗ
ちなみにカルダモンはカレーに入っていてダイリーガーのイチロー選手は毎朝カレーを食しているとかなんとか。
「ちいさいことをかさねることが、とんでもないところに行くただひとつの道」byイチロー
なるほど！

WINDOWSでネットワークの共有フォルダが見られない（アクセスできない）

今日、新しい人が職場に入ってきたのですがその人が持参したノートパソコンからサーバの共有フォルダが見られないという減少が起きてしまいました。
症状はこんなかんじでした。

• サーバの共有フォルダが見られない
• インターネットは出来る
• 私のPCへのpingは通る
• 私のPCからのpingは通らない

でいつもの用にグーグル先生に聞いてみたらこんなサイトがあったので貼っておく。
ネットワークの共有フォルダに接続できない場合のチェックリスト

結局原因はファイアーウォールでした。

設計～結合テストまでのスケジューリング

今日は私が目安としている設計から結合テストまでのスケジューリングについて書きます。まぁあくまで目安ですし理想論が入ってます。

• 1/3設計
• 1/6コーディング
• 1/4単体テストとデバッグ
• 1/4結合テストとデバッグ

設計が1/3でかなりの時間を割いていますが、バグをつぶすコストは下流工程になればなるほど高くなってしまいます、そしてコーディングする前と後ではコストが大きく変わってきます。また、新しい技術の導入検討なども有りますので設計の時間は多めに取るようにしています。

設計がしっかりしていれば後はひたすらキーボードを叩くだけなのでコーディングは1/6と少なめですね。

そして1/2がテストです。これはテスト仕様書作成やテストコードのコーディング時間も含んでいます。

フロー状態について

何かに夢中になって気がついたら「あれ、もうこんな時間か」てなことが結構あったりするんですが、この夢中になってる状態のことをフロー状態とかゾーン状態とか言うそうです。

フロー状態はすごく集中力が高まっているので生産性がかなり高い状態にあります。
しかし、ちょっとした外部からの刺激でこのフロー状態は解けてしまい再びフロー状態になるには15分以上の時間が必要なのだそうです。

仕事中に質問したりすると質問された人がフロー状態にいた場合、フロー状態が解けて生産性が下がってしまい更にフロー状態に再び入る為に１５分以上の時間を無駄にしていまいます。

だから、うかつに質問したりしない方がいいんです。

私自身このフロー状態って、その通りだなと思っていて聞いた方が早いなと思っても極力しないで自分で調べるようにしています。

こんな話を仕事場でしたら、なんか鼻で笑われてちょっと悔しかったです。

テストケースの上げ方について

今日はテストケースのデータを上げる際に気をつけていることを簡単に書きます。

１．数値のゼロ、文字のブランク
　　これらの値はプログラマが考慮していない場合が多いのでケースに上げています。

２．境界値
　有効な範囲の境界となる値です。例えば３～6が有効な値だった場合、

• 正常ケースで３と６
• 異常ケースで２と７

　を上げるようにしています。

３．意地悪な値
　「１．」と同じような考え方ですが、何とかしてバグを見つけてやる、こんな値は考慮してないだろう、どうだー！？っていう値を考えますｗ。
　
以上です。（たった３つかよ！何か忘れている気がしなくもないですが・・・
箇条書きにするとたった３つですが、この３つが頭に入っていれば十分な品質が確保出来るんじゃないでしょうか？

テスト駆動型開発の基本的な考え方について

今日はテスト駆動型開発の基本的な考え方について書きます。(間違ってたらすいません）
テスト駆動型開発って聞くとすごく難しい感じがしますが、

コードを書く前にテストケースを上げる

ただそれだけのことです。
テスト駆動型開発によって得られるメリットは

• 仕様を把握していないとテストケースが作れない、つまり仕様の理解を深めることが出来る、あいまいな部分をなくすことが出来る。
• 仕様の理解を深めることによってバグが少ない、かつ拡張性が高い、かつメンテナンスしやすい設計が出来る可能性が高くなる。
• 仕様に矛盾や問題があるとテストケースが作れない、つまり仕様書レベルでバグをつぶすことが出来る。

などです。
私が以前関わっていたプロジェクトではテストを自動化し、

1. 仕様書を確認する。
2. テストケースを上げる。
3.  「１.叉は２.」で仕様書に矛盾や問題が有った場合は仕様書を差し戻す。
4. 自動化の為のテストケースコードを記述する。
5. 設計＆実装
6. テストケースを通す。

のような手順で開発して、毎朝その日の最新ソースで全てのテストコードを実行し常に品質を確保していました。