組込み系こそJenkinsでちょっと便利なビルド環境をつくろう

JenkinsってWeb系のひとだけが使って便利なやつだろー？組込みだから関係ないもんねー？なんて思っていませんか。

そんなことはありません。組込みだって活用は可能なんです。だって組込みは、

• クロスコンパイルが当たり前
• 開発環境（有料）のライセンスの都合で、ビルドPCをみんなで使いまわしている
  ……負荷状況に応じてビルドするマシンを選択してくれたらいいのに！
• 開発環境の都合で、OSごとにビルドマシンを用意している
  ……マシンが多くて管理が面倒くさい！
• 開発環境に新しくアプリをインストールするのは嫌だ

なんてこと、ありますよね。Jenkinsならこれを楽に解決できちゃうるんです。

Jenkinsの特徴

ざっくり言ってしまうと、Jenkinsはちょっと賢いcrontabです。 ちょっと賢い部分というのは、

• 処理を開始するトリガに指定した時刻、周期が設定できる
  （…cronに似た書式で設定可能）
• 処理を開始するトリガにgitやsubversionが更新されたタイミングを簡単に設定できる
  （…git hookスクリプトを使用）
• 手動でブラウザのUIから処理を開始することができる
• Master-Slave構成が容易に構築できて、分散ビルドもできちゃう
  （…Slaveにはインストール不要！）
• ビルドマシンがWindowsでも大丈夫
  （…Javaが動けばOK）
• 複数のマシンのうち、特定のマシンでビルドする設定も簡単（…※１）
• ビルド結果をブラウザで簡単に確認できる
• ビルドした成果物をブラウザで取得できる
• Slaveノード（ビルドマシン）にgitやsubversionがインストールされていなくても、git/subversionの連携が可能！
  （…Jenkinsのプラグインを使えば）

というところです。

※１：Slaveノードに「ラベル」を設定でき、処理（ジョブ）を動作させるノードをラベルで指定可能です。 ラベルを使うことでWindowsでなくLinuxで処理をするとか、 特定のマシンを指定して処理をさせることも可能になります。

組込み用ビルドマシンをJenkinsで活用する

Jenkinsは、Master-Slave構成を取ることが出来ます。 MasterノードにはJenkinsをインストールする必要がありますが、Slaveノードにはインストールの必要がありません。 Slaveノードとして動作させるには、

• MasterノードからSlaveノードにSSHで接続ができる（NAT環境は不可）
• SlaveノードでJavaアプリケーション（Java Web Start）が実行できる。（NAT環境もOK）

のどちらかの条件さえ満たしていればよいのです。 Windowsマシンの場合は、Java Web Startを使えばOKです。特に設定は不必要で（※）Jenkinsのブラウザの設定画面から、「jlnp」とかかれたリンクをクリックするだけで起動できます。

（※：環境によってはNATのポート開放や、Firewall設定は必要です）

Jenkinsを使うのに必要なことって？

先に書いたように、「Jenkinsはちょっと賢いcrontab」です。 そのため、ビルドしたり、自動テストしたり、組込み基板に焼きこんだり、したいというならば、それを実行するコマンド／バッチファイルを作成する必要があります。 逆に言えば、コマンドを叩いてできることなら、なんでも連携できちゃいます。

まとめ

というわけで、組込み系でもJenkinsは活用可能です。どんどん活用しましょうよ！！お願いします、、、

インストール方法は他のサイトにお任せいたします…

Windows 10 のフォントレンダリングは文字が欠ける（何も改善されていない）

Windows 7, 8.1でプログラミングする場合、フォントをConsolasなど定番フォント（Inconsolata、Source Code Pro、DejaVu Sans Mono、Anonymous Pro、…）に変更することが一般的です。

しかし、これらのフォントは英数字のみ収録されているため、日本語のコメント文を表示することが出来ません。 日本語が全く表示されず空白になってしまったり、表示されても文字が潰れて読めなかったり、文字の比率がおかしくなってしまう事があります。

対処法には、大きく２つの方法がありました。
①FontLink設定する。
②Rictyのように、英字フォントに日本語フォントを合成する。

デメリットは、①の場合は、英数字以外はメイリオなどを使うようにレジストリを設定した場合、メイリオは横長なので等幅フォント風に幅を調整するパラメータ設定が難しいことです。 ②のデメリットは、windowsのフォント描画性能が悪いせいで「f」や日本語の文字の横棒が消えてしまう問題があることです。フォントサイズ20以上にすればまだ読めるのですが、 現実的に使用する10〜18ポイントでは使い物になりませんでした。 （そこでGDIPPやMacTypeのようなツールに人気がありました）。

