Lastig

初級Web系エンジニアの技術系とかもろもろのブログ

明晰夢 調べたものメモ(リンク、動画、本など)

最近明晰夢に興味を持ち始めたので、調べたものをメモしてみた。
ちなみに僕は明晰夢に絡んだオカルトとかスピリチュアルとかそういう類には興味がない。
そういった見方を否定するのも変だと思うけれど、何か未知のものが出てきたときにすぐ宇宙のエネルギーだの神様だのを持ち出す態度を僕は受け入れられない。

・How Lucid Dreaming Works
5分間でLucid Dreamingについて科学の目線から解説している動画。
普通の夢が映画を見るようなものとすると、明晰夢はゲームをしているようなものだ、という例えは非常にわかりやすい。
www.youtube.com

・Neural Correlates of Dream Lucidity Obtained from Contrasting Lucid versus Non-Lucid REM Sleep: A Combined EEG/fMRI Case Study
明晰夢の存在を科学的に証明したとされる実験。
現実で手を握る動きをしたときと、明晰夢の中で手を握る動きをしたときで、脳の血液が集中した箇所が似ていたことを根拠にしている。
academic.oup.com

・Stephen Laberge: Lucid Dreaming (excerpt)
S.ラバージ氏は明晰夢の研究者として有名。夢見の技法が代表著作。
この動画はスピリチュアル的な目線で明晰夢を解説している。
明晰夢は社会的、物理的な制約から離れることができる素晴らしい体験だというような内容、、、だと思う。
www.youtube.com


・脳と意識:夢の真実 (エハン塾)
この人もスピリチュアルな感じの方。話しが巧みで面白い。
上記のS.ラバージ氏の「夢見の技法」を取り上げている。
他の人の夢に入れる人間がいるという話がでてくる。そんな源氏物語みたいなエピソードはにわかには信じがたい。。。
www.youtube.com


インセプション (映画)
夢、潜在意識を舞台にした作品。夢の中でアイデアを実現させて奪うというストーリー。
面白そう。
www.youtube.com


・夢見の技法 -スティーブン・ラバージ- (書籍)
f:id:lazycat99:20181216121332j:plain
https://www.amazon.co.jp/明晰夢―夢見の技法-スティーヴン-ラバージ/dp/4393361199
明晰夢について詳しく解説された本。エバン氏いわく「腰が抜けるほどすごい本。本当に深い」らしい。
まだ読んだことないけど、明晰夢に興味のある人なら一度は呼んで見る価値はありそう。
結構古い本なので、書店には基本置いてないっぽい。もちろんkindleもない。古本屋かAmazonで紙の書籍で買うのがいいだろう。

CSDNで使えるプログラミング関連の中国語メモ (随時更新)

マイナーなエラー調査では英語はもちろん、最近だと中国語なら引っかかることが多いので勉強したいと思った。
とりあえず拾った中国語メモしていく。あとでカテゴリごとに整理しようと思う。


如果・・・もし〜なら

检查・・・詳しく調べること。≒検査
校验・・・検査
设为・・・設定

如果设为true・・・もし設定がtrueなら

网・・・ネット、インターネット
连接・・・接続
络连接・・・ネットワーク接続
关闭的・・・閉じた

(例文)
检查下网络连接・・・ネットワークの接続を確認すること。

数据・・・データ
数据库・・・データベース
(例文)
检查下数据库是否正常连接・・・データベースの接続が正常か確認すること。


解决办法・・・解決方法
池中的・・・プール
空闲・・予定のない、暇な
空闲进程・・・アイドルプロセス


参考になりそうなサイト

辞書的に単語を網羅してくれている
IT常用日语 - dadalan的专栏 - CSDN博客

人間が生きるのに最低どれくらいのkcalが必要なのか?考察メモ(※考察失敗)

一人暮らしをしていると、実家ぐらしと違って待っていてもご飯は出てこない。
お腹が空いたら買いに行くか料理するかしないといけないわけだが、どちらもめんどくさいななんてダメ人間的なことを思いながら、いい方法はないかとgoogle先生に浅い質問をすると、「ブレサリアン」という言葉を知った。

ブレサリアンの意味はこんな感じだ。

