AMAgrammar <> PROgrammer

CSSのローディング・アイコンのコスト - Weblog - Hail2u.net

hail2uの長嶋さんによる、「ローディング表示する時はJSでDOM操作するけど、コスト高いからCSSで何とかしようよ」という提案。

デモでは、対象となる要素に、ローディングアイコンを描画する為の要素(「spinner」クラスのdiv要素)を含ませておいて、「:only-child」擬似クラスで表示非表示を切り替えるという手法。

しかし、これだとロード対象を読み込んだ後もローディング表示用の要素が無駄に残ってしまうのでイマイチ美しくないように思える。

下記期間にメンテナンスを実施いたします。

メンテナンス期間中は、ご利用いただけないサービスがございますのでご了承ください。

期間

2014年04月24日（木） 午前1時 から 午前6時

最終的なメンテナンス終了時刻は、作業状況によって前後する場合がございます。

範囲

• Seesaaブログへの記事投稿・閲覧など全般
• ((略))
• Seesaaブログで作成されたブログへのコメント投稿・トラックバック送信

以上、「メンテナンスのお知らせ（2014年4月24日実施）:Seesaaからのお知らせ」より。

という訳で、該当時間は御迷惑をかけますが宜しく御願いします。

2014年4月9日、 Windows XP サポート終了

という訳で、家の Windows XP を入れているPCはどうにかしなければならない。さてどうしたものか。

ここで、今まで使った事があるOS(ディストリビューションを含む)を振り返ってみた。幾つかはバージョンナンバーまで憶えていないが、大体、古い順に次のようになる。

1. 日本語MS-DOS (NEC PC-9800シリーズ用の奴。バージョンは忘れたが、 1.44MB FD が読めるようになる前のものだったのは確か。)
2. N88-BASIC(86) (ROM BASIC の方。)
3. Windows 95
4. Windows 98
5. Windows 98 SE
6. Windows 2000 (無印〜SP4)
7. KNOPPIX 3.2 日本語版
8. KNOPPIX 5.0.1 日本語版
9. Fedora
10. Windows XP (無印〜SP3)
11. Ubuntu Netbook Edition 10.04
12. Ubuntu 〜11.4
13. Windows Server
14. Cranchbang 10
15. Windows 8 (評価版)
16. Cranchbang 11

Windows 8 に移行するのはそれはそれで利点がある。どうもあまり評判がよろしくないスタート画面だが、私は悪くないと考えている。キーボード操作を主体としているので、多くのショートカットが用意されているのも利点。何よりも、PowerShellが使えるのがでかい。

しかし、Windowsだと開発関係のツールが使いにくいんだよね。Gitとか。開発関係のツールは大体*uixの文法を前提に作られていて、それがWindowsの文法と馴染みにくいという話なんだろうけど。

さて先ほどのリストを俯瞰してみると、BSD系の経験がない事に気づいた。開発関係ツールとの兼ね合いから*nix系が望ましいし、良い機会なので採用し、環境構築を試みた。

家の環境だとネットに繋がらない

家の環境だと FreeBSD 10.0-RELEASE を Live CD として起動しただけではネットにアクセスできない。例えばGoogleにpingを打ってみても 「cannot resolve www.google.com: Host name lookup failure」 と言われる。

具体的には、PC本体と無線LAN子機 (BUFFALO WLI-U2-G54HP) をUSBケーブルで接続、親機とはWPA2-PSKで接続している。ネット接続できないのは、多分、PC自体のLANポートとモデム/ルータを直接ケーブルで繋いでいないで、無線LANを使っているせいだろうと予想。今まで、所謂*nix系の Live CD はKNOPPIX、Ubuntuと、割と様々なデバイスに対して良きに計らってくれるタイプの物しか使った事が無かったのが仇となったか。散々調べまわる羽目になった。

結論から書くと

root@:~ # ifconfig wlan0 create wlandev rum0
wlan0: Ethernet address: 00:1d:73:a1:2d:dc
root@:~ # wpa_passphrase 0123456789AB XXXXXXXX > /var/wpa_supplicant.conf
root@:~ # vi /var/wpa_supplicant.conf
2j^c$key_mgmt=WPA-PSK<ESC>:wq<CR>
root@:~ # wpa_supplicant -B -i wlan0 -c /var/wpa_supplicant.conf
Successfully initialized wpa_supplicant
root@:~ # mkdir /tmp/bsdinstall_etc
root@:~ # touch /tmp/bsdinstall_etc/resolv.conf
root@:~ # dhclient wlan0
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
DHCPOFFER from 192.168.1.1
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.1.1
bound to 192.168.1.29 -- renewal in 86400 seconds.

で、ネットに繋がる(少なくともpingは打てる)ようになった。以下、調べた結果のメモ。

