2010年01月30日

うそなき

こなつがレベルアップしました。

こなつはうそなきをおぼえた

こなつのえんぎりょくがこうじょじょうしました。

こなつはてごわくなった
posted by aki at 09:16| Comment(0) | TrackBack(0) | 小夏 | このブログの読者になる | 更新情報をチェックする

2010年01月16日

救急車

今週の日曜日、天気が良かったので、ピザハットのピザ(8,9,10日は「ハットの日」で持ち帰りは半額)を近くの公園で食べることにしました。

公園には滑り台があって、どろんこになるまで滑りまくって、超ご機嫌でしたわ〜。

で、子供センターで小1時間ほど遊ばせてから、買い物して帰ろうと思って車で移動してたところ、小夏がいきなり嘔吐し、すぐに帰宅も繰り返し嘔吐が続き、病院に連れて行くことになりました。

いろいろ病院に電話したんですが、結局救急車のお世話になることに...。

病院でははっきりとした原因はわかりませんでしたが、2時間ほど点滴をすることになりました。

点滴をさせるのも大変でしたが、大分弱ってたのか点滴が始まるとすぐ寝てしまいました。で、1時間半ほどして目が覚めると、ちょっと元気になっており、残りの30分嫌がって暴れるぐらい回復しました。

しかし、今度はmamiさんの気分が悪くなり、嘔吐を...。

 

次の日、予定を全部キャンセルして2人の看病してたんですが、今から考えると、小夏はどうもノロウィルスにやられたんじゃないかと思われ、mamiさんも2次感染でやられたのかと...。

akiも水曜日に全身に寒気がし、お腹の調子が悪く、ファミリー全滅の危機を迎えましたが、次の日には治ったんで、単なる風邪だったのか、耐性があったのか...でなんとか「ほぼ壊滅」状態で済みました。
よく聞く話なんですが、子供が風邪とかもらってくると、家族全員が次々とやられるって話は結構本当のことだと思います。

 

ようやく家の中が落ち着いてきたんですが、今週はほんとに大変でした。

posted by aki at 11:15| Comment(0) | TrackBack(0) | akiの独り言 | このブログの読者になる | 更新情報をチェックする

2010年01月10日

HTTPの間違いやすい点

Web開発者はHTTPについて知らない(Webを理解してないWebアプリ開発者)ということを書いたんですが、HTTPを簡単に言ってしまうと、リソースに対するCRUDについての取り決め(プロトコル)です。本来はW3CのRFCを読むのが良いんですが、以下のサイトが非常によくまとまっていて読みやすいです。

で、HTTPの細かいところの言及は避けるとして、aki的には、このHTTPを利用するときに間違えやすい点をまとめていこうと思います。

 

@リソースにURIを割り当てていない

リソースというのはURI(Uniform Resource Identifier)というIDで一意に識別されます。

1つのURIに複数の意味を持たせ、渡すパラメータ(クエリーストリングなど)でリソースを識別しようとすることです。

例えば、こんな感じ

/resources?type=entity&id=resource1

こういう場合は、以下のようにリソースにちゃんとIDを割り当ててやるほうが望ましい。

/resources/entities/resource1

 

Aリソースの操作に正しいMethodを利用しない

次にMethodについてですが、リソースのCRUD操作についてそれぞれMethodが存在します。

  • Create:POST
    ※ HTTPはリソースに対するCRUDですが、RPC的(WebServiceなど)な利用ではPOSTを使用します。 拡張解釈をして、サーバー側の処理で結果というリソースを新規作成すると考えれば妥当なのかと...。
  • Read:GET
  • Update:UPDATE
  • Delete:DELETE

上の@にも絡んでいて、ちゃんとリソースにIDを割り当ててないということも原因になってる場合が多いんですが、リソースの操作を他のMethod(大抵POST)で代用してしまうことです。

/resource/entities/resource1

Method:POST
Parameters:cmd=DELETE

本来は、

/resource/entities/resource1

Method:DELETE

