vscode x asdf x Go の時の No preset version installed for command gopls

ひさしぶりに使うPCで Go linter が効かなくて困った。

No preset version installed for command gopls vscode

language server の gopls が起動しない模様。

Go to output で出力を見ると、↑のエラーメッセージが出ていた。

.tool-versions ファイルは project root に存在し、対応するバージョンの Go も asdf で install されている。 PATH も通っている。

一応 rc ファイルを確認すると、手動で /usr/go/bin にPATH を通している記述があったので、念のため消しておいた。 asdf reshim golang を忘れなければ、go install した ツールが使えないことはないはずだから。

それでも↑のエラーが消えなかった。

エラーメッセージに Go 1.20 への言及があったので、1.20 (今は 1.21 ) はどこから持ってきているのかと思い、 go.mod をみたら、 1.20 になっていた。

go mod tidy -go=1.20

を実行して解決。

指摘をもらって、なんでそんなことに気づけなかったのか、と思うことがある

指摘をもらって、なんでそんなことに気づけなかったのか、と思うことがないだろうか。

先日、設計ドキュメントを書いて、「目的がよくわからない、想定している具体例がないので正しいのか間違っているのか判断材料が十分に書かれていない」と指摘をもらうことがあった。その夜に考えたことを書いてみる。

まず感謝

まず、その指摘は素直に受け止めて、感謝を伝えるのが大事だ。

誰かに何かを指摘するというのは、簡単なことではない。 次回も指摘をしてもらうために、言い訳を重ねたり、などはしない方がよい。

ただし、何も考えてないやつと思われたくない、ただ素直に感謝を伝えるだけだと何も考えてないと思われてしまうかもしれない。 そういう時どうすればいいか、は今の所わからない。

日頃の行いでどんな印象を与えているか次第かもしれない。どうしようもない。 まぁそんなことはいいとして。

何故か / 原因

自分を客観的に見ていれば気づけたはずなのに、と思う指摘は少なくない。

何故こんなことが起きるのか、原因は何か考えてみた。基本的に脳が原因で、

  • 脳のメモリが圧迫されて、判断力が鈍る
  • 精神が脳の性能を制約する
  • 脳のメモリに乗っている情報だけで、狭い視野で無理に結論まで出してしまう
  • 知りすぎ

脳のメモリが圧迫されて、判断力が鈍る

これが肌感覚では一番多い。

  • 経験不足だと、何をするにも調べたり考えたりすることが多い。
  • ツールに習熟していないと、ツールの使い方を考えることに脳のリソースが取られる。
  • 設計ドキュメントのテンプレートや、どこかの本に書いてあったフレームワークなど、所与の物による制約

こうしたことが積み重なると、脳のメモリは圧迫され、気づけば冷静な判断ができなくなってしまう。

逆に、経験豊富な人が冷静で的確な判断をして見える理由の一つは、脳のメモリにゆとりを持っているからだ。

経験があれば調べる必要もなく頭にある知識を取り出せばよく、考えなくてもパターンがいくつか浮かんでくる。 色んなツールを使ったことがあれば、そちらに意識を割くことなく作業ができる。

精神が脳の性能を制約する

焦ったり、心の余裕がないと、メモリ総量がそもそも逼迫する。

日常だ。

脳のメモリに乗っている情報だけで、狭い視野で無理に結論まで出してしまう

既に近いところにある情報を使って、安易に判断して大局を見失うパターン

知りすぎ

これは『イシューからはじめよ』に記載があった、何故コンサルが必要か、の話から持ってきた。 メモリだけでなく、HDD まで書き込まれてしまった情報が、判断の視野を限定してしまう。

これは先に書いた経験があればメモリの余裕が生まれる、と反対の話だ。経験があるほど判断を誤る。

しかし「知りすぎ」はそう発生することではない。職種によるが、大体はパターンを知っているか知らないか、の違いのほうが大きい。 『イシューからはじめよ』でも、情報は集めるが、集めすぎに注意しろ、という文脈で出てきている。

どうすればいいか / 解決策

主にメモリ不足状態に限定して考える。一番多いからだ。

まずは、自分のメモリ不足状態を自覚すること

なんか、冴えないな、と思うとき。メモリ不足状態に陥っていることに気づかないといけない。

そもそもメモリ不足状態にならないように普段から習慣を作る

基本的な対策が最も大切だ

  • 睡眠をしっかり取る
  • 適度な運動
  • バランスの良い食事
  • メンタルの維持

