2015.11.16

英字配列キーボード(ローマ字漢字変換)で思ったこと。

MacBook Airを購入するのにAppleStoreを徘徊しているとちょっと気になった写真がありました。

MacBook Airはバックライトキーボードが採用されていますが、AppleStoreのサンプルで掲載されているものはASCII配列のもの。

 

「あれ? MACって日本語キーボード持っていたよね?」と素直な疑問。

おとよと妻はパソコン通信時代からパソコンを使用していたので、所謂かな入力派。

ローマ字入力も出来ますが、入力速度と打ち間違いのなさで考えるとかな入力のほうが楽チンです。

ググってみるとJISかな配列キーボードもちゃんと準備されているのが判り安心して発注できたのですが、その過程でMACキーボードのかなキーに対する酷評している意見もちらほら…

まぁ選択の自由なのでご自由に…なのですが、かなり誤った認識が広まっているようにも思います。

 

多くの場合、キートップに書かれている「かな」印字が邪魔、ASCII文字のみが美しい…という意見で、ここでの前提は日本語入力はローマ字入力なのだと思いますが、おとよ的には「そもそもローマ字入力でなぜ満足しているのだ??」と思ってしまいます。

デザイン的な美しさを語りたい気持ちもわかりますが、コンピューターは所詮道具。

道具としての性能・機能を犠牲にしてデザイン重視は本末転倒。

そこまで日常で日本語を大量に打たないというのもあるかもしれないですが、

26文字覚えるだけだから簡単

 → いやいやキーボードは結局85~100ボタン分覚えないと意味ないんだから、理由になってない。

ブラインドタッチで高速入力できるからASCIIのほうが速い
 → この話はブラインドタッチ同士で比較していないので無意味、かな入力のブラインドタッチはハンパない速さ。

かな入力/ローマ字の入力の話題は多くの場合こういう話に終始していて意味ないと思います。

どう比較しても、ローマ字入力は打撃数が多い、「Computerとコンピューター」…を打つために『ComputerTOKONNPYU-TA-』とローマ字ひらがな変換を思考ロジックに一段入れるのはやはり思考の妨げになる可能性があります。

 

日本のコンピューターの歴史で、ローマ字入力が登場したのがかなり後。

THE 国産パソコンのNECパソコン(PC6601/PC8001/PC8801/PC9801)の登場初期は日本語といえば半角かなが基本で、かな配列で入力するしか方法がありませんでした。 その後登場した初期の漢字変換のNEC単漢字変換もかな入力が基本。(なんと初期のワークステーション、DEC社のPDP/11やDEC/11も日本語環境ではかな入力です)

 

ローマ字入力をサポートしたのは一太郎にバンドルされたATOKが最初だったと記憶しています。

キーボードアレルギーという言葉が出来るほどパソコンに馴染めないおじ様たちが生まれた時代です。

この時に「26文字覚えれば大丈夫…」という触れ込みで採用されましたのがローマ字入力。

覚えるキーが少なくてよいということで一様に広まりましたが、いつの間にかローマ字入力こそが真…のような流れになってしまい今だこの慣習を引きずっているのも事実。

 

これは学校のパソコン授業にも波及していて、日本語入力をローマ字入力で教えている・・・これって絶対おかしい。

そもそも、先生がかな入力を覚えなかったのがすべてだと思いますが、学校の先生はパソコンの専門家ではなく指導要綱を片手間で覚えたもの…またその教員課程を教えている先生もローマ字入力の世代。

 

それを子どもに押し付けていいの?

 

学校の授業では百人一首などを覚えます。

なのに26個の少ないキーを覚えるだけで云々というのはまったくおかしい。

子どもの記憶力と環境適応能力を考えれば、かな入力を覚えさせるべきだと思う。

まぁおとよのこういう意見も、かな打ち派の押し付けに過ぎないのかもしれないですが…

 

限られた時間で一気に数千文字の書類を作ってみると…かな入力を覚えていて良かったとひしひしと感じます。

特に技術書類のような英語と日本語の混在文章はなおさらです。

日本語文章入力で入力効率改善をお考えの方…一度かな入力を試されてはいかがでしょう。

半年くらいで大体入力できるようになるので、それほど難しいものではないですよ??

 

 

2015.11.15

VAIOが死んで、MAC買った。

妻が普段使用しているパソコンはVAIOノート。

 

結構前に自分で初めて買ったパソコンは98君・・・PC9821…CanBe。

