タグ

asyncに関するakishin999のブックマーク (60)

  • Play2をサーブレットコンテナで動かす - たけぞう瀕死ブログ

    Play2は組み込みのNetty上で動作します。サーブレットコンテナ上での動作はサポートされていません(ロードマップを見ると今後、バックエンドの1つとしてサポートされる可能性はあるようです)。 しかし、様々な事情でTomcatなどのサーブレットコンテナ上でPlay2を動かしたいというケースもあるでしょう。play2-war-pluginというsbtプラグイン(とランタイムを組み合わせたもの)を使用するとPlay2アプリケーションをwarにしてサーブレットコンテナ上で動作させることができます。 https://github.com/dlecan/play2-war-plugin play2-war-pluginを使用するにはまずAPP_HOME/project/plugins.sbtに以下の記述を追加します。 resolvers += "Play2war plugins release" a

    Play2をサーブレットコンテナで動かす - たけぞう瀕死ブログ
  • Netty の基本 - hozumiの日記

    ここ数日、Nettyについて調べていたので理解できたことを書きます。 JBoss Netty Netty は Java で非同期、イベント駆動のネットワークアプリを作るためのフレームワークです。Netty を使うと早くて簡単にハイパフォーマンス、ハイスケールでメンテナンス性がいいものが作れます。いいとこ取りの全部乗せです。 なぜハイパフォーマンス、ハイスケールか? Netty は Java NIO(New I/O)をラップしていて、ノンブロッキングなIO操作ができます。そのため、1つのコネクションにずっと1スレッドを割り当てる必要がないため効率のよいリソース消費をします。従来のブロッキングなOIO(Old I/O)もサポートしており、僅かな変更で好きな方を使えます。また、NIOの複雑なByte BufferをChannelBufferというオブジェクトに抽象化し、不必要なコピーが発生しない

    Netty の基本 - hozumiの日記
  • Finagle - 都会育ちのメッセージングフレームワーク - Backnumbers: Steps to Phantasien

    Scala でもやるかとぶつやく同僚を見て, たしかに Scala したいかも...などと意思の弱い私は気をそそられ, しかし特に書くものも思いつかずなんとなくウェブをぶらぶらしていた. そういえば HerokuScala をサポートしたニュースを読んだっけと検索すると, たしかにアナウンスがあった. このアナウンスにあるサンプルコードは面白い. Lift でも Play でもなく, Twitter の RPC フレームワークである Finagle が使われている. Finagle でサンプルを書いた理由の一つは画面におさまる簡潔さ, あとは流行り物の目新しさだろうけれど, Heroku の勧める Polyglot Platform の ありかたを示す意味もある気がしなくもない. Polyglot Polyglot という言葉を最初に目にしたのは プロダクティブプログラマ だったと思

  • アクターモデルについて

    YouTube nnabla channelの次の動画で利用したスライドです。 【AI論文解説】クラスタリングによる大規模データセット自動キュレーション https://youtu.be/RGO10ALxuso 以下の論文を解説しています。 Automatic Data Curation for Self-Supervised Learning: A Clustering-Based Approach https://arxiv.org/abs/2405.15613 スライドで使用している画像は論文中のもの、またはそれを参考に作成したものを使用しています。

    アクターモデルについて
  • 2015年Webサーバアーキテクチャ序論 - ゆううきブログ

    2023年03月31日追記:この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We

    2015年Webサーバアーキテクチャ序論 - ゆううきブログ
  • defer/asyncチェックツールを作りブラウザ対応状況を確認してみた | ゆっくりと…

    ちょっと前に 「scriptのdefer/asyncを理解し、ページの高速化方法を探る」 というエントリーを書きましたが、はてなのブックマーカー edvakf さんから 「Opera は defer も async も対応してないはず」 というご指摘を頂きました (edvakf さん、ありがとうございます)。 こちら と こちら (2012年11月16日:Google のドキュメントが削除されました) の表を 「対応状況」 としてそのまま流用してしまったのが失敗でした。英語をよく読めば、You can use the defer/async attribute on the following elements と書いてあります。つまり 属性は使えるけど、動作は別 とも読めるわけで…。 ということで、「defer/async チェッカー (仮)」 を作ってリベンジすることにしました。 1.

  • scriptのdefer/asyncを理解し、ページの高速化方法を探る | ゆっくりと…

    Yslow ルールでは、スクリプトはページの最後尾、つまり </body> 直前に置け、と言っています。なぜなら、スクリプトの読み込みや実行により、他のページ要素の読み込みやレンダリングがブロックされてしまうからです。 一方、古くは IE4 の時代から Microsoft はこの問題に対処するため、defer 属性という独自の解決策を実装してきました。これは HTML 4.01、XHTML 1.0、1.1 で仕様として採用され、HTML5 にも発展する形で引き継がれています。 IE 以外のブラウザも既に対応されており、IE の独自仕様という色合いが濃かった従来と異なり、これからは広く利用されていくのではないかと思います。 下のビデオは、スクリプトの位置と defer 属性のあり/なしによる、ページの読み込み/表示速度の違いを Pagetest.com でテストしてみたもので、明らかな差異が

  • setTimeout関数を使ってJavaScriptの処理を非同期化してみる - 知らないことがあってもへっちゃらさ

    わかったブログ さんの「遅いブログパーツを高速表示する方法」で紹介されていた setTimeout関数を使った JavaScript の処理の非同期化がなかなか使えたのでメモメモです。 一般にHTMLファイル内に下記のようなコードがあった場合 <script type="text/javascript"> example(); </script> ブラウザは example() の処理が終わるまで次の処理に進まないんですよね。このソースがHTMLファイルの中ほどにあって、なおかつ example() の処理に非常に時間がかかる場合、ユーザーにはWebページの表示(描画?)が止まっているように見えるわけです。 そこでソースを <script type="text/javascript"> setTimeout(function() {example();}, 0); </script> のよ

  • <script>タグのasync属性を使わずに非同期でJavaScriptを読み込む方法 | さくらたんどっとびーず

    HTML5 では <script> タグに async という属性が加わってまして、これを指定しておくと src で指定された JavaScript ファイルの実行が非同期で行われます。(src 属性を指定しないと async は意味を持ちません。) <script type="text/javascript" src="http://..." async="async"> </script> ググってると async の値として async=”true” を指定しているページが多いようですが、W3C の HTML5 の定義(4.3.1 The script element と 2.4.2 Boolean attributes 参照)だと空の文字列か属性名そのものを指定しろってことになってますので、こっちが正しいです。(たぶんw) If the attribute is present,

    <script>タグのasync属性を使わずに非同期でJavaScriptを読み込む方法 | さくらたんどっとびーず
  • Promiseに関するパターンや命名規則 - Qiita

    やや自己流含む。 getXxx/fetchXxx getXxxは同期、fetchXxxはPromiseということにしている。とくに非同期の取得系はfetchということに決め打ってる。 GETリクエストであることを明示したいときにややこしいという問題はあるが、そのケースは少なく、JS内で同期/非同期を明示したいことの方が多い。 例: 非同期の副作用系はput/post/sync/send/uploadとかそのあたりを適当に使う。 Promise( (done, reject) => {..}) 恐らく仕様的に正しいワードは fulfill, reject なのだが、fulfillはタイプ数が妙に多いのと、llが多くタイポしやすく、またタイポが発見しづらいので、自分は慣習的にdoneを使っている。 追記: fulfillよりもresolveの方が仕様に沿ってるっぽいhttp://people.

    Promiseに関するパターンや命名規則 - Qiita
  • Google Analytics トラッキング スニペット再考(2010) | MOL

    アナリティクス公式ブログ: 成長し続ける Google Analytics のエコシステム 非同期トラッキングコードが公式に推奨されるようになったので、ようやく重い腰を上げて調べてみました。長文です。 なぜ、非同期トラッキングコードが推奨されるのか? 今回のトラッキングコードはurcin.js、ga.jsに続く大きな変更となります。非同期トラッキングコードの恩恵を受けるためには、以前のトラッキングコードを使用されている方は、当然変更しなければなりません。しかし、大規模サイトの場合などはアクセス解析担当者とコード実装者は違うことも多く、エンジニアさんにお願いしなければなりません。「え〜、前変えたばっかじゃん!」などと言われるかもしれません。そんな時にアクセス解析担当者はトラッキングコード変更のメリットを提示しなければなりませんね。Analytics 公式ブログでは、非同期トラッキングコードの

    Google Analytics トラッキング スニペット再考(2010) | MOL
  • Node.jsフロー制御 Part 1 – コールバック地獄 vs. Async vs. Highland | POSTD

    (このシリーズのPart 2はこちら: Node.jsフロー制御 Part 2 – FiberとGenerator ) 今回は、JavaScript/node.jsアプリケーションのフロー制御に対するアプローチを、いくつか取り上げて比較してみたいと思います。 通常のコールバックを使う 平坦化されたコールバックを使う Async ( @caolan 作)を使う Highland (こちらも @caolan 作)を使う Bluebird ( @petkaantonov 作)を使う Expressフレームワークを使った以下のルート処理(お粗末ですが)を例に見てみましょう。 ファイルから読み込む いくつかのプロセスを実行する(ステップの数は3つ) プロセスとは、単に拡張データをコールバックする任意の非同期処理を指します ファイルに結果を書き出す リクエストに対して成功またはエラーのメッセージを返す

    Node.jsフロー制御 Part 1 – コールバック地獄 vs. Async vs. Highland | POSTD
  • 非同期プログラミングの難しさとScalaのFuture

    Toshiyuki Takahashi @tototoshi @edvakf 2つめはFuture[Either[E,T]] 派というかモナドトランスフォーマー派だと思いました。この場合はEitherTじゃなくてOptionT使うと思います。 2015-03-26 10:30:37 Toshiyuki Takahashi @tototoshi @edvakf Scalaだとモナドトランスフォーマーそんな一般的ではないので普通の人は妥協して、もしくはそういうものとして最初の形にすると思います。最後のやつはIOとして想定しているのがDB以外もある気がしてなんとも言えないですが、よく見るパターンではないです。 2015-03-26 10:32:27 Toshiyuki Takahashi @tototoshi @edvakf あと別の話で、asyncなドライバー使ってない限りJDBCはブロックす

    非同期プログラミングの難しさとScalaのFuture
  • 幸せな非同期処理ライフを満喫するための基礎から応用まで - Qiita

    クライアントアプリにとって、マルチスレッドプログラミングは避けては通れない重要な概念です。しかし、気をつけないとハマるポイントも多く、初めてクライアントアプリを学ぶ人たちからすると、複雑で難解な取っつきづらいものでもあります。ここでは、スレッドの基から、効率的な使い方、また複雑化しやすいポイントをシンプルに実装するためのノウハウを見ていきます。 TL;DR スレッドの取り扱い方を知る Threadをそのまま使わず、AsyncTaskやIntentService、時にThreadPoolExecutorを使ってスレッドの使い方を効率化する。 複雑な処理フローをシンプルに扱うためのフレームワークを導入する PromiseやRxAndroidなどで、複雑化しやすいポイントを整理する。 スレッドの基 スレッドといえば、ThreadクラスやRunnableクラスがベースにあります。以下のようにす

    幸せな非同期処理ライフを満喫するための基礎から応用まで - Qiita
  • ES7 の Async/Await を使ってみた - Qiita

    Taming the asynchronous beast with ES7 babel の experimental に ES7 の Async/Await が入ったというので、さっそく導入してみた。対象は画像を点字を変換するわりかしどうでも良いモジュール。 seurat - JavaScript utility to generate a braille text from an image 導入前 ファイル読み込みや画像の変換に非同期処理を多用しており、node.js スタイルの 非同期API(コールバックを渡すやつ) を prominence というユーティリティ関数で Promise 化していたが、行ごとに then が出てきたり、複数の値を渡すために Promise.all を使ったりと、あまり読みやすいとは言えないコードだった。(コールバック地獄になるよりはマシだと思うけど.

    ES7 の Async/Await を使ってみた - Qiita
  • 比較:並行処理 - Java とScala とGo - | TECHSCORE BLOG | TECHSCORE BLOG

    こんにちは、馬場です。 完全に出遅れていますが、個人的に触ってみたかったGo言語と戯れてみたいと思います。Go 言語といえば並行処理ですよね。せっかくですので、他の言語Java 8 / Scala 2.11 と比較しながら見ていきたいと思います。 お題:二分探索木を比較する。 並行処理のお題は、超充実しているGo 言語のチュートリアルTour of Goのエクササイズ、Equivalent Binary Tree です。 二分探索木とは、子の数が最大2である二分木で、「あるノードの左の子およびその全ての子孫ノードの持つ値はそのノードの値より小さく、右の子及びその全ての子孫ノードの持つ値はそのノードの値より大きくなるように構成した」もの(Wikipedia)です。 2つの二分木が、形はちがえど同じ値を保持している場合があります。そのために、 1. 二分探索木を生成し、 2. 2つの二分木の解

  • 【Akka入門の入門】Part.1 メッセージを送る | Scala Tech Blog

    初めまして、新卒の増田と申します(^o^) 入社後はJavaを使っていて、チームを異動して初めてScalaを触り始めた・・・ という頃に、Akkaというフレームワークを使うので勉強するように言われました(^o^;) まず入門書を買おうとしたのですが、日語のがない・・・(T_T) ドキュメントも英語だし何書いてあるのかさっぱりわからない・・・(T_T) Scalaも始めたばっかでよくわからない・・・(T_T) という状況だったので、英語でもドキュメントより入門書の方がまだ理解できるかも・・・と思い『Developing an Akka Edge』というを購入しました。 そのを読みながら、ドキュメントを読みながら、先輩に聞いたり調べながらAkkaについて勉強したことをスライドにまとめました! ただとても長いので、このブログでは簡潔なまとめ+説明のための簡単なコードを書いていきます(^o

  • マルチスレッドプログラミングのFutureパターン – ザワプロ!

    マルチスレッドプログラミングのパターンの一つにFutureパターンというものがある。 これは、ある処理を別スレッドで非同期に実行させて、その結果を受けたいときに用いられるパターンである。 特徴的なのは、処理の実行担当者(JavaではExecutorServiceがそれにあたる)は、処理(JavaではCallable)が渡されると別スレッド上で処理を開始して、メインスレッドには即座にFutureオブジェクトを返すことである。 なぜこのオブジェクトがFutureと呼ばれるかというと、今現在はまだ結果を取得できないが、将来のある時点で取得することになるからである。 その後、Futureのget()メソッドを呼ぶと、メインスレッドはCallableの処理が終わるまでブロックされる。 そして別スレッドで処理が終わった時点で結果が取得できる。 プログラム例を以下に示す。 public static v

  • JavaScript Promiseの本

    この書籍はCreative Commons Attribution-NonCommercialの ライセンス で公開されています。 また、PDFとしてレンダリングしたバージョンは以下からダウンロードすることができます。

    JavaScript Promiseの本
  • イベント駆動プログラミングとI/O多重化

    9. 非イベント駆動な ネットワークプログラミング process Client or thread process Client or thread process Client or thread

    イベント駆動プログラミングとI/O多重化