たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
ラインマーカーの実装について質問を受けて回答したのだけれども、同様の疑問を持っている人がもしかしたらいるかも知れないなあとか、最近全然技術文書を書いてないなあとか、ドキュメントを増やすのもデベロッパの務めだよなあとか、なんやかや考えて文書にまとめてみた。
で、このドキュメントを書く途中で気がついたことやなんかを盛り込んで、ラインマーカーそのものを更新したりもして。
ああ、この時間の無いときに何でこんなことを僕はやってるんだろう……DOMを触ったことがある人にとってはあまりに常識的な話で、DOMを触ったことがない人にとってはちんぷんかんぷんな話、という非常に微妙な内容のドキュメントになってしまい、こんな物が一体誰の役に立つのだろうか、と我ながら激しく疑問に思う。
まあ、あれだ……一日遅れの24歳の誕生日プレゼントだと思ってください。って、自分が人にあげるのかよ。
blosxom+Markdownに慣れてしまうと、HTMLを書くのが面倒でたまりません。
先週末、しぶやjsのテクニカルトークを見てきた。今回は一般の観客です。
いやぁ、どれもこれも興味深い話で感嘆するばかりでした。居眠りしてたのは寝不足のせいですが、それでイラレの話を聞き逃してしまったのは非常に残念でした。
話聞いてると改めて思うけれども、もうだいぶ前からJS界隈はすっかり「ライブラリを駆使して云々」な世界に切り替わっちゃってたんだなあ。僕なんかは全部自前であれこれやることに未だに引きずられてて、今ならライブラリいっこあれば誰でも簡単にできることを、自分は自分で実装してみたぜーというだけのレベルで喜んでたりする、ガキんちょなんだということが身にしみて分かる。僕はそんなレベルで満足しちゃってるけど、他の人は、そういうライブラリを使ってもっと高度なことにガンガン挑戦していて、僕はすっかり取り残されてしまった。
XULでもJSでもCSSでも何でもそう、ぼくはシーラカンスで進歩を止めてしまってる。否、シーラカンス止まりなのが僕なんだ。そこから先にはどうあがいても進めない、そこが僕のできる限界なんだ。そんな風に思った。
JavaScriptで危険な事や妙ちきりんな事をしてみたい人のための覚え書き。一般的なユーザの立場の人はあんまり見ない方がいい話。興味本位で触ると痛い目を見かねない話。
もう先週のことになってしまったけど、Shibuya.js第1回テクニカルトークに参加した。
皆さんワロける素晴らしいプレゼンばかりで、僕チン大いに焦りましたよ。受付に座りながら必死こいて少しでもウケを狙えるように内容を書き直したりとかしてた。でも基本的にセンスがないから、大いに寒い結果になってしまったように思う。うあぁぁぁそればかりが心残りだ(←それが感想なのか)。
CPANならぬJSAN、PAUSEならぬJAUSEとか、JavaScript高速化のテクニックとかの実践的な物から、DOM3 XPathのようなとんがった物まで、色々盛りだくさんの内容だったと思う。実のところJavaScript/Ajaxな話題には疎い僕には新鮮に感じる情報も多かった。ライブラリとか、prototype.jsくらいしか使ったことないし。それもまともに使いこなせてなんてないし。
これからもオモロくなってってくれたらいいなあ。
東京に来たからって「じゃん」とか使ってみたんだけどさ。別にそんなのどうでもいいんだけどさ。
引っ越しとか記事執筆とかでゴタゴタしてる間にいつのまにかShibuya.jsが明日に迫ってしまってた。どうしよう何も準備してないよ。登録時に知らん間に付けられてた「モテル!XUL」といういかがわしいタイトルを書き換える暇もなく。ていうか渋谷ってどこですか? なに御茶ノ水? じゃあ自転車で行くですよ。イベントは何時から? ほうほう18時からですか。
すごい人達ばかりで僕なんておもくそ場違いというか、じゃあどこだったら場違いじゃないんだよと言われると場違いじゃないところなんてどこにもなくて、強いて言うなら観客席にいるのが本来の僕の在り方だと思うのですが、ともかく行ってくるのですよ。
/latest 以外のディレクトリに置いているページで使っているコンテンツリスト生成用JavaScriptがprototype.jsのObject汚染におもくそひっかかっててメニューぶっ壊れ状態になってたことに今頃気付いた。連想配列とfor-inループの組み合わせで大量死発生。ということでリンク先で提案されている以下のコードを組み込んで対処した。
Object.prototype.forEach = function(func){ for(var key in this){ if(!(key in this.constructor.prototype)){ func(this[key],key,this) }else if(this[key] != this.constructor.prototype[key]){ func(this[key],key,this) } } }; obj.forEach(function(value,key,self){ alert([value,key]); });
ンモー
全ページでprototype.jsを読み込むようにしてみた。とりあえず使える環境にしとかないと遊ぶのも勉強するのもなんもできんからね。
ナローバンドな人はごめんなさいってことで。
prototype.js 1.4.0を使っていることを前提として。
ラジオボタンというのは、こういう奴のことだ。
チェックボックス風のものがいくつか並んでて、一つだけを選べるというもの。ここで1~3のどの項目がチェックされているのかをJavaScriptで知るためには、通常、以下のようにする必要がある。
var nodes = Form.getInputs($('form'), 'radio', 'dummy');
var selectedItem = $A(nodes).find(function(aNode) { return aNode.checked; });
alert(selectedItem.value);
ところでXULでは、同様のものを以下のように書くことができる。
<radiogroup id="dummy">
<radio value="1" label="項目1" />
<radio value="2" label="項目2" />
<radio value="3" label="項目3" />
</radiogroup>
そして、XULではradiogroup要素のノードから直接「選択された項目の値」を取得することができる。
alert($('dummy').value);
XUL生活(?)が長かった僕は、これにすっかり染まってしまって、prototype.jsにラジオボタン用の機能がないことを知って非常にガッカリしたと同時に、どうやってラジオボタンの選択された値を一発で取得すればよいのか分からず大いに困惑した(「Enumerableクラスのfindメソッドまたはdetectメソッドを使う」という前述の方法などで、やろうと思えばできるということには後から気がついたけど、慌てていた僕はそこまで思い至らなかった)。
そういうわけでごろうさんに泣きついてみたところ、以下のような方法を教えてもらえた。
alert(Form.serialize($(form)).toQueryParams()['dummy']);
フォーム全体の値を一旦クエリの形式に変換して、その上でラジオボタンの部分の値を得るという方法だ。なるほど、こんな方法もあるのか……ということでさっそくこれを使わせてもらうことにした。
でも、この方法はちょっと遠回りなのが残念といえば残念。実行時間も少々余計にかかりそうな気がする。ラジオボタンは排他的選択なんだから、XULの場合のような一発で値を得る方法がprototype.jsにもあっても良さそうなものだと思うんだけどなあ。トホホホホ。
まじめな報告?はよそで書いたので、こっちではふざけた話ばかり書いてみますよ。
2進数では、ビット列をずらすだけで簡単に2n倍または1/(2n)倍(できる。
10進数 | 2進数(ビット列) |
---|---|
1 | 0000001 |
2 | 0000010 |
4 | 0000100 |
8 | 0001000 |
16 | 0010000 |
32 | 0100000 |
64 | 1000000 |
2進数というのは0と1というビットの並び(ビット列)でできている。数値を2倍するというのは、このビット列を1つ左にずらすことに等しく、1/2倍する(2で割る)というのは、1つ右にずらすことに等しい。
4倍するというのは、2×2倍すること=2回2倍するということ。つまり、数値を4倍するというのは、このビット列を左に2つずらすということだ。
8倍するというのは、2×2×2倍すること=3回2倍するということ。つまり、数値を8倍するというのは、このビット列を左に3つずらすということだ。
2進数が基本になっているコンピュータでは、2の倍数をかける(2の倍数で割る)計算はこのようにすれば、何の面倒もなく物凄く高速に結果を得ることができるわけである。ゲームプログラミングのようなとにかく高速なレスポンスが要求される分野では、こういうテクニックが多用されるのだそうだ。