ここですという名前のブログやさん

【2010年8月29日に追記】

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

実際には、


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

と言うことになります。

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


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

内容は、「月の異名（というか、月の呼び名）」さらに……。( http://asano-nagi.sblo.jp/article/38759410.html ) で書いたものではあるのですが。
さて、節気さんシリーズでは、月の名前は「（旧暦）何日の月はどういう名前」という立場ではなく、「（旧暦）１日から数えて、何回目の月はどういう名前」という立場をとっています。
たとえば、今年（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年は）９月22日が中秋の名月」と言われることになりますが、節気さんシリーズは、9/22になっても、10:30 頃までは、「小望月」と言ってますし、翌日（9/23）になっても、昼前まで、「中秋の名月」とつぶやくことになります。

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

もしかして、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

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


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

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

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

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



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

○ ４）接続完了後、クライアントからのデータを受信する
○ ５）クライアントからのデータは CRLF で１行ごとに区切る
○ ６）２個の空行（CRLF のみの行）を受信したら、次の処理に移行する

○ ７）最初の空行の直前までをヘッダとする。
○ ６）最初の空行の次の行をボディとする（ボディは１行のみ）
○ 　　・以上の結果を、Memo_server_recv に順次書き込む

８）ヘッダの処理
○ 　　・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 に順次書き込む

９）ボディの処理
○ 　　・ボディの内容を、そのまま、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）と同じ

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

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


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

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

さて、少しずつ見てゆきましょう。
まず、（旧暦での）月初めです。

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

引き続き、月の半ばです。

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

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

では、月末付近はどうでしょうか？
これが、月末付近の詳細です。

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

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

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

【2010年8月29日　追記】

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

【月齢とは】

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

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

上記の通り、「朔の瞬間」を基準に月齢を数えるわけですが、さらに、１日 = 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になっています。

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

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

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

よく知られている、「十五夜」という表現は、この、「旧暦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 以降)
（括弧の中は、朔を含む日から数えた（当日も含む）付きの出現回数）

※ただし、朔の前日（旧暦の月末）は、晦日月

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

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

以上、ご案内でした。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【終わりに】

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

※もっとも、ツイートを「公開しない」設定の場合、それは、きっと公開されていないのだろうと思う。

Twitter における、Basic 認証の終了期限が近づいております。
そういうわけで、節気さんシリーズは、なんとか、OAuth 対応を終えたわけですが、もしかして役に立てばと思い、検討中に使用した、簡易型のモニタをアップしてみました。



ただし、もともと、単なる確認用に、やっつけ仕事で作成したものなので、statuses/update （単に、つぶやきを、ポストするだけ） しか対応していません
また、つぶやきとして設定する文を作成する手段も持っていません。
さらに、Proxy にも対応していません
それでも、もしも役に立つところがあれば

というわけで、実体はこちら → http://axis.blue/tec/oauthmon.html

OAuth だと Basic 認証に比べてなぜ安全なのか？　これは、以前に書いたのですが、書き忘れが当たったので追加します。
もうひとつ、OAuth 認証だと、「誰が書き込んだか」がはっきりわかるという点があります。
たとえば、あるアカウントから大量・無差別なメッセージが書き込まれたとします。
これは、誰がやったのでしょう？

もしかしたら、そのアカウントの正当な利用者かもしれません。もしくは、その利用者が利用しているどこかのサービスかもしれません。もしくは、パスワードが盗まれたのかもしれません。詐欺的なサービスに引っかかったのかもしれません。

従来、このような場合、「アカウント停止」という手段がとられがちでした。
そのアカウントの所有者が、本当に「やった」のかどうかが判断できないのと、それ以前に、SPAM を確実に止めるとしたら、そのアカウントを停止するしか方法がなかったからです。

Basic 認証では、「該当のアカウントのＩＤとパスワードだけを使う」仕様なので、これは同じ事です。
一方で、OAuth 認証が絡むと事情が変わってきます。
OAuth 認証で何かをしようと思うと、該当するアカウントに関する情報だけでなく、それを投稿する側の（たとえば Bot の）情報も必要です。
ですから、もしも、あるアカウントからSPAMが発信された際、少なくとも、「どんなアプリケーションを使ったか」は特定できます。

それが、たとえば、詐欺的なアプリケーションだった場合、（ユーザーのアカウントではなく）そのアプリケーションのアカウントを停止することで、ユーザーアカウントを有効にしたまま、SPAM を止めるということもできるようになります。

こういう利点もあるのでした。