正月休み明けの話を今頃はてなダイアリーに書くのも何ですが、開始時にここで紹介しましたので終了についても書きます。 本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう http://kmaebashi.com/programmer/webserver/index.html 1年半ほどかかりましたが、一応完結いたしました。1年半のうち1年ほどは放置状態でしたけれども。 上記のリンクを見ていただければわかるように、この記事は、以下のような構成になっています。 TCPサーバ/クライアントを作る Webサーバを作る 落ち穂拾い(その1) 落ち穂拾い(その2) POSTメソッド へなちょこサーブレットコンテナもどき「Henacat」を作る Cookieに対応する セッションに対応する 最初は簡易的なWebサーバを作っていますが、最終的にはへなちょこなサーブレットコンテナHenac
Help us understand the problem. What is going on with this article? 仕事で Golang を使ってウェブアプリを作ることになりそうなので、どんな構成がいいのか考えてみる。あくまで前提ありきの選択なので、何でもかんでも適用できるわけではない。 JS や静的ファイル部分は今のところ考慮していない。単によく知らないので。 突っ込み大歓迎です。これいいよ！とか教えてください 前提 多機能なフレームワークよりシンプルなフレームワークに色々組み合わせる方法をとりたい。 開発者は数名程度。Golang に精通している開発者が 1 名いる。残りはこれから。 開発者は Django での開発経験が豊富な人が多い 全員ウェブ開発経験はそれなりに積んでいる。 HTML と JSON 両方のパターンが存在するのでテンプレートエンジンは重要。 JS
最近H2OというHTTPサーバを書いているのですが、プロファイルを取ってみるとsprintfが結構な時間を食っていて不満に感じていました。実際、sprintfは数値や文字列をフォーマットするのに十徳ナイフ的に便利なので、HTTPサーバに限らず良く使われる（そしてCPU時間を消費しがちな）関数です。 では、sprintfを最適化すれば、様々なプログラムが より高速に動作するようになるのではないでしょうか。ということで作ったのが、qrintfです。 qrintfは、Cプリプロセッサのラッパーとしてソースコードに含まれるsprintfの呼出フォーマットを解析し、フォーマットにあわせたコードに書き換えることで、sprintfを高速化します。 たとえば、以下のようなIPv4アドレスを文字列化するコード片を sprintf( buf, "%d.%d.%d.%d", (addr >> 24) & 0xf
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに マーティンファウラーがmicroservicesの記事で、小さな役割をもったサービス群にアプリケーションを分割することを提案しています。 cookpadが、サービスをマイクロサービス群に分割していることの記事が注目を浴びており、最近急速にバズワード化しているように感じます。 バズワード化して、ポイントが損なわれる前にいくつかの注意点をまとめておきます。 1.インフラコストは基本的に増大する microservicesは、今まで単一のアプリケーションコードで行われていたことを複数のサービスサーバーに分割して管理・運営していくこと
13. Over The Top 手段の例 市場 ユーザ メリット 事業者 メリット 利用方法 Skype, WebEx (YouTube, Ustream) キャリアに縛られない独自の仕組みを 提供する少数のベンダーが参加可能 世界中の人と無料/安価で会話できる 限定的なAPI提供 一部連携可能 ユーザが組み合わせて利用 http://www.slideshare.net/mganeko/2013-web-rtctechcross/6 より改変して引用 15. キャリア型通信 Over The Top Webブラウザ型 手段の例 市場 ユーザ メリット 事業者 メリット 利用方法 固定電話 携帯電話 (TV放送) Skype, WebEx (Youtube, Ustream) WebRTC インフラを持つ キャリアが支配 キャリアに縛られない 独自の仕組みを提供 する少数のベンダー が参
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
