日記帳だ! 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など)

<< 過去

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

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

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

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

再起動したらちゃんとスリープに入るようになり、昼休みに見ても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)

AACなら24kbpsに削れるか

気づけば、もう木曜日で、やっぱり月曜日が欠けると一週間が早い気がする。

けっこう慌ただしい1週間だなぁとも思うが、それなりにうまく進んでるのかね。


ちょっと前の話なんだけど、タブレットで音楽を聞けるようにするために、

音楽ファイルを再エンコードしていた。

タブレットのメモリはあまり余裕がないのだが、持ち歩ける曲数は多くしたかったので、

音質は多少犠牲としてもできるだけ圧縮率を高くしたいということで、挑戦していた。


高圧縮といえばAACだろうということで、その中でそれだけ圧縮できるかというのを試してみた。

Nero AAC Codecをfoobar2000で叩くということで設定しようとすると、

オススメは可変ビットレートで、もっとも低品質にすれば約15kbpsまで下げられるようになっていた。

典型的にMP3で128kbpsとかに設定してエンコードすることを考えれば、かなり小さい。

そんなんでいいんかと思いつつ、試しにやってみると、意外とまともに聞こえる。

ただし、高音部が明らかにおかしいが。高圧縮率にするとそこは犠牲になると。


ただ、同じビットレートでMP3だと高音部がバッサリ削れて、あまりよくないAMラジオみたいになってしまうが、

AACはバッサリ削るわけではないのか、なんかおかしいなと気づくけど、それなりに聞ける。

何個か試してみた結果、約24kbpsという設定でタブレット用のファイルを作ることにした。

1GBで90時間ぐらい入るということで、これぐらい入れば一応は困らないという計算もある。

ええ、実はそんなに入るんですよ。1曲5分で換算すると1000曲ぐらいですね。


「24kbpsなんて」と弟には言われそうなものである。

弟はMP3で128kpsでも削りすぎではないかと言うような人だったから。

一般的に128kbpsあれば十分と言われているのだが、いや320kbpsにするべきだとか、可逆圧縮にすべきだとか、そんなことを言うような人もいる。

違いがあるかないかで言えばあるという話なのだが、ビットレートを上げる価値があるのかはよくわからない。

アーカイブ用ならそこは追求すべきという考えもあるのかもしれない。HDDの容量は有り余ってるのだし。

持ち歩き用としてはビットレートを下げるのは特に問題は無い気がするが、それにしても24kbpsというのは一般的にやりすぎだろうと思う。


ちょうどBluetoothのイヤホンを買ったので、これで聞くために音楽をタブレットに入れこんだわけだけど、

ケーブルがなくなったので電車の中で聞くとかでも煩わしさは減った。

タブレットは大きいからポケットの中に入れにくいし、その点でBluetoothのメリットはなおさら大きい。

今までタブレットで音楽を聞く気にあまりならなかったのはそういう事情もあったのかも。


Author : hidemaro
Date : 2016/10/13(Thu) 23:18
コンピュータ | Comment | trackback (0)

寝てるのにタブレットがスリープしていない

タブレットを充電せずに寝たら、起きたら電池が30%ぐらい減ってて驚いた。

寝る前に満充電にしたから充電しなくていいだろと思ってたのだが、それにしてもおかしい。


調べてみたところ、全くスリープになっていないことがわかった。

そりゃ消費電力が高いわけである。

通常は画面が消えている状態で、特に問題なければスリープとなって消費電力を減らすものである。

スリープ中も割り込みは利くから、インスタントメッセンジャーとかの受信はできるようになっている。

寝ている間、大半はスリープだけど、時々、スリープを解除しているのが典型的な姿である。


原因は Google Play開発者サービス にありそう、というのは統計データからわかったのだが、

それに対する有効な手立ては見あたらなかった。

いや、見つかったんだけど、どうも効果なさそうだったんだよね。

『GooglePlay開発者サービス』がバッテリーを異常消費する&スマホを発熱させまくる時の対処方法 – Android 6.0対応 (usedoor)

これがないとGoogle Playが使えない、ぐらいならまだよかったのだが、カレンダーも同期されないということで、

無効化するに無効化できないプロセスだが、それだけにこういう問題を引き起こすこともある。


真相のほどは分かっていないのだが、こういうことがあるそうで。

MeMO Padの電池はうまくいってれば長く持つんだけど、

さすがにAndroidがそのポテンシャルを引き出してくれないとどうしょうもないという話である。

旅行前にめんどくさい話だ。


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

括弧がないと後で困ることがある

プログラミング言語の制御構文の表記として、2タイプの書き方が使われることがある。

例えば、Cだと{}で囲むか囲まないかの2通りがある。

if(a==0){ foo(); bar(); }
if(a==0)  foo();

ただし、{}で囲まなくていいのは1文だけで終わるときだけ。

2文以上になるときは{}で囲むことが必須となっている。

Pythonだとインデント必須だからこういう問題は無いなど、全てのプログラミング言語共通の問題ではないが、多くの言語で存在する問題だ。


なんで1文だけなら{}で囲まなくてもよいのだろうか?