HTML 4.0の仕様上、FORMタグではPOSTかGETしかMethodに指定できないので、POSTでDeleteを代用するしかない(HTML 5やXMLHttpRequestではPUTやDELETEも指定できる)のですが、パラメータとかに操作を指定してしまったりします。
こういう場合は、X-HTTP-Method-Overrideという拡張Headerで行いたい操作のMethodを指定してPOSTするようにするのが望ましい。

/resource/entities/resource1

Method:POST
Header:X-HTTP-Method-Override=DELETE

また、リソースのReadで認証情報などの情報が必要で、クエリーストリングの一部として指定したくない場合にPOSTで代用してしまうこともあります。そのような情報は、HeaderやCookie(Secure Cookie)を利用するべきであり、特に認証に関しては、HTTP認証を行なえばクライアント(ブラウザ)が自動的に対応してくれます

まぁ認証をするということは、「サーバー側で認証済みトークンを新規作成する」と考えれば、POSTでも良いとは思います。

 

BStatus Codeを使い分けない

サーバー側の処理結果をクライアントにResponseとして返すとき、Responseにはその処理結果に対応したStatus Codeを指定する必要があります。

実はこれが結構守られていない。

Status Codeをいくつか紹介すると、

  • 200(OK)
  • 201(Created)
  • 202(Accepted)
  • 204(No Content)
  • 301(Move Permanently)
  • 302(Found)
  • 303(See Other)
  • 304(Not Modified)
  • 400(Bad Request)
  • 401(Unauthorized)
  • 403(Forbidden)
  • 404(Not Found)
  • 405(Method Not Found)
  • 406(Not Acceptable)
  • 409(Conflict)
  • 410(Gone)
  • 412(Precondition Failed)
  • 415(Unsupported Media Type)
  • 500(Internal Server Error)

などがあります。

よくやってしまうのは、

  • 何でもかんでも200(OK)にして処理結果の詳細(例えばエラーメッセージなど)をResponseのMessage Bodyにセットする。
  • ResponseにセットするEntityが無いにもかかわらず200(OK)をセットしてしまう
    →204(No Content)を使う
  • リソースの作成で200(OK)を返しえしまう
    →201(Created)を使う
  • 処理後の転送で302(Found)を利用するが、転送した際にMethodまでも変更してしまう
    →303(See Other)を使う

などです。

 

Cすぐセッションを使う

HTTPは、1回のRequestとResponseでリソースの処理が完結します。
つまり、状態を保持しない(Stateless)な処理が原則です。

言い換えると、何回実行しても常に同じ結果が返されるように作るのが望ましく、HTTPのRequestとResponseはその経路や回線の状況によっては結果が返される順序が入れ違って返されることもあるため、呼び方や順序によって返される結果が変わるのはStatelessの観点からは望ましくないと言えます。

また、HTTPの話をすると、決まって「セッションってなに?」とか「セッションってないの?」と聞かれますが、セッションとはサーバー(コンテナ)の機能であり、サーバー側で状態を保持するときに使用するオブジェクトで、HTTPには規定されていません

それより、本当に状態を保持する必要があるのかということを検討したほうが良いです

検討した結果、状態の保持(Stateful)が必要というのであれば、その情報をどこに(Scope)どのくらいの期間保持するのか(ライフサイクル)を検討し、アプリケーションの構成によって、状態の保存する場所(Scope)を決定します。

  • クライアント
    • Cookie
    • Parameter(クエリーストリングやHeaderなど)
  • サーバー
    • Web Tier(SevletのHttpSessionやJSFのManagedBeanなど)
    • Business Tier(EJBなど)
    • Data Tier(データベースやファイル)

加えて、これらの保存した情報を保存期間が終了したら、適切に破棄するようにしなければなりません。

D内容ネゴシエーションを利用しない

Webアプリケーションにおいては、クライアントは受け取り可能なVariant(MediaType、言語、文字セット、エンコーディングなど)をサーバー教えてあげる必要があるし、サーバーもクライアントに対して実際に返すEntityのVariantを教えてあげることで、サーバーとクライアントが通信を行なうことができる。(内容ネゴシエーション)

