日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

JavaScriptを有効にし、Cookieを受け入れ、以下のブラウザを使うことで完全なコンテンツが楽しめます。
Mozilla Firefox 3.0(Get Firefox)・Opera 9.6・Safari 3.2・Lunascape 4/5(Gecko)・Lunascape 5(WebKit)
Internet Explorer 7/8とそれを使うIEコンポーネントブラウザ(Lunascape・Sleipnirなど)

<< 過去

タブレットでもマウスを使う

タブレットを買ったからmicroSDを買ってきたという話を書いた。

microSDは安い

最近は、旅行の時にノートPCを持っていくことはなくなっていて、そこで重要なのがタブレットだ。


以前より、Bluetoothキーボードは使っていた。

AndroidでBluetoothキーボード

これは新しいタブレットでも引き続き使う想定でいる。

さらにこれに加えてマウスも導入することにした。


マウスもワイヤレスなのだが、既存のワイヤレスマウスを転用したので、Bluetoothではない。

どういうことって、タブレットのUSBコネクタにワイヤレスマウスのレシーバーを付けたって話。

タブレットのUSBコネクタはmicro-Bという形状で、レシーバーのUSBコネクタはType Aという形状でそのままでは合わない。

けど、秋葉原で探すと安価な変換コネクタがあって、確か300円ぐらいで買えた。

変換コネクタ+レシーバーをポコッとタブレットに差し込むと、マウスが使えるようになる。


あまり出番のないワイヤレスマウスに活躍の場を与えようというのが動機ではあるが、

タブレット+キーボード+マウス という組み合わせはなかなかよい。

タッチパネルだからマウスがなくてもタッチすればよいのだが、タブレット横向きでタッチって慣れないんだよなぁ。

指で小さな文字に触れようとすると、うまく触れないから、適宜拡大してタッチするのがタブレット流。

けど、タブレット横向きと拡大の相性というのはあまりよくないような気がする。

そこでマウスがあれば、拡大しなくても細かいところに触れる。

さらに片手キーボード、片手マウスでPCのごとく操作出来るのも好都合というわけ。


ちなみにタブレットのUSBホスト機能、使える機器と使えない機器があるのは言うまでもないが、

USBストレージはだいたい使えるので、変換コネクタを介してストレージを差し込むと、ちゃんと読み書きできる。

なので、タブレット・スマートフォンでUSBストレージの中身を確認するとか、そういう用途にも使える。

変換コネクタはものによってずいぶん値段も形状も違うので、いろいろ探してみるとよい。

シンプルで安いのを見つけたら買いだと思いますがね。といっても普通にタブレット・スマートフォン使う分にはあまり使うものでもないが。


Author : hidemaro
Date : 2017/08/22(Tue) 23:16
コンピュータ | Comment | trackback (0)

思っていたCRC32とは少し違う

最近、CRCの計算とかやることがあって……

というかこれからCRCを導入しようとしているところがあって、そのための調査をしてたんだよね。

導入するならCRC32だろうと思ったのだが、詳しく調べてみると、これまで思ってたより複雑だった。


というのも、これまで職場で使ってたCRC32と、僕が想像していたCRC32と、世間的によく使われているCRC32は、それぞれ少しずつ違ったのよね。

これまで、職場で使われているCRC32の計算プログラムを他のシステムに移植したりすることはあったんだが、

その意味について詳しく考えたことはなかったし、世間のCRC32の計算がどうなってるかはあまり気にしてなかった。

だから、いろいろ勘違いがあったというわけ。


そもそもCRCというのは、2進数のわり算の余りのこと。

CRC32の場合、一般的には0x104C11DB7 という33ビットの値でわり算をして、その余りの32ビットの値を使う。

そういう理解はしていたし、職場で主に使われているCRC32も、世間的によく使われているCRC32もこの考えは一緒。

だけど、単純に上に書いた考えで計算した値と、職場で使われているツールで計算したCRC32の値が食い違うんだよね。

ソースコードの途中経過を追うと、かなり最初の方で食い違いがあるらしい。

そこでいろいろ調べてみたのだが、根本的なところに差があった。それは、よく使われるCRC32は右送りだということだ。


CRCの計算では左送りと右送りという考えがある。

普通、コンピュータの計算というのは一番左のビットがMSB、右のビットがLSBと考えて計算する。

CRCの計算もそうだと思ったのだが、この考えは主流ではないらしい。

ちなみにこの方法でのCRC計算はデータを左ビットシフトしながら計算するので、左送りという。

CRCの計算で一般的なのは、右のビットをMSB、左のビットをLSBと考えて計算する方法。

CRCの計算に限っては1バイト単位でMSBとLSBを反転させて計算するのが一般的な方法らしい。

