満足せる豚。眠たげなポチ。:「業務知識」は目的じゃない
SI業界が開発するシステムの目的は何か？ それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。 スーパークリエイターがSI業界で即戦力になれない理由 もう業務知識幻想は止めようよ。必要なのは課題を適切に設定する能力とその解決に向けてプロジェクトを円滑に進めるプロジェクト遂行能力。その最低限の基盤になるのがコンピュータサイエンスなり、プラットフォームの知識と経験でしょう。（自分も弱いのを棚に上げて言うけどさ。） 一番性質が悪いのが「業務知識」だと思うよ。この言葉も意外に確かなものを伝えていて、所詮知識なんだよね。別にそれを使って仕事をしたわけではないから、業務スキルではなく業務知識。 「業務知識」の意味するところっていうのは、『開発チームの一員としてドメインに精通している（少なくとも文化としての用語がわかり、それが
満足せる豚。眠たげなポチ。:業務システム開発でドキュメントを作ることについて
職場でここ３〜４ヶ月の間、システム再構成のためのドキュメント化プロジェクトというのを進めてきた。その中で『ドキュメントを書く』ということに対する意識が随分自分の中で変化したので、メモしておく。 まずは経緯から。 そのシステムは、いわゆるレガシーなシステムで、十数年来の歴史を持つ。これまで基盤が多少変わることがあっても基本的にソフトウェアアーキテクチャ（どのような単位で機能をモジュール化するか、どのように機能を抽象化し変化に対して柔軟にするか）に変わりはなく、作った当初の設計にツギハギしてメンテナンスを続けていた。 元々は、一体何をすれば増員以外の手段で開発量を上げられるかということを議論していた。現行のアーキテクチャのままでは求められる開発期間とバージョンアップのサイクルに対して近い将来限界を迎えることが明白であったためだ。 今のアーキテクチャや設計に問題があり、メンテナンス性を大いに損ね
満足せる豚。眠たげなポチ。:業務システム開発の世界だってコードの力で変えられる
これ、必読。 業界の重鎮とやらに惑わされるヒマがあったら、一歩でも前に進むために何をするかを考えたい。 山ほどあるサブセットから, どうやって適切な妥協点を選べばいいのだろう. 絡まりあったプラクティスをときほぐして本質に迫る根気と,サブセットの善し悪しを判断するクライテリアを K は持っていた. http://www.dodgson.org/omo/t/?date=20071103 誤解を恐れずに言えば、業務システムの開発において一番面白いのは実はここだ。 プログラミングとは、忠実に正確にまじめにシステムを動かすためのコードを書く作業ではない。 本当のプログラミングとは、コードの力を駆使して問題自体を解消してしまうような仕組みを創造するプロセスだ。その対象が身内なこともあれば、顧客なこともあるだろう。その意味で、「業務システム開発はクリエイティビティを発揮できない」なんていうのは、「私は
満足せる豚。眠たげなポチ。:Asianux Road Show 2007 まつもとゆきひろさん、基調講演のメモ
2007/10/16 Miracle Linux 社開催の Asianux Road Show 2007 へ行ってきた。そのうち、まつもとさんセッションのメモ書き。急いでメモったので、理解が違っているところや聞き漏れ、聞き間違いがありえる。読まれる方は、そこを理解したうえで読んでください。 タイトル Ruby からのメッセージ 自己紹介 プログラマ オープンソース開発者 言語デザイナ 世に言語の種は尽きまじ 一説には数千とも数万とも ほとんどは消えていく アイディアの具現化 いつか自分の言語を 言語を作りたい人は一定数いる Ruby という名の言語も３つ存在する ただ、ほとんどは寿命が短く使われない 作者しかユーザがいない、とか 先端言語と普及言語 言語における対立軸 一般向け／学術向け 最新技術／枯れた技術 先端言語 特定のアイディアに深く依存 応用範囲が狭い アイディアの実用性を証明（
満足せる豚。眠たげなポチ。:お客さんのホントの気持ちに迫るための一言。
たいていの人は自分のやり方というのを持っている。そして、大人にもなると少なからず自分が知らないことがあるというのを認めたくない。だから、システム開発をしているとこんなことがよくある。 「これこれこういう機能のものを作ってくださいよ。」 「その機能ってどんな機能なんですか？」 「うん。それはね、こんな風に動いて、あとはあんな風に動いてくれれば大丈夫です。」 そして、もし言われるがまま作ったものを見せると、きっとこういう答えが返ってくる。 「ちょっとイメージと違うなぁ。これだと○○なとき、困るんですよぉ。」 ちょっと待て。「よぉ」なんて言われてもこっちも困る。 というわけで、要件聞きに言ったのに機能の詳細に突っ込んで話しをして下さる人へはやんわりとこの言葉を使うことにしている。 「そうですよね。今その機能がなくて困っているのはたとえばどんなことなんですか？」 「このシステムを作る目的を教えてく
満足せる豚。眠たげなポチ。:Ruby の include/extend が分からなくなってきた・・・
FileUtils は FileUtils.mkdir といった形で利用ができる。つまり、モジュールの特異メソッドになってるのだけど、module_function を探しても見つからない。 それでもコメントに燦然と輝く "# All methods are module function." の文字。 なんだ？？と思って探し回った結果。↓ そりゃ、そうだぁ。そんなやり方もあったのね。。（あれ、もしかして一般的なの？） というわけでメモ。 クラスメソッド＝クラスの特異メソッド。モジュールメソッド＝モジュールの特異メソッド。 モジュール関数＝モジュールの得意メソッドであり、モジュールの private メソッド。 self.include(other) とすると、Mixinにより self に other のインタフェースが実装される。 self.extend(other) とすると、 ot
満足せる豚。眠たげなポチ。:なぜ顧客は受入テストで仕様変更に気がつけるのか？
「リーンソフトウェア開発」P219から。 システムが、顧客の意図どおり動くことを確認するテストは「顧客テスト」という名前で呼んだ方がよい。それは、テストの目的が、顧客がシステムに期待したとおりシステムが動くことを確かめるためだからである。 そう。そのとおりだ。そして、本書ではその顧客テストを短いサイクルタイムで複数回を行うことでリスクを軽減するというアプローチを取る。 その主張も正しい。一つの解決策として非常に参考になる。 だけど、ここで一つ大きな疑問がある。顧客はなぜ「顧客テスト」をするとしっかり仕様の漏れ、ミスを発見できるんだろう？ ちょうど今日もそうだった。すでにシステムはリリース間近。まさに「顧客テスト」が行われていた。そして発覚した仕様の漏れ。 その対応自体はけっきょく事なきを得たのでここで話題にはしないけれど、不思議なのはその仕様はけして「ビジネス環境の変化」で昨日今日浮上した
満足せる豚。眠たげなポチ。:技術者のための提案書のお手本を読む
Ringo's Weblog さんで紹介されていた Tim Berners Lee の提案書が面白い。一読されることをオススメします。素晴らしい文書をご紹介・翻訳して下さっている ringo さんに感謝。 1990年にTim Berners Leeが提出した、最初のWebブラウザ開発の提案文書は、優れたプロジェクト・マネジメントの手本となる文書である。 と書かれているとおり、何かが目を見張るほど卓越した提案書というわけではないが、非常にバランスが取れ、よく練られた内容の提案書になっている。（特殊な技法が使われていてスペシャルな存在になっているとかいう類ではなくて、ベーシックなスキルの積み重ねで全体として高品質な提案書になっている。） 個人的に好きな点は、 見通し：やりたいこと、やりたくないこと やらないこと の項。 この言い回しは、技術文書だとわりと見かけるのだけど、他の界隈ではあまり見な
満足せる豚。眠たげなポチ。:コンソールアプリケーション用 Ruby フレームワーク SimpleConsole を使ってみた
Ruby の用途が、 業務アプリをばりばり開発！ とかではなくて、 仕事をするなかでちょっと困ったり面倒だったりするときのツール という位置づけな自分にとって、書いているコードはいくつかオプションを指定してコンソールで走らせてやれば終了するようなものがほとんどを占めている。 そうすると、かなり毎度同じような内容を書いていたりして、DRY じゃないなー（けど、自分しか使わないようなのが多いし、ま、いっかー）と感じていた。 そうこうするところに、SimpleConsole というコンソールアプリ用のフレームワークの紹介を読み、「これで解決するんでない？」と期待を持ったので試してみることにした。 SimpleConsole って何？ 紹介をざっと読む限りだと、SimpleConsole は、 オプションの解析とバリデーションを自動でやってくれる Controller と View を簡単に作成
満足せる豚。眠たげなポチ。:Paul Grahamのプログラミング言語観・その３
「Paul Grahamのプログラミング言語観・その１」と「Paul Grahamのプログラミング言語観・その２」の続き。 昨夜書き終えてストックしていたネタなのだが、うちにしてはめずらしく気の利いたタイミングでのエントリとなった。 プログラミング言語はデザインをするものを妨げるべからず これは、やりたいことだけに集中できるということだ。プログラミングは創造的作業だ。プログラマが本来やるべきは、ソフトウェアをデザインすることで、そのために力を注ぐべきである。 プログラムというものは、証明のように、もともと様々な間違いの枝がそこいらじゅうに生えていた木の枝をきれいに刈り込んだものだ。だから言語の良さを測るには、完成したプログラムがどれだけ綺麗かを見るだけじゃだめで、プログラムが完成へと至った道筋がどれだけ綺麗だったかをみなければいけない。 from "デザインとリサーチ ---Design
満足せる豚。眠たげなポチ。:タイムマネジメントをするということ
基本は、ドラッカーの「経営者の条件」の第二章に集約される。 時間の使われ方を実際に記録し、 やるべき仕事以外のもの(やらなくてよい仕事ではない)に手を付けるのを止め、 残った時間をまとめ、大切なことに集中する時間を作る これは話としてはわかっていた。優先順位ではなく、劣後順位を付ける。 でも、この話がわかっても、実践できていたかというとできていなかった。 それが、次のことを意識するようにしたことで劇的に改善した。 それは、仕事には、 定量的な仕事(一定の時間やれば確実に終わり、かかる時間も読みやすい仕事) 定量的でない仕事(一定のところまでやれば終り、というのがはっきりしない仕事) と、 やりたい仕事・好きな仕事 やりたくない・気の進まない仕事 があるということ。 そして、その中で、 やるべき仕事 それ以外の仕事 があるということ。 これらの優先順位はこのようになる。 やるべきで、定量的な
満足せる豚。眠たげなポチ。:Ruby on Rails 入門を購入
くまくまーの中の人が書いた Ruby on Rails 入門が気になっていたので、仕事帰りに本屋で購入。(既発の Rails 本が全部置いてあった職場近くの本屋は正直どうなんだとちょっと疑問に思った。それだけ Rails が浸透したのか?) 肝心の本を2時間くらいで読了したわけですが、かなり良い出来でした。2冊目の Rails 本に一押し。1冊目なら、大人しく AWDwR の前田修吾さん監訳版なんかを購入しておいた方が安全と思われます。 それにしても、舞波はさておき、ActiveSupport から始まる Rails の解説というのもこだわりが感じられ、とにかく今この瞬間の Rails を切り取った本としては最高に面白い仕上がりでした。「 Pragmatic Programmers の Ruby 本 + レシピブック」みたいなかんじで、「 AWDwR + 舞波本」というかんじのポジション取
満足せる豚。眠たげなポチ。:岡本吏郎さんの「会社の数字がカラダでわかる!」
岡本吏郎さんの「会社の数字がカラダでわかる! 〜会計するカラダのススメ〜」を読みました。 基本的には会計の本なのですが、それ以上に会計の話を通して、マネジメントということについての思想を伝えようとする。そんな本です。 管理するのでも、コントロールするというのとも少し違います。何もかもを自分が手を出すことはできない中で、正しい方向へ行っているのか否かというのを、どのように判断するのか。そのための知恵が詰まっています。 これはまさに知恵の本です。とにかく実際に必要なことは何か。会計ということが現実的に役に立つためには、一体何をする必要があって、何はする必要がないのか、それはなぜか。そんな「知恵」が書かれています。 一方で、会計についての「知識」はとても手薄です。必要ないから薄いのでしょう。試験に答えるための会計を知りたいからとか、知らないと恥ずかしいから、というような動機でこの本を読むのはオス
満足せる豚。眠たげなポチ。:Pathname で遊んでみる
require 'pathname' class Pathname def /(path) self + path end end def method_missing(name, *args) name.to_s end root = Pathname.new '/tmp' root/foo/bar # => #<Pathname:/tmp/foo/bar> (root/bar/foo).parent.children # => [#<Pathname:/tmp/foo/bar>, #<Pathname:/tmp/foo/baz>]
満足せる豚。眠たげなポチ。:Enumerable#shuffle
# random_index.rb class RandomIndex def initialize(size) @indexes = Array.new(size) { |i| i } end def next @indexes.delete_at(rand(@indexes.size)) end end # enumerable_shuffle_method.rb module Enumerable def shuffle(seed = nil) srand(seed) if seed require 'random_index' entries = self.entries # for chache indexes = RandomIndex.new(entries.size) shuffled_entries = [] while index = indexes.next shuf
満足せる豚。眠たげなポチ。:外部インタフェースのコードと内部実装のためのコードを分離する
１０年来の業務プログラムなので、いろいろ経緯があって今の形なのは仕方がないと思うけど、よくない設計に何も言わないとそのまま次の１０年も過ぎ去りそうなので指摘してしまおう。 今後、コードをデータとして持つときは、次の二点を考慮して扱ってください。 外部インタフェースであるコード（ユーザの都合で変わるコード）と内部の実装で取りまわすためのコード（identifier）は別にすること 他システムは自分のシステムから見たらお客さんであり、コードがお客さんの都合に左右されることを考えたら、他システムで使うコードもやっぱり内部の実装からは切り離した設計にすること たとえば、こんなシステムの話です。GUIからコードとその名称を入力値として受け取り、DBへ一時保存します。そして、あるタイミングでそのコードを他システムへ送信します。送信された先ではそのコードを使って集計・分析をします。 こんなときに、現在の
満足せる豚。眠たげなポチ。:優れたハッカーによるSIは本当に理想図なのか
Life is beautifulさんの ソフトウェアの仕様書は料理のレシピに似ている 知的労働者には「組織を移る力」がある を読んでの感想。 あと、併せて読んだ話は下の二つ。どこかで話が重なる部分があるかも。 浮ついた「ギーク」への説教（※老害注意） プログラマとして 産業としてのSIerについて語りたいのか、プログラミングスタイルについて語りたいのか。それはさておくとしても、少なくとも誰のために何を作る話をしているのかははっきりしないと意味がないんじゃないかと思います。 もちろん、一般論としてのプログラミングスタイルとしてどちらがより優れたものが作れるのかなんていうのは議論するまでもないです。 ただ、その上でスケールしやすいパッケージ系のソフトウェアビジネスについての話なのか、それとも儲けの上限が決まっていて一人一殺形式だからスケールしにくいSIビジネスについての話なのか、というのはは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
満足せる豚。眠たげなポチ。:エンジニアの欠点
満足せる豚。眠たげなポチ。:これはアンチパターンな予感。
DB設計で迷ったことのある方に。