HTTPのクエリパラメータにコロン(:)を書くのは不正なのか。 - こせきの技術日記
PHP の $_SERVER['REQUEST_URI'] と parse_url() の予想外な動作について。 - こせきの技術日記 の続き。 PHPのparse_url()は、 "/abc?a=x&time=09:00&x=y" はパースできるのに、 "/abc?a=x&time=09:00" だと失敗する。 相対URIで「動作しない」仕様だかららしいのだが、それはともかく、コロンのパーセントエンコードが必須なのか気になったので調べた。 URIの仕様 RFC 3986 まず、基礎となる URI の仕様 RFC 3986 がある。 RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax Uniform Resource Identifier (URI): 一般的構文 日本語訳 RFC 1738 - A Gopher URL
Rails, Django, Laravel 開発サーバをダブルクリックで起動する vagrant-layout プラグインというのを作った - こせきの技術日記
vagrant-layout というのを作りました。 koseki/vagrant-layout at plugin · GitHub この記事で書いていた環境を生成する Vagrant プラグイン＆設定サンプル集です。 Vagrant を使って Mac からダブルクリックで操作できる仮想環境を作る - こせきの技術日記 インストール $ vagrant plugin install vagrant-layout でプラグインをインストールします。 Quickstart $ mkdir my-project $ cd my-project $ vagrant layout init php で各種ファイルを生成します。生成された、 sandbox/osx/start.command (Mac) sandbox/win/start.bat (Windows) をダブルクリックしてしばらく待つ
GitHub の公開鍵で暗号化する ghcrypt の処理内容 - こせきの技術日記
GitHub のユーザ名を指定してファイルを暗号化するツール ghcrypt を作った - こせきの技術日記 の続き。甘い物のことは忘れて、もうちょっとちゃんと書きます。 いくつかバージョンアップを行いました。暗号化はAESで行い、AES のパスフレーズを公開鍵で暗号化するようにしました。現在のバージョンは 0.5 です。 https://github.com/koseki/ghcrypt ghcrypt ファイル名 githubユーザ名(受信者) ghcrypt ファイル名.enc.tar githubユーザ名(送信者)で、暗号化・復号化を行います。 動作環境 OpenSSH の 5.6 以降が必須です。OpenSSL は 0.9.8 あたりで動作確認をしてます。 OpenSSH 形式の公開鍵を OpenSSL で使える PKCS#8 にエクスポートするために、 OpenSSH 5.6
PHP の $_SERVER['REQUEST_URI'] と parse_url() の予想外な動作について。 - こせきの技術日記
REQUEST_URI と HTTP_HOST PHP のサーバ変数 $_SERVER['REQUEST_URI'] には、ふつうパスとクエリが設定される。 'REQUEST_URI' ページにアクセスするために指定された URI。例えば、 '/index.html' PHP: $_SERVER - Manual ただし、常にパスから始まると保証されているわけではない。以下のように、 GET に続けて絶対 URL を書いたリクエストを送ると、 GET http://localhost/test.php?query=value#fragment HTTP/1.1 Host: localhost $_SERVER['REQUEST_URI'] の値は、 http://localhost/test.php?query=value#fragmentになる。 ポイント: REQUEST_URI は
![PHP の $_SERVER['REQUEST_URI'] と parse_url() の予想外な動作について。 - こせきの技術日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/55b01fd08be95f01daa424d75fcf14d298cf4b79/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704591929884399267%2F6435922169449100371%2F1381914302)
Git の仕組み (2) - コミット・ブランチ・タグ - こせきの技術日記
Git の仕組みシリーズの2回目です。目次がここにあります。 前回の記事では、Git オブジェクトとリファレンスが大きなツリー構造になっていることを説明しました。 また、Git オブジェクトがどのように記録されているか、 ファイルツリーの変更がルート tree オブジェクトの ID に反映される仕組みなどを見てきました。 今回は commit オブジェクト、ブランチ、タグ、stash の仕組みについて説明します。 実際のデータが見たいときは、Git Object Browser にアクセスしてみてください。 5. commit オブジェクト 先に説明した通り、Git オブジェクトデータベースには、複数のファイルツリーを保存できます。 個々のファイルツリーは、最上位 (ルート) にある tree オブジェクトの ID で区別することができます。ファイルツリーは、大抵の場合、過去のファイルツリ
Git の仕組み (1) - こせきの技術日記
目次 はじめに Git を使ったことがない方へ 生のデータが見たい方へ Git の全体像 .git の中身 Git オブジェクトデータベース 4種類のオブジェクト リファレンス リファレンスのリファレンス 大きなツリー Git オブジェクトの ID と 中身 ハッシュ関数 SHA1 の簡単な説明 tree と blob オブジェクト tree と blob の参照関係 ルートツリーの ID でツリー全体を識別する commit オブジェクト リファレンスとブランチ ブランチ ブランチ先頭を指すリファレンス HEAD リファレンス detached HEAD 2種類のタグ 一時待避 (stash) インデックス キャッシュとしての役割 マージ Fast-Forward マージ non Fast-Forward マージ rebase reset 2種類のブランチ 各リポジトリが自分のブランチを
Vagrant を使って Mac からダブルクリックで操作できる仮想環境を作る - こせきの技術日記
この記事を公開する直前に Vagrant Cloud がはてブに上がってるのを見て、今あわてて追記しています。すごい楽しいことになってますねー。 Vagrant Cloud Vagrant 1.5 and Vagrant Cloud - Vagrant ブログ記事をざっと読んだ感じだと、Vagrant 1.5 の新機能は、 VagrantShare - まるで公開されてるサイトみたいに VM の URL をチームメンバーに見せる Box を koseki/centos みたいな短い名前で指定できるように。バージョン管理 rsync と SMB でフォルダ同期 Hyper-V - MS の仮想環境に対応 insecure-private-key の代わりに SSH でパスワードが使えるように プラグイン管理 Funtoo, NetBSD, TinyCore Linux のゲストに対応。ネット
はてなIDがクッキーで約50サイトに送られていた話 - こせきの技術日記
(追記) 要点を整理をした記事を書きました。こっちのほうが、余計なこと書いてない分、わかりやすいかもしれません。 はてなブックマークに、マイホットエントリーという大変すばらしい機能があって、毎日見ている。 マイホットエントリー機能のご紹介 - はてなブックマーク開発ブログ 自分のマイホットエントリーのURLはこう。 http://b.hatena.ne.jp/koseki/ マイホットエントリーを見ていると、はてなID koseki を含むリファラが各サイトに送信される。 リファラは Google アナリティクスの __utmz に記録される。 Firefox には、全クッキーの値を横断検索する機能がある。 設定 ＞ プライバシー ＞ Cookieを個別に削除 ＞ 検索 自分の環境では、およそ50個*1のクッキーに koseki という文字列が含まれていた。 あんなサイトやこんなサイトを、
Google アナリティクスで使われるクッキーについて __utma / __utmb / __utmz - こせきの技術日記
公式な仕様は無さそう。ソースを読むのは厳しい。整形しただけでは全然読めなかった。 クッキー 4種類 現行バージョンの ga.js が使用するクッキーは、主に4つ。 __utma ユーザを識別。2年有効。 __utmb 今回のセッションを識別。30分有効。 __utmz どこから来たか。リファラ。6ヶ月有効。 __utmv カスタム変数。2年有効。 __utma, __utmb, __utmz は、ga.js が実行されたときに、無かったら作られる。 __utmv は、_setCustomVar() で作られる。 有効期間は、最後に更新した時点からカウントする。4つとも、GAにデータが送られる度に更新される。 たとえば __utma なら、ユーザが2年間サイトに来なかったら消える。2年以内に再度アクセスすると、そこからまた2年の有効期間が与えられる。 他に、 __utmc 古いバージョンであ
はてなダイアリーの記事をgithubでバージョン管理する。 - こせきの技術日記
github や code repos のような公開リポジトリを使って、ブログに履歴管理機能を追加できるのではないかと考えた。この記事では、はてなダイアリーの記事をgithubでバージョン管理する方法を検討する。また、ブログ記事の履歴を公開するメリットについて考える。 この記事の履歴は、以下で参照できる。 http://github.com/koseki/hatenadiary-koseki2/commits/master/2009-06-29-HatedaGithub.txt これまでにやったこと はてなダイアリーライター(はてダラ)にローダー(はてダロ)を加えてgithubに上げた。 koseki/hatenadiary-writer · GitHub Text::HatenaとWEBrickでプレビューサーバを実装した。 Rakeで更新環境を作った。 最近書いた記事をgithubに上
地雷だらけのrsyncを理解する。 - こせきの技術日記
rsync -avz --exclude-from=pattern-file --delete SRC/ DEST SRCの末尾に/をつける。たいてい必要。 SRCスラッシュの有無は、mv SRC DEST と mv SRC/* DEST の違いと一緒。スラッシュの後ろに*が省略されているものと考える。 DESTのスラッシュの有無は関係なし。 --dry-run(-n)をつけて試す。 SRC、DESTともローカルのディレクトリを指定して試す。 DESTはまず空ディレクトリで試す。DESTが同期済みだと何が更新されるのか正確にわからないので。 --list-onlyをつけてファイル一覧を得る。 DESTを省略してファイル一覧を得る。 --list-onlyと同じ？ --deleteはDESTのファイルを根こそぎ削除する可能性がある。注意。 --delete-excludedは使わない。--d
mod_rewriteの考え方。 - こせきの技術日記
http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html を見ながら。 URLが正規表現(A)にマッチし、かつ 文字列(B)が条件(C)を満たす場合に、 URLを(D)に書き換える。 というのが基本。 RewriteRule URLが(A)の正規表現にマッチしたら(D)で書き換える。 正規表現(A)は、リライトを実行するかどうかの条件(真偽値)であって、置換 url =~ s/(A)/(D)/ ということではない。たとえば、以下のような正規表現でリライトされる。 Google Code Search # 1文字マッチしたらリライト実行。空文字列でなければ実行する。 RewriteRule . index.php [L] Google Code Search # 先頭にマッチしたらリライト実行。常に実行する。 RewriteRule ^ -
2つの期間が重なり合うかどうかを判定する。 - こせきの技術日記
2つの期間 A〜B と X〜Y が重なっているかどうかを判定したい場合。 のように4つのパターンがある。これを単純に、 A <= X && Y <= B || X <= A && Y <= B || A <= X && B <= Y || X <= A && B <= Yのように判定してはいけない。 Xは青い線の上を、Yは赤い線の上を動くとき、A〜B と X〜Y は重なり合う。この条件は、 X <= B && A <= Yこれで4つのパターンをカバーできる。ORは不要。始点と終点をわかりやすく書くと以下になる。 始点2 <= 終点1 && 始点1 <= 終点2アルゴリズムに名前がありそうな気がするけど、見つけられなかった。 (追記) 矩形の重なり判定の方が情報が見つかった。 * Life is beautiful: ビル・ゲイツの面接試験－私の場合 * 長方形の重なりを判定する問題 - ザ
地獄のようによくわかるSQLテーブル結合 - こせきの技術日記
テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNER JOIN → JOIN LEFT OUTER JOIN → LEFT JOIN RIGHT OUTER JOIN → RIGHT JOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSS JOIN。 こんなの使いません。 ブクマ用画像。
Apacheのアクセス制御をちゃんと理解する。 - こせきの技術日記
Apacheの設定で Order deny,allowとか Satisfy anyとか、なんだか意味わからん人のために。僕はずっとわかってなかった。 基本 Apacheのアクセス制御には、 ホストによる制御 (Order,Allow,Deny) ユーザ認証による制御 (Auth*, Require) の2通りがある。 Satisfyは、2通りあるアクセス制御の両方を満たす必要があるかどうかを決定する。デフォルトはSatisfy all。Satisfy anyなら、どちらか片方満たせばよい。 Order http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#order Order deny,allowは、全てのホストからのアクセスを許可する。 Order allow,denyは、全てのホストからのアクセスを拒否する。 Order d
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
