一休さん　(トランプのルール)

トランプ/普通・小学生(低学年) トランプ/2人以上 トランプ/5分以上

基本情報

  • 使用カード：52枚
  • 人数：2人～(6人ぐらい)
  • 時間：5分以上
  • 別名：七五三
  • 亜種：ぶたのしっぽ

「ぶたのしっぽ」の手を置くルールとほぼ同じ進め方。

勝ち負け

  • 手持ちのカードが少ない方が勝ち

準備

  • カードをよく切り、裏向きで円の形に並べる
  • 順番を決める

進行(最初のプレーヤー)

  • 円から1枚引き、「一休さん」と言いながら円の中央へ表にして置く(台札)
  • 次のプレーヤーへ

進行(各プレーヤー)

  • 円から1枚引き、「一休さん」と言いながら円の中央へ表にして置く
  • 置いたカードが一休さん(「A」「9」「3」)の場合、全員が台札の上に手を置く
  • 一番遅い(一番上の手)のプレーヤーが台札を全部取る
  • 一休さん以外で手を置いてしまったら、おてつきとして台札を全部取る
  • 次のプレーヤーへ

終了

  • 円が全部無くなったら終了
  • 取ったカードの枚数を数えて勝敗を決める

オプション・ローカルルール

  • 七五三(「7」「5」「3」)の場合に手を置く 他、語呂合わせなら何でも当てはめられる
  • いくつか語呂合わせを決めておき、台札に置く時の掛け声の数字に合わせて手を置く
    「一休さん」と言いながらであれば「A」「9」「3」、七五三なら「7」「5」「3」が対象になる
  • 手を置くルールにせず、一休さんなら必ず台札を取る
  • etc...

メモ

たまたまなのか、どちらかが派生したのか分からないが「ぶたのしっぽ」の手を置くルールとほぼ同じ。
「ぶたのしっぽ」に記載したジョーカーなどのオプションルールも適用できるので、好みに合わせて。

語呂合わせを考えれば何でもできるので、ご苦労さん、肉屋さんなど、色々変えながらやるのも楽しいかも。

<トランプのルール一覧>

ぶたのしっぽ　(トランプのルール)

トランプ/簡単・幼児 トランプ/2人以上 トランプ/5分以内

基本情報

  • 使用カード：52枚
  • 人数：2人～(6人ぐらい)
  • 時間：5分以内
  • 別名：ぶたのケツ、ドーナツなど
  • 亜種：一休さん、七五三

「ぶたのしっぽ」は最初に並べる形から名前が付いたらしい。
「ドーナツ」も同じ理由だろう。

勝ち負け

  • 手持ちのカードが少ない方が勝ち

準備

  • カードをよく切り、裏向きで円の形に並べる
  • 順番を決める

進行(最初のプレーヤー)

  • 円から1枚引き、円の中央へ表にして置く(台札)
  • 次のプレーヤーへ

進行(各プレーヤー)

  • 円から1枚引く
  • 引いたカードが、台札の一番上のカードと同じマークなら、台札を全部取る
  • 違うマークならそのまま台札の上に重ねる
  • 次のプレーヤーへ

終了

  • 円が全部無くなったら終了
  • 取ったカードの枚数を数えて勝敗を決める

オプション・ローカルルール

  • 同じ色(黒、赤)なら台札を取る
    • 接戦になる、大量取得・逆転が減る
  • 同じ数の場合も台札を取る
    • 意外性が増える、後述の手を重ねるルールで特に有効
  • 自分の番の際、円から引くのではなく、手札から台札へ1枚置ける
  • ジョーカーを入れておき、ジョーカーを引いたら台札を取る
    もしくは引いたプレーヤーは手札全てを台札に戻す
    戻す場合、台札の一番上はプレーヤーが自由に決める(ジョーカー以外)
  • 同じマーク(同じ数字)が出たら、全プレーヤーが台札の上に手を置く
    一番遅かった(一番上の手の)プレーヤーが台札を全部取る
  • 子供は集めるの好きなので、多い方が勝ちにしてもいい
    ただし手札から出せるルールや手を置くルールとは合わないので、単純に円から引くだけのルールの時に
  • etc...

手を置くルールの場合、より複雑な条件を付けることもある。
決まった数字(例えば7)なら必ず手を出す、台札の倍数・約数の場合も出すなど。

