hitsumabushi845の日記

心理的安全性の保たれた空間に書く適当なメモ

『Kubernetes Certified Application Developer (CKAD) with Tests』記録 - セクション1・セクション2

今年上半期は Certified Kubernetes Application Developer(CKAD) の取得を目指して勉強していく。
先人の受検ログを見ると、Udemy にある Mumshad Mannambeth 氏の『Kubernetes Certified Application Developer (CKAD) with Tests』を活用している人が多かったので、先日のセールのタイミングで購入。

www.udemy.com

同氏による CKA のコースも合わせて購入した。

まずはセクション1と2を完了したので、記録。

Section 1: Introduction

このセクションでは、コースの概観や CKAD の説明が行われる。

このコースでは CKAD の取得を目的として、出題範囲に従ってレクチャーが展開される。
Workloads APIs や Service APIs 等の基礎、Kubernetesアーキテクチャといった基礎の部分は前提知識となるため、全くの初心者は以下のコースから取り組むことが推奨されていた。

www.udemy.com

上記のコースの存在は知らなかったが、すでに『Kubernetes 完全ガイド』を写経しながら通読したこと、Kubernetes the Hard Way をやったこと1からスキップしてよいと判断し、このまま進めていく。

特筆すべき点は、ここで CKAD/CKA の受験料が 15% オフになるバウチャーコードが提供されること。 通常 $300 の受験料が $255 になるので、セールのタイミングで購入しておくと実質無料になる。

イントロダクションはサクッとこんな感じ。次セクションから具体的な解説に入るようだ。 完全ガイドを通読したとはいえ、忘れてしまっているところも結構あるので復習も兼ねて進めていこう。

Section 2: Core Concepts

このセクションでは、Pod, ReplicaSet, Deployment, Namespace, Service といった基本的なリソースについての説明とハンズオンテストが提供される。

この2つはわりと日頃触れてるのでサクッと流す。
ここではじめて Practice Test が入る。Practice Test は、KodeKloud(Katacoda) を使って作られており、ブラウザ上で実際に k8s クラスタを触りながら確認テストができる。
これが学習体験としてけっこう楽しい。

f:id:hitsumabushi845:20210325011608p:plain
Practice Test のイメージ

  • Recap - ReplicaSets

ReplicaSet は普段使わないので、思い出しがてらちょっとしっかりやる。 ReplicationController の存在を(ほぼ)はじめて知る。ReplicaSet には selector を定義できるが、ReplicationController はできない。

Deployment と違い、ローリングアップデートもできない。
例えば kubectl edit などで定義を書き換えても配下の Pod は再作成されない。
というかそもそも、ReplicaSet の上位に存在して、ReplicaSet を管理することでローリングアップデートやロールバック(など)を可能にしたリソースが Deployment。

  • Recap - Deployments

というわけで Deployment。
Deployment 固有のフィールドとか結構忘れてるなーと思ったけど、このセクションではそれは扱わないっぽい。ここでは基礎のみ復習して、後段のセクションで詳細を扱うようだ。

  • Recap - Namespaces

Namespace リソースそのものは簡単なのでサクッと。
...と思ったら急に Service とか DNS が出てきてびっくりした。Namespace をまたいだ名前解決の話もここだったようだ。

  • Certification Tip: Imperative Commands

yaml を使わずに kubectl コマンドだけでリソースを作る方法について。
CKAD の試験は時間がタイトなので、この手法をよく使うらしい。

Practice Test では Pod と Deployment の作成は難なくできたが、Service の作成が慣れておらず手間取った。

セクション2はここまで。次はセクション3: Configuration。


  1. これは kubeadm 使用/非使用でそれぞれ行った。kubeadm を使用したクラスタ構築の記録は Qiita に書いた。qiita.com

2021年の目標など

こまめにブログを書きますまいか。
新年一発目のブログということで、今年の目標など書いていきましょう。

資格をとる

