Home > 技術全般 Archive

技術全般 Archive

Safariで文字化けでDjangoのHttpRequestのcharset指定などを見直す

男の小遣い帳で、Ajaxでデータを取得したときにSafariで文字化けしていた。
自宅のサーバーでは動いていたからおかしいなーと思ってたんだけど、レスポンスヘッダのContent-Typeにcharset指定が無かったようだ。

自宅ではhttpd.confに
AddDefaultCharset UTF-8
と書いていたけど、共用サーバーでそんな設定はしないよな。

とりあえずDjangoからAjaxのレスポンスを返すときに
values = simplejson.dumps(data, ensure_ascii=False)
return HttpResponse(values, mimetype=”text/plain”)

となっていたのを以下に変更。
values = simplejson.dumps(data, ensure_ascii=False)
return HttpResponse(values, mimetype=”text/plain; charset=UTF-8″)

この対応で大丈夫か確認のため、一応Djangoのソースを見てみた。
HttpRequestクラスでは
def __init__(self, content='', mimetype=None):
from django.conf import settings
self._charset = settings.DEFAULT_CHARSET
if not mimetype:
mimetype = “%s; charset=%s” % (settings.DEFAULT_CONTENT_TYPE, settings.DEFAULT_CHARSET)
if not isinstance(content, basestring) and hasattr(content, ‘__iter__’):
self._container = content
self._is_string = False
else:
self._container = [content]
self._is_string = True
self.headers = {’Content-Type’: mimetype}
self.cookies = SimpleCookie()
self.status_code = 200

となっていて、mimetype指定があるときはそのままContent-Typeに突っ込んでいるので、charset指定も普通のヘッダのように書き足してOKっぽい。
mimetypeにcharsetが入っていなかったら、自動的にDEFAULT_CHARSETを追加してくれれば良いのに。HttpResponseにmimetypeを指定するときは、charsetも入れておいたほうが良さそう。

これでとりあえず動いたんだけど、どうやらSafariはそもそも文字化け問題を含んでいるらしい。
(恥ずかしながら知らなかった。)
古いSafariだとContent-Typeでちゃんとcharset指定してもダメなのかな?

とりあえずJavascriptも直しておこうというわけで、以下を参考に直した。
[ajax] Safari の responseText で UTF-8 コード文字化け回避 Kawa.netブログ(川崎有亮)/ウェブリブログ
最速インターフェース研究会 :: SafariのAjaxの文字化けをクライアント側だけで対応するバッドノウハウ
レスポンスヘッダでcharsetを返さなくても、この対応をすれば動作した。

サーバー側もJavascript側も対応して、とりあえず完了。

補足 画面遷移なしでファイルアップロードする方法

画面遷移なしでファイルアップロードする方法というエントリーのアクセス数が多いわけですが、自分でこの方法を使ったときに少し悩んだことがあるので補足。

この方法は、画像をアップロードした瞬間に即座にデータを確定するときにはそのまま使えるが、画像とコメントなどを同時に編集して、次の画面でデータ確認やデータ登録完了させようとすると問題がある。
戻る対応をしていないので、確認画面や完了画面から戻るボタンで戻ると、アップロードした画像が消えてしまうから。

例えば私が嫁ブログ画像アップロードの仕組みを検討していたときは以下のようなことをやりたいと思っていた。

  • 画像とコメントを簡単に登録できる仕組みにしたい
  • 複雑な遷移は操作が難しいので1画面内で画像をアップロードしてコメントを入力できるようにしたい
  • 画像をアップロードするたびに画面遷移させるのはやめたい

上記を実現するためには、画像をアップロードした時点でデータを確定してはいけないわけで、それはあくまで編集中の情報のはず。バリデーションなどは投稿ボタンを押した段階で実施したい。
ただし、画像をいちいちアップロードするときに戻るボタン対応するのも大変そう。(どうやればいいのかすら分からない)
というわけで、大まかに以下のような実装をした。