ブレサリアン・・・Bretharian。不食主義者。空気や太陽光だけで生きていける人のこと。またそれを目指している人。

下記のNaver記事がブレサリアンについて実例(?)付きでわかりやすくまとめてくれている。

matome.naver.jp

70年間飲まず食わすはさすがに嘘だろ。一ヶ月に一食しか食べないぐらいで抑えておけばよかったのに。
あと人間が光合成できるって論外でしょ。

全く食べずに生きていくのは無理があるとして、少し食べるだけで健康に生きていけるなら、エコだし面白いと思った。
こんなこといったら料理業界の人には怒られそうだが、少食で生きていくことで時間的にも物質的にも無駄が減るのはイケてる気がする。

なので、今回は人間が生きていくのに最低どれくらいの食べ物が必要なのか調べて考えてみた。
※本当かわからないリソースから素人が勝手に考えただけなので、もし試す人がいたとしても責任は取れません。あしからず。

最低限のカロリーとは?

よく言われる話だが、1日で必要な最低限エネルギー量は
・成人男性・・・約2000kcal
・成人女性・・・約1500kcal

※ちなみにこの値はずっと平均値だと思っていたのは内緒。最低限の値だったのか。。。

この数字は、厚生労働省が発表している「日本人の食事摂取基準」とやらがソースになっている。
www.mhlw.go.jp

「日本人の食事摂取基準(2015年版)策定検討会」 報告書 (エネルギー.pdf)
https://www.mhlw.go.jp/stf/shingi/0000041824.html


上のエネルギーについての報告書も読んでみると、厚生省の最低限カロリー算出のロジックの根拠は以下の2点っぽい。
①健康な人のBMIを目指すと健康になれるよね
②健康な人のBMIの値を維持できたら、健康だよね (摂取カロリーと消費カロリーのバランスをとる)
BMIは計算しやすいしわかりやすい指標だが、体重と身長の比率でしかないのが弱みだ。
健康の指標としてはちょっと頼りないので、それを理想値の根拠とした上記の値は信用しきれない。


ということで、よく聞く必要最低限エネルギーカロリー約2000kcal, 約1500kcalという考えは採用しないことにする。


とはいえ、摂取カロリーと消費カロリーのバランスをとる必要があるというのは正しい考え方な気がする。
次は消費カロリーから最低限の摂取カロリーを逆算してみようではないか。

消費カロリーについては、ここのサイトが読みやすくて、わかりやすい。以下引用しまくる。
www.beauty-muscle.com

消費カロリーは、大きく以下の3つに分類されるらしい。
基礎代謝 (勝手に消費される、体温維持とか内蔵動かすとか) 約60%
・生活活動代謝 (座る、歩く、走るとか) 約30%
・食事誘発性熱産生 (食べ物を消化、吸収するときに使う) 10%

上記のサイトは計算もしてくれるので、試してみたらこんな感じだった。

f:id:lazycat99:20181202200301p:plain
消費カロリー

一日に2203kcal必要らしい。でもこの計算もBMI基準なら同じ理由で信じることができないぞ。
いつのまにこんなに世の中を信じられなくなっちまったんだか。。。

基礎代謝の計算式は以下らしい。

国立健康・栄養研究所の式(Ganpule et al., 2007)
*1×1000/4.186
注)*1;男性=0.5473×1、女性=0.5473×2

体温の維持に筋肉量はかかわらないんだろうか、内蔵動かすのにかかるカロリーってどうやって計算or測定するんだろうと思いつつ、割と誤差は小さい計算式らしい。
一旦信じる心を大切にしよう。


そうすると、消費カロリーが2203kcalなら摂取カロリーも2200kcalぐらい摂ればいいのか?
しかし、2200kcal摂ったところで100%吸収されるわけがないじゃないか!

下記のサイトを調べると、食べ物の成分(糖質、脂質...)の一覧表から合計のkcalを計算するらしい。
そういえば家庭科の授業で計算させられたな。

www.asahi.com


やっぱり吸収率も計算しないといけないらしい。ということで調べると今日一番の驚きだ。

カロリーや栄養の吸収率は、食事の時間や同時に食べるものに関係なく、常にほぼ100%