今年受検したいと思っているものは以下の通り。

  • CKA or CKAD
    昨年12月より副業で Kubernetes を触っているので、せっかくなら...と思っている。
    "or" とあるように、どちらか一方だけかもしれないし、どっちもかもしれない。
    あわよくば本業の資格取得補助制度を活用したい。
  • TOEIC
    本来であれば昨年受検するつもりだったもの。
    昨年申し込んだものの、コロナ禍により抽選方式になっていて、落選してしまった。
    最後に受検したのが3年前なので、いい加減更新したいと思っている。
    TOEIC はこれまで特別な勉強をしていないのだが、スコアは 4xx -> 6xx -> 7xx と過去3回着実に伸ばしている。
    そのため今回は 800 点台を目指したいが、いい加減それ用の勉強をしないと厳しそう。

こまめにブログを書く

このブログでは特定の技術に関する話題以外の、技術以外の話やポエムなどを書いていきたいと思っている。
特定の技術要素については、せっかく Organization に属しているので Qiita に書くつもりでいる。

こまめにと言っても、せいぜい月2程度のペースでゆるくやっていきたい。
いままでできていない身で変に高い目標を掲げてもつらくなるだけなので。

Terraform を勉強する

2021年から本業・副業ともに Terraform を扱うようなので、ゆるく勉強する。
仕事で使うのでまあ勉強できるだろうと高をくくっている。

特に到達目標はないが、仕事が回る程度に扱えればよいと思う。

golang を勉強する

そろそろ新しい言語を勉強したい。
golang は、複数のプラットフォームに向けてコンパイルできるということで、かねてより興味は持っていたが、
Kubernetes に触れるようになったことでより勉強するモチベーションが上がっている。

とりあえず、Gopher 道場 を進めていこう。

おわりに

ひとまず現時点で考えている目標はこの程度。
今年を象徴するテーマとなるような、新しい趣味の目標がひとつほしいところ*1

*1:一昨年はカメラとDJ、昨年は一人暮らしをそれぞれはじめた。

今年のおしごと2020

来年はもう少しこまめにブログを書きたい。
今年のおしごとを四半期刻みで振り返ります。もちろん外に向けて書けるものだけ。

1月~3月

今年は昨年3月から引き続き、オンプレ向け自社製品デプロイツール開発として働いていました。
1~3月のお仕事は大きく2つ。

Amazon Corretto JRE のデプロイ機能開発

自社製品は Java で動いており、サーバにランタイムとして JRE を配置する必要がある。

そこで、デプロイ時に JRE の更新も自動で行いたいという需要が生まれたので、
ツールに対して新規機能として実装。

製品や環境ごとに JRE の配置先が違ったりするため、それらを吸収するためデプロイ先を任意に変更できるよう開発した。

Google Form と Slack の連携スクリプト作成

これは主務とは異なるタスクのため、合間を縫って*1*2実装していた。

お客様との窓口となるコンサルの、顧客訪問時の記録を Google Form で行うという施策において、
Slack に自動的に連携され、Slack 上で様々なやりとりをできるようにしたいという需要が生まれた。

Google Apps Script(GAS) をつかって、Form 送信時に Slack に自動通知される仕組みを作成した。

・・・というとあっという間に作れそうに思えるが、つらみポイントがいくつかあったので書いておこう。

Slack 通知の対象となるフォームが20以上ある

GAS には、Spreadsheet や Form などの Google Apps と紐付くスクリプトContainer-bound script)がある。 これをつかうと、Spreadsheet であれば編集時やシートを開いた時、Form であれば回答の送信時など、Apps 固有のイベントを手軽にスクリプトのトリガーとして利用できる。
そのため、フォーム送信時にスクリプトを発火させる場合は Container-bound script を使うのが都合がよいのだが、 20以上あるフォームそれぞれにこれを設定するのは実装コストも保守コストも爆上がりしてしまう。

そこで、Google Apps と紐付かないスクリプトStandalone script)に実装し、
外からイベントトリガーを定義することで、単一のスクリプトで複数のフォームのイベントを管理することとした。

具体的には、TriggerBuilderを使って各フォームごとにスクリプトからトリガーを定義した。
これによって、ひとつの関数を実行するだけですべてのフォーム送信イベントをトリガーとして定義できるようになったのだが、 ここでもう一つの問題が生じた。

1ユーザあたり、スクリプトに設定できるトリガーが20個までという制限

題通りなのだが、GAS にはあるスクリプトに設定できるトリガーの数に制限がある。
具体的には、20 トリガー/ユーザ の制限となる。ref: https://developers.google.com/apps-script/guides/services/quotas#current_limitations
そのため、20以上あるフォームに対してトリガーを1人で設定することが不可能なのである。