メンタルの維持は、習慣で、ネガティブな記事を見ない、ポジティブな思考を声に出す、などがよくある

メモリ不足状態になったとき、できるだけ早く回復すること

メモリ不足状態になったら、脳のメモリを解放すればいい。

つまり、忘れればいい。

  • 散歩する
  • 寝る
  • 他の事を考える
  • 買い物に行く

が有効だろう。

余裕を作ることも大事だ。 連続してミーティングを入れないなど、普段から予定に余裕を持つ。 もしメモリ不足状態になったら、休憩させてください、ということが大事。

おわりに

先日、「あえてゆっくり考える」ことも大事だ、という話を見たが、あれも近い話だと思う。

ソフトウェアエンジニアとサッカー選手って似ている

余談:三笘選手すごい

イギリスのプレミアリーグでブライトンの三笘選手がすごいゴールを決めた。

昔、マラドーナという有名な選手がいて、その人のゴールに似ていたらしい。

私は三笘選手を応援している。

私は去年の始めはサッカーに一切興味なかったのに、ついに夜中にリアルタイムで試合を見るようになってしまった。

2022/4 からアオアシというサッカー漫画のアニメを見始めて、ブルーロックというサッカー漫画のアニメを見て、ワールドカップの日本代表を応援(ミーハー)している内にサッカーを見るようになった。

ブルーロックはとんでもサッカー漫画なのだが、アオアシは、サッカーを知らない人が読むと楽しめると思う。

サッカーの戦術・戦略があることを知ったのはアオアシのおかげだ。

ソフトウェアエンジニアもサッカー選手も似ている

三笘選手のゴールに関係はないが、最近考えていることがある。

アオアシを見て、サッカーの基本知識を得て、プロの試合を見る内にソフトウェアエンジニアとの共通点に思い当たった。

サッカー選手は

  • 自分の能力を試合の中でアピールする
    • 素人目にはゴールシーンくらいしか印象に残らないが、わかる人はその他の動きをよく見て評価する

エンジニアは

  • 自分の能力をマネージャーに見せて評価してもらう
    • 成果を出す過程に再現性があるか、ソフトウェアの品質が高いか、などは見る人が見ないと分からない。

これはプロフェッショナルであれば当然かもしれないが、チームプレーであるという点でも共通している。

サッカーは

  • 各々の役割が与えられているが、試合の状況を見て柔軟に対応したり、他のチームメンバーに指示を出したりする

エンジニアは

  • チームの中でソフトウェアエンジニアではあるが、コードを書くだけではなく、コトに向かう中で要件をしっかりと理解する要求もあり、他のメンバーとコミュニケーションしたり、サポートに回ったりする。

みたいなことを雑に考えていた。

GPU その他を増設した

2年ぶりにPCをいじくる

GPT 関連のモデルを自分で回したいと思い、2年前から使っているPCにGPUを増設することにした。

2年前に初めて作ってから、素人がとりあえずで触るものではないなと思ったので、ずっと触らずにきたが、満を持して。

2年前にもお世話になった友人に再度手伝ってもらい、GPUのおすすめ等を聞いてたら、一緒に秋葉原に行くことになった。

GPU3060を買いに行ったが、不思議なことに帰り道ではSSD と RAM も袋に入っていた。

取り付け

100%初心者でよく分かっていないが、すでに取り付け済みのものがあるので、それに倣って設置すればいいと考えた。

なお、2年分のほこりがすごかった

RAM は押す

RAMを取り付けようとして、全然はまらなくて焦った。

ツメが片方しか開かなくて、正常には見えたが、調べて出るサイトだと全て両側にツメがあるタイプで、迷った。

結局、はまらないのはサイドの滑りが悪いから、と出てきたので、いくつかの角度から強めに押しこんでみて、挿した。

さて、2枚目のRAMをさそうとしたら、CPUクーラーの出っ張りがRAMの取り付け位置にはみ出していて、付けられなかった。

そこでCPUクーラー(その時は何のファンだったかは意識せず、ただのファンだと思っていた)を外すことにした。

CPU クーラー

壊したかと思った

なんか2種類ネジがあったが、ファン側だけ外せばよかったので外そうとした。

しかしネジが外れなかった。

諦めてマザボに近い方のネジを外すことにした。プッシャー(バネみたいな)がついていたので、外す時に勢い良く外れた。電動ドリルで作業してたので、ちょっとしたパニックだった。