テニスコート1面分の面積がある小腸の表面を通る間に、余すことなく吸収されるイメージらしい。
wp.w8eq.com


信じがたいのでサイトに書いてあるとおりに「アトウォーター係数」について調べてみる。

食品の熱量(エネルギー)について ~エネルギー換算変数の話~
http://www.jfrl.or.jp/jfrlnews/files/news_no35.pdf

f:id:lazycat99:20181202203034p:plain

やはり近似値として、90%以上は吸収されるらしい。まじかー。

このままだと、最低摂取カロリーは2200kcalになってしまう。
吉野家の牛丼624kcal × 3食でも若干足りない。美味しいけどそれはめんどくさいし、金も減る。

次のアプローチとして、現代から離れてみよう。
昔の人は病気にもなっただろうが、現代人ほどのカロリーを食べなくても健康に暮らしていた人はいるはずだ。

それでもだめなら、必殺"他の動物の食生活を持ち出す"作戦か、さらにそれでもだめならいっそ光合成理論に走るしかない。

調べだすといきなり躓いた。
現代人のカロリー摂りすぎとも言えないらしい。僕が浅はかだった。

getnews.jp


mediplus-lab.jp


OK。認めよう。成人男性に必要な最低限摂取カロリーは2200kcalだ。

今回の敗因は統計に頼りすぎたことだ。そもそもの発端がブレサリアンだった時点で、統計的な考え方でどうこうできるわけないのだ。
ハズレ値が実際に成立することを証明しないといけなかったのだ。

なにやってんだか。今度完全食とやらを試してみようかな。

*1:0.1238+(0.0481×体重kg)+(0.0234×身長cm)-(0.0138×年齢)-性別*1

PostgreSQL便利テク メモ

PostgreSQLの便利テクを随時集めていく。

versionは9.3 ~ 9.6あたり。(←適当)

psqlによる定期実行

select now(); \watch 3

3秒ごとに「select now();」を発行する。
insert文でも使えるので、1分毎とか30分毎ごとに登録されるダミー値作るのとかにも使えそう。

ストアドプロシージャの書き方サンプル
関数作成

CREATE FUNCTION func_sample()
 RETURNS SETOF bigint
 AS
 '
     SELECT id from table ;
 '
 LANGUAGE 'sql' ;

トランザクションを明記する必要があれば、SELECT文の前後にBEGIN, ENDを追記する。

関数実行。

select func_sample();


データをCSV形式で吐き出す

\COPY (select * from table) TO 'C:\sample.csv'(FORMAT csv);

MBTI診断を受けて、INTPが自分の人生を振り返ってみた

f:id:lazycat99:20181027025109p:plain
MBTI診断結果

気まぐれでMBTI診断というものを受けてみて結構面白かったので、真面目に自分のことを振り返ってみた。

MBTIとは
MBTI診断は統計に基づいた性格分析だ。
Myers-Briggs Type Indicator®の略で、Katharine Cook Briggsが娘のIsabel Briggs Myersとともにユングの理論をもとに発展させた性格分析理論で、4つの軸によって人の性格パターンを分ける。

・ Introversion (I) or Extraversion (E)
・ Intuition (N) or Sensing (S)
・ Thinking (T) or Feeling (F)
・ Judging (J) or Perceiving (P)

よほど豊富なデータが蓄積されているのか、実際に受けてみると自分の心を見透かされているのではないかと思うほど当たってたりする。

Free personality test, type descriptions, relationship and career advice | 16Personalities

they also give us a chance to describe a significant part of human personality and create theories that attempt to explain why we do what we do

Personality types are useful tools for personal growth and mutual understanding, but remember that people are too complex to be completely defined by their types. Please try to avoid using types as lazy labels.

とあるように、この研究はなぜこのように行動するのか、なぜこのように感じ、考えるのかを説明することで、より良い生き方を見つけるためにある。。
「あの人は○○型だから、しょうがない」、「自分が○○型だから××だっていいんだ」とかそういう思考のためにあるのではない。
行動や考えのもとを理解することで、悩みが解決したり少しでも良い人生を送れるようになってほしいというのが根っこにあるメッセージだと思う。


診断結果 ~INTP~

