まいんだーのはてなブログ

はてブなのはてブロなのどっちなの

YAPC::Kyoto 2023に参加していろいろしました

なんと前回の投稿は2017年。。。
YAPC::Kyoto 2023に参加してきました、楽しすぎていろいろ壊滅しておりましたが「ブログを書くまでがYAPC」ということで、私のYAPC::Kyoto 2023はこのエントリをもって終わらせます。

感謝

まずは開催をあきらめず、大きな事故もなくやり遂げたJPAの皆さんとスタッフの皆さん、本当にありがとうございました。
またYAPCに参加できたことをとても嬉しく思っています。
特に @papix のクロージングスピーチは「何としてもやるんだ」と思って雌伏の時を過ごしてきた気持ちが伝わってきました。

スポンサード

2020年にいろいろあって自分の会社を作ったんですが、そこから3期(20年度、21年度、22年度)である程度現金が出来たのもあり、今回イベントスポンサーをさせていただきました。
YAPCには「個人スポンサー」というものもあるのですが、今回「折角の機会だし、YAPCで育ててもらった側面もあるのでより大きな貢献ができれば」と考えたのがその理由です。
後から聞いたら、YAPCの企業スポンサー枠は今回全部埋まったようで、イベント運営においてお金で解決できる範囲を増やすことに貢献できたのは良かったなと。

幕間CM

現地でもYouTubeでも、参加された方は1度は目にしたであろうアレを企画しました。
www.youtube.com
そもそもスポンサードしたけど特に会社をアピールする必要はそれほどないため、いろいろと用意されているスポンサーメニューを全部こなすつもりもなかったのですが、何か面白いことができればとも思っていたので活用させていただきました。幕間の休憩中に「フフッ」となっていただけていたら幸いです。
大井町.pmは毎度あんな感じで、技術に関して好き放題会話できるpmとして大井町界隈で活動していますので、近くに来られる際にはどうぞお気軽にご参加ください。

Something New

前日祭のLT合戦にも参加させてもらい、ここ3年で取り組んでいたことの一部をアウトプットしました。
特に「数の暴力に対して孤独に戦う」と「王道ではないGoのASTの使い方」なんかは私としても新しい経験でした。
私の経験やスキルが活きそうなお仕事があれば、ご相談くだされば貢献できると思います。

トーク

ここ2年のオンライン開催のYAPCにおいて行われていた裏トークですが、今回もやるということで現地でひたすら裏トークし続けるということをやりました。
オンラインの頃は朝から夕方まで @ytnobody さんと @Soudai さんだけで延々回していく状態だったのですが、今回は現地でオープンに行っていたので飛び入りの方にいっぱい来ていただいたのは大きな違いであり、嬉しかった点でした。
なにせ裏トークは基本その場を離れられないため、現地でトークを聞いたり、来場している知人にあいさつに行くなどがしづらいので、来てくれた方本当にありがとうございました。
来てくださった方が裏トークにそのまま参加してくれることで、これまで以上に幅広い話題が扱えたと思いますし、過去最高に贅沢なコーナーになったのではないかと思います。
アーカイブもあるようなので、気になる方はご覧ください。


※来訪頂いた方との交流の例

栗栖さんがふらっと来てくれたのを放流したおかげで「裏トーク入っていいんだ」ということが伝わったと思うので、とても良い流れが出来たのだと思います。栗栖さんありがとうございます。

学生との交流

学生支援のスポンサーもしたのですが、スポンサー向けイベントとしてランチの時間帯に話をする企画に参加しました。
本来的な狙いとしては企業が学生にアピールして採用に向けて~といったものだったと思いますが、見事にそんなつもりがなかったので特にするアピールもないまま参加しました。
交流の中で印象に残ったのは、学生からの「今の会社に入った理由」という質問に対して、スポンサー側全員(大西さん、ワイトンさん、自分)起業した側だったので「自分で作ったんで。。。」という回答になっていたところですね。

私は基本的に会社のアピールではなく、YAPCというイベントとどう関わって、それがエンジニアとしての成長やキャリア形成にどういう良い影響があったかという話をして「皆さんも支援する側に是非なってください」ということを伝えました。

