2010年08月03日

著作権の自動発生と、著作権登録制度

2010年現在、日本では(そして他の多くの国でも)著作権は著作と同時に「自然発生する」と考えられている。
一方で、「ちゃんとした」著作権の登録制度も存在している。ついでに言えば、ちゃんとしていない著作権の登録も、一部の団体で勝手に行われている。

では、自然発生するという著作権に、登録制度が存在するのはなぜだろうか?
それは、著作権が「譲渡可能」なものであることを最大の理由としている。
しばらく前、「著作権の保護期間延長」が問題になったことがある。これを書いている時点では、ひとまず、延長しないという方向にはなったが、このときに、「著作者と著作権者は異なるということを意識して議論しなければならない」という話を聞いたことがある。

実際、「お金になる」ような著作権は、多くは、何とか事務所に譲渡されており、著作者といえども自由に複製できない(著作権者ではないから)という状況だったりする。
この場合、「誰が著作権者か」を明示するために、(ちゃんとした)著作権の登録制度は有用なのである。

さて、問題になるのは、一部民間で行われている、「ちゃんとしていない」著作権登録である。
セールスポイントは、「著作権登録であなたのアイディアを保護しましょう」ということらしいけれど、どうやら、自分が書いた図面やら(アイディアの)説明文やらを、「登録」して、「保護しよう」ということらしい。
しかしながら、著作権ではアイディアは保護されない。確かに、その図面や説明文と「全く同じもの」を作れば、著作権の侵害になる場合もある。けれど、アイディアを表現するのに、全く同じ文面は不要であろう。

これだけの話であれば、単に、「役に立たない」というレベルで終わるのだが、著作権として考えれば、もうひとつ別の問題がある。
要するに著作権の侵害とは、「勝手に複製を作ってはいけない」ということである。
だから、オリジナルの存在を知らずにたまたま同じものを(または類似のものを)作ってしまった……という場合、著作権の侵害とはならないのである。

これは、「依拠性」という概念であり、ちょっと探すと、「ワン・レイニー・ナイト・イン・トーキョー 事件(昭和53年9月7日・最高裁)」が判例として出てきたりする。
だから、アイディアを保護するために、著作権の登録をしてみたところで、もしも、その図面なり説明文なりを、公開せずに後生大事にしまっておけば、たとえ類似のアイディアが出現しても、「そんなもの(=オリジナル)は、見る機会などなかった。それにアクセスすることなどできなかった」と言われてしまえば、少なくとも、著作権の侵害はいえなくなってしまう。

たとえ、著作権登録を行ったとして、「盗まれないように誰にも見せずにしまっておく」という運用を勧めていたとしたら、それは、著作権侵害という主張を不可能にしてしまうという、ことでもあるのだ。
つまり、著作権の侵害(=無断複製)を主張するためには、逆説的ではあるが、「誰もが見ようと思えば見られる」という状況に置くということが必要なのである。

著作権の場合、たとえ、同じものができたとしても、「知らなかった(それを見る手段がなかった)」と証明できれば、著作権の侵害には当たらない。
一方で、特許の場合、特許は必ず公開されるので、「知らなかった」が通用しない世界ではある。
posted by 麻野なぎ at 12:28| Comment(0) | TrackBack(0) | 著作権の周辺

2010年08月02日

Turbo C++ (というか、BCB というか、C++ Builder)で、DLL の「共有セグメント」を使う安直な方法

【結論】

・共有セグメントに置きたい変数は、グローバルレベルで、「初期化せずに」宣言
・以下の記述のみの .def ファイルを、プロジェクトに追加する。

----------------- from here ------------
SECTIONS
_BSS READ WRITE SHARED
----------------- to here ------------

さて、先日、突然一日のキーストローク数をカウントしてみたくなりました。
公開するわけでも、販売するわけでもない、そういう目的なので、まあ、なんとか動かせばいいか……というレベルでいろいろ情報を探すと、

・システムフックというのを使えばいいらしい。
・システムフックは、dll として作成する必要があるらしい。
・この場合、dll は、各スレッドごとに作成されるので、グローバル変数(たとえば、キーストロークの総数)は、共有セグメントに持たなければならい。

ということ。
そして、共有セグメントを使う方法としては、

#pragma data_seg("セグメント名")
ここで、変数を宣言+初期化
#pragma data_seg()

としたあと、.def ファイルで、このセグメントを共有指定すればOKという情報が。

