Programmers Office

イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき (Harvard business school press) クレイトン・クリステンセン おすすめ平均 破壊的イノベーションについての名著 破壊的イノベーションには感動！ 優良企業、優秀な経営者は技術革新に滅ぼされる？ チャレンジャーの為の名著だと思う 大企業は本当に破壊的イノベーションを活かせないのか？ Amazonで詳しく見るby G-Tools <h4> カンタム </h4> <p> いきなり余談・・・。本書の題材の中心はHDDメーカーなのですが、その中でカンタムの名前が何度か出てきて、妙に懐かしい。<br />入社前に割引でパソコンを買ったのですが、当時はWindows95が出たてのほやほや。まずは壁紙を花見にしてマインスイーパーをしますよね。でもすぐに<a href="http://www.amazon.co.jp/gp/redirect.html%3FASIN=4756130151%26tag=konnokiyotaka-22%26lcode=xm2%26cID=2025%26ccmID=165953%26location=/o/ASIN/4756130151%253FSubscriptionId=0G91FPYVW6ZGWBH4Y9G2" target="_blank">Run Run Linux </a>を買ってインストールしました（ってこの本まだ売ってるのかい！！）。情報処理試験なるものを受けたほうがよいのかな、C言語を勉強しないといけないんだ、LinuxなんかのUnix系だと無料で環境が入っているらしい、という短絡思考です。<br />で、Linux入れるのはなかなか容易でなく、HDDも自分でちゃんとメーカー・型番まで分かって選ばないといけないんですよね。というわけで、<b>QUANTUM</b>が脳裏に残っているわけです。 </p> <h4> 技術 </h4> <p> 前半で「技術」の定義付けがあって、それをインプットからアウトプットを生み出すプロセスとしてとらえています。さらに後半ではプロセスとリソースを区分けしていて、リソースは交換可能だが、プロセスはその組織に根付いている（だから、コンサルティング会社などは激しく人が入れ替わるが組織としての価値を保ち続けている）。<br />似た話だと思いますが、組織の能力とその組織で働く人材の能力の区分けもされていて、組織としての能力はプロセスと価値基準だと。<br />プロセス改善という言葉をちょっと軽く使っていたなと思います。単に改善ではなくプロセス改善。その組織が持つ技術の向上。 </p> <h4> Excel </h4> <p> では破壊的技術はどこから生まれるのよ、という時に一番分かりやすかったのがExcel。機能で言えば、市場の需要を大幅に超えてしまっているわけで、下から侵食するチャンスだという話。Googleやら何やらあるわけですが、ただ、ファイルの流通という問題があるからそう簡単にはいかない。しかし、危険な臭いはしますよね。 </p> <h4> 「存在しない市場は分析しえない。破壊的技術の用途となる市場は、開発の時点では単に分からないのではなく、知り得ない。」 </h4> <p> この表現は何かに近いぞ。そしてそれに対処するための方法として本書が勧めるのが、小規模な組織が小さな失敗と小さな成功を繰り返して学習を重ねること。近い！ </p>

私たち（？）ヘルプとかマニュアルとか書くの、あまりうまくないですよね。 けど、「相手の身になって考えてみろ」「運用を考えろ」みたいな言葉にちょっと反抗期。 ただ、それらはちゃんと書くことによって、仕様を深く考えることに貢献するし、テストのレベルも上がると思うし、メンテのときにも役立つし、要するに自分にちゃんと返ってくるんじゃないかなという独り言。

色々作るのも、最近は忙しい＋モチベーションが上がらなかったのですが、そういうときは外に出るべし、ということで、ちょっと調べてみました。 オープンソースにするのはライセンスとかももう少しちゃんと勉強しないと怖いので徐々にという感じですが、それでも外にソース置場がほしいなと。 CodeReposはまだちょっと度胸ないし、他も決め手がないなという中で、決め手があったのがOrigo。 http://www.origo.ethz.ch/wiki/origo 何が決め手かというとVisualStudio用プラグインが用意されているということ。 ところが、それに関しては、私の環境が元々ちょっとおかしくて、うまく動いてくれませんでしたという落ち。まあいいです。 全般的には、wikiベースでちょっとその手のものへの慣れは必要かなという印象。 トラッキング（Issues）に関しては、レポートのフォーマットが下記のように書かれていてよい感じ（って普通そういうものですか？Tracとか使ったことないので）。 What steps will reproduce the problem? What is the expected output? What do you see instead? What version of the product are you using? On what operating system? Please provide any additional information below: また、レポートの分類（bugとかenhancementとか）が決められておらず、一瞬どうかと思いましたが、Tagsがあるので、そこに書けばよさそうです。むしろそれはいいかも。 バージョン管理はsvnです。まだつないでませんが。どっちみちソース管理するならこういうところを使うことを考えておくのもよいなと思いました。その意味で、Origoは、オープンソースだけでなく、クローズソースも歓迎されているのもポイントかも。 （参考） ソフトウェア開発ホスティングWeb APIクライアント「Origo API Client」 （作ってみたプロジェクト） http://eventmanager.origo.ethz.ch/

グリモン第二弾。 MOONGIFT:Google Readerを便利に「Better Google Reader」 Preview buttonがよさげです。

