房総半島にあじさいをゆっくり鑑賞できる場所がありました

先週末、房総半島の大多喜町にある「麻綿原高原(まめんばらこうげん) 妙法生寺 天拝園」へ行ってきました。

6月〜7月は首都圏各地であじさいが咲いていますが、なかなかゆっくり鑑賞とはいかないもの。場所によっては、60分待つような所もあると聞きます。そんな中、今回足を運んだ麻綿原高原は、心行くまであじさいを観賞できる、素晴らしいスポットでした。そんな話を「あじさいの山」「眺望も抜群」そして「交通について」の3点に分けてお話しします。

filmscan933

あじさいの山!

相方と「週末、どこに行こう?」と話していたとき、何気なく房総半島を目指す事になり、そしてたまたまあじさいが咲いているスポットがあると聞いてたどり着いた麻綿原高原。

驚いた事に、お寺の周りはあじさいの山となっていました。

filmscan936

そして、人もそれほどいません。心行くまで、あじさいを鑑賞する事ができます。もちろん、写真撮影にもじっくり取り組む事ができます。あまり深く考えずに、フィルムをあまり持って行かなかった事を少し後悔しました…。

filmscan924

なお、お寺にはちょっと面白いものがあります。ぜひ、この目で体験してみてください。

眺望も抜群

あじさいばかりではなく、眺望も抜群です。お寺の上に行きますと、晴れていれば勝浦や太平洋を眺めることができます。

IMG_2211

この日は梅雨時であったのにも関わらず、素晴らしい青空と海を眺める事ができました。ちょっと時間がずれていると、夕立にあっていた可能性があったので、本当に運が良かったなと思っております。

交通について

さて、問題は交通です。これだけ空いているのは、簡単には行く事ができないからとも言えます。公共交通機関ではなく、自家用車で行く事がほぼ必須であり、さらにここは山の中であるためそれなりの山道を走り抜けなければなりません。

私は葛飾区のレンタカー屋さんからここまで、京葉道路経由で順調に移動して3時間弱かかりました。また、この日は途中の道が土砂崩れのため遠回りを余儀なくされました。また、遠回りした先も、それなりの険しさの道でした。そして、山道の日陰はたいてい路面がぬれていますので、速度を出し過ぎないよう気をつけて走行する必要があります。

そのため、運転に不慣れな方は天候が荒れるとわかっている日はやめておいた方が無難です。ただ、状況が許す時であれば、この風景をぜひ他の方にもお楽しみいただけたら嬉しいな〜と考えています。

おわりに

ここまで、房総半島のあじさいスポット「麻綿原高原」について、3つの観点でお話ししました。首都圏からそれなりの時間と道の険しさをクリアしなければなりませんが、それに見合った価値は充分にあります。また、写真撮影が好きな方は、あじさいをじっくり撮影するチャンスです。

今年の見頃は、7月第2週、そう、このブログを投稿した今日あたりです。ぜひ、行楽先の候補として検討されてみてはいかがでしょうか。

filmscan922

July Tech Festa 2014へ行ってきました #techfesta

今日は、July Tech Festa 2014に足を運んできました。ITインフラに関するソフトウェアや運用技術の話ばかりではなく、知見として獲得しておきたい他の分野に置ける開発のベストプラクティス等も聴く事が出来ました。

基調講演の「Serverspecに見る技術トレンドを生み出すヒント」では、Serverspec開発にあたってどのような事を考えていらっしゃっていたのか伺えた、貴重な機会となりました。

「インフラエンジニアのための次世代プロトコル入門」では、次世代プロトコルの導入はもう迫ってる現実であり、必ず来る未来である趣旨の話であることを確認させられる、ちょっとヒヤッとするセッションでした。

「Contrailを用いたSDI/NFVの実現」では、Interopよりもここ最近のネットワーク関連のキーワードを掘り下げるよい機会となりました。同時に、ネットワーク関連の話は本当に難しくなってしまって、OS・ミドルウェアレイヤーと同時に追いかけるには難しいのかなと思い始めています。

「フロントエンドで普及が進むビルドツールたち ? Grunt、gulp ほか」では、gulpを使ったWebページ・フロントエンド制作の最新のベストプラクティスを学ぶ事ができ、かつ自分の知識が化石化し始めている危機意識をもつ機会となりました。

それでは、今回もノートをアップしておきます。

概要

★今年もやります!JTF2014!!★
皆様,今年もインフラエンジニアのための祭典,July Tech Festaを開催する運びとなりました。今年は6/22(日)開催です。昨年は300名超のご参加をいただき,技術セミナーをはじめ,数々のセッションが大盛り上がりとなりました。今年のJTF 2014は,セッションなど更にパワーアップし,昨年以上に熱く開催されます!テーマは「インフラ・テクノロジーマップ2014 〜明日を楽するために今日自動化を頑張るエンジニアの集い〜」とし,まさに今年の全貌が見える,旬のインフラ技術が結集します。ぜひご参加ください!

