neko2wakai
その日学んだことや再認識したことなどをだいたい毎日投稿します
読んだ本のメモや要約、これから取り込みたい部分とか整理用。ざっくりしか書いてないけど、ざっくりとは書いてあるようにしたい。
今日の学び非同期コミュニケーションでは色々注意するといい話 トピック事にGood/Badの例があってわかりやすい やりがちなことも書いてあって、大分刺さる 気を付けていることがGoodになっていて振り返りにいい コミュニケーションは同期/非同期問わずコストがかかるつもりでいると精神衛生上良さそう
今日の学びavroファイルを扱えるツールいろいろ Apache Avro Tools：CLIスキーマの表示: Avroファイルのスキーマを表示可能 データの変換: JSONや他の形式にデータを変換可能 ファイルの検証: Avroファイルが正しい形式であるかを検証可能 Apache Spark：pythonライブラリ分散処理: 大規模なデータセットに対して分散処理を行える 多言語サポート: SQLを含むさまざまなプログラミング言語をサポートしている avro-pyt
今日の学びgitの運用ガイドの話 ③適切な粒度で投げる、受けるは首肯した レビュワーに求める温度感や宵越ししないというのは目指したい リポジトリの構成上、宵越しすると破壊的な差分が発生してしまう場合もあるため、依頼からマージまでの速さは開発では重要かも 所感このnoteは日々継続を目標にしていますが、他の行動にも時間かかるようになってきたのでどうするか悩みどころです。
今日の学び言語化は大事という話 説明するときの要点 短く簡潔に 内容は目的と手段のセット 鍛え方 方法1 利害関係者と意見を一致させながら話し合いを進めること 上記を繰り返しながら改善していく 方法2 一人で要点をまとめる練習をする 先輩や同僚に聞いてもらう 所感自分の立ち位置と業務のフェーズそれぞれで目的を考えて頭においておくことが重要とのこと。 目的が頭にあれば、手段がそれを達成に近づけられるかを指標にして捉えられる。
今日の学びOSSコントリビュートチュートリアル git, githubの習熟 ossへの参加ハードルを下げられる ossカルチャーを学ぶ BigQueryのコスト調査の話 利用状況などを探るにはINFORMATION_SCHEMAが使える BIで可視化 terraform化もできるで 所感コスト周りの調査をする機会があり、これを機に一度調べてみる。 BigQueryにかぎらず、方法やステップに落とし込めるといい。
今日の学び開発環境としてdev containerを使ってみる話 設定ファイルを作成して、すぐにコンテナ内で開発に入れる ユーザ権限はルートだが、たぶん権限定めることはできそう 依存ライブラリも設定ファイルに記載する 便利ツールの話 CLIをシステム内の他のPythonパッケージから分離して管理するツール 開発環境を汚染せずに隔離された環境で実行できる pipやpipenvなどの既存のパッケージ管理ツールとは異なり、CLIツールの管理に特化している 所感
今日の学びGoogle Cloudの資格制覇の話 出題範囲の把握 ハンズオンで軽く触る udemyの問題集を回す 解答を表示して解答を読み込む 難易度ランキングあり 所感だいぶ前にAssociate取っただけなので資格駆動で勉強するのにいいかも
今日の学びNotebookLMがヤバい サイトリンクやPDFを読み込ませて質疑応答チャットが作れる 使えるソース種類は以下 Google Drive PDF テキストファイル コピーされたテキスト ウェブサイトリンク OLAP（オンライン分散処理）と相性のいいインプロセス分散処理DB「DuckDB」の正式リリースバージョン1.0.0の話
今日の学びドキュメント整備の話 必要なドキュメントの洗い出し 優先順位をつける ルールの制定 ディレクトリ名やファイル名のルール ページ名被りの避け方 周知のルール ドキュメント作成の負担を低減する slack通知を実際に使ってみる話 メンション通知を受け取れる DBのページ追加らプロパティ更新をトリガーにできる 所感ドキュメント整備の目標はこんな感じだろうか？ 構造認識の共有 誰でもどこに何がありそうかがなんとなくわかる ドキュメントの一生が設計
今日の学び視座の要素分解の話 問題発見から解決までのどの位置にいるかで視座の高低が変わる 相手がどのレベルで問題に取り組んできたかは採用で確認できる 記事では点プロットだが、温度プロットのように領域がありそう Aさんは問題発見から指摘までは頻度や詳細度があるが、以降は減りがちみたいな 自分はどうだろうかというのは意識してアクションを振り分けて記録することで伸ばしていけるか？ オンボーディングにおけるドキュメントツアーの話 会社のことやチームのことなど大枠の説明か
今日の学びSQLの民主化は万人に正しいかという話？（以下、私見） 期待する結果を取得できるSQLをかけないと意図しないデータを根拠にする可能性があるかも 「どういうデータが欲しいか」を言語化してエンジニアに投げるorAI利用でチェックだけ投げるが全体効率的か？ クラウドのアクセス制御の話（リンクは例） 適切な権限管理をしよう 権限を個人に紐づけたり、terraform管理すると入れ替え大変 Googleグループを使おう Googleグループの管理権限は少数に握ら
今日の学び爆速にするテクニックや環境の話 issueでタスクを分解する 最初から完璧なリストにしない 他者の視点を入れる pull requestの粒度 変更対象が多岐にわたらない リファクタと新規追加など テスト 通してはいけないものは通さないようなテスト内容になっているか CI/CD 高速化：すぐに結果がわかる 自動化：リリースをワークフローで行う 通知：些細なことでも通知を飛ばし、気づけるようにする 所感Twitterで流れてきて気になった本。
今日の学びマネージャーになるとこうなるだろうなあという想像の話 （マネージャーになれる気がしないというのは、一旦棚に上げて考える） 責任感で抱え込むのではなく、積極的にマネージャーの弱いところを開示していくのはどうだろう この情報を詰めるにあたってエンジニアからの視点が欲しいとか バグ報告を見た時の動き方の話 まずは反応する バグの詳細情報を確認する どの環境で発生しているか（本番なら優先度上げ） 見つけた情報はログ目的でスレッド投下 意思決定者が判断しやす
今日の学びチーム振り返りあるある 自責problem言いがち チームに主眼を置いた try増殖バグ 優先度付けた ルール形骸化 仮説検証して、不要なら廃した 必要ならまたtryに上がってくる 以前のチームでKPTやっていたので思い当たる節がありすぎました。 中でも①暗くなりがちは以前参画したチームで強く感じました。これどうにかならないかなと思い、進行役に「Keepの前に感謝を伝える時間を5分未満でいいので入れられないか」を提案したことがあり、実際に次の機会で
今日の学びhttps://www.digitalservice.metro.tokyo.lg.jp/documents/d/digitalservice/ai_prompt 生成AIのプロンプトの話 資料作成の時に役割付与しがちだったので目からうろこ 理由を書かせるも初見だった 「要件定義」について聞くとしたら、いつもは以下のようにしていた note参考にもう少し簡潔に知りたい場合の書き方を試す。 前者は要件定義の段階ごとの説明をしてくれているので、これはこれであ
今日の学びpoetry + pyenv + etc それHatchに大体入っているよ 諸々設定されているので新規プロジェクトする時点である程度開発環境が揃うのが良さそう 所感開発環境構築はpoetryで大分楽になりましたが、もう一歩進んで楽になりそうです。 コマンドとかなんやかんや設定回りの問題は発生しうるものなので、Hatch導入でその手順を減らせるようになると新規メンバーにとってうれしいですね。 終わりに週末二日とも雨予報でした。ちょっと出かけたかったです。
