|

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

(solved) Javascriptのエラー: Node cannot be inserted at the specified point in the hierarchy / NS_ERROR_DOM_HIERARCHY_REQUEST_ERR

環境

Firefox 3.5.6

状況と原因

appendChild の実行時に
Exception... "Node cannot be inserted at the specified point in the hierarchy" code: "3" nsresult: "0x80530003 (NS_ERROR_DOM_HIERARCHY_REQUEST_ERR)" (略)
といったエラーメッセージが出る。

次のコードで再現する。

foo = document.createElement("p");
bar = document.createElement("p");

// エラーは出ない。
try{
  foo.appendChild( bar );
}catch(e){
  console.log([ 1, e ]);
}

// 循環的な親子関係。エラーが出る。
try{
  bar.appendChild( foo );
}catch(e){
  console.log([ 2, e ]);
}

// 自身へ子として自身を追加。エラーが出る。
try{
  foo.appendChild( foo );
}catch(e){
  console.log([ 3, e ]);
}

このように要素間で階層構造に矛盾が生じる時に出るエラーらしい。 上記以外にもNGなパターンがあるかも。

スポンサーサイト

Google Wave コンプリートガイドが CC BY-SA で公開されている

The Complete Guide to Google Wave is BY-SA
Google Wave コンプリートガイドが CC BY-SA で公開されている

Cameron Parkins, 2009-12-14

Gina Trapani and Adam Pash are editors at Lifehacker, but over the last couple of months they've been penning (wiki-ying?) a guide to Google Wave. Their hard work has paid off as a preview edition of The Complete Guide to Google Wave is now available for purchase as a DRM-free PDF. The first edition of the book will be debuting in January as both a PDF and a softcover print book with new editions to follow throughout 2010.

Gina Trapani と Adam Pash は Lifehacker の編集者だが、 ここ数か月間は Google Wave のガイドブックを執筆していた(wikiっていた?)。 かれらのハードワークは The Complete Guide to Google Wave のプレビュー版として結実し、DRMフリーな PDF として購入可能になっている。 この本の初版は 1月に PDFと印刷された書籍の両方で登場し、 その後 2010年を通じて新しい版が続く。

What's particularly salient to those in the CC-community is that Trapani and Pash have authored and collaborated on the book using MediaWiki and are releasing its content under our Attribution-ShareAlike license. This means the book is not only compatible with Wikipedia (allowing it to be imported to and exported from the encyclopedia), but also free to share, sell, and reproduce online – a decision that is already bearing fruit in the form of a full Japanese translation.

CCコミュニティにおいて特に重要なのは、 Trapani と Pash が MediaWiki を使って執筆・協働したことと、 表示-継承 ライセンスで公開していることだ。 つまり、この本は Wikipadia と互換性がある (Wikipedia との間で import、exportが可能)だけでなく、 オンラインで自由に共有、販売、再生産することができる。 この決定は、 完全な日本語訳 という形ですでに成果を出している。

You can learn more about the project at their website, where the guide will continue to be freely available.

彼らのウェブサイト で詳細を知ることができ、 このガイドは引き続き自由に利用できる。

Creative Commons License
This work by Cameron Parkins (original English text) and sonota (Japanese translation) is licensed under a Creative Commons Attribution 2.1 JP License.
Based on a work at creativecommons.org.

ブログに関するメモ(仮)

整理されていない適当なメモ。予定地的エントリ。 気が向いたら追記・修正などする予定。

基本的には技術的な題材を扱った記事向けだが、 それ以外のジャンルの記事でも適用できるものもあると思われる。

必ずしも「全員がこうすべき」という内容ではなく、 あくまで「自分はこういう方針で動いている」+αといった感じ。 金科玉条にして絶対遂行すべしというものでもなく、 実際には自分も割と適当に臨機応変にやっていたりする。

自分なんかよりよっぽど素晴らしい記事を書いている人がタイトルだけで大損している みたいなケースを見るとものすごくもったいないと思うので、 そういうのが減らせれば……と(そうすると自分も助かる)。


2つの戦略:
・新着を意識 … フィードなどから来る人
・検索結果を意識 … 検索サイトから来る人
この記事で対象にするのは後者。

成果/コスト比。