★イベントの詳細★

イベントの詳細は次のURLでご確認下さい。

http://2014.techfesta.jp/
  • 弁当
    • A会場にて頒布
    • 13:00まで頒布
    • 食べるのはA会場 or 食堂にて
    • 指定のゴミ箱へ

Serverspecに見る技術トレンドを生み出すヒント

宮下 剛輔 さん

  • 技術トレンドのキャッチアップ

  • Deckset でプレゼンしてる

  • 今はほとんどCookpadで仕事をしているらしい

  • 本セッションのインフラの定義: OSからミドルウェアといったソフトウェアレイヤーを指す言葉

  • 最近のトレンド
    • Chef
      • 4, 5月に立て続けに本が出た
      • USでは2014にPuppetのシェアを超えたらしい
    • Ansible
      • Chefへのカウンター (複雑さ、大規模さへのカウンター)
    • 仮想化関連
      • Vagrant
      • Docker (2013–03くらい Serverspecと同じくらい 仮想化以上の意味があるものではあるがとりあえず SEE Also:WEB+DB Press Vol.81)
    • テスト駆動インフラ/インフラCI
      • Test Kitchen
      • Serverspec
      • WEB+DB Press Vol.80 に特集記事があるので読んでね
    • Immutable Infrastructure
  • テスト駆動インフラ/インフラCI
    • 概念自体はあった
      • アプリケーション開発の手法をインフラ構築に応用する。
      • 2012年に @riywo さん、 2007くらいに自身でも考えていた。
    • GitHubを利用したワークフローにまで広げられる
  • Serverspecとは
    • 2013–03末にリリース
    • 名称は正しく! Serverspec, serverspec, SERVERSPEC のどれか。1つめは現状、2つめは旧です。気をつけてね!人の名前間違えないのと同じように、
  • Serverspec背景
    • なぜ生まれたの?
      • Puppetで構築は自動化できた→でもExcelベースのチェックシートでの目視をやめたい・自動化したい
    • Assurerの誕生
      • 2007年に作ったPerl製テストフレームワーク
      • プラグイン拡張可能
        • Plaggerの影響
        • Filter, Format, Notify, Publish, Test
      • make test でテスト実行, TAP形式で結果を出力
        • CPAN AuthorなのでPerlでのテストのやり方を踏襲した
      • 敗因
        • 振る舞いをテストした
          • 状態テストよりも要件が複雑化する
        • 詰め込みすぎて更に複雑になった
          • フェイズ分け, プラガブル, 分散処理, シェル
        • Serverspecほどコンセプトが明確ではなかった
          • 自分すら使わなくなった…
    • Assurer以後
      • 思い返しても積極的に何かしようともしなかった
      • マネジャをやっていた事もあり若干現場から距離を置くようになりあまり触らなくなった
    • またPuppetを触り始めた
      • 以前書いたものがレガシーコードになっていた…(あの時はベストプラクティスがなく、今の状況に合っていない。)
      • リファクタリングしたい→当然テストも必要
    • CI環境を整える
      • LXCコンテナでテスト。コンテナをさくっと作れるPuppetマニフェストを書いた。 (でもDockerが出てきて無用になってもた)
    • テストツール探し
      • Puppetはrspec-puppetくらししかない。しかしモジュール化されていない。使えない状況。
      • Chef周辺の方が充実。
      • 上記は実際のサーバの状態をテストする訳ではない。
    • Serverspecの登場
      • 同僚(@hibomaさん)のLXCコンテナをテストするコードをRSpecで書いていた。パクって汎用的にした。
      • 1日でプロトタイプを作り、次の日にgemを公開。
    • 初期
      • 複数OS, バックエンド切り替え対応など、色々入ってきた。
      • いろんな人を巻き込んだ。
        • ちょっとした隙を作る。
    • 今後
      • v2.0
        • 作業中
        • 拡張しやすくするためのリファクタリングが中心
        • 表面上はあまり変わりません
  • Serverspec認知度
    • Black Duck Open Source Rookies of the Tear 2013 にて、Docker, InfluexDB, Appium と並んで受賞。
    • Thought Works Technology Rader 2014にて、Provisioning Testingの項目で出てくる。
    • Rubygems.orgにて30万DL (参考:Chefは400万)。
    • 雑誌 WEB+DB PRESS Vol.75,76,80,81
      • @naoya_ito さんの推しあってのこと
    • 書籍
      • 5冊ほど
    • 海外の反応
      • Adam Jacob さんなど
      • ドイツ
    • ChefConf で発表した資料
      • Puppet のカンファレンスではRejectされてしまった
      • ChefConf で話せるのは認知されてきたんだなと思った
    • Sensu+Serverspec って話もあるらしい
  • Serverspec成功要因
    • ワールドワイドで認知された経緯
    • 能動的な要因
      • 別領域で成功しているプラクティスを持ち込む (今回は特にソフトウェア)
        • テスト駆動
        • CI
      • 同じ用語を用いるとイメージしやすい
        • テスト駆動インフラ
        • インフラCI
      • 名前
        • Server + RSpec と直球
        • 類推しやすい
        • 覚えやすい
      • 英文ドキュメント
        • 日本国外で広く認知してもらうためには重要
        • README, serverspec.org などは最初から英語で書いた
      • 既にメジャーになっているものに乗っかる
        • Puppet, Chef と言ったキーワードをちりばめる
        • Puppet ,Chef の中の人に拾われて広まったかと思う
      • ドキュメントのわかりやすさ
        • リーチャビリティあげるだけではダメ。
        • 見てすぐにわかる、斜め読みしただけでわかるように。
      • ツール自体のシンプルさ
        • そのものがわかりやすいことが重要。
        • テストに特化
          • 構成管理・VMの操作をは省いた
      • 他ツールとの組み合わせ
        • busser-serverspec
        • vagrant-serverspec
      • Agent less
        • テスト実行する環境でRubyで動けば良い
        • テスト対象はSSHだけあればいい
      • とりあえず動かせるような環境で
        • サーバに色々入れるの嫌ですよね (わかります)
        • RHELでサポートできるバージョンで使えるようにしておいた
    • 技術トレンド要因
      • chef界隈テストの盛り上がり
      • JenkinsやCI as a Serviceの普及
      • GitHubの普及
  • まとめ
    • 欲しいもの、面白いものを自分のために作ろう!!!そして公開しよう。
      • (人類の技術発展のための無償開発、というスタンスではいいものはできないよね。)
    • 技術トレンド生み出す近道はない
      • 少なくとも自分は知らない
    • その積み重ねが素晴らしいものを生み出す事につながる
      • 自分が作って公開したものは、小さなものを含めて100ほどある。

