CyberFramework

• エンドユーザー・コンピューティング。確かにこれは目指さないとならないことだと思うが、もうそこそこ出来てるってのは驚きだ。
• で、解決策の1つであるこの製品の紹介(?)として、凄いことが一杯書いてあるんですが、これが本当に既に実現済みなわけですか？だったら驚嘆。ぜひ一度見てみたいもんだ。--戯

• 光ファイバーで通信ができるようになっても、何に使ったらいいのか分からないため、なかなか各家庭に入ってこない …全くです(藁
• 実際のニーズや次代を継ぐ発想は、そういう一部の限られた人達が持っているのではなく、我々の生活の中にあるんです
• 現場で誰でも作れるようにしなければいけない…これも至極全くです
• ドラッグ & ドロップで 1 、2 秒で作られたんでは、たまったものではないですからね …ついてけない人(や結果的に不要になる人)は引退すればいいんです(藁)。雇用維持のための旧態技術支持なんて糞食らえ

• 「複雑さを回避するシステム」…再利用性と対比(?)するかたちでこの言葉に注意を向けてるのは、素晴らしいんじゃないかな。
• 皆、システムが複雑なのは業務が複雑なのだから仕方ない、と思ってしまっている …(藁うしかない…(t_t)
• コンピューターの心臓部の CPU 云々… 再利用性高い、かつ具体性の低い、つーかメタ度の高い、そんな「部品」を用意しといて、それを「繋いで」いく、という事を言ってるみたいね。
  • 構成の階層ツリーで言えば、幹へ近いほどメタで再利用性高く、枝葉ほど具体的で直接問題解決型になる、という階層構造。まあ普通な話だわな。
• 1 行 1 行書いていたのでは、複雑さを回避することはできません。先ほどの CPU の例のように、もっと上のレイヤーのコンテキストで複雑さをカバーしていかないことには …字でソースを書くことの限界。字も「再利用性高い」「具体性低い」「メタ度高い」のだが、問題はそれが「行き過ぎてる」ことなんだろうと俺は思う。
  • つまり、字よりは少しばかり幹側の部品といえるものを、旨い具合に1つのモノとして提供できんか？という話だと思う。

• どんな部品を持ってきても必ずくっつく…ソフトウェア配線、特にミュージックシンセサイザ(のうち往年のアナログパッチケーブル型)みたいな世界かな。任意の配線の組み方を許可し、そのあらゆる組み方に対する(破綻的でない)結果が存在する。コネクタのかたちと流れる電気の規格(だけ？)を決めておくってことだと思うけど。
• 「関数名をどういうふうに書いたらいいか」 …Screenshotから想像すると、これは機能や状態(オブジェクト?)のアイコン化で凌いで(回避して)いる模様。巨大な問題を解く時にはコーディング(^^;が大変になると思うけど、解かねばならぬ全ての問題が巨大だと限らない以上、これも十分に有効な戦略だろう。
• 「引き数は何個あるか」、「引き数の型は何か？」 Maxでも見て取れるようなやり方で解決できる、と言っていいかな…。まあ引数の変化が「配線の矛盾」としてプログラマにエラー報告されればいいんだろうな。
  • やっぱり引数は癌だったんだ！(藁

• 業務ノウハウ、言い方を変えると、ナレッジをソフトウェアとして蓄積できるということ …すばらしい！ソフト化することにより「自分らの」ビジネスを厳密に観察する…鏡だ…事になるので、非常に良い事だと思う。ビジネスや内部手順がDQNなのに、ソフト屋にソフト作らせるだけで薔薇色に業務改善される、なんてな幻想が打破される(かも知れない)のは望ましい事だ。自分らの変さを自分らで思い知ればいいんだ(藁)。ソフトはなまじ気が利かないので、そういう変さを厳格に教えてくれるカナリアのようなものだ。
  • (業務ノウハウのドキュメントを)実は従来は、残していなかったのかもしれません …確かに、後で掘り起こして読むこともせず、あるいは読んだとしてもその文書の正しさを「厳密に」検証することもしないなら、文書を書いた時間と費用をドブに捨てただけ。下手に「書いた」と思い込んでるだけ始末が悪い。
• 口伝えに伝えていく、マヤ文明のような世界 …身にしみます(藁
  • 現在のようにお客様のニーズにタイムリーに対応しなければ生き残れない時代では …よく聞く言い方だが、これってどうなんだろう？確かにビジネス速度の問題も有るのだが、それ以前に(昔であっても)「正しい(間違ってない)」ビジネスでなければ客が怒ると思うのだが？昔は客も間違いに(滅多に)気付かなかったという意味だろうか？
  • つまりIT化は、ビジネスを「正確」にしたんだ。その副作用で高速化が得られた(まあ計算機の速度自体も十分貢献しているが…)。昔も金勘定とかは(人力で苦労して)正確にしていたが、昔は数値化しにくいものは正確でなくても罷り通っていた…のかも知れない。
  • 自分達の手元にノウハウを集積し、外部に出さないことが重要 …個人的にはこういう考え方は嫌いだが。まあITなら(望めば)逆にそれを他者に公開するのも楽になるわけだだし、道具の使い道の問題でしかないか。
  • あとは、どんな便利なツールを使ってもやっぱり出現するであろう、DQN実装やDQN設計を行なう連中(笑)を、どう排除するかだな…
    • 「業務が複雑なのだから仕方ない」という考え方を改めず、この上位階層でも同様の認識を繰り返してしまうと、意味不明なグチャグチャのCyberFrameworkプログラムが出来てしまうことだろう。
    • 結局、ビジネス(アイデア)自体の設計(や把握)の段階で、メタだの抽象だのいう概念を使ってアイデアの構造をすっきりさせる、っていう段階は常に必要なのだろう。メタや抽象を使わずに話を済ませることは、よほど単純素朴な話でない限り無理だ、と諦めるべきだと思う…

• アプリケーション == 設計図 …ごもっとも。これが一番良いわな。
• トライ & エラーで作っていきますので …実際(旧来方式だけど)ソフト作っていて思うのが、「トライ＆エラーを笑うものはトライ＆エラーに泣く」っていうか、トライ＆エラーというやリ方の「強さ」なんだよね。
• 設計図がないことには恐ろしくて変更もできない …上のドキュメント不在の話と同じで、ソフトそのもののドキュメントも、「書いたけど後で(きちんと)読めるようになってない」事が往々にして有る。もちろん管理を厳格にするという手もあるがそれには限界が有るようだ。一番良いのはドキュメントとソフトそのものが不可分であることだと思う。

• 作ったアプリケーションがどう動いているかをリアルタイムで確認する …やっぱりこういうことが出来て欲しいよね。
• 分割したプロジェクト間のインタラクティブが 100 の階乗分だけ出てくるわけですから、ほとんど打ち合わせだけで終わって …ぎゃはは…有る有る…(T_T)。というわけで、分割しただけじゃ駄目なんだよ。このページで指摘されてるように、分割しただけじゃ複雑化問題への取り組みを(たとえば結合テストの日まで)先延ばししたことにしかならない。却って性質が悪くなる。
• 自分が作っている複雑な世界を、見えるようにしなければなりません …合点合点合点！！

• 色々な試行錯誤のもとにゴールにたどり着くのが現実 …これを認めるべきです。ウォーターフォールは、オブジェクト指向に不似合いなだけじゃなく、プログラミング…ひょっとすると工学的な行為は全て？…に不似合いなのだと思う。
  • 俺風に言えば「下書きを大事にしろ」。
• クラスをダイナミックにローディングする機構と(後略) …こういうのはSmalltalkでもJavaでも(その他色々な多少モダン＆高級な言語で)できるんで、Objective-CやNextに拘る必要は(今は)無いわけだね。嬉しい時代だ。後はその嬉しさを活用するのは今を生きる俺たちのJobだ。
• 発想がいい加減なのは人間の美点だが、それがいい加減な「まま」では(ノイマン式)計算機は動かない。だからこそ、人間の思考(いい加減)を計算機に「教えること自体を試行錯誤」しないとならない。

• エンドユーザ(略)自分だけで作れる人は 100 人中 5 人しかおらず …あははは(^^;…
• ユーザーは「自分が好む世界」と「本当に実用的な世界」とのバランスが分からないんですね …確かにそれは有るかも知れない。ただ、ユーザがそのギャップに苦しむ機会すら与えられない現在の(多くの)状況に比べれば、贅沢(というのもなんだが)な悩みかも。
  • つまり、エンドユーザ計算機な環境では、ユーザーが何回か失敗して痛い目にあいさえすれば、ユーザはエキスパートになれるわけだ。

• 36 歳 …すばらしい。
• 35 歳くらいで管理職になって、上流設計で適当にごまかして …あはは。管理職だろうが上流だろうが構わないんだが、それが実際に「ごまかし」的な低レベルの仕事しかしていないなら(そしてそういう奴はしばしば居るようだ)、駄目じゃんです。
• 本来好きであったはずのソフトウェアが嫌いになってしまう …うわ。そういやこっちも、ソフト作るの自体が好きそうな人を、職場であまり見かけないぞ(T_T)
• 日本の教育にも似てますよね …げ。馬鹿は再生産されて現場に導入(笑)されていたのか…
• ソフトウェアをずっと死ぬまでエンジョイしていこうよ …全くです。せめて生涯教育のネタくらいには、なってほしい。

• 仕事を楽しくしなきゃ …全くです。部下を規律だのなんだの言って縛ればいいとか、苦労するべきだとか思ってる奴が居るが、ああいうのが日本の景気(笑)を悪くしてるんだと思う。
  • 「美しい仕事」をする(させられる)のは、楽しい(=現場の人を心理的にも技術的にも豊かにする)し、成果(納品物)としても良いものであるはずなんだから、そっちを目指すほうが良いに決まってる。
• 歴史に残るような仕事をするためには、一生続ける必要があります …必ずそうだとは思わない(例：Linusが一生Linuxを作り続け「なくてもいい」と思う)が、一生続けてもいいのも確かだし、糞仕事なら続けず出来るだけ急いで辞めるほうが適切だし。
• 辛いことから出来るだけ早く逃げ出すことばかり考える …確かに、その状態な若者たちに「品質上げろ」「利益挙げろ」と言っても無駄だろうね。
  • 客が美しくないことを言うならば、まだ仕方ない面も有るが、自社の人間(特に上司)が美しくないことを言うのは、やるせないね。だって自社の利益をみすみす溝に捨ててるのに気付かない人なんだもん。
• あの世に行ってからも「こんなソフトを書いてるよ」と、メールを出すくらいの気持ちで …かくありたいです。

このページを編集 (9243 bytes)

以下の 1 ページから参照されています。

• ソフトウェア配線　最終更新: 2005-01-20, 11:45:54 <61>

This page has been visited 5380 times.