/ ,' 3

https://twitter.com/gorlemkun

ねねっち四連星

ブログ更新滞り中で、ブログ更新にするネタが無いほど現実がパツっており、QOLが下がり、ムシャクシャし始めてしまい、気づけばペンを持ち、ねねっちを大量に描いていた

 

f:id:gorlem:20180320001122p:plain

f:id:gorlem:20180320001128p:plain

f:id:gorlem:20180320001132p:plain

f:id:gorlem:20180320001138p:plain

まあ半分本当で半分嘘みたいな感じではあるが、イライラすることがあったのは確かで、ペンを持つととても集中できてすべての悩みが消えていくので、絵を描くことはかなりQOLを上げてくれていると思う。

 

ちなみにすべて模写だったと思うので元絵を探そうと思えばあると思います。

 

絵を描くことに関しては前回↓の記事でまだ時間がかかりすぎている感覚があって、今回はさらに時間の短縮をはかった。

gorlem.hatenablog.com

 

やったこととしては

  • 下描きを書かない
  • アタリとらない
  • グリッド使わない
  • レイヤー使わない
  • 塗らない

という感じで、全体的に少ない手数、欲を出すなら全部一発描きで終わらせるくらいの気持ちで取り組んだ。時間をかければクオリティはある程度上がることが分かっていたので、短時間でそれなりのクオリティを出すことを目指した。

 

その結果、上から順に

10分->20分->1時間->1時間20分

と、前回よりだいぶ短縮できている(前回は5時間かかってたはず)

まあただ描くほどに時間をかけてしまう癖が助長されている感じがあるので、そこは反省が必要。時間かけた分、線はより細く、形も整ってきているんだが、費用対効果を考えるとこのクオリティで1時間以上はかけすぎな気がしている。

 

出来れば1時間以内、30分くらいでこれくらい描けるようにしておきたいなあ。手数的には余裕で足りると思うので、後は同じ時間あたりの精度を上げていくだけだと思う。

 

それと別途、模写ではなくて想像から描くほうもやっていて、そこは強く試行錯誤中。

模写がある程度出来るなら、創造もいけるんじゃないかという感じは少し持てるようになってきた。こちらもがんばるし、結構楽しそうである。

 

あと描きたい絵がない。描いておいて何を言っているんだという感じだが、本当に描きたい絵がない。

ねねっちを描いているのは他に描きたい対象が無かったんでそうしてしまっている。ねねっちに興味無いわけではないけど、これといって好きなキャラクターが他に居ないのでモチーフ選びが大変。アニメはごくたまに観るくらいなんでレパートリーがとにかく無い。

なぜ描くか?は描いてる途中の集中体験が楽しいんであって、なにか表現欲があるというわけではないんで困った。ので、周りの人からリクエストを受けることにした。これはこれで絵を通じてコミュニケーションが取れるようになってまた楽しい。

 

早速キズナアイのリクエストをもらったので描いている。楽しい。かわいい。いやーしかしやはり模写ではなくて自分なりの構図とかポーズとか考えて形にしたいなあ・・・時間さえあれば。

f:id:gorlem:20180320001144p:plain

開発もしたいのでこれだけやっているとそれはそれでQOLが下がってしまう。バランスが難しい。しかしやはり絵を描くのは楽しいぞ。

Node.jsのDockerの公式イメージを動かす

今回はNode.jsのdockerの公式イメージを動かす。

https://store.docker.com/images/node

前回の記事だとDocker Hubのページを見てしまっていたのだが、Docker Storeというものを見つけたので今回はそちらのページ。

ただExploreのリンクから辿れる公式っぽいDockerイメージが溢れかえってしまっており、個人的にはDocker Hubのほうがシンプルで好き。

今回みるバーションは8.9.4 LTS。LTSというのはLong Time Supportの略で、まあようは安定版なんだと思う。

こちらにサポート期間が書いてあって、2019/4まではサポートしてくれるそうな。

github.com

