オンラインゲームの仕組みや工夫を調べてみたのを社内勉強会で発表した。ときのスライド。の公開用。 オンラインゲームの種別とそれぞれの仕組みについての話と、オープンソースになっているQuakeの仕組みの話、という2つの話が主なトピックRead less
![オンラインゲームの仕組みと工夫](https://cdn-ak-scissors.b.st-hatena.com/image/square/8590107b57530397bf9e52c9193831484ff98d27/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fonline-game-150520141452-lva1-app6891-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Stay organized with collections Save and categorize content based on your preferences. We want to help you build beautiful, accessible, fast, and secure websites that work cross-browser, and for all of your users. This site is our home for content to help you on that journey, written by members of the Chrome team, and external experts.
Chrome Dev Summit に初参加しました!色々トピックとして気になったものを紹介してます。後直接 Addy Osmani とか Paul Irish とかに聞く機会があったので、色々ついでに聞いてきました。 Chrome DevRel teams create a Chrome cake #ChromeDevSummit [pic.twitter.com/5u6VPZ0oHb](http://pic.twitter.com/5u6VPZ0oHb)— Yosuke FURUKAWA (@yosuke_furukawa) November 12, 2018 Chrome も 10 周年なんですよねー。感慨深い。 1日目は「現在のChromeでできること、やってること」という感じで、ケーススタディやツールチェインの話が多めでした。 2日目は「未来のChromeでできること、今後やるべ
公式サイト:http://plasma.io/ Whitepaper:http://plasma.io/plasma.pdf Plasmaの概要 Vitalik ButerinとJoseph Poonが発表した、スマートコントラクトを実行する際のプロセスをスケーラブルなものにするためにプロセスを大幅に最適化するものです。これにより取引手数料の圧倒的な低下も見込まれます。またWhitepaperでは、数十億tpsまで拡張する潜在能力があると述べられています。 子チェーン、そしてまたその下に子チェーン…といったようにツリー状にブロックチェーン(台帳)をつなげ、最終的な結果をrootチェーン(Ethereum)に記録します。 Plasmaの仕組み 概要 Plasmaは子チェーンの使用によってroot chain(Ethereum)のスケーラビリティ問題を解決しようとするものです。概念的にいうと、
HTTP2 時代のサーバサイドアーキテクチャフィードバック - Togetterまとめ のあたりで話していたことのまとめ。 補足 タイトルで「ES6 Modulesってconcatしないと動かないの?」と一部に誤解を与えてしまったようなので補足。ES6 Modulesがブラウザにネイティブ実装されたら、当然concatしなくても動きます。 ここで書きたかったテーマは「ES6 Modules + HTTP/2 + concat無し は ES6 Modules + HTTP/1 + concat と同等の速度で動作するのか」です。 追追記 (2016/01) kazuhoさんはh2oで Cache Aware Server Push という解決策を提案しています。 Jxckによる日本語解説記事: HTTP/2 Push を Service Worker + Cache Aware Server
昨日作った mdbuf が 100000文字を超える場合、遅いときいたので、色々試してみた。 手元で18万のテキストを用意して編集してみた。それなりに重いが、それでもIMEを完全にブロックしてしまうほどでもない。とはいえイライラはする。 innerHTML で挿入にかかる時間を計測してみた結果、自分の手元では markdown 10000文字あたり、1.6ms の遅延。というわけで、体験を損ねない限界は 100000文字辺りが限界だと思う。とはいえ自分は最新モデルのMackbook Pro の中位ぐらいのモデルなので、平均的にはその半分の5万文字ぐらいだろうか。 ただ、画像がある場合には入力の度にリクエストが走ってるような気がするので、それのリサイズも合わさって、あまり良くない気がする。あとでアクセスがキャッシュに閉じてるか確認しておく。 細かい工夫として、IMEの変換中はプレビューの更新
SAN FRANCISCO ー October 9, 2018 ーThe workflows and technologies required for modern web development are undergoing dramatic reinvention. Netlify, a San Francisco based company serving a large base of passionate web developers, has seen the transformation first hand. They've engineered a new platform for the web where content and applications are created directly on a global network, bypassing the
off-the-main-thread は今フロントエンドで熱いテーマの一つです。日本語圏では今ひとつ話題になってないので紹介しておきます。 off-the-main-thread の概念の大まかな概要については、Chrome 開発者の nhiroki さんの日本語の記事があるので、こちらを参照してください。 nhiroki.jp speakerdeck.com ここまでのあらすじ 従来のウェブブラウザーでは、一つの画面につき一つ割り当てられる、UI スレッドと呼ばれる名前空間で様々な処理を行ってきました。DOMセマンティクスの評価, CSS による rendering / painting、JSのScripting…。もちろん裏側ではブラウザが様々なバックグラウンドサービスに処理を委譲し、スレッドで実行され、その非同期な結果を受け取っているわけですが、少なくともUIスレッドで走るJSから
ウェブブラウザにおいてメインスレッドはとても重要なリソースです。なるべくメインスレッドを使える状態にしておくことが滑らかな UI/UX を実現する上で重要になります。しかし、実際には多くの処理が実装上の理由やブラウザ仕様の不足によりメインスレッドでしか動かせないため、メインスレッドは忙しくなりがちです。特にページロード時は JavaScript の実行やリソース読み込みなどでとても忙しくなります。 とあるページの perf プロファイル。メインスレッドでせわしなく処理が行われている様子が分かる。 これを解消するために、ブラウザの処理をメインスレッド以外 (off-the-main-thread) でも実行できるようにする試みが行われています。 1. Off-the-main-thread とは メインスレッド以外のスレッドに処理を委譲することを off-the-main-thread と呼
この例の他にも、onChange={(ev) => handleChange(ev)}などのようにアロー関数を使う例もよく見るかもしれません。こちらはアロー関数式で作られた新しい関数が、呼び出し元のスコープに束縛される特性を使って、thisを束縛しています。 この書き方自体に、シンタックス上の問題があるわけではなく、またReactもエラーを出さずに動作します。では何が問題なのでしょうか。 描画パフォーマンスへのペナルティ 実はこのようにrender関数内で関数を動的に作ってしまうと、reactがコンポーネントをアップデート(再描画)するたびに、新しい関数が作られてしまいます。最初のペナルティは、この実行時における関数の定義と破棄に伴うオーバヘッドです。大きなページで大量のエレメントを同時にアップデートする際などに、無視できない影響が出ます。 もう一つの大きな影響は、Reactが再描画の判断
パフォーマンス改善ハンドブック ウェブページにおけるパフォーマンスに関する問題の見つけ方や考え方の事例をまとめた Webフロントエンド パフォーマンス改善ハンドブックを公開しました。 URL: https://dwango-js.github.io/performance-handbook/ このハンドブックでは過去に行ったWebフロントエンドのパフォーマンス改善の事例を中心に紹介しています。 注意点としてWebフロントエンドは常に変化しているため、現在の最適な解決方法を提案するものではありません。 また、アプリケーションによっても最適な解決方法は異なります。 今回の事例ではViewライブラリにReactを用い、映像再生プレイヤーなどある程度複雑な機能を持ったウェブアプリケーションのWebフロントエンドを扱います。 具体的にはニコニコ生放送(以下「生放送」)で行った事例を中心に書かれていま
builderscon tokyo 2018『Electronによるアプリケーション開発事情2018』
本講演で登壇したのは、株式会社ポケラボの覚張泰幸氏。覚張氏は2013年の入社から、エンジニアとして『戦乱の侍キングダム』や未リリースの新規アクションRPGなどに参画。今回の公演で扱うタイトルの『SINoALICE ―シノアリス―』(以下、『シノアリス』)にも、エンジニアリーダーとして携わっているという。 覚張氏はまず、大きな話題ともなった『シノアリス』リリース当時に発生した連続メンテナンスについて、対応に当たった当事者として説明を行った。 なお、連続メンテナンスの概要はつぎの通りである。『シノアリス』はリリース後間もなく緊急メンテナンスを開始。翌日には一時的にメンテナンスから脱するも、数時間後には再度メンテナンスに入るという状態が1週間も近く続いていた。 覚張氏はこうした当時の様子をより具体的に紹介するため、メンテナンスが行われたスケジュール表を公開。その内容はというと、ほとんどがメンテナ
Update: The Cost Of JavaScript In 2019 is now available to read. Building interactive sites can involve sending JavaScript to your users. Often, too much of it. Have you been on a mobile page that looked like it had loaded only to tap on a link or tried to scroll and nothing happens? Byte-for-byte, JavaScript is still the most expensive resource we send to mobile phones, because it can delay inter
自分のポートフォリオサイトをサンプルに、どのくらいの容量削減ができるのかを確認してみました。 jsおよびCSSは、サイトの表示に必要な要素を1ファイルにバンドルした状態です。 画像ファイルはjpegの圧縮率などによって最終的なサイズが大幅に変化するので、jsとCSSのサイズ変化のみを取り上げました。 Bootstrap + Font Awesomeのような重量級フレームワークを使用しても、十分に実用的な容量まで削減できました。これならスマホ+3G回線での表示も心配ありません。 手法 適用しやすさを順に手法を並べると、以下のようになります。 遅延する 圧縮する キャッシュする まとめて削る 遅延する サイト上にあるほとんどのリソースは、実際には後から読み込んでも問題なく動作します。 まず最小限の構成でサイトを表示させ、重いファイルは後から読み込みます。 javascriptの遅延読み込み h
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く