こればかりはどうひっくり返っても回避不可能なので、トリガーの設定を行う人を複数立て、
Google Spreadsheet にトリガー設定履歴を記録することとした。

この制限結構きついなあ。

そして

まあ、いくつかの面倒くさいポイントはあったものの、今でも元気にスクリプトは動いている。 どうもコンサル組織においてわりと重要な仕組みになっているようで、噂によると今年の秋時点で1万件以上の記録が Slack に連携されているみたいです。

4月~6月

この辺から在宅勤務が本格化。
実家には小さな折りたたみテーブルと MacBookPro しかないので、会社に比べて画面が小さく辟易した。

4~6月にやったことは以下の通り。

  • オンプレサーバーヘルスチェック機能開発
  • Qiita Organization に入った
  • 部内で LT? をした

オンプレサーバーヘルスチェック機能開発

オンプレサーバの物理マシンはデータセンターにあったりお客様先にあったりと、日頃のメンテナンスがおろそかになっていることがある。
その場合、ディスク等の枯渇が突然発生してシステムが正常に動かないトラブルが発生することがある。

そこで、開発しているツールにディスクと表領域のチェック機能を実装した。 ツールはWebアプリケーションとして動くため、チェック方法のわからない(スキルを持たない)人でも使えるよう、
ボタンをポチポチするだけでチェックできるよう実装した。

UI/UX には結構気を遣ったつもり。

Qiita Organization に入った

ついに弊社も Qiita に Organization を作ったらしいので参加した。
昔取った杵柄で、Contribution 数がちょっとあったので、参加したての頃は Organization の Contribution 数の大半をぼくが占めるということに。

今はあの記事とかあるので、全然たいしたことない。

部内で LT? をした

月次の全体ミーティングでは、持ち回りで LT をすることになっている*3
6月は私が担当だったので、これまでの1年ちょっとの経験から得られたサポートエンジニアとしての心構えを紹介した。

スライドは Internal な内容が多いので公開できないが、ざっくり以下のような内容を話した。

  • 問い合わせは回答スピードが命。
  • スピードは大事だが、回答の質も大事。
  • つまり、質とスピード*4を両立する必要がある。
  • そのために必要なことは以下の3つ
    • 事実と推測を区別する
    • ゴールを明確にイメージし、そこから逆算する
    • いち早く事実だけを積み重ねる

概ね好評だったようなので、いつか再放送できるといいなーと思っている。

7月~9月

先述の在宅勤務環境が耐えられなくなったことと、Stay Home によって少しお金が貯まったので、
これを機に一人暮らしを始めた。

この時期はあまり特筆すべきことがない。というか外に向けて書けることがない。

インターンのメンターをした

いわゆる「夏インターン」のメンターをした。
Withコロナということで、完全オンラインのインターンシップとなり、在宅にてZoomやSlackを活用したインターンであった*5

ぼく自身は学生時代にインターンに参加したことはなく、自社も通常の新卒採用での採用だったため、
そもそもインターン自体はじめてであった。

インターンは3日間行われ、その間学生のアウトプットのレビューをしたり、
Zoomのブレイクアウトセッションを使って行われているグループワークを見回ったりしていた。

初日のアウトプットを見たときは「大丈夫かこれ...というか3日でどうにかなるものなのか...???」と不安になったものだが、
終わってみるとどのグループもとてもよくできていて、なんというか感動した。

というか、(就職活動とはいえ)学生が真摯に課題に取り組む姿や、3日間を通して明らかに成長している姿を見て、
むしろ自分が学ぶことが多かったなという印象。

社会人も3年目に突入し、ある程度"惰性で"働くことができるようになってしまっているので、
この時の学生の取り組み方を折に触れて思い出し、自らの働き方を修正していきたいと思っている。

10月~12月

さて、記憶にも新しい最後の四半期。
10~12月にやったことは以下の通り。

  • Webマニュアルをリニューアルした
  • 副業を始めた
  • 引き継ぎをした

Webマニュアルをリニューアルした

開発しているツールのマニュアルは Web から参照できる Web マニュアルとして提供している。
このWebマニュアル、現在は Asciidoc を用いて作成されており、ここから HTML ドキュメントを生成している*6