8.9.4 LTSのDockerfileはこちら。これからDockerfileの中でされていることをざっくり見ていく。

github.com

FROM buildpack-deps:jessie とあるので、Debianの色々ライブラリインストールされているやつをベースにしているっぽい。詳細は前回の記事で書いてあります。

gorlem.hatenablog.com

まずはnodeグループの作成と、nodeユーザーの作成、nodeグループへの追加とログインシェル指定、nodeというホームディレクトリを作成している。

RUN groupadd --gid 1000 node \
  && useradd --uid 1000 --gid node --shell /bin/bash --create-home node

次に後のチェックサムをするための鍵を下準備する。

# gpg keys listed at https://github.com/nodejs/node#release-team
RUN set -ex \
  && for key in \
    94AE36675C464D64BAFA68DD7434390BDBE9B9C5 \
    FD3A5288F042B6850C66B31F09FE44734EB7990E \
    71DCFD284A79C3B38668286BC97EC7A07EDE3FC1 \
    DD8F2338BAE7501E3DD5AC78C273792F7D83545D \
    C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8 \
    B9AE9905FFD7803F25714661B63B535A4C206CA9 \
    56730D5401028683275BD23C23EFEFE93C4CFFFE \
    77984A986EBC2AA786BC0F66B01FBB92821C587A \
  ; do \
    gpg --keyserver hkp://pgp.mit.edu:80 --recv-keys "$key" || \
    gpg --keyserver hkp://keyserver.pgp.com:80 --recv-keys "$key" || \
    gpg --keyserver hkp://ipv4.pool.sks-keyservers.net --recv-keys "$key" || \
    gpg --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys "$key" ; \
  done

鍵について深掘りたい方はこちらを見るとよいかも。 https://github.com/nodejs/node#release-team

んでもって、やっとnodeをインストール。実行出来るバイナリをそのまま落とすのでチェックサムする必要があるのと、cpuのアーキテクチャに合わせたバイナリを引いてこないといけないので、アーキテクチャを調べるコマンドを変数にもたせてurlに含ませたりしている。

ENV NODE_VERSION 8.9.4

RUN ARCH= && dpkgArch="$(dpkg --print-architecture)" \
  && case "${dpkgArch##*-}" in \
    amd64) ARCH='x64';; \
    ppc64el) ARCH='ppc64le';; \
    s390x) ARCH='s390x';; \
    arm64) ARCH='arm64';; \
    armhf) ARCH='armv7l';; \
    i386) ARCH='x86';; \
    *) echo "unsupported architecture"; exit 1 ;; \
  esac \
  && curl -SLO "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-$ARCH.tar.xz" \
  && curl -SLO --compressed "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc" \
  && gpg --batch --decrypt --output SHASUMS256.txt SHASUMS256.txt.asc \
  && grep " node-v$NODE_VERSION-linux-$ARCH.tar.xz\$" SHASUMS256.txt | sha256sum -c - \
  && tar -xJf "node-v$NODE_VERSION-linux-$ARCH.tar.xz" -C /usr/local --strip-components=1 --no-same-owner \
  && rm "node-v$NODE_VERSION-linux-$ARCH.tar.xz" SHASUMS256.txt.asc SHASUMS256.txt \
  && ln -s /usr/local/bin/node /usr/local/bin/nodejs

最後にyarnを入れる。yarnはjsなので、ダウンロードしてきて配置するだけでOK。ただ圧縮されたファイルから、gpgで復号化している。

ENV YARN_VERSION 1.3.2