あと手を置くルールにするなら、ほぼ必然的に少ない方勝ちになる。
もし多い方勝ちにするなら、一番早く台札に手を置いたプレーヤーが台札を取ることになるが、ほぼ間違いなく台札を置いた人が一番早くなるからつまらないと思う。

メモ

多い方勝ちルールだと坊主めくりに近い感じになる。蝉丸さんがいないぶん、分かりやすいかも。
マーク合わせ・数合わせルールだけなら、マークが判別できる・数字が分かる子供ならできる。
カードを手に持つ必要がないので、手の小さな子供にはやりやすい。
運次第なので大人vs子供でも手加減を考えなくてもいい。

手を置くルールは大人も加わるなら小学生以上でないとキツイか。
「うすのろ」系になるので大人でも単純に盛り上がるかも。
たぶん手を出す条件がローカルルールでいっぱいありそう。
爪は切っておこう。

<トランプのルール一覧>

Windows Update　80072EE2エラー対処

Windows

HDDを入れ替えたPCにWindows7をインストールしたが、Windows Updateが「80072EE2」エラーで動かなかった際のメモ。

信頼済みサイト

真っ先に出てくる対処法。
インターネットオプションの信頼済みサイトにアップデート関連のURL
http://*.update.microsoft.com
https://*.update.microsoft.com
http://download.windowsupdate.com
を登録して、「このゾーンのサイトにはすべてサーバーの確認（https:)を必要とする」のチェックを外す。

結果：もちろん真っ先に試した、ダメだった。

Internet Explorerバージョンアップ

エラー対策を調べる際にMicrosoftのサイトが一部正常に表示されなかった。
IEが8のままだったので、念のため最新版(11)をダウンロードして入れてみる。

結果：これぐらいで直ってたらメモにしない。

Windowsライセンス認証

LANに繋がずにインストールしたため、ライセンス認証ができていなかった。
原因調査の過程でシステム画面を開いて気づいた。
ライセンス認証を通してみる。

結果：やっぱりダメだった。

Windowsファイアウォールを無効

Windowsファイアウォールが悪さをしている可能性を考えて、ファイアウォール無効にしてみる。
ただ仮に上手くいったとしても、自動Updateができない(毎度F/WをOFF→手動Update)ことになるが、とりあえず。

結果：ファイアウォールが悪いわけではない様子。

Windows Updateクライアントのバージョンアップ

調べていると以下のサイトを発見。
Windows7SP1-64bit WindowsUpdate (エラーコード 80072ee2) - Qiita
PCは64bitではなく32bitなので念のためKB3112343を確認すると、Windows Updateクライアントのパッチ(バージョンアップ)の様子。
システム要件に合致するものをダウンロードして手動でインストール。

結果：犯人はヤス、もといヤツ。

めでたく更新プログラム65個をダウンロード中。

そう言えば、よくある「Windows Updateがいつまでも終わらない問題」もUpdateクライアントの最新版を手動で入れれば解消する、みたいなことだったな。
Windows Updateで問題が起きたら、Updateクライアントの最新版を確認するのがいいのかも。

rrule.js簡易メモ

JavaScript iCal

icalのrruleから該当日付を計算してくれるjavascriptライブラリ。
超便利、だが色々問題があったのでメモ。

ビルド環境：node + bower + webpack
※BowerWebpackPluginでbower取得したモジュールはパス書かなくてもいいようにしている。

mainのパスが違います問題

bowerで最新版(2.1.0)取得後、とりあえずライブラリを読み込んで

var RRule = require('rrule').RRule;

ビルド。

Module not found: Error: Cannot resolve 'file' or 'directory' ./rrule.js in ・・・

なぜ・・・

rruleのbower.jsonを確認すると、"main": "rrule.js"となっているが、実際はlib/rrule.jsにある。勘弁して。
とりあえず"main": "lib/rrule.js"に直すと、ビルドエラーは解消。

README.mdが間違ってます問題

12月の土日を指定するrruleを指定してみる。

var rrule = new RRule({
    freq: RRule.WEEKLY,
    byweekday: [RRule.SA, RRule.SU],
    dtstart: new Date(2016, 11, 1),  // 2016/12/01
    until: new Date(2016, 11, 31)    // 2016/12/31
});

実行すると

Uncaught TypeError: Cannot read property 'WEEKLY' of undefined

なぜ・・・スペルミスとかしてないし。
デバッグするとRRuleがundefinedになっている。というわけで、

// var RRule = require('rrule').RRule;
var RRule = require('rrule');

