大手町ビルの人気店。
本場の讃岐うどんに近い味が楽しめるので、重宝している。
昼時は混雑しているが、11時前半に行けば割と空いているので、待ちたく無い人は11時台に行くのがおススメ。
体験を重視するというのは当然だが、ではその体験を記録していくというのは、なかなか意識しないとしないもの。
特に忘れやすい自覚がある人間は、せっかくの体験も記録を残さず放置してしまうと、あっという間に忘却してしまい、体験を糧にすることが難しくなる。
ログというものが大事ではあることはわかっていても、なかなか徹底することは難しい。
逆にいうと、そこがちゃんと出来ると、より他の人より差別化出来るということでもある。
人間の能力はほぼその人の習慣で決まるというのが持論で、習慣になるかはほぼ目標設定で決まり、目標設定が達成できるかは、目標設定の妥当さと自身あるいは他人によるコーチングによって決まる。
本当のわずかな例をのぞいて、人間に個体差はそれほど多くない。 特に専門領域ほどその傾向が顕著。
急激な気候の変化や大雨で靴が濡れたことによる下肢の冷えにカラダが耐えきれず、体調を崩してしまった。
体調を崩すということはデメリットばかりだが、一方でカラダを休めることが出来る期間でもあるので、これをチャンスとばかりに、よく眠っておく。
風邪の時は、これがチャンスとばかりに、睡眠をとりまくったり、ストレスを解消するために過ごすほうが良いのか、明確に風邪をナスことだけに集中したほうが良いのか、どちらのがよいのだろうか。
常に緊張感を持って働いている人は前者、そうでなければ後者のほうが得るものが大きいのかもしれない。
最近ブログ記事を多めにかくようにしている。
文章力の向上やコーディング能力の向上を図りたかったからだ。
上達するためには毎日効果的な練習で持って文章記述を継続していく必要があるが、ひとまず効果的な練習は置いておいて継続させるのが目標だ。
Splatoonの上達もそうだったが、上達方について真面目に考え始めるのは、壁にぶち当たっときでも良いのではないか、ということ。
変に上達方法について考え始めると、練習時間が伴っていないのに、これだけ上達するにはどうしたらよいかということを考えているのになかなかなか上達しないのは、向いていないからだ、 という思考が出てきて、それが上達を遅くしてしまうからだ。
まずは絶対的な練習量を確保してから、効率的な上達方法を探るほうが総合的にみて得られるものが多いはずだ。
SNSを見ないようにして、ニュースなども基本的に移動中以外は見ないようにしたら、時間がものすごく有意義に使えるようになった。
ニュースをチェックすることの一番の弊害はその情報が今するべき作業に大してノイズとなってしまうことだ。 人によってはこれがノイズ隣らないが、私はこれの影響がものすごく大きいので、上記の縛りを導入することで、時間をものすごく有効に使えるようになった。
人の特性ごとに最適な解は違うわけで、人生の目的の内のひとつは、その人の最適解を見つけること、なのかもしれない。
最適解、もしくは最適解に近い答えややり方を見つけることで、ライフスタイルが大きく変わるということは、今までの経験からも何度もあったこと。
今後も最適解を見つけることを意識していきたい。
体調が悪いので軽めに。 軽いものであれば、逆にトレーニングしたほうが良い。習慣は出来るだけ維持したい。 * 腕立て 10×3 * 腹筋 10×3
ECSは AWSが提供する、kurbernetes・Swarmに似た、コンテナ管理サービスのうちの１つです。
普段開発環境でDockerを使用している方、kubernetes・SwarmなどでDocker Clusterを構築している方でも、ECS独自の用語などのため、混乱する方が一定数以上いると思います。
ここでは、そのような方を対象に*1、ECSの概要とECSで用いられる用語の概念について説明していきます。
前提として、dockerを使ったことがある人が対象です。
http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/Welcome.html
なにはともあれ、公式ドキュメントをしっかり読みましょう。 ECSは日本語ドキュメントがしっかり用意されているので、効率の面から言ってもまずは日本語資料を読み切ってしまいましょう。
ECSで使われる コンテナ という用語は、Dockerで使われている コンテナ と同等の意味ですので、ここでは解説しません。
ECSで使われる イメージ という用語は、Dockerで使われている イメージ と同等の意味ですので、ここでは解説しません。
普段使っている例で言うと、docker-compose.yml の記述に近い。
実際に、 ecs-cli では、 docker-compose.yml の形式で記述したタスク定義を、ecs-cli compose コマンドでdeployすることが出来る
実際の例で説明すると、docker-compose.yml で定義したタスク定義をインスタンス化したもの。
ECSクラスター上では、タスクを最小単位として、ECの実インスタンス上にタスクが配置される。
上述のタスクはスケジューリングが出来るため、例えばバッチ処理は、スケジューラでタスクを定期実行することで実現できる。
タスクが実行される環境をまとめた概念。 実装上は、複数のEC2インスタンスをグループ化して、同じグループ内では共通インターフェースを通して協調できるようにしたものと言える。
クラスター内のインスタンスでタスクのスーパーバイザーとして動作し、タスクの管理、Docker レジストリからDっockerImageのプル、ECSコンソールや ECS APIを介してのECSからの制御を受け付ける。
ECS は EC2 上で動作するEC2 上では、 タスク のスーパーバイザーとして、 コンテナエージェント が動作しているタスク定義 をテンプレートとして、 タスク が生成され、 タスク を管理しているのが コンテナエージェント で タスク は コンテナエージェント を介して、 クラスター 内の他のタスクと協調動作をする*1:実際は自分の理解の確認とメモという側面が大きいですが
tmux に reattach-to-user-namespace' した際、新規ウィンドウ名が全て、reattach-to-user-namespace' に設定されてしまいました。
消去などでリネームの手間がかかるため、任意のデフォルト名を設定する方法を調査しました。
ほぼやりたいことが、 Stackoverflow で書かれていました。
何通りかやり方があるのですが、今回は、 .zshrc の末尾に、 printf '\033kdefault\033\\' を追記することで解決しました。
これは何をしているかというと、tmux では新規ウィンドウを作成した際に、シェルを起動するため、zshの場合は、$HOME/.zshrc を読み込みに行きます。
そこでシェルのprintf 関数で tty にエスケープシーケンスを送っています。
\033k が ESC [ に相当し、 非表示文字のエスケープシーケンスの始まり、
\033 が ESC ] に相当し、非表示文字のエスケープシーケンスの終わりを現します。
これらのシーケンスをtmuxが解釈し、ウィンドウ名に設定しています。
大学時代の後輩に誘われて、技術書典3に行ってきた。
入館料無料でUDXアキバ・スクエアで開催されていたこともあり、特に迷うことも無かった。
展示スペース自体はそれほど広くないため、入場制限が行われていた。
ある時間帯までは整理券が特定の番号以下の人しか入場させないことにより、入場制限を行っていた。
まず整理券をもらう。
許可されている整理券番号の範囲が、時間に応じてスタッフから告知されるので、それに従って入場する。
再入場用のスタンプが押されたり、カタログや電子決済が出来るアプリが配布されていたりと、イベントの規模にしては、やたらとツールが充実している。
技術者向けイベントであり、運営スタッフも技術者が中心であるから、このようにツール類もこだわっているのだろう。
コミケなどにもこの辺りのツール導入されるとよりコミケ運営も効率化されるのかもしれない。
さて、イベント自体について。
歩いてみてわかったが、やたらと知人に会う。
元同僚だったり、勉強会イベントで知り合った人、あるいは現在の関係会社の人だったり。
自分の交友関係の広さなのか業界自体が狭いからなのか。
自分はさほど技術者的な意味での交友関係は広くないので、後者だろう。
フロントから低レイヤー・ハードウェアまで記事の内容は多岐にわたる。
結局、私はたまたま友人が運営していたサークルを見つけて記念に(と言ってしまうといささか失礼かもしれないけど)１冊買っただけだった。
この手のイベントは参加するなら、買う方よりも、売るほうがみのり多そうなので、もし次回参加するとしたら売る方で参加したい。
最近技術コミュニティには所属しておらず勉強会にもあまり顔を出していなかったが、このようなイベントに参加すると、 エンジニアとしてのやる気が喚起されるのが良い。
最近、少しばかりエンジニア的な意欲が失われていたので、モチベーションを維持するためにも、このような技術的イベントに積極的に参加したほうが良いのかもしれない。
なにはともあれ、誘ってくれた元後輩には感謝したい。
眠い時にやるべきこと
何故かshell scriptの構文がなかなか覚えられなくて、書くたびにWebのリファレンスを参照している。 一度shell script付けになる必要性を感じる。
あと、はまりどころも多い。
if [ ! $HOGE ]; the といった場合に、 ! や $HOGE の前後にスペースが必要なのは割りと罠だ。
以下のことを行いました。
自身の特性に合った入出力方法を確立し、出力の質と量を最大化するため。
人によって、最適な情報の入出力方法は変わります。
なぜかというと、人によって脳の特性に違いがあるからです。
コンピュータで例えると、例えばメモリは潤沢にあるがCPU性能が低い、あるいはメモリ容量は少ないがCPU性能が高い、などです。
人間には効果的な反復練習により形成される高速なディスクストレージ・思考のキャッシュがあるので、ある特定の作業を効果的な練習方法で継続していれば、個々人の能力差というのはそれほど大きくならないというのが持論です。
効率的な入力を心掛けないと、ネットワークの形成が遅くなったり、あるいはネットワークの忘却の方が早くなってしまい、いつまでたってもネットワークが強くならないという問題があります。
そのため、どれだけ効率的な入出力を行うかということが、すなわちその人の能力を決定づけるということになります。
個人によって、このネットワークの形成の最適な方法は変わるため、自分に最適な入出力方法は、何度も試行錯誤して修正していくしかありません。
これらの試行錯誤は長年行なっていますが、ログとしては残していなかったため、試行ログを残すために、現在このブログを書いています。
まず自身の特性を知ることが重要です。
自身の特性として以下のものがあります。
CPU性能は普通以上にある。
メモリ性能は劣悪
入力に対するデフォルトフィルターが未熟
これらの特性の上で、自身の最適な入出力方法を決定する必要があります。
そのまえに補足です。
入力に対するフィルター機能が未熟であるということはどういうことかというと、重要度の高い情報と低い情報を瞬時に判断する能力が未熟であるため、どの情報も並列にとらえてしまい、煩雑な情報が多くなれば多くなるほど、思考速度が衰えます。
そのため、元となる入力情報をシャットアウトすることが必要です。
PCを使った作業で、より重要度の低いと思われる情報は以下の通りです。
プッシュ通知
Slackでのやり取り
これらの情報をシャットアウトすることで、より現在の作業に集中することができます。
音楽については、逆に作業に取り掛かるまでの初期コストを下げたり、飽きるのを遅くする効果、単純作業でも長時間維持できる効果などがあるので、ときには必要な情報になったり、時にはノイズとなる情報で、扱いには注意が必要です。 導入の際にのみ音楽をかけるなど、色々工夫が必要です。
デメリットとしては、必要な情報さえシャットアウトしてしまうことで、持っている情報がアンバランスになってしまうことです。
特にエンジニアにとって最近の重要技術について触れ合うことは重要なので、これらは死活問題となる可能性があります。
ただし、一方でそれらの情報をまともに入力してしまうと、頭がパンクしてしまい、本来集中して考えるべきことさえ集中できなくなるリスクもあります。
リソースが足りない場合、より深いところを学ぶことを意識するならば、そのような表面的な必要な情報をある程度シャットアウトするのも仕方ないと考えることができます。
以上のことを踏まえた上で、しぼった入力・出力チャンネルは以下の通りです。
書籍
Web上の一時ドキュメント
1行ニュース(5分など軽い待ち時間が発生した際に取得)
ローカルメモ
２月以降に読んだが、ブログに書いていない書籍一覧。 マンガ、雑誌は含んでいない。
したたかな寄生 脳と体を乗っ取り巧みに操る生物たち (幻冬舎新書)
筋トレが最強のソリューションである マッチョ社長が教える究極の悩み解決法
“内向型”のための雑談術 自分にムリせずラクに話せる５１のルール (大和出版)
IPad Pro用のキーボードを買ったのですが、すこぶる快適です。
ちょっとした空き時間にBlog記事を書けるので重宝しています。
iPad Proには Apple Pencilと純正専用キーボードが必須ですね。
私は知り合いと鉢合わせすることが多く、かならずわたしから発見する。
注意力がいつも散漫なわりには、毎回自分から発見するのが謎ではある。
ADHDのなくなった母も同様の能力をもっていたが、ADHDに特有のなにかがあるのだろうか。
触ろうと思いつつ、なかなか触っていなかったscalazをやりはじめました。
Tutorialが充実しているのが素晴らしいですね。
ルーチンに組み込んでいきます。
成功体験は以下の要素により構成されます。
成功体験はこれらがセットになって初めて生まれるため、例えば漫然と8時間毎日勉強して合格に近い大学を受け合格するのと、志望校を設定して受かるためにプロセスを細分化して勉強して合格してきた人を比べた場合、後者の方が圧倒的に成功体験の質や数も多くなります。
この成功体験が足りないと、すぐ諦めてしまったり、投げ出したりしてしまい、これが更に成功体験を得る機会を奪っていきます。つまりスパイラルに陥るということです。
自信がある状態とは過去の経験から以下のことを達成できると思っている状態のことです。
いずれも成功体験が必要ですが、目標設定と至るまでのプロセスと達成が無いと成功体験にはなりえません。
その為、自信を得るとは、目標設定と目標を実現するためのプロセスを実行し、達成することに他なりません。
目標設定〜達成までのセットをいかに効率的に増やしていくかが重要になります。
成功体験を増やすということは、何かしらのゲームにおいてゴールを設定し、そのゴールまでの攻略法を見つけ、達成するということです。
ゲームのゴールは、例えばノーベル賞を受賞する、TOEC900点を取得するなどがあると思いますが、成功体験の少ない人ほど細かい粒度で、
もののほうが良いです。
理由は以下のとおりです
スシコラで対スクリュースロッシャー戦でのデスが多いので、自分なりに考えた対策方法について述べます
正面からスクリュースロッシャーと打ち合うとかなりの確率でデスします。
キル速自体はスシコラの方が強く、射程もほんの少しだけスシコラの方が長いのですが、 スシコラ側のエイムがブレると、スクスロの方がダメージ範囲が大きいため、デスする確率が高くなってしまいます。
サイド・バックから狙うことで、キル速・塗り性能の差、相手がこちらに反応するまでの遅延時間によって、こちらが一方的にキルを取りやすくなります。
サイド・バックから狙う際に、相手が翻して返り討ちに合うことがたまにあります。 もし相手がこちらの攻撃に気が付いて相手が回避行動と反撃をしてきたら、潜伏しつつ相手のミスショットを誘ってから攻撃することで、デスが少なくなります。
中距離では撃ち負ける確率が高いですが、近距離ではスシコラのほうがキル速が早く有利です。
塗り性能もスシコラのほうが良いため、塗り勝ってから距離を詰めてのメイン射撃で、キル出来る確率が高くなります。
スクリュースロッシャーのスペシャルはハイパープレッサーですが、敵陣に切り込んで使うメインと後方で狙撃するタイプのスペシャルとでは相性はいまいちよくありません。
ハイパープレッサーはメインブキへの切替えも出来ないため、スペシャル発動中のスクリュースロッシャーは格好の的です。
相手もそれを見越してあまり敵前でハイパプレッサーを撃つことはないと思いますが、もし偶然見かけた際は忘れずキルを取っておきましょう。
背の低い障害物の後ろは一方的にスクスロが有利となるので、スクスロ射程範囲内で、背の低い障害物の背に隠れない。
本来、スシコラはスクスロに対して一方的に弱いということは無いのですが、個人的に対スクスロ戦でデスが多くなることが多かったので、対策方法について考えてみました。
もっと良い対策方法などあれば募集中ですので、お気軽にコメント下さい。
tmux/screen 上で nvim を使用した際に、 escape/Ctrl-[ 入力に対するレスポンスが遅いため、これを解決する方法について記述します。
tmux/screen 上で nvim のescapeレスポンスを早くする$HOME/.tmux.conf 上で 以下の設定を追記する
set -s escape-time 10
screen の場合は、以下の設定を $HOME/.screenrc に追記します。
maptimeout 10
vimなどで、 escape-time を 0 にしている例をよくみかけますが、nvimの場合0だとうまくいかず、 10程度のdelayを必要とします。
tmuxではEscape入力があった際に、500msec のディレイの後にバックグラウンドのターミナルにコマンドを送信している。
上記の設定ではこのディレイを極端に早くすることで、キー入力の直後にバックグラウンドのターミナルにEscapeコマンドを送信している。
エンジニアが意識するべきことを列挙する
純粋に楽しめる分野について目標設定を行う。
苦行にならないように、飽きが来ないように問題を設定する。
技術領域は多岐にわたるため、自分が知らない技術があるからといって、不安になって学習計画を変えたりしない。
必要な知識なら、その後の学習計画に加えればよいだけだし、不必要な知識なら学習しなくても良い。
仮に基礎的なコンピュータサイエンスの知識と現在流行りの技術があり、どちらかを選択する場合には、基礎的な知識の学習を優先する。
記事の執筆やコミュニティ活動それ自体はエンジニアリングとは関係がない。
あくまでエンジニアリングの副次的なものとして考え、それが目的にならないようにする。
設計をせずに行き当たりばったりのコードを書いていても、コーディングスピードや設計能力は向上しない。
思考とコーディングは個別に考え、同時には行わない。
ユニットテストがない状態では、デバッグのコストはプログラムの規模が大きくなるほど指数的に大きくなる。
ユニットテストを書くことで、デバッグのコストの増大を線形に抑えることが出来る。
使いやすいデバッギングツールを使うことで、デバッグの速度を早くすることが出来る。
ちゃんとウォーニングやエラー出力を読んでから行動する。 読まないまま行動しない。
上記とは逆説的であるが、ツールに頼りすぎない。 すぐに解決できない問題は、あえてツールに頼らず、ロジックを追うことも重要。
何か調査事項があった場合に、一次ソースを明確にする。
出来ればQiitaやStack Overflowは使わないほうが良いが、使う場合も、一次ソースまで追った上で参照する
ドキュメントを読む時間と書く時間がどちらかに偏りすぎないようにする。
