Go の並行処理 - Block Rockin’ Codes
intro 先日の Go のカンファレンス GoCon で、 Go の並行処理周りについて発表させて頂きました。 Go Conference 2013 spring - connpass 具体的には Goroutine や Channel の話ですが、これらの機能は結構面白くて、いじって遊んでるだけでもわくわくします。 Go の並行処理は、設計方針がわりと特殊だと思うのですが、設計がシンプルなので分かるとそこまで難しくはないです。 (使いこなすのは、経験が必要そうですが) 今回話すにあたって色々調べましたが、発表時間の都合上省いたものもあるし、質疑応答で聞かれて応えられなかったこともあるので、 ここでまとめて置こうと思います。 発表資料 今回の発表資料はこちらです。 このブログの内容は、これをベースにします。 http://jxck.node-ninja.com/slides/gocon-
「次世代 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
HTTPS 化する Web をどう考えるか - Block Rockin’ Codes
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
Go の interface 設計 - Block Rockin’ Codes
history 13/3/31 Tag について追加 intro Go を触ってて interface を用いた設計がまだまだよくわかってなかったので、一旦まとめることにしました。 Go には明示的な継承の機能は無く、 interface も例えば Java のそれとはかなり毛色が違うので、(Class ではなく) Struct の設計に結構癖があると感じます。 Go の interface は言語設計的にもかなり尖っていて、 Go という言語を強く特徴付けていると同時に、 Go 言語自体の開発者たちもこの機能をかなり重要視しています。 例えば、 Go の開発者の一人である Russ Cox 氏によれば Go's interfaces―static, checked at compile time, dynamic when asked for―are, for me, the most
Extensible Web を支える低レベル API 群 - Block Rockin’ Codes
Intro 最近 Extensible Web の話がたまに出るようになりましたが、なんというかレイヤの高い概念(ポエム)的な話が多い気がしてます。 もう少し具体的な API とか、「それコード書く上で何が変わるの？」って話があまりないので、今日はそこにフォーカスして、 Extensible Web 的な流れの中で整理された API の話をします。 しかし、実際には API が 「Extensible Web という理念で生まれたかどうか」は自明ではないので、 今標準化されている低レベルな API を拾い、それを整理するというエントリだと思ってもらと良いかもしれません。 あまり知られてない API もあると思うので、これを期に「これがあれば、今までできなかったアレが、標準化や実装を待たなくても、できるようになるな」と思ったら是非書いてみると良いと思います。 実際はそれこそが Extensi
#HTTP2Study の軌跡 - Block Rockin’ Codes
Intro この記事は HTTP2 アドベントカレンダー 24 日目 の記事です。 HTTP2Study HTTP2 Study は、2013年8月くらいから小さく小さく活動しているコミュニティです。 HTTP2 もまだ HTTP2.0 と呼ばれていた頃で、 Draft でいうと 04 くらいですね(今は 16)。 (ちなみに、現在の仕様では "HTTP2.0" ではなく "HTTP/2" もしくは "HTTP2" が正しい名称です。) 仕様を策定してる HTTPbis としての議論は概ね片付いて、 HTTP2 の仕様は RFC にするための次のステップに移り、もし仕様を覆すような大きな指摘が無ければ、来年の頭にはこのまま RFC として公開されるかもしれないというところまで来ました。 そして今日はこの仕様策定をずっと追いかけてきた HTTP2Study がやってきたことを、簡単にまとめて
「for やめろ」またはイベントループと nextTick() - Block Rockin’ Codes
ものすごく遅レスですが、LLDiver で @esehara さんの LT であった話。 forやめろ、あるいは「繰り返し」という呪縛から逃れるために 簡単に言うと、 1~10 までを出力する方法を複数考えるというもの。 for, while, 再帰, goto etc.. と出て、途中で終わっちゃったので結論はよくわかりませんでしたが、 Node ではどれも使わずにできるな、と思ったのでちょっと例を出してみます。 ちなみに、タイトルでネタバレしている通りイベントループの話です。 そしてよくある「イベントループとは何か」「なぜ止めてはいけないのか」「process.nextTick() とは何か」「setImmediate() と何が違うのか」 などを解説する良い例だったので、書いてるうちに実はそっちがメインの解説となりました。 サンプルの実行結果は Node v0.11.13 です。(書
Web+DB Press vol.82 で Go の特集を書かせて頂きました #wdpress - Block Rockin’ Codes
update 2015/4/20: 技術評論社さんのおかげで、 無料で公開されることになりました！ intro タイトルのとおり、 Web+DB Press の vol.82 に 「はじめての Go」 というタイトルで特集記事を書かせていただきました。 Web+DB press vol.82 届いた。特集で「はじめての Go」を担当させていただきました。 初見ももちろん、「Tour of Go の次」を探していた方の参考になれば幸いです！ #wdpress #golangjp pic.twitter.com/UbUue18wlp— Jxck (@Jxck_) August 20, 2014 WEB+DB PRESS Vol.82 作者: 山口徹,Jxck,佐々木大輔,横路隆,加来純一,山本伶,大平武志,米川健一,坂本登史文,若原祥正,和久田龍,平栗遵宜,伊藤直也,佐藤太一,高橋俊幸,海野弘
Go のスライスでハマッたところ - Block Rockin’ Codes
intro 先日 GoのSliceもヤバイ - Qiita こんな記事をみて、別の挙動だけどスライスの内部を理解しきれていなかった頃のことを思い出した。 結構前に謎に思っていた挙動についての話。 以前この挙動を解説しようと思って、前提として書いたスライスの内部構造の記事が、 Go のスライスの内部実装 だったのですが、そっちを書き終わって満足してしまい、本題を忘れていました。 この挙動は、先のブログで説明した内容がわかっていないと、なかなか理解できないかも。わかってしまえば簡単ですが。 やりたいのは、関数側でスライスを操作したときの呼び出し側での結果。 順を追ってみてみます。 配列を関数内で変更する 関数は値渡しで、配列はそれ自体が値なので、まるっとコピーされます。 以下の例は、戻り値で返さないと、呼出側は変化しません。 package main import ( "log" ) func
ハイパフォーマンス ブラウザネットワーキング書評 - Block Rockin’ Codes
Intro 執筆段階から、 Web で無料閲覧できた High Performance Browser Networking が、紙の本として出版され、その翻訳本が完成したということで、献本を頂きました。 原著には本当にお世話になったし、 HTML5Experts.jp で書いた Make the Web Faster の連載でもよく参考にした本なので、日本語で読めるようになったのは非常にありがたいですね。 本当はレビュアの依頼を頂いたのですが、色々あって他の方に振ったりしてしまったので、せめて全力で書評させていただきます。 やっと献本頂いたイリヤ本ゆっくり読める。日本語で読めるのは素晴らしい。 #http2study pic.twitter.com/Zy00OOy6ve— Jxck (@Jxck_) 2014, 5月 11 Make the Web Faster ところで、 Google
なぜ html の form は PUT / DELETE をサポートしないのか？ - Block Rockin’ Codes
注意 内容については一切保証しません。 ここでは、主に W3C ML での議論や各種仕様などに基づいて書いています。 ここに書かれていることが正しいかどうかは、自身で判断して下さい。 事実としておかしいところなどは、コメントでどんどん指摘して下さい。遠慮はいりません。 ただし、このエントリでは「form が PUT/DELETE をサポートするべきかどうか？」の議論はしません。 「REST の是非」や「PUT/DELETE の意義」についても議論する気はありません。 ここでやっているのは、あくまでもどういった議論の末現状があるのかの調査です。 そうした意見がある場合は、 W3C などに投稿するのが最も有益だと思います。 History 2014/03/29: 公開 2014/03/29: XForm と XHTML の関係を明確化(thanx koichik) 2014/03/29: HT
これからの Web の話をしよう。 (次世代 Web セッション @ CROSS2014) - Block Rockin’ Codes
Update 2014-01-19 振り返り CROSS2014 が無事終了しました。 以下ログです。ビデオは前のセッションとかぶっているので 35 分くらいからが本セッションです。 USTREAM: cross-a (35:00~) Togetter: 次世代 Web セッション #cross2014 Slideshare: next generation web talk cross2014 去年に引き続き、今年もなかなか密度の高い内容になったんじゃないかと思います。 プロトコル編では、普段なかなか表に出てこない方を中心にお呼びして、2013 年から今日までの流れを踏まえつつ、今起こっているプロトコル的な変化を浮き彫りにし、今後の HTTP2.0 の展望や QUIC の持つ意義などを話し合いました。 象徴的なのは「TCP/IP の破壊」などという想定外に振り切った本音に見て取れるかと思
なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏
Engine.IO からみる Socket.IO の今後 - Block Rockin’ Codes
intro この記事は 東京Node学園祭2012 アドベントカレンダー : ATND の 24 日目の記事です。 Socket.IO の 1.0 が、出る出るといって全然出ないので、 やきもきしている方も多いと思います。 しかし、その裏では Engin.IO という、割りと良い感じの ファミリープロジェクトができていて、 ちょうど先日 RealtimeConf でもその話がありました。 これは Socket.IO にも繋がるはなしなので、 今日はその Engine.IO の話をします。 参考はこのへん、 https://github.com/LearnBoost/engine.io https://vimeo.com/52496621 Engine.IO と Socket.IO (と WebSocket.IO) Socket.IO は、 1.0 を視野に入れたあたりで、 関連プロジェクト
WebSocket サーバの実装とプロトコル解説 - Block Rockin’ Codes
intro なんだかんだ WebSocket を使ってるのに、 WebSocket サーバを自分で書いたことが無かったので、RFC も落ち着いてきたここらで、仕様を読みながら実装してみようと思いました。 "WebSocket サーバ 実装" とかでググると、 Socket.IO とか pywebsocket で WebSocket アプリ作って、「WebSocket サーバを実装」みたいなタイトルになってることが多いみたいですが、 (Apache に PHP で HelloWorld して、「HTTP サーバ実装しました」とは言わないよね。) この記事では、 WebSocket プロトコルをしゃべるサーバ自体を実装します。 といっても、全部やるのはちょっと大変だったので、基本的なテキストメッセージのやりとりの部分だけやって、エコーサーバができるところまでやりました。 完成版のソースは以下で
Trigger と Stream ベースの Reactive スタイルについて考える - Block Rockin’ Codes
intro 先日 Meteor について調べて発表するにあたり色々調べたり、そのあと何人かの方々とお話させて頂いた中で、 思うところが出てきたので、アウトプットしたいと思います。 Meteor について発表してきました。 - Block Rockin’ Codes Meteor 以前からも思っていたところもありますが、ちょうどいいので Meteor も対比に出しながら書いてみます。 Reactive Programming @naoya_ito さんも書いてたように、やはり一番大きいのはここだと思います。 Meteor.js - naoyaのはてなダイアリー 簡単に説明すると、 よく Excel に例えられますが、あるセルに他のセルの値を用いた計算式を埋めておくと、 その参照先のデータが変わった時に、式を埋め込んだセルの値も連動して変わるようなあれです。 プログラミングで見るなら、 例えば
Node.js の起動オプション、環境変数、npm start の話 - Block Rockin’ Codes
Node は起動時に色々オプションをつけることができます。 面白いもの、有益なものあるんですが、あまり言及されてないので、 ちょっと紹介してみようかと思ってます。 最後の npm start の話は、それ単体で書いても良いかと思っていたんですが、 関連するし良い機会なので書きます。 そして、オプション周り興味がない方も、Node やってる方は最後の npm start の話だけでも、 読んでいただけるとと思ったりします。(知らない方が多いようなので) ここで紹介している Node のバージョンは v0.7.7 です。しかし v0.6.x あたりでは、 v8 のバージョンが古く、オプションが微妙に違います。そこは v0.6.12 での結果を載せている場合もあります。 -h まあ、とりあえず全ては -h から始まる。ということで、実行すると以下が出ます。 Usage: node [option
Node におけるスケールアーキテクチャ考察(Scale 編) - Block Rockin’ Codes
[追記] 途中までは Node での複数プロセス起動、プロセス間通信等について書かれていますが、後半は自分が前回の記事 を書くにあたって自分が考えてたことを少し強引に広げて書いた個人的な妄想が多く含まれ、Node におけると言っときながら、後半は Node 関係ない感じになってしまいました。 正直まだ分かっていないことが多いです。変なところをどんどん指摘していただけるとむしろ嬉しいです。 Node におけるスケールアーキテクチャ考察(SSP 編) - Block Rockin’ Codes の続きです。 もともと何となく結論があって書き始めたんですが、書きながら色々調べているうちによくわからなくなりました。 まだまだ調べたらないことがわかったので、とりあえず今わかっているところまで書きます。 結局何がいいたいのかよくわからない感じかもしれないけど、ゴールは SSP のバックエンドの Nod
dotCloud で WebSocket - Block Rockin’ Codes
dotCloud が WebSocket に対応したという発表がありました。 dotCloud Announces Native Support for WebSockets | dotCloud Blog dotCloud は多くの言語やミドルウエアに対応していて、 CLI からアプリがデプロイできる PaaS サービスといった感じです。 (Heroku なんかをイメージしてもらうとわかりやすいかも。) 早速、 Node.js + Socket.IO でどんなもんか試してみました。 アカウントは自分は結構前にとったんですが、今ならすぐ取得できるっぽいです。 CLI のインストール 専用の CLI があるのでそれをインストールするところから始めます。 http://docs.dotcloud.com/firststeps/install/ にある通り、 Python の pip で入れます
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
