手回しお湯沸かし器

作る為にはどういった感じで考慮する必要があるかなぁと思って、まずは計算してみまし
た。

1kW(1000W)は860kcal/hとします。

1Lの水を1℃温度を上げるのに必要なカロリーが1kcal

20℃の水300ccを90℃に上げる必要のあるカロリーの計算を行う。
水1Lを20℃から90度に上げるのに必要なカロリーは(90-20)=70Kcalとなる。
水は300ccなので、70Kcal×300÷1000=21Kcal

5Vの手回し発電機でお湯を沸かす場合
取り出せる電流量が2Aとした場合、5V×2A=10Wh
（1分間に120～180回転)

10Wh=86kcal/h

必要な熱量は21kcalなので、90℃になるまでに必要な時間は86/21≒15分

100ccあたり5分掛かる感じでしょうか。

ソーラークラッカーとどっちが早いのかなぁ？　っていう感じでしょうねｗ

テレビ設置アパートでも受信料 NHK返金訴訟、岡山地裁が棄却

記事：
テレビ設置アパートでも受信料　NHK返金訴訟、岡山地裁が棄却


この記事なんですがね。
おかしくね？岡山地裁さんよ、っていうものです。

１．入居したらＴＶが付いていた
２．ＮＨＫと受信料契約をした。
３．退去した。
４．ＮＨＫと受信料契約を解約しようとした。
５．ＴＶを処分していないので解約できないと断られた。
６．裁判はＮＨＫ側の主張を認めた。

おかしいよね。
「設置者から権利を譲渡されたり、承諾を得たりして、設備を占有使用して放送を受信で
きる環境にある者も含まれる」
と言ってますが、退去したらこれに該当しなくなりますよね？

記事の書き方がおかしいのかどうか分かりませんが、なんか変だし……記事どおりなら、
同じ受信装置に対して複数の契約者が存在することになります。

ワンセグ受信料の問題点

ネットでも受信料を徴収すると言う新たな問題点が浮上しつつある中、その前段階としてワンセグも受信料が必要だと言う判決が再び出ました。

まず、議論の前段階に抑えておきたいのは、ＮＨＫのラジオです。

ＮＨＫはラジオでもかつては受信料を取っていましたが、現在では取っておりません。

背景を考えるに、ＴＶの普及にあわせて受信料を取らなくなったんだろうと言う予測があります。

もう一つ抑えておくのは、「設置」の法文の意味です。

ワンセグなどの移動端末については、「設置」に当たらないというのが裁判所の判決でしたが、それが覆った形です。

総務省の怠慢とかいろいろありますが、当初の「移動受信用地上基幹放」という形で法文に登場する「設置」とは別扱いになっていた点があります。

十四　「移動受信用地上基幹放送」とは、自動車その他の陸上を移動するものに設置して使用し、又は携帯して使用するための受信設備により受信されることを目的とする基幹放送であつて、衛星基幹放送以外のものをいう。

カーナビのＴＶ受信機能がそれに該当しますが、わざわざ別扱いにしてるのに「携帯のワンセグ」を家の放送設備と同じ「設置」に含めないというのが当初の裁判所の判決であり、含めるとしたのが現在の裁判所の見解です。

個人的には、裁判所やＮＨＫが決める話ではなく、総務省が「契約の対象とするかどうか」をキチンと精査して法文を改定する話じゃないのか？って思いますが。

今回の判決により、ドコモなどの携帯会社も困惑しているようです。

そりゃそうでしょうね。単身赴任した場合、赴任先でＴＶを所持している場合は別途契約（割引はされているようですが）する必要がありますが、ワンセグの場合は「場所」を選びません。

国内において何処でも受信できなければ、放送法を協会が順守していないと言う問題もあります。

それだけでなく、法人の場合は受信設備の台数で受信料金が変わってきます。

ワンセグ機能のある製品は何も携帯電話だけでなく、ポータブルＤＶＤやカーナビなど複数存在する為、今回の調査結果で各法人は追加で受信料を支払う必要が出てきます。

デジタルフォトフレームにすら、ワンセグ機能がついたものがあるのです。

それを考え問題点を纏めると、以下の通り。

１．住民票の住所にて受信料契約が基準になるのであれば、生活住所が違う場合は別途契約を結ぶ必要がなくなるのではないか？

単身赴任者や子供が大学などで下宿などを行う場合、住民票を移さないケースは多々ある。旧来は下宿先の賃貸で別途ＮＨＫの受信料金契約を行っていたが、この判決を考慮すれば、住民票の住所にて契約していれば、別途契約する義務はないとなるのではないか？