Asciidoc はあまり利用することがなく、実際このマニュアルの作成以外では利用しない。
そのため、できれば Markdown でマニュアルを作りたいと思っており、合間を縫って*7マニュアルのリニューアルに取り組み始めた。

せっかくなので頑張ったポイントについて書いていこう。

MkDocs をつかった

マニュアルのベースとなるフォーマットを Asciidoc から Markdown に変更するにあたりもっとも大きな問題は、
Asciidoc に比べて Markdown は表現力に乏しいこと。

特に、Asciidoc における「ブロック」が一般的な Markdown では利用できないため、
警告や Tips などの情報の表現が難しい。

そこで、Markdown ベースの静的サイトジェネレータである MkDocs を利用した。
これは、Python-Markdown 拡張を利用でき、これによって通常の Markdown 以上の表現が可能となる。

また、サードパーティーテーマも豊富にあり、きれいなドキュメントを簡単に作成できる。
作成した Web マニュアルでは Material for MkDocs を利用した。

Remote - Containers をつかってマニュアル編集用の環境を整備した

MkDocs ドキュメントを編集する際は、ローカルに Python と MkDocs 関連の各種ライブラリといったものをインストールしなくてはならない。
これらの環境構築は往々にして社内ドキュメントに手順がまとめられるが、だいたいメンテナンスが漏れたり、環境依存のトラブルが発生する。

そのため、VSCode拡張機能 Remote - Containers をつかって、環境をコンテナ化することにした。
Remote - Containers は VSCode 自体もコンテナ上で動くため、VSCode 拡張機能も含めてパッケージ化できることが魅力。
MkDocs 編集環境をパッケージ化するため、MarkdownYAML 用の拡張機能も併せてパッケージ化した。

詳細はアドベントカレンダーとして Qiita にも書いたので、リンクを貼っておく。

qiita.com

副業を始めた

12月から副業を始めた。
副業はもともとする気がなかったのだが、会社の先輩が副業3つやってる話を聞いたこと、友人から副業の誘いを受けたことから、「1つくらいならできるかな?」と思い、開始。

内容としては Kubernetes を扱ってなんかしています(まだよくわかっていない)。
Kubernetes 自体、知ってはいたが利用するのははじめてなので、『Kubernetes 完全ガイド』 を写経しながら読み進めている。

来年は CKA, CKAD の取得を目指したい。

引き継ぎをした

さて、昨年3月からやってきたオンプレ向けデプロイツール開発であるが、2021年1月から別部署に異動が決定した。
そのため、12月後半は各種業務の引き継ぎを行っていた。

異動する身としては、仕事を新たに自分でやっても意味が無いと思い、なるべく自分から仕事をとらないようにしていた。
その結果として12月後半はめちゃくちゃ暇だった。

おわりに

というわけで、来年からは新しい部署で働くことになりました。
副業もどうなっていくのかわからないし、2021年は今のところまったく予測不可能です。 とりあえずフルリモートワークになることはほぼ確定だそうなので、いろいろアウトプットを増やしていけるといいなー。

*1:いわゆる「スカンクワーク」というやつなのだが、今の弊社においてこの文化は明文化されていない。悲しい。

*2:前職(?)の公式ウェブサイトを見ても今現在では明文化されていない。おい、どうしちまったんだ。

*3:LTといっても、10分程度なので少し長め

*4:© t_wada

*5:東洋経済に取材されたので掲載しておく

*6:AsciiDoctor を利用している。

*7:これもいわゆる「スカンクワーク」

今年買って良かったもの2020

このブログは1年の総括を書く場所なのか???
まあ、書いていきましょう。

今年は引っ越しも伴って、大きい買い物が多かった。

音関連

MUSICMAN JP12 6 strings

www.soundhouse.co.jpMUSICMAN公式ではもうリンクがないので、SOUNDHOUSEのリンクを貼った

高校生のころからギターをダラダラやってきたけど、いい加減はじめて買ったギター(Fender Jagstang*1)をやめたいと思い続けて早数年。
バンドを組んだこともなく、ただ気が向いたら触る程度なので高い物買ってもなあ...とも思うが、Dream Theater 大好きなぼくとしては、いつか JP が欲しいとも思っていたのでした。

