Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 自分はこれまでメンバーレベルのポジションとしてしか働いたことがありません。 ただ、自分と比較して必ずしも技術的に優れているわけではない同僚がインパクトの大きい仕事をしたり、上司やマネージャーの信頼を得たりしていくのを見た経験から、 自分がよりインパクトの大きい仕事をしていくためにはどのような部分が足りていないのかを考えるために、色々と調べたり、考えたり、まとめたりしてみました。 シニアなエンジニアについて ここでは、グレードの高いエンジニアや抽象度の高い仕事を日常的に行っているエンジニアをシニアなエンジニアと呼ぶことにします。 シニアな
本記事のテーマはGitHub Actionsです。個人的に「もっと早く知りたかった！」と考えているグッドプラクティスを、厳選してお届けします。想定読者は次のとおりです。 普段GitHub Actionsを雰囲気で運用している人 GitHub Actionsをコピペや生成AIで乗り切っている人 他者が書いたコードの意味をより深く理解したい人 本記事でGitHub Actionsの基本は説明しません。グッドプラクティスを含めて基礎から学びたい人は、拙著『GitHub CI/CD実践ガイド』を読んでみてください。GitHub Actionsの基本構文から運用のコツまで、網羅的に解説しています。さて書籍紹介はこれぐらいにして、さっそく本題へ進みます。 GitHub Actionsの設計指針 GitHub ActionsはCI/CDや各種自動化で役立つ、汎用的なワークフローエンジンです。一般的に長期
プロジェクト新規参入者のリードタイム短縮の観点から見る、品質の高いコードとアーキテクチャを保つメリット
組織に自動テストを書く文化を根付かせる戦略（2024秋版） / Building Automated Test Culture 2024 Autumn Edition
2024年10月18日 日本SPIコンソーシアム（JASPIC） ソフトウェアプロセス改善カンファレンス2024
何かの取り組みを始める時、たいていまずは"過去の経緯"をざっと調べると思う。そうしないと過去に起きた問題を踏んでしまったり再発明をしてしまったりするからである。 皆当たり前にやっているように見えて、この過去の経緯の調べ方には意外とスキルのバラつきがある。自分も常にうまくできているわけではないので、思考整理のために雑に書き出してみる。 たとえば一例として、「Androidの自動テストの方針」を決めようとしているとしよう。背景にある課題は適当に想定してほしい。次のようなステップで過去の経緯を調査していく。 1. 調査期間を決める 調査はダラダラとやってしまいがちなので自分で期限を決める 内容にもよるが、自分は半日~1日に設定することが多い。社外の方とのスケジュール調整が入る場合には1週間くらいかかることもある 例で言うと、自分ならいったん1日で設定してガッと集中して調べてキャッチアップすると思
こんにちは。pixivのnamazuです。 先日開催されたPIXIV DEV MEETUP 2024にて、『pixivというシステムはどんな形をしているのか、それはなぜか。』というテーマで発表をさせていただきました。当日、セッションにご参加いただいた皆さま、そしてフィードバックをいただいた方々に、改めて感謝申し上げます。 Webサービス開発において面白い点の一つは、どのサービスもその要件や状況に応じて異なる選択がなされることです。結果として、類似点がある場合もありますが、細部において同じものはなく、すべてがユニークです。弊社内でもさまざまな違いが見られますが、業界全体を見渡すとさらに多様性が広がっていることでしょう。 今回の発表では、pixivのシステムに関する重要な要件や状況をいくつか取り上げ、現時点でどのような構造になっているかを、インフラストラクチャ、バックエンドアプリケーション、開
テスト自動化の協業を加速する！ テックタッチのフロントエンドにおけるテストの分類 - Techtouch Developers Blog
フロントエンドエンジニアの 92thunder です。去年北海道旭川市に移住しまして、長らく打ち合わせを続けてきた家が10月にデプロイされたのでQoLが爆上がりしています。 テックタッチではデプロイ頻度を上げるためにテスト自動化に取り組んでいます。テスト自動化をQAエンジニアと進めていくためにテストの分類を策定する取り組みを始めました。この記事では、テックタッチにおけるフロントエンドのテストの分類とそれを策定するにあたって意識したポイントについて説明します。 デプロイ頻度改善のため、テスト自動化に取り組む なぜテストの分類が必要か テストの分類 コンポーネントテスト インテグレーションテスト テストの分類で意識したこと テストサイズを意識してコスパの良い自動テストへ 一般的な分類より、社内でのテストの呼び分けやすさを重視 おわりに デプロイ頻度改善のため、テスト自動化に取り組む テックタッ
はじめに Next.jsにServer Actionが新しく導入されました。サーバ上の関数をブラウザから直接呼び出すようなコードの書き味を提供するもので、非常に魅力のあるコンセプトだと私は思っています。ただしサーバ上で実行されるコードとブラウザで実行されるコードの境界が曖昧で、"use server"のセキュリティ上の懸念もよく議論されています。 一方で、私の先日の記事Next.jsで簡単なCRUDアプリを作りながら気になったセキュリティ: Railsの視点からで、私はこの"use server"問題には言及しませんでした。まだ非常に新しい話題でかつNext.js側の対応も進行中だというのもありますが、実は個人的にあまり気にならないのが最大の理由です。 気にならなくなったきっかけは、Server ActionをRuby on Railsのコントローラと同じように考え始めたことです。こうする
【QA業務効率化】GAS + Notion APIを用いたテスト進捗報告の自動生成 - enechain Tech Blog
はじめに enechainでのテスト管理 テストケースとテスト進捗の管理 バグチケットの管理 日々のテスト進捗報告の自動生成 テスト進捗情報の取得 バグチケット情報の取得 報告の整形とSlackへのポスト 進捗報告生成のトリガー 今後の展望 まとめ はじめに こんにちは！enechainでQAチームのマネージャーを務める杉田 (@sug1san) です。 QAチームでは先日、初の試みとして「QAオフサイト」と題したイベントを社外の会場を借りて実施し、日頃眼の前の業務に忙殺されて後回しになりがちな品質改善、QA業務改善に、メンバー各人が自身でテーマを決め、丸一日かけて取り組みました。 今回は、私がそこで取り組んだGAS (Google Apps Script) とNotion APIを用いたテスト進捗報告の自動生成の取り組みについてご紹介します。 enechainでのテスト管理 本題に入る前
開発生産性の現在地を開発生産性の歴史と開発生産性Conference2024から振り返る - Tabelog Tech Blog
目次 目次 はじめに 開発生産性の歴史 工業製品のコスト管理 (1950~1970年代) 工業製品とサービス業の収益増加 (1980~2000年代) ITサービスの開発生産性 (2010年代~) 2024年現在の開発生産性 開発生産性の経営視点での構造化 B-1 プロセス改善 B-2 ソフトウェア化 B-3 技術的負債 B-4 開発者体験 2024年時点での開発生産性の現在地 まとめ 【採用】開発生産性の歴史を一緒に作りませんか？ 参考文献 はじめに 食べログ開発本部、品質管理室で室長をしている荻野です。近年ITサービス業界では、ビジネスを取り巻く変化に迅速に対応するため、アジャイル開発やDevOpsなどの開発プラクティスが普及し、開発生産性に関する議論が活発化しています1。 このブログ記事では、開発生産性の歴史をアジャイル開発の源流である日本の製造業まで遡って振り返った上で、開発生産性C
最近、技術経営に入門している。技術者として感覚的に当たり前と思って実践していたことでも、経営の視点で構造化・言語化するまでには距離があり、苦戦しつつ頑張っている。 その修行として思考を雑にアウトプットするようにしてみる。なにか答えを見出すわけでもないし、まとまりもないし、すぐに言ってること変わるかもだけどご勘弁を。 なお、前提として竹内さんの「CTOの頭の中」シリーズの考え方をベースにしている。 初回のテーマは基盤開発。 プロダクト規模が大きかったりマルチプロダクトだったりして、複数のフィーチャーチームがあり、それらを下支えする基盤チームがあるような組織を考える。チームトポロジーの言葉でいえば、ストリームアラインドチームがあり、それを支えるプラットフォームチーム/コンプリケイテッド・サブシステムチームがある感じ。 そのような環境で、基盤チームが担う「基盤システム」に対する期待値はブレがち。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 弊社ソニックガーデンの社内勉強会で、「個々人が実践している生産性向上の取り組みをお互いに共有し合おう」という勉強会が開かれました。 ちゃんとした準備時間が取れず、勉強会の10分前ぐらいに「そりゃー」と思いついたものをバババッと書き出したのですが、いくつかみなさんの参考になるものもあるかもしれないので、こちらでもシェアしてみます。 簡単に取り入れられそうなライフハック的なテクニックからそうでないものまで、とりあえず僕が思いついた内容を雑多に書き出したので、よかったら参考にしてみてください！ ググるキーワードが思いつかないときは生
ピラミッド、アイスクリームコーン、SMURF: 自動テストの最適バランスを求めて / Pyramid Ice-Cream-Cone and SMURF
2024年10月29日（火）13:00 ～ 14:30 バルテス共催セミナー「開発失敗につながる偏ったテストしてませんか？プロが教える本当に考えるべきテストバランスのとり方」
【Go】kong で CLI のトップレベルに --version フラグを実装する - KAYAC Engineers' Blog
お久しぶりです。SRE の市川恭佑です。 今回は Go で CLI ツールを作成する際の小ネタを紹介します。 そもそも CLI パーサの選定 Go でコマンドを解析する手法は多岐に渡ります。そもそも標準 flag パッケージだけで実装することも可能ですし、spf13/cobra や urfave/cli をフラグパーサに採用することも多いかと思います。 好きなものを使っていただくのが一番ですが、今回の話題で取り上げる alecthomas/kong は、サブコマンドのサポートのみならず簡単な制約チェックも提供されているのが魅力的です。個人的には、不正なフラグが与えられたときに適切なエラーメッセージを返すことの面倒臭さを考えると、ここら辺もパーサ側にお願いしたいなって気持ちになることが多いです。 ちなみに kong は、alecthomas/kingpin と同じ作者によるツールで、みなさん
https://kaigionrails.org/2024 オンラインとオフラインのハイブリッド 日程：2024.10.25 (Fri.) - 26 (Sat.) 会場：有明セントラルタワーホール https://kaigionrails.org/2024/events/ OGP用 直前イベント 10/10(木) 19:30〜21:45 【オフライン開催】Proposals on Rails 2024 - connpass 10/15(火) 19:00〜20:30 Kaigi on Rails 2024 タイムテーブル解説会 - connpass 10/17(木) 19:30〜21:30 Reject on Rails 2024 - connpass 10/18(金) 18:00〜21:00 【大阪オフライン開催】Kaigi on Rails 2024 非公式予習会 - connpass
Wardite というWASM Runtimeを作っていました。 github.com 今の所、「RustでWasm Runtimeを実装する」の内容を一通り実装した段階です。 zenn.dev fibまで動くようになったので、ゴリラさんのコースの範囲は一旦完成 あとはwasm坂を登り続けるだけだ... pic.twitter.com/65m8qbSvap— Uchio Kondo💥 (@udzura) 2024年10月28日 以下のようなwasmプログラムを動かせます。 (module (func $fib (export "fib") (param $n i32) (result i32) (if (i32.lt_s (local.get $n) (i32.const 2)) (then (return (i32.const 1))) ) (return (i32.add (call
はじめに • • みなさん、自動テスト実装していますか？ ここ数年でモバイル界隈においても自動テストを実装する機会は増えてきているか と思います さらに • Xcode16から待望の「Swift Testing」が利用できるようになりました これで、自動テストをもっと実装できるようになりますね
対象読者 RSpecをそれなりに書いたことがあるがフロントエンドテストは未経験なエンジニア カラリアの開発に興味があるエンジニア 香りで世界を彩ることに興味があるエンジニア もし、私たちの開発チームに興味を持った方がいましたら、 ぜひカジュアル面談からお話しましょう！！ はじめに こんにちは、ハイリンクでプロダクト開発エンジニアをやっていますタイガです。 この記事では、フロントエンドのテストに初めて挑戦した感想をお伝えしたいと思います。 正直なところ、新しいテストフレームワークを学ぶことには少し抵抗というか腰が重いという気持ちがありました。 新しい構文を覚えたり、テストの書き方を一から学んだりするのは大変そうだな、という印象があったためです。 ちなみに私自身はRails歴は5年くらいで、Rspec歴も同じくらい。 フロントエンドテスト及びJestは初めて触るので、まさに「RSpecをそれな
テスト容易性の確保にかかわる責務設計、リファクタリングのためのデザインパターンに、Humble Objectパターン（Humbleオブジェクトパターン、質素なオブジェクトパターン）があります。 Humble Objectパターンは、ユニットテストのデザインパターン集であるxUnit Test Patternsで定義されたものです。近年は書籍「単体テストの考え方/使い方」でテスト容易性を確保する基礎的技術として紹介され、認知が広がっています。 Humble Objectパターンは自動テスト、特にユニットテストをターゲットとします。大まかな概要として、以下を実施します。 自動テストで実行しにくいオブジェクトを、「自動テストで実行できるオブジェクト」と、「自動テストで実行しにくいコード」に分離する テストすべきロジックの責務をなるべく「自動テストで実行できるオブジェクト」に集中させる。 このHu
SmartHR 品質保証部 労務ユニットAの紹介 こんにちは！QAエンジニアのkaomiです。 入社して1年3ヶ月が経ち、労務領域のプロダクトを中心にさまざまな業務に携わっています。 オーストラリアの固有種であるウォンバットが大好きで、10/20(日)に大阪府池田市で行われる「ウォンバットの日」が気になっています。 はじめに 本記事は品質保証部の連載記事第2弾です。今回のブログでは、労務ユニットAの紹介と現在取り組んでいる活動について紹介します。 労務ユニットAについて 第1弾のブログで触れたように、労務ユニットAは2024年7月の組織変更で新たに編成されたユニットです。チーフ（プレイングマネージャー）1名とメンバー3名の計4名のQAエンジニアで構成されています。 労務ユニットAでは労務領域の基本機能プロダクトと年末調整機能のプロダクトを担当しています。メンバーは開発チームに専属しておらず
2024/10/18 iOS Test Night #13の登壇資料
こんにちは！ROUTE06 でソフトウェアエンジニアをしている @sasamukuです。 Kaigi on Rails 2024 に参加してきましたのでレポートをお届けします！ 前回に引き続き、ROUTE06 は Silver Sponsors として協賛させていただきました。 弊社からは4人のメンバーが現地参加しました！ ROUTE06は4名でおじゃましてます🙌 #kaigionrails @hoppiestar @sasamuku @MH4GF @ynndino88 pic.twitter.com/n7BRei0djt— ヤノ | ROUTE06 (@ynndino88) 2024年10月25日 参加レポート セッションレポート Keynote: Rails Way, or the highway Capybara+生成AIでどこまで本当に自然言語のテストを書けるか？ モノリスでも使
"Data Migration on Rails"という発表をKaigi on Rails 2024でしました - valid,invalid
表題の通りRailsにおけるdata migrationの手法や現在地についてKaigi on Rails 2024で発表してまいりました。 4年連続でスピーカーとして参加*1することができ大変光栄でした。また、後述するようにオフラインならではの稀有な体験ができ、楽しかったです。 今回の発表について 発表に用いたスライドは以下です。 今回はこれまでの発表とは違ったアプローチに挑戦してみました。これまでの発表が1つの課題やプロトコルについて深掘るスタイル（まぁ、発表って普通はこっち）だったのに対し、今回は収集する情報の幅を広くとりつつ特定テーマの現在地を半網羅的に示すというsurvery report風味な内容という感じ。 意図したアプローチではありつつも、スライドを作りながら「ちょっと浅すぎないか」「広く薄いこの内容は誰にとって面白いのか」とけっこう直前まで悩んでいた。特に一番伝えたい芯を
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
シニアなエンジニアの振る舞いとリーダーシップについて - Qiita
なんとなくから脱却する GitHub Actionsグッドプラクティス11選 | gihyo.jp
約9000個の自動テストの 時間を50分->10分に短縮 Flakyテストを1%以下に抑えた話
過去の経緯の調べ方 - Konifar's ZATSU
pixivというシステムはどんな形をしているのか、それはなぜか。 - pixiv inside
Next.js App Routerの"use server"雑感 : Rails視点から
基盤システムとは何か、中長期システム投資の観点から考える｜Yuku Kotani
「あなたの実践している生産性向上の取り組みは何？」に @jnchito が答えてみた - Qiita
Kaigi on Rails 2024 - ruby-jp
Pure Ruby なWASM Runtimeを型付きで実装してみた - ローファイ日記
自動テストの信頼性を高めるミューテーションテストの活用に向けて | ドクセル
RSpecに慣れたエンジニアがJestを始めてみた話 - High Link テックブログ
テスト容易性のためのデザインパターン：Humble Objectパターンとは - 千里霧中
SmartHR 品質保証部 労務ユニットAの紹介 - SmartHR Tech Blog
自動テストの信頼性を高めるミューテーションテストの活用に向けて
Kaigi on Rails 2024 協賛・参加レポート - ROUTE06 Tech Blog