学童のプログラミング教室で、Minecraft on Scratch から子供の興味を引きはがすべく、micro:bit を 5個（増税前、消費税8%の駆け込み）購入しました。

実はスイッチサイエンスさんはキャッシュレス還元に対応したそうなので、10/1 以降に購入したほうがお得だったわけですが。まあ、いいや、勢いで送料無料になる1万円まで大人買いです。

※ああ、結果だけ欲しい方は、一番最後にジャンプするといいです.

学童で子どもに試してみる

プログラミング教室をやっている学童に先に請求してもよいのですが、ここは実験も兼ねて自腹で購入。うまくいけば後で、欲しい子には2,000円也で購入してもらうか、学童に請求を上げるかというところなのですが。

あえなく「玉砕」です。

まず、数あるプログラミング教室の中で、私が行っているところは、

• 小学3-6年生が10人ちょい雑多に集まっている感じ。
• 予算の関係上、中古 ノート PC の Windows 7 を使っている。
• 場所が共有スペースを使っているので、デスクトップ PC は置けない。
• 有線 LAN が使えず、無線 LAN（私物の Pocket WiFi）を使っている。
• ノート PC に Bluetooth が付随していないものが多い。
• 中古のノートPCなので、USB が 1個しか生きていないものが多くて、USB ケーブルのマウスと付け替えないといけない。
• そもそも、micro:bit(mbed) への HEX ファイルのドラッグ＆ドロップが子供には難しい。

このプログラミング教室は、3年前から始めたのですが、プログラミングを教える…ってのは雑多な環境では難しかったので、「Scratch で遊ぶ」にシフトしました。いは、Scratch で作られているゲームならば、なんでも ok ってことで、ファミスタもどきとか青鬼もどきとか、いろいろ流行りがあって、今はマインクラフトもどきなのです。
ちなみに、ゲームばかりやっている子ばかりではなくて、Scratch でゲームを自作している子もいます。

• ゲームを自作している子には、適宜質問に答える＆適宜手伝う。
• ゲームをしている子は、攻略法は友達同士で話し合ってね

というルールでやっています。学童の目的として「安全に子供を預かる」が有線なので、プログラム自体を教えるってのは二の次なのです。とはいえ、漠然と遊ばせるだけはつまらないので、毎回プリントを配るし（1回300円也を徴収しているので）、それなりに「パソコンに慣れる」ことを目的としています。

と、いう状況はさておき、プログラミング環境としてはあまりリッチな環境ではありませんが、そこは工夫次第というところです。

Scratch から micro:bit を操作する

micro:bit を操作する方法は2種類あります。

MakeCode を使ってプログラミング

https://makecode.microbit.org/

こんな感じでブロックを使ってプログラムをして、micro:bit に流し込みます。ダウンロードした後に HEX ファイルをドラッグ＆ドロップする方法と、あらかじめ micro:bit とリンク（たぶん、BLEを使っている）させておいて「ダウンロード」ボタンを押したら直接流し込んでくれる方法です。

手元の PC でやると、この自動流し込みが便利なので操作的にはさほど気にならないのですが。Bluetooth の付いてないデスクトップPCとか、古い Windows 7 のノートPCだと結構な手間です。

あと、Scratch に慣れていると、この

• プログラムをコンパイルして、マイコン（micro:bit）に流し込む

という流れが難しかったりします。そのあたりは、電子工作で Arduino を使っていれば慣れるので（というか慣れないといけない）ので、それはいずれやるつもり。

Scratch 3.0 から直接 micro:bit を操作

https://scratch.mit.edu/

もうひとつ、Scratch 3.0 の拡張機能を使う方法です。Scratch 3.0 では、あらかじめ micro:bit に scratch-microbit-1.1.0.hex なファームを書き込んでおいて、BLE 通信をしながら操作する方法です。これだと、いちいち micro:bit に書き込む必要がなくて、Scratch の操作だけで micro:bit を扱えます。

micro:bit と BLE 通信で連携をするので、

• micro:bit のAボタンを押したら、猫に喋らせる
• Scratch 猫をクリックしたら、micro:bit の LED を光らせる

