昨日は、Lotus夜Dayに行ってきました。私はこういうイベントに参加するのは初めてなのですが、とても楽しかったです。参加された皆様、お疲れ様でした。主催の茶坊主さんも完璧な進行をありがとうございました。
Notes/Domino担当者としても、様々な面白いお話や、ネタに出会うことが出来て感動だったのですが、私が感動したのは、次のネタです。
「ドラッグ＆ドロップした複数の添付ファイルを、正しいファイル名順に並ばせたい」
実はこのテーマは、お馴染み、Alan Lepofskyのコネタブログでも言及されています。
Quick way to reorder attachments
当時はこのリンクを読んで、あー、なるほど、そんな使い方があるかーと思ったものでした。
ところが、昨日参加された方は、もっとスマートな方法を目にされたかと思います。私も知りませんでしたし、私の周りのマニアたちも知りませんでした。平塚さんのアイディアなので、ここの場で私から書くことはしませんが、きっとすぐに広まるのではないでしょうか。Alanにも教えてあげたいです。
2006/11/16
2006/10/31
ブックマークバーからのアプリケーション起動
今日は、こんなTechnoteを見つけました。
How to create a bookmark which opens up an application outside of Notes
ブックマークバーからアプリケーション起動が出来たら嬉しい、と思ってる方はいらっしゃるでしょうか。上記エントリでは、その方法についてが記述されています。
ブックマークバーへのエントリは、bookmark.nsf の UserBookmarkOrder というアウトラインが実体になっているのですが、こうやって文書として記述されていないと、なかなか bookmark.nsf から探し出すのは大変です。
私の場合、ワークスペース（＆レプリケータ）を使ってDBアクセスしていますが、ブックマークバーは「現在使っている文書のブックマーク」として活用しており、かなり頻繁に追加と削除を繰り返しています。
以前、大量の文書を選択したまま、1文書のつもりで間違えて全部をブックマークバーにドラッグ＆ドロップしてしまい、大量のブックマークエントリを作ってしまったことがありました。当時はこのUserBookmarkOrderを知らなかったので、一括削除が出来ずに泣く思いで１つ１つエントリを削除していたのですが、結局諦めて bookmark.nsf 自体を再作成しました・・・。
（関連話）UserBookmarkOrderは、デフォルトページをワークスペースにしたい時に、触られた方もいらっしゃるかもしれません。
Setting the Workspace To Launch as the Home Page in the Notes R5 or 6 Client
How to create a bookmark which opens up an application outside of Notes
ブックマークバーからアプリケーション起動が出来たら嬉しい、と思ってる方はいらっしゃるでしょうか。上記エントリでは、その方法についてが記述されています。
ブックマークバーへのエントリは、bookmark.nsf の UserBookmarkOrder というアウトラインが実体になっているのですが、こうやって文書として記述されていないと、なかなか bookmark.nsf から探し出すのは大変です。
私の場合、ワークスペース（＆レプリケータ）を使ってDBアクセスしていますが、ブックマークバーは「現在使っている文書のブックマーク」として活用しており、かなり頻繁に追加と削除を繰り返しています。
以前、大量の文書を選択したまま、1文書のつもりで間違えて全部をブックマークバーにドラッグ＆ドロップしてしまい、大量のブックマークエントリを作ってしまったことがありました。当時はこのUserBookmarkOrderを知らなかったので、一括削除が出来ずに泣く思いで１つ１つエントリを削除していたのですが、結局諦めて bookmark.nsf 自体を再作成しました・・・。
（関連話）UserBookmarkOrderは、デフォルトページをワークスペースにしたい時に、触られた方もいらっしゃるかもしれません。
Setting the Workspace To Launch as the Home Page in the Notes R5 or 6 Client
2006/10/13
ウェブ進化論と医療崩壊
Notes/Dominoには直接関係ありませんが、いくつか書きたいことが重なったので記しておきます。
きっかけは、RSSリーダーで読んでいたこの記事でした。
My Life Between Silicon Valley and Japan - 日経BP・BizTech図書賞を受賞しました。
もちろんウェブ進化論は読んだことがあったのですが、「医療崩壊」という本は初めて知りました。ここにあるとおり、日経BP・BizTech図書賞を受賞した3本の中の１つのようです。
日経BP・BizTech図書賞に「ウェブ進化論」など：ITpro
そこで例によって早速図書館に行って借りてきました。こちらの本です。
Amazon.co.jp： 医療崩壊?「立ち去り型サボタージュ」とは何か: 本: 小松 秀樹
さて、この本は普段読書の習慣がない私が、まさに生まれて初めて引きつけられるように読んだ本かもしれません。家族に医者を持つ身として、また長いこと病院にお世話になった身として興味深かったことも事実ですが、何より筆者の語り口、また類似の問題がIT業界にも多数あることなど、多々共感出来たことが幸せだったのだと思います。
この本の気持ちよいところは、筆者が自身の意見を非常に明確に述べており、必ず意見が分かれそうなところも、理由を付けた上で自身の意見を明確にしているところです。また、その論理的思考には非常に気持ちよく、自分の思考回路に共鳴出来るものでした。さらに、よい倫理観の角度で、社会的なマクロの視点と現場的なミクロの視点から見事に１つの意見を作り上げています。あまりに優秀すぎるのですが、まるで自分の父親ではないかと思うくらい親近感を覚えました。
筆者の小松先生は中で現在の医療現場に関して、様々な問題点を指摘しているのですが、それがIT業界の問題点に接近していることが、自分に刺激的だった理由の１つだと思います。
例えば「人は誰もが間違える」とか「安全とコスト」とか、また発生する過失に対する社会的反応はIT業界にとって今後恐ろしいテーマのような気がします。
と、そんなこんなで刺激を受け、まずは身近な人にこの本を教えてあげたいな、と、自分のmixiの日記にぼそっと書きました。そこの感想の１つに「ウェブ進化論なんかより、よっぽど面白いと思った」と書きました。自分にとってウェブ進化論は同一業界だったので、興味深くはあるし楽しく読んだのですが、衝撃が違いましたので。
これがよかったのか悪かったのか、ふと気がつくと（私は普段足あととかアクセスログとか全く気にしない人なのですが）、梅田望夫さんご本人からアクセスを頂きました。
最初は書評を求めて、定期的なキーワード検索＆巡回を行っているのかと思ったのですが、mixiなど足あとが残る場合、むしろ「梅田さんが書評を読む」という事実以上に、「梅田さんに自分の日記を読んでもらえた」という効果のほうが高いのではないかと思いました。ここで思い出したのが以下の意見です。
コラボレーション・エンジニアの考える日々 - 足あと機能の実装
なるほど。私のケースでは、医療崩壊を褒めるために、ウェブ進化論を利用してしまったので、ちょっと後ろめたい気持ちもありますが、一般的にはやはり効果は大きいのかもしれません。
（なお、ウェブ進化論は発売日近くにAmazonで購入させて頂き、面白くて一気に読んだということを補足しておきます。）
きっかけは、RSSリーダーで読んでいたこの記事でした。
My Life Between Silicon Valley and Japan - 日経BP・BizTech図書賞を受賞しました。
もちろんウェブ進化論は読んだことがあったのですが、「医療崩壊」という本は初めて知りました。ここにあるとおり、日経BP・BizTech図書賞を受賞した3本の中の１つのようです。
日経BP・BizTech図書賞に「ウェブ進化論」など：ITpro
そこで例によって早速図書館に行って借りてきました。こちらの本です。
Amazon.co.jp： 医療崩壊?「立ち去り型サボタージュ」とは何か: 本: 小松 秀樹
さて、この本は普段読書の習慣がない私が、まさに生まれて初めて引きつけられるように読んだ本かもしれません。家族に医者を持つ身として、また長いこと病院にお世話になった身として興味深かったことも事実ですが、何より筆者の語り口、また類似の問題がIT業界にも多数あることなど、多々共感出来たことが幸せだったのだと思います。
この本の気持ちよいところは、筆者が自身の意見を非常に明確に述べており、必ず意見が分かれそうなところも、理由を付けた上で自身の意見を明確にしているところです。また、その論理的思考には非常に気持ちよく、自分の思考回路に共鳴出来るものでした。さらに、よい倫理観の角度で、社会的なマクロの視点と現場的なミクロの視点から見事に１つの意見を作り上げています。あまりに優秀すぎるのですが、まるで自分の父親ではないかと思うくらい親近感を覚えました。
筆者の小松先生は中で現在の医療現場に関して、様々な問題点を指摘しているのですが、それがIT業界の問題点に接近していることが、自分に刺激的だった理由の１つだと思います。
例えば「人は誰もが間違える」とか「安全とコスト」とか、また発生する過失に対する社会的反応はIT業界にとって今後恐ろしいテーマのような気がします。
と、そんなこんなで刺激を受け、まずは身近な人にこの本を教えてあげたいな、と、自分のmixiの日記にぼそっと書きました。そこの感想の１つに「ウェブ進化論なんかより、よっぽど面白いと思った」と書きました。自分にとってウェブ進化論は同一業界だったので、興味深くはあるし楽しく読んだのですが、衝撃が違いましたので。
これがよかったのか悪かったのか、ふと気がつくと（私は普段足あととかアクセスログとか全く気にしない人なのですが）、梅田望夫さんご本人からアクセスを頂きました。
最初は書評を求めて、定期的なキーワード検索＆巡回を行っているのかと思ったのですが、mixiなど足あとが残る場合、むしろ「梅田さんが書評を読む」という事実以上に、「梅田さんに自分の日記を読んでもらえた」という効果のほうが高いのではないかと思いました。ここで思い出したのが以下の意見です。
コラボレーション・エンジニアの考える日々 - 足あと機能の実装
なるほど。私のケースでは、医療崩壊を褒めるために、ウェブ進化論を利用してしまったので、ちょっと後ろめたい気持ちもありますが、一般的にはやはり効果は大きいのかもしれません。
（なお、ウェブ進化論は発売日近くにAmazonで購入させて頂き、面白くて一気に読んだということを補足しておきます。）
dbcache flushのスペリング
Dominoサーバーの割と重要なコマンドに、「dbcache flush」なるものがあります。特に手元で検証しているときなどは、頻繁に使ったりします。
ところで、私だけかもしれませんが、この「flush」という単語が実は、flushだったかflashだったか、なかなかスペリングが覚えられません。
という、悩みを長年抱えてきたのですが、本日私の悩みは解決しました。
実は、このコマンドは「db f」という省略形があったのです。これで、flushのスペルに悩むことはなくなりそうです。
この情報は、下記の technote を読んでいて発見しました。
Domino server console command abbreviations
この他にも、コンソールコマンドと省略形が紹介されています。使ったことのないコマンドもありますし、省略形を知らないコマンドもありました。それほど数多いものではないので、目を通してみるのも面白いかと思います。
ところで、私だけかもしれませんが、この「flush」という単語が実は、flushだったかflashだったか、なかなかスペリングが覚えられません。
という、悩みを長年抱えてきたのですが、本日私の悩みは解決しました。
実は、このコマンドは「db f」という省略形があったのです。これで、flushのスペルに悩むことはなくなりそうです。
この情報は、下記の technote を読んでいて発見しました。
Domino server console command abbreviations
この他にも、コンソールコマンドと省略形が紹介されています。使ったことのないコマンドもありますし、省略形を知らないコマンドもありました。それほど数多いものではないので、目を通してみるのも面白いかと思います。
2006/10/04
グループ文書のメンバーソート
コネタです。
IBM - Is it possible to sort the Members listed in a Group document?
グループ文書の中につめこんだメンバーをソートする方法です。
方法といっても、「メンバーのソート」というアクションボタンがあって、編集モードでクリックするだけ、という極めてシンプルなものです。
グループ文書のメインテナンスの方法というのも、各ドメインそれぞれ、いろいろなアイディアで運用されていると思いますし、例えば「追加は必ず最後に加える」みたいなルールがある場合は、ソートすると折角の時系列が崩れてしまいますが、ソートのニーズもあるのではないかと思います。
ちなみに、「ソートってどうやっているんだろう」とふと思ってしまうわけですが、デザイナーで確認すると思いっきり「Call QuickSort(FieldList)」と書いてありました。スクリプトライブラリのCommonライブラリに、ソート処理関数がLotusScriptで書いてあります。大きいところをクイックソートで、小さいところをインサートソートで、と、アルゴリズムも教科書以上に実際のコードは複雑なものなのですね。
IBM - Is it possible to sort the Members listed in a Group document?
グループ文書の中につめこんだメンバーをソートする方法です。
方法といっても、「メンバーのソート」というアクションボタンがあって、編集モードでクリックするだけ、という極めてシンプルなものです。
グループ文書のメインテナンスの方法というのも、各ドメインそれぞれ、いろいろなアイディアで運用されていると思いますし、例えば「追加は必ず最後に加える」みたいなルールがある場合は、ソートすると折角の時系列が崩れてしまいますが、ソートのニーズもあるのではないかと思います。
ちなみに、「ソートってどうやっているんだろう」とふと思ってしまうわけですが、デザイナーで確認すると思いっきり「Call QuickSort(FieldList)」と書いてありました。スクリプトライブラリのCommonライブラリに、ソート処理関数がLotusScriptで書いてあります。大きいところをクイックソートで、小さいところをインサートソートで、と、アルゴリズムも教科書以上に実際のコードは複雑なものなのですね。
2006/09/22
Teamstudio Japan Blog
今、私が活動しているところで、Analyzerの監査フィルタをみんなの知恵を出し合って上手いこと作れたらいいね、など、TeamStudio関連な話をよくしているのですが、情報源の１つとしてBlogがあるということを本日教えてもらいました。Katoh-sanがんばってらっしゃいます。
Teamstudio Japan Blog
早速、私もRSSリーダーに登録しておきました。
＃と宣伝しておいてから・・・。あーごめんなさい、RSSのリンクがおかしいみたいです・・・。
Teamstudio Japan Blog
早速、私もRSSリーダーに登録しておきました。
＃と宣伝しておいてから・・・。あーごめんなさい、RSSのリンクがおかしいみたいです・・・。
2006/09/17
アイディアを出し合うということ
直接Dominoとは関係ありませんが、先日のビジネスディナーにて激しい意見交換を行ったときに思ったことです。
私は昔からわりとくだらないアイディアを考えるほうだったのですが、それを知人に話すとかなりバカにされるので、最近はとても控えめになってしまってました（日本人は、こういうときなかなか褒めてくれないのですよね）。でも、優秀な方々のアイディアを聞いて、やはり様々なことを考えて、アイディアを出してみるというのは重要なのだなと思いました。とってつけたように書くと、Notes/Dominoの利用って、アイディアが重要なところが結構あると思います。
いろいろなことを考えたものですが、恥を忍んで今覚えている主要なアイディアを書いてみます。あまり本気ではないので、突っ込まないで下さい。
1. ノートPCの充電
喫茶店や電車などでノートPCを開く人は、バッテリーがどれだけ長持ちするかが気になるかと思います。時間としては長持ちすればするだけよい。
そこで、考えたのですが、外部から受けるエネルギーを何らかの形で蓄積出来ればよいのではないかと。で、１つの形として、キーボードタイプの力など無駄なエネルギーがありそうで、少しでもこの力で充電出来ればどうだろう、というのが提案です。さんざんバカにされてます。他にもいくつか変形版があるのですが。
2. ノートPCの両面ディスプレイ
向かい合った机で、画面をシェアするのはなかなか難しいですよね。そこで、ノートPCのディスプレイが両面タイプになれば、両側から同じものが見れて非常にスムーズになるのではないか、という提案です。
3. 携帯電話のYes/Noボタン
電車の中で携帯電話を使うな、ということですが、大事な用件などで、通話先とどうしてもコミュニケーションがしたい場合ってあると思います。その時の妥協策として、例えば、通話先には「Yes/Noクエスチョン」で話してもらい、こちら側は「Yes/No」ボタンを押すと、電話先にそれが音声なりで伝わる。というのを考えてみました。そうすることで、マナーを守りながらもメール以上にスムーズなコミュニケーションが出来るのではないかと。
私は昔からわりとくだらないアイディアを考えるほうだったのですが、それを知人に話すとかなりバカにされるので、最近はとても控えめになってしまってました（日本人は、こういうときなかなか褒めてくれないのですよね）。でも、優秀な方々のアイディアを聞いて、やはり様々なことを考えて、アイディアを出してみるというのは重要なのだなと思いました。とってつけたように書くと、Notes/Dominoの利用って、アイディアが重要なところが結構あると思います。
いろいろなことを考えたものですが、恥を忍んで今覚えている主要なアイディアを書いてみます。あまり本気ではないので、突っ込まないで下さい。
1. ノートPCの充電
喫茶店や電車などでノートPCを開く人は、バッテリーがどれだけ長持ちするかが気になるかと思います。時間としては長持ちすればするだけよい。
そこで、考えたのですが、外部から受けるエネルギーを何らかの形で蓄積出来ればよいのではないかと。で、１つの形として、キーボードタイプの力など無駄なエネルギーがありそうで、少しでもこの力で充電出来ればどうだろう、というのが提案です。さんざんバカにされてます。他にもいくつか変形版があるのですが。
2. ノートPCの両面ディスプレイ
向かい合った机で、画面をシェアするのはなかなか難しいですよね。そこで、ノートPCのディスプレイが両面タイプになれば、両側から同じものが見れて非常にスムーズになるのではないか、という提案です。
3. 携帯電話のYes/Noボタン
電車の中で携帯電話を使うな、ということですが、大事な用件などで、通話先とどうしてもコミュニケーションがしたい場合ってあると思います。その時の妥協策として、例えば、通話先には「Yes/Noクエスチョン」で話してもらい、こちら側は「Yes/No」ボタンを押すと、電話先にそれが音声なりで伝わる。というのを考えてみました。そうすることで、マナーを守りながらもメール以上にスムーズなコミュニケーションが出来るのではないかと。
2006/09/15
コラボレーションで刺激を受ける
とあるビジネス・ディナーのお誘いを受け、Domino系のブログやエッセイの著者としても有名な方々3名と共に、楽しい夜を過ごしてきました。ビッグネーム3名に囲まれ、私は末席。よい刺激を頂きました。
本来は、「Hannoverの夢を語る」というテーマだったはずでしたが、皆さんの幅広い視野と興味はNotes/Dominoのだけに留まることなく、本当に幅広く知的な話題で、刺激的でした。
今回は圧倒されて座っていただけですが、自分もこの人たちの刺激となる話が出来るようになればなあと思わさせられます。（Web2.0系のコネタなどは提供できるのですが、私の偏った守備範囲ではそんな程度でした。Google Image Labelerネタとか）
思えば、自分が所属する部門でも、昔は、技術者たちが、夜遅くまで残って自分の考えを激しくぶつけあっては、未来について語り合ったものですが、その頃の刺激的な日々を思い出しました。
オフラインで激しくコラボレーションして刺激し合うことの重要性は若い頃から叩き込まれていたのですが、このブログ時代、オンラインでも、よい刺激を少しでも与え合うことが出来ればな、と思う次第です。
きっと参加された著名ブロガーの方々はたくさんの記事のヒントを得たでしょうし、私からも「是非それについて書いて下さい」とお願いしておいたので、そのアイディアや知性を我々とシェアして下さることでしょう。
本来は、「Hannoverの夢を語る」というテーマだったはずでしたが、皆さんの幅広い視野と興味はNotes/Dominoのだけに留まることなく、本当に幅広く知的な話題で、刺激的でした。
今回は圧倒されて座っていただけですが、自分もこの人たちの刺激となる話が出来るようになればなあと思わさせられます。（Web2.0系のコネタなどは提供できるのですが、私の偏った守備範囲ではそんな程度でした。Google Image Labelerネタとか）
思えば、自分が所属する部門でも、昔は、技術者たちが、夜遅くまで残って自分の考えを激しくぶつけあっては、未来について語り合ったものですが、その頃の刺激的な日々を思い出しました。
オフラインで激しくコラボレーションして刺激し合うことの重要性は若い頃から叩き込まれていたのですが、このブログ時代、オンラインでも、よい刺激を少しでも与え合うことが出来ればな、と思う次第です。
きっと参加された著名ブロガーの方々はたくさんの記事のヒントを得たでしょうし、私からも「是非それについて書いて下さい」とお願いしておいたので、そのアイディアや知性を我々とシェアして下さることでしょう。
2006/09/09
Blogテンプレート 7.0.2
普段はあまりSametimeをもらわないのですが、昨日は何故か大当たりの日で、マレーシアとチャットしている間に、知り合いのフランス人からもチャットを受けました。彼からメッセージをもらうのは初めてだったのですが、どうも社内でHannover展開するにあたって(?)、うちのチームの状況を確認 しにきたようです。
で、お話しているうちに、
「うちのブログのテンプレート、7.0.2 のBlogテンプレートにしてみたんだけれど」
と言うではありませんか。早速、アクセスしてみました。
The Blog - You are all set now :-)
決して得意でない英語で頑張ってブログ書いてますねえ。DominoとLinuxを心底愛するJNK氏です。
で、お話しているうちに、
「うちのブログのテンプレート、7.0.2 のBlogテンプレートにしてみたんだけれど」
と言うではありませんか。早速、アクセスしてみました。
The Blog - You are all set now :-)
決して得意でない英語で頑張ってブログ書いてますねえ。DominoとLinuxを心底愛するJNK氏です。
2006/09/07
サイジングと数字の一人歩き
マレーシアからSametimeでチャットをもらいました。マレーシアはASEANのテクニカルサポートの中心なので、APによく問い合わせがきます。
彼（あったことないので実は性別を知らず、名前や会話だけでは推測が出来ないのですが、とりあえず「彼」ということにします） の質問は、以下のようなものでした。
マ：「１つのAIXサーバーで、6000人を accomodate 出来るって話をきいたんだけれど、本当？」
とりあえず、accomodate が、「登録」なのか「同時利用」なのかは気になりました。あと、どうやら「AIX1台＝6000人」という公式が出回っていそうな雰囲気です。
まあ、ともあれ会話の流れもありますので、
私：「6000という特定の話はきいたことはないけれど、構成や利用形態によっては可能なケースもあると思うよ」
と、回答してみました。
すると、彼曰く
マ：「可能ってどういうこと？どこかにそんなドキュメントある？」
とのこと。なんか不安になってきました。不安な理由は、ドキュメントを見せたら、きっとそれだけで納得してしまって、「1台のAIXサーバー＝6000ユーザー」という公式が出回ってしまうような気がしたからです。
developerWorksのテスト結果で、6000ユーザー以上のものがあるとは思ったのですが、そのまま教えるのも怖かったので、
私：「ドキュメントは何に使うの？ この手のパフォーマンスデータは中身を熟知して慎重に扱わないと、ケースバイケースだから」
と、様子を見てみました。すると、
マ：「わかった。じゃあ、まずぼくが意味を理解して、それからちゃんとサポート先にはきちんと説明するから」
とのこと。
そこで、
かくいう私も、自分が担当でないサーバー製品のスケーラビリティがどんなものかは、目安の数字だけでも知りたくなってしまいますし、その数字が一人歩きしやすいというのも気持ち的にとてもよくわかります。難しいですね。
彼（あったことないので実は性別を知らず、名前や会話だけでは推測が出来ないのですが、とりあえず「彼」ということにします） の質問は、以下のようなものでした。
マ：「１つのAIXサーバーで、6000人を accomodate 出来るって話をきいたんだけれど、本当？」
とりあえず、accomodate が、「登録」なのか「同時利用」なのかは気になりました。あと、どうやら「AIX1台＝6000人」という公式が出回っていそうな雰囲気です。
まあ、ともあれ会話の流れもありますので、
私：「6000という特定の話はきいたことはないけれど、構成や利用形態によっては可能なケースもあると思うよ」
と、回答してみました。
すると、彼曰く
マ：「可能ってどういうこと？どこかにそんなドキュメントある？」
とのこと。なんか不安になってきました。不安な理由は、ドキュメントを見せたら、きっとそれだけで納得してしまって、「1台のAIXサーバー＝6000ユーザー」という公式が出回ってしまうような気がしたからです。
developerWorksのテスト結果で、6000ユーザー以上のものがあるとは思ったのですが、そのまま教えるのも怖かったので、
私：「ドキュメントは何に使うの？ この手のパフォーマンスデータは中身を熟知して慎重に扱わないと、ケースバイケースだから」
と、様子を見てみました。すると、
マ：「わかった。じゃあ、まずぼくが意味を理解して、それからちゃんとサポート先にはきちんと説明するから」
とのこと。
そこで、
- 登録ユーザーと同時アクセスユーザーとでは、キャパシティの考え方が違う
- 同じサーバー（CPU数、メモリ）でも、ディスク構成によって結果が大きく異なる。特に6000ユーザーだったら、パフォーマンスに十分なディスク本数が必要不可欠
- 同じ1人のユーザーでも、使い方によってサーバーの負荷が全く違うから、あくまでユーザー数は１つの参考的な指標
- だから、AIX1台で6000ユーザーは、可能な構成ケースもあるけれど、いつも可能だとは思わないでね
かくいう私も、自分が担当でないサーバー製品のスケーラビリティがどんなものかは、目安の数字だけでも知りたくなってしまいますし、その数字が一人歩きしやすいというのも気持ち的にとてもよくわかります。難しいですね。
2006/09/06
Web 2.0 & Domino
Web2.0な技術要素といえば何はともあれAjaxですが （AjaxだからといってWeb2.0というわけではないのですが） 、知らない間に下記のようなBlogが開設されていました。私、Ajax好きなので楽しみです。早速Dominoでタグクラウドとか興味深い記事が読めます。
Web 2.0 & Domino
楽しみに購読させてもらうことにします。
余談：フランス人がこうして英語文化圏（＝世界）に貢献をしているというのも、個人的には少し気になる事象です・・・。
Web 2.0 & Domino
楽しみに購読させてもらうことにします。
余談：フランス人がこうして英語文化圏（＝世界）に貢献をしているというのも、個人的には少し気になる事象です・・・。
2006/09/02
ちょっと気になった統計値
雑談ばかりですみません。
今日、Livedoor Reader(私がプライベートで使っているRSSリーダー)で、徘徊中にふと気になって見た統計値。このRSSリーダーは、ほぼ日本人専用といってもいいので、日本的な統計値がとれそうです。（Bloglinesなどでは、また違う結果になりそう）
Official Google Blogのフィードを登録している人は442(+0)人いました。
Google Japan Blogのフィードを登録している人は1961(+7)人いました。
注：フィードは複数のタイプが提供されていますので、「私と同じフィード(+違うフィード)」です。
一方、Dominoはというと、日米を代表するサイトで比較してみて
Ed Brillのフィードを登録している人は4人いました。
IBM Lotus Notes/Domino (R) をこよなく愛して。。。。を登録している人は17人いました。
どうも、統計値としては、特定カテゴリでの比較において、「日本を代表するブログの購読者数」は「世界を代表するブログの購読者数」の4-5倍みたいです。これは、思ったよりも、差が小さいとみるべきでしょうか、どうでしょうか。（もっとも母集団が「RSSリーダー使い」というのは「4-5倍」という数値に影響が出ていると思いますが）
それから、比較してはいけない、「GoogleネタはDominoネタの100倍盛り上がっているのか」については、コメントが（いろいろな意味で）難しいのですが、RSSリーダーファンにはGoogleファンが多いということを考えると、100倍も違うことはさすがになかろう・・・とも思います。
（ちなみに、こういった比較は好きでないですが、気になって調べました。ウィンドウズ開発統括部、は、84名でした。OSとアプリケーションというの違いというのはあるけれど、、、。)
なんか、頑張らなければいけないと思った土曜日。
今日、Livedoor Reader(私がプライベートで使っているRSSリーダー)で、徘徊中にふと気になって見た統計値。このRSSリーダーは、ほぼ日本人専用といってもいいので、日本的な統計値がとれそうです。（Bloglinesなどでは、また違う結果になりそう）
Official Google Blogのフィードを登録している人は442(+0)人いました。
Google Japan Blogのフィードを登録している人は1961(+7)人いました。
注：フィードは複数のタイプが提供されていますので、「私と同じフィード(+違うフィード)」です。
一方、Dominoはというと、日米を代表するサイトで比較してみて
Ed Brillのフィードを登録している人は4人いました。
IBM Lotus Notes/Domino (R) をこよなく愛して。。。。を登録している人は17人いました。
どうも、統計値としては、特定カテゴリでの比較において、「日本を代表するブログの購読者数」は「世界を代表するブログの購読者数」の4-5倍みたいです。これは、思ったよりも、差が小さいとみるべきでしょうか、どうでしょうか。（もっとも母集団が「RSSリーダー使い」というのは「4-5倍」という数値に影響が出ていると思いますが）
それから、比較してはいけない、「GoogleネタはDominoネタの100倍盛り上がっているのか」については、コメントが（いろいろな意味で）難しいのですが、RSSリーダーファンにはGoogleファンが多いということを考えると、100倍も違うことはさすがになかろう・・・とも思います。
（ちなみに、こういった比較は好きでないですが、気になって調べました。ウィンドウズ開発統括部、は、84名でした。OSとアプリケーションというの違いというのはあるけれど、、、。)
なんか、頑張らなければいけないと思った土曜日。
2006/08/29
IT技術者の健康
いろいろな諸事情により、私は個人的に「IT技術者の健康」というものにも非常に興味があります。自分が経験したことを考えると、Dominoよりこちらのほうが社会的責任があるのではないかと思っているくらいです。（もちろん、Dominoに関してもこれまで通りマイペースで何か書くつもりです。）
本当はここでそのような話をしようかと思ったのですが、ブログを分けたほうがいいというアドバイスを頂いたので、別途作ってみました。こちらで健康の話をするのは最初で最後ですが、一応リンクを貼っておきます。
IT技術者の健康徒然
専門家ではありませんが、何らか社会の役に立てれば嬉しいです。
本当はここでそのような話をしようかと思ったのですが、ブログを分けたほうがいいというアドバイスを頂いたので、別途作ってみました。こちらで健康の話をするのは最初で最後ですが、一応リンクを貼っておきます。
IT技術者の健康徒然
専門家ではありませんが、何らか社会の役に立てれば嬉しいです。
2006/08/27
数学は役に立たないか
夏休みに、藤原先生の「世にも美しい数学入門」という本を読みました。
内容は、博士の愛した数式の小川さんとの対談形式で、一般人が興味をひきやすいような読みやすいものでよかったです。
で、中で気になったのは、「数学は人類の役に立たない」というお話。
そういえば、自分も高校生の頃、数学の中でどうしても理解出来ない部分があって、自分の当時の家庭教師の先生に「XXXなんてなかったらよかったんですよ」と言ってみたら、「でもXXXがなかったら、今の生活の中でなかったものや出来ないことがあったかもよ」とあっさり言われたのを思い出しました。
さらにいろいろ考えてみると、先日読んだ「暗号技術入門」の本で解説されていたPKIの解説では、思いっきり現代数学が関係していたな・・・、と。昔、離散数学を勉強したときは、こんなもの何の役に立つかと思ったけれど、こういった暗号数学がなければ、インターネットでお買い物も出来ないのだなあと、ふと思いました。
きっと、フェルマーやポアンカレの証明なんかは、今のところ直接現代社会の役に立たないのかもしれないですが、ふと、人が言うほど不要なわけでもないよな・・・と思い返してみました。
Notes/Domino技術者として、この部分に興味があったら、やはり「ネットワークセキュリティ」を読むべきなのでしょうね。なんといっても、Notesのセキュリティを設計した、当時Irisのチャーリー・カウフマンが著者で、Notesのセキュリティについても短く触れてあります。
この本の存在は、かなり前に知って購入済みでもあるのですが、難しそうで開く気になれず眠ったままになっています。読まなければなあ。
内容は、博士の愛した数式の小川さんとの対談形式で、一般人が興味をひきやすいような読みやすいものでよかったです。
で、中で気になったのは、「数学は人類の役に立たない」というお話。
そういえば、自分も高校生の頃、数学の中でどうしても理解出来ない部分があって、自分の当時の家庭教師の先生に「XXXなんてなかったらよかったんですよ」と言ってみたら、「でもXXXがなかったら、今の生活の中でなかったものや出来ないことがあったかもよ」とあっさり言われたのを思い出しました。
さらにいろいろ考えてみると、先日読んだ「暗号技術入門」の本で解説されていたPKIの解説では、思いっきり現代数学が関係していたな・・・、と。昔、離散数学を勉強したときは、こんなもの何の役に立つかと思ったけれど、こういった暗号数学がなければ、インターネットでお買い物も出来ないのだなあと、ふと思いました。
きっと、フェルマーやポアンカレの証明なんかは、今のところ直接現代社会の役に立たないのかもしれないですが、ふと、人が言うほど不要なわけでもないよな・・・と思い返してみました。
Notes/Domino技術者として、この部分に興味があったら、やはり「ネットワークセキュリティ」を読むべきなのでしょうね。なんといっても、Notesのセキュリティを設計した、当時Irisのチャーリー・カウフマンが著者で、Notesのセキュリティについても短く触れてあります。
この本の存在は、かなり前に知って購入済みでもあるのですが、難しそうで開く気になれず眠ったままになっています。読まなければなあ。
2006/08/04
技術者と英語について
技術者に必要なもの
上記記事を読んだり、開設したばかりの「ShortCuts」を試してみたことにインスパイアされたので、私が思っている英語についてを書いてみます。
個人的に現在一番気になっているのは、「日本」と「英語を母国語としない国」の英語力の差です。
去年の冬、1ヶ月ほどボストンで仕事をする機会に恵まれました。日本人は私だけでしたが、身近には、数名のアメリカ人に加え、フランス、アイルランド、インド、ブラジル、ドイツから来た技術者たちがおり、非常に多国籍な環境でした。アメリカとアイルランド以外は、みな、non-native です。
当然かもしれませんが、母国語ではないにしろ、全員かなり流暢に英語を使っていました。発音は厳しいものがありましたが、「英語を使いこなす」という能力においては十分で、きっとTOEICを受けたら文法問題を間違えない限り、Listeningは満点、Readingも470点くらいはとるでしょう。彼らが選ばれた戦士なのかは不明ですが、私はTOEIC965なんて保有していませんから、諸外国との能力差は感じたわけです。
こういった個人的な問題は、私１人が努力すればよい話ですが、むしろ気になったのはこれからの話。
フランスやドイツの技術者と話をしてみたところ、彼らの国では、英語の技術文書を当たり前のように読むと言っていました。この文の主語は、「IBM社員」ではなく、あらゆる技術者（つまり、身近にいえば、パートナー様や、各企業の情報システム担当者様）なのだそうです。もちろん、日本にだって当たり前のように英語を読む方もたくさんいると思うのですが（特に、ブロガー近辺）、基本的に日本語で閉じている自分たちにとって、彼らとのこの時の会話はやや衝撃的でした。
そういえば、以前台湾に言ったときも、彼ら同士、会話は中国語でしたが、お客様への提出資料は英語で作成していました。メールも英語でした。中国語入力が大変だから英語を使う、と言っていたのを思い出します。（英語はそんなに上手でなかったですが）
もちろん、日本は、翻訳されたもの、独自に書かれたものを含め、英語以外の言語での技術情報は極めて豊富な国だと思います。それでも、英語の情報には数ではとてもかないません。（ニーズからいえば、作成者側の努力がまだまだ必要とされる）
そんな中、諸外国の技術者たちが、普通に英語で情報収集していたら、「日本語だけ読む日本人」とはどんどん差が出てしまうのではないか、という危惧をその時に思いました。
現在インターネットを通じて加速する国際的な情報交流ですが、日本は物理的な線でこそ海外とつながったものの、言語的な問題から島国になっていると思います。私個人も、島国ハンデが出ないように、いろいろと努力してるつもりではあるのですが、それでも情報の流通にギャップを感じることがあります。
ということで、1人でも多くの日本人が、日本語情報にあわせて英語情報も読むようになると、私としてはとても嬉しいです。私の所属や業界に関わらず、全てのジャンルにおいてそう思います。取り残される日本にはなって欲しくないです。フランスやドイツに負けたくないです。
最近では、むしろ、私たちは日本語＋英語の両方の情報が入手出来るのだから、英語さえきちんと出来れば、アメリカ人よりよほどよい環境だと思います。トラブルで困っているときなんか、英語情報は心強い味方になることも多いですよ。
上記記事を読んだり、開設したばかりの「ShortCuts」を試してみたことにインスパイアされたので、私が思っている英語についてを書いてみます。
個人的に現在一番気になっているのは、「日本」と「英語を母国語としない国」の英語力の差です。
去年の冬、1ヶ月ほどボストンで仕事をする機会に恵まれました。日本人は私だけでしたが、身近には、数名のアメリカ人に加え、フランス、アイルランド、インド、ブラジル、ドイツから来た技術者たちがおり、非常に多国籍な環境でした。アメリカとアイルランド以外は、みな、non-native です。
当然かもしれませんが、母国語ではないにしろ、全員かなり流暢に英語を使っていました。発音は厳しいものがありましたが、「英語を使いこなす」という能力においては十分で、きっとTOEICを受けたら文法問題を間違えない限り、Listeningは満点、Readingも470点くらいはとるでしょう。彼らが選ばれた戦士なのかは不明ですが、私はTOEIC965なんて保有していませんから、諸外国との能力差は感じたわけです。
こういった個人的な問題は、私１人が努力すればよい話ですが、むしろ気になったのはこれからの話。
フランスやドイツの技術者と話をしてみたところ、彼らの国では、英語の技術文書を当たり前のように読むと言っていました。この文の主語は、「IBM社員」ではなく、あらゆる技術者（つまり、身近にいえば、パートナー様や、各企業の情報システム担当者様）なのだそうです。もちろん、日本にだって当たり前のように英語を読む方もたくさんいると思うのですが（特に、ブロガー近辺）、基本的に日本語で閉じている自分たちにとって、彼らとのこの時の会話はやや衝撃的でした。
そういえば、以前台湾に言ったときも、彼ら同士、会話は中国語でしたが、お客様への提出資料は英語で作成していました。メールも英語でした。中国語入力が大変だから英語を使う、と言っていたのを思い出します。（英語はそんなに上手でなかったですが）
もちろん、日本は、翻訳されたもの、独自に書かれたものを含め、英語以外の言語での技術情報は極めて豊富な国だと思います。それでも、英語の情報には数ではとてもかないません。（ニーズからいえば、作成者側の努力がまだまだ必要とされる）
そんな中、諸外国の技術者たちが、普通に英語で情報収集していたら、「日本語だけ読む日本人」とはどんどん差が出てしまうのではないか、という危惧をその時に思いました。
現在インターネットを通じて加速する国際的な情報交流ですが、日本は物理的な線でこそ海外とつながったものの、言語的な問題から島国になっていると思います。私個人も、島国ハンデが出ないように、いろいろと努力してるつもりではあるのですが、それでも情報の流通にギャップを感じることがあります。
ということで、1人でも多くの日本人が、日本語情報にあわせて英語情報も読むようになると、私としてはとても嬉しいです。私の所属や業界に関わらず、全てのジャンルにおいてそう思います。取り残される日本にはなって欲しくないです。フランスやドイツに負けたくないです。
最近では、むしろ、私たちは日本語＋英語の両方の情報が入手出来るのだから、英語さえきちんと出来れば、アメリカ人よりよほどよい環境だと思います。トラブルで困っているときなんか、英語情報は心強い味方になることも多いですよ。
2006/07/28
サーバータスクのリスタート
主にテスト環境での話が多いと思いますが、試行錯誤しながら設定変更してはタスクを再起動することは結構あるものです。
HTTPタスクの再起動というのは、非常によく行うもので、「tell http restart」のコマンドに、これまでさんざんお世話になりました。
Routerタスクの再起動というのも、頻繁にやります。そこで、なんとなく「tell router restart」と打ち込むわけですが、これは間違い。Routerタスクで、設定変更を反映させたい場合は「tell router update config」を使う必要があります。
と、ここまではいいのですが、では他のタスクは・・・・という話になります。
実は、Domino 6以降、サーバーコンソールコマンドとして、以下のようなものが用意されました。
restart task <タスク名>
例えば、「restart task router」とか「restart task adminp」などというように使います。
実は、この技術文書を見て、私も今日知ったところです。
Can the Domino Router task be restarted with a 'Tell Router Restart' command?
余談：
restart server というコマンドは、世界中で相当打ち込まれていると思うのですが、ブラインドタッチ組にとっては、このコマンドはうちにくいですね。左手1本で、特に「r t」がうちにくいです。私は、res ser と打ってます。（「res s」でよいのですが、回文になってるのが気持ちよいので・・・）
HTTPタスクの再起動というのは、非常によく行うもので、「tell http restart」のコマンドに、これまでさんざんお世話になりました。
Routerタスクの再起動というのも、頻繁にやります。そこで、なんとなく「tell router restart」と打ち込むわけですが、これは間違い。Routerタスクで、設定変更を反映させたい場合は「tell router update config」を使う必要があります。
と、ここまではいいのですが、では他のタスクは・・・・という話になります。
実は、Domino 6以降、サーバーコンソールコマンドとして、以下のようなものが用意されました。
restart task <タスク名>
例えば、「restart task router」とか「restart task adminp」などというように使います。
実は、この技術文書を見て、私も今日知ったところです。
Can the Domino Router task be restarted with a 'Tell Router Restart' command?
余談：
restart server というコマンドは、世界中で相当打ち込まれていると思うのですが、ブラインドタッチ組にとっては、このコマンドはうちにくいですね。左手1本で、特に「r t」がうちにくいです。私は、res ser と打ってます。（「res s」でよいのですが、回文になってるのが気持ちよいので・・・）
2006/07/21
TeamStudio Analyzer
あるところで、TeamStudioの情報交換を行ったのですが、わりといろいろな使い方があるものだと感心しました。私は、AnalyzerとConfiguratorしか普段はインストールしておらず、日常的に使っているのはConfigurator だけです。
一応、情報交換会に出る都合上、少しは機能を理解しておこうかなとヘルプを読んでみましたが、なかなか面白かったです。Analyzerといえば、設計書の提出に使ったり、設計要素を抜き出して全文検索したり、専用のビューを作って、「何らか一覧」を作ったりする・・・というのがよく知られたところでしょうか。「監査機能」も面白いですね。デフォルトのフィルタだけでも、何らかの発見になるかもしれませんし、上手く使えば「お作法のよいアプリケーション」も増えていくと思います。
ヘルプを読むと、例えば「フィールドヘルプのない項目一覧」とか「名前が_1で終わるフィールド一覧（コピペすると出来る）」とか、ノウハウ的なことも書いてあったりします。
使いやすいツールだけに、ヘルプをじっくり・・・なんてあまりやらないのですが、たまには読んでみるのも面白いですね。
きっと、このツールには、フィルタやら、分析結果DBのカスタマイズなどまだまだベストプラクティスがいろいろとあるのではないかと思います。
一応、情報交換会に出る都合上、少しは機能を理解しておこうかなとヘルプを読んでみましたが、なかなか面白かったです。Analyzerといえば、設計書の提出に使ったり、設計要素を抜き出して全文検索したり、専用のビューを作って、「何らか一覧」を作ったりする・・・というのがよく知られたところでしょうか。「監査機能」も面白いですね。デフォルトのフィルタだけでも、何らかの発見になるかもしれませんし、上手く使えば「お作法のよいアプリケーション」も増えていくと思います。
ヘルプを読むと、例えば「フィールドヘルプのない項目一覧」とか「名前が_1で終わるフィールド一覧（コピペすると出来る）」とか、ノウハウ的なことも書いてあったりします。
使いやすいツールだけに、ヘルプをじっくり・・・なんてあまりやらないのですが、たまには読んでみるのも面白いですね。
きっと、このツールには、フィルタやら、分析結果DBのカスタマイズなどまだまだベストプラクティスがいろいろとあるのではないかと思います。
不在通知
不在通知エージェントは、Hannoverからエージェントではなくなり、コアコードになるそうです。
Instantaneous Out-of-Office in "Hannover"
Lotusphereの資料、きちんと目を通してなかったので、流れていってしまうところでしたが、Edのブログで気が付きました。 instant response って何なのでしょうね。
実は、私個人は、ユーザーとしてこの不在通知使っていません。。。深い理由はないのですが。
Instantaneous Out-of-Office in "Hannover"
Lotusphereの資料、きちんと目を通してなかったので、流れていってしまうところでしたが、Edのブログで気が付きました。 instant response って何なのでしょうね。
実は、私個人は、ユーザーとしてこの不在通知使っていません。。。深い理由はないのですが。
技術情報のRSSフィード提供
既にあちこちで宣伝されているのでご存知の方も多いでしょうが、サポートページのRSSフィード提供が開始されました。
サポート/技術情報
AutoDiscoveryはついていないので、上記ページのXMLリンクから直接登録して下さい。
これまでMyRSS使ってかろうじて読んでいたのですが、いちユーザーとして非常に嬉しいです。
私は、フィードジャンキーとまではいかないにしても、情報収集の9割以上をRSS/atomに頼っています。ブラウザのブックマークは、ほとんどすかすかで、RSS提供されていないページは基本的に読んでいません。
ちなみに、このフィードをFirefoxのライブブックマークで読むことは可能です。でも、私の個人的好みでは、それはあまりオススメ出来ない読み方です。
フィードには、「全部読みたい」タイプと、「全部読まなくてもよい」タイプと2種類ありますが、サポート情報の更新件数はたかがしれているし、Domino技術者なら全部目を通しておいてもよいのではないかと思います。
このように全部目を通したいタイプのフィードには、未既読管理機能を備えたRSSリーダーを使うのが私の好みです。こういうRSSリーダーとして、昔は、Bloglinesを使っていましたが、今は livedoor Reader を使っています（キーボードショートカットがショートカットが気持ちいいので）。 そのまた昔は、クライアントインストールタイプを使っていましたが、大量のフィードをさばくにはサーバー型のほうがよさそうだと思っていつからか変更しました。
一方、Firefoxのライブブックマークも使っていますが、こちらは極めて局所的に、自分のdel.icio.us の登録項目、はてなブックマークの人気エントリだけ使ってます。昔は、asahi.comのフィードや CNET Japan も入れてましたが、ニュース読まないのでやめました。特に、自分のソーシャルブックマークのRSSを設定しておくというのは、オススメです。 その他、「暇なときにぱらっと見てタイトルを確認する」という程度のフィードは、ライブブックマークでよいかなという気がしてますが、多く登録しすぎるとブラウザが重くなるので微妙ですね・・・。
サポート/技術情報
AutoDiscoveryはついていないので、上記ページのXMLリンクから直接登録して下さい。
これまでMyRSS使ってかろうじて読んでいたのですが、いちユーザーとして非常に嬉しいです。
私は、フィードジャンキーとまではいかないにしても、情報収集の9割以上をRSS/atomに頼っています。ブラウザのブックマークは、ほとんどすかすかで、RSS提供されていないページは基本的に読んでいません。
ちなみに、このフィードをFirefoxのライブブックマークで読むことは可能です。でも、私の個人的好みでは、それはあまりオススメ出来ない読み方です。
フィードには、「全部読みたい」タイプと、「全部読まなくてもよい」タイプと2種類ありますが、サポート情報の更新件数はたかがしれているし、Domino技術者なら全部目を通しておいてもよいのではないかと思います。
このように全部目を通したいタイプのフィードには、未既読管理機能を備えたRSSリーダーを使うのが私の好みです。こういうRSSリーダーとして、昔は、Bloglinesを使っていましたが、今は livedoor Reader を使っています（キーボードショートカットがショートカットが気持ちいいので）。 そのまた昔は、クライアントインストールタイプを使っていましたが、大量のフィードをさばくにはサーバー型のほうがよさそうだと思っていつからか変更しました。
一方、Firefoxのライブブックマークも使っていますが、こちらは極めて局所的に、自分のdel.icio.us の登録項目、はてなブックマークの人気エントリだけ使ってます。昔は、asahi.comのフィードや CNET Japan も入れてましたが、ニュース読まないのでやめました。特に、自分のソーシャルブックマークのRSSを設定しておくというのは、オススメです。 その他、「暇なときにぱらっと見てタイトルを確認する」という程度のフィードは、ライブブックマークでよいかなという気がしてますが、多く登録しすぎるとブラウザが重くなるので微妙ですね・・・。
2006/07/19
確率と網羅性
先日、知人のマイミク日記に書いてありました。
Dominoの技術者をしていると、「ドメイン設計」や「運用設計」「移行設計」などに関わることも多いかと思います。そのような時に、各ドメインの特徴を理解した上で、例外ケースを見逃すことなく、網羅性のあるデザインをするのは重要ですし、またこれは非常に難しくもあります。実はこれらは、上記のような確率の問題を正しく考えることとわりと近い能力が要求されるのではないかと思いました。（二項定理のような数式変形はどうでもよいのですが、漏れなく場合分けして数えるというところ。数学証明の場合分けも似たようなものだと思います）
私の脳も、長らくご無沙汰でさび付いたものですが、たまにはこのようなことをするのもよいかもしれないと思った次第です。
よく、ベストのデザイン方法を探すときに、いくつかの候補があがった上で、「他によい方法はないですかね」という質問ももらいますが、これも上手く網羅性の観点から考えると、「他にはない」ということが証明出来ることもあります。
こういう質問のとき、私はわりと、「Xか、Xでないか」の2種類に分割して、深く考えていくことが多いです。例えば、「ドメインを１つにする方法と、分割する方法と2種類が考えられますよね。１つにすると・・・」など。この時点まででは、全ての解決方法は必ず網羅されているといえます。で、さらにそれぞれのケースを掘り下げていっては「×マーク」をつけています。
きっと、これだけビジネス本が普及している世の中ですので、世の中には確立されたよいメソッドがあると思うのですが、私の整理も含め、ふとDomino技術者として思ったことを書いてみました。
n人でじゃんけんして「あいこ」になる確率っていくつだろう・・・何を思い立ったか、久しぶりにこのような確率の問題を解いてみたくなり、紙と鉛筆で計算してみました。高校数学からは久しく遠ざかっていたため、二項定理をすっかり忘れており、コンビネーションのΣまでで止まってしまったのですが、それでも久しぶりに普段使わない部分の脳の末端を運動したかんじで気持ちよかったです。この問題では、「あいこになる全ケースをどうやって数えるか」がポイントですね。
Dominoの技術者をしていると、「ドメイン設計」や「運用設計」「移行設計」などに関わることも多いかと思います。そのような時に、各ドメインの特徴を理解した上で、例外ケースを見逃すことなく、網羅性のあるデザインをするのは重要ですし、またこれは非常に難しくもあります。実はこれらは、上記のような確率の問題を正しく考えることとわりと近い能力が要求されるのではないかと思いました。（二項定理のような数式変形はどうでもよいのですが、漏れなく場合分けして数えるというところ。数学証明の場合分けも似たようなものだと思います）
私の脳も、長らくご無沙汰でさび付いたものですが、たまにはこのようなことをするのもよいかもしれないと思った次第です。
よく、ベストのデザイン方法を探すときに、いくつかの候補があがった上で、「他によい方法はないですかね」という質問ももらいますが、これも上手く網羅性の観点から考えると、「他にはない」ということが証明出来ることもあります。
こういう質問のとき、私はわりと、「Xか、Xでないか」の2種類に分割して、深く考えていくことが多いです。例えば、「ドメインを１つにする方法と、分割する方法と2種類が考えられますよね。１つにすると・・・」など。この時点まででは、全ての解決方法は必ず網羅されているといえます。で、さらにそれぞれのケースを掘り下げていっては「×マーク」をつけています。
きっと、これだけビジネス本が普及している世の中ですので、世の中には確立されたよいメソッドがあると思うのですが、私の整理も含め、ふとDomino技術者として思ったことを書いてみました。
登録:
投稿 (Atom)