そのため、定期的にデジマートで中古相場を調べていたのですが、JP12 が比較的安く*2出ていたので、うっかり購入。

うっかり買った割にはわりと満足度が高い。
「JP を所有していること」への高揚感だったり、ちょっと嫌なことがあっても「まあ家に帰れば JP12 あるしな」ってなるし仕事でむかつく人に会っても「そんな口きいていいのか?私は自宅で JP12 とよろしくやってる身だぞ」ってなれる。

サウンドもぼく程度のへっぽこ日曜ギタリストには申し分ない。
そういえば、これに伴って Amplitube も買ったんだった。レビュー書けるほど使いこなせてないのでここには書かない。

AKG K240MK2

www.soundhouse.co.jp

これを買うまでは、SONYMDR-CD900ST を使っていたのだが、
側圧の強さとパッドがすぐにペラペラになってしまうのが災いして頭が痛くなってしまっていた。

そんな折、職場の同僚の音楽強いマンがこれを猛プッシュしていたので、うっかり購入。
側圧もほどよく、なにより AKG なので気分が良い。ぼくは音関係は気分で評価しているのか???

まあとにかく、快適になりました。

AirPods Pro

www.apple.com

身の回りを Apple 製品で固めている(MacBook, iPhone, iPad, Apple Watch 所有)身としては、Apple 製品同士の連携が良いこと、
また AirPods Pro のノイズキャンセリングが最高との評を聞き、買おうか悩んでいた。

そんな折、コストコで税込 25,880 円で売られていた*3ので購入。

良かったところ:

  • やっぱりノイズキャンセリングがつよい。外部音取込モードとのシームレスな行き来によって、付けっぱなしで生活できる。
  • 装着して即接続される。Bluetooth設定をいちいち開くなどが無くてよい。

あとはワイヤレスイヤホン一般のメリットになるので割愛。

エンジニアリング関連

ウルトラワイド湾曲ディスプレイ(LG 35WN75C-B)

www.lg.com

これまで、15インチMacBookProだけでリモートワークを闘ってきたが、
引っ越しに伴って広いデスクも手に入ったことだし、いい加減ディスプレイを買おうと決心。

会社のSlackに感想を書いてたので転記。

  • とにかく大きい。ウィンドウを贅沢に配置できる。3分割できるウィンドウ配置ツール(BetterSnapToolとか?)があるとなおよい。
    →ウィンドウ配置ツールは Magnet を買いました。
  • ブラウザ2枚開きながらVSCode見るとかが1画面でできるのがアツい。GitHub, リファレンス, VSCode を同時に開きたい瞬間があるので。
  • あとは、ディスプレイではないけどモニターアームが思ったより良い。モニターを自分の体勢に合わせて移動できるのは思った以上に良い。

Manta60

yushakobo.jp

1年半ほど前に、Mint60 で自作キーボードに入門し、これが2つ目の自作キーボード。 今回はなるべく Mint60 とは異なる要素を持ったキーボードを作ろうと思い、以下の条件を満たすものを探した。

  • Row-Staggered ではない
    • Column-Staggered か Ortholinear(格子配列)
  • なるべくホットスワップ
    • キースイッチはソケット式,ProMicroはコンスルーといったように,トラブルがあったときに交換しやすくしたい。
    • このへんはMint60からの学び。
  • パーツの調達
    • Mint60 ではキースイッチやキーキャップなど全て揃ったものを購入していたので、今回は自分で調達してみたかった
  • 表面実装
    • ただ単に,今まで表面実装をしたことがないので,挑戦してみたい。

上記の条件を満たし、かつ個人的な好みとして「親指キーが多い」を満たすものとして、Manta60 をチョイス。

以下、感想。

  • 親指キーの多さは最高。
    • ほとんど親指でやりたいことができる。
    • Space, Enter, BS, Command あたりをマッピングしている。
  • 格子配列もはじめは慣れなかったが,一週間くらい使ったら慣れた。
    • 一方で,通常の Row-Stagerred キーボードが打ちづらくなってしまいました()
  • かばんに入れてるとたまにキースイッチごと外れてることがある
  • デフォルトのキーマップだと,B キーが右手側に来るため,はじめはちょっと違和感があった。
    • これはマッピング変えることも検討したが,検討しているうちに慣れたのでこのままにしてある。

