| 次のページ >>

スポンサーサイト

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

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

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

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

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

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


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 の組み合わせ

参考(外部リンク)

スポンサーサイト

雑記: 2008-10

雑記


JScript 覚書2つ

2008-10-10

var ForReading = 1;

function readFile( path ){
  var fso, fin; 
  fso = new ActiveXObject( "Scripting.FileSystemObject" ); 
  fin = fso.OpenTextFile( path, ForReading ); 
  var content = fin.ReadAll();
  fin.Close(); 
  return content;
}

WScript.Echo( readFile( 'foo.txt' ) );

読み込み対象である foo.txt の中身が空の場合、次のメッセージが出る。

Microsoft JScript 実行時エラー: ファイルの最後を超えた入力を行おうとしました。

ちなみに、ファイルが存在しない場合は 「ファイルが見つかりません。」という異なるメッセージが出る。


var ForReading = 1;
var hideWindow = 0    //ウィンドウを非表示
var shell = new ActiveXObject( "WScript.Shell" );

function readFile( path ){
  var fso, fin; 
  fso = new ActiveXObject( "Scripting.FileSystemObject" ); 
  fin = fso.OpenTextFile( path, ForReading ); 
  var content = fin.ReadAll();
  fin.Close(); 
  return content;
}

shell.Run( "cmd /c echo " + new Date() + " > foo.txt", hideWindow );

WScript.Echo( readFile( 'foo.txt' ) );
// → shell.Runで上書きされる前の foo.txt の内容が表示される

foo.txt への書き込みが完了してから次の処理を実行させたい場合、 Run() の第3引数を true にする。


2008-10-04

Ubuntu Studio でフォルダ共有

普通の Ubuntuではメニューに「フォルダの共有」があるが、Ubuntu Studioにはない。

Synaptic で検索すると、「nautilus-share」というそれらしいパッケージが見つかり、 インストール済み。

当てずっぽうでコマンドを探してみたところ、 sudo shares-admin で「フォルダの共有」設定ツールが起動した。

あとはたぶん普通のUbuntuでの設定と同じ。

[2008-10-10] 素のUbuntuでも 8.04 で無くなっていたようです → ubuntu 8.04 "フォルダの共有" - Google 検索

[雑記] 2008-05


2008-05-21

ガチガチの利権団体と、アナーキーなワレザーが対立している、というような理解は間違いではないが、それらの中間にはいろいろな考えの人がいる。当たり前のことだが、ネットをやる人の誰もが「法律など無視してオーケー」と単純に思ってるわけではないし、著作権者の側も一般には「取締りを厳格にすることだけが正解」と思ってるわけではない。「今のしくみには問題がある」と言ったからといって「法律などすべて無視していい」と思っているわけではないし、「決まりは守るべきだ」と言ったからといって「今のしくみですべてが良い」と思っているわけではない。

同人などの二次創作エトセトラにしても、全員が全員「ディズニー以外の版権モノはオーケー」みたいに思っているわけではなく、中にはいろいろなジレンマを感じている小心者も少なくないと思う。


2008-05-14

「火の使用は悪魔のわざだから、やめなさい」と宣伝する人がたくさん出るのは、それだけそれが大きなポテンシャルのある技術であることを示しているだけで、重要な技術であればあるほど、それについてさまざまな意見が出るのは当然だから、それはそれで良い。

ただ、その過程で、法律なんてあてにならない、守っても守らなくても、どうせでたらめだ、という風潮が広まってしまうとしたら、とても残念だ。残念だし、法律やら裁判やら何だか火の使用は悪いとか言ってるけど、どうせでたらめだし、あてにならないし、しらねーよ。いいじゃん、あったかいし。まる。で終わってしまう。でたらめなやめさせ方でやめさせようとしても、逆効果ということだ。

本当にそれをやめさせたほうが全体にとってメリットがある事案なら、必ず納得のいくやめさせ方というものがあるはずだ。納得のいくやめさせ方ができないのだとしたら、結局、それをやめたほうがいいという合理的な根拠は何もない、ということを、間接証明していることになってしまう。


2008-05-06

RAA - rmp3
Ruby で書かれた CUI な mpg123フロントエンド。 curses を利用。



Ubuntu で Ruby/GTK+ なオーディオプレーヤー demae を使ってみる。

tarball 取ってきて展開して ./demae で実行。

$ ./demae
Exception `LoadError' at ./demae:62 - no such file to load -- gtk_treemodel_xtra.so
demae: Error occured in loading "gtk_treemodel_xtra.so".
       Have you installed it properly?

$ grep -r gtk_treemodel .
./demae:    require 'gtk_treemodel_xtra.so'
./demae:demae: Error occured in loading "gtk_treemodel_xtra.so".
./ext/Makefile:# Makefile for gtk_treemodel_xtra.so
./ext/Makefile:all: gtk_treemodel_xtra.so
./ext/Makefile:gtk_treemodel_xtra.so: gtk_treemodel_xtra.c
./ext/Makefile: $(MAKE) -C $(RUBY_GNOME2_DIR)/gtk/src gtk_treemodel_xtra.o
./ext/Makefile: $(LD) -shared -o $@ $(RUBY_GNOME2_DIR)/gtk/src/gtk_treemodel_xtra.o
./ext/gtk_treemodel_xtra.c:void Init_gtk_treemodel_xtra(void)
./ext/README:  Finally, install "etc/gtk_treemodel_xtra.so" into a directory where Ruby
バイナリー・ファイル./ext/i686-linux/gtk_treemodel_xtra.soは一致しました
require 'gtk_treemodel_xtra.so'
↓とりあえずの処置として demae の該当箇所を直接修正
require '/home/user/demae-0.7.2-r1/ext/i686-linux/gtk_treemodel_xtra.so'

ぐぐっても出てこないので危うく作者さんに問い合わせるとこでした(^^

これで起動しました。 後は synaptic で sox、mpg123 などをインストールすると各種オーディオファイルが 再生できます。Ogg Vorbis 用には vorbis-tools です。

追記20090221:
    homedir = File.dirname(File.expand_path(__FILE__))
    $LOAD_PATH << File.join(homedir, "ext/i686-linux")
    require 'gtk_treemodel_xtra.so'

[雑記] 2008-03

雑記


2008-03-25


カリ城が好きな人は観ましょう。あとドパルデューのシラノの口上・啖呵が好きな人も観ましょう (声を当てているのはドパルデューではなくてジョルジュ・ジュイエーという人だそうですが)。

2008-03-23

OpenOffice.org Basic で単純な文字の置換。
Sub simpleReplace( str as String, pre as String, post as String )
  dim position as Integer

  Do
	position = InStr( str, pre )
	If 0 = position then
	  	Exit Do
	Else
		Mid( str, position, 1, post )
	End If
  Loop
End Sub

ぉ。ニコニコに上げてる人がいた。

はてなブックマーク - Virt - FX EP‐ニコニコ動画(SP1)

はてなブックマーク - Virt - fx 2.0‐ニコニコ動画(SP1)



** ホームに戻る

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