にすると正常に。webpack使っているから？ それならREADME.mdが間違っているとは言えない。

と思いきや、調べる過程でソースを読んでいて気づいた。

    module.exports = {
        RRule: RRule
        // rruleset: rruleset
    }

rrulesetが公開されてない？
gitのrrule.jsと比較すると、ソースが全然違う。。。
どうやらgitに表示されているソースはREADME.mdは2.2.0-devで、正式リリースの2.1.0ではない様子。
できればRRuleSetも使いたかったが、管理が怪しげな2.2.0-devを使う気にはなれないので、そこは諦めることにする。

動作確認

根本のソースは正しいロジックなのか疑心暗鬼になりつつ動作確認してみる。

// 12月の木土
var rrule = new RRule({
    freq: RRule.WEEKLY,
    byweekday: [RRule.TH, RRule.SU],
    dtstart: new Date(2016, 11, 1),  // 2016/12/01(木)
    until: new Date(2016, 11, 31)    // 2016/12/31(土)
});
rrule.all();
=> 結果がDate配列で返される
Thu Dec 01 2016 00:00:00 GMT+0900 (東京 (標準時))
Sat Dec 03 2016 00:00:00 GMT+0900 (東京 (標準時))
Thu Dec 08 2016 00:00:00 GMT+0900 (東京 (標準時))
Sat Dec 10 2016 00:00:00 GMT+0900 (東京 (標準時))
Thu Dec 15 2016 00:00:00 GMT+0900 (東京 (標準時))
Sat Dec 17 2016 00:00:00 GMT+0900 (東京 (標準時))
Thu Dec 22 2016 00:00:00 GMT+0900 (東京 (標準時))
Sat Dec 24 2016 00:00:00 GMT+0900 (東京 (標準時))
Thu Dec 29 2016 00:00:00 GMT+0900 (東京 (標準時))
Sat Dec 31 2016 00:00:00 GMT+0900 (東京 (標準時))

dtstart ≦ ● ≦ untilで木・土が列挙されているので問題なさそう。

between()で期間を絞ってみる。

// 12/08(木)から12/24(土)の間だけ取得する
rrule.between(new Date(2016, 11, 8), new Date(2016, 11, 24));
=>
Sat Dec 10 2016 00:00:00 GMT+0900 (東京 (標準時))
Thu Dec 15 2016 00:00:00 GMT+0900 (東京 (標準時))
Sat Dec 17 2016 00:00:00 GMT+0900 (東京 (標準時))
Thu Dec 22 2016 00:00:00 GMT+0900 (東京 (標準時))

rrule.between(new Date(2016, 11, 8), new Date(2016, 11, 24), true);
=>
Thu Dec 08 2016 00:00:00 GMT+0900 (東京 (標準時))
Sat Dec 10 2016 00:00:00 GMT+0900 (東京 (標準時))
Thu Dec 15 2016 00:00:00 GMT+0900 (東京 (標準時))
Sat Dec 17 2016 00:00:00 GMT+0900 (東京 (標準時))
Thu Dec 22 2016 00:00:00 GMT+0900 (東京 (標準時))
Sat Dec 24 2016 00:00:00 GMT+0900 (東京 (標準時))

第3引数にtrue指定すると、between()引数の日時も含んでくれる。

RRuleSetが使えないは残念だが、rrule解析してくれるだけでもかなりありがたい。

Javaで年号を追加する

Java

POIを使って年号(元号、和暦)付き日付をExcelに出そうとすると少し面倒なことになった。
年号関連のセル書式判定がイマイチな処理になる上、Excelのバージョンが変わると仕様が変わるかもしれない。

そんなわけでJava側で処理した方がいいという考えになったが、年号をカスタマイズしたい時にどうするのか調べたのでメモ。

年号が変わるなんて先の話だと思っていたが、現実になりそうだよなぁ。
日本中のSEが狂喜乱舞するんだろうなぁ。

・・・の前に、Java8で日付/時刻API(Date and Time API)が追加されているので、そちらでの年号の扱いも確認。
参考：日本人のためのDate and Time API Tips - Programming Studio

Java8 Date and Time API概要

Date and Time APIでは、日付のみ、時刻のみ、日付/時刻の3種クラスが用意されていて、用途によって使い分ける。

  • 日付のみ：通常はLocalDateクラスを使う。ChronoLocalDateを実装したクラスが当てはまる。
  • 時刻のみ：LocalTimeクラスを使う。元インターフェイスは特に無し？
  • 日付/時刻：通常はLocalDateTimeクラスを使う。ChronoLocalDateTimeを実装したクラスが当てはまる。

