我慢ならない
格安鯖（HP Proliant ML115G1）にLinuxMintを入れて、掃除してファン付けまくって使ってたんだけども、昨日、室温が36度の時点で落ちた。まぁさすがにこの室温だと使ってる自分も落ちかけてたんだけども、ミドルタワーというよりミニタワーレベルの筐体でいくらエアフローを気にしたところで、室温がここまで上がると焼け石に水で、どう頑張っても耐えられないらしい。
ちなみにMBAの方は起動はするけども、アームレストが爆熱になり、熱暴走っぽい現象で風車が回りっぱなしになるので使用は無理。こんなエクストリームな環境下でどうやってPC使うかを考えるってのもかなりアホなんだけども、この室温下でも動くPCもある。それは格安鯖のNEC Express5800 110gdだ。こいつにはC2Q Q6600を載せてるんだけども、昨日の室温36度の状態でも動いてた。まぁグラボを積んでないので、なんとかなってるってのもあるんだけど、それでもCPUが普通に稼働してる（コア温度が60度台で動く）のは優秀。まぁメイン鯖として使ってたのでメモリもヒートシンク付けてるし、ファンも前後2個ずつ動かしてる。なによりML115よりも筐体がでかいのでエアフロー的にはかなり有利。
ならば、いっそのことこの110gdをクライアント機にしてはどうだろうか？
と、ML115が落ちた時に思いつき、そのまま110gdの分解清掃を始めた。全ファンを綺麗に掃除して、CPUはグリス塗りなおしてヒートシンクも徹底的にホコリ除去。ML115からグラボを移植し（ちなみにグラボはnVidiaのGF8600GTSだ。こいつが爆熱源のひとつ）、OSもMintを入れてみた。
・・・が、遅い。CPUはいい。ちゃんと動いてる。グラボも液晶2枚で動かすとちょっと微妙だがちゃんと動いてる。ファンも回ってて、ちゃんと排熱してる。だがI/Oが遅い。HDDを2機載せてるんだけども（500GB+1000GB）こいつが遅いのだ。
MBAに慣れてるのでSSD速度に慣れ親しんでるってのはある。なのでHDDで動く環境で遅さを感じてしまうのはある程度は仕方ない。だが、それでも遅い。例えば、エクリプスを起動させるのに1分かかる。ちなみにMonodevelopは5秒ぐらいだ。許容範囲だろうか？だがファイル編集中にカーソル移動ももたつく。これでは開発環境としては使えない。
まず、これにはいくつか理由がある。パーティションの切り方がアホなのだ。自分でやったんだからアホもなにもなくて自業自得なんだけども、元々、この110gdはHDDを3本積んでいた。システム領域とデータ領域だ。データ領域用HDDには各種データが入ってる。そいつを/dataとかにマウントして使ってる。残り2本のHDDでシステム領域を分割していた。/と/homeと/varとスワップを2本のHDDに配分していたのだ。今回110gdをクライアント機にするにあたって、熱源を減らすために、このHDDを1本外したのだ。なので上記のディレクトリが1本のHDDに載ってしまっている。
一昔前だったらそんな構成は普通で、問題にするところじゃないんだけども、今は違う。MBAのSSDに慣れた体でこの構成、しかもアプリは昔よりも確実に重くなってきている。それにクライアントとして使っているということにも問題がある。作業をしながら音楽を聞いているのだ。なのでディスクIOは頻繁に発生していると思う。それを5400rpmのSATA HDDが1台でやってる。メモリは8GB積んでるのでそうそうスワップを使うことは無いと思うが、もしスワップを使う状態に陥ったら使い物にならないだろう。
で、過酷な状況でクライアントPCとして動かす方法を模索する事にした。
まず、現在の省電力メイン鯖として動いてるAtom搭載機からSSDを外す。SSDにはシステムが載ってるので、鯖環境は作りなおしになる。これは1台しかないSSDをクライアント環境で使うためには仕方ない。このSSDをクライアント環境のシステム領域として使うとして、更に問題がある。液晶が2枚あるということだ。
グラボはGF8600GTSなんだが、こいつが2枚の液晶の描画をするのに不安があるのだ。グラボのメモリは256MBで、24インチクラスの液晶を2枚表示させるには若干無理がある。しかも、110gdは鯖機で、グラボを挿せるように出来ていない。PCI-Eの4xのスロットに無理矢理挿してる。なので根本的に無理がありまくるのだ。だが、ML115はPCI-Eのスロットは16xだ。グラボのスペックをフルに発揮できる。なのでML115に刺した状態の8600GTSの描画はある程度安定しているが、110gdの方だとかなり微妙だ。どんぐらい違うかというと、ML115ではフルHDのyoutube動画を表示できるが、110gdに挿してるとカクカクになる。グラボは同一なのでスロット側の速度がやはり原因なんだろう。
こういった前提条件の中で、以下の解決策に行き着いた。
- 110gdの筐体 + 110gdのマザー + SSD + 8600GTS（現行の110gdにSSDを移植するだけ）
- 110gdの筐体 + ML115のマザー + SSD + 8600GTS（現行の110gdにML115からマザーを移植）
エアフロー的に110gdの筐体を使う以外の選択肢は無い。グラボも8600GTS以外の選択肢は無い。そうなると、8600GTSの性能をフルに発揮できるようにML115のマザーを移植するか、現行の110gdのマザーで我慢するかだ。マザーを交換すると当然CPUが変わる。ML115の方はAthlon64 X2 +5000 BEで、110gdはC2Q Q6600だ。コア数はデュアルコアとクアッドコアで、当然Q6600の方が性能が良い。逆に発熱はAthlonの方が酷い。
総括すると、CPU性能を取るか、グラボ性能を取るかの2択になる。普通にクライアント環境として考えればAthlon環境でグラボをフル活用できる方がいいと思う。だが、これは開発環境だ。描画性能より演算処理性能をあげるべきなんじゃなかろうか。それに高温の環境で使うのだ。発熱が少ないC2Qの方が安全だろう。
・・・といった感じの究極にアホくさい2択で悩んでいる。根本的に涼しいとこで作業しろよって感じなんだがな・・・。
そうだ。Linuxがあった
昨日、Xamarinに関する記事を書いていて、Linux環境があるってことをふと思い出した。
Mintで開発環境を作ったものの、筐体とか中身は安い鯖を流用してるので、夏場になるとファンが物凄い勢いで回る。それこそ飛行場にいるんじゃないか？ぐらいの気分で爆音を出すのでとてもじゃないが作業に集中できない。なので涼しくなるまでは放置だなー、なんて感じで5月終わりぐらいから放置していた。
もう7月だし、これから夏に入ってくので、今年の夏もMBAで涼しいところを探して放浪しながらプログラミングかなー、なんて思っていたんだけども、せっかくC#勉強し始めたんだし、この開発環境にMonodevelopをインストールしておくことにした。まぁインストール自体はすんなり終わったんだけども、やはりファンが煩い。起動時から全開ですよ。こりゃたまらん。一体どんぐらいの温度が出てんだろうか気になったのでxsensors入れて確認してみると80度・・・・。いくら爆熱のAthlonとは言え、いくらなんでも熱すぎでしょ。
つーわけで久々に筐体開けてエアフローの確認と掃除をすることにした。やったのは
- 前面パネル内フィルタ交換（換気扇フィルタで自作）
- 前面パネル内吸気ファン交換（薄型80mm X 2 を 新品92mm X 2へ）
- 爆音後方排気ファン 92mm から ダクトをつけて120mmへ
- CPUクーラー掃除（埃だらけだった・・・。多分80度までいった原因はこれ）
- 爆音CPUファン 92mm から静音92mmへ交換
- エアフロー確保のため、グラボ以外のカードを撤去（NICとサウンドが載ってた。NICはオンボード、サウンドはUSBサウンドにした）
- グラボ排気用スロット搭載ファン設置
- ケーブル整理
上記全部やって12時間ぐらいかかっちまった。
で、その結果、室温31度の状態で
- アイドル時 42度 − 高負荷時 64度
まで改善。しかも爆音ファンを撤去したので静音状態でだ。
おそらく、この状態なら真夏でも使えるんじゃないかと予想。PCがギブアップする前に人間がギブアップだろう。
ってことで、せっかくLinuxを復活させたので、XamarinじゃなくMonodevelopで開発していきたいと思う。Macは当分の間はバイナリの動作確認用PCってことで。
MacのC#（Mono）でSQLiteを使う
まぁ表題の通りなんだけども、いろんな情報がありすぎてかなり悩んだので、備忘録的に残しておく。
まぁXamarin使ってるので、Xamarinの公式サイトとかみたり、他の開発者のブログとか読んだりしてると、いくつかSQLiteを使う方法が出てくる。・・・のだが、うちの環境ではNuGetからのインストールする方法ではまともに動かなかった。いろいろ試してみた結果、いかの方法で動いた。
Xamarin公式のチュートリアル的な記事なんだけども、Xamarin公式でもNuGetから落としてくる方法について書かれてる物もある。どっちも試したけども、こっちが確実だった。Mono内蔵の物を使ってるので、おそらく他の環境でもうまく動くんじゃなかろうか。
Xamarinはじめました
前々からGUIアプリ作成に興味があったんだけども、最近、PHPばっか書いていた反動なのか、どうにもその欲望が止まらなくてSwiftを勉強し始めた。Swiftは触ってみると結構簡単でobj-cに比べて「触れないことは無い」言語だった。オープンソース化されたってのもあって、今後もしかしたらメインストリームに出てくるかもしれないなー、と感じられた。ただ、現状だと実質的にMacでしか作ったものを触ることは出来ないし、MacでGUI開発するのであればCocoaの勉強をしなくてはならないってことは避けて通れない問題だってのも感じられた。
SwiftはXcodeで開発するんだけども、GUIの開発に関しては内蔵されてるStoryboardを利用することになる。このStoryboardってのが便利なんだか不便なんだか判らない代物で、確かにお手軽ではあるんだけども、何かと敷居が高かったりもする。というのも、世の中の開発者ってのは「Macで開発する=iOSアプリを作成する」って感じで、デスクトップアプリを作成することに関しては情報があまりないのだ。しかもあったとしてもobj-cの情報ばかりで、Swiftでデスクトップアプリ開発に関する事を調べるとかなり限定されてくる。これは辛い。Swiftでビジネスロジックを書くだけなら言語仕様を勉強すれば出来ないこともないんだけども、それとCocoaについてを組み合わせるといきなり敷居が高くなるのだ。
それはともかく、GUIアプリを作成するにあたって、もう一つ考えなきゃならないことがある。マルチプラットフォームのGUIってことだ。使用するメイン環境はMacだけども、Linuxも使う。これを念頭に入れていたので、今まではGUIアプリ作成はQtだったりJava系GUIだったりってのを検討していたんだけど、まだSwiftはマルチプラットフォームがどうこう言うのは時期尚早だ。
と、こういう経緯を経て、Xamarinに手を出してみた。XamarinはC#なんだけども、MS製の言語での開発経験がVB2.0の頃ぐらいなので、今まで触ったことのない言語だ。言語仕様に関してはスクリプト言語と違うってことで、今までとは勝手の違う部類なんだけども、それでもWin開発者の多さと（Swiftよりは）昔からある言語ってことでネット上の情報に関しては申し分ない。いろいろと納得いかない部分もあったりするが、全体的にとても開発しやすい言語だと感じた。なんていうか、開発者が作った言語ってよりも、アプリ使用者が作った言語って感じで、うまく言えないけども、雰囲気的に簡単なのだ。雰囲気とかって言葉で曖昧な感じで言うけども、なんていうか簡単な雰囲気なのだ。そこがSwiftと違うと感じた。
C#で開発すると言っても、Macのデスクトップなアプリを作成するのにCocoaの情報は欠かせない。だがXamarinもStoryboardを使用してUI部分を作成するので、Swiftと労力は変わらない。っていうか、SwiftではiOS向けな情報ばかりだったが、Xamarinでもそれは同じで、AndroidとiOSアプリを作るって情報ばかりが世の中に溢れている。結局のところ、SwiftだろうがXamarinだろうが、GUIアプリを作るのに勉強しなければならないのは言語仕様よりもGUIフレームワークなのだ。・・・・という現実にぶつかってちょっと絶望した。Winの開発系書籍とかだとC#だろうがC++だろうがVBだろうが、GUIフレームワークの使い方の情報ってのはそれなりにあると思うが、MacだとiOS向けの開発に関するものはあってもデスクトップアプリ開発に関する物は凄い少ない。もうちょっとなんとかならんのだろうか。情報少なすぎ。
MacでGUIアプリを作るのにCocoaの勉強は避けて通れない。ということを再認識したところで、Xamarinでの開発に関する情報を色々集めてみた。そこで判明したのだが、XamarinはC#だけども、このC#って言語を利用した開発環境ってのはマルチプラットフォームで色々あるということが解ってきた。結局のところ、.NETのパチもん的なMonoを利用して動かしてるんだけども、このMonoがある環境であればC#アプリを動かせるってことだ。なので、ゲーム分野で結構採用されてるっぽかった。有名どこだとUnityなんかはMonodevelopをベースにしてC#で開発ができるらしい。そうか、OSプラットフォーム依存じゃないGUIフレームワークだったらマルチプラットフォームアプリを完結して書けるんだなー、なんて薄っすら思ったとこでピンとくる。Qt+Xamarinはどうだろうか？と。
QtはマルチプラットフォームなGUIフレームワークだけども、多言語に対応している。Pythonからですら使えるのだから、C#バインディングがあってもおかしくない。って事で探してみたらあった。
日本語情報だとQyotoってのが見つかったんだけども、どうもこのプロジェクトはobsoleteらしい。後継がQtSharpみたいだ。
おし、これでQtアプリをXamarinで書くかー、って思ったんだけども、もうね、情報が皆無。誰もやってないんじゃなかろうか。さすがに情報が無いと敷居が高いから調べてたら、英語のフォーラムで俺と同じような疑問を持ってる人がいて、それに対する返答で「C#のマルチプラットフォームのGUIアプリ作るんならGTK#使えや。GTK#はMono内蔵だからMonoがある環境なら動くぞ」みたいな情報を入手した。そうかGTKか。GTKなら日本語情報は少ないが英語情報は巷に溢れかえってるのでなんとか勉強できそう。GTK#勉強するぜ！
・・・と、ここまでたどり着くのに1ヶ月かかった。Swift勉強し始めて、Xamarinインストールして、Cocoaうざいと思ってQt使おうかと思ったらGTK#、みたいな流れ。正直、C#とGTKだと、XamarinじゃなくてMonodevelopでいいじゃん、って感じなんだけども、まぁいつ気が変わってCocoaを勉強しはじめるか判らんのでXamarinでGTK#ってのにこだわっていきたい。
さて、何作ろうか。
ポモドーロ・テクニックのその後
まずTodoアプリを変えた
こっちの方が使いやすい。
ポモドーロタイマーは以前と一緒のを使ってる。コードを書いてて時間になると、ささやかにインタラプトしてくれるので一応気付く。ガチガチのポモドーロタイマーだときっちりインタラプトしてくれるらしいけども、俺はささやかな方がいいみたいだ。つーのも、いくら25分という時間が決まっててもキリの悪い時ってのはあるわけで、関数名途中まで書いて休憩、ってわけにはいかない。関数の中身を書かないまでも、さすがに関数名は全部書かせて欲しい。そういった意味でささやかにインタラプトしてお知らせしてくれるぐらいの方が都合がいい。
25分作業して5分休憩してってのを繰り返すのがポモドーロ・テクニックなんだけども、ずっとやってきて思うのがやっぱり25分は少ない。もっと集中力は続くっぽいので50分ぐらいやって10分休憩みたいな学校の授業ペースの方が合いそうな気がする。25分で切られると若干ストレスが溜まるかな。特にノリノリでコーディングしてる時は2時間ぐらい書き続けられそうなので、ポモドーロ・テクニックを使わない方が良い様な気もする。
やる気が無い時に無理矢理やるのであればポモドーロ・テクニックは有用だろうけども、一度やり始めちまうと数時間放っといてくれたほうがいいと思うな。まぁ一日トータルの作業時間って考えると、こまめに休憩をとってるポモドーロ・テクニックの方が長くなるんだろうけども、中身の濃さを考えると時間で区切るのも考え物だと思ったり思わなかったり。ルーチンワーク的な物だったらポモドーロ・テクニックがいいんだろうけども、プログラミングとの相性ってそんなに良くないんじゃなかろうかね。やる人次第なのかな？
ともかく、集中し始めるまでの最初の1時間ぐらいはポモドーロ・テクニックを使って、ノリノリになってきたらポモドーロ・テクニックを使わないで集中力が持続する限り書き続けて、集中力が切れたら長めに休憩して、休憩終わったらポモドーロ・テクニックをやって、ってのを繰り返してる。これで５，６時間はなんとかやれてる感じ。いきなり数時間集中しようと思って作業やるよりも、ポモドーロ・テクニックで徐々に集中力を上げてって、集中したらやり続けるって感じのハイブリッドなポモドーロ・テクニックが今のとこいい感じにやれてるって感じだな。このままやっていきたいと思う。
さて、仕事の為にPHPのリハビリやってるんだけども、1年以上ぶりで書くPHPはかなり新鮮。んで、Vagrant環境にPHP7を入れてるんだけども、PHPだとWeb前提ってのもあってそんな重い処理をさせないので、いまいち速さが実感できない。wordpressとか動かしたら結構違うんかな？
