A Day In The Boy's Life -57ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

A Day In The Boy's Life-jQueryUI-sotable1

 

うまく説明するのが難しいので、一番はデモ を見てもらうことでしょうか。

 

(この記事の最後にもデモを用意しています)

 

リスト表示をしていてその順番を入れ替えたいときに、古典的なやり方をしようとしたら、プルダウンメニューで順番に選択して言ったり、ボタンで画面遷移を繰り返しながら順番を入れ替えるという方法があるかもしれませんが、jQuery UIを使えば簡単にスタイリッシュな並び替え画面を実装することが出来ます。

 

 

 

jQuery UI Sortableの使い方

 

 

 

まず始めに、jQuery本体とjQuery UIをロードできるようにしておきます。

 

自サーバーに無い場合は、Google code上にホストされているものを利用してもよいかもしれません。

最も簡単な使い方は、下記のようにulタグにidを指定して実際に動かすためのliタグを記述します。

 

<html xmlns="http://www.w3.org/1999/xhtml" lang="ja" xml:lang="ja"><head><meta http-equiv="content-type" content="text/html; charset=UTF-8" /><>

 


実際にSortableの機能を制御しているjQueryスクリプトは、ハイライト表示している4行のみです。

ulタグに指定するidは、jQueryの制御スクリプト内に指定している「$("#id名")」部分と一致していれば何でもかまいません。

liタグの各々にidを指定しているのは、並べている状態をシリアライズしてURL用のパラメータとして取得するためです。(詳しくは後述)


Sotableには幾つかのオプションがあります。

上記で指定しているのは、「items」で動かす対象のDOM要素(デフォルトでもliタグは自動認識してくれますが)、cursorで要素をドラッグしたときのマウスカーソルのスタイル、opacityで動かした際の透明度を指定しています。

なんとなく、スタイル系の変更はCSSで直接した方が早いような気もしますが。

 

この他にも多くのオプションや、動作時のイベントをフックさせることも出来ます。

 

詳しくは、下記のサイトが参考になるかと思います。

 

jQuery UI API 1.8.4 日本語リファレンス > Interactions > Sortable @ Stack Trace

 

 

上記の例では、liタグを動かす対象にしましたが、その他にもdivタグやtableタグでも動かすことが可能です。

 

 

<table id="sortable">    <tr><td>Item 1</td></tr>    <tr><td>Item 2</td></tr>    <tr><td>Item 3</td></tr>    <tr><td>Item 4</td></tr>    <tr><td>Item 5</td></tr></table>

 


ただし、divタグは自動で要素を認識しえくれますが、tableタグを使う場合は、itemsオプションにtrを指定する必要があります。

(じゃないと、テーブルごと動いてしまいます)

 

$("#sortable").sortable({ items: 'tr' });

 


簡単に導入できるので、既存のサイトでもそんなに手を加えることなく変更することも可能ではないでしょうか。

 

 

jQuery UIのSotableを使ったちょっとしたサンプルコード

 

 

 

せっかくなので、デモサイトに少し手を加えてソート対象要素の追加・削除や送信時のパラメータ取得ができるサンプルコードを書いてみました。

 


- リストの並び替え、追加、削除、送信(するためのパラメータ取得)をするデモ

 

 

 

 

 

リストをドラッグ&ドロップで並び替えるだけでなく、「Add Item」のリンクからリストを追加できます。

 

 

 

削除はリストの右脇にある「×」ボタンで行います。

「Send Data」のリンクをクリックすると、リストの状態をシリアライズしてURLパラメータに変換してくれます。

実際には、送信先にこのURLを付け加えれば状態を保存するということも出来るでしょう。

 

ソースコードは下記のようになります。

 

 

<html xmlns="http://www.w3.org/1999/xhtml" lang="ja" xml:lang="ja"><head><meta http-equiv="content-type" content="text/html; charset=UTF-8" /><link rel=">

 


シリアライズの部分で少しはまったので補足しておくと、動かす対象のliタグのid名で「id名-数値」のようにしておくことで、パラメータは「id名=数値」というように分割して生成されます。

意図的にURLのキーを変更したい場合は、

 

$("#sortable").sortable("serialize", {key:'order[]'})

 

 

