Webサービス公開前のチェックリスト
個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 なお、この記事では各項目の解説はあまり入れていません。2024年7月10日のClassmethod Odysseyで少し詳しく話そうと思っているので、よかったら聞きにきてください。オンラインなので無料です。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポ
C言語をマスターしたい人はGCCのバージョン14を使いましょう - pyopyopyo - Linuxとかプログラミングの覚え書き -
C言語（C++を含む）を習得したい人，ポインタを勉強したい人はgcc-14を使いましょう．難しいところは gcc-14 が丁寧に解説してくれます C言語の難しいところ 例を示します．C言語で記述された，たった６行のソースコードです int main() { int buf[10]; buf[10] = 0; return 0; } このソースコードには問題があります．初見でわかるでしょうか？ : : : 問題があるのは buf[10]=0 の部分です．C言語でやりがちなミスですが，これがバグやセキュリティホールの原因になります． C言語が難しい理由は二つあります．この手の問題を見逃しやすい点と，この手の問題を理解することが難しい点の二つです gcc 14 に解説してもらいましょう 上記の６行のソースコードをgcc14を使ってコンパイルしてみます ソースコードのファイル名は test.c と
本記事は「珠玉のアドベントカレンダー記事をリバイバル公開します」企画のために、以前Qiitaに投稿した記事を一部ブラッシュアップしたものになります。 はじめにみなさん、docker composeを利用しているでしょうか？ 複数のdockerコンテナをまとめて立ち上げたり、環境変数を定義できたり便利ですよね。 この記事ではある程度docker composeを利用している方向けに私が便利、便利そうと感じたdocker composeの機能を挙げてみました。 docker compose cli v2を利用docker-composeではなく docker composeコマンドも利用可能になっています。 Docker Desktopでは v3.4.0から利用可能で、基本的にはコマンドの互換性あります。 ファイル監視による自動更新docker compose 2.20.0からCompose
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)
Intro Ladybird は、他のブラウザエンジンをフォークせず、企業との取引に頼らず、寄付だけで作ることを宣言した新しいブラウザエンジンだ。 Ladybird https://ladybird.org/ これがいかに価値のある取り組みなのか、 Web を漫然と眺めてきた筆者による N=1 の妄言を書いてみる。 ブラウザエンジンとは ブラウザは、「ブラウザ UI」と「ブラウザエンジン」と、大きく二つの構成要素に分けて考えることができる。 ブラウザエンジンとは、いわゆる Web 標準の技術を片っ端から実装した、ブラウザの土台となるものだ。 ビルドすれば、入力した URL からネットワーク経由でリソースを取得し、パースしてレンダリングして表示できる。そのための IETF RFC や WHATWG HTML や ECMAScript が実装されている、標準技術の結集だ。 その上に、例えばタブ
2024年7月25日紙版発売 柴田芳樹 著 A5判／208ページ 定価2,860円（本体2,600円＋税10%） ISBN 978-4-297-14293-3 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Amazon Kindle honto この本の概要 本書は，著者が1993年から約30年間経験してきたAPI仕様の作成，2003年から20年間経験してきたテストファースト開発／テスト駆動開発の知見をまとめたものであり，一般的なソフトウェア開発者が習得することが容易ではない事柄を，本書を通して学び，実践してもらうことを目的としています。 本書が提唱する「API仕様ファースト開発」はWebサービスにおける大域的なテスト駆動開発の実現に必要なものであり，また，API仕様ファースト開発を実現するにはテスト駆動開発が必要です。API仕様ファースト開発とテスト駆動
ログ基盤のFluentdをFluent Bitに移行して監視ツールを実装した話 - Mirrativ Tech Blog
はじめまして、Azuma（@azuma_alvin）です。現在大学院の1年生で、2024年2月から4ヶ月間ミラティブのインフラチームにインターンとして参加しました。普段はインフラやMLOpsといった領域に興味があり、最近はVim環境の整備がマイブームです。 本記事では、ログ基盤をFluentdからFluent Bitへ部分移行した経緯とその2種類の監視ツールの実装についてお話しします。 記事の最後に、インターンから見たインフラチームの特徴と私が4ヶ月間で学んだことを紹介しています。興味がある方は末尾までスクロールしてぜひご覧ください。 1. 背景と目的 2. ミラティブのログ基盤について 3. ログ欠損の原因調査 Fluentdのバッファリングの仕組み fsnotifyを用いたバッファリングの観察 負荷試験 日付時刻フォーマットとワイルドカードによるログ欠損 ログ保存とサーバータイムスタン
コードを書き始める前からテストをずっと考える ─ 継続的テストモデルとシフトレフトなテスト活動をアジャイルにどう取り入れるか - Agile Journey
読者の皆さんは、テストについてどのようなイメージをお持ちでしょうか。「開発の後に行う確認作業」といったイメージを持たれている方もいるかと思います。 しかし、開発しようとしているソフトウェアに不具合の混入を防ぐには、もっと早い段階でテストについて考えることが必要です。こういったテスト活動は、プログラムを1文字も書いていないときから始めることができるのです。 本記事では、2016年に提唱された継続的テストモデルを紹介しつつ、アジャイルとも親和性のあるシフトレフトなテスト活動について解説していきます。 DevOpsにおけるテストの考え方 DevOpsのループ図とは何か？ 継続的テストモデルとは何か 継続的テストモデルにおいてテストは「活動」である シフトレフトなテスト活動とシフトライトなテスト活動 シフトレフトなテスト活動としてのテスト駆動開発 コード実装を始める前から行うテスト活動 シフトレフ
はじめに エンジニアの皆様、テストコードはちゃんと書けておりますでしょうか？（挨拶） どんな開発言語や開発手法を導入していたとしても、アプリケーションの機能実装とテストは表裏一体であると言えます。場合によっては機能の作り込みよりも時間をかけるべきケースが多いくらい重要である（・・・と信じたい）反面、デッドラインが近づくにつれて真っ先に工数が削られやすく軽視されがちな工程でもあります。 時間に追われてテストコードを書いた結果、テストの体をなしていないコードになっていたり後で見返したときに記述が煩雑すぎてメンテ不能になっていたり・・・といった苦い経験は誰しもがあるかと思います。かくいう自分もそんなことは多々ありました。 そんな今までの経験則を基に「自分がテストコードを書くにあたってどんなことを意識しているのか？」をいくつかピックアップして備忘録も兼ねて紹介したいと思います。 一応注意なのですが
前回の記事では、JavaScript の実行エンジン V8 の JIT 出力コードを読んでみました。記事は M1 Mac 上で動かした結果でしたので、ARM アーキテクチャのアセンブラを読むことになりました。 さてそんな ARM アーキテクチャですが、最近の ARM には FJCVTZS という JavaScript 専用の機械語命令があるのをご存知でしょうか？CPU に、特定の言語（それもコンパイラを持たない JavaScript）専用の命令があると知ったとき、私は大いに驚きました（過去にも Jazelle みたいなものはありましたが） 今回は、この FJCVTZS 命令について、実際にどれだけ効果があるのか、V8 をビルドしながら調べてみましょう。 FJCVTZS 命令とは？ FJCVTZS 命令は、Arm v8.3 から導入された JSCVT 命令の一つで、JavaScript の言
『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/
TRACERYプロダクトマネージャーのharuです。 「要件定義とは何を目的としたプロセスなのか？なにが出来たら完了なのか？」 はじめて要件定義する人は、ここで詰まってしまうことが多いようです。 要件定義は、設計や実装に比べて、具体的な作業がイメージしにくいプロセスです。 そのような背景もあってか、2023年4月のBPStudy#188〜要件定義を学ぼう。ChatGPTを添えてに私が登壇した時の以下のスライドには、945個のはてなブックマークをいただきました*1。 speakerdeck.com 945というブックマーク数は、要件定義というものを具体的にイメージしにくいと感じている人が世の中に多いことの現れかもしれません。 そこで「要件定義とはそもそも何か」について、何回かの記事に渡って説明します。 この記事では要件定義の目的とゴールについて説明します。 プロジェクトの数だけ存在する開発プ
高品質と高スピードを両立させるテストアプローチ/Test Approach that Improves Quality and Agility Together
高品質と高スピードを両立させるテストアプローチ/Test Approach that Improves Quality and Agility Together
開発生産性の観点から考える自動テスト（2024/06版） / Automated Test Knowledge from Savanna 202406 Findy dev-prod-con edition
2024年6月29日 Findy 開発生産性カンファレンス2024 Closing Keynote https://dev-productivity-con.findy-code.io/2024
良いテストコードのために悪いテストコードを理解する - 不安定なテスト編: iOSアプリ開発ユニットテストの場合
「モバイルアプリ開発における良いテストコードの考え方」の発表資料です。 https://trident-qa.connpass.com/event/320151/
プログラム、下から作るか？上から作るか？
TL;DR プログラムは「下から組む方法」と「上から組む方法」がある プログラムを組む時は少しずつテストしながら組む はじめに なにかゼロからプログラムを組むとします。そのプログラムのアルゴリズムや、何をやるべきかはなんとなくわかっているけれど、どこから手をつけてよいかがわからず、ChatGPTに全部書かせて、その後修正できずに困る、という事例を何度か観測しています。 プログラムをゼロから書くのは慣れが必要です。プログラムをゼロから書く場合、小さな部品を一つ一つ作っていって、最後にそれらを組み上げる「下から書く」方法と、「こういう関数が必要であるはず」と外枠から書いていって最後に中身を埋める「上から書く」方法があります。その一般論を論じるのは私の能力を超えるため、以下では「下から」と「上から」の例を挙げて、その「気持ち」を説明してみようと思います。言語はなんでも良いですが、ここではPyth
アメリカの民間宇宙企業SpaceX（スペースX）は日本時間2024年6月6日、同社が開発中の新型ロケット「Starship（スターシップ）」による第4回飛行試験を実施しました。Starship宇宙船は宇宙空間を飛行後に大気圏へ再突入し、予定されていたインド洋への着水を行って飛行を終えています。【最終更新：2024年6月6日23時台】 【▲ 米国テキサス州にあるSpaceX（スペースX）の施設「Starbase（スターベース）」から第4回飛行試験のために打ち上げられた新型ロケット「Starship（スターシップ）」。SpaceXのライブ配信より（Credit: SpaceX）】 Starshipは1段目の大型ロケット「Super Heavy（スーパーヘビー）」と2段目の大型宇宙船「Starship」からなる全長121mの再利用型ロケットで、打ち上げシステムとしてもStarshipの名称で呼ば
スライド概要 GitHub Actions Meetup Tokyo #3 https://gaugt.connpass.com/event/317178/ このプレゼンテーションでは、サイボウズ社のGaroonのE2Eテストについて、GitHub Actions self-hosted runner 上で実行していたE2Eテストを高速化・安定化させるために取り組んだこと、E2Eテストワークフローの視点の改善アイディアについて話されます。GaroonのE2Eテストにおける実行時間とFlakyが問題となっており、その改善に取り組んだ内容が紹介されています。 おすすめタグ：GitHub Actions,E2Eテスト,self-hosted runner,Garoon,テストワークフロー
ChatGPTプログラミングのすすめ
ChatGPTなどの大規模言語モデル (Large Language Model; LLM) にプログラミングやリファクタリングをさせる場合、目的に合ったものが作られているかを何らかの方法で検証する必要がある。 プログラムの正しさを完全に保証する方法はないが、ある程度の正しさを継続して担保するための方法を探ってみたので以下にまとめた。 ポイントは、ChatGPTの生成したプログラムの検証にもやはりChatGPTの力を借りることである。 実行可能性と入出力のチェック プログラムを生成するタスクである場合、いつでも「実行できるか？」というチェックが可能である。これは自然言語の生成と大きく異なる点だろう。実行可能性を確かめることは最低限のチェック項目になる。 エラーが出力された場合、自力で修正するか、もしくは、エラーの内容をChatGPTに提示して修正を依頼し、再度実行可能かを確かめる。 入力・
こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 弊社では本番環境へのデプロイを1日に複数回実行していますが、本番環境での不具合の発生率は低いです。 次の画像は弊社のあるプロダクトの直近1年のFour Keysの数値です。 平均で1日2.3回の本番デプロイを行っていますが、変更障害率は0.4%程度を維持しています。単純計算ですが、1年で障害が2件程度の水準です。 また、平均修復時間は0.3hとなっており、障害が発生しても20分以内には復旧できていることがわかります。 この数値を維持できている理由の1つにテストコードの品質があると考えています。 システムで発生する不具合を自動テストが検知することで本番環境への不具合の混入を事前に防ぐことができ、仮に不具合が発生したとしても修正内容が他の箇所に影響が出ないことをテストコードが保証してくれるため迅速に修正できるから
t-wadaさんの開発生産性の観点から考える自動テストを聴講して悔い改めたこと - shoudaiの日記
t-wadaさんのセッションを聴講したこと 2024/6/29に開発生産性カンファレンスに参加してきました。 その中でなんでもかんでもE2Eテストでも実行してしまうことがあるけど、 悪ではないけどデメリットもあるよ。って話がありました。 speakerdeck.com スライドP47のアイスクリームコーンとピラミッドの図だけはご参照ください。 頭の中にその図が残っているため、前提になってます。 セッションの概要 アジェンダからざっくりお話は 信頼性の高い 誤検知（テストとして正常であるはずがエラーになってしまう）や見逃し（エラーがあっても正常にしてしまう）がないこと 実行結果 実行結果値だしたり、エラー原因が特定しやすいテストを書くこと 短い時間で到達 確認したい観点を確認できる最小のテストスコープ（単体テスト、結合テストなどの粒度）でテストできるようにすること 状態に保つ 短い時間で到達
コンテナの仕組みを勉強したかったため、Goでコンテナランタイムを自作した。雑実装だし未実装の機能もたくさんあるが、ある程度形になってきたため現状をまとめる。 リポジトリ github.com kombu/dashi - 自作コンテナランタイム kombu/nimono - eBPFを利用したシステムコールロガー kombu/yaminabe - dashiとnimonoを利用したマルウェアサンドボックス プロジェクト名から和の雰囲気を感じるが、これはリポジトリ名をkombu（昆布）にしたかったため、せっかくなら今回は和風で固めようと思ったから。趣があっていいんじゃないでしょうか。 dashiが自作コンテナランタイムだが、nimonoとyaminabeは実験的な要素で、セキュキャン2023でコンテナを使ったマルウェアサンドボックスを実装した経験があり、今回はその再実装を自作コンテナランタイム
１．はじめに UTF-8 の文字コードのファイルには、BOM (Byte Order Mark) がある場合とない場合がある。 Unicode の規格では、BOM は、推奨されないが、許容されている。 ja.wikipedia.org 今回、必要があり、色々な OS や言語で、UTF-8 の文字コードのファイルを作成した時、BOM が記録されるか、されないか、を調べた。 ２．色々な OS や言語での BOM 2.1 Windows 10, Visual Studio, C++, _wfopen (_tfopen), // Visual Studio 2005 以降 保存 FILE *fp = _wfopen(name, _ L"w, ccs=UTF-8"); if (fp == NULL) { // エラー処理 } fwprintf_s(fp, L"ABC漢字123\n"); fclose
Serverless Frameworkの有償化に伴いAWS CDKとAWS SAMへの移行について検討してみた | DevelopersIO
なおこの「Credits」という単位は serverless.yml ファイルのregion,stage,serviceパラメータの組み合わせによって定義されるようです。 したがって、例えば開発者やチケット毎の検証環境をstageで分けている場合は、その分Creditsが嵩むという形になります。 また、serviceもどのように分割するかで総Credit数が変わってきますので、この辺は見積りのし辛さに繋がってくるのかなと思います。 例えばregionとして東京, シンガポールを用意し、stageとしてprod, stg, dev, user1, user2があり、serviceとしてxxx, yyyがある場合、単純に掛け算をすると2x5x2の20 Creditsとなります。 また、Serverless Dashboardの機能を使うと、トレース50,000あたりで1 Credit、メトリク
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
個人的docker composeおすすめtips 9選 | フューチャー技術ブログ
なぜブラウザエンジンは 1 つではダメなのか? または Ladybird への期待 | blog.jxck.io
Web API設計実践入門──API仕様ファーストによるテスト駆動開発
テストコードを書く上で個人的に気をつけている5つのこと - Qiita
ARM に存在する JavaScript 専用命令「FJCVTZS」を追う（ついでに V8 をビルドする）
要件定義の目的とゴールとは - TRACERY Lab.（トレラボ）
【速報】スペースX、新型ロケット「スターシップ」第4回飛行試験を実施 宇宙船はインド洋へ着水
E2Eテストワークフローを高速化・安定化させる取り組み | ドクセル
Findyの爆速開発を支える「システムを守るテストコード」の実例3選 - Findy Tech Blog
コンテナランタイムを自作した - zebian.log
UTF-8 の BOM について - 将棋プログラミング