携帯対応の続き

それにしても俺はCakePHPを使っているにもかかわらず何故に開発スピードが遅いのだろう?不器用だからか?テレビ見ながらやってるからか?はい、携帯対応の続きです。ログインとユーザ登録と、記録の登録までできるようになったけど、記録の登録時に$this->setFlash(‘登録しました’);みたいにしたら、思いっきり文字化けした。

まあこれは、flashするときの文字列がUTF-8のままなんだろうというのはすぐにわかるのだが、defaultレイアウトファイル上で、$session->flash()ってされて出力されてるので、このメソッド内部に改修を加えないといけなさそうだということまではわかって、色々調べていたが、タイムアップ。今日はもう寝る。。。

とりあえず、参考になりそうなURLを記述。試してないけど、後日試しますので。。。

http://cakephp.jp/modules/newbb/viewtopic.php?topic_id=751&forum=3&post_id=1698#forumpost1698

ってか、flashメソッドの内部のe($out);を、return $out;にして、レイアウト側でe($session->flash)だったら、e(mb_convert_encoding($session->flash(), ‘SJIS’, ‘UTF8’));でいけるんじゃないの?と思ったのだが。まあ、逆にechoする手間が面倒だわな〜普通は。


携帯版サイトの作成中

自転車でヒルクライムしようぜ!の携帯対応を行おうと思って、現在CakePHPガイドブックなどを見ながらやっている最中です。処理はコントローラー側で既に実装しているわけなので、あとはビューとajaxで実装していた機能の実装などなんですが、逆に悩ましい…。

mixiなどのSNSやブログの場合は、基本的には日記サイトなので(あくまで基本ね)、出す情報もそんなに複雑じゃないけど、ランキングサイトの場合は思ったより複雑。とりあえず使えるってレベルまで早くもっていきたいところです。たぶんモバイル対応したら、結構使いやすいと思うんですよね〜。ヒルクライム走り終わったテンションで記録を投稿できるというのがまた達成感があるというか。それにしてもユーザ増えないね〜(T_T)

なるべく早くやろう!


本日は三坂峠にアタック!

土日の両方とも天気がよかったので、二日続けてヒルクライムアタック!
今日は三坂峠に行ってきました。
昨日の疲れが残っていたせいか、正直全然速く上れんかったw

タイムは51分ジャスト。昨日の五明といい、29分ジャストだし、不思議だ。

三坂は俺のベストタイムが37分40秒だったかな?それくらいだから、10分以上遅くなっている。やっぱり運動不足がたたっているなぁ。再来週がOB会で行われる三坂T.T.なので、それまでにはせめて45分台を叩きだせるくらいの体力を回復したいが、2週間しかね〜!!頑張ってローラー台乗ります…。

あと今年は軽量ホイールを買って〜とか考えていたけれど、そんな余裕が言える状態ではなくなったので、お預け…。またディープリムで頑張って上ります。あれも重いからなぁ〜。平地ではいいんだけど。


久々にトレーニング

このところ、自転車でヒルクライムしようぜ!の制作ばっかりで、自分自身がヒルクライムに行けてなかったので、久々にロードに乗って出かけてきました。先週は雨だったけど、今週は晴れたのでまさに自転車日和!暑くも寒くもないこの初夏が一番いい季節。

行ったのは、サイクリング部の頃のトレコースである五明。引っ越してからはこのトレコースに行くこと自体が既にトレーニングになる距離になってて(^^;)結構遠い。まあのんびりと、準備運動のような気持ちで出かけて、スタート地点に到着。

いよいよ、ヒルクライムタイムトライアルの開始!

このコースはのっけから緩やかに見えて結構上ってるので、最初で飛ばすと後で全く体が反応しなくなるので、最初は抑え目に走ったほうがよい。と思っていたのだが、既に最初のほうでバテた。そんなに体力落ちてるんか!俺!グダグダになりながら、最初の激坂を上り終え、長い下りへ。ここもタイムを縮めるいいチャンスなのだが、バテてて全然漕げない。ペダルを一応回すのが精一杯。

あとは小学校からゴールのレインボーハイランドまでずっときつい上り坂。途中であまりにも肩がだるくなってしまって最後まで行けるかわからんくらいだったが、なんとか気力で走った。しかし、タイムは29分ジャスト。自分が大学生だった当時は、ランドナーで23分50秒とかだったのに、ロードなのに5分以上も遅くなっている。体力落ちてるなぁ〜。。。

ゴールでくたばっていたら、サイクの後輩のボブソンと偶然出会った。彼はデートのドライブがてら来たみたいだったのだが、それにしてもビックリした。最近はチャリにあんまり乗ってないかわりにバイクにはまってるみたいで。まあ社会人になったら、そうなる人のほうが多いしな〜。

明日も晴れるみたいなので、またどっかにアタックしてくるかな?やっぱり外で走ると気持ちいいし!


書評:ハイパフォーマンスWebサイト

今、自分が仕事でやっているサイトは比較的大規模なサイトなので、パフォーマンス改善がよく課題に上がります。今でもDBのパフォーマンスをよくするためにチューニングするとか、SQLを見直せばとか、javascriptのイベントを減らせばとか、もっとキャッシュを利用するようにすればとか、ま〜色々と出てくるのです。

しかしそんな状態で今はフロントエンドのほうではなく、やや特殊な仕事を任せられてるので、私は全然パフォーマンス改善に貢献できてないのですが(案は出すけど)、貢献できていないとなおさら気になるというか…。まあ、自分もWebサービスを公開したらやっぱりパフォーマンスは気になるというのもあるし(ちなみにいまだにユーザが1桁しかいないのが悲しい(T_T))、久々にオライリー本を買ってみました。BLOG HACKSぶりかな?

ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール
ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール 武舎 広幸 福地 太郎 武舎 るみ

オライリージャパン 2008-04-11
売り上げランキング : 1027

おすすめ平均 star
star利用者の視点
starフロントエンドエンジニアの執念

Amazonで詳しく見る by G-Tools

まだ全部は読んでないんだけど、この本は薄いくせにめっちゃ役に立ちそう。著者はYahooのフロントエンドのパフォーマンス改善を担当としていた人で、その方法論が詳細に記述されています。普通はサーバサイド側の処理の軽量化にどうしても目がいってしまいがちです。しかし、ダウンロードしてからの画面レンダリングに処理の8割が割かれているのです。その8割部分のパフォーマンスを改善するほうがユーザのストレス軽減に関して効果は劇的だということが書かれてます。

いや〜、javascriptを軽くするために頑張ればいいというくらいは考えていたけれど、この本を読んだら目からウロコ。全然知らなかった軽量化術が書かれてました。しかも、基本的にプログラマもしくはWebデザイナーであれば簡単にできる処理が多いッス。サーバサイドの処理や構成を修正しようとしたら数ヶ月単位の仕事になるけれど、この本に書かれてる簡単な項目修正であれば1時間もかからないです。もちろん込み入ったことをすれば数日はかかるでしょうが、それでも数日です。時間とパフォーマンスの費用対効果を考えたら、即効性があり簡単な、この本に書かれていることを実行していけばよいのではないでしょうか?サーバサイドの修正はその後でもいいかと。最終的にはサーバサイドの修正になってくるでしょうけどね。