のように、第2引数の「key」にキー名を指定します。

 

こうすることで、

 

order[]=1&order[]=2&order[]=3&order[]=4&order[]=5

 

 

というようなURLを生成することができます。

 

jQuery UIのマニュアルを見ると、ポートレットのような機能を作ることも出来るみたいなので、用途の幅は結構広いかもしれません。

 

 

 

 

 

 

このタイトルは、先日読んだ「プログラマが知るべき97のこと 」の74番目に登場します。

そこには、下記のようなことが書かれています。


私はテクニカルリーダーという立場になったばかりの頃、自分の役目は、プロダクトマネージャやビジネスアナリストから来るバカげた要求をはねつけ、自分たちのチームの素晴らしソフトウェアを守ることだけと思っていました。何か要求が来た時には、それを「受け入れるべきもの」ではなく、常に「却下するもの」と捉え、その前提でほとんどの会話を始めていたのです。
(略)
「イエス」から始めるようにする、という簡単な変化だけで、私の仕事への取り組み方は劇的に変わりました。わかったのは「イエス」という返事の仕方にも多くの種類があるということです。

こういったことを思い当たる人、または周りにいるって人は多いのではないでしょうか。

IT部門に勤めていると、絶えず顧客からの要求にさらされます。

その中には、聞くに堪えないものも数多くあり、一通りの話を終える前にその話を握りつぶすかのように反論を始めたりもします。

しかし、そんな話の中にでもユーザーは目的を持って話しており、論点がずれていたりはするものの確かに解決すべき課題というのが見えてくることも多々あります。



「ノー」と答えて行き場を失ったユーザー要求


立場の違いから、言われたことは受け入れざるを得ないというエンジニアも数多くいると思います。

そういった人から見れば、要求に「イエス」ということへのリスクというもの強く認識しているでしょう。

要求を受け入れることで面倒な仕事は増えるは、何らかの変化をもたらすことで実行リスクが大きくなるは、スケジュールがタイトな中でリソースは不足するは、丸投げされるは、とネガティブな要素しか考えられなくなってしまったりもします。


過去に一度痛い経験をしてしまうと、もう二度と簡単に「イエス」なんて言うもんかという態度も取りがちです。

そんな経験があるかないかはわかりませんが、まずは「ノー」と突き放す人は自分たちの領域を守ろうとえらく保守的になってしまっていたりもします。


「ノー」という答えの中には、「それは自分たちの仕事ではない」という意味が含まれていることがあります。

しかし、自分たちがノーと突き放したその要求は誰が解決するのでしょうか。

確かに、しかるべきところがまずは要件を固めるべきという問題もあります。

システム化の施策の中で解決を図ろうにも、IT部門で考える前にその業務であったりルールであったりを整備する担当部門というものの存在があり、そっちで検討してきてから話しましょうね、というような意味合いでノーと答える人もいるのでしょう。


「ノー」という人の中には、ノーといった理由を示さないでただ拒否する人や、たいしたリスクではないのだけど、さも致命的であるかのように拡大解釈して理由を付けるという人もいます。

「客先で資料を参照したいのですが」と聞かれれば「セキュリティの関係でそれは無理です」と答え、「じゃあオンラインストレージでファイル転送とか出来ませんか?」と聞かれれば「予算がありません。おたくの部門で費用を持ってもらえるんですか?」ってな具合で、押し問答を繰り返したり。


頭ごなしに「ノー」と言ってしまうとそのユーザーの要求は行き場を失い、ただただその人の心のうちで消滅するしかなくなってしまいます。

それが本当に会社にとって解決すべき重要な要求や課題であったとしても。

情報システム部門の役割は、自社の業務ドメインを認識し、そこでの問題や変化に対してITを投入して管理していくというものがあるでしょうが、自分たちの領域を守ろうとするあまり、そこに踏み入る勇気を失っていたりもします。

ITのプロ集団であるはずなのに、ITによる解決案さえも出さないのは悲しいことではありますが。



「ノー」では始まらず「イエス」では始まること


ノーと答えることで「情報システム部門がノーと言ったのでダメになった」という変な軋轢も生まれます。