除数(0x104C11DB7)のMSB・LSBを反転させた値を使いながら、データを右ビットシフトしながら計算するので、右送りと呼ばれる。

なぜ右送りが主流なのかというと、シリアル通信ではLSB→MSBの順序でデータを送ることが多いから。

到着したデータから順番に後ろに足して、わり算してというのを繰り返すとすれば、こちらの方が好都合なんだと。


そういう前提が分かれば、逆回しで計算するように書けばよいだけのことである。

これまでのソースコードも見返しながら、右送りで計算するように書くと、職場で使っていたツールの計算結果と一致するようになった。

ただ、その一方で世間でよく使われているらしいCRC32の計算ツールの結果とは食い違うことに気づいた。

なぜ食い違うのかというと、それは世間で使われているCRC32は前と後に追加の処理が入っているからである。

確かに世の中に転がっているサンプルプログラムと、職場でよく使われているCRC32の計算プログラム、

似てるが、前後に差があることに気づいた。


どうも、世間ではCRC32の初期値は0xFFFFFFFFとして計算して、最後にビット反転させるのが一般的らしい。

職場では初期値0x00000000のものしか見たこと無いし、最後のビット反転もしない。

なぜ、初期値を0xFFFFFFFFとするのが一般的なのかというと、

0を初期値にすると0x00が連続するデータに対するCRCがオール0になってしまうからだそう。

そういえば、以前このBlogにも「オール0のデータに対するCRCはオール0になる」ことに由来する事件について書いたな。

一見正しいCRCだけど

これを避けるために初期値を0xFFFFFFFFとすることが一般的になったそう。

最後にビット反転を行う意味はよくわからないが、なんとなく最後も反転させておくかと考えたんだろうか。

ただし、前処理・後処理は誤り検出の能力に本質的な差はないとされている。

オール0のデータに対するCRCがオール0になったとしても、それは運の悪いケースの1つという話だ。


このあたりの事情を調べているときに発見したことがある。

どうもデータの後ろにCRCを付加したデータを作って、それのCRCを計算すると一定のCRCになるという性質があるらしい。

16進数で 01 02 03 04 05 06 07 08 というデータ列があったとする。

これを初期値0xFFFFFFFF、右送りでCRC32を計算し、最後にビット反転すると0x3FCA88C5 という値が得られる。

このCRCはわり算の余りのMSB・LSBを反転して後処理した値なので、全体のMSB・LSBを反転して、

さらにデータ列の順序を踏まえて、計算バイト単位でMSB・LSBを反転すると C5 88 CA 3F というデータ列になる。

すなわち右送りの場合は、計算して得られたCRCをリトルエンディアンで並べ替えて付加すればいいってこと。

こうしてCRCを付加したデータ列のCRC32を同様に計算すると 0x2144DF1C になる。

一見すると意味不明な値だが、これは 00 00 00 00 というデータ列に対して計算したCRC32と一致し、

同様の方法で生成したデータ列に対しては必ず0x2144DF1C というCRCが求まる。


ちなみに最後のビット反転の後処理がない(再反転した)場合、最初のデータ列のCRCは 0xC035773A になる。

これをリトルエンディアンで並べ替えて 3A 77 35 C0 というデータ列を最初のデータ列に付加する。

このデータ列にビット反転の後処理なしのCRC32を計算すると 0x00000000 になる。

そうなんですね。後処理がなければ、綺麗にオール0になるんですね。

原理は上とまったく一緒なんだけど、後処理なしだとオール0になるということの方が本質に近い。

わり算の余りを後ろに付けるってそういうことだから。

CRCを最後に付ける場合にしか適用できないのだけど、当てはまる場合は実装上、シンプルでよい方法かも。


同じ方法で計算するだけならなんとなくで使ってればいいんだけど、

マイコンとデジタル回路とか、複数の方法で計算する場合はその間で整合性がとれる必要がある。

あと、今回は取り上げなかったけど、Intel CPUに内蔵されているCRC32計算命令では、一般的に使われているものと除数が異なるそう。

というわけで、よく理解して使わないと痛い目を見ることもあるって話。

原理が思いのほか複雑だから、ハマってしまうとなかなか手間取ると思うので要注意だなと思った。


Author : hidemaro
Date : 2017/07/20(Thu) 22:31
コンピュータ | Comment | trackback (0)

端末課金はよく考えれば当たり前の事

「端末課金」という言葉を聞くことがある。

なんのこっちゃという話だが、スマートフォンのゲームでこういうことを言う人がいる。


というか、調べても「アイドルマスター シンデレラガールズ スターライトステージ」のプレイヤーしか言ってないが。

