来週は!

WNIという天気予報のホームページがあるのだけど、そのホームページは結構予想がよく当たる。

驚いたことに、そのホームページで来週1週間の最高気温の予想が出ていた。何と、我が地方都市も来週は最高気温が39度に達するのだって!!!

これまでも高温だったが、せいぜい35℃程度であった。我が街は周りが山で緑が多いため、他の近隣の都市が39℃に達していても、せいぜい35℃止まりだった。

それが、今度は39℃だって!大暑です。私は、これまで、39度を体験したことが無いので、来週を迎えるのが恐ろしい。

でも、仕事をしている時期には、真夏の日中に炎天下を歩いたことが何度でもあるので、多分、耐えられるとは思う。

でも、年々気温が高くなり、前年より低くなることが無いので、このまま推移していくと、何度迄上昇するのだろうか?上限温度が我々には届いて来ないので、将来が不安である。

温暖化の原因は、化石燃料の大量消費と、ヒートアイランド現象であり、何れも人間の仕業である。何とかして、人間のこれまでの悪行を改め、脱・化石燃料を促進して、地球大気のクリーンナップ化、都会のオール緑化を実現して、動物、植物の生息できる地球に再生するようにしたい。

cssは面倒

先日から、cssとhtmlとを使ったホームページの練習をしている。特に、パソコンとスマホのように画面サイズの異なるデバイスに自動的に適合するアプリの作成である。

理論は良く分かったのだが、コードを作成中にミススペルを入力することがあり、それの対策が大変である。ミススペルも全個所で統一してミススペルを入力していればまだしも、沢山ある同一用語の中で一か所だけミススペルをしていると、それの検索が大変である。

昨日経験したのだが、「menu」と書かなければいけない個所で、「manu」と書いていた。他の個所は正しく「menu」と書いているのだが、1か所だけ間違ったために、予想外の表示になってしまっていた。詳しくは、メニュー項目(例:カレー、サラダ、パン、…)を横並びに表示すべきところが、縦に並んで表示されているのである。どうして縦方向に並んで表示されるのか分からなかったので、随分苦労したが、スペルミスのため、横並び表示の指示が無効になっていたのである。

その他のミスとして、ハンバーグメニューという縦に3本の水平線が並んだアイテムを、クリックすると、✕マークに変身するプログラムが、矢張りスペルミスで機能していなかった。プログラム自体結構ボリュームがあるので、スペルミスを探すのがとっても時間と労力がかかる。最初からスペルミスと分かっていれば、検索も簡単だが、プログラムの内容を検討し、動作、機能をチェックしていくので、スペルミスまではかなりのチェックをした後でしか辿り着かない。

プログラムのミスの発見はデバッグ処理としてかなり進んでいるが、所詮個人で書いたプログラムでは、時間をかけて力任せに検索せざるを得ない。

苦労するので、こんな作業は辞めようかとも思うが、ミスを克服し、上手く動作すれば、それまでの苦労を忘れる安堵感が得られ、次の新たなプログラムにチャレンジしたくなる。

プログラムを書いている人はこういったルーティンを何時も経験しているのだと思う。

同窓会開催まで道半ば

中学校の同窓会を開催することがこの春(2月末)決まり、私も幹部の一員になり、同窓生の住所調べ、案内状の送付、宴会場の選択等を、略4カ月かけて行い、ようやく開催の目途が立った。

慣れない作業なので、ミスがあってはいけないと思い、何度も確認して作業を進めたので、4カ月の間は忙しく、他の作業をする時間も意欲もなくなった。

今は、同窓会の宴会場も、出席者の数も決まり、一段落である。

今回の同窓会は、卒業以来60年ぶりであり、その間に一度だけ40歳の頃、同窓会があったという低頻度な集まりである。

だから、全ての同窓生の15歳か16歳の時の面影は、今は無いはずであり、同窓会場では、全くの浦島太郎の物語を経験するようなものである。これは少し楽しみではあるが、いずれにしても、おじいちゃん、おばあちゃんばかり、楽しみも半減である。

