タグ

ブックマーク / qiita.com (199)

  • 「テスト自動化実践ガイド」執筆に至るまで - Qiita

    はじめに テスト自動化についてのを書きました。2024年7月30日に発売します。 もともと2021年3月ぐらいから書き始めて、同年12月に書き終わる予定だったのですが、伸びに伸びてこんなことになってしまいました。 幸いなことに興味を持ってくださっている人が多いようなので、ここでは書籍で書ききれなかった、執筆に至るまでの背景(あるいは、いかに自分がE2E自動テストで苦労してきたか)について書いてみたいと思います。 試行錯誤の時期 自分が初めてE2Eテスト自動化に取り組んだのは2018年ごろからで、当時は TestCafe というツールを使っていました。そのころのことは別の記事に書いてあります。 ちょっと引用してみましょう。 イケてるところ コマンド一つでマルチブラウザテスト環境が構築できる これだけで完成です。SeleniumのようにWebDriverのインストールは必要ありません。あとは

    「テスト自動化実践ガイド」執筆に至るまで - Qiita
    Kesin
    Kesin 2024/07/17
    qiitaの神龍の人が一巡りしてから執筆した書籍についてqiitaに投稿するのは胸熱展開すぎる
  • (2023/06)Jest における CommonJS / ECMAScript Modules の扱いについて - Qiita

    1. 概要 JavaScript における CommonJS(以下、CJS)と ECMAScript Modules(以下、ESM)の問題は色々なところで発生する厄介な問題です。 Jest を使ったテストコードにおいてもこの問題に直面することがあります。 この文章は Jest における CommonJS / ECMAScript Modules の扱いについて包括的な情報提供を目指して書いています。 これを書くにあたって私は様々な情報収集をした他、不明瞭なところは実験サンプルを作って動きをみたり、関連するモジュールの中身を見てみたり、色々なことをしています。 正確な記載を心掛けますが、間違いを発見した場合は遠慮なく指摘をしてください。しかし、Node.js の世界は進歩が速いので受けた指摘をこの文章に反映するかどうかはわからないことを予め申し上げておきます。 基的にはこの文章は執筆時点の

    (2023/06)Jest における CommonJS / ECMAScript Modules の扱いについて - Qiita
    Kesin
    Kesin 2024/03/05
  • WebAssembly の過去・現在・未来 - Qiita

    はじめに WebAssembly (略して Wasm) では WASI や WIT、 Component Model など様々な仕様があります。 それぞれが登場した背景、モチベーションなどを理解することでなんとなく概要を掴んでいくことができるのではないかと考えたため、過去・現在・未来と時間軸で整理してみました。 まず Wasm とその特徴に関して簡単に紹介した後、Wasm の過去として生まれた背景やモチベーションを紹介します。 そして現在の Wasm がなぜ注目を集めているのか、そして現在策定中の仕様と目指している未来について紹介します。 WebAssembly とはなにか WebAssembly はスタックベースの仮想マシン用バイナリ命令フォーマットの仕様です。Wasm と略されます。 Wasm ファイル(Wasm モジュール)は一般に .wasm という拡張子で表されるバイナリファイル

    WebAssembly の過去・現在・未来 - Qiita
    Kesin
    Kesin 2023/12/21
    言語をまたいでライブラリを利用できるようになったらかなり面白くなりそう
  • OSS 活動を通して貢献できた Meilisearch を紹介したい - Qiita

    この記事はスタンバイ Advent Calendar 2023 の11日目の記事です。 こんにちは。求人検索サービスを提供する株式会社スタンバイでプロダクト開発部長をしている大須賀です。 普段の仕事は開発組織運営などのマネジメントが中心です。一般的にマネージャは、業務として直接的に開発に携わることが少なくなり、Individual Contributor (IC) としてスペシャリストを目指すエンジニアから敬遠されがちです。確かにその通りかもしれませんが、幸運なことに私の場合、仕事をではマネージャとして、OSS 活動ではエンジニアとして、今年一年、充実したキャリアを積むことができたと思っています。 そこで今回は、会社でマネージャをしながらも、OSS の活動でエンジニアとして貢献できた OSS 全文検索サーバー Meilisearch を紹介したいと思います。 私が Meilisearch

    OSS 活動を通して貢献できた Meilisearch を紹介したい - Qiita
    Kesin
    Kesin 2023/12/14
  • re:Invent 2023 で発表されたAmazon S3 Express One Zoneを使ってみる - Qiita

    はじめに この記事は一休.com Advent Calendar 2023 7日目の記事です。 AWS re:Invent 2023で発表されたAmazon S3 Express One Zoneの検証をしてみたいと思います。 Amazon S3 Express One Zoneとは? 2023/11/28にAWSから新しいストレージクラスであるAmazon S3 Express One Zoneが発表され、その日のうちに東京リージョンにもGAされました。 特徴 S3 Standard ストレージ クラスよりも最大 10 倍優れたパフォーマンスを提供するように設計されている 1秒あたり数十万のリクエストをサポートしている S3 Standard ストレージ クラスよりも 50% 低いリクエストコスト データを比較的短期間保持して、その間に非常に頻繁にアクセスする用途に向いているそうです。

    re:Invent 2023 で発表されたAmazon S3 Express One Zoneを使ってみる - Qiita
    Kesin
    Kesin 2023/12/08
    readが速い。特に小さなファイルが多いユースケースが得意そう
  • TypeScriptを他のツールで取り扱うためのコンパイラオプションについて - Qiita

    TypeScriptプロジェクトにおいては、ビルド速度が重要です。TypeScriptのビルド速度はCI/CDの効率に直結します。しかしながら、tscはそこまで速くないことも知られており、tsc以外のツールをTypeScriptのビルドパイプラインに混ぜることもよく行われています。 TypeScript(tsc)のコンパイラオプションの中には、そのようなユースケースをサポートするためのものも存在します。公式ドキュメントではInterop Constraintsとして分類されているもの(の一部)です。この記事ではそれらを紹介します。 isolatedModules isolatedModulesは古くからあるTypeScriptのコンパイラオプションのひとつで、tsc以外を用いてTypeScriptトランスパイルするユースケースをサポートしてくれるものです。 TypeScriptの主な仕事

    TypeScriptを他のツールで取り扱うためのコンパイラオプションについて - Qiita
  • Terraform職人のためのOpenTofu入門 - Qiita

    この記事は クラウドワークス Advent Calendar 2023 シリーズ1 の 4日目の記事です。 はじめに 「父さんな、Terraform職人やめてお豆腐職人でっていこうと思うんだ」と言いたいだけの @minamijoyo です。 2023年8月HashiCorpはこれまでMPL2のOSSライセンスで公開していた主要製品をBSL(Business Source License)に変更することを発表し、Terraformはv1.6.0からOSSではなくなりました。 このライセンス変更を受けて、OSS版のTerraformを求める人たちで、MPL2時点のコードベースからforkしたOpenTofuの開発が進められています。 HashiCorpのBSLは、実質的に競合他社の商用利用に制限をかけたもので、ほとんどの一般的なユーザに直接的な追加の制限はありませんが、間接的にTerrafo

    Terraform職人のためのOpenTofu入門 - Qiita
    Kesin
    Kesin 2023/12/04
    最近のterraformとコミュニティの関係ってそんなに渋かったのか。そういう事情もあるならやむなしという感もあるなあ
  • GitHub Actions で Xcode のインクリメンタルビルドを実現する (xcode-cache アクション) - Qiita

    GitHub Actions で iOS アプリをビルドするときの Xcode のインクリメンタルビルドを有効にするためのキャッシュ設定について解説します。 CI でのビルドで Xcode のインクリメンタルビルドが使えるようになれば、毎回 CI 上でフルビルドし40分程度かかっていたプロジェクトが、差分のみのビルドでビルド時間が5分に短縮されたりすることが期待できます。 環境 この記事では、以下の環境で調査・検証した結果を記載しています。 ローカル環境 macOS Ventura 13.5.1 Xcode 14.3.1 (14E300c) APFS (Encrypted / Case Insentive) GitHub Actions 環境 macos-latest macOS Monterey 12.6.8 Xcode 14.2.0 (14C18) 結論 結論としては xcode-ca

    GitHub Actions で Xcode のインクリメンタルビルドを実現する (xcode-cache アクション) - Qiita
    Kesin
    Kesin 2023/09/20
    最後の方に書いてあったけど “--driver-show-incremental” このオプションの存在を知っているだけでも正しく設定できているかどうかの検証に相当便利そう
  • ライブラリにTypeScriptコードを同梱するときはディレクトリを分けよう - Qiita

    ライブラリがこんな構成になっていませんか? TypeScript製のライブラリをnpmで配布するとき、そのパッケージの構成は次のようなフラットな構造になっていませんか?フラットな構造とは、TypeScriptファイル(.ts)と、型定義ファイル(.d.ts)が同じディレクトリにあるような構成です。 ├── index.ts ...... TypeScriptファイル ├── index.d.ts .... 上の型定義ファイル | package.jsonのtypesフィールドで指定してる。 ├── index.js ...... 上のJavaScriptファイル | package.jsonのmainフィールドで指定している。 | ├── module.ts ..... TypeScriptファイル | index.tsからimportされている。 ├── module.d.ts ...

    ライブラリにTypeScriptコードを同梱するときはディレクトリを分けよう - Qiita
  • VSCode の新機能「built-in port forwarding」を使いローカルサーバーにインターネット側からアクセス - Qiita

    VSCode の新機能「built-in port forwarding」を使いローカルサーバーにインターネット側からアクセスHTMLJavaScriptNode.jsVSCode はじめに この記事は、以下の公式ポストや、VSCode のアップデート後のリリースノートにも出ていた「built-in port forwarding」を試してみた話です。 この機能を使うと、ローカルにあるサーバにインターネットからアクセスできるようになります。 同様のことを実現するものには、有名どころの 1つに「ngrok(エングロック)」があったり、その他にもたくさんの類似サービスがあります。 実際に VSCode の built-in port forwarding を試してみる それでは、VSCode の built-in port forwarding を試してみます。 自分が試す際に参考にした情報は

    VSCode の新機能「built-in port forwarding」を使いローカルサーバーにインターネット側からアクセス - Qiita
    Kesin
    Kesin 2023/09/13
    “【追記】 公式記事の「How are forwarded ports secured?」という項目の記載” にこの機能を管理したい場合の方法について紹介されているので気にする会社では公式ドキュメントの記載と合わせて確認すると良さそう
  • コンパイルキャッシュでRustのビルド時間を短縮しよう - Qiita

    これはRustその3 Advent Calendar 2019の初日の記事です。 sccache — Mozillaが開発したRust製のコンパイルキャッシュ Rustはコンパイル言語です。個人的にはRustのコンパイル速度は遅くはない方だと思っていますが、依存しているクレートが多いとビルドにかかる時間が長くなります。特に非同期I/Oを行うWebクライアント/サーバーのクレートを使ったときや、Cargo自体をライブラリとして使うCargoサブコマンドをビルドするときなどは、依存クレートが200個くらいになることがあり、マシンの性能によってはビルドにかなりの時間を要します。 ビルド時間を短縮するためにコンパイルキャッシュという種類のソフトウェアがあります。これはコンパイルによって作られた成果物をディスクなどにキャッシュしておき、同じ条件のコンパイル要求があったときには、キャッシュしたものを返

    コンパイルキャッシュでRustのビルド時間を短縮しよう - Qiita
    Kesin
    Kesin 2023/07/30
    Rustはccache的なツールでコンパイルキャッシュを効かせることができるのか
  • OpenTelemetryとGrafanaでLogsとMetricsとTracesを接続する - Qiita

    OpenTelemetryとGrafanaを利用してPrimary Signalsを接続してみました この記事で紹介したものはDocker Composeで必要なソフトウェアが起動するようにしてGitHubにpushしてあります はじめに CNCF TAG Observabilityのwhitepapperでも紹介されている 以下のPrimary Signalsは可観測性を語る上では欠かせない要素になっています DatadogやSentry、Splunkなど各種プラットフォームでもLogsとTracesの接続など このPrimary Signals同士を互いに参照させることで優れた体験を得ることが出来ます 一概に対抗というわけではないですがGrafana Labsでもこの領域ではアクティブに活動していてソフトウェアは多岐に渡ります LGTM stackと呼ばれるようにログにはLoki、可視

    OpenTelemetryとGrafanaでLogsとMetricsとTracesを接続する - Qiita
    Kesin
    Kesin 2023/07/11
    OpenTelemetryでデータを送る先としてGrafanaもいけるのか
  • terraform importしてplan差分がない=環境が再現できているといつから錯覚していた? - Qiita

    はじめに 先日、Terraform v1.5.0がリリースされました v1.5の目玉はなんと言っても import ブロックと terraform plan -generate-config-out によるtfファイルの生成ですよね〜。これで既存のリソースもimportし放題だと巷で話題です。 ところで、Terraformの特徴として、「インフラをコード化することで環境が再現できる」などと一般的に謳われています。また、Terraformには「既存リソースをimportする機能」があります。別にそれぞれ単独では間違ってはないのですが、これらを組み合わせて、「既存リソースをimportしてplan差分が出なければ元の環境を再現できる」と言えるのでしょうか? 残念ながら現実にはそうとも言い切れません。なんとなく経験上わかってる人もいるとは思いますが、意外と気づいてない人も多そうな気がしたので、ち

    terraform importしてplan差分がない=環境が再現できているといつから錯覚していた? - Qiita
    Kesin
    Kesin 2023/06/19
    確かに。v1.5から気軽にimportできるのは間違いないけど、再現性まで考えるならイチからterraformで全部作成しないと安心はできない
  • Xcode Cloud は銀の弾丸になるのか - Qiita

    記事は弊社が技術書典 14 で無料配布する同人誌「ゆめみ大技林 '23」の寄稿です。追筆や訂正等がある場合はこの記事で告知します。 皆さんは iOS 開発においてどんな CI を利用しているでしょうか。Bitrise?Circle CI?いやもしかすると Jenkins のお世話をしている方もいらっしゃるのではないでしょうか。いずれにせよ、CI/CD は現代の開発において必要不可欠な環境と言っても過言ではないでしょう、なぜなら CI/CD こそ我々に提出されたコードをマージする自信をもたらせてくれているのです。 そんな中、アップルがついに公式の CI サービスを 1 年の Beta を経て昨年正式リリースしました。その名も Xcode Cloud です。名前のとおり、Cloud で動く Xcode とイメージして差し支えないでしょう。 筆者が考えるこの Xcode Cloud の最大の

    Xcode Cloud は銀の弾丸になるのか - Qiita
    Kesin
    Kesin 2023/05/21
    Xcode Cloudの良いところも悪いところも解説してくれている。そして試される信仰心
  • 開発生産性について議論する前に知っておきたいこと - Qiita

    はじめに 事業としてソフトウェア開発を行う企業にとって、自分たちの開発チームの生産性が十分に高いのか、あるいはそうでないのかについては大きな関心があります。 そのこと自体は、何かを計測し、改善するというのは営利企業としては健全です。一方で、ソフトウェアエンジニアリングの世界で「生産性の高さ」だと主張できる汎用性の高い指標は存在しません。こういった状況の中で、「生産性」を巡る議論は経営やビジネス部門とエンジニアチームとの間で繰り広げられ、場合によっては大きな不和や不信感につながることも珍しいことではありません。 今回は、エンジニアの開発生産性について、さまざまなステークホルダーと議論する上で把握しておきたいさまざまな論点について解説します。それによって、「我々が当に議論すべきテーマは何か」についての共通認識をつくるための土台を構築することを目的としています。 もしかしたら改善したいことは「

    開発生産性について議論する前に知っておきたいこと - Qiita
  • なぜJestのmockライブラリに混乱してしまうのか? - Qiita

    はじめに JavaScriptのモックライブラリでは、 sinon などが有名であるが、テスティングフレームワークに Jest を使ってるならば Jest組み込みのモックライブラリで済ませたほうが学習コスト少なくて済むだろうと思える。 しかし、 sinon の感覚でJestのモックライブラリを使おうとすると違和感というのか、モックへの考え方の違いに気づかされる。 ということで今回は、Jestのモックライブラリの考え方と使い方を整理していきたいと思う。 モックの用語整理とJestモックライブラリの位置づけ モックと一言でいっても、それが指す内容は微妙に異なる。 ここでは、モックを 広義のMock Object と 狭義のMock Object と分けて整理してくれているテスト駆動開発を参考に用語を整理する。 テスト駆動開発では、モック用語を、下図のとおり、テストダブルとそのサブクラスとして

    なぜJestのmockライブラリに混乱してしまうのか? - Qiita
    Kesin
    Kesin 2022/12/29
    jestのmockはちょっと複雑なことをやろうとすると公式ドキュメントの説明では全然足りないのでやりたいことベースで解説してくれているのは助かります
  • Vimで快適なgit生活を送る - Qiita

    はじめに gitを使いソフトウェアを管理することは多いです。 今回はVimに依存することで、git生活をより快適に送るTipsを紹介します。 1. git commit実行時のテンプレートにprefixを追加する commitメッセージを書く際にprefixを先頭に書くことは多いです。 よく使うprefixなら、commitメッセージを書くときに逐一確認できる環境を作りたいですよね。 gitコマンドを使うことで、git commitを実行した際に特定の文字列をテンプレートとして挿入できます。 コミットメッセージの書き方自体は、以下の記事を参考にしました。 https://qiita.com/konatsu_p/items/dfe199ebe3a7d2010b3e # feat: A new feature # fix: A bug fix # docs: Documentation onl

    Vimで快適なgit生活を送る - Qiita
    Kesin
    Kesin 2022/12/05
    gitのcommit.template知らなかった。git commit時にはvimを開くので設定しておこう
  • Four keys を計測する CLI ツールを作った - Qiita

    はじめに Four keys とはソフトウェア開発の生産性を測定するのに利用される以下の4つの指標のことである(参考)。 デプロイ頻度(Deployment Frequency) ソフトウェアのデプロイ頻度 変更リードタイム(Lead time for changes) ある変更をソフトウェアに適用してから、その変更がリリースされるまでの時間 障害修正時間(Time to restore) ソフトウェアに障害が発生してから、その障害が修正されるまでにかかった時間 障害率(Change failure rate)ソフトウェアのデプロイのうち障害が発生したデプロイの割合 これらの指標を簡易に測定するための CLI ツールを作成した。 この記事では、この CLI ツールについて紹介する。 使い方 インストール Releases の最新バージョンから自分の環境に合わせた実行ファイルをダウンロードす

    Four keys を計測する CLI ツールを作った - Qiita
    Kesin
    Kesin 2022/09/02
  • React、過剰に複雑な代物。 - Qiita

    はいさい!ちゅらデータぬオースティンやいびーん! 今回の記事は筆者に珍しく、技術紹介ではなく、僕の個人的な意見を書きます。あくまでも、自説です。 React自体は画期的で、プログラミング界に貢献したプロジェクトだと思っていますし、完全に否定したいわけではありません。 Reactに対する違和感=芽生えては大きく育った種 筆者はReactがとても好きでした。JavaScriptが好きになったきっかけもReactでした。何から何までもReactで書き直して、Custom Hooksを作って、refを子部品に渡したり、バリバリ満喫していました。 Vue仕事の関係で習得せざるを得なくなったのですが、Vueは最高に大嫌いでした。これならReactで書き直してやるぅ!と思ったりも。 Reactについて社内でも導入を推進したり、React入門の勉強会を開いたりもしています。 しかし、そんな筆者は、最近に

    React、過剰に複雑な代物。 - Qiita
    Kesin
    Kesin 2022/07/08
    むしろDOMとかHTMLを独自の要素で抽象化しているからこそReact Nativeみたいなことが可能になるのでは。他のライブラリとは目指してる世界が違うのでは
  • ここがつらい! Slack API - Qiita

    半分ネタ記事です。あんまり真面目に書きません。 項目数が多いので,気力でなんとか書きます。分類は諦めます。 他にもある!っていうのがあったらコメント欄で教えて下さい。気が向いたら追記します。 公式の TypeScript 型定義がもはや型定義を諦めている 辛い度: ★★★★★ 辛い中でもこれはかなり上位に来るやつ。 こちらに OpenAPI 形式で仕様が定義されていて, https://github.com/slackapi/node-slack-sdk/tree/main/packages/web-api/types ここに仕様に基づいて TypeScript の型定義ファイルが吐かれるようになっています。 Git 管理されていないので,実際のリリースを見てみましょう。 https://unpkg.com/@slack/web-api@6.7.2/dist/response/Reacti

    ここがつらい! Slack API - Qiita
    Kesin
    Kesin 2022/06/20
    黎明期にhubotで雑botを作っていた時代からするとどうしてこうなった感。古いAPIのままでも動いていることには感謝しているけどどこかでv2にして整理するべきだったのではないかと思わなくもない