以上の情報を頼りに、dll を作り始めましたが、#pragma data_seg が変?
あ、これ、Visual C++ の独自拡張なのですね。BCB ではそのままでは使えません。

ではどうすればいいのか?
「メモリマップトファイルを使用してください」
あ、確かに、とっても正しい回答であります。

といいつつも、さらに、メモリマップトファイルまで理解するのはちょっとおっくう。
そこで、「何が本質的なのか?」と自問。

別に、変数に「任意のセグメント名をつける」ことが必要なのではなく、「その変数が存在するセグメントを、共有セグメントとして定義する」ことが必要なのです。

そう、「その変数が存在するセグメント」さえわかれば、(さらに、副作用さえなければ)、そのセグメント名を共有セグメントとして指定すれば良いわけです。

そこで、とりあえず作成したキーフックするソースをアセンブルしてみると、問題の変数は、BSS というセグメントに存在している。あとは、BSS というセグメントを共有セグメントにすればいいわけで……
※冒頭で、「初期化せずに」と書いたのは、たまたまこの条件の変数が BSS に存在していたというだけです。

keyHookdef.def というファイルを作って、その中に、上記の
SECTIONS
_BSS READ WRITE SHARED
を書き込み。

これをプロジェクトに追加すると、どうやら、所定の動作をしてくれたようです。
めでたしめでたし。

ちなみに、ソース全体は以下のようになります。

---------------- keyHookUnit1.cpp ------------------------
#include
#include
#include
#pragma hdrstop

// この下にある、グローバル変数が、BSS に存在するようです。
HINSTANCE hInst;
HHOOK hHook;
int pressCount;

static void save()
{
std::ofstream otf("c:\\user\\keyCount_LL.txt");
otf << pressCount;
otf.close();
}

static void load()
{
std::ifstream inf("c:\\user\\keyCount_LL.txt");

if (inf)
{
inf >> pressCount;
inf.close();
}
else
pressCount = 0;
}

LRESULT CALLBACK HookProc(int nCode, WPARAM wp, LPARAM lp)
{
if ((nCode == HC_ACTION) && (wp == WM_KEYDOWN)) // キー押下時
{
pressCount++;
if ((pressCount % 1000) == 0) save();
}
return CallNextHookEx(hHook, nCode, wp, lp);
}

extern "C" __declspec(dllexport) void HookStart()
{
load();
hHook = SetWindowsHookEx(WH_KEYBOARD_LL, (HOOKPROC)HookProc, hInst, 0);
}

extern "C" __declspec(dllexport) void HookEnd()
{
UnhookWindowsHookEx(hHook);
save();
}

extern "C" __declspec(dllexport) int get()
{
return pressCount;
}

extern "C" __declspec(dllexport) void clear()
{
pressCount = 0;
save();
}

#pragma argsused
int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved)
{
hInst = hinst;
return 1;
}
---------------- keyHook.h --------------------------------
#include

extern "C" __declspec(dllexport) void HookStart();
extern "C" __declspec(dllexport) void HookEnd();
extern "C" __declspec(dllexport) int get();
extern "C" __declspec(dllexport) void clear();

---------------- keyHookDef.def ---------------------------
SECTIONS
_BSS READ WRITE SHARED
---------------- to here ----------------------------------
posted by 麻野なぎ at 12:28| Comment(1) | TrackBack(0) | Twitter と Bot の周辺

2010年07月27日

節気さんBotと、「中秋の名月」

【2010年8月29日に追記】