検索指向のメリット: 1回/1日 閲覧される記事を 1000個書けば、 単純に計算して毎日 1000アクセス/日になる。 新着指向の場合、更新を止めたらそこで客足が途絶える。
堅実さ。
SEO指南などでよく目にする「ブログは特定のトピックに絞りましょう」みたいな 制約を気にせずいろんな記事を書ける(かも)。

記事の有効期限。 内容的にはすぐには古くならなくても、文体などが古くなることへの対策。

マスを相手にしない。 マスはマスコミに任せる。

テーマ選定

自分で調べ物をしていて次のような場合に記事にする:

  • ウェブ上に情報が存在しない
  • 情報は存在しているが、散在している、英語記事である
  • 情報は存在しているが、検索キーワードとの関係でなかなか見つからない。 タイトル(目立つ部分)にキーワードが入ってないので目視ではスルーしてしまう。

など。 当たり前の話なので改めて書くのも何だが、 自分で書いた記事に適切なタイトルを付けて公開すると検索結果の 1ページ目に出ることも多い。

検索結果ドリブン。

タイトル

自分が検索して何かを調べる場合、大抵はタイトルしか見ていない。 そこで見つからなかったら脇に添えられた補助テキストに目を通す、と言ってもいいくらい。 → タイトル大事。 せっかく記事を書いてもタイトルのせいでスルーされるのは非常にもったいない。 本当にもったいない。