次は 40% の Column-Staggered キーボードを作りたい。

暮らし関連

ドラム式洗濯乾燥機(日立 BD-SV110EL)

kakaku.com

はじめての一人暮らしに伴って、最もやりたくなかったこと、それは「洗濯物を干して、取り込む」という作業である。
ハンガーに掛けたり、天気を気にしたりと、精神に負担が大きすぎる。

そのため、「この作業をゼロにできるなら金に糸目は付けん!」と購入した結果、引っ越しにおいて最も単価が高い買い物になったのでした。

ま〜本当に高かったけど買って良かった。リモートワークとの相性がいい。
朝シャワー浴びてそのままスイッチオンして、昼ご飯のタイミングで取り込む、といったルーチンが出来上がりました。

siroca のサイクロン式コードレスクリーナー

www.siroca.co.jp

掃除機を選択する条件として、

  • コードレスであること
  • ハンディクリーナーとしても機能すること

を選んだ。
こいつはその条件を満たして1万円くらいで手に入るのでわりと満足している。

コードレスでハンディクリーナーとして機能すると、ちょっとした掃除を気軽にできて良い。

amadanaウォーターサーバー

premium-water.net

普段から水をガバガバ飲むので、ウォーターサーバーは必須と思い一人暮らしでも導入。
amadanaウォーターサーバーは、普通のサーバーに比べて電気代が高いけどオシャレなのでこれにした。

デスクの真横に置いているので、仕事中も手をのばせばキンキンの水が得られるので生活の質が上がる。

おわりに

今年は本当にお金を使いすぎた。
来年はもう少し節約しよう。

お題「#買って良かった2020

*1:Fender Japanだけどね。とにかく悪名高いあのトレモロユニットに悩まされていた。

*2:といっても20万円オーバー

*3:Apple で買うと税込 30,580 円

ゴールデンウィークにDJ Mixを投稿した。

はい。もう1ヶ月も前の話です。 ゴールデンウィークにDJ Mixを投稿しました。

モチベーション

一言で言うと、ブランクが空きすぎたから。

2019年は2月にDJコントローラーを買ったばかりの超初心者にも関わらず、幸いにも3度ほどDJをする機会をいただけました。
しかし、最後にDJをしたのは昨年の9月。
半年以上のブランクが空いており、今年5月にあるはずだった出番はCOVID-19の影響により無くなりました。 このままでは(ただでさえ下手なのに、もっと)下手になってしまう!

というわけで、リハビリを兼ねてGW期間でMIXを録りました。

条件

言うほど条件はないです。

  • アニソン原曲MIX
  • 30分程度

やってみて

よかった点

わるかった点

  • 30分を超えた
  • もっとアンセム使えばよかった
    べつにイベントに出てるわけでもないのに、誰に配慮してアンセムを避けたんだろうか?
  • 意味のわからんBPM飛ばし
    アオくユレている→Jumpin'! Dancin'! の繋ぎ、なにこれ????無理矢理にもほどがある。多分疲れてた。
  • ラスサビへの飛ばしをミスった
    H-A-J-I-M-A-R-I-U-T-A-!!のラスサビへの飛ばし、HOT CUEボタン押しそこねてちょっと変になっちゃった。
  • 必然性のないつなぎが多い
    聞いてて違和感のない繋ぎを意識しすぎており、キーとかBPMばかりに目が行って、繋ぐ曲と曲の関連性がない物が多い。

反省点が多すぎて涙が出てくるね。また夏あたりに投稿するようにします。

今年お仕事でやったこと

今年も一年お疲れさまでした。

 

1〜2月

SRE としてインフラの Monitoring とそれに伴うトラブルシューティングをしたりしてました。

Zabbix や AppDynamics とかで監視をしていて、何か起きたら Slack にアラートが飛んでくるという仕組みや、Toil をなくすために親の仇のように自動化をしていくみたいな精神は後の(3月以降の)チームでのやっていきかたに大きく影響しています。

 

また、トラブルシューティングの記録や、工数の管理をするための Web アプリを Vue.js と Spring boot で作っていました。

Vue.js 側のビルドと Spring boot 側のビルドをまとめてやりたくなって、Mavenmaven-frontend-plugin とかを組み合わせて全部 Maven からビルドできるようにしたりしてました。

 

