サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
murank.hatenadiary.org
heroku みたいな git push で自動デプロイする方法として、よく post-recceive フックで git pull する方法が載っているけど、 自分の場合、それがうまくいかなかったことがあったのでメモ。 よくある post-receive フックの内容は以下の通り。 #!/bin/sh ( cd /path/to/repository git --git-dir=.git pull origin master ) 普通の使い方をしている限り、この方法で問題なく動作する。 が、うっかり git push -f してしまうといろいろとややこしいことになる。*1 というのも、git pull は結局 git fetch + git merge でしかないので、(本当はなかったことにしたい) 以前の HEAD と新たな HEAD をいい感じにマージしてしまうからこんなことになる。
free や delete に NULL を渡しても問題ないというのは有名な話*1だけど、Win32 API はどうなんだろうという話。 できれば公式情報として「問題ナイヨー」という保証が欲しいところだけど、いまいち MSDN を見てもよく分からない。 INVALID_HANDLE_VALUE に少しでも関係していそうな事といえば、「関数が ERROR_INVALID_HANDLE を返したら(関数が失敗したら) 大抵の場合はCloseHandle しなくてもいいよ」程度しかない。 It is usually not necessary to call CloseHandle if a function that uses a handle fails with ERROR_INVALID_HANDLE, because this error usually indicates that
ファイルの変更を取り消そうと思って $ git reset --hard fileとしたら fatal: Cannot do hard reset with paths.と怒られた。 $ git reset --hard HEAD fileとか $ git reset --hard HEAD -- fileとか試してもやっぱり怒られる。 じゃあどうすればファイルの変更を取り消せるのかというと $ git checkout fileとすれば良いみたい。 なんで reset では取り消せないのか調べてみたところ、 git reset [-q] [] [--] … git reset [--patch|-p] [] [--] […] git reset [--soft | --mixed | --hard | --merge | --keep] [-q] [] git-reset(1) とあった
とりあえず gnome 入れて firefox 動くようになったのでメモ。 FreeBSDインストール FreeBSD バージョン 8.1 インストール を参考にして普通にインストール。 ただし、「Choose Distributions」は「User」のみを選択した。 また、あえてソフトウェアを全部 ports でインストールしようと思ったので、パッケージでは何もインストールしない。 sendmail停止 自分の場合、インストール時にドメインを設定しなかったので起動に時間がかかるようになってしまった。 これは sendmail が原因らしい&どうせメール使わないのでいっそ sendmail を無効にしてしまう。 /etc/rc.conf に以下を追加 sendmail_enable="NONE" 参考:FreeBSD ハンドブック - MTA の変更 ports更新 国内にミラーを作って
前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは? HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは? --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset
いままでなんとなく使ってきたけど、ようやく使い方が分かったような気がするのでメモ。 前提知識 インデックスとワーキングツリーが理解できていること HEAD が何か分かっていること git diff ワーキングツリーとインデックスの差分を表示。 git add した後にさらに修正したけど、そういえばどの時点で git add したのかなー、というときに使う? git add したらすぐにコミットする自分には関係なさそう。 git diff --cached HEAD とインデックスの差分を表示。 git add して、コミットする前に差分を確認したい時に使うんだと思う。 自分は git diff よりもこっちの方をよく使う。 git diff HEAD HEAD とワーキングツリーの差分を表示。 前にコミットした時からどれくらい編集したか確認したい時に使う。 HEAD の部分はコミット(HE
autotools(autoconf/automake/libtool) の設定のあまりの複雑さに挫折してしまった人にとって、OMake は救世主といっても過言ではないはず。 OMake とはなんぞやという人は以下のサイトを見るといいかも。 OMake つかったらC言語でプログラム書く手間がバカみたいに減った - 日記を書く [・w・] はやみずさん マニュアルを日本語化してくださってる方もいて、感謝感謝。 OMakeマニュアル 日本語訳 ただ、使っていて ファイル間の依存関係は気にしなくてもいいけど、プログラムのビルドに必要なファイルは指定する必要がある。 サブディレクトリにも OMakefile がいる という点が気になった。 このままだとファイルやディレクトリを追加するたびに OMakefile を修正・コピーする手間がかかってしまう。 というわけで、ルートディレクトリの OMake
ちょっとした構文解析なら Xpressive でも充分だけど、ちゃんとした(?)構文解析器の Spirit と比べてどれだけ性能の差があるのか調べてみた。 どうせ比較するなら実用的なもので、というわけで RFC 2616 やらを参考に HTTP のリクエストヘッダをパースさせてみた。 本当はパースしたヘッダの内容を取り込ませて比較したかったけど、時間の都合上、正しいヘッダかどうかの判断だけにした。 パースしたヘッダと、それぞれ 1 万回ずつパースしたときの結果は以下の通り。 計測に使用した PC のスペックは CPU: Core i5 750@2.67GHz、メモリ: 2GB、gcc: 4.4.3。 // 標準的なヘッダ std::string str("GET / HTTP/1.1\r\n" "Host:www.google.co.jp\r\n" "User-Agent:Mozilla/
先日インストールしたUbuntuでWLI-UC-G300Nを使おうとしたら 若干苦労したのでメモ。 参考サイト http://www.toy-poodle-four.net/cgi-bin/four_sb/log/eid1414.html https://forums.ubuntulinux.jp/viewtopic.php?id=7779 https://forums.ubuntulinux.jp/viewtopic.php?id=6825 https://forums.ubuntulinux.jp/viewtopic.php?id=7557 1、2のページではWLI-UC-G300NにはRT2870チップが使われているとあるが、 自分の環境でlsusbをしてみると Bus 001 Device 004: ID 0411:016f MelCo., Inc. となり、どうもIDが違う。 試
pipe や popen を使っていると、本来なら出力済みのはずの他プロセスの出力がなかなか取得できないことがある。 最初はpopenやpipeのせいかと思っていろいろ調べたけど、どうも出力時のバッファリングの影響のようだ。 自分のプログラム中でバッファリングの方法を変更するのは setvbuf でできるわけだけど、 これを LD_PRELOAD と組み合わせると他プロセスのバッファリング方法を変更できそう。 というわけで、以下他プロセスに読み込ませる共有ライブラリのソース。 #include <stdio.h> namespace { struct NoBuffer { NoBuffer() { setvbuf(stdout, NULL, _IONBF, 0); } } instance; } おそらく大抵の Linux 環境で動くと思うけど、未保証ということで。 後はこれを適当なファイ
そろそろバージョン管理ツールのひとつやふたつ、使えるようになっておくと便利だろうというわけで、流行りのGitに手を出してみた。 なんでも、Git Extensions を使うと Visual Studio と連携できるらしい。 が、インストールしても Visual Studio には何も変化がない。 まさか Express Edition だからか?と思って Professional Edition をインストールしたところ、見事にメニューに "Git" という項目が増えた。 結論 Git Extensions を Visual Studio から使いたかったら金払え。 (実際はインストールの順番とか、無料版はサードパーティのプラグイン使えないとかあるのかもしれないけど、とりあえず動いたからよしとしよう)
ブラウザキャッシュとレスポンスヘッダの関係を調べてみた。 調べたブラウザ Firefox 3.5 IE 6 Opera 9.64 Google Chrome 2.0.172.33 レスポンスヘッダ Expires Last-Modified Cache-Control Pragma 結論 以下のレスポンスヘッダを返す。 Expires、Last-Modified、Cache-Control、Pragma 以外のヘッダについては任意。 キャッシュさせたい場合 Cache-Control: private, max-age=有効期間の秒数 条件付GETをさせたい場合 Expires: 過去の時刻 Last-Modified: 過去の時刻 キャッシュさせたくない場合 Cache-Control: no-cache 調査方法 それぞれのブラウザで以下のレスポンスヘッダを返すページを読み込んだときに
このページを最初にブックマークしてみませんか?
『murank.hatenadiary.org』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く