Kafka on Docker なんだか二度目な気がするけれど気のせいです
docker-compose.yml version: "3" services: zookeeper: image: confluentinc/cp-zookeeper:5.5.1 hostname: zookeeper container_name: zookeeper ports: - "32181:32181" environment: ZOOKEEPER_CLIENT_PORT: 32181 ZOOKEEPER_TICK_TIME: 2000 broker: image: confluentinc/cp-kafka:5.5.1 hostname: broker container_name: broker depends_on: - zookeeper ports: - "9092:9092" - "29092:29092" environment: KAFKA_BROKER_ID: 1 KAFKA_ZOOKEEPER_CONNECT: "zookeeper:32181" KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://broker:29092,PLAINTEXT_HOST://localhost:9092 KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1 CONFLUENT_SUPPORT_METRICS_ENABLE: "false" cli: image: confluentinc/cp-kafka:5.5.1 hostname: cli container_name: cli depends_on: - broker entrypoint: /bin/sh tty: true networks: default: external: name: iot_network そういえば、先日知ったのですが！docker-compose コマンドが、Docker CLI にサブコマンド compose という形で実装されて docker compose ps ができるようになったらしいです。Usage を見ると docker-compose のほうが少しだけ Options の種類が多そうに見えるのですが、docker-compose で非推奨のものはわざわざ実装しないという方針のよう？
目標管理が上手な人になりたい 以前みたいに個人的な目標管理がうまく出来ていないなぁと思って
じゃあ、以前はどんな感じで目標管理していたっけ？と思い、見返してみました
https://suwa.home.blog/2019/10/20/%E3%82%84%E3%82%8A%E3%81%9F%E3%81%84%E3%81%93%E3%81%A8/
今後できれば半年以内にやりたいなあとおもっている内容です。
LT慣れする ハッカソン参戦 チューターやってみる 技術的な何かで30pほど書く＆製本 AWSの資格挑戦してみる OS自作 ラズパイで何か作る なるほど〜
きちんと期限を設ける 「やった・やらない」で、達成したかどうか分かりやすい目標を立てている そして「技術的な何かで30pほど書く＆製本」「AWSの資格挑戦してみる」この2つ以外は達成できている気がする。
あと、3年後や5年後の自分像もあると良いなぁ。
ただ「3年後にこうなりたいのに、やりたいことが出来ていない」みたいに、理想がガッチガチに固まりすぎると自分で選択肢を狭めてしまいそうな気もするんだよな、頑固だから・・。 今年の目標は「しなやかに」なので、理想と現実の折り合いをじょうずにつけながら走り続けられるようになりたいです。こまめに振り返ろう。
あと、目標に一貫性をもたせたい。例えば、5個目標を立てたところで、全部方向性が違うとボンヤリした人になってしまう気がする。つまり整理すると・・
半年後までに達成したい目標をたてる 「やった・やらない」が分かりやすいようなものにする 3年後、5年後の自分像も言語化する 目標には一貫性をもたせる。もしくは、共通項を見つけて「どうなりたいか」を自覚する ・・ってコト？！
ちいかわ構文も完全マスターしたい。
目標設定 半年後までに達成したい目標 英語: 自分の扱っている技術を英語で伝えられるようになる
そのためにやること mikan で毎日70単語→100単語は英単語を覚える Daily 英会話を続ける Blog も英語で書くか・・ 社会貢献: Django Girls や OSS 活動を通して社会貢献活動をする
そのためにやること Django Girls リポジトリのブラッシュアップ Django Girls の活動に引き続き参加する OSS へ貢献する 知識: より専門的な知識を深める
そのためにやること 知識のアウトプットのために、技術的な何かで30pほど書く＆製本 コーディングの練習をするために、自分で開発したツールを改善していく Lisp に入門して Emacs の設定を自分で管理できるようにする 英語ができるようなれば、Django Girls での翻訳作業にも役立つし、OSS 活動をする際にも英語は便利なので、使いこなせるようになりたいなぁ。
3年後、5年後の自分像 3年後には、英語のコミュニケーションや、自分のコーディングスキルに自信をもっていたい。より自分の理想に近い社会への貢献方法を模索して、納得のいく形で取り組めていたら良いなぁと思います。
5年後には、技術でやっていくのかマネジメントも視野にいれるのか自分の中でハッキリさせたい。あと多分、教えることが好きなので、何かしら教える活動をしていきたい。
目標には一貫性をもたせる 社会貢献を通して自分自身も成長していきたい感じなんだなぁと思いました。
2021の目標 昨年(2020年)の振り返りです。
A look-back 2020
2021年の目標は「体力づくり」でした。
2021年の半ばから週に2〜3日出社するようになったため、体力はついたかなと思います。
技術系イベント＆BLOG 以前は入門だったりハンズオンだったりのイベントに「広く浅く、とにかくたくさん！」という気持ちで参加していたのですが、だんだん専門的な内容を扱うようになるにつれて参加したい技術イベントの種類が減ってきたように感じます。
Kubernetes Middle Way
ふわっとしていた Kubernetes のネットワークについて、流れを把握することが出来ました。 Zapier
日常生活での課題を解決したい！→技術選定→設計→実装→試験→新たな課題
一連の流れを一つの BLOG でまとめることができました。
メール送受信の仕組みとプロトコルについて、学ぶモチベーションのきっかけになりました。 Customize my Terminal
バルタン星人にハマってターミナルに表示させてみました。 Contribute Anniversary
初めて OSS に PR を出して merge され、晴れて contributor になれました。
2021年で一番うれしかったです。 Django forms
久しぶりに Django Girls へ参加してきました。
チュートリアルの翻訳作業をもくもくとこなしました。
「何故スタッフとして参加するのか」ということを言語化できたので良かったです。 他には、Netlify 上でホスティングしていた当 BLOG を Vercel▲ に移行したり、Emacs の理解を深めるために Lisp 入門したりしました。
読んだ書籍 ITと数学
データをもとにして予測をたてていく行為を、ノートの上で数式をもちいて行うための本でした。例えば、一年間の月別平均気温のグラフを四次関数で仮定します。そこから、最小二乗法で誤差を小さくしていくために紙に数式を書いて実際に解いていきました。また、パラメータの値を求めるために、偏微分や合成関数だとかの公式を思い出しつつ解いていきました。
わたしにとって数学は現実逃避のための道具でしたが、数学を現実に役立てるために使う初めての経験でした。(本当に悲しいことがあったときは、読書をするより数学に没頭するほうが現実からより離れることができると感じます。)
後述する転職活動が思いのほか難航してつらかったので、この書籍で数式を解きながら現実逃避していました。
転職活動 転職活動、はじめはグダグダでした。
エージェントに登録してみたのですが
「とりあえず練習だと思って、多少興味の方向性が違っても面接を受けてみてください」
というアドバイスの通りに、何社か受けてみました。そして、興味がないので明らかに顔と態度に出てしまい、企業側も
「エージェント経由ということは何社か受けているとは思うのですが、その中で弊社を選んだ理由は何ですか？」
といった内容で質問をしてくるのですが、正直(うーん、何でだろう？)という気持ちで答えるので、まったく的を得ない回答しかできずに相手を困惑させたと思います。
そういった面接を50社近く受けました。だんだんと、面接する企業側に対して失礼だし、申し訳ないという気持ちが大きくなり、また(エージェントの『数を撃てば当たる』の転職方法は、わたしに向かないのでは・・)と、感じ始めたため、一旦エージェントを使わずに転職活動をしてみることにしました。
「本当に転職したい」
と心から思う、IT企業のSRE職に2社応募した結果、2社ともスムーズに内定を貰うことが出来ました。ここから得た教訓は、おそらく自分が思っている以上に、自分の本音が顔と態度にでるということでした。
うそをつくことが苦手で、本音と建前を使い分けることが下手な人間は、常に人様にバレても問題のないような本音で生きたほうが、生きやすいと思います。普段の小さな考えごとでも、人が見ていないような場でも、恥ずかしくない生き方をしたいと思いました。
なぜ Lisp に入門したのか もともと Emacs の設定をするときに 「おおもとである Lisp の言語設計の思想を少しでも理解することで Emacs の設定にいかせるのでは？」 というモチベーションで、Lisp について調べていた。
例えば、leaf みたいなパッケージ管理を使うと、本来なら自分で制御できる範囲の根っこの部分が他人依存になってしまうから使わないようにしていこうと考えた。
ただ、そもそもその判断に妥当性があるのかイマイチ自分自身で納得できなかった。どこまでを自分で制御可能な射程距離だと考えるのかにもよるのかもしれない。
調べていくなかで Lisp の言語設計の思想が Emacs の設計思想に影響を与えているように感じた。本体を小さくして必要に応じてモジュールを追加していく、そのモジュールも自分自身で実装していく(それが簡単にできるようになっている)といった価値観なんだなぁと思った。
わたしは、機能性の高いペン立てが欲しくて探したけれども、どれも自分の欲しい機能を満たしていないし、そもそも将来的にどういった機能が欲しくなるかも未知数で
「長く使いたいからこそ、最小構成で尚且つ拡張性の高いペン立ては存在するのか？」
と考えたときに、レゴブロックでペン立てを作れば良いと思った。
探したら、実際にレゴでペン立てを作る人たちは一定数いた。
きっと彼らは Lisper ないしは、その価値観に共感する可能性の高い潜在的 Lisper なのかもしれない(？)
入門してみて とりあえず近所の本屋に行って、検索機で「Lisp」と入力して、出てきた本を買って入門してみた。
「括弧がそのまま構文木を表現している」と知ったときは、確かにそうだわ、そのまま図になる！と感動した。これは図で理解するタイプには分かりやすそう。
演算式であっても前置記法という部分で「アセンブリもそうだったな」と思い出して、リストのメモリ配置の部分では「アセンブリでは自分でやらんといけんかったわ……」と、思い出した。普段コードをあまり書かないので、比較対象がOS自作のさいに触ったアセンブリ言語になってしまう。
全体的にシンプルで入門向きな言語だと感じた。これで Emacs の設定も捗ると良いなぁ。(捗るのか？)
emacs_卒leaf 使っている package の整理
leaf とは: Homebrew みたいな感じ
elpa (Emacs Lisp Package Archives)
→ emacs 内で使われているパッケージを管理 これからは: use-package.el を使う 今後 github からのパッケージを入れる場合は？
→ quelpa & quelpa-use-package を検討する
使っている package 名一覧 (leaf leaf-keywords :ensure t :init (leaf hydra :ensure t) (leaf el-get :ensure t) (leaf blackout :ensure t) (leaf terraform-mode :ensure t) (leaf gfm-mode :ensure t) (leaf markdown-mode :ensure t) :config ;; initialize leaf-keywords.el (leaf-keywords-init))) ;;残り - Ivy - swiper - counsel - prescientc - ivy-prescient 今後も使うかどうか検討して必要なら入れる