噂になってた国土地理院の赤色立体地図を見てみたの巻。

internet.watch.impress.co.jp

この記事を見て赤色立体地図をみてみた。
メモがてら蔵王のお釜へのリンクを貼っておくです。

maps.gsi.go.jp

いかにもCGって感じの画像ですが、惑星の地表面を宇宙からスキャンして作ったような雰囲気もあるわー。(あるかなー?)
お釜の中心から縮尺を小さくしていくと、お釜の周辺は塊感のようなものがあるけど、その周りに毛細血管のような部分が出てきて、
自然の動きとかも感じられてくるよね。
面白かったです。


あと妙に使いづらいのが玄人感を出してるなぁと一瞬思いましたが、そんなこともなく、慣れの問題でした。
・右上に「機能」ボタン。
・左上に「情報」ボタン。
リンクを開くとポップアップメニューで隠れていたので注意する。

あと、このサイトの地図のページは重くて四苦八苦です。
たまたま利用者が集中したのか、自分のノートPCが弱いのかわかりませんが。ファンが唸りました。
動きがガクガクしだして辛かったです。
ブラウザにもよるかなと思い、Safariに変えたら多少よくなったかも。

タブ・スペース戦争

www.gizmodo.jp

なんかこの海外ドラマ面白そう・・・。

さて、タブ・スペース戦争も昔の話って感じで、いつ頃からか思うようになった事。

所感

 まず、インデントはタブの方が楽だと思って使ってました。その考えはその時からずっと変わらないだろうとも思ってました。思ってたんですけど、いつ頃だったかインデントにスペースを使っているプロジェクトに関わる事になって考えを改める事になりました。最初に関わった時はやれやれって思っていたんですけど、でもそれを使い続けていても特に不便を感じなかったという事があるんですね。 そうして私はインデントにスペースを使うことへの抵抗がなくなっていき、もうどっちでもいいかなという感じで見れるようになりました。 とりあえず統一されている方がいいのはありますが、混在される場合は・・・混在させて使ってる人は本当にそれが使いやすいのか、個人的にはまだ疑問がありますが、それも自由に選択できる方がいいとは思います。
プロジェクトでルールが決まってるなら何も考えずに相手に合わせるだけです。

理由

 まず、タブの問題が何かといえば環境によって表示が異なってくるという点なのでしょう。大体[幅:2/4/8]にされてるとしてタブはどの幅に設定されてたのかな?と他人には分からない事だとか。 それが社内や決められたチーム内での開発であれば同じ開発環境と設定などのルールを決められるので合わせない人がいても合わせてってお願いする程度だと思うんですが、 OSSの開発になると、開発環境は人それぞれで統一されない事が殆どなんですね。だから見た目がタブ幅の設定などに影響されないスペースを選択する方が良いという事になってきます。まだ見ぬ多くの人の事を考えてスペースを選択する。 例えば、作った本人としてのAさんの環境では揃えられたコードが見れたとしても、それを見る他のNさんの環境では表示が崩れるという事があり得るので。 OSSでは特に環境の違いがバラバラになる事を勘案して、共有されるコードについてはインデントをスペースにする方が全体への配慮として優しいかもですね。

でも

 でも自分の好きなスタイルで開発したいですよねー。プロジェクトには合わせなければならないけど、それでもスペースorタブ自分の好きなスタイルで開発したい。問題ないです! 自分の好きなスタイルで自由にやっちゃいましょうー。それは単に自分のローカル環境でだけちょっと変換してやればいいだけの事ですから。共有物に余分な変更を入れなければローカルでは好きにできるってわけです。
 エディタとフォーマッターを使って解決です。チェックアウトしたものを自分好みに自動整形、共有する前に元の形に合わせて自動整形する。gitでも設定してできそう(課題:分からないから後でやれたらやりたい)。(とりあえず計算資源が安くなってるっていいね) 例えば空白インデントがルールだったら、行先頭に空白n個があったらタブに変換する、元に戻してから共有する。 コミットする前にフォーマッターを挟むように示し合わせておくのもいいね。
 そもそも、スペースを使ってても不便を感じなかったのはエディタの力が大きいですね。コーディングに特化したエディターはコーディングをしやすくするための工夫が沢山考えだされてきて、インデントという概念も昇華してきているのでスペースでもタブ感覚で操作してくれるようになってるし、中にはvi操作にするプラグインなどもあって慣れてしまえばテキストの操作がより効率的にできるようになります。慣れるまでがちと大変かもですが。*1