実は、「月の名前」の切り替え時刻を考え直しました。
詳細は、「月の異名」再び( http://asano-nagi.sblo.jp/article/38733291.html )への追記としましたが、これにより、中秋の名月の切り替えも、普通の感覚にかなり近づいたと思います。

実際には、


始まり:2010年9月22日 5:22 (高知の明六ツ)
終わり:2010年9月23日 6:00 (月齢君の定時ツイート)

と言うことになります。

--------------------- 追記、ここまで。


今年も、秋になると、「中秋の名月」がやってきます。
節気さんシリーズBotでも、中秋の名月に反応します。(世界の……、は除く)
ただ、当日になると、「節気さんシリーズ、違うんじゃないか」と思われそうなので、早めにちょっとした解説です。

内容は、「月の異名(というか、月の呼び名)」さらに……。( http://asano-nagi.sblo.jp/article/38759410.html ) で書いたものではあるのですが。
さて、節気さんシリーズでは、月の名前は「(旧暦)何日の月はどういう名前」という立場ではなく、「(旧暦)1日から数えて、何回目の月はどういう名前」という立場をとっています。
たとえば、今年(2010年)の中秋の名月付近は、

9/21 16:21 月の出 〜 9/22 4:12 月の入り(小望月)
9/22 16:47 月の出 〜 9/23 5:08 月の入り(十五夜)
9/23 17:13 月の出 〜 9/24 6:04 月の入り(十六夜)

として、取り扱っています。(月の出・月の入時刻は東京のもの)
「何日の月が」という規定をしてしまうと、月が出ている間に(日付をまたぐので)月の名前が変わったり、未明の月(月の入り前)と夕刻の月(月の出後)のどちらの名前なのかとか、そういう問題が発生するためです。

さて、このようなわけで、月の名前が変化するタイミングは月の入りと月の出の中間としています。
ですから、節気さんシリーズが、「十五夜(特に、中秋の名月)」とつぶやくのは、

開始:小望月の月の入りと、十五夜の月の出の中間 = 9/22 10:29
終了:十五夜の月の入りと、十六夜の月の出の中間 = 9/23 11:10

となります。

一般的には、「(2010年は)9月22日が中秋の名月」と言われることになりますが、節気さんシリーズは、9/22になっても、10:30 頃までは、「小望月」と言ってますし、翌日(9/23)になっても、昼前まで、「中秋の名月」とつぶやくことになります。

それは、こういう事情によるわけです。

2010年06月11日

OAuth への道 ―― OAuth gate 作ってみました

もしかして、Basic 認証の Bot の出力をそのまま、OAuth に置き換えられるんではないか……と、
ちょっと作ってみました。

非常に限定的な用途になりますが、もしかして、どこかに需要があるかも……しれないと。

【特徴】

・Bot と 同じパソコンの中で動きます(ネットワーク経由でも動かないことはない)
・故に、外部に、パスワードなどを送信しません
・ただし、パソコンの中に、OAuth 用のシークレットコードを保存します
・Twitter のパスワードは、(OAuth gate では)保存しません。

【対象】

・Windwos で動作します。(一応、OAuth gate が Windows 上で動けば、ネットワーク上の他のパソコンでBotが動くのも可です)
・POST にしか対応していません(Twitter API では、statsues/update のみです)
・何かを投稿する毎に、Twitter に「接続」と「切断」をするタイプのBotにしか対応しません。
・それ以外の機能が使われていたりすると、良くないことが怒ると思います。
・プロクシにも対応していません。
・ひとつの Bot に対してしか(というか、一組の、OAuth キーに対してしか)対応していません。

詳しくはこちらで → http://www.axis.blue/tec/oauth_gate.html
posted by 麻野なぎ at 12:31| Comment(0) | TrackBack(0) | Twitter と Bot の周辺

2010年06月10日

OAuth への道 ―― OAuth gate というのを考えてみた。

OAuth gate の動きを少々修正しました。
いや、修正したと言っても、まだ作ってませんが。
さて……。


Basic 認証で動く Bot と同じパソコンの中で動いて、OAuth 認証にして Twitter に投げるという発想で。

もともとが安易な性格なので

・Windows で動いて
・Bot のみ対応
・そもそも、POST のみ対応
・一回ごとに(認証だけではなく)接続と、切断を行うBotのみ対応

というパターですが。
こんなのでできるのかな?
とりあえず、○つけたのは、コードを書いたつもり。



○ 1)[SYSTEM] port の値(デフォルトは 80)で、サーバーとして待機する
○ 2)クライアントからの接続要求を受け入れる
○ 3)クライアントから切断が要求されたら、接続を切断する(自動)
×   ・その際、Twitter 側に接続中であれば、その接続を切断する

○ 4)接続完了後、クライアントからのデータを受信する
○ 5)クライアントからのデータは CRLF で1行ごとに区切る
○ 6)2個の空行(CRLF のみの行)を受信したら、次の処理に移行する

○ 7)最初の空行の直前までをヘッダとする。
○ 6)最初の空行の次の行をボディとする(ボディは1行のみ)
○   ・以上の結果を、Memo_server_recv に順次書き込む

