相変わらず基本 T/O なのですが、恥を忍んでもうちょい書きます。
もはやこのブログは、自らの知識のなさと頭の回転の遅さを
嘆く場所と化しております。
さて。最近 Windows でちょっと開発しなくちゃいけなくなりまして。
Chocolatey で Git for Windows (v2.11.0) とか
ConEmu (v16.12.6.0)とかを入れてみたんです。
それで Git bash を直接、あるいは ConEmu を通して起動したんですが、
どうも日本語がおかしい。
それも、?????? という文字化けでも、
□□□ というようなトウフ化でもなく、
''$'\346\227\245\346\234\254\350\252\236''.txt'
といったような表示のされ方をしていました
（上記は 日本語.txt というファイル名の例です）。
どうも、UTF-8の数値コードといいますか、
バイト表現がそのまま数字で出ている感じでした。
文字化けやトウフの対処は検索ですぐ見つかったのですが
（例えば、lsコマンドは ls --show-control-chars としろとか、
使うフォントを日本語対応のものに変えろとか）
私のような症状はみつからず。
で、しばらく試行錯誤してからようやく気付きました。
これ単に locale がUTF-8に対応していないだけなのでは・・・？
というわけで locale コマンドをたたいてみると、
$ locale
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
ですよねー。
というわけで ConEmu の場合、
export LC_ALL=ja_JP.UTF-8
と打って locale 設定を上書きする形で無事解決。
Git bash だとそれだけだとなんかうまく動かなかったような気がする？ので、
タイトルバーを右クリックして現れたメニューから Option 画面を開き、
左のリストから「Text」 を選んで、
Locale と Character set を ja_JP / UTF-8 にし、
起動しなおしたら直りました。
最初に疑うべきところを疑わなかった私が悪いっていうことで、
皆さんは私のように時間を無駄にしないようにしていただければと思います。
2016年12月11日日曜日
2016年6月4日土曜日
Youtube動画埋め込みを最大サイズ指定しつつレスポンシブにする （インラインスタイルver）
よくあるやつなんですけど、インラインで style 指定してしまうやつのメモです。良い子はマネしちゃいけません。
<div style="max-width:560px">
<div style="position:relative; width:100%; padding-top:56.25%;">
<iframe style="position:absolute; top:0; left:0; width:100%; height:100%;" src="https://www.youtube.com/embed/CmRih_VtVAs" frameborder="0" allowfullscreen=""></iframe>
</div>
</div>
<div style="max-width:560px">
<div style="position:relative; width:100%; padding-top:56.25%;">
<iframe style="position:absolute; top:0; left:0; width:100%; height:100%;" src="https://www.youtube.com/embed/CmRih_VtVAs" frameborder="0" allowfullscreen=""></iframe>
</div>
</div>
2016年4月17日日曜日
スリープ中に電源が勝手にシャットダウンする症状が、WiFiドライバーを更新してみたら出なくなった話
もはや、「自分と同じ問題に直面した人がいたら助けになるように」という趣旨に
変わってきているこのブログですが、今度は悪名高き Kernel-Power41エラー (KP41エラー)と戦った話です。
先日、Windows10 入りのラップトップをマウスコンピューターでいろいろカスタマイズして注文したのです。
届いてからいろいろセッティングしてみたのですが、おかしいことが一つ。
スリープ中に電源が勝手にシャットダウンしているのです。
おかしいなあと思いいろいろ調べた結果、これはKP41病なのではという疑いが。
（KP41エラーについては、検索してみればいろいろ引っかかると思います）
というわけでイベントビューワーで調べてみました。
- スタートメニュー、というか窓のアイコンを右クリック
- 「イベントビューワー」をクリックして起動
- カスタムビュー > 管理イベント から怪しいイベントがないか探る
というわけでビンゴ。
 |
| Kernel-Power 41 エラー |
どうも、 Thinkpad で自分と同じようにスリープ中に電源が切れる症状が出たけど、
Intel の WiFi のドライバーを再インストールしたら直ったよ、とのこと。
なるほどそういえば、注文時に無線LANモジュールが在庫の関係で
"インテル(R) Dual Band Wireless-AC 3165" に勝手にアップグレードされていたなと思い出し、
デバイスマネージャからドライバの更新を試してみることにしました。
- スタートメニュー、というか窓のアイコンを右クリック
- 「デバイスマネージャ」をクリックして起動
- 一覧の中から「ネットワークアダプター」以下にある Intel の WiFi ドライバーを見つけ、右クリックのメニュー、またはプロパティの「ドライバ」タブ内からドライバーを更新
 |