JPA理事もこういってますし、学生の皆さんはできるだけこういうプログラムを活用して交流の幅を広げていってもらいたいですね。

おわりに

@ar_tama さんベストトーク獲得おめでとうございます。2010年のキーノートは当時あのチームにいた自分にとっても特別なものなのですが、そこから10年の時を経てフラグ回収する様はかっこよかったです。トークは聞けていないのでアーカイブが上がり次第見ようと思います。
@nekokak さんと @onishi さんのトークはそれぞれとても良かった、できれば2回に分けてそれぞれのキーノートにしたほうがいいレベルだと感じます。
しかし最も「ああ、YAPCに来たな」と思ったのは、前日祭LTでトーク中に「その "== 0" 要らないよね」と容赦なくコメントしていくDanさんを見た時でしたね。

次回は広島だそうですが、その前にヘルシンキPerl & Kohaカンファレンスが行われるようなので、海外カンファレンス未経験の方は是非行ってほしいなと思います。
docs.google.com

というのもYAPC::Europe 2014に参加してとても良い経験になったという思い出があるためです。

www.slideshare.net

それではまた!

Microsoft Build 2017 のキーノートで発表のあった MySQL / PostgreSQL 関連の発表をざっくりと

MicrosoftMySQL/PostgreSQL のマネージドサービスを始めます

内部的にはずっと前から取り組みがされていて、多くの新規 Azure ユーザから望まれていた一方なかなか出てこなかった MySQL/PostgreSQL のマネージドサービスがいよいよ出てきました。 azure.microsoft.com azure.microsoft.com 何年も待ったわ~ほんとに。。。

これまでの MySQL/PostgreSQL マネージドサービスの課題

各種クラウドにあるサービスには大きく2つの課題があったと思います

インスタンス” というサイジング

どのサービスも基本的に “仮想マシン” 単位で要求性能とキャパシティを決めて、そこにセットアップの自動化とバックアップ、そして別インスタンスへのフェイルオーバーを提供するものでした。 仮想マシンでのプロビジョニングはこれまでの運用感覚からいうと分かりやすい一方、仮想マシンへの手入れができないのでその点は諦める必要があるところがありました。

“ダウンタイム” のトレードオフ

障害発生時のフェイルオーバーが発生した場合、他のサービスではDNSによるフェイルオーバーだったりして、クライアント側が接続について考慮する必要がありました。 スケールアップのための操作には、シャットダウンが必要であり、これもサービスを一度メンテナンスモードにするなどのダウンタイムの考慮が必要でした。 また、MHAを使っている人がやるようなダウンタイムなしの運用を求めると、仮想マシンを使わざるを得なくなります。

Azure Database for MySQL/PostgreSQL の特徴

“コンピュートユニット” と “ストレージユニット” というサイジング

Azure Database for MySQL/PostgreSQL は、インスタンスという概念が存在しません。 “どの程度のCPUとメモリを利用するか” という、所望のワークロードに合わせたプランを選択することになります。 実際に Azure Portal からサービスを受けようとすると f:id:myfinder:20170511005100p:plain このように、処理量と要求ストレージをスライダーで設定する形になります。 Preview 中はこの変更に制限があるようですが、GA までにはこの設定変更が任意のタイミングに(運用中であっても変更可能!)できるようになるはずです。

docs.microsoft.com ここにざっくりとした解説がありますが、もっと詳しいリソースガバナンスについてはいずれ MySQL Casual などで話をしたいと思います。

Azure SQL Databaseと同様のダウンタイム

こうなると当然気になってくるのが “ユニット変更したときの挙動はどうなるの?” という点だと思います。 Azure Database for MySQL/PostgreSQL の挙動を知るには、Azure SQL Database の仕組みを知ることが近道です。 Azure SQL Database がどういう挙動をするかは docs.microsoft.com このドキュメントにありますが “average under 4 seconds, and in more than 99% of cases is less than 30 seconds.” が示す通り、基本的にこのダウンタイムでスケールアップ/スケールダウン、フェイルオーバーが行われます。 この特徴は MySQL/PostgreSQL のサービスにも引き継がれており、 docs.microsoft.com こちらにも全く同様の記述があります。

