[B! sql] t_yanoのブックマーク

炎上したのでまとめ：ベンチャー社長で技術者で：エンジニアライフ

株式会社ジーワンシステムの代表取締役。新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。炎上したので、論点を整理しておく。 1．業務系では効率がトレードオフできない必要条件業務系の職務では、「効率を求めること」がトレードオフしてはいけない必要条件です（十分条件ではない）。医者でいうならば、「命・健康」と同じ、トレードオフしてはいけない必要条件です。効率が必要条件にならない職業もあるけれど混同してはいけない。 2．SQLはオブジェクト指向言語の数十倍の効率オブジェクト指向言語を使い切るのと、全部staticで宣言してしまうような使い方と比べても、効率は数十％も変わらない。 SQLとオブジェクト指向言語を比べたら、数百～数千％の差が付く。言語や手法を考えるとき、慣れてない人はできないから無限大の工数が掛かる。ですから、できない人を対象に比べても

t_yano 2010/06/02

長くなったのでまとめた http://togetter.com/li/26032

リンク

こういうコードを書く人を... - masayang's diary

The Daily WTF: SQL Error 191: Nested Way Too F#%&ing Deeply SELECT DISTINCT COUNT(Task.RecId) FROM Task WHERE (Task.TaskType = @P514) AND (Task.Status = @P1) AND (Task.RecId is not null) AND (((((((((((((((((((((((((((((((((((((((((((((((((((( (((((((((((((((((((((((((((((((((((((((((((((((((((( (((((((((((((((((((((((((((((((((((((((((((((((((((( ((((((((((((((((((((((((((((((((((((((((((((((((((

t_yano 2010/01/04

そういう風に最初に教えてもらって、それしか方法がないと思い込んで疑問を持たなかった（他の方法を探そうとしなかった）ってことかな。

ネタ
sql

リンク

Martin Fowler's Bliki in Japanese - ThoughtWorksでのRuby

以下の文章は、Martin FowlerによるRuby at ThoughtWorksの日本語訳である。 ThoughtWorksは、2006年から本格的なプロジェクトにRubyを使い始めた。2008年の終わりまでには、Ruby プロジェクトの数は41個になった。この経験から我々は何を学んだのか。QConの講演に備えて、私は調べてみることにした。ここでは、Rubyの生産性、スピード、保守性など、よくある質問に対する現時点での我々の考えについて述べていく。現時点での我々の結論としては、Rubyは十分に使えるプラットフォームであり、様々な形態のアプリケーションに利用することを真剣に考慮すべきである、というものだ。特に、Ruby on Rails を利用したWebアプリケーションにおいてはそうである。最後に、Active Record のテスティングに対する考えなど、技術的な教訓についても触れる。

t_yano 2009/07/13

『私は、プロジェクトのみんなと話すときはいつも、O/RマッピングフレームワークはSQLを80〜90%を隠してくれるが、きちんとしたパフォーマンスを得るにはSQLをいじらなければいけないと言っている』これは正しい。

リンク

XPもいいけれど、先ずはSQLが出来るようになるべき。:なにわのITベンチャー社長Blog - CNET Japan

hisyamadaより: XPの導入をしようとした私はすぐに大きな壁に突き当たりました。それは「全員同席」と「ペアプログラミング」でした。全員同席とはユーザ、マネージャ、開発者が一箇所で開発を行うという考え方で、システム開発のスピードを加速させ、利害関係の不和を解消するために考え出された手法です。特筆すべきは顧客と開発者を同席させると言うもので、開発過程で明らかになる不明瞭な要求や仕様を、同席している顧客に即決させる［続きを読む］ XPもよいと思うのですけれど、弊社はＳＱＬにこだわっています。一般的にＤＢ（ＳＱＬ）のスキルがなさすぎなんですね。弊社の入社試験の変形型で説明します。使われるテーブルは得意先マスタ　　　　得意先コード　　　　得意先名　　　　住所　　　　・・・受注テーブル　　　　受注ＩＤ　　　　受注日　　　　得意先コード　　　　・・・受注明細テーブル

t_yano 2008/09/27

相手のやりたいことを脳内SQL化できることは大事。SQLは集合の言語で、要件を集合化できるのはよいこと。SQLは苦手なのでこういうSQLをぱっと思いつかない。