Windows 10 (Technical Preview)ではどうか

試しにサクラエディタにてRictyの表示をしてみました。（画像はRicty Diminishedのフォントサイズ12ptです）。 しかし、残念ながらWindows7時代と同様に、文字の一部が欠けてしまいます。「語」の口の部分が几のように下が欠けています。また、英語部分も文字が歪んでいます。 これまでどおり、諦めるか、従来のツールを使うしかなさそうです。

Webで検索するとMacTypeの動作報告がいくつか見つかるため、Windows10でもMacType等のツールに頼るしかないです。

マイクロソフトは改善する予定はない

当然、フォント描画をなんとかしてくれ！という要望は世界中からされているのですが、却下されてしましました。（参照: Improve font rendering）

Improve font rendering

Anyone who's used other operating systems knows Cleartype distorts fonts to a point where some look atrocious. In general, it makes fonts too thin and jagged which makes them harder to read. Projects like gdipp and MacType try to address this issue, however, they can't provide the best result.

「他のOSに比べてもWindowsのフォントはギザギザになるし汚いよ。gdippやMacTypeだけじゃ限界があるから、改善してほしいな」という意見に対して、回答は…

Admin (Admin, Microsoft Windows) responded · Mar 26, 2015

Thank you for the great feedback. IE, Windows modern shell and Office all use grayscale. ClearType is only used in a few places on the desktop shell, not in places where people read text. This is no longer an issue starting in Windows 8.

「IEもOfficeもグレースケールを使っていて、ClearTypeは限られた場所で使っているだけだ。Windows8の時点で既に問題は解決されているから、対処はしないよ」と。

つまり、Windows10では、フォントの問題は解決されない見込みです。

MacBook Retina＋Windows10で解像度を16:10に変更する方法

Windows 10 Technical Previewが2014年10月から公開されています。

私はMac Book Pro (Retina)で無料の仮想化ソフト「Virtual Box」上にインストールして、Windows 10TPでの動作確認を実施しています。 ところが、Virtual Box上のWindows10 TPでは、標準で選択できる画面解像度は1600x1200、1280x1024、1152x864、1024x768と、画面解像度が4:3のものしか使用できません。

フルスクリーンで使用する場合はもちろんのこと、ウィンドウモードで使用する場合でも16:10や16:9で使用したいと考えるのが普通では無いでしょうか？そこで、Macbook+VirtualBox上のWindows10にて、画面解像度を自在に設定する方法を調べました。

仮想マシン上のWindowsで認識できる解像度の追加方法

Macのターミナルからコマンドを実行することで追加が可能です。

Terminalにて、VirtualBoxのインストールディレクトリに移動します。

cd /Applications/VirtualBox.app/Contents/MacOS

下記のコマンドを実行します。

VBoxManage setextradata "Windows 10 TP" CustomVideoMode1 1280x800x32
VBoxManage setextradata "Windows 10 TP" CustomVideoMode2 1440x900x32

ここでは画面解像度として1280x800と1440x900を追加しています。

「Windows 10 TP」の部分は、VirtualBoxの仮想マシンの設定名称に合わせて変更してください。「Oracle VM VirtualBox マネージャー」の画面にて表示されている名前を使用します。大文字と小文字が区別されることに注意してください。

CustomVideoMode のあとの数字は、追加する数に合わせて1,2,3,...と変更します。

最後の1280x800x32の部分で追加する解像度を指定します。横幅ドットx縦幅ドットx色数ビットの型式で指定します。

※ちなみに、このコマンドはホストOSがWindowsでも共通に使用できます。ディレクトリをC:\Program Files\...に読み替えてやってください。

どの解像度を追加すべきか

Appleの公式サイトに記載があるように、Macbookはアスペクト比が16:10で、iMacは16:9のようです。
https://support.apple.com/ja-jp/HT5266
(16:10) 2560x1600 - MacBook Pro (Retina, 13-inch, Late 2012 以降)
(16:10) 2880x1800 - MacBook Pro (Retina, Mid 2012) および MacBook Pro (Retina, 15-inch, Early 2013 以降)
(16:9) 5120x2880 - iMac (Retina 5K, 27-inch, Late 2014)

したがって、16:10または16:9の画面解像度を設定するのがお勧めです。

Macbook Pro Retinaの場合でも、フルスクリーンであれば16:10が便利ですが、ウィンドウモードで使用する場合にはDockの表示領域を考慮して16:9程度の画面解像度を追加しておくと便利です。