２．住所を必要としない移動端末について放送法一条の「放送が国民に最大限に普及されて、その効用をもたらすことを保障すること。」という部分をどのように保障するのか？　トンネル内や地下も含まれるが、放送法の受信可能地域は１００％ではない。フェリーなどの海上移動中なども受信することはできないのが現状である。理屈と実態があっていないのが実情であり、移動端末を対象とするのであれば、率くと実態をあわせる義務がＮＨＫには生じる。

３．スーパーや展示会などで使用されるデジタルフォトフレームやポータブル装置は原則ワンセグ受信などしない。しかし、受信の有無や装置の目的の有無ではなく機能の有無を基準とする場合、前述だけでなく家電量販店や携帯電話の契約店などが保有する台数分、受信料契約を結ばなければならない結果となる。同じ条文に対して、個人と法人で解釈を変える「これはこれ、それはそれ」は存在しない以上、すべからく公平に受信料を徴収することになるのではないか？

以上の三点だけでなく、ＮＨＫの暴走は止まりません。

インターネットの回線にまで踏み込もうとしています。

インターネット回線でネットワークとつながることが出来る端末として代表なのは、当然パソコンでしょう。

個人のパソコンだけでなく、法人でネットワークに繫いでいるパソコンなど無数に存在します。

これが現実となった場合、一つの法人でＮＨＫへの受信料契約として毎月換算で１００万円以上の支払が必要になるというところがごろごろ出ます。

ホテルの契約だけであれほどもめているのです。

ＮＨＫと言う組織は、あらゆる法人と個人を敵に回すつもりなのでしょうか？

なお、日本消費者協会の考えとしては、ＮＨＫに対して受信料については基本料金を設定し、視聴時間に合わせて利用料金を支払ういわゆるスクランブル化を求めているようです。

記事：二審もワンセグ携帯に受信料支払い義務　東京高裁判決

記事：5Gから楽天対策、ワンセグ受信料、ドコモダケの行方まで――ドコモ株主総会で語られたこと

記事：日本消費者教会　最高判決からＮＨＫ受信料を考える。

【報道しない自由？】東シナ海で流出した油の行き先

鹿児島県の宝島に「油のようなもの」漂着、沈没タンカーから流出か

このような記事がネットをにぎわせているようです。

さて、これで懸念されているのが
「3週間ほど前に日本の排他的経済水域（EEZ）内で沈没したタンカーから流出した油」
です。

これに対する日本側の対応と見解については、下記の記事が参考になるでしょうか？

沈没タンカーから油　日中海洋当局が対応



日本側対応は、「海保が油を揮発させるために船を走らせ拡散」で回収していません。
記事にある教授は「気体のものを液化している。火災で大半が燃えたか気化してしまった可能性が高い。沿岸から離れた場所なら影響は考えにくい」としています。

日本側の対応にも疑問も持ちますが、中国側は事故によって流出した油の回収や処理に対して、何らアクションを見せていないのも気になります。
事故起こしても責任を取らないのであれば、航路と使用させるな、と思うんですがね。

ちなみに、衝突した場所（中国圏内）と沈没した場所（日本圏内）は違います。つまり、事故は中国で起こり、日本圏内まで誘導した後に沈没させたんですよね。
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgeJGtxi8Im1CpkS23MHRizGHfc4pl4a1bd94t0NuBhR22zlMh0OVFzLTouTmKltIIpzcb9ednlHks0fjEgwK2T-R6WJUsjsJvw_53o6e4JmZhLtktxWmeUrlXXx1G8ZmFVjV-mvlYibMg/s1600/20.jpg

これに抗議しない外務省って、どういうことなんでしょうかね？
使用済み核燃料を黄河河口に投棄して中国は起こらないのでしょうか？問題にしないのでしょうか？
今回、それと同じようなことをされたわけですが、怒らない時点で非常に問題なんですがね。

【Windows】会社のパソコンが遅くなった【Update】

表題どおりです。

記事：【Excel】二重取り消し線の取得/設定が出来ない＆下線のスタイルで破線・波線などの特殊線が取得/設定出来ない！【VBA】

で、非常に重くなった件とも関連すると考慮しております。

今まで特にストレスを感じていなかった処理が、非常にストレスを感じるレベル（「応答なし」というフリーズするようになった！？　と言うレベル）に変化しました。

会社のパソコンですから、特に不要なソフトウェアはインストールしておらず、３日前と本日とで違う点としては、Windows　Updateか！？　でも、アップデートで遅くなるようなことは？

記事：ウィンドウズＰＣ、ＣＰＵの脆弱性対応で動作速度に影響

どうにも、このあたりのアップデートが原因のようです。

