読者です 読者をやめる 読者になる 読者になる

Folioscope

プログラミング/Unix系/デザイン/CG などのメモがもりもり

Qiitaの記事を書くときは、それっぽいアイコンを見出しに置くと、それっぽい記事に見える

最近技術的な記事は Qiita に投稿することとなり、こちらの記事はめっきりと減りました。たまにはこちらにも投稿したくて、Qiitaに関する記事を一つ。Qiitaの記事を書くときは、それっぽいアイコンを見出しに置くと、それっぽい記事に見える、という内容の記事です。

Qiitaの記事でアイコンを使う

QiitaはFont Awesomeを使用しているため、fa-*** をクラス名に持つ要素を配置すると、アイコンが表示されます。このアイコンは見出しにも使うことができます。例えば次のように記述すると、

<i class="fa fa-key"></i> Personal access tokenの発行  
-----------------------------------------------------
まずGitHubのPersonal settingsから......

このように表示されます。

f:id:ibenza:20160619215350p:plain

見出しにアイコンを追加すると見通しが良くなり、文字だらけの退屈な記事でもワクワクする記事に見えてきます。また若干、意識高い系エンジニアにも見られそうです。

f:id:ibenza:20160619215356p:plain

いいアイコンがないときは、それっぽいもので代替

Font Awesomeの豊富なアイコンであっても、いいアイコンが見つからない事がちょくちょくあります。そんなときは何食わぬ顔で適当にそれっぽいアイコンを使用します。そうすれば直接関係がなさそうなアイコンであっても、記事を読み進める上でのアクセントとなります。

例えば「はじめに」という見出し、いいアイコンが無いのでなんとなくmap-signsを使ってみます。すると「はじめに」を表現できなくても、記事全体の道標を記しているように見えます。

f:id:ibenza:20160619215403p:plain

また 「動作環境と構成」という見出しでは、サーバと関係なくてもserverをつかってみます。すると何らかの環境が説明されるかのように感じます。

f:id:ibenza:20160619215407p:plain

つぎに Basic認証の自動化」 という見出しでは、なかなか用途がわからないmagicを使ってみます。すると、まるで魔法のように手順が自動化されそうに見えます。

f:id:ibenza:20160619215411p:plain

そして最後に 「動作環境」という見出し、関係がなさそうなfighter-jetを使ってみると、ジェット機のように何を動作させる感じが出ます。

f:id:ibenza:20160619215414p:plain

完全にマッチしたアイコンでなくても、それっぽいアイコンを使用すると何故か馴染みます。また読者は筆者ほどにアイコンの意味を考えないので、思考停止でアイコンを散りばめれば良いです。

LEDでモールス信号

C/C++ Linux

LEDでモールス信号を出力するプログラムを作りました。

Morse Code for LED in Linux · GitHub

sysfsなどに出力すると、コンピュータのLEDを使ってモールス信号を送ることができます。

echo 'Hello World, Goodbye' | a.out >/sys/class/leds/input0\:\:capslock/brightness

学内システムインテグレータのようなことをしたお話

コラム・雑談

自分は大学院生活で、およそ2年間、学内システムインテグレータのようなことをした。NAISTの学生宿舎内のネットワークは、学生ボランティアの委員会により保守・管理されており、自分もその委員に属していた。その活動を何も残さないのは勿体無いので、その活動内容および得られたことを記事に綴る。

活動内容

学生宿舎のネットワークは学内ネットワークを利用するため、学内アカウントで認証を行い、不審な通信を発見ししだいその学生への対応も行う。このゲートウェイ・認証システムも委員会お手製アプリが動いている。エンジニアがトップに立つかどうかは賛否両論あるが、意思決定の迅速さから自ら委員長に立候補した。そして委員会の運営にいろいろと思うところがあったので、その改革を試みた。

認証システムの再構築

f:id:ibenza:20160330134721p:plain

自分が委員会で行った一番の大仕事は、認証システムのリプレイスである。自分の入学時に使用されていた認証システムは、バグが放置されていたりと、お世辞にも褒められたものではなかった。しかしそれ以上に、その管理方法が最高にロックだった。まずデータベースにSQLiteを使用していた。更に、ユーザの管理をWebアプリのソースコードPython)を手動で編集し、毎回Webアプリの再起動をした。宿舎に新たな学生が入る度にこの作業を行っていた。しかしこの惨鼻なシステムには、悲しい理由がある。自分が入学する半年前、宿舎ネットワークのゲートウェイが壊れた。そのときシステムのデータも飛び、しばらく宿舎内でネットワークが使用できない状態が続いた。その後当時の委員会のメンバが、突貫はあるが、数週間でシステムの再構築を行ったのであった。