このゲームの特徴として、高い3Dスペックが要求されること、リズムゲームということでタイミングにシビアなことがある。

すなわち高い性能のあるスマートフォンを用意しなければ、満足なプレイが難しいと。

ただし、本当に高いスペックが必須なのかというと、必ずしもそうとは言えないんだけど。

2Dモードにすればスペックが低くても問題ないのだから。


というわけで端末課金というのは、高いスペックが要求されるゲームのために端末にお金をかけることを表している。

けどよく考えてみれば当たり前の話なんだよね。

かつて、コンピュータゲームを遊ぶためには、ゲーム機を買う必要があった。

このゲーム機はゲームを遊ぶために十分なスペックを持っているので、それで満足に動くようになっているわけだ。

ところが専用のゲーム機を使わないPCゲーム、スマートフォンゲームというのは満足して動くための装置をユーザーが見繕う必要がある。


じゃあ、PCゲームも事情は一緒じゃないかと言われると、確かにその通り。

秋葉原でいろんな店がゲーミングPC関係商品を充実させているのは、そういうニーズが大きいことを表している。

高いスペックが要求されるPCゲームを買うなら、それに応じてこういうものを買いましょうとか、そういう目安も示されている。

ただ、スマートフォン向けのゲームは、とりあえずプレイするだけなら無料であることが多い。有料としても基本的には安いのでは?

手軽に遊べるから手を出してみようと思ったら、自分の端末がスペック不足であることに気づき、

ゲーム内で有料アイテムを買う(よく「課金」と言われている)という以前に、端末を買い換えるという話が出てくるわけ。

だからこそ端末課金という言葉が出てくるのだろう。


かくいう自分もゲームを念頭に置いて端末を買い換えた人なのだけど。

Y!mobileに帰ってきた

BB.exciteモバイルLTEの品質があまりよくなくて、優遇期間がそろそろ終わるということの方が大きな理由だったが、

一方で、タブレットの性能不足に悩んでいて、その解決策も兼ねていた。

ゲーム自体にはお金をかけていない(有料アイテムの購入含めて)けど、それをプレイするスマートフォンにはいくらかお金をかけたと。

まぁそもそも電話として使えるAndroid端末持ってないから、何らかの形では買わないといけなかったし、


スターライトステージが出てきた時、スマートフォンでここまでできるんだと驚かれたんだけど、

実際のところ、高い表現力を得るためには、相応のハードウェアが必要ということで、

落胆した人もいたかもしれないし、端末課金に走った人もいたのかもしれない。

当たり前のように持っている端末で満足に動くかというと必ずしもそうとは言えないと。

それぐらい性能向上が著しい世界だから。

最近「3Dリッチ」というモードが追加された。リリース後の性能向上に応じて作られた新モードということだろうか。

これで満足に動く端末は本当に限られてるんだけど、表現力の向上は顕著だそうで。

3Dリッチ狙いで端末課金、そんな話もあるのかな。


Author : hidemaro
Date : 2017/07/01(Sat) 19:21
コンピュータ | Comment | trackback (0)

カイロのように電池を食う

会社に行ったら、ポケットの中がえらく熱い。カイロを入れてるかのように。

そう思ってポケットからスマートフォンを出すと、電池がえらく減ってる。

設定→電池を呼び出すと、ずっとスリープしていないことに気づいた。

再起動したらちゃんとスリープに入るようになり、昼休みに見ても1%ぐらいしか減ってなかった。


タブレットでもそうだけど、時々こういうことあるんだよね。

だいたい再起動すれば直るかな。

これがずっと続くようだと「不眠症」とか言われるんだろうけど。

一時的な問題なら仕方ないって話では。


タブレットはものが大きいこともあって、発熱を強く感じることはそうなかった。

それより高機能なものが1/4ぐらいの面積なんだから、発熱すると熱いと感じるんだよね。

今時のスマートフォンの高密度さを感じることのできる一例である。

そんな中でもすごく熱いのがゲームをプレイしているときのこと。

高い3D性能を使っていると熱くなるし、電池の減りも早い。

ポケットにこんな高性能な端末が入るなんてと思うのだが、そうはいっても相応のエネルギー消費はあるらしい。


使わないときの電池消費をできるだけ減らす。

これは非常に重要なことなのは、今日の朝の一件からもわかること。これまでも実感してきた。

うまくいくと本当に電池の減りって遅いのは、比較すればよくわかる。

電源を切らなくても、無に等しいほど消費が少ないと言ってもよい。

タブレットは充電の頻度はあまり高くないが、使用時間は限定的なので、電池消費はかなり抑えられている。

スマートフォンも使わない時間はほとんど減らない。使うとガッツリ減るが。

