Bunrindo's BackUp

ぷらら「Broach」⇒ gooブログ
Broach

私の年賀状スタイル

2009-12-31 13:47:34 | 趣味の工房
 今年も大晦日となり、ようやく年賀状書きからも解放されホッとしている。 
虚礼廃止やメール普及により一時年賀状を出す人が減少したが、日本郵便の民営化(?)もあり、ここ数年は年賀状の販売枚数は伸びているとのことである。

 年賀状を書くと言っても、殆どの人は年賀状ソフトのお世話になっている。 私の受け取った約130枚の年賀状をチェックしてみると、自筆(自作版画も含む)が6枚(5% 弱)と少なく殆どがパソコン印刷である。 宛名の方も24枚(18% 強)が手書きになっており、80% 強の人はパソコン印刷である。 『なぜ宛名の方が手書きが多いのか?』を分析するのも面白そうだが、また別の機会にしたい。

 そういう私も裏表ともパソコン印刷であるが、10数年来、自作の年賀状ソフトを使っている。 当時も市販の年賀状ソフトもあったが、
① 住所入力の初期工数が大変。
② 単年度仕様で、個人毎の過去の受発信記録がない。(当時)
③ デザイン素材は多いが、ワンパタンで自由度が少ない。
等々の使い勝手の悪さから、自作するに至った。
 爾来、毎年、年末は自作の年賀状ソフトのバグとの戦いとなっている。 それでも最近は、ようやくバグも納まって来ており、以前ほど年賀状ソフトと格闘する事は無くなった。 

 最近では優秀な年賀状ソフトが市販されているとは思うが、12月初、日本郵便のホームページで『はがきデザインキット』なるフリーの年賀状ソフトを見つけダウンロードして試用してみるが、これは完全なハズレだった。
 
 年賀状発行履歴を見ると、実に15年間使い続けてきた事になる。 15年間の履歴は以下の通り。
 (差出人はぼかしを入れた。)


 その間に、郵便番号も 5桁から7桁に変り、宛名パタンは以下となった。
 (確認用のサンプルとした。)


 この年賀状ソフト、第3者に使って貰う様な安定性はないが、私自身にとっては深い愛着があり、パソコンが操作できなくなる年まで、どうやらこのソフトを使い続ける事になりそうである。


旧暦計算について

2009-08-10 17:06:56 | 趣味の工房
 私の作っている家計簿ソフトのカレンダーに、大安、赤口、・・・、仏滅などの旧暦の六曜を追加したいとかねがね思っていたが、何か手間取りそうな予感がしたので長い間後回しにしてきた。 時間に余裕のできた1ケ月程前、カレンダーへの六曜追加を開始。

【六曜】
 六曜とは、大安、赤口、先勝、友引、先負、仏滅のことで、一種の占い・迷信である。
ある行政・団体では、その記載や使用を禁止する所もあると聞くが、まあいい。やって見よう。
 六曜は同じ順序で日別に振り当てられる。 但し、1月・7月は「先勝」を先頭に繰り返され、他の月も、2月・8月は「友引」、3月・9月は「先負」、4月・10月は「仏滅」、5月・11月は「大安」、6月・12月は「赤口」を先頭に、順に繰り返されるという単純なものだ。
しかし、この月は全て旧暦の月であり、この旧暦月を求めるのに悪戦苦闘が始まる。

【新暦と旧暦】
 常日頃使っている新暦は「グレゴリー暦」と呼ばれるもので、1年を12ヶ月、365日とするが、地球が太陽を回る周期(1年)は 365.2421904日。 月と季節のズレを防ぐ為、4年に1度閏年を設け、更に400で割り切れる年は閏年にしないと言う方法をとっている。
しかしながら、Septemberが9月であったり、Octoberが10月であったり、1ケ月の長さも古代ローマ時代の決め事がそのまま引き継がれてきている等、月の決め方は余り論理的とは言えません。
 一方、旧暦は、明治5年12月3日から明治政府にて改暦される以前に使われていた「天保暦」の事をさし、この「天保暦」では、月は、1年を太陽と地球の位置から24等分した【二十四節気】と、【朔望周期(月の満ち欠け)】によって決まります。 また、月名も以下の様にその季節にあった気候や祭事に関連してつけられ、味わいがあります。 
睦月、如月、弥生、卯月、皐月(早苗月)、水無月、文月(穂含月)、葉月、長月(夜長月)、神無月(神嘗月)、霜月、師走。 
尤も現在では、新暦の月でも、この和暦の月名で呼ぶ様になっています。


【二十四節気】
 地球が太陽をを回周する公転軌道の位置を 15度(°)単位に24等分し、その位置に当たる日を
