2008年12月25日
デジタルドルフィンズ導入設置をしました。
営業の高松です。
本日は東大阪市にある傘の製造メーカーさんに
デジタルドルフィンズの導入設置作業に行ってきました。
ドルフィンをうまく使って、この会社の課題を解決していきます。
1．海外から自社のサーバー（ドルフィンズ）を見たい。
2.ＦＡＸを電子化したい。
3.ペーパーレス化したい。
（紙で出力しないで、ＰＤＦ化してそのままデータ管理したい。）
ドルフィンを導入することによって、
書類を捜す時間の無駄。
ＦＡＸなど紙を出力する無駄。
海外に書類を運ぶ無駄。
がなくなります。
まずはドルフィンに慣れていただいて、
どんどん登録していって下さい。
本日は東大阪市にある傘の製造メーカーさんに
デジタルドルフィンズの導入設置作業に行ってきました。
ドルフィンをうまく使って、この会社の課題を解決していきます。
1．海外から自社のサーバー（ドルフィンズ）を見たい。
2.ＦＡＸを電子化したい。
3.ペーパーレス化したい。
（紙で出力しないで、ＰＤＦ化してそのままデータ管理したい。）
ドルフィンを導入することによって、
書類を捜す時間の無駄。
ＦＡＸなど紙を出力する無駄。
海外に書類を運ぶ無駄。
がなくなります。
まずはドルフィンに慣れていただいて、
どんどん登録していって下さい。
2008年12月24日
電柱に巻きつけてあるあるもの
KUです。
朝の3S 清掃にて、表の清掃でした。
近くの電柱を見ると画期的な仕掛けが有りました。溝の形状が工夫されています。上から水を流すと汚れを下方に押し流してくれます。左が流す前、右が流した後の写真です。く のような ゝ のような溝が並んでいます。水を流してみると、なかなか爽快な汚れの取れ方でした
朝の3S 清掃にて、表の清掃でした。
近くの電柱を見ると画期的な仕掛けが有りました。溝の形状が工夫されています。上から水を流すと汚れを下方に押し流してくれます。左が流す前、右が流した後の写真です。く のような ゝ のような溝が並んでいます。水を流してみると、なかなか爽快な汚れの取れ方でした
2008年12月22日
イベント駆動型と逐次駆動型
KUです。
きょうはプログラミングの考え方と人の性質とをちょっと混ぜて考えて見ます。
先が長うございますので、先に結論を書きますと、
「『指示待ち』型の方々は、作業の効率としては良いと思いますので、そういう方が多い傾向には賛成です。主体で動かれる方は、指示待ち型の人をうまく活用できるように、�‐�況判断と指示に注力して頂く、��外部の力を主体と指示待ちの間に取り入れて指示待ちを活用する、ことが理想なのかもしれない。」でございます。
以下の内容は、それを理由付けせんが為の長駄文です。興味のある方、どうぞご覧くださいませ。
--
1990年代、パソコンのプログラミング・スタイルは逐次駆動型が主流であったと記憶しています。
当時ちょっと流行っていたBASICという言語を例に説明していきます。
パソコンを制御する命令を順に羅列するスタイルでプログラムを書きます。パソコンはそれを解釈し、その通りに実行して行きます。
例えばINPUT命令は、キーボードから文字・数値等を入力する。
PRINT命令は、ディスプレイに文字・数値などを表示する。
IF命令は、式を評価して、YES/NOを判断して、YES/NOの結果に応じた動作を実行する。
GOTO命令は、指定した行にプログラムの制御を移す。
以下の画面は、UBASICという開発環境で、掛け算をするプログラムを書いた例です。
「動きとしては、表示をし、数値を2つ入力し、掛け算をし、結果を表示する」を繰り返すプログラムです。
仕事のやり方に例えるなら、自分から動くタイプと言えるでしょうか。逐次自分で仕事を出して、判断して、対応も自分で仕切るという性格から、そのように考えます。
--
一方、イベント駆動型というスタイルが定着しつつあります。
出来事が起こるまで待って、起こったら処理を実行する、というスタイルです。いわゆる指示待ち式です。
ちょっと分かりにくいと思いますので、画面写真を交えて説明します。
数値を2つ入力する欄を設けて、[計算する]ボタンを設けています。
[計算する]ボタンをクリックすると、掛け算し、結果欄に表示する仕掛けです。
こんかい手書きしたプログラムは、掛け算の部分だけです。イベント駆動型プログラミングの効率の良さはそこに有ります。
(もちろん悪さも有ります。イベント駆動型の仕組みを実現する為の技術開発や、パソコンの処理能力も必要です。但し、それらは既に技術者たちの努力や、個人・企業等によるIT投資による効果で、現実的にはほぼ解決している、と考えています。)
おかげさまで、処理の部分は以下のように短いです。(プログラムの全体量は先程よりも長いのですが、その部分はあえて示しません。)
private void button1_Click(object sender, EventArgs e) {
numericUpDownAnswer.Value = numericUpDownX.Value * numericUpDownY.Value;
}
ここでは button1_Click の処理、[計算する]ボタンを押したときの処理だけを書いています。
動作としては、入力欄一つ目と、入力欄二つ目の内容を取り出して、掛け算して、結果欄にそのまま設定する、という処理を一行で書いています。
(一行で済んでいるのはオブジェクト指向の恩恵や、RAD手法の恩恵など他の理由が有るからで、ここでは問題では有りません。)
ということで、『指示待ち』的な考え方は、ことプログラミングの世界に限っては、有用であることが分かります。
--
プログラミングの世界ではなぜ、逐次駆動型→イベント駆動型(指示待ち型)に移行する傾向が見られたのでしょうか。
スケーラビリティ・処理能力の限界 が理由だと思います。
パソコンの能力が飛躍的に増大した結果、機能の要求が大きくなったことが要因ではないかと思います。
(後、納期とか開発コストの問題とか。色々有りますが、この分野は皆様の方が良くご存知かと思いますので、詳しくは触れません。)
解決の要因としては、先程少し触れたように、
�ゝ蚕儚�発や
��IT投資による改善
が後押しになっていると考えられます。
解決の手法としては、「技術者による 受け皿・インタフェース・フレームワーク の構築」が挙げられるのではないかと思います。
図化するとこのような意味です。
もうまとめてしまいますと：
プログラミングの世界では、「主体的なものと、指示待ち型のものとの間にフレームワークを構築することで、生産性が上がるに違いない」ということを大昔に考えた人が居たに違いなく、またそのような図式が完成することで、今日のプログラミングの環境は生産性が向上した、と考えています。
もしかしたら、この図式は現実の職場環境でも通用するかもしれず、この受け皿を構築するか、外部の力に委託するか、という手法で生産性が上がるんじゃないかなと書きながらぼーっと考えてみました。
以上―
きょうはプログラミングの考え方と人の性質とをちょっと混ぜて考えて見ます。
先が長うございますので、先に結論を書きますと、
「『指示待ち』型の方々は、作業の効率としては良いと思いますので、そういう方が多い傾向には賛成です。主体で動かれる方は、指示待ち型の人をうまく活用できるように、�‐�況判断と指示に注力して頂く、��外部の力を主体と指示待ちの間に取り入れて指示待ちを活用する、ことが理想なのかもしれない。」でございます。
以下の内容は、それを理由付けせんが為の長駄文です。興味のある方、どうぞご覧くださいませ。
--
1990年代、パソコンのプログラミング・スタイルは逐次駆動型が主流であったと記憶しています。
当時ちょっと流行っていたBASICという言語を例に説明していきます。
パソコンを制御する命令を順に羅列するスタイルでプログラムを書きます。パソコンはそれを解釈し、その通りに実行して行きます。
例えばINPUT命令は、キーボードから文字・数値等を入力する。
PRINT命令は、ディスプレイに文字・数値などを表示する。
IF命令は、式を評価して、YES/NOを判断して、YES/NOの結果に応じた動作を実行する。
GOTO命令は、指定した行にプログラムの制御を移す。
以下の画面は、UBASICという開発環境で、掛け算をするプログラムを書いた例です。
「動きとしては、表示をし、数値を2つ入力し、掛け算をし、結果を表示する」を繰り返すプログラムです。
仕事のやり方に例えるなら、自分から動くタイプと言えるでしょうか。逐次自分で仕事を出して、判断して、対応も自分で仕切るという性格から、そのように考えます。
--
一方、イベント駆動型というスタイルが定着しつつあります。
出来事が起こるまで待って、起こったら処理を実行する、というスタイルです。いわゆる指示待ち式です。
ちょっと分かりにくいと思いますので、画面写真を交えて説明します。
数値を2つ入力する欄を設けて、[計算する]ボタンを設けています。
[計算する]ボタンをクリックすると、掛け算し、結果欄に表示する仕掛けです。
こんかい手書きしたプログラムは、掛け算の部分だけです。イベント駆動型プログラミングの効率の良さはそこに有ります。
(もちろん悪さも有ります。イベント駆動型の仕組みを実現する為の技術開発や、パソコンの処理能力も必要です。但し、それらは既に技術者たちの努力や、個人・企業等によるIT投資による効果で、現実的にはほぼ解決している、と考えています。)
おかげさまで、処理の部分は以下のように短いです。(プログラムの全体量は先程よりも長いのですが、その部分はあえて示しません。)
private void button1_Click(object sender, EventArgs e) {
numericUpDownAnswer.Value = numericUpDownX.Value * numericUpDownY.Value;
}
ここでは button1_Click の処理、[計算する]ボタンを押したときの処理だけを書いています。
動作としては、入力欄一つ目と、入力欄二つ目の内容を取り出して、掛け算して、結果欄にそのまま設定する、という処理を一行で書いています。
(一行で済んでいるのはオブジェクト指向の恩恵や、RAD手法の恩恵など他の理由が有るからで、ここでは問題では有りません。)
ということで、『指示待ち』的な考え方は、ことプログラミングの世界に限っては、有用であることが分かります。
--
プログラミングの世界ではなぜ、逐次駆動型→イベント駆動型(指示待ち型)に移行する傾向が見られたのでしょうか。
スケーラビリティ・処理能力の限界 が理由だと思います。
パソコンの能力が飛躍的に増大した結果、機能の要求が大きくなったことが要因ではないかと思います。
(後、納期とか開発コストの問題とか。色々有りますが、この分野は皆様の方が良くご存知かと思いますので、詳しくは触れません。)
解決の要因としては、先程少し触れたように、
�ゝ蚕儚�発や
��IT投資による改善
が後押しになっていると考えられます。
解決の手法としては、「技術者による 受け皿・インタフェース・フレームワーク の構築」が挙げられるのではないかと思います。
図化するとこのような意味です。
もうまとめてしまいますと：
プログラミングの世界では、「主体的なものと、指示待ち型のものとの間にフレームワークを構築することで、生産性が上がるに違いない」ということを大昔に考えた人が居たに違いなく、またそのような図式が完成することで、今日のプログラミングの環境は生産性が向上した、と考えています。
もしかしたら、この図式は現実の職場環境でも通用するかもしれず、この受け皿を構築するか、外部の力に委託するか、という手法で生産性が上がるんじゃないかなと書きながらぼーっと考えてみました。
以上―
