Mingw-w64/MSYS2 を入れなくても Git for Windows で間に合うみたい - 檜山正幸のキマイラ飼育記 (はてなBlog)
長年MinGW/MSYSを使い続けているのですけど、最近あまりアップデートされません。例えば、bashは9年前のversion 3.1のままです。世間ではversion 4.2, 4.3が使われているのに。 MinGW/MSYSの後継らしきMingw-w64とMSYS2の組み合わせに替えようかと思ったのですが、Git for Windowsがあれば十分な気がしてきました。 内容： MinGWとMSYS ディレクトリレイアウトとPATH環境変数 Mingw-w64とMSYS2 Git for Windowsのシェル環境 まとめ MinGWとMSYS MinGWとMSYSは一緒に使っている人が多いと思いますが、目的が異なる2つのシステムです。MinGW/MSYSとよく比較されるCygwinは、単一のシステムとしてWindows上にPOSIX環境を実現するものです -- 目的も方式も明快です。こ
Gitの解剖学的要点：「怖くない」の1/15圧縮版 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「もうGitは怖くない： 自信を持って使いたいあなたへ」は、「タイトルがミスリーディングで良くない」とか、「よけい怖くなる」とかの反応がありました。「怖い」という感情は個人差があるからしょうがないですね。タイトルはおそらく、「Gitの解剖学」あたりが受け入れられ易かったのかな。それとも、「ほんとうは怖いGit」？ 僕自身が気になったことは2点で： 長過ぎる。読むのが大変。 男女の裸の写真が入っている。 裸の写真2枚は、いちおうストーリーを補完しているのでイイとしましょう。しかしあの長さは、たぶん自分でも読み返さないと思います。でも、書いてある内容を後で参照はしたいので、要点だけを箇条書きにまとめておきます。 Gitは内部構造がまる見え。.git/ディレクトリを覗けばいい。 Get http://www.chimaira.org/misc/git-quest-kit.shar . See h
もうGitは怖くない： 自信を持って使いたいあなたへ - 檜山正幸のキマイラ飼育記 (はてなBlog)
2014初頭に書いた「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」の最後の文： ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示（樹形図）の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん
少し補足： Git for Windows と SourceTree for Windows - 檜山正幸のキマイラ飼育記 (はてなBlog)
「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」に対するブックマークコメント欄を見たので、ちょっとだけ補足をしておきます。 SourceTree for Windowsのバージョン1.4リリースの発表では、新機能に"git-svn support"が挙げられています。試してみました。Google CodeにSubversionのリポジトリを作って、SourceTree上からクローンしてみました。これはうまくいきました。が、ローカルGitリポジトリからのプッシュが認証エラーするようです。それ以上詮索してませんが、なんか設定か調整が必要なんでしょう。[追記]GoogleCodeのパスワードが、When prompted, enter your generated googlecode.com password.
WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows - 檜山正幸のキマイラ飼育記 (はてなBlog)
分散バージョン管理システムの利用は拡大しています。そのなかでも最も人気のあるツールはGitでしょう。しかし、GitをWindowsで使うのはなかなか困難でした。 Windows向けのGitであるmsysGitは、bashのコンソールを出して、最小限のUnix風コマンドライン環境を提供するものです。これは使いやすくありません。もう一つの選択肢であるTortoise Gitは、Windowsのエクスプローラー（ファイルマネージャ）に統合されたGUIツールですが、僕は「なんか違うな」と感じてました -- これは個人の感性の問題ですが、ファイルマネージャに横付けすることが、分散バージョン管理システムへの良いUIを提供するようには思えないのです。 ところが、最近は事情が大きく変わっています。使いやすいGUIツールとして、2013年6月に正式公開されたSourceTree for Windowsが存在
僕らが大好きだったWebはなくなるのかもしれない - 檜山正幸のキマイラ飼育記 (はてなBlog)
Webはなくなるのかもな、と思います。 この記事の続きは「ブラウザが消滅して： APIベースのWeb」 あの頃のWeb 「Webとは何か」を定義しなければ、なくなるか／存続するかなんて議論は意味をなしません -- それは承知ですが、ここでは曖昧な、あるいは感傷的なWebのイメージに基いて話します。 Webはブラウザで閲覧するものでした。ブラウザはHTML文書の表示装置です。ハイパーリンクをたどってインターネットを“サーフィング”できます。あるいは、検索エンジンを利用して目的のWebサイトを探します。たまにフォームを使ってWebに“書き込み”をします。それが、今までの（「かつての」かもしれない）Web体験です。 このようなスタイルのWebの盛り上がりのピークは2005年からのWeb 2.0ブームだったと思います。Web 2.0の提唱者だったティム・オライリーの真意はどうであれ、Web 2.0
主キー／外部キーなんてドーデモイイ - 檜山正幸のキマイラ飼育記 (はてなBlog)
土曜日の「データベースは圏なんだよ！の会」（hirataraさんのメモ）で、「主キー／外部キーなんてドーデモイイでしょ」的なことを言ったので、「どういう観点ならドーデモヨク見えるのか」を補足しておきます。別な観点からはドーデモヨクナイでしょうが、そういう別な観点を否定するものではありません*1。 以下の話は、集合圏に関する練習問題にもなっています。モノ射とプルバックの定義を確認して、集合圏のなかで具体的に考えてみてください。手を動かして具体的に追いかければ、ドーデモヨサが実感できるはずです*2。 Cは集合圏の部分圏としまします。したがって、Cの対象は集合で射は写像です。データベースを考える文脈では、Cは有限個の対象からなる小規模なもの（有限表示を持つ圏）です。Cは、Cと同じ“形状”を持つスキーマSのデータベースインスタンス（スナップショット）だと思ってください。 Cの対象Aごとに対象K(A
bitbucketはもう信用する気になれない - 檜山正幸のキマイラ飼育記 (はてなBlog)
bitbucketは、分散バージョン管理システムのリポジトリと関連機能をホスティングしているサービス。Catyの開発にはずっとbitbucketを使ってきた。細かい不満はあるものの、「これはダメだ」というほどの問題点は感じていなかった。だが、最近の変更は酷い。それについては、既にKuwataさんが書いている。 http://return0.info/note/2012-10.html#id2012-10-10 http://return0.info/note/2012-10.html#id2012-10-19 Wikiの記法が、WikiCreoleからMarkdownに変わったのだが、互換性への配慮が一切されてない。ユーザーが今まで貯めこんできたデータが壊れる事態もヤムナシという判断らしいが、ヒド過ぎる。具体的に言うと、過去にWikiCreole記法で書いた（イシュートラッカーの）イシュー
nginx(エンジンエックス)をWindows上で動かして、SSLとリバースプロキシーの実験をした - 檜山正幸のキマイラ飼育記 (はてなBlog)
我々のWebフレームワークCatyでは、Pythonで実装したサーバーによりWebサイト／Webアプリケーションを動かしています。このCatyサーバーは、次のような点で十分とは言えません。 仮想ホストの実現 HTTPS（SSL）通信 キャッシュによるWebアクセラレーション 詳細かつ柔軟なロギング 複数プロセスを使ったパフォーマンス向上 とはいえ、Webサーバーとしての機能を充実させることはCatyの目的ではないので、不足な部分は既存のサーバーソフトウェアの力を借りることにします。Apache + (mod_python or mod_wsgi)、lighttpd + FastCGI といったところが候補でしょうが、結局、nginx（エンジンエックス）を使うことにしました。現状のCatyサーバー（caty-server.py）には特に手を加えないで、nginxを手前に置くという構成です。
シェルのリダイレクトの補遺 - 檜山正幸のキマイラ飼育記 (はてなBlog)
昨日書いた「シェルのリダイレクトを『こわいものなし』というくらい完全に理解しよう」に、随分とブックマークやトラックバックをいただきました。それらのフィードバックを拝見して、僕の説明にいたらない所があったと思いますので、ここで補足します。 コマンド実行単位≒simple command パイプ記号「|」や逐次実行の記号「;」を含んだ長いコマンドラインも、１つのコマンドとその引数、それとリダイレクト指定からなる“成分”に分解できます。こういった成分をなんと呼ぶか僕は知らないので、仮に「コマンド実行単位」とでも呼びましょう。 シェルの構文（grammar）的概念としてsimple commandというものがあります。ここで言ったコマンド実行単位は、ほぼsimple commandだと言っていいでしょう。「ほぼ」と付けたのは次の理由からです； 「コマンド実行単位」は、1つのプロセスを起動することを
シェルのリダイレクトを「こわいものなし」というくらい完全に理解しよう - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Java BlockingQueueで遊ぶ：パイプラインごっこ」でパイプラインの話をしたので、本来の、つまりUnixのパイプやリダイレクトを少し調べてみました。 たまに話題となる some-command >file 2>&1 と some-command 2>&1 >fileの挙動の違いについて、「シェルはコマンドラインリダイレクトの指定を右から左に解釈実行する」なんて説明が見つかりました。んなバカな！ パージングは左から右にするものですよ。パーズツリーを逆順にたどることはできるけど、そんなことする必然性はなんにもないよ。 次の記事を読むと、「右から左」なんて事情じゃないことが分かるでしょう。 UNIXの部屋 検索: リダイレクト シェルのリダイレクトにまつわる失敗 さてここでは、複雑なリダイレクト処理も完全に理解できる処方箋を示しましょう。例えば、次のコマンドラインが何をするか分かる
もう一度、ちゃんとJSON入門 - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕自身も僕の周辺もJSONをよく使います。でも、細かい点でけっこうミスをやらかしています(苦笑)。このエントリーで、JSONを使う上で注意すべきこと／間違いやすい点をすべて列挙します。 内容 兼チェックリスト： 仕様原典さえ読めば完璧（のはずだが） 数値の前にゼロを付けてはいけない 16進数表記も禁止だよ 数値の前にプラスを付けてはいけない 小数点からはじまる数値はダメ 用語法が違うよ：プロパティとメンバー メンバー名には常に文字列を使う 空文字列""もメンバー名に使える 配列要素はキッチリと並べよう 文字列を囲むには二重引用符だけ 文字列内のエスケープが微妙に違う 仕様にないエスケープは構文エラー undefinedもNaNもありません ラッパーオブジェクトは使わないのが吉 型システムとtypeofに関する注意 最後に 仕様原典さえ読めば完璧（のはずだが） JSONは、小さくて簡単な仕様
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
