2011年11月29日火曜日

〔文明批判のテーマアップ〕

拝啓 ジェシー殿 お体の具合はいかがでしょうか?


 近況は...


 もうすぐ、国はおろか育った風土が壊れようとしています。

 だから、いずれ釈迦が再び現れ将来の極楽浄土が、  ...『それから、世界やシステム全体が、どうか(過去はこうで、また現況はこうゆう状態。)。』...  となど上等なことばかりいっておれません  そして今、今後や将来がそれ、と 未来を見通さないともう後がありません。

 つまり、いま自分は、  ~平成19年(西暦2007年)初夏頃・朝日デイリー【発行】などで先輩諸氏がいっていた~  生き残りへの戦いのまっただ中にいると自覚しています。

 最早、私にはまとまった考えも方策もありません。また、この年でこれから世界史を勉強している時間も余裕もありません。

 にも関わらず、新しい地平を夢に秘め、日々・希望を口ずさみ、これから明日・明後日も少し微笑みながら近隣の人と手を取り合って生きつもりです。







 とにかく今日コレから、〔文明批判のテーマアップ〕は、私には必須だと考えています。





...昨今の諸々の業 お世話様です。

                  - 以上 -

#NOVEMBER 29, 2011 1:33AM

- J-L.I.A. ~atom

***









2011年8月6日土曜日

魚雷運動方程式

http://ja.wikipedia.org/wiki/%E4%B9%9D%E4%B8%80%E5%BC%8F%E9%AD%9A%E9%9B%B7#cite_ref-14
---
誰か<リンク中の数式を見てください。
どんな感じか教えてほしい。--- *!

2011年6月3日金曜日

プログラミングに於ける待ち合わせ逐次実行の処理について(ブラウザ編)

【前回タイトル】プログラミングに於ける待ち合わせ逐次実行の処理について(テーマアップ)
【前回リンク】 http://proglogg.blogspot.com/2011/06/blog-post.html

例えばブラウザの場合、あまり時間もないので全く外から見た感触になるが、元のスレッドにも書いたとうり、今後同じ理由で二つ以上のブラウザの同時使用はやめた方がよい。理由は、他のブラウザからの影響分からない(調べるのが困難など)からで、IEとi????の同時使用で、動作が止まることはある。また、同じブラウザ内でも、窓違いのJAVAアプレットなどのその他不明スクリプトも他への影響は、分からないと使えない。想像だが、挙動から見てIEが一番信用は出来る。(他の名の知れない一つ以上のブラウザが共有権を犯すと、応答しないことがあった。動作などロックのジレンマに至ってはいないか? 偶然、他がDLLやリソースなどを解放すると制御がプログラムに戻ることもあり得る。{当て推量でWindowsタスクマネージャなどCPUやメモリの飽和を見るのは、迷信の部類になると、断言しておく!}
応答しない場合の多くは、DLL内で止まっていることが考えられ、応答が戻るまでプログラマは制御できないし対応など出来ない。といった理由で、共有権を犯すとブラウザの排除はアカウント業務では、これからの課題となる。かみ砕いていうと、これらを考慮していないプログラムがあると、Windowsにも関わらず規則を守り・行儀の良いプログラムの方が、全て応答しなくなる可能性はある。)
 最近、期末前から白い背景の画面のWebページも見るが今後も負荷はほとんど軽くはならないと見る。リソース以外でもDLLの同時共有は可能だがモノによって排他的使用しか出来ないものあるハズである。
つまり、他のブラウザや枠の外でのアプレットがこれらの扱いを丁寧にしているかに、より依存すると考えている。
メモリ解放の処理や手続きの正しいリターンの遵守よるリークの問題より、今後これらの排他的リソース使用の件が、今後の社会のネックとなるには必須と見る。(過去の反省が出来ていないし、無秩序な(ブラウザ)並列処理や深い(窓)ネストは、極力避けたいとの私の願い。)
次回は、プログラムの平行動作と待ち合わせ、更に行列キューと割り込み処理についての概論に触れられたらと思う。
最後に、待ち合わせを考慮しないプラグラマ・SEのシステムは使えない。ネットワークを外したハズした、単一OSの方が(待ち合わせが無ければ)安心になる。
***
《コメント》
※過去の並列処理など複雑化への反省と、より線形でシンプルかつ可読性が良く堅牢で安全な手続きへの明日を目指す!
-Bye