自分でモデムカード増設したり、メモリ増設したり、FDDドライブ増設したり…

かなりの廃人っぷりを発揮していたのですが、VAIOが発売されてからはVAIO一筋です。

理由は「カッコいいから」…ここは女性らしいですね。

そのVAIOノートは、VGN-NW91GS…7-8年前に購入したCore2Duoのものです。

Windows7proが搭載された初期のものではないかと思います。

 

日々の家計簿、予定表、Webサーフィンその他もろもろ、一日中電源が入った状態でかなり酷使されてきたと思います。 この間、放熱FANが誇りで目詰まりしたり、キーボードに異物が混入したり…経年で発生するトラブルは何度かありました。 これらは都度私が分解してオーバーホールすることでまぁなんとかメーカー修理という自体は避けてきたのですが、思わぬ形で買い替えのときが来ました。

 

液体…そうミルクティーをこぼしてしまったのです。

 

甘味料が入った液体はパソコンには致命傷になりかねず…VAIOもその影響がありました。

分解してキーボードを洗浄してみましたが、張り合わせのフィルム基板内部に甘味料が浸透してしまい、無限キー入力状態から回復しません。 メーカー修理するにも既に部品保有期間が過ぎていますので、仕方なくキーボードはハーネスを外して使用不能にし、近所のヤマダ電機で700円で購入してきたUSBキーボードで急場は凌ぐこととして、新たなパソコンを購入することにしました。

 

妻の第一希望は…やはりVAIO。

でもVAIOは会社ごと身売りしてしまったので以前のVAIOではないんですよね。

OSもWindows10インストールモデルになるので、おとよ的にはちょっと消極的。

 

OS変わることや、普段使用している家計簿系ソフトはOpenOfficeであること、妻のスマホはiPhone6s、ディスクサーバーはLinuxで構成しているのでSambaでもNFSでも接続できる…これらを考えれば、Windowsに拘る必要もないので、この際MACに移行することにしました。

もともとおとよは会社標準パソコンがWindowsになって業務パソコンが配布されるまではMac Quadra950を使用していたので、MACのほうが馴染み深いです。OSがバージョンアップしても操作系が統一されているのはMACの魅力ですし、以前ほどMACは高額なパソコンではなくなったので妻にMAC(MacBook Air)を一押し。

 

使ったことのないパソコンなので、当初は戸惑っていた妻ですが、ショップで現物を見てMacBookのデザインを見て即決…その夜にAppleStoreでポチっとしました。

 

購入したのは、MacBook Air 13インチモデル。

CPUは標準のCore-i5。

メモリは増設して8GB。

SSDは多少余力もたせて256GB。

ショップ販売モデルはメモリ=4G / SSD=128GBモデルなので、この構成はAppleStoreカスタマイズのみ。価格は14万少々なので、DELL/HPといった海外ブランドパソコンにはかないませんが、国内大手メーカーモデルと価格的には遜色ありません。

 

明日にでも配達されてくるようなので、18年ぶりのMACを堪能したいと思います。

(といっても…メインで使用するのは妻なのですが…)

 

2015.03.03

Nextgen Gallery 文字バグってます

blog更新しようと写真をNextgen Galleryプラグインにアップロードすべくアップローダー画面を起動すると見事に文字化けしてました。

 

確か、このプラグインをアップデートしたのは先週くらい。

丁度サーバートラブル勃発中でblogに画像アップロードしていない時でした。

はじめはブラウザが文字コードを間違って解釈しているのか?? と色々試してみたものの一向に治る気配なし。 どうやら文字化けしているのはこのアップローダー画面のメッセージだけで、プラグインの他の項目は正しく表示されています。 バグ確定ですかね? これ?

 

うーん、Nextgen Galleryは比較的更新は頻繁なのはいいですが、色々と別のところにエンバグを作ってしまうこと多いですね~。

取り敢えずボタンは機能しているので、この投稿の画像然りアップロードは無事機能しているようですが…ちゃんと修正されるのかな?

 

2015/03/08

プラグインを過去のバージョンに戻したりして試してみましたが、どうやらプラグインのバグではなかったようです。

先日のサーバートラブルでデータベースのリペアをかけた際に文字エンコードの情報がどころか壊れたようです。

最終的には、WordPressのマルチバイト言語環境での累積的バグを修正する”WP Multibyte Patch“を一旦アンインストールして、再インストール/有効化することで問題が解決されました。

2015.02.27

