眠れなくなるほど面白い自律神経の話を読んで実践したいこと3つ
最近、謎の不調が多く「自律神経のせいじゃない?」と思うことが多かったので読みました。
年齢を感じますね。
実践したいこと3つ
朝1杯の水を飲む
胃腸の動きによいということは知っていたのですが、自律神経にもよいことを知りました。
こんな些細なことで健康に近づけるなら喜んでやります。食事の間隔を5時間程度あける
じつはこれ、テレワークになって結構できてないところ。家にいるので小腹がすくとついつい食べてしまうんですよね。
胃腸にもよくないし、自律神経にもよくないようなので、やめましょう。食べる時間を決めて規則正しく生きないとなと思います。若くないもんね。1日1か所掃除する(30分以内)
部屋がきれいだと気持ちいい。その通りだと思いますが、ずぼらな自分は後回しにしがち…。
子供も掃除しないので、毎日お掃除タイムを設けて子供も片づけ、自分も掃除の時間を作ってちょっとずつきれいにしていきたいなと思いました。
感想
全体的には「これ、どこかで見たことある…」という内容がおおいのは否めませんでしたので、初心者向きの本かと思います。
でも知っているのに実践してないよね?ということが再確認できたので、これを機に実践にうつそう!と考えるきっかけになったのがよかったです。
アウトプット大全を読んで実践いたいこと3つ
元々気にはなっていたのですが、前回インプット大全を読んでこちらも読んでみたい!と思ってすぐぽちって読みました。
インプット大全で実践したいことの1つ「すぐ読む」をさっそく実践して購入即読書開始。
やってみた感想、買ってすぐは読む意欲がすごくて勢いよく読めました。途中ちょっと仕事が忙しく読書時間がとれずに間が空いてしまうと、読書スピードが落ちたのを感じます。
さて、今回は3つ以上実践したいなと思うことがあったのですが、これまたインプット大全で学んだ通り、あえて3つに絞ります。
また「自分の人生に総じて役に立ちそうなこと」ではなく「今の自分に必要なこと」に焦点をあてて3つを選びました。なので「俺ならこの3つは選ばないな~」という人は多いかもしれません。
実践したいこと3選
いいこと+注意orしてほしいことorどうしたらいいか考えようで伝える
話し方のアウトプットです。ほかの書籍でも見るような内容ではあるのですが今の自分にはとても必要なことです。
仕事ではリーダークラス、家庭では子育てをしているのでどうしても注意や叱ることが多くなっています。
そんなときついつい注意から入ってしまうんですよね…。リアルタイムに必要になる習慣なので、相当意識していないと実践していくのは難しいです。なので改めて意識するためにこちらにあげることにしました。開始前に質問する(暗記より前に問題解く)
今まで自分は10数年間、資格を取るときには必ず教科書を読み終えてから問題に取り組んでいました。資格のためだけに問題を解いて覚えていく、というのが気持ち悪かったんです。
それを今勉強しているPM試験からガラッと変えました。問題から入ってます。もちろんだいたい不正解です。
正直PMはとりたくてとるわけではなく、上から言われて仕方なく…です。興味がないし、苦手分野で楽しくないので教科書だけ読んでもちっっっとも頭に入ってきませんでした。でも問題から入って不正解していくと、いきなり教科書を読むよりは頭に入ることを実感しました。
まず、なんで不正解なのか?という疑問が生まれるので、多少の興味がでてきます。解説を見て、ああそうなのかと思いながら自分でメモにまとめていくのもいいです。最初から図が与えられるより、自分で図にしていく方が圧倒的に頭に入っていく感があります。
自分で頭の中に地図を作っていっているような感覚で、問題を解いて勉強していく方法の方が正直楽しいなと思います。大変おススメです。とにかく完成させてからブラッシュアップ
このブログを書くときに、まさにこの方法で書くようにしたいなと思いました。
ついつい途中でなんどもプレビューして確認して、書き直して…でなんだかんだ結構時間がかかっているんですよね。こんな稚拙な文章なのに…。
そのほか仕事や趣味なんかにも使えそうだなとおもっています。今まさに実践1回目なので、効果のほどはまだわかりません。
感想
インプット大全と同じくこちらもビジネス書をいろいろ読んでいると見たことある…みたいな内容が多いのは確かです。
でも何より読みやすい、なので頭に入りやすい。トピックごとにページが分かれているので、読み返しやすくもありそうです。
子供が大きくなって勉強するようになったら、この本渡して「いきなり問題解け」と教えたいなと思います。(数学とかも公式覚える前に問題解いて意味あるのかな??
インプット大全を読んで実践したいこと
インプット大全を読みました。有名なのはアウトプット大全の方なのかなと思うのですが、知識を吸収するのが好きな自分はインプット大全から読ませていただきました。
読んだ結果、知識を吸収しても定着させるにはアウトプットも重要なので、アウトプット大全も読む必要がありそうだな!と感じました。なのでさっそくポチりましたよ。
実践したいこと3つ
アウトプット前提でインプットする
ビジネス書、IT書籍については読んだ後このブログでアウトプットするようにしているのですが「アウトプット前提」では読めていないなと思います。
読みながら気になる点をメモしていて、それを参考にブログを書いているのが現状です。ここは誰かに伝えたいかも!という視点で読むともう少し深く読むことができるかも、と今は考えています。すぐ読む
自分は本を買って満足してしまうタイプ。読みたいなと思って買ったのであれば、すぐ読まないとダメですよね。
読みたい!の熱があるうちに読んだ方が読み進めるのも早いし頭に入ってきそうです。
仕事やプライベートの関係で100%の実行は難しいのですが、できる範囲でやりたいと思います一度に覚えられるのは3つまで
例えば、セミナーに行って何でもかんでも覚えようとすると、結果何も覚えられずに終わってしまう。でも3つに絞ると覚えられる。
というような内容です。これに関しては自分も身に覚えがあり、今後研修を受けたら3つに絞って記憶していきたいなと思っています
感想
今回は一言一句よむというよりはちょっとななめ読みしたので完読が早かったです。
ほかのビジネス書で読んだことあるなという内容もちらほらありましたが、復習にもなりましたし、読みやすかったので知っている内容でも苦痛には感じませんでした。
良書なので、本棚にきちんとしまわせていただきました。
OS移行後にCSVの文字コードが変わってしまった件
CentOSからUbuntu、RedHatにサーバ移行していますか?
もうすぐEOSLだというのに、いまだOS移行案件が複数走っているわが社ですが、その際に起きた事象を紹介します。
事象
現行環境だとSJISで出力されるファイルが、新環境だとUTF-8で出力されていた
結論からいうと
cronからバッチを起動した場合、バッチ内で利用しているnkfコマンドが権限エラーで実行できていませんでした。 バッチを直接実行した場合とcronから起動した場合に権限が違うからです
cronから呼び出されるバッチは、ちゃんとcronから起動してテストしつつ /var/log/cron のログも確認しようね というのが教訓です。
調査ログ
現行と新環境で文字コードの違いを発見したときに、nkfコマンドで変換していて、それが上手く動いていないということはshellを見てすぐにわかりました。
- 新環境で手動でnkfをたたいてみる → 文字コード変換が正しく行われるので、nkfが使えないわけではない
- 新環境で手動でバッチを実行してみる → 文字コード変換が正しく行われるので、バッチからnkfが使えないわけではない
- 新環境でcronからバッチを実行してみる → 文字コード変換されないので、cronが悪いらしい
- /var/log/cronを確認する → nkfコマンド実行時にエラーがでている
という感じで比較的簡単に原因特定はできました。
感想
cron設定でうごくものはcronから起動して試験する、という基礎ができてなかったなと思います。
これに関しては知っていたはずなのに、それをメンバーに周知徹底できなかった自分の落ち度だと思います
次は同じ失敗しない…!
1on1やコーチングのメモまとめ
やりたい!と思い何冊か読んだのですが、いまだ実践にうつせておらず… そろそろやろうかなということで、これをやっていこうという部分を一度まとめたいと思います。 実際やってみている要らないがあれば更新していきたい。
1on1始める前の心得
- 傾聴、相槌、反復する
- 自分が伝えたいことを伝える、自分が聞きたいことを聴く場ではない
- 相手の意見を肯定する(同意する必要はない)
1on1をどう進めるか
- 目標を明確化、現状を明確化、ギャップを分析
- 目標を決める手がかり
- これまでどんな仕事をしてきたか
- 何をしてる時が楽しかったか
- 譲れないこだわり
- 何を大事に生きてきたか
- 侵食を忘れるほどの趣味はあるか
- 目標を決める手がかり
- 話すテーマから決めてもらう
- コミットすべきものを引き出す(いつまでにやる、どうやって進めるというところまで)
- 時と場合により以下のいずれかを選択して進めていく
質問例
※質問したあと相手が沈黙していたら考えているのでせかさない
- 身につけるべきものを問うとき
- 理想に近づくために、自分に必要なものは何ですか?
- 自分が今持っている知識やスキルで使えそうなものは何ですか?
- 行動の視点
- やろうと思っていて、実行できていないことは何ですか?
- 目標を、達成するために、今日からできることは何ですか?
- 次回までにどんなことをやりますか?
- 考え方の視点
- 大事にしている価値観は何ですか?
- 作業の振り返りの際
- 成功した要因は?
- 成功したときとの違いは?根本的な原因は?
- 今回の経験から何を学んだのか
世界一流エンジニアの思考法を読んで実践したいこと3選
去年話題になっていた本をようやく読みました。面白かったです。
自分の軸足は今はマネージャー側にあるので、エンジニアに対してこう接したらいいかもという視点で読んでみたり、いつかエンジニアに戻ったときには…(願望)という風に読んでいました。
実践したいこと3選
- 楽しんでいるかを重要視する(楽しい仕事は生産性が高い) → ほんとこれ
- 時間がかかっても整理する。仕事効率超アップ → 日々の作業消化だけに翻弄されない
- 難しすぎるのは、基礎が足りていないか、脳の使い方が間違っている → 基礎力をつける。つけてもらう
感想
外国での話をベースにしながら、日本のIT業界についても言及されているのがとてもよかったです。
ただ、こういう本を読むと考えることがあって、いつもいつも本の通りにはできないという結論に至ってしまいます。
それは「家庭」「家族」のことです。
「自分の幸せを考えよう」と言われても、子供の幸せを最優先に選択すると自分が幸福になれる選択肢(転職)をとれない。どちらも幸福になれる選択肢がよいのですが、それにはリスクを伴うのです。
リスクをとってでも幸福を追い求める勇気が自分にはないので、結局現状維持を選び自分の幸せは後回しになります。
そうなること自体に文句はありません、安定と子供の幸せを最優先をとることが自分にとって最も良い選択肢だからです。
家庭の事情は人それぞれなので、事例をだされても自分には当てはまらないとは思うのですが、お子さんがいらっしゃる方はどうしているのかな、というのが知りたいです。
とりあえず今は、今の環境で少しでも幸せになれるように動いていくしかないのかなと思っています。
謎のServiceUnavailableの原因を追え!
CentOS7のEOSLが近づいてきて、SIerの皆様はOS切替に奔走していることと思います。
弊社でも複数のOS切替案件が動いていて、その際発生したServiceUnavailableの原因調査に悩まされた話をします。
前提知識・条件
ServiceUnavailableとは
503エラーです。サーバが「ちょっとこれ以上働けないから無理です」っていう状態です。
構成
ロードバランサ1台、その先にアプリケーション用のサーバが3台います。
WebサーバはApache、アプリケーションサーバとしてTomcatで動いています。
なお、すべてのアプリケーション用サーバの性能・設定は同一になっています(設定ミスってなきゃ…)
ServiceUnavailableの発生条件
クライアント側でボタンクリック後60秒で発生している。3台すべてのサーバで発生する。
調査順
順を追って調査していきます。
Tomcatのログを確認する(catalina.out、gcログ)
503エラー、つまりサーバの処理能力の限界ということらしいのでまずtomcatのログ周りを確認しました。
gc頻発しているとか、Exceptionとか何かしらのログがあると思ったのですが、ServiceUnavailable発生時刻には何のログもありませんでした。Apacheログを確認する(http、errorログ)
503エラーを返している。つまりhttpのログとして503が記録されているのではないかと思い、ログを追います。
しかし該当時間に503を返しているログがありません。
はて、どこでServiceUnavailableが発生しているのでしょうか?Tomcat、Apacheの設定を確認する
先述した前提条件にある通りServiceUnavailableはボタンクリック後60秒で発生しています。ですので、どこかの設定で『60秒経過したら503にする』というタイムアウト的な設定が入っていると考えました。 しかし、どこにも『60秒』の設定がありませんでした。LBのログを確認する
LBのログにも何もでていません。完全な無風状態でした。正直、この時点でLBが怪しいと思っていました。Tomcatが503を返したのであれば、Apacheのhttpログに503エラーが記録されるはずだと考えていたのでTomcatの可能性は非常に低いです。Apacheが503を返したのだとしても、やはりhttpログに503が記録されそうな気がします(検証してないですが)
LBが犯人であることを特定する
LBが怪しすぎるので、アプリケーション用サーバにLB経由ではなく直接アクセスできるように設定変更し、直アクセスで動作確認を実施しました。
すると、直接アクセスした場合ボタンクリック後60秒経過しても同様の事象が発生しなかったのです。 LBが犯人であることが確定しました!LBの設定値を見直す
各種設定を見直し、60秒の設定を無事発見しました。 設定変更すると無事ServiceUnavailableが発生しなくなりましたとさ、めでたしめでたし。
所感
振り返ってみると、当たり前の調査を順にやっただけだな?と思えるのですが、やっている最中は「どこで発生しているのかまじでワカラン」状態でした。
また、今でこそ多少の経験値があるので調査の次の1手が思い浮かびますが、これが5年目くらいの時に起きていたら「どこ調べたらいいの」状態で涙していただろうなと思い、記事にさせていただきました。アプリ開発者でも平然とインフラ寄りの仕事振られるのが辛いです。