8)ヘッダの処理
○   ・POST で始まり、.json を含む行 → POST http://api.twitter.com/1/statuses/update.json HTTP/1.1 に差し替える
○   ・POST で始まり、.json を「含まない」行 → POST http://api.twitter.com/1/statuses/update.xml HTTP/1.1 に差し替える
○   ・Authorization: で始まる行
×     Basic 以降、行末までの文字列を取得する
×     文頭・文末のスペースをトリミングする
×     得られた文字列のハッシュを算出する(MD5)
×     算出されたハッシュが、[USER] ID_Pass と一致することを確認する
×    ・一致しない場合、Twitter 側への送信は行わない
×      クライアントへは、とりあえず、エラーの旨を返す。
○     OAuth ヘッダを算出し、これに差し替える
○   ・Host: で始まる行 → Host: api.twitter.com に差し替える
○ ・その他の行 → そのまま
×   ・POST で始まる行、Authorization: で始まる行のいずれかが存在しない場合、Twitter 側への送信は行わない
      クライアントへは、とりあえず、エラーの旨を返す。

○   ・以上の変換処理(そのままの行を含む)結果を、Memo_twitter_send に順次書き込む

9)ボディの処理
○   ・ボディの内容を、そのまま、Memo_twitter_send に書き込む

× 10)api.twitter.com に接続要求を行う
× 11)接続を待つ → 60秒以内に接続できないとき、Memo_twitter_recv に、「接続エラー」を書き込み、サーバーとしての接続を遮断する
× 12)api.twitter.com に対して、Memo_twitter_send の内容を順次送信する
× 13)api.twitter.com に対して、読み込みを行い、読み込み内容を、Memo_twitter_recv に順次書き込むとともに、クライアントに送信する
× 14)受信終了文字列を受信したら( とか)Twitter への接続を切断する

○ 15)クライアントからの切断要求を受けて、接続を切断する。(3)と同じ
posted by 麻野なぎ at 12:20| Comment(0) | TrackBack(0) | Twitter と Bot の周辺

2010年06月04日

「月の異名(というか、月の呼び名)」さらに……。

さて、先日月の異名(というか、月の呼び名というほうが一般的みたいですね)の算出ロジックを変更したとアップしたばかりですが、改めて、ちょっと詳しく書いてみようと思います。

まず、実例をご紹介します。
これは、2010年6月12日から、7月11日までのグラフです。
(これは、旧暦の5月いっぱいに相当します)
juneall.gif

月が出ている時間帯・旧暦の日付・そして、新しく変更した「月の呼び名」算出ロジックによる「月の呼び名」の変化状態を表しています。横軸の日付は、2日ごとにつけられており、たとえば、6/12 と書かれている線から、次の線までが、実際には6/12 になります。
画像では詳細が見られないと思いますので、詳しく見られるように、PDF にしたものをこちらにおいておきます。
tokyo_2006_06.pdf

まず、ここからわかるのは、6月12日から7月11日の間は30日あるのに、月は29回しか出ていないということです。
こんなわけで、月の呼び名は、(無理矢理全部につけたとしても)29個しかなく、30日間に割り振るのは無理だということだったのです。

さて、少しずつ見てゆきましょう。
まず、(旧暦での)月初めです。
jun01.gif
月初めは、太陽と月がほぼ同時に出入りしますので、この段階は、旧暦の日付と月の出現回数はよく揃っています。
実際、「節気さんシリーズ」でも、旧暦のついたちは、旧暦の日付にあわせています。
それでも、徐々に月の出が遅れてきているのがわかると思います。

引き続き、月の半ばです。
jun02.gif
ここで、6/29(6/28 と 6/30 の間)の線を横切っているのが、いわゆる十五夜の月です。
このように、夕暮れ近くから、夜明け近くまで、夜半をまたがって出現します。
当然、月が出ている間に、旧暦の15日から、16日に日付が変わってしまいます。
「今出ている月の名前」としては、夜半を境にして名前が変わってしまうというのは、やはりまずいかなと思うわけです。
このようなわけで、節気さんシリーズのロジックでは、一番上の線にあるように、月の出前から、月の入りの後までを、その月の名前として統一するという形になっています。
これが、出現回数を基準にした名付けです。

それでも、――十五夜が、「旧暦15日の夜の月」と言われているように――その日の夜の月の名前なのだと考えれば、まだつじつまは合います。

