2014年6月にHTTP/2の13番目のドラフトが公開され、来年にはRFC化の見通しとのことでHTTP/2の機運が高まってきています。 HTTP/2の世界を体感すべく、HTTP/2プロトコルでHello World!を表示するまでの手順をまとめました。 最速と名をうちましたが実のところそこそこ長い道のりですので予めご了承ください。 方針 簡単と思われる方法を探した結果、以下の構成にしました。 クライアント 2014年7月現在、Google ChromeではHTTP/2を有効にすることはできませんが、Chromeの開発版であるChrome Canaryを使えばHTTP/2を有効できます。 Mac Book ProにChrome Canaryをインストールします。CanaryはChromeの開発版でMac用のdmgパッケージが提供されているのでインストールは簡単です。 なお、クライアントはng

トーク採択していただきました。インフラエンジニア(狭義)は死んだ ソーシャルメディアでの拡散などしてくださった皆様有難うございます！！！１ 初日の朝イチでだいぶ早いですが、早起きしてお越しいただけると大変うれしいです。 2014-08-29 10:20:00 に 慶應義塾日吉キャンパス内 協生館 2F 多目的教室2 でお待ちしております。よろしくお願い致します。

以下のトークが採択されました。2日目の藤原洋記念ホールにて、15:20からです。 Mobile First Development for Perl Mongers 最近はPerlはあまりやっていないのですが、サーバーサイドとクライアントサイド（モバイルアプリ）をいい感じに協調して働くための仕組みを考えたりしています。YAPC::Asiaにくるエンジニアはサーバーサイドの方が多いと思うので、そういう方たちにとって面白い話ができたらいいなと思っています。 ところで、このトークは ninjinkun といっしょにやります。トークの内容が似た感じなので合体してみたのですが、せっかくだから2人でお互いの状況を話つつ、モバイルアプリ開発やサーバーサイドとの連携についてディスカッションしようと思います。

Nothing is perfect from the beginning. We want to support the growth of documents from hatching to completion. 最初から完璧なものなんてない。 esaは情報の一生を見守りたい。

_ スパイスライフで働くエンジニアが嬉しく思っている9つのこと スパイスライフに入社してから半年ほどが経ち、私が入った当時2人(邦明率100%の頃)だったエンジニアも現在社員だけで7人、フリーランスの方をあわせて9人にまで増えました。 どうやって集まったのかを考えてみると、Rails寺子屋や邦明.rbなどのなんらかのコミュニティ活動で知り合った人がほとんどです。エンジニアの採用が難しいこの時代にいい人達に集まってもらえて、コミュニティへの感謝の想いは強まるばかりです。かつては私がコミュニティに育ててもらっていたのが、今はひっぱる側として、人の成長を通じてコミュニティに貢献できていると良いなと思っています（もちろん、私も今でも成長させてもらっています）。 さて、スパイスライフのエンジニアはどのような生態で生息しているのでしょうか。部長の職権を振りかざして「エンジニアの働き易い環境つくり」を進

design_menter.md エンジニア向けデザインメンター（謎）をはじめて、2〜3ヶ月が経ちました @ken_c_lo in 町田の部屋 新年会 2014-03-30 何やるの？ 実際のプロジェクトに入って、エンジニアのデザイン業を支援する デザインといっても広義。（案件のフェーズや人によってそれぞれ違うことやってる） HTML CSS ビジュアルデザイン UI設計 仕様設計 ユーザーフローの設計 プロジェクトの価値の定義、コンセプトメイキング コンサルティング 等… 「考え方から伝える」というのを大切にして、気をつけてる 週1MTG 2時間前後 受託案件の場合、お客さんも含めMTG 宿題で次週の話すテーマを用意してくる MTG以外は、GitHub Issueでやりとり 基本、コーディングはしない けど、エンジニアが書いたSassとかマークアップとか直してプルリクエストすることはある

クラウドサービスバンザイ！ ハードウェアの置き場要らないし、資産管理もほとんどいらないし。 負荷急増にもすぐ対応できるし、サーバー納品待ちとかないし。 「このロット、ハズレだなー」、とかないし。 Saasレベルののもに至っては、ほんとに「１ライセンス月いくら」しか気にしなくて良いからなー。 いいよのなかになったもんだー。 情報システムに資金を回しにくい非IT系ベンチャーにとっても、非常に嬉しい時代になりました。 そして、ふと沸き起こるトラブル 情シスがサーバーを手放して、Iaasを活用した。 情シスが開発を手放して、Paas・Saasに乗っかった。 そして残ったのは、ほんとに低層の「ネットワーク」の部分。 情シスが呼び出されるトラブルの多くが「ネットワークが繋がらない、遅い」という問題に。 そんなに複雑な構成を組んでいない、設定すべき情報もほとんどないネットワークで、トラブルが起こります。