この仮システム、結局メンテナンスされずに、自分の入学時にも引き続き使用されていた。そして委員会に入ってからその実態を知り戦慄した。SQLiteのDBが壊れてInternal Errorが発生したり、本番環境のソースコードを手動で編集することに耐えられなくなり、ついにシステムのリプレイスに踏み切った。

仕様変更とマシンの更新に伴い、スクラッチから作った。委員会のメンバと共に時間を見つけて開発を進め、11ヶ月かけてリリースできた。デプロイ後数週間はハラハラしながら見守り、その後浮上した細かなバグを潰し、今は安定稼働をしているようだ。なお開発時に得られたTipsなどは、Qiitaにでもまとめようかなと思う。

バージョン管理システムの導入

f:id:ibenza:20160330134710p:plain

旧認証システムからも伺える通り、委員会内ではあまり先進的な技術を導入してない。それらを必要としている人も毎年1-2人程度である。しかしデプロイなども考えるとバージョン管理システムすらないのは不便だったので、学内のサーバを新たに借りてGitLabを導入した。またGitLabを学内のKerberos認証と関連付けるために、Kerberos認証の認証をしながらGitLabにパッチも当てたりした。

モダンなドキュメント管理

ユーザ向けにネットワークの設定方法や注意事項を記した資料を配布しているが、従来の資料はMS Wordで作成され、ファイルが更新される度に委員会内wikiにアップロードされていた。Web版ドキュメントが用意したかったのと、バージョン管理したかったため、HTMLベースのドキュメントに切り替えた。静的サイトジェネレータMiddlemanを利用して、Gitによるバージョン管理を行った。

ボランティア・インフラエンジニアの苦労

この2年間、常に事がうまく進んだわけではない。学生・そしてボランティアであるがために、至らないことや挫折したことも多かった。

運営体制の難しさ

メンバのほとんどは2年で卒業するため、長くメンバに属している人がいない。また職員からの干渉も少なく、委員会内で顔を合わせる機会は、月に一度の月例ミーティングのみだ。そのためメンバ間の繋がりも疎で、、必然的にノウハウや情報の教諭がうまくできず、引き継ぎも不十分となった。

また学生かつボランティアなので学業を優先すべきであり、自分も強制したくはなかった。忙しい時期には、学生たちも足が遠のいた。この支障は委員会に入って直後から感じていたため、運営体制をより良いものにしたかったが、方法がわからなかったため例年どおり何も変わらなかったのが心残りである。

若者のネットワーク離れ

「若者のネットワーク離れ」というのは自分の意見ではなく、学内の教員の意見である。下の学年の新メンバが少なくて学内の教員に相談すると、学生のネットワーク離れも深刻という。一昔前と比較するとネットワークの知識がなくともネットワークにつなげる時代になったためか、その教員の研究室も同じ状況だという。

ネットワーク離れが事実かどうかはサンプルが少ないため一概には言えないが、少なくとも過去の委員会のログを見るとIPv6移行プロっジェクトなどが存在を確認できたため、少なくとも今より昔のほうが活発だったと言える(IPv6移行はいまだされておらず、そのプロジェクトの存在も今は忘れ去られている)。これも引き継ぎの難しさの理由の一つであった。

ユーザとインフラエンジニア間のギャップ

f:id:ibenza:20160330134710p:plain

インフラとは、ユーザからはインフラは常に動いて当然のもので、また障害発生時は異常事態である。しかしエンジニアからすると、常に動かすのも難しく、簡単に障害が発生しうる。正常に動作されている時は特に感謝はされず、障害発生時には怒りと苦情のメールが飛んでくる。このユーザとインフラエンジニア間のギャップを感じた。

幸い宿舎の学生は、ボランティアで活動しているのを理解しているためか、ネットワーク停止時にもそこまでの怒りのメールをもらったことはなかった。それでもシステム停止時やメンテナンス直後は、胃を痛める思いで作業をした。インフラエンジニアの苦労が若干理解できた気がするので、インフラの障害発生時にも穏便に対応するよう心がけるようにする。

おわりに

この2年間、家庭では体験できない規模のネットワークを扱えたのは良かったと思う。ある程度自由に活動できたのも嬉しかった。その反面苦労することもあり、エンジニアとして、人間としての未熟さも痛感した。これらの活動は将来の自分にとって良い経験となることを祈りたい。

中学2年生のときに作ったスクリーンセーバー

f:id:ibenza:20160210210411p:plain

GUIプログラミングを始めた人が作りたいもの、 そして中学2年生が見てワクワクするもの、 それは共通して映画「マトリックス」の緑の文字が画面上に覆い尽くされるアレです。 自分が中学2年生のとき、C++とWin32APIを使ってGUIアプリケーションにハマっていて、 同時にマトリックスも大好きだったので、スクリーンセーバーを作りました。

github.com

ファイルのタイムスタンプを見ると、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だったので、その影響もあったのではと思います。 そのうちまた修正したいな。