サーバー不幸の連鎖その3(歯切れの悪い完了)

WordPressのプラグインのお陰でMySQLのDBの修復も完了し、仮想サーバーやVMWare含めたシステム全体を再起動すると新たな問題が発生していました。

 

今度はこれまで無事に動いていたWEBサーバーも動作しなくなっています。

厳密には、旧サイトは普通に動いていますが、このblogを格納している新しいWEBサーバーがエラーを出しています。

何度かサーバーを再起動して傾向を探ろうとしますが、

 

Apacheから“503 Service Unavailable”エラーで落ちる場合と

WordPressから“データベース接続確立のエラー”のエラーで落ちる場合

 

この二種類あるようです。

どちらも起動したてのサーバーでは考えにくいエラーです。

特にApacheのエラーはサーバーリソースが枯渇した場合に出るエラーで、安定稼働していたApache設定ファイルには何も手を加えずシステム再起動して出るような類のものではありません。

旧サイトは正しくつながっているので、少なくともリバースプロキシのApacheは正しく動作しているようです。

 

そして起動時のログを追いかけながら、何度か再起動を繰り返しているとおかしな傾向が見えてきました。 サーバーの起動にかなり時間が掛かっているということに・・・

 

システム全体の再起動では、親サーバーが起動した後スクリプトでVMWareをバックグラウンドで起動し順次仮想サーバーを起動していきます。 同時実行するとサーバーの起動順序がバラバラになるので一つ一つの仮想サーバーの動作が確定してから次の起動に移ります。

よって複数のサーバーで起動の時間がかかっていると全体の起動完了が非常に時間が掛かることになります。

それぞれの起動を追いかけて行くと、途中で引っかかっているシーケンスを発見しました。

 

netfsサービス…NFSです。

 

本来ならばVMWare内の仮想ネットワークでのNFS接続なのでそんなに接続に時間がかかるとは思えません。

しかし、確実にNFSでつまづいているようです。

再起動してログイン画面が出、システムにログインし、dfコマンドでマウント状況を確認するとログインした段階ではまだNFSマウントされていません。

数分経過してからdfで確認するとNFSマウントされているので、どうやらバックグラウンドモードで再接続を試みているようです。

ただWEBサーバー / MySQLサーバー / sambaサーバーこれらはNFSマウントされた先のデータを利用していますので、こんなに遅くマウントされることは想定していません。 どうやらこれがエラーの諸悪の根源のようです。

 

対策としてはNFSクライアント設定でnfsvers等CentOS同士だから・・・と、デフォルト解釈で任せていた部分を明示的に設定。

出来ればサーバー起動前にNFSマウントを保証したいのでバックグラウンド接続はやめてフォアグラウンド接続の設定にしたかったのですが、それだと今回のような場合ハングアップ同様の状態となりかねず、もっと深刻な問題になりそうなので一旦見送り。 さらにsambaについてはsambaの設定(smb.conf)において接続先IPアドレスだけでなくネットワークインターフェース名(eth1等)を明示的に設定。

 

これら設定を行ってシステムを再起動…安定接続できるようになりました。

 

何れのサーバーもクライアントからの接続とNFS接続を分離し、仮想とはいえDUAL LAN構成としていたのでここに問題があったのかもしれません。

・・・ここで「かもしれません」と歯切れの悪い記載になっているのは、本当にそうなのか…と、設定を元に戻して再起動すると今度は何事もなかったように起動して来て不具合の再現性が無くなってしまったためで、本当にこの設定が決定打なのか…じつははっきりと言い切れないのです。

 

ただ接続設定が明示的ではなかったのは事実で、その設定自体がなにか悪影響するわけではないと思います。

なので今回はこの設定のまま運用を再開することにしたのですが、やはり内心は不安です。

 

暫く様子をみて、また何かあるようであれば追いかけてみたいと思います。(こういう体験はできれば勘弁願いたいですが…)

2015.02.25

サーバー不幸の連鎖その2

WEBサーバーが観れなくなっている原因を探ろうとノートパソコンを起動しようとしたら、まさかのsambaサーバーの同時不調。

危うく無実のノートパソコンがクラッシュしかけの状態まで行き、やっとの思いでサーバーのメンテナンスを開始。

 

まず行うのは、外部(WAN)側からの接続は駄目で、では内側(LAN)からのアクセスはどうか。

 

コチラは問題なし?…いやなんとなく重い…でも一応機能はしている。

 

