ポーリング、Ajax、Comet、Server Sent Events、WebSocket サーバPUSH方式の大雑把な比較 Read less
ポーリング、Ajax、Comet、Server Sent Events、WebSocket サーバPUSH方式の大雑把な比較 Read less
2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
こんにちは、技術部の大石です。開発基盤グループで課金システムの担当をしています。 インターネットサービスの決済・課金システムの開発や運用は、サービスの根幹を支えるために正確性と機能性を満たさなくてはなりません。また同時に、価格や料金体系、決済手段のバリエーションでユーザーに利便性を提供する必要もあります。「堅牢性」「信頼性」と「柔軟性」「開発スピード」という相反する要素の両立が求められます。 その結果、決済・課金システムは適切な設計や運用を意識しないと複雑になってしまいがちです。 課金システムの開発、運用でよくある問題 複数の決済方法を同じサービスの上で共存させる難しさ 例えば、最初にクレジットカード決済を導入して、その後にコンビニ決済、キャリア決済やアプリ内決済と決済方法が増えていくことはよくあることです。 最初の導入の際にクレジットカード決済への設計だけでなく、その後に増えていく決済を
2. エンジニアをやっています川田です。Webのパフォーマンス関連のことで、いろいろと活動しています ウェブエンジニア ・Software Design(技術評論社) 2014年5-7月号 「Web標準技術ではじめる Webパフォーマンス改善」 他 ・html5j パフォーマンス部 ・日本Cordovaユーザー会 ・Microsoft MVP (Internet Explorer) ・W3C Web-perf WG 他 ふろしき (川田 寛) Published Community 4年前、とある開発プロジェクトで フロントエンドの性能劣化にかなり苦しめられ 以来、Webのパフォーマンス技術を追っています
ウェブアプリケーションのフロントエンドに関わる方なら、もう Web Components という 言葉を全く聴いたことがない方は少ないのではないでしょか。 すでに関連記事も数多く出回っており、実際に触り始めている方も多いと思います。しか し、なぜこれが革命的技術なのか、周囲の人に簡潔に説明できる方はどれくらいいるで しょうか？この記事では、それを試みていきたいと思います。 デジタル部品の流通革命 # ソフトウェア部品の流通に今、大きな変化が起きてきています。 数年前のオープンソース環境を覚えているでしょうか？レポジトリは集中管理型の subversion、リリースは zip、テストは手動。Issue の登録もプロジェクトごとにことな るバグ管理システムが使われていたため、とっつきづらかったでしょうし、パッチを送る のも面倒でした。 そんなオープンソースを取り巻く環境が、git や GitH
正月休み明けの話を今頃はてなダイアリーに書くのも何ですが、開始時にここで紹介しましたので終了についても書きます。 本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう http://kmaebashi.com/programmer/webserver/index.html 1年半ほどかかりましたが、一応完結いたしました。1年半のうち1年ほどは放置状態でしたけれども。 上記のリンクを見ていただければわかるように、この記事は、以下のような構成になっています。 TCPサーバ/クライアントを作る Webサーバを作る 落ち穂拾い(その1) 落ち穂拾い(その2) POSTメソッド へなちょこサーブレットコンテナもどき「Henacat」を作る Cookieに対応する セッションに対応する 最初は簡易的なWebサーバを作っていますが、最終的にはへなちょこなサーブレットコンテナHenac
ブラウザでの Javascript の高速化と Backbone や Angular のような JavascriptMVC フレームワークの登場により、以前より SPA（Single page application）が構築しやすくなりました。 さらに、Yeoman に代表される SPA を作成するするための scaffold（土台）が整備されてきましたので、結構さくっと SPA が作れるようになったのも事実です。 さくっと作った SPA がさくさく動かない・・・作ったけど使えない・・・なんてことにならないように、SPA を構築する前に知っておいた方がいい課題について調べてたり考えてみました。 目次 1. パフォーマンス 2. メモリリーク 3. セキュリティ 4. フレームワークロックイン 5. 画面設計から UI コンポーネント設計への思想転換 6. フロントエンジニア不足 7. 番外
Pelletkachels waren ooit eenvoudige apparaten voor verwarming, maar ze hebben een opmerkelijke evolutie doorgemaakt sinds hun bescheiden begin in de jaren ’80 van de vorige eeuw. In dit artikel duiken we diep in de geschiedenis van pelletkachel, bespreken we de belangrijkste mijlpalen en ontwikkelingen op het gebied van subsidiemogelijkheden en werpen we een blik op de transformatie tot moderne en
はじめに この話はGuillermo Rauch氏が書いたhttp://rauchg.com/2014/7-principles-of-rich-web-applications/ という記事の翻訳です。許可を得て翻訳しています。 ここ最近Web業界を賑わしているSingle Page Applicationの必要性、HTTP2/SPDYといった技術、リアクティブプログラミングやIsomorphicデザインという考え方について包括的にまとめたすごく良い記事になっております。 最初に断っておきますが、ものすごく長いです。各セクションがわかれているので時間がない方はセクションごとに書かれたtl;DRとまとめを読むだけでも参考になるかと思います。 ちなみに明日のNode学園祭には、本記事を記述したGuillermo Rauch氏が見えるので、そこで詳しく聞いてみるのもいいのではないでしょうか。
製品やサービスが顧客の継続的・習慣的な支持を得るためのしくみについて解説した理論書「Hooked」。 その日本語版出版を記念して、著者のニール・イヤール氏と、翻訳を監修した弊社代表の金山によるセミナーが先日行われた。 今記事では、その中でニール氏が語った『使われ続けるサービスに必要なこと』をお伝えしたいと思います。 「hooked」モデルとは Facebook、Twitter、LINE。 これらのサービスにはある共通点があります。 それは、顧客に"習慣"を提供するのに成功していること。 私達が、これらのサービスのサイトやアプリを立ち上げるのは、"何となく"という場合が多いのではないでしょうか？ そして、我々サービス提供者は、その"何となく"、つまり”習慣”を欲してやまない訳ですが、ニール氏はそれらのサービスを調査し、それをスタンフォードのマスターで教える中で、それらのサービスの"習慣"形成
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
This document discusses the memory usage of Perl-based web applications running in a multi-process prefork model with MaxRequestsPerChild configuration. It notes that this model ensures memory is reliably freed when processes exit after fulfilling a set number of requests. It allows for temporary large memory allocations or memory leaks to be tolerated. The operator needs to monitor for irregular
しょっちゅう必要になるので、メモ書き程度に 参考にしたのは、以下の URL です。 Apache Webサイトのメンテナンス中画面を出す正しい作法と.htaccessの書き方 | Web担当者Forum Nginx nginx: Create HTTP 503 Maintenance Custom Page nginxで特定ホスト以外からのアクセスをメンテナンス画面にする方法 (2) – (ひ)メモ Nginxでrestart, reloadをすることなくメンテナンス画面に切り替える – Qiita 前提としてメンテナンス中画面として表示する際に使用する html は以下のファイルを使うものとします。 maintenance.html style.css /img/corp_logo.png また、以下の IP アドレスからのアクセスは管理者からなのでメンテナンス中画面を表示しないものとし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
