どうも。
「最近会社にプライベートを蹂躙されている感が否めない」
でお馴染みの
s
m
d
です。(s^m^)d
ギョ、っとした記事を見つけた。
NHK、「テレビあるけどNHK見てない」などと受信契約を結ばぬ一般家庭を提訴
テレビを設置しているのに受信契約を結んでいないとして、
ＮＨＫは１６日、東京都内の５世帯に対し、それぞれ受信契約の締結と、
衛星放送分を含む２カ月分の受信料４５８０円の支払いを求める訴訟を、東京簡裁に起こした。
http://blog.livedoor.jp/dqnplus/archives/1677370.html
なん、、、だと、、、？
あなたの周りには、受信料を支払っている人間がどれくらいいますか？
僕の周りにはほとんどいません。
でも、ほとんどの家庭にはテレビがあるし、放送法でいうところの支払い義務は発生するんでしょう？
一体この5世帯は何をやらかしたんだか。。
ちなみに、こんな記事を見た。
Q. 受信料の支払いは義務？
A. 放送法第６４条に「ＮＨＫの放送を受信することができるテレビをお持ちの場合、ＮＨＫと受信契約をしなければならない」との規定があり、
放送法に基づき総務大臣の許可を得て定められた日本放送協会放送受信規約で「受信料を支払わなければならない」と義務づけられています。
したがって、ＮＨＫの放送を受信できるテレビが設置されていれば、受信契約を結んでいただき、受信料を支払っていただくことになります。
http://pid.nhk.or.jp/jushinryo/know/qa.html#q4
でもね、放送法には
（受信契約及び受信料）第64条
協会の放送を受信することのできる受信設備を設置した者は、
協会とその放送の受信についての契約をしなければならない。
ただし、放送の受信を目的としない受信設備又はラジオ放送
（音声その他の音響を送る放送であつて、テレビジョン放送及び多重放送に該当しないものをいう。第126条第１項において同じ。）
若しくは多重放送に限り受信することのできる受信設備のみを設置した者については、この限りでない。
http://www.houko.com/00/01/S25/132.HTM#s3.6
要するに「NHK見ない」場合は支払い義務は発生しないはずだ。
先の5世帯はここを押していればよかったんじゃないかな？
今後の動向が気になりますね。
僕は学生の頃、寮生活を謳歌していたんですが、NHKが寮にやってきて
「全体説明会」なるものを実施すると申してきました。
何を「説明」するのか興味があったので(冷やかしじゃないよ！ほんとだよ！)、僕は参加を試みるのでした。
しかしまぁ蓋を開けてみればただのNHK受信料の使い道のお話、だけ。
要約すると「寮でテレビ設置してるということは受信料を支払う義務があります！ほらほら払ってね！」です。
その場で契約書を書いていた人間もちらほらとはいましたが、
僕は急にお腹が痛くなったので契約したい一心をグッとこらえて自室に戻るのでした。
学生寮なんだから「寮(という世帯)」で契約して「受信料を分割して引き落とす」とかならまだ理解はできる。
が、なぜ「部屋単位」で契約が必要なのか？それが理解できない。
それともなにか。
「テレビ(=テレビ受信ができる装置)」があることイコール契約が必要なのか？
だとするとテレビ2台所有していたら2契約必要なの？
と思ったら、こう書かれていた。
ただし、受信契約は世帯単位となりますので、一般の家庭でテレビの視聴が可能なパソコン、
あるいはテレビ付き携帯電話を含めて、複数台のテレビを所有している場合に必要な受信契約は１件となります。
http://pid.nhk.or.jp/jushinryo/know/qa.html
テレビ視聴が可能なパソコン、テレビ付き携帯電話、アウトなんだね。
ちなみに我が家にはテレビがありません。引越しの際に友達にあげたから。
引越しをして以来、一度も集金に来られた事はないからさ。
もう集金のシステムはなくなったとばかり思っていたよ。
というかスクランブル方式にしなよNHKさん。乙。
お客さんに「とある機能が利用できません。」と調査依頼されました。
「○○○○年○○月○○日」のフィールドを 年/月/日 それぞれプルダウンで選択し、
値をポストしても機能が動かないとのこと。
色々とハマってしまい、冷静になって解決できたので議事録として残しておきます。
上記年月日のデータは、システム側でjava.sql.Timestampクラスに変換していました。
以下に簡単なテストクラスを用意します。
非常にシンプルなクラスです。
で、java.sql.TimestampクラスのvalueOfメソッドですが、javadocではjdk1.6と1.5でそれぞれ以下のように記述されています。
jdk1.6
例外: IllegalArgumentException - 指定された引数が yyyy-mm-dd hh:mm:ss[.f...] 形式ではない場合
jdk1.5
例外: IllegalArgumentException - 指定された引数が yyyy-mm-dd hh:mm:ss.fffffffff 形式ではない場合
小数点以下の秒数の取り扱いに違いはあれど、それ以外の値は同一のチェックのように見えます。
次にこのクラスを実行してみます。このとき、パラメータは "2011-1-23 12:34:56" とします。
C:\>"C:\Program Files\Java\jdk1.6.0_23\bin\javac.exe" TestTimestamp.java
C:\>"C:\Program Files\Java\jdk1.6.0_23\bin\java.exe" TestTimestamp "2011-1-23 12:34:56"
java.lang.IllegalArgumentException: Timestamp format must be yyyy-mm-dd hh:mm:ss[.fffffffff]
at java.sql.Timestamp.valueOf(Timestamp.java:194)
at TestTimestamp.main(TestTimestamp.java:8)
C:\>"C:\Program Files\Java\jdk1.5.0_11\bin\javac.exe" TestTimestamp.java
C:\>"C:\Program Files\Java\jdk1.5.0_11\bin\java.exe" TestTimestamp "2011-1-23 12:34:56"
2011-01-23 12:34:56.0
jdk1.6の場合、IllegalArgumentExceptionが出ました。
月の部分がmmのフォーマットになっていないためです。
でも、1.5の場合では実行できています。
1.5のチェックが甘いというか、親切心で補完してくれているとでもいうのか。
いずれにせよドキュメントに書かれた事には違反しています。
(ビルドバージョンまで関係しているかもしれませんが、調べてないよ。)
実はこのお客さん、数年前にサーバを新調し、色々とミドルウェアを新しくしていました。
あまり使わない機能だったため、今まで発覚しなかったようです。
回避策としては「年月日のパラメータ生成は必ずフォーマットと一致するように補完する」とかかい？
いやはや。なんともダサいシステムです。
お客さんに説明しづれぇなぁ。
「○○○○年○○月○○日」のフィールドを 年/月/日 それぞれプルダウンで選択し、
値をポストしても機能が動かないとのこと。
色々とハマってしまい、冷静になって解決できたので議事録として残しておきます。
上記年月日のデータは、システム側でjava.sql.Timestampクラスに変換していました。
以下に簡単なテストクラスを用意します。
import java.sql.Timestamp;
/**
* java.sql.Timestampクラスのバージョンによる振る舞い確認クラス
*
* @author smdbanana
*/
public class TestTimestamp {
public static void main(String[] args) {
try {
// 第一引数を利用してインスタンスをつくる
Timestamp ts = Timestamp.valueOf(args[0]);
// 標準出力
System.out.println(ts.toString());
}
catch (Exception e) {
// とりあえずprintStackTrace
e.printStackTrace();
}
}
}
非常にシンプルなクラスです。
で、java.sql.TimestampクラスのvalueOfメソッドですが、javadocではjdk1.6と1.5でそれぞれ以下のように記述されています。
jdk1.6
例外: IllegalArgumentException - 指定された引数が yyyy-mm-dd hh:mm:ss[.f...] 形式ではない場合
jdk1.5
例外: IllegalArgumentException - 指定された引数が yyyy-mm-dd hh:mm:ss.fffffffff 形式ではない場合
小数点以下の秒数の取り扱いに違いはあれど、それ以外の値は同一のチェックのように見えます。
次にこのクラスを実行してみます。このとき、パラメータは "2011-1-23 12:34:56" とします。
C:\>"C:\Program Files\Java\jdk1.6.0_23\bin\javac.exe" TestTimestamp.java
C:\>"C:\Program Files\Java\jdk1.6.0_23\bin\java.exe" TestTimestamp "2011-1-23 12:34:56"
java.lang.IllegalArgumentException: Timestamp format must be yyyy-mm-dd hh:mm:ss[.fffffffff]
at java.sql.Timestamp.valueOf(Timestamp.java:194)
at TestTimestamp.main(TestTimestamp.java:8)
C:\>"C:\Program Files\Java\jdk1.5.0_11\bin\javac.exe" TestTimestamp.java
C:\>"C:\Program Files\Java\jdk1.5.0_11\bin\java.exe" TestTimestamp "2011-1-23 12:34:56"
2011-01-23 12:34:56.0
jdk1.6の場合、IllegalArgumentExceptionが出ました。
月の部分がmmのフォーマットになっていないためです。
でも、1.5の場合では実行できています。
1.5のチェックが甘いというか、親切心で補完してくれているとでもいうのか。
いずれにせよドキュメントに書かれた事には違反しています。
(ビルドバージョンまで関係しているかもしれませんが、調べてないよ。)
実はこのお客さん、数年前にサーバを新調し、色々とミドルウェアを新しくしていました。
あまり使わない機能だったため、今まで発覚しなかったようです。
回避策としては「年月日のパラメータ生成は必ずフォーマットと一致するように補完する」とかかい？
いやはや。なんともダサいシステムです。
お客さんに説明しづれぇなぁ。
どうも。
「具合が悪い時ほどヒキがいいのはデフォ」
でお馴染みの
s
m
d
です。(s^m^)d
昨日は夜中に仕事をしながら平太の生放送を見ていたらいつの間にか朝になっていた。
当然仕事は全然進んでなくて愕然としたわけです。
「ながら作業」は効率悪くてよろしくないね。まぁ休日返上でやってるからいいんだけど。
それにしても平太は面白いﾅｰ。
さて、原稿の仕事が一向に終わる気配がなかった僕は現実逃避にホールに向かうのでした。
薬局に行くついでに魔がさしたのはここだけの秘密だ。
まさかあの時点であんな展開になるとは思わなかったんだ。
番長2、導入からそろそろ3週間になろうかというのに、客付きがとんでもないですね。
常に入れ替わり立ち替わり席が埋まってる印象です。
どこぞのお店ではワンフロアすべて番長で埋めたﾂﾜﾓﾉもいるとか。
確かに継承と進化をしっかりと固めている感はあります。
10tの期待度がやや落ちたかな、という印象は否めないけどね。
4号機番長が大好きだった僕らはいいカモのようですな。
僕自身は初代の方はとても相性がよく、ゾーン狙いだけで結構勝てていました。
「番長甘いわ(^p^)」
なんて言って友達に呆れられていたのはいい思い出です。
ここからちょっと脱線。昔話入ります。
4号機番長で、昔ういちが提唱した狙い方
「Bモード狙って鮪一本釣り(だったかな？)」
てのがあってね、どういうことかと言うと
1. Bのゾーンで連してる(Bの当選は7/8でREGなのでそれも加味)台を狙う。
2. そこでボーナスを当てるんだけど、次のテーブルもBに残るように祈る。(Bからは天国に行きやすい)
3. 次回もBの状態でボーナス中に1G連させれば、次テーブル(Bモード)を参照して青BIGが選択されやすい。(赤:青の比率は1:3)
4. 青BIGの1G連を頑張る！
みたいな感じ。
そもそもBからは天国行きやすいし、BではほぼREGがくるから1G連が難しい。
そんな無茶な打法ねーよ、と思っていたんだけど、1回だけその機会に出会えたんだ。
A→B→Bみたいな推移をしている中ハマリ台を打ち始めて、案の定REG当選。
この時は上記の狙い方で打ち始めたのではなく、天国移行狙いだったんだが…
REG中にJACハズレ。はずれたっす～。
1G連で出ていたBIGは、、青BIG。
天国モードに移行していたら35%で青が出るので、この時点では天国に移行したものだと思っていた。
その青BIGで再度1G連。スベリベルおいしいです。
1G連で出てきたBIGはまたしても青BIG。
ここで、ういちのあの言葉を思い出す。「(ま、鮪だー)」と。
その日はそれなりにヒキが強かったんだと思う。結局青BIGのみ8回1G連したのだった。
1時間もせずに3k枚強を出し、128を抜けてサッとヤメた僕がそこにいた。
嗚呼、懐かしいね。
脱線終わり。
薬局を出て、帰路を行く。
「いや、いや、待てよ。うーん。ほんのちょっとだけケロットを打とう。」
と思ってホールに入ったわけだけど、一応、一応番長のシマを覗いてみる。
時間は11:30。
10台ある番長は、2台空いていた。
ART2回の89Gヤメの台。ART0回の159Gヤメの台。
僕は後者の台に座っていた。ケロット？なにそれおいｓ(ry。
僕はこれまで番長2を6回打った。
5k以内の負けが2回。
10k以内の負けが3回。
14kの勝ちが1回。
うん。つまり負けているってことだね。
6回打って、フリーズを2回引いてるんだけど、うち1回は負けてるからね。
勝ちのイメージが掴めなかったんだ。
(そのホールで万枚超えは何回も見てるのでベタピンということはありえないと思う、と思う。)
まぁ、据え置きかもしれない159Gヤメの台をスタートしてみたわけだけど、
これが220G位にゾーン臭いざわつきから特訓→対決→負け。
どうやらリセットのようです。
ヤメないとどこまで連れて行かれるかわからない、恐ろしい子！
投資は3kだし、大人しく帰ろうと思ったわけです。
残り少ないメダルを消化しようと適当にやっていたら、
256G スイカ
257G 強チェリー
258G チャンス9枚
ｳﾎｯ なんだこのヒキは。。もうちょっと様子みるか、、、
259G
フリーズ。DDTしてみたらチャンス目だったから、このゲームでの当選なんだね？
謎のヒキ。店長△。
3kでフリーズなら十分だろう。500枚だろうと何だろうと流して帰ってやろう、とね、
考えたわけですよ。
これまで2回フリーズを引いた、と先ほど申したわけですが、
1回目のフリーズでは一撃1700枚(超番長中に60G上乗せでのスタート)
2回目のフリーズでは一撃900枚(超番長中に30G上乗せでのスタート)
とね。この実績からだと「へたすりゃ500枚」なんて十分考えられるわけですよ。
だが、今日の超番長ボーナスは元気があったんです。
赤30G、青50G、赤50G、計130G乗せ。
180Gからの頂RUSHでございます。
データを取っていないのでこれ以外の情報は曖昧。
覚えていることは
・赤ボーナスで210G継続が1回(それ以外はほとんど60か90)。
・絶頂RUSHに1回だけ当選(10G+6Gで合計210G上乗せ)。
・ART当選は15回。内訳は多分、赤7青1黒7。
・ART最終ゲームでチャンス9枚→通常画面に戻ってレバーオンで画面割れからボーナス当選→再度頂突入(50G)
・1つの小役での最大上乗せは弱チェリーでの
こんな感じでした。
頂を抜けた後、30G程回してヤメ。
一撃1900G位。6137枚。
十分すぎる勝ち。
それにしてもしんどかった。
フリーズと絶頂がキモだな、あの台は。
前に隣のお姉さん(謎の美人)が9k枚出していた時も絶頂でガンガン上乗せしていたし、
そのホールの最高記録180k枚出ていた時も絶頂で700G位を一撃で上乗せしていたらしい。
多分僕はもう番長2を打つことはないでしょう←
そして、当然ながら仕事(原稿)はこれっぽっちも進んでいません。
まぁ、締め切りには間に合いますよ。
この日記も「文章を書く」リハビリにはなったしね。
では。また。
Android携帯からの投稿
「具合が悪い時ほどヒキがいいのはデフォ」
でお馴染みの
s
m
d
です。(s^m^)d
昨日は夜中に仕事をしながら平太の生放送を見ていたらいつの間にか朝になっていた。
当然仕事は全然進んでなくて愕然としたわけです。
「ながら作業」は効率悪くてよろしくないね。まぁ休日返上でやってるからいいんだけど。
それにしても平太は面白いﾅｰ。
さて、原稿の仕事が一向に終わる気配がなかった僕は現実逃避にホールに向かうのでした。
まさかあの時点であんな展開になるとは思わなかったんだ。
番長2、導入からそろそろ3週間になろうかというのに、客付きがとんでもないですね。
常に入れ替わり立ち替わり席が埋まってる印象です。
どこぞのお店ではワンフロアすべて番長で埋めたﾂﾜﾓﾉもいるとか。
確かに継承と進化をしっかりと固めている感はあります。
10tの期待度がやや落ちたかな、という印象は否めないけどね。
4号機番長が大好きだった僕らはいいカモのようですな。
僕自身は初代の方はとても相性がよく、ゾーン狙いだけで結構勝てていました。
「番長甘いわ(^p^)」
なんて言って友達に呆れられていたのはいい思い出です。
ここからちょっと脱線。昔話入ります。
4号機番長で、昔ういちが提唱した狙い方
「Bモード狙って鮪一本釣り(だったかな？)」
てのがあってね、どういうことかと言うと
1. Bのゾーンで連してる(Bの当選は7/8でREGなのでそれも加味)台を狙う。
2. そこでボーナスを当てるんだけど、次のテーブルもBに残るように祈る。(Bからは天国に行きやすい)
3. 次回もBの状態でボーナス中に1G連させれば、次テーブル(Bモード)を参照して青BIGが選択されやすい。(赤:青の比率は1:3)
4. 青BIGの1G連を頑張る！
みたいな感じ。
そもそもBからは天国行きやすいし、BではほぼREGがくるから1G連が難しい。
そんな無茶な打法ねーよ、と思っていたんだけど、1回だけその機会に出会えたんだ。
A→B→Bみたいな推移をしている中ハマリ台を打ち始めて、案の定REG当選。
この時は上記の狙い方で打ち始めたのではなく、天国移行狙いだったんだが…
REG中にJACハズレ。はずれたっす～。
1G連で出ていたBIGは、、青BIG。
天国モードに移行していたら35%で青が出るので、この時点では天国に移行したものだと思っていた。
その青BIGで再度1G連。スベリベルおいしいです。
1G連で出てきたBIGはまたしても青BIG。
ここで、ういちのあの言葉を思い出す。「(ま、鮪だー)」と。
その日はそれなりにヒキが強かったんだと思う。結局青BIGのみ8回1G連したのだった。
1時間もせずに3k枚強を出し、128を抜けてサッとヤメた僕がそこにいた。
嗚呼、懐かしいね。
脱線終わり。
薬局を出て、帰路を行く。
「いや、いや、待てよ。うーん。ほんのちょっとだけケロットを打とう。」
と思ってホールに入ったわけだけど、一応、一応番長のシマを覗いてみる。
時間は11:30。
10台ある番長は、2台空いていた。
ART2回の89Gヤメの台。ART0回の159Gヤメの台。
僕は後者の台に座っていた。ケロット？なにそれおいｓ(ry。
僕はこれまで番長2を6回打った。
5k以内の負けが2回。
10k以内の負けが3回。
14kの勝ちが1回。
うん。つまり負けているってことだね。
6回打って、フリーズを2回引いてるんだけど、うち1回は負けてるからね。
勝ちのイメージが掴めなかったんだ。
(そのホールで万枚超えは何回も見てるのでベタピンということはありえないと思う、と思う。)
まぁ、据え置きかもしれない159Gヤメの台をスタートしてみたわけだけど、
これが220G位にゾーン臭いざわつきから特訓→対決→負け。
どうやらリセットのようです。
ヤメないとどこまで連れて行かれるかわからない、恐ろしい子！
投資は3kだし、大人しく帰ろうと思ったわけです。
残り少ないメダルを消化しようと適当にやっていたら、
256G スイカ
257G 強チェリー
258G チャンス9枚
ｳﾎｯ なんだこのヒキは。。もうちょっと様子みるか、、、
259G
フリーズ。DDTしてみたらチャンス目だったから、このゲームでの当選なんだね？
謎のヒキ。店長△。
3kでフリーズなら十分だろう。500枚だろうと何だろうと流して帰ってやろう、とね、
考えたわけですよ。
これまで2回フリーズを引いた、と先ほど申したわけですが、
1回目のフリーズでは一撃1700枚(超番長中に60G上乗せでのスタート)
2回目のフリーズでは一撃900枚(超番長中に30G上乗せでのスタート)
とね。この実績からだと「へたすりゃ500枚」なんて十分考えられるわけですよ。
だが、今日の超番長ボーナスは元気があったんです。
赤30G、青50G、赤50G、計130G乗せ。
180Gからの頂RUSHでございます。
データを取っていないのでこれ以外の情報は曖昧。
覚えていることは
・赤ボーナスで210G継続が1回(それ以外はほとんど60か90)。
・絶頂RUSHに1回だけ当選(10G+6Gで合計210G上乗せ)。
・ART当選は15回。内訳は多分、赤7青1黒7。
・ART最終ゲームでチャンス9枚→通常画面に戻ってレバーオンで画面割れからボーナス当選→再度頂突入(50G)
・1つの小役での最大上乗せは弱チェリーでの
こんな感じでした。
頂を抜けた後、30G程回してヤメ。
一撃1900G位。6137枚。
十分すぎる勝ち。
それにしてもしんどかった。
フリーズと絶頂がキモだな、あの台は。
前に隣のお姉さん(謎の美人)が9k枚出していた時も絶頂でガンガン上乗せしていたし、
そのホールの最高記録180k枚出ていた時も絶頂で700G位を一撃で上乗せしていたらしい。
多分僕はもう番長2を打つことはないでしょう←
そして、当然ながら仕事(原稿)はこれっぽっちも進んでいません。
まぁ、締め切りには間に合いますよ。
この日記も「文章を書く」リハビリにはなったしね。
では。また。
Android携帯からの投稿