■画像アップロードボタン押下の動作
1.画像アップロードボタンを押すとiframeをターゲットにしてPOST
2.tmpディレクトリに画像を保存し、結果を返す
3.画像を画面に表示すると同時に、投稿formにtmpファイル名を保存したhidden項目を追加する
※ 「画面遷移なしでファイルアップロードする方法」に書いたのとほぼ同じ
※ hiddenにファイル情報を保存することで、その他のデータと同時にsubmitできるようにする

■画像削除ボタン押下の動作
1.ajaxでPOSTする
2.サーバーのtmpファイル削除し、結果をJSONで返す
3.画面の画像表示とhidden項目を削除

■投稿ボタン押下
1.ajaxでPOSTする
2.入力チェック、画像存在チェック、tmp⇒正規ディレクトリへ画像移動、DB登録、結果をJSONで返す
3.JSONでエラーが返ってきたら、その旨Javascriptで画面に表示する
4.JSONで正常完了情報が返ってきたら、Javascriptで登録完了画面に遷移させる

■その他
1.画像のtmpディレクトリに残ってしまうゴミは、お掃除バッチで削除する
※ たいした利用数ではないので、実際にはたまに手で消しているんだけど。。。

例えばブログなどで、画像をアップロードする画面とエントリーを記入する画面が別々なのは、初心者には難しい様子。ということで簡単に編集できるようなツールを作ろうと思ったんだけど、思ったよりも実装に手間取ってしまった。
とりあえず動いたから良かった。

携帯サイトの文字コードってUTF-8だとどれくらいまずいの?

djangoで携帯サイト。(UTF8以外のエンコードでサイト公開)を見て、素朴な疑問で思ったんだけど、携帯サイトをsjisで作らないとどれくらい問題があるんだろう?

一部の古い携帯で閲覧できなくなるのはわかる(※)。
それって実際ユーザーの何割くらいいるんだろう?
携帯サイトを良く使うようなユーザーなら、そんなに古い携帯使わないんじゃないかとも思う。

Google Calendarを携帯で閲覧できる簡単な仕組みをUTF-8で作って仲間内で使っているが、見られないという話も聞いたことないし。

古い携帯が対応していない以外の問題は何かあるのかな?
仕事で作った携帯サイトは全部sjisだったし何も疑問はなかったんだけど、急にutf-8でダメな理由がそれほど無い気がしてきた。

どうなんでしょう?

※素晴らしいまとめがあった ⇒miniturbo::Memo - 携帯電話での文字コード対応表 まとめ

ORマッパーがあってもSQLは覚えたほうが良い

Matzにっき エンタープライズ

具体的にRails(特にActiveRecord)では難しい事例つき。そうか、こんなことしたいニーズもあるのか。 JavaなORマッパーはこういうのもサポートしてるのかな。

が、80:20則に従った割り切りがRailsの力の源でもあるのでさまざまな状況が考えられる「複雑さ」を一概に支援するのも難しい話だ。

そもそもエンタープライズの仕組みで、複雑かつ重要な状況だったらORマッパーなんて使わないんじゃないかな。
自分だったら怖くて使え無そう。
そういう状況では、生のSQLを書いて、微調整も可能だしチューニングも可能だし・・・という状況にしておきたい気がする。
というわけで、簡単にSQLの世界に降りていける仕組みと、少しくらい複雑なSQLでもすぐにかける能力の両方がないといけないんだろうな・・・という感想。

「80:20則に従った割り切り」で便利なツールやフレームワークを使って、いざというときは下のレイヤーにすぐ降りられる・・・というのが理想的だと思う。

プログラマーと筋トレ愛好家の共通点

なぜかPHPの設計を嫌がる優秀なプログラマーが多いが、スポーツクラブでトレーニングしているときに気がついた。
これは筋トレ中級者以上が、初心者を小ばかにするのと同じだと。