また、CPUとグリスでくっついていたところをおそらくねじ切ったので、それも変な力が入って壊れたんじゃないかと大いに焦った。

外してから、このファンはCPUの上に乗ってるやつだと思いだした。外しては行けない、と聞いていた気がしたので、やらかしたと思った。

あと、外す時にいろんな音がしたので、CPUが壊れてないか心配だった。この心配は最後に電源をつけて動かすまで続いた

再取り付け

向きを変えてCPU クーラーを取り付けようとしたら、 ネジが明らかにマザボに届いていなかった。ネジはジャンパーを持っていてそれを押し込みながら回さないといけないのかと思いどう頑張っても力が入らないので詰みかと思った

ケースを立てようとしたときに何かが動く音がして、偶然にもケースの逆側に板が落ちていることを発見した。サイズ的にマザボの裏側からファンを取り付けのためのものだと理解して、ボードを抑えながらで大変だったが、ファンも取り付けられた。

グリスを持っていなかったので、熱効率が悪くなるらしいと知りつつ、とりあえず付けた。前のグリスが固まった破片が飛び散っていて、静電気が怖かったので、慎重にとった

SSD

取り付ける場所を見つけるのが大変だった

ネジが、2年前の箱の中にそれっぽいのがあって良かった。別で買う必要があるのかと焦った

ななめに差し込んだあと、ゆっくり押さえつけた。これも割れそうで怖かった。

監視

温度監視には lm-sensors というツールを使う

https://kaworu.jpn.org/ubuntu/lm-sensors

sudo apt install lm-sensors
sudo sensors-detect #全部yes
sensors

平常時は50度くらい

適当に繰り返し実行するスクリプトを書く

 while true; do sensors | tee -a temperature.log && sleep 2; done

負荷

負荷には stress というツールがあるらしい

stress コマンドを使ってマシンに負荷をかける - CUBE SUGAR CONTAINER

sudo apt-get -y install stress pcp util-linux
cat /proc/cpuinfo | grep processor | wc -l
12

上記の監視コマンドを流しながら、別のターミナルで負荷をかけてみた

stress -c 4
stress: info: [40492] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd

結果、90度まで行ってしまった

$ cat temperature.log  | grep Tctl
Tctl:         +49.4°C  
Tctl:         +49.9°C  
Tctl:         +49.6°C  
Tctl:         +50.2°C  
Tctl:         +65.5°C  
Tctl:         +83.1°C  
Tctl:         +86.6°C  
Tctl:         +89.4°C  
Tctl:         +91.1°C  
Tctl:         +91.0°C  
Tctl:         +92.5°C  
Tctl:         +94.1°C  
Tctl:         +94.9°C  
Tctl:         +95.0°C  
Tctl:         +95.1°C  
Tctl:         +94.8°C  
Tctl:         +89.0°C  
Tctl:         +83.2°C  
Tctl:         +78.1°C  
Tctl:         +73.8°C  

総評

調達から組み立て、検証までを一人でやるのはやっぱり無理な分野だと思う。

わからないことを予想を建てて、調べて、なんとかする、はソフトウェアエンジニアリングと近しいところがあるが、ミスった時に数万円が消えると考えると、メンタル的に重労働だった。

追記:グリス塗った

重い腰を上げて、CPUグリスを塗った。 同時に、フロンガスのスプレーを買ってホコリを除去したが、恐ろしいほどにホコリが俟った。

グリスを塗って無事に再起動できた後、同様の負荷実験をしてみた。

平常時:40℃ 負荷最高温度 81℃

というところだった。

追記:ダブルディスプレイにした

グリスは塗っていたが 50度前後になっていた。

大山初登頂!初心者の挑戦と学び

はじめに

先月の2023/6/18に、神奈川の大山に登ってきました。私は高尾山しか上ったことのない登山初心者なので、初心者用の山と言われる大山を選びました。初心者とはいえ、高尾山の次への挑戦は、初心者としては色々と学びが多かったので、そのログを残します。

0. 登山前の準備

まず戸惑ったのは、いくつかあるルートの入り口が違うことです。高尾山はルートはいくつかありつつも、高尾山口に行けばいいことはわかっていたので、入り口選択は最初の関門でした。

いくつか調べるうちに、よく使われるルートはロープウェイのある入り口だとわかったので、そこに決めました。

