タグ

ブックマーク / jxck.hatenablog.com (9)

  • 2015 年をふりかえる - Block Rockin’ Codes

    Intro 個人的には HTTP2 と ORTC/WebRTC と Service Worker 周りさわって、 JS と Go を書いてる一年だった。 Extensible Web - Progressive Web APP Extensible Web で始まった話が、様々な API の設計に適用された。 結果手に入った Service Worker を始めとする Low Level API を組み合わせて、もう一度モバイルと Web の関係を見直す Progressive Web App まで進み、 Web の形が見直された年だった。 Extensible Web の夜明けと開発者が得た可能性の話 - Block Rockin’ Codes HTTPS また、 HTTPS の重要性の認識が、啓蒙からデプロイまで降りたという印象。そして、待望だった Let's Encrypt がついに

  • Let's Encrypt を支える ACME プロトコル - Block Rockin’ Codes

    Intro 先日 #http2study で mozilla の Richard Barnes が Let's Encrypt について話してくれました。 資料: Let's Encrypt Overview この資料の翻訳 はしたのですが、いらなくなってしまったので供養もかねてこのプロジェクトのモチベーションと、 Web でおこっている HTTPS 推進のたどる道について、資料を補足しつつ紹介します。 結論から言うと Let's Encrypt はもちろん ACME プロトコル についても是非知っておくと良いと思います。 HTTPS の問題 すでにこのブログでも紹介しているように、 Web における HTTPS の重要性は増し、それの普及を後押しする活動が各所で進められています。 HTTPS 化する Web をどう考えるか よく言われる盗聴防止を始め、暗号化を行うことで防げる問題は多くあ

    Let's Encrypt を支える ACME プロトコル - Block Rockin’ Codes
  • 次世代 Web カンファレンスを開催しました #nextwebconf - Block Rockin’ Codes

    intro 次世代 Web カンファレンスを開催しました。 名称: 次世代 Web カンファレンス 日時: 2015/10/18(日) 9:00-17:30 場所: 法政大学外壕校舎 4F 後援: 法政大学情報科学部 参加費: 無料 hashtag: 全体: #nextwebconf 405: #nextwebconf405 406: #nextwebconf406 407: #nextwebconf407 実施概要 概ね開催概要の通りです。 jxck.hatenablog.com やったこと やったことはシンプルです。 テーマ毎に、今 Web がどうなっていて、これからどうなっていくのか をひたすら議論するセッションのみのカンファレンス やらなかったこと 以下はこのカンファレンスではやりませんでした。 スポンサー募集 Tシャツ/ステッカー/チラシ作成 公式サイト作成/ドメイン取得 公式懇

    次世代 Web カンファレンスを開催しました #nextwebconf - Block Rockin’ Codes
    yasuharu519
    yasuharu519 2015/10/22
    面白かったなー!
  • 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

  • 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

    Ajax 誕生から 10 年とこれから - Block Rockin’ Codes
  • Extensible Web を支える低レベル API 群 - Block Rockin’ Codes

    Intro 最近 Extensible Web の話がたまに出るようになりましたが、なんというかレイヤの高い概念(ポエム)的な話が多い気がしてます。 もう少し具体的な API とか、「それコード書く上で何が変わるの?」って話があまりないので、今日はそこにフォーカスして、 Extensible Web 的な流れの中で整理された API の話をします。 しかし、実際には API が 「Extensible Web という理念で生まれたかどうか」は自明ではないので、 今標準化されている低レベルな API を拾い、それを整理するというエントリだと思ってもらと良いかもしれません。 あまり知られてない API もあると思うので、これを期に「これがあれば、今までできなかったアレが、標準化や実装を待たなくても、できるようになるな」と思ったら是非書いてみると良いと思います。 実際はそれこそが Extensi

    yasuharu519
    yasuharu519 2015/02/09
    いいまとめ
  • Extensible Web の夜明けと開発者が得た可能性の話 - Block Rockin’ Codes

    Web based on Standards Web は誰のものでもありません。 だれかプロダクトオーナーがいてその人が意思決定するとか、そういうのとは真逆の成り立ちをしています。 標準的な仕様を決めて、その仕様に則って Web の世界は成り立っている。 政府が作るサイトも、 Twitter も、学生が作ったブログも、全部同じルールで作られている。だから繋がる。 これって結構凄いことだと、自分は思っています。 Standarization このルールの決め方にもルールがあって、ちょっと敷居は高いかもしれないけど、誰でも自由に参加して、自由に意見を述べることができる場があります。 標準化団体ってやつですね。 なんか一部の人たちが勝手にやっているように思えるかもしれないけど、それは選挙に行かない人の理論と同じです。 あなたが仕様について意見を持ってて、それが妥当であるならば、その発言は仕様を根

  • Golang Error Handling lesson by Rob Pike - Block Rockin’ Codes

    Intro この記事は Go Advent Calendar 2014 の 15 日目の記事です。 例えばネットワークのフレーム処理的なものを書いている場合、以下のようなコードがよくでてきます。 There are many codes like this, while writing a Network Frame Parser program. var type uint8 err = binary.Read(r, binary.BigEndian, &type) if err != nil { return err } var length uint32 err = binary.Read(r, binary.BigEndian, &length) if err != nil { return err } ... 関数の中では、各要素の長さ毎に読み込んで、読み込みに失敗したらエラーを

    Golang Error Handling lesson by Rob Pike - Block Rockin’ Codes
    yasuharu519
    yasuharu519 2014/12/16
    Err処理について
  • 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

    Go の interface 設計 - Block Rockin’ Codes
    yasuharu519
    yasuharu519 2014/08/10
    設計
  • 1