春分( 0°)、 清明( 15°)、 穀雨( 30°)、立夏( 45°)、小満( 60°)、芒種( 75°)、
夏至( 90°)、小暑( 105°)、大暑( 120°)、立秋( 135°)、処暑( 150°)、白露( 165°)、
秋分(180°)、寒露( 195°)、霜降( 210°)、立冬( 225°)、小雪( 240°)、大雪( 255°)、
冬至(270°)、小寒( 285°)、大寒( 300°)、立春( 315°)、雨水( 330°)、啓蟄( 345°)
と命名します。 二十四節気の名前も月名と同様、季節・気候を表現する名前となっています。 
 公転軌道の位置は「太陽の黄経」と呼ばれ、上記の( )内の数値がそれに当たります。
軌道位置(太陽の黄経)が30で割り切れる二十四節気を【中気】、30で割り切れない二十四節気を【節気】と呼びます。 また、【中気】の中でも、冬至、春分、夏至、秋分は特に【二至二分】と呼び、旧暦の月を決めるキーとなります。 即ち、冬至を含む月は11月、春分を含む月は2月、夏至を含む月は5月、秋分を含む月は8月となります。
各【二十四節気】が新暦の何月何日になるかは、「およその日」は分かりますが、年によってズレる可能性があります。 これは、1年を365日とするため、地球の公転周期との差(0.2421904日=約5.49時間)分だけ毎年誤差が生じ、1日前後の違いが発生するためです。
このため、特定の年の【二十四節気】の日付を求めるには、その「およその日」前後の「太陽の黄経」を求め、【二十四節気】の「太陽の黄経」が存在する日を、その年の【二十四節気】の日付とします。
 特定の日の「太陽の黄経」は、18個の Cos関数の総和で求められます。 (『旧暦計算サンプルスクリプト Rev.1.1説明書』 H.TAKANO著を参照)また、「太陽の黄経」は、Sin関数の総和でも求められる。 (『太陽と月の略算式の紹介』 参照) ようですが、私の場合はCos関数を使いました。
 旧暦のこよみの作る場合、こよみを作る年の前年の冬至から、翌年の春分までの二十四節気の新暦での年月日を求めます。 なぜ前年の冬至からかと言うと、冬至のある月が旧暦の11月となり、旧暦月を決めるベースとなっている為です。
こうして求めた【二十四節気】と新暦の日付の対応を【二十四節気テーブル】に作っておきます。


【朔日(ついたち)】
 旧暦では、新月から次の新月までを1ヶ月とします。 この周期を、【朔望周期】と言い、29.530589日となります。 朔は新月、望は満月のことです。
新月とは、太陽と地球の間に月が位置する時点のことで、地球からは月の見えなくなります。
月も地球の周りを公転しており、月の公転軌道の位置を「月の黄経」と呼びます。 新月を別に定義すれば、「太陽の黄経」=「月の黄経」となる時点が新月なります。 この時の月齢がゼロです。新月(月齢=ゼロ)となる時点が存在する日が、【朔日(ついたち)】となります。
 特定の日の「月の黄経」は、63個の Cos関数の総和で求められます。 「太陽の黄経」と同様、Sin関数の総和でも求められるようですが、同じく Cos関数を使いました。
 旧暦のこよみの作る場合、こよみを作る年の前年の冬至直前の朔日から求めます。 旧暦月を決める為の基準月となる為です。 【朔日】には、【二十四節気】とは違い「およその日」は無いため、「太陽の黄経」と「月の黄経」の差がプラス/マイナスに反転する前後の日時と黄経差を求め、黄経差 = 0 となる日付を求めます。 これが、前年の冬至の旧暦月(11月)の朔日となります。
一番目の【朔日】が決まると、次の【朔日】は【朔望周期】をプラスした日を「およその日」とし、あとは、一番目と同様に朔日を求めます。 こうして、翌年の春分直後までの朔日を求めます。
こうして求めた前年の冬至直前の朔日から翌年の春分直後までの朔日は、【朔日テーブル】に記録します。 【朔日テーブル】には、①【朔日】の他、②【晦日】(次の朔日の前日)、③【朔日】から【晦日】の間の存在する中気の日付(複数個存在する月も有り)、④③の中気日付が【二至二分】か、否か、も計算・記録しておきます。


【閏月】
 新月から新月まで(【朔望周期】)は 29.530589日であり、従って、旧暦の1ケ月の日数は、29日、又は30日となります。 (この【朔望周期】は、地球も太陽の周りを公転しているため「月の公転周期」とは異なります。) そうすると地球の公転周期(365.24…日)より、11日強短くなってしまうので、このズレを修正するため、【閏月】を挿入します。 約3年に 1回 (正確には、19年に7回)、この【閏月】を挿入することにより、計算上このズレが修正されます。


【旧暦年・旧暦月の割り付けと、閏月の挿入】
 次に、前述の【朔日テーブル】の各朔日に【旧暦年】・【旧暦月】を割振ります。 