RUN set -ex \
  && for key in \
    6A010C5166006599AA17F08146C2130DFD2497F5 \
  ; do \
    gpg --keyserver hkp://pgp.mit.edu:80 --recv-keys "$key" || \
    gpg --keyserver hkp://keyserver.pgp.com:80 --recv-keys "$key" || \
    gpg --keyserver hkp://ipv4.pool.sks-keyservers.net --recv-keys "$key" || \
    gpg --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys "$key" ; \
  done \
  && curl -fSLO --compressed "https://yarnpkg.com/downloads/$YARN_VERSION/yarn-v$YARN_VERSION.tar.gz" \
  && curl -fSLO --compressed "https://yarnpkg.com/downloads/$YARN_VERSION/yarn-v$YARN_VERSION.tar.gz.asc" \
  && gpg --batch --verify yarn-v$YARN_VERSION.tar.gz.asc yarn-v$YARN_VERSION.tar.gz \
  && mkdir -p /opt/yarn \
  && tar -xzf yarn-v$YARN_VERSION.tar.gz -C /opt/yarn --strip-components=1 \
  && ln -s /opt/yarn/bin/yarn /usr/local/bin/yarn \
  && ln -s /opt/yarn/bin/yarn /usr/local/bin/yarnpkg \
  && rm yarn-v$YARN_VERSION.tar.gz.asc yarn-v$YARN_VERSION.tar.gz

ちなみに、これらインストール方法では/usr/local/binにバイナリだったりソースコードだったりを置いている。

この辺以外にも、例えば/binディレクトリは色んな階層に置かれていたりするんですが、その辺の内訳はこのページがわかりやすかったです。

www.atmarkit.co.jp

最後に、何も指定が無ければnodeコマンドが起動されるようになっている。

CMD [ "node" ]

起動してみる。起動の仕方はこのページが詳しい。

https://github.com/nodejs/docker-node/blob/master/README.md#how-to-use-this-image

とりあえずHello worldしてみる。

$ docker run -it --rm node:carbon
> console.log("Hello world!");
Hello world!
undefined

お。動いた。(そしてインタラクティブなコンソールがあることを初めて知った。)

バイナリのディレクトリにそれぞれもちゃんと置かれているし、nodeコマンドもちゃんと効く。すごい。

$ docker run -it --rm node:carbon /bin/bash
root@462127feff1e:/# ls usr/local/bin
node  nodejs  npm  npx  yarn  yarnpkg
root@462127feff1e:/# node
> .exit

npmやyarnもちゃんと動くー。Dockerすばらしい。

$ docker run -it --rm node:carbon /bin/bash
root@f57a34c0b0e4:/# npm -v
5.6.0
root@f57a34c0b0e4:/# yarn -v
1.3.2
root@f57a34c0b0e4:/# node -v
v8.9.4

どうやってこのイメージを使っていくのがいいですよ系の話はこちらにまとまっているっぽい。

https://github.com/nodejs/docker-node/blob/master/docs/BestPractices.md

ちょっとJSを触る気になった。

日常的に脳死でもコードが書き始められるようにした

ベタープログラマでcode kataという習慣が紹介されていて、

何らか問題などの簡単なきっかけでコードを書く機会を自分に投げてみる

という考え方が刺さり、やり方をいろいろ試している。 

gorlem.hatenablog.com

なにが刺さったのかというと、この考え方を応用すればwrite code everyday的な習慣を簡単に導入出来そうというところ。

John Resig - Write Code Every Day

これなら自分のコードを書くまでの腰の重さを解決してくれるのでは。と思わせてくれた。

 

自分にとってコードを書く、というと

  • 自分の解決したい問題を考えて
  • ほかに同じ問題抱えている人がいるかリサーチして
  • どんなソフトがいいかざっくりデザインして
  • 実現可能な技術リサーチして
  • 必要ならチュートリアル読んだりして
  • どういうプロトタイプにするか決めて
  • さあ、やっとコードを書くぞ

というあまりにも長いプロセスを頭の中に描いてしまっていた。

これだと、コードを書くよりもそれ以外の作業が重い・・・いやまあ使いたいソフトを作れたらそりゃあ楽しいんだろうけど、そこまで経験していないことも多いから、考えただけで面倒さが面倒でしょうがなくて、考えるのをやめてしまう。

 