インフラエンジニアのための次世代プロトコル入門

中島 博敬 さん

  • スライドは後で公開します

  • インフラエンジニアの仕事
    • 上も下も知る
    • 未来を見据える
  • 現状
    • HTTP, TCP, IP
      • ずいぶん変わってない
      • 動いているものを変更するな。変えるのは大変だ。
    • Web
      • 非同期通信の台頭
  • なぜ次世代プロトコルなのか?
    • 接続環境の変化・ページのリソース数・Webアプリケーションのインタラクティブ化
    • 遅延がWebサービスの収益にリンクする
    • HTTP/1.1
      • 接続の度のヘッダ、無駄だよね!
        • コンテンツ圧縮はできるけど、ヘッダはできない。
        • こまい通信が増えると最悪だね。
      • 「黒魔術」による解決。
      • それも限度がある。
  • HTTP/2
    • SPDYからの提案をベースに議論を開始
      • CRIME攻撃の問題を解決
    • とにかくオーバーヘッドを減らす
    • 全二重通信 (Push)
  • TCP Alternative
    • QUIC
      • SPDY – Head Line Blocking の問題
      • だからUDPベース
      • 1RTTで接続
      • Forward Error Correction – パリティ技術
      • Packet Pacing – Conguision Control (UDPの弱点を補強)
      • Multi Path – ハンドオーバーを0RTTで
  • TCPを既存のネットワークに影響が出ないように変えて行く取組み

  • TLS
    • OpenSSL 悲しい出来事 2つ…
  • IPv6
    • 対応は 日本で3.49, 米国でも7.97% 泣ける
    • Azure 米国リージョンの IPv4 のアドレスが枯渇 (65万個 使い果たした)
    • IPv4 のアドレスの枯渇の問題は既に発生している
    • fail2ban は v6 対応してなくて泣いたとか
    • 新サービスから対応しよう
  • ハイパフォーマンスブラウザネットワーキングもあわせて読みましょう

  • 興味があるプロトコル、一つはじっくり掘り下げてみよう。

  • 次世代プロトコルの導入、もう迫ってる現実だ!必ず来る未来である。

Contrailを用いたSDI/NFVの実現