MacbookPro Retina(13in)は、ディスプレイの解像度は2560x1600と高いのですが、実際には擬似解像度として 1280x800ドットと同じ倍率で画面表示されます(標準設定の場合)。 そのため、縦幅800ドット以下の解像度を追加するのが便利です。

画面解像度はWikipediaにリストがありますので、そこから適当に選んできましょう。
http://ja.wikipedia.org/wiki/%E7%94%BB%E9%9D%A2%E8%A7%A3%E5%83%8F%E5%BA%A6

以上から、私のおすすめは 1280x800, 1280x720あたりです。

第二次世界大戦中の日本の暗号の話

第二次世界大戦中の暗号戦争について知りたく、本を読みました。

今日読んだのは、「暗号を盗んだ男たち」という本です。
檜山良昭「暗号を盗んだ男たち　人物・日本陸軍暗号史」光文社NF文庫 ISBN4-7698-2035-6 （定価602円＋税）

以前にサイモン・シンの「暗号解読」（上巻・下巻）を読んだことがあります。この本には、紀元前から現代のコンピュータに至る暗号史のほか、第二次世界大戦中のドイツのエニグマ暗号機や、イギリスの天才数学者アラン・チューリングについて詳しい話が記述されています。暗号をめぐり、暗号の作成と解読がせめぎ合う歴史が面白く書かれており、非常に興味深かったのです。しかしながら、日本の暗号がどうたったのかという点については分からず、旧日本軍や外務省の使っていた暗号と、その強度について知りたいと思いました。そこで探して読んだのが冒頭の「暗号を盗んだ男たち」という本なわけです。

太平洋戦争当時の日本の暗号は、大きく分けて「外務省」「陸軍」「海軍」の３つに分類されるようです。本書が取り扱っているのは主に「陸軍」についての話です。（ですので、「外務省」や「海軍」については別の本を探す必要があります。）そして、「外務省」「海軍」と「陸軍」で大きく異なるのは、陸軍の暗号強度は高く、アメリカ軍に完全解読されぬまま終戦を迎えたという点にあります（※1）。海軍の暗号は戦争が始まり一年程度で破られ、外務省に至っては海軍よりもさらに簡単な暗号しか使っていなかったと言われています。（※1：1993年の本書の記述から。インターネット上を検索してみたところ、実際には陸軍の暗号も解読されていた？という話や、1996年に米国機密文書が機密解除され解読されていた事実が判明したとの情報がありました。）

私は大日本帝国時代の暗号というのは、きっと軽視されており、ずさんな暗号しかなかったのだろうと思っていました。また、英国のように偉大な数学者を活用し、科学的に暗号を設計するという思想なんてなかったのだろうと考えていました。しかし、本書を読んでその考えが覆されました。日本も、陸軍に関しては、優秀な数学者を集めて暗号の研究を行っていたのです。

……ただし海軍と外務省の暗号は弱いものでした。特に外務省の暗号が弱かったと言われており、どうしてそんな体制のままだったのかについて、詳しく知りたいと思いました。本書では海軍や外務省については詳細はありませんが、陸軍暗号よりも海軍や外務省についての本は多く出版されているようなので、読むには困らなさそうです。

本を読んで興味深かった点をリスト化：

1. 大正13年(1924年)当時は日本の暗号は大きく立ち遅れていた。陸軍はポーランドからヤン・コワレフスキー大尉を招聘し、講義を依頼した。このとき、陸軍は海軍にも話を持ちかけ、海軍からも講義を受講したという（本書31ページ）。
   • ⇒感想：海軍・陸軍とそれぞれで暗号業務があり（当時は電信課が行っていて暗号という業務はまだないが）、縦割り感の強い中で、相互にコミュニケーションを取ろうといていることが意外に思えた。
   • ⇒132ページにも、昭和3年（1928年）ごろ陸軍と海軍が共同してアメリカ国務省のグレイ・コード（日本側はNADEDと呼称）を解読したエピソードがある。
2. 昭和11年(1936年)、第七師団暗号係将校の原久将校は、乱数を使い捨てにするという無限乱数式の暗号を思いつく。（128ページ）
   • ⇒現代でいうワンタイムパスワードの発想。コンピュータも満足にない時代に作るという点がすごい。