使ってるときの電力消費も減らす余地がなくはないけど、フル性能使われるとそりゃ無茶だよね。


Androidの電池の減り方のグラフってのは、電池の減りの原因分析にとても役立つ。

じりじりと減るか、急激に減るか。そういうところで理解が変わってくるから。

今回のなんてわかりやすくて、ある時刻から一定のスロープで残量が減ってたから、

こりゃなんか裏でまずいことが起きてるが再起動で直るだろうと推定できた。

電池が減る原因を分析するというのも、今時のスマートフォン・タブレット特有のことかもしれない。

電池を消費する原因が簡単ではない機器なのだから。


Author : hidemaro
Date : 2017/06/22(Thu) 22:04
コンピュータ | Comment | trackback (0)

勝手に消えるアラームと消すまで残るアラーム

最近、2種類のシステムを使って、ある種の監視システムを作っていた。

どっちも過去に作ったものをちょこちょこっといじってやれば完成するということでやってたのだが、

この2つのシステムを同時にいじってたら、監視の方針に差があることに気づいた。

どっちの監視システムも過去に構築したのは自分なのだが。


仮にこの2つのシステムをAシステムとBシステムと名付ける。

Aシステムの監視の基本的な考え方は、異常状態になったらアラームを表示して、ログに残す、

そして異常状態から復帰したら、アラームを消して、こっちもログに残すというもの。

異常状態から復帰するとアラームは消えてしまうのだが、ログには残るので、何かあったことはわかる。

一方、Bシステムの監視の基本的な考え方は、異常状態になったらアラームを表示して、

異常状態から復帰しても、手動で復帰動作をするまではアラームは消えない。

Aシステムでも異常状態から復帰しても手動で復帰動作をするまではアラームが消えないように作り込んだ部分はあるのだが、一部だけ。


なんとなく作ってたらこうなったという話なんだけど、一応、両システムの長所短所を踏まえたものではある。

Aシステムは異常状態の表示機能が充実していて、ロギング機能も充実している。

なので、元々ある仕組みをできるだけ活用した結果こうなったわけだ。

一方のBシステムは異常判定は基本的に手で作り込む必要があったので、

サンプルや過去の構築例を見ながら、異常検出機能を手で作り込んでいった。

サンプルはことごとく、異常検出したら手動復帰までアラームを消さないようになっていて、それにならったわけだ。

そういう用途で使われることが多いみたいね。


Bシステムで主に使った方式の方が、なにかあったことが確実に分かる点では優れている。

実用上はAシステムで主に使った方式でも問題はないことは確認済みなのだが……

それぞれ個別に存在している分にはあまり気にならなかったのだが、2つ平行で作業をしているとなんとなく気になる。


その昔、僕以外の人がAシステムで作ったものを見てみると、

AシステムでもBシステムのごとく、異常検出を手で作り込んで、異常検出したら手動復帰までアラームを消さないように作られていた。

それをことごとく作り替えたのは僕なんだけど、標準機能にあるものをあえて手で作るのはおかしいだろということで、

標準機能を使えるところはできるだけ使うようにしたんだよね。

標準機能だけでできない部分もマニュアルなどに掲載されているサンプルを参考に作るようにした。

もともと妙な機能で作り込まれていたので、メンテナンス性があまりよくなかったのだが、

標準機能で足りずに作り込みが必要な部分でも、よく使われる方法にしておけば、メンテナンス性もよいだろうと考えたのだ。

その結果、Aシステムでは異常状態から復帰したら、アラームが消えるようになった部分が多かったと。

それでもログには残るので実用上の不都合はないのだが。


基本的にはBシステムの方が貧弱なんだけど、フルカスタムで作る分には意外とやりやすい面もある。

がんばって1つ作れば、あとはそれのコピペでいろいろ使えるので、1回苦労すれば、あとはそんなに手間もかからない。

逆にAシステムは標準機能が充実している分、カスタマイズ方法がややトリッキーになる部分もある。

想定されたこと以外をやろうとすると、妙に大がかりになったりすると。

僕が作り替える前のAシステムの構築方法が妙な機能を使ってやっている部分が多かったのは、そこら辺の都合もあったのかなぁと。

試験系によりAシステムとBシステムを使い分ける必要があるので、どっちかに片寄せするわけにはいかないのだが、

似たようなものを2つ触ってると、やっぱりそれぞれ個性があるなとは思うね。


職場に他に詳しい人があんまりいなくて、僕が一番詳しいという話すらある。

一方のシステムは今の職場に来る前のOJTで触ってたので、それでやれよという話になり、

そっちができるならもう一方もできるだろっていって、マニュアルやノウハウ集を見ながらやったらできたと。

過去には他の職場の人に助けてもらいながらやってたらしいんだけどね。

