続、NHKを解約手続き。書類キター(とっくの昔に)

窓口に電話してから早一ヶ月、返信用書類はとっくの昔に届いてましたが、すっかり忘れてました。

封筒の中身。返信用封筒と、書類が入ってます。必要事項、は自分の名前を直筆＆捺印するだけの簡単なお仕事です。


届いた封筒では、書類は3つ折りに入ってますが、そのままでは返信用封筒に入りません。もちろん4つ折にすれば入りますが、ンンンン？と思わないでもない。



と言う訳で出します。

TBSオフィシャルSASUKEサイト閉鎖 ※と思ったらドメインが変わってるだけだった

昔の記事を読み替えしていて、リンクをチェックしたら、SASUKEのオフィシャルサイトは今年1月でドメインごと無くなってましたね。昨今の形骸化っぷりを見れば、むしろ遅すぎたぐらい。

http://www.tbs.co.jp/sasuke_rising/

TBS SASUKEの競技内容を見れば、その理不尽さには目を見張ります。

瞬発力主体の第1ステージはまだ良かった。そして第2ステージ以降でも(瞬発力主体に)そうするべきだったのですよ。

第2ステージから、一転、とにかく腕の筋力を問うものに集約します。

「サーモンラダー」物干し竿にぶらさがって、体のバネだけで上の段に掛け替えろとか。



アンステーブルブリッジ



両端点でぶら下がってるだけの板、しかも逆辺に両手で捕まって移動しろとか。

あり得ません。しかもコレで腕の筋肉が消耗し尽した頃を狙って、

ジャンプで、数メートル先にぶら下がる鎖を掴め。(鎖は回ります)

素手の握力だけで、自分の体重と加速度を支えきれとか、馬鹿じゃねえのかと。

第3ステージから更に理不尽に。



天井に付いてるボールをつかんで懸垂しろとか。

これって、ただ「棒を掴め」とは訳が違います。指の筋力を効率的に消耗するように考えられてる。

端的に言えば、全ての障害がイイ感じに、筋力を消耗させるように出来てる。TBSの思惑としては「君は今までよくやってくれた、さあこの辺りで落ちてくれ。視聴率に貢献してくれて有難う」ってことですよ。

人は○○のみで生きるにあらず

tumblrから辿ってるので、半年出遅れてます。

http://www.watanabemiki.net/journal/post-373.html

「１４年連続自殺者３万人」の国、日本

しかし、私は私の周りのカンボジアの人たちから、誰かが自殺したという話を聞いたことがない。カンボジアで自殺者がいないとは思わない。ただ、生きるのが必死の彼らが自ら命を絶とうとは考えないのではないか。何とか生き抜いてやるというエネルギーをひしひしと感じる。
日本とカンボジアを比べても仕方がないが、圧倒的に日本の方が経済的には豊かだ。しかし、１４年連続で毎年３万人以上自ら命を絶つ社会が真に豊かと言えるだろうか。我々はあまりに、無関心になってはいないか。その膨大な数に痲痺していないか。
政府のなかに内閣府自殺対策推進室がある。しかし、自殺はいっこうに減らない。３万人ひとりひとりの自殺の背景をどれだけ細かく把握しているのか。それがなければ対策も何もない。
自殺者は社会のカナリアだと思う。カナリアは坑道などでいち早く有毒ガスを検知する。「我々の社会はおかしいぞ」と自殺者の方々は、自らの命を絶って訴えているのかもしれない。

極めて自明の話なのですが、経済的な豊かさと、精神的な豊かさを混同してますね。日本は、経済的には非常に豊であると断言できます。なんだかんだと飢え死にしてる人は少ないですし、逆にニュースになっちゃうぐらいですから。

「豊かさ」というから主題が判らない。「幸せ」とでも言い換えてみれば良いでしょう。日本人のすべてが幸せだなんて誰も思うまい。そんなん無理だしね。故に、その最終段階として自殺者が出たとしても、小生は何とも思いません。もちろんそれが知人であれば、何とも思わないわけはありません。ただし、彼らが自殺などしないと信じてますがね。真の友人というのはそういうもの。

