アカウント名:
パスワード:
いやいや、素人から玄人まで分け隔てなくアプリケーション開発をできるようにしたVisualStudioなどのツールを手がけたマイクロソフトはすごいとおもう。
>>おかげで尻拭いが大変。これよく上から目線で勘違いしている人がいるけど結局そういったソースなどの管理以上にプロジェクト管理ができない人や部署、会社がいうせりふなんだ。
きつい言葉でいうと管理ができない無能なんです
VC++の面倒くさい前処理後処理イベント処理のコードを見えないようにして誰でも簡単にWindowプログラムを作れるようにしたのは本当に素晴らしいと思います。
VBぐらいのシンプルな言語・動作環境があれば業務の7割ぐらいはそれで回せるので、VB* [microsoft.com]はとても期待しています。
そうそうで、フック必要な仕様がボコボコ着いててあれ?となる。特に多かったのはEnterキーで項目移動。
なにせ基礎となるOSの仕様完全無視の、汎用機/コボラー源流のクソ仕様。そして今はブラウザアプリがその犠牲者。
作らされる立場だとそう思うんですけど、現場の熟練オペレータさんたちの作業を見ると結構見方が変わるものでやっぱり Enter キー遷移は必要なんだなあ、と。
あの人たち、画面も手元も見ないでひたすら脇の伝票をめくりながら信じがたい速度で入力していくのですよ。左手は伝票をめくるので入力は右手だけで、テンキーの数字と Enter しか押さない。Enter キー遷移なしで同じ作業を同じ効率でやってみてね、と言われたら正直ごめんなさいとしか言えません。
手書きの紙の伝票だの帳票だの申請書だの FAX だのといったやつらを絶滅させるか、画像認識・OCR の技術が飛躍的に進まない限り、Enter キー遷移はなくせないでしょう。
# というか、むしろそういった高スループットの作業にブラウザアプリは適していないので# そういう作業用にレガシーな入力端末を残すシステム設計をするほうが良いのではないかと。
管理以前に、素人を素人のままプロジェクトに参加させたことが問題だと思う素人も苦労とも同じ管理工数で管理できるのなら問題にはならないでしょうね
「ある業務」を「プログラム化する」ことを考えた場合、通常、「その業務の専門家で、プログラミングの素人」と「その業務の素人で、プログラミングの専門家」が組むことになります。従来の方法というか今でも「プログラミングの専門家が、業務の専門家に聞き取り調査を行い、仕様策定し開発する」というのが一般的な開発工程ですけど、その方法だと「業務として必要なものを過不足無くプログラム化」するのが非常に難しいんですよね。#いわゆる「顧客が本当に必要だったもの」
それよりも、「業務の専門家が、直接プログラミング」した方が、ちゃんと「顧客が本当に必要だった物」が出来ます。「できあがったプログラムがクソコードになる」かもしれませんが、それよりも「正しい要望通りのプログラムになる」方が非常に重要。#業務側が「当たり前だと思って言及していない」ことを、プログラム側が「言及されていないので実装しない」というのが非常にありがち。
そういう「プログラミングの素人な、業務の専門家が、自前でプログラムを作ることができる」という点で、VBなどのRADツールは非常に強力というかエポックメイキングなプロダクトだったんですよ。「業務の素人で、プログラミングの専門家」なハズのソフトメーカー側でだけ見るとクソコード量産機というデメリットしかない代物になっちゃうわけですが…
それよりも、「業務の専門家が、直接プログラミング」した方が、ちゃんと「顧客が本当に必要だった物」が出来ます。「できあがったプログラムがクソコードになる」かもしれませんが、それよりも「正しい要望通りのプログラムになる」方が非常に重要。
これに関してはVBよりVBAがいいんだよなぁ。どっちもVBじゃんと言えばそうだが、ソフトとしては一応別物だし。
「業務の素人で、プログラミングの専門家」なハズのソフトメーカー側でだけ見るとクソコード量産機というデメリットしかない代物になっちゃうわけですが…
実際には「ソフトメーカー側のプログラマ(肩書き)」でもクソコード量産してたのは結構居るので、結局は「エンジニアの能力を見極めることなく人月とか書いたステップ数だけで評価してたクソな管理職」の責任に帰結するんじゃないかなあと思うのです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
Visual Basicの最大の問題点 (スコア:5, すばらしい洞察)
どう考えても、こんな奴にプログラムやらせたらダメだろレベルにでも
プログラムができるようにしたこと。おかげで尻拭いが大変。
clausemitz
Re:おしりからミミズが出てきたYO (スコア:0)
いやいや、素人から玄人まで分け隔てなくアプリケーション開発をできるようにした
VisualStudioなどのツールを手がけたマイクロソフトはすごいとおもう。
>>おかげで尻拭いが大変。
これよく上から目線で勘違いしている人がいるけど
結局そういったソースなどの管理以上にプロジェクト
管理ができない人や部署、会社がいうせりふなんだ。
きつい言葉でいうと管理ができない無能なんです
Re: (スコア:0)
VC++の面倒くさい前処理後処理イベント処理のコードを見えないようにして誰でも簡単にWindowプログラムを作れるようにしたのは本当に素晴らしいと思います。
VBぐらいのシンプルな言語・動作環境があれば業務の7割ぐらいはそれで回せるので、VB* [microsoft.com]はとても期待しています。
Re:おしりからミミズが出てきたYO (スコア:1)
そうそう
で、フック必要な仕様がボコボコ着いててあれ?となる。
特に多かったのはEnterキーで項目移動。
なにせ基礎となるOSの仕様完全無視の、汎用機/コボラー源流のクソ仕様。
そして今はブラウザアプリがその犠牲者。
Re:おしりからミミズが出てきたYO (スコア:4, 参考になる)
作らされる立場だとそう思うんですけど、現場の熟練オペレータさんたちの作業を見ると結構見方が変わるもので
やっぱり Enter キー遷移は必要なんだなあ、と。
あの人たち、画面も手元も見ないでひたすら脇の伝票をめくりながら信じがたい速度で入力していくのですよ。
左手は伝票をめくるので入力は右手だけで、テンキーの数字と Enter しか押さない。
Enter キー遷移なしで同じ作業を同じ効率でやってみてね、と言われたら正直ごめんなさいとしか言えません。
手書きの紙の伝票だの帳票だの申請書だの FAX だのといったやつらを絶滅させるか、
画像認識・OCR の技術が飛躍的に進まない限り、Enter キー遷移はなくせないでしょう。
# というか、むしろそういった高スループットの作業にブラウザアプリは適していないので
# そういう作業用にレガシーな入力端末を残すシステム設計をするほうが良いのではないかと。
Re: (スコア:0)
管理以前に、素人を素人のままプロジェクトに参加させたことが問題だと思う
素人も苦労とも同じ管理工数で管理できるのなら問題にはならないでしょうね
Re:おしりからミミズが出てきたYO (スコア:1)
「ある業務」を「プログラム化する」ことを考えた場合、通常、「その業務の専門家で、プログラミングの素人」と「その業務の素人で、プログラミングの専門家」が組むことになります。
従来の方法というか今でも「プログラミングの専門家が、業務の専門家に聞き取り調査を行い、仕様策定し開発する」というのが一般的な開発工程ですけど、その方法だと「業務として必要なものを過不足無くプログラム化」するのが非常に難しいんですよね。
#いわゆる「顧客が本当に必要だったもの」
それよりも、「業務の専門家が、直接プログラミング」した方が、ちゃんと「顧客が本当に必要だった物」が出来ます。
「できあがったプログラムがクソコードになる」かもしれませんが、それよりも「正しい要望通りのプログラムになる」方が非常に重要。
#業務側が「当たり前だと思って言及していない」ことを、プログラム側が「言及されていないので実装しない」というのが非常にありがち。
そういう「プログラミングの素人な、業務の専門家が、自前でプログラムを作ることができる」という点で、VBなどのRADツールは非常に強力というかエポックメイキングなプロダクトだったんですよ。
「業務の素人で、プログラミングの専門家」なハズのソフトメーカー側でだけ見るとクソコード量産機というデメリットしかない代物になっちゃうわけですが…
Re: (スコア:0)
これに関してはVBよりVBAがいいんだよなぁ。どっちもVBじゃんと言えばそうだが、ソフトとしては一応別物だし。
実際には「ソフトメーカー側のプログラマ(肩書き)」でもクソコード量産してたのは結構居るので、結局は「エンジニアの能力を見極めることなく人月とか書いたステップ数だけで評価してたクソな管理職」の責任に帰結するんじゃないかなあと思うのです。