Web 開発者の責任 (翻訳): Days on the Moon
John Resig 氏による A Web Developer's Responsibility という記事が素晴しかったので、著者の許可を得てここに日本語訳を掲載します。 Web 開発者の最大の負担は、ブラウザのバグと非互換性への対応に膨大な時間を費やすことであるといって間違いないでしょう。それゆえに、それらへの対応に不満をいうのは、Web 開発者全員の常となっていました。ブラウザのバグは迷惑でいらだたしく、仕事を大幅に難しくします。 ブラウザのバグはとてもいらだたしく、通常の開発における最大の負担です。ですから、開発対象のブラウザが、自身のバグを見つけ修正できるようにしてやるのは、すべての Web 開発者にとっての責任です。自分が見つけたバグに対して責任を持ち、「ほかの誰かがこれを見つけるだろう」とは思わないことで、ブラウザの進歩の速度は加速していくでしょう。 ブラウザを支援する解決策
Kanasan.JS JavaScript 第 5 版読書会 #6: Days on the Moon
Kanasan.JS JavaScript 第 5 版読書会 #6 に行ってきました (当日のチャットログ、参加者のブログ一覧)。今回は 14 章「ブラウザウィンドウの制御」から 16 章「CSS とダイナミック HTML」の途中まで読み進めました。 タイマーの仕様 (14.1、p. 282) setTimeout などのタイマーはブラウザが独自に実装したもので、標準化された仕様は存在しません。HTML 5 の草案には一応含まれているものの、独立した仕様に移すことが示唆されています。かといって、その場合の受け皿となるであろう W3C WebApps WG にもはっきりとした動きは見られず (Apple の人から高精度タイマーの提案が出ていましたが)、タイマーの標準化がどうなるのかよくわかりません。 Navigator オブジェクト (14.3.3, p. 289) Navigator オブ
Kanasan.JS JavaScript 第 5 版読書会 #5: Days on the Moon
Kanasan.JS JavaScript 第 5 版読書会 #5 に行ってきました (当日のチャットログ、参加者のブログ記事一覧)。今回からはいよいよ第 2 部、クライアントサイドスクリプトということで、13 章全体を読みました。 控えめな JavaScript JavaScript をどのように使うかの指針として、「控えめな JavaScript (unobtrusive JavaScript)」(WaSP DOM Scripting Task Force の声明文) というキーワードが挙げられています。 HTML マークアップと JavaScript コードを分離する。 正常に機能を停止する。ブラウザがある機能を持たない、もしくは JavaScript 自体が動作しない場合であっても、コンテンツが利用可能であるようにする。 アクセシビリティを低下させるのではなく、向上させる。 これは
Shibuya.js in Kyoto 発表資料「取説 正規表現」: Days on the Moon
オープンソースカンファレンス 2008 Kansai 内のセッション、Shibuya.js in Kyoto に発表者として参加させていただいたので、資料を公開します。 取説 正規表現 内容は JavaScript での正規表現の基本的な扱い方です。正規表現パターンの解説はよく見かけるのですが、それを実際にどう使うかという情報が不足していると感じたので、一部だけですが取り上げてみました。こちらの練習不足でぎこちないプレゼントなってしまい申し訳なかったです。 補足ですが、if ((match = re.exec(str)))、while ((match = re.exec(str))) のように条件式を丸括弧でくくっているのは、それが代入式であることを強調するためです。SpiderMonkey では if (match = re.exec(str)) などと書くと、「等値比較 (==) を代
Kanasan.JS JavaScript 第 5 版読書会 #4: Days on the Moon
Kanasan.JS の JavaScript 第 5 版 (サイ本) 読書会 #4 に行ってきました (参加者のブログ記事一覧、当日のチャットログ)。 会場、設営 開始 15 分ほど前に会場に着いたのですが人気なし。特に名前のない貸し会議室とのことで、本当にここであってるのか Twitter で他者の動向を探ろうとするも、運悪く Twitter がダウン中。携帯から必死に地図を探していたところにほかの人が到着して一安心となりました。 開始時点で Windows マシン使用者が私を含めて 2 人という脅威のMac率でした。無線 LAN の共有も Mac 機を主体に行われ、そのせいか Windows 機では無線 LAN が利用できず。私は結局 Kanasan さんの EMOBILE 端末を借りてネットに接続しました。 クラス JavaScript にクラスベースオブジェクト指向言語でいうとこ
本気でやるなら黙読は避けて朗読すべき: Days on the Moon
「読書百遍義自ら見る」という言葉があります。難解な書物であっても 100 回も読めば自然と意味がわかるようになるという、熟読の大切さを説いた句です。しかし、これは本当のことなのでしょうか? 2000 年もたてば社会も常識もまったく変わってきます。昔の人の言ったことが今も正しいとは限りません。 疑問があれば解明したくなるのが人の性というもの。実際に「読書百遍義自ら見る」は正しいか、確かめて紀要にまとめてくださった方がいます。それによると、女子大生にデカルトの「方法序説」を 30 回読んでもらったところ、ほとんどが内容を理解するにいたったとのこと。この言葉の正しさが見事に証明されたのです。 ただし、一点注意することがあり、それは黙読ではなく朗読するということ。人間は活字を使いだしたのはたかだかこの5千年程度のことであるが、音声を使った情報のやりとりは動物の時代から行ってきたことであるという由緒
Kanasan.JS JavaScript 第 5 版読書会 #3: Days on the Moon
Kanasan.JS の JavaScript 第 5 版読書会 #3 (当日のチャットログ、参加者のブログ記事一覧) に行ってきました。同じ会場で先立って vim 勉強会があったのですが、私は先日 Meadow に乗り換えたばかりなのでそちらのほうはパスしました。 配列のプロパティ JavaScript ではすべてのプロパティ名が文字列として扱われます。配列 a に対して a[-1.23] = true としても、a["-1.23"] = true と同じに扱われ、"-1.23" という名前のプロパティができるだけでエラーにはなりません。ただし、配列に関しては非負整数とみなされる名前のプロパティが特別扱い (length プロパティにも影響を及ぼしうる) されます。 Array#join と Array#toString 配列に対して、join メソッドを引数なしで呼び出すのと toSt
Kanasan.JS CodeReading #3: Days on the Moon
Kanasan.JS の Prototype.js CodeReading #3 (参加者のブログ記事一覧) に行ってきた。今回は告知が開催間際だったせいか人数はやや少なめだったけど、内容的にはこれまでと変わらぬ濃さ。範囲としては Prototype.js 1.6.0.2 の 1352 行目から 1650 行目付近まで。 コードリーディング 無線ネットワークが提供されているはずが私のマシンでは利用できず。LAN ケーブルをお借りして有線で接続。それにしても私がこれまでに参加した Kanasan.JS でネットワーク関係の不備に陥ること 4 回中 4 回。何か呪いでもかけられているのかと疑いたくなる。 例外処理の有無 Ajax.Response#getStatusText などは try 文による例外処理を行っているのに、Ajax.Response#getResponseHeader および
Kanasan.JS #2 レポート & 資料: Days on the Moon
関西での JavaScript 勉強会、Kanasan.JS #2 に行ってきました。今回は 9 時から 21 時という長丁場で、内容は前回に引き続き Prototype.js のコードリーディング。ただし、前回はバージョン 1.5.1.1 だったのが今回からは 1.6.0 を使用ということで、コードリーディングに先駆けて 1.6.0 での変更点に関するプレゼンテーションをやらせていただきました。他の参加者の方々のレポートなどは Kanasan さんの記事経由で読めるかと思います。 フリートーク 午前中はフリートーク及びプレゼンテーションということで、自己紹介の後雑多な話題に。 リファレンス どんな参考文書を利用しているかという話題。とりあえずググって出てきたページという方が結構いるようです。私も検索エンジンを使ったりもしますが、特定のサイトだとこんな感じです。 コア言語 ECMAScri
Days on the Moon
この記事はPerl Advent Calendar 2022の21日目の分です。 Perlでは、関数内で定義した関数も外部から見えてしまいます。 use feature 'say'; sub foo { sub bar { say 'bar'; } bar(); } # foo関数の外でもbar関数を呼び出せる。 bar(); 特定のスコープでのみ参照できる関数を定義したいときは、関数定義をsubではなくmy sub（またはstate sub）から始めます。この機能はレキシカルサブルーチン（lexical subroutines）と呼ばれます。 use feature 'say'; sub foo { my sub bar { say 'bar'; } bar(); } # 未定義の関数呼び出しによる例外が発生する。 bar(); ちょっとした処理をまとめるのに便利なレキシカルサブルーチン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