同時に、バスに乗る必要があるのを認識しました。

1. 登山口までのアクセス

当日になりました。

時間
6:30 家を出発、松屋で朝食
7時過ぎ 電車に乗車
8:20 伊勢原駅に到着

ちなみに朝をしっかり食べてエネルギー補給にはこだわりました。何があるかわからないので.

到着すると、8:23分発のバスは既に止まっていて、その前に列ができていました。

バスが来てるのに列ができてるのが不思議でしたが、バスは既に満車で、乗れない人が次の便を待っている状況でした。

この時間のバスは20分に一本なので最低でも20分は待たないといけないことが判明しました。もしかしたら40分待ちになります。

初心者で不安もあったのでできれば早めに登り始めたく、思い切ってタクシーに乗りました。 同じく並んでる人と相乗りしたかったのですが、声をかけた方はバスやロープウェイの割引チケットを買っていたらしく、残念ながら一緒に乗れる方が見つからず、そのまま乗りました。

料金は3000円でした。

あとで職場の人にこの話をしたのですが、タクシーの相乗りは「話さないといけないし、話さないと今度は沈黙がつらい。だから基本相乗りはしたくない」との意見が多かったです。私のコミュ力は高くないですが、世間話くらいはウェルカムのつもりだったので、その温度差に気づいてなかったです。

ケーブルカーが9時から運行開始なので、次回はその時間に被らないようにもう2本くらい早いバスを考えてみたいと思います。

2. 登山開始

タクシーで大山ケーブルバス停到着すると、すぐ目の前にトイレがあり、ここはキレイです。

山道に入る前にしばらく石畳階段の参道を登ります。両脇にはお土産屋さんやご飯屋さんが並んでいますが、朝は開店準備中。

この参道が上り階段で、段数も結構あるので、登山道に入る前でもそれなりに疲れます。

参道が終わるとロープウェイの駅が現れました。 正確には、右に曲がればロープウェイの駅、そのまま行けば登山道、という分岐です。

ロープウェイには乗らないので直進。一緒に登る予定だった相方は参道ですでに疲れたとのことでロープウェイを選択。ロープウェイは片道670円です。

直進すると、すぐに男坂、女坂の分岐が現れました。 事前調べで男坂の方が大変と知っていたので、男坂を選択。ちなみに「体力に自信がない人は男坂はやめておけ」的な表示が出ています。

男坂では、太ももを腰より高く上げる必要のある急な石階段が続きました。 かなり大変で、途中休憩を挟みながら進みました。 警告するのも理解できます。

上りはきついし、下りは怪我しそうな道でした。

なんとか登りきると、女坂を登ったルートと合流し下殿に到着です。

トイレがあるので休憩。任意で利用料を払います。ロープウェイも下殿までしかなく、相方と合流です。

下殿にはお店やお土産屋さんもあります。 残念ながらあまり関心がないのでスルーしました。

3. 山頂へのルート

後半戦、山頂まで向かいます。

後半戦入り口に100円でお守りを持っていけと記載があったので、払います。 100円を入れて2歩歩いたら、目の前に長い階段が現れました。きれいに造られた石階段ですが、いきなり心を折りに来ているようにも見えます。

ここからは○町目と書かれた目印が置かれています。全部で28町目まであり、どこまで進んだかなんとなくわかるようになっています。

yamap を見ていましたし、他の登山客もたくさんいたので、迷う心配はなかったですが、数字が増えていくので、進捗が出ている感はあってこの目印は楽しかったです。

山頂までのルートも岩の階段をひたすら登っていくようなルートで、男坂ほどではないですが、男坂と合わせて太ももにかなりの負担でした。相方は体力がなく、こまめに休憩を入れましたが、自分一人だったとしても頻繫に休憩が必要になったと思います。

途中、中学生サッカーチームの集団を先に行かせたりしました。 登山客も多かったし、中学生がトレーニングとして使うような山で、初心者向けと言われるだけはあると思いました。

ちょうど12時に登頂。

山頂の眺めが良かったです。 山頂にもお店が一つあって、席もたくさんありました。先ほどのサッカー少年を含め、多くの登山客で賑わっていました。 持ってきた羊羹を食べて少し休憩。

山なので当たり前ですが、小さな虫が尋常じゃないくらいいて、残念ながらゆっくり留まる気にはならなかったので、早々に下山を始めました。

4. 下山ルート

