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

こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab

中国のSNS「快手（Kuaishou）」は、テキストから最大2分間の動画を生成できる動画生成モデル「可灵（Kling）」を開発。多数のサンプル動画を掲載するデモサイトを公開した。 テキストから最大2分間のフルHD動画を生成 A Chinese AI video generator just dropped before we got access to Sora Can generate 2-minute videos at 30fps, 1080p quality, available on the KWAI iOS app with a Chinese phone number A few generations from their site: 1. pic.twitter.com/NEmWiqKHiO — Rowan Cheung (@rowancheung) June 6, 20

以下の文書はBashを使う前提の話。 Bashにはコマンド置換(Command substitution)というのがある。$(another-command)のように、$()でコマンドを括る記法だ。これを利用すると、括弧で括られたコマンドが実行され、その標準出力が文字列として取り出され、$()全体を置き換える。シェルスクリプトでは非常によく見る技術だ。 この$()でファイルの内容を読み出すというのを最近見た。このような用法は非常によく見る。 foo-command $(cat params.txt) しかし、より良い書き方があるのでこれを提唱したい。$(< params.txt)と書くことで全く同等のことができる。しかも速いのでこちらのほうが完全に上位互換となる。 foo-command $(< params.txt) この方法はBashのドキュメントのコマンド置換のコーナーにちゃんと書か

はじめに Linuxの面白い（あんまり使い道のないどうでもいい）コマンドを9個まとめてみました。暇な時ぜひ試してみてください！ ※環境によっては、コマンドのインストール方法が異なる場合があるので、本記事ではインストール方法を記載しません。 1.メッセージをつぶやくウシ cowsay cowsayは、メッセージをつぶやくウシ(オプションで他の動物を指定することも可能)のアスキーアートを生成するプログラムです。 下記コマンドを実行すると、「Hahaha」というセリフを言うウシが表示されます。 $ cowsay Hahaha ________ < Hahaha > -------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || $ cowsay -f turtle Hahaha ________ < Hahaha > -------- \ __

GitHub Actions に Arm64 ランナーが来たので Docker のマルチプラットフォームイメージをビルドしてみる 2024/06/03 に GitHub Actions に Arm64 ランナーが追加されました。 現在はパブリックベータで、Team と Enterprise Cloud プランでのみ利用可能です。料金は x64 の同性能のランナーより 37% 安く、電力効率が高いため二酸化炭素排出量削減にもつながるとのことです。 この記事では、新しく追加された Arm64 ランナーを使って Docker のマルチプラットフォームイメージをビルドしてみます。 マルチプラットフォームイメージとは？ マルチプラットフォームイメージとは、複数の異なる CPU アーキテクチャ（場合によっては異なる OS）のイメージを 1 つのイメージとして扱えるようにまとめたものです。マルチプラット

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

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を厳しく適用

リプライには「どうやってるの？」といった趣旨の質問も多いが、Lettier氏は「Paid course coming soon.（有料コースを準備中です）」と回答しており、その構造はまだ明らかにされていない。 参考資料として、Lettier氏が3月にYouTubeにアップしたこちらの動画では、シェーダーノードを用いてスケッチ風のトゥーンシェーディングをつくっている。 また、Lettier氏はGitHubでツールやチュートリアルも公開している。2019年に公開された「3D Game Shaders For Beginners」は3Dゲームに対してSSAO（Screen-Space Ambient Occlusion、ポスト処理によるアンビエント・オクルージョンの近似効果）や被写界深度、ライティング、ノーマルマップなどを実装するためのドキュメント。17,000超のスターと1,300のフォークを

この記事は Vim 駅伝 の 06/05 の記事です。 前回の記事は thinca さんによる、 06/03 の「Meguro.vim #23 を開催しました」という記事でした。 次回は 06/07 に投稿される予定です。 はじめに 本記事は以下の記事のオマージュです。 Vim の基本操作のうち、比較的マイナーながら汎用的に使える機能や小技を集めました。プラグインや複雑な設定が必要なものは含まれておらず、いずれも Vim と Neovim の両方で使うことができます。気になったものがあれば使ってみてください。 ノーマルモード編 検索結果を次々と置き換える Vim で文字列置換を行う最も有名な方法は :substitute コマンド （短縮形: :s） ですが、ノーマルモードの cgn というイディオムも便利です。これは c オペレータと gn テキストオブジェクト (:h gn) を組み合

はじめに こんにちは、最近の私の人生はキックボクシングとコーディングの2つの活動に極端に偏りつつあります。nwiizoです。一見正反対のようなこの2つの活動ですが、共通する本質があります。それは、頭で考えるだけでなく、実際に体を動かして実践することで新しい発見や気づきを得ていくプロセスです。 キックボクシングでは、理論だけでは表現できない”技”を体で覚えていきます。理論上の動作はスムーズに行えても、実際にパンチやキックを繰り出す際には、さまざまな戦略を一瞬のうちに計算し、機動的に対応しなければなりません。そこでは思考するよりも先に、体が自然と反応するよう繰り返し訓練を重ねていきます。 一方のコーディングにおいても、書籍から得た知識を単に暗記しているだけでは意味がありません。実際にコードを書きながら、試行錯誤を重ね、バグに出くわし、その都度解決策を見出していく中で、本当の理解が深まっていきま