という動きが簡単にできます。これだと、物理的なものを「プログラミングで操作する」というのが直感的にわかっていいです。内部は、ややこしいことになっているのですが。

Scratch で micro:bit を操作するためには、条件があって、

• BLE 接続できること
• Scratch Link を動かしておくこと

があります。micro:bit と BLE 通信をするので、Buetooth が必要なのはいいのですが、さて、Scratch Link がちょっと癖ものなのです。
Scratch Link の動作条件が、

• Windows 10 以降
• macOS

ということになっていて、Windows 7 では動かない。何故？ってことになります。

scratch-link
https://github.com/LLK/scratch-link

理由は、Scratch Link のコードを見るとわかります。Windows の場合、UWP で使われている Bluetooth モジュールを使っていて、これが Windows 10 以降しか入っていないんですよね。Windows 8 が出た頃に、BLE 通信が流行った時代があって、そのときに Windows 7 で動かそうとして悪戦苦闘した覚えがあります。結局 BLE 通信は無理なので Bluetooth のシリアル通信にしましたが。実は、Scratch Link 内部ではシリアル通信も対応しているのですが、インストール環境が Windows 10 以降になってしまっているので、これでも Winodws 7 は使えないのです。まあ、そのときは自前ビルドをするわけですが。

Scratch 3.0 – Scratch Link – micro:bit の関係を紐解く

Scrach 3.0 のコードは Github で公開されているので、

• LLK/scratch-gui: Graphical User Interface for creating and running Scratch 3.0 projects.
• LLK/scratch-vm: Virtual Machine used to represent, run, and maintain the state of programs for Scratch 3.0
• LLK/scratch-link: Device interoperability layer for Windows and MacOS

の3つから調べることができます。scratch-microbit-1.1.0.hex のコードは見つからなかったのですが、まあ、これは BLE のペリフェラルなところなので省略してもokでしょう。

ざっと、調べたところこんな感じです。

Scratch on Browser 
 WebSocket
 ^
 | JSON-RPC
 v
 WebSocketServer
 JSONRPCWebSocket
 + didReceiveCall
Scratch Link 
 BLESession
 + DidReceiveCall
 + OnValueChanged
 ^
 | BLE GATT 
 v
 BLE
micro:bit

• Scratch 3.0 で WebSocket を使っている
• Scratch Link は WebSocketServer で待ち受け
• Scratch 3.0 – Scratch Link の間は JSON-RPC で通信
• Scratch Link と micro:bit は BLESession で BLE 通信

そうなると、Scratch Link の JSON-RPC で受けているところを適当に WiFi に切り替えてやって、ラズパイや適当な Windows 10 を挟み込んだプロキシを作ればいけそうですね。

と思って、Scratch Link のコードを .NET Core で書き換えようとしたところ、Scratch 3.0 -> Scratch Link な URL ってどうなっているのか？と思い至りました。いやいや、WebSocket を使ったことがなかったので。

Scratch Link – Japanese Scratch-Wiki

を改めてみると、『そのため、Scratchはlocalhostに直接アクセスできないため、device-manager.scratch.mit.eduに接続する。』という一文があります。たしかに、scratch-vm のコードを検索すると、この URL が書いてあって、直接ローカルなPC（localhost とか 127.0.0.1 とか）には接続していないんですね。

なるほど！WebSocket って localhost が使えないのか！ってことでした。
思い込みで、localhost しか使えないのかと思っていたのですが、実は localhost「は」使えないという落とし穴が（苦笑）あったのですね。
なので、Scratch 3.0 は、拡張機能で WebSocket を使うたびに device-manager.scratch.mit.edu を呼び出して DNS で 127.0.0.1 を返して貰っています。

hosts を変更する

となれば、話は簡単です。
いちいち、ローカルホストに接続するために device-manager.scratch.mit.edu を呼び出しているということは、他の PC を呼び出したい場合は device-manager.scratch.mit.edu を通す必要がない、ということです。

なので、実現したい環境として、

• Scratch 3.0 が動いている Windows 7
• micro:bit と接続している BLE ありの Windows 10

という別々の環境を作った場合、Windows 7 から Windows 10 の Scratch Link への通信に切り替えてやればよいわけで、