おっと「幸せ」の尺度については、小生は小生なりの結論をもってはいます。ここでの言及は控えますがね。だって言う必要ないでしょ。人それぞれなんだから。

しかして、「幸せ」を計るのに、自殺者の数を数える必要すらありません。サザエさん程度のコンテンツで「幸せを補充」してもらわなければならない。そんな日本人が結構居る状態が、既にヤバイと思います。

「期限を過ぎると、収められなくなります」

国民年金保険のことです。

小生、恥ずかしながら、「国民年金」が「保険」だとは思ってませんでした。

何年か前から、委託業者のアイヴィジットとやらが、何度となく来てたのですが、
一度も対応したことがなく、「納付」の溜まること2年分。
正直、アレ、健康保険払ってますよ？と電話したら、イヤイヤ違うと言われて。
そりゃそうなのですが。

まったく気にしたことありませんでしたが、ついでなので聞いてみました。
「納付期限から2年が経過すると時効により納付ができなくなります」

25年間だか収めないと、年金受給の資格を失うんだそうな。

納付が出来なくて誰が困るんだが、そこまで言及しなければ、フェアではない。
まさか、聞かないオマエラガ悪いとか思ってないよね。
いや思ってるかもね。それが「お役所仕事」その真骨頂ってところでしょうか。

とは言え、小生は思いました。「なあんだ、それだけ？！」

実はこの年になるまで「保険」というシステムを真面目に考えたことがなかったのですが、要するに「経済的に余裕のある(ことになってる)誰かさんが、経済的に余裕のない誰かさんを経済的に支える」というシステムなのですよね。母集団を集めなければ成り立たないシステムですよねこれ。

それに、時効→25年間に足りません→受給資格なし。という辺りが小賢しい。

納付者に払わせたいのなら逆効果でしょうコレ。

支払い期間に応じて、受給金額が増えます、っていうなら納得できる。しかしそんな約束は絶対できないわけです。受給金額はその時々で変わる。金をオアズカリシテル誰かさんの都合で。「配当金」だよね。

少子化やらなんやらで、「支える」側の人数はどんどん減って、「支えられる」側はどんどん増える。小生がその年頃になる頃には、「年金納付、月12万円」「受給額、月3万」って話になりかねません。受給金額の保障をできないのは仕方はないですけどね。

今でさえ既に、月数万円後半って話ですよ。5万円切るのも時間の問題。これ誰が助かるの？何とか生きては生けるでしょうけど、ギリギリでしょう。家賃すら払えない人も居るでしょうね。テレビの灯りだけで生活してますって話も聞きました。NHKの番組で。

ニホンノホウリツハオトシヨリヲミステマセン。
なんか、NHKの受信料に匹敵する、虚しさを感じます。

そういうことであれば、「年金を払わない」という主張もアリでしょう。否定はしませんが、納得はできます。56歳でその主張をしてるオジイサンが居ましたよ。知人に。自分で食い扶持を稼ごうって意気込みが残ってるならそうするべき。

終身雇用が崩壊してるなら、逆に、何才になっても働くことも出来るわけでしょう。理想論ですが。小生はその予定があるにはある。自営業だし。

ちなみに小生の父は「ちゃんと年金払え」派です。そしてとっくの昔に定年退職組。まあ人それぞれだからね。

OAuth 勉強中。の方々

どうも探し方が悪かったらしい。他にも似たように悩んでる人多いですね。

Oauth client initialization in python for tumblr API using Python-oauth2
http://stackoverflow.com/questions/7569018/oauth-client-initialization-in-python-for-tumblr-api-using-python-oauth2

↓の人が貼り付けたgist

https://gist.github.com/1242662

ほほう、python だと oauth/2モジュールが存在すると？そりゃそうでしょうね。
https://launchpad.net/ubuntu/+source/python-oauth2/
ホントだ。流石はubuntu。