SRE は昨年の11月に配属されたばかりでしたが、オンプレ向けのデプロイツール開発チームがメンバーの退職が相次ぐなどあり崩壊寸前だったため3月からそちらに異動することになりました。

3月から異動するのはよかったのですが、それを通告されたのが1週間前だったのは結構びっくりしました。

1週間で引き継ぎ用の API ドキュメントやアーキテクチャ説明ドキュメントを作成して、なんとかさほど後を濁さずに去れたと思っています。今でも上述の Web アプリは使われているみたいなのできっと大丈夫でしょう。

 

3〜12月

というわけでオンプレ向けのデプロイツール開発チームに異動しました。

メイン業務はツールの開発とツールに関する問い合わせ対応とトラブルシューティングなのですが、

とにかく開発環境がめちゃくちゃでした。

入ったときは、

  • Jenkins は一応ある。が、オンプレサーバーに構築されているしバックアップも取られていない。ジョブに使うスクリプトはサーバーのローカルに生で配置されている。あと権限管理が存在しない。
  • GitLab も一応ある。が、これもまたオンプレサーバーに構築されているしバックアップも(以下略)
  • なぜか Maven のリモートリポジトリもオンプレでオレオレ Nexus が立っている。しかも歴史的事情により、この筐体が海外にある。
  • 種々のオペレーションが手作業で行われているし、ドキュメントも存在しないか陳腐化している

といったような、いいんだか悪いんだかわからない環境でした。ていうかきっと悪い。サーバー吹っ飛んだら終了だけど大丈夫か???

 

なので、メイン業務に並行して、これらの改善をやっていました。

 

結果、今では

  • Jenkins は毎日バックアップを取るようになりました。また、スクリプトはほとんど GitLab へ移行しました。Role-based plugin を使って、権限管理もおこなうようになりました。
  • 謎のオンプレ GitLab は廃止しました。会社で用意している GitLab があるので、こっちに全てのリポジトリを移行しました。余計にサーバー管理コストを払わなくて済むようになりましたね。
  • 謎のオンプレ Nexus も廃止しました。会社で(以下略)
  • 手作業で行われている種々のオペレーションもなるべく Jenkins ジョブ化しました。
  • Jenkins ジョブの実行結果や、GitLab のイベントは全て Slack に通知するようにしました。

 

入った頃から比べたらはるかに安心できる環境です。よかったよかった。

メイン業務もちゃんとやってました。開発したチケットの数はチーム内でも1番多かったですし、対応した問い合わせの数も多分1位か2位くらい。(20200114: 1位でした)

あと、海外の開発メンバーとのやりとりとかもやってました。仕様の確認やコードレビューなど。基本的に Slack ベースなので、speaking は伸びなかったですが、reading と writing は伸びたような気がします。来年は TOEIC L&R を受けてみようかしら。

そういえば Google Apps Script 講座とかも社内でやっていました。これはテキストを作ったのでどこかで公開したい。

 

本当に今年はいろいろやった気がします。

来年もこれくらい幅広くやっていきたい。

今年買ってよかったもの

はてブロ開設だけして放置してたので、今年買ってよかったものでも書いてみる

DDJ-400

今年を象徴する買い物はやっぱりこれだったと思います。
これを買ったことがきっかけで、いろいろあって今年は3回ほどDJをすることができました。

www.otaiweb.com

DJを始めたことで、音楽の聞き方も変わってきました。そのへんの話についても書けるといいなあ。

PCスタンド

もともとスタンドを持っておらず、DJコントローラーの奥にノートPCを置く配置で練習していましたが、
ノートPCが遠くなってしまい操作性が悪かったです。 購入後はDJコントローラーとPCが近くなり、操作性とともに練習のモチベーションが上がりました。

そうしてできたのがこれとか

これです。

みんなきいてくれよな!

英辞郎の辞書データ

英和辞典のデータです。 booth.pm

で、なぜ買ったかというと、↓で紹介されている Mouse Dictionary を利用していたから。
フリーの辞書データでもわりと使えたんですが、熟語とか、英語特有の言い回しとかに対応できず、結局Weblioとかを検索する・・・みたいなループに陥っていたので。
そもそも500円なんだからさっさと買えという話。

qiita.com

買ってからはいろいろはかどっています。