この仕組みについてもいずれ詳しく MySQL Casual などで話をしたいと思います。

Azure SQL Database for MySQL/PostgreSQL がより良くワークするユースケース

Movable TypeWordpressなどのCMSEC-Cubeなどのソフトウェアパッケージとの組み合わせ

普段のワークロードはそれほど高くないが、柔軟かつダウンタイムを短く運営したいという受託の多いWeb開発企業にとって、サービスをほぼ止めずに切り替えができるデータベースサービスは有利に働くと思います。

たくさんのDB/スキーマを管理しなければならないSaaS企業

SaaSの構築パターンとして、アプリは共通だがDB/スキーマを分ける運用をしている会社さんは多いのではないかと思います。 そういったサービスでありがちなのが、特定顧客のマスターだけ負荷が上がり始めるなど、ワークロードの偏りです。 そういう時に、ダウンタイムがより短くスケールアップできる選択肢があると、サービス運営にかかる負担を下げられるのではないでしょうか。

おわりに

Previewが始まったばかりなので、まだまだこれからですが、ついにMicrosoftSQL Server以外のRDBMSを正式にサポートするということは大きな変化だと思います。 ご関心のある方はぜひ触ってみて、フィードバックを送ってください。

(General Feedback): New (2470 ideas) – Customer Feedback for Microsoft Azure

では。

※追記

キーノートの後のセッションで、ローンチ時点から日本リージョン(Japan East/Japan West両方!)で展開されることが発表されました。これで皆さん安心して(?)お試しいただけますね! f:id:myfinder:20170511144034p:plain

ISUCON6参加者が実践したInfrastructure as CodeあるいはISUCON6のAzureインフラ解説

ISUCON6予選参加者の皆様、お疲れさまでした。
今回の ISUCON は Microsoft Azure ということで、多くの方にとってなじみのない環境だったと思います。

そこで、今回の ISUCON6 の予選問題がどのような仕組みで展開されているのか、Azure IaaSの仕組みを交えて解説します。

はじめに

@matsuuさんの多大な努力によって、運営に提案しようと思っていた構成の大半がすでに作られていました。
使ったことのないクラウドを触り始めてすぐに作り上げてしまうのは、さすがです!

復習される際はぜひ、@matsuuさんの作ったテンプレートを活用するとよいでしょう。

Azure IaaSの概要

Azureはおおむね国ごとにジオという単位で分けられており、その中に2つ以上のリージョンを持っています。
リージョンはそれぞれペアになるものが存在していて、日本では東日本と西日本がそれぞれペアリージョンになります。
そして、リージョンの中には複数のデータセンターが存在するという構成です。
f:id:myfinder:20160918132458p:plain

データセンター内では、物理サーバの配置を"クラスター"という単位で配置しています。
クラスターは同種のハードウェアの集まりで、例えばXeon E5-2673 v3の乗った10G NICのサーバなど、スペックが統一されたものです。
ユーザが仮想マシンを起動すると、裏側では "ファブリックコントローラ" と呼ばれるものが、その仮想マシンをどのクラスターに配備するかを決定します。

仮想マシンをファブリックコントローラが配備することを "デプロイメント" と呼び、これは一つのクラスターを対象に配備が行われます。デプロイメントはクラスターを跨ぐことはありません。
デプロイメントは、リソースマネージャーモデルの仮想マシンであれば、後述の "可用性セット" 単位で1つのデプロイメントとして扱われます。

f:id:myfinder:20160918135925p:plain

これは管理画面にも一切出てこないもので。通常ユーザはこのクラスターを意識することはありません。
ユーザがクラスターを意識するタイミングがあるとすれば、インスタンスタイプ変更の時です。

クラスターは "同一スペックのサーバの集合である" と説明した通り、インスタンスタイプの変更はこのクラスターの範囲の中で行うことになります。
ですので、最初にAシリーズなどの古めのスペックのインスタンスタイプで仮想マシンを作ると、古いクラスターに着地することになり、その後Dシリーズへ変更するにはVMを一度削除する必要があります。

f:id:myfinder:20160918134715p:plain

クラスター内部の構造