では、月末付近はどうでしょうか?
これが、月末付近の詳細です。
jun03.gif
ここで、7/6 の前の月の出は 7/5 の 23:31 です。そして、7/6 の後の月の出は、7/7 の 0:04 です。
つまり、カレンダー上では、7/6 には一度も月の出がなかったということになります。
ですから、7/6 は旧暦の26日であっても、「この日に出る月」の名前というのは、決められません。
また、7/7 の月の出の直前には、日付も旧暦の27日に変わってしまいますから、「その後に出る月」ともいえません。
こうして、旧暦の日付基準では、二十六夜に相当する月が決められなくなってしまうわけです。

節気さんシリーズでは、出現回数ベースで月の名前をつけているので、この、7/7 の未明に出ている月が、二十六夜の月になります。

種々述べてみましたが……やっぱり、図があるとわかりやすいですね。

2010年06月03日

「月の異名」再び

【2010年8月29日 追記】

この記事で書いている、「月の名前」の付け方(というか、名前を変えるタイミング)を変更しました。

もともと、月の名前というのは、現に空にあって見えている月に対するものかと思うわけで、月が沈んでいるときの名前というのはないような気もします。
が、節気さんシリーズで、一日中ツイートしている関係もあって、まあ、そうもいっていられない。

そこで、当初は、「月の入りの時刻と、次の月の出の時刻の真ん中で月の名前を変える」という方針にしました(この記事の後半にはそのままの形で残っていますが)

ただ、これだと、普通に「今日は十五夜です」などといわれるのに比べて、かなりタイミングが後ろにずれるわけです。
「今日は中秋の名月です」という日の、昼前まで別の名前をツイートしていたり。

これを考慮して、「日本全国で(実際には、50地域の月の出君がカバーしている50の地域)月の出が終わった10分後」に名前を変えることにしました。

これで、「月の出とそれに対応する月の入りの月の名前は同じ」という条件を確保しつつ、通常いわれるタイミングにかなり知覚することができました。

------- 追記ここまで。

さて、「節気さんシリーズ」で、月の異名(三日月とか、十六夜とかそういう名前)を表示するようにしました。
この月の異名は、多くは旧暦の日付に基づいたものであるとして、旧暦の日付の日付を算出して、それに名前を割り当てるようにしていたのですが、どうも、これは違うらしいという記述を見つけました。

直接見たのは、WikiPedia の、この記事です。

http://ja.wikipedia.org/wiki/%E6%9C%88
(記事の中の、「月齢と呼び名」)


ただ、当初は、「旧暦の日付ではなく、月が出た回数を元に決める」ということの真意がわからず、節気さんシリーズでは、上述の通り旧暦の日付をもとに名前をつけていました。

ところが、これではちょっとまずいかもしれない――と、気づきました。
たとえば、このブログを書いている2010年6月はじめは、月は午後11時過ぎに昇り、翌日の午後になって沈みます。
ところが、節気さんシリーズの月の名前は、「旧暦の日付」に基づいていますから、午前0時で(日付が変わるのに伴い)名前が変わってしまいます。
しかし、現に空にある月の名前が、突然変わってしまって良いものでしょうか? せめて、月の出から月の入りまでは「同じ名前」でないとまずいのではないでしょうか?
これが、「旧暦の日付ではなく、月が出た回数で決める」という記述の真意でした。

さて、これで計算しようとすれば、(旧暦における)一ヶ月分の月の出・月の入りの時刻一覧を準備しなければなりません。さらに、月の出から月の入りまで――ということは、その日の月の出・月の入りの時刻に依存するというわけで、言い換えると、「どの場所における」というのを定義しないと、「今から臥し待ち月」などといえないわけです。

悪いことに、節気さんシリーズの「月齢君」は、地域に依存しないような Bot にしています(実際、月齢と月相は地域に依存しない)。
結局、以下のように処理をして、なんとか、それらしく表示することにしました。

・朔を含む日は「朔月」とする。(優先)
・朔の前の日(旧暦の月末)は、「晦日」とする。(優先)
・前回の月の入りの時刻と、今回の月の出の時刻の真ん中を、「名前が変わるとき」とする。
 ※この場合の、月の出・月の入りの基準は「東京」
 ※いすれにしても、地球の裏側に月があるときなので、地方毎の誤差は気にしないことにします。
・「今の時刻」が、「名前が変わるとき」を何回通過したかを元に、月の名前を決める。

当面、これで様子を見ることにしました。

2010年05月30日

月に関するいくつかの指標 ―― 月齢・月相 そして、月の異名