すると、プログラミングと筋トレの間にすごい相関関係があることが分かってきた。

ポイントは3つ
1.レベルが上がっていくにしたがって、当初の目標よりも先へ先へと進む

プログラミングでは 筋トレでは
HTMLを書きたい 腕立てでちょっと引き締めるたい
PHPのincludeを覚える 腹筋やスクワットもやってみる
動的なページを作り出す スポーツクラブでマシントレーニングをする
よくわからないけどオブジェクト指向と言い出す 見よう見まねでフリーウエイトのベンチプレスを始める

以下略・・・

で、当初の目標であるなんとなく引き締まった体は身についているのに、なぜか筋肉を太くすることに目標が変わったり、洋服がきつくなるのが嬉しくなったりする。そこまでいくと、周りからは少しずつ変な目で見られるようになる。

プログラマーも深くもぐっていくにしたがって変人(←一般人には理解できないことに喜びを覚える)になり、いわゆるスーツたちから理解されなくなっていくのではないだろうか。
「とにかく動けばいいのに、きれいな設計がどうこう言われてもどっちでもいいよ、知らないよ」とか
「この言語がどうこう言われても良く分からないよ」・・・みたいな。

2.自分よりレベルが下のものに対して、不必要に高レベルなものを薦める

これがまさしく「PHPの設計が悪くてユーザーは満足できるのか」と言ったり「includeだってテンプレートを使えばほとんどの言語でできるしその方が幸せ」と思う心理と同じである。

筋トレに置き換えると、腕立てをやる人に対してスポーツクラブのほうが効率的だといったり、ちょっと筋トレしてみたいだけなのにトレーニング理論や栄養理論を振りかざしたり、変なフォームの人を見るとあざ笑ったり。
怪我するとか効率が悪いとか言うが、ほとんどの人は怪我するほどの重量は扱わないし、そんなに筋肉つけたいとは思っていないのだ。

しかし、実は初心者もたちが悪い。
ちょっとできると、いろいろできるようになったと勘違いしてしまう。
たいしたレベルでもないのに、こんなことできるぜーといって自慢し、上のレベルを見なくなる場合がある。
こうすると、上級者は「お前のやっていることはたいしたこと無いじゃん」と大人気なく言ってしまうのも道理である。

つまりPHPが幅を利かせて、「PHPすごいぜー」という雰囲気の世の中になると、「そんなのダメだぜ」といいたくなるのもよーく理解できるのだ。

3.そこそこのレベルになると宗教戦争が勃発する

プログラミング言語間やOS間ではしばし宗教戦争が起こる。
とくに個人のレベルが少し上がったころに良く起こる。

筋トレにおいても同じだ。
ベンチプレスはブリッジして高重量がいい派 vs べた寝できっちりきかせるストリクト派
フルスクワットでなければスクワットじゃ無い派 vs ハーフで十分派
(意味分からない人はごめんなさい)

しかしさらにレベルがあがると、宗教を超越してそれぞれの利点なんかを冷静に判断できるようになる。

最後に思い出したのは、itproにのっていたRubyのまつもと氏のインタビュー。
まつもとゆきひろの「プログラミング言語論」【前編】(1):ITpro

そういう人たちはどんどん潜っていって自分のバランスのちょうどいいところで留まるんですが,私の見るところ,その究極の行き先はハードウェアかOSか,プログラミング言語のいずれかのようです。

筋トレも同じだ。行き着くところは3つ。
ボディービル(※1)、ウエイトリフティング(※2)、パワーリフティング(※3)、の3つだ。
フレームワークなんかを開発している人は、さしずめベンチプレス競技(※4)といったところか。

こうして、PHPはユーザーにとっては素晴らしいとかPHPは本当にダメな言語なの?とかで、PHP擁護をしてきたが、けなすほうの心理も理解するに至ったのである。