| WiFiドライバの更新 |
これで症状が出なくなりました（少なくとも、更新した後からこの記事を書くまでの約一週間のあいだは）。
というわけで、同じような症状にハマっている方は試す価値はあるのではないでしょうか？
2015年4月28日火曜日
msysGit のインストールで [po/bg.msg] Error 253 が出たら環境変数にLANG=CでOK
T/O・・・といいたいのですがもうちょいまともに書くことにしましょう。
久しぶりの更新過ぎて何を書けばいいんだという感じではありますが。
先日、 Windows に msysGit を入れようとしたんです。
https://msysgit.github.io
Git for windows ではなく、ページの下のほうにある Contributer 用の msysGit の方です。
Contribute する気は特にないのですが・・・
それで、msysGit-netinstall-1.9.5-preview20150319.exe なるインストーラを実行していたら、
その途中にこんな感じのエラーが出ました。
Generating catalog po/bg.msg
msgfmt --statistics --tcl po/bg.po -l bg -d po/
302 ﾂﾌ|bZ[W.
make[1]: *** [po/bg.msg] Error 253
make: *** [all] Error 2
何のことやら？というエラーだったのですが、
以下の forum のやり取りによれば、 「環境変数に LANG = C入れろ」 との事。
https://groups.google.com/forum/#!msg/msysgit/leSx-cJMv2A/Q9cxYCegxTQJ
マジでか・・・Windows の環境変数に LANG = C を入れるのか・・・
というわけで、コントロールパネルからシステムのプロパティーを開き、
「環境設定」タブの下のほう、「環境変数」ボタンから設定画面を出し、変数：LANG 値：C を設定。
msysgit ディレクトリ直下 の msys.bat （私の場合 C:\msysgit\msys.bat) を再実行し、
git ディレクトリに移動して（私の場合 C:\msysgit\git）
make clean してからの make all でうまくいきました。
日本語の情報が見つからなかったので、備忘録として一応置いておきますよ。
久しぶりの更新過ぎて何を書けばいいんだという感じではありますが。
先日、 Windows に msysGit を入れようとしたんです。
https://msysgit.github.io
Git for windows ではなく、ページの下のほうにある Contributer 用の msysGit の方です。
Contribute する気は特にないのですが・・・
それで、msysGit-netinstall-1.9.5-preview20150319.exe なるインストーラを実行していたら、
その途中にこんな感じのエラーが出ました。
Generating catalog po/bg.msg
msgfmt --statistics --tcl po/bg.po -l bg -d po/
302 ﾂﾌ|bZ[W.
make[1]: *** [po/bg.msg] Error 253
make: *** [all] Error 2
何のことやら？というエラーだったのですが、
以下の forum のやり取りによれば、 「環境変数に LANG = C入れろ」 との事。
https://groups.google.com/forum/#!msg/msysgit/leSx-cJMv2A/Q9cxYCegxTQJ
マジでか・・・Windows の環境変数に LANG = C を入れるのか・・・
というわけで、コントロールパネルからシステムのプロパティーを開き、
「環境設定」タブの下のほう、「環境変数」ボタンから設定画面を出し、変数：LANG 値：C を設定。
msysgit ディレクトリ直下 の msys.bat （私の場合 C:\msysgit\msys.bat) を再実行し、
git ディレクトリに移動して（私の場合 C:\msysgit\git）
make clean してからの make all でうまくいきました。
日本語の情報が見つからなかったので、備忘録として一応置いておきますよ。
2012年5月6日日曜日
Objective-C のコードの循環的複雑度を測るツール
職場で Objective-C のコード (つまり iPhone アプリ) を書いているのですが、
その循環的複雑度 (Cyclomatic Complexity) を測りたいなあと思い立ち、
無料で使えるツールが無いかなあと思って探したところ、次のツールが見つかりました。
headerfile-free-cyclomatic-complexity-analyzer
http://code.google.com/p/headerfile-free-cyclomatic-complexity-analyzer/
2012/05/06現在、最新は hfcca14.py です。
拡張子でお分かりの通り、Pythonで書かれたツールです。
Objective-C を使っているなら、たいていの場合 MacOS X 上 で作業しているでしょうから、
その場合は Python がそもそも入っているので問題なく使えると思います。
使い方は上記のページで大体わかると思いますが、
python hfcca14.py filename.m
てな感じでやるだけです。ディレクトリ指定や複数指定ももちろん可能です。
オプションはいろいろありますが、出力結果のしきい値を変更する -C は特に重要です。
あるしきい値 (デフォルトは15) 以上の複雑度を持つ関数が存在する場合、
実行結果に警告として表示されるのですが、例えばしきい値を 20 としたい場合には、
python hfcca14.py -C 20 filename.m
とかやればOKです。
"header-file-free" と書いてあるように、このツールは若干簡易的な測り方をしているようで、
ヘッダファイルは無視されますし、
また#defineで書かれたマクロなどの展開を（デフォルトでは）行わないようです。
まあ、実用上はそれで十分かなと思います。
あと、裏話ですが、Objective-C サポートしているといいつつ、
Objective-C 特有の関数シグニチャの解析が微妙だったせいで、
実行結果で表示される関数名がめちゃくちゃだったので、
作者にそれを修正するパッチ送ったら採用してくれました（それが上記の最新版です）。
これ以外にも色々探したのですが、
中々 Objective-C をサポートしているツールが見つからないんですよね。
他によいものがあればぜひお教え下さい。
2012年4月30日月曜日
循環的複雑度 ( Cyclomatic Complexity ) とは何ぞや
注意:この記事だけアクセスが多くて逆に不安になっております。
不正確な記述が含まれる可能性が大なので、必ずほかの記事も当たっていただければと思います。
今回は、循環的複雑度（Cyclomatic Complexity）について書きます。
これは、ソースコードのメトリクス（定量的に評価した値）の一つです。
条件複雑度（Conditional Complexity）とも呼ばれます。
簡単なメトリクスとしては、関数の行数やコメント行数など単純なものもありますが、
循環的複雑度はもう少し"プログラムの内容を考慮した"メトリクスです。
循環的複雑度とは、一言で言うと、
"あるひとつの関数がどれだけ複雑か"度
です。もう少し詳しく言えば、
"あるひとつの関数について、どれぐらい分岐があるか" 度
を表す数値です。
プログラムの中の各関数について、この複雑度の数値が計算されます。
Wikipediaに書いてあるようなフォーマルな定義だと、
"関数の制御フローを有効グラフとして書いたときの、(グラフの辺数) - (グラフの頂点数) + 2×(連結コンポーネント数)"
という感じで、「定義自体が複雑じゃボケ！」と言いたくなってしまいます。
（フォーマルな定義はそれはそれで面白い部分があるので時間があれば紹介するかもしれません。
なぜ循環的複雑度と呼ぶのか、もそちらに従っていますので。）
実際のところはもっともっと簡単に計算できます。
NDepend という .NET 向けのメトリクス計測ツールでは、以下のように計測しているとしています。
（http://www.ndepend.com/Metrics.aspx#CC による）
関数の循環的複雑度 = 1 + 関数の中に以下のものが出てきた回数：
if、while、for、foreach、case、default、continue、goto、&&、||、catch、?: (三項演算子)、??
つまり "デフォルトの複雑度は 1 で、分岐が発生するたびに 1 増やすよ" といっているだけです。
自分が知っている別のツールでも同じような感じですので、結局これで十分ということのようです。
非常に簡単でわかりやすい尺度です。
値が小さければ小さいほど、その関数には分岐は少なく、構造が単純で理解がしやすい、ということになります。
逆に、値がデカければデカいほど、分岐が多く、構造が複雑で理解がし辛い、というわけです。
テストに必要なテストケースの数もこれに直結しています。
例えば、次の（無意味な）関数 foo の複雑度は 5 です（if や for 等を数えればすぐわかると思います）。
「良いプログラム」ならば「（その中の各関数の）循環的複雑度が小さい」は大抵の場合正しいと思います。
読みやすくなるように考えて作られたプログラムであれば、
ある程度の処理の単位で関数化が行われているはずであり、
結果としてひとつの関数内の分岐の数（＝複雑度の値）はある程度で抑えられているはずだからです。
対偶を取ると、「循環的複雑度が大きい」ならば、「良くないプログラムである」ということです。
逆に、「循環的複雑度が小さい」ならば「良いプログラム」であるか、といえば私はそうは思いません。
これは、コーディングルールに似ています。
良いプログラムはコーディングルールを守って書かれているでしょうが、
コーディングルールが守られているからといって必ずしも良いプログラムとは言えません。
コーディングルールをちゃんと守る事も、複雑度をある程度で抑えることも、
どちらも単にコーディングをする上で守るべき最低限の事をしているに過ぎないからです。
ただ、性質上どうしても複雑度が大きくなってしまう処理や、
人の目にはそこまで複雑には見えなくても、複雑度の計算結果は大きくなる処理があります。
特に swich-case や if文 の中に || や && が多くある場合は顕著です。
例えば、以下の例はその典型例でしょう。
stackoverflow - why would I refactor this code as Cyclomatic Complexity is 58
もちろん、複雑度を一定以下に抑えるように関数／コードを書くことは推奨されてしかるべきですが、
その一方で、ある一つの絶対的なしきい値を設けて
「複雑度がそれ以上になる関数は絶対禁止」とするのはやりすぎかなと考えます。
あくまでも目安としてしきい値を設定しておいて、
それを超える関数については分割などのリファクタリングを検討するようにする、という程度が良いと思っています。
一応、一般的に言われているのは次のような基準です。参考程度に。
個人的には 20 以上だとちょっと嫌だな、という感じです。
まあ、普通に考えて書いていれば、基本的に 10 以内に収まると思います。
ちなみに、職場で見つけた一番ヤバかったのは 47 の関数でした
（そこは後でリファクタリングにより20まで落としましたが）。
stackoverflowだと、171 の関数を見たことがあるよ、という投稿があったりしたので、
それに比べると全然マシなのかな、という気もしてきます。
stackoverflow - What is the highest Cyclomatic Complexity of any function you maintain? And how would you go about refactoring it?
余談。
循環的複雑度はあくまで、一つの関数に対してその複雑度を測っています。
なので、ある関数の一部を切り出して関数化してあげるだけで、複雑度の値は落ちます。
「全体の処理の流れ自体は変わっていないのに、小手先で複雑度の値を下げて意味はあるのか？」
という議論もあるかと思います。
一理あるのですが、以下のようなメリットはあると思います。
参考
http://ja.wikipedia.org/wiki/循環的複雑度
http://en.wikipedia.org/wiki/Cyclomatic_complexity
http://www.teknologika.com/blog/what-the-heck-is-cyclomatic-complexity/
http://www.ndepend.com/Metrics.aspx#CC
http://ishare.intellicorp.com/cs/cto/b/ctrueman/archive/2011/08/20/estimating-the-complexity-of-abap-programs-the-good-bad-and-ugly.aspx
http://stackoverflow.com/questions/911637/what-is-cyclomatic-complexity
不正確な記述が含まれる可能性が大なので、必ずほかの記事も当たっていただければと思います。
今回は、循環的複雑度（Cyclomatic Complexity）について書きます。
これは、ソースコードのメトリクス（定量的に評価した値）の一つです。
条件複雑度（Conditional Complexity）とも呼ばれます。
簡単なメトリクスとしては、関数の行数やコメント行数など単純なものもありますが、
循環的複雑度はもう少し"プログラムの内容を考慮した"メトリクスです。
循環的複雑度とは、一言で言うと、
"あるひとつの関数がどれだけ複雑か"度
です。もう少し詳しく言えば、
"あるひとつの関数について、どれぐらい分岐があるか" 度
を表す数値です。
プログラムの中の各関数について、この複雑度の数値が計算されます。
Wikipediaに書いてあるようなフォーマルな定義だと、
"関数の制御フローを有効グラフとして書いたときの、(グラフの辺数) - (グラフの頂点数) + 2×(連結コンポーネント数)"
という感じで、「定義自体が複雑じゃボケ！」と言いたくなってしまいます。
（フォーマルな定義はそれはそれで面白い部分があるので時間があれば紹介するかもしれません。
なぜ循環的複雑度と呼ぶのか、もそちらに従っていますので。）
実際のところはもっともっと簡単に計算できます。
NDepend という .NET 向けのメトリクス計測ツールでは、以下のように計測しているとしています。
（http://www.ndepend.com/Metrics.aspx#CC による）
関数の循環的複雑度 = 1 + 関数の中に以下のものが出てきた回数：
if、while、for、foreach、case、default、continue、goto、&&、||、catch、?: (三項演算子)、??
つまり "デフォルトの複雑度は 1 で、分岐が発生するたびに 1 増やすよ" といっているだけです。
自分が知っている別のツールでも同じような感じですので、結局これで十分ということのようです。
非常に簡単でわかりやすい尺度です。
値が小さければ小さいほど、その関数には分岐は少なく、構造が単純で理解がしやすい、ということになります。
逆に、値がデカければデカいほど、分岐が多く、構造が複雑で理解がし辛い、というわけです。
テストに必要なテストケースの数もこれに直結しています。
例えば、次の（無意味な）関数 foo の複雑度は 5 です（if や for 等を数えればすぐわかると思います）。
「良いプログラム」ならば「（その中の各関数の）循環的複雑度が小さい」は大抵の場合正しいと思います。
読みやすくなるように考えて作られたプログラムであれば、
ある程度の処理の単位で関数化が行われているはずであり、
結果としてひとつの関数内の分岐の数（＝複雑度の値）はある程度で抑えられているはずだからです。
対偶を取ると、「循環的複雑度が大きい」ならば、「良くないプログラムである」ということです。
逆に、「循環的複雑度が小さい」ならば「良いプログラム」であるか、といえば私はそうは思いません。
これは、コーディングルールに似ています。
良いプログラムはコーディングルールを守って書かれているでしょうが、
コーディングルールが守られているからといって必ずしも良いプログラムとは言えません。
コーディングルールをちゃんと守る事も、複雑度をある程度で抑えることも、
どちらも単にコーディングをする上で守るべき最低限の事をしているに過ぎないからです。
ただ、性質上どうしても複雑度が大きくなってしまう処理や、
人の目にはそこまで複雑には見えなくても、複雑度の計算結果は大きくなる処理があります。
特に swich-case や if文 の中に || や && が多くある場合は顕著です。
例えば、以下の例はその典型例でしょう。
stackoverflow - why would I refactor this code as Cyclomatic Complexity is 58
もちろん、複雑度を一定以下に抑えるように関数／コードを書くことは推奨されてしかるべきですが、
その一方で、ある一つの絶対的なしきい値を設けて
「複雑度がそれ以上になる関数は絶対禁止」とするのはやりすぎかなと考えます。
あくまでも目安としてしきい値を設定しておいて、
それを超える関数については分割などのリファクタリングを検討するようにする、という程度が良いと思っています。
一応、一般的に言われているのは次のような基準です。参考程度に。
- 1-10 : シンプルで、リスクが小さい関数
- 11-20 : 中程度の複雑さとリスクの関数
- 21-50 : 複雑、リスクが高い関数
- 50以上 : マジでヤバイ関数
個人的には 20 以上だとちょっと嫌だな、という感じです。
まあ、普通に考えて書いていれば、基本的に 10 以内に収まると思います。
ちなみに、職場で見つけた一番ヤバかったのは 47 の関数でした
（そこは後でリファクタリングにより20まで落としましたが）。
stackoverflowだと、171 の関数を見たことがあるよ、という投稿があったりしたので、
それに比べると全然マシなのかな、という気もしてきます。
stackoverflow - What is the highest Cyclomatic Complexity of any function you maintain? And how would you go about refactoring it?
余談。
循環的複雑度はあくまで、一つの関数に対してその複雑度を測っています。
なので、ある関数の一部を切り出して関数化してあげるだけで、複雑度の値は落ちます。
「全体の処理の流れ自体は変わっていないのに、小手先で複雑度の値を下げて意味はあるのか？」
という議論もあるかと思います。
一理あるのですが、以下のようなメリットはあると思います。
- 関数化して適切な名前をつけることで読みやすくなる
- 関数が分かれればそれだけテストしやすくなる
参考
http://ja.wikipedia.org/wiki/循環的複雑度
http://en.wikipedia.org/wiki/Cyclomatic_complexity
http://www.teknologika.com/blog/what-the-heck-is-cyclomatic-complexity/
http://www.ndepend.com/Metrics.aspx#CC
http://ishare.intellicorp.com/cs/cto/b/ctrueman/archive/2011/08/20/estimating-the-complexity-of-abap-programs-the-good-bad-and-ugly.aspx
http://stackoverflow.com/questions/911637/what-is-cyclomatic-complexity
2012年4月1日日曜日
node-websocket-server と Firefox11 とで通信するとうまく動かない？
!!!注!!! この記事は書かれたのが2012年4月とかなり古いです。状況は大幅に変わっていると思いますので、参考程度でお願いします。
最近ちょっとnode.jsをローカルに入れて弄っています。
で、WebSocketとやらを実験的に触ってみようと、
よく紹介されている node-websocket-server というパッケージを npm で入れてみました。
しかし、なんだかローカルのnode.jsサーバー + node-websocket-server と
Firefox11 とを通信させようとしてもうまく動かなくて困ってしまいました。
調べてみると、node-websocket-server の本家はここみたいです。
https://github.com/miksago/node-websocket-server
ただ、作者が忙しいみたいで、最近は更新が止まっています。
代わりにそれをforkした以下だともう少し先に進んでいます。
https://github.com/VanCoding/node-websocket-server
（node.js で 出来るだけ最新の node-websocket-server を使う。 の記事を参考にさせていただきました）
上記のは一応、websocket protocolの draft 16 まで対応してます、という体です。
wikipediaによれば、Firefox 11やChrome16以降では RFC6455 (draft17 の次、ほぼ最終版?) に従った実装がされているので、
後者のパッケージの方を使えば、比較新しいしちゃんと動くのかなあと期待したわけです。
で、改めてこれを入れてみて動かしてみたのですが・・・
うーん。やっぱりFirefox 11では動かない。
ふと思いついて、試しにChrome 16を使ってみると・・・なんとうまく動いてしまいました。
えっ？ なんで？ なんでなの！？
混乱しながらlogを仕込んで調べてみたら、さらに次のようなことがわかりました。
WebSocketのシェイクハンド時に用いるHTTPヘッダの Connection フィールドについて、
昔のdraftでは "Upgrade" というトークンのみが入っていることが期待されていたようです。
しかし、比較的新しい仕様 (draft13 以降) では、
"Upgrade" が含まれていれば他のトークンも含まれてよいことになっています。
Firefox11ではそれに従い、
Connection: Keep-alive, Upgrade
と入っているみたいです。
結果として（昔のdraftに従って書かれた) node-websocket-serverだと
シェイクハンド時のチェックで invalid 扱いになりはじかれてしまいます。
具体的には、node-websocket-server の lib/ws/server.js にある、次の行の部分です。
そのチェックコードを以下のように弄ったら、Firefoxでもうまく動きました。うわーい。
（修正は faye-websocket-node のコードを参考にしています）
パッケージとして公開するならもっとちゃんとメンテしてくれないと困る、というお話でした。
最近ちょっとnode.jsをローカルに入れて弄っています。
で、WebSocketとやらを実験的に触ってみようと、
よく紹介されている node-websocket-server というパッケージを npm で入れてみました。
しかし、なんだかローカルのnode.jsサーバー + node-websocket-server と
Firefox11 とを通信させようとしてもうまく動かなくて困ってしまいました。
調べてみると、node-websocket-server の本家はここみたいです。
https://github.com/miksago/node-websocket-server
ただ、作者が忙しいみたいで、最近は更新が止まっています。
代わりにそれをforkした以下だともう少し先に進んでいます。
https://github.com/VanCoding/node-websocket-server
（node.js で 出来るだけ最新の node-websocket-server を使う。 の記事を参考にさせていただきました）
上記のは一応、websocket protocolの draft 16 まで対応してます、という体です。
wikipediaによれば、Firefox 11やChrome16以降では RFC6455 (draft17 の次、ほぼ最終版?) に従った実装がされているので、
後者のパッケージの方を使えば、比較新しいしちゃんと動くのかなあと期待したわけです。
で、改めてこれを入れてみて動かしてみたのですが・・・
うーん。やっぱりFirefox 11では動かない。
ふと思いついて、試しにChrome 16を使ってみると・・・なんとうまく動いてしまいました。
えっ？ なんで？ なんでなの！？
混乱しながらlogを仕込んで調べてみたら、さらに次のようなことがわかりました。
WebSocketのシェイクハンド時に用いるHTTPヘッダの Connection フィールドについて、
昔のdraftでは "Upgrade" というトークンのみが入っていることが期待されていたようです。
しかし、比較的新しい仕様 (draft13 以降) では、
"Upgrade" が含まれていれば他のトークンも含まれてよいことになっています。
Firefox11ではそれに従い、
Connection: Keep-alive, Upgrade
と入っているみたいです。
結果として（昔のdraftに従って書かれた) node-websocket-serverだと
シェイクハンド時のチェックで invalid 扱いになりはじかれてしまいます。
具体的には、node-websocket-server の lib/ws/server.js にある、次の行の部分です。
そのチェックコードを以下のように弄ったら、Firefoxでもうまく動きました。うわーい。
（修正は faye-websocket-node のコードを参考にしています）
パッケージとして公開するならもっとちゃんとメンテしてくれないと困る、というお話でした。
2012年3月24日土曜日
VirtualBoxの仮想ハードディスクのサイズを増やす
Virtual Box上の仮想マシンにUbuntu 11.10 を入れているのですが、
その仮想ハードディスクのサイズが8GBと小さめだったせいで
いつの間にかキツキツになってしまったので、ディスク容量を増やしてみました。
参考にしたのは以下のサイトです。
VirtualBoxでハードディスク容量を増やす
【Ubuntu】Virtualbox の仮想ハードディスクの容量を増やす方法 [ubuntu]
[linux]/etc/fstabの設定方法
上記を組み合わせたり自己流（という名のミス訂正）でやったので、
自分の流れだとこんなでした。
VBoxManage は clonehd じゃなくて modifyhdでやったほうが楽だったかもですが。- VirtualBoxで新しい仮想ディスク(20GB)を持つ新しい仮想マシンを作成する
- ”C:\Program Files\Oracle\VirtualBox\VBoxManage.exe” clonehd OLD.vdi NEW.vdi --existing で、 古い仮想ディスクから新しい仮想ディスクへ内容コピー
- パーティションもコピーされている都合上、このままでは新しい仮想ディスクも8GBしか使えないままになってしまうので、パーティションを操作することに
- 新しい仮想マシン (with 新しい仮想ディスク) に対し、 Live CD として Ubuntuのiso を用いて起動し、その上でgpartedを起動
- そのままじゃリサイズできないのでswap領域 (/dev/sda5) を一旦削除
- パーティションのリサイズ
- 削除したswap領域 (/dev/sda5) 作り直し
- 作り直したswap領域 (/dev/sda5) のマウント情報の書き換えをしなくちゃいけないのをすっかり忘れたまま、新しい仮想マシン上のUbuntu起動してしまう（ミス）
- あわてて sudo blkid で新しい /dev/sda5 (swap領域) の UUIDを調べ、 /etc/fstab の記述を書き換える
- Ubuntuを再起動し、 swapon -s でswap領域が認識されているかを確認して一安心
2012年3月22日木曜日
ぼくが かんがえた さいきょうの ぷれぜんてーしょん かんきょう
以下は実話です。
どうしこうなってしまったのかと、正直反省してます。
・・・嘘です。反省する気はありません。
Windows、Linux(のディストロであるUbuntu)、MacOS(をベースにしたiOS)、
と主要OSを制覇しているほか、jQuery、Apache、TeXなど、
さまざまなテクノロジが組み合わさった画期的で馬鹿らしいシステムとなっています。
iPadにVNCクライアントを入れるのもやってみたんですが、
さすがにレスポンスが遅かったので却下しました。
どうしこうなってしまったのかと、正直反省してます。
・・・嘘です。反省する気はありません。
構成
- 無線ルータ Aterm 3500R
- Windows
- VirtualBox
- Ubuntu 11.10
- プレゼン用html/css/jsファイル
- jQuery.js : JSライブラリ、アニメーションに使った
- TeX + mathtex : 数式 -> 画像変換のためのcgi
- Apache : mathtexをcgiとして動かすため
- Firefox : プレゼン用HTMLの表示
- Ubuntu 11.10
- Splashtop Streamer : iPadのマウスアプリ TouchPad と連携をとる
- VirtualBox
- iPad2
- TouchPad : iPhone/iPadを、ローカルネットワーク上のPCのマウス代わりに出来るアプリ
- Windows
プレゼンの仕方
- Windwos上でUbuntuをフルスクリーンにする
- Firefoxをフルスクリーンにしてプレゼン用HTMLファイルを開く
- iPadをWindowsのマウス代わりし、操作しながら発表
- しゃべってる途中で噛んでしまいグダるがなんとかごまかす
- 発表後「アレは何で作ったんですか？」と訊かれてニヤつく
Windows、Linux(のディストロであるUbuntu)、MacOS(をベースにしたiOS)、
と主要OSを制覇しているほか、jQuery、Apache、TeXなど、
さまざまなテクノロジが組み合わさった画期的で馬鹿らしいシステムとなっています。
iPadにVNCクライアントを入れるのもやってみたんですが、
さすがにレスポンスが遅かったので却下しました。
2011年12月3日土曜日
Languages on JavaVM
最近JavaVM上の言語をよくみるようになったので、メモ
- Java
- とりあえず
- JavaFX
- 気づいたら増えていて、気づいたら消えていたような言語
- Scala
- 割とRubyを意識してるように感じる文法。型システムが強いらしい。
- Clojure
- Lispの方言な感じ言語
- Groovy
- テストでよく使われてると聞いたが……
- Ceylon
- よく知らないがBetter Javaな方向らしい
- Xtend
- Eclipseでがんばっている言語。パーサフレームワークを強化したらこうなったっぽい？
- Kotlin
- JetBrain(InteliJのところ)が作っている言語。やっぱりBetter Javaな方向。
おそらく幾つかの漏れがあるはずなので、見つけ次第追記します。
これを全部フォローするのは大変そう
おまけ？
- JRuby
- RubyのJVM実装。それなりに良いらしい
- Jython
- PythonのJVM実装。JRubyほど話を聞かない。逆に.NET実装のほうではIronPythonしか話を聞かない
2011年10月15日土曜日
Ubuntuセッティング
ディレクトリ名を英語表記に
ターミナルから"デスクトップ"とか打ってられないので
"Desktop"にしたいわけです。
端末より以下を入力してあとはいい感じに。
LANG=C xdg-user-dirs-gtk-update
参考：
http://ubulog.blogspot.com/2007/10/ubuntu.html
2011年9月13日火曜日
Project Lambda 現状
2011年8月28日日曜日
和訳： Project Lambda (前半)
注：この文書はProject Lambdaの提案を和訳したものです。訳の正確性は保証しません。
この文章におかしなところがあればオリジナルを参照してください。
Brian Goetz 2010/10/10
この文書はJava言語にラムダ式を追加する案です。このスケッチはMark Reinholdによって 2009/12に作られた原案をもとに作られました。前のバージョンは2010年7月に発表されました。
2011年8月13日土曜日
Facadeパターン : 隠蔽 or not 隠蔽？
デザインパターンねたの続きです。
Facadeパターンというものがあるんですが、一言で言えば、
「複数の（低水準な）オブジェクトをまとめて扱えるような（高水準な）窓口用クラスを作る」
というものです。
HeadFirstデザインパターンから例を引用すると、
低水準なコンポーネントである
アンプ、スピーカー、プロジェクタ、照明、・・・
といったものを、
高水準クラスである"ホームシアター"で一気に調整する、とかそんな感じです。
HeadFirstデザインパターンでは、
Facadeを使うクラスが、Facadeクラスに低水準コンポーネントを渡す、
という形で説明されています。
したがって、高水準な機能だけでは実現できないような"微調整"が必要なときには、
低水準コンポーネントに直接アクセスすることが可能である、と説明されています。
つまり、Java風擬似コードで言うとこうです。
Facadeとなるクラスの中で、privateに低水準コンポーネントを作る、ということをしています。
したがって、Facadeを使う側は、直接低水準コンポーネントを触れない、というわけです
(setterやgetterを作れば別ですが)。
特に、日本語版wikipediaでは低水準コンポーネントを隠蔽する点にしっかり言及しています。
擬似コードだとこんなです。
隠蔽するかしないかで、クラス図的にはほぼ同じでも、
正直相当違うんじゃないかと思うのですが、どうなんですかねえ。
どっちが正解とかそういうことは無いとは思うのですけども、
せっかく名前をつけている以上はっきりしておいてもらいたいなあと思います。
ま、そもそもFacadeパターンなんて、
わざわざ言われなくても勝手に使っているものにしか見えない、というそもそもの問題がありますが。
この辺の「何をいまさら」感は、Template methodパターンとどっこいどっこいでしょう。
Facadeパターンというものがあるんですが、一言で言えば、
「複数の（低水準な）オブジェクトをまとめて扱えるような（高水準な）窓口用クラスを作る」
というものです。
HeadFirstデザインパターンから例を引用すると、
低水準なコンポーネントである
アンプ、スピーカー、プロジェクタ、照明、・・・
といったものを、
高水準クラスである"ホームシアター"で一気に調整する、とかそんな感じです。
HeadFirstデザインパターンでは、
Facadeを使うクラスが、Facadeクラスに低水準コンポーネントを渡す、
という形で説明されています。
したがって、高水準な機能だけでは実現できないような"微調整"が必要なときには、
低水準コンポーネントに直接アクセスすることが可能である、と説明されています。
つまり、Java風擬似コードで言うとこうです。
class FacadeUser{
...
func(){
...
LowLevelComponent1 comp1 = new LowLevelComponent1();
LowLevelComponent2 comp2 = new LowLevelComponent2();
Facade facade = new Facade(comp1, comp2);
...
}
...
}
class Facade{
LowLevelComponent1 comp1;
LowLevelComponent2 comp2;
// constructor
Facade (LowLevelComponent1 comp1, LowLevelComponent2 comp2){
this.comp1 = comp1;
this.comp2 = comp2;
...
}
...
}
一方、wikipediaなんかでは、Facadeとなるクラスの中で、privateに低水準コンポーネントを作る、ということをしています。
したがって、Facadeを使う側は、直接低水準コンポーネントを触れない、というわけです
(setterやgetterを作れば別ですが)。
特に、日本語版wikipediaでは低水準コンポーネントを隠蔽する点にしっかり言及しています。
擬似コードだとこんなです。
class FacadeUser{
...
function(){
Facade facade = new Facade();
...
}
...
}
class Facade{
private LowLevelComponent1 comp1;
private LowLevelComponent2 comp2;
// constructor
Facade (LowLevelComponent1 comp1, LowLevelComponent2 comp2){
this.comp1 = new LowLevelComponent1();
this.comp2 = new LowLevelComponent2();
...
}
...
}
隠蔽するかしないかで、クラス図的にはほぼ同じでも、
正直相当違うんじゃないかと思うのですが、どうなんですかねえ。
どっちが正解とかそういうことは無いとは思うのですけども、
せっかく名前をつけている以上はっきりしておいてもらいたいなあと思います。
ま、そもそもFacadeパターンなんて、
わざわざ言われなくても勝手に使っているものにしか見えない、というそもそもの問題がありますが。
この辺の「何をいまさら」感は、Template methodパターンとどっこいどっこいでしょう。
2011年7月24日日曜日
Iteratorパターン
注意：
- この記事は適当に書かれています。あとでドリーが綺麗にまとめてくれます。
- この記事はC#erな人が書いています。
現在デザインパターンを勉強中なのですが，さて，デザインパターンの中で一番を選ぶとしたら一体なんなのでしょうか。私が思うにそれはIteratorパターンでしょう。Iteratorパターンはプログラムを書く中で，最もよく使われ，最も直接目にすることはなく，今でも最もHOTなパターンです。
このパターンは集合に対し統一的にアクセスする時によく使われる実装を形式的にまとめたものでした。しかし今ではJavaを初めとし様々な言語でその実装を隠蔽しforeachとして利用できるようになっています。
Iteratorパターンは何故よく使われるのか，それは集合に対して汎用的に利用できるパターンだからでしょう。しかし最近ではメソッドチェーンと呼ばれるプログラムの書き方が流行り，集合に対する操作は今まで以上にエレガントに表現されるようになりました。
http://www.atmarkit.co.jp/fdotnet/chushin/comparedataproc_01/comparedataproc_01_01.html
今までのプログラムと見た目がぜんぜん違う！でも大丈夫，内部的には普通にIteratorパターンが使われています。Iteratorは不滅です。Javaはエレガントな言語じゃないので今まで通りifと一緒に拡張for文(Java5.0より追加された構文)を使ってください。
Iteratorパターンはよく内部イテレータと外部イテレータに分けて説明されます。多くの言語では外部イテレータの利用が言語レベルでサポートされています。では内部イテレータはどこで使われるのでしょうか。実は別のパターン，Observerパターンに姿を変えて利用されることがあります。
Observerは例えばマウス座標の監視などに使われます。でもよく考えるとObserverは連続で通知されるマウスの座標というデータを順に処理しているだけです。そう，これはIteratorパターンと同様なのです。Iteratorパターンがデータをpullして処理しているのに対し，Observerは向こうからデータがpushされる，ただそれだけの違いです。
さて，そんな事が真面目に研究されているプロジェクトがあります。その名もReactiveExtension．ちょっと調べてみるとpull型をpush型に変えるだけでこれだけの違いが現れるのかとびっくりします。
発端の映像はこちら（英語でココだけ見ても普通のことしか言ってないように見える）
http://channel9.msdn.com/blogs/charles/erik-meijer-rx-in-15-minutes
Reactive Exntensionがむっちゃ詳しいブログ
http://neue.cc/
ここらへんを見るとウヒョーとなれること，請け合いです。
2011年7月18日月曜日
デザインパターン絶賛考え中
誰かさんが部屋に置いていったオライリーの「Head First デザインパターン」を読んでます。
いやーこれは良い本ですね。
まだ斜め読みレベルですが、よく出来た本だと思います。
でも手元にあるのが第一刷だからか、怒涛の誤植祭りになってます。
修正がかかっているでしょうし、新しいのを改めて手に入れようかなとも思っています。
あるいは、英語のペーパーバック版のほうが値段が安いのでそっちにしようかな・・・
とりあえず、この本を（一週間かけて）読み終わってから、
頭の中でデザインパターンをまとめてみたいと思います。
とりあえず、今考えているのは、Strategy/State/Commandパターンについてです。
この本には、StrategyとStateは双子だと書いてあるみたいです（まだそこまで読めてませんが）。
「デザインパターンを読み解く」では、
これにあわせてCommandも一緒だと指摘してあります。
確かに、ある関数（手続き/処理/アルゴリズム）をひとつのオブジェクトとして扱って、
交換や再利用などを楽にする、という方向性としては近いものを感じます。
手続きを状況に応じて入れ替える、というイメージだとStrategyに、
状態に応じて処理が切り替わっていくというイメージだとStateに、
それぞれをコマンドとみなして、キューにつんで実行していく、というイメージだとCommandになる、
というイメージを今のところは持っています。
Commandはともかく、Strategy/Stateではひとつの関数だけでなく
複数の関連する関数群をオブジェクトとしてまとめる、ということもあるでしょう。
その意味では、"Factory Methodを一まとめにしてオブジェクトにする"という
Abstract Factoryも、若干近い趣があるかもしれません。
まあ、まだまだ考え中です。
いやーこれは良い本ですね。
まだ斜め読みレベルですが、よく出来た本だと思います。
でも手元にあるのが第一刷だからか、怒涛の誤植祭りになってます。
修正がかかっているでしょうし、新しいのを改めて手に入れようかなとも思っています。
あるいは、英語のペーパーバック版のほうが値段が安いのでそっちにしようかな・・・
とりあえず、この本を（一週間かけて）読み終わってから、
頭の中でデザインパターンをまとめてみたいと思います。
とりあえず、今考えているのは、Strategy/State/Commandパターンについてです。
この本には、StrategyとStateは双子だと書いてあるみたいです（まだそこまで読めてませんが）。
「デザインパターンを読み解く」では、
これにあわせてCommandも一緒だと指摘してあります。
確かに、ある関数（手続き/処理/アルゴリズム）をひとつのオブジェクトとして扱って、
交換や再利用などを楽にする、という方向性としては近いものを感じます。
手続きを状況に応じて入れ替える、というイメージだとStrategyに、
状態に応じて処理が切り替わっていくというイメージだとStateに、
それぞれをコマンドとみなして、キューにつんで実行していく、というイメージだとCommandになる、
というイメージを今のところは持っています。
Commandはともかく、Strategy/Stateではひとつの関数だけでなく
複数の関連する関数群をオブジェクトとしてまとめる、ということもあるでしょう。
その意味では、"Factory Methodを一まとめにしてオブジェクトにする"という
Abstract Factoryも、若干近い趣があるかもしれません。
まあ、まだまだ考え中です。
2011年7月12日火曜日
くいずです（JavaScript apply編）
くいずです
pushを じっこう したとき あらーと で でる もじれつ なーんだ
こんなの一発で理解できたらすごいです。
元ネタ、というか参考サイト
pushを じっこう したとき あらーと で でる もじれつ なーんだ
var x =" World";
var o = { x: "He" };
function f(m){
for(var i = 0; i < arguments.length; i++){
m+=arguments[i];
}
m = this.x + m;
alert(m)
};
function push(){
f.apply(o,new Array("l","o",this.x));
};
こたえこんなの一発で理解できたらすごいです。
元ネタ、というか参考サイト
2011年7月10日日曜日
デザインパターンを（真の意味で）理解するために
デザインパターンを一通り勉強しようと、
日本語、英語問わずいろいろなウェブサイトを眺めているのですが、
いろいろとデザインパターンに対する疑問がわいてきました。
たとえば、有名なGoFの23パターンについて、
パターンの"粒度"もまちまちだし（一般的過ぎるものから、非常に限定された問題にのみ使えるものまで）、
分類の仕方もほかのやり方があるだろう、と感じました。
先人の知恵は示唆に富むものであることは重々承知なのですが、
深い理解のために知識を再構成することは非常に重要だと思うのです。
しかしながらウェブ上だと、
GoFの23パターンをずらずら説明しておしまい、みたいなところが多く見えます。
「もうちょっとなんか考えてから説明しろよ」と正直思ってしまいます。
で、いろいろ探して、参考になる（と現時点で思っている）次の2つを見つけました
デザインパターンを読み解く
Relationships between Design Patterns
前者は日本語のサイト、後者は英語で書かれた論文です。
どちらも、沢山あるデザインパターンの本質を考察し、
その位置づけや関係性を再構成しようとしています。
別にわかりやすくそれぞれのパターンを解説しているわけではないですし、
その解釈もこの両者で一致しているわけではありません。
しかしながら、このような努力は非常に素晴らしいものだと思いますし、
表面を舐めただけの解説よりも256倍ためになります。
今度からこれらのサイトを参考にしていきながら、
デザインパターンについてちょっと考えていきたいと思っています。
他にも参考になるものが見つかると尚良いのですが。
書籍のほうがまだマトモなのですかね？
日本語、英語問わずいろいろなウェブサイトを眺めているのですが、
いろいろとデザインパターンに対する疑問がわいてきました。
たとえば、有名なGoFの23パターンについて、
パターンの"粒度"もまちまちだし（一般的過ぎるものから、非常に限定された問題にのみ使えるものまで）、
分類の仕方もほかのやり方があるだろう、と感じました。
先人の知恵は示唆に富むものであることは重々承知なのですが、
深い理解のために知識を再構成することは非常に重要だと思うのです。
しかしながらウェブ上だと、
GoFの23パターンをずらずら説明しておしまい、みたいなところが多く見えます。
「もうちょっとなんか考えてから説明しろよ」と正直思ってしまいます。
で、いろいろ探して、参考になる（と現時点で思っている）次の2つを見つけました
デザインパターンを読み解く
Relationships between Design Patterns
前者は日本語のサイト、後者は英語で書かれた論文です。
どちらも、沢山あるデザインパターンの本質を考察し、
その位置づけや関係性を再構成しようとしています。
別にわかりやすくそれぞれのパターンを解説しているわけではないですし、
その解釈もこの両者で一致しているわけではありません。
しかしながら、このような努力は非常に素晴らしいものだと思いますし、
表面を舐めただけの解説よりも256倍ためになります。
今度からこれらのサイトを参考にしていきながら、
デザインパターンについてちょっと考えていきたいと思っています。
他にも参考になるものが見つかると尚良いのですが。
書籍のほうがまだマトモなのですかね？
2011年7月5日火曜日
Awesome Inc.のブログアーカイブの横幅がおかしい件について
このブログは、Bloggerに元からあるAwesome Inc.というテンプレートを使っているのですが、
右にある「ブログアーカイブ」のレイアウトがというか横幅が細くなってしまい、
下の画像のようにかわいそうなことになっていました。
こういうの我慢できないんで修正しました。
右にある「ブログアーカイブ」のレイアウトがというか横幅が細くなってしまい、
下の画像のようにかわいそうなことになっていました。
こういうの我慢できないんで修正しました。
2011年7月4日月曜日
SyntaxHighlighter ( with Autoloader ) 導入記
ドリーです。
このブログにSyntaxHighlighterを入れました。
JavaScriptをつかってコードの色づけをしてくれる良さげな奴です。
公式ページはこちら。
http://alexgorbatchev.com/SyntaxHighlighter/
いやーなかなか苦労しました。なのでやり方をメモしておきます。
まず基本的に読み込むべきは
このブログにSyntaxHighlighterを入れました。
JavaScriptをつかってコードの色づけをしてくれる良さげな奴です。
公式ページはこちら。
http://alexgorbatchev.com/SyntaxHighlighter/
いやーなかなか苦労しました。なのでやり方をメモしておきます。
まず基本的に読み込むべきは
- shCore.css
- look and feel用CSS
- shCore.js
- 各言語用.jsファイル
登録:
投稿 (Atom)