3. 「乱数式暗号は組み立てにも翻訳にも、骨が折れてダメだという物が入る。訓練さえ積めば、どんな型式の暗号にもまさるとも劣らず、手早く処理できるということを見せてやるのだ」（130ページ）
   • ⇒訓練により短時間で処理できるとして対処したようだ。でも実際には業務量は半端無く多く、負荷が高かった。また、海軍や外務省暗号は機械式のものだったのに対して、陸軍は機械式にすることを嫌がっていたと言われる。
   • ⇒感想：第一線の暗号まで手作業でやるのは無理があると思う。トランジスタもなくコンピュータもない時代なので難しいのだが、独自に機械を開発するなど、出来なかったのかなあと思う。
4. フィンランド公使館やイギリス大使館、アメリカ大使館に憲兵が忍び込み、乱数表の写真を撮影するエピソード。ゴミの中から裁断された書類を繋ぎ合わせる試みもある。フィンランドの乱数表は、カーボン紙により保護されており、写真を撮ろうにも開けると痕跡が残る工夫（カーボン紙を破らないと中が見えない）がされていた。開けた痕跡が残れば、当然その乱数表は使用されないので見た意味は無いし、暗号自体もさらに強化されてしまう恐れがある。（144ページ）
   • ⇒ソーシャルエンジニアリングはハッキングの基礎。大使館へ侵入し金庫を開けるなど、諜報とはそこまで日常的にやるものなのかと驚いた。
   • ⇒現代でも重要な電子部品は、物理的・機構的に分解ができないように設計されているものがある。リバースエンジニアリングのために中を開けないように、開けると物理的に部品が破壊されてしまう構造にして耐ダンパー性を持たせている。時代は違っても似たアプローチが生き続けるところが面白い。
5. 暗号解読室の女性タイピストに接近し、情報をもらう（206ページ）
   • ⇒いつの時代も親密になると情報が手に入る。仕事のための偽りだとしても、狙った人と親密になる能力があるってすごいこと。諜報は、常人には務まらない。
6. 昭和18年（1943年）ごろから、暗号理論をいっそう発展させるための教科書づくりが始まる（226ページ）
   • ⇒無限乱数が昭和11年ということを考えても、理論体系を作るのが遅すぎるように見える。
7. コンピュータもない時代なので、手作業で日本語の統計情報（かなの使用頻度や、単語の使用度数）を作成した。しかし言語学者にあったところ、それらの課題は既に学者には既知のものだった。さらに統計処理ができるパンチカードを日本生命や第一生命は所有していた。もし使用できたら作業効率は大きく異なっていたはず（230ページ）
   • ⇒時間の損失を考えると言語学者に先に聞いておけば、と悔やまれる。このようなすれ違いは何時の時代もあるものですね
8. ベルリンへ向かう道中、シベリア鉄道内で毒入りウォッカを勧められ、死亡する話（232ページ）
   • ⇒「暗号」とは関係がないけれども、「諜報」の話には、そこまでやっているのか、そんな堂々と活動しているのかと驚かされる。
9. 専門の数学者の知恵を借りるべきとして、高木貞治など、日本を代表する数学者を集める（248ページ）
   • ⇒イギリスがアラン・チューリングらを集めたように、日本も当然、ちゃんと、優秀な頭脳が活用できていた。
10. スウェーデン製のクリプトテクニックという機械を入手し、アメリカの暗号（209暗号機）を解析する話（268ページ）
    • ⇒数学的なアプローチから解析をしている。科学を用いて体系的に解析する体制があることが意外だった。旧日本軍というと、どうしても行き当たりばったりというイメージや、理性的・論理的でなく感情的・精神論的というイメージが合ったため。

何もかも憂鬱な夜に

中村文則『何もかも憂鬱な夜に』 を読んだ。

「何で、思春期ってあるんだろう」
真下は、あの時こうも続けた。
「それって、ただの言葉だろ」
あの時僕は、自分を語り過ぎた恥ずかしさから、そういう話題をわざと軽視しようとした。
「いや、あるよ。……何で人間はこの時期に、混乱しなけりゃいけないのか……、何か、意味があると思わないか？　性欲の衝動が強くなって混乱するって、言うだろ？ でも、その他に……」
「そうかなあ」
「うん、人間は、何ていうか、社会的な動物だから。社会的な生物としての、反発というか……。現在あるものとかを、浄化、新しくするために、反発しなけりゃいけないというかさ……。そういう社会的な生物の、衝動……本当はそういう役割が、神というか、DNAに刻まれてるのに、俺達はただの子供とされてる……とか」

面白かったのは、「思春期」についてのこの回想シーンだ。思春期のとき、思春期ってなんなんだよってモヤモヤ思案する。そのモヤモヤが表現されていて見事だと思う。思春期というもの自体もDNAに刻まれているのかもしれないって気がしてくる。