そんな感じでたまに新発見があると、いつまでたってもチュートリアルが終わらない感じになるですね。

C系ならclang-formatかな、
http://clang.llvm.org/docs/ClangFormat.html
web系だとprettierがいいらしい。わかんないけど
https://github.com/prettier/prettier

差分の心配もそんなないかな、gitならタブ・スペース無視するオプションがあるし。 (設定の方は後で調べておきたい。)

(:エディタの話忘れてた、後で入れておきたい。)

*1:emacsは昔トライしてみたんですがメタキーがちょっと...、憧れのemacs

Python:命名規則覚書

 昨年のことですが会社でPythonを触る事があって、 その時は命名規則などは気にせず、ドキュメント見ながらバラバラ書いてたのですが
 最近、その言語で推奨する命名規則とかあるよなぁと、ふと気になったので探って見たのでした。もともとプログラム書く時は公式ルールみたいな物があればその例に倣って書くようにはしてるんですよ。作るの優先て時もあるって事ですね。
(既存のプロジェクトが固有のコーディングスタイルを規定しているならば、そちらに従うべきですけども)

さてと、それでは、〜本題〜
Pythonのコーディング スタイルにおいては「PEP8」とか「PEP257」という物があるらしいので興味があったら調べよう。僕も暇があったら覚えようって言う途中の段階なのですよ。

変数名:cur_position (小文字 & スネークケース)
関数名:calculate_function(小文字 & スネークケース)
クラス名:MyClass (先頭大文字 & キャメルケース)
モジュール名:my_module (小文字 & スネークケース)
パッケージ名:package (小文字 & スネークケース)
定数:STAR_BACKS (大文字 & スネークケース)

という感じでした。まずは何も考えずにやれる所から始めていくスタンスです。
(課題:アンダースコアのルール面倒なので追い追い覚えよう。とりあえずは "_" を付けたら非公開メンバーって覚えておくのだ。) 
色々教えあえる人はほしいね。(なんか微妙だけどいらないって言ったら嘘だわ)

それで、今回調べてたら、ちょっといいな!って思った所がありました。 関数に付けるコメントです。

def func():
    """
    関数の説明だよ
    """
    return 0;

こんな感じで、関数名の直下にコメントをつけるスタイルナウいですね。今まで触ってきた言語にゃ無かったので斬新な感覚でした。しかも表題名があってその下に書くってのがまた自然な感じで受け入れやすいと思いました。

で!
これで終わりでは無かったのだ。

実はPythonにはDocstringという言語の機能があるようなんですね。 関数呼び出しの要領で整形されたドキュメントを表示させられるのです。 *1

help(func)

または

print(func.__doc__)

これはそもそも__doc__属性に保存されると言う言語の仕様があるらしいですね。
(課題課題:暇があったら属性のことも調べておかないとだな。)

実際に動作する事をPythonのREPLからも確認できました!
こんな風に表示されたよ。 f:id:joint1:20180605013814p:plain
(help(func)実行時のもの。コメントが違うけど気にしないでね)

これが、外部ツールではなくて言語の機能として初めから組み込まれてるという所がモダンですねぇー。関心しました。こんなことで関心してしまうとは古い人間かもしれませんが。そこはご愛嬌ですよ。

