自分はMachine Learing Casual Talksという勉強会の運営を @chezou さん、 @tetsuroito さん、 @komiya_atsushi さんの運営陣に合流する形で 2018/7 に再開しました。
もともと自分は根底として勉強会運営が好きで、つくばにいた頃から、tsukuba.rb や PRML勉強会などの勉強会運営をしていたというのもある。
詳しい経緯は過去に記事に書いていた。 見返すとなかなかにエモい文章ですね。
Machine Learning Casual Talks #5 を開催しました
その後子供が産まれる直前の 2020/05 に12 回目を開催して以降、育児で時間的・精神的余裕がなくなって開催が途絶えてしまっていた。
2021/06 に社内チャットで、
育児で運営が途絶えてしまったんですが、皆さんどう克服しましたか?
という質問したら、要約すると
@lestrrat さん 燃え尽きてもいいじゃないか by @lestrrat @sinmetal さん 志低く、無くならないようにしようぐらいの気持ちです。 と多種多様な考えを聞けて自分の中でも色々と考えが深まりました。
当時の僕の反応を拾ってみるとこんな感じ
志が低いというのはとても良いですね。存続させるの大事だなぁと痛感してます:relaxed: 僕も学生でつくばにいた頃東京の勉強会は参加できないけど、資料公開してくれるのありがてぇ、そしてこの分野(機械学習エンジニア) に興味あるけどそもそも鶏卵問題で経験がないと参入できないから知見を公開してくれるの助かるなぁという思い出があったなと今思い出しました w 今は実務でバリバリ触れているからこそ初心を忘れてしまったのかもしれないので、情報発信の大事さを今一度噛み締めました
で、 2022/02 の現在ふとリアル開催?の時に比べるとオンライン開催ってめちゃくちゃ省エネで開催できるなと気が付きました…!
開催の手間 やるべきことを簡単に洗い出してみます。
共通部分 開催前 登壇者探す connpass 作成 Twitter 告知 当日 Twitter 実況 司会 リアル開催 数ヶ月前 会場確保(自分の場合メルカリの会場を毎回スポンサーとしてお借りしていた)。なぜならメルカリが勉強会会場として高頻度で使われるのでハコを抑えるのが毎回激戦区だった。 スポンサーしてもらうために申請 当日(会社にて) 開催ビルで準備。入場用の道具(入場用、案内用の看板設営、ポスター印刷して看板に挿入) 開始時間 1 時間前から動き出す 懇親会のデリバリー受け取り、配備 会場の音響設備、接続確認 100 個以上の椅子や机を勉強会スタイルに並び替える(これがマンパワーが必要で地味にきつい、これを運営のみんなでやっていた) 登壇者全員の接続確認 懇親会終了後撤収 ゴミなどがちゃんとゴミ箱に捨てられているかの確認と清掃 机・椅子などもきれいに全部拭いて、元の形に戻す。基本的に準備したものをすべてもとに戻していく 9 回目以降は、撤収ボランティア枠を設けて手伝ってもらっていた。確か 8 回目の時に @keisuke_umezawa さんや @nasuka さんが手伝いますよと自発的に行ってもらえてめちゃくちゃ感激した覚えがある(実際は 4-5 人に手伝ってもらいましたが全員は覚えてないです、すみません)。この場面は本当~に良い記憶として残っている。なんか運営していてよかったと思った一番の記憶かもしれない。その後毎回無償で手伝ってもらうのは申し訳ないので、抽選枠ではなく、ボランティア枠と撤収作業を手伝ってもらえると、確実に勉強会に参加できますよという仕組みを作った覚えがある。 21:30 に撤収開始で、終わるのは 22:30 くらい。帰宅は日付が変わるか変わらないかという感じ オンライン開催 前日 配信が問題なくできているかのリハーサル 当日(自宅にて) 開催 30m 前に登壇者にビデオチャットに参加していただき、接続確認 懇親会終了後、そこはすでに自宅。例えば 23 時に終わったとしても、23 時には家にいるこれって凄い。 とオンライン開催のコストは比類できないほど低いことがわかりますね。...
最近、技術的負債の優先順位付けとどうやって消化すべきかを考えていた時に、同僚のスーパーエンジニアの方から本質的なアドバイスを聞けたのでメモ。 自分は技術的負債タスクの消化をどうやって仕組み化して、定常的に消化していくべきかを試行錯誤していた。
なぜなら、機能開発と比較すると優先度が低くなりがちな技術的負債タスクを定常的に消化できているチームこそ、短期と中長期の視線を兼ね揃えたバランスが取れた戦略が取れているのではと考えていたからだ。 なので消化できないのは仕組み化がうまくできていないから、どうにか解決できないかなと思っていた。
だが、同僚がくれた言葉で目から鱗が落ちた
その技術的負債解消が本当に必要ならやりますよね。 必要でないならやらない、他にもっと重要なタスクがあるなら、そっちを優先するのでいいんじゃないかなと。 本当に必要なタスクならやると優先順位付けするので、直近必要でないと思っている無理して消化する必要はないですよ。
なるほど、これに尽きる。 今までは優先度が低かったとしても技術的負債タスクを消化できていることが良い文化なのではと勘違いしていた。
そのタスクを解決したら何が嬉しいか、どんな価値を提供できるかを常に考えて、優先順位付けを行って抱えている技術的負債タスクの中でも選定して解くべき課題に集中して解くべきだと学べた。
それこそが価値を生み出すエンジニアだなぁ。学び
注)もちろん場合によりけりなので、自分がいる環境での学びです。
2021 年に購入して、今も愛用しているものを記しておく。 買ったものだと、その後愛用しているか定かではないかつ良い品なのかわからないので、愛用しているもの限定です。
CORONA(コロナ) 衣類乾燥除湿機 除湿量 18L (木造 20 畳 / 鉄筋 40 畳まで) 日本製 Amazon
買ったきっかけは、2020 年に築浅の物件に引っ越したが新築の傾向なのか湿気が溜まりやすく、油断して、パントリーの床においていた旅行用のボストンバッグがカビてしまっていたことがあった。水取りぞうさんなどで対応していたことがあったが、知らぬ間に満水になり気づくのが遅れることが多かった。
そのため思い切って一番除湿力が高そうなこの機種を買ったところ大満足。梅雨の時期には一晩起動しておくと朝には 4.5L のタンクが必ず満タンになり、部屋の中に漂う嫌なモワモワ感が完全に消え去って住心地が圧倒的に向上した。また副次的に良かったのは衣類乾燥機能がすごく良かった。雨で部屋干しをせざるを得ないときもこの機能を使えば全く臭わずに乾燥させることができて、一粒で二度美味しい家電だった。またフィルターも 10 年は交換しなくても良いのが良い。1 年経った今でも全く臭わない。タンク自体も特有の臭さが全くないので最高。
AfterShokz Aeropex 骨伝導イヤホン Amazon
リモートワークの開始に伴い、最初は 2019 年頃にオフィスでの騒音対策として購入したWH-1000XM3を使っていたのだが、長時間つけると耳が痛くなることが多かった。またイヤーインタイプのイヤホンも自分は耳の形が合わなくてフィット感がいまいちだったりモゾモゾして 1 時間のミーティングでも嫌なことが多かった。AirPods も検討したが、自分は iPhone ではなく Pixel を使っているし、気づかずに落として紛失しそうで怖かったのでなにか良いイヤホンがないか探していた。Shokz はその悩みを完全に解決してくれた。耳は防がないし、1-2h つけても全く痛くならないし、何より軽い。Shokz はいろんなシリーズがあるが、
ミドルレンジのものを買ってなんか違うなと思うのは嫌だったので思い切ってハイエンドモデルを買ったがとても満足している。もしかしたらOpenMove でも良いかもしれないが、試したことがないのでわからん。ブランド名も After・Shokz から Shokz に変わって、(OpenRun Pro)が出たのでちょっと気になっている。バッテリーが更に長持ちなのと小型化、低音が効くようになったらしい。
Shokz いいですよね！自分も使ってます。新しく出る OpenRun 系統は 29g と、Aeropex と比べると 3g 重いようです。小型化の方がより適切かと感じました。 by @tatsuokundayo
2022/01/08: @tatsuokundayo さんにご指摘いただいた点を修正
WH-1000XM3はノイズキャンセリング機能は感動するレベルだったが、オフィスに行くことがなくなった今、用済みなのでメルカリで売った。速攻で売れたので気持ちよかった。
Xiaomi Mi ハンディクリーナー ミニ Mi Vacuum Cleaner Mini コードレス ミニ掃除機 ハンディ掃除機 Amazon...
Objective 1 検索エンジニアの領域でシニアレベルのスキルを身につける
KR 1 2022 年に国際会議・インダストリー会議のどちらでも良いので、対外発表できる成果を出す 成果を提出するのは 2023 年で OK
KR 2 Python, Go の両方を自信を持って書けるように。 TODO: 定量的に測定して数値化する
Write Code Every Day とか良いのかもしれない? wakatime とかでどれくらい書いたかを算出しても面白いかもしれない。 もしくは Atcoder とか?
Objective 2 有限な自分の時間の管理を生産的に行って、手を動かしまくる習慣を身につける
KR 1 Toggl を積極的に使って、1 年間どれだけ生産的な時間を創出できてか可視化する KR 2 継続して、SNS は断つ(ダラダラと見ない) 2021 年も設定していたが、2022 年も引き続き。連絡手段と周知を行うことのみに特化して使うようにする。 SNS での情報取得は辞めて、RSS や News letter などで情報を取得するようにしはじめた。今の所凄く良い。 自分も News letter を過去にやって続かなかったりしたけど、なんかやってみたいなと思うようになりつつも Blog でいいのではと思ったり…
KR 3 2021 年の 5 月から開始している翻訳プロジェクトを一段落させて出版可能な状態まで持っていく 詳細はまで伏せますが、自分が発起人の翻訳プロジェクトがあるんですが、今年の年末までには出版可能な状態まで仕上げていきたい。 友人 2 名を誘って始めたプロジェクトだが、初めての経験ということもあり学びが多い。...
うなすけさんの wakatime を利用した振り返り方が面白かったので、来年は真似したいと思い導入してみた。
サーバーサイドエンジニアとして 2021 年に使った技術と来年の目標
なので先週くらいから wakatime を使って、VSCode での利用統計をとってみることにした。
https://wakatime.com/
Markdown が圧倒的に多いのは現在 Markdown で執筆活動をしてるからですね。
仕事をほぼ納めてから導入して執筆しかまともにしてないからこうなってるな。。。 詳細は今はお話できないのですが、再来年くらいには形になっていることを祈る。
利用した技術一覧 Language New: Go Backend 開発ではメインで使っている。今までは Python がほぼメインだったが、検索チームに異動したことで Go が必要不可欠になったので頑張って習得中。久々に新しい言語に触れるけど新鮮な気持ち。明確に型があると、エディタがガンガンサジェストしてくれて楽しい。間違ってるとすぐ知らせてくれる。Go も Python までのレベルまで引き上げて書けるようにしておきたい所存。 New: Java (code reading) 主に Apache Lucene と Apache Beam の code reading をしていたのがメイン。同僚からは VSCode ではなく、IntelliJ IDEA 入れたほうがめちゃくちゃ捗るよと言われつつもまだ使いこなせていない…。Lucene, Solr, Elasticsearch のどれかに来年は contribute してみたい。 Python Google BigQuery と組み合わせたデータ分析や可視化、Airflow で利用。あとは機械学習サービスの改修でも書いていた。なんだかんだ手に馴染んでいるのがやはり Python で、2022 年は一段階上のコードを書けるようになりたい。1/4 ほど読んで積ん読になってしまっている Fluent Python を読みきらないと… StandardSQL Google BigQuery でお世話になっている。まだまだ「え、こんな便利関数あったんだ」となる。ちょっとした前処理は BQ に投げたほうが遥かに効率が良いので、BQ→Python で何をどこまでやるかはバランス感覚がやはり大事。 Software New: Apache Beam Java は code reading, Python は自分で入門がてら形態素解析する Beam model を書いていた。Apache Beam Go SDK が GA になったので、なにか作りたい。原著論文も勉強会で今度話したいな。ストリーミングで処理を行いたい際には、選択肢の第一候補に入るソフトウェアかつ動いている仕組みがめちゃくちゃおもしろいので、もっと深堀りして書いていきたい。 New: Apache AirFlow (CloudComposer) GCP の各サービスを組み合わせてゴニョゴニョしたいときにものすごく楽。なれるまではデバッグが辛かった。そんなにこなれたことやっていなかったとしても、ピタゴラスイッチ的なデバッグが必要になることが多いので、最初は辛かったけど、慣れたらめっちゃ便利。 New: Apache Lucene 社内の code readning 勉強会で、近似近傍探索のロジックを眺めていた。 Amazon が e コマース検索を Lucene により、どうスケールさせているか at Berlin Buzzwords 2019 の記事でも Lucene 自体の特性を表層的に理解できてスゲーッ!...