有村 淳矢 さん

  • ShowNet構築の気分的な疲れが残ってる…(汗)

  • Contrailとは?
    • SDNプラットフォーム ソフトウェア
    • Open vSwitchを使って…という議論があるけど、それそのものだよ。
    • コントリビュートできます
  • プレーンの分離
    • OLD WAY
      • Managerment, Control, Service, Forwarding Plane が内在し、各機器が自立分散して動いていた。
    • NEW WAY
      • コントローラを用いてこれらを集中管理。
  • Contrail
    • 5つのコンポーネント
      • Configuration Manager
      • Collector
      • Web UI
      • Control Plane Node
        • BGPベースのコントロールプレーンを管理
      • Compute Node
    • オケストレータ
    • SDNコントローラ
    • XMPPでメッセージをやりとりしている
    • 大規模にスケールするクラウドサービスを実現可能
      • MPLS VLAN のように
  • OpenFlowとの違い
    • 集中管理している所は同じ。
    • 既存IPネットワークにも情報をフローベース(IP, Port)で注入 コントローラが膨大な情報をもっている
      • 機器に負荷をかけずにトラフィックを切り替えられる
    • オーバーレイモデル(Contrail)だと細かいものを太くして自律分散している
      • 細かい制御が難しくなる
  • NFVとSDN
    • NFVとSDNは完全にイコールでは結ばれない
    • NFVとSDNを絡めて使う事でより良くなる
    • OSの部分だけ抜き出して仮想化するのがNFV
  • Contrailを用いたSDNサービス
    • オーバーレイ クラウドデータセンター
    • IaaS & VPC, Seamless MPLS Datacenter
    • サービスエッジ, NaaS VPN GW
      • 末端のセキュリティ対策をデータセンター側で移譲させてしまう
      • (CATVインターネットとかだといい感じっぽそう)
  • SDN時代のデータセンター・アーキテクチャ」も参照

  • Spine-Leaf のメリット
    • 遅延・ジッターのレベルが一定 (輻輳しなければ)
      • Webアプリケーションのネットワークパフォーマンスが安定する (Hadoopとか)
      • 論文もあるよ
  • VXLAN GW (ToR)スイッチ
    • VXLANトンネルを経由してデータセンター間でやりとりできる、が…
    • VLANタグはつけない
    • サーバ側で先にVTEPを通してしまう
  • 仮想の世界で問題があると、単にミラーポートからDumpするデバッグは難しくなった。
    • Contrail等を使えば楽、らしい。
  • くわしくは
  • 久々に技術的に追いつけない内容だった…

フロントエンドで普及が進むビルドツールたち ? Grunt、gulp ほか

河村 奨 さん

  • 下北沢オープンソースカフェとリブライズの人

  • カフェは東京で二軒目のコワーキングスペースだったそうだ

  • Grunt (ぐらんと)

  • gulp (がるぷ)
    • こちら中心でいきます
  • フロントエンド制作の今
    • デモンストレーション「アンネ・フランク・ライブラリー」
    • 単にHTMLを書くだけでは作れなくなった
    • gulpfile.coffee (coffeescript)
      • 画像ファイルの自動変換
      • いろいろ
      • デザイナが手作業でやっていたものを自動化する (現場にいると本当に大変そうだった)
    • クロスブラウザチェック
      • 同時に複数のブラウザをチェックできる スクロールもsync (めっちゃいいですねこれ)
    • ほぼリアルタイムにブラウザをチェックしながら制作可能
      • HTMLの即時反映
      • 画像のリアルタイム反映もできる (サイズも含めて!!!)
    • それなりに高速に動くらしい
      • 非同期でタスクが走る
      • デモだと 300msec くらいでいける
  • 比較
    • Grant
      • フロントエンド制作の自動化の立役者
      • npmで入れられる デザイナも使うくらいなので簡単である
      • 1年くらい、お世話になったそうです。
    • gulp
      • タスク設定ファイル、Grantと比較すると、1/3くらいの分量。おうふ。
      • コマンド間連携もできます。
      • Googleも乗った。
        • Web Fundamentals – マルチデバイス対応スターターキット タスクランナーにgulp採用
      • 新しめのサイトの制作はgulp採用が増えている
  • gulp
    • package.json, gulpfile.coffee
    • 「ブラウザ直近2バージョンまでサポート」なんてことも
    • インクリメンタルビルド可能
  • 何を自動化するの?
    • LESS, Sass, Styles
    • CSS最適化
      • 「uncss」(使っていないCSSを削れる) – 秘伝のCSSをスリムに
    • CoffeeScript 等のコンパイル
    • Browserify, Require.js, Uglify
      • ライブラリ依存、難読化、圧縮。
    • Style Guide
    • 画像最適化
    • フォント自動生成
  • 何のための自動化?
    • 楽をする。2回同じ事しない。
      • デザイナには鉄則ではなかった。美徳とさえ言われていた事もあった。
    • コンパイル・自動生成
    • テスト・ソースコードの検証
    • リアルタイム化 (LiveReload, BrowserSync)
  • ビルドツールの変遷
    • 石器時代
      • ShellScript, AppleScript, Adobe JavaScript
    • 中世
      • Make – Watchman(Facebook謹製のファイル監視ツール)の影響
      • Rake, Jake, Fabric, Ant
    • 近代
      • Guard, Watcher (ディスコン)
      • Middleman
    • 現代
      • gulp, Grunt, Brunch, Broccoli
    • 平行世界
      • ワークフローが限定的になるので悩ましい
      • CodeKit, Prepros, Atom, …
  • サーバ・クライアント・そして第三極?
    • デザインの現場からの要請
      • ウォータフォール方法論の崩壊
      • レスポンシブ
      • インブラウザ
      • デザインもテストファースト(CI)の時代に
    • 改めて、自動化。
    • 共通プラットフォームとしてnode.jsがデファクト。
    • フロントエンド開発にプログラマが参入した結果が、今。