クラスター内部では "障害ドメイン" という単位で電源やネットワーク機器が配置されていて、これらの装置の障害がほかの障害ドメインに影響を及ぼさないように設計されています。ひとつのクラスターは、数十の障害ドメインで構成されています。

先に少し触れた "可用性セット" ですが、仮想マシンのメニューにそういうものがある事に気付いた人もいるかと思います。
これは、複数の仮想マシンを同一の可用性セットに入れると、最大で3つの障害ドメインに分散配置されるようになるものです。
f:id:myfinder:20160918141159p:plain

Azureの各種サービスはこれらの基盤の上に成立しています。

Azureにおけるリソース管理の概念

ISUCON6予選では "Deploy to Azure" ボタンを押して "リソースグループ" を作成し、その中に仮想マシンやネットワーク、予約済みIPといった "リソース" を展開しました。
Azureにおけるリソース管理はこの "リソースグループ" という単位で複数のリソースを行うのが基本です。
f:id:myfinder:20160918151204p:plain
Azureにおいては全てのものがリソースであり、必ずどこかのリソースグループに属します。
リソースグループは図にある通り、リージョンを超えて広げることができます。もちろん海外のリージョンでもOKです。
リソースへのアクセス制御は、リソース、リソースグループごとにアクセス制御(IAM)で設定をすることができます。
f:id:myfinder:20160918152120p:plain
これとは別に、タグも存在しています。タグはリソースに対して "キー = 値" 形式で付与することができます。
例えば "所属プロジェクトAに属するリソースグループ" とか "本番環境である" とか、そういった分類をするときに利用します。
f:id:myfinder:20160918154210p:plain

ISUCON6予選で皆さんが行った "Deploy to Azure" の仕組み

Azureではリソースを宣言型のテンプレートを用いて管理しています。
ポータル画面から何かのリソースを作った場合、裏側ではすべてテンプレート定義として生成され、管理されています。
逆に言うと、独自のテンプレートを定義して、それを読み込ませることも可能ということです。

今回のISUCON6予選ではこの手法を用いて、運営の用意したテンプレートを各自のAzureアカウント内へサーバ環境をデプロイする手法を取りました。
下記が、そのテンプレートの基本構成です

{
   "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "",
   "parameters": {  },
   "variables": {  },
   "resources": [  ],
   "outputs": {  }
}

テンプレートの要素詳細はドキュメントを見ていただくとして、定義の中で特に重要なのが resouces セクションです。
resouces セクションでは、作成若しくは更新されるリソースを定義します。と、書いてもわかりにくいと思うので、実際の仮想マシンの定義内容を見ていきましょう。

{
      "type": "Microsoft.Compute/virtualMachines",
      "name": "[parameters('vmName')]",
      "apiVersion": "2015-06-15",
      "location": "[variables('location')]",
      "tags": {},
      "properties": {
        "hardwareProfile": {
          "vmSize": "Standard_D2_v2"
        },
        "storageProfile": {
          "imageReference": {
            "publisher": "Canonical",
            "offer": "UbuntuServer",
            "sku": "16.04.0-LTS",
            "version": "latest"
          },
          "osDisk": {
            "name": "[concat(parameters('vmName'), '-os')]",
            "createOption": "FromImage",
            "vhd": {
              "uri": "[concat('https', '://', variables('storageAccountsName'), '.blob.core.windows.net', '/', variables('commonName'), '/', parameters('vmName'), '-os.vhd')]"
            },
            "caching": "None"
          }
        },
        "osProfile": {
          "computerName": "[parameters('vmName')]",
          "adminUsername": "[variables('adminUsername')]",
          "customData": "BASE64Encoded-userdata",
          "linuxConfiguration": {
            "disablePasswordAuthentication": true,
            "ssh": {
              "publicKeys": [
                {
                  "path": "[concat('/home/', variables('adminUsername'), '/.ssh/authorized_keys')]",
                  "keyData": "[parameters('sshPublicKey')]"
                }
              ]
            }
          },
          "secrets": []
        },
        "networkProfile": {
          "networkInterfaces": [
            {
              "id": "[resourceId('Microsoft.Network/networkInterfaces', parameters('vmName'))]"
            }
          ]
        }
      },
      "resources": [],
      "dependsOn": [
        "[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountsName'))]",
        "[resourceId('Microsoft.Network/networkInterfaces', parameters('vmName'))]"
      ]
    },

