select_column = {“d_column”:  ”DATE_FORMAT(pub_date, ‘%%Y%%m’)”}

_list = PurchaseRecord.objects.extra(select=select_column)
_list = _list.values(“d_column”).annotate(cnt=Count(‘id’))

上記はMySQLを利用しているケースの書き方です。

あ、横長になると見難いから2行に分けただけで、1行で大丈夫ですからね。

「ORマッパー使ってるのにデータベースに依存ってなによ」

な感じではありますが、extraを使っている部分は直接クエリが流れるみたいですね。
つまり、「DATE_FORMAT(pub_date, ‘%%Y%%m’)」の部分は

select *,DATE_FORMAT(pub_date, ‘%Y%m’) as d_column
from app_purchaserecord

といった風に、追加されるのです。で、追加されたカラムを使って集計、という流れですね。うっかりミスりやすいのが「%」を二つにする点でしょうか。

あと、データベースを変えたら「select_column～」の部分に修正が必要です。使用するデータベースに依存した書き方になります。ここは要注意ですね。

class Div(models.Model):

name = models.CharField(max_length=100)

upper = models.ForeignKey(Div)

だと、syncdbの時に「Divなんてありません」と怒られてしまいます。そりゃそうだ。
ので、

class Div(models.Model):

name = models.CharField(max_length=100)

upper = models.ForeignKey(’self’)

と書きます。

Python2.5、Django1.1.1でのお話でした。

一昔前はInnoDBはMyISAMほどパフォーマンスが優れず、更新系のテーブルと参照系のテーブルでストレージエンジンを使い分けたものですが、今はストレージエンジンによるパフォーマンスの差も少ないため、行レベルロックができるInnoDBを積極的に採用するケースが増えてるみたいですね。まぁ数千万行をレコードから数ミリ秒でレスポンスを返さないといけないケースとかではどうなるのかわかりませんが。

DATABASE_OPTIONS = {

“init_command”: “SET storage_engine=INNODB”,

}

settings.pyに上記を記載するだけでsyncdbするときにInnoDBでテーブル作成してくれます。が、この記述はテーブル作成が終わって運用にはいったら削除するように、とのことです。

MySQLとの接続が確立された後にわざわざストレージエンジンを指定するコマンドを送っているっぽいので、普段は無駄な処理が発生しちゃうっていうことなんですかね。

NSString* _str = @”hoge”;

if([_str isEqualToString:@"hoge"])

{

NSLog(@”match!”);

}

{$array|@debug_print_var}

これで出力できます。簡単ですね。

最近ものすごく久しぶりにPHPを書いていますが、Array関連のメソッドが非常に豊富で、便利だなぁと。

iPhoneアプリが作りたくてmac買ったのにiPhoneの母艦としてしか使わずに早一年。実際の開発期間は一ヶ月以下という情けないだらしなさです。申し訳ない。

「Answer9」

単純なパズルゲームです。３秒間の間にパネルの場所覚えてめくっていくだけ。ノーマルモードだと1から順番に9までめくっていきます。ハードモードの場合はめくる順番をランダムに指定されます。ハセテツはハードモードをクリアしたことがありません。w

リリースしてから24時間程度ですが、アメリカですでにレビューを書いていただけました。２件あって、両方とも五つ星！最高にうれしいです。開発屋にとって、こういうのが最高の報酬なんだろうなと思う瞬間です。

「It’s a great memory game for all ages!」

「Very simple, but it’s a nice memory exerciser.」

感涙です。

このまま勢いに乗って調子に乗って、次のアプリ開発に着手します。次はタスク管理アプリ。タスク管理はシンプルじゃないと意味がないんですよ。偉い人にはそれがわからんのです。

class TwitterAuth
require ‘oauth’

def self.consumer

OAuth::Consumer.new(
[Consumer key],
[Consumer secret],
:site => “http://api.twitter.com”
)

end

def self.request_token(_token, _secret)

OAuth::RequestToken.new(
consumer,
_token,
_secret
)

end

def self.access_token(_token, _secret)

OAuth::AccessToken.new(
consumer,
_token,
_secret
)

end

end

まずは上記のクラスを作成。OAuth関連の処理はこっちにやらせます。で、次がコントローラー。

require ‘rubytter’

class AuthController < ApplicationController

def index