誰も触れないわけでもないんだろうが、もともとメンテナンス性がよくなかったからね。なかなかノウハウも蓄積できなかったのかなと。

今後は職場内で触れる人も増えて欲しいんだけどさ。


Author : hidemaro
Date : 2017/05/26(Fri) 22:31
コンピュータ | Comment | trackback (0)

塩漬けされた古いOSのコンピュータ

最近、ランサムウェアによる被害が話題になっている。

データを暗号化して身代金を要求してくるという、たいへん対処に困る代物である。

特にWindows XP以前のOSでの被害が多いということだが、それ以降のOSでもあるとは言っている。


基本的に古いOSは十分なセキュリティ対策ができないということで、ネットワークに接続しないようにという話がある。

会社でもセキュリティ対策の行われた標準PC以外はネットワークに接続しないようにとなっているので、

古いOSのPCがあったとしても、それはスタンドアローンで使うことになる。

スタンドアローンでもUSBストレージなどを介してデータが行き来するので、全く無影響ではないのだけど、


ここの職場には以前の製品で使っていたマイコンの開発環境などの都合で何台もの古いコンピュータが置いてある。

今だと資産にならない金額でも上等なコンピュータを買えるが、その時代のコンピュータは必ず資産になる金額していた。

だから、毎年、資産調査ということでそのコンピュータを1台ずつ掘りだして、確かにあると確認して回ってるけど。

ものによるが、だいたい使用頻度はきわめて低く、毎年1回、存在を確認されるだけという存在のものも多い。

ただ、サポート終了までの間は、万が一のことがあっては困るので、古いコンピュータを残し続けているのだという。


古いコンピュータがゴロゴロ転がってはいるけれど、幸いにもスタンドアローンで定常的に使うようなコンピュータはなかったはず。

古いOSのコンピュータを定常的に使わざるを得ないということになれば、それはいろいろな不安がある。

本当にスタンドアローンで使い続けるの? 行き来するデータは本当に安全なの? ってね。

うちの職場はそれで不都合はほとんどないんだけど、どうしても使っている装置の都合で古いOSを使わないといけないとかなると困るよね。

使う機会が非常に限定されるなら、不便だなぁって言いながらも妥協できるんだけどね。


そうこう言ってるうちに、職場で使うOSもバージョンが変わるんだったかな。

段階的に置き換えって話だったと思うけど、そうなったときに各種環境は対応できるのか?

おそらく、最新のシステムで使ってる各種ツールについては特に問題なしだろうと思う。自作ツールはダメでも対応させることになるだろう。

問題はその1つ前の世代だよね。こいつがダメになる可能性は否定できない。

例え、ダメになってしまうにしても、即時置き換えではないので、しばらくの猶予はあるのだが。

なんとなく大丈夫なんじゃないかと思ってるんだが、実際に動かして確かめたわけじゃないのでなんともかんとも。


Author : hidemaro
Date : 2017/05/16(Tue) 23:08
コンピュータ | Comment | trackback (0)

組み込みシステムの専門家のための試験

今日は情報処理技術者試験の日、というわけで受験しに行っていた。

何を受験するって、エンベデッドシステムスペシャリスト試験(ES)ですね。


僕の専門分野は組み込みシステムで、そういう仕事を主にしている。

とはいえ、当初は電気電子工学の一分野という認識で、これが情報処理の分野に含まれるという認識はあまりなかった。

けど、ちゃんと情報処理技術者試験の中に組み込みシステムの開発者のための知識・技能を問う試験があるんですね。

それがES試験というわけ。


ES試験は情報処理技術者試験の中で高度試験と呼ばれるジャンルに該当する。

情報処理技術者試験は4レベル構成になっている。

その中でも情報処理分野の技術者向けの試験は、レベル2・3・4の3階層に分かれている。

レベル2は基本情報技術者試験(FE)、レベル3が応用情報技術者試験(AP)、

そしてレベル4は高度試験と呼ばれ、専門分野ごとに8つに分かれ、その1つがES試験ということ。

レベル2のFE試験については、2008年に受験して合格している。(cf. IPAがやる試験だというので受けに行った)

その後、去年にレベル3のAP試験を受験し、今年にレベル4のES試験を受けたわけだけど、

こういう手順を踏んだことにはそれなりに意味がある。


レベル4の高度試験は専門分野ごとに特化した試験になっているが、そうはいっても他の分野の知識も一定あることが求められている。

この他の分野の知識っていうのが、AP試験で問われているレベル3の情報処理の知識なんですね。

だから、高度試験を受けるにしても、AP試験相当の知識が必要なんですね。