• Windows ならば、C:\Windows\System32\drivers\etc\hosts
• Linux ならば /etc/hosts

を書き加えます。

192.168.1.28 device-manager.scratch.mit.edu

「192.168.1.28」なところは、Windows 10 のある PC の IP に書き換えてください。こうすることで、device-manager.scratch.mit.edu への呼び出しが偽装されて、micro:bit に繋がっている Scratch Link（Windows 10 あるいは macOS） へ接続されます。

2以上繋がっている場合は、こんな風に並ぶので名前で使い分ければよいでしょう。

scratch-vm のほうを書き換える

なお、もう一つの方は、scratch-vm にある WebScoket の接続先を書き換えます。

scratch-vm/scratch-link-websocket.js at develop · LLK/scratch-vm

scrach-gui/vm/link をあれこれやっているのは、自前でオリジナルなブロックを創ったり、Android の Firemate に繋げたりしたいので、こっちのほうはいずれ試してみる予定。

台風が近くまで接近しているので、非常に眠いので眠気覚ましに。

世の中は任天堂スイッチの世界なので、Joy-Con で操作することが多いと思うのですが、Joy-Con はちょっと高い。正規版だと 8,000円位しますね。互換機？（バイブレータがないらしい）の場合だと、もうちょっと安いみたいなのですが、まあ、手元に Wii コントローラがあるし、試しにつなげてみようというところです。

以前、ラズパイに Wii コントローラをつなげようとしたとき、古い Wii リモコンだとうまくいくのですが、新しめの Wii リモコンプラスだとペアリングがうまくいきません。Bluetooth 側のプログラムを改変すれば、接続はできるのですが、それがいいのかどうか不明だったので放置状態でした。

bluetoothctl と xwiimote を使う

ラズパイ3 に xwiimote を入れて使います。
ラズパイ3 の Raspbian には既に bluetooth に接続するための bluetoothctl があります。

sudo apt install bluez

した後で

bluetoothctl

を実行します。プロンプトが出るので、

power on
scan on

で接続先の Bluetooth 機器を探します。

このときに、Wii リモコンの裏側の赤いボタンを押して、接続待ち状態にしておくと、Nintendo RVL-CNT-01-TR のデバイス名が出てきます。ここに出てくる ID を使って、

pair 9C:E6:35:04:51:4A
connect 9C:E6:35:04:51:4A
trust 9C:E6:35:04:51:4A

して接続をします。

これで、Bluetooth 接続状態にしておいて、xwiishow コマンドを使います。

sudo apt install xwiimote 

してインストールした後に、

xwiishow 1 

で Wii リモートの操作画面を表示させます。

A,Bボタンの操作や、加速度センサー、IRセンサーの値が表示されています。

詳しい使い方は、下記を参照

XWiimote – ArchWiki

どうやって Wii リモコンの処理ををするのか？

Linux なのでデバイスはファイルとして開かれるので、/sys/bus/hid/devices で調べられるそうです。

pi@raspi3:~ $ ls /sys/bus/hid/devices
0005:057E:0330.0002
pi@raspi3:~ $

たぶん、xwiishow のあたりから API が出てると思うのだけど、これは後で。

コードがここで公開されています。
GitHub – dvdhrm/xwiimote: Open Source Nintendo Wii Remote Linux Device Driver https://github.com/dvdhrm/xwiimote

PC の場合は、WiimoteLib というライブラリがあるそうです。

Siv3DでWiiリモコンを使う – Qiita

Windows からラズパイにリモート接続する方法はいくつかあって、

• VNC を使う
• Xming を使う
• リモートデスクトップを使う

という方法があります。昔から、定番は VNC でラズパイ側に VNC サーバーを起動させておいて、Windows で VNC Viewer を使うという方法ですね。

比較的安定しているし、LAN 内でも結構遅くて苦痛なのですが、画面全体を操作する場合は仕方がないということで使っています。

Xming のほうは、Windows 版の X サーバーを入れて操作する方法で、Xming X Server for Windows 日本語情報トップページ – OSDN かなりバイナリが古いのですが、Windows 10 上でも軽快に動きます。xterm だとか、X Window に対応しているソフトをラズパイ側に入れておくと動きます。