プログラミングに於ける待ち合わせ逐次実行の処理について(テーマアップ)

 簡単にいうと、製造工程に於いて、部材を発注してから仕入れまでの標準的な従来の期間と異なって来つつあり、最近のことを考えると、製品の仕上がりの目安の予測が困難になっている。(仕入れ先が、電話に出ないとか...)
 もう少し掘り下げると、例えばマイクロソフト・マウスを使うと延滞を起こす場合があるが、待ち合わせ無視するサードパーティのマウスは止まらず良品と判定をするのは、どうかということ。
 つまり、マイクロソフト・マウスは処理の待ち合わせをする純正品で、他からの影響により処理は異なる。処理時間の標準は予測出来ても、排他処理の場合、表面上、挙動を停止するかのように振る舞う。とにかく、安直に他からの影響を考慮しないのは問題がある。

今の社会、本当はこれらの論議がいる。(あなたブラウザは、これから大丈夫か? 私は 例ヤツは、いわゆる梗塞じゃないと考えている!)
****************************** *
-atom(); June 3(FRI), 2011(H.23)

2011年5月7日土曜日

AccessLog



管理者宛メール・アドレス変更のお知らせ

拝啓 題記の件、以下の通りご連絡申し上げます。
mailto:kids.atom@gmail.com
宜しくお願いします。
-敬具

《追記》
以前の管理者宛メール「info@cst-neco.jp」は、ドメイン転送時の不手際でウイルスメール指定となり未達でした。当方の不手際で大変ご迷惑を掛け、申し訳御座いませんでした。
以降は、お手数ですがお手元のアドレス帳など、当メール・本文中のメール・アドレスへの変更をお願い申し上げます。
今後ともに当Webのご愛読・ご愛顧の程、よろしくお願い申し上げます。
-以上

『アノニマス』(May 7(SAT), 2011)

『アノニマス』(May 7(SAT), 2011)

 本日の新聞で、『アノニマス』という表現が見られるが、私はその集団が何かは分からない。
私が知っている『anonymous』とは、Windowsサーバーのアカウントに与えられるアクセス権限の一つで『匿名』という権限を指す。例えば、『CEO_Smith』氏に役員のアクセス権限を与え、役員権限の方にのみアクセス可能な共有フォルダを作れば、一般社員、課長、部長権限のアカウントの他者はアクセス出来ない。また、個人名に課長、部長など役職に応じた権限を与え(一つのアカウントにカテゴリの違う他の権限を複数の与えることが可能)各人の職位に応じた共有フォルダの読み書きが、コントロール出来る。
そして、私の知っている権限『anonymous』とは、Window Server上で匿名として名前を名乗らずアクセス出来る権限のことだったと思う。普通は、社外の見学者などに対して付与し閲覧されても問題にない社外公開用共有フォルダにのみ許可したり。また、重要顧客などのお名前に問題のない閲覧だけの条件で一日のリース期間で許可したりする。

《追記》
『アノニマス』という集団は、はじめて聞いたが、現実には『anonymous』権限を使うかどうかは経営陣の意志決定というより、サーバー・アドミンの臨機応変な状況判断ひとつになる。つまり、権限は付与する側で、アクセス拒否など用途に応じた対策はいる。
ところで本日の新聞の記事など、各々ハッカー集団については正しい解説がほしいところになるが、実際には脈絡がないと見れる。
最後にOSは何か!?
《以上》

2011年5月5日木曜日

陽子等について

件名:陽子等について

リンク:http://slashdot.jp/science/article.pl?sid=10/04/01/1044256

リンク:https://mercury.j-parc.jp/usjparc/ui/

【コメント】
(5行削除;筆者)
MAY 5(THU), 2011 22:10(JST)

2011年4月26日火曜日

リンク:原発は安全だと聞かされてきて ... - MSN産経ニュース

