LEDでモールス信号
LEDでモールス信号を出力するプログラムを作りました。
Morse Code for LED in Linux · GitHub
sysfsなどに出力すると、コンピュータのLEDを使ってモールス信号を送ることができます。
echo 'Hello World, Goodbye' | a.out >/sys/class/leds/input0\:\:capslock/brightness
学内システムインテグレータのようなことをしたお話
自分は大学院生活で、およそ2年間、学内システムインテグレータのようなことをした。NAISTの学生宿舎内のネットワークは、学生ボランティアの委員会により保守・管理されており、自分もその委員に属していた。その活動を何も残さないのは勿体無いので、その活動内容および得られたことを記事に綴る。
活動内容
学生宿舎のネットワークは学内ネットワークを利用するため、学内アカウントで認証を行い、不審な通信を発見ししだいその学生への対応も行う。このゲートウェイ・認証システムも委員会お手製アプリが動いている。エンジニアがトップに立つかどうかは賛否両論あるが、意思決定の迅速さから自ら委員長に立候補した。そして委員会の運営にいろいろと思うところがあったので、その改革を試みた。
認証システムの再構築
自分が委員会で行った一番の大仕事は、認証システムのリプレイスである。自分の入学時に使用されていた認証システムは、バグが放置されていたりと、お世辞にも褒められたものではなかった。しかしそれ以上に、その管理方法が最高にロックだった。まずデータベースにSQLiteを使用していた。更に、ユーザの管理をWebアプリのソースコード（Python）を手動で編集し、毎回Webアプリの再起動をした。宿舎に新たな学生が入る度にこの作業を行っていた。しかしこの惨鼻なシステムには、悲しい理由がある。自分が入学する半年前、宿舎ネットワークのゲートウェイが壊れた。そのときシステムのデータも飛び、しばらく宿舎内でネットワークが使用できない状態が続いた。その後当時の委員会のメンバが、突貫はあるが、数週間でシステムの再構築を行ったのであった。
この仮システム、結局メンテナンスされずに、自分の入学時にも引き続き使用されていた。そして委員会に入ってからその実態を知り戦慄した。SQLiteのDBが壊れてInternal Errorが発生したり、本番環境のソースコードを手動で編集することに耐えられなくなり、ついにシステムのリプレイスに踏み切った。
仕様変更とマシンの更新に伴い、スクラッチから作った。委員会のメンバと共に時間を見つけて開発を進め、11ヶ月かけてリリースできた。デプロイ後数週間はハラハラしながら見守り、その後浮上した細かなバグを潰し、今は安定稼働をしているようだ。なお開発時に得られたTipsなどは、Qiitaにでもまとめようかなと思う。
バージョン管理システムの導入
旧認証システムからも伺える通り、委員会内ではあまり先進的な技術を導入してない。それらを必要としている人も毎年1-2人程度である。しかしデプロイなども考えるとバージョン管理システムすらないのは不便だったので、学内のサーバを新たに借りてGitLabを導入した。またGitLabを学内のKerberos認証と関連付けるために、Kerberos認証の認証をしながらGitLabにパッチも当てたりした。
モダンなドキュメント管理
ユーザ向けにネットワークの設定方法や注意事項を記した資料を配布しているが、従来の資料はMS Wordで作成され、ファイルが更新される度に委員会内wikiにアップロードされていた。Web版ドキュメントが用意したかったのと、バージョン管理したかったため、HTMLベースのドキュメントに切り替えた。静的サイトジェネレータMiddlemanを利用して、Gitによるバージョン管理を行った。
ボランティア・インフラエンジニアの苦労
この2年間、常に事がうまく進んだわけではない。学生・そしてボランティアであるがために、至らないことや挫折したことも多かった。
運営体制の難しさ
メンバのほとんどは2年で卒業するため、長くメンバに属している人がいない。また職員からの干渉も少なく、委員会内で顔を合わせる機会は、月に一度の月例ミーティングのみだ。そのためメンバ間の繋がりも疎で、、必然的にノウハウや情報の教諭がうまくできず、引き継ぎも不十分となった。
また学生かつボランティアなので学業を優先すべきであり、自分も強制したくはなかった。忙しい時期には、学生たちも足が遠のいた。この支障は委員会に入って直後から感じていたため、運営体制をより良いものにしたかったが、方法がわからなかったため例年どおり何も変わらなかったのが心残りである。
若者のネットワーク離れ
「若者のネットワーク離れ」というのは自分の意見ではなく、学内の教員の意見である。下の学年の新メンバが少なくて学内の教員に相談すると、学生のネットワーク離れも深刻という。一昔前と比較するとネットワークの知識がなくともネットワークにつなげる時代になったためか、その教員の研究室も同じ状況だという。
ネットワーク離れが事実かどうかはサンプルが少ないため一概には言えないが、少なくとも過去の委員会のログを見るとIPv6移行プロっジェクトなどが存在を確認できたため、少なくとも今より昔のほうが活発だったと言える（IPv6移行はいまだされておらず、そのプロジェクトの存在も今は忘れ去られている）。これも引き継ぎの難しさの理由の一つであった。
ユーザとインフラエンジニア間のギャップ
インフラとは、ユーザからはインフラは常に動いて当然のもので、また障害発生時は異常事態である。しかしエンジニアからすると、常に動かすのも難しく、簡単に障害が発生しうる。正常に動作されている時は特に感謝はされず、障害発生時には怒りと苦情のメールが飛んでくる。このユーザとインフラエンジニア間のギャップを感じた。
幸い宿舎の学生は、ボランティアで活動しているのを理解しているためか、ネットワーク停止時にもそこまでの怒りのメールをもらったことはなかった。それでもシステム停止時やメンテナンス直後は、胃を痛める思いで作業をした。インフラエンジニアの苦労が若干理解できた気がするので、インフラの障害発生時にも穏便に対応するよう心がけるようにする。
おわりに
この2年間、家庭では体験できない規模のネットワークを扱えたのは良かったと思う。ある程度自由に活動できたのも嬉しかった。その反面苦労することもあり、エンジニアとして、人間としての未熟さも痛感した。これらの活動は将来の自分にとって良い経験となることを祈りたい。
中学2年生のときに作ったスクリーンセーバー
GUIプログラミングを始めた人が作りたいもの、 そして中学2年生が見てワクワクするもの、 それは共通して映画「マトリックス」の緑の文字が画面上に覆い尽くされるアレです。 自分が中学2年生のとき、C++とWin32APIを使ってGUIアプリケーションにハマっていて、 同時にマトリックスも大好きだったので、スクリーンセーバーを作りました。
ファイルのタイムスタンプを見ると、2006年8月30日でした。 いまから10年前ですが、お蔵入りにするのがもったいなかったので公開しました。 当時書いたコード、10年後の2016年になっても、コンパイルできてバイナリもそのまま実行できます。
背景
マシンは父親から譲り受けたFMVに、コンパイラはVisual C++ 5.0を使って、Win32APIの勉強に勤しんでいました。 そしてWin32APIの勉強は猫でもわかるWindowsプログラミングで進めてました。 その本にはスクリーンセーバーの雛形のサンプルも会ったので、それを元にマトリックスの文字を流しました。
ビルド
現在は残念ながらVisual C++のビルド環境が無いですが、Appveyor上でビルしてます。 便利な時代です。 当時はまだクラウドという概念どころか、Web上のCIという贅沢なサービスもありませんでし、GitHubもまだ存在してませんでした。
終わりに
当時自分が13-14歳くらいのときに書いた、C言語のような粗悪なC++コード、今見返すとひどいものです。 猫でもわかるWindowsプログラミングのサンプルはどれもCだったので、その影響もあったのではと思います。 そのうちまた修正したいな。