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 を前進させる手段である
Ajax 誕生から 10 年とこれから - Block Rockin’ Codes
Intro 誕生と言うのが正しいか微妙だけど、多分誕生でいいと思います。 というのも、「Ajax」という名前の出典は以下の記事で、この記事が書かれたのが今日からちょうど 10 年前でした。 Ajax: A New Approach to Web Applications (当時から、 URL が一回変わっている) Web 初めてまだ 10 年たって無いんで、全部見てきたってわけではないですが、個人的にはちょっと思い出深い記事だったりするので、ちょっと振り返ってみます。 Ajax: A New Approach to Web Applications 筆者の Jesse James Garrett 氏は UX のコンサルティング会社である Adaptive Path の創立メンバーの一人で、 UX エンジニアです。 この記事の趣旨は、当時既にあった Google Maps や Gmail、G
なぜ 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
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 =
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 を視野に入れたあたりで、 関連プロジェクト
"リアルタイム Web" に関するプラクティスのアウトプット - Block Rockin’ Codes
追記 11/12/26 MLのスレッドへのリンクが間違っていたので修正。 introduction WebSocket なんかをつかって、従来のステートレスな処理以外に、コネクションを継続するステートフルな処理が可能になりました。 これを利用すると、これまで実装が難しかったリアルタイムな表現を Web に持ち込むことができます。 そして、 WebSocket を用いたプログラムを作成する上で、Node.js と Socket.IO を用いる方法について、 今年はこのブログでも何度か紹介してきました。 今日は今年一年の集大成として、自分が色々試しながら得たリアルタイム Web に関する知識、技術などを、 ここにまとめてアウトプットしたいと思います。 今回お話しするのは、 東京Node学園 3時限目 : ATND で発表した下記内容の抜粋です。 Node Academy | "About Sl
Node におけるスケールアーキテクチャ考察(SSP 編) - Block Rockin’ Codes
＊息抜きがてら書いていたら長くなってしまった。。 ＊当たり前ですが、あくまで個人的な考えです。 ＊ころころ変わるかもしれません。 Node の基本的な知識についての話は色々なところで出始めて、 じゃあこーいう場合はどうするの？ みたいな話が出始めたりもするようになってきた気もします。 正直、自分にもまだ分からないことだらけです。 そもそも自分はそこまでスケールに関するアーキテクチャや、OS の低レイヤに精通しているとは言えないので、 これを期に Node は何が得意で何が不得意なのか、スケールさせるために考えないといけないこと、などを自分なりにまとめて、 ついでに、これまで学んできた周辺のアーキテクチャに関する知識も混ぜて、色々思考実験をしてみたいと思っています。 だから WebSocket にブラウザが対応してないとか、そんな複雑なサーバ群本当に運用できるのかとか、 そういう話は無しに、
require('events').EventEmitter.call(this) の意味 - Block Rockin’ Codes
[修正] コメントで指摘されたように、回答4の訳が間違っていたので訂正しました。 Node の ML に以下のような質問が投稿されました。 What is the meaning of require('events').EventEmitter.call(this) 内容としては。 「以下のようなコードがあったんだけど、これってどういう意味？」 var util = require("util"); var events = require("events"); function MyStream() { // ここの意味がよくわからん、これは `new MyStream` と同じに見えるんだけど違うの？ events.EventEmitter.call(this); } util.inherits(MyStream, events.EventEmitter); var steam =
Node で使える ECMA Script 5 の新機能 - Block Rockin’ Codes
追記 11/9/24 Gistのリンクを本家Wikiに貼ってみました。 11/9/24 log 関数を修正しました。 11/7/10 JSON.stringify の第二引数 replacer について、補足しました。 11/7/14 os0x さんの指摘を反映しました。 String.trimRight、trimLeft は ECMA Script 5 非標準です。 JSON.stringify の第3引数には"\t"などの文字列も渡せます。 JSON.parse の第2引数 reviver について補足しました。 Array.prototype.forEach の第2引数 について補足しました。 "use strict" 時の Object.freeze 等の挙動について補足しました。 「ECMA5 というのはちょっとおかしな略し方」について補足しました。 タイトルを修正しました。(旧
Node におけるスケールアーキテクチャ考察(Scale 編) - Block Rockin’ Codes
[追記] 途中までは Node での複数プロセス起動、プロセス間通信等について書かれていますが、後半は自分が前回の記事 を書くにあたって自分が考えてたことを少し強引に広げて書いた個人的な妄想が多く含まれ、Node におけると言っときながら、後半は Node 関係ない感じになってしまいました。 正直まだ分かっていないことが多いです。変なところをどんどん指摘していただけるとむしろ嬉しいです。 Node におけるスケールアーキテクチャ考察(SSP 編) - Block Rockin’ Codes の続きです。 もともと何となく結論があって書き始めたんですが、書きながら色々調べているうちによくわからなくなりました。 まだまだ調べたらないことがわかったので、とりあえず今わかっているところまで書きます。 結局何がいいたいのかよくわからない感じかもしれないけど、ゴールは SSP のバックエンドの Nod
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