intro SPDY の Server Push については以前にも書きましたのでそちらをご参照下さい。 SPDY と WebSocket の基礎と SPDY の Push - Block Rockin’ Codes 上記記事ではサンプルの実装に node-spdy を用いましたが、更なる検証のために他の実装を調べました。 主な SPDY 実装で、 Server Push を実装しているサーバは、把握してる範囲では以下のような状況です。 Apache mod_spdy (対応) Jetty (対応) node-spdy (対応) Nginx (非対応) 今回は Server Push の検証のために、 Apache mod_spdy でこの機能を有効にする方法を調べました。 Apache mod_spdy 名前の通り、 Apache HTTP Server を SPDY 対応させるためのモ

Java最新版のJava SE 8 Update 11とJava SE 7 Update 65では極めて深刻な脆弱性が修正された。 米Oracleは7月15日、Javaやデータベースなど同社製品の脆弱性をまとめて修正する定例の「クリティカルパッチアップデート」（CPU）を公開した。特にJavaには極めて深刻な脆弱性が存在することから、できるだけ早くアップデートを適用するよう呼びかけている。 同社のセキュリティ情報によると、今回のCPUでは計113件の脆弱性に対処した。このうち20件をJava SEの脆弱性が占める。20件とも、ネットワークを介して認証を経ることなくリモートから悪用される恐れがあるといい、共通指標のCVSSで最高値の「10.0」に該当する極めて深刻な脆弱性も含まれる。 これら脆弱性は、最新版のJava SE 8 Update 11（Java SE 8u11）と、Java SE

UNIX domain socket 通信は同一マシン上のプロセス間通信にしか使えないというデメリットがありますが，tcp 通信よりも圧倒的にパフォーマンスが良いので要求仕様的に使わなければならない局面は多いと思います 今回はフロントに Nginx で proxy して同一マシン上の別プロセスで動いているアプリケーションサーバーに対して UNIX domain socket 通信を行う構成で実際のアプリケーションサーバーに流れている通信を見たい時にどうするか書きます 実際にトラブルが起こった時に実際にどのような通信が流れているのかは tcp 通信なら tcpdump をすれば見れますが，UNIX domain socket 通信の場合は容易に見ることが出来ないので実際のアプリケーションサーバーにどのような通信が流れているのか分かりません しかしアプリケーションサーバーにどのような通信が流れ

データセンター内のサーバ設定やアプリケーションのデプロイなどの自動化ツールとして知られるChefが、Dockerに対応した「Chef Container 0.2.0（beta）」を発表しました。 DockerはLinuxコンテナ技術の1つとして軽量な仮想環境を実現し、分散アプリケーションを迅速にデプロイするなどの用途で広く使われようとしています。Dockerには、Dockerの構成を記述するためのDockerファイルがありますが、分散環境に適した自動化された構成手法が望まれており、現在さまざまな技術が登場しつつあります。 ChefがDockerに対応することで、既存のRecipeやCookbookといった構成ファイルをDockerの環境にも適用できるようになるため、管理者はこれまでの環境をDockerによるLinuxコンテナ環境へと移行しやすくなるでしょう。 Docker内で動作するChe

Go はネットワークアプリケーションを手軽に書ける言語ですが、例えば 80 番ポートなど、 root でしか bind できないアドレスを Listen するアプリケーションを、 root でないユーザーで動かすのは地味に面倒です。 普通はソケットを bind してから setuid/setgid するのですが、 Linux では setuid が呼び出したスレッドしか適用されないという問題があり、 Go との相性が悪いからです。 参考 対処方法として、 Linux では capabilities を使って非 root ユーザーでも 1024 番以下を bind できるようにし、 Mac OS X などでは bind してから setuid するようにする。 先に root で bind したソケットを Go のプログラムに渡す。 2番めの方法を使うサンプルプログラムを書いておきます. $

port 80を開くためにはroot権限が必要だが、開いたあとはセキュリティーリスクを最小限にするために一般ユーザ権限に降格したい、というWebサーバをGoで書く例です。 【追記3】 下記の例ではLinuxで動作させた場合に不十分です。 Linuxではsetuidを呼び出したスレッドにしか効かないので、以下の例をそのままLinuxで動かすとsyscall.Setuid()は成功しますが、HTTPのHandlerでは別スレッドで動くことがあるため、rootのままで動作することになります。 methaneさんのコメントを参照ください rootで起動した状態で":80"をlistenして syscall.Setuid() で一般ユーザになり http.Serve()する package main import ( "net" "net/http" "syscall" "log" ) func m