下山ルートは、往路を引き返すことを考えていましたが、登りと同じ岩道を下るのは大変だし、まだ登りの登山客も多かったので、急遽別ルートで、見晴台の方を通って下殿まで帰ることにしました。

ちなみに調査不足だったのでこのルートはよくわかっておらず、降りてる人が多かったので従った形です。

往路の岩道はあまり舗装されてなく、大変な山道という感じだったのですが、帰りのルートは階段づくしの森の散歩道という感じでした。

階段のへりだけが細い丸太になってるような、山の土の階段、という感じです、伝わりますかね。 ただひたすらに階段を下っていたので途中から足がプルプルしていました。

下山している間、虫がずっとまとわりついてきていて、足を止めて休憩しようものなら三秒で計10匹くらいが頭の周りを飛び回り、目にも入ってきそうな勢いでした。 次回からは虫除けスプレー必須です。 これは蚊ではなく、コバエみたいな虫だったので、さされたりはしなかったのが幸いでした。

時間の問題なのか、それともルートの問題なのか、とにかく虫がすごかったのだけとても記憶に残ってます。

永遠の下り階段を終えて見晴台につくと、下殿方面への分岐があり、そこからは等高線に沿って歩くので、高低差がなく、散歩でした。途中に滝があって、観光としても良かったです。

相方を再度ケーブルカーに見送って、下殿からの帰りは女坂を選びました。 男坂はすでに書いた通り危なそうだったのと、別ルートを見ておきたかったのが理由です。

女坂は階段の高さこそきつくはないものの、その分だけ段数と距離があるので、男坂と比べて危険度は低いものの、必要な体力は変わらなそうだなと思いました。

途中、ケーブルカーの線路が見えたり大きな神社があったりで、お楽しみポイントはあったのも、男坂との違いでした。

5. 登山後のリフレッシュ

登山のあとは、鶴巻温泉に行く予定を立てていました。 参道を抜けてバス停まで降りると、伊勢原行のバスがちょうど来ていたので、乗り込みました。鶴巻温泉の直行便もあるんですが、それは本数が少ないので、伊勢原駅まで行ってしまう方が早いと思います。

バス停のトイレの横に靴を洗う場所があったらしいのですが、気づかなかったです。靴を洗わずにバスにのるのはマナー違反だったのかなと反省してます。

伊勢原駅についたら、電車で一駅乗って、鶴巻温泉駅に移動です。駅からは近かったです。

鶴巻温泉のサイトを見ると、タオルレンタルはなく、売店で買うしか無いと書いてあったので、念のためコンビニで三百円でタオルを買ってから行きました。見間違いじゃなければ、売店で小さなタオルがコンビニの倍以上の値段だったので、買って行ってよかったです。

温泉に到着したら靴を洗う水道が用意されていて 登山客もたくさんいたので、大山登山をする人にとっては鉄板のルート なんだということが伺われました。

温泉は日中でも登山客でにぎわっていました。いい湯でした。

余談ですが、鶴巻温泉駅にはもう一つ"陣屋"という宿が検索で出てきました。こちらはどうやら高級旅館みたいです。 日帰り入浴はご飯を食べた人であれば可能と書かれていましたが、ご飯が1万円以上するので、実質的には、日帰り入浴で行くのではなく、ご飯や宿泊目当てで行く場所みたいです。

まとめ

初めての大山登山をまとめました。 学びを簡単にまとめると、

  • バスを何本か待つことになるので、ケーブルカーの時間も考えて早めに駅に着く
  • 虫除けスプレーを忘れない
  • 登山用、温泉用でタオルは2枚以上、温泉用の着替え、はしっかり用意

といったところです。次の山はどこにしようかな。

AWS SAA の学習リソース ~ ChatGPT を添えて~

AWS Certified Solutions Architect - Associate を取得しました。

Associate 資格に対して、「普段AWSを触っていて、ベストプラクティスを知っていればちょっとの勉強で取得できそう」と思っていませんか? 私は思ってました。

しかし実際は、想像以上に範囲が広くて大変でした。受験後も正直落ちたと思ったくらい。舐めてかかってはいけません。 私のAWSの経験が2-3年というのはありますが、経験の長いエンジニアでも、試験範囲全てを触ったことがある人は少ないんじゃないでしょうか。 (DirectConnect, Snowball family, Kinect, ECS/EKS と全て知ってる方は少ないのでは...?)