now / of

現在日時を取得する際はnow()、指定日時を取得する際はof()を使う。

LocalDate date = LocalDate.now();  // 今日
LocalTime time = LocalTime.now();  // 現在時刻
LocalDateTime dateTime = LocalDateTime.now();  // 現在日時

LocalDate date = LocalDate.of(2016, 1, 2);  // 2016年1月2日
LocalTime time = LocalTime.of(12, 34, 56);  // 12時34分56秒
LocalDateTime dateTime1 = LocalDateTime.of(2016, 1, 2, 12, 34, 56);  // 2016年1月2日 12時34分56秒
LocalDateTime dateTime2 = LocalDateTime.of(date, time);  // 2016年1月2日 12時34分56秒

at / to

クラス間の変換メソッドがat・・・、to・・・で用意されている。
atは情報を足すイメージ、toはそのまま変換するイメージ。

LocalDate date = LocalDate.of(2016, 1, 2);  // 2016年1月2日
LocalTime time = LocalTime.of(12, 34, 56);  // 12時34分56秒

// 全て2016年1月2日 12時34分56秒
LocalDateTime dateTime1 = date.atTime(time);
LocalDateTime dateTime2 = date.atTime(12, 34, 56);
LocalDateTime dateTime3 = time.atDate(date);

LocalDateTime dateTime = LocalDateTime.of(2016, 1, 2, 12, 34, 56);  // 2016年1月2日 12時34分56秒
LocalDate date = dateTime.toLocalDate();  // 2016年1月2日
LocalTime time = dateTime.toLocalTime;  // 12時34分56秒

format / parse

DateTimeFormatterを使う。DateTimeと付いているが日付/時刻専用ではなく、LocalDate, LocalTimeも同じ。

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy/MM/dd");

LocalDate date1 = LocalDate.of(2016, 1, 2); 
System.out.println(date.format(formatter));  // 2016/01/02

LocalDate date2 = LocalDate.parse("2016/01/02", formatter);  // 2016-01-02のLocalDate


あと演算系のAPIも用意されているが、今回は本筋と逸れるので省略。

年号を扱う

年号を扱うにはChronoLocalDate実装(日付のみ系)のクラスJapaneseDateを使う。
now(), of()が用意されていて、かつ年号ベースでのof()もある。

JapaneseDate date1 = JapaneseDate.now();
JapaneseDate date2 = JapaneseDate.of(2016, 1, 2);
JapaneseDate date3 = JapaneseDate.of(JapaneseEra.HEISEI, 28, 1, 2);  // 平成28年1月2日 = 2016/01/02

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("Gyy年MM月dd日");
System.out.println(date2.format(formatter));  // 平成28年01月02日

JapaneseDateは出力用

JapaneseEraは明治以降の年号を扱うEnum型。おまけに各valueが直感的でない。
明治[-1]、大正[0]、昭和[1]、平成[2]になっている。
1970年が起点なので昭和が1ということらしい。 なのでプログラム上で使うならJapaneseEraを使ったof()は使わ(え)ない。

更にJapaneseDateにはparse()がない。ナンテコッタイ。
おそらく"平成28年1月2日"という文字列をparseするのが面倒なのだろう、気持ちは分かる。
ただそのおかげで、文字列"2016/01/02"からJapaneseDateを直接作る術も無い。
一度LocalDate(or LocalDateTime)にparse()して、from()で読み込むのが正解か？

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy/MM/dd");
LocalDate date1 = LocalDate.parse("2016/01/02", formatter);
JapaneseDate date2 = JapaneseDate.from(date1);

あと、JapaneseDateクラスはあるが、JapaneseDateTimeというのは無い。

そんなわけで、日付はLocalDateやLocalDateTimeで処理するのが基本で、表示などのformatにだけJapaneseDateを使うことになるだろう。

年号を追加する (!! Java8ではできません !!)

参考：Javaで新元号に対応する - Qiita
jre/lib/calendar.propertiesに年号行を追加する。
仮に「2017/10/01から新年号『現合』開始、短縮文字は『G』」だとしたら、

name=\u73fe\u5408,abbr=G,since=1506783600000

と書く。 \u73fe\u5408は「現合」をnative2asciiした文字、1506783600000は1970/01/01からのミリ秒。