で、実は、昔から Windows のリモートデスクトップを使う方法があったのですが、結構遅いし、日本語入力が打てないとかいう問題がありました（ラズパイ側に wnn とか入れればいい？）。ですが、今だと軽快なスピードで動きます！何が変わったのか？単に CPU スピードが速くなったのか？
少なくとも VNC Viewer だと遅くて辛いのですが、リモートデスクトップだと全然問題ありません。

インストールは簡単で、ラズパイ側に xrdp を入れるだけです。

sudo apt install xrdp

Windows からリモートデスクトップで接続すると、xrdp のログイン画面が出ます。

session は X.org のままにしておいて、ログインすれば ok です。

画面はちょっともたつきますが、設定とか Scratch ぐらいならば全然 ok ですね。ssh でつなげてコンソールで設定するのもいいんですが、GUI があると楽です。

特にラズパイの場合は、HDMI 接続せずに LAN ケーブルつけて放置（あるいは WiFi 接続のみ）することが多いので、ちょっとした GUI の設定が必要なときに便利です。

ちなみに、Ubuntu にも xrdp を入れると普通に接続できます。

Ubuntu（うちのは 18.04）に xrdp を入れるだけでリモート接続できるのでお手軽です。Ubuntu のほうは日本語入力が使えます。VSCode も軽快に動きます。

うちの仕事の環境は、基本 Windows で揃えているのですが、一番の難点は Windows Update です。別口で Windows Server を使えばいいのでしょうが、これは私にはオーバースペックだし、そもそも別口でサーバーを揃える位ならば、Linux を使える環境を用意したほうがよかろう、ってのが主旨で、

サブ開発環境を Ubuntu 18.04 で準備する | Moonmile Solutions Blog

去年の夏に Linux 環境を整えました。仕事柄 Visual Studio が必須なのと、仮想環境がワンセットになっていないと辛い（Windows 7 とか、別の Linux 環境とか）ので、メモリを増加させて相乗りをさえていた訳ですが、月１に訪れる「Windows Updateによる再起動」が辛い。

会社で使う業務PCならば、帰宅時に電源を落とすというのが普通なのでしょうが、

• 機械学習させているときに、数日間廻しっぱなしにする必要がある
• バックグラウンドで仮想環境（VMWare）が常に起動している
• バックグラウンドで Docker が常に起動している

ということになると、不意にやってくる Windows Update による再起動は結構な痛手です。暫くはタイミングを見て手動で再起動（VMWareも手作業でスリープさせる）というのを繰り返していたのですが、去年の春あたりから「勝手に再起動」が頻発してしまって、あまりに耐えかねて Linux マシンを用意しました、ってのが去年の夏です。

構成などは、さきのブログを見て貰うということで、1年間 Linux サーバーとして動作させた感想をメモしておきます。

なんといっても再起動しないのが良い

目的が「再起動させない」なので、Linux マシンは24時間運用です。電力的にどうか？という話しもありますが、私の場合は仕事場が自宅なので、利用時間はこれで良いのです。
単純な NAS や自宅 WEB サーバーならば、Raspberry Pi でも良いのですが（あるいは Orange Pi などの互換機でもOK.），仮想環境として VMWare を動かすのが前提だってので、通常の PC を用意します。メモリはそれなりに潤沢に置いて、CPU はそこそこ、直接画面を見ることはないのでグラフィック関係はオンボードのものを利用しています。

Linux サーバーには普段はモニタはつけていなくて、VNC で接続します。実は VNC での画面更新は非常に遅いので、VSCode などを使った編集が難しいのがデメリットなのですが、そこは Telnet でつなげて vi なり emacs を使います。

業務上、常に VMWare 上で Windows 7 が動作しています。裏で見えているのが保守しているシステム（旧顧客環境のため Windows 7 が稼働している）、手前にあるのが VSCode ですね。絵文字もカラーで綺麗にでます。ただし、VNC 経由だとキーボードの反応とかが極めて遅いので、基本は、

• telnet で vi を使ってコードを書く
• WinSCP を使ってファイル転送
• samba を使って Windows とファイル共有

