サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
techblog.paild.co.jp
お手伝いの@helloyukiです。最近tokioの提供するtracingに関していろいろ調べごとをしました。こうしたクレートを十分に使いこなすにはどうすればいいかを考える上で、自分なりに考えがまとまってきたので記事にしたいと思います。 なお、筆者はRust以外のプログラミング言語でのオブザーバビリティ関連の事項についてはまったくわかりません。Rust以外の事情は考慮しない記事となっている点にご注意ください。 目次 tracingとは オブザーバビリティ、テレメトリ、構造化ログ オブザーバビリティ テレメトリ 構造化ログ tracingを使う 核となる概念を掴む スパン、イベント、サブスクライバを使ってみる 実際のWebアプリケーションで使用する Tips フィールドの設定 構造化ログと非構造化ログの切り替え まとめ 参考 tracingとは tracing is a framework
お手伝いの@helloyukiです。パラメータ化テストをする際使えるrstestというクレートがあるのですが、このクレートが意外にいろいろなことができて感動したので記事にします。実務でどう使っているかもあわせて説明します。 rstestとは rstestがどのような課題を解決するであろうクレートであるかと、もっとも簡単なユースケースを紹介します。 問題意識 テストを書いていると、ある関数に対して与える値をわずかに変えながら、似たようなテストを書くことがあると思います。たとえば閏年を判定するためのテストを素のRustで書こうとすると次のようになるかもしれません。このテストでは、年号と閏年か平年かのペアを持つベクターを定義し、それをforループで回すことで記述量を減らしています。 #[derive(Debug, Eq, PartialEq)] enum Year { // 平年 Common,
お手伝いの yuki です。前回に引き続き、小ネタを紹介します。 みなさんは Rust でのバリデーションチェック時、どうしていますか? まず考えられるのは自前実装です。手でバリデーションチェックをひたすら書く方法がまず考えられると思います。あるいは、私のブログで以前紹介したことがあるのですが、バリデーションチェック情報を型に落として実装し、トレイトなどを駆使して若干程度半自動化するといった方法をとることもできるでしょう。 yuk1tyd.hatenablog.com あるいは多くの方は validator クレートを利用しているかと思います。私も業務でこのクレートを利用していますが、バリデーションチェックの情報をアノテーションに残しておくことができるため、どのフィールドにどのバリデーションチェックがかかる予定かがわかりやすく気に入っています。 github.com その他の選択肢として最
こんにちは、お手伝いの大櫛です。 今回は、rustc/Cargoまわりの脆弱性紹介に引き続き、community crates関連の脆弱性を紹介していきます。 rustcと違い、ある脆弱性一つがRustユーザー全体に影響を与えるものではないため、比較的広くつかわれているcrateのものや、個人的に面白いと思ったものを取り上げます。必ずしも今回の脆弱性すべてがCVSSスコアで言うところのクリティカルなものではないこと、今回紹介した以外にもクリティカルな脆弱性は存在し得ることをご留意ください。 また、筆者の理解不足により、脆弱性の説明において誤った内容を述べている可能性があります。そのような記述を見つけた際には何かしらの形でお知らせいただけますと幸いです。 対象とする脆弱性について RustSec Advisory DatabaseまたはGitHub Advisory Databaseに登録さ
こんにちは、お手伝いの大櫛です。 今回はRustのテスト体験を快適にするテスト系ライブラリ・ユーティリティをいくつか紹介します。 記事中、例としてコード片を示す箇所があります。今回はRust 1.73.0を用いていますが、今後のリリースにより動作が変わっている場合があります。また、各crateのバージョンについてはそれぞれの見出し直下に記載しています。 Fake 使用バージョン:v2.8.0 github.com UUID生成処理やユーザーインプットを受け取る処理などにおいて、テスト時だけそれらの処理や値を差し替えるという手法はよく取られています。 それらを補助するcrateがFakeになります。見目にわかりやすい名前をしていますね。 例えば、UUIDv5をランダムに生成する場合は以下のようになります: use fake::{uuid::UUIDv5, Fake}; use uuid::U
こんにちは。ペイルドの id:pranc1ngpegasus です。 今回は外部サービスから連携されるクリアリングファイルを仕様書に沿ってパースし、内部サービスに取り込む処理を再構築したので紹介します。 Before 図1: これまでのシステムの全体像 上記にこれまで稼動していたシステムの全体像を示します。 これまでデータのパースと内部サービスのリクエストは全てWindowsサーバ上で動くバッチで実行されていました。 Windowsサーバが外部サービスからクリアリングファイルを受け取りとバッチの実行をしており、以下のような問題点がありました。 永続化レイヤーを持たなかったためエラー時の復旧が面倒 EC2上で実行されるためバックアップ関係がEBSに依存している キューがなく処理全体が密結合になっている After 図1: 完成したシステムの全体像 上記に完成したシステムの全体像を示します。
こんにちは、お手伝いの大櫛です。 今回はRust + testcontainersのテスト環境、非同期にテストを行う際の注意点や工夫ポイントなどについて紹介していきます。 testcontainersとは testcontainersとは、PostgreSQLのようなDBや、Nginxのようなweb serverなどの環境をコンテナ形式でお手軽に用意してくれるフレームワークです。 testcontainers.com 主にテスト環境をお手軽に作成したいときに有用で、ローカルやCIなどの環境に併せてコンテナ・Dockerセットアップを細かく変える必要がない点が一つメリットに挙げられそうです。 Rustの他にJavaやGo、RubyやNode.jsなど、メジャーなプログラミング言語・実行環境向けのライブラリも用意されているので、コンテナの立ち上げからテスト実施までを開発言語内で完結させることが
Rocketの特徴 Rocketにはこれまで何が起きていたのか v0.5を使う 今回作るアプリケーションのお題 使用するクレートの追加 Routing JSON Fairings: データベース接続 1. コネクションプールを保持するための構造体を用意する 2. 設定ファイルに情報を書く 3. 1で作った構造体をサーバーにattachし、アプリケーションを起動する。 Todoを作成するRoutingを用意する Responder: エラーハンドリング 注意したいこと まとめ 参考サイト お手伝いの @helloyuki です。 最近、asyncに完全対応したRocketがついにリリースされ、v0.5から使えるようになったというニュースが舞い込んできました。RocketはRustのエコシステムをかなり前から支えてきたクレートではあったものの、いくつかの事情によりしばらくなかなか技術選定されな
お手伝いの yuki です。 今日は serde の話です。最近仕事で serde を使っていて「これはバグでは??」と思った挙動がありました。具体的には untagged というものなのですが、同僚に「これはバグではなく仕様」というコメントをもらいました。たしかにドキュメントを見てみると注意書き等書いてあり、そういえば serde をなんとなく使っていたなと思いました。というわけで今日は記事を書くことで serde の理解を深めるということをしたいと思います。 なお、この記事はドキュメント以上のことはあまり書かれないと思います。実務的にどう利用しているかという観点から、このドキュメントをもとに記事として再編集することを目指しているためです。serde のドキュメントは下記にあります。 serde.rs 目次 目次 まず、読み方 serde とは何か? 基本 基本的な使い方 まとめ まず、
こんにちは、ペイルドの大竹です。 今回は外部サーバーと通信を行っているEC2インスタンスをECS on Fargateに移行した話をしたいと思います。 移行する前は以下のような構成となっていました。 背景 EC2インスタンスの運用にて以下の課題がありました。 弊社ではPCI DSS準拠等の理由により、EC2インスタンスへのログインできる人・場所を制限し、ログインには申請が必要となっている パッケージ・カーネルの脆弱性対応等の定期運用が属人化している 制限された場所からのみアクセスが可能なため、急に手動対応が必要になった場合、迅速に対応できない可能性がある PCI DSSの要件でユーザーの管理・パスワードを定期更新などが必要 上記課題を解決するため以下の対応をすることにしました。 ECS on Fargateの採用 脆弱性対応はコンテナイメージを修正するだけなので誰でも対応が可能になる ログ
お手伝いの yuki です。今日はクレートを使った小ネタです。claim という、アサーション関連の便利なマクロを提供するクレートがあります。意外と知られていない気もするので紹介しておこうと思います。 claim assert_matches! や Result の結果を判定するのに便利な assert_ok! 、Option の結果を判定するのに便利な assert_some! 、非同期処理周りで用いられる Poll の準備完了判定を行える assert_ready! などの便利なアサーションに関連するマクロを提供するクレートです。シンプルながらも強力なクレートです。 下記から利用することができます。 github.com 今回はテスト用として説明しますが、もちろん本流の処理にも利用できます。リリースビルド時には挿入されない debug_* で始まるマクロも、すべてのマクロに対して提供さ
paild 社でお手伝いをしている yuki です。前回に引き続き Dependency Injection 略して DI の話題を書いていきたいと思います。今回は Rust における DI についていろいろと考えてみました。今回紹介する実装はかなり単純な例を用いたもので、この記事からさらにみなさんのアプリケーションの実装状況に合わせていくつか工夫は必要になるかもしれません。ただ、とっかかりとしては十分なものになっていると思うので、DI でお困りの方はぜひ参考にしてみてください。 今回実装したいアプリケーションのお題について 今回紹介する技法の種別について コンストラクタインジェクション 静的ディスパッチを用いたもの 動的ディスパッチを用いたもの 静的ディスパッチと動的ディスパッチの利点・欠点 shaku (DI コンテナ)を用いたインジェクション shaku の利点・欠点 余談: DI
こんにちは、お手伝いの大櫛です。 今回はrustcや標準ライブラリ、Cargoについて発見された脆弱性のいくつかを紹介していきます。 Cargoについての補足ですが、一般的なセットアップツールの一つであるrustupを使う場合、rustcとCargoはRust toolchainとして強く結びついています。このため、今回はrustcと共に紹介したいと思います。 念のための注釈として、この文章中の「Rust x.y.z以降」という表現はx.y.z自身を含むものとします。 また、この記事中ではMIT/Apacheでデュアルライセンスされている標準ライブラリの実装コードを一部引用している箇所があります。 最新stableに追従する重要性 脆弱性の紹介をする前に、rustcの脆弱性対応についてのお話を少ししておきます。 Rustは他の言語にあるようなLTSのような概念を持ちません。重大な問題の修正
お手伝いの @helloyuki_ です。今回はポエムです。 今回は、Rust を始めた当時、プログラミング言語は Java しかまともに触ったことがない新米若手 Java エンジニアだった私[*1]が「見たことがなく、使いどころがわからなく理解が難しい」と感じたポイントについて紹介します。対象とするソフトウェアのレイヤーが低いか高いかを問わず、とにかく Rust をやってみて理解するまでに時間がかかり、難しいと感じたポイントについて紹介します。 Rust の「メモリ安全」って、結局何 所有権とライフタイム 参照 スマートポインタ 代数的データ型 関数が第一級である モジュールシステム self 型クラスという側面でのトレイト まとめ 私が Rust をある程度使いこなせるようになるまでの話 「難しい」って何?、の話 Rust の「メモリ安全」って、結局何 そもそも論ですが、Rust が取
イントロ はじめまして。ペイルドの中川です。 弊社はサーバーサイドの開発に Rust を採用しています。 運用監視ツールには Datadog を採用しているのですが、Datadog 公式の SDK には Rust が含まれていません。なんてこった。 この記事では Rust で Datadog と連携する方法を紹介します。記事中に登場するソースコードは GitHub で公開していますので併せてご覧ください。Rust のバージョンは執筆時点(2023 年 4 月)で最新の 1.68.2 を使いました。 github.com OpenTelemetry Datadog は OpenTelemetry1 形式のテレメトリデータ(メトリクス、ログ、トレース)に対応しています。 OpenTelemetry が Rust 用 SDK を提供してくれているのでこれを使います。 次の axum を使ったシン
こんにちは大櫛です。Travis CIがオープンソースプロジェクトで使いづらくなったり、Azure PipelinesからGitHub Actionsになった途端*1爆発的な流行が生まれたりと、CIサービスにおいてもここ数年で色々な動きがありました。 特に技術記事・ブログのトレンドや企業のリクルート向け資料を見ていると、GitHub Actionsの利用が進んでいるような印象を受けます。 今回はそんなGitHub Actionsについて、Rust projectで使う際に知っておいた方がいいことやactionを紹介していきます。 以下の情報は執筆時点(2023-02-19)のものに基づいています。閲覧時には無効・誤ったものになっている可能性がありますので、必ず最新の情報・状態を確認するようにしてください。 actions-rs(非推奨) まずはじめに、執筆時点では使用を控えた方がいいact
paild 社でお手伝いをしている yuki です。みなさんは Rust で DI をしようと思った際に困ったことはありませんか?この連載では、他のプログラミング言語で利用される DI パターンを参照しながら、Rust でそれを実装するためにはどのような工夫が必要かまでを検討します。中には Rust での実装が難しいパターンも出てくるかもしれません。その際は、なぜ難しいのかまでを検証します。 そこそこの規模のソフトウェアを実装するにあたって、ソフトウェアエンジニアが共通して利用する手法がいくつかあると思います。その中でも DI (Dependency Injection; 依存オブジェクト注入) は最もポピュラーな手法の一つであり、保守運用まできちんと耐えうるソフトウェアの設計をしたいとなったときに、まず真っ先に候補に上がる手法でしょう。 Rust ではこの DI をどのように行えばよいの
このページを最初にブックマークしてみませんか?
『techblog.paild.co.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く