MW211 EXIT

devlog
どっち?/末尾に「。」は必要か
2012年01月17日
設計に限った話ではないが、パソコンで書く文章に句点(「。」)は必要なのだろうか?

日本語としては当然「。」があった方がいいのだろう。
そういう常識から、「。」がないことを画一的に批判する人もいる。

でも、読みやすさとしては、「。」で改行した方が断然見やすい。

ってことは、末尾の「。」って別になくてもいいじゃんと思う。

実際、禁則処理なんか気にせず「。」を改行コード(\n)に置換しちゃえば楽チン。

別に「。」の後に空改行をいれなくても全然違和感はない。

ま、最大の欠点は、一行に二文以上書けないということなんだけどね。

ここだけ、「。」で区切るってのもね(だいたい、「。」は全部置換するつもりだし)。

ってことで、当ブログでは一行に二文以上書きそうなので、
他の文書とは違って「。」を使ってます(ダブルスタンダードは避けては通れない)。
分類:設計、どっち?
JavaScript/周期処理
2012年01月16日
┌──────────────────────────────────────┐
│init() {                                                                    │
│  setInterval(func(), 1000);  // 1秒周期                                    │
│}                                                                           │
├──────────────────────────────────────┤
│function func() {                                                           │
│  処理;                                                                     │
│}                                                                           │
└──────────────────────────────────────┘
                    「setInterval()」↓  ↑「setTimeout()」
┌──────────────────────────────────────┐
│init() {                                                                    │
│  setTimeout(func(), 1000);  // 1秒周期                                     │
│}                                                                           │
├──────────────────────────────────────┤
│function func() {                                                           │
│  処理;                                                                     │
│  setTimeout(func(), 1000);  // 1秒周期                                     │
│}                                                                           │
└──────────────────────────────────────┘

こんな感じで書き分けられる。

前者は何が何でも時間に厳格で、後者は前の処理が終わるのを待ってくれる。
分類:JavaScript
jQuery/いろいろあるよね(1)
2012年01月15日
jQueryってやり方がいろいろあって、知らないと損した気分(不安な気分)。

┌──────────────────────────────────────┐
│(1) $(this).val()                                                           │
│(2) $(this).attr("value")                                                   │
│(3) $(this)[0].value                                                        │
└──────────────────────────────────────┘
これらは全部、同じ。

ちなみに値を代入したい場合にはそれぞれこう。
┌──────────────────────────────────────┐
│(1) $(this).val("値")                                                       │
│(2) $(this).attr("value","値")                                              │
│(3) $(this)[0].value = "値"                                                 │
└──────────────────────────────────────┘

これらの基本を踏まえて他の属性で処理に迷ったら流用すればよい。
(3)はprototype.jsっぽい書き方。
(2)はjQuery的な書き方。
そして(1)は特殊なjQueryに特化した書き方
(属性によっては該当するメソッドがない場合が多い)
ってとこかな。

jQueryにこだわらないのであれば、(3)にしとけばjQueryのない世界へ置換しやすい。
jQueryにどっぷりというのであれば(2)から入って(1)の知識を増やしていくって感じか。

(2)と(3)を把握できれば、立ち往生する機会が減るかも。(後で見直す(改善)のも重要)
分類:jQuery
jQuery/セレクタ徳川家康(2)
2012年01月14日
「$(this).children()」と「$(this).find()」の違い。

前者は子供だけ、後者は子々孫々まで。

家康の場合
「$(this).find("光圀")」はみつかるけど
「$(this).children("光圀")」はみつからない。


「$(this).find("慶喜")」とかまでOKだ。
分類:jQuery
jQuery/セレクタ徳川家康(1)
2012年01月13日
わかる人にわかればよい。
徳川家康が起点です。

家光から義直を捜す場合。

「$(this).parents()」=「秀忠、家康」だから

「$(this).parents("義直")」ではみつからない。

「$(this).parents()」ってのは、直系の先祖を辿ってくれる。

「$(this).parent()」だと、単数系だから親一人だけ(「秀忠」)

「$(this).find()」てのは子々孫々まで全部を網羅する。
#たぶん、引数に条件を指定して絞り込む使い方普通なんだろうけど

ってことは、
「$("家康").find()」=「秀忠、家光、家綱、義直、光友、頼宣、頼房…」だから

「$(this).parents().find("義直")」でみつかる。

律儀者だったら「$(this).parent().parent().find("義直")」かもね。
#いやいや、中途半端な律儀ぶりだけどね
分類:jQuery
設計/パスワード
2012年01月12日
パスワードってのは他人に知られてはいけない。
だから暗号化する。

「A(暗号化前)→B(暗号化後)」を例として話を進めると。