同窓生の20%以上が物故になっていた。年齢がら仕方ないのであるが、中学生の時、楽しく遊んだ人が数人亡くなっていて寂しい思いがした。更に、まだ生存していると思われるが、現住所が分からず、同窓会案内状が返却されてくる方も10人弱いた。同窓会出席者は卒業生全体の30%程度であった。他方40%程度の生存者は、欠席である。多分高齢のため、出歩くのが鬱陶しかったり、体調が悪かったり、するのであろう。

今日はこの程度で。これからはもう少し高頻度でブログ書きます。ヨロシク。

 

 

 

 

flexbox

現在、CSSで、flexboxが実現できず悩んでいる。この技術は、例えば3個のブロックを表示デバイスの幅が規定値より小さい場合縦向きに並べ、規定値より大きい場合横向きに並べるというテクニックである。今回は、CSSを教科書通り記述しているのだが、上手く動作しない。というか全く動作しない。

このテクニックの見せ所は、モバイル端末のディスプレイとパソコンのディスプレイとで表示する場合に、モバイルではブロック記事が縦向きに並び、パソコンでは、ブロック記事が横並びするところである。これがディスプレイのサイズに応じて自動的に切り替わるので、ホームページ作成がモバイル用とパソコン用を別々に作成しなくてよく、大変労力並びに時間節約ができる。

でも、まだ、今のところは上手く行かないので、別の教科書を購入することにした。多分その教科書には詳細にそのテクニックが記載されているのだろう。

尚、このテクニックの発展形として、例えば4個のブロックを2行2列にマトリクス形状に配列したり、縦又は横に1列ずつ配列したりすることも可能である。これが私の目的とする配列方式である。ここでいうブロックとは、記事とか写真とかのひと塊(1コラム)に該当する。

さてさて、新しい教科書が早く来ないかな?

 

 

スタイルシート勉強中

久し振りにホームページを触る機会があり、新しいホームーページで使われているCSS(スタイルシート)の意味が良く分からなかったので、勉強している。

HTMLとCSSとを解説した書籍を購入し、例題を入力した。HTMLとCSSとの入力を終わり、デバックして実行ボタンを押し、ミスなく入力できていることを確認した。

早速、ブラウザでHTMLを表示してみた。驚いたことに、奇麗に表示している。1回の入力だけで、表示成功したことは珍しいので、大変喜んだ。

早速、講師の作成したファイルをダウンロードして、同じ例題のHTMLをブラウザに表示してみた。比較結果は、私の作成したHTMLでは、文章表示欄の背景色が白色であるのに対し、講師のものは、色付きになっている。

確かに、CSSファイルをみると、文章欄はセクションごとに異なった色で背景色を表示するようになっている。私の作成したCSSファイルを見てみると、チャンと背景色を指定している!!

つまり、私の作成したCSSファイルは背景色を指定しているのにも拘わらず、HTMLをブラウザに表示したら、色がつかないのである。

今朝から、数時間検討しているが、まだ分からない。CSSファイルは間違いが無いので、色付きで表示されなければならないのだが、何故か色がつかないのである。

もう今日は朝から、CSSファイルを眺め過ぎたので、検討中止である。明日にでも、再度検討してみよう。

それにしても、CSSを用いると、ページ表示が大変奇麗である。その点は〇である。もう少し勉強しなくっちゃ。

 

ハルカゼ

ゴールデンウイーク初日(5/3)に孫たちが熊本からやって来た。

と、ここまでは嬉しいことなんだが、その孫たちが風邪を引いていて、到着するなり、寝込んでしまう事態となった。母親はこうなることは十分わかっていたようで、私も、孫たちにとってせっかくの休みなのに、可哀そうにと思っていた。孫2人のうち一方は、風邪は左程重症ではないらしく、翌日か翌々日には、歩き回り、大阪万博へ祖母を連れて見学へ行った。

残りの孫も一日中、安静にしていたら楽になったようで、一方の孫が行った翌日、万博見学へと出かけた。