総務部技術課!? エンジニアのための業務完全自動化へのアプローチ

服部 健太 さん

  • Kompira 開発している所 (2013年のプロシンに来てた所かな?)

  • フォースクーナーはデータホテルに売却

  • 自社プロダクトの紹介。

  • プロシンの発表の後から、どの辺が変わったのだろう。

おわりに

  • 家の用事があって、懇親会には行けませんでした。ちょっと残念。
  • スタッフの皆さん、AIITのみなさん、話者の皆さん、どうもありがとうございました。
  • Mackerel Meetup #1 に行ってきました #mackerelio

    昨夜は、はてなさんが提供を始めたサーバ管理ツール、その名もMackerelに関するお話を伺いに行きました。ITエンジニアの中での俗語ではサーバを「鯖」といいまして、そこからMackerelという名前が来ているようです。

    また、ITインフラ系の方ばかりではなく、プログラマの方等、様々な背景を持った方達の交流の場ともなりました。はてなさんの懐の深さを感じずにはいられません。

    それでは、いつものようにノートをアップしておきます。

    概要

    Mackerelの紹介

    @motemen (おおつぼ)さん

    • 「まかれる」と読む
    • Mackerelディレクターやってます
    • overview
      • サーバ管理ツール as a サービス
      • 元々 社内ツールがあった アイコン「鯖」
      • はてなの知見を活かして、今までとは違うものを提供する事となった。
      • 選択した言語・ミドルウェア、全て新しい試み。
        • Scala + play + postgresql + graphite + angluarjs + go
    • 特徴
      • ロールによるホスト群の管理。
      • エージェントベースのリソース管理。
      • リソースの可視化。
      • APIベースの管理。
    • Orgとユーザ
      • Org単位で課金する予定。
      • ユーザは複数のOrgに所属できる。
    • サービスとロール
      • 様々なホストが強調して動いている…1つのWebサービス単位でまとめる
      • ホスト群を役割でまとめる…ロール
    • ホストのライフサイクル
      • Status: Stdby, Working, Mainte(監視停止)
      • 役割が終わったサーバは「退役」がある
    • Metric
      • Agentが収集→時系列で可視化
      • ロール毎にまとめてチャートを表示できる。
        • (ばらつきとか、問題の有無とかを見つけやすそうですね。)
    • 監視機能が今日からリリース!
      • Alerts メニューだ!!!
      • Agentからしばらく疎通が無いと通知。ホストの死活監視。メールベース。
      • 管理画面から「実験的機能を有効にする」ってのもできた。Experimentalな機能を使いたい場合はこちらです。
      • 今後: 閾値ベースの通知を作りたい。
      • (Web Hook使えるようになるのかな?)
    • APIを公開しているので、Agentは自分で作れまます。
    • yum/apt がオススメ。brew install, go get などもできます。
    • 収集
      • 1分間隔。
      • 今後、1時間位1回収集し直す変更を入れる。
      • 設定ファイルを書き足せばカスタムメトリクスを収集可能。
        • 書式はSensuプラグイン互換
        • 表示方法も編集可能(Webベース)
      • Agent側でRoleの設定を定義可能。無ければ作ってくれる。
        • cookbook-mackerel-agent でも使えます。
    • API
    • CLI: mkr
    • その他のツール
    • はてなさんの事例
      • 有名な某サービスの状態
      • cookbook-mackerel-agent を改良、httpステータスの分布、レスポンスタイムの数値をとる。
        • 見せ方、考えたい。
    • Feedback 歓迎します

    ロードマップ

    田中さん

    • 6月
      • 監視・通知
      • アプリケーションメトリクス
    • 7月
      • グラフ拡充 (カスタム・外部貼付)
    • 8末〜9月
      • 正式化したい
    • 監視・通知
      • 7月に応用的なものをつける
      • 閾値監視
      • 通知手段 (HipChatなど)
    • アプリケーションメトリクス
      • レスポンスタイム・
      • エラーレート
      • サービス全体の状況を俯瞰する
      • カスタマイズ
        • ラベル
        • 形状
      • 監視・通知もつけたい
    • グラフ
      • 外部貼付け
      • 高速化は随時やります!
      • ダッシュボードの使いやすいUIは悩んでいるらしい
    • デプロイ支援
      • デプロイタイミングをプロット
        • (まあ、この辺りで色々起こるもんな。)
      • ロールのバージョニングとgit hashとの紐付け(7,8月)
    • 正式リリース後
      • ユーザ管理権限強化
      • クラウド連携強化
        • LB, インスタンスをキックできたりとか
        • これ欲しいね
      • Docker支援
        • イメージリポジトリ、API操作。
    • カスタムメトリクス関連
      • 色々作っています
      • まとめていきます
      • (Go, Pythonライブラリ欲しいっす)
    • mackerel-client-ruby
    • 連携
      • hubot (ドックフーディング中らしい)

    オススメッ!

    • 簡単セットアップ
      • 複雑過ぎない 簡単過ぎない
    • システム構成要素を一元管理
    • サービスの時系列データを可視化

    質疑応答

    • 事前のご意見・ご要望
      • 台数 (時系列データの管理って大変ですよねー)
        • 2,000台 はてなで実績あり。10,000まではいけるんじゃないか。
      • AutoScale環境で使いやすくしたい
        • ドックフーディング中 がんばって改善しています!
      • サービストップのLoad Avg.を変更できるといい。
        • 検討します。
      • CloudWatchにメトリクスデータを流したい
        • REST APIで今後できるようにします。
      • OSSでの無償提供は考えているか?
        • 前向きに考えます
        • 事例がないので色々相談させて下さい
      • 価格
        • 原則 従量制でいきます
        • ボリュームディスカウントとは考えます
        • 固定が欲しい件は応相談
        • 数値はいずれにしても検討中
    • Web Hook 対応 (質問した)
      • 早い段階でやります。やりたい!
      • アプリケーション間連携の重要性は考えていらっしゃる模様。
    • 代理店 (@netmarkjpさんより)
      • ぜひお話しさせてください
    • メトリクスの細分化 よりリアルタイム化したい
      • あると面白いと思っているが、Agentの実装をどうするか悩んでいる。
      • API的には5秒は受けられない。どうするか考えたい。
      • 需要があるのは確認している。

    おわりに

    Nginx ユーザ会 #0 に行ってきました #ngxug #hbstudy

    昨夜、サイオステクノロジーさんで行われた「Nginx ユーザ会 #0」に足を運んできました。

    この日は、Nginx開発者であるイゴールさんから直接お話を聞ける貴重な機会となりました。

    それでは、いつものようにノートをアップしておきます。ただ、今回は本編は全て英語(逐次通訳あり)でした。もし、解釈の誤り等ありましたら、Twitter経由でご指摘いただけましたら幸いです。

    概要

    Nginxユーザ会 #0 (共催: #hbstudy #56)
    
    初来日のNginx開発者Igor Sysoev(イゴール・シソエフ)さんを囲む会
    
        イゴールさんを囲んでビール、ピザスナックありのカジュアルな集まりの予定です
        nginx.com社公認のNginxユーザ会を立ちあげたいので、その第0回的な気持ちです
    
        Nginxユーザーコミュニティの立ち上げについて サイオステクノロジー 安藤浩二さん
        日本のユーザーコミュニティの歓迎とNginx社としてのコミットについて Nginx社 CEO Gus Robertsonさん(通訳付き)
        Nginx アップデートNginx社CTO Igor Sysoevさん(通訳付き)
        質疑応答(通訳付き)
        懇親会
    
    ■概要
    
        日時: 2014/6/18(水) 19:00?20:30 ※開場18:30
        会場: サイオステクノロジー東京オフィス 9階オープンスペース (東京都港区南麻布2‐12‐3 サイオスビル)
        参加費: 無料
        告知順の都合で hbstudy #56 が #55 よりも先に開催になりますのであしからず
        当日はUSTREAMでのライブ中継も予定しています(チャンネルは↓)
    
    http://www.ustream.tv/channel/sios
    
    ※twitterでhbstudyをフォローしてください! 
     公式ハッシュタグ→ #ngxug #hbstudy

    はじめに

    • 背景
      • サイオステクノロジーさんがNginx Plusの国内販売代理店契約を締結
      • ばばさん(@netmarkjp)が色々サポート
      • 滝澤さん(@ttkzw)さんのhbblogでの連載が普及を後押し
      • デジタルキューブさん、ビヨンドさんも後押し。
    • 参加してね!
    • ゆるキャラがほしいっ!
      • わぷー (WordPress)
      • あれより可愛い方が良いなぁ…
      • ロシアではチェブラーシカ(?)
    • hbstudy
      • ちょっとしたおしらせ
      • 初hbstudy参加者多い!
      • しゃべりたい人 @netmarkjp さんまでご連絡を!大歓迎!!
      • サイオスさんと商業的なつながりがあるわけじゃないよ!
        • (実はHBの問い合わせフォームから直球で連絡を受けたのでした)

    開発元より

    ガスさんの話

    • オージーの人だ
    • 赤坂にもおったらしい。日本に戻れて嬉しい!
    • nginxの概要
      • 140M数のサイトで使っている
      • nginxはプラグインを追加してどんどん機能追加できるぜ!ユーザコミュニティの助けがあっての事。
      • それがあって今がある。
    • httpの成長は早い
      • ワールドワイドで話を聞いてきた
      • API, モバイルでバイス, ダイナミックWebサイト, メディア…

    アンドリューさん

    • Co-founder
    • 3年やってます
    • 開発者ではないけど、イゴールさんとやってきた。
    • 日本は初めてだ
    • Modern Web Server
      • ユーザがハッピーである事が大切。ハッピーにするのがnginx。
      • 10年の蓄積…それでもモダンだ。現状にあわせて機能追加できている。
      • 小さくても、急に大きくなっても役立てる。
    • nginxがもたらすもの
      • 「重量挙げ」はnginxがやるぜ!…ビジネスに集中してもらえるように。
      • Who benefits? – 人・アプリ・Web
    • 強調したいのは、nginxはユーザコミュニティとともに開発して行くプロジェクトである。

    イゴールさん

    • モスクワから来たよ!
    • 1970年 カザフスタン生まれ
    • 初めて使ったのは YAMAHA MSX だ
    • 色々興味があったけど、特にCSを学ぼうと思った。MSXのおかげっぽい。
    • av.com – 大学で初めて作った大きなソフトウェア。MS-DOSのウィルス対策ソフトらしい。
    • 日本は初めてだけれど、日本文化が好きっぽい。
      • アニメはよくわからん。
      • 10代の頃に、伝統的なものに興味があったらしい。
        • 庭園とか?
        • 日本文学 (芭蕉・蕪村)
      • まっ、ロシア語に翻訳していたものだけれどね!
      • 東京もいいね!住んだら楽しいだろうねー
      • おっと言い忘れた、15歳の子がいるんだけれど。
      • 昨日、寿司食べたんだけれど、日本で食べたらロシアと違ってうまくて認識を改めたよ!好きだよー
    • 2000年ごろに開発開始…その頃はApacheが台頭
    • ある開発者の人が、ApacheがProxyとしてアクセラレーションで来ているのか疑問を呈してきたのが発端。
      • 調べたけど、ぜんぜんあかんやった。
      • なんとかしたい。
    • Apacheモジュールを自分で書こう!とした。
    • そのうち、モジュールをIntegrateして行く道があるんじゃないかと考えるようになった。
    • C10K問題 – これ以上だとどうにもならん。
    • lighttpなどがあったけど、静的コンテンツしか扱えなかった。商用だとプロプロエタリだった。だから、OSSを作ろうとした。
      • lighttpは設定がCLIしか使えない。
      • バーチャルホストもはりづらい。
      • Apacheのような柔軟性を担保、だけどあそこまでなくてもいい。できすぎると管理負担がでかくなって泣くよね。
    • Apacheにあるいらない設定を省こうとした。
      • 夜中に電話がかかってくるような状況はやめたい。
    • 最初から入れたかったのは オンラインアップグレード
    • 名前は、紆余曲折を経て nginx という綴りになった。見た目も、音もいいぜ!
      • ロシア語的に、2つ目のNの逆は意味があるらしい。’い’という音らしい。イゴールさんの名前の頭文字なのと、ロシア発なのを込めたかった。
    • 2004/10/04 最初の公開版をリリース。
      • proxy, 静的ページに対応
      • 2005年にCGIに対応
      • 最初 3年くらいはロシアのユーザばかりだった。
      • 2007年に英語版を作った。その後は英語の地域に広がった。
    • 長い事一人でやってきた。
      • その後、仲間に加わってくれたのが、マキシムさん。
      • 開発を加速させたかった。
      • 2009, 2010年頃はメンテに必死で新機能がつけられなかった。それを打開したかった。
      • 英語のドキュメントも整備したかった。
      • 共同創設者のおかげで、マーケ、マネジメントの環境が整ってきた。
    • 英語でコミュニケーションできる状況は、私に取って助かる。
    • 2013年に、Nginx Plusを発表。商用版。
      • Stable lineをベースに開発。安定性が高い。
      • より古いバージョンを使うのを好んでいる人もいる。安定性を買っていると聞いているから。
        • でも、それは違うとのこと。 一番新しいものが一番安定している! 古いものはBug Fixの施しは無い。
      • 2ラインの開発
        • Stable Line
        • Main Line – Nginx Plus・最新版

    質疑応答

    • HTTP 2.0 サポートについて
      • SPDY 3.1 はサポートしている。似ているので、それほど手を加えなくても行けると思う。
    • ビルドを簡素にするインタフェース開発の計画はあるか?
      • よりビジュアルなWebインタフェースの開発の計画はある。
      • イゴールさん的には、テキストファイルでまとめた方が便利だと思ってる。何度も使えるし。
      • ただ、毎回やるわけじゃないから、作った方がいいなーとは思ってる。
      • 後で個別に更に聞いてみたら、テキストファイルにまとめているのだったらそれでよくね?これはあんまり優先度高くなさそうだった。
    • 古いバージョンを使い続けてるんだが…
      • セキュリティに関するFixは古いバージョンについても適用
      • SPDYでパフォーマンス向上を期待できる
      • Proxyを使っていればテストも可能
      • 1.7.2:昨日追加した機能により高度なキャッシュ機能も作ったよ
      • websocketの機能も付けたよ

    メモ

    • 逐次通訳の方の語彙力半端ない。このノートも、自分の耳が追いつけない所は逐次通訳の方のお話を頼りました。大変おつかれさまでした。
    • 英語力付けていかんといけん、特に話せない。もっと質問したい。
    • サイオステクノロジーさん、どうもありがとうございました!

    スキー 2013-2014シーズンの滑走記録 – 少ないけど長い

    毎年恒例となりました、スキーの滑走記録です。

    今年は相方と一緒に行動する事が増えまして、回数こそ減りましたが、シーズン自体は長く、あちこちのスキー場を巡る事ができました。

    DSC_0354

    通ったスキー場は…

    でした。なお、滑走日毎の詳しい話は別のブログ『スキー – 週刊 スポーツこえむ – 自転車とスキーの記録』をご覧ください。

    ■滑り方を教える側になる

    今年は相方とよく滑りに行くようになりました。今まではひとりである事がほとんどだったのですが、随分と変わりました。幸いな事に、相方は身体能力が高く、スキーを覚えるのがとても早いのです。練習の結果、安比高原スキー場では滑走日3日目なのにオオタカコースの第3リフトのエリアまで登って滑っていましたし、谷川岳では滑走日5日目でしたが春のザラメ雪の中で一度も転倒せず休憩無しで中級者コースを滑っていました。

    教えると言っても、以前自分がスキースクールで実践していたバリエーショントレーニングをやってみたり、スマートフォンで滑りを撮影し確かめながら修正点を探り出す練習をしていました。

    こちらのビデオは、バリエーショントレーニングの様子です。外足を滑らかに出せるように取り組んでいます。

    教え方はいろいろあるのでしょうけど、何よりも「楽しく滑る」環境を作る事ができれば大丈夫なのではないでしょうか。

    ■スキーと一緒に楽しむもの

    僕は旅好きでもありまして、最近は心の余裕ができてきたのでしょうか、スキーとともにこんなのを楽しんでいます。

    • 電車を楽しむ (初めてE5系に乗って320km/hを体験した)
    • うまいものを食べた (石打丸山・安比高原…)
    • 温泉に入ってゆっくりした (谷川岳)

    ただひたすら滑るのももちろん楽しいです。とはいえ、ちょっと見渡すものを増やすだけで、より楽しい時間を過ごせるのではないでしょうか。

    DSC_0665

    ■来シーズンはどうしようか

    今シーズンはこんな感じの腕前で終わりました。

    色々課題がありますね。オフシーズンに体を作っていないのもバレバレです。1級までの道はまだまだ長そうです。道具も一部傷んできたり、壊れてしまったものも出てきまして、そろそろ買い替えはじめたいなと考え始めています。

    また、時間を見つけて白い山に力をもらいつつ、滑り込もうと思います。

    それでは、また来シーズンもゲレンデでお会いしましょう。

    ■参考リンク