※1 例の肉体をひけらかすあれである。大抵の日本人は気味悪さを感じるようだ。
※2 オリンピック競技の、重たいものを頭の上まで持ち上げるやつ。生活の役に立つかどうかは分からない。
※3 スクワット、ベンチプレス、デッドリフトの3種目の合計重量を競う競技。デッドリフトは一般人の9割が知らない。
※4 ベンチプレスの重量のみを競う競技。一番人気。レベルが低い人たちもなぜかベンチの重量だけは競いたくなる。

Zope → やっぱりJava、PHPへ

サービスをすばやく開発するための基盤としてZopeを使っていたが、結局JavaやPHPに転換したという話を聞いたことがある。

問題は生産性ではなく、技術者の確保。

自社で技術にコミットしてそれを継承していく覚悟が無いなら、できるだけ技術者を集めやすい技術を使ったほうがいいんだろう。
中途半端に覚えただけだと、トラブルになったときの対処も難しくなるし。

こういう話は、なぜかちょっぴり悲しいというか切ないというかそんな気分になる。

続・システム部門は難しい

CIOと情報システム部門の役割を見つめ直せ - @IT情報マネジメント

先日のアクセンチュアの記事に比べたらかなりいい。
2ページ目の最後の提言にまとめてあって、これがよくまとまっていていい。

  • 情報システム部門は経営情報戦略部門へと進化を遂げるべきであり、経営サイドもそれに気付いて、相応のポジションに位置付けるべきである
  • ビジネスが先か、ITが先かについては企業環境やビジネスモデルに応じて選択されるものであり、経営者は現状の経営戦略策定アプローチが妥当かどうか、いま一度考えるべきである
  • 経営=プロジェクト(プログラム)であることを意識し、CIOや情報システム部門は経営戦略から設計・実装、そしてオペレーションからモニタリング(経営監視と改善施策)まで、多岐の領域に直接的にかかわるべきである
  • 「CIOの必要性」について企業は認識を深め、その育成に関してももっと真剣に注力すべきである

もったいないのは、あまりにも「かっこよく」記事がまとまりすぎている気がする。
特に経営情報戦略部門と言う言葉がかっこよすぎて、現場の若い人なんかはイメージが先行してしまうのでは?

この提言を自分なりに言い直してみる。

  • 情報システム部門は社内のコンサル部隊。相応のポジションになるべきだけど相応の実力が必要。
  • ビジネスでもITでもどちらから入っても良いが、経営戦略に従って両方のバランスを高次元で取れる部隊にならないとダメ。
  • 超上流から泥臭い下流工程や運用、更には評価まで全部関われ、最低でも理解してマネジメントできるようにしろ
  • そういう難しい部隊を率いるCIOはもっと難しい。育成も難しいけどちゃんとやるべき。

システム部門というのはスーパーマン的役割を期待されてるなーと思ってしまう。
戦略コンサル、ITコンサル、SIer、運用アウトソーサーなどなど全てをカバーしてマネジメントしろと言うんだから。

全体像が大きすぎて、どこから手をつければ良いのか分からなくなりそう。
色々関わろうとしすぎると、全てが中途半端になって自分の価値が何なのか分からなくなっちゃうし。

システム部門の難しさ

日本のIT生産性の低さは果たして改善できるのか - @IT

 社内システムの標準化努力が欠けており、さらにレガシーシステムとの兼ね合いでアプリケーションを分離できないために、オフショア開発などの利用によるコスト削減もままならず、SOAに基づくシステムの総合的な刷新も阻んでいるという。

 CIOは本来なら業務部門を束ねて全社的に最適なIT投資を目指さなければならないはず。~中略~「ミッションが不明確で、コスト削減ばかりに注力してしまうケースも見られる」(沼畑氏)。さらに経営トップとのコミュニケーションも年に数えるほどという例があるほどで、CIOとしての機能を果たしていないと指摘する。

 「日本で強い製造業は、徹底的な標準化を図ってきた。製造業でできることが(ほかの業界の)IT投資でできないわけはない」と、沼畑氏は社内におけるITの標準化の重要性を訴えた。

