7つの非機能特性
POSA本より、システムの非機能特性。
・変更容易性
・相互運用性
・効率
・信頼性
・テスト容易性
・再利用性
今の時代だったら、機密性が加わるのかしら。
トラックバック URL :
コメント (0)POSA本より、システムの非機能特性。
・変更容易性
・相互運用性
・効率
・信頼性
・テスト容易性
・再利用性
今の時代だったら、機密性が加わるのかしら。
トラックバック URL :
コメント (0)仕事ってストレスが溜まるものである一方、ストレス解消の側面もあってもいいと思う。
必要なのは演出か?
その昔、ドラえもんで、「面白パズルブック」という道具をドラミちゃんが出したことがあって、何かっていうと、宿題を面白おかしい問題に変換するツールだった。のび太はそれが宿題だとは知らず、嬉々としてそれを説くわけだが。
よいきっかけ、よい演出、よいモチベーションがあれば、宿題でも仕事でもある程度は面白くなるというのは事実だろう。
例えば、楽しい職場?
銀座の一等地とか華やかなロケーションを選ぶとか、職場にイイ男イイ女がいるとか。
・・・あぁ、どうも自分は考えることが下賎だなぁ。
人によってモチベーションが上がる方法なんてマチマチなんだし。
もっとマジメに考えるならば、達成感の演出ということになるだろうか。
「イエース、○○が上がったぞー」的なカタルシスを日々演出出来るようになればいいのだが。
っていうか、これって普通のことだな、別に。
はてなの住所登録義務化問題に興味があったので、あちこちをしばらくROMっていた。
結局、ユーザやネット上での様々な意見を吟味して再構築した結果、はてなサイドが義務化撤回ということで落ち着いたようだ。
コンシューマ向けASPサービスを考える上で参考になる事例だったのではないだろうか。
ユーザ流出という損失を少なからず被ったものの、企業サイドの準備不足(うまい方法はあったハズだ)による悪印象を誠意ある態度である程度リカバリー出来たような気がする。
ふと筋違いなんだろうけど「トラブルは絶好の機会」という言葉を思い出した。
ネット上の企業について言うと、今回のはてなは例外で、多くはそれ程トラブル処理はあまりうまくない気がする。
誠意の見せ方が普通にうまい企業というのはやはり存在するので、そういうところを見習ってもいいような気がするのだが。
情報整理術の一つなんですが、これっていいですね、
1.伝えたいことを3つに絞る。
2.それぞれに対し、(WHAT)(WHY)(HOW)の組み合わせを最大3つずつくらいで分解する。これで、最小9、最大27ぐらいのポイントになる。
3.それらのポイントを頭の中に叩き込む。
4.最後に中心となるひとことを絞りだす。
電子情報の置き場所としてとりあえず考えてみたこと。
・私のホームサーバ
・私のPDAやモバイル、ICカード
・私のレンタルサーバ
・サービスを提供する企業のサーバ
・サービスを提供する企業が参照する第三者機関サーバ
えーとどうしてこんなことを書くのかというと、ホームサーバが一般的になったら、今のASPをめぐる状況って激変するのかなぁ、って思って。
・・・っていうか、そんなのまだまだ先のことか。
思いつき。
私のホームサーバが一般的になったら、バックアップストレージでもインフラでもなんでもいいんだけども、私のレンタルサーバがホームサーバのセカンダリ(とかスレーブ)という位置付けになって積極的に利用されるのだろうか、やはり。
トラックバック URL :
コメント (0)またえらいイベントがやってるんですね。
楽天は来てないのかな?勢揃いだよ。
IT業界の経営者やVCが集結:「New Industry Leaders Summit 2004」が開幕
SF に JYUGEM というプロジェクトがあった。
| JYUGEMは、半導体製造装置を対象にSECS/HSMSの標準的な適用方法を定義したGEM/OBEMスタンダードを実現するためのプログラムです。 |
その昔、かれこれ5年ぐらい前にこっち系の仕事やってたんだよね。
SECSメッセージかぁ、懐かしいなぁ。
しかし、SF にこういうのがあるとは思わなかった。
他に面白そうなのないかなぁ、と思ったらこんなのがあった。
mobways
| 本プロジェクトでは,旅券やチケット,クーポン,マネー,施錠等の権利情報/価値情報を電子化して携帯電話に格納し,かつ携帯電話に搭載された近接認証デバイス(Felica等)を使用する事により,価値情報の認証機能を実現するフレームワークを提供します.(しばらく待ってね) |
「しばらく待ってね」という言葉が示すように、今のところ(2004/11/24現在)は何もなかったけど。
いつの間にか、Tomcat5.5.4 が出ていた。
早速インストールしようと思ったら、動かない。
RELEASENOTES.txt を見てみた。
|
Tomcat 5.5 is designed to run on J2SE 5.0 and later, and requires configuration to run on J2SE 1.4. Make sure to read the “RUNNING.txt” file in this directory if you are using J2SE 1.4. |
あぁ、J2SE5.0 を入れなきゃ動かないのね。
J2SE 1.4 でも動かせる方法があるみたいだけども、せっかくなので、5.0 を入れてみるか。
トラックバック URL :
コメント (0)J2SE5 同様に、C# 2.0 もジェネリック に対応するらしい。
ジェネリックとは何かというと、クラス内の型をパラメータ化できること。
|
class Hoge<T> { } ・・・ Hoge<Integer> iHoge; |
C++では元々あったんだよなぁ、確かこの機能。
ただ、実際にはこういう型パラメータをもったクラスを作らずに、あらかじめ用意されているコレクションクラスを利用するぐらいに留めた方がよさそうだけど。
実際のクラス作成でこれを使い始めると、クラス図が混乱することになりそう。
以前の記事 でも書いた、msdn のパターンのページ 内の「エンタープライズの相互運用性 : .NET と J2EE」を軽く読んだのでメモ。
ざっくりいうと、Java と .NET の相互運用には以下の3つのテクノロジーが考えられるということ。
1.Web サービス
2.MOM (MessageOriented Middleware : メッセージ指向ミドルウェア)
3.ダイレクト アプリケーション ブリッジ ソリューション
それぞれの内容については本文を参照。
っていうか、2 は メッセージを管理するサービスを間に置いておけよ、ってことらしく、3 は 低レイヤで稼動するインターフェイスを準備してやるから、RPC のイメージで直接呼び合え、ってことらしい。
ふと妙なことを思いついた。
究極の非同期、それは「人間」。・・・あるシステムからあるシステムへ、人自らが情報を打ち込むとか。
「え、どのみち月一回ぐらいしかデータ同期の必要がないんでしょ?FDにデータ入れてコピーしなよ」
と何度言ったことか。
ただ、マン向けの「入力」「出力」のインターフェイスを作るのと、それをシステムで一本にしてしまうののどちらを選択するかは完全にケースバイケースではありますが。
トラックバック URL :
コメント (0)HTML convert time: 1.589 sec. Powered by WordPress ME