話はここで済めば、万々歳、メデタシメデタシなのであるが、実は、その日の夜になって、祖母が高熱を発症し、動けなくなった。翌日病院へ行き、インフルエンザと判明した。しかし、インフルエンザでも、39度を超える熱が出て、頓服を飲んでも38℃を少し下回る程度で、6時間もすると、すぐ39度を超えるところまで上がる。

三日ほどこの状態を繰り返し、何とか39度以上に上がるのだけは回避できるところまできた。ところが、孫2人と母親、それに祖母と4人が1部屋に寝ているものだから、インフルエンザのうつし合いが起こってしまった。もう回復した筈の孫がまた発症したのだ。同時に母親も発症し、発症していないのは、別の部屋で寝ていた私と孫の父の二人だけになった。

5月6日には熱のない孫1人と父親が帰路についた。残ったのは孫1人と母親、それに我々祖父母の計4人。このうち発症していないのは私だけで、残り全員が高熱にうなされていた。

私は極力発熱している者と接触するのを避けていたが、それでも、翌日から体調がおかしくなり、インフルエンザにかかってしまった。

以後、孫たち全員が帰って後10日ほど、体調が悪く、咳き込むことが多く、殆どベッドで寝たきりだった。

昨日(23日)から体のふらつきが少なくなり、平常生活に近づいて来た。

ゴールデンウイークの休みは、計画が沢山あったが、上記の通り、風邪、風邪、風邪であった。

教訓1:今後、熊本から一家そろってくるときは、その前に健康状態をチェックし、発熱している者がいたら、帰ってくるのを断ることにする。

九州地方のインフルエンザは、エゲツナクきつい!!!!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

アクセス数

最近、中学校の同窓生で、同窓会を開催する計画をしている。中学校卒業以来61年経過しているので、随分と皆さんは年を取っている。

ところが一端計画を口外すると、その噂が独り歩きし、同窓生の全員が既に知っているといった事態になっている。

別にそれはそれで良いのだが、私としては責任ある仕事を押し付けられて、本当にやり切れるのだろうかと、心配で、自信が無い。

それでも、まだ開催日までは半年以上あるので、切羽詰まった思いにはなっていない。時間的にも余裕がある。

そこで、あることを思いついた。それは、この際、同窓会のホームぺージを立ち上げて、そのページの中に、ID,Passwordが無ければ入れない会員サイトを設置し、そこを同窓会のアルバムを保存する場所とすることである。

同窓会の写真をどうするかは悩むところであるが、このように会員サイトを設けて、アルバム保存場所とすれば、各同窓生はそこから好みの写真をダウンロードして利用でき、便利である。しかも、自作のホームページなので、ソフト制作費、使用料等払う必要が無く、大変安上がりである。

ということで、1か月ほど前からホームページの準備に係った。何とか形は出来たが、何分加齢のため、長時間の作業が出来ず、少しずつ作業を進めていった。約1か月かそれ以上の期間を経て、ようやく形が出来た。

現在、会員サイトは、私だけが知っているID,パスワードを入力しないと入室できないので、まだ、誰も入っては来ていない。

しかし、である。ホームページの他の部分は同窓会実行委員の4名にしか知らせていないのだが、サーバーの中でアクセス解析を見ると、これまでに初めて訪れた人が91名!!であった。この人数は、1人が何回訪れても、1としかカウントしないので、実行委員以外も沢山の人がホームーページを閲覧していることになる。ただ、一人でパソコンとスマホとタブレット端末を所有する場合、それぞれの機器でアクセスすると、3とカウントされるので、素直に91名が訪れたとはならない。しかし、4名や5名ではありえない。少なくとも30人、普通は6,70人でしょう。

という訳で、既に、同窓生のホームページは公開状態である。まツ、良いか。

 

悪戦苦闘

RENTALサーバーの設置に、もう2週間ほど続いている。担当者にメールで尋ね、少しづつ前進している。多分、8,9割は完了したと思う。