テストする。

JapaneseDate date1 = JapaneseDate.of(2016, 1, 2);  // 2016/01/02 => 平成28年1月2日
JapaneseDate date2 = JapaneseDate.of(2020, 7, 24);  // 2020/07/24 => 現合4年7月24日 (東京オリンピック開会式)

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("Gyy年MM月dd日");
System.out.println(date1.format(formatter));  // 平成28年01月02日
System.out.println(date2.format(formatter));  // 304年07月24日 ？？？？？

304年てなんぞや。。。
これ年号が「3」で「04年」と表示されている様子。たぶん3はJapaneseEraのvalue値だと思われる。

つまり、壮絶に時間を費やしてダメだったという。。。
できると書いてあるサイトがあったがエアプということか。まともなSEならエアプは恥ずかしいからやめましょう。

誤解の無いように言うと、参考：Javaで新元号に対応する - Qiitaに書いてあるcalendar.propertiesに年号追加する方法自体は間違っていない。
calendar.propertiesに追加してDateFormatでDate型をformatすれば、意図した通りに追加した年号が計算されて表示される。
Date and Time APIがcalendar.propertiesに対応できていない、というかこれバグのレベルなんじゃ。。。

結論

  • 年号追加はJavaのバージョンアップまで待つ、という人

    • Date and Time APIを使っておく

  • バージョンアップできない、先行で年号追加したい、という人

    • Date and Time APIを使いつつ、年号表示の処理だけDate(+ DateFormat)使う

iCalのrruleを必要な分だけ抜き出して使う

つれづれ iCal

システム上でスケジュール情報を登録・保持するようにしたいが、一から考えるのは面倒、特に繰り返し条件が。
なのでiCalのrruleの仕様をそのまま踏襲することにするが、日本語情報がほとんど無い。
一番参考になったのがここ。
CalDAV(iCalendar)のrrule（繰り返し設定）一覧まとめ
FREQを基点にしてまとめ直す。

FREQ 繰り返し条件 DAILY WEEKLY MONTHLY YEARLY
UNTIL 終了日 ○ ○ ○ ○
BYMONTHDAY 月の日付指定 × × ○ ○
BYDAY 曜日指定 ○ ○ × ○
INTERVAL 間隔 ○ ○ ○ ○
BYMONTH 月指定 × × × ○
COUNT 繰り返し回数 ○ ○ ○ ○

ここから機能を絞っていく。
まず前提として、開始日・終了日は必須で保持する。
無期限の予定とかほぼ入れない。特に仕事では大抵年末や年度末で期間を切る。

  • FREQ:DAILY

    • そもそも要る？ 開始 - 終了日を指定して連続させればいい
    • 仕事上のスケジュールで2日おき/3日おき(INTERVAL)とかお目にかからない
    • 大体は毎週 x曜日とかになる

  • FREQ:YEARLY

    • たぶん要らない。毎年この日、という指定はあれば便利だと思うけど
    • 毎年予定は忘れないようにするために使うことが多い気がする
    • 必要なら個人のGoogleカレンダーに入れてもらう、今回のシステムでは必要性がない
    • 関連してBYMONTHも不要になる

  • UNTIL

    • 要らない。終了日で表現すればいい、二重に持つのはややこしい

  • COUNT

    • 要らない。仮に「毎週火曜 全5回」とかの予定があっても、普通は最終日を意識するし、終了日を指定すればいい

というわけで棚卸しした結果こうなる。

FREQ 繰り返し条件 WEEKLY MONTHLY
BYMONTHDAY 月の日付指定 × ○
BYDAY 曜日指定 ○ ×
INTERVAL 間隔 ○ ○
  • 毎日 (開始 - 終了日の範囲指定)
  • 毎週 x曜日、2(3, 4・・・)週ごとの x曜日
  • 毎月 x日、2(3, 4・・・)ヶ月ごとの x日

これだけ表現できれば大抵の予定はカバーできるだろう。

SourceTreeアップデート(しても大差なし)

つれづれ

SourceTreeダウングレードしたかったが、する時間などもちろん無く、その間にバージョンアップ通知が来たのでバージョンアップしてみる。現在は1.9.6.1。

ツリー表示は復活して見やすくはなったが、フォルダ内のファイル全選択ができないのでポチポチ選択しないといけないのは変わり無し。
あと重くなったのはPC自体のせい？　常時起動しているわけではないからいいけど、もう少し何とかして欲しいところ。