論理学者型の人達にとって大きな壁となっているのは、絶えず付きまとう失敗に対する恐怖心です。自分の思考や理論に決定的な欠落がないかを心配して見直すあまりに、立ち往生し、自分の考えが正確に当てはまることは決してないのだという、実体のない世界の中に迷い込んでしまいます。こうした自信喪失を克服することが、論理学者型の人達が直面する最大の課題ですが、論理学者型の人達には大なり小なり知性という才能があります。この知性を活かして闘う価値を見い出した時、世の中に貢献します。

学生時代になぜ自分がこんな勉強をしているのかわからなくなった時期があった。自分はずっと研究がやりたいのだと思っていたが、物理や化学に自分でも驚くほど興味を持たなかった。
勉強をするわけでもなく、かといって部活とか他に打ち込むわけでもなく、ただ自分の思考の世界で迷子になっていた。人生における目的や目標を持てない時期は決して楽しいものではなかった。
夜はあまり眠れず、近くを何時間も歩き回ってひたすら自分は何がしたいのか一カ月以上考え続けたときもあった。

そんなときに出会ったのがプログラミングだった。
ちょっとバランスが崩れただけですぐに迷宮入りしそうな自分の思考を現実にして、明確にして、動かすことができる。そんな世界があることをそれまで知らなかった。

僕にとってプログラミングは、世の中が少しでも良くなるようにと願い考えながら、実際は自分の思考だけに閉じこもって何も行動しないというINTPらしい自己矛盾を解決することができる救いのような手段なのだ。

個人的な感覚としては、「絶えず付きまとう失敗に対する恐怖心」よりも、自分の発言・思考と行動が矛盾することへの気持ち悪さのほうがずっと強い気がする。
今でも時々、何年も前に自分がこうしようと考えていたことと、今の自分の行動が矛盾していることが気になって、生活のパターンを変えたりすることがある。

自分に対してそう思うのは僕の勝手なのだが困るのは、他人を見て発言と行動が一致していないと軽蔑を感情をいだいてしまうことだ。
その人は場を盛り上げたり、笑いを生むために口にしたことであって、特に深い意味はないのに、普段の行動を矛盾している!と思うと「何言ってんだこいつ」と内心思ってしまう。
これはINTPがどうこうというより、僕の人間的な器が小さいだけかもしれない。

強み

Enthusiastic – When a new idea piques their interest, Logicians can be very enthusiastic

わかる。面白そうなことがあるとそればっかり考えていたい。仕事とかほっぽりだしてそっちに集中したいが、そういうわけにもいかない。
1つのことに向けた集中力はINTPの最大の長所だと思う。
はじめて自分でc++学習用のクイズアプリを作ったときは、寝る食う以外は何もせずひたすらコーディングしていた。
もちろんわからないことだらけだったが、それでもバグを直したり、ネットで拾ったソースをコピペしてとりあえず貼っていくうちに、アプリと呼べるものに近づいていくのは楽しかった。

仕事でプログラムを書くようになってから、技術的には断然成長したが、スケジュールに追われてそういう気持ちでプログラムを書ける時間は少なくなった。
少なくなった、というより自分がそういう時間を確保する工夫が足りていないのが現状だ。

Imaginative and Original – These connections are the product of an unrelenting imagination – Logicians’ ideas may seem counter-intuitive at a glance, and may never even see the light of day, but they will always prove remarkable innovations.

確かにもっとこういうものがあったら便利なのに、とかもっとこういう機能があれば便利なアプリになるのにというアイデアは特に意識しなくても出てくる。
ひたすら思いついたことをメモしていくと、100個以上になることはザラだ。だが実現するのはその中のほんの2,3個だったりする。
水平方向にはアイデアが広がるけど、垂直方向の思考の展開というか具体的な実現までのルートをイメージするのが苦手なのだ。
正確には苦手というより、なにか思いつくとそれが楽しくてそこで満足していまい、実現するまでに必要なリソースとかスケジュールを考える習慣が欠けているのだ。
ここを克服するかどうかはINTPにとっての1つの分岐点だと思う。
実現するルートをイメージするは、僕にとってはかなり苦労することで途中で全く別のことを考えてしまったりする。
自分の思考なのに、全く思うようにならないので、とても歯がゆい。
最近は考えが迷宮入りしそうになったときには、ひたすら紙に書き出すという解決策を一つ見つけたが、まだまだ模索中。