というわけで、コードを気軽に書ける題材を見つけて、書けるだけ書いていき、どんどん腰の軽い状態を作っていこうというやり方をすれば解決できるんじゃないかとcode kataのコンセプトを見て思ったのだった。

 

実験第一弾として、積ん読になっていた本を題材に、そこに書いてあるコードを写経しつつ実行していくことにした。

写経用のリポジトリもつくった。

github.com

また、Dockerさえインストールされていれば環境に悩まされず気軽にコードを実行出来るようにしたので、書き始めるまでの敷居がものすごく低くなった。最初だけコマンド調べるのに苦労したけど、最終的に超ラクになったのでDockerすばらしい・・・。勉強しといてよかった。

https://github.com/gorlemkun/poodr#getting-started

 

しかしこれ、コードを書いているというよりも書き写している感じなので、これは本当にコードを書いていると言えるのか?と自分を疑うこともあったけど、書き写しなおかげで敷居を低く出来ている気がするので、最初はこれでもいいかなという感じ。

やってみたらやってみたで、本を批判的に評価しながら読めるようになったりして、頭に残りやすくなった気がするし、なんだか仕事で開発しているシーンでも即座に効き始めてしまっているので、いい効果はあるんだと思う。それだけ時間がかかるので、あまり読み進められないけども。

 

もうちょっと慣れてきたら本来のcode kata的な頭を使う問題に移して行きたいというのと、なにか新しい技術のチュートリアルとか、技術の選択肢を広げる方向性のcode kataも並行してやろうかなと模索中・・・やりすぎはやりすぎで挫折しやすくなるので慎重に・・・。

 

ひとまずはよかったぽい。この流れが続くとうれしい。

まんが 世界の歴史を読んだ

 

学研まんが NEW世界の歴史11 世界恐慌と第二次世界大戦

学研まんが NEW世界の歴史11 世界恐慌と第二次世界大戦

 

 かっこいい。とにかく歴史を動かしている人たちはかっこいい。。惚れ惚れするシーンが結構ありました。特にヒトラーとガチンコバトルしたイギリスのチャーチルがまじでかっこいい。表紙のひとです。

歴史は近代から読むのが個人的にはオススメです。なぜなら今の世の中と情報がつながっていて、どうして今こういうふうな世の中なのか、が分かるようになっていく体験がとてもおもしろいから。各国がどういう国かの印象も変わった。

また、最近読んだベタープログラマのような海外の書籍だと、著名人の引用が入ってることが多いのですが、その人の時代背景、どんな経験をもとに語ったことだったか、まで分かってしまう、というとても面白い経験ができました。

これはベタープログラマの中の引用そのまま。

成功は決定的でなく、失敗は致命的でない。大切なのは続ける勇気である。

ウィンストン・チャーチル

チャーチルに関してはもうすぐ映画が上映されるらしいですね。熱い。

www.churchill-movie.jp

歴史に関してはまじで興味が今まで全くなかったので、マンガ化されてることはかなりの救い・・・学研まじありがとうございますという気持ち。

 

 

関連

gorlem.hatenablog.com

 

ベタープログラマを読んだ

 

ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック

ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック

 

 

自分のプログラマとしてのやっていきかたを見直すきっかけにとてもいいです。よかったです。

この本はいい意味で考えさせてくれる問いがすごく入ってます。

一人でウンウン考えているだけだと、自分を振り返るための質問を作ったりして、建設的に自分なりの答えを作っていくのがかなり難しいと思うので、この本の質問にはかなり救われました。

ちょっと抜粋

 