クソダサい俄かC/C++erでごめんなさいって感じです。 C++は知り合いに聞いてもゲレゲレしてて嫌いって言われるから辛いんですが。 確かにその人の言う通りなところもあって苦しめられることも多いけど、僕は好きだよC/C++ 11以降。
ただ、Linus神も嫌ってるC++だからね!、そこは見習って嫌いになりたいとも思っていたりする。(微妙な問題

同様に "モジュール"と、"クラス"についてもdocstringを付けられるので付けていきましょう!

"""
Module infofmation.
"""

class Wasabi():
    """
    Class information.
    """
    def func():
        print("PiyoPiyo")
        return 0

こんな感じなんですかね。

君も今日から Let's try!!! だぜ!!

¥e


オライリーですよね

入門 Python 3

入門 Python 3

ノンプログラマーできますかね、理想的ですが

KivyでGUI作ってあげようかなって思ったんだけど、結局停滞中

Pythonは割りかしモダンで楽だからPGの人は入門用とか読んでも仕方ないもんな。これあればいいのかな?

エキスパートPythonプログラミング 改訂2版 (アスキードワンゴ)

エキスパートPythonプログラミング 改訂2版 (アスキードワンゴ)

追記:しがない雑談をちょっと書こうのつもりが想定より長くなってしまった。

*1:manコマンドみたいな物ですね

ひそねとまそたん

hisomaso.com

 最近すっごく面白かったアニメ!

 「ひそねとまそたん」 まじレッサーのひそねと変態飛翔生物のまそたんが運命と戦う物語だった。

ーー以下駄文ーー

この平仮名のタイトルとサムネイルっぽい絵を見手の第一印象は ほのぼのしたお話なんだろうなという程度の認識で食指は動かなかったです。 だって、"ひそね"、"まそたん"と聞いても全然こんなの想像できませんし。

 そんなある日、これはどうやら空自が舞台となっていてそで竜を操っているらしい、という感じの情報を入手したら俄然興味が湧いてくるというのはファンタジーも飛行機も好きなら仕方ないこと。 空を飛ぶのは人類の夢だから。 「空自」+「竜」っていう組み合わせの珍しさと合わせて。

 アニメを実際に見るまでのイメージとしては、--現実の空自で飛ばしてる空飛ぶ鉄の塊を竜に見立てて、その竜と隊員が交流する日常を描く。-- 程度のイメージで、序盤は大体あってたけど。
竜(変態飛翔生物)が実は国に繁栄をもたらすとされ争いのタネにならぬよう秘匿して重宝されてきた。今は空自が引き継いでいる。なぜなら竜は空を飛ばせてやらないとストレスが溜まるから。っていう感じの設定だったのは意外だった。自我のある竜なのにパイロットが必要な理由は多分今後も語られないと思うけど。全然構わないですよ。

 主人公の甘粕ひそねが高校卒業後の進路を考えるところから始まる。 自分にしかできない事をやりたい人、それが何かわからないけど見つかるといいなって周りで話している。それらの声を横に聞きながら、飛んでいくF15を目にしたせいなのか、第一志望に航空自衛隊とだけ書く。やりたい事もなく自分にしかできない事なんて分からずそんな人物像。

 入隊した自衛隊では適正検査からDパイ候補生にされる。 この竜のパイロット?する方法が斬新だったからそれだけでも見てほしいなって思った。 
最初に上司に反発するところが、言いたい事を言えず仕事を断れない溜め込んじゃう日本人サラリーマンの気持ちを代弁しているのかもしれない。 突然殴りかかるカミーユ・ビダンのようだった。カミーユは殴るに至る理由があるんだけど殴られる方はまさか殴られるとは思っていなかった。 いや、まぁ、こじつけなんですが。
ひそねは慰めに来た機付長に胸の内を打ち明ける。曰く、思った事をなんでも言ってしまって周りとうまく馴染めないと悩んでいる。 そういう劣等感を抱えた主人公が、まそたんとの出会いからワンダフルライフが始まる。まそたんと関わって成長していくストーリーなんですね。ストーリーの枠はそん感じで置いといて、

 一番の見所は F-15に変形するドラゴン です。(ネタバレだと思うんですが公式でもその他でも言われてるんで放映されたらそのあとはネタバレ規制とか無いんですね悲しいですが。) コクピットVRで全天周スクリーンが再現されていました。空を飛んでるっていう飛翔感をアニメで表現される時が一番ワクワクしてしまう自分の感覚はキッズのままだから、ここめっちゃ面白いので空飛ぶのが好きな人はみんな見てー。第一話での掴みがバッチリってことですね。

 全くどうでもいい話になるんですけど、これも考えると辛い所ですよね、本当のドラマをやりたいって思ってても、最初の第1話の20分で継続視聴してもらうための掴みをやらないといけなくて、それはドラマパートを置き去りにしてでもまそたんを飛ばす事を優先しなければならないということになる。それに対する解としては飛ばす事とドラマをリンクさせて上手くまとめるとする。実際上手いからいいんだけど。それということは逆説的に言うと数話かけてから飛ばすという話の作り方は出来ない事になり、つまりTVアニメのお話の作りは実はたくさんの制約によって(以下ry 制約なんてどんなメディアでも同じだけど。
 それで自分も1話目を見てる時からちゃんと飛んでくれよって心の中で願ってしまう心があって邪魔でしょうがない。見ている時にドラマお話とは関係ない所で不安になる。例えば、半分過ぎたがまだ飛ばさないのか?この流れで飛ばす所まで持っていけるのか?制作様を信じてるぞ...。とか邪念が浮かんで来てしまう。どう考えても純粋にドラマを楽しもうという姿勢ではない。エゴのようなものが付いて回っている。これはもう仕方ないんだよなと諦めているけど。やっぱりそう思ってしまったのです。

 あと、よく考えたらこれまでのロボアニメと類似したパターンがあるので、そう言う意味では安心して見てもらえるかもしれない。
-- 平和に暮らしていたが、突然陰謀に巻き込まれ、実はこんなものが開発されていた!今から君がパイロットだ。やってくれるな?やーってやるぜー!!--

 何でアニメファンがアニメのチェックが弱いんだとか思われるかもしれないけど、毎回全部チェックとか普通無理だから。過労死しちゃう、好きなら何でもできるわけじゃないんだよ < 話の文脈が間違ってる。

 タイトルが全部平仮名だと、どこで区切ればいいか直感的にわからないから、こういうのってヴィジュアルとセットで見せてもらわないとダメなんでしょう。よくあることだけど。

 基地内の移動時にひそねが乗っていたバイクはカブで、そう言えば最近カブを見かけないなと思った・・・。と思ったが仕事が屋内だから当然か。

 ひそねとまそんたんの良さについてぼーっと考えてたら、自衛隊が配ってたパプリカ王国の漫画を思い出して読みたくなってきた。(もしかすると実家の奥底にあるかもしれないし、ないかもしれない、地震で捨てたか)さすがに今は続いていないだろうか。うーむ、自衛隊って意外と漫画を出しててビックリさせられるよ。広報宣伝用の漫画なんだけど、それがパプリカ王国だけかと思ったら、等身大の青年が出てくるものもあってそんなバリエーションがね。きっとパプリカ王国の受けが良かったのだろうと思いたいです。とりあえずパプリカ王国の漫画だけでも出版してくれ!

追記. 見返すとまそたんを紹介できていなかった。 竜のまそたんは前任者が退いてからは長らく適合パイロットがいなくて格納庫で燻っていたみたいなんだ。言葉で意思疎通はできないから周りはやきもきしてるみたいなんだけど。とはいえ、ひそねとの関係では彼女の悪い性格で思った事を言ってしまうmまそたんはその一言に拗ねたりするから言葉はわからなくても意思疎通ができてしまってるようで、マンガ・アニメ的なんですね。なので、そんなまそたんの態度から察してコミュニケーションを取って行くひそねだったりする。 そういう傷つく側とそれを察して反省して仲直りして段々近づいて行く。 そんな事をしながら、ひそねとまそたんがこれからどんな経験を通して変わって行くのかなって言うのが期待されるところなのかな。 〇〇を飲み込んだりする所は野性味たっぷりに描かれてる。

ハセガワ たまごひこーき 航空自衛隊 F-15 イーグル ノンスケール プラモデル TH1

ハセガワ たまごひこーき 航空自衛隊 F-15 イーグル ノンスケール プラモデル TH1

$ git commit --fixup <commit>

試しにGitの話でも。

最近Git 2.xの記事を読んでみて覚えた事を1つ紹介してみる。

japan.blogs.atlassian.com

この記事に書いてある 「git commit --fixup を利用して、素早い修正を」の部分をご紹介です。
↑の記事を読んでみて、翻訳のせいか理解するのに少し手間取ったので、その時間を短縮するか、理解の補助するお役に立てればと思った物です。元の記事を読んでわかる人には不要な物となります。

$ git commit --fixup

用途:
コミット履歴を修正するために使います。

前提条件:
rebase をするのでブランチを共有していない事。
つまりリモートにpushしていない事。

状況と使い方-手順:
例えば、ローカルの作業ブランチである程度作業を進めた後で、数個前のコミットにちょっとした間違いがある事に気付いた。(typoをしていたとか、消し忘れとか)
このような状況があったとして。

こうした場合でも、修正を新たにコミットして解決できますが、 コミット履歴をちょっと綺麗にしておきたいと考えた時には"--fixup"を使って直すこともできます。

以下のようなコミット履歴があったとして、 このA1のコミットの内容を修正したいとします。
(A1、A2、A3の部分はコミットメッセージの部分だと思ってください。)

commit: A3
commit: A2
commit: A1
checkout: topic_branchA

A1に適用したい修正をして、 それをコミットする際に --fixup を指定します。

$ git commit --fixup <A1のハッシュ>

適用したいコミットをオプション引数に渡します。
このコミットを確認すると以下のようなメッセージになっています。

fixup! A1

履歴の状態はこんな感じです。

commit: fixup! A1
commit: A3
commit: A2
commit: A1

そのあと引き続きこのブランチで必要な作業を完了させたとします。 

そして最後ですが、マージをする直前に先ほどのfixup!を適用するため
以下のように git rebase を行います。

$ git rebase --interactive --autosquash

一応簡単に補足
 --interactive :対話的に行うという指定。省略しても良いです。
 --autosquash :スカッシュの自動化みたいな事をします。

rebase完了後のコミット履歴を確認すると前の状態から、"fixup!"の付いたコミットが消えていて、その変更内容はA1に含まれている事になります。

commit: A3
commit: A2
commit: A1

以上で完了です。

--fixupというのが何をしているか簡単に説明すると [fixup! log_message] と言う形式でコミットにマークをつけることになります。
それがある状態で git rebase --autosqush をした際に fixup!のlog_messageに一致するコミットを修正対象として1つのコミットにまとめられます。
(そのコミットが、fixup対象としたコミットの直後に配置されて変更内容が適用される。) という事を git で半自動的に行ってくれます。

reflogを確認すると以下のようになってます。

rebase -i (finish): returning to refs/heads/topic_branchA
rebase -i (pick): A3
rebase -i (pick): A2
rebase -i (fixup): A1 //<< fixupしたコミットがこの順番に来ている。
rebase -i (pick): A1
rebase -i (start): checkout master

ちなみに、
* fixup! と似たもので squash! があります。
* 全く同じメッセージのコミットがあった場合の動作も一応確認しておきたい・・・。

余談

rebase についてはコンフリクトの修正でバグのコミットを隠してしまう可能性がある事に気をつけた方がいいかもしれません。 私の経験で、 rebase でコンフリクトを解消しながら完了させたあとにコミット履歴を見ると、そこでコンフリクトしていたという情報が欠落していた記憶があります。
(記憶違いだったら申し訳ないです。)
もっと正しい事例が↓この記事にあります。
https://frasco.io/why-you-should-stop-using-git-rebase-535fa30d7e25

ここにある通りマージしていくのが良いと思っています。正確な記録が残るので。
ただ、簡単な修正のためにfixupでrebaseするぐらいはあるかなと。

フォント!

フォントへの思い(ry


今使っているフォント : "Fira code"

github.com

Fira codeを使い始めた経緯:
発端は プログラムの仕事で毎日コードを見ていると、目が引っ掛かる事があります。
 文字が見づらい時があるんです!
似たような単語、文字と文字との間隔の詰まり具合、太さと大きさ、
色んな要因があって意識がゲシュタルト崩壊を起こしているのかなって思います。
だから、フォントを変えるだけで仕事の効率がちょっと向上するかも知れません。

仕事で毎日コードを見る事になるので、なるべくストレスが少ない物を求めています。
そう思って、プログラミングに向いているフォントを探していました。

最初は等幅フォントが良いという事で"Osaka"フォントを使っていました。
これは Mac にデフォルトで入っていて、日本語が使える等幅フォントといえば"コレ"という感じがしました。
変更してみると、Xcodeでは日本語のコメントをつけた時に変な行間が開いていて中々のストレスだったのですが。
それがなくなって落ち着きました。

・・・でも、納得していませんでした。

その後転職して職場もマシンも変わったので環境構築ついでにフォントを探してみました。
やっぱりプログラミング向けに作られたフォントを選ぶのが良いだろうと思いました。

選択のポイント:

  • 特に重要なのは以下の文字が考えずに見分けられるかどうかです。

"1iIlL", "0oO"

そして選んだ"Fira code"を見つけました。
元々は "Fira mono" というフォントがあってこれをプログラミング向けのフォントに拡張した物らしいです。

これにはリガチャー(合字)が入っていました。
リンク先に見本があるのでご確認ください。
これを最初に見た時は、見慣れた記号を別な形で表示している物に慣れるのは良くないなと思いました。
なぜなら、またフォントを変更したくなった時に、この表示をサポートしているフォントを探そうとすると
選択肢が限られてしまうと思ったからです。
でも、使う事にしました。
もしフィーリングに合わなくても、すぐに変更すればいいわけです。

そうして昨年から使ってきて特に不都合もなくいい感じです。
リガチャ―の記号にはそれほど違和感がありませんでした。

リガチャ―の説明を先にしておいてこんな事を言うのもなんですが、
それより何より、文字間隔の入れ方が巧妙で気に入ってます。

1. if (a == b)  
2. if ( a == b )  

どちらが見やすいでしょうか?
これはあくまでスペースを挿入して調整してますが、
詰めすぎに感じるけど、だからといってスペースを入れるのも大げさだし・・・。
それが"Fira code"では語のまとまり毎に微妙な区切りが作られているようで
上の2つの中間とまでは言いませんけど、スペースを入れなくても非常に見やすくなります。
だから、おススメですよ!


いつか何かのデザインの中で使ってみたいフォント

未来的ロマンを感じる

Dendritic Voltage Font | dafont.com

宇宙的カッコよさの代表格

Nasaliza font. abc-font.com

日本の皆が大好きなドイツのDINとFUTURA

http://type.gs/culture/interview_kobayashi.html


昔お気に入りだったフォント

手書きの日本語フォント。すごいね@@

オリジナルフォント【みかちゃん】

VIDEO GAME では"Front Mission"のフォントが渋くてお気に入りでした。
特に同シリーズの"FRONT MISSION ALTERNATIVE"では横幅3ピクセルで表現された英語のフォントが登場します。

↓ゲーム画面:下段に表示ているコンソールは行動ログを流しています。そのフォントを見てください!
Mecha Damashii » News: Front Mission Alternative Translation

Thanks.

¥e


フォント・アライアンス・ネットワーク FONT x FAN HYBRID 4

フォント・アライアンス・ネットワーク FONT x FAN HYBRID 4

遺伝子と人格について物思いに耽る

# 人の体には、それぞれ個人毎に固有の人格が宿っているらしいです。(人格や意識)

結論:人の人格は遺伝子で決まる。

なぜそう考えたか:
まずは、
人の人格を形成する大きな要素として脳が果たす役割が大きい事。
脳の形は動物毎に大体決まっている。 人間であれば人間の脳と分かる程度には、他の動物と比較したとき形のパターンが浮かび上がってくる。
形が似ているということは、中身も大体似ていると考えてもいいのかもしれない。
中身というのはニューロンのネットワークのマップとかまで含めて。
それも、前頭葉、側頭葉などなど脳の各部位の役割分担も大方決まっているらしい事。

生物に脳が発生して、出来上がる脳が、動物の種類毎に分類可能になる一定のパターンに収束しているという事。
それは設計図に基づいて同じ物が作られているからだとすると。
その設計図に当たる物は遺伝子なのだろうと。

そうして出来上がったそれぞれの人間の性格がある一定のパターンの範囲内に収束しているのだとすれば。
性格も遺伝子によって決まっている。
言うまでもなく生後に生きながら常々得ている経験によって性格は変化していく。(誤解されないように、) その変化の方向性も遺伝子による部分があるとしていいんじゃないかなとか考えてました。 (反応を受けて、何かを選択する時にその結果は脳の造りに左右されるのだと思ったので。)

# そもそもなぜそんなことを考えたか: それが重要だったんですけど、途中で寝て醒めたら、忘れてました。

社会の中で生きる人々を見ると、個人毎に異なる人格ではあるものの、人々の人格のパターンはある一定の範囲内に収まっているように思えて、 その事が不思議でした。

社会性、人々のコミュニティには常識が形成されていて、それを逸脱する人が少ないのだとすれば、人々が似た者同士だからじゃないでしょうか。

動物でも、同じ種類の動物であれば同じような行動パターンを取っている事を知っています。

これらの仕組みや差異を認識する事で、もっと面白い社会や人生が開けるのかなとか思いました。

# もしも、その脳が形成されるときに秩序や規則がなかったとしたら、人々は秩序だった社会を形成できなかったかもしれないし、互いに言葉を交わすことはなかったかもしれない。 それは自然淘汰されてきたからなんでしょうか。

現代の私たちは同じ人間だけど、他人として一つの社会の中に共存して協力していて、
たまに人類として大きな成果を上げてくることができたのかどうか。

コミュニケーションできるから協力できる。

それはポジティブなんだけど、ネガティブなことも同様にあって、
私が色々悩んだりして苦しんでいるのも、遺伝子に起因するのかと思うと忌々しいDNA配列めぇーなどと思うのであった。

パターンの例えば、褒められたら嬉しいとか、約束は守る、都合が悪くなったら嘘をつくとか、様々な人間に共通するパターンを想像できる。

自分の持っている一番得意なパターンが重宝されるところに自分の身を置く事がいちばんの幸せ。

たくさん頑張ってきても、ストレスを感じて、うまく行ってないと思える、やっぱり向いてないことをやってるのかもしれないなとか。

日本人の9割が知らない遺伝の真実 (SB新書)

日本人の9割が知らない遺伝の真実 (SB新書)