「AWSで始める負荷テスト入門」というタイトルで DevelopersIO 2024 Sapporo に登壇しました #devio2024 | DevelopersIO
中川です。 2024年7月5日に開催した「DevelopersIO 2024 SAPPORO」にて、オフライン登壇させていただきました。 登壇資料 話したこと 負荷テストの概要と目的 負荷テストの進め方 AWSを活用した負荷テスト 実践的なTips 当日の登壇スライドはこちらになります。 参考・紹介資料 参考にしたサイト 負荷テスト on AWS のすすめ 第三十五回 ちょっぴりDD - 人気番組の新作配信を安定起動させた、サーバーレスな AWS 分散負荷試験ソリューション「Distributed Load Testing」を使った負荷試験の仕組み 負荷テストとは？目的や種類ごとの観点、実施の流れについて解説 Types of load testing 参考にした書籍 Amazon Web Services負荷試験入門―クラウドの性能の引き出し方がわかる 分散負荷テストソリューション AW
2024年版「基本的なウェブアプリケーションを構築する」のチュートリアル手順まとめてみた[Amplify Gen2対応] | DevelopersIO
初めてAWSのサーバレスサービスを学習するときに利用できる「基本的なェブアプリケーションを構築する」の内容を2024年現在でも実行できる手順にしてみました こんにちは、臼田です。 みなさん、AWSのチュートリアル活用してますか？(挨拶 今回はAWSの初心者向けハンズオンコンテンツである基本的なウェブアプリケーションを構築するを2024年の現在版の手順としてまとめてみました。 このコンテンツはAWSのサーバレスなサービスを利用して、簡単にウェブアプリケーションを作成する体験ができるチュートリアルとなっており、登場するAWSの各サービスを理解するのにちょうどよい内容でした。しかし、リリースされてしばらく経っているのもあり、特に今回のAmplify Gen2リリースもあってだいぶ画面や操作方法などが変わってしまいました。 実現できる事自体は変わらないので、現時点でこのチュートリアルを初心者でも完
![2024年版「基本的なウェブアプリケーションを構築する」のチュートリアル手順まとめてみた[Amplify Gen2対応] | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/89d69da1ff63f03a6134b1ba08325495afbaf56e/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2024%2F06%2F000_basic_web_app.png)
GitHub Copilotと快適なユニットテストコード作成生活
こちらで登壇させていただいた資料です。 https://trident-qa.connpass.com/event/314818/ ※ こちらは2024/05/23 時点の私の考えとなります。更新の予定はございませんのでご了承ください
脳に収まるコードの書き方
Mark Seemann 著、吉羽 龍太郎、原田 騎郎 訳、Robert C. Martin まえがき TOPICS 発行年月日 2024年06月 PRINT LENGTH 312 ISBN 978-4-8144-0079-9 原書 Code That Fits in Your Head FORMAT Print PDF EPUB ソフトウェアは複雑さを増すばかりですが、人間の脳は限られた複雑さしか扱えません。ソフトウェアが思い通りに動くようするには、脳に収まり、人間が理解できるコードを書く必要があります。 本書は、拡張を続けても行き詰ることなくコードを書き、複雑さを回避するための実践的な方法を解説します。最初のコードを書き始めるところから機能を追加していくところまでを解説し、効率的で持続可能なペースを保ちながら、横断的な問題への対処やトラブルシューティング、最適化を行なう方法を説明します
愛されて23万View！新卒向け研修資料「テスト文字列に”うんこ”と入れるな（2024年版）」を公開しました｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
ホーム 技術ブログ 愛されて23万View！新卒向け研修資料「テスト文字列に”うんこ”と入れるな（2024年版）」を公開しました 愛されて23万View！新卒向け研修資料「テスト文字列に”うんこ”と入れるな（2024年版）」を公開しました こんにちは松井です。今は会長になりました。 遡ること3年前、2021年の新卒研修向けに「テスト文字列に”うんこ”と入れるな」という資料を作成しました。 おかげさまで多くの方に読んでいただいたようで、SlideShareのView数は「23.6万View（2024年4月現在）」にまで達しました。 わたし的にはもうこれで満足していたのですが、 「会長、今年も例のうんこの話をしていただけませんか」 というオファーがあり、またこのクソみたいな話をすることになったという次第です。 せっかく話をするならばということで、事例やTIPSのページを新たに加え、「2024年
サブスクリプション課金システム開発ケーススタディ - inSmartBank
世はまさに大サブスクリプション時代。この潮流の中で弊社スマートバンクもまた、去る2023年7月12日にB/43プラスというサブスクリプションサービスをリリースしました。 サブスクリプションといえばユーザーに提供されるコンテンツや機能といった直接的な価値に焦点が当たりがちですが、その土台にはサブスクリプションビジネスを成立させるための課金システムがあります。本記事では筆者が行った課金関連の開発を振り返ってみて重要だったポイントや工夫点を伝えてみたいと思います。 すでに世に多くのサブスクリプションサービスがある中で、課金システムの実装はコモディティ化した単純な作業に思えるかもしれません。しかしながら自社サービスにてゼロから実現するとなると、想像よりも多くの思考と意思決定が必要とされる、エンジニアリング観点ではとても奥深い題材といえます。いち開発プロジェクトのケーススタディ、あるいはいちプログラ
ブラックボックスになりがちな開発チームの内部状況を指標を用いて可視化する｜mtx2s
自社ソフトウェアプロダクトを内製する組織であっても、開発チームがそれをどうやって作り上げているか、開発者ら以外にとってはブラックボックスであり、不可視です。それだけに、開発チームのパフォーマンスや内部状況の良し悪しは、各々の主観や興味によって、不統一な認識を持ってしまうことも多いでしょう。そしてそのような認識のばらつきは、開発する当人たちにとっても実は同じです。 しかし、例えブラックボックスであっても、自動車のダッシュボードのように様々な指標によってその内部が数値化され、可視化されていれば、チームのパフォーマンスに統一的な認識を持たせやすくなります。 本記事では、どのような指標を可視化すべきか、その代表的なものについて取り上げます。 リードタイム（開発、製造）リードタイムは、開発項目ごとの作業期間を計測したもので、短いほど優れていることを示す指標です。計測対象となるプロセス全体を「開発」と
仕様書とテストを用いた「AI駆動開発」
数年前にAIを離れ現在はフロントエンドをやっているのですが、半年くらい前に思い切り引き戻されました。画像生成AIにおけるmidjourneyとstable diffusionの登場です。noteのCTO深津さんが記事を出したと思ったのも束の間、急速に進化を果たしました。 絵柄の固定・ポーズの指定・マシンスペックなど、日々さまざまな問題を解決しながら新たな技を身につけています。 しかし、同等かそれ以上に話題になっているのは大規模言語モデル(Large Language Model)かもしれません。ChatGPTが話題になった思ったら、BingやPerplexity,You.comなど大規模言語モデルを交えたサービスが次々と登場しました。 活用方法もたくさん見つけられており、私は特に以下の二つの記事が好きです。 「感情回路」の記事に入力(プロンプト)でここまで変わるのかと感動したことを覚えてい
ChatGPTを最強の学習ツールにする方法 - Qiita
こちらの記事は随時追加更新していきます 記事の内容 何かと話題のChatGPTですが、今回はこのChatGPTをプログラミング学習として活用し、 「最強の学習ツール」にしてしまおうという記事になります。 内容を書き換えれば、英語学習などにも置き換えることができます。 筆者の関連記事 ChatGPTはそのチャット内で質問した内容を記憶しそれによって回答が異なるケースがあります。 もし、意図した回答が得られない場合などは「New chat」から新たに質問するなどの工夫が必要です。 そして、ChatGPTからの回答内容はあくまでも一つの例であるという認識で向き合いましょう。 アジェンダ 登録方法 質問のコツについて ロードマップ(カリキュラム)を提案してもらう ふんわりとした内容を具体的にしていく 更に深掘りして手順を教えてもらう 「何がわからないかわからない」状態をなくしていく 次のレベルアッ
雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
【考察】テストコードのきれいな書き方 - Qiita
作ったものが想定した動作をしているか。 それを確認するために、テスト（試験）を行います。 検証したいことがちゃんと実現できて確認が取れているのであれば、その品質自体は割と気にされないことが多い印象です。 保守・運用・追加開発 をしていくプロジェクトが多くあると思います。 その作業の中で、改善を取り入れていくこともあると思いますが、その中でも一番後回しにされるのが、テストコードの改善のように思います。 推測ですが、「コストによるメリット・リターンが少なすぎる」ことが理由かな…と（開発者目線ではリターンが大きいのですが、運用者目線ですとリターンが少なく見えてしまう）。 であれば、最初からある程度綺麗なものがどういうものかを考え、作成しておけば良いのではないか・・！ ということで、考察していきたいと思います。 前提 考察をするにあたり、言語化した時の表現や意味のズレが発生しやすい部分もあると思い
IDEにChatGPTを統合、「この関数のテストコードはどこ？」「XXXを実装するならどう書けばいい？」など、AIでコードと対話できる「qqbot」登場
IDEにChatGPTを統合、「この関数のテストコードはどこ？」「XXXを実装するならどう書けばいい？」など、AIでコードと対話できる「qqbot」登場 テキストから高度なイラストを生成するAIや、人間と自然な対話を可能にするAIが最近話題になっています。 この人間と自然な会話をするAIチャットの代表的なサービスであるChatGPTの派生サービス（Variant of ChatGPT）をVisual Studio CodeなどのIDEに統合し、開発中のコードについて「この関数のテストコードはどこ？」などと対話できる「qqbot」が登場しました。 開発したのはDan Robinson氏。 Introducing qqbot, a variant of ChatGPT that lives in your IDE. The cool thing about qqbot is that it k
ソフトウェア開発者は徹夜してはいけない - ソフトウェア工学研究の日々
睡眠は大切とよく言われますが、睡眠不足が開発者に与える影響をまじめに調べた面白い論文が、ソフトウェア工学のトップ論文誌 IEEE Transactions on Software Engineering に掲載されていました。ソフトウェア工学研究室助教の Raula 先生から教えてもらいました。 Need for Sleep: The Impact of a Night of Sleep Deprivation on Novice Developers’ Performance - IEEE Journals & Magazine この論文での被験者はイタリアの大学生 45人。Test-First 開発でプログラムを書かせるタスクを行ってもらっています。23人には実験前日に睡眠を控えてもらい、平均で直近20時間程度は寝てない状態になっています。対照群は、前日に平均で6.5時間、通常通り寝た
「テストコードにはテストの意図を込めよう」の発表報告＆補足説明＆質問回答 #vstat - ブロッコリーのブログ
先日、「リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～」というイベントで登壇してきました。 veriserve-event.connpass.com 今回は発表内容に対する補足と、発表に対していただいた質問に回答します。気になるところだけでも読んでもらえればと思います。 目次 目次 発表内容 発表に対する補足 【補足1】都道府県のテストについて 【補足2】Parameterized Testsへの利用について いただいた質問の回答 【質問1】リーダブルなテストコードの勉強方法はありますか？ 【質問2】テストコードのメンテナンスをするにあたってのリファクタリングの頻度はどれくらいか？ 【質問3】レビューをする際、機能自体のレビューにかけた時間に対してテストのレビューにかける時間はどのくらいの割合で行っていますか? 【質問4】
テストコード導入奮闘記～私はこうやってプロジェクトにテストコードを導入しました～ - Qiita
導入 どうやら新卒2年目社員のAさんが上司のZさんにプロジェクトにおいてテストコード導入を打診してるようです。少し内容を見てみましょうか。 Aさん(新卒2年目社員)「最近テスト自動化やテストコード、TDDなどの単語をよく聞きます。うちはテストコード書いてないですし、実装後の簡単な動作確認、最終の結合テストしかしていません。開発体験と品質を上げるために、テストコードを導入したいです。」 Zさん(上司)「そうは言うがね、君。今のうちの状況を見てごらんよ。みんな複数のプロジェクトに関わっていて、常に多忙。残業時間もぎりぎりで何とかプロジェクトが回っている状態だよ。そんなみんなにさらに作業を増やすようなことを提案するというのかね？しかも、テストコードはお客様からしたら作っても作らなくても関係ない、いわば直接利益に関係ないような作業じゃないか。もちろん、世の中で認知されているということは知ってるよ？
Docker創始者らが開発、ビルド／テスト／デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に
Docker創始者らが開発、ビルド／テスト／デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に Dockerの創始者であるSolomon Hykes氏らが中心となって開発しているオープンソースのCI/CD環境構築ツール「Dagger」が公開されました。 Windows、Mac、Linuxで試すことができます。 And we are live! Introducing Dagger, a new way to build CI/CD pipelines. By the creators of Docker. https://t.co/DU8racmoUo — dagger (@dagger_io) March 30, 2022 Daggerが定義したCI/CDパイプラインはポータブルになる Daggerとは「A P
(自分の) JavaScript のユニットテストの書き方
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
手軽に負荷テストができるツール「Taurus」がスゴい
modules: jmeter: version: 5.4.1 # ここに書いてあるバージョンを勝手にダウンロードしてくれる properties: log_level.JMeter: WARN log_level.JMeter.threads: WARN system-properties: org.apache.commons.logging.simplelog.log.org.apache.http: WARN 既存ツールのラッパーとして動作 デフォルトでは内部的にJmeterが実行されますが、以下のようなツールで作成されたスクリプトを流用することが可能です。 JMeter Gatling Locust Selenium Vegeta つまり、さきほどはYAMLでシナリオが記述可能とは言いましたが、もちろん既存のスクリプトを流用できるってことです。 いままで作り上げてきたスクリプトや
テストコードを書き始める前に考えるべきテストの話（2021年版） #scrumosaka / scrum_fest_osaka_2021
以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P12 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2011.J02 http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf#page=15 ※2011年版は現在リンク切れのため、最新版のシラバスのURLを掲載しています P17 概説テスト分析 http://www.slideshare.net/takashiyamasaki378/ss-55384920 P29 システム/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイル開発における品質管理