実は、コンパイラにとっては{}を使わない方が基本みたいなんだよね。

基本は1文、だけど{}で囲むと2文以上を1文という扱いにできるというのが実際のところらしい。

foo(); も {foo(); bar();} も1文と捉えると、制御構文の後には1文しか書かれないのだ。

ただし、実際にプログラムを書く人にとっては、

if(…){ ~ } とか for(…;…;…){ ~ } で1つの制御構文だと思っていることが多いのではないだろうか。

これを基本として考えれば、1文ならば{}を省略できるというとらえ方になる。


ケースバイケースではあるのだが、僕はできるだけ{}は省略しないようにしている。

if(a==0){
foo();
}else{
bar();
}

この場合は、下記の通り書いてもよいのだが……

if(a==0)
foo();
else
bar();

ただ、難点があって、bar();の後にhoge();を実行する必要があることになったとき、

if(a==0)
foo();
else
bar();
hoge();

うっかりこう書いてしまうと想定通り動かない。

なぜならば、これは{}を使って書いたら if(a==0){foo();}else{bar();} hoge(); という意味になってしまう。

{}を付けておかないと、後で書き足したり消したりするときにうっかりしてしまうことがある。

できるだけ{}を省略しない理由の1つである。


最近はVerilog HDLを書くことが多いのだが、Verilogも事情は一緒である。

VerilogだとCの{}に相当するのは begin~end だ。

だからbeginとendはものすごい頻度で書く。

ただ、明らかにbeginとendを書くのはめんどくさいので、既存のソースコードを見ると書かれてないこともしばしば。

always @(posedge clk or posedge rst)
  if(rst==1)
A <= 0;
else if(setX==1)
A <= A_X;
else if(setY==1)
A <= A_Y;

こんなに書いてるのにbegin,endを省略してもよいのだ。

ところがAとは別にBというレジスタに、setX=1のときはB_X、setY=1のときはB_Y をセットするとなれば、

always @(posedge clk or posedge rst)
  if(rst==1) begin
A <= 0;
B <= 0;
end
else if(setX==1) begin
A <= A_X;
B <= B_X;
end
else if(setY==1) begin
A <= A_Y;
B <= B_Y;
end

とbegin,endを書き足さないと想定通り動かない。


この程度ならまだよいのだが、Verilogのcase文ではもっとひどい目にあうことがある。

case(sel)
0:  Aout <= Ain0;
  1:  Aout <= Ain1;
  default: Aout <= 8'h00;
endcase

実際にはもっとずらずらと並んでいるわけだけど……

見ての通り、Verilogのcase文というのはCで言うところのswich文にあたるもので、

0ならば0:以下を実行、1ならば 1:以下を実行、いずれにも当てはまらなければdefault: 以下を実行するとなっている。

パッと見似ているけれど、けっこう違う。Cだと条件が終わるごとにbreak;を書かないといけないけど、Verilogはそういうのない。

で、selでBoutも選択する必要があるとなるとこうなる。

case(sel)
0: begin
    Aout <= Ain0;
    Bout <= Bin0;
  end
  1: begin
    Aout <= Ain1;
    Bout <= Bin1;
  end
  default: begin
    Aout <= 8'h00;
    Bout <= 8'hFF;
  end
endcase

そう、2文以上になると、条件ごとにbegin~endを書かないといけないのだ。

これを延々と書き換えるのは骨が折れる。

そこまでして元のcase文を活用するのがよいのかという話もあるが。


さすがにcase文にいちいち begin~end を書くのは割に合わない気もするが、

alwaysやらifやらにはできるだけbegin~endを書くように心がけている。

最初は1文だけだと思っていても諸事情により2文以上書きたくなることは時々あるので。

そんなときに小さな改造で済むのなら begin, end を何回も打つ程度は大したことではない。

そういうのに慣れてしまって、Cの{}なんて何の手間でもないと感じるほどだ。


あと、Verilogで困るのがalways文で書かれた組み合わせ回路で、

条件を追加するとセンシティビティリストをいちいちいじらないといけないとか。

always @(sel,A,B,C) begin
if(sel==1)
Q <= A & B;
else
Q <= C & D;

入力は sel,A,B,C,D の5つあるのに、センシティビティリストにはsel,A,B,Cの4つしか列挙されていない。Dを忘れている。

これを忘れたがために想定外の回路が生成されてしまうこともあるので、要注意ということ。

解決法はいくつか想定されて、センシティビティリストを*にして always @(*) にするというのも答えの1つ。

ただ、そもそもalways文で組み合わせ回路を作ろうとすること自体が危ないという話もあって、

assign Q = (sel==1) ? A & B : C & D;

としておけば間違えなく組み合わせ回路が生成される。

少なくとも近所では組み合わせ回路=assign文という考え方の方が主流のようで、新規でalways文で組み合わせ回路を書くことはなさそう。

こういうのはHDL特有の問題だけど。ソフトウェアではこういうタイプの悩みはない。


Author : hidemaro
Date : 2016/07/06(Wed) 23:18
コンピュータ | Comment | trackback (0)

Tools