ってことをやります。VMWare 上で動いている Windows 7 は、そのままリモートデスクトップで接続ができるので、VNC を介在せずに、業務 Windows 10 – Windows 7 間で動かせるので、通常の PC のように動かせて便利です。

Linux マシンは不意に再起動しないので、仮想環境がいきなり倒れたり、機械学習用のプロセスが倒れてたりすることはありません。まあ、実際のとこれは適度に apt upgrade するのですが、面倒？なのもあって、ここ半年ぐらいはそのままです。旧来の意味でのサーバーとしての利用ですね。

インストールするソフトウェアは最小限に

この Linux サーバーは外部に公開している訳ではないので、セキュリティリスクが低いのですが、一応、インストールするソフトウェアは最小限にしています。
最小限とはいっても、適当に動かしたいものを入れるので、

• mysql
• PHP
• apache
• java
• dotnet

あたりが入っています。あまりたくさん入れると、再構築が面倒なのと、バージョン違いのあれこれで悩むことになるので、少な目にしておきます。
実際の業務サーバーになると、メールなりFWなりの設定が出てくるわけですが、社内（個人内）で使うものなので、ややこしい設定は入っていません。その分、再構築は楽なのです。

逆に、なんらかのテストをしたいときは、VMWare か Docker に押し込めます。VMWare にしても本格的な運用ではなく、実験的に使うことが多いので既存のものをクローンして使うだけで済みます。HDD の容量を見て、適当なタイミングで仮想環境は消してしまいます。

Ubuntu なので snap が使えるのですが、あまり使っていません。仕事柄ソフトウェアのバージョン違い、OS のバージョン違いを確認することが多いので、snap を使うよりも、VMWare で用意してしまったほうが楽なのです。

なお、仮想環境は HDD の容量を気にしてあれこれと消したりするよりも、2T HDD を買ってしまって、さっくりと増量してしまったほうがベターです。メモリも仮想環境用に 32GB まで増量させています。本当は 64GB に上げたかったのですが、結構な値段になってしまったのでランクを落としました。それでも大丈夫なのは、

• 業務用 PC で Windows 10 で 32GB
• Linux で Ubuntu 18.04 で 32GB

に分けられたからですね。業務用 PC のほうでは仮想環境を動かすことがなくなった（実際は、アズールレーンが BlueStacksで動いていますがｗ）ので、32GB でも十分になりました。

クラウド環境でもいいのでは？

自宅 Linux を作るよりクラウド環境を要したほうがいいのではないか？と思うこともあります。実際、VPS を借りたとしても、年間2万円弱でそれなりの Linux サーバーを借りられます。手元の Linux サーバーは 13万円 + 電気代がかかっているわけで、実は外部で借りたほうがランニングコストは安くなるでしょう。おそらく、VMWare 等を使って仮想環境を作らないのであれば、クラウド上に Linux や Windows を入れてしまったほうが手軽です。問題は、回線スピードなのですが、今となっては光回線が普通になってきているので、Windows 10 からリモートデスクトップで繋げても、そこそこの画面更新スピードで動くでしょう。

なので、最近となっては全面的にクラウドに持って行ってもよいのですが、クラウド環境を使う最大のデメリットは、

• ビックデータや画像データなどの大量のデータを送り出すのに時間が掛かること

です。光回線の場合、下りのスピードは早いのですが、上りのスピードが遅いことが多々あります。なので、検索のためのデータとか、何か加工するためのデータをクラウド上にアップロードするときにかなりの時間が掛かります。転送量の価格もあるのですが、時間が掛かるのが大問題です。

手もとの Linux サーバーだと、HDD を USB でつなげるとか、社内ネットワーク越しにコピーするとかで相当にスピードでコピーができます。一番早いのは、micro SD カードか外付けの SSD にコピーして USB 3.0 経由ですね。
なので、業務的にデータの秘匿性が高くはなくても、オンプレミスで Linux サーバーを運用させるメリットはそれなりにあるわけです。まあ、オンプレミスの場合には、SE 役が必須なわけですが…ひとまず、自宅 Linux の場合は自分な訳だし。

定期的に発生する「クソコード」発言問題だけど、新人の未熟なコードよりも（自称）熟練者のクソコードのほうが害が大きいので、さりげなく「クソコード」というようにしている。例えば、