ナベアツを書いているときに14でアホになってしまうという現象が起きて、ちょっと悩みました。原因は ret = IIf(((i mod 3) = 0) Or (Instr(CStr(i),”3″) > 0),ToAho(CStr(i)),CStr(i)) と書くべきところを ret = IIf(((i mod 3) = 0) Or (Instr(ret,”3″) > 0),ToAho(CStr(i)),CStr(i)) と書いていたからです。これだと14がアホになる他、30番台のいくつかではアホにならないという障害になります。テストで気づいたからよかったのですが、仮に10までしかテストしていなかったら気付かなかった可能性があります。ヒヤリハットみたいなものなので、仮に10までしかテストしなくて障害を起こしてしまったとして（あるいはテストしたけど気づかなかったとして）、二度とこのような問題を起こさないように根本原因を解消しておきたいと思います。 根本原因を探る際に、なぜなぜ5回というのがありますが、なぜなぜを「なぜ発生させてしまったか（なぜそのような記述をしてしまったか）」と「なぜ流出してしまったのか（なぜテストで防げなかったのか）」という観点があるというのが面白かったので、そんな感じでやってみます。 一つの参考として：「なぜなぜ分析」手法 実践セミナー 「なぜなぜ分析」手法 実践セミナー（PDF） なぜ発生させてしまったか (1)Dimで初期化されると思い込んでいた (2)思い込みのため初期化しなかった（現状もしていない！危険！） (3)最初は「3の倍数のとき」という条件のみで記述して、後から「3のつく数字のとき」という条件を追加したが、その際当初のToAhoメソッドで使っていたInstr(ret,…という記述をコピペした (4)CStr(i)は変数に入れてから使おうかと一瞬思ったが、まあこの程度はいいかと思った（現状もそうだ！） なぜ流出してしまったか (1)10までテストすれば十分だと思った (2)14は3の倍数だと勘違いした (3)OKボタンを連打して確認したので、期待値と異なる値になっていることを見逃した 発生させないための対策 (1)宣言の直後に必ず初期化する (2)宣言と同時に初期化できないVB Scriptは使用しない (3)宣言に対応する初期化があるかを機械的にチェックする (4)関数の入れ子が複雑になるような場合は戻り値をいったん変数に入れてから引数として渡す (5)前後関係等に依存する値は裸で使わずいったん変数に入れてから引数として渡す (6)各ステップ毎に期待する動作になっていることを確認しながら記述する (7)誤りの再利用を避けるためすぐに対策を取っておく 流出させないための対策 (1)どこまでテストすれば品質が保証されるかを、テスト仕様を決める際に論理的に導き出す (2)原則として考えられる全パターンをテストする。例外的にリソース上の問題等で全パターンテストができないときは、論理的に絞り込みを行う (3)テスト仕様を作成する際にはInとOutをデータとして準備する こんなことを考えてみると、いろいろ感じることがあります。 ・発生させないための対策の方がコストが小さそう ・もっとも、発生させないための対策(5)は言うほど簡単ではない ・発生させないための対策の方が適用範囲が広そう ・流出させないための対策の方が「ちゃんと対策をとりました」と言いやすそう ・対策の中には、発生対策の(2)のように、いろいろな理由で取りえないものもある ・「必ず」のような精神論的対策は実際は無意味（今回もさらすにあたって結構気は使っているのにこの有様） ・論理的絞り込みは結構難しそう（現在のロジックは2桁までの仕様ですが、では3桁に対応しようとした際にテスト範囲を論理的に決めうるかはなかなか難しいような気がする）。それよりも、徹底的な自動化で全パターンやってしまう方が良いような気がする。

床屋の時間を待ちながら、1000speakersを見ながら、漫画喫茶でナベアツ。 なんてすてきな休日・・・ nabeatsu.vbs — MsgBox "3の倍数と3のつく数字のときにアホになり、5の倍数のときに犬っぽくなります。（40までいくよ）" Dim i For i = 1 To 40 Dim ret ret = IIf(((i mod 3) = 0) Or (Instr(CStr(i),"3") 0),ToAho(CStr(i)),CStr(i)) ret = IIf((i mod 5) = 0,AddDog(ret),ret) MsgBox(ret) Next Function ToAho(str) Dim ret ret = str If Len(ret) = 2 Then ret = Left(ret,1) & "じゅう" & Right(ret,1) ret = Replace(ret,"1じゅう","じゅう") End If ret = Replace(ret,"1","いてぃ") ret = Replace(ret,"2","にぃ") ret = Replace(ret,"3","しゃん") ret = Replace(ret,"

デブサミも行けず、ITpro Expoっていつの話だよ、という感じですが、資料を放っておいても邪魔なので、整理。 そんな中から「ワークフロー」というキーワードを掲げている製品をまとめ。 サイボウズ ワークフロー for ガルーン 2 ****X-point – ウェブフォーム・ワークフロー “エクスポイント” desknet’s MajorFlow for.NET パソコン決裁DocGear

からすみを　炙って食べると　異様にうまい ライターであぶってもいいんですよ。

tpircsさんに背中を押され、入れてみました。 Webブラウジングを快適にするAutoPagerize を参考。 ちょっとキモイ感じがいい感じ♪

こんな表から  こんな出力を得たい  借方・貸方を横に並べて、借方だけある場合は貸方NULL、貸方だけある場合は借方NULL、みたいな感じ。 — SELECT 借方仕訳.伝票番号 , 借方仕訳.行番号 , 借方仕訳.科目 AS 借方科目 , 借方仕訳.金額 AS 借方金額 , 貸方仕訳.科目 AS 貸方科目 , 貸方仕訳.金額 AS 貸方金額 FROM ( SELECT 伝票番号 , 行番号 , 科目 , 金額 FROM 仕訳サンプル WHERE 貸借区分 = ‘借’ ) AS 借方仕訳 LEFT OUTER JOIN ( SELECT 伝票番号 , 行番号 , 科目 , 金額 FROM 仕訳サンプル WHERE 貸借区分 = ‘貸’ ) AS 貸方仕訳 ON 借方仕訳.伝票番号 = 貸方仕訳.伝票番号