過去に読んだSF小説を思い出す時に、ブックカバーの絵やデザインが思い浮かびます。
私は、平井和正著「幻魔対戦」「ウルフガイシリーズ」や、ジェイムズ・P・ホーガン著「星を継ぐ者」3部作等を思い出す時に、絵を思い浮かべる事はあっても、絵の作者をあまり意識しませんでした。
ふと「絵を描いたイラストレーターはどなただったのだろう」と思い、ネットで探して見ました。
平井和正作品では、生頼範義さん
ジェイムズ・P・ホーガン作品では、加藤直之さん
が、それぞれ多かった様です。その他のイラストレーターさんの絵の時も有りますが、今回その全てを調べる事はしていません。
手元に現物の本があると良いのですが、仕舞い込んでいて、直ぐに見られないので、間違えていたら、また静かに訂正いたします。
カテゴリー: Uncategorized
ITでは「置換」が頻繁に出てきます。
ソフトエンジニアの、基礎知識であり、ITに置ける本質的な部分の一端を成すと言えば、大げさかもしれませんが。いろんなシーンで「置換」は出てきます。
特に、C言語でマクロを理解するには、多分「置換」は外せないと思うのですけど…。
と言う事で、また、検索結果を、二個ほど提示させて頂こうと思います。
その他、事務系では、ワードプロセッサや、スプレッドシートで、データの置換位は出来ないと、作業効率あげられないでしょうとか。
viやemacsで置換をするのは、プログラマーの基礎技術じゃなかったっけ？。
とか。
私自身は、とても未熟ですので、下記の文章を書くのは厚かましいと思っています。私の勘違いなど有りましたら、ぜひコメントに頂ければ幸です。
さて、先ほど、viやemacsと書きましたので、余談になりますが、UNIX系技術者なら、ご存知の、環境変数について書きます。
各自に払い出された個人アカウントで作業している場合は、いいのですけど、共通のアカウントで作業する場合、環境変数は、勝手に変更しては成らないのです。
各自、UNIX系技術者なら、環境変数に、あれこれ仕込んでおられるでしょう。仕込んでいると言う言い方は適切では有りません。作業効率アップを目指してカスタマイズをなさっていると思います。
ファイル削除コマンドのオプションで、「ディレクトリは消さない設定」で運用していたり、「ディレクトリも消す設定」で運用していたり。
共通のアカウントの環境変数の設定で、「ディレクトリは消さない設定」で運用している中で、誰かが、それを「ディレクトリも消す設定」に変更したりすると、困ったことが発生する事があります。変更の仕方によるのですけど、ログイン直後に読み込む環境変数設定関連ファイルをいじらずに、作業中の環境だけで設定値変更しているなら、他への影響は比較的少ないかもしれませんが、その作業環境で実行するコマンドやプログラムやスクリプトには影響が出るかもしれませんので、注意が必要です。
さて、この環境変数関連のファイルを書き換えると、以後その共通のアカウントでログインをしてくるメンバーの作業環境にも、変更が適応されます。怖いですねー。
なので、新人が入来た時に、新人の熟達度がどのくらいかによりますけど、UNIXの初歩のマニュアルを読みながら、環境変数をいじっていたりしたら、共通アカウントの設定をいじらないように指導することが大切です。
クーロンで動いているプログラムや、スクリプトやプログラムは、環境変数の影響を受けますので、環境変数をいじる場合は、その辺も考慮して、影響を出さないような変更を行うべきです。そうじゃないと、過去のソフト資産を作り直すとか修正することになり、修正や作り直しは検証作業を伴い、その分、労働が増えますので、とても大変です。
環境変数で設定可能な項目は多岐に渡りますので、どこで何が何に影響するかを知るのも、もしかすると結構大変かもしれません。
逆に、そう言う状況が予想されますので、ソフトエンジニアは、環境変数に配慮したソフトを組むべきなのかも知れません。
そうそう、Windowsにも環境変数は有ったと思いますが、そんなに意識しませんね。
カテゴリー: Uncategorized
隠蔽を英語に直しますと「hide」や「hiding」になるかと思います。
さて、日本語で、「隠蔽」と言う発音を聞くと、余り良い感じがしませんが、IT業界では「隠蔽：hiding」は、ちょっと違ったニュアンスで、頻繁に使います。
要するに例えば、プログラミングと言う仕事をすると、えてして、作っている物が、複雑に成りがちで、判りにくくなりがちなので、何とか分かり易く出来たら良いね。と言う事で、一連のややこしい部分を関数として切り出す等して、必要最小限のデータだけを、関数との間でやりとりすることで、実際にその関数内部で行われる複雑でややこしい事を、関数をコール（呼ぶ）側のプログラマはそんなに意識しなくてもよくすると、仕事が楽になるよね。プログラムコードも読みやすくなるよね。生産性も上がるよね、と言うアプローチの一貫として「隠蔽」と言う事や、言葉が使われるシーンが結構有ります。
メニュー等の、プルダウンメニューとかポップアップメニューとかもそういう、ニュアンスが有りますよね。
普段なるべく見えないようにしておいた方が、画面を広く使えて良いよね、とか、べったりと画面全体に総ての機能のボタンが出てくるより、カテゴリー分類され、階層化されて、その時必要とする機能じゃないメニューは隠しておいた方が使いやすいよね、とか、そういうアプローチで、「隠蔽」と言う技法が使われています。
と言う事で、ソフト関係や、通信関係等、IT関係全般について、そういう傾向が有リますので、悪い意味での「隠蔽」と言う概念で「隠蔽」と言う言葉を使っていないことも、多いのです。
ちょっと知っておいて頂ければと思いまして。
こういうのはトリビアになるのかなー？成らないのかな？。
ITの全体像を完全に理解したいとか、完全に把握するには、隠蔽されている部分についても注目して、内部の挙動をつぶさに理解し把握することに成ると、思いますけど、並大抵の精進や努力では到達が難しいと思えます。
ギアが3枚有って、どう噛み合って居てどれが、どちらに回れば、どれがどちらに回るとか、ギア比で、どのギアをどの程度の力で回せば、それぞれのギアに、どの程度の力が加わるかとか、ぶつさに理解するような作業です。
と、ここまで書いていて、思いついたのですが、
オートマチックの自動車のシフトレバーと、
実際の変速機構における、ミッションと、
それをコントロールするソフトウェア的
制御機構をイメージするとします。
運転しているドライバーは、シフトレバーの位置くらいしか意識しないと思います。
この様にドライバーに内部の状態を隠蔽しているからこそ、内部メカニズムのタイミング制御などにドライバーは気を取られることもない。
そう言う、例え話が出来そうに思えます。
カテゴリー: Uncategorized
中学生か、高校生までに、様々な業種に就職した先輩の話を聴けたら、また違った人生だったかも、とか思わせてくれる動画に出会いました。
検索キーワードは、「Day in the Life」とか
「Day in the Life:Software engineer 」とかです。
キーワードをDay in the Life:なになに(英語スペルで)とかすると、他のカテゴリーも検索できるかも知れません。
例えばhairdresserなどを入れて、「Day in the Life:Hairdresser」等として。
’https://youtu.be/vt79JcPfZQA?si=PM139CZCEdu-bMrC
カテゴリー: Uncategorized
1月からインフルエンザに罹患し、インフルエンザ回復後に蓄膿症を患い、暖かくなるまでは、ちょっと乗れないのですけど。
昨年末から、プライベートな、ちょっとした、プロジェクトを実行中です。
琵琶湖大橋の通行料金のカテゴリでは、125cc以下のバイクの場合、「軽車両等（原動機付き自転車：１２５ｃｃ以下のもの）」の区分に入り、2017/02/28現在で、料金は「10円」と成っています。
10円を支払う作業が、バイクだと大変なんです。
そこでバイク運転者の視点から料金支払時の動作を記します。
（スクーターじゃない、オーソドックスなバイクの場合です）
１．料金所が近づくと、どの料金所のレーンに入るかを決める。
２．前後左右の車両の動きに注意を払いつつ、料金所のレーンに入る。
※左手でクラッチ、左足でシフトダウンしつつ、
※右手右足でブレーキングを行いレーンで停止する。
※この時シフトはニュートラル以外だと、左手はクラッチを握っていなくてはならなくなる。
３．グローブ（手袋）を脱ぐ。
４．財布を出す。
５．10円を拾い上げ、財布を片付ける。
６．10円を料金所の職員さんに手渡し、領収書を受け取る。
７．領収書を片付ける。
８．グローブ（手袋をする）
９．出発する。
１０．前後左右の車両に注意を払いつつ合流する。
自動車だったら楽なのに、バイクの場合グローブと財布が原因で手間取ります。
そこで、始めたプロジェクトは、「グローブ脱がずに何とかしよう」です。
１００円ショップで売っている、ケーブルを壁に止めるグッズで、10円を握らせてます。
バイクのハンドルとかメータ付近に、先ほどのグッズを貼り付けて、10円を握らせておいて、料金所では、グローブを脱がずに支払いをして、スマートに料金所を通過したいと思っています。
「10円に笑う物は10円に泣く」とか、そういう言葉も有りますけれど、10円ですから、もし落としても、そんなに痛くない。
やってみて気づいたこと、バイクはエンジン振動とか、路面振動で、結構振動していて、挟んだ10円がずれてくるとか、振動でハンドルのメッキ部分を叩いて居るとか、メータに貼り付けると、プラスチックを振動で叩いて居るとか。
内心「ひょぇーー」と言う傷が…。
１００円とかだと、ちょっと考え物かなーと、思います。
小銭に気をとられて、バランスを崩すとか、コケるとか怪我するとかは絶対に避けなければいけません。
コンビニ等で停車する度に、どこにくっつけるか試行錯誤しています。
カテゴリー: Uncategorized
海外では、いろいろ法律も文化も気候も需要も異なるようで、自動車等、日本には無いカテゴリが有る様です。
日本にも原付の四輪車や、ミニカーが走っているのを、稀に見かけますが、「普自動車通運転免許」が必要だと思います。老人用の電動カーや老人用電動カートは歩行者扱いで車両では無いので、歩行者と同じ扱いで、免許不要で、歩道を走れる（このへんは各自調べてください、間違えると、えらい事に成りそうですし）らしい。
さて
欧州（ヨーロッパ）での、「EURO 原付四輪」と言うカテゴリですが、
今日ネットを見ていまして、初めて知りました。
日本の軽自動車より小さいカテゴリらしいです。
https://matome.naver.jp/odai/2141507537408737901
運転技能や、保険とかのこともあると思いますけど、日本の道は狭いので、「おさきにどうぞ」がちょっと難しかったりしますし、既に、日本では、軽自動車と言うカテゴリで、可愛いのや、広いのや各種バリエーションが有りますので、どうなるのでしょう。
ただ…。
125ccバイクから見た道路事情は、125ccバイクが入れない道路が存在しますので、海外の方には、判らないのじゃないかと思えたりします。高速道路は走れませんし、一部を除いてバイパス道路も入れない様です。その他所々二輪通行禁止区間と言うのも存在します。通信ナビゲーションでさえ、地図の最新化が追いつくのが大変な様で、頻繁に工事などで、道路の位置が変更されていたり、県道・国道・町道等での降格・昇格があり、峠や岬がトンネルになっていたりて、ナビが現在位置を把握するのに苦労している様に思えます。自動車と違ってバイクは隙間を通って廃止され旧道になった道路でも、走れたりしますので、迷い込んだら苦労するんじゃないかと思えます。さらに、スマフォナビに頼って、山間部や海岸部等の電波到達困難地域に入り込んでしまいますと、ナビが当てにならなくなりますし。どうなるんでしょう。
カテゴリー: Uncategorized
PASCALは再帰的呼び出しが出来る言語仕様を持っています。
むかしNECのPC-8001を持っていた頃に、Z-80と言う8ビットCPUを搭載したこのPC-8001で、PASCAL言語の入門レベルの練習をしたことが有ります。今のCPUから考えれば、当時に、このクラスのCPUで、しかも搭載メモリーはRAMが32Kバイトなのに、PASCALが動いていたってすごいなーと思います。
※正確にはPC-8001には、Z-80互換のNECのCPU[μPD780C-1 4MHz]が搭載されていたそうです。
PASCALを勉強し始めたとき、TK-80でのマシン語＋ニーモニックとPC-8001のBASICしか経験が無い私は、PASCALのグローバル変数とローカル変数で、ちょっとこんがらがって、しまいました。さらに再帰呼び出しをやると、変数がどうなるの？上書きしないの？とか、そういう疑問を持ちました。ステップ毎に、各変数の中身を表示させてどう変化するかを見たりして、徐々に納得したような記憶が有ります。
当時私は、「PASCALを作られた方々って、すごいなー」と感動しました。
ハノイの塔パズルを解くプログラムを作る時に、 そのアルゴリズムをPASCLで再帰的呼び出しを使って記述する様子を、判りやすく解説して居る動画が無いか検索して見まさした。
が、あまりピント来ない動画が多い様です。
普通に検索してみても、ピタッとくるサイトが見つかりにくい感じがします。
すっきりしなくてすみません。
さて、プログラムに興味の無い方は、「再帰呼び出し」に興味が持てないでしょうし。現在現役のプログラマさんは、常識的にご存知でしょうし、わざわざ書く話題でもなさそうに、思いつつ…。
あるアルゴリズムをPASCALの再帰呼び出しを使って記述すると言う事自体がパズル的ですから、ハノイの塔と言うパズルの解を求める目的でプログラムを記述する、このプログラミング作業自体がパズル的でもあり、それが、おもしろいと思うのです。
やわらか頭とか、水平思考とか、その手が有ったか、とか、問題解決へのアプローチの数々、過去の大勢のプログラマの試行錯誤の結果が、世の中に溢れるプログラムされたコードには沢山埋まっていて、他人のコードを読むと言うのは、とても自分では思いつかないような、様々なアプローチを見るチャンスです。
つまり、推理小説やSF小説や、エッセイや、書物を読むのと同じで、他人の経験を共有するチャンスです。
チャンスですが、でもすっごく時間がかかってしまったりします。
また、問題は、自分の慣れていないプログラム言語を読みこなせないとか、自分のなれていないプログラムスタイルを読むと疲れるとか、または大勢で製造されたソフトウェアはそのチームの文化を理解していないと、読みこなすのが大変だとか。ソースコードやその類の物を読もうとすると、若干そういう問題が有ります。
コンパイルされた後の、マシン語なり、中間言語なり抽象表現になってしまったコードを読むのはその特性から、大規模なパズルをとくようなもので、とても大変であり、大規模な解析システムを使いこなさないと出来ないと思えます。
大規模な解析システムを使いこなせるなら、ソフトウェアの大企業で、デバッグのお仕事をバリバリこなせるはずなので、大企業のエリートとして、高給取りになるのも夢ではないと思いますけど、大変だろうなーと思います。
と言う事で、PASCALの再帰呼び出しで、パズル「ハノイの塔」を解くプログラムをプログラミングするとか、その内部の挙動を頭で正確に把握すると言うのは、将来に向けての第一歩になると思います。
どこかで、どなたが書いておられたのですが、プログラマーの中には、プログラムを、やり始めると、ついつい没頭して行って、仕組みを頭の中に作り上げていく日々の中、どんどん、生身の人とのコミュニケーション能力が落ちていくのが、自分自身で良く判る。と言うタイプの方が居られる様です。
いろいろな人の話を読みますと、「完全に仕事のことを忘れて、家族と過ごしたり、散歩していると、ふと、突然、解決策が、天から降りてくる。」と言う方も居られる様です。
いろいろな方が居られる様ですが、プログラマの方は、真っ当な社会生活を送れなく成っちゃうといけませんから、注意が必要かも知れません。
1万時間の法則とか、良く聞きます。1日7時間で1万時間はどのくらいになるか計算すると、ほぼほぼ4年くらいになり、一日8時間で計算すると3年半とか、そういう数字になるでしょうか。
石の上にも三年とか。
桃栗三年柿八年とか、継続こそ力なり、なのかも知れません。
カテゴリー: Uncategorized