小生の使ってるのはLinux Mintですが、mintリポジトリに無いものはubuntuリポジトリに探しにいくので、使えます。ありがたや。

OAuth 勉強中 (1) Request_Token取得まで

どれどれ。

• まずアプリケーションの申請をして、Consumer_key, Consumer_secret をもらう。
• これらの値は、Webサービス側の都合で完全に決まる。基本16進数の文字列。っぽいが。

ここからは毎度のアプリケーション起動時の操作。

• Request Token を生成してもらう。
• Webサービスの特定のURL Request token URL に、後述のパラメタ付きで投げると、oauth_token/oauth_token_secret がもらえる。
• このoauth_tokenは、次回の通信から、sha_secretの計算に付け加える。
• sha_secret =  Consumer_secret + "&" + oauth_token
• そのoauth_tokenを伴って、Web認証画面に飛ばす。authorize URLとか言う。
• Webベースアプリケーションの場合はリダイレクトで飛ばせるが、単独アプリの場合は、URLを表示して、そのページを手動で開いてもらう必要がある。
• PINを発行してもらう。
• PIN→ oauth_verifier とかに入れるのが一般的らしい

Request Tokenの生成がちょっと面倒臭い。pythonのdictっぽく書くなら。

message_org_dict={
oauth_consumer_key: Consumer_key,
#oauth_signature: シグネチャ。
oauth_signature_method=大抵 "HMAC-SHA1 ",
oauth_timestamp: time.time(),
#oauth_nonce:
#oauth_version:
}
#signatureの計算は、実は宛先URLに依存するように出来ていて
oauth_token = "";message_str = "&".join( [ "GET", url, "&".join( [ key + "=" + message_org_dict[key] for key in sorted( message_org_dict.keys() )
] ) ) ;
sha_secret = Consumer_secret + "&" + oauth_token;
signature_hex=hmac.new( sha_secret , urllib.quote(message_str,""), hashlib.sha1).digest().encode("base64").strip(); message_org_dict.update( { "oauth_signature":signature_hex } )#これで漸く通信できます。

アレ、意外と判りやすい？！もっと全然判らなかったような気がしたけど。あーそうか、Access Token とか Request Tokenとか、用語があちこちでカスってるのが判りにくかったのか。ネーミングのセンスが悪いです。劇的に。

何れにしても、必ずWebを経由しなければならないようですね。であれば、単独アプリよりは、Web Applicationの方が有利かな。Request_Tokenの要求で、自動的にリダイレクトしてもらえるようだし。

この中で、変数群のカテゴライズをするなら

• Webサービス依存
• url  :ライブラリの内部とかに保持する？
• 登録アカウント依存 :外部ファイルでjsonとかにして置く。ハードコーディングは嫌いです。
• Consumer_key
• Consumer_secret
• セッション依存: PHPであれば$_SESSIONにぶち込める
• request_token
• (oauth_verify)

そうすると、何で巷のライブラリ群って、あんなに複雑な実装になってるんだろ。

tumblrのPhoto Setをラクに使いたいのだが

小生はtumblrを使ってますが、いつの間にか追加してる機能photoset。
こいつは、複数の画像をまとめて扱える代物です。

おあつらえ向きに、解説付きの記事を挙げてくれてる人が居ました。
http://effective-tumblr.tumblr.com/post/7689044701/photoset-redux

とは言え、標準ではWebから使うしかないし、ブックマークレットでは対応してません。画像類は一旦ローカルに控えてた上でアップロードする必要があります。要するに面倒臭い。

で、tumblr API v2とやらを使えばそれが出来るらしい。
http://www.tumblr.com/docs/en/api/v2#photo-posts
でも認証形式がOAuth。

あー聞いたことあります。facebookの案件の後期でやりました。ただあの時はfacebook.phpが全部頑張っちゃったので小生は訳も判らないまま。
https://github.com/facebook/php-sdk/tree/master/src

仕方ない勉強しますか。