リンク:『「原発は安全だと聞かされてきて ...」危険隠蔽にゴルバチョフ氏憤り 旧ソ連機密文書 』 - MSN産経ニュース
URL:http://sankei.jp.msn.com/world/news/110425/erp11042521240006-n1.htm
#2011.04.26 8:00am(JST)

2011年2月14日月曜日

IEにoffice2010のリボンをつけてほしい!

左の図はOFFICE2010(EXCEL)の画面。
図の赤枠内のようにリボン部のアイコンが伸展/圧縮すると便利!
※IEにも、是非この機能をつ付けて、ほしい!
/~atom() - February 14, 2011

2010年12月21日火曜日

フィールド連鎖の有効性(マスタ・コードの一元性)について

MS-Accessなどで、フィールド連鎖の有効性を主張するのは、妥当なことだと思う。
また、マスタ・コードの一元性を主張するのもユニークという意味では良く分かる。
例えば、社内である商品の単価は一つであるべきである。

しかし、わたしの経験では資材の納入単価と経理上の仕入単価が違ったりして、資材には秘密というのが結構あるが、論外になる。
話を戻して、例えば依存関係から外れている商品マスタを、課長が休日出勤してメンテして別のコピーが持っているとか。
また、オペレータとバックアップ担当の引き継ぎなどを考えると、仕様レベルのプログラムやSEが問題を内包し、オペレータに変更の詳細部を告知ししないほうがトラブルが少ない。
そして、SEデザイナは、常に仕様や仕様変更を書き留めるべきである。

マスタのコードは、トランザクション・入力オペレータよりは商品単価の管理は少ない人数でした方が良い。
同じ商品でコードが変われば、ファイルの依存(参照)関係(リレーション)を理解するプログラマがトランザクションのコード付け替えプログラムを走らせると、トラブルが少ない。多分、休日や夜間の仕事になる。

別の人間が依存関係から外れるマスタのセットやバックアップを持っていても対応は可能だし安心になる。
旧コードのトランザクションのデータ・ファイルがストッカーから出て来なくなるのを見計らって、旧コードを削除する。
===

2010年12月20日月曜日

リレーションシップのオプションについて

①参照整合性
②フィールドの連鎖更新
③フィールドの連鎖削除
---
①は、理解できるが、②,③は、このオプションの取り扱ったことが無いので違和感がある。
(何らかの理由で、リレーションシップが切れてるマスタのあった場合、問題ないのか?例えば、過去のバックアップを戻した時、コードに依存する参照関係には注意がいるのではないか?私は、あまり使いたくない。

便利な機能だが、普通はコードは変更したり、削除してはイケナイ。以前のコードはそのまま置いておいた方が良い。また削除する理由にも依るが、削除ではなく、マスタに新しいコードを採番し、トランザクションの方のコード付け替えのメンテ・プログラムを書いた方が、安全策! 管理者は、安易に使わない。要するに、このオプション使い方次第だと思う。良く分からない。)
===

2010年12月19日日曜日

データーベースの正規化

 タイトルのデーターベースの正規化については、Appendixに上げた本に書いてある。Microsoft Access2007用の教本ではあるが、プログラマの素養としてデーターベースのデザインには必須の内容で、特化したアプリケーションの構築に役立つ。この本は、資格取得用の教本で題記のテーマの一般的な事項として簡単で大変分かりやすく書いてある。 
 データーベースの第三の正規化までの記述と、MS-Accessをお持ちの方は、教本の前後の問題の演習をすると、アプリ構築の理解がより一層理解が深まると思う。
//Computer Science Technology JAPAN->atom() 2010/12/19 23:54

《Appendix》
『よくわかるマスター Microsoft office Specialist Access2007 完全マスターⅠ(公認テキスト)・FOM出版』(ISBN978-4-89311-868-4 C3055 \2200E)

2010年12月16日木曜日

データー・ベースレコードの更新処理

TITLE:データー・ベースレコードの更新処理


 先ず更新の為に一つ注意をしておきたいのは、題記のデーター・ベースレコードの更新処理で、更新は{リード}→{アップデート}と覚えてください。
 よく陥る罠は、同じキーのレコードを更新する場合、同じレコードを{削除}→{追加}となる。これは間違い。必ず{リード}→{アップデート}にして下さい。