ちなみに Associate を取得した理由は、取得すると会社の中で嬉しいことがあるからです。

そんなわけで体験記として、 勉強リソースについて書きます。 結局試験なので、一定の勉強時間を投下できれば何を使っても大丈夫だと思います。

何を使って勉強したか

勉強を始めるにあたって、何を使うのが効率的か分からなかったです。 ざっと調べると、

あたりが見つかるのですが、良し悪しがわかりませんでした。 正直なんでも良いと思ってたので、公式かつ無料の AWS skill builder を使うことにしました。

AWS Skill Builder

コースがいくつかあるのですが、試験対策用のページと思しき "solutions-architect-learning-plan-earn-a-learning-badge" のコースに Enroll してコンテンツを消化していきました。

試験範囲の分野を解説する動画やリソースへのリンク集になっています。 コンテンツごとに学習にかかる目安の時間がかかれており、合計で 220 時間あります(長過ぎる)。 取捨選択して飛ばしながら進めれば終わるかなと思ったのですが、試験が近くなっても 30% 前後しか終わってなかったので全てやるのは途中で諦めました。

良かった点

  • 動画リソースが充実している。
  • 動画は軽いし、速度も簡単に調整可能、スクリプトも説明もついてる
  • 試験の形式を確認できる動画がある。最初にやっておくと良い。

注意点

  • 過去のコンテンツも含まれているので一部内容が古い場合がある
  • 別のコンテンツで内容に重複もある
  • 英語

結論として、AWS Skill Builder を全部こなすのは試験対策として、また学習の観点からもあまり効果的ではないと感じました。

実際に AWS Service 触ってみる(おすすめ)

勉強する中で出てきたサービスやユースケースを実際に使ってみたりしました。

良かった点

  • 楽しかった
  • 周辺情報も一緒にインプットできる
  • 適当にRDSを立ち上げたら三連休明けに請求が $100 くらいになってたなど、ハプニングがあるので記憶に定着する

注意点

  • 学習になるとはいえ、油断すると思わぬ課金をされてしまう。(私は会社の学習用の AWS アカウントを使っていたので、反省はしつつもダメージが少なかった)

試験対策の観点では時間対効果が悪いかもしれないですが、学びとしては一番良いと思います。

Ping-t

試験4日前に、もっと問題を解いておきたいと思って、はじめました。

良かった点

  • オンライン問題集サービスで、SAAの問題を解くには無料で使える。
  • 問題数がたくさんあり、問題ごとに解説がある。とても良かった。
  • 日本語の方が解説が頭に入ってきた。最初から日本語で勉強しておけばよかったと後悔。
  • Ping-t だけで合格したという体験記もあるみたい。不思議には思わない。

注意点

  • 日本語のみ。私は英語で受験したので、他の英語問題*1も使った

もっと早く使い始めればよかったと感じています。非常におすすめです。

ChatGPT

ChatGPT は Plus を契約していますし、当然何度も使ってました。しかしやはり万能ではないです。

良かった点 - 似たAWSサービスの違いをチャット形式で雑に質問できたこと。 - "雑に" というのがポイント。自分の理解度に合わせて、十分な理解まで最短でたどり着ける感覚がとても助かった。

注意点

  • 聞いた内容が正しいかは分からないので、気をつけないと誤った理解をしてしまう。
  • 問題作成も依頼してみたのですが、他の問題サイトと比べ、実際の問題と乖離がある感触でイマイチ。
  • 問題自体はネットにたくさんあるので、ChatGPT に出してもらわなくても、既存のリソースを使い尽くせば良い。

問題を作らせたりはできないですが、疑問に思ったことは自分の言葉でどんどん聞きます。

資格は目的ではなく、勉強するための手段

私は資格そのものに大きな意義を見出していないため、会社からの特別なインセンティブなどがなければ積極的に取得するつもりはありません。 ただ、勉強のためのマイルストーンとして試験を置いたことはあって、そこに一定の価値は感じました。メリットは、

  • 試験日を決めておけば、強制的に期限が決まる
  • 試験があるのでちゃんと勉強する気分になる

です。

今回も、期限がなければだらだらと AWS Skill builder の動画を見て、そのうち飽きて勉強をやめていたと思います。 オンプレ関連のリソースについても知ろうとしなかったでしょう。 なので、試験の予約を先にして、そこに向けて頑張って勉強、みたいな形で付き合っています。

おわりに