「そうは言っても奇をてらったタイトル付けないと読んでもらえないんだよ ウワアアアン!! ヽ(`Д´)ノ」 というのも分かるが、 ひねったタイトルを付けなければ見てもらえない時点で すでにレッドオーシャンに足を突っ込んでおり、 テーマ選定の段階ですでにまずいのではないか。
→ マスを相手にしない
本当に「これまでとは違う何か」を書いているのなら、 その「違う何か」が分かるタイトルにしておけば、 そのテーマ・トピックを追いかけている人だったらタイトルを見ただけでピンとくるのでは。

自分が検索したときのキーワードをメモっておく、リストアップしておく、覚えておく。 → 後で記事のタイトルを決めるときに利用する、思い出す。

検索してくる人の行動を想像しながらタイトルを決める。 SEO(検索エンジン向けの最適化)(だけ)ではなく、検索結果を見る人間向けに(も)最適化する。 上位に表示されていても関係なさそうに見えたらクリックしない。

アクセス解析で検索語を見て後でより良いタイトルに変更するのもありでは。

多少長いタイトルでも構わないと思うが、検索エンジン等がタイトルを全部表示してくれない問題。

問題(不具合やバグ、設定ミスなど)を解決し、解決法を書いた記事なら、 タイトルにそれと分かる記述を入れる。 このブログでは頭に「(solved)」と入れている。 英語なのは英語圏の検索者も想定しているためと、 このくらいならエンジニアっぽい人なら通じるだろうと踏んでいるため。 少なくとも「解決法・解決例がある」ことだけは伝わるはず。
日本人以外も日本語の文章は読めなくてもコード片やキーワード、 設定ファイルのパス等は拾えるはず。 自分が外国語で書かれた記事を読むときにどう思うかを想像する。

記事を紹介してくれる人への配慮

Aさんの書いた記事を読んで、Bさんが自分のブログで紹介したいとする。 タイトルがきちんと内容の要約になっていない場合、 Bさんが気を利かせて「タイトルには書いてないけどこの記事は~という内容である」 と判断して、リンクの脇に説明のためのテキストを添える。

この場合、Aさんは Bさんに余計な手間・コストを負担させている。 Bさんにわざわざ説明させている。 最初からきちんとしたタイトルが付けられていれば、そもそも説明を添える必要がなく、 ただタイトルと URL をコピペするだけで済む。

Bさんが説明の手間を惜しんだ場合、 つまり Aさんが付けた適切な要約になっていないそのままタイトルではスルーされる確率が高まる。 スルーされやすいタイトルがそのまま伝播する。


記事が書かれた日付、公開された日付も重要なメタデータで、 大量の記事へのリンクから新しい記事を探したいからリンクを辿る前にあらかじめ知りたい、 という場合がしばしばある。 これを title要素に含めるかは難しいところ。
title要素にはそもそも「タイトル」を入れるべきだと思うので、 そこに日付という異質な情報を入れるのではなく、 日付のための専用の書式があると良い。
……ということもあり、このブログでは日付は title要素には含めていないが、 上記のように有用な情報なので、 外部サイトへのリンクには日付を入れることが多い。 統一的な書式がないので手作業で、これも余計な手間。

title要素にサイト名も入れるか。 これも日付と同様そもそも title要素に入れるべきではない情報だとは思うが、 当ブログではよりあえず慣例に従っている。

サイト/ブログのタイトルに記事の内容と無関係に見えるサイト/ブログ名を title要素に入れると、 厳密な見方をすればノイズになる(検索のノイズになるのと、場合によっては「釣り」っぽくなる)。
たとえば「Xについていろいろ書く日記」という名前のブログがあって、このブログ名が title要素に入っている場合、 「Xに関係のない記事」の title要素にも X というキーワードが入ってしまう。
そう考えると、サイト運営者の名前の入った 「誰それのブログ」「Foo's website」といったサイト/ブログ名は意外と優秀なのかもしれず、 これなら title要素に入っていても「余計な情報」にはなりにくい。

タイトルはその場で完結するのではなく、いろんなサイトをひとりで渡り歩いていく。 拡散・伝播する。

ウェブサービスなども基本的に title要素を機械的に読む。

title要素が空だったりサイト・組織名だけみたいなのは論外。

学術論文のタイトル決定のノウハウ

現役でアカデミックな場に身を置いている訳ではなく、 私が学生時代に教わった範囲での話。 分野によって作法の違いなどはあると思われるし、ひょっとしたら勝手に解釈している部分もあるかも。

徹底的に「読者の時間節約・作業効率化」を意識したスタイル。 「読者が求める内容がその論文に書かれているかどうか」が タイトルを読んだだけで分かるようになっていると理想的。 また、読者もそれを前提に読むかどうか判断する。 送り手・受け手の間でプロトコルとして成立している。

意味的に過不足がないようにする。 タイトルと内容が違っていれば読者は怒るだろうし、 それ以前に審査をパスしない。

タイトルに入りきらないキーワードは「キーワード」の欄に書いておく。 読者も当然それをチェックして、読むべきか、読まざるべきか判断する。

基本的にこの程度の事だが、要するにいかに読者への便宜を図るかということ。

このスタイルの利点は、 (1)基準が明確。 (2)先天的な才能や詩的なセンスなどがなくても、トレーニング次第でそれなりに適切なタイトルが付けられるようになること。 (3)基準が明確なので、悩まずに機械的にタイトルを決められるようになる。
(余談だが、こういうことを大学じゃなく高校あたりで教えればいいのにと思う)

これはあくまで学術論文の場合の話なので、 ブログなどの場合そこまで厳密にこれに倣わなくてもいいと思うが、 応用のメリットは大きいと思われる。

ブログ・ウェブ記事に限らない日本語の話など。

before: 「Linux で zip化された mp3アルバムを聴く」
→ 「Linuxで」が「zip化された」にかかっているか「mp3アルバムを聴く」にかかっているかが曖昧。
after: 「zip化された mp3アルバムを Linux で聴く」


書評・書籍の感想などを書いた記事なのにタイトルに「書評」などのキーワードが入っていないケース。


「Firefox で Javascript を実行する方法」 という記事を書こうとする。 その方法がたとえば○個あったとして、安直に 「Firefox で Javascript を実行する○つの方法」とするのは あまり良くないと思われる。
記事タイトルを見て「ふーん」と思ってスルーする読者を想像すると、 記事の書き手としてはそこで 「いや違うんだ、HTML中に書くのとブックマークレットと、 そこらへんまでは普通思い浮かべるだろうけど、 その他にもショートカットキーで呼び出したり マウスジェスチャで呼び出す方法も書いてるんだ 」 と思う。 そう思うのなら、それをそのまま、素直に、タイトルにも反映させればいい。
たとえば「実行」を「呼び出し」という表現に変えてみる。
たとえば「Firefox で Javascript を呼び出す○つの方法(ショートカットキーやマウスジェスチャなどで)」 などとしてみる。
「○つの方法」というのはやめて 「~呼び出す方法のまとめ」にしてみる(これは微妙かも)。

具体的に。


「定額給付金に関連した消費等に関する調査」の結果について

自分だったら、次のように日付と「内閣府が出している資料である」ということが分かるように書く(紹介する)と思う。

「定額給付金に関連した消費等に関する調査」の結果について / 2010-01-15 内閣府


「foo を使ってみた」というタイトル → foo を知らない人はスルーする
なので、foo のことを知らない人には読ませたくない、まではいかなくても foo を知らない人は別に読まなくてもいいかな、みたいな場合は良いかも。

「○○を△△する foo を使ってみた」というタイトル → foo について知らなくても「○○を△△する」に興味がある人は関心を持つ。
なので、foo について知らなくても「○○を△△する」に興味がある人にも 読んでもらいたい場合はこっち。

参考

その他

何か「素直な表現ができない症候群」みたいなものがあるように思う。 無意識下で「感情に訴えるような書き方をしなければならない」と刷り込まれてるような。
小学校か中学校の国語の授業で「段落の要旨を書こう」みたいなのがあったと覚えているが、 ああいうのをもっとちゃんと定着するように(国語の授業で) トレーニングしたらいいんじゃないか……と思ったりする。
そうすると、将来研究者だとかじゃなく普通の社会人になっても、 たとえばメールの件名をきちんと書けるとか、そういうところで普通に役立つスキルになるのでは。

情けは人のためならず。

(場合によっては)英語圏の閲覧者を想定して図の中の文字を英語にする。 本文が読めなくても重要なポイントが図だけで伝わるように。

画像検索経由で来る人を想定。 テキスト検索よりも画像検索の方が適切な結果が短時間で得られる場合がある。


* 読んでもらいたい
* 別に読んでもらわなくてもいい。
  (書いたのでせっかくだから公開しとく、みたいなケース)

* タイトルが良い要約になっている
* タイトルが良い要約になっていない

で 2x2 の組み合わせ

参考(外部リンク)

Emacs Lisp メモ: Enumerable的な何かのようなもの

まあなんというか練習も兼ねた書き散らかしです。ものすごく適当です。 Emacs Lisp 詳しくないのでダメコードだと思います。 気が向いたら追加・修正するかも。


(defun each (f list)
      (let ((temp list))
        (while (not (eq (car temp) nil))
          (funcall f (car temp))
          (setq temp (cdr temp)))))
;;=> dolist
;; list.each{|x| print x }
;; ↓
;; (dolist (x list)
;;   (print x))


(defun all? (f list)
  (let ((temp list)
        (flag t))
    (while (not (eq nil (car temp)))
      (if (eq nil (funcall f (car temp)))
          (setq flag nil))
      (setq temp (cdr temp)))
    flag))


;; map, collect
(mapcar
 '(lambda (x) (+ x 1))
 '(1 2))

(defun detect (f list) ; or find
  (let ((temp list)
        (result nil))
    (while (and (eq result nil)
                (> (length temp) 0))
      (if (funcall f (car temp))
          (setq result (car temp)))
      (setq temp (cdr temp)))
    result))


(defun find-all (f list) ; or select
  (let ((temp list)
        (result '()))
    (while (< 0 (length temp))
      (if (funcall f (car temp))
          (setq result (append result (list (car temp)))))
      (setq temp (cdr temp)))
    result))
;; => remove-if, remove-if-not


(defun include? (f list) ; or member?
  (let ((temp list)
        (result nil))
    (while (and (eq nil result)
                (< 0 (length temp)))
      (if (funcall f (car temp))
          (setq result t))
      (setq temp (cdr temp)))
    result))
;;=> memq(eq で比較), member(equal で比較)


;; The MIT License

;; Copyright (c) 2009 sonota (yosiot8753@gmail.com)

;; Permission is hereby granted, free of charge, to any person obtaining a copy
;; of this software and associated documentation files (the "Software"), to deal
;; in the Software without restriction, including without limitation the rights
;; to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
;; copies of the Software, and to permit persons to whom the Software is
;; furnished to do so, subject to the following conditions:

;; The above copyright notice and this permission notice shall be included in
;; all copies or substantial portions of the Software.

;; THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
;; IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
;; FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
;; AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
;; LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
;; OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
;; THE SOFTWARE.
include?, member?
→ memq(eq), memql(eql), member(equal)



** ホームに戻る

|
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。