思ったより反応があったので、満足です。
次回は他のネタでも発表してみたいと思いまーす。
Nds＃24 単体テスト
View more presentations from Kazumune Katagiri
checkboxをチェック状態にする時の注意点
お陰様でjQueryのせいでhtml以外でUIを書きたくありません。
さて、jQueryでcheckboxをチェック状態にするには、
$("input[type='checkbox'][name='checkboxName']").val(['001','002']);
のように、1行で書けてしまいます。val()の中には配列を設定することでレスポンスの値を元にチェック状態を設定することができます。
ですが、val関数の引数にnullを設定してしまうとcheckboxのvalueが消えてしまいます。画面上は問題なさそうなのに、value値が取得できず、小一時間ハマりました。
それにしてもcheckboxの構成情報をマスタから取得して表示しつつ、テーブルから取得した値を参照しながらcheck状態にするような画面をstrutsなんかでやる時はえらく面倒だったのですが。最近も面倒なんでしょうかね？
Selectorsって便利だけど
jQueryを使う上でSelectorsは避けて通れません。これに合致する奴にイベント設定や、css付与することができ、パズルみたいでちょっと楽しかったりします。
で、今回こんな構成でaタグにクリックイベントを追加しようと思いました。
<table id="table1"> <tr> <td><a href="javascript:void(0)">AAA</a></td> <td>あいうえお</td> </tr> <tr> <td><a href="javascript:void(0)">BBB</a></td> <td>かきくけこ</td> </tr> <tr> <td><a href="javascript:void(0)">CCC</a></td> <td>さしすせそ</td> </tr> </table>
jQueryはこんな感じで記述。
$("#table1 a").click(function(){ alert("押したね"); });
FireFoxで動作確認して、じゃーIEは・・・と思ったところ、IE8で動かない。IE9では動くのに・・・。
結局、Selectorsを複数の要素で使うときに先頭にid属性があるとうまく動かないようでした(ちょっと自信ないです)。
先頭にclass属性でやれば良いっぽい。tableはこんな感じ。
<table id="table1" class="table1Class">
jQueryはこんな感じで記述。
$(".table1Class a").click(function(){ alert("押したね"); });
ブラウザ統一できねぇかな・・・。複数のバージョンで挙動が違うってのは飽きました。
イマドキのWebシステムに向けて
最近のWebシステムは、クライアント依存しづらくしなきゃだめよねー、ということで、サーバサイドにはJava、クライアントはJSON+JavaScriptでレンダリングという構成でシステム構築を考えております。そんな中で気づいた事をメモっとこうかなぁ、と。
なんでそんな構成にするの？
PCのWebブラウザだけでなくスマフォのブラウザやネィティブなアプリに対応しやすくするためです。サーバサイド処理を変えることなくクライアント側の処理で対応させちゃおうということです。サーバサイドの処理はJavaでなくてもPHPやRubyでもなんでも良いわけです。クライアント側と会話さえできれば。
サクサク感がたまらない
今まではsubmitして画面表示しなおすという方式が当たり前だったのですが、この方式に慣れてしまうと、画面遷移がモサく感じます。何か、ボタンを押すたびに画面が切り替わってスクロールバーが一番上に戻ることに違和感を持つようになりました。
そして、レスポンスには、必要な情報だけ返せば良いというのが気に入っています。ある部分だけ書き換えたいのに他の余計な情報まで意識してレスポンスに含めないといけなかったあの頃の俺、どうかしてるぜ、的なノリです。何ていうんでしょうか、検索条件を受け取り、検索結果を返す処理なのに、レスポンスには検索条件も含めなければならない違和感。それが無くなり、必要な情報だけ返せば良くなった、というのは処理の見通しも良くなる、ということです。
ハマらない為の工夫
処理の分散を防ぐ
jsで判断文を書くとロジックがサーバ側とクライアント側に分散する可能性があるので、できるだけサーバサイドに処理を押し込んでjsではレンダリングに徹してもらうのが良いのではないか、と思います。どうせJSPでその辺の処理を書いていたわけですからサーバの負荷はそんなに大きくなるわけじゃないと思いますし。
サーバとの通信
同期させてます*1。非同期にすると同期が必要な時にいろいろ制御しなきゃいけなくなりそうでしたから。同期しておけばその辺を考えなくて済みますし。全画面描画しなおすのが嫌なだけです。
小悪魔女子大生のサーバーエンジニア日記
読みました。後輩クンからのありがたいプレゼントを使って購入。
小悪魔女子大生のサーバエンジニア日記 ――インターネットやサーバのしくみが楽しくわかる
- 作者: aico,株式会社ディレクターズ,村井純
- 出版社/メーカー: 技術評論社
- 発売日: 2011/01/27
- メディア: 単行本（ソフトカバー）
- 購入: 10人 クリック: 1,135回
- この商品を含むブログ (50件) を見る
この分野に対して情報処理技術者試験の参考書を読むよりも理解度は増します。「言葉だけ知ってる」ことを理解できたことがいくつかあって、何気に僕には為になりました。でも、手書き部分はイマドキの文字っぽくてやや抵抗アリ。
これ読み終わった後、「餅月あんこ」って今何やってるのかなーと思っちゃいました。ドラネコシアター好きだった。
くやしいと思ったその後に
「仕事で『くやしい』と思ったことの無い人は恐ろしいほど仕事が順調か、目標が低い人だ」みたいなことをつぶやきで見ました。まったくその通りだと思います。
ただ「くやしい」と思うだけでは成長しません。その後どうするか、ということが大事だと私は思うのです。
私の経験からですが、「くやしい」思いをして、どうしたらその思いをせずに済むかを考えて仕事に取り組めば必然的にいい仕事ができると思います。他人にごちゃごちゃ言われていやいや勉強するよりも、自分から能動的に勉強しようとした方が身につく筈です。
くやしい思いをして、「時間が過ぎるのをただ我慢して待つ」のでは成長しません。メンバーやお客さんに恵まれなかった、運が悪かったと思うのは簡単ですが、自分ではベストを尽くしたのかを振り返ることも必要でしょう。
プロの開発者を自負するなら、言われたことだけでなく、プロジェクトや自分に足りないものは何かを常に把握してそれを補わなければなりません。「流行っているから」も勉強する上でひとつの動機になり得ますが、だからといって対価をもらう価値があるかというと別問題です*1。
ですが、会社間の政治的な事柄や契約的な事柄に対しては、個人の頑張りではどうしようもないことの方が多いでしょう。私も経験がありますが、SES契約だから自分のやりたいようにできないこともたくさんあります。その会社の社内標準フレームワークをそのプロジェクトでは絶対にFitしないことがわかっているのに使わざるを得ず、無理やり使ったことでスケジュールが大幅遅延したことや、理解できない設計書を与えられ、質問は受け付けられず解読しながら実装したら仕様バグを実装バグとされて「行間読め」と怒られたこと等。
ただ、SES契約には成果物責任はないので言い方は悪いですが「時間が過ぎればサヨウナラ」が通じてしまうことが多いのです。やっぱり「点」の作業にならざるを得ないことが多い。SES契約は与えられる責任が小さくなることもありますが、会社にとってのリスクは少なくなります。成果物責任が発生する元請け側の契約では、時間が過ぎても何の解決にもなりませんから。元請け側はそれなりのリスクを抱えているのです*2。
仕事をする上でそんなジレンマを抱えている人も多いことでしょう。ただ、「どうせ勉強しても意味が無い」と思い始めたらそこで成長は止まってしまいます。いつか自分のやりたいようにできるプロジェクトが振ってくるかもしれませんし、転職することで自分のやりたいことが実現できるかもしれません*3。自分がやりたいことを思い、それが実現した時にうまく立ち回れるように今不足していることを勉強しておくことも良いかもしれません。システム開発に携わる人は「俺、ここまで知ってるから勉強しなくて大丈夫」ということにはならないと思います。都度勉強していかなければ仕事ができなくなっていく日がもう来ていると思います。昔うまくいったことがこれからもうまくいくとは限りませんし。
さらに、今の境遇が自分にとって「くやしい」と思うなら、その状況に置いている会社に不平を言うよりも、自分が次も同じようにならないためにはどうすれば良いか考えて行動した方が良いと思うけどな。今は変わらないかもしれないけど、きっと次に活きるはず。感覚がマヒしちゃって「くやしい」と思わなくなるのが一番やばい。