まぁそういう規定がプロトコルのプロコトルたる所以なんですが、そんな機構を利用せずにRequest時にパラメータにVariantに該当する情報を指定したりResponseにVariantをセットせずに放置してEntityを返すようなことをしたりしてしまう。

正しくは、

Request Headerについては

  • Accept:クライアントが受け取り可能なMediaTypeを指定する(複数および優先度を指定可能)
  • Accept-Charset:クライアントが受け取り可能な文字セットを指定する(複数および優先度を指定可能)
  • Accept-Language:クライアントが受け取り可能な言語をセットする(複数および優先度を指定可能)
  • Accept-Encoding:クライアントが受け取り可能なエンコーディング(gzip等)をセットする(複数指定可能)

これらの組み合わせの中からサーバー側にとって最適な組み合わせのVariantが利用されます。
もしサーバーが処理できるVariantが存在しない場合、ResponseのStatus Codeに406(Not Acceptable)がセットされることになります。

Response Headerについては

  • Content-Type:EntityのMediaTypeや文字セット(charset)を指定
  • Content-Language:Entityの言語
  • Content-Encoding:Entityのエンコーディング(gzip等)

をセットすべきです。

 

EPrecondition(事前条件)を正しく利用しない

まぁこれはアプリケーションの設計によるところもあるんですが、Precondition(事前条件)を利用してリソースのバージョニングができるんですが、この機構を適切に利用していない。

Preconditionを利用するには、

Request Header

  • If-Match
  • If-None-Match
  • If-Modified-Since
  • If-Unmodified-Since

Response Header

  • Last-Modified
  • ETag

を使用し、各Methodでは以下のことができるようになります。

  • GET:クライアントでリソースのキャッシュが利用できる
  • POST、PUT、DELTE:リソースに対して楽観的ロックを行なうことが可能

こういう機構がありながら、

  • サーバー側でリソースのキャッシュ機構を設ける
  • リソースの楽観的ロックでロック失敗したときに正しいStatus Codeを返していない
    →409(Conflict)を返すべき

ということを目の当たりにしたことがあります。

実際に自分の会社でアプリケーションのサーバー側にキャッシュ機構を設けようという話があり、「先にクライアントのキャッシュを利用すべき」&「サーバー側で不特定多数のリクエストのキャッシュを保持するのは現実的に難しい」ということを1から説明し、その話は無くなった(と思われるんだが、ちゃんと理解したのかなぁ...)。

 

 

 

以上、Webに携わるものとしては常識(HTTP自体が常識?)に近いところなんですが、結構知らずにに使っているのが現実のような気がします。
これがわかれば、Web APIとしてかなり市民権を得てきたRESTも、リソースがHTMLページではなく、XMLやJSONなどのデータになっているだけであり、RESTだから厳しく使用方法を規定しているわけではないのが理解できると思います。

大分好き放題書いてみましたが、結局のところ、この内容が「あたりまえじゃん!」と思っていただけるような状況になれば幸いです。

posted by aki at 13:33| Comment(0) | TrackBack(0) | コンピュータ | このブログの読者になる | 更新情報をチェックする

2010年01月09日

Webを理解してないWebアプリ開発者

最近、社内の技術指導で必ず最初にWebの話から行います。

Webを利用するってなんだろう?と考えると、端的にはHTTPというプロトコルを利用するということなんですが、

  • Webアプリ:Web(およびそれに関連した技術)を利用したサーバーサイドのアプリケーション
  • Webアプリのクライアント:一般にはブラウザ

となります。

話し始めは「何をいまさら...」って顔されるんですが(特に経験者)、話していくうちにみなさんWebに関してのリテラシー(特にHTTPの仕様について)が低いことに気付いてくれます。

まぁいろいろ原因はあると思うんですが、

  • Webがアプリケーションのベースとして利用できることが認知され、世の中に急速に広まってしまった
  • 仕様を理解してなくても動くものが作れてしまうような技術が発達してしまった
    • Servlet
    • コンテナ
    • アプリケーション・フレームワーク(strutsなど)
    • ...

のが主な原因として挙げられると思います。

