Go の Generator を channel と closure で速度比較(または Go でのアトミック処理イディオム) - Block Rockin’ Codes
追記 この記事は元々 Go のイディオムとして、いわゆるジェネレータの実装がどうできるのかを軽い気持ちで書いただけで、速いから「Closure を使いましょう」などと一言も言ってなかったのですが、一方が channel であったため原子性についての言及がいくつかありました。 自分としては、ローカルのちょっとしたツール(shell の代わりくらい) の中で使ってただけなので、並行性には言及するつもりがそもそも無かったのですが、自分もそうした前提を書いていなかったのにも原因があります。 例えばこの記事が「グローバルシーケンス」の実装例として参考にされ Web アプリにでもコピペされて、バグの原因になったりでもしたらマズイので大幅に追記します。 (正直ロックを使った排他制御はあまり得意では無いですが。。) Intro 無限に連番を生成するロジックをジェネレータとして組むときに、 Go の場合は二
ORTC が切り開く SVC サイマルキャストと WebRTC NV - Block Rockin’ Codes
intro 「ORTC って WebRTC がちょっと便利になるくらいなんでしょ？」くらいに思っている人が結構いるようだったので、現時点で予想される ORTC のもつ可能性 と、現状の WebRTC の問題点、そして WebRTC がこれからどうなっていきそうかについて、自分の理解している範囲で書いてみます。 ORTC については、ほとんど実装が無く(と書いてる間に Edge に入っちゃったんですが)まだドラフトやそこにある Example、 ML での議論などの公開情報を元に書いてるだけなので、間違っているものや、将来変わるところも有ると思います。よって内容は一切保証しません。 また、何か自分の理解がおかしいところなど有った場合は、コメントなどで指摘頂けると幸いです。 低レベル API 化へ WebRTC は少なからず「ブラウザで P2P テレビ会議」をするというユースケースを中心として
「次世代 Web カンファレンス」を開催します #nextwebconf
Intro 2015/10/18(日) に、「次世代 Web カンファレンス」を開催します。 名称: 次世代 Web カンファレンス 日時: 2015/10/18(日) 場所: 法政大学 hash: #nextwebconf 公式: connpass 参加費: 無料 Motivation 「Web について話す場」 というか「Web そのものをテーマにした場」というのが、意外と少ないなとずっと思っていました。 (もちろん、結果として Web について話しているカンファレンスや勉強会はたくさんありますが。) そして、スライドなどを用いて何かを「発表する」ニュアンスではなく、進化の早い Web で「今何が起こっているか？」と「これからどうなっていくのか？」という、答えの無いもの、でもみんなが気になり考えていること、今だからこそ考えないといけないことを真っ向から議論する場というのが、もっとあって
HTTP2 時代のサーバサイドアーキテクチャ考察 - Block Rockin’ Codes
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
Block Rockin’ Codes
新しい技術などを自分で色々試せるように、自分のドメインの、自分で作ったブログに移行しました。 ここの記事も、いくつかはアップデートがてら移行していく予定です。 あたらしいブログは以下です。 ということで Blog を移転しました。 / “Blog を移転しました | https://t.co/c3DSoNCwFc” https://t.co/CHoKkYm6RW— Jxck (@Jxck_) 2016年2月15日 よろしくお願いします。 Intro 個人的には HTTP2 と ORTC/WebRTC と Service Worker 周りさわって、 JS と Go を書いてる一年だった。 Extensible Web - Progressive Web APP Extensible Web で始まった話が、様々な API の設計に適用された。 結果手に入った Service Worker
Go のスライスの内部実装 - Block Rockin’ Codes
History 14/05/09: Merge2 を修正しました。http://twitter.com/jbking/status/464659353945911297 Intro Go のスライスは、いわゆる LL 系の言語が持つ可変長配列の実装と似ています。 よって LL のような手軽な扱いをすることもできますが、その内部実装を知ることでより効率の良いメモリハンドリングができ、パフォーマンスを改善や、メモリーリークの防止などに繋がる可能性があります。 この辺は SWrap というライブラリを作りながら勉強したので、今回は、この Go のスライスの内部実装を解説します。 Go の配列 スライスを知るためには、まず配列について知っておく必要があります。 Go の配列は固定長のため、以下のように長さを指定して宣言します。 var arr [4]int func main() { arr =
Fetch API 解説、または Web において "Fetch する" とは何か？ - Block Rockin’ Codes
Update [14/11/11]: Chromium での実装が M40 からあるそうなので、末尾に引用追記させていただきました。 [14/11/12]: この記事を書くにあたって、色々なかたにレビューや助言を頂いたのですが、謝辞などが一切抜けてました、本当にすいません。追記しました、ご協力頂いた方々本当にありがとうございました。 WHATGW Fetch Spec WHATWG のメンテナンスするドラフトに Fetch Spec が追加されました。 もうすでに日本語訳もあります、すばらしい。Fetch Standard 日本語訳 この仕様には二つのことが定義されています。 "Fetching": Fetch するとは何か? の定義 "Fetch API": fetch() の定義 後者の定義に基づく fetch() という DOM API の実装も始まっています。(詳細は後述) しかし
ジェネレータの解説と非同期への適用 - Block Rockin’ Codes
update 2014-01-16 ご指摘頂いたので修正しました。ありがとうございます！ @Jxck_ 動画すごくわかりやすかった！一個、重箱の隅っこなんだけど、convert関数のapplyしてるところ、fn.apply(fn, args) になってるけど fn.apply(this, args) が正しい気がしました！— Kazuhito Hokamura (@hokaccha) 2014, 1月 13 https://gist.github.com/Jxck/8380852 は修正済みです。動画の取り直しは勘弁して下さい(汗 - fn.apply(fn, args); + fn.apply(this, args); intro あけましておめでとうございます。 今年からはてなブログへ移行しました。 去年末くらいから流行っている Express の後継 Koa では JS の新機能ジェ
markdown のリアルタイムレンダリングツール markup をリリースしました - Block Rockin’ Codes
intro 最近は Readme やら執筆原稿などで markdown を使うことが結構多かったりします。 markdown をレンダリングするツールは色々あるんですが、 エディタは好きなものを使いたいので、自分でレンダリングして、 ブラウザで確認できる何かがあればいいなぁと思ってました。 そんな時、 Github が markdown のレンダリングを API としてやっていたことを知りました。 Markdown | GitHub API しかも、サーバから叩くぶんには認証などもなく、 5000 回/時も叩けるということで、 それを使ってリアルタイムにレンダリングするツールを作りました。 使い方 インストールは $ npm install markup $ markup readme.md [3000]これだけです。 流行りに乗っかって?、ググラビリティの低い名前でリリースしてます。 m
WebSocket サーバの実装とプロトコル解説 - Block Rockin’ Codes
intro なんだかんだ WebSocket を使ってるのに、 WebSocket サーバを自分で書いたことが無かったので、RFC も落ち着いてきたここらで、仕様を読みながら実装してみようと思いました。 "WebSocket サーバ 実装" とかでググると、 Socket.IO とか pywebsocket で WebSocket アプリ作って、「WebSocket サーバを実装」みたいなタイトルになってることが多いみたいですが、 (Apache に PHP で HelloWorld して、「HTTP サーバ実装しました」とは言わないよね。) この記事では、 WebSocket プロトコルをしゃべるサーバ自体を実装します。 といっても、全部やるのはちょっと大変だったので、基本的なテキストメッセージのやりとりの部分だけやって、エコーサーバができるところまでやりました。 完成版のソースは以下で
クライアントとサーバの両方で使える JS コードの書き方 - Block Rockin’ Codes
追記 11/12/25 Bi ってそんなに一般的ではない、 Both-Sides JavaScript の方が、ということでまた変更しました。(side でなく side's') 11/12/04 Both Side JavaScript は変ということで、 BSJS=Bi-Side JavaScript に変更しました。 本文 CSJS と SSJS で両方同じ言語で処理が書けるメリットの 1 つとして、 書いた処理の共有があげられます。 (そこにメリットを感じない人もいるかも知れませんが。) 例えば Validater を共有 クライアントの状態をサーバで再現 などがあります。前者はそのままですね。 受け取った入力のバリデーションはサーバでは必須で、フィードバックを速くするためにクライアントでも同じように行う場合があります。 今まではサーバで書いたバリデーションと同等のものを JS に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