この知識の確認方法は3種類ある。

  1. 午前I試験(全試験共通の問題)で合格点を取る
  2. 2年以内にAP試験に合格している
  3. 2年以内に他の高度試験に合格しているか、午前I試験で合格点を取っている

2または3の条件に当てはまる人は午前I試験免除という扱いになる。

で、去年にAP試験を受験したのは、ES試験で合格するにはどのみち必要な知識だし、2の条件で午前I免除を受けることを狙ったものだった。

そして、無事にAP試験に合格したので、午前I免除で申し込んでいる。


午前II試験は10時50分スタート、そこから40分の試験となる。

共通問題の午前I試験に対して、午前II試験は試験ごとに違う問題だから、専門分野の基本的な知識を確認する試験ということだろう。

とはいえ、実態としてはマークシート方式で足切りをするという意味合いの強い試験なのかなと。

ただ、午前のマークシート方式の試験を午前Iと午前IIに分けたせいで、午前Iが50分、午前IIが40分、いずれも短いから途中退出不可になっている。

ということで11:30まで必ず拘束されることになる。それから1時間後には午後の試験が再開するのだけど、これがけっこうきついのだ。

昼休み1時間って十分に見えるけど、試験開始20分前までには着席するようにと指示されているし、15分前には問題・解答用紙の配布が始まる。

だから、実質40分しかないのよね。弁当持ってきて食べるだけならなんとかなるけどさ。

一方、FEとAPは午前は2時間半の長丁場で9:30~12:00ということになっているが、

実際には90分経過後に途中退出ができるので、11時半までにはほとんどの人が退出してた覚えがある。

FE・APも午後試験は午前試験終了の1時間後ということで13:00から再開なのだけど、

途中退出込みで考えると正味1時間以上の昼休みが確保できるので、かなりゆとりがある。この差は大きい。


ともあれ昼休み明けは午後I試験、午後II試験と続く。いずれも記述式の試験だ。

組み込みシステム開発の実務を想定したような問題になっている。

なぜ、午後試験が2つに分かれているかというと、試験時間が長いから。

午後I試験は90分で、大問1つが必須、これとは別に選択問題として大問2つから1つを選ぶようになっている。

午後II試験はなんと120分、これで解くべき大問は1つで、大問2つから1つを選ぶようになっている。

確かにこれをぶっ通しでやるのはきついかな。(FE・APの午後試験は2時間半ぶっ通しだから、ここら辺が限界という認識か)

そして、午後II試験は大問1つで2時間とはかなり異様な試験である。

もちろん大問1つとはいうけど、この大問のボリュームが大きいんだよね。


で、試験のできはどうだったの? って話だが、午前II試験と午後I試験は大丈夫かなと思っている。

試験ごとに6割あれば合格ってことだから、それなら大丈夫かなと。

ただ、午後II試験はどうかなぁ。

午後II試験の設問がかなり謎が多くて、高専時代の知り合いが受験していて、その人もだいたい同じ所見だったんだけど。


そもそもES試験って、ソフトウェアとハードウェアの組み合わせでどうやって動くか問う問題も多いんだけど、

それってソフトウェア関係あるか? という質問もあるんだよね。それを元にソフトウェアを作るでしょって話なんだろうけど。

あと、組み込みシステムってリアルタイム性が求められるのが通常だから、処理時間とかの計算が多いんだけど、

午前II試験で選んだ問題は、処理時間の計算をしようにも、前提条件があいまいで、答えがうまく決まらなくて困った。

何があいまいだったかというと、最悪条件を決めるための要素があいまいだったと。

最悪条件でも何ms以内に処理が終われば間に合うというのを求めたかったんだが、この問題で言う最悪条件ってどれだと困ってしまったと。

とはいえ、6割あれば合格だしね。

心配な問題はいくつもあるけど、全部落としたりしてなければ、なんとかなるんじゃないの?


これが合格したら、とりあえず僕の専門分野に対して、一通りの実力が認められたということになる。

というわけで一段落かなと思うんだけど、これに続いて他の高度試験を受けるかって話はある。

受けるとすればネットワークスペシャリスト試験(NW)かなぁ。

現状はネットワーク関係の仕事はしてないんだけど、僕が所属している部全体としては、ネットワーク関係の仕事をしている人もいる。

自分たちの作っている機器も、その先はネットワークにつながるものだし、そういう点では勉強する価値の高い分野ではある。

今回、ES試験に合格すると、それから2年間は他の高度試験でも午前I試験が免除になる。

NW試験は秋だけに実施される試験だから(ES試験は春だけ実施)、今回合格で午前I免除になるとすれば、今年の秋と来年の秋の2回になる。

しっかり勉強して受験することに意味があると思うので、やるとすればちゃんと勉強しないとねぇ。