request_token = TwitterAuth.consumer.get_request_token(:oauth_callback => “http://#{request.host_with_port}/auth/callback”)
session[:request_token] = request_token
redirect_to request_token.authorize_url

end

def callback

_token = session[:request_token]
request_token = TwitterAuth.request_token(_token.token, _token.secret)
access_token = request_token.get_access_token(
{},
:oauth_token => params[:oauth_token],
:oauth_verifier => params[:oauth_verifier]
)
session[:request_token]=nil
_account = {
:user_id => access_token.params[:user_id],
:token => access_token.token,
:secret => access_token.secret
}
session[:account] = _account
redirect_to :action => “timeline”

end

def timeline

_account = session[:account]
token = TwitterAuth.access_token(_account[:token] , _account[:secret])
_twitter = OAuthRubytter.new(token)
@user_timeline = _twitter.user_timeline(_account[:user_id],:count => 100)

end

end

def timelineが自分のタイムラインを取ってくるところで、「:count=>100」と指定しているのは「新着100件取ってきて」っていうことです。ここを指定しないでおくと規定値では２０件取得してくれます。def callbackでセッションに入れたuser_id、token、secretをデータベース等に保存しておけば次回以降はこれらだけで認証とツイートの取得ができます（というか認証自体はtokenとsecretだけでOK）。

Twitterのアプリケーション登録申請で登録する際、コールバックURLを指定しないとWebアプリケーションとして登録されません。「開発中だからURLなんて決まってないよ」っていうケースでも、適当なURLを登録しておいてください。どうせ実際のコールバックURLはRubyのスクリプトで指定しなおしています。ハセテツはここに気が付かず、そこそこの時間を浪費しました。

で、タイムラインを表示するviewは

<ul>
<% for item in @user_timeline do -%>
<li><%= item.text %></li>
<% end -%>
</ul>

こんな感じです。

return render_to_response(‘index.html’)

っていう書き方をしているのですが、「コレ、cookieの書き出しどうすんのよ」って悩んでしまいました。その結果、

def  index(request):

_max_age = 45*24*60*60

_expires = datetime.datetime.strftime(datetime.datetime.utcnow() + datetime.timedelta(seconds=_max_age), “%a, %d-%b-%Y %H:%M:%S GMT”)

_response = render_to_response(‘index.html’)

_response.set_cookie(‘hoge’, value=’hogehoge’, max_age=_max_age, expires=_expires, path=’/')

return _response

こんな書き方をしたらできているようでした。上記の例だと、現在時刻から45日間有効なcookieを書き出しています。

単純なことなんですが、意外と躓いてしまった。。。

Python2.5、Django1.1.1です。

そういえばDjangoの1.2がリリースされてますね。検証したいな。

同じような処理をさせた場合、どの言語が一番早いのか。非常に気になるところでありますが、試したことがありませんでした。今回試してみたところ、意外な結果が出たのです。

下の方に書いたそれぞれのプログラムを実行した結果の、プログラム内部で計測したミリ秒を比較してます。

3回計測した平均です。同じ処理をさせるプログラムを書いたつもりですが、本当にフェアなものになっているのか正直自信がありません。そもそもPHPはWebアプリを主な目的としているとのことなので、こういう処理は得意としていないのかもしれない。

また、それぞれのプログラムのループ内2行目、文字列連結の部分をコメントアウトして実行してみると、これまた意外な結果が出ました。

PHPは文字列連結が苦手なんだろうか。暗黙的な型変換にコストがかかるのだろうか、等々考えてしまいます。それとも秒を求める部分がネックなんですかね。その辺は今後追っていきます。

ただ、これまでPythonの方がRubyより早い、と思っていたために自分の無知さに猛烈に恥ずかしい思いをしています。

実際にMySQLと連携するバッチを書いたときにはRubyの方が遅かったり、Railsアプリがもっさりだったり、「速い」という印象がまったくありませんでした。が、それはある特定の面しかみていない上での思い込みだったのかもしれません。

これはRailsが遅いのか、もしくはMySQL/Rubyが遅いのか。当時の書き方がマズかったのか。今後、いろんなケースでこういった比較をしてみようかと。

今回の検証がすべてではないし、これが答えだとも思っていません。また、そういう意図を含んだエントリではありません。今回の検証だって、特定の面しか見ていません。が、あまりに意外な結果だったため、自戒の念を含めてブログに書きました。

「こう書くともっとフェアだよ」「こういうテストの方がいいんじゃない」等、アドバイスいただけるとうれしいです。

フレームワークまで含めた検証した方が現実的なのだろうか。。。

#!/usr/bin/php
<?
function microtime_float()
{

list($usec, $sec) = explode(” “, microtime());
return ((float)$usec + (float)$sec);

}
$_start = microtime_float();
$_sec = date(’s’);

for($i=1;$i<100000;$i++)
{

$_val = (mt_rand(0, 100) + $i) / $i;
$_str = $_val.date(’s’);

}

echo microtime_float() – $_start;
?>

Ruby

#! /usr/local/bin/ruby

i=1
_start = Time.now

99999.times do

_val = rand(100) / i
_str = _val.to_s + Time.now.sec.to_s
i += 1

end

p (Time.now – _start).to_f

Python

#!/usr/bin/python
# -*- coding: utf-8 -*-
import datetime
import random

_start = datetime.datetime.now()

for i in range(1, 100000):

_val = random.randint(0, 100) / i
_str = str(_val) + str(datetime.datetime.now().second)

print datetime.datetime.now() – _start

CPU:Xeon 1.86GHz
メモリ:2GB
OS: CentOS5.4 32bit
PHP:5.2.11
Ruby:1.8.7
Python:2.5.2

必要なライブラリはhuBarcode。現時点でのバージョンは0.57です。easy_installでもインストールできます。

実はこのhuBarcodeにちょっと問題があって、インストールしたままでは利用できませんでした。

1. site-packages/hubarcode-0.57-py2.5.egg/ean13/__init__.pyと
   site-packages/hubarcode-0.57-py2.5.egg/ean13/renderer.pyの
   「from functools import reduce」をコメントアウト。
2. fontsフォルダ（WindowsのFontフォルダではなく、huBarcodeについているもの）site-packagesの下に配置。easy_installの場合は不明だが、ソースからのインストールの場合は手動で配置する必要があった。

「from functools import reduce」はPython3からの記述方法なのかな？Python2.5の環境では動きませんでした。

ここまでが前準備。やっとコーディングに入れます。

from ean13 import EAN13Encoder

_barcode = EAN13Encoder(‘123456789012′)
_barcode.save(“sample.png”)

コーディングは簡単。これだけでバーコードのpng画像が作成されます。EANは13桁ですが、最後の一桁はチェックサムなので、指定できるのは12桁までです。

どっちかっていうと二次元コードの方がニーズがあるだろうから、そっちも調査してみます。