この小説では、主人公が30歳弱になるまでが描かれている。アラサーだとか、「三十にして立ち、四十にして惑わず」などという三十路という年齢だけど、そんな年齢になってもきっと”思春期”の気持ちって続いているんだろうなあと腑に落ちるところが気持ち良かった。

性欲の衝動が強くなって混乱するってことが減っても、代わりに出世欲だとか結婚欲だとか、いろんな欲によって衝動が強くなって混乱するってことはままあることだと思う。

本小説のように30歳間近となっても、 あるいは神聖かまってちゃんの「23歳の夏休み」という曲のように23歳であっても、 思春期のようなモヤモヤはなんだかずっと残るのかあという気がする。

大阪・新大阪から米原へJRで行く最安手段は？

移動する機会がありましたので検討しました。検討結果は最後にまとめています。

JR大阪駅からJR米原駅へ、また、JR新大阪駅からJR米原駅へ行く場合の価格について比較。彦根・長浜へ行く場合も同様に切符を選択します。 （2015年1月現在：消費税8%含む）

在来線の場合（大阪から米原まで新快速で所要時間は83分）

（1）正規運賃

何も考えずに切符を買うとこの値段になります。 大阪→米原、新大阪→米原はともに片道運賃1940円です。

（2）区間を分割して購入

大阪から京都までは特別運賃が設定されているため、大阪→京都と京都→米原と切符を分割購入することで料金が安くなります。

分割すると合計で1700円となり、片道▲240円の節約になります。 （大阪→京都：560円、京都→米原：1140円）

（3）昼得切符を購入

使用できる時間帯に制約のある回数券です。 大阪から京都までの切符を昼得切符にすると、12回分で3800円なので1枚当たり317円。 合計すると片道一回あたりが1457円相当となり、片道▲483円の節約です。

土曜・日曜・祝日の休日ダイヤの場合は終日、昼得切符が利用できます。 また平日の場合も特定の時間帯（朝10時から夕方17時）であれば、昼得切符が利用できます。 ただし、切符を分割する場合は、乗車するときと降車するときの両方が昼得切符の時間帯である必要があります。

（4）青春18切符を購入

春・夏・冬の期間限定で使用できる1日乗り放題の切符で、5回分で11850円です。 したがって、1回あたりでは2370円です。 日帰りで往復する場合、正規料金は1940円×2=3380円なので、往復で▲1510円の節約です。

乗り放題切符なので、大阪駅や米原駅からさらにJRに乗る場合はさらにお得度が増します。

（5）企画切符を購入

季節によっては関西1dayパスが発売されます。 JR西日本の大阪近郊のほとんどの路線に乗車できます。

指定区間の1日乗り放題で3600円です。 日帰りで往復する場合、正規料金（3380円）に比べて、往復で220円損になります。

大阪駅から神戸・和歌山方面へさらにJRで移動する場合、 米原駅から長浜方面へさらにJRで移動する場合、 なんども乗降する場合には企画切符のメリットもでてきます。 往復するだけであれば、金券ショップの価格を考慮すると利用シーンはないでしょう。

（6）参考：金券ショップでの実売価格

昼得切符の場合、片道1500円程度で販売していることが多いようです。

青春18切符や昼得切符はバラ売りはしていませんので、1往復しかしないのであれば、大抵は金券ショップのほうが安くなってしまいます。

新幹線 自由席の場合（新大阪→大阪の所要時間は36分）

新大阪→米原は所要時間36分（在来線より約45分速い）
大阪駅から米原駅の場合は、在来線(4分)と乗継時間を考慮すると約50分（在来線より約35分速い）です。

（1）正規運賃

新大阪→米原で購入：片道4420円

（2）区間を分割して購入

新幹線は一駅区間だけの乗車の場合、少し運賃が安くなります。あらかじめ分割して購入しておくと安くなります。なお、乗越清算の場合は正規運賃と同じになるため、あらかじめ買っておくところが重要です。

大阪・新大阪→京都、京都→米原で購入：（1420円＋2220円＝）片道3640円。片道▲780円の節約です。

（3）企画切符を購入

「シャトル切符」という企画切符がJR東海から発売されています。 ただし発売は米原の東隣の駅の醒ヶ井駅〜大垣駅までの各駅となります。 また発売駅から新大阪駅までの往復切符で、途中下車ができないということになっています。

醒ヶ井から新大阪までが往復で4940円です。別途新大阪から大阪までの在来線 片道160円を買うとすると、大阪駅から醒ヶ井駅まで往復で5100円になります。