• こんなクソみたいなコードを残してしまうと、未来に禍根を残すし
• 使う身になってみれば、クソみたいなAPIを公開されても誰も使わないし
• こんなクソみたいなUIは誰も使わなくなるから、削ったほうがコストが安くなりますよ

とかとか。以前は汚物用語は使わないようにしていたのだけど、なぜかインパクトが薄く（自称）熟練者には届かないようなので、時に散弾銃のように混ぜるようにしている。ちなみに、さりげなく「クソ」を混ぜると、当たらない人には当たらずにスルーされる。本人だけには分かるようなので、顔が少し赤くなるので判別がつく。
また、「クソコード」を言うときは、本人に対して言うのではなく、

• ディスプレイのコードを示しながら、「ここのクソコードなんですけどね」とか
• 印刷したコードにアンダーラインっぽい「削除ライン」を引きながら「ここのコードなんですけどね」

とやる。コードを書いた本人が悪いのではなく、悪いコードを修正しない当人が悪いという示唆である。プログラマは職人的な能力が問われるので、日々進化する。だから、数日前に書いたコードは、自分が未熟だったゆえに（ものを知らなかったゆえに）書かれたコードであれるのだから、数日後にものを知ったあとで直せばいいのだ。
だから、直せばOK. 直さないのは何かが「クソ」なのだから。

何を参考書にする？

• ソフトウェアインスペクション
• ピアレビュー

コードレビューに関しては、この２冊があれば十分である。

「ソフトウェア インスペクション」は、IBMで育ったレビュー方式で、厳密にレビューの仕方が規定されている。ざっくりと集まって、ざっくりと（自称）熟練者が新人に対して評価を下すのではなく、レビューを行う品質管理担当がいて厳密に手順を決めておく。きっちりと行うには、IBM ぐらい大きな組織でないと難しいのだが、レビューする日を別に定めて、レビューを記録しながらやると同じような効果が得られる。
最大のポイントは、レビューをするものが事前にレビューをしておくことだ。レビューをするために長い時間取られるが、それだけの効果があるし、なによりも面と向かって言うのではなく、あらかじめ紙面に書いておくことで感情的にならずに済む。また、面と向かったときには「何を基準にして駄目なのか」を明確に言えるようにしておく必要がある。

「ピアレビュー」は、インスペクションよりも緩く、一般的なレビューよりも丁寧なものを示している。コードを前にしてピンポイントで進んでいくのではなく、頭から最後まで通してコードを読み進め、レビューをしていく。このローラー作戦を遂行することで、コードの品質が「標準的」になるのが、ピアレビューの特徴である。コードが標準的になると、他の人から読みやすくなるし、保守もしやすくなる。改修コードを入れるときにも、既にあるコードになじむように「補修」あるいは「補完」することによって、全体の質を同じに揃えることができる。

マイナス生産者を排除するためレビューを行え

一般的に、コードレビューは

• コードの品質を上げる
• 新人が作ったコードの間違いを直す

という目的で行うことが多いのだが、最近の新人プログラマはそれなりにプログラムコードを勉強しているし、30年前とは違ってプログラム言語も豊富になってきたので、極端に不味いコードが出てくることは少なくなっている…と思う。会社に属さなくなって10年以上経つので、ほんとうのところはどうなのか分からないのだが（いやいや、頭でっかちな新人っぽい人はちらほら見るので、それなりの「ぴよぴよコード」はあるとおもうのだけど C#のぴよぴよコードをなんとか使える形にするための2つの方法 | Moonmile Solutions Blog）。
と、その前に（自称）熟練プログラマが陥りがちな「クソコード」のほうが有害である。どんなところが有害かというと、

• 「クソコード」を書いた人にしか分からない、クソ理論でコーディングされて、誰も理解できない。
• 「クソコード」を書くために、クソみたいなライブラリを付随されていて保守性が悪い
• 業務システムの場合、テスト費用、保守費用が別途かかってくるので、それを増大させるのは全て「クソコード」である。

