ProgLogg: STDEV（標準偏差）ジェネレーター．

2009年1月3日土曜日

STDEV（標準偏差）ジェネレーター．

* ********************************************************** *
TITLE：『平方根』のコメント(2009-1-1)から＞BASICプログラムで画面から値を入力させ、標準偏差の計算の過程をエクセルに吐き出せたら、（学生さん）など便利かもしれない。

△『STDEV（標準偏差）ジェネレーター．』の画面を、作成してみました。

　　(EXCELに、吐き出す方法を考え中です。）

　　｛[Q].意見がある人は、連絡を下さい。｝~(atom)

1 件のコメント:

kids atom.2009年1月3日 14:51
適用業務のプログラムを作る過程で、演算した結果の検証は必須です。
今までは、MSのVsual Studio製品では、プログラム作成時には強力デバッガがあるので内部変数は簡単に追えますが、それまでの言語製品では、結果の値の検証は至難の技でした。
とはいえやはり、常に開発環境の中でプログラムのソースを見ながら検証するのは、大変な労力が必要で疲れます。
かねてから、こういったプログラムはあればと考えていて、これからは役に立つでしょう。
｛安価な値段で、短時間で作成する環境を提供して頂けるMSさんに感謝します。｝
(atom)
返信削除
返信

コメントを追加

『今日のひとこと』

◆2010-03-26 ・TITLE:《人工太陽》（その二）

とにかく、ここのHTMLエディタは、ホントに良くできてると関心している。

人工太陽の件は、たまに太陽が見えなくなったら、どうしようかと不安になる。それから、でも良いか？

　やっぱり、技術リテラシーの進歩というのは、需要に牽引されるファクターが多いことだろう。しかし、大儀名文があっても、簡単には他に見せられないわけで、個人の未公開アイディアを誰が参照しているか分からない世界での思案は、全く不安になる。高い開発理念と権利の保護の観念を持ち、結果、他人の評価が大きい場所へと開発の場は、移るのでしょう。

作者が知らないうちに、類似イディアの情報が、未知の空間を飛び交い、その気配をそれとなく感じる不安ほど、怖いものはない。

~atom()

◆2009-11-17 ・TITLE:《人工太陽》

誰がいいだしたのか、各国民間共同開発プロジェクトで、（原子力）《人工太陽》の開発が、早急にいる。軍事予算削ってでも、．．．軍需になる。'RedProjects' か'GeenProjects'でも．．．

~atom()

◇2009-10-21 ・TITLE:JP DOMAIN

『mailto:xyz@cst-neco.jp』としたときに、これをクリックすると、メーラーでは大丈夫か？

（すみません、間違った！）

~atom()

◇2009-10-03 ・TITLE:WebFormまだ、手をつけたことが、なのですが、以前から私たちが、手をつけているアプリケーションの実現は、WebFormからでは、無理だと思う。｛パット見ただけで、画面コントロールが、少ない気がする。｝

作業コストの見方からいうと、Computtingの極みなんだけども、以前からの継承を、WebFormで焼き直すのは、本当に止めて於いて方が良い。

飛び先のレベルが違うソフトなど、安直で勘違いしたソフトが目に、つく。~atom()

◇2009-09-12(2) ・TITLE:＜DEBUG operation & function＞ (For Microsoft VisualStudio2008 IDE-DEBUGER)を、アップ。

直感的では、ないですけど、

『MS IDEに於けるデバッガの作業画面』は、待って下さい。

~atom()

100%Original & License Free このSiteは、全て１００％オリジナルで、今のところ、ライセンス・フリーなので、安心して参照して下さい。但し、軍需目的は、私の承認が必要です。今回から、宇宙開発への利用は、私の承認は、必要ありません。ちょっと、宿題も、勿論ＯＫです。著作権は、主張しますので、利用の際は、明示を心がけて下さい。~atom()

◇2009-09-12 ・100%Original & License Free

このSiteは、全て１００％オリジナルで、今のところ、ライセンス・フリーなので、安心して参照して下さい。但し、軍需目的は、私の承認が必要です。今回から、宇宙開発への利用は、私の承認は、必要ありません。ちょっと、宿題も、勿論ＯＫです。著作権は、主張しますので、利用の際は、明示を心がけて下さい。

~atom()

◇2009-09-11 ・MS IDEに於けるデバッガの作業画面

MS VisualStudioには、強力なデバッガが使用できるが、直感的な理解の助けを進める為、IDE（統合開発環境）に於けるデバッガの作業画面のハードコピーと簡単な、コメントを掲示できたら、良いのかもしれない。

~atom()

◇2009-09-10 ・TITLE:リッチテキストとＨＴＭＬConversion

この分野は、私は素人だけど、リッチテキスト？とＨＴＭＬのConversionは、やめといた方が、良い。

JAVA Appletも、平文など、見てられない！

頑張っているのは、分かる。SEは、いないの？

エピステーメは、Appletのインプリメントを、しているのか？くだらないことはしない。

~a to m()

◇2009-09-09 ・TITLE:新しいソリュージョンの予感．

実は、2009-09-05の掲示、『Ｃ＋＋．ＮＥＴに、ついて』は、反響が感じている。感じているというのも変で、言い方を変えると、反響があることが、必然になる。いまの学校でのプログラミングは、Ｃ言語が主体と、なっていると思う。しかし、やはり、馬鹿大や大コン　レベルには、やはり、ハードルが高い、となると、Ｃから派生した、ＪＡＶＡになる。ＪＡＶＡは、本格的な言語では　ない。ダウンザイジングの風が吹くと、分けのわからん、Web言語、スクリプトの類や、また、ミニコンにセット売りのデ－ターベース利用言語になる。後者は、１～２Ｗ程度から一ヶ月の研修コースぐらいで、習得可能なのか、知らない。簡単というのが、お触れ書きか？。（といっても、ステートケントの中が、何をしているか分からないので、結構難しい。私には、絶対無理。ＣＯＢＯＬの”ＵＮＴＩＬ”の様で、頭を、硬直させる。）となると、実は一つのステートメントで、一つの仕事をする、ＢＡＳＩＣやＣが、ゴールへの近道に感じる。ただ、簡単な処理をさせるにも、ＪＡＶＡの何倍ものステップを要する。ＪＡＶＡは、複雑な処理もスッテプが少なく出来るが、トラブッタ時の対応策に困る。極論すると、納品後の立ち上がりで、簡単な要求がのめない、お絵かき言語になる。私の認識では、プロの使う言語ではない。言語のインプリメントにない機能への仕様が満たせない結果になり、プロジェクトが暗礁に乗り上げるケースが、ほとんどと見ている。実際には、３年生までが作ったＪＡＶＡ言語のシステムなど、お金など貰えると思うのが大間違い。それは、論外になる！

ところで、私はというと、2002年からVB.NETを使って来て結構いける。プログラミングで、一番手間なのは、画面になる。画面は、フォーム・デザイナで、（MOUSEで、コントロールを配置すると、）学生でも簡単に設計と作成ができる。例えば、TextBoxを、どこへ。CheckBoxを、どこへと、Mouseで配置していく。

C++は、というとMFCで作ると、結構手間になる。しかし、本当の意味での、プロジェクトは、これに限ると思う。例えば、火星探査機などや、核開発は、これでないと、取り返しがつかないことになる。いい方を、変えると、こと細かな部品の隅々まで、修正が、きくのではないかと、思う。ただですネ、超プロの言語になる。

秀才で大学にあっては、常にトップ、企業に入っては、世界の誰々といった人でも、なかなか、手ごわい。学生時代C言語には、自信があるのでと、会社の上司に話をし、手を付け迷宮に入り、誰にも相談できず、死ぬ思いをしている人は、少なからずいるのでは、ないかと思う。

私達は、全員、宇宙開発のシステムを、プログラムするわけではない、まだ私も、足のくるぶし迄しか、使ってないが、『Ｃ＋＋．ＮＥＴ』なら、画面は簡単。VB．NETとライブラリと、同じハズで、これは、使えると思う。その他、C言語のステートメントは、そのまま使える。但し、これはWindows FORM画面の話で、デバッガで、簡単に、変数が追える。WebFORMとなると、まだ、お手伝いできない。たぶ～ん、画面のコントロールも少なかったか．．．。

デバッガも使えたかどうか、分からない。（乱文ゴメン）。

企業のセキュリティと引継ぎのハザマで、つらい思いをしている人は、いるのかも知れない。これは、会社に相談するかどうかは、あなたの問題。私の経験だと、時間をとって、作り直した方が、早いのが、80％。ほんとに、厳しい世の中だな～。

＜以上＞　　　　~atom()

◇2009-09-06 ・TITLE:パスワードの盗用詐欺に注意．

例えば、何かのタイミングで、キャッシュをクリアさせるなどして、ログイン時、ログイン・ネームとパスワードを入力するタイミングで、パスワードなどを搾取する常習者がいるので、十分注意してください。~(atom)

◇2009-09-05 ・TITLE:『Ｃ＋＋．ＮＥＴ』における、作成作業画面．　(MS Visual C++ 2008) - 2009/09/05

かなり、作りが粗雑な資料だが、早い方がメリットがあるのでは、無いかと言うことで、また、下記の本を取り寄せるまで、待ちきれない人の為に、取り急ぎ、上記の件名(TITLE)の掲示をしました。

了解願いたい。（但し、私のオリジナルです。）

~(atom)

◇2009-09-02 ・TITLE:『明快入門 Visual C++2008 シニア編』[著]林晴比古 [刊]SoftBank Creative 2009年8月24日初版第一冊発行 ISBN978-4-7973-5580-2

この本の構成は、第１部ネイティブプログラミング(MFC) 第２部マネージプログラミング(．NET) 。

この本でいくと、『Visual C++．NET』が、可能となる。

* ***** * ***** * ***** * ***** * ***** * ***** *

→ 知ってた？コンシュマー界の一大事！？　或いは、知らないのは、私だけか？

この本よると、ＶＢ．NET、ＶＣ＃．NETライクな、コントロールが、使えそう。ただ、ネイティブコードでは、無く、中間コードを吐くので、ランタイムは、必須なのでしょう！？

※遅くれてしまいましたが、ちょっとお久しぶりです。今日は、これくらいで勘弁してください。怒らないで．．．

~(atom)

◇2009-06-11 ・TITLE:少し落ち着いたので．．．

　少し落ち着いたので、半年ぶりに勉強を開始したが、色欲に走って、なかなか時間が取れない。

　半年あまりのブランクは大きいが、いろんな他の勉強をさせてもらって感謝している。

　様々な浮き沈みもあったが、有意義な日々だったことには変わりはない。

前向きな意識が、僕の取り巻く、忌まわしい状況を解除させる。 - '放心状態'より

◇2009-03-20 ・挨拶を忘れてました。

大変、ご無沙汰しております！

さて近頃、昨晩遅々まで仕事して、朝見てみるとストレージ上の文書が、どうもおかしい！　といった人は、結構いると思います。

私は、記憶が良い方ではありませんが、個人的なレポートとしては、かなりあるという気がします。

ただ、証拠が無いので、疑うことは出来ません。

そこで、対策としてワープロでもCOPY & PASTEを、誰もが簡単に使いこなせる時代なんですから、テキスト形式簡単な単純なエディタを作成し、コピー&貼り付けで、そのエディタに持っていき、行毎にCheck Sumを取り、更にCheck Sumの縦を同様にXor（排他的論理和）のようなものを求め、結果の値を切れ端メモにして保管しておく様なことが、必要なのかも知れないと思います。

~(atom)

◇2009-03-20 ・3/15の前掲の記述で、先ず「デッドロック」の単語の使い方は、間違い！

皆さんが普段いっているフリーズの事で、単語の使い方がおかしいので、お詫びして訂正します。

私の云っているのは、「NULL Pointer assign」の事で、メンバ（変数）のポインタのアドレスが、アサインされずNULLを指すことです。

これは、必ずしもフリーズを起こすわけでは無く、機種に依存すると思います。

ですが、普通はほぼプログラムがハングします。

~(atom)

※「デッドロック」とは何かというと、私の知っているのは、ＩＯバスに同時に書き込みをしたりして、ＩＯバスがロックすることです。

｛ここは知識程度なので、解説は詳しい人に譲ります。間違ってたら、御免。｝

◇2009-03-15 ・SEの中には、C言語がデッドロックを起こす事を知らない人がいる。

プログラマの中には、デッドロックを起こすからといってコンパイラメーカーを訴えるという人まで出てきかねない。

いずれも、ナンセンス！

コンパイラの良し悪しは、使ってみないと分からないが、評価は必ず使い手がする。

また、自分の作ったプログラムは、ふつう自分（提供者）が面倒を見る。

例えば、材料が悪くても、製品は悪ければ、提供できない。

リリースした後で、材料が悪かったというのでは、誰も相手してはくれない。

当然、自分のプログラムをリリースするかどうか決めるのは、SEでは無く、プログラマが判断する。

何故なら、SEがリリース後デバッグすることは、まず無い。

プログラマだったら時間がある限る、黙って直さないといけない。

だから、自分のプログラムをリリースかどうかは、プログラマが判断するべきである。

プログラムが完璧であるというのは迷信だと思うのは、私だけなのか？

今社会では、もし心を読む機械があるとしたら、永久にリリースなどできないでしょう。

~(atom)

◇2009-03-06 07:45・通勤と一緒で、朝一はラッシュしてページが開かない。

今や LANの標準的な帯域はＧＩＧＡなのでしょうか？ - 隔世の感がする。

当Local areaでは、真面目なので、帯域は10M.（笑）

~(atom)

◇2009-03-04 08:36・『今日のひとこと』を書き込むと、治りました。済みませんでした。

◇2009-03-04 08:33・掲示板の一部に障害が、発生しているようです。申し訳ないです。

◇2009-03-02 ・ドメイン管理者メール受付開始．（感想やご意見がありましたら、下記メールアドレス宛まで、ドシドシお寄せ下さい。）

mailto:info@cst-neco.jp

※初心者さん用メールアドレスも開設検討中！

◇2009-03-01 ・ドメイン取得（参加を期待しています。）

http://cst-neco.jp/- Computer science technology net-com japan

◇2009-02-27 ・仕様書は、最初に書くのも普通だが、完成後は提出先の要求のレベルに合わせて書くことが多い。

どのレベルで書きましょうかと聞くと、大抵は、固まってしまったり、こちらで検討するので、兎に角、最初から全部資料を取り揃えて提出せよといったことが多い。

そういった場合、電話や顔を合わせお聞きすることになるが、

最初から確固とした仕様書は有るべきだと云う方は、それなりの対応になる。｛多くは、しゃべり方ばかりをおっしゃるので、困ってる？｝

初回の打ち合わせなどは、構えない現場のパートのおばさんの方が、仕様打ち合わせは、気持ち良くスムーズに進む。

｛10分休憩にアメなど、もらうと気持ちが良い。｝

　開発では最初の仕様書から、幾度となく見直しが行われるので、その都度訂正した書き込みをした仕様書があるとしても、開発後提出を求めらてから、状況に応じて書き直しになる。

｛一度に如何にに多くのドミノを倒すかに人生を掛け、砦の中から出ようとしないのも一つの生き方だが、行く先々で仕事の中で触れ合いを求めるのも、良いかと思う。お気を付けて帰って下さいと云われるたりすると、男女に限らずそういう人が好きになる！｝

~(atom)

◇2009-02-27 ・要求仕様書とソースがあって、引き継ぎ後、前任担当者ももういない。

それぞれを、見比べると差違が見つかる。

さて、どうするか？

・問題がないのでほっておく。

・要求部署に聞く。

・仕様書を訂正する。

・ソースを訂正する。

<前のひとことの追記>

→ASMは、8Bitsなことぐらいは誰もが知っている。

→COBOLではディメンジョンを切ってから、その後にコードを書く。

→Cで変数を宣言する前に、変数を使用する人はいない。

．．．で、何か？

~(atom)

◇2009-02-27 ・今はどうか、コードだけを書いてモジュール構成図を提出しないとクビになる会社があると聞いている。

コードを書かず構成図だけ書くと、あたかも構成図を書いた人が作者に見える。

そういう人は、プログラマとは云わない。

こういったモジュール構成図は、ブロック間の繋がりなどが図示され、全体見渡しが良くなる。

他のプログラマがこれを見ながらソースを読むと理解が早くなるが、コードに内容が無いと意味がない。

私はとはいうと、図は書かず、子供のことが気になるので早く帰って洗濯をした。

子供の成長を見ていると幸せになる。　帰ってから誰かがコッソリみる事がほどんどなのか？　ともかく、明示的に引き継ぎを依頼された事は何度も無いので構成図とは全く縁がないし、チャント云わないと関知しない。

むしろ、時間が有れば他人が放置したねじ曲がったコードと戦い、作者にはなれなかっが、結果として、有り難がるお客の顔を見るのは、嬉しいことだ。

ところで、コーダーの世界には、遠方への前方参照の解決という問題がある。

ASMでも、CでもCOBOLでも、変数定義がコードより先に来るのは、コンパイル時に変数を先に認識させる必要があるからである。

マイコンの出始めにはメモリなどリソースが高価で、今よりコンパイラが未成熟だったので、資源節約の為ラベルやサブルーティンの飛び先及び変数定義を、先に記述するケースが普通になる。

これら、変数定義やラベルの飛び先を先に記述するのは（ラベルの場合、上から下に飛ぶのは）、人の感覚として、違和感はない。

ところが、ラベルやサブルーティンの場合、飛び先を上から下（源流から下流）に飛びように書くと、人の感覚としたは素直にみえるが、前方参照になる。

コンパイラが未成熟な場合、前方参照（未だ出会ったことの無いシンボルへの参照）は、シビアなエラーになったり、コンパイラに余分な処理が必要となることがある。

私のやり方では、下から上の方向（文末から文頭の方）のシンボルへ飛ぶ。｛シンボルは、先に認識させり必要がある。｝

コーディングとは縁の無い方の感覚から云うと不謹慎なことかも知れないが、これら後方参照は、私（達）の習慣になる。

飛び先が下から上（下流から源流）飛ぶのは、不自然なことかも知れないが理由がある。

モジュール構成図を元にコードを読む方は、今後留意されたい。

最後に、コーダーは、常に自分の時間を使ってでも、吐いたコードに磨きをかけるべきである。

~(atom)

◇2009-02-23 ・Feb 23, 2009の掲示のテーマの'コンピューティングにおける数値の扱いについて．'については、前回のテーマ'コンピュータ言語でのZEROの扱いについて（はじめに）'を上げてから、日も余り経っていないですが、それも含めて、過去の世間標準の'数値の丸め方'などもあるものの、それ以外の項目にも自分のやり方や考えを持っている。

　また、8Bitsマイコンが、この世に浸透してから時が経ち、他からの受け売りや伝え聞いたところもあるが、なんとか次世代に未整理でもある程度書いたものでまとめて伝えることは、決して無意味なことではないと思う。

　掲示にあったては、他のエンジニアリング的な所産の権利を侵害するつもりもないですが、万一抵触する可能性があれば、メールなどで単刀直入に指摘をお願いしたい。

　先ず、テーマの'数値の扱い'の考えられる項目を列挙すると、次のようになる。

・数値の内部の値の持ち方．

・数値の外部表現の仕方．

・数値の丸め方．

・数値の有効桁．

・数値の大小比較．

・基数の扱い．

・ZEROの扱い．

・小数点の扱い．

・桁落ちの問題．

・型の一致の問題．

・テンプレートについて．

・統計値の求め方．

---------- ・ ----------

以上だが、'統計値の求め方'については、提供者のソフトの秘蔵のノウハウもあると思うので、他の権利を侵害しないように出来るだけ標準的な形で、また算数を理解できる程度の頭で平易に記述出来ればと思っています。

^(atom)

◇2009-02-22 ・私のくだけた時の文章が、『ハンプティ』と云われるのは良く分かる。

それは、多分受け取る側の問題で『ハンプティ』のいわれ方でさえも、比喩と受け取るかはどうかかは、貴方次第！（笑）

上の二行を読み、思わず苦笑してしまうリテラシーのある貴女とお付き合いたいしたい。mailto:kids.atom@mbn.nifty.com

~(atom)

◇2009-02-22 ・テーマはアップして中身がない掲示もありますが、使ってもらっても結構です。

また、ご一報頂けたら幸いです。

mailto:kids.atom@mbn.nifty.com

本日掲示したテーマ:「コンピュータ言語でのZEROの扱いについて（はじめに）」については、各言語でZEROの扱いにかなり差があるようです。算数を理解する程度の頭で考えると、例えばCOBOL系の零'0'がなんで、未入力（空）を意味するのかが、不思議になります。

それには、多分理由があります。

　・　

　・　

　・

私の拙い経験則から、それらのことがどのようになっているのか考えられたらとは思っています。

敬具

◇2009-02-21 ・Feb 21, 2009 Title:'Print Form Design'のあと書き．

2/21 'Print Form Design'に掲示した内容のあと書きとして、これから、半角入力文字列の属性のテストをするルーティンを作る場合を考える。

言語は、COBOL、BASIC、Cとし、 instr(chr) 関数や int isalpha(char* ch); メンバなど、標準関数やライブラリは使わないことにする。

私なら、関数内(COBOLの場合は、ロジックになる。)では、二つのネストしたループを使い、外側のループでは入力文字列から一文字ずつ取り出し、内側のループでは、コンスタントな文字列変数にマッチするかをどうか一文字ずつCheckする。(ex. chStr = "ABCDEF..."、char ch[26] = "ABCDEF....";、　02 CHECH-MOJI PIC X(26) VALUE "ABCDE...".)

関数からの結果は、論理型（値）を、返す。(COBOLは省く。)

ステップ数は、11インチ紙 - 2～3枚程度で、200stepぐらいが目途だが制限無し。（200stepを大幅に超える場合は、ソースプログラムの文頭で、コメントなどで説明をすること。）

制限時間は、静かなところで 3時間以内 - 朝9時から始めて昼12時までぐらい。(超特急で、1～1.5H）

　　　　　　- （関数説明書や評価テスト後の訂正、は別）

こんなところでしょうか。

　・

　・

　・

　そうして色々考えていると、世間では何故JAVAに流れるのかが、見えてくる。

学校では教育言語としてC言語を教え、このC言語から派生したと思われる JAVAは、ライブラリが充実している。

また、ネットワークで使用するのに、適している。

　しかしながら、私などパッケージを開発するプログラマは、出来合いのライブラリを使うのを嫌がる。｛多分痛い目に遭わないと、分からない。｝

こういった、スクリプトやアプレットなどで困る理由で、すぐに思いつく事柄は二つある。

①プログラムで使用しているライブラリ中身は、外からでは見えないのでバグや挙動がおかしい時、ソースが無いと原因が追えない。　

※｛関数の機能仕様書があっても、細かい挙動が分からない時がある。そういう意味では、'C言語'なのだが、火星探査機のようなプログラムを作る訳ではないし、私は低級プログラマなのでそんなにコストは、掛けられないというのが本音になる。

RPGやCOBOLの○○句は気持ち悪いくて - シンプルなのが良い。また、どんな言語でも仕事で使うのなら、ソースを見てネイティブに理解できる言語が良い。｝

②言語に依存すると、移植性が低くなる。（私の場合、勉強が足りないので、言語に依存する部分が多いと直感的な理解がしにくい。言語に関係なく、命令は同じ回路にしたい。）

　また、今まで述べたこと以外に、画面から入力された文字列のTestとして確定キーが押されされると、以下のCheckが必要となる。

①未入力Check．

②長さのCheck．

③文字属性のCheck（全角、半角なら数値か文字か？）．

④数字の場合のCheck、他．　

※④の場合、例えば数値のZEROは入力不可、下限と上限(ex.1～999)の範囲Check、などがあるが、今回説明は、パス。

　これらことは、プログラミングの経験が少ないＳＥや営業には、口話で真意はなかなか伝わらないようである。

ライブラリがあるのに、何故無駄な時間を使うのかという話しになりがちだと思う。

ここで何か気の利いたたとえ話でも思いついたらとは思う。

こられが、実際の話なのですが、．．．．

＜御礼＞

最後に、今、この「今日のひとこと」に書き込みをしていますが、私（達）によりよい環境を提供して頂いている、この掲示板の提供者と開発者に感謝します。

｛問題があれば指摘もしないのに、度々プログラムが大きな改善や小さな修正されていくのが良く分かります。

彼らは、本物です。｝

~(atom)

◇2009-02-21 ・もうすぐ、ウイルスソフトの期限が切れる。

HDDが、壊れて一年になる。

HDDがイカレタのは、期末とは関係ない。

これよりかなり以前のこと、私が自宅のマシンに、ウイルスソフトを入れたのはNimdaに感染してからで、会社では既に導入はしていた。

必要なデータのあるので、朝方四時までかかり隔離した。

他のウイルスも経験があるが、Nimdaほど恐ろしいものはない。

きっと、放射能の拡散もこんな感じなんだと思う。

関係ないようでも、会社と自宅との結びつきは強いと思った方が良い。また、その性格から既存の編み目を潜る　新しいウイルスも常時発生することだろう。

時代と共に、ペナルティを承知で仕事をする働き者を　攻撃する動きもあると思うので、これからは　辞めた方が良い。

話が変わるが、宇宙の始まりに「虚数時間」が流れていたという話があるが、よく分からない。この宇宙の始まりでは無い　今も虚数時間が流れているのか？

ちんぷんかんぷん．

◇2009-02-20 ・いま、懐中電灯の単ニの電池が切れたとしよう。保証期間内の3ヶ月であろうが、10年後であろうが、電池を変えれば良いわけで、メーカーヘルプデスクを頼る人も、少ないと思う。

　例えば、ジャンボジェット機がライフ　サイクル内で、搭乗口のハッチが開かず、飛行場から飛ばなければ、大変な問題になる。

　整備の担当が連日徹夜の末、原因を突き止めると搭機口のハッチのセキィリティ　センサーの電池切れと判明した。

　そして、商社経由で、そのボタン電池のメーカーの営業に問い合わせると、消耗品なのでサポート外といった返事。

整備担当が、事故統括責任者に報告、設計部署に連絡が伝達される。設計部署では、その部分のデサインをした者ものは、すでに退職して行方が知れない。

月例の取り締まり役定例会議では、設計課長が呼ばれ、役員が訓辞を垂れる。

『あれほど、問題が起こらないように、言ったではないか！』

　ＰＣの話をすると例えば、節約の為、ＰＣの画面の節電対策がしてある。その部署では、十年来ブレーカーを落とすのが習慣で、実は会社の指示となっている、ＰＣの節電対策も会社の指示である。

節電対策をするとＰＣの画面が黒くなる。

　ＰＣ画面の表示中にブレーカーを落とす人はいないが、習慣となっているブレーカーを落とす時に、ＰＣのことに気づく人は、以前は少なかったと思う。いまは、そうでも無い。

一概にはいえないが、気づかないと結果として、そのＰＣの寿命は保証できない。

　

　何々の一言という話があるが、配慮が足らないといえばそれまでで、実は大変な問題を秘めている。

　場合によっては、原因を公表せず、同時期買ったＰＣ全部　寿命だから買い換えて下さいという話になりかねない。

ジャンボ機も　そう！

　これから、システムが大きくなればなるほど、こういったことは多くなる。（持論ではあるが、一人の人間が把握できないほどのシステムは、作ってはならない。）

また、ヘルプデスクやサポートは、ユーザーの為にある。

問題は　サポートの技術的な知識量の話ではなく、（未知の）問題を解決できるかどうかの話。

　最後に、設計前に引き継ぎ出来る技量がある者がいるかどうかの予想は、なかなか難しい。　

/乱筆御免．

◇2009-02-17 ・私たちの間ででは20年以上も前から、言い古された言葉ですが。『プログラムには、ワンステップに、一つの悪魔でいる。』といった事を良くいいます。

また『（隠れた）曲がり角の向こうには、いくつ曲がり角があるか分からない。』といった表現もします。

プログラムの修正時間の予測は困難です。

これは、プログラムを一行修正すると、他の影響を及ぼす範囲の関連の部分を全部見直す必要があると言うことです。

ここに、プログラム作りが困難な理由の一つがあります。

　例えば、6,000ステップのコボルのプログラムがあるとします。

つまり、6,000ステップ中にいくつバグが分からず、ワンステップ修正することで、場合によって10箇所以上の副作用がおきます。

そして、ワンステップ修正する毎に、6,000ステップで副作用が起こらないかを調べる必要があります。

更に、その中の一箇所を不注意に触ると、また、副作用が起き、相乗的にバグが広がります。

ここまで書くと、プログラムの修正に掛ける時間の予想の難しさが、少しは分かって頂けると思います。

また、放置して誰の触らないプログラムならともかく、プログラマが、他人様のプログラムを無断で触ること無いのはこの為です。

ホントに無断でプログラムを触られる事ほど、ひどい事は無いです。

また、作業中に意味も無く声を掛けるのも、関心しません。

とにかく、1年生プログラマが作ったものほど、ひどいものはありません。相乗的に広がる不具合に気づかないケースがほとんどだと考えます。このレベルでは、方法論では無く、毎日その日の終わりに熟練者が一行ごとにじっくり見てあげる必要があります。プログラミングは、口頭伝承の技に近いものが有ると考えます。

/乱筆御免．

◇2009-02-14 ・時間起源：『時間は空間とともに現れるのか？』

私の頭では、よく分からない。

俄に考えると、何も存在しない虚無の空間を考える時、もうすでに時間は存在している。

確かに、「時間の矢」は存在し、私（達）は、未来には戻れないと思う。

時間は空間とともに現れるのでは無いかと思う。

~(atom) mailto:kids.atom@mbn.nifty.com

http://www.nikkei-science.com/page/magazine/0809/200809_040.html

◇2009-02-13 ・万物よ地場、地場より先に必要なのは時間なのでないだろうか？

~(atom)

◇2009-02-13 ・この世の始めがあるのなら、

　　　　　　　　　　　　　この世の終わりがあるのだろうか？

- そんなこと、まだ出会ってなので、分からない。（笑）

~(atom)

◇2009-02-11 ・今日は、昔でいうと'紀元節'．

父からはお辞儀は、最敬礼は'45度'、敬礼は'15度'と聞いている。

ネットで調べると敬礼は'10度'とある。

また、背筋を伸ばすのも'敬礼'とある。

（育ての親は、嘘つき！）

◇2009-02-10 ・~(atom)論を考えていますが、生きてるあいだに何か、形にできるか？

・この「今日のひとこと」を、書き込んでいるエディタと、この掲示板の文字数の上限は？

◇2009-02-07 ・前回の『今日のひとこと』の光ケーブルの帯域の分割の話は、暗に指摘のあっったとうり一本の光ケーブルに複数の波を乗せる技術をいっている。

一つの技術が世間に行き渡るまでには、時間が掛かる。

　やはり、unixやC言語などの開発製品なども例外では無い。

それらフリー系呼ぶトーンの軽さには、いくつかの問題を秘めている。｛C言語は、簡単には習得できない。冗談で仙人への道ということはよくいわれるが、初心者にとってハードルが高いことには変わりはない。｝

　今は、管理意識、話し方やボキャブラリー（語彙）ばかりが先行し、プログラムテクニックや言語学？については、耳にすることは少ない。

　今のアプレット、スクリプトの類などのソフトウェアから開発されるプログラムは、その産物である。

｛ジェネレータから生成するＨＴＭＬなどのソースコードなどは、ナンセンス！｝

　また、製造業の製品は、ソフトウェアの手を借りていないことは少なくないし、もっと問題なのは、（作る／作らせる）人の姿勢かもしれない。学校、研究諸機関の（ライセンス）フリーの言語の継承の流れに安易に乗らず、どの言語製品が良いかは、厳選してほしい。

　それと、とにかくプログラムを作る自分をやり方早く見つけ、簡単にその流儀を曲げてはいけない。

　話を戻して、波にのせるレイヤの内容は、お父さんしか興味のないところは外し、コマーシャルとそれ以外の三つぐらいに分けてほしい。

＜p.s.＞

｛LANについては、平日はネットーワークの本を読むこと半年ぐらい朝から晩まで本を読み、土日は車で愛犬と静かなところへいって、夜が明けてから暗くなるまで、PCでドキュメントをまとめた。

今の私にできることは、これぐらい。いたらぬ点は、勘弁してほしい。｝

◇2009-02-07 ・今年わ。（2009年）．．．

2001年宇宙の旅という映画があったと思うが、今年は　それをはるかに過ぎてしまった。近頃は、遙か彼方遠くから、まだ会った事のない妹レイヤの助けを呼ぶ声が聞こえてくる。．．．そんな感じがする。

それはともかく、都会の砂漠で会話もしないのに、行き交う人々と笑顔でコンタクト出来ることは、お互いに誰にもいってはならない。いうと、秘密組織の攻撃にあう。（笑）

　初老をとうも過ぎたというのに、女性が妙に気になるのも、それはそれでイイのかもしれないが、ほんとはお互いの問題だ思う。

　が　しかし、もの心がつく頃の子供への悪影響は、計り知れない気がする。というのは、旦那や子供が家を出払ったあと、家を守る主婦の真昼の妄想が気になる。

　私と致しましては、家庭内をともかく、共有部分のインターネット情報の伝達には、光ケーブルがかなり普及したのでは無いかと考えている。　

　ここで、光ケーブルでは、帯域の分割は同じインフラで可能だと思うので、そろそろ、お父さんしか興味を示さない大人の．．．テレビでいうような．．．チャンネルとそれ以外を手始め分け、望みもしないのに公の人の目に入らないようにしてほしい。（お父さんも、その方が都合が良い。）

　あと、Webメールを打ったあと、女性の下着が出現するのは、どうしたものか、バレンタイン前とはいえ、後ろめたい気になるのは、私だけか？気なってしょうが無い。

◇2009-02-05 ・ここの内容に、意見がある人は、ここに書く必要がある。もしくは、共通の発言の発言の場がいる。

また、言ったことが文字に残せない文化は、タコである。

◇2009-02-05 ・単刀直入な表現をしないと分からない一党がいるので、困っている。

普通バックアップは、サーバー運用責任者の仕事で、ＩＴのリテラシーの有る一般事務員には関係ないような気になる。

しかし、少なくとも私（達）がしている、ＰＣからの入力業務の内容は、一時間、先祖帰りしても大変困る。

今のサーバーのバックアップのやり方は、最新の状態のみを保証する傾向にある。また、少し前のバックアップの手法にしても一日に一度のバックアップが普通である。

　また、レストア（復元）にしても、サーバー運用責任者と一般クライアントの知識レベルとはかなり差があり手続きには手間がかかる。

　また、会社のセキュリティの問題と称して、クライアント自身のＰＣにデーターの書き込みを許さない会社も多いと思う。

　経験則でいうと、個人のデーターを多く保持するようなPowerUserのＰＣが無為にクラッシュする事も少なくない。テンペストのようなことも決して無いと思うが、気持ち悪い現象が目につく。

　サーバーに保管してあるデーターの内容が、翌朝どうもおかしいという人は少なからずいると思う。

私は、正直な話、今はネットワークは、インターネット以外は、使いたく無い。

電気の技術もそうらしいが、インターネットの技術の積み上げは、開発者の個人のスキルと努力による部分が多いと思う。

　技術の振興は結構だが、世の趨勢はあまりにも、安直と感じている。

　次に、バックアップ機器やソフトを提供するベンダで、バックアップ作業のデーターを保証するところは、多分、今のところ一つも無いと思う。（憎むべきは、クラックする人間の考え方である。本来、ウイルス対策ソフトにお金をかけるべきでは無く。クラッカーをネットワークに入れてはならない。）

　※サーバー運用責任者は作業手順を、決して間違える事が有ってはならない。しかし、運用責任者の意志に反して、真面目な人ほどデーターの保証はできない。

　また、クライアントは会社で自分自身が今日した作業の内容に、責任を持つ義務がある。故に、データーの内容を保証をする方策を、みんなで考える必要がある。

　で、私はというと、西暦2000年以降のテーマの『コラボレとオプティニティ』以外として、セキュリティインフラの有るべき姿というのも、あるのかも知れない。

これらは、現代人のセキュリティ問題の共通項なのかも知れない。

◇2009-02-05 ・電子文書の版管理として、昔？からやっているの、一度、内容に切りをつけたり、特に、一度リリースしたもののオリジナルを、バックアップも取らず絶対変更してはならない。

オリジナルからそのまま変更し、保存する時にリネームに失敗し、元を壊してしまうケースは、かなり有ると思う。

　プログラマの場合、一瞬のミスが、会社全体に迷惑をかけたり自宅を失うような事態も有ると考えてほしい。（最近では、電子文書を扱う機会の多い一般事務員も同じ。夜遅くや深夜の作業時には、特に注意！）

　では　どうしたら良いのか、オリジナルの電子文書をそのまま、別のところを（必ず全部）コピーし（全体の）バックアップを取り、リネームする。｛一部のファイルは、絶対ダメ！｝

リネームは、例えばフォルダごと、又は、ファイル名に西暦年月日の数字にレビジョン番号（枝番）を付ける。（例）FileName_20090205a.ext(種別)

枝番は、朝一の'a'は、前回変更したものと同じソース。

後は、トイレに行くなど机を離れたり、時間毎休憩ごとに、全体をコピーし、'b' -> 'c' -> 'd' -> 'e' ．．．

と、アルファベットを昇順に増加させリネームすること。

　超　重要な文書の場合、別のところ（フォルダなど）にコピーした、当日分のリネームしたファイルなどの（必ず）全部を、ストリーマテープ・カートリッジなどにバックアップを行い、ＰＣやサーバーから、外に出して帰ること。

◇2009-02-04 ・テーマだけアップした『Theme:多次元データ配列のシリアル化について考える．』は、80系のアセンブラでは、普通の手法か？特に、目新しい手法でもないと思う。

ダータを格納できるメモリは、便宜上直線的に並んでいると考えた方が良い。

便宜上としたのは、インターリーブやリトル・インディアンとかがあるからで、インディアンとかで、ふざけた書き込みと言われればそれまで。

アセンブラはよく分からない。

◇2009-02-04 ・モダリティ？な、表現が多いと、客観的では無くなるのか？

やっぱり、エリートには、かなわない！

（『Theme:擬似的なマルチタスクについて．』は、コメントに本文を書きました。）

◇2009-01-31 ・世の大半がそうなのか？オープン系の某研究所の論文のすばらしさには、簡単?するばかりである。

Web上のクオリアの文にいたっては、そのひたむきさに、感動さえする。

日経サイエンスのは、そうでも無いが - 時代寵児たるウチの女史（達）の方が、まだ世間を知っている！

私はというと、ただ、フザケテいるばかり也。

◇2009-01-31 ・プログ　アーカイブの掲示の内容は、ライセンスフリーです。

無断でどんどん使ってもらっても、良いですﾖ！

◇2009-01-30 ・当たり前の話しだが、私の知っている人（達）は、自分のリリースしたものに責任を持つ。組織であれ同じだと思う。ライブラリなどや環境が、悪かった言うのは理由にならない。

とはいえ、コンピューティングの世界は日進月歩である。

自分の事はさておき、今の開発環境と、約20年前を比較する人は白痴である。

　例えば、文字検索機能の貧弱なエディタやEdlinで6,000ステップのプログラム・ソースのデバッグは、実際には不可能である。

ただ、不可能を可能にするのは、あなたの普段の前向きな努力にかかっていると思う。

◇2009-01-23 ・掲示の『VerticalScrool』が、実現できた所以は、問題がFormのプロパティにあると気づくかどうかに、かかっていた。（知っている人には、何でもないことである。）

恐らく西暦200?年以降dotNet VBが初版出てからの個人的な懸案のテーマで、実際には、その時２，３時間、今回２，３時間程度のことである。私はこういったテーマを未曾有のごとく抱えていて、正直な話、それだけで疲れる。

エジソンが偉いのは、限りある時間で精一杯努力することだが、私の場合は、なぜかそうでは無い。

むしろ、『何故ひらめくのか？』に、興味がある。

それは若い時、美しい娘が、なぜ好きになるのだろうと思うのに似ている。

だた、それだけ（思うだけ）では生きてて、私はつまらない。

というのは、色々トライして苦心すること！を、大事にしたいと思うからである。~(atom)

◇2009-01-21 ・随分昔、私がプログラムを始めた頃の先人の本を、読んでいると、『我々はプログラムをしているのであって、BASCICやC言語をしている訳ではない。』とある。また、『どの言語でも通用するプログラミング・スタイルを身につけよう。』とある。

◇2009-01-17 ・上に今日まで掲示したVisual Studioを購入してからの、私の書き込みの内容は、技術的には、ほとんど目を張ることないノウハウです。

しかし、新しいコンパイラ製品などの場合、インターネットは別にして場合によっては一日掛けて、本屋巡りをしても行き着くかどうか分からないことも少なくないです。

また、果たして自分が或いは部下が手を付けて乗り切れるかどうかは、予め分からないことばかりです。当然、仕事を与えられても出来なければ次の仕事がなくて辞めてしまうような事が現実です。

開発には、こういったことはつきものです。

若い人にお願いしいことは、自分自身で考え乗り切ろうと努力する習慣を付けて下さい。

私の場合、仲間や若い人が出来なくて責めてことは少ないと思います。

問題だと思うのは、バグがあっても知らないないふりをすること、他。

また、逃げ口上を切る仲間とは仕事は出来ません。

常に、若い人に言って来たのは『出来ないのは、（能力だから）仕方が無い。これから、何をどうしたら良いかを、考えて下さい。』です。

しかし、努力する人には、少しはお手伝いは出来ます。

｛全く考えようとしない（出来ない）不向きな人は、どうしょうがない。｝

知識を身につけることは、大事ですが、自分で問題を解決しようと、常に努力する姿勢はもっと大事だと考えます。

そういう共に頑張る人に、少しでもお役になれば幸いです。

◇2009-01-13 ・『洗練されたものは、美しい！』

美しく見やすいプログラムを作る秘訣は、行間にある。

行間を意識してコーディングすることにより、プログラムの見やすさは、飛躍的に向上する。

平たくいうと、行の区切りを空白行一行にするのか、二行挿入するのか、或いは、シングル・クォーテーションにするかなどを工夫することにより、見たイメージで文の前後の脈絡を捕らえられるようになり、考える負担を軽くし見やすくなる。

◇2009-01-12 ・実務では、プログラム・ソースの速読で、全体の大きな流れを把握したいことが多い。

そうする為には、変数は追ってはいけない。

細かい条件分岐はあまり気にしないで、ブロック単位で、ここで何をしているかを理解し、全体の流れを掴む。

◇2009-01-11 ・イベント・ドリブン　プログラミングも、最初は、気持ち悪くてしょうがなかったが、いきなりコードを書くより、とにかく沢山のこの手のプログラムを読んで、目を慣らそう。

　また、（なかなか手に入りにくのでしょうが、）プロの書いた二千ステップ以上のソースも普段から慣れて速読が出来、読む前に怖じ気づかないようにしよう。

　コツは、変数を追ってはいけない、細かい分岐も、あまり気にしないように、極力全体の流れを読むようにしよう！

｛それでも、必要に応じて、時間を掛けて細かくみる局面もあると思うが、仕様を理解して（自分の言葉で）作り直した方が早い時もある。｝

◇2009-01-11 ・（メンバ）変数を、CODEの真ん中に書くのは、良くないらしい。

例）．Dim m As String = "ABC"

デｲメンジョンを切り、変数を値で初期化するのも、メモリ管理上問題あって、よろしく無いらしい。このところは有りますが、（私は、）CODEの真ん中でも、美しければ気にならない。

｛ノイマン型言語？使いの人にとっては、気持ちが悪いか？不謹慎なのヵ？｝

◇2009-01-10 ・Visual StudioのMSDN Subscrition版がほしいんだけど、高い。

　　一般の勉強家にも廉価なアカデミック版購入の道を開けてほしい。

◇2009-01-10 ・手前みそな話をさせて頂くと、いまのところ参考文献（本）は、ありません。インターネットぐらいは参照しますが、ほとんどは、頭の中に入っております。

◇2009-01-09 ・Event Driven Programmingは、慣れるまで大変でしょう。

◇2009-01-08 ・掲示の画像が、小さい時は画像をマウスでクリックして下さい。

◇2009-01-07 ・『今日のひとこと』のTESTです。　　　

＊ ――― ・ ――― ＊

ProgLogg

Programmer's collaboration site.

自己紹介

ブログアーカイブ

MSN

フォロワー

2009年1月3日土曜日

STDEV（標準偏差）ジェネレーター．

1 件のコメント:

『今日のひとこと』

ProgLogg

Programmer's collaboration site.

自己紹介

ブログ アーカイブ

MSN

フォロワー

2009年1月3日土曜日

STDEV（標準偏差）ジェネレーター．

1 件のコメント:

『今日のひとこと』

ブログアーカイブ