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
なぜ作ったのか これまでRustのGraphQLライブラリはjuniperとasync-graphqlがありました。 これら2つはCode Firstで設計されており、GraphQLのスキーマ定義をRustのマクロを使用して定義します。 以下はasync-graphqlの例です。 use async_graphql::*; struct MyObject { value: i32, } #[Object] impl MyObject { async fn value(&self) -> String { self.value.to_string() } async fn value_from_db( &self, ctx: &Context<'_>, #[graphql(desc = "Id of object")] id: i64 ) -> Result<String> { let co
こんにちはGAOGAOの代表をしております @tejitak です。GAOGAOアドベントカレンダー 17日目の記事です。GAOGAOのスタートアップスタジオにて、最近お手伝いしている海外のお客様案件にてTypeORMを導入しています。 今回の記事では、TypeORMとはなんぞや?という方を対象として、まだ比較的日本語記事が少ないTypeORMについてのご紹介します。 Node.jsのORM Node.jsでサーバーサイドを実装する際にはExpressを使うことが多いと思います。ExpressはサーバーサイドのWebフレームワークで、データベースを扱うORMは自由に導入することができます。以下代表的なORMを紹介します。 mongoose 公式ドキュメント: https://mongoosejs.com/ MongoDBはJavaScriptとの相性の良さから昔からNode.jsの多くのプ
エムスリーエンジニアリンググループ QAチームの城本です。BIRでアンケートシステムのQAを担当しています。最近E2Eの自動テストを導入した際に、フレームワークの選定や作成後の運用で考えたことを紹介します。 E2E自動テスト導入の動機 今回E2Eテストの導入対象としたのは、ここ一年くらいで開発からサービスインに至ったアンケートシステムです。システムの仕組みはこちらの記事でも紹介されてますので、よかったらご覧ください。 www.m3tech.blog 当初このシステムに対しては、UIを変更する可能性も大きかったため修正コストの方がかさむと考えE2Eテストは導入していませんでした。サービスインしてしばらくすると、安定的に稼働し始めたこと、機能追加も回り始めたこともあって、E2E自動化の検討を始めました。 小さく始めることにし、E2E自動化の対象は以下2点をカバーすることとしました。 アンケート
await new Promise(resolve => setTimeout(resolve, 3000)) // 3秒待つ // ... 3秒後の処理 ... // よくある長めの実装 const sleep = () => new Promise(resolve => { setTimeout(() => { resolve() }, 3000) }) await sleep() // ステップ1: () => { resolve() } は resolve に短縮する const sleep = () => new Promise(resolve => { setTimeout(resolve, 3000) }) await sleep() // ステップ2: resolve => {} は resolve => に短縮する const sleep = () => new Prom
Swift 5.5 では、待望の async/await 構文をはじめとした Swift Concurrency Roadmap における並行処理機能、いわゆる Swift Concurrency のサポートが多く開始され、WWDC21 でも各機能の使いかたや仕組みが詳細に解説されていました。 Swift Concurrency についてはすでに koher 氏の 『Swift 6 で来たる並行処理の大型アップデート近況』や『先取り! Swift 6 の async/await』 などの資料でも詳細に解説されています。この記事では WWDC の各セッションで行われた説明の紹介を中心に、この記事ひとつで Swift Concurrency についての現時点での概観を把握できる状態を目指して、改めてまとめてみました。 async/await Concurrency にまつわる様々なプロポーザル
はじめに 「UniTask」を Unity プロジェクトに導入することで 非同期処理を簡単に記述できるようになります この記事では「UniTask」の使い方をいくつか紹介していきます 目次 はじめに 目次 検証環境 導入方法 使用例 Resources.Load を非同期で待つ シーンの読み込みを非同期で待つ 指定したフレーム数待つ 指定した秒数待つ コルーチンを待つ 指定した条件が true になるまで待つ 指定した条件が false になるまで待つ 自作の非同期メソッドを待つ UnityWebRequest を待つ 進捗を取得する 3D の当たり判定を待つ 2D の当たり判定を待つ ボタンが押されるのを待つ Awake、Start、OnDestroy を待つ OnEnable、OnDisable を待つ AsyncLazy(非同期遅延初期化)を書く すべての非同期処理が終わるまで待つ
この記事は Rust アドベントカレンダー 5 日目の記事です。OGP 画像は間に合わなさそうな画像です。 Rust そのものには非同期処理の仕組み自体はありますが、非同期のタスク群をスケジューリングして実行する仕組みがありません。これはユーザーもしくはライブラリに任されています。例えば代表的なライブラリである tokio は schadular や executor を提供します。 非同期処理は関係してくる分野が多くさまざまなレイヤーが重なるのでとても難しいと思っています。そこで非同期処理を深く理解するために tokio を使わなければレイヤーをひとつ剥がせて理解が深まると思いました。そこで tokio を使わずに Rust の公式 crate だけで非同期処理を実現してみましょう。 ちなみに前編とついているのはアドベントカレンダーに間に合わせるために志半ばで切り上げたからです。という
home A TCP Proxy in 30 lines of Rust Jul 2021 TCP proxies accept connections from one computer and forward them to another. AWS Global Accelerator and Cloudflare Spectrum are examples of TCP proxies you can pay to use in the wild. TCP proxies can be quite simple. Here we’ll write one in 30 some lines of Rust. After we write it we’ll demonstrate the proxy’s functionality by proxying traffic from lo
Debugging asynchronous code in JavaScript can feel like navigating a minefield at times. You don't know when and where the console.logs will print out, and you have no idea how your code is executed. It's hard to correctly structure async code so it executes in the right order as you intend it to. Wouldn't it be nice if you had some guidance while writing asynchronous code, and to get a helpful me
Several weeks ago, the .NET Blog featured a post What is .NET, and why should you choose it?. It provided a high-level overview of the platform, summarizing various components and design decisions, and promising more in-depth posts on the covered areas. This post is the first such follow-up, deep-diving into the history leading to, the design decisions behind, and implementation details of async/a
Async UI: a Rust UI Library where Everything is a Future Lifetime-Friendly, Component-Based, Retained-Mode UI Powered by Async Rust This blog post is intended for readers with some experiences in async Rust. It assumes you know what a Future is! What is Async UI? Async UI is a proof-of-concept Rust UI library with backends for the web (HTML/JS) and GTK 4. Screenshots Todo List Demo (interactive ve
※ 本記事ではざっくりとした理解を目的とするため、スレッドとプロセスとコア、非同期処理と並列処理と並行処理の違いについて詳細には取り扱いません。気になる方は下記の記事などをご参考ください。 async スレッド数もコア数も1 だから並列処理じゃなくない? というツッコミは正解です。正確には並列処理ではなくて「非同期処理」といいます。フロントエンドのJavascriptから始めた方にはなじみが深いかもしれませんが、「非同期処理」と「並列処理」は全く違う概念なのでご注意ください。 処理の概要としては、最初に複数のリクエストを投げておいて、レスポンスが全部帰ってくるまで待ち、応答が揃ってから処理を再開します。 これにより、応答に 3~7秒(平均5秒)かかるスクレイピングを100回行う場合、同期処理なら500秒程度かかるところ、asyncを使った非同期処理なら7,8秒程度で実行できます。 (外部と
The first versions of React Router actually had an async hook to help with data loading called willTransitionTo. Nobody really knew how the heck to use React at the time and we were no exception. It wasn't great, but it was at least going in the right direction. For better or for worse, we went all in on components for React Router v4 and removed the hook. With willTransitionTo gone, and component
この記事ではasync/awaitについて完全に理解する[1]ことを目標に説明します。 完全に理解するために一部厳密には正確ではない表現をしますがご了承ください。 (明らかに事実と異なる内容が含まれている場合はご指摘いただけると助かります) ちなみにC#の文法説明になりますが、他の言語でも基本的な考え方は同じはずです。例えばJavaScriptの場合はTask型をPromise型に置き換えていい感じに読んでください。 非同期処理とTask型 async/awaitを完全に理解するためには、非同期処理の扱い方について完全に理解する必要があります。 そもそも非同期処理って何?という方はググってください。同期処理と非同期処理の違いについては完全に理解した前提で説明します。 非同期処理は複数のタスクを同時並行に処理するためのものですが、実際にコードを書いていると非同期で処理しているタスクが終わるま
Route requests to handlers with a macro free API. Declaratively parse requests using extractors. Simple and predictable error handling model. Generate responses with minimal boilerplate. Take full advantage of the tower and tower-http ecosystem of middleware, services, and utilities. In particular the last point is what sets axum apart from other frameworks. axum doesn't have its own middleware sy
我々の生活にQRコードが浸透してから何年経ったでしょうか。QRコードの読み取り機能はOS標準で可能になり、もはや「QRコードアプリ」すら不要な時代になりました。 一方でブラウザにおけるQRコードの取り扱いは、全くサポートされていませんでした。今まではゼロから実装した有志のライブラリを使ってQRコードの読み取りを実装していました。 しかしBarcode Detection APIの実装で、そういったライブラリも不要になるかもしれません。 Shape Detection API 近年になって、ブラウザにShape Detection APIというAPIの策定・実装が始まっています。 Shape Detection APIは現在以下の2つのAPIから構成されています。 Barcode Detection API Face Detection API また、「親戚」として、OCRを実現するText
Announcing `async fn` and return-position `impl Trait` in traits The Rust Async Working Group is excited to announce major progress towards our goal of enabling the use of async fn in traits. Rust 1.75, which hits stable next week, will include support for both -> impl Trait notation and async fn in traits. This is a big milestone, and we know many users will be itching to try these out in their o
.NET added async/await to the languages and libraries over seven years ago. In that time, it’s caught on like wildfire, not only across the .NET ecosystem, but also being replicated in a myriad of other languages and frameworks. It’s also seen a ton of improvements in .NET, in terms of additional language constructs that utilize asynchrony, APIs offering async support, and fundamental improvements
コルーチンの基本的なアイディアを正確さより雰囲気重視で解説してみました。 一応コルーチンやイベントループによる非同期処理に関しては概念はPythonに限った話ではないのでNode.jsなどでも同じ理解でいいはず。。。 下記のサンプルを全部動かすにはPython 3.6以降を使ってください。(ローカルにない場合はdocker run --rm -it python:3.7とかでもOK) コルーチンとは サブルーチンの上位(?)概念です。 サブルーチン(いわゆる関数)はエントリポイントが一つで、一度呼び出したら値が返されるまで一気に動きます。 これに対しコルーチンはエントリポイントが複数箇所あるため、一度呼び出されても中断でき、その場所からまた再開できるというものです。 async/awaitとネイティブコルーチン Python 3.5でasync/await構文とともに導入されたネイティブコ
SpringFramework 6.0.11 SpringBoot 3.1.2 @Async と @EnableAsync の使い方 SpringFrameworkで @Async を使うとかんたんにメソッドを非同期で実行できます。 @Component class AsyncComponent { @Async void method() { // 時間のかかる処理 } } 使う側は単にメソッドを呼び出すだけです。戻り値を処理したいなら Future で受ければいいけど、投げっばでいいなら void で良い。投げっばでいい場合の方が多いはず。 @Async を使うためにはアノテーションを処理する何かしらが必要で、この一式を用意するように指示するのが @EnableAsync です。 以下のようなクラスをSpringがわかるところに置いてあげます。 @EnableAsync @Config
Promise を返す非同期関数を扱うとき Promise をそのまま返す書き方と Promise を await してから返す二通りの方法があります。 const fetchUsers1 = async () => { return axios.get("/users"); }; // または const fetchUsers2 = async () => { return await axios.get("/users"); }; 上記のコード例は一見するとどちらも同じように動作するように思えますが、以下のような違いがあります。 例外がキャッチされる場所 スタックトレースの出力 マイクロタスクのタイミング 例外がキャッチされる場所 初めに考えられるもっとも顕著な例として try/catch ブロックと共に使用されている場合です。端的に説明すると return の場合には関数の呼び出し元
はじめに FastAPIを始めてみたところ、async/await構文があり、Pythonにも「async/await構文があるんだなー」と初めてその存在を知った。 しかし、FastAPIのサンプルコードやネットで公開されているコードを見ると、async defとdefをどのように使い分けているのかよくわからず、結局、「どっちを使えば良いんじゃろう?」という気持ちになったので、async/await、同期 / 非同期(並行処理)を調べつつ、結論を導いてみることにした。 いきなり結論 Path operation 関数の場合、async defではなくdefで、基本、実装する。 defだけでも、外部スレッドプールで非同期処理されるようにフレームワークとして実装されているとのこと async defを使った方が良いのは以下の2ケース async/awaitをサポートしているライブラリを利用した
背景 FastAPIでは以下のようにデコレータ関数を使うことでHTTPサーバのpathを設定することができ、これをPath Operationと呼びます。 from fastapi import FastAPI app = FastAPI() @app.get("/") async def read_root(): return {"Hello": "World"} @app.get("/items/{item_id}") async def read_item(item_id: int, q: str = None): return {"item_id": item_id, "q": q} このPath Operationでdefを使うべきかasync defを使うべきかの方針を説明します。 環境 Python 3.9.11 FastAPI 0.74.1 方針 結論から言うと以下の方針で
2019年11月にリリースされたRust 1.39では,非同期プログラミングを支援するためにasync/awaitが言語機能として導入されました. 機能自体の解説は「Rustの非同期プログラミングをマスターする」などを読んでいただくと良いでしょう. 本稿ではasync/awaitの基本的な知識は前提としたうえでformat!との組み合わせにより生じる不可解なエラーについて解説します. エラー例 次のコードはStringを受け取るasync fnにformat!で作成した文字列を渡し,awaitしています. async fn take_string(_: String) {} fn main() { tokio::spawn(async { take_string(format!("")).await; }); } $ cargo c Checking crate_name v0.1.0 (
Recently, I found myself returning to a compelling series of blog posts titled Zero-cost futures in Rust by Aaron Turon about what would become the foundation of Rust's async ecosystem and the Tokio runtime. This series stands as a cornerstone in writings about Rust. People like Aaron are the reason why I wanted to be part of the Rust community in the first place. While 2016 evokes nostalgic memor
Safari 13.1 adds support for the async Clipboard API. This API allows you, as web developers, to write and read data to and from the system clipboard, and offers several advantages over the current state of the art for reading and writing clipboard data via DataTransfer. Let’s take a look at how this new API works. The API The Clipboard API introduces two new objects: Clipboard, which is accessibl
Intro Promise.withResolvers() は、 Stage 4 であり ES2024 の候補となった。 すでにブラウザでの実装も進んでいるため、その活用方法を解説する。 イベントの Promise 化 JS では、非同期処理 API は長らくイベントリスナベースで定義され、それを組み合わせるフロー制御で処理されてきた。 しかし、 Promise が定義されて以降は、標準 API も Promise を返すようになり、 async/await によって処理されるのが一般的になってきた。 結果、イベントリスナベースの API を Promise 化するような場面も増えた。 例えば以下のようなものだ。 async function request() { return new Promise((resolve, reject) => { document.querySelect
I'm not feeling the async pressure written on Wednesday, January 1, 2020 Async is all the rage. Async Python, async Rust, go, node, .NET, pick your favorite ecosystem and it will have some async going. How good this async business works depends quite a lot on the ecosystem and the runtime of the language but overall it has some nice benefits. It makes one thing really simple: to await an operation
The Async Foundations Working Group believes Rust can become one of the most popular choices for building distributed systems, ranging from embedded devices to foundational cloud services. Whatever they're using it for, we want all developers to love using Async Rust. For that to happen, we need to move Async Rust beyond the "MVP" state it's in today and make it accessible to everyone. We are laun
最近のお仕事で、C#の非同期処理の書き方が分からずに、溶岩地帯に自爆していくコードを沢山みるようになったので、ケースとして日常風の記事にしてみました。 どんな風にハマってしまい、どうやって解決するのかが分かると思います。 結論 先に書いておきます。 Task.Run()を使ってはいけません Task.Result, Task.Wait()を使ってはいけません Threadクラスを使ってはいけません async-await構文だけを使って書きます async voidにするのは特殊な場合だけです がんばれー、わかってしまえば難しくない! 補足: もしあなたがJavaScriptで非同期処理を書いた事があるなら、その知識をそのまま生かせます。 JavaScriptではTaskの代わりにPromiseを使いますが、Promiseには上記1,2,3は存在しません。しかし、それで困ることはありません
Tonic: gRPC has come to async/await! I am pleased to finally announce a crate that I have been working very hard on for the past few months. tonic has finally hit the initial 0.1.0-alpha.1 release! Stable releases will follow in the coming months. What is Tonic? Tonic is a gRPC-over-HTTP/2 implementation focused on high performance, interoperability, and flexibility. This library was created to ha
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く