使いまわせそうな方法が見つかったのでメモ。 ユーザー毎にタグを作成できるような機能を作成していて、特定のユーザーのタグを一括で取得しようとする場合、普通にタグ毎にエンティティを作成していると、200件くらいのタグをuserでfilterして取得するだけでも結構時間がかかる。 class Tag(db.Model): """key_name is user_id/tagid""" user = db.ReferenceProperty(User) name = db.StringProperty() ... tag_list = Tag.all().filter("user = ", user).order("name") 色々調べてみたところ、検索に使用しないデータはシリアライズしてzlib圧縮してBlobPropertyに入れておくといいらしいことが分かった。考えてみるとタグはユーザー
前回からずいぶんと時間が経ちましたつづきです。(激しく申し訳ない) 前回は永遠とQueryChartの説明をしましたが皆さん試してみましたか? チケットに手を入れる必要があるので躊躇ってやっていない人も多いと思います。 さて今回はチケットに手を入れなくても出来る、マイルストーンのプログレスバーをカスタマイズについてです。 プログレスバーをカスタマイズ Tracのマイルストーンビューは結構悲しくて、デフォルトでは「解決済み」と「未解決」を二色で塗り分けて表示しているだけです。 0.11からワークフローのカスタマイズも可能になり、色々な状況を設定可能になりましたがTracのwiki(TracIni#milestone-groups-section)に書かれている内容はイマイチ良く分かりません。 ワークフローも0.10とは違い、acceptとassignが明確に分けて管理されるようにもなりました
前回のエントリ アメリカの組織から日本の社畜問題について考える - Rails で行こう! で現代日本の最大の社会問題は、滅私奉公・転職困難という「社畜」問題かもしれない、と述べた。中小企業には比較的人材の流動性はあるが、日本経済を支配する大企業の人事政策はきわめて硬直的である。大企業の正社員になる方法は、原則として、新卒時に入社することだけである。たとえ中途採用で入ることができても「生え抜き組ではない」という色眼鏡で見られ、出世は期待できない。転職しようとしても、中途採用のよい職が極端に少なく、収入の減少を覚悟しなければならない。結果として、会社にしがみつくしか方法がなく、会社がいかに理不尽な異動や転勤を命じても唯々諾々従うしかない。サービス残業を強いられても、他に選択肢がなければ受け入れざるを得ない。 日本企業は、このように従業員の人生全体を抱え込んでいるので簡単に解雇することはできな
Android SDK上で使うことを前提として、ビュー(レイアウト)とモデルとの間でオブジェクトを交換する処理を書かなくて済むような、なんらかのデータバインドの仕組みを書くことにした。 データバインド あまり考えすぎても仕方が無いので、取りあえず方針だけは決めることにした。 1. Windows Forms方式 2. Beansbinding方式 このどちらも使わないことにする。 常時バインド状態は便利だが、現状では処理コストがメリットを上回る可能性が高いと考える。(あくまで現状であって、アンディ・ルービン氏が言うような2GhzのCPUを持つ機器が出てきたり※1、JIT等の高速化技法によりDalvikの実行スピードが格段に速くなった場合は※2、また再考の必要がある) ではどうする? ModelBinder方式 モデルバインダはASP.NET MVCのコアコンポーネントの一つで、ここ数年来に
Quicksilverの検索性能が、感性をくすぐってきた。 「apple」→「AppleScript Editor」 「ase」→「AppleScript Editor」 「prol」→「Property List Editor」 「im」と入力して、「Image Capture」を起動したいが、「iMove」がトップヒットになってしまう...。 そんな状況でも、候補リストから2回連続で「Image Capture」を選択すれば、3回目以降は「Image Capture」がトップヒットになる。 直近のユーザーの好みを学習してくれるのだ。 もちろん、「ima」まで入力すれば「Image Capture」がトップヒットになる。 「ase」「prol」のような、単純な前方一致でも、部分一致でもない検索には恐れ入る。しかも、シンプルだけど学習もしてくれる。使うほどに手に馴染んでくる仕組みは、この辺
Google App Engine の webapp.RequestHandler には、ハンドラ内で例外が発生したときに呼び出される handle_exception メソッドがあります。このメソッド、デフォルトでは HTTP ステータスコードを 500 に設定するだけですが、これをオーバーライドして、動作をカスタマイズできます。 例外の情報をログに出力するベースハンドラクラスを作成し、リクエストハンドラはベースハンドラを継承すれば、集約例外ハンドラになりますね。 class BaseHandler(webapp.RequestHandler): def handle_exception(self, exception, debug_mode): # 例外情報をログに出力。 logging.exception(exception) # とりあえず親の実装を呼び出しておく。 # 独自のエラ
国内のネットのオリンピックの審査結果の評判を聞いているとこんな感じだ。 ・キムヨナは採点基準を追求した点取り型の演技で技術的には浅田真央の方がレベルが高い。 ・浅田真央は世界初のトリプルアクセルを成立させたが、採点基準の上では低くなる。 なんだか、いつもヘンな技術にこだわってスカタンをする日本のメーカーみたいで笑ってしまった。 ここでも言われているように、日本以外の国では、韓国のデジタル家電の方が日本製品よりメジャーなモノが多い。価格も安いし、ユーザーのニーズに沿った製品を作ってくる。ヘンな機能を追及したりしていないからだ。 浅田真央のように、日本のメーカーはヘンに技術にこだわることが多い。 たとえば、ソニーがビデオのベータマックスを出したとき、なぜか「カセットの大きさ」にこだわっていた。彼らは、文庫本サイズにこだわった。おかげで初代ベータは1時間しか録画できなかった。そこはこだわるべき
iPhoneアプリから自己証明書の https サーバーに接続しようと思った場合、どうするのがいいでしょう。 普通に Objective-C の NSURLConnection を使用すると証明書の検証エラーになってしまいます。少し検索すると非公開APIを使用して回避する方法もあるようです。(NSURLConnection +setAllowsAnyHTTPSCertificate:forHost) Cocoa アプリだとこの方法で良いかもしれません。しかし iPhone では審査ではじかれること請け合いです。と言うかはじかれました。 そこで libcurl をつかって C の世界で HTTP 接続をしてしまえばリジェクトしようがないだろうということでやってみたときの記録です。 前提 以後の作業はすべて iPhone SDK をインストールした OSX 上で行っています。 openssl
<?xml version="1.0"?> <feed xmlns:idx="urn:atom-extension:indexing" xmlns:gr="http://www.google.com/schemas/reader/atom/" xmlns:media="http://search.yahoo.com/mrss/" xmlns="http://www.w3.org/2005/Atom" idx:index="no"> <!-- Content-type: Preventing XSRF in IE. --> <generator uri="http://www.google.com/reader">Google Reader</generator> <id>tag:google.com,2005:reader/user/10689165820831989733/state/c
近所迷惑を被っているとしたら、Wi-Fi接続名でメッセージを伝えるのはどうだろうか(本家記事より)。 passive aggressive notes.comでは、そんな風にさりげなく(?)ご近所さんに苦情を伝えるWi-Fi接続名を取り上げている。「YourDogShitsInMyYard (お宅の犬がうちの芝生でフンするのですが)」「3rdFloorAssholesSTFUOnYourBalcony (3F野郎、ベランダでうるさすぎるぞ)」「Wecanhearyouhavingsex (いたしている声がまる聞こえです)」「please no more grindcore at 3am (深夜3時のグラインド・コアは勘弁してくれ)」などなど。 /.Jerはなにか面白い Wi-Fi接続名に遭遇したことはあるだろうか?
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く