①企画切符の条件として、米原→新大阪、新大阪→米原の順でしか乗車出来ません。そのため、新大阪→米原、米原→新大阪と乗る場合には向きません。切符の有効期間は二日間なので、２日連続で大阪から米原へ向かうのであれば、使うことも出来ますが…。

②途中下車ができないので、本来なら米原→醒ヶ井、醒ヶ井→米原と往復する必要があります。よって、米原〜醒ヶ井の200円の運賃と、往復10分＋乗換待ち時間が必要になります。と、すると、所要時間の短縮効果が薄くなり、所要時間と金額を考えると在来線が優位です。米原から大垣までの東海道線は本数がかなり少ないので、新幹線との乗継を考えるとロスが多くなります。

③米原〜醒ヶ井の200円運賃だけ買って、米原〜醒ヶ井を往復して乗ったことにすると時間的にはメリットが残ります。ただし、私にはこれが合法なのかはわかりません、旅客規則やシャトル切符の条件を確認する必要があります。

④醒ヶ井〜新大阪の往復切符なので、醒ヶ井から米原区間の権利を放棄したことにできないのでしょうか？実際、インターネットを検索すると米原から乗車したり、米原で降りている人がいるようです。これが認められているのかは私にはわかりませんでした。途中下車と違って、残りの米原〜醒ヶ井を乗るわけではないので問題ないのでしょうか？

（4）金券ショップ

この区間は金券ショップでの取扱量は少なく、したがって割引額もほとんどありません。

まとめ

在来線と比較すると、新幹線は往復70分短縮を3000円で買う、というコスト感覚になりそうです。

結局、在来線で昼得切符を活用するのが一番コストパフォーマンスが良さそうです。 大阪駅からなら大抵は座れますからね。

技術英文の書き方〜仕様書を英語にするにはどうしたら良いのか？

エンジニアであれば、英語で技術文書を書く必要に迫られることもある。近頃の会社では「オフショア」だのと言って、海外の会社に英語の仕様書を提示する必要も出てきているのではないだろうか。 さらに悪いことに、技術文書ならではの特有の表現とか、特有の文法があるに違いない。

私は英語が苦手だ。英語を読むくらいならC言語を読むほうがマシだ。中学英語までの平易な英語でなければ書けないし、単語もほとんど分からない。

なので、どうやって技術英文を書けばいいのかを考えてみた。結論からいくと方法は、「専門の本を読む」「多言語対応ソフトウェアを参考にする」となる。

特有の言い回し

コンピュータならではの特有の単語というものがある。 幸いカタカナ語が多いので、「ダイアログ」「スワイプ」など、大抵の用語はそのまま英語にできそうだ。 だけども、「名前をつけて保存」のような変化球には対応がしづらい。

UIに関する言い回しは、特有の専門語となっているけれども、日本語と英語が一対一に対応しやすい。

私のおすすめする、対応関係を調べるため手段は：
(1) 英語版で使ってみる。
(2) OSSなどの言語切替用の翻訳ファイルを参照する。
という二つの手段だ。

(1)は当たり前で、使ってみればどれとどれが対応しているのかがすぐわかるのだ。AndroidやiPhone、LinuxといったOSは設定で簡単に言語を切り替えることができるし、Webサービスでも世界展開しているものを活用すると雰囲気がわかってくる。

(2)は(1)の応用である。他言語化されているオープンソースであれば、①そもそも他言語化されているような有名プロジェクトであれば、翻訳の質も高い、②翻訳されたファイルを比較しやすい、というメリットがある。

ではどうやって翻訳ファイルを検索すれば良いのか。 これにはGoogleの拡張子検索を活用するのが良い。 gettextというライブラリを使って多言語化している場合、 翻訳ファイルは拡張子が「po」となる。したがって、Googleで「filetype:po」をキーワードに付加してやれば良い。

「名前をつけて保存　filetype:po」として検索すれば、すぐに対応する英語が「Save As」となることが分かる。 ⇒(google検索結果を見る)

文章の書き方

仕様書の書き方には特有のルールがある。日本語の仕様書だって、小説や新聞のような文体では記載されないのだから、英語でも同じと考えることに不思議はない。

こういうものは本のお世話になるのが良い。

おすすめできるほど沢山の本を読んだわけではないのだが、私が手にとって役に立ったものを紹介したい。

「技術英文の正しい書き方」佐藤洋一（著）、オーム社、2003年、ISBN4-274-19706-9

良い点は、例文の数が60個もあること（コンピュータ関連に特化したものも含む）。そして、それが今すぐ使える内容で、例文の英語を少し変えればそのまま仕様書に適用できるところだ。例えば、こんな例文が記載されている。