FreeBSD 10.0-RELEASE のインストールメディアは Live CD としても利用できる。実際に(既に何某かのOSが入っている)HDにインストールする前にその挙動を確認できて便利だが、困ったことにデフォルトのキーボードの設定が英字用のそれとなっている。常日頃から英字キーボードを利用しているならともかく、日頃、日本語のキーボードを使っている場合、キートップに印字されている物とは別の文字が出てくるのでとても切ない事になる。ので、毎回きちんと設定しなければならない。

以下で日本語の106キーボードに設定できる。

root@:~ # kbdcontrol -l /usr/share/syscons/keymaps/jp.106.kbd

「FreeBSD キーボード設定／カーネル設定など」に拠ると、「jp.106x.kbd」だと CAPS LOCK キーとCTRLキーが入れ替わるらしい。確かに、そういう風にキーを入れ替えて使う人も居ると聞く。他にも「jp.pc98.kbd」と「jp.pc98.iso.kbd」というのが在ったが、これは恐らく、昔なつかし国産機PC-98x1シリーズ関係だろう(手元にPC-98x1機は無いので確認出来ていないが)。

Ruby Weekly の Issue 183 で知ったが、Ruby製ビルドツール「Rake」の開発者である Jim Weirich 氏が亡くなられたそうだ。

Unless you've already heard the news on Twitter, it's with much sadness I pass on the news that Jim Weirich has died. Jim was not only a well known Rubyist as the creator of Rake, but also a respected teacher, speaker, mentor, and friend to many.

氏はGitHubに、2月20日0時46分にcommitしたコードをpushしている。氏の最後のcommitのページには、彼の死を悼む人々のコメントが沢山投稿されている。GitHub社も、特別にコメントをページ上部に掲載している。

さながら、このページが氏の墓標としての役割を果たしているかのようだ。

コードを書き生きるプログラマとして、その様は羨ましくもある。個人の最後の成果物が墓標のように機能する可能性には今まで気づかなかったが、割と「アリ」なのかも知れない。

願わくば、私も何時の日にか、その死に際して「墓標」に沢山の人々が集うような人間になりたいものだ。

この記事は、「Vim Advent Calendar 2013」の第77日目、通算2回目の担当記事である。

なお、昨日はosyo-manga(@manga-osyo)さんの「Vim Advent Calendar 2013: KaoriYa 版 Vim の +migemo を試してみた」だった。

更に、私のVAC2013担当記事1つめは「closesomewindow.vim – 条件に合うウィンドウを閉じる Vim plugin」だった。

最初に言っておく。

ごめんなさい。

ヒアドキュメントとは何か?

シェルスクリプトやその他大体のスクリプト言語に実装されている、以下のような機能のことである。

var = <<EOS
↑こういう風に、
  "<<" + 識別子
という形式で書いたら、
次に識別子と同じ文字列が現れるまでの、
全ての行の内容を、
一つの文字列として取得出来る

↓この"EOS"までがヒアドキュメント
EOS

どうも、PowerShellと出会ってからというもの、オブジェクト指向型でないコマンドラインシェルが時代遅れに見えて仕方ない天井冴太です。

Zshだと、ターミナルを開き直しても以前やったコマンドの履歴が参照出来て地味に便利。確かBashもそうだった気がする。PowerShellでは出来ないのか?とググって、以下の記事に辿り着いた。

PowerShell - このコマンドレット、この前実行した、ような・・・・・・ - Qiita

ふむふむ成る程。prompt関数内でGet-Historyした結果をExport-Csvして、それをImport-Csvするコードを自分のプロファイルのファイルに書き込めば可能と。

で、上記記事中のコードには、記事自体でも明記されているが、幾つかの問題点が残されている。

• 何も入力していない状態でEnterを押すと、一つ前の入力が保存される。
• ダブルクォーテーションマークのエスケープ処理が抜けている
• バージョン3.0未満だとExport-Csvに-Appendオプションが無い為、コードが少々複雑になる
• exit以外の方法でPowerShellを終了させると、直前の履歴が保存されない。

上2つは解決出来そうだ。3つ目もある程度は緩和出来そう。という訳でチャレンジ……出来た!

$historyFilePath = "~/.posh_history.csv"

Import-Csv $historyFilePath | Add-History

function prompt {
	$latestHistory = Get-History -Count 1
	if($script:lastHistory -ne $latestHistory) {
		$csv = ConvertTo-Csv $latestHistory

		if( -not(Test-Path $historyFilePath)) {
			Out-File $historyFilePath -InputObject $csv[0] -Encoding UTF8
			Out-File $historyFilePath -InputObject $csv[1] -Encoding UTF8 -Append
		}
		Out-File $historyFilePath -InputObject $csv[-1] -Encoding UTF8 -Append

		$script:lastHistory = $latestHistory
	}

	return "$pwd >"
}