何に時間がかかったかというと、ホームページのURLを、独自のものに設定しようとしたためである。独自URLを設定するためには、ドメイン設定の後、ドメインの追加処理があり、それに難航した。

何故、ドメインの追加をしないといけないかというと、独自URLを追加するドメインとするためである。分かってしまえば簡単なのであるが、サーバー側の解説が必要な処理のみ説明し、何故それが必要なのかの解説が無いからである。だから、パソコンを通じて手続きをしていても、今何をしているのかが分からず、操作中の手続きの意味を理解するのに時間がかかる。

でも、今はドメインの追加の反映待ちになったので、反映完了すれば、ホームページコンテンツをアップロードして、同窓会の写真アルバムページのリハーサルができる。

今回のレンタルサーバー会社は、メールではあるが、親切にパソコン入力のアドバイスをしてもらい、感謝している。少々レンタル料が嵩んでも、親切にリペア処理を手伝ってくれるのが嬉しい。

RENTALサーバー

同窓会の写真を同窓生に配布する方法として、ホームページに会員ページを作り、IDとパスワードを入力しないと入室できないようにするつもりである。

ただ、会員ページを作るには、サーバーにhtaccess機能がサポートされていなければならない。そういったサーバーとして、格安に手に入るものとして、レンタルサーバーがある。

先日から、レンタルサーバーとして、高機能で、格安のものを物色している。

それで、驚いたことは、最近のレンタルサーバーは大手企業が運営していることである。だから、サーバーと言っても、パソコンが1台か数台あるといったものではなく、数十台か数百台かそれ以上、それも、日本国内に分散して配置している。そのため、サーバーの登録手続きがとても難しい。ドメインの設定にしても、2個必要となり、どっちのドメインが主となるのか分からない。そのため、ホームページのURLにしようと思ったドメインがそうなっていないことがあり、それを修正しようと契約内容を変えようとすると、ホームページが上手く動作しないこととなる。

それで、現在、レンタルサーバーを変更してみているが、各レンタルサーバー毎に手続きの様式が異なっていて、現在の進行状況が何をしているのか分からなくなる。そして、今から何を手続しなければいけないのかもわからず、レンタルサーバーの契約終了に行きつかないのである。

何とか、契約書式を規格化し、各レンタルサーバー運営者毎に統一して欲しいと思う。

そうでないと、契約作業に時間がかかり、そのうち契約者が減少するのじゃないだろうか?

利益のためなら、消費者犠牲?

最近、気になっている事例を説明する。

●セルフレジ :セルフレジは、買い物をした客が、各商品の価格をバーコードリーダーに読み取らせ、決済するシステムである。それまでは、レジに店員がいて、その店員がすべての作業をやっていた。

客は、買取価格の金額を支払うだけの作業であった。ということは、セルフレジになって、それまでの店員がしていた作業を客が代行するようになったのである。でも、代行しても何ら代行料を貰っている訳でない。ただ働きしているのである。客がタダ働きしている限り、経営者は店員が不要となったことに伴う給料分、利益が増大するのである。

店員の給料分の金額を客側に還元するのなら理解できるが、一切そういったことはやっていないようである。

そもそもの話だが、客が購入した商品の合計額を計算するのは、客でなく、店側の人間である。店側と客とは、利益相反の関係にあるので、客に合計金額の計算をさせるのは店側にとって不利益を蒙る可能性があるからである。

だから、セルフレジシステムは、これまでの商品取引に反するシステムであり、店側が客の購入した商品の金額を計算する作業をやるべきである。別に店員にさせなくとも、自動読み取りロボットを設置して、店側の責任で読み取りを行い、買取価格を計算するのである。

もし、現行のような、セルフレジシステムをこれからも継続するなら、代行手数料分を客に支払うべきである。

私は、何故、消費者がこのことを主張しないのか、良く分からない。商品買取の行為に立ち戻って考えれば、分かることなのに、と思うのだが・・・。

ここでは、買い物を例に挙げて説明したが、現在の社会システムは、既存のシステムの規則、規範を無視した、客側に作業を転換している例がチョクチョクある。

Top