スイーツ（笑）と呼ばないで!!
|
| |||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
11/25/04:40 [PR] |
11/28/18:27 不器用な人こそワーカーホリックになる!?人からワーカーホリックだと言われたりすることがある。
私自身そうだと思うこともある。 実際、仕事大好きだし。 なんでかなー と思うと・・・ 思い当たることがある。 実は・・私・・・不器用なんです。 そうまさに 「自分、不器用っすから・・」 という感じ^ ^ 他人と比べてそんなに優れた能力があるわけでもない。 でも、昔から 誰か人の役には立ちたいなー とずっと思ってきた。 でも、 ピアノを弾いて誰かの心に訴えかけたり、 お医者さんのように誰かの病気を治せるわけでもない。 そんな特殊な能力のない自分にとって、 誰かの役に立つ一番手っ取り早い方法は・・・ 仕事をすること、だと思う。 仕事って、するとお金を貰えるわけだけど、 誰も慈善事業で私にお金なんか寄付してくれない。 お金を貰えるってことは、 少なくともその人にとって役に立つ何かを提供出来た時だと思ってる。 だから・・ 私は仕事が好き。 不器用で、でも誰かの役に立ちたいという気持ちが強い人は、 きっと私みたいな仕事大好き人間、ワーカーホリックになるんじゃないかな。
PR
|
11/28/18:09 非正規化と未正規化は違うDB設計の世界には「正規化」という言葉がある。
より正確にはRDB(=リレーショナル・データベース)の世界に存在する言葉だ。 そして経験の豊かなDB設計者は時々こんな言葉を口にする。 「パフォーマンスを重視して、その項目は"非正規化"しておいた。」 そんな言葉に新人DB設計者はなんとなくカッコ良さを感じる。 「正規化？ 知ってるよ。でも、ここは あ・え・て 正規化したのを崩したの!!」 というロックな感じである。 そうまるで私が 「あー、 私はKY(=空気読めない)ではなく、 AKY(=あえて空気読まない)なので・・」 と答える時のような・・・(蛇足) この「あえて」というのはとても大事だ。 ”非正規化”は、必ず”正規化”の後に発生する作業である。 未だ正規化していないもの、すなわち、”未正規化”と呼ぶものとは似て非なるものなのだ。 頭の中でも良い、必ず1回はきっちり正規化し、それをあえて崩す。 私は非正規化したときには、必ずDB定義書の備考欄に「非正規化」とコメントをいれる。 PGは非常にロジカルな思考をする生き物である。 だから、パフォーマンス等の諸事情から非正規化された状態は一瞬理解に苦しむ・・・はず。 ということで、今日はそんな KY(=空気読めない) と AKY(=あえて空気読まない) は違う・・・ というお話でした。。あれ？
|
11/27/12:29 止まない雨はない物心がついた頃には、
止まない雨はない ということは誰でも知っている。 人が必ず死ぬことも、 日々実感はないけれども、 頭ではわかっている。 でも、 終わらないプロジェクトがないことは、 意外にも信じられていない。 ある他社が関与していた案件で火が吹いている案件があった。 その火消しを頼まれて、 初めてそのお客さんのところに伺った時、 先方の担当者の一人が呟いた。 「いやー、このシステムは完成しないですよ。 このプロジェクトには終わりはないです。」 本気でそう信じているような様子だった。 「だから、正直もうこのシステムに関する会議には出たくないんですよね。」 とその担当者は続けた。 末期症状である。 ヤケになって治療を投げ出している状態。 こんな状態の時は、超たいへん・・。 「大丈夫です。終わらないプロジェクトはないです。」 と言葉で伝えても、いきなりは信じてはもらえない。 経験上、効果的な手法が１つある。 私は 「なるほど。これは確かに大変そうですね。 ちなみに、◯◯さん、 このシステムの見積明細とか機能要件一覧とか、 見たことあります？」 と聞いてみた。 答えは 「発注のタイミングで1回見たかもしれないけど・・・覚えていない」 というもの。 そこで私は提案した。 「じゃ、ちょっと時間かかりますが、見積明細を見ながら、 現在の状態と、それがどうなったらその機能は完成と言えるのか、 ゴールを１つずつ一緒に定義していってみましょう。」 一緒に進めていくと、 「発注したのに"出来ていない"」と思っていたものが実際は発注されていなかったり、 「欲しいのはこれじゃないから"出来ていない”」と思っていたのが、 実は発注内容を担当者が勘違いしていたり、 という認識のギャップが明らかになっていった。 数時間に及ぶこの作業が終わった時、担当者は言った。 「このプロジェクト、終わる気がしてきました。 ゴールが見えたというか、何ができたら完了なんだというのが見えて、 そのために必要な作業は何なのかが見えました」 その時初めて私は言った。 「はい。終わらないプロジェクトは無いです。 共通のゴールが見えたらもう大丈夫です。 これから一緒に頑張って、私たちで良いシステムを作っていきましょう!!」 止まない雨は・・・無い。
|
10/15/11:00 プログラマーをリスペクト!!私は、学生の頃からプログラミングをしている。 最初の作品は中学校の時。 ラインアートと共にディスプレイの四辺を壁に見立ててボールの跳ね返りをシミュレーションするプログラム。 もちろん、社会人になってからもプログラマーとして働いた事もある。 毎日毎日プログラミングしていた。 だから、プログラミングが大好き。 今でも、週末のうち一日は趣味でプログラミングをしている。 本当は、仕事でも書きたいと思う事がある。 でも、絶対に書かない。 それは、プログラマという仕事をプロフェッショナルとしてリスペクトしているから。 だから、わたしは物理的なレベルではほとんどプログラマに指示は出さない。 でも、たまーーに、物理的にレベルの相談をしてもらえる時がある。 これからもプログラマーに対するリスペクトの気持ちはきっと消えることはないと思う。
|
10/12/11:00 LaravelのMigrationsは救世主？最近、ある案件を引き継いだ。 資料もほとんどない。 引き継いだ時には、デモ環境には開発環境と同じ最新のソースと最新のDB定義が適用されていると聞いた。 でも、何かがおかしい。デモ環境で操作していると、あるテーブルの項目が足らないとか、nullはNGというエラーがでる。 そこで、開発環境とデモ環境の定義をmysql_dumpしてdiffってみた。 見事にテーブルの中の複数の項目の型やnot null制約など定義が違う。 そう、この案件は古い案件なのでLaravelを使っていない。 LaravelのMigrationsで定義の変更を管理していれば、 人間は完璧じゃない。だから、なるべく自分を信じないことが大事。 Laravelは期待を裏切らない。我らが救世主。
|