[基本例文(33)]
文字列が長い場合には、それぞれの文字列（CALCULATIONやTRANSFORMATIONなど）にシンボル（＊や＊＊など）を割り当てておくことができるので、例えば、＊という記号を入力してEnterキーを押すと、最初の文字列（CALCULATION）を入力したのと同じになります。

[基本例文(50)]
DELETEコマンドの対象となる画面が存在しません。

→ No screens exist for the DELETE command

この例文に対して、好ましくない英文例と、それぞれの問題点が日本語で指摘される。必要ならば、日本語の文章の曖昧な点を指摘した上で、望ましい英語例文が記載されているところが分かりやすいと思う。

仕様書にありそうな文章に対して、英語例文がある。こういう本を探していた。

C言語で処理系依存なコードを書く

プログラミングにおいては、相当な理由がない限り、わざわざ処理系依存なコードを書くことはありません。仕事なら「このコーディング規約に従うこと」「この静的解析ツールで警告をゼロにしろ」「MISRAガイドラインに従う」だの、厳しく言われるかもしれません。でも趣味の世界ならなんでもあり、やりたい放題できます！

ということで、処理系依存なコードを沢山書いてみましょう。と、突然言われてもなかなか処理系に依存するコードは出てきません。そこで、C言語の規格を参照して、「処理系依存」とされているものを順に書いてみましょう。そして、コンパイラによって動作が本当に違う！って確認していきたいと思います。

処理系依存なコードとは

2015年現在では、C言語の規格としてはC99（ISO/IEC 9899:1999、JIS X 3010:2003）やC11（ISO/IEC 9899:2011、対応するJIS規格は未発行）があります。 C99であればJISから日本語で規格を読むことができます（ただしWindows環境に限る。LinuxやMacでの閲覧は出来ませんでした）。 現在最新のC11ではJIS規格はまだありません。ISO規格の閲覧は有料となるため、C11では最終ドラフトのN1570で代替することにします。

それでは規格の「Annex J (informative) Portability issues .」 （JIS規格の場合は「附属書J.可搬性」）を参照して行きましょう。何ページにも渡って、下記の分類で「べからず集」が記載されています。

• J.1 Unspecified behavior
• J.2 Undefined behavior
• J.3 Implementation-defined behavior
• J.4 Locale-specific behavior
• J.5 Common extensions

今回はこれから幾つかピックアップして実行してみます。使用するコンパイラはgccとclangです。バージョンはgcc 4.9.2とclang (Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn))で実行しました。

J1: Unspecified behavior

— Whether two string literals result in distinct arrays (6.4.5). ...文字列リテラルが同じポインタになるかどうかは処理系依存

#include 

int main()
{
 const char* str1 = "hello, world";
 const char* str2 = "hello, world";
 printf("%s str1 = %p, str2 = %p\n",
  (str1==str2 ? "[Match]" : "[Different]"),
  str1, str2
  );
 return 0;
}

これを実行すると「Match」と表示されるか「Different」となるかは処理系次第のようです。GCCもClangも、デフォルトのままコンパイルすると「Match」となりました。文字列リテラルを最適化して配置するのがデフォルトなのですね。

— The order in which the function designator, arguments, and subexpressions within the arguments are evaluated in a function call (6.5.2.2). ... 入れ子になった関数の呼び出し順序は処理系依存です。

#include 

int f(int x, int y)
{
 printf("f(%d, %d)\n", x, y);
 return x+y;
}

int g(int n)
{
 printf("g(%d)\n", n);
 return n;
}

int main()
{
 int a = f(f(g(1),g(2)) , f(g(3),g(4)));
 printf("a = %d\n", a);
 return 0;
}

これはGCCとClangで実行順が異なりました。GCCでは一番右側から実行されていきます。 「 g(4) g(3) f(3, 4) g(2) g(1) f(1, 2) f(3, 7) a = 10 」
しかしClangでは、一番左側から実行されていくようです。 「 g(1) g(2) f(1, 2) g(3) g(4) f(3, 4) f(3, 7) a = 10 」 面白いですね。

— Whether or not a size expression is evaluated when it is part of the operand of a sizeof operator and changing the value of the size expression would not affect the result of the operator (6.7.6.2).

#include 