"type": "Microsoft.Compute/virtualMachines" 部が仮想マシンを表す記述です。Azureで提供されているtypeはCLIの "azure provider list" コマンドで確認することができます。
"name": "[parameters('vmName')]" 部はその名の通りこのリソースの名前を定義する部分です。parametersは運営の用意したテンプレートにあるparametersセクションに記述されたものを指定しています。
locationはvariablesセクションにある "location": "[resourceGroup().location]" という記述の通り、そのリソースグループが定義されたロケーションに合わせる設定になっています。
"properties" で、それぞれのtypeが要求する属性を指定していきます、仮想マシンの場合は "仮想マシンタイプ" "ストレージ設定" "OSプロファイル" "ネットワーク設定" "依存しているリソース" が主に設定を必要とする項目です。

この定義で仮想マシンが立ち上がるわけですが、実際のプロビジョニングは別に走ります。その指定をしているのが "osProfile" -> "customeData" です。
ここにBASE64エンコードしたスクリプト(今回はbashスクリプト)を書いておくことで、起動後にcloud-initによってプロビジョニングする形です。

#!/bin/sh
# init script for isucon6-qualifier

set -ex

export DEBIAN_FRONTEND=noninteractive
apt update
apt install -y --no-install-recommends ansible git aptitude
apt remove -y snapd

cd /tmp &&  wget -O- https://isucon6qimage.blob.core.windows.net/isucon6q/isucon6-qualifier.tar.gz | tar zxvf -
cd /tmp/isucon6-qualifier/provisioning/image/ansible
PYTHONUNBUFFERED=1 ANSIBLE_FORCE_COLOR=true ansible-playbook -i localhost, *.yml --connection=local -t prod
cd /tmp/isucon6-qualifier/provisioning/image
./db_setup.sh
cd /tmp && rm -rf /tmp/isucon6-qualifier && rm -rf /tmp/ansible-tmp-*
shutdown -r now

こういうJSONを書く時に、どういう構成になっているか視覚的に見られる方が良いでしょう。そんな時はARMVIZを使うと、図のようにどんな構成になっているかを可視化できますので、Azureでインフラ構築をする際にはぜひ活用してみてください。
f:id:myfinder:20160918184557p:plain

作成したJSONは、どこかパブリックな場所に置いて https://portal.azure.com/#create/Microsoft.Template/uri/ にエスケープしたURLを渡すか、Azureポータル管理画面の "テンプレートのデプロイ" から投入することもできます。
f:id:myfinder:20160918192239p:plain
他にはAzure CLIのコマンド "azure group deployment create -f " でもデプロイ可能です。

今自分が使っている環境の設定がどうなっているかを見たい、という場合 https://resources.azure.com/ にアクセスすると、閲覧可能なサブスクリプション配下の設定状況を見ることができるので、一度見てみると良いでしょう。

うぇー結局JSONかよめんどくせ〜と思ったあなたへ

AzureといえばMicrosoftが提供しているわけですが、MicrosoftといえばVSCodeも提供しているわけでして、このテンプレートもVSCodeで書くことができます。
azure.microsoft.com
このページに書いてある通り、"ext install azurerm-vscode-tools" すれば、補完を効かせて記述することができます。
VSCodeにはTerminalが統合されているので、そのまま "azure group deployment create -f " で手元からクラウド側に反映させることができるので、portalを触ることなくどんどんデプロイできます。

付録: ストレージアカウント?

初めて仮想マシンを作ったとき、"ストレージアカウント" という言葉が出てきて "???" となった方は多いのではないでしょうか。
Azureのストレージコンセプトは、ストレージサービスの中に複数の機能が存在する構成になっています。
f:id:myfinder:20160918155104p:plain
そして、そのストレージアカウントは、コンテナ―という箱と、その中に作られるVHDやTable、Queueで構成されています。
f:id:myfinder:20160918155224p:plain
単純なハードディスクサービスのようなものは今のところないので、この概念を頭の片隅に置いておいて下さい。