1番目の朔月は、前述した様に旧暦月は 11月となります。 2番目以降の朔月は、直前の旧暦月にプラス1 します。 勿論、直前の旧暦月が 12月ならば、旧暦月は1月、旧暦月年をプラス1 します。 
 では、どういう月を【閏月】にするか?
結論から言えば、次の条件に当てはまる時、その月は【閏月】とします。
(1) 【中気】を含まない月であること。
(2) 前の【二至二分】を含む月から次の【二至二分】を含む月の間に、3回の朔日(月)があること。 
つまり、冬至を含む月(11月)の4ヶ月後に春分を含む月(2月)になる場合とか、春分を含む月(2月)の4ヶ月後に夏至を含む月(5月)になる場合とか、・・以下同じ・・、の場合である。 この条件を見落とすと、旧暦月がズレしまいます。
 【閏月】が発生した場合には、直前の【旧暦年】・【旧暦月】はそのままで、【閏月】とします。
こうして割り付けとた【旧暦年】・【旧暦月】・【閏月】も、【朔日テーブル】に記録します。 


【旧暦テーブルの作成】
 これで、旧暦年・旧暦月とその朔日に対応する新暦の日時が決まりましたので、後は欲しい新暦月の旧暦テーブルを作ります。
この旧暦テーブルには、新暦年月日毎に、旧暦年月日、六曜、二十四節気等の旧暦情報を記録します。 その他、【二十四節気テーブル】や【朔日テーブル】を作る際に計算した、各日々の「太陽の黄経」、「月の黄経」、「月齢」等を記録しておけば、デバッグに役立ちます。
 月齢は、(【朔日テーブル】の朔日(時刻を含む)-新暦の年月日)にて求めることができます。 通常、正午時点のものを言うため、上記値に12時間を加えた値がその日の月齢となります。
また、干支も興味があれば、このテーブルに追加できます。
月、年単位の干支もありますが、必要な都度も簡単に求められます。
(『干支』 wikipediaを参照。 http://ja.wikipedia.org/wiki/%E5%B9%B2%E6%94%AF )


【あとがき】
 Webにて検索した結果、多くの参考になるサイトのお世話になり、おかげで本を購入するまでも無く、MSAccessd上のBasicでの旧暦計算を実現できた。 大いに感謝!
しかしながら、十数年間の旧暦カレンダーを作ってこれで大丈夫と確信した後、2033年について試行してみたら見事アウト。 旧暦は、太陽と地球と月の運行の微妙な位置関係を反映した暦であることをつくづく実感した。 完成(?)まで約1ヶ月を要したが、大変貴重な経験であった。
 今回使用した 「太陽の黄経」と「月の黄経」を使って、『日の出・日の入』、『大潮・小潮』 時刻も求められそうであるが、場所情報が加わり少し時間も掛かりそうなので、また次回の機会にしたい。
 特にお世話になった、Web上の参考文献・サイトは以下の通りです。
1. 『こよみのページ』 (http://koyomi.vis.ne.jp/directjp.cgi?http://koyomi.vis.ne.jp/reki_doc/doc_0330.htm)
2. 『旧暦計算サンプルスクリプト Rev.1.1説明書』 H.TAKANO著。 (http://api.sekido.info/qreki-doc)
3. 『太陽と月の略算式の紹介』 (http://www.geocities.co.jp/Technopolis-Mars/3631/index.html)
4. 『旧暦は地球を救う』 (http://www.88d.jp/top.html)
5. 『干支』 等。 wikipedia (http://ja.wikipedia.org/wiki/%E5%B9%B2%E6%94%AF)

ブログ開始

2007-06-14 18:25:01 | 趣味の工房

この五月に加入しているテニスクラブのホームページを立上げたのを期に、

Broach試行ユーザ登録依頼、一度の投稿もしていなかったブログを思い出し、

この際、マイブログも中身のあるものにして行こうと思い立った次第。

まず困ったことは、ブログでは何が出来るか? ホームページ作成との違い? 

1年以上前に印刷したブログ作成の解説は、

Broachサービスの度重なる機能追加で役立たず。

「Broachの基本機能マニュアル」のダウンロード、印刷とその理解から再開。

次に、ブログの基本方針は?マイブログであり、余り他を意識せず、

徹底的に自己の興味本位な内容に徹する事。 しかしながら、

同じ趣味を持つ先人の意見やコメント等は拝聴できる様な仕組みにはしておきたい。

仕組みは追々考えるとして、まずは記事の投稿。 

どんなコンテンツにするか? 

カテゴリとしては、

取り敢えず、1:テニス、2:家計簿ソフト、3:住所録ソフト、4:ロボット、

それに、5:アルバム、と、6:もろもろ を設定。 

全てのカテゴリ記事が投稿できるかどうか全く自信は無いが、

まずは実行ありきで、自分自身を奮い立たせている次第。