Honest and Straightforward – To know one thing and say another would be terribly disingenuous – Logicians don’t often go around intentionally hurting feelings, but they believe that the truth is the most important factor, and they expect that to be appreciated and reciprocated.

INTPの例として、マトリックスのNeoが挙げられているが、赤いピルを飲むあたりがINTPなんだろう。
ついこの間あったのは、お客さんから画面の構想を聞く打合せに会社の偉い人と先輩方と参加した。
その後の内部打合せで偉い人がお客さんの要望とずれたイメージを図にしていた。
これは間違っていると思ったが、そのとき僕は「これこっちなんですね?」という弱い主張しかできなかった。
口で何か説明したりするのが、かなり苦手なのでどういう風に自分の意見を主張するのか分からなくて、損をしてしまうことがある。
ここはもっと勉強しないといけないところなんだろうな。


弱み

Very Private and Withdrawn

その通り。飲み会は基本嫌いで、時間をかけて仲良くなった人以外とは食事ですらストレスがたまる。
ワーワー周りの人が盛り上がってるのを見ながら、話の内容は一切聞かず全く別のことを考えて、自分だけ別の世界にいるような感覚に陥ることは日常茶飯事だ。
そんなことをしていると、たいてい先輩に絡まれて、「すみません」と謝るのがお決まりだ。

Absent-minded – When Logicians’ interest is captured, their absence goes beyond social matters to include the rest of the physical world.

自覚あり。何か考えてたり、没頭してるときにLINEとか来ると、スライドして通知を画面から消してそのまま数日から1週間放置したりはよくあること。
自覚はあるが、改善の意思はない。社会的によくないことだと頭ではわかっているが、心の中ではなんでその必要があるのか分かってない。没頭してるほうが楽しいから。
友だちから転職の相談を受けたときも、作業に集中しているときには正直どうでもいいと思ってしまった。

職場でも集中したいときは、話しかけないでオーラをバンバン出してしまうタイプだ。
たまに「こわい」と言われたりして、ちょっと傷ついたりは意外としない。
多分この性格の根元には、独りよがりで思いこみが激しい面も一役買っている。
本当は集中なんてしなくても、想像力を働かせればもっと早く良いものを作る方法があるはずなのだ。
それなのに自分は集中しているという言い訳を建てて、自己満足に浸りがちなのも最近の悩みだ。

自分とは違う意見を受け入れるのが下手で、否定から入ってしまう癖がある。
だから「もしこうなら、こうなって、さらにこうなるはずだ」という想像力が足りないので、先を読みながら仕事を進められない。
否定から入る癖を直そうと、頭の中で「そんなのあるはずない」という声が聞こえるたびに「いや待てよ、でももしそうなら。。。」と賛否両論を一人で繰り広げるカオスな営みがマイブームだ。
こういうことするのはINTP成分が高めかもしれない。

診断の的確さに感動して、勢いで購入したPDF版詳細のLogicianのページ最後にこんな言葉がある。

Best of luck on your path, Logician. It may not be easy, but few things worth doing are.

We modestly hope that we have lighted a few lanterns along the way too.

月並みな表現だが、心にジーンときた。
INTPとかいう変な人(失礼だけど合ってるでしょ)の幸せをこんなに願える人間がいること、自分でもわからなくなるくらいこんがらがったINTP的思考を理解しようと努力している人が世界に存在する事実(大げさだけど)に勇気づけられ、励まされた。偉大な研究だと思う。

まとめ
振り返ってみて、思ったよりINTPだった。
でも診断結果と自己分析結果が一致しているということは、MBTI診断の自分の選択に一貫性があって信頼できるということだと思うとちょっと嬉しかったりする。
だってINTPだもの。

【エラー解決】org.hibernate.engine.jdbc.spi.SqlExceptionHelper - ResultSet に列名 DTYPE は見つかりませんでした。

SpringとJPAを使って自作のアプリを作っていたらDaoで「ResultSet に列名 DTYPE は見つかりませんでした。」というエラーがでたので、原因と解決法をメモ。



サマリー