チャレンジを楽しむ、より

  • あなたは、プログラミングに関して何に興奮しますか。今すぐに取り組みたいものとその理由を考えてみてください。
  • 古びたコードを生み出すために給与をもらうことで幸せですか。あるいは、卓越した成果を生み出しているという理由で、給与をもらいたいですか。
  • 賞賛を受けるために仕事を行っていますか。つまり、同僚やマネージャからの称賛を求めていますか。
  • オープンソースのプロジェクトに取り組みたいですか。コードを共有することで、あなたは満たされますか。
  • 新たな領域や新たな難解な問題に対する解法を提供する最初の人になりたいですか。
  • 知的訓練といいう楽しみのために問題を解きますか。
  • 特定の種類のプロジェクトで働きたいですか。つまり、ある種の技術があなたに適していますか。
  • ある種の開発者たちと一緒に働き、彼らから学びたいですか。
  • 起業家の視点でプロジェクトを見ますか。つまり、ある日、あなたを億万長者にすると思うものを追い求めていますか。

それぞれの質問の下に自分の回答を記述しながら読んでいくのがおすすめです。そして具体的に今日、明日から何しようか、というアイデアにつなげやすくなります。 

 

あと、code kataという習慣についての言及が自分の中で超新鮮でした。

簡単な練習問題を毎日解いて、日々練習し、武道における「型」のようなものを習得しましょう。という考え方です。まあスポーツとかだと当たり前だと思うんですが、ソフトウェアエンジニア的な文脈でこういうことを話してる人はあまり見たことがなかったです。

katakodaというブラウザ上のLerning Platformもおそらくこのcode kataに影響を受けているんではないかと思われます。

www.katacoda.com

そして提唱者は達人プログラマー著者の一人のDave Thomasさん。すごいです。自分なりにいいやり方を考えて、やっていこうと思いました。

codekata.com

Docker HubのRuby公式イメージを深掘る

 

gorlem.hatenablog.com

 

環境構築シリーズ続き。

前回色々調べた&調べ方が分かったことによりDocker Hubに置かれている色々なイメージがどんなもんかざっくりとわかるようになっているはず。

https://hub.docker.com/

自分でDocker上に構築していく道も考えたが、まずは先人のやり方をみていくことにした。

Rubyの公式イメージ

https://hub.docker.com/_/ruby/

ruby:<version>

This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of. This tag is based off of buildpack-depsbuildpack-deps is designed for the average user of docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system. 

ruby:2.4 などのバージョン番号以外何も付かない単純なバージョン指定で落とせるイメージがDocker Hub上のデファクトで、まあ大体どんな用途でも最適化しようと思わなければこれで行けるよ、という意味なのだと理解した。またDebianが使われているっぽい。

 

公式イメージページにあるタグのリストから単純なバージョン指定で引いてこれるイメージを探すと・・・

このjessie?という名前のついたものが基本的なイメージらしい。

github.com

jessieの内容について深掘りするには、上記イメージ内の一番上の行に

FROM buildpack-deps:jessie

 とあるので、buildpack-depsのリポジトリを深掘りすると良さそうで、

https://hub.docker.com/_/buildpack-deps/

ここを見ると

とあり、一番下のがjessieで、ruby:2.4のイメージの元はjessie↓、

https://github.com/docker-library/buildpack-deps/blob/d7da72aaf3bb93fecf5fcb7c6ff154cb0c55d1d1/jessie/Dockerfile

 

そしてjessieのイメージの元はjessie-scm↓、

https://github.com/docker-library/buildpack-deps/blob/1845b3f918f69b4c97912b0d4d68a5658458e84f/jessie/scm/Dockerfile

 

さらにjessie-scmのイメージの元はjessie-cur↓lで、

https://github.com/docker-library/buildpack-deps/blob/d662dc69f910feb241f6d0c9d2cd6cc2fb6c5e6c/jessie/curl/Dockerfile

 

jessie-curlのイメージの元はdebian:jessie↓(ここでリポジトリが変わる)

https://hub.docker.com/_/debian/

https://github.com/debuerreotype/docker-debian-artifacts/blob/6af0f6159c515601731d92972a245199337e3ca6/jessie/Dockerfile

 

