RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
質問が出ないのは話し手の責任が8割。だから「質問が出る」ようにルールを決めたら、大成功した話。
ちょっと前の話になるんですが、はてな匿名ダイアリー、通称「増田」でこんな記事を読みました。 質問力の付け方 知識がなくて質問できない部分も確かにあるけれど、少し考えれば分かる違和感に気付かないままの時もある。 そして質問しても、後が続かない質問しか出てこない。もしくは、本質的ではない的外れなものしか出てこない。 論議に対してクリティカルに効くような質問が出来ないし、それを引き摺り出すことも能わない。 ベストディスカッション賞を取る質問なんか一生出てこない。 「質問が思いつかない」「いい質問が出来るようになりたい」という増田の話ですね。 当たり前の話なんですけれど、「質問」というのは確かに非常に重要でなんす。 基本、話す側には、「聞き手が何を知らないか」が分かりません。 ゼミだろうが発表会だろうが関係なく、話し手と聞き手の間には、間違いなく知識の溝が出来るものでして、話す内容だけでそれを埋め
最終回 今生きるプログラマーが、この仕事をあこがれのものにする | gihyo.jp
ご好評いただいた本連載も今回で最終回。いつもとは趣向とは変え、竹馬氏がこれまでのインタビューを振り返りながら、未来への展望を綴ります。 一皮むけば高度なコンピュータサイエンスが 今まではインタビュアーとして抑えた感じでやってきましたが、今回は自分のブログ「mizchi's blog」の読者はご存じのような、いつもの感じで行きます。 この連載インタビュー企画の依頼を受けたときの個人的な狙いとして、技術評論社の名前を使って、いつもは会いづらい人に会いに行く口実を作ろう、ということを考えていました。その目的はほぼ達成できたので、関係者諸氏には、とても感謝しています。 ……という個人的なテーマとは別に、僕自身が本連載を通して一貫して表明したい課題感があり、それは「高度なコンピュータサイエンス／プログラミングスキルの現場適用の難しさ」というものです。 僕自身、大学でコンピュータサイエンスを修めたわけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