まずはES試験に合格してからとは思うんだけど、その先として検討しているのはそんなところ。


Author : hidemaro
Date : 2017/04/16(Sun) 19:19
コンピュータ | Comment | trackback (0)

Androidは市外局番を知っている

携帯電話の通話履歴を見たら、なんか料金区域の名前らしきものが表示されている。

どうも今のAndroidの通話履歴表示ではその電話番号の地名が表示されるようになっていて、

携帯電話だと「日本」、固定電話だと「東京」のように料金区域の名前が表示されるみたい。


そしてよく見てみると、電話番号に適宜ハイフンが入っている。

これ、適当に入れてるわけではなく、ちゃんとデータベースを持ってるみたい。

04709と打ち込むと04-709と区切られ(鴨川MA)、04702と打ち込むと0470-2と区切られる(館山MA)。

これを発見したときにはかなり驚いた。

まぁこれも同じデータベースを使ってるんだろうね。


しかし、電話番号の料金区域の名前って果たして知りたい情報かね?

固定電話だとスタンドアローンで電話料金の概算をするなら必要そうだけど。

昔の電話機についていたLCRやACRというのはそういうことをやってたんだろうなぁ。

電話番号から距離を計算して、時間帯と距離を照らし合わせて、通信会社を決めるということをやってたわけだから。

とはいえ、携帯電話だと日本国内であれば電話料金は一律だから、どうでもいい話である。


ただし「日本」という情報はちょっと役立つかも知れない。

というのも国際ローミングなどで外国から電話をかける場合、国番号を付けない=その国内に電話をかけることを意味する。

韓国でかけた 032-xxx-xxxx と日本でかけた 03-2xxx-xxxx は区別したいかもなぁ。

裏では国番号付きで管理してるのかな?

もしも日本国内でも市外局番省略があるならば、どの料金区域でこの電話番号という組み合わせは役立ちそうだが、

移動体通信で市外局番の省略ができるとすればPHSが考えられるが、あんまり一般的ではない気がする。

市外局番省略できるって言っても、どの料金区域にある基地局にかかるかという保証はできないし。

PHS基地局のエリアは狭いから、実用上はあまり問題はないという話だったのかも知れないけど、推奨されないのは言うまでもなく。


市外局番の変更ってのもあるけど、それは定期的なアップデートで対応してるのかな。

パッと見た感じ、世界中の電話番号のデータベースが入ってるっぽいな。

韓国の電話番号も的確に区切れてるように見えたから。

そんなところに力を入れる必要があるかは疑問だが、おもしろい機能だとは思った。


Author : hidemaro
Date : 2017/03/01(Wed) 22:53
コンピュータ | Comment | trackback (0)

新しい内線電話はほとんど携帯電話

今日から会社も再開。

そしてこの正月休み中に内線システムの切り替えが行われたので、

今日はそれで1日てんやわんやだった。


この内線システムの切り替えというのは、無線の内線網を廃止して、公衆回線に集約するというもの。

内線網とPHSの公衆回線の両方に接続できる端末を内線電話として使っているところも多いかと思う。

父の職場がそうだったんだけど、職場内の通話も、緊急時の自宅と職場間のやりとりでも同じ端末を使えるようにしていた。

雪が降ったからと、今日は休暇にするぞって言って、内線電話で職場に連絡してたこともあったし、

逆にトラブル時に職場から電話がかかってきてたこともあったけど。

ただ、うちの職場ではこれまで内線電話と公衆回線用の携帯電話は完全に分かれていた。

公衆回線用の携帯電話は営業部署の人など出張の多い人だけが持っているのだけど。

これが、正月休み明けからは公衆回線用の携帯電話に一本化されることになったわけだ。


うちの職場の人は全員、内線電話しか持ってなかった人なので、新しく公衆回線用の携帯電話が配布された。

この携帯電話は内線電話の代替なのだが、筐体には「070-xxxx-xxxx」と番号が振られている。(070だけどPHSではない)

携帯電話である以上は電話番号というものは存在していて、実際にこの番号にかけたら着信できるようになっているらしい。

じゃあ普通の携帯電話なのかと思ったら、発信側に制限が設けられていて、内線にしか発信できないようになってるとのこと。

一方で、使える場所については特に制約がなく、公衆回線の電波が入るところなら事業所内外を問わず使える。

もともと公衆回線用の携帯電話を持ってた人は、これまで通り外線発信もできるようになっていて、

これに加えて内線への発信、内線番号での着信ができるようになるという仕組みだそうで。


概略としてはこんな具合だが、使ってみないとよくわからないことはあるので、職場の人でいろいろ試してやっていた。

まず、かけ方がこれまでの内線電話と違うという戸惑いがあった。

