週刊ニュース Lv2（2022年11月19日～2022年11月25日）

前回は週刊ニュースを substack というサービスで書いたのですが、素早くアウトプットできることもあり、媒体を分けずに今のブログでやることにしました。前回の週刊ニュースも移行済みです。

11 月 19 日(土)

最近 Go を学んでいるのですが、この日は改めて Go 言語やりたい！となってそれを言語化しました。

Go 言語をやっているのは mattn さんに憧れているのもあるし、勝手に低レイヤーに近い言語だと思っているので、低レイヤーを学べる数少ない機会も Go だと多そうだし、長く使っていけそうだし、シンプルな言語仕様だから追っていきやすそうだし、初心者とプロでもそう書き方に違いが出る言語でもないしと色々あるけど、最終個人的に好きだからやりたい。

また、Go で何か作りたい！となったので Go の活用事例をたくさん調べました。

調べた活用事例たちの中でも一番腑に落ちる説明だったのが下記です。
- go を利用する傾向が強いのは、最初から強くスケールを意識している。ゆえにコンテナ技術やマネージドクラウド・オーケストレーションの中で用いられる傾向が強い。IoT/基盤技術/一部データサイエンス周り/大規模システム/高速なキューイング処理などをするシステム/普通の http rest などだがまるで大規模バスシステムなどのように爆速で振る舞うニーズ　などが多いと思います。
  参考： Go 言語が現在落ち目になってきていると聞きました。ついこの間までむしろこれから伸びる言語として扱われていたのに、いきなり評価が逆転してしまった理由は何故だと思いますか？
調べた活用事例たち

Windows 純正のメンテツール「PC Manager」を使ってみました。

winget でインストール(winget install Microsoft.PCManager)することができ、早速 Boost ボタンを押してみると、自分の場合は 1.9GB くらいあった temp ファイルを削除してくれました。UI もわかりやすく直感的に操作することがきて、Windows 純正というのも推せるポイントでした。すでに導入して 1 週間くらい経ちますが、問題なさそうなので今後インストールアプリのリストに加わることになりそうです。
参考：購入直後のヌルサク感が復活!?　 Windows の純正無料メンテツール「PC Manager」を試してみると…

同僚からオススメされていた WEB+DB PRESS Vol.130 の「イミュータブルデータモデルで始める実践データモデリング」を読みました。

「1 つのデータが複数の業務で更新される場合は、アプリに複雑性をもたらす」という所は大きくうなずきながら読んでました。
3 章は実践的な話だったのですが、社員と部門テーブルは社員が登録されるタイミング、部門が作成されるタイミングはそれぞれ別。社員と部門が結びつくのはその後のタイミングなので、それは所属という交差テーブルで表現するなど、今まで中間テーブルというものがうまく説明ができなかったのですがすごく納得できました。実際にテーブル設計するときにまた読んで理解を深めたいです。

11 月 20 日(日)

この日も引き続き、Go で何か作りたい → 業務で Go を活かせることはないかという観点で調べていました。

最終的に Go で今すぐに業務で活かせることは何かという問いの答えはでませんでした。
また、副産物として映像分析ツールを小・中・高校で導入している事例をいくつか見つけてこれは自社で開発しているサービスと相性が良さそうという確信を持つことができたので、よくなる DB に事例や案をまとめて提案するまで行いました。(よくなる DB はサービスがよくなると思うアイデアを集めた DB でそのアイデアを元にプロダクトロードマップに含めていくかを意思決定していきます。)

11 月 21 日(月)

#go-zassou、#dev_sports_tech_challengeという 2 つの新しいチャンネルが生まれました。

Go で何かしたいという想いがあったため、Classi さんのRuby の会社の手札に Go を加えるまでという記事を参考に#go-zassouチャンネルを作りました！このチャンネルをきっかけにいろんな技術の話に花が咲いたりしたので作ってよかったとおもいます。
さらに、#dev_sports_tech_challengeというチャンネルも生まれました。少し外に目を向けてみると、スポーツ x IT で問題解決に取り組んでいる企業はたくさんいて技術のレベルも高いと感じました。#dev_sports_tech_challengeというチャンネルでは、スポーツ x IT で問題解決したいときに相談したり共有したりお互い高め合うことができそうと思いで作りました。

11 月 22 日(火)

アトミックノートは再度着手するときのトリガーとなるようにブレインダンプまでしておくという知見を得た

あとでアトミックノートを書こうと思い、とりあえずタイトルだけ書いておいたのですがタイトルだけでは思い出せないということがわかりました。構造化まではしなくていいもののそのとき思ったことをブレインダンプしておく必要があると思いました。

最近は組織が小さいうちから今後スケールするためにできることを考えています。

組織が大きくなったときに急にスケールしなくなるのは、それは今まで個人で技量のある人がいい感じで回してくれていたからという仮説を立てました。
仮説が正しいかどうかはわかりませんが、小さいうちからコアメンバーが自然とやっている素晴らしいこと、カルチャーを仕組みとして実装するのが良さそうではと思っていますが、メンバーと話し合いながら模索していこうと思ってます。

11 月 23 日(水)

mattn さんのライブコーディングで機械学習試してみました。

1 年前くらいに Vim のことを知りたくて見たのですが魔法すぎてナニモワカラナイだったのですが、今見るとスコシワカルくらいになっていて成長を感じました。今でも mattn さんのコーディングは早すぎて止めないとわからないのですが…Vim と Go 言語と機械学習どれも興味ある人は入り口としてもっともコスパがいいのでおすすめです（笑）
ゴリラ.vim #16 ~ mattn さんのライブコーディング

11 月 24 日(木)

この日は 24 時くらいまで実装をしてました…全然終わらなかったので、月曜日の自分に任せました。

11 月 25 日(金)

チームのエゴ（価値基準）があるとよいという話をしました。

最近、「Team Geek」という本を読んでいて、自分のエゴよりもチームのエゴを優先すると個人間で対立もなくなるし、何よりチームとして何を優先したいのかがあるのはいいことだと思いました。なので、その話をなにかの拍子にしました。チームのエゴが今はないのでメンバーと話し合いながら自分たちチームのエゴはなんだろうと考えてみたいです。
自分をよく見せようとするよりも、「集団」のエゴを考えみてはどうだろうか。チームの功績やグループの誇りについて考えてみよう。 1.6.1 の「エゴをなくす」

改めてブログをどうするか考えた。

今のブログは Roam Research の static-site という拡張機能で構築しました。かなり大変だったのですが、最近は毎月の維持費が気になり、広告をつけたりしましたがあまり足しにならず引っ越しなどを検討していました。最終的には、シンプルなマークダウン管理も git 管理は面倒だから気が進まない、今の Roam Research のインターフェースはやっぱり魅力的、なんだかんだ引っ越しは大変、ということもあって今のまま運用していくことにしました。ただ将来的にはパブリックなデジタルガーデンに興味があり、それは今の static-site では実現できないので、Roam Gardenのような形で無料で git 管理不要なものが出てきたらデジタルガーデンだけはそっちでやるとかはあるかもしれません。