• 入力無しEnterで重複する履歴が保存されるのは、その時には履歴情報の更新が行われないから。毎回、直前の履歴を$script:lastHistoryに格納しておき、それと現在の最新の履歴を比較する事で、履歴の更新の有無を判断している。
• 元のコードでは、追記するレコードをマニュアルで構築してる。故にエスケープ処理の抜けが発生しているのだが、CVSへの変換だけであればConvertTo-Csvが使える。ConvertTo-Csvの結果の最終行を取り出せば、それが求めるレコードの内容となる。
• 同様に、元のコードではマニュアルで構築しているCSVファイルのヘッダ(シリアライズした型の名前、各フィールドに対応するメンバの名前)2行も、ConvertTo-Csvの結果の先頭2行が使える。

後は、現状prompt関数に直書きしているのを別の関数に独立させれば、なおシンプルになるだろう。

しかし、そもそも履歴のファイルへの保存が追記でないといけないのかは疑問。PowerShellで記憶出来る履歴の最大件数は$MaximumHistoryCountに設定された値(デフォルトは64)で、それを超えると古いものから捨てられる。ファイルに保存されている履歴の件数が$MaximumHistoryCount以下であれば問題ないが、それを超えると、古い情報は無意味になり、しかもファイルは際限なく太っていく。情報を追加するだけのAdd-Historyではなく、実行も行うInvoke-Historyを使うというならば話は別だが、毎回上書きした方が良いのではないかと思う。エクスポートの為のコードも、「Get-History | Export-Csv -Path $historyFilePath」だけで済むしね。

• MinGW | Minimalist GNU for Windows
• GCC for both x64 & x86 Windows! - MinGW-w64

ある思いつきがあって、それが実現出来るのか確認する為に、 Win32 API を使ったコードを書いてる。

MinGWのgcc環境下で書いているのだが、Winternl.hが無いと怒られる。mingw32-w32apiパッケージを導入すればいいのかと思ったがそうでもない。

ググってみると、Rubinius開発者のIRCチャットログと思しき物がヒット。

00:08:29	natte	src/mutex.c:2:22: fatal error: winternl.h: No such file or directory
00:09:02	natte	strange seems like the platform SDK is missing, thought that would come with VS Ultimate but I guess not
00:33:46	brixen	I think you're using mingw
00:33:51	brixen	instead of mingw-w64
00:37:13	natte	oh crap
00:37:17	natte	you are correct

どうも、MinGWとは別にMinGW-w64というプロジェクトがあって、そっちを使えばいいらしい。

「個々のコンパイラ?Wolfram Mathematica 9 ドキュメント」曰く。

MinGW

CCompilerDriverパッケージはWindowsにおけるGCCのネイティブWindowsポートであるMinGW(http://www.mingw.org)について，Windowsプラットフォーム上でテストされている．このソースのMinGWは64ビットバイナリを生成しないことに注意されたい．この機能は汎用Cコンパイラのセクションに記載のMinGW-w64で提供される．

64ビットターゲット用MinGW

http://www.mingw.orgで入手できるコンパイラはWindowsの32ビットおよび64ビットの両方で動作するが，現時点では32ビットバイナリのみをコンパイルする．64ビットWolframライブラリを生成するためには，MinGW-w64（http://mingw-w64.sourceforge.netから入手可能）という別のプロジェクトを使う．

ううむ、MinGWとMinGW-w64が別物だという事は把握したが、何故、別になっているのか。MinGW-w64が(その名の通り)64ビット環境専用というのならば解るが、そういう訳でもないらしい。理由が分からんので若干モヤモヤする……

というか、導入するのが面倒くさいで御座る! MinGW関係のディレクトリにPATH通してるから、単純にインストールとPATH設定だけだと競合して変な事になるのが目に見えるてるで御座る!

あるC++プログラムをMinGWのGCCでコンパイルしようとしたら、吐き気がする程の大量のエラーメッセージが表示された。いやいやエラーになるにしてもこの量は有り得ないわ。何かが悪さしてるんじゃないか。

で、試しに超簡単なコード書いてコンパイルしてみようとしたらコケる。

> type test.cpp
#include <iostream>

int main(int argc, char *argv[])
{
		std::cout << "hello" << std::endl;
		return 0;
}

> gcc test.cpp
C:/Program Files/Haskell Platform/2012.4.0.0/mingw/bin/ld.exe: cannot open outpu
t file a.exe: Permission denied
collect2: ld returned 1 exit status

> g++ test.cpp
Info: resolving std::cout  by linking to __imp___ZSt4cout (auto-import)
c:/program files/haskell platform/2012.4.0.0/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line.
This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.