akiはJavaが専門なんでJavaを前提として話をしますが、ほんとにServletは便利で、ServletによりJavaはWebのサーバーサイド技術の代表格として定着したといっても過言ではありません。でも、Javaを利用したWebアプリ開発者はServletやJSPのAPIは知っていても他のJavaEEの技術を知らないというか、ServletがJavaEEの仕様の一部ということすら知らないといったことが現実だと思います。(まぁなんでこんなことが言えるかというと、自分もそんな時期があり、お恥ずかしながらWebアプリを開発している会社で問題なく通用していました。(u u;)

blogなどでServlet等のWebアプリに関する技術のサンプルを書いている方がいらっしゃいますが、その方々はHTTPに熟知している方もいらっしゃると思いますが、そのHTTPに関しては前提というか常識のため大抵何も言及されていません
そんなblogを、前提の知識を持っていない方がアプリ開発の参考にしてしまうと、知らず知らずのうち(まぁほんとに知らないんですが...)にHTTPの仕様から逸脱する利用方法を行ってしまいます。
それでも、アプリケーションとしては動いてしまうため、

動作してしまう=正しいこと

という思い込みから、それを他の人に発信し...ということが繰り返され&積み重なり、Webというものを知らない&理解していないWeb開発者が出来上がっていっているわけです。

そんな流れを少しでも抑止するべく、社内では必ずWebおよびHTTPの説明からするようにしているのですが、このblogが誰かの参考になればいいなぁと思ったわけです。

posted by aki at 15:05| Comment(0) | TrackBack(0) | Web | このブログの読者になる | 更新情報をチェックする

イターイ

今日、小夏の新型インフルエンザの予防接種に行ってきました。

チクッとするので、注射で泣いちゃうかな〜と思ってましたが、診察室を出るときに「イターイ」とのたまわった(最近覚えたばかり)だけだそうな

...周りのお子様は大体泣いているのに...そのくらいの注射じゃもう泣かなくなったようです

下の写真は、帰りに近くのコメダ珈琲店にいってシロノワールを食べているときのものです。口の周り真っ白ですわ〜。

 

100109_1126~0002

posted by aki at 13:40| Comment(0) | TrackBack(0) | 小夏 | このブログの読者になる | 更新情報をチェックする

2010年01月08日

新しいあだ名

小夏のあだ名がまた新しく増えました。(おいらはあだ名担当)
  • あばれまっクィーン
ちなみに、いままで付けられたあだ名は...
  • あま゛えんぼう将軍(ま゛=ま+ば)
  • クイージ(食い意地)
  • 怪獣コナラ
...
もっとたくさん付けたはずなんですけど、忘れてしまった。ちょっと惜しいなw
posted by aki at 18:27| Comment(2) | TrackBack(0) | 小夏 | このブログの読者になる | 更新情報をチェックする

はじめてのコーヒー

家族でミスタードーナツに行ったら、小夏がおいらたちのカフェオレを舐めました
おいらのカフェオレはガムシロップを入れて甘くしてたんですが、mamiさんのは甘くしてなかったんで、舐めた瞬間、ビクッっとしてへの字口になりました。子供の味覚にとっては、相当苦かったと思われ...。
まぁこれで懲りる小夏ではないのだが...。
IMG_7847
「低燃費少女ハイジ」の手ぬぐいをガチャポンして、少し満足げなこなさんです。
posted by aki at 16:25| Comment(0) | TrackBack(0) | 小夏 | このブログの読者になる | 更新情報をチェックする

2010年01月06日

最新の技術にキャッチアップするのは難しい?

ここ何年も思っていることなんですが、大学を卒業したての人たちがIT関連の会社に入社して技術者というか開発者としてプログラミングで一人前になるのは非常に困難だと思っています。

というのは、会社の研修で習うことといえば、せいぜいオブジェクト指向の基礎だけで、そんな内容しか知らない状態で開発という名の製品のメンテナンスに携わる...
製品も数年前のstrutsベースのMVCモデルのアプリケーションだったりするわけで、そうでなくても知っておかなきゃいけない技術情報も年々多くなってきており、こんな状況下であっという間に1年経ち、すぐ同じ道を辿る後輩の面倒を見る...。

自分はJavaのサーバーサイドの開発とくライアンとのUIをメインに行っており、Java(JavaEE)とJavaScriptが専門なんだけど、どうも最近の状況が変わってきた感じがあり、一昔前のプログラミング・スタイルでは通用しなくなってきた感がある。
そのため、今まで技術者でやってきた人間も新しいスタイルを知らないまま古いスタイルのプログラミングを後輩に継承したりしてしまう。
また、インターネットに掲載されている情報(特に日本語のサイト)も大抵古い情報であったり、その技術の特徴的なところだけの紹介で、深い内容のものがほとんど無いのが現状である。
そんなこんなで、現在の日本において、最新の技術にキャッチアップするのは新しい人たちも、古い人たちも、相当難しい状況になっていると思うわけです。
まぁこんなことを常日頃思っていたんですが、チームに配属した後輩に対して、なるべく時代にキャッチアップした内容の必要な知識を昨年末から講義したので、今後自分なりにまとめていきたいなぁと思っています。
posted by aki at 23:15| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2010年01月05日

いちごの日

今日のおいらは仕事始めでした。
あさの電車は若干空いてましたね。
やはりまだお休みの人も多いんだろうか。
ぜんぜん関係ないけど、今日は『いちごの日』なんで、いちごシューを買ってみました。
いまから食べることにします。
posted by aki at 22:52| Comment(0) | TrackBack(0) | akiの独り言 | このブログの読者になる | 更新情報をチェックする

2010年01月03日

3日坊主

3日坊主とすら言えない状態をさけるため、とりあえず書いてみました。
明日から会社の仕事始めですが、社長の挨拶がめんどいというのはおいといて、帰省のときの渋滞を少しでも避けるため、明日は休んで5日から出社です。
まぁのんびり帰りますわ〜。
posted by aki at 20:11| Comment(0) | TrackBack(0) | akiの独り言 | このブログの読者になる | 更新情報をチェックする

2010年01月02日

書初め

小夏さん、書初めを行いました。
IMG_7677
 
惨事とならぬよう、100円ショップで雨合羽を用意してたんですが、そんなに凄い事態になりませんでした。
もうすぐ1歳5ヶ月なんだけど、筆の持ち方とか勢いとか堂に入ってますわ〜。(親がいうのもなんですがw)
ちなみに、隠れて見えませんが、左手に饅頭を持って煩悩丸出しで臨んでます。
作品番号@
IMG_7688
作品番号A
IMG_7689
作品番号B
IMG_7690
作品番号C
IMG_7691
posted by aki at 20:10| Comment(0) | 小夏 | このブログの読者になる | 更新情報をチェックする

2010年01月01日

あけましておめでとうございます

あけましておめでとうございます〜長く沈黙しておりましたが、まだ元気(?)に生きております。で、恒例の言い訳ですが、
  1. お仕事が忙しい、というか、モチベーションが上がらないのが日常生活に影響している
  2. mamiさんと使うPCが同じなので、長時間の占有が難しい(ちなみに、今日は結構早く起きたw)
  3. 最強生物「小夏」(現在1歳4ヶ月半)のお相手が深夜近くまで続く(今は寝てますw)
といったこと(特に3番目がハンパねぇ〜)で、なかなかBlogから遠ざかっていましたが、まぁぼちぼち開始しようかなぁといった年始でございます。 ちなみに、実家の犬山市は昨晩から雪が積もって、結構寒いです。
とりあえず、今日は飲んだくれておしまいだと思います。(だめ人です)そうそう、明日は小夏と書初めします。いっちょ前にペンとか箸とか大人と同じように使っており(結構子供らしからぬ状態ですw)、とある人から「書初めさせなさい」とアドバイス受けたんでやらせてみます。(昨日、子供用の雨合羽を用意しましたわ〜)どんな賛辞、もとい惨事となるかはご報告します〜。では、今年もよろしくお願いします〜。
posted by aki at 08:44| Comment(0) | akiの独り言 | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。