株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 炎上したので、論点を整理しておく。 1．業務系では効率がトレードオフできない必要条件 業務系の職務では、「効率を求めること」がトレードオフしてはいけない必要条件です（十分条件ではない）。医者でいうならば、「命・健康」と同じ、トレードオフしてはいけない必要条件です。 効率が必要条件にならない職業もあるけれど混同してはいけない。 2．SQLはオブジェクト指向言語の数十倍の効率 オブジェクト指向言語を使い切るのと、全部staticで宣言してしまうような使い方と比べても、効率は数十％も変わらない。 SQLとオブジェクト指向言語を比べたら、数百～数千％の差が付く。 言語や手法を考えるとき、慣れてない人はできないから無限大の工数が掛かる。ですから、できない人を対象に比べても
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 (((((((((((((((((((((((((((((((((((((((((((((((((((( (((((((((((((((((((((((((((((((((((((((((((((((((((( (((((((((((((((((((((((((((((((((((((((((((((((((((( ((((((((((((((((((((((((((((((((((((((((((((((((((
以下の文章は、Martin FowlerによるRuby at ThoughtWorksの日本語訳である。 ThoughtWorksは、2006年から本格的なプロジェクトにRubyを使い始めた。2008年の終わりまでには、Rubyプロジェクトの数は41個になった。この経験から我々は何を学んだのか。QConの講演に備えて、私は調べてみることにした。ここでは、Rubyの生産性、スピード、保守性など、よくある質問に対する現時点での我々の考えについて述べていく。現時点での我々の結論としては、Rubyは十分に使えるプラットフォームであり、様々な形態のアプリケーションに利用することを真剣に考慮すべきである、というものだ。特に、Ruby on Rails を利用したWebアプリケーションにおいてはそうである。最後に、Active Record のテスティングに対する考えなど、技術的な教訓についても触れる。
hisyamadaより: XPの導入をしようとした私はすぐに大きな壁に突き当たりました。それは「全員同席」と「ペアプログラミング」でした。全員同席とはユーザ、マネージャ、開発者が一箇所で開発を行うという考え方で、システム開発のスピードを加速させ、利害関係の不和を解消するために考え出された手法です。特筆すべきは顧客と開発者を同席させると言うもので、開発過程で明らかになる不明瞭な要求や仕様を、同席している顧客に即決させる［続きを読む］ XPもよいと思うのですけれど、弊社はＳＱＬにこだわっています。 一般的にＤＢ（ＳＱＬ）のスキルがなさすぎなんですね。 弊社の入社試験の変形型で説明します。 使われるテーブルは 得意先マスタ 得意先コード 得意先名 住所 ・・・ 受注テーブル 受注ＩＤ 受注日 得意先コード ・・・ 受注明細テーブル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