初心者にこれが多いのは、キーでリードしてキー・アンマッチでエラーとなるのが怖い。
 この場合、リード・アンマッチ(エラー)の時は、レコードは追加になる。また、リード・エラーで無ければ、言い換えると同じキーのレコードがあれば、{アップデート}(更新)になる。


《追記》
・ 特に、主キーでリードをかけた時、キーがレコードになくエラーすなわちオペミスとするはまずい。(オペレターのせいではないので、安心してください。SEのデザインが悪い。)
・ また、プログラマは、主キーがレコードに無いときのエラー処理は必ず丁寧に処理をしてください。
・ 後者(レコードの{削除}→{追加})のデメリットや、サンプル・ソースなどは機会があれば...(言語は要望に応じます。)//


2010年7月20日火曜日

My Program Source


 左の図は、Windowsの画面からマウス操作イベントを受け取り処理をするVisual Basic.NETのプログラムです。

 前掲と比較の対象には、なりませんが、Program Sourceの違いは、直感的に、おわかりになるでしょうか?参考まで..
~atom() - 2010/07/20 6:59

2010年7月19日月曜日

半自動化した不可読性の怪獣の正体!?

今日は、海の日也!

これが、現在世界中でもっとも多く使われているというプログラム・ソースコードの正体になる。怪獣になる。

システムというのは、統制を取らないと、この様に無惨な仕事の結果となる。(面白い・金になるでは、収集が着かない。整然としているのは、表向きだけになる。)
現代っ子プログラマは、ほんとうに気の毒になる。
ただ、プログラマとて知っていて黙っている男は、決して戦争の悲惨さを語ろうとしない、慈善家にも等しい。忙しく、手に負えないではなく、問題認識としてのエントリだけでもほしい。それが、民主主義の基本だと、信じている。(ほんとは、気になってはいるとか? )・お願いだから!

それは、実際に、社会のポリシーは、常に不用意な残業代の支払いを拒否する。また、あなたの奥さんや子供が、現実に扱っているソースが如何に難解かに興味はなく、予定通りの将来設計を望んでいる。(それは、ウチの娘に聞いてほしい。)
暗黙の反響...場合によって、システムとは何かという再度・論議が必要か?という議論の方も気になる。~atom()。。。

2010年7月16日金曜日

2010-07-16

◆7月16日 縫い目のない服とは、甲冑(かちゅう)のことでないかと思う。

自分も、スーツは何着も持っているが全部若向きで、特に最近は変ないわれ方をするので困ってる。
さすがにY体の二着は入らないが、子供が出来てからのモノは、ほとんど置いてありほぼ袖は通る。もう、限界かな!
これから、どうするのかほんとに馬子マゴするばかり...('_') .(さあ、私は、だれでしょう?) - 2010/07/16 6:30(JST)

《追伸》
※自分が育てた子供には折りをみて、『人と会う時は、スーツになる。』といってある。最近は、どうしているのか!? (本件ですが、仕様が複雑過ぎるとジレンマとなりシステムが破綻することは良くある。もう、手遅れとみている。先に、忠告しておいたら良かった!? クラウドなど、本当に不安になる。)//

2010年7月12日月曜日

英語が堪能になりたい。

TITLE:英語が堪能になりたい。

 特に、技術論もさることながら英語に堪能で世界各国の識者が出席する学術会議など、論を述べる発表者に対し出席者への理解を促し会議自体の円滑な進行を進めることが出来る人は、専門分野での会議のみならず、各界で引っ張りだこに、なるのでしょう!
羨ましい限りです。
~atom() - 2010/07/12 23:09(JST)

2010年6月16日水曜日

親愛なる、作家先生に老婆心ながら...

TITLE:親愛なる、作家先生に老婆心ながら...

私には、時間がない。個人趣向で文を書きつづけているので、ライターの仕事はないと思う。
最近では、誤字が多くトーンが不真面目だとの噂が多いので、特に、気にしている。
しかし、オリジナルの問題と捉えると、他のものとは違うとは思っている。