ひとりじゃなくてみんなで使うためのgolangの本 "みんなのGo言語"

9/9(金)発売の "みんなのGo言語" を Daisuke Maki (@lestrrat) | Twitter さんから頂戴しまして、一足先に読むことができました。感謝を込めて感想を書かせていただきます。

みんなのGo言語[現場で使える実践テクニック]:書籍案内|技術評論社

本書のカバー範囲と対象読者

本書はいわゆる "これからGoを始めたい" 人向けの本ではありません。 A Tour of Go でできるような最初のイロハはカバーされていません。 すでにGoを多少触り始めていて、一人だけで書くのではなく、周りの同僚や仲間など複数の人間が関わる環境でどのようにGoを活用していくべきかの指針をまとめたものと捉えると良いでしょう。 もちろんこれから始めたいという人に対して役に立たないわけではありませんので、特にチーム開発運用にGoを取り入れたいと考えている方には得られるものが多くちりばめられていると思います。

一通り読んだ所感

前述の通り、本書は第1章から "チーム開発" という言葉が出てくる通り、個人がひっそり写経するものではなく、多くの人どうしでGoを使った開発をしていくために "チーム開発の始め方" "マルチプラットフォーム対応" "実際のアプリ/CLIツール開発の実践" "テスト" "ハック的な黒魔術" まで幅広くテーマを扱っているので、広い視野を持って読むとより著者たちがこれまでの実運用でどのようなことを考えてGoを使ってきたか見えてくるのではないでしょうか。 特に3章はバージョン管理からチューニングまでをカバー範囲としてまとめられており、また、6章では長く運用を続けていくために必要なテストの手法が実践的にまとめられています。 私は普段、仕事でGoを書く立場ではありませんが、もし使う機会があればこの書籍を片手に実践していこうと思います。

おわりに

"みんなのGo言語" はその書籍名の通り、ひとりではなくみんなで使うときにどのように対応していけば良いか、著者一同の実践ノウハウが詰まっています。 著者一同が実践してきた内容や良いとされていることを一通り押さえており、ページ数も多すぎないので気軽に読むことができます。

もしあなたが "なんとなく気になってるんだけどどうやって使ったら、導入していったらよいだろう" とお悩みの場合は、本書は良いGoライフを得る一助となるでしょう。

最後に重ねまして @lestrrat さん、ありがとうございました。

クラウドを使い始めた初心者が脱初心者へ向けた第一歩を踏み出すための一冊

俺たちのリーダーこと @iara さんが著者に名前を連ねている、Amazon Web Services 実践入門を発売前に頂戴することができたので、御礼を兼ねて感想などをまとめさせていただきます。

twitter.com

www.amazon.co.jp


本書のカバー範囲と対象読者

本書は入門本と銘打たれている通り、IaaSと一部のマネージドサービスを紹介しつつ、UIとCLI両方での操作がまとめられています。
オンラインマニュアルにも同様のことは書かれているわけですが、本書では実際に手を動かしてみるにはこうしましょう、という切り口でまとめられているので "クラウドをこれから使いたい、でもどうやって触ったらいいかわからない" という人がまず写経的にやってみるのに適していると感じました。
他にも、 "今AWS使っているんだけどUIからポチポチとやっているだけだよ" という方がもう一歩深い使い方を学んでいくというところでも役立つと思います。
そういった側面が強いため、手順をまとめたマニュアル集といった趣になっており、事例や深く突っ込んだ使用法については言及されていません。

読んだ所感

リーダーの書いた5章を読んだ時に、"最近はむしろこういうネットワーク設計とかしなくなってきたな" と思ったところが気づきというか振り返りがありました。
従来のクラウド活用は、物理サーバとネットワークの設計をクラウドに持ち込んで再現するといった向きが多かったと思います。
自分自身がいち技術者としてクラウドを触り始めたのはIaaSであり、やはりそういった "既存技術をうまくIaaSに合わせていく" アプローチで作っていました。
最近のクラウド利用はそのようなVMを並べるところから徐々に、PaaS/SaaSを組み合わせてサービスを作る流れになってきています。サーバーレスアーキテクチャとか言われているようなやつですね。
PaaS自体はSalesforceGoogleのApp Engineに代表されるようなサービスが既に7年前くらいにはあったわけですが、その利点が広く取り沙汰されるようになってきたのはここ1〜2年かなと。
"as a Service" をうまく組み合わせてサービスを作る際には、IaaSでやっていたようなネットワーク設計は(PaaS/SaaSの陰に隠れて見えなくなり)利用者が考慮する必要がなくなるわけです。