そしてdebian:jessieはというと、scratchからなので、やっとここでスタートとなる空ファイルに到達できる。(Docker Hubがscratchリポジトリという空のレポジトリを定義している。https://hub.docker.com/_/scratch/

そしてDocker Hubのdebianリポジトリの説明を見ると、

Stable releases are also tagged with their version (iedebian:8 is an alias for debian:jessie

とあるので、どうやらdebianの正式バージョンの8個目のものを指しているらしい。そしてdebian:jessieのDockerfileの中にある

ADD rootfs.tar.xz /

というのはdebian8のイメージを解凍して空のコンテナ上に置くことをしているはず。

・・・とrubyのDockerfileを調べる前に、そもそものFROMで指定しているベースイメージに何が入っているのか一通りざっくり調べてみると、

 

jessie-curl

ここまではapt-getに頼らずアプリインストールするための最低限の構成。

  • ca-certificate(証明書そのものを扱う)
  • curl(色んなプロトコルでデータ送受信)
  • wget(ファイルのダウンロード)
  • gnupg(ファイル暗号化)
  • dirmngr(証明書もろもろ管理サービス)
 
jessie-scm

ここまではおそらく外部リポジトリを扱えるようにするための構成。

  • bzr(バージョン管理)
  • git(バージョン管理)
  • mercurial(バージョン管理)
  • openssh-client(SSHリモートホストに接続)
  • procps(プロセス管理。psでプロセス監視したりプロセスkillしたりするやつ)
 
jessie

うーなんかいっぱいある。

まとめるとおそらく、外部からソースを落としてきてコンパイルして使えるようにするための構成だと思われる。

lib***系はLinuxでよく使われる共有ライブラリ群。たぶん。

autoconf, automake, makeあたりはCのコードをバイナリにコンパイルするのに使う。

  • autoconf \ automake \ bzip2 \ dpkg-dev \ file \ g++ \ gcc \ imagemagick \ libbz2-dev \ libc6-dev \ libcurl4-openssl-dev \ libdb-dev \ libevent-dev \ libffi-dev \ libgdbm-dev \ libgeoip-dev \ libglib2.0-dev \ libjpeg-dev \ libkrb5-dev \ liblzma-dev \ libmagickcore-dev \ libmagickwand-dev \ libncurses5-dev \ libncursesw5-dev \ libpng-dev \ libpq-dev \ libreadline-dev \ libsqlite3-dev \ libssl-dev \ libtool \ libwebp-dev \ libxml2-dev \ libxslt-dev \ libyaml-dev \ make \ patch \ xz-utils \ zlib1g-dev \
 
ruby

やっとたどり着いたrubyのイメージなんだが、見てみるとrubyのインストールしかしていない。

ただ、そのインストール方法がなかなか複雑・・・にみえる。ざっくり見た感じ、は

  • Rubyのバイナリが入った圧縮ファイルを落としてくる
wget -O ruby.tar.xz "https://cache.ruby-lang.org/pub/ruby/${RUBY_MAJOR%-rc}/ruby-$RUBY_VERSION.tar.xz"
  • 解凍する
tar -xJf ruby.tar.xz -C /usr/src/ruby --strip-components=1
  • コンパイルする
  • autoconf(コンパイル設定生成) -> ./configure(実際に設定) -> make(ビルド) -> make install(ビルドしたやつのインストール) の流れはよくあるやつ。
autoconf
gnuArch="$(dpkg-architecture --query DEB_BUILD_GNU_TYPE)"
./configure --build="$gnuArch" --disable-install-doc --enable-shared
make -j "$(nproc)"
make install

rubyの公式にもこの方法は一応ちょっと触れられている。

Building from Source

Of course, you can install Ruby from source. Download and unpack a tarball, then just do this:

$ ./configure
$ make
$ sudo make install

By default, this will install Ruby into /usr/local. To change, pass the --prefix=DIR option to the ./configure script.

Installing Ruby

  • bundlerをインストールする
gem install bundler --version "$BUNDLER_VERSION" --force
  • 色々環境変数設定する
  • GEM_HOME: Gemのホームディレクト
  • BUNDLE_PATH: BundlerがGemを入れるディレクト
  • それ以外は正直よくわかりませんでした・・・まあよしなに設定してくれているということで。
ENV GEM_HOME /usr/local/bundle
ENV BUNDLE_PATH="$GEM_HOME" BUNDLE_BIN="$GEM_HOME/bin" BUNDLE_SILENCE_ROOT_WARNING=1 BUNDLE_APP_CONFIG="$GEM_HOME"
ENV PATH $BUNDLE_BIN:$PATH

環境変数まわりはこの辺にもっとほかのやつが書いてある。

docs.ruby-lang.org

Bundler: bundle config

 

と、こういう手順。

 

・・・rubyのインストールよりもそれ以外が膨れ上がってしまった感があるが、

  • 根本のベースイメージにDebianが使われていたり
  • 基本的なソフトがrubyインストール前段階でいくつか入れられていたり
  • rubyがソースコードからインストールされていたり
  • gemまわりの環境変数が事前に設定されていたり

することを把握しておくと、今後のデバッグであまり困らない気がする。

 

はー。やっと終わった。やはり疲れる。1週間くらい記事を書くのにかかった。ただ、環境構築つらい問題は少しずつ解消されてきている気がする。しかしまだまだこれではアプリが書けないので、もう少しやっていこう。

毎日謎に疲れないための仏教とかマインドフルネスなどなどの分野についてまとめ

最近やけに疲れている症状が再発した。

色々調べると、仏教とかマインドフルネスがヒットして、色々本を読んだりしたので観点をまとめておきたい。

 

要はこれらは、頭で考えることの広さをいかに絞るか?に焦点が置かれた話題だと思う。

 

謎に疲れる原因

誰でも頭で考えようと思えばなんでも考えられると思っていて、

  • 自分のこと
  • 他人のこと
  • 世界のこと
  • 宇宙のこと
  • 過去のこと
  • 未来のこと

というように、ちょっと大げさめに出したが、本当になんでも考えられてしまう。

で、この幅を自分で抑制しようとはなかなか思えないために、考えすぎてしまい、謎に疲れる。ということが起きてしまうのだと思う。

単純に

  • 過去
  • 現在
  • 未来

をすべて考えた場合にしても、情報量にしては

  • 現在×3

の処理を頭でしていることになるので、そりゃ疲れるわな。と思う。

 

疲れないために

疲れる原因としては、

  • 一気にたくさんのことを考えすぎてしまう

があるので、頭で考えることの広さを絞る必要がある。

 

そこで仏教の考え方が使える。

例えば瞑想は、言葉を唱えたり、自分の間隔に集中することで、考える広さを絞れる。

 

で、これはなにも考えない極限の状態だと思うが、ずっと瞑想していると毎日暮らしていけないので、ここから

  • 何を最低限考えていくか?

を選び取っていくことで、余計に疲れない毎日の過ごし方が出来るようになるはず。

例えば、

  • 仕事している時は目の前のタスクに集中し、未来や過去のタスクは考えないようにする。
  • 考える場合は、考えるための時間をとり、またひとつのことに集中する。

など。

 

こういう例を出しちゃうと当たり前な仕事のスキルに見えがちなんだけど、この考え方を他人について考えるかとか、自分の感情について対応するかとか、色々な範囲に汎用的に適用していけることに気づけると奥が深いです。

どういう種類のものに対して、どういうルールを適用していくかは状況それぞれ、個人それぞれだと思うので、本を読んで考えて、自分なりのルールを作っていけばよいと思う。

実践してみたがとてもよかった。かなり生産性あがるし、省エネです。

 

参考書籍

シンプル・ライフ 世界のエグゼクティブに学ぶストレスフリーな働き方

シンプル・ライフ 世界のエグゼクティブに学ぶストレスフリーな働き方

 

ほかにも色々読んだが、この2冊で十分だと思う。

もとは宗教の考え方なので全部信じるのは危険で、取捨選択が大事。この分野は情報鵜呑みにするタイプの人にはオススメできないです。