長くなりがちだったコードレビューを改善した話 - 弁護士ドットコム株式会社 Creators’ blog
弁護士ドットコム クラウドサイン事業本部でエンジニアをしている山田です。 主にフロントエンドを担当しています。 普段の業務でフロントエンド開発のコードレビューをすることが多く、今回は長い時間がかかりがちだったコードレビューを以下の施策で改善した話をします。 タスクへの認識合わせを拡充 タスクを小さく分割 類似するタスクのレビュー内容は共有 必要に応じて同期的にレビュー 達成されないスプリントゴール スプリントゴールが達成できない原因 コードレビューが長くなる要因 レビュアーのレビュー期間が長い タスク担当による対応期間が長い 対応策 タスクについての認識合わせの時間を設ける タスクをなるべく小さくする 類似する複数のタスクはレビュー内容を共有 必要に応じてオンラインミーティングなどで画面共有し会話しながら同期的にレビューする スプリントゴールも達成できるように まとめ 達成されないスプリン
インフラエンジニアはSREではないし、SREとPlatform Engineeringも別物 - inductor's blog
インフラエンジニアの肩書きをSREに変えるタイプの組織変更は近いところから遠いところまでいろんなところで見かけてるんだけど、改めてそれって名前変えただけじゃないよね？って問いかけは個人が組織に、組織が個人にそれぞれ相互でした方がいいと思う。 インフラエンジニアって言葉もまあ定義が死ぬほど広くてどこからどこまで指すのってのは組織によって違うね大変だねって話ではあるんだけど、SRE(Site Reliability Engineering)やPE(Platform Engineering)はインフラと必ずしも対応関係にあるわけではないんだよな。 Platformってのは言ってしまえば会社のエンジニア組織の中で自分達に最適化された基盤を作る人たちの集合体とそのプロダクトそのものを指していて、Platform Engineering組織の中には当然フロントエンドエンジニアやデザイナー、プロダクトオ
Pandasのメモリ削減方法を整理した - Taste of Tech Topics
皆さんこんにちは 機械学習チーム YAMALEXチームの@tereka114です。最近、寒いので、鍋を中心に食べて生きています。 検証段階でも、規模の大きなデータを扱う機会が増えてきて、Pandasのメモリ消費量が厳しいと感じてきたので、その削減や効率化のテクニックまとめたいと思いました。 有名なものからマイナーなものまで、思いつく限り書いてみます。 そもそもなぜ、Pandasのメモリ削減技術が必要なのか 準備 Pandasのメモリ削減 1. 型修正 2. 逐次読み込み 3. 読み込み時の型指定 4. 逐次読み込み＆集約 5. 不要なものを読み込まない 6. 不要なカラム／DataFrameを消す 番外編：そもそもPandasを利用しない 最後に そもそもなぜ、Pandasのメモリ削減技術が必要なのか Pandasで扱うデータの多くのファイルはCSV,Parquet, JSON（JSONL
OSS活動を通して掴んだ海外キャリア。英語力よりも技術力を大切にチャンスを掴む - Findy Engineer Lab
コンテナ脆弱性ツール「Trivy」の開発者である福田さんと、Denoのコントリビューターをしていた日野澤さん。お二人は、OSS活動を通して海外キャリアをスタートさせました。 海外企業で働くのであれば、英語スキルは必須のはず。しかし、福田さんは「未だに英語はわからない」と話し、日野澤さんは「英語は話せるものの、複数人の会話は聞き取れない」と言います。その上で「英語スキルに関係なく挑戦することが大事」だと教えてくれました。 本稿では、4月26日（火）に行われた「オープンソース活動が切り開いた海外キャリア論 vol.4」のなかで語られた、海外企業での働き方やOSS活動との向き合い方についてまとめています。 パネリスト 福田 鉄平さん / @knqyf263 Aqua Security Software Ltd. Open Source Engineer コンテナ脆弱性ツールであるOSS「Triv
ソフトウェアエンジニアでテストマンな私が家を買う際にやったこと - 若くない何かの悩み
はじめに ソフトウェアエンジニアでテストマンを生業とする Kuniwak です。今回は家を買うためにやったことを紹介します。 というのも、家を買うためにやったことを知人に話してみたら面白がられたため、誰かの役に立つかもしれないと思ったからです。 なおこの記事はソフトウェアに関する技術の記事ではありません（随所に検証の基本的な考え方などが散りばめられていますが…）。また、この記事で紹介する意見・手法は多分に cocopon 氏の影響を受けています。cocopon 氏の家購入エントリもこの記事と同時に公開されているはずです。 また、この記事はとても長いので先にポイントを説明しておきます。この記事ではライフプランシミュレーションに始まり次のような3Dモデルを作って日照や照明の検証をしていきます。また、3Dモデルを作るだけでは漏れが出るのでさまざまな検証を組み合わせています： 検証のために作った3
エンジニアはもっと図を書こう - 生涯未熟
たまには軽い話題をば。 自分の中で信頼できるエンジニアかどうか？を見極めるひとつの指標で「込み入った議論の時に図を書くかどうか」というのがあります。 今までの経験上、図を書く派のエンジニアは割と良い感じの人が多かったので採用している指標なのですが、何故これが機能しているかというのを改めて考えてみた。 他者の認知負荷を理解している コンテクストを合わせることにコストをかけられる意識がある 自分の思考の整理するツールとして図を扱えている ザッと挙げましたが、この３つが機能している要因なのかなという気がしています. 他者の認知負荷を理解している あれやこれやエンジニア間で技術議論している中で、「Aさんはこの領域に詳しいけどBさんはこの領域にはほどほど詳しいくらいだな」という個々のレベル差に応じて認知の負荷がかかります。ただでさえ議論していると結構なスピードで話が展開されていくので、認知負荷が更に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