アンケートデータはよいとして、オフショア、SOA、標準化などコンサルでお金になりそうなことを言っているだけだなーという印象。

今のシステム部門はどっちつかずになることが多いと思う。
経営視点を・・・とか言われているために泥臭いIT現場は自分たちの仕事ではないと思ってしまう。
システム部門なのに専門内容は中途半端しか知らず、かといって経営視点とか業務視点も中途半端。
一番ひどいパターンは、業務部門とベンダーの連絡係になってしまい、自分たちは何のために仕事しているんだ状態になる。

どっちの能力も磨かれないまま、成果を出そうとするとベンダーとの値引き交渉などでコストメリットを出すだけになってしまう。
そして、経営や業務の視点でも、ITの視点でも、どちらからでもそのときに本当に良いものが何なのかよく分からない。
つまり本当のところ、いいシステムを作ろうと思ってない、作れない人が多いんだろうな。そして言われたものをいかに安く作るかばかりを目指してしまう。

本来なら、経営とIT両方の視点から高度な回答を期待されているんだろうけど、いきなりそれは酷だと思う。

打開策は、もう一度足元を見てITの要素技術を勉強させたりITプロジェクトのマネジメントを勉強させるのが先決だと思う。自分で手は動かせなくても基本的な考え方を知らないと業務課題の解決のアイデアなんか絶対に出てこない。せいぜいコンサルの言う内容をまとめなおすだけ。
足元をしっかりしようよという感じ。
その上で、優秀な人材にはITの肝を理解しながら経営視点を持つような教育を行う。
一朝一夕では無理だろうけど、いきなり高度な成果を期待したって無理ですよ。

負荷テストツール

どうやらWebLoadという負荷テストツールがオープンソース化されたらしい。
ウノウラボ Unoh Labs: オープンソース戦略により、無償で使えるようになった負荷テストツール

ちょっと大き目のサイトで負荷テストすると、負荷かけクライアント側も気をつけないとボトルネックになってしまうから始末が悪い。
しかも、負荷をかける量、というか仮想ユーザー数で課金されたりしてコストパフォーマンスがすこぶる悪くなってくる。

オープンソースというのは嬉しいけど、比較表のScalabilityあたりを見ると大規模な負荷テストで使うのは厳しいのかな。

ちなみに私が負荷テストしたときは、httperfを使ってた。
いいツールだったと思うけどコマンドライン起動しかないから、シェルで起動スクリプトを作って、リモートシェルで複数マシンから同時に負荷をかけたりしていた。

商用ツールを使うとそういう手間も軽減されるんだろうか?
データ収集とかシナリオ作成とかも簡単にできるんだと嬉しいな。

そのうち機会があったら試してみよう。
ただ、商用ツールになるとびっくりする値段になる(ことが多い気がする)から、費用対効果はどうなのかな?

さくらインターネットのCGIでInternal Server Error

かなり前の話だが、PythonでCGIを書いてみようと思ってさくらインターネットのレンタルサーバーにCGIをアップしたらInternal Server Errorになって、ものすごーくはまったことがある。

トレースも出力されないし、何をやってもダメ。
そもそも実行された形跡がなさそう。
Pythonのパスが違うのかなーとか色々悩んでしまった。

今思うと恥ずかしい話だが、パーミッションを775にしてしまったのが問題だった。
(共用サーバーだからセキュリティの観点からもパーミッションは 755 or 705 にしなきゃ動かない設定になっている)

久しぶりに実際に手を動かそうとすると、ものすごい簡単なところではまる上に、解決策もすぐに見つからないものだなーと実感した。

プロジェクトリーダーとかマネージャーとかになって手を動かさなくなる人も多いと思うけど、実際に手を動かさないで錆付いちゃうと結構まずいこととかあるだろうなと反省した。

Home > 技術全般 Archive

Search
Feeds
Meta

Return to page top