まぁ、イエスと答えると、「じゃあ、後は情報システム部門でよろしく」と丸投げされたりもするので、それはそれでユーザー部門への疑心が募る結果となり、そのバランスの取り方も難しい場合がありますが。


一昔前では、システムは魔法のように思われていたのかもしれません。

そして、餅は餅屋にのように魔法は魔法使いにと情報システム部門に頼っておけばどうにかなるという考えの人も多かったのでしょう。

現在では、ITサービスはコモディティ化しており、魔法使いとしての威厳や持ち味も失われつつあります。

その過去にいいように扱われた苦い経験からか、ユーザー部門と情報システム部門との信頼関係も失われつつあるように思えます。

「イエス」と答えてきた過去があるがその報いが無いからこそ、現在は「ノー」と答えたくなるのかもしれません。

または、「イエス」と答えるだけの力を持ち合わせなくなってしまったということも考えられます。


ただ、それは「イエス」の答え方にもよるもので、きちんと解決すべき課題に対して要求する部門とシステム部門とでどのような体制で取り組んでいくべきかという検討が必要でしょう。

その中には、業務担当部門でしか考えることが出来ないプロセスであったり、解決手法というものが存在します。

お互いがその問題を解決するためにどのように取り組んでいくべきかというのを、双方の役割を明確にしながら進めていけばいいわけで、その一部を担うことに対して「イエス」と答えればいいわけです。


まさに「イエス」にも様々な種類があるということです。

ユーザーの要求というのはいきなりゴールかのように見えて、実際は方向違いでスタートを切っていることも多々あります。

その要求の向こうにある本質的な課題を聞き、別の手段からのアプローチを提供すれば解決する問題かもしれません。

「イエス」から始めれば道は開けますが、「ノー」から始めれば始まりもしません。


「Yes or No」の二極化した答えしかないわけではありません。

その答えはそんなに単純なものではなく、ずっと複雑であり紐解かなくてはならないものでしょう。

それはお互い認識しつつも、双方が自分たちの利益を守るためのカードとしてしか使ってないようであれば本末転倒ではあります。

そのきっかけである「イエス」という回答が望まれるのだと感じます。




プログラマが知るべき97のこと/著者不明
¥1,995
Amazon.co.jp


以前に「ソフトウェアアーキテクトが知るべき97のこと 」という本を読みましたが、体系的には同じでそのプログラマ版になっています。

ただし、レイヤーが違うので書いている内容も別物。

仕事やキャリア上、どちらが今の自分に近いのかで読み分けてみるのもいいかもしれません。


この本は、世界で活躍する著名なプログラマの体験からくるベストプラクティスとなっています。

それを読んで感じたことは、


・ どんなに優秀なプログラマでも躓く問題というのは同じである

・ 問題が大きかれ小さかれ対処する方法はごく基本的な解決方法をとる

・ 原始的な技術とアルゴリズムの重要さ

・ プログラムを芸術へと昇華するそのこだわり

・ 学び続ける姿勢


といったことでしょうか。


具体的なソースの書き方というものを示したものではありません。

ただ、プログラマとはいえソースコードを書く意外に知るべきことが数多くあるというのも事実です。

そういったことを、それぞれ経験豊富なプログラマの体験を通してつづられており、プログラマとして経験があるエンジニアが読み進めていると誰しも当てはまるということがかかれているかと思います。

この辺は、誰しもが通る道であるということがわかり安心感も得られます。


特にテストのこと、人間関係、そして保守性への考慮とコードへの美しさのこだわりというのが目に付きます。

これは一般的によく言われていることですが、多くのプログラマ改めてそう書いているのを読むと、その重要性というものも増して感じ取れるのではないでしょうか。

そのプログラマとしてのこだわりと、基礎的な知識が如何に大事なことであるかということを。


優秀なプログラマほど、考えが複雑であるように見えますが(確かに面と向かってしゃべると何を話しているのかわからないことも多々ありますが)、結構シンプルでそのシンプルな考えを徹底する強いこだわりがあるのだなと感じます。

プログラマがソースコードのことだけでなく、プログラマとして生き残っていくためのノウハウを詰め込んだ一冊となっており、プログラマのみならず一緒に仕事をする非エンジニアも、その考えを理解できるのはないかと思います。