「節気さんシリーズ」に、最近、「月齢君」を加えました。
その件は、ご案内ということで、記事にいたしましたが、このときに、月の異名を併せて表示するようにしました。
また、節気さんシリーズ全体としても、月に関しては、「月齢」と「月相」という二つの数値を表示しています。

ここでは、このあたりのことについて書いてみたいと思います。

【基準となる瞬間 ―― 朔】

月に関わる数字で、日常的に関わる(言い換えると、地球から見たときに関わりのある数字)の基準は、「朔」です。
言い換えると、新月の瞬間ということで、さらにいえば、「太陽と月が同じ方向に見える瞬間」です。
ただ、同じ方向といっても、太陽と月は滅多に重ならないので(完全に重なるときには日蝕になります)おおざっぱに言えば、横方向の位置が一致したときになります。
※ただし、横方向というのが、地平線の方向ではないので、横方向の位置が一致したときといっても、もしも見えたら(それこそ、新月の瞬間なので実際は見えませんが)違和感のある位置だと思います。

これを基準にして、月齢や月相が定義されます。

【月齢とは】

堅い言葉で言えば、「朔の瞬間からの経過日数」です。
たとえば、これを書いているときから、一番近い朔(新月の瞬間)は、2010年6月12日の20:15(日本時間)です。
これを元にして、翌日(6月13日)の20;15 には月齢1、翌々日(6月14日)の20:15には、月齢が2……と数えるわけです。

【小数点のある月齢表示は?】

上記の通り、「朔の瞬間」を基準に月齢を数えるわけですが、さらに、1日 = 1.0 として、算出する場合に小数点以下を含めた表示を行います。上記の例では、12時間(= 0.5日)経過した翌日(6月12日)の、8:15 には、月齢 0.5 となります。

【月齢と月の形】

さて、月齢というのは経過時間を元にした数字です。一方で、月が地球の周りを回る早さも、地球が太陽の周りを回る早さも一定ではありません。こんな訳で、月齢と月の形は、完全には一致しません。
たとえば、2010年5月28日 8:07 は満月になった瞬間ですが、このときの月齢は 13.9 でした。
一方で、2010年12月21日 17:13 の満月は、月齢 15.6 です。
そうはいっても、月齢12で満月になるというようなことはありませんから、十分目安にはなるということです。

【月相とは】

これに対して、月の形を正確に反映しているのが「月相」です。
月相とは、「見かけの月と太陽がなす角度」のことされています。
つまり、月相が0度であれば、太陽と月は同じ方向=新月。180度なら、反対方向=満月。90度と270度は半月です。
これには、もうひとつの表し方があって、0度〜360度を、0〜28の数字で表すものです。節気さんシリーズで使用しているのはこちらの数字になります。
こちらの数字を使った場合には、月相0が新月、月相14が満月、月相7と21がそれぞれ半月です。
上述した、5月28日と、12月21日の満月も、月相はいずれも14.0になっています。

※節気さんシリーズで、「そろそろ満月」「概ね上弦」「まさに新月」などと表示しているのは、この、月相を基準にしています。

【旧暦の日付と、月の異名】

さらに関連しているのが、旧暦(太陰太陽暦でした)の日付です。
この暦は、「朔の瞬間を含んだ日がついたち(一日)」として、それ以降、2日、3日……と日付を振っていったものです。
そして、月の異名の多くが、この日付を基準としています。

よく知られている、「十五夜」という表現は、この、「旧暦15日の夜の月」を意味しています。
旧暦の日付の決め方は、先に述べた月齢の定義と類似しています。言い換えれば、月の異名もまた、月の形と完全には一致しないということです。
このため、いわゆる中秋の名月(旧暦8月15日の夜)は、必ずしも満月ではないという事態も発生します。
(もっとも、満月に近いというのは間違いありません)


節気さんシリーズにおいて、月の名前は、以下のようにつけています。

朔月(1)・既朔(2)・三日月(3)・夕月(4)・夕月(5)・宵月(6)・弓張月(7)
九夜月(9)・十日夜(10)・十日余の月(11)・十三夜(13)・小望月(14)・十五夜(15)
十六夜(16)・立待月(17)・居待月(18)・臥待月(19)・更待月(20)・二十日余の月(21)
弓張月(23)・有明月(24, 25, 27, 28)・二十六夜(26)・暁月(29 以降)
(括弧の中は、朔を含む日から数えた(当日も含む)付きの出現回数)

※ただし、朔の前日(旧暦の月末)は、晦日月