タイムリーに言えば、ＣＰＵ関連のバグは発見されたと言う記事を思い出します。

このバグ修正を行うと、ＣＰＵの能力が３割落ちる、だったかな？

車だったら、リコールの対象になるレベルだと考慮いたしますが、パソコン業界には「リコール」がないんでしょうか？（あるけどやらないだけかなぁ）

ソフト的な部分じゃなく、ハード的な部分らしいので、対応するためにはＣＰＵを交換する必要があるんでしょうが、、、

交換するとなると、Intelは倒産するだろうなぁってレベルかなぁ。

問題となるのがWindows10より前のOSが殆どらしいので、Windows10（プロフェショナル版とかウルティメイト版？とか）への無料アップデートとかの方が、まだ現実的かもしれませんね。

本当に「この問題にぶち当たった」とはっきりいえませんが、確かエクセルのマクロなどは、その速度はＣＰＵに依存する（マルチタクス処理ではないので、２０１０年以前の物はマルチコア系のＣＰＵの恩恵は受けなかったと記憶しています）

マルチスレッド化にして処理してやれば早くなるのか、それとも変わらないのか？

それは分かりませんが、

今後の検討課題として一通り仕上げた後に試しても良いかもしれません。

【Excel】二重取り消し線の設定【オートシェイプ】

エクセルで二重取り消し線を使用したい、という人はちらほらいるようで、ネットで検索するとその質問や方法についてヒットしますが、

一律でいうなら「二重取り消し線は使用できない」というものです。

セルの書式設定を見ても、取り消し線はあるものの二重取り消し線はありません。

方法として紹介されている物は、オートシェイプの直線を二重線に変更して取り消したい文字列の上に重ねると言う方法です。

ネットでは殆どヒットしなかった、エクセルで二重取り消し線を使用する方法として、

オートシェイプ（図形）のテキスト挿入機能を利用する方法があります。

セル内のテキストに対するフォント装飾で二重取り消し線の設定は出来ませんでしたが、

オートシェイプのテキストに対してフォントプロパティを開くと下図のとおり二重取り消し線する設定ができます。

メリット

・印刷時に＝線の位置とセル内の打ち消したい文字の位置がずれる問題を回避することが出来る。

デメリット

・オートシェイプの値をセルに入力したり参照するにはＶＢＡを利用するしかない。

（数式や関数で参照する方法が見つからなかった）

・印刷時にオートシェイプの位置が表示とずれる場合がある。

ぱっと思いつく感じはこんなものです。

【Excel】VBA マクロでオートシェイプ内の上付き文字を設定しても反映されない問題。【VBA】

VBAでフォントの装飾を変更するコードを書いていたのですが、どうにも摩訶不思議な現象に遭遇しました。

エクセルを使用している方なら経験があると存じますが、セルに対して装飾を施すことが出来ます。

セル内の文字列を個別に対象にすることもでき、それをVBAで装飾を施す場合

　Range(セル情報の位置["A1"]).Characters(開始位置,文字数).Font.Superscript = True

こんな感じです。

オートシェイプの文字列もセルと同様のことができますので、VBAでやろうとしたのですが、なぜか反映しないという事象が発生しました。

（例：Aというオートシェープの文字をBというオートシェイプに装飾含めてコピーするというコード）

コートで書くと下記の通り。（上付き文字）

A.TextFrame.Characters(開始位置,文字数).Font.Superscript = B.TextFrame.Characters(開始位置,文字数).Font.Superscript

図にあるとおり、下付き文字と打ち消し線は問題なくできるという不思議状況です。

コピー元Bの上付き状態を(IF)で判定する分には問題なく取得できます。

なので

If B.TextFrame.Characters(開始位置,文字数).Font.Superscript = True Then

A.TextFrame.Characters(開始位置,文字数).Font.Superscript = True

　End If

と言うコードに変えてやったのですが、コピー先の「A.TextFrame.Characters(開始位置,文字数).Font.Superscript」はFalseのままという状況です。

Excelの2002及び2003では、正しく取得できないと言う問題があるようですが、2013ではSuperscriptだけが直っていない状況のままなのでしょうか？

Excel 2003 および Excel 2002 でオートシェイプに入力されている文字の正しいプロパティ情報が取得できない

取得は問題なく出来るんだけどなー。

結論を言えば、「True」を「msoTrue」に変更したことで問題を回避することが出来ました。

If B.TextFrame.Characters(開始位置,文字数).Font.Superscript = True Then

A.TextFrame.Characters(開始位置,文字数).Font.Superscript = msoTrue

　End If

ただ、これは明らかに「バグ」だよなぁ。