これまで、内線番号を直接押せばかけられたが、これからは 内線プレフィックス+内線番号 でかけることになる。

なので、電話帳には内線プレフィックスをつけて登録しましょうとのこと。

外線発信ができないとは書いたが、内線プレフィックス+外線プレフィックス+外線番号 でかけると、内線交換機で外線がかかるとのこと。

結局は外線に発信することができるらしい。直接発信する場合との差は発信元の番号ぐらいか。(内線交換機経由だと固定回線の番号になる)

こうなってくると従来からの公衆回線用の携帯電話の存在意義が怪しくなってくるが、

データ通信が使える(社内のE-mailサーバーにアクセスできる機能が使えるはず)と言うのが本当の差分なのかな。


もう1つの問題が、初期設定では電源OFFの時に親機に転送される設定になっていなかったということ。

これまでの内線電話は初期設定の時点で、内線電話にかからなければ、所属する部署の固定電話に転送されるようになっていた。

新しいシステムでは圏外時などの転送設定を随時設定・解除できるようになっているのだが、

設定しないと電源OFFの内線番号にかけると「おかけの電話は――」という音声ガイダンスが流れるだけで、その先に何もない。

これまでほとんど気に掛けてこなかった固定電話の内線番号を調べて、圏外時にその番号に転送するように設定しておいた。

この設定は全員最初にした方がいいですね、ということでE-mailで宣伝しといたが。


新しい内線システムには戸惑いも多いものの、メリットは少なくない。

なぜならば内線用の電話で出張先でも内線への発信・着信ができるからだ。

先日、職場の人がとあるところに出張で出かけていたのだが、その出先から1日何回も外線で電話がかかってきていた。

そのたびに固定電話で受けては、社内にいる担当者に取り次いでとやっていたので、かなりめんどくさかったそうだ。

今後は内線電話を出張先に持っていけば、それで直接、担当者に電話をかけることができるようになる。

あと、これはそういう使い方をするかはわからないんだけど、外線から取次なしに個人の内線電話に直接かけることができるようになった。

あらかじめ内線電話の外線番号を調べておく必要があるし、そんなことしたいかって言われると、やりたくないけどさ。


Author : hidemaro
Date : 2017/01/05(Thu) 19:33
コンピュータ | Comment | trackback (0)

今やアセンブラの時代ではない

開発工程の中で使うチェックリストってのがある。

これは確認したかというのがずらっと並んだ表を印刷して、

そこにチェックをつけて、チームリーダーにも見てもらってというのをやってた。


しかし、このチェック項目の中にどう考えても変な項目があるんだよな。

具体的な項目は書かないけど、おそらくアセンブラでプログラムを作ってた時代の名残なのでは? と思ってる。

アセンブラで書かれたプログラムの小変更ならば、バイナリで見ても差分は小さいだろう、

ということを前提として書かれたチェック項目なのだが、変なチェック項目だ。

注釈で「コンパイラが生成する場合は真面目に見なくてもいい」と書かれているので、ほとんど何も考えずにOKにしているが。


確かにいつぞやの製品まではアセンブラでプログラムを書いてたらしいね。

ただ、今のアーキテクチャも、その1つ前の世代のアーキテクチャもCでプログラムを書いてますからね。

そう考えると、このチェック項目ってどれぐらい意味あるの? って思うんだけどね。

アセンブラの時代なら、なるほどなぁと思わせてくれるチェック項目だったのだが。


一方で同じソースコードをコンパイルすれば、ほとんど同じバイナリファイルが出てくることが期待できる。

そういう比較作業は何度かやったことがあって、DFのバイナリモードはたびたびつかっている。

差分ツールが大活躍

過去に作ったこのバイナリとタイムスタンプ以外同じバイナリを吐けるか確認して、そのときと同じ環境が再現できたか確認したり、

定数だけ差し替えたソースコードをコンパイルしたら、その前と定数部分以外は同じバイナリになってるか確認したり。

今でもバイナリレベルでの比較ってのはなくはないと。差が大きくなると比べる意味は乏しいが。


最終成果物がバイナリということで、このバイナリは本当に正しいのか? と問われているわけだが、

そうはいうけど、結局、そのバイナリはコンパイラ任せなわけでチェックしがいがない。

どちらかというとチェックサムだよね。

最終的にバイナリを提出するときにはバイナリのチェックサムを添えて提出するんだけど、それが正しいかどうか。

これもツール任せではあるのだが、ツールの使い方とかいろいろあるんでね。そこは自分とチームリーダー両方が見ると。


Author : hidemaro
Date : 2016/11/16(Wed) 23:50
コンピュータ | Comment | trackback (0)

Tools