ところで、ITに疎いライター先生に内在する問題として、辞書でも他の文書からコピー&貼り付けをすると、仕事は少なくなる。というより、ない。
年配の作家先生はどうなのか? また、私も例えとしてどうなのか? 老婆心ながら、業界のタブーに反し....。無論、私の使っている辞書からコピー&貼り付けでワープロに持っていくと、画面上に見えないコピーライトの版権情報が、含まれることがある。
お金を払って、個人で買った辞書などでも同様になる。
幾ら、立派な文体や流儀作法でも仕事は来ず、出版者からは変ないわれ方ばかりに、なるので注意がいる。
例えば、『先生は、もう、お年ですから..』。

また、助手、特に効率優先の単発のプロ女性には、注意が必要になる。ITの事情に詳しい出版者の方は、すぐ、その品質に気が付かれると想像している。

こころ当たりがあるお方は、先ず、プロなんですから、自らの手で入力して下さい。
私の論だと、手書きからワープロに切り替えると、倍・努力すれば、四倍の思考の広がりが、いずれ必ず出来てくる。
私が、特に頭が云々でも何でもなく、IT戦略に秀でているだけだと思っております。

それと、話は変わるが、プログラムでも、ソースの文体を見ただけで、人柄まで見えてくる。
~atom() - 2010/06/16 21:17(JST)

2010年6月1日火曜日

最近、なぜか、話にくい!

TITLE:最近、なぜか話にくい。

彼はバリバリと、言われたようで、実は彼らがバリバリなわけです。
それはともかく、何故話にくいかより、なぜ、彼らと話易かったかを、ここに回想したい。



 技術論で、彼らとの話の中では、相手の仕事の流儀や議論の進め方や話方を、指摘する人はいなかった。
 それを話題にすると、話の焦点がぼけるわけで、只でさえ、議論中のテーマを詰め時、さわりでは筋とは違う脇道にそれているようでも、本題を詰めるのが筋ですから、相手の話方の癖を指摘すると、思考が大きく妨げられるからに他ならない。少なくとも、人間というか私の頭のキャパなど、知れているわけですから、本題を詰めるのが限界ギリギリという自覚がお互いにあるからだと思う。
 一時期の技術ディスカッションの中で、話方を指摘されたようなことは、例外として二、三あるが、それは、関西にて、名古屋以東では皆無になる。偶然かも知れない。
 話の途中に、頭の活性化を進めるための、余裕のブレークを入れられる人は、相手への思いやりで、一緒に仕事が出来る人になる。朝一でも、会議前の余談も必須で、相手がどんな人かの探りと礼儀や思考の活性化を進める議論へのイントロとなる。
 会議中は、まとまった話をし、それを、じっくり聞くのか、或いは、細かい項目毎に一問一答するのかは、流儀が分かれるところではありますが、進行は幹事に任せるべきだと思う。
 どちらにしても、思考を妨げない話し方さえも意識しない柔軟な対応が出来る人と、お付き合いはしたいモノ。私は、技術者一人に営業一人、ワンペアみたいな会社だっが、企業では、生産管理の技術者の中には、その畑で知る人ぞ知るような方は、海外を含めてグループ企業内で、技術打合せの専門家のようで、別のセクションの廊下で、見かけることや話題に上ることはある。

ともかく、論議中の相手への遮りや話の骨子を曲げられても気にさえしない、時間内の話がまとまりせえすれば、机を叩いての激論も、個人的にはいっこうに構わない。本当に、忌まわしいのは、自分の意見も全くないのに相手に、横やりを入れる愚劣な行為になる。
 その中で、二十年ほど経って、その道ではいわずと知られた方から、..「彼はバリバリ」との風評は、光栄の極みになる。
 ただ、誰がいったのか、「ブリキの勲章」、「枯れ草」と言われる表現も、話題になるだけ、まだマシかな! と、過去を回想し 今の世相をツブヤク。(いま、その比喩は、かなり当たってる!?)
~atom() - 2010/06/01 23:55(JST)