本稿はNext.js v15.0.0-rc.0時点の情報を元に執筆しており、PPRはさらにexperimentalな機能です。v15.0.0のリリース時や、PPRがstableな機能として提供される際には機能の一部が変更されてる可能性がありますので、ご注意下さい。 Partial Pre-Rendering(以降PPR)はNext.js v14.0で発表された、SSRやSSGにならぶ新たなレンダリングモデルです。 PPRは前述の通り開発中の機能で、v15のRC版にてexperimentalフラグを有効にすることで利用することができます。ppr: trueとすれば全部のページが対象となり、ppr: "incremental"とすればexport const experimental_ppr = trueを設定したRouteのみがPPRの対象となります。 // next.config.mjs

最近読んだ「入門 継続的デリバリー」がとても良かったので紹介しますね, というエントリーです. 入門継続的デリバリー良かったです. 「継続的デリバリー（Continuous Delivery）」とか「DevOps」ってどこから学ぶかわからんな！？ というのは割とあるあるだと思っています, そもそもめちゃくちゃ難しい話なので（ちゃんと学ぼうとすると）. そんな中, 「入門 継続的デリバリー」がよく説明できてて良かったので感想と関連する書籍を紹介できればと思っています. TL;DR 入門 継続的デリバリー 我々はなぜCDをするのか? 具体的なプラクティス 入門後に読むべき良著 Kubernetes CI/CDパイプラインの実装 継続的デリバリー チームトポロジー 結び - 我思うCDとDevOps TL;DR 「入門 継続的デリバリー」は継続的デリバリーの大切さと概念, 手法を現実にありそうな

本記事は 【プルリクウィーク】 4日目の記事です。 💻 3日目 ▶▶ 本記事 ▶▶ 5日目 📚 こんにちは越川です。 GitHubはアプリケーションの開発に携わる人がメインで使う、という印象が強かったのですが現在、クラウドエンジニアの私もほぼ毎日GitHubを触っています。 私の場合、業務上、IaCを使うのでプログラミングをする機会が多く、その分プルリクエスト（以降PR）を見ることも出すことも多くあります。今回は自分自身がPRを見る時、または出す時にどんなことを意識しているのかを書いてみようと思います。 ※PRとは新規開発や改修などの内容を関係者に通知する仕組みです。このPRをトリガーに関係者はコードのレビューを実施し、問題なければマージを行います。 ※IaCとはInfrastructure as Codeの略称で、サーバーやネットワークなどあらゆるインフラリソースをコード化し、構築を

はじめに こんにちは。ソーシャル経済メディア「NewsPicks」の QA/SET チームの海老澤です。 先日は Playwright を使ったE2Eテストの導入について、紹介させていただきました。 今回は作成したテストをAWS 基盤上で動かす方法を紹介させていただきます。 前回の記事 tech.uzabase.com E2Eテスト実行のタイミング NewsPicksでは 下記のタイミングで E2Eテストを実行させています。 ①リリース時のカナリーデプロイ後 NewsPicks ではカナリーリリースを採用していてカナリーへのデプロイが完了した後、カナリーに向けてE2Eテストが動きます。 ②開発環境デプロイ後 動作確認をしたい場合に feature ブランチなどでデプロイ後 E2Eテストを実行できるようにしています。 本記事では主に 「②開発環境デプロイ後」 を例に紹介します。 実行方法 具

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

はじめに セキュリティエンジニアの齋藤ことazaraです。今回は、不可思議なContent-Typeの値と、クラウド時代でのセキュリティリスクについてお話しします。 本ブログは、2024 年 3 月 30 日に開催された BSides Tokyo で登壇した際の発表について、まとめたものです。 また、ブログ資料化にあたり、Content-Type の動作や仕様にフォーカスした形で再編を行い、登壇時に口頭で補足した内容の追記、必要に応じた補足を行なっています。 また、本ブログで解説をする BSides Tokyoでの発表のもう一つの題である、オブジェクトストレージについては、以下のブログから確認をすることが可能ですので、ご覧ください。 blog.flatt.tech なぜ今、この問題を取り上げるのか？ 従来のファイルアップロードにおいて、Content-Type の値を任意の値に設定すること

AWSなどクラウド上のシステム負荷試験について解説した書籍「Amazon Web Services負荷試験入門」のレビュー記事です。負荷試験の基本知識、ツール、PDCAサイクルを使った具体的な進め方が詳細に解説されています。 こんにちは、ゲームソリューション部の入井です。 今回は、AWS等のクラウド上に構築したシステムへの負荷試験について、具体的な手順や試験中に発生しがちな課題とその解決方法等について解説した書籍「Amazon Web Services負荷試験入門」を読んだ感想を書いていきます。 感想 Chapter 1 間違いだらけの負荷試験とWebシステムの失敗事例 タイトルの通り、負荷試験の進め方のよくあるアンチパターンが架空の事例を使って紹介されています。 打ち合わせ、試験準備、試験実施、試験レポートといった段階毎に登場人物同士の対話形式で進んでいくのですが、「お客様の意向で今回は

どうも GitHub Actions 上で Docker ビルドを行うと時間がかかるなぁと感じていました。 かなり軽量の Go の Web アプリケーションを Docker イメージにしてプッシュするプロセスなのですが、全体で 3 分ほどかかっています。 今回はその速度改善を行ったので、得た知見を記事にしたいと思います。 最終的に、ケース次第では以下のような結果を出すことができました。 ※ケース = go のソースコードのほんの一部を変更してワークフローを実行する。　go.mod など依存関係に変化はない。 go build: 60秒 → 1秒 docker/build-push-action ステップ: 2分30秒 → 30秒 ワークフロー: 3分 → 1分 前提 go build は Dockerfile のステップで行っており、イメージとして以下のような内容になっています。 FROM