余談: 日程変更は24時間前がタイムリミットなのですが、試験 2日前の時点で勉強不足を感じてました。 そこで、 Ping-t をランダム60問で受験して、43点以上取れなければ試験日程を延期しよう、と決めて解きました。結果は、ぴったり43点でした。 内心延期したかったので、この数字には一人で笑ってしまったのですが、結果的には今回は良い方に転んだので良かったです。

Professional を受験するときはしっかり自信をもった状態で受けに行きたいと思います。

Go Conference 2023 聴いてきました!(感想とメモ)

GoConf 楽しかった

GoConference に初参加して、セッションを拝聴しました!

有休を取って、個人として参加です。休みをとったのは、

  • 単純に申し込みタイミングで現職に入社してなかった
  • 業務と並行すると集中して聞けない
  • 業務枠だと、会社に還元しなきゃ、ちゃんとした記事書かなきゃ、といういらないプレッシャーを(勝手に)感じてしまう

のが理由です!

有休を取っても、ずっとsessionを聞き続けるのは大変なので、結局休み休み聴くことになりました。

どのセッションも濃くて面白く、こんなにいい話が無料で聞けるのは運営・スポンサーのお力あってこそだと思います、本当にありがとうございます!

拝聴したセッションpickup

聴いたセッション全てではないですが、いくつかのsessionについて感想(自分にとってのメモ)を残します!間違ってたら教えて下さい!

タクシーアプリ『GO』高速マッチングシステムで実践したGoチューニングテクニック

speaker: https://twitter.com/74th

配車の高速マッチングシステムをパフォーマンスを維持しながらマイクロサービスに切り出した話でした。

タクシーを呼ぶ人も複数、車(タクシー)も複数いる中で、全体最適なマッチングを計算する必要があります。 誰かが長い時間待たされることもないようにする、という制約条件もありますし、簡単な計算ではないと思います。 今回のセッションはアルゴリズムはスコープ外だったのですが、個人的にはそこも面白そうだなと感じました。

パフォーマンスを維持していることの確認のためのツール(E2Eやガントチャート)を整備したり、バッチ処理を導入した上で最適化したり、既存システムの価値を損なわないために丁寧に進めててすごいなと思いました。 マイクロサービスへの切り出しをする人にとっても参考になる事例だと思いました。

無理なく始めるGoでのユニットテストの並行化戦略

speaker: https://twitter.com/sho_hata_

slide: https://speakerdeck.com/shohata/go-conference-2023

テストの平行化をするためにあれやこれやをした話でした。

-p オプションと -parallel オプションが別物なのをしらなかったです、勉強になりましたmm

サブテストの平行化をするためには t.Parallel() をそこかしこに書く必要がありますが、面倒なのでツール作っちゃっててhack精神がいいなと思いました。 その他、平行化でに当たって気をつけること、課題解決ツールについて端的にまとまっていて、勉強になりました。

よくわかるThe Go Memory Model - 行間を図解で埋め尽くす

speaker: https://twitter.com/shino_nobishii

material: https://github.com/nobishino/goconference2023/blob/main/glossary.md

goを深く理解したい人がぶつかりがち(らしい)なMemory Model についての解説でした。

講義が設計されていて、教えるのがうまい教授、って感じでした。 Memory Model については全くしらなかったのですが、すごいわかりやすくて、理解した気になりました。 とりあえず datarace オプション (-race) 付けなきゃ、ですね。

話がわかりやすくて面白いのもそうですが、概念自体も面白かったですし、go のメモリ管理を深く理解したいなと思いました。 「逐次一貫モデルはほとんどの良いGoプログラムについて成り立つが、全てのGoプログラムについて成り立つわけではない」とか、言い回しが素敵でした。

多様なプロトコルと駆動モデルをサポートするIoTゲートウェイの開発と運用の知見

speaker: twitter.com

slide: https://speakerdeck.com/takesinoda/duo-yang-napurotokoruto-qu-dong-moderuwosapotosuruiotgetoueinokai-fa-toyun-yong-nozhi-jian

いろんな現場で動いているIoT機器と自社クラウドをつなぐ間にいるゲートウェイについての話でした。

個人的に、ハードウェアとソフトウェアの両輪で課題解決するプロダクトが面白いなと思っていて、全く専門外でしたが楽しく聴かせていただきました。

