shinoのときどき日記
2011年07月04日(Mon)
■ 最近のこと
- 地デジ対応という名目でTVを買い換えた。
- ついでにTV台も変えた。無印良品の子供用ローテーブル。かわいい。
- 自動掃除ロボット、ルンバを買った。
- ルンバ最適化のために部屋の家具の配置替えをした。
- 手元で使っているマシンにVMware Player+Ubuntu 10.04 TLS server入れた。
マシン、楽しいよ、マシン。
2011年07月09日(Sat)
■ マシンのメモリを2GB→5GBに増やした。
アプリをいくつか立ち上げると、マシンの動作のもたつきを感じるようになったので、メモリを増やすことにした。
メモリを増やすなんてそんなに滅多にすることではないので、いくつか検討ポイントと、増設前後のリソースモニタの比較を乗せておきます。
購入前
マシンの仕様を確認する。わたしのマシンは画面右下にマシンのシリーズ名"Pavilion dm1"と書かれてる。これにはいくつかスペック違いのものがあるのだけど、買ったのは量販店なので、オリジナル（量販店）モデルというもの。
この、メモリとメモリスロットの仕様を見る。HP サポートドキュメント - HPサポートセンター
マシンを開けなくても、"PC3-8500" "DDR3-SDRAM" "204ピン" "SO-DIMM"あたりにあったメモリが必要で、最大5GBとあるのは、オンボードが1GBで、差し替えられるのが4GBまでということがわかる。また、スロットは１つしかないので、今のメモリは廃棄にすることを前提に、4GBを新しく買うということになる。
ただし、4GB積んで、オンボードと足して5GBになったとしても、今、使っているOSは32bit版のWindows7なので、メモリを認識するのは3.2GBまでとなる。
購入
一応、PCメーカー純正の4GBのメモリをみたら、価格は税込み69300円だった。…。その価格出すなら、新しいノートPC買います…。
ということで、PC3-8500のメモリを価格コムで探すと、最安で2998円くらいのメモリが出てくる。でも、ここで、ラムディスクでWindowsの限界を突破する | メモリーMAX増設で本当の力が目を覚ます | BUFFALO バッファローを見る。
4GB+1GB=5GBをマシンに積んでも、使えるのは3.2GB。残り2GBくらいは不使用領域になる。それをRAMDISKで有効に使えるならば、楽しそう！と思い、結局、AmazonでBUFFALO ノートPC用増設メモリ PC3-8500(DDR3-1066) 4GB D3N1066-4G/E by バッファローを\4170でぽち。
メモリ到着後
HPのサポートページにちゃんとメモリの増設方法のページがあったので、これを参考にしながら、メモリ差し替え。
リソースモニタ 1GBスロットメモリバージョン
リソースモニタ 4GBスロットメモリバージョン
ハードウェア予約済みというのは、32bit Windows7が認識できないメモリエリア。そこで、そのエリアをRAMDISK化するために、期待のBUFALLO RAMDISKユーティリティをインストールしようとしたら、失敗した。get disc statusというエラー。
もう１回、蓋をあけてエアダスターでよくスロット周辺を吹いて、差し直したところ、RAMDISKユーティリティのインストールができました。わたしの環境ではFドライブに割り当てられたので、Windows7の環境変数のTMPとTEMPをFドライブ参照にした。これがどのアプリにどう効いてくるかは楽しみ。
2011年07月10日(Sun)
■ CPUの温度を調べる。
使っているノートPC(Pavilion dm1)が、どうにもこうにも熱いので、Core TempというCPUの温度を調べてくれるアプリをWindows7に入れてみた。
dual coreでCPUがふたつ入っているのだけど、冷却開始前、２つとも63℃だった。無理矢理、保冷剤をかましてみたら、48℃まで一瞬、落ちたけど、だいたい、52～4℃くらい。保冷剤を外すととたんに63℃まで上昇する。キーボードはかなり熱くて、低温やけどしてしまいそう。
しかし、冷凍した保冷剤は結露が危険なので、応急処置。はやめに冷却ファンを検討しないといろいろ危険すぎる。保冷剤はずしても熱暴走しそうだし、保冷剤をすれば結露するし。
あと、いままでわたしは、Wireless KeyboardをノートPCのキーボードに重ねていたのだけれど、キーボードを重ねた状態のCPU温度と重ねない状態のCPU温度はそれだけで5℃くらい違ったので、キーボード重ねは冷却効果を遮断してしまうのでよくないということに気づいた。
■ デュアルディスプレイ状態へ
いろいろと片付いて8年くらい前に買ったデスクトップPC（すでに使えない）の17インチディスプレイを流用して、念願のデュアルディスプレイ状態にしてみた！
2011年07月18日(Mon)
■ tDiary会議！
tDiary会議で、ローカル環境にVM入れて環境作りましたという話をしてきましたー。
まだまだ謎の単語がたくさんあるけれど、おもしろいです。
旅を続けるよ！
スライドはこちら。
追記１
開発環境におけるruby1.8系と1.9系の切り替えは、大きくわけて３つある。
ひとつめは、rubyのバージョンごとにVMを作成する。しかし、この方法はセットアップが大変なのと、切り替え時、いちいち、VMを落として起動することをしなくてはならない（または複数VMを起動する）ことになるので、推奨されない。
もうひとつはrvmを使う。あとで調べる。
最後のひとつはruby1.8と1.9を異なる場所にインストールしてindex.rb と update.rb の一行目に書かれている ruby のパスを変える。
これは、tDiary会議前に、たださんにぽろぽろっと発表内容を話したら、教えてくれたこぼればなし。
追記２ 本日のトピック
- tDiaryのjQuery対応について（まちゅさん）
- tDiaryのテーマ開発について（NTさん）
あと、まちゅさんはtDiaryのevernoteプラグインも開発中ということですが、tDiary側のセクション処理が難しいそう。
■ RubyKaigi2011へ行ってきた！
今年は最後のRubyKaigiということで、最終日の今日のみ、参加できました。その中のアンカファレンスでtDiary会議もあり、プチ発表したり、LTを大ホールで聴いたり、名物Ruby折り紙でルビーを作ったり、とっても楽しかったです。スタッフのみなさま、おつかれさまでした！
2011年07月20日(Wed)
■ 自分用LaTex Makefileを書いた。
最近、LaTexにはまっている。PDFで出力するテキストは、できるだけLaTexで書くのが目標。
今日は、*.texをコンパイルするためのMakefileを書いてみた。
2011年07月22日(Fri)
■ LaTexをTexLive2011にした。
ptetexというもうサポートされてないLaTexをインストールしてしまっていたのだけれど、どうにもこうにも日本語フォントの埋め込みがうまくできない。日本語フォントの埋め込みができないとslideshareなど海外のPDF readerに日本語が表示されない！ということで、いろいろ施行錯誤した。
やりたかったのは、次の3点。
- UTF-8なファイルを扱えること
- 日本語フォントの埋め込みができること
- 多書式（いろんな種類の日本語フォントが扱えること）
調べた結果、一番最近でたTexLive2011というのだとほとんどインストールしてからあまりあちこちを触らないで、UTF-8も日本語フォント埋め込みもできるということがわかった。微妙にplatex hoge.texやdvipdfmx hoge.dviで警告（WARNING)が出るものの、一応、目的を達成できたPDFが作成できたので良しとする。
以下のリンク先に、今回の環境構築とtexからpdf作成の手順をまとめた。
2011年07月30日(Sat)
■ tDiaryのテーマをUTF-8にしてみた。
tDiaryのテーマ（css）が、github上で見ると、コメントが文字化けしている。これは、githubがUTF-8なファイルしか対応していない一方、tDiaryのテーマはUTF-8化しないで、euc-jpのものが多いため。
euc-jpにしている理由のひとつは、わたしの予想では、IEがIE7までcss内に"@charset utf-8"と記述されたものをきちんと表示していなかったためかと思われる。また、携帯でも一部、いまだUTF-8未対応なブラウザがあるらしい。（未検証）
だけれど、IE8でUTF-8なCSSに対応するようになっているし、tDiaryのHTMLはすでにUTF-8だし、cssもUTF-8に追随しても、そろそろいいのではないかなぁ、と、思い、次の手順で、テーマのREADME/cssをutf-8に変換した。
gitから最新バージョンのテーマを取得
$git clone git://github.com/tdiary/tdiary-theme.git
変換前に確認
$find ./tdiary-theme -type f -name "*.css" -exec nkf --guess {} \; -print > css.log
$find ./tdiary-theme -type f -name "README" -exec nkf --guess {} \; -print > readme.log
$find ./tdiary-theme -type f -exec grep -l "charset \"euc-jp\"" {} \; > charset_euc-jp.log
css.logには、cssファイルの文字コードとパスが記載。 readme.logには、READMEファイルの文字コードとパスが記載。 charset_euc-jp.logには、cssファイルの一行目に "@charset "euc-jp""と指定されているファイルが記載。
変換
css/READMEは、UTF-8に変換。そして、cssファイル一行目を"@charset "utf-8""に置換。
$find ./tdiary-theme -type f -name "*.css" -exec nkf -w -w80 -Lu --overwrite {} \;
$find ./tdiary-theme -type f -name "README" -exec nkf -w -w80 -Lu --overwrite {} \;
$find ./tdiary-theme -type f -name "*.css" -exec grep -l "@charset \"euc-jp\"" {} \; -exec sed -i 1s/euc-jp/utf-8/ {} \;
変換後の確認
$find ./tdiary-theme -type f -name "*.css" -exec nkf --guess {} \; -print > css_utf8.log
$find ./tdiary-theme -type f -name "README" -exec nkf --guess {} \; -print > readme_utf8.log
$find ./tdiary-theme -type f -exec grep -l "charset \"euc-jp\"" {} \; > charset_utf-8.log
…で、ログレベルでは確認したのだけれど、動作の確認をする、theme/themebench.rhtml がわたしの環境では動かない＆内容が古いので、どうしようかなぁ…と、思っているところです。
