https://toruby.connpass.com/event/286678/ の発表資料です。
STORESでフルタイムRubyコミッタをやっている遠藤(@mametter)です。 最近Rubyインタプリタのとある問題の修正に成功した(と思う)ので紹介します。といっても格好良い話ではなく、とても泥臭い話です。 問題 RubyのCIで不定期に次のようなエラーが発生していました。いわゆるflaky test。 1) Failure: TestSymbol#test_inspect_under_gc_compact_stress [.../ruby/test/ruby/test_symbol.rb:126]: ":testing" expected but was ":\"\\x00\\x00\\x00\\x00\\x00\\x00\\x00\"". 発生確率が絶妙で、しばしば起きるのですが、デバッグのために狙って再現しようとしても起きないという代物でした。 問題の分析 エラーが起きていた
AIを用いてソフトウェアテストの最適化を実現するソリューションを提供する「Launchable」は、JenkinsをベースとしたCI/CDプラットフォームを提供する「CloudBees」に買収されたことを発表しました。 Jenkinsの作者である川口氏が立ち上げたLaunchable Launchableは、オープンソースのCI/CDプラットフォームであるJenkinsの作者 川口耕介氏が共同創業者として立ち上げた企業です。 参考:ソフトウェアテストの実行を機械学習で効率化する。Jenkins作者の川口氏が立ち上げた「Launchable」で実現しようとしていることとは(前編) Launchableが提供するソリューションは、膨大な項目になるソフトウェアテストをAIを用いて優先順位付けし、全てのテストを実行するのではなく必要十分なテストのみに絞り込んで実行することで、テストサイクルを短縮し
渡米 メールでやってきた唐突な仕事のオファーに応えて、渡米を決意した。どうしてそう決めたのかと言われれば、口うるさい母親が昔からアメリカに行けアメリカに行けと煩かった事だとか、給料がよかったからとか、ソフトウェア技術者にとっていかにシリコンバレーが特別であるかとか、それらしい理由もないではない。でも、実際には入念な検討は何もなかった。面白そうだからやってみようと思っただけだ。それで良かったと思っている。若さというのは、無知で無謀なものだ。でも、そのおかげで人生が思わず開けたりするのが、面白いところだ。 その決断の結果、僕の人生は一変した。これを機に、付き合っていた女性と結婚する事に決めた。2001.1.1という日付も縁起が良さそうではないか。誰もいない区役所に婚姻届を出し、近所のコンビニで肉まんを買って食べて結婚を祝い、数日後の飛行機に乗って、冬とは思えぬまばゆい陽光につつまれたサンフラン
サーバーサイドからインフラ領域を中心としたWebエンジニアとして、リードエンジニアからプロダクトマネージャー、CTOと、順調にマネジメントの階段を上がってきた松木雅幸(Songmu)さん。その後、再びプレイヤーとして転職し、現在またマネジメントに取り組んでいます。この螺旋(らせん)のキャリアと呼ぶ働き方の変遷と、それを支えるOSSへの取り組み方について寄稿いただきました。 ▲ベストスピーカーを獲得したYAPC::Tokyo 2019での登壇(写真提供:Japan Perl Association) 私は、小粒ながら多くのOSSを開発してきました。他にも技術的な情報発信や、ISUCONでの優勝経験、エンジニア向けSaaSのプロダクトマネージャーやCTOといった経歴があるため、技術力でキャリアを築いてきた人間だと思われがちです。しかし実は、エンジニアの中では相対的に高めなヒューマンスキルを武器
Launchable, Inc.のソフトウェアエンジニアであるこんぼい氏は、ドキュメントを大事にしている理由と、具体的にどのようなドキュメントを運用しているのか、また、ドキュメント文化醸造のための取り組みについて紹介しました。全2回。 こんぼい氏の自己紹介 こんぼい氏:よろしくお願いします。「非同期な開発体制を支えるドキュメント文化」ということで発表します。 まず自己紹介をします。矢吹遼介と申します。Launchableという会社でソフトウェアエンジニアをやっています。インターネット上ではゴリラのアイコンで「Konboi」というIDでやっています。よろしくお願いします。 Launchableについて はじめにLaunchableについて軽く紹介させてください。USに本社があって、Jenkinsの作者の川口さん(川口耕介氏)がSun(Sun Microsystems)の時の同僚のHarpre
知人のエンジニアリング・リーダーと話していたら、「エンジニアに顧客視点でもっとモノを考えてほしい、そこに芯を持ってほしい」と思い悩んでいた。その人がその短い言葉に込めた思いを全部理解したとも思わないが、僕もそういう気持ちは良く分かる。 現在の事業上の課題とは全然関係ない方向に情熱を燃やす人。そこはそんなに拘るところなの、と思うところに拘りを持つ人。まあ一定数見てきた。もっと全員で同じ方向を向いて同じ問題意識を持って…何とかならないのかなぁ。 わかります。 まさにそういうのを実現するのがエンジニアリング・リーダーの仕事ですよね。 僕も人様に講釈できるほど上手く出来ているとも思わないが、今までの反省からこういう道具が使えるんだな、という考えは幾つかある。 技術者の美意識・情熱というのは、宗教のようなものだから、布教が出来る。会社に望ましい方向に技術者の情熱を誘導してあげるということだ。例えば、
ソフトウェアテストの自動化やローコード・ノーコードツールへのAI技術導入が急速に進んでいる。とはいえ、生成AIはいまだ研究段階にあり、日本でも海外でも有効な活用方法を模索している途上にある。本セッションでは、ソフトウェアテスト領域のトップランナーである3人、Launchable,Inc共同社長の川口耕介氏、プログラマでテスト駆動開発者の和田卓人氏、オーティファイ株式会社代表取締役 CEOの近澤良氏が、生成AI時代のソフトウェアテストの現状と課題、これからの展望について語った。 海外と日本のソフトウェアテストの現状 アメリカに住み、20年間アメリカのソフトウェア開発現場を見続けてきた川口氏は、「故郷に錦を飾りたい」という思いから、日本でもJenkinsやDevOps、ソフトウェアテストのような取り組みを進めていきたいと考えている。しかし、取り組みの中でいろいろな難しさを感じ、日本と海外のソフ
本日2024年3月5日(火)の昼間に開催された、『AI時代のソフトウェアテストの現在と未来』というイベントがとてもよかったので、特に印象深かったポイントについて共有したいと思います。 イベントの詳細はこちらで。 autifyjapan.connpass.com 登壇者はタワーズ・クエストの和田卓人 @t_wada さん、Launchableの川口耕介 @kohsukekawa さん、Autifyの近澤良 @chikathreesix さんのお三方。ファシリテーターは、近澤さんと同じくAutifyの、末村拓也 @tsueeemura さんです。 宣伝タイム Launchableは、「テストの失敗をよりインテリジェントに扱う」ことを目指している。 たとえば、テストのFlakinessの判定や対処にできるだけ人を介在させないとか、過去の実行結果を見て再実行要否の判断をするといったもの。 Auti
小西秀和です。 今回はAWS Application Migration Service(AWS MGN)について実際に使ってみた経験からアーキテクチャとライフサイクルの関係、使い方の注意点をまとめてみたいと思います。 今回の記事の内容は次のような構成になっています。 AWS Application Migration Service(AWS MGN)とは AWS Application Migration Service(AWS MGN)とAWS Server Migration Service(AWS SMS)との違い AWS MGNの基本的なアーキテクチャとライフサイクルの関係、使い方の注意点 AWS MGNにおけるライフサイクルの状態と次の状態に進むためのアーキテクチャにおけるステップの関係 [Not ready(準備ができていません)] [Ready for testing(テス
Efficiency Redefined: CloudBees Acquires Launchable to Enable Development Teams to Iterate Faster Today we’re thrilled to announce that Launchable is joining the CloudBees family. Launchable’s innovative AI-augmented approach to QA aligns perfectly with CloudBees’ mission to deliver better, more secure and compliant software faster than ever. By acquiring Launchable, we can quickly integrate the c
Launchable, Inc.のソフトウェアエンジニアであるこんぼい氏は、ドキュメントを大事にしている理由と、具体的にどのようなドキュメントを運用しているのか、また、ドキュメント文化醸造のための取り組みについて紹介しました。全2回。前回はこちらから。 運用ドキュメント1 Project Proposal こんぼい氏:ここからがメインパートというか、どんなドキュメントを運用しているのかを紹介していければなと思います。 いろいろなドキュメントがあるんですが、今回は4つ例を持ってきました。1つ目がProject Proposal、2つ目がDACI(Driver, Approver, Contributors, Informed)、Postmortem、CS Investigation Logというかたちで持ってきました。 まず1つ目がProject Proposalですね。読んで字のごとくじゃ
はじめに こんにちは、タイミーでバックエンドエンジニアをしている新谷、須貝、難波です。 2月10日に広島国際会議場で YAPC::Hiroshima 2024 が開催されました。タイミーはGold Sponsorとしてブース出展をしており、エンジニアが3名とDevEnable室が3名の総勢6名で参加させていただきました。 どのセッションも興味深かったのですが、この記事では我々が拝見したセッションのうち特に印象に残ったものをいくつかピックアップしてご紹介します。 なお、タイミーには世界中で開催されている全ての技術カンファレンスに無制限で参加できる「Kaigi Pass」という制度があり、エンジニアはこれを使って参加しております。詳しくは下記のリンクをご覧ください。 productpr.timee.co.jp 経営・意思・エンジニアリング speakerdeck.com 普段我々が行なっている
はじめにスイス・ジュネーブに本社があるSonarSourceに転職が決まりました。 自分がこの会社を受けた際、スイスでエンジニアをしている人の情報をほとんど見つけることができなかったこともあり、自分が持っている情報を積極的にオープンにして行きたいと思い筆を取りました。 また、私は自身もさまざまな方に助けられて転職が決まったので、自分と同様の思いを持つ方の手助けになりたいと思っています。 詳しくは以下のpodcastでも話しています。 転職先について2006年創業で、SonarCloudやオープンソースのSonarQubeといったClean Codeを実現するための解析ツールを開発している会社です。 スイス以外にもアメリカやフランスにオフィスがあります。2022年に$412M(600億円相当)の資金調達をしています。 SonarCloud Demoなぜスイスか結論から言うとスイスに行くことに
先日、機会をいただきましてCI/CD Test Night #7でAPIテスティングツール*1を開発している中で考えていることをお話しさせていただきました。 testnight.connpass.com 詳細はスライドをご覧ください。 speakerdeck.com APIテストはスモールテストと比べて効果は大きいがコストも大きい 私はAPIテストの一番の課題はこれだと思っています。 APIテストは、「APIに対してリクエストを投げてそのままテストする」というわかりやすさがあります。 また、テストあたりにおけるカバレッジの広さというメリットもあります。 なので、できればデメリットであるコストの大きさをなんとかしたいわけです。 この課題の解決には2つの方法があります。 コストを小さくする 範囲を広げて効果を大きくする 先に、範囲を広げる方法について考えると 作ったテストをそのまま負荷テストに
■ RubyKaigi 2024 Day 1 Day 0 にして、RubyKaigi は予定が詰まっていて大変だな...となっているところに Day 1 が開催。 2024 は会期が水曜-金曜なので Matz オープニングキーノートからクロージングに移動して、今年はぺんさんがキーノートだった。Quine など weired なコードの紹介をしながら Trick の披露に合わせて RubyKaigi の見どころを紹介するという内容で大変良かったと思う。 ■ 那覇の市場で昼食 キーノートのあとは昼食の時間。Day 1 は Launchable の onomax さんと何かを食べつつ、CI 実行時の失敗をどう見つけているのか、というユーザーインタビューを受けるために、ウミヘビを食べることができるという店へ。 mame, nobu と 4 人でめちゃくちゃ暑い那覇を歩いて市場にたどり着いたら、水曜
はじめにブログを書くまでがYAPCなので! 2024年2月9,10日行われた YAPC::Hiroshima 2024 に参加してきました。ありがたいことに激戦の中、自分の応募したトークが採択されたので登壇してきました。 自身のトーク / 非同期開発体制を支えるドキュメント文化トークのモチベーションとしては 何としてでも広島に行きたい Launchableに入社するまでは SlackとかMTGでの議論を中心とした同期的なプロダクト開発を進めてきました。 一方入社後はドキュメントを中心とする非同期をベースとした開発にガラッと変わり、なぜそれがワークしてるのか自分自身ための整理。 また、他社さんの事例も出るようなきっかけになれれば という思惑がありました。 スライドが多くなってしまったせいで後半駆け足になってしまったのは反省点ですね… トークの後のQAセッションや、トークが終わった後の廊下や懇
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く