「A」を管理するのは危険だ。
もし管理者が会員全員のパスワードをすべて持っているとしたら
それを覗かれた場合大変なことになるので、かなり神経を使うことになるだろう。

暗号には復号がつきものだ。
でも、パスワードの場合は復号の必要はない。
パスワードが一致すればそれで事足りるのだ。
もし、パスワードを忘れてしまったら?
元のパスワードなんか教えなくたっていい。
再発行すればいいのだ(そして再設定してもらう)
#そもそも忘れるようなパスワードを教えてもらってもまた忘れるかもね

とにかく「A→B」の矢印は「A←B」である必要はない。

ってことで、「→」しか方向がない強力な暗号化機構を用意して
・パスワードは「B」のみを管理して「A」は入力した時だけ使って破棄する
・パスワードの照合(一致)は「→」を使って変換した「B」(?)が
  管理(保持)している「B」と一致するかで判定するようにする
っていうルールにすればよい。

これだと例え「B」が流出しても「→」を使って変換した結果を照合するので
「B→Z」とかになって「B」だけでは役立たずになる。
「?→B」となる「?」がわからなければ意味がない。
そしてそれは「←」がないので事実上無理。
これで、管理者は結構楽になる。

さて「→」にあたる機構、どんなのがあるのか?
ハッシュってのがあって、「md5」とかいろいろ種類がある。
こいつの特徴は「B」が固定した幅の値に収まる。
つまりどんなAであっても、Bは「00~99」になるみたいなもんだ(1でも1000でも)。
ってことは、重複もありうる。
そう、「A」でも「C」でも「→B」となる場合がありうるのだ。
でもこの確率はとっても低いらしい。
(Bの幅が十分に広くて、Aも使えない文字とかもあって入力が限られるから)
そしてなによりも「AorC→B」ってことは、「←」が難しいことが一目瞭然。
(な気がする)
分類:設計
JavaScript/disabledの錯覚
2012年01月11日
「disabled="disabled"」みたいな属性を付加することにより
その項目を入力不可とするとともに、POSTパラメータとして送信しなくできる。
(っていうか送信できないのが結構厄介だったりするけど)

でも、こいつは消滅したわけじゃない。
document.getElementById()とかでもしっかり扱ってくれる。
特にjQueryのeach()とかでもね。

チェックを外した瞬間に動的にdisabledにして、submitにチェックって時に
チェック対象外かなって錯覚するパターンだ。
分類:JavaScript、jQuery
設計/数値っぽいけど文字列の場合のソート
2012年01月10日
「2」と「10」の場合、数値としてソート(昇順で)すると「2→10」の順になるが、
文字列としてソートすると「10→2」の順になる。
文字列だと先頭の一文字目で「1」と「2」を比較して「1」が先に来るからだ。
「い」と「ああ」をソートすると「ああ→い」の順になるのと同じだ。

特に「文字列+数値=文字列」の場合に顕著になる。
「番号2」「番号10」とかの場合。(「番号10」が先になってしまう)

回避方法とは?

ま、ゼロパディングでしょうなぁ。
「番号02」「番号10」にすりゃ問題なし。

「02」ってのが嫌なら「番号②」「番号⑩」って方法もある
でも「⑳」までしかないけどね。(それに特殊文字はちょっと)

ま、後は、表示用項目とソート用項目とを分けて
ソート用項目は「番号02」、表示用項目は「番号2」とか二重管理してしまうのも手だ。
どうせだったら、ソート用項目を順番の連番にしてしまうってものもあり。
これをIDと言ったり言わなかったり。

ゼロパディングたって何桁パディングすりゃいいんだかってのも結構重要。
さっきの例だと「100」を超えて3桁に突入したら破綻する。
まるで二千年問題だね。
でも大抵は、数値項目でもあらかじめ桁数を決めたりするものなので、
そんなに悩まなかったりするかも。
分類:設計
WindowsVista/コマンドプロンプト
2012年01月08日
コマンドプロンプト(DOSコマンド)に、ファイルやらフォルダやらを
ドラッグ&ドロップすると、たちどころにそいつのパスとかを表示してくれる機能って
WindowsVistaで廃止されたんだね。

セキュリティ強化の為だって。

気づかなかった。
自然とパスをコピペする癖がついてしまっていた。
分類:小ネタ、Windows
Smarty/先頭一文字だけ出力
2012年01月07日
テーブルの列幅が限られていて、先頭一文字だけ出力して
全文はカーソルをそこにあわせることにより、コメント的に表示させる…
なんてテクニックをSmartyで簡単にやる方法。
┌──────────────────────────────────────┐
│<td title="{$xxxx|escape}">{$xxxx|truncate:1:'':true|escape}</td>           │
└──────────────────────────────────────┘
分類:Smarty
前へ 1 … 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 … 156 次へ