エラー内容
ERROR org.hibernate.engine.jdbc.spi.SqlExceptionHelper - ResultSet に列名 DTYPE は見つかりませんでした。

原因
Entityの継承関係。親クラス、子クラスの両方に@Entityをつけるなんてナシだよというおはなし。

解決策
継承元の親クラスEntityに@MappedSuperclassアノテーションだけつけて、それを継承した子クラスEntityに@Entityをつける。

用語
DTYPE・・・継承関係のあるクラスを区別するための識別子。




エラー内容


ERROR org.hibernate.engine.jdbc.spi.SqlExceptionHelper - ResultSet に列名 DTYPE は見つかりませんでした。

DTYPEってなんだと思ってググる

JPA永続性プロバイダは、デフォルトで、継承階層でクラスを区別するためのDTYPEという識別子列を作成します。

※引用元:JPA注釈の参照情報
ということで原因はEntityの継承関係にありそう。というか実際そうだった。

英語では

the Persistence provider assumes a default column name of DTYPE and column type of DiscriminatorType.STRING.

とか書いてあるのでDiscriminatorTypeの略なのだろう。Discriminatorは識別という意味だそうだ。



対処法



解決策としては共通部分のEntityに@MappedSuperclassアノテーションをつけて、それを継承した2つのクラスを作る。

勝手な推測だけど、子クラスにも@Entityをつけると、hibernate.loaderがQueryを実行して得られるObjectに親クラスと子クラスの両方のEntityの型を関連づけてしまうので、どっちのEntityに変換すればいいのかわからなくなるみたいな感じ?



エラーが起きたソース



HogeEntity.java

@Entity
@Table(name="hoge")
public class HogeEntity {

	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	@Column
	protected Long id;

	@Column
	private String name;

	// getter, setterは省略

}

HogeHogeEntity.java

@Entity // <--ココが原因!
public class HogeHogeEntity extends HogeEntity{

	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	@Column
	protected Long id;

	@Column
	private Long fuga_id;

	// getter, setterは省略

}

HogeDao.java

/**
 * Idでデータを取得
 * @return
 */
public Optional<HogeEntity> selectById(long id) {

	EntityManager manager = factory.createEntityManager();

	StringBuilder sqlBld = new StringBuilder();
	sqlBld.append("  SELECT ");
	sqlBld.append("  * ");
	sqlBld.append("  FROM hoge ");
	sqlBld.append("  WHERE ");
	sqlBld.append("  id = :id ");

	Query query = manager.createNativeQuery(sqlBld.toString(), HogeParentEntity.class);
	query.setParameter("id", id);

	@SuppressWarnings("unchecked")
	List<HogeEntity> list = query.getResultList(); // <--ここでエラー

	manager.close();

	Optional<HogeEntity> optEntity = Optional.ofNullable(list.isEmpty() ? null : list.get(0));

	return optEntity;

}

※Optionalで書いてあるのは、今回のエラーには関係ない。

ちなみにgetResultList()ではなく、getSingleResult()を使った場合は、
クエリー結果のObjectをEntityに変換する処理で、ClassCastExceptionが発生する。対処法は同じ。

Object result = query.getSingleResult();

if (result != null) {
    HogeParentEntity entity = (HogeParentEntity ) result; // ここでClassCastException
}
 



修正後のソース



HogeAbstractEntity.java

@MappedSuperclass // <--ココを修正!
public class HogeAbstractEntity {
        
	@Id
	@GeneratedValue(strategy = GenerationType.AUTO)
	@Column
	protected Long id;

	@Column
	private String name;

	// getter, setterは省略
}

HogeEntity.java

@Entity
@Table(name="hoge")
public class HogeEntity extends HogeAbstractEntity {
        // 何も書かない。継承するだけ。
}

HogeHogeEntity.java

@Entity
public class HogeHogeEntity extends HogeAbstractEntity {
        @Column
	private Long fuga_id;

  // getter, setterは省略
}

共通部分は@MappedSuperclassアノテーションをつけて、切り出してあげる。
実際に使うEntityは@MappedSuperclassをつけたEntityを継承して実装するかたち。



DTYPEなんてわかりにくいエラーメッセージやめてほしいよね。