という点があげられる。個人開発をしていたり、ずっとその会社でライブラリを作り続けていたりするのならばいいのだが、ある程度の大き目の業務システムになると、複数名が関わらざるを得ない。なので、良かれと思ってコードを改修していていても、それは「クソコード」になり得るし、実際に「クソコード」となってしまう。
よって、クソコードは「レガシーコード」よりも低位にある。逆に、先に書いた通り、クソコードは直せばふつうのコードになる。だから、「直さないクソ」な人がクソコードを生み出す≒マイナス生産者である、という話になるのだ。

「ピープルウェア」にある通り、マイナス生産者は清く排除するのがよろしい。あるいは隔離だ。その方法いくつか逆引きにも書いたし、どこかで検索すれば出てくるだろう。

自称熟練者のクソコードの例

自分の過去のコードを見れば、いくらでもクソコードが出てくる。なので、私の書いたクソコードを紹介しておこう。

static int hxx_number = 0;
...
int HXX_get_NUMBER() 
{
	return hxx_number ;
}

その昔、UnixにC++がなくてC言語しか使えなかったとき（まだg++はなかった）に、オブジェクト指向風にメソッドぽいものを作ったクソコード。呼び出し側は、HXX_get_NUMBER 関数で値を取るわけだが、いやいや面倒くさいし、中身が何か分からない。中規模程度であれば、hxx_number を直接参照したほうが可読性がよいだろう。
可読性がわるくなるので、コードを引き継いだ人が迷惑するクソコードだ。

struct DATA data ;

for ( int i=0; i<2; i++ ) {
	...
	data.array[i] = 0 ;
}

構造体のデータを0で初期化する例だが、for文で2つまでか使わないのは無駄だ。arrayが可変ならば必要かもしれないけど、そもそも「2」を即値で置いているのが駄目だろう。素直に、array[0] = 0; array[1] = 0 ; で十分だし、C言語だから memset( &data, 0, sizeof(data)) と memset を使ってゼロリセットするほうがよい。

$h = $this->params['data']['Reservation']['CompletionTime']['hour'];
$m = $this->params['data']['Reservation']['CompletionTime']['min'];
if (  $this->params['data']['Reservation']['CompletionTime']['meridian'] == 'pm' ) {
	$h += 12 ;
	if ( $h == 24 ) { $h = 12; }
}
$CompletionTime		= "$h:$m";
$h = $this->params['data']['Reservation']['StartTime']['hour'];
$m = $this->params['data']['Reservation']['StartTime']['min'];
if (  $this->params['data']['Reservation']['StartTime']['meridian'] == 'pm' ) {
	$h += 12 ;
	if ( $h == 24 ) { $h = 12; }
}
// 入庫時刻の補正
if ( $h == 12 && $m == 1 ) { $h = 0; }
$StartTime		= "$h:$m";
$CustomerBilling		= $this->params['data']['Reservation']['CustomerBilling'];
$y = $this->params['data']['Reservation']['AcceptanceDate']['year'];
$m = $this->params['data']['Reservation']['AcceptanceDate']['month'];
$d = $this->params['data']['Reservation']['AcceptanceDate']['day'];
$AcceptanceDate		= "$y-$m-$d";
$Remarks			= $this->params['data']['Reservation']['Remarks'];
$Scene				= $this->params['data']['Reservation']['Scene'];

これは、PHPをよく知らないときに作ったコードなのだが、日時変換が駄目過ぎて泣けてくる。いわゆる「自称熟練者」がプログラム言語の流儀をよく調べずに、ひとつだけの金づちでなんとかしようとした悪い例である。WEB APIのGET呼び出しなので、今ならばJSON形式のGMT表記で一発で変換できるパターンである。実際、ここは結合テストをすり抜けてしまって運用時にバグが発覚したものである。つまり、クソコードが被害を出してしまった好例？だ。

個人開発や少人数開発であれば、どんなトリッキーなコードを書いてもいいけど（自分がわかるならば）、小規模であっても製品にする場合や複数名でコードを弄るときには、できるだけ「平坦なコード」を書くのがよい。それはコードの標準化とか、共通ライブラリの利用とかいう上辺の話だけではなくて、コードの質を揃えて資産化するという意味でだ。本格的にはMDAとかもうちょっと模索が必要なところだけど。