特にWordPressにログインするとものすごく重い。

ここで疑ったのはeo光と接続しているアクセスルーター。

しかし、おとよが採用しているのはマイクロリサーチ社のSuperOPT100E

民生用ながら空気のような存在とまで言われる信頼性の塊。

先代のSuperOPT50も同様に信頼性の塊で10年以上使用していたものの、本体ではなく電源(ACアダプタ)が壊れたので買い換えしてまだ2年ほど。

そうそう考えられない事ながら念のため、普通にインターネットに接続。

 

コチラ問題なし。快調。

 

仮想マシンが不調なのか?? と、念のため別仮想マシンで動作しているメールサーバーを外部(WAN)/内側(LAN)からアクセスしてみる。

 

外部(WAN)NG / 内側(LAN)OK。

 

WEBサーバーとメールサーバーがまったく同じ挙動…ということは、仮想マシン個別の話ではなくて、

 

1.VMWare自体がおかしなことになっているのか

2.VMwareを動作している親サーバーがおかしなことになっているのか

3.インフラ(Internet)がおかしくなっているのか

 

この三つに想定要因が絞られる。

続いて確認したのが、アクセスルーター(SuperOPT100E)はLAN側に簡易DNS機能を有しているので、LAN側からのサーバーアクセスでは簡易DNS機能を使用していることから、外部のDNS…とくにこのwendy-net.jpがちゃんと外から見えているか。

これは我が家の固定IPで直接外部から接続してみるとわかる。

 

結果、IPアドレス直接アクセスではOK / ドメイン名アクセスではNG

 

どうやら原因は見えてきた、ドメインを管理しているdnsサーバーが怪しい。

 

そこでnslookupを使用して”wendy-net.jp”が登録されているns.mydomain.jpと比較用にgoogleのdnsにアクセスしてみる。

ビンゴです。 dnsサーバーが落ちています。

pingを打ってみると応答ありなので、センターが物理的に落ちているのではなくて、ホスティングサーバーが落ちているっぽい。

原因はわかったものの、私の手の及ぶところではないので、とりあえずドメイン管理会社にメールで連絡。

この時点で日曜日の夕方になっていたので、実際に対応いただけるのは早くて明日。 気長に待つしかないでしょう。(困るけど)

 

しかしそれでも、なぜWAN側からアクセスされることのないsambaや、WEBサーバーが極端に重くなっているのか…この問題が解決していません。

とくにsambaの不調は深刻で、お家のすべてのパソコンがログイン後デスクトップでブラックアウトしたままになります。

 

色々ググッてみるとsambaは更新により過去の設定ファイルが役に立たない場合があるという記述を発見。 このsambaを設定したのはCentOS6.4のとき。 今は更新により6.6となり、それからの自動更新が行われています。

ちょっと信じ難い部分もありますが、昨年末にアップデートし、安定稼動を見届けた状態のスナップショットもありますので問題の切り分けには丁度良かろうと…CentOS動作のサーバー(WEBサーバー / リバースプロキシ / MySQLサーバー / samba)を昨年末にロールバック。

 

今回一番うかつな作業でした。

 

MySQLのDBやWEB本体のディスクはすべてNFS経由で親サーバーのストレージにありますので、仮想サーバーには一切依存性のデータは残していないはずでした。

それは事実ですが、一点依存性のある重要なファクターを忘れていました。

 

時間です。

 

時間軸が昨年末に戻り各サーバーのntpd同期が完了しないうちにサービスを動作させたので、特にWordPressがMySQLにアクセスした際にパニックが発生。 インデックスデータの整合性が取れなくなるというトラブルに発展。

まさに泣きっ面に蜂です。

WordPressのDBまで飛ばして、この2ヶ月ほどのデータがDBアクセスできない状態とあっては再起不能になりそうです。

ただこちらの問題は幸いWordPressにインポートしていたデータベース管理用プラグイン“WP-DBManagerにリペア機能が搭載されていて、インデックスの不整合を何とか修復してくれました。こちらはかなり運が良かったです。(今回ノートパソコンでもロールバックして痛い目をみたので、今後ロールバックはよほどのことがない限りやらないと心に誓った)

 

しかし、まだsambaは不調のままです。 なんら不具合対策は前進していないです。

ここまでサーバーをあれこれ触っていたので、一度システム全体をリセットして仕切りなおし…と親サーバーを再起動すると、さらに別の問題が発生します。

 

つづく・・・

1 / 912345...最後 »