2010年05月25日

(ご案内)節気さんシリーズに、「月齢君」を追加しました。

え……タイトルの通りです。
節気さんシリーズには、月齢・月相「だけ」をつぶやくBotはありませんでした。
というわけで、なんとなく、「月齢君」を追加しました。

・一日に14回(午前と午後の、0時(12時)・3時・5時・6時・7時・9時・10時)に月齢と月相をつぶやきます。
・つぶやく時刻が中途半端なのは……作者が、「月の情報ならこの時刻かな」と適当に設定しました。
・毎正時だとちょっと多すぎるかなどうかな、などと思いながら。
・朔月・望月・半月の瞬間に、「ただいま朔(新月)です」などとつぶやきます。
・朔月・望月・半月が近づくと、(おおむね2日前から)そろそろ、概ね、ほとんど、まさに……などをつけて、つぶやきます。
・朔月・望月・半月の前後(20時間以内)には、「xx時間xx分後」とか、「xx時間xx分前」などもつけます。
・最後の3つは、節気さんシリーズ(世界の……を除く)共通の仕様ですが。

以上、ご案内でした。

そうそう、URL は、 http://twitter.com/sekki_getsurei です。

2010年05月19日

ツイッターのツイートはどこまで公開されているのか

この記事を書いている日、ツイッターでは、「無断フォロー」をきっかけとして、ちょっとした騒動があった。
その是非は置くとして、少なくとも、「自分のツイートを無断で見て欲しくない」という感情を抱きつつ、ツイッターを続けていたということなのだろうなと思う。

さて、この件については、類似の内容を「ツイッターの『嘘』」というタイトルで書いたばかりであるが、今一度、書いてみたい。

【ツイッターの一般的な印象】

どうも、インターネット上の「掲示板」などに比較すると、一般的な使い方では、ツイッターというのは、ずいぶんと「閉じた」環境に見えるらしい。
自分のフォロワーや、フォローを中心としたタイムラインという閉じた世界で、ツイートが連続するというイメージである。

だから、知らない人に勝手にフォローされる=知らない人に自分のツイートが読まれるのはちょっといやだな――という、そういう感覚が発生しうるのだろう。
しかし、考え方を変えれば、誰かをフォローするというのは、「ツイートを読みます」と意思表示をした上で読むということに過ぎない。
実際、そういった意思表示をしなくても、ツイートを読む方法というのは普通に存在するのだし、また、むしろ、自分が全く知らないところでも読まれ得るのだと意識しておくのは悪くないと思う。

【誰かのツイートを読むいくつかの方法】

たとえば、私自身、@asano_nagi のツイートを読むにはどんな方法があるだろうか。

ひとつは、 http://twitter.com/asano_nagi にアクセスするという方法である。これはあえて紹介する必要もないだろうと思う。
もうひとつは、 http://twitter.com/statuses/user_timeline/59402332.rss を RSSリーダーなどにフィードするという方法である。

これらは、特に珍しい方法ではない。そして、注目すべきは、ログインする必要も、そもそも、ツイッターのアカウントを持っている必要もないということである。

【もしかしたら、嗜好に関わる問題かも】

さらにいえば、ツイッターには、「おきにいり」という機能がある。
文字通り「おきにいり」だったり、後で読もうという目印だったり、それぞれに使われている機能だと思う。

いずれにしても、この機能を、「自分だけのメモ」として使っているというケースも多いのではないかと思う。
しかし、これも、たとえば、http://twitter.com/asano_nagi にアクセスしたあと、その場所で、「おきにいり」をクリックすれば、見ることができてしまう。
これも、ログイン不要である。
「自分自身のメモ用」として使うのか、「私としてはこれをおすすめします」という意味で使うのか、どちらを意識するかで、内容も異なってくると思うのである。

また、「ふぁぼったー」というサービスを経由すれば、さらに過去にさかのぼって「おきにいり」を確認することができる。

【終わりに】

以上書いたように、ツイッターのツイートは(そして、「おきにいり」も)普通に公開されているものである。
わざわざフォローしなくても、それどころか、ツイッターのアカウントを持っていなくても見えるものであると、そういう意識が、どこかで必要なのではないかと、そう思うのである。

※もっとも、ツイートを「公開しない」設定の場合、それは、きっと公開されていないのだろうと思う。
posted by 麻野なぎ at 21:08| Comment(0) | TrackBack(1) | Twitter と Bot の周辺