工場や重機の中など、ハードウェアが置かれる環境は様々で、また、何か問題が起こった時にSSHしたり実際のハードウェアを触りにいけるわけではない、とかなり厳しい条件だなと思いました。 ハードウェアの通信規格は本当に様々で、それをゲートウェイを噛ませて一定の標準化をするわけですが、それぞれにドメインが深かったりするので開発も運用もかなり大変だよな〜と思ってました。

GoCon でもありますし、セッションの内容はシステムのリアーキテクチャとそれをgoでどうやって実現したかの話がメインで、これも面白かったです。

Dive into testing package ~ Part of Fuzzing Test ~

speaker: https://twitter.com/sivchari

slide: https://speakerdeck.com/sivchari/dive-into-testing-package-part-of-fuzzing-test

testing package の実装まで潜って理解していく話でした。昨年に基本編を話していたらしく、その発展編でした。

基本編をしらなくてもわかるように構成してくださってたのですが、途中でボーッとしてしまって、途中から追えなくなりました。 基本編も含めて読み直させていただきますmm

Escape Analysis in Go: Understanding and Optimizing Memory Allocation

speaker: Harsh Gupta (@dhrsh24) / Twitter

(最後のスライドにリンクが資料へのリンクがはられてたのですが、メモれなかったです...)

英語のセッションでしたが、スライドに日本語も書いてくださってました。

escape analysis の説明と、メモリ最適化のためにどのように書くと良いか、の話でした。

関数内で宣言した変数は関数のスタック領域にメモリが確保されますが、宣言した変数が関数の寿命よりも長生きする場合、その変数はヒープ領域にメモリ確保されます。 スタック領域は自動で解放されますが、ヒープ領域の解放はGCをまたなくてはならず、結果メモリ効率が悪化します。 どちらの領域でメモリ確保するかはコンパイル時に決定され、その様子は -m -l オプションを付けてbuild すれば見ることができます。

...と、理解しました

関数内で宣言した変数をポインタを返して外から使う、みたいなお行儀の悪いことはしていないと思いたいですが、改めて意識しながらコーディングしようと思いました。

Go1.20からサポートされるtree構造のerrの紹介と、treeを考慮した複数マッチができるライブラリを作った話

speaker: https://twitter.com/convto

slide: https://speakerdeck.com/convto/introduction-of-tree-structure-err-added-since-go-1-20

タイトル通りの話でした。

proposal の議論を紹介しつつ、仕様の意思決定がどう行われたかまで紹介してくださって、わかりやすかったです。 仕様の問題点について可能性を考えた上で、実際に議論に上がっていた別仕様について実装してみて、今の仕様がバランスのとれた落とし所だという結論にたどり着いていました。 批評で終わらず、手を動かした上で自分の意見を持つ、というのがすごいなと思いました。批評家で終わらないようにと改めて自戒しました(この記事はメモだから許して)。

Goのデバッグ用ロガーの開発を通して得た, デバッグとgoパッケージに関する知見

speaker: https://twitter.com/task4233

slide: Goデバッグ用ロガーの開発を通して得た デバッグとgoパッケージに関する知見 - Google スライド

デバッグする際の選択肢について整理した後、消し忘れがちなデバッグロガーをコミット前にgit hooksで削除する仕組みの話でした。

たしかにデバッグロガーを消し忘れることはあるので、素晴らしい仕組み解決だなと思いました。 あと print がbuiltin にあるの知らなかったです。

AST関連をgoで扱う基本的な方法も紹介されていて、linter 自作してみたい機運が高まりました。

sync.Mutexの仕組みを理解する

speaker: twitter.com

slide: https://speakerdeck.com/ffjlabo/sync-dot-mutexnoshi-zu-miwoli-jie-suru

sync.Mutexの内部実装まで見ていって、完全理解するまでの流れを一緒に進めてくれる話でした。

排他制御はOSの仕組みを勉強するときに触れたことがありますが、自分で実装しようとしたら失敗する気しかしないな、と改めて思いました。

Deep Dive の話でもそうですが、内部実装もgoで書かれているから読みに行けるのはgoの良いところであり、好きなところです。

おわりに

ちゃんと聞けなかったセッションもキャッチアップしていきたいです。(それが難しいからリアルタイムに参加している節もあるんですが、気持ちは気持ち)

あらためてスポンサーの会社様、運営の皆様、登壇者の皆様、盛り上げてくださった参加者の皆様、ありがとうございました!

自分も登壇できるようになりたい..!