とは言え "我々はクラウドフリーで常にVMと仮想ネットワークしか使いません" という主義の会社もあれば、"うちではas a Serviceをうまく組み合わせる人のことをインフラエンジニアって呼ぶよ" という会社もあるので、すぐに見えなくなるものでもないし、ましてネットワークの技術自体が無くなることはあり得ないのだけれど、うっかりすると触れる機会がどんどん少なくなっていくものになるなと。

そういった流れの良し悪しについては色々な言説ありますが、何を選べばよいかを判断できるような人材になったほうが、著者の言う "もっと生産的で有用な時間を確保できる" ようになると考えます。

おわりに

"Amazon Web Services実践入門" はAWSを使い始めた初心者が脱初心者へ向けた第一歩を踏み出すのにちょうど良いでしょう。
今の時代、"How"はAWSに限らず掃いて捨てるほど存在しているので、適切に選びとってサービスを作っていけるステップとして本書を使うと有意義だと考えます。

最後に、本書を贈っていただきました @iara さんに感謝申し上げます。ありがとうございました。

JAWS-UG Meguro #2 で "今更聞けないストリーム処理のあれとかこれ" というLTをしました。

最近はAzureをよくさわるんですが、AWSも引き続きホットなのでJAWS-UG Meguro #2へ行ってきました。
単に行くだけというのも面白くないので、最近いろいろ調べているストリーム処理回りについて一度整理しておこうということで、基盤と技術選択についての簡単なまとめをLTしたのでここに貼っておきます。

www.slideshare.net

これから始めたい人で、よくわからないけどとにかく始めて何かしら可視化したいという人は引き続き Azure Stream Analytics をお勧めします。

次回テーマは運営のAWS SAの方に希望を言うと良いそうです。
個人的にはAWS上でのネットワーク設計とかいろんな人の話を聞いてみたいかなと思ったりします。

YAPC::Asia 2015でAzureの話をした件とハッカソンの運営をした件

YAPC::Asia 2015 での発表

  • Discover the Microsoft Azure と題して、Azureの特徴ある "as a Service" の紹介と、その基盤について入門的な発表をいたしました。
  • 以前 "今後は複数クラウド事業者が提供するサービスを組み合わせて開発する流れが加速する" と書いたかと思いますが、各社特徴あるサービスがどんどん出てきており、かなり選択の幅は広がってきたと思います。
  • 今回紹介したPowerBIなんかを試してみたいという方は、下記の記事をご覧いただくのが手っ取り早いかと思います。 qiita.com

ハッカソンの運営

  • 2013年にも運営をさせてもらったわけですが、今回はGitHubさんの協力もあって、内容がかなり充実したものになりました。
  • YAPC::Asia 本編でトークのあった、Ben OgleさんのElectron話と、mizchiさんの開発話(から発展して逆質疑応答になっていたのは面白い展開でした)
  • 普段交流のない人とも交流ができて、いろいろとインプットを得ることができました。

所感

昨年 YAPC::Europe に参加した話をしたところ、今年は日本から8名(‼)参加するとのことで、いい流れだなと思います。 これまでの運営形態でのYAPC::Asiaはいったん終了という話ですが、builderscon.ioの発表もあり、カンファレンスは今後も盛り上がっていくといいなと思いますし、微力ながら協力できることは積極的にしていきたいです。

牧さんをはじめ、スタッフの皆様、とても良いイベントをありがとうございました。 過去最大の会場規模でも平和裏に進んだのは凄いことだと思います。

個人的なハイライト

  • SUZURIさんとmotemenさんの発想が完全に一致 f:id:myfinder:20150824114842j:plain