int main()
{
 int a = 1;
 size_t b = sizeof(++a);
 printf("a=%d. \n", a);

 a = 1;
 size_t c = sizeof(int [++a]);
 printf("a=%d. (will be 2)\n", a);

 a = 1;
 size_t d = sizeof(int [++a % 1 + 10]);
 printf("a=%d. (unspecified: 1 or 2)\n", a);
 printf("b=%zd, c=%zd, d=%zd\n", b,c,d);

 return 0;
}

sizeof演算子に式を与えた場合の動作で、可変長配列について規定したものです。++a % 1 + 10は++aを実行してもしなくても結果は変わりません。ちなみにgccもclangもともに1,2,2という結果でした。

J2: Undefined behavior

J3: Implementation-defined behavior

J4: Locale-specific behavior

j5: Common extensions

続きはまた次回。

おわり

分量がおおいので、今回はここまででおしまいです。

（英語力の問題もあり、誤解をしていたらごめんなさい）

追記

追記：下記サイトにて未定義動作や処理系依存のコード例と、その回避方法が記載されていました。 https://www.securecoding.cert.org/confluence/display/seccode/DD.+Unspecified+Behavior;jsessionid=9AFACDECE35236C29B02BC507735CF34 https://www.securecoding.cert.org/confluence/display/seccode/CC.+Undefined+Behavior

TV感想：エンジニアとして生きる根幹

新年から＜エンジニアとして生きるために必要な信念とは何か？＞、＜エンジニアとして根幹を成すものはは何なのか＞を 録画していたNHKの番組をきっかけに考えることになりました。 番組中で凄く良い言葉がありましたので、その内容を引用します。

NHK2015年1月12日放送「プロフェッショナル　仕事の流儀」第251回 ”振り切る先に、未来がある

http://www.nhk.or.jp/professional/2015/0112/index.html

以下は、NHK放送内でのマツダ・常務執行役員　パワートレイン開発担当・人見光夫氏（60）の発言からの引用です。

試すときは大きく振って試してくれ。じわじわと　こつこつとやったら人より新しい発見なんて絶対できないので、大きく振りなさいと。だって誰も行ったことがない世界へ行ったら何が起きるかですよ。

ブレイクスルーできそうな改善をひとつ、部下が見つけた時には、

目標はここまでいけば達成できるという姿をつくって その実現のアイデアを出して欲しいんだけどね。そういうのを見ると「あとここやればいい」と他のところをおやすみするから

いけるのがここと分かって、ここでやめた言う必要はないんでね。遠慮したらいかん。まだ諦めちゃいかん。必ず目標を目指そうよ。

エンジニアとして挑戦する姿勢が大事だということでしょう。壁にぶつかった時にひとつ光明が見えてくると、ついついそのアイデアだけを見てしまいがちですが、トータルとしての目標を達成するためにはひとつの光明だけではなくて、まだまだブレイクスルーが必要になってくるでしょう。そこで甘えてしまうのではなく、さらにさらにと貪欲にアイデアを試すっていうのは、追い込まれれば追い込まれるほど難しいのが現実ではあると思います。でもどうせやるなら”大きく振って”やりきってやろうじゃないか、とそう勇気付けられました。

人見氏はエンジンの技術者でした。私はソフトウェアのエンジニアです。要件定義をしたり、仕様書を書いたり、ソースコードを眺めたり、その試験をしています。そんな環境の中で、「大きく振った」アイデアとはどういう内容になるのでしょうか。とにかく安く短納期で品質を、という業界のなかで、大きく振ったアイデアとは何か？をまず考えていきたいと思います。

（開発は）一斉にやったら大きい会社の方が勝つでしょうけど、その前に何をやるかというところでは大きいも小さいもなくて、そこで考えが勝っていれば　そりゃ勝てることだってあるでしょう

絶対自分が（アイデアを）思いつく。これが一番のプライドです。次は人のものも否定しない。これも技術者としてのプライドがある人間はそうすべきだと思いますがね」

これは本当にその通りでしょう。方向さえあっていれば、あとは突き進めば良いだけ。方向を合わすことが一番難しいです。方向を合わすためには、「あるべき姿は何か」そして「現状はどこにいるのか」が分かっていないといけません。理想の姿も現状の姿も、周囲と相対化して比較しないとなかなか見えてきません。だからこそ、エンジニアなら感度を高くしていくことが大事でしょう。

アイデアは出すのに資本はいりません。考えるだけならタダ。恵まれない環境の小さな小さなやつだって、頭をとにかく使えばきっと勝てるはず！

明日からまた頑張ろう、と思える番組でした。

ブログ、はじめました。

2015年、新たにアウトプットする場として、blogを始めることにしました。

主にコンピュータプログラミングについて書きたいと思っています。

よろしくお願いします。