第6回Twitterタイムラインで見るWicketのオブジェクト指向プログラミング(後編) 矢野勉(やのつとむ) 2009-12-11
Java, Wicket shin1ogawaさん(http://shin1o.blogspot.com/)が、WicketをAppEngineで使うために用意したクラス群を公開しています。非常に便利そうで、注目しています。 http://sourceforge.jp/projects/gaejtools/svn/view/gaejtools-wicket-util/src/main/java/appengine/wicket/?root=gaejtools AppEngineではセッションストアをHttpSessionStoreにすることで、バックエンドをビッグテーブルにすることができるのですが、API上でサイズに制限があるなど注意が必要です。公開されているクラス群には、制限を超える場合にはmemcacheに分割保存するAppEngineSessionStoreや、AjaxPagin
関数型パーサーの章にたどりついたんだけど、これはいいとおもった。今Haskellの概念を学びたいという人には、間違いなくこの本を推す。 何がいいかというとモナドという言葉がほとんどでてきません。他の本はモナドが特徴だみたいなかんじになって、モナドとはみたいな書き方なわけですが、本書の場合はこういうときはこう書いたほうがいいよね的な書き方があった後に、実はこれモナドっていうんだよみたいな書き方。これはいいと思った。 というわけで、Haskellの本が最近沢山でているけど、何を買ったらわからんという人は、この本をまず買うといいと思います。ただ、プログラムの記法というか記号が数学記号なので付録の対応表をみないときついですが。 プログラミングHaskell 作者: Graham Hutton,山本和彦出版社/メーカー: オーム社発売日: 2009/11/11メディア: 単行本(ソフトカバー)購入:
ブログ パスワード認証 閲覧するには管理人が設定した パスワードの入力が必要です。 管理人からのメッセージ https://mac-tegaki.comへ移転中 閲覧パスワード Copyright © since 1999 FC2 inc. All Rights Reserved.
Mercurialを使った俺々バージョン管理ノウハウまとめ(2009年夏編) - 文殊堂で、 export・importによるつまみ食いmergeの話を書いたら、 id:ursmがTransplantExtension - Mercurialを教えてくれた。 先日書いたやり方はbranch b1に含まれるいくつかのchangesetをb2につまみ食いする場合は、 つまみ食いしたいchangesetを指定してそれぞれhg exportしてpatchを作成、 b2のheadにupdateしてからhg importで順次patchを取り込んでいくというやり方だった。 hg transplantを使う場合は、b2のheadにupdateして、 hg transplant -b b1 とやれば良い、後は各chnagesetつまみ食いするかなど聞かれていくので、 つまみ食いの対象の場合はy、ではない場
Gitのchangeset圧縮がうらやましいので、 MercurialQueueを利用してやってみた。 概ね↓を参考にした。 ursmの日記 最初からMercurialQueueで管理していない場合のやり方です。 branchのMercurialQueueへのpatchに変換 Rev:298〜Rev:301のbranchのRev:298〜Rev:300を圧縮するとする。 まず該当branchのheadに移動する hg update 301 qimportでRev:298〜Rev:301をMercurialQueueのpatchに変換する。 hg qimport -r 298:301 このとき例えばRev:299だけ別のbranchなどという場合は、 Rev:299がネックになってしまいできないので、 Rev:299を除外してコマンド実行を分割する。 hg qimport -r 300:30
EclipseのJava projectをMercurialのリポジトリとして管理していて、 その中に何かclassがあるとします。 Eclipseのリファクタリング機能でpackage移動とclass名変更すると、 変更/移動元classのファイル削除と、 無関係の新規ファイル(変更/移動)追加になっている。 これは嬉しくない。 そこで、右クリックメニューからGuess Renamesを選択する。 類似度を自動判定し、後付けでhg renameにしてくれる。 ちゃんとファイルの移動になっています。 annotateで見てもちゃんと、 (自動で)変更されたpackage宣言/class宣言の行だけが 先ほどcommitしたリビジョンになっています。 参考・公式ドキュメントより Bitbucket | The Git solution for professional teams
今流行のkey-value storageの利点と欠点など。小さいデータをたくさん扱うタイプで、単純なkey-value型のデータモデルを持つ分散KVSについて。 Webアプリをとりまく最近のKVS事情、雑感を読んで、ちゃんと整理して把握しておかないといけないな、と思ったので少し整理。 それは違うぞーという事があったらコメントくださいm(_ _)m ※2009-11-17 追記:現在、KVSという用語の意味は定義されておらず、使う人によって揺れています。ここで言うところの分散KVSは、Dynamo や kumofs や ROMA など を想定しています。 分散KVSの利点 スケールアウトできる 簡単にサーバーを追加して性能を上げられる 単体の性能が高い スキーマレス 最初は少ない台数で安く、後からサーバーを足してスケールアウト!という運用ができる。アプリケーションに影響せずに、ストレージ側
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く