並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 68件

新着順 人気順

testingの検索結果1 - 40 件 / 68件

  • アメリカでソフトウェアエンジニアの職を探した - pco2699’s blog

    はじめに 前提 アメリカで働くためのビザ 業務経験 2023年のアメリカのテック業界の状況 具体的な就活のステップ ソフトウェアエンジニアのインタビューで求められることの抽象的な理解 レジュメ Job Descriptionから逆算してレジュメを作る 一枚におさめる 数字を用いてスケールとビジネスインパクトを示す なるべく隙間を埋める フォーマット添削ツールにかける レビューを受ける ネットワーキング・リファラル 応募する アメリカの就活はNumber Game 採用のトレンドを追う 時期を見計らう Linkedinで最新の求人を見つける方法 Promotedをすべて非表示にする "Most Recent"順にする 検索クエリを工夫する 設定をブックマークする 時間を決めて巡回する コーディングインタビュー対策 アルゴリズムの地図を脳内に作る 大学やCouseraでアルゴリズムの授業を取る

      アメリカでソフトウェアエンジニアの職を探した - pco2699’s blog
    • 【翻訳】テスト駆動開発の定義 - t-wadaのブログ

      このブログエントリでは、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化(Semantic Diffusion)とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私(和田)はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正

        【翻訳】テスト駆動開発の定義 - t-wadaのブログ
      • テストの学習へようこそ!  |  web.dev

        テストの学習へようこそ! コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このコースでは、ウェブ用のテストの概要と探索について説明します。 このコースで学習する内容は次のとおりです。 テストの基礎 自動テストと手動テスト テストを実施する場所と方法 ベスト プラクティス 何をテストすべきか、誰に責任があるのか、目的そのものとしてではなく、目的を達成するために手段をテストすることを検討する方法など、テストの理念。 このコースには、学習に役立つ簡潔で実用的なサンプルコードも含まれています。 コースのスコープには、Node.js などの環境で実行される、フロントエンドの JavaScript とドキュメント モデル、バックエンドでのライブラリ テストが含まれます。テストの経験はありませんが、JavaScript の基礎知識と Node.js などに関する経験が必

          テストの学習へようこそ!  |  web.dev
        • しずかなインターネットの技術構成

          こんなWebサービスをリリースしたので、技術的な話をまとめておこうと思います。 元々このサービスは、趣味の延長線のような感じで開発を始めました。競合にあたるnoteやはてなブログなどのサービスが確固たる地位を築いているということもあり、「お金にはならないだろうけど、自分の趣味を詰め込んだものにしよう」というゆるい気持ちで開発を続けています(楽しい)。 選定の方針 趣味と言っても文章投稿サービスなので、ユーザーが少数であったとしても長期間運営しなければなりません。そのため、ユーザー数が少なければランニングコストが数千円/月以下、ユーザー数が増えたときは段階的にコストが上がるように選定を行いました。 アプリケーション フルスタックNext.jsアプリケーションをCloud Runにデプロイしています。各APIエンドポイントはNext.jsのAPI Routesで生やしています。 Next.js

            しずかなインターネットの技術構成
          • GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる

            GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。 そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyとRuby on Railsをアップデートし続けていることを今年(2023年)4月に明らかにしています。 参考:GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている そして同社はこのGitHub.comを支える1200台以上のMySQL 5.7を、GitHub.comのサービスレベルを維持したまま1年以上かけてMySQL 8.0にアップグレードしたことをブログで明らかにしました。 Up

              GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる
            • プログラマーの教養としての原則

              参考 プリンシプル オブ プログラミング - 3年目までに身につけたい一生役立つ101の原理原則 発行: 2016/3/23 著者: 上田 勲 まえがき プログラマーの世界で語り継がれる原則や格言を知ることは、その共通の言語や道徳を理解する手助けとなります。 『プリンシプル オブ プログラミング』(以下、プリプロ)は、統一された語句と形式により、先人のプログラマーたちが重要視していた思考法やアプローチを、微妙な概念の違いに気を使うことなく理解できるよう構築されています。この記事では、この本を読む上で役立つ101の原則マップと原則から抽出した価値観をまとめます。プリプロを読む際のガイドになればと思います。 一方で、プリプロに収録されていないウィットに富んだ原則や格言も多く存在します。この記事では、主に私の現場で重要視しているプリプロの101の原則以外の原則・格言も追加で紹介します。 プログラ

                プログラマーの教養としての原則
              • 組織をハイパフォーマーにするスキル、DevOps - techtekt

                こんにちは。弊社のエンゲージメントサーベイ製品HR Spannerのリードエンジニアを担当している岡部です。昨今注目されているDevOpsとそのケイパビリティについて、およそ一年前に社内の勉強会で発表を行ないました。今回の機会に、こちらでも寄稿させていただきたいと思います。 元になっている書籍は比較的大規模な開発を対象にしていると思いますが、当社のHR Spannerは10名程度の比較的小規模な開発であり、それを前提とした内容になっています。 DevOpsとは何か? 書籍「LeanとDevOpsの科学」では大規模アンケート調査により、高収益、高利益率、高市場占有率を持つ企業は、単に起業家精神やM&Aの取り組みだけでなく、開発組織におけるDevOpsのケイパビリティを強化している傾向が浮かび上がっています。この結果は単なる相関関係ではなく、統計手法によって因果関係として確認されています。また

                  組織をハイパフォーマーにするスキル、DevOps - techtekt
                • Preparing for the end of third-party cookies  |  Privacy Sandbox  |  Google for Developers

                  Preparing for the end of third-party cookies Stay organized with collections Save and categorize content based on your preferences. If your site uses third-party cookies, it's time to take action as we approach their deprecation. To facilitate testing, Chrome has restricted third-party cookies for 1% of users from January 4th, 2024. Chrome plans to ramp up third-party cookie restrictions to 100% o

                  • 広く使用されている「xz」にssh接続を突破するバックドアが仕込まれていた事が判明。重大度はクリティカルでLinuxのほかmacOSにも影響 | ソフトアンテナ

                    Red HatやDebianを含むLinuxディストリビューションで広く使用されている圧縮ツール「xz」の最新版に悪意のあるバックドアが含まれていた事がわかりました(Ars Technica)。 発見した開発者のAndres Freund氏は、xz version 5.6.0と5.6.1に悪意のあるコードが含まれていることが分かったと指摘しています。幸い、このバージョンは主要なLinuxディストリビューションの製品リリースでは使用されていませんが、Fedora 40やFedora Rawhide、Debian testing/unstable/experimentalなどのベータ版リリースには含まれていたそうです。 macOSのHomebrewでは、複数のアプリがxz 5.6.1に依存している事が判明し、現在xz 5.4.6へのロールバックが行われています。 悪意のある変更は難読化され、バ

                      広く使用されている「xz」にssh接続を突破するバックドアが仕込まれていた事が判明。重大度はクリティカルでLinuxのほかmacOSにも影響 | ソフトアンテナ
                    • t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog

                      こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの

                        t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog
                      • VSCode(VisualStudioCode)の定番機能を一挙解説 - Qiita

                        はじめに コードエディタ界の王様VisualStudioCode。開発の際に使っている方も多いのではないでしょうか。 本記事では、VSCode(VisualStudioCode)の定番機能を紹介していきます。 この記事を読んで、VSCodeマスターになりましょう! 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています!興味をお持ちいただける方は、こちらまで。 そもそもVSCodeって? VSCode(VisualStudioCode)はMicrosoft社が提供する無償のコードエディタです。2015年リリースですが、着々とユーザーを増やしており、2023年現在、世界で最もポピュラーなコードエディタの1つとなっています。 コードエディタって? 字や記号などのテキストで構

                          VSCode(VisualStudioCode)の定番機能を一挙解説 - Qiita
                        • ソフトウェアエンジニアにおすすめしたい本を100冊選んでみた | gennei's blog

                          Adobe Firefly で生成PdMむけの記事でこのような記事がある。 「プロダクトマネージャーこそ、戦略的に読書せよ!」── 最短で成果を出すための読書地図 (1/6)|ProductZine(プロダクトジン) これのエンジニア向けの記事がないかなと思っていたがなさそうだったので作ろうと思った。しかし客観的な視点でこれがおすすめというのは難しいので自分が参考になったと思った本を家の本棚を見ながらまずは100冊リストアップしてみた。 紹介する本は10年読まれていたり、近年発売のものであれば10年後にも読まれているだろうというものを選ぶようにしている。個別のプログラミング言語やフレームワークなどの本はバージョンアップに追随ができないことが多いので選んでいない。 入門本プリンシプル オブ プログラミングリーダブルコード定番中の定番。おそらくこの2冊はあちらこちらで紹介されている。とりあえず

                            ソフトウェアエンジニアにおすすめしたい本を100冊選んでみた | gennei's blog
                          • 5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる

                            はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、

                              5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる
                            • マイクロソフト、Webアプリのテスト自動化サービス「Microsoft Playwright Testing」プレビュー公開。クロスブラウザ/クロスプラットフォームのテストを並列実行

                              マイクロソフトは、Webアプリケーションのテスト自動化ライブラリ「Playwright」を用いた、Microsoft Azure上のテスト自動化サービス「Microsoft Playwright Testing」のプレビュー公開を発表しました。 Microsoft Playwright Testingに使われている「Playwright」は、マイクロソフトが中心となってオープンソースで開発しているWebアプリケーション向けテスト自動化ライブラリです。対応環境が幅広く柔軟で、精度の高いテストを特長としています。 具体的には、Chrome、Edge、Firefox、Safariの主要なWebブラウザのすべてを対象にしたテスト自動化が可能で、ヘッドレス、ヘッドありのいずれにも対応。モバイルエミュレーションを用いたAndroid版Google ChromeとMobile Safariのテストも、実

                                マイクロソフト、Webアプリのテスト自動化サービス「Microsoft Playwright Testing」プレビュー公開。クロスブラウザ/クロスプラットフォームのテストを並列実行
                              • 自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理

                                切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React

                                  自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
                                • 【2024年最新版】0からReactを勉強するならこのロードマップに従え! - Qiita

                                  はじめに こんにちは@Sicut_study (Watanabe Jin)です。 去年の10月頃にReactのロードマップを投稿しておかげさまで1000いいねもすぐそこになりました そこから私自身も状況がかなり変わり、大好きなReactを使ってプログラミングを教えるスクールを運営しております。 エンジニアになりたい完全未経験の方や、すでにエンジニアだけどもっと自由にプログラミングができるようになりたい人をたくさん教えてきました。 👇メンバーの記事はこちらにあります その中である程度この流れで学習をすすめていけば1-2ヶ月程度でReactで自由にサービスを作れるレベルに再現性をもってレベルアップすることができると確信がもてたので、 実際にやっているカリキュラム(React部分)をすべて紹介します ロードマップは完全未経験でもできるようなものになっていますのでわかる箇所は飛ばしてもOKです。

                                    【2024年最新版】0からReactを勉強するならこのロードマップに従え! - Qiita
                                  • ユニットテストってもう言わない! CI/CD時代のテスト分類に最適なテストサイズという考え方

                                    はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか? 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って

                                      ユニットテストってもう言わない! CI/CD時代のテスト分類に最適なテストサイズという考え方
                                    • マイクロソフト、Webアプリテストの自動化サービス「Microsoft Playwright Testing」プレビューを開始

                                      マイクロソフト、Webアプリテストの自動化サービス「Microsoft Playwright Testing」プレビューを開始 マイクロソフトは、Webアプリケーションのテスト自動化フレームワーク「Playwright」を用いた、Microsoft Azure上のテスト自動化サービス「Microsoft Playwright Testing」のプライベートプレビューを開始すると発表しました。 テスト自動化フレームワーク「Playwright」 Playwrightは、マイクロソフトが中心となって開発しているオープンソースのWebアプリケーション向けテスト自動化フレームワークです。 実行環境、対象ブラウザ、対応言語が幅広く、テスト実行時にはWebブラウザの動作を自動的に待つ機能を備えるなど、柔軟で精度の高いテスト自動化が実現できる点を特長としています。 具体的には、デスクトップ向けのWebア

                                        マイクロソフト、Webアプリテストの自動化サービス「Microsoft Playwright Testing」プレビューを開始
                                      • ジュニアエンジニアを脱却するための「コンテナ流儀」 - Uzabase for Engineers

                                        こんにちは。ソーシャル経済メディア「NewsPicks」で検索システムを開発しております崔(ちぇ)です。 この記事は、 NewsPicks Advent Calendar 2023 の23日目の記事になります。 qiita.com 昨日ははぐっさんによる「SwiftUIのKeyframeAnimatorでちょっとしたカードアニメーション 〜猫の手を添えて〜」でした! はじめに コンテナ流儀: 必要最低限のものだけで運用する Point1)レイヤーは少ないほどいい TIP:ベースイメージを作る Point2)不要なパッケージをインストールしない Point3)いつ再起動してもいいコンテナを作る Point4)独立したアプリケーションにする TIP:複数のプロセスを実行したい場合もある TIP:環境変数を積極的に使う Point5)フォアグラウンドで実行する 終わりに まとめ 感想 告知 はじ

                                          ジュニアエンジニアを脱却するための「コンテナ流儀」 - Uzabase for Engineers
                                        • 書評:GitHub Copilot とのペアプロ TDD でつくるローグライク RPG - 若くない何かの悩み

                                          本記事は「GitHub Copilot とのペアプロ TDD でつくるローグライク RPG」の書評です。題名にローグライクRPGとあるのでゲーム開発の本なのかなと思ってしまいますが、本題は仕様の端的な表現をもたないシステムを LLM を使って真っ当に開発する方法の解説だと思います。タイトルにローグライクRPGと書いていることでゲーム開発に興味のない人の興味を失わせてしまい損をしている気がします。 背景 最近の LLM の流行を受けて私も Chat-GPT や GitHub Copilot といった LLM を開発で利用しています。端的に仕様を表現できるシステムは LLM に質問して実装を得る方が自分で実装するより圧倒的に速く正確であるという感想を抱いています。ただ端的に仕様を表現できるシステムばかりではありません。えてして価値を生んでいるシステムというのは端的な仕様の表現が存在しないもので

                                            書評:GitHub Copilot とのペアプロ TDD でつくるローグライク RPG - 若くない何かの悩み
                                          • テストピラミッド万歳 | POSTD

                                            クイックサマリー:「テストピラミッド」は、自動テストをUI、サービス、ユニット単位に整理することで、開発に自動テストを組み込む方法を示すために作成されました。2012年に定義されて以降、このモデルは次第に使われなくなってきたように思いますが、本当に廃れてしまったのでしょうか。この記事では、最新のテスト戦略を紹介するとともに、今日のソフトウェア開発におけるテストピラミッドの関連性を検討します。 筆者の同僚であるジャン・フィリップ・ピエトルチェクが、かつてコードを書く開発者の責任について、次のように述べました。 none「我々の仕事の成果を最終的に使用する人々は、(中略)我々がただ最善を尽くすだけでなく、実際に機能するものを作ることを期待しているのです。」 — ジャン・フィリップ・ピエトルチェク 彼の言葉は、私たちが書くコードをそれに依存する人々の観点からとらえている点で非常に印象に残りました

                                              テストピラミッド万歳 | POSTD
                                            • 「コードに早まってDRY原則を適用しないこと」とGoogleが呼びかけ

                                              Googleに存在するコードを読みやすく保守しやすい形に保つ取り組みを行うグループ「Code Health」が、「DRYを早まって適用しないこと」と題した記事を公開しました。 Google Testing Blog: Don't DRY Your Code Prematurely https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html DRYは「Don't Repeat Yourself」の略称で、コードを重複させないことを重視する考え方です。重複するコードが存在していると、特定の機能を変更しようとした時に同じ機能を持つ部分を全て探して同時に変更する必要があり、見落としやミスが発生する危険性が高まります。一方、コードの重複を防げていれば一カ所だけを変更すればOKというわけ。 一見DRYを厳しく適用

                                                「コードに早まってDRY原則を適用しないこと」とGoogleが呼びかけ
                                              • BudouX: 読みやすい改行のための軽量な分かち書き器

                                                .app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads

                                                  BudouX: 読みやすい改行のための軽量な分かち書き器
                                                • Poku

                                                  🐷 What's Poku?A cross-platform test runner that brings the JavaScript essence back to testing. ⚡️ Quick Tutorials

                                                    Poku
                                                  • Why Is SQLite Coded In C

                                                    Note: Sections 2.0 and 3.0 of this article were added in response to comments on Hacker News and Reddit. Since its inception on 2000-05-29, SQLite has been implemented in generic C. C was and continues to be the best language for implementing a software library like SQLite. There are no plans to recode SQLite in any other programming language at this time. The reasons why C is the best language to

                                                    • 夢の常温常圧超電導体「LK-99」の存在を支持する研究結果が相次いで発表される、再現したLK-99が超電導物質だと示唆する動画も公開

                                                      2023年7月、韓国の研究チームが室温かつ常圧で超電導状態になる物質「LK-99」を開発したとする論文を発表し、世界中の研究者から大きな注目を集めています。新たに、LK-99の常温常圧超電導を支持する研究結果がアメリカのローレンス・バークレー国立研究所や中国の瀋陽国立研究所の研究者らによって発表されたほか、中国の華中科技大学によって「再現したLK-99の超電導性を示唆する動画」も公開されました。 [2307.16892] Origin of correlated isolated flat bands in copper-substituted lead phosphate apatite https://doi.org/10.48550/arXiv.2307.16892 [2307.16040] First-principles study on the electronic struc

                                                        夢の常温常圧超電導体「LK-99」の存在を支持する研究結果が相次いで発表される、再現したLK-99が超電導物質だと示唆する動画も公開
                                                      • 業務システム SPA のフロントエンド技術選定(2023年版) - KAKEHASHI Tech Blog

                                                        本エントリはカケハシ Part 2 Advent Calendar 2023の13日目の記事です。 (Part 1もおもしろい記事がいっぱいあるので、ぜひご覧ください。) はじめに こんにちは。カケハシでソフトウェアエンジニアをしている平松です。 今年、新規プロダクト立ち上げの機会があり、その際に行ったフロントエンドの技術選定について紹介したいと思います。 フロントエンドの領域は選択肢が豊富で、変化のスピードも速いため、プロダクトの要件に適した技術を選ぶことはひとつの挑戦です。 実際、フロントエンド技術選定のヒント 【令和五年度版】のアドベントカレンダー記事を読んで、その難しさを改めて感じました。 今回の新規プロダクトは、ユーザがログインして利用するtoBの業務システムです。 私はカケハシでは2度目の新規プロダクト立ち上げですが、前回の経験を活かしつつ、新しいアプローチにも挑戦しています。

                                                          業務システム SPA のフロントエンド技術選定(2023年版) - KAKEHASHI Tech Blog
                                                        • オープンソースのメーラー「Thunderbird」の開発チームが「バグを減らす開発手法」を解説

                                                          メールソフト「Thunderbird」では、ソフトウェアの品質向上のために開発チーム内で日常的に自動テストが実行されています。その理由や手法についてThunderbirdの開発チームが解説しています。 Automated Testing: How We Catch Thunderbird Bugs Before You Do https://blog.thunderbird.net/2024/04/automated-testing-how-we-catch-thunderbird-bugs-before-you-do/ ◆自動テストの目的とメリット Thunderbird開発プロジェクトではコードの変更によるバグの発生を最小限に抑えるために「自動テスト」が重視されています。開発チームによると、、Thunderbirdのコードや機能に変更が加えられるたびに、Windows、macOS、Li

                                                            オープンソースのメーラー「Thunderbird」の開発チームが「バグを減らす開発手法」を解説
                                                          • コードを書き始める前からテストをずっと考える ─ 継続的テストモデルとシフトレフトなテスト活動をアジャイルにどう取り入れるか - Agile Journey

                                                            読者の皆さんは、テストについてどのようなイメージをお持ちでしょうか。「開発の後に行う確認作業」といったイメージを持たれている方もいるかと思います。 しかし、開発しようとしているソフトウェアに不具合の混入を防ぐには、もっと早い段階でテストについて考えることが必要です。こういったテスト活動は、プログラムを1文字も書いていないときから始めることができるのです。 本記事では、2016年に提唱された継続的テストモデルを紹介しつつ、アジャイルとも親和性のあるシフトレフトなテスト活動について解説していきます。 DevOpsにおけるテストの考え方 DevOpsのループ図とは何か? 継続的テストモデルとは何か 継続的テストモデルにおいてテストは「活動」である シフトレフトなテスト活動とシフトライトなテスト活動 シフトレフトなテスト活動としてのテスト駆動開発 コード実装を始める前から行うテスト活動 シフトレフ

                                                              コードを書き始める前からテストをずっと考える ─ 継続的テストモデルとシフトレフトなテスト活動をアジャイルにどう取り入れるか - Agile Journey
                                                            • Ultimate Guide to Improving MySQL Query Performance

                                                              MySQL is certainly a powerful open source database management system, but even the most robust engine struggles when queries take an eternity to execute. For DBAs and developers, improving MySQL query performance is an ongoing goal. Efficient query performance is crucial for ensuring the smooth operation and optimal user experience of applications powered by MySQL databases. When businesses rely h

                                                                Ultimate Guide to Improving MySQL Query Performance
                                                              • System tests have failed

                                                                When we introduced a default setup for system tests in Rails 5.1 back in 2016, I had high hopes. In theory, system tests, which drive a headless browser through your actual interface, offer greater confidence that the entire machine is working as it ought. And because it runs in a black-box fashion, it should be more resilient to implementation changes. But I'm sad to report that I have not found

                                                                  System tests have failed
                                                                • 結合テストを書くときはコードベースを分離している

                                                                  新規開発の設計支援や古いコードベースを甦らせて欲しいという相談をもらったときに、最初にちょろっとコードだけお手本的なコードを書いてから引き渡しているのだが、そのときに必ず結合テストを書くようにしている。 3, 4年前から僕と付き合いがある人からすると、 「「「あの sadnessOjisan がテストを書くだと!!!」」」 という感じだと思うのだが、最近はテストに思うところもあってちゃんと書いている。 そしてそのテストコードだが、基本的にはアプリケーションから分離して書いている。その話をしたい。 OGP OGP は野方ホープで海苔が分離されて出てきた時の画像だ。 アプリケーションから分離したテストとはどういうことか 最終的にはテスト対象のサーバーを Docker コンテナで固めて、そのコンテナに対して HTTP リクエストを投げてその結果や DB の中身を検証するコンテナを docker

                                                                    結合テストを書くときはコードベースを分離している
                                                                  • private 関数にもテストを書きたいとき

                                                                    「private 関数にはテストを書かない」というのが多数派だと思う。だが昨日、仕事で In-source testing を書いていたらふと private 関数にテストを書きたくなった。そこで、In-source testingができる環境下でもprivate 関数にテストを書くべきかを X で聞いてみたら何か盛り上がっていた。 (In-source Testing: https://vitest.dev/guide/in-source.html) 反応を見る限り、やはり「private 関数にはテストを書かない」の方が主流だった。Kent Beck先生の http://shoulditestprivatemethods.com を紹介するツイートにもそういった反応が寄せられていた。(ぶんぶんさん、教えてくれてありがとうございます。) (このサイト面白すぎますよね・・・) 自分の立場を

                                                                      private 関数にもテストを書きたいとき
                                                                    • jQuery 4.0.0 BETA! | Official jQuery Blog

                                                                      jQuery 4.0.0 has been in the works for a long time, but it is now ready for a beta release! There’s a lot to cover, and the team is excited to see it released. We’ve got bug fixes, performance improvements, and some breaking changes. We removed support for IE<11 after all! Still, we expect disruption to be minimal. Many of the breaking changes are ones the team has wanted to make for years, but co

                                                                      • TDDは「開発者テストのTips集」t-wada氏が改めてひも解く“本質” - レバテックラボ(レバテックLAB)

                                                                        プログラマ、テスト駆動開発者 和田卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』(オライリージャパン、2010)監修。『SQLアンチパターン』(オライリージャパン、2013)監訳。『テスト駆動開発』(オーム社、2017)翻訳。『事業をエンジニアリングする技術者たち』(ラムダノート、2022)編者。テストライブラリ power-assert-js 作者。 日本におけるテスト駆動開発(以下、TDD)のエバンジェリストとして知られる和田卓人さん。TDDが世に出て20年あまりが経ち、開発者の間でその名が広がっています。その一方で、和田さんは「TDDの本来の意味を知らなかったり誤解したりしている人たちもかなり増えている」といいます。 今回は、TDDは本質

                                                                          TDDは「開発者テストのTips集」t-wada氏が改めてひも解く“本質” - レバテックラボ(レバテックLAB)
                                                                        • チーム開発を加速するテストの育て方

                                                                          テストを書いてないというチームには色々理由があると思いますが、「何をテストすべきかわからない」「書き方がわからない」「どのくらいメリットがあるかわからない」という意見は多いのではないでしょうか?テスティングフレームワークの選定や使い方を学ぶのは重要ですが、それ以上にテストの目的や戦略を学ぶことが重要です。チーム開発においてテストを活かすのは相応の知識とスキルが必要になりますが、活かせればテストは開発スピードを維持・促進する飛び道具になり得ます。 本稿は筆者が取り組んで実際に高いチーム満足度と速度を得られた、テスト戦略についてまとめたものです。

                                                                            チーム開発を加速するテストの育て方
                                                                          • 『GitHub CI/CD実践ガイド』でGitHub ActionsとCI/CDを体系的に学ぼう - 憂鬱な世界にネコパンチ!

                                                                            『GitHub CI/CD実践ガイド――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用』という書籍を最近出版したので紹介します。本書ではGitHub Actionsの実装と、CI/CDの設計・運用を体系的に学べます。一粒で二度美味しい書籍です。筆者個人としては「実践Terraform」以来、4年半ぶりの商業出版になります。 gihyo.jp どんな本? GitHub利用者にとって、もっとも導入が容易なCI/CD向けのソリューションはGitHub Actionsです。GitHub Actionsの活用事例は多く、検索すればたくさん情報が出てきます。ただ断片的な情報には事欠かない反面、体系的に学習する方法は意外とありません。CI/CD自体がソフトウェア開発の主役になることもまずないため、なんとなく運用している人が大半でしょう。そこで執筆したのが『GitHub CI/

                                                                              『GitHub CI/CD実践ガイド』でGitHub ActionsとCI/CDを体系的に学ぼう - 憂鬱な世界にネコパンチ!
                                                                            • フロントエンドを Vue.js から React にリプレイスしたお話 (前編) - NTT Communications Engineers' Blog

                                                                              はじめての方、はじめまして。久しぶりの方、お久しぶりです。 イノベーションセンターの何縫ねの。(@nenoMake)です。 普段の業務ではソフトウェアエンジニアとして Node-AI という WEB アプリケーションの開発をしています。 パブリックな活動としては、好きな言語である C# 関係の OSS 開発や技術ブログの投稿、登壇などをしています。 ですが、今回は C# ではなくフロントエンドのお話をします...! この記事では今まで Vue.js 2.x で開発されていた Node-AI の WEB フロントを完全に捨て去り、React にリプレイスしたお話をつらつらとしていきます。 まずは前編ということで、リプレイスプロジェクト発足時の課題感からはじめ、プロジェクトの進め方や選定技術などについてお話しします。 後編には内部の設計などのより技術的なお話をしたいと思います。では前編スタート

                                                                                フロントエンドを Vue.js から React にリプレイスしたお話 (前編) - NTT Communications Engineers' Blog
                                                                              • Downfall

                                                                                Downfall attacks target a critical weakness found in billions of modern processors used in personal and cloud computers. This vulnerability, identified as CVE-2022-40982, enables a user to access and steal data from other users who share the same computer. For instance, a malicious app obtained from an app store could use the Downfall attack to steal sensitive information like passwords, encryptio

                                                                                  Downfall
                                                                                • Secrets from the Algorithm: Google Search’s Internal Engineering Documentation Has Leaked

                                                                                  Google, if you’re reading this, it’s too late. Ok. Cracks knuckles. Let’s get right to it. Internal documentation for Google Search’s Content Warehouse API has leaked. Google’s internal microservices appear to mirror what Google Cloud Platform offers and the internal version of documentation for the deprecated Document AI Warehouse was accidentally published publicly to a code repository for the c

                                                                                    Secrets from the Algorithm: Google Search’s Internal Engineering Documentation Has Leaked