このエントリーをはてなブックマークに追加

タイムテーブル

先に感想

  • JAWS DAYS は初参戦
  • 最初の挨拶は聞けなかった
  • 会場運営、こなれてきている感じ。AWS Summitとかと同じイベント運営なのかな？
  • 一番面白かったのは、「開発するように運用するインフラ」「今こそ語るエンジニアの幸せな未来」「LT」
  • インフラの話は、こうあるべきっていう理想形が描かれていた気がした。真似してみたい
  • エンジニアの未来の話は、地方との給与格差の話が面白かった。ちょうど個人事業主になろうとしている僕には結構タイムリーに感じる話だった
  • LTは、みんなスベってなくてすごいと思ったｗ

10:10~

[Aceに聞け]cloudtrailとconfigによるセキュリティ強化のための第一歩 加納 良純 [富士通関西中部ネットテック株式会社]

  • 中央線東海支部　支部長
  • CloudTrailの概要
    • 操作の履歴（マネジメントコンソール、SDK、CLI）
    • JSON、S3バケットに保存、SNS通知
    • セキュリティ、コンプライアンス、ガバナンス
    • IaaS部分の「証跡」管理
    • APIコールを取得
  • 設定の仕方
    • ウィザード形式で簡単よー
    • 保存のファイル形式（フォルダ分け、ファイル名など）
    • 各リージョンのログを同じS3バケットに入れることができる。リージョンのフォルダ分けがある
  • ☆V字コントロール
  • 証跡管理
    • システム操作をログとっておく。第三者への証拠にも
  • 標的型メール
    • ばらまき型から、標的型へ
    • ☆RAT（リモート操作ツール）
    • 標的型メールでの侵入事例
      • （？これとCloudTrailどう絡む？）
      • この事例ではインスタンスを立てられていた
  • Glacier に入れたりするといいよね
  • ☆多要素認証、SNS認証
  • ログは最低1年残そう。半年バックドアに気づかなかった事例あり
  • ☆MFAデリート　（誤操作で消さない）
    • バケットのバージョニング設定の必要あり
    • ハードウェアとソフトウェアをえらべる

  • S3からGlacierへのアーカイブ設定（S3のGUIで）

  • 利用事例

    • Excelにデータインポート
    • SNSの通知と、バケット上のログのデータを付き合わせ。改善されていないことを確認

  • ☆GyzaMail（Macメーラー）

  • ☆Splunk（ログ解析）

  • configは時間切れ！

  • （ログのJSONの内容が気になる）

10:36~

[Deep Dive] まる見え、AWS!! ～CloudTrailとConfigからわかるAWSオペレーションのすべて～ 酒徳 知明 [アマゾン データ サービス ジャパン（株）]

  • SAさん。エンタープライズ、SI系のサポート。アーキテクチャ構築など
  • 「クラウドならでは、で気をつけることは？」
    • でもログおおすぎで利用のしかたがわからない、、、
  • API管理とリソースの管理（スケールが変わるから）
  • ↑に対応するのは、CloudTrailと、Config
  • Configについて、関係をもたせて、一元的にリソース状況をみることができる
  • CloudTrail
    • NonAPIEventもとれる（マネジメントコンソールへのログイン）
    • 「なるはやでONにしてください」
    • JSON形式での出力
      • どう使うか？
        • アラート、検索、可視化
  • アラート
    • パスワードを3回間違えた！の通知
      • CloudWatchLogs　MetricFilter （文字列のフィルタリング）
      • メトリクスフィルターのサンプル
        • rootログイン、認証失敗、特定インスタンスタイプの作成、セキュリティグループ変更
      • cloudformationのテンプレートで↑のサンプルとか作れる（一般的に監視すべき項目）
  • CloudTrailAPI Activity Lookup
  • ログをCloudSearchに突っ込んで検索したい
    • CloudTrailのJSONを、CloudSearchのテーブルに合わせないといけない
    • SNSのイベントをフックして、LambdaでCloudSearchに突っ込むと言うこともできる！
    • CloudSearchではなくElasticSearchとKibanaで可視化、も簡単！
    • ☆今は全リージョンでLambda動かないので、S3とLambdaは同じリージョンで動かす！
  • Configの話（CloudTrailをさらに後押し）
    • インパクト分析（設定変更を行うと、どれくらいのインスタンスに影響ある？）
    • リソース管理と、その履歴を持っている
  • ☆Stream,History,Snapshot
    • リレーション
      • まだサポートされてるAWSリソースが少ない（Redshiftとかまだ）
  • Config対応のサービスがいろいろある
    • 「LogStorage」
      • 古いAMIから立ち上がっているサービスの可視化

11:10-

[Aceに聞け] OpsworksでDevOpsを感じよう 古渡 晋也 [アイレット株式会社]

  • さいたま支部
  • CloudPack のひと。認定SA
  • プロビジョニング、設定管理、デプロイ、監視、アクセス制御
  • ChefやGitを使ってプロビジョニングとデプロイを
  • DevOpsについて
    • 国内と海外の現状
    • ☆OpsWorksのセミナー3/26にある
    • 課題が多い
      • 誰が何をやる？、線引き
      • セキュリティ
      • やった場合の投資利益率が不明
    • でも、なんか改善の実感はある！
  • スタック
    • トップ要素
    • デフォルト値を決めていく（リージョン、VPC、EC2のOSなど）
    • さきにVPCとサブネットを作っておかないといけない！
    • OpsWorksエージェントが入る。インターネット経由でAPIと通信するので、プライベートにしちゃうとAPIたたけなくてハマる。
  • レイヤー
    • アプリやミドルウェアのタイプ（Rails,Node.js,Javaとか）
    • ☆Static Web Layer
    • （？スタックに対して複数設定する？）
    • セキュリティグループの設定
  • インスタンス
    • インスタンスタイプ、スケーリングタイプ
      • スケーリングタイプ、手動、時間ベース、負荷ベースを選べる
  • リポジトリ（デプロイするアプリ）

  • デプロイ

    • アンデプロイ、ロールバックも可能
    • （DBのマイグレーションは？）

  • 監視

  • パイプライン

    • スタック作成、レイヤー→インスタンス→アプリ→デプロイ→監視

  • 継続コード管理　Git系でやる

  • 継続的な運用　デプロイ、モニタリングも

  • 苦手なもの

    • 商用のエンタープライズアプリなど、プライベートでしか動かしちゃいけないもの。
    • すべてが当てはまらない例もあるので

  • DevOpsは簡単じゃないし、OpsWorks使ったからそれができるようになるわけじゃない

  • （？Chef以外にも選択できる？）

  • （？テストは組み込めるのか？）

    • →Jenkinsの例があった

11:36-

[Deep Dive] AWS OpsWorksの仕組みと活用方法のご紹介 舟﨑 健治 [アマゾン データ サービス ジャパン（株）]

  • SAさん
  • 活用例の紹介

  • 初心者向けの活動など

  • OpsWorksつかったことありますか？　ノ　→　少ない

  • OpsWorksを使うと、自動化できる領域が大きい！

  • OpsWorksエージェントによって、自動構成ができる

    • OpsWorksエンドポイントにポーリングしている
    • ChefZero（Solo）を実行する（Chefサーバは要らない）
    • レシピのリポジトリと、アプリのリポジトリは別々に指定可能

  • スタックコマンドと、エージェントコマンド

    • エージェントコマンドはインスタンス内に入って実行する。利用はおすすめしない

  • 任意のタイミングで、インスタンスにスタックコマンドを実行可能

  • OpsWorksの「ライフサイクルイベント」でコマンドを実行する！

    • 5つのタイミングがある（セットアップ、デプロイ、コンフィグ、レシピ実行、シャットダウン）

  • スタック内に複数インスタンスあるばあい、後から追加してきたインスタンスのConfigureイベントのタイミングで、すべてのインスタンスにConfigureイベントが来る

  • シャットダウン時にはシャットダウンされたインスタンス以外のインスタンスにConfigureのイベントがくる

  • Configureイベントに何を入れるかが重要

  • 構成情報の管理

    • 構成情報内に、DB接続情報を入れておくことができる
    • DynamoDBとかElastiCacheとかも構成情報としてJSONに入れておくことができる

  • Opsworksエージェントがアウトバウンド使うので、そこは注意

  • 利用例

    • デプロイを自動化
    • Gitのpushを、JenkinsレイヤーのJenkinsインスタンスがフック→ビルド成功後にJenkinsがDeployコマンドを実行
    • オンプレミスにOpsWorksエージェント入れることで、オンプレサーバもOpsWorks管理可能！
      • 注意点はUbuntu！

  • ハンズオン資料があるので、それ使ってみてね

  • （つかってみないことには、という感じが強い）

  • （スタックコマンドのテストはどうする？）

  • （「24/7」の読み方がわからない）

12:00 - ランチ。お弁当出た

13:00-

DevOps が普及した今だからこそ考えるDevOpsの次の姿 安達 輝雄 [株式会社ソニックガーデン]

  • 自称フルスタックエンジニア
  • DevOpsはやり初めてはや数年。当たり前？
  • その場でアンケート、（DevOps）実践できている人　ノ　→　少ない？
  • 本セッションでのDevOpsの定義
  • SonicGardenの事情
  • HerokuかAWSか。AWSについての話
  • OpsWorks利用している
    • なぜ使うのか？
      • ELB、RDS、☆AutoHealing、Load/Time Base Scaling、☆Clone Stack（別のシステムでも丸っと使える）
  • デプロイの自動化　
    • ☆Breakman（rubyのセキュリティチェック）
    • ☆wercker　pushのフック。自動テスト。自動デプロイ

  • Paas、Saas を利用

    • ☆SideCI（自動コードレビュー）、☆Mandrill（メール送信）☆Papertrail（ログ管理、検索）、☆bugsnag（エラー監視、管理）、NewRelic

  • 「納品のない受託開発」

    • 40システムを運用している（12人。うち2人は新人）
    • DevOpsに変化

  • ボトルネックの変化

    • サービスの開始/運用のための必要な準備
    • サービスを構成する要素
      • デザイン、マーケティング、データマイニング　←　この辺にも効率性が求められ始めた
    • Devはプログラマだけじゃない。デザイナ、マーケター、アナリティスト

  • Devのなかだけでも障壁が

    • 専門領域が違うことにより、スピーディにやりたいことができない。
      • プログラマがどうすればいいかわからない

  • ↑へのSonicGardenでの取り組み

    • デザイン
      • Bootstrap,☆Compassで、プログラマも簡単にスタイリッシュなデザインを。
      • ↑だけじゃない、さまざまなデザイナーの作業。クリエイティブな部分も。
      • このあたりはプログラマがすぐに習得できない。でも、理屈だから
      • ☆「WEBエンジニアのための　WEBデザイン実践入門」
      • デザイン界隈のすごい人に、メンターをお願いして教えてもらっている
      • どういう効果があったか
        • 強調したい情報を目立たせる、情報をゾーニング（整理）
        • ページごとにコンバージョンを意識
    • マーケティング、行動分析
      • 自社サービスで、ばりばり活用できていない。
      • でもサービスを広げるためには重要
      • WEBマーケティングを得意とするお客さんから合同勉強会＆実践
      • ビューなど都度エンジニアがやるのは大変
        • デプロイ不要な仕組みを自分で作った！
      • 最初からSEOに強くなる
      • デプロイなしでビューのフレーズを変更できる仕組みの開発

  • Opsもプログラミングできてあたりまえ

  • デザイナーなど、他分野への理解も広げて行くのがどうか

  • 質問タイム

    • →Opsは分かれていない
      • AWSは得意で一応担当だけど、ほかのこともやる。
    • 10人で40サービス トラブルと障害の対応はどうしている？　同時多発でおこって苦労したところは？
      • アプリレイヤーは、Railsだから、だれでも修正可能。インフラもOpsWorksで自動スケールするから、大丈夫。セキュリティ対応はちょっとあったけど、それでもまあ大丈夫。
      • 同時のやつも、同じ構成で建っているから、一度手順を確立すれば楽。
    • 40サービスを同じ構成で。バージョンの入れ替えとか、言語の入れ替えとか、どうなっていく？
      • Railsもだいたい最新に更新している
      • 40サービスは、HerokuとAWSが半々。Herokuの場合は、全然手を動かさない。
      • バージョンアップは自動テストで効率よくできるように
      • OpsWorksで、新旧の入れ替えは2つのスタックを立ち上げて、ELBを切り替えていく
    • ほかの構成管理ツールがいいとか、なったときはどうする？
      • どうしても使いたいものがあれば、全部移行する！
    • 大きいバージョンあっぷや、全とっかえなどある？
      • Puppetをつかってた→CustomJSONのユーザデータ→OpsWorks
    • NewRelic以外につかっている？
      • Nagiosつかったり、Munin使ったり（自社内で立ててる）
    • NewRelicとMuninの使い分けは？
      • Saas利用不可の会社のため
    • Railsのロケールファイルの編集（「copytuner」）は公開しない？
      • ニーズがあれば公開するよー
    • どの技術を使う、という判断はどうしている？
      • HerokuかAWSかの判断は、Herokuの制約。長い通信タイムアウトなどが例。
      • 新しいサービスの判断。試してみて、ほかでも使うかどうか。

  • まとめ

    • エンジニアに幅広いことが求められてるようになるよー
    • スキルが広がっていく

  • （？OpsWorksの、Clone Stackはアカウントまたげないよね、、、？）

14:00-

開発するように運用するインフラ 土居 正行 [Kaizen Platform, Inc.]

  • @m_doi
  • カイゼンのインフラ屋さん

  • DynamoDB、Kinesisがお気に入り

  • おしながき

    • 開発側のワークフロー
    • 運用側のワークフロー
    • これからのワークフロー

  • KaizenPlatform

    • ABテスト
    • JSのサイト埋め込み。ログを送信
    • ログ受けとりの部分、よくある構成
    • Saasもたくさん使ってる

  • 開発のフロー

    • githubとCircleCI
    • WorkInProgressで空のプルリク → 開発→レビュー→QA→本番リリース
    • 開発プロセス
    • ボットがランダムでレビュアーを選ぶ
    • メンションでレビュー時の注意点を
    • QAブランチへマージ→本番へ　CircleCIを活用
    • CircleCI UnitTest,E2ETest
      • fooブランチにpushしたらbarする
      • fooとbarを細かく制御可能
    • ボットにQAブランチへのマージお願い
      • QA環境にデプロイ
      • 本番環境へのデプロイプルリクが作成
    • E2Eテスト。heaaless ブラウザでテスト
      • インフラエンジニアにも役に立つ
    • 全部OKなら本番へデプロイ
      • 本番環境にE2Eテストもやる
    • GithubとCircleCIとチャットの操作で完結〜

  • 運用のワークフロー

    • 構成管理　Chef,Github,circleci
    • WIPでプルリク　→ レシピ作成（vagrant やEC2など）　→　レビュー　→　構築テスト（Dockerで構築、Serverspecによる検証）　→　本番適用
    • CircleCIのジョブの進行状況の内容見れる（Jenkinsとまあ同じ）
    • hubotにお願いすることで、チャットに履歴が残る！
    • 構成変更後のe2eテスト。本番に対してもちゃんと確認できる。インフラを変えても、ちゃんと動いているかどうか（インフラ屋にすごくうれしい！）

  • 開発プロセスと運用プロセスの比較

    • （あれ、同じ？）
    • プロセスが同じメリット
      • 開発⇔インフラがお互いの変更をすることができる
      • 開発側でやりたくなる変更もインフラやることが　できる
        • いちいちミーティングとかして、いつ本番にはいる？

  • Kaizenエンジニア行動指針

    • 官僚的にならない！（○○さんに許可をとってから、）

  • @mirakuiさん　「（インフラエンジニアは）権威的にならない」

  • まとめ

    • 開発と運用のプロセスを合わせる
    • 開発も運用に参加する敷居を下げる
      • やろうと思えばできる環境をつくる
    • インフラエンジニアこわくない
      • 官僚的・権威的じゃないよー

  • おまけ

    • セキュリティアップデート
      • チャットでbotに指示
      • yum --security check-update の結果を取得→プルリク作成
      • レビューして問題なければプルリクをマージ。→実際にアップデート
      • ただし再起動が絡むものはちょっとめんどくさい
    • CircleCIがボトルネックになる
      • 並行実行でキューがすごくたまっちゃう（待ちがおおい）
      • お金で解決するか、ジョブの高速化（Dockerなど）

  • いいSaasの紹介

    • ☆Bugsnag アプリエラーの検知とダッシュボードまとめ（いつ、どのくらい発生したか。通知もできる。スルーもできる）
    • ☆Pingdom　複数拠点からエンドポイント監視
    • ☆PagerDuty　障害通知 on-call scheduleに従って、電話/SMS/スマホアプリの通知
      • ☆Sensu（監視）,Pingdomとの統合も簡単

  • QA

    • チャット運用。外部からの接続はセキュリティどうする？
      • ポリシー次第ではできないけど、会社的には許容している
    • E2Eテスト、ChefをCIツール実行で、ツールが落ちたときは？
      • CircleCIは落ちたあと、SSHログインできるので追跡している
    • 官僚的にならない　責任をとらない
      • レビューを通すのでレビューを通した人
    • CircleCIとの比較は？
      • CI中にログインできたりとか、細かい機能の提供
    • Saasの採用基準　
      • 人数が増えるとすごく高いものがある。　人数に対してお金を払えば解決できるなら、コストに見合うので、ということで採用したりする
      • ロックインについては、そのサービスの安定性を見たりする。

15:00-

[Aceに聞け] EC2はもう不要？Lambdaってなにができるの？ 白石　正行 [株式会社鈴木商店]

  • 入門
  • 業務利用はまだしていない
  • これから使おうと思っている人向け

  • インフラちょっと苦手　Node.js歴（1週間）

    • S3へのオブジェクト通知をフックして、何かやる（画像がアップされたらサムネをつくるとか）

  • トリガの設定

    • S3,DynamoDB,Kinesis,CloudTrail

  • コードの設定

    • アップロードするか、画面で書くか、CLIでアップするか。言語はNode.js

  • サムネイルを作るサンプルの実行

  • どんな利用シーンがあるか

    • データ、ファイルの加工
    • ファイルのメタ情報を　DBに保存
    • 通知　（SNS、SQSを利用）

  • 料金

    • リクエスト数＆メモリｘ実行時間
    • 無料利用枠は、初年度だけじゃない

  • アプリ寄りの処理をインフラ側へ持って行ける

    • （↑ほんとにこれはいいこと？）

  • 外部ライブラリの活用

    • （↑何が使えるんだろう。画像ライブラリとか、おそらくできるんでしょうけど。形態素解析とか）
      • →パッケージングしてやればOK

  • （？失敗したりしない？）

[Deep Dive] AWS Lambdaを紐解く 西谷 圭介 [アマゾン データ サービス ジャパン（株）]

@Keisuke69

  • SAさん
  • Lambdaがない場合
    • 仕組み作り
      • 環境構築
      • スケール
      • モニタリング
  • lambdaなら
    • ビジネスロジックにフォーカスできる
    • コードが動いた時間だけに課金

  • 料金体系

    • コンピュート時間

  • 例　DynamoDBへの書き込みをトリガーに、データの更新やプッシュ通知など

  • 例　CloudTrailのログ解析→通知

  • 例　MobileSDKから直接LambdaFunction実行

  • /tmp いかにread/writeが可能

  • コンテナ内で実行されている

  • ネイティブライブラリも利用できるよ

    • ビルドしてパッケージングしてやる必要がある

  • ImageMagickは最初から使える

  • ログインはできないよー

    • （コンテナ技術だろうから）

  • アウトバウンドはすべてOk。インバウンドは不可

  • カスタムイベント

    • JSON形式の値

  • context.done() ファンクションが終了したものと見なす

  • イベント pushモデルと、pullモデル

    • push モデル。3回までリトライ
    • pullモデルはポーリング。準女性あり。

  • ファンクション作成時の注意

    • IAMRoleを正しくセットアップする
      • Execution roles, Invocation roles
    • 再帰処理は慎重に
      • 無限にループする可能性あり

  • 実行コンテナのライフサイクル

    • 作成時
    • 終了時は4つある　（タイムアウト、Called Termination, Default termination, クラッシュ）

  • 再利用

    • 以前のコンテナが再利用されることがある

  • プロセスの凍結と再開

  • 制限事項（リソースなど）

  • 4/9 にLambdaのハンズオンやる

16:00-

今こそ語るエンジニアの幸せな未来 田中 邦裕 [さくらインターネット株式会社] / 堀内 康弘[旅人] / 比企 宏之[cloudpack]

  • 田中さん（モデレータ）
    • さくらインターネット
  • 2015年、cross　でもやったネタ

  • 堀内さん　旅人

    • 技術顧問（マネーフォワード、Retty、PandaGraphics、）

  • 関東か非関東か

    • 地方が多いかどうかを聞きたかった

  • 今の給与に満足している？

  • エンジニアの幸せについて

  • 働きやすさと働きがい

    • 働きやすさは　待遇面
    • 働きがいは　ポジティブな成長に向かう感じ

  • 比企さん　働きやすいが、たいへん

  • 堀内さん　AWS働きやすかった。自由に働けた。意外と休んでる。

  • 働きやすさと働きがいの色分け

    • バランスがとれているかどうか

  • 比企さん　SIerのとき高かったけど、1人月を超えられると思ったから、今の会社に。

    • きっかけは、2011でJAWSUGに大阪やっていた。コミュニティに参加することでエンジニアの価値観が変わっていた。黒字で給料を上げる、が前の価値観

  • 堀内さん　↑　SIerのことはやったことない。楽しいことをずっとやってきた。

    • お金をたくさんもっていることが価値観ではない。500~600万くらいでやっていた。30歳くらいまで。

  • 田中さん　不満足と満足。不満足が解消しても、不満がない状態にしかならない。

  • 堀内さん　興味がうつってくる、飽きてくると、ほかのことに転職というながれが。

  • 田中さん　満足がえられない（研鑽できない、飽き）

  • 比企さん　クラウド業界満足はしている。大変すぎる

  • 堀内さん　働きやすさでやめたわけではない。最初はPerlをずっとやってた。ブログを書いてみる。cpanも書いてみる。楽しかったから。プログラムを書くのがemacsで小指が痛くなった。次はpython（gumi）。pythonの次にAWS。gumiが大きくなってくるときにいた（5人→1年で100人とか）。次にエンジニアのマネジメントの機会←楽しいのかな？　エバンジェリストの仕事を紹介されて、やめる

  • 比企さん　SIer。VBはやってた頃に、新人。ずっと同じ画面作ってるのがやだった。つぎはモバイル開発。自分の好きなことを選べてた。前職ではクラウドという価値観はなかった。リーマンショックの中戦っていた。←エンジニア（1人月）の価値観に疑問を持った。　エンジニアとしてやりたいことができる方がいいが、お金はあった方がいい。

  • 田中さん　年齢かける~15 x 18ぐらいはもらえた方がいい？　働きにくい状態はどこ？最低限の働きやすさ

  • 比企さん　前々職、32歳、取締役、CTOでやめた。給料高かったけどやめた

  • 堀内さん　働きやすさと働きがいはいろいろと変化してきた。昔はやってることが楽しければよかった。給料がよくなってくると、お金考えなくなってよくなる。何か興味をもてることがあるとほかのことを考えなくよくなる。奥さんが最近大事。仕事のやる気が無い時期に、自分のことを手放しで認めてくれる人がいるのは重要。

  • 田中さん　☆「イノベーションオブライフ」過去は取り戻せない

  • 比企さん　好きなことをやり続けて、父親としてはNGだと思う。たぶん捨てられる。昔は貧乏だったので、食われない状況は作らない。仕事でも家庭でも結果だすけど、好きなことはやらせてくれ、という感じ。生活感がない。

  • 堀内さん　家族仲はいい。エンジニアはものをつくれるひと。ものを作れる人は未来明るい。いろんな働き方ができる。エンジニア以外のひとってリモートワークとか難しい。どの会社もエンジニアが足りない。人の能力は変わらないけど、そこにやる気をかけ算。つまらないと思うと、アウトプットが小さくなっちゃう。10年前よりWEBエンジニアの給料あがっている。どんどん転職していけば、いつかは成功できるのでは

  • 比企さん　地方は問題。大阪は経営者は買いたたく（ねぎってなんぼ）。←このなかでエンジニアはコストになっちゃってる。地方のエンジニアが救われるのでは？

  • 田中さん　北海道と東京で給与水準を合わせている。怒られたこともある。

  • 比企さん　CloudPackも地方でも給与水準合わせている。地方でも高い値段でエンジニアを雇えるなら、その会社は儲かっている証拠。そういう良い会社になっていってほしい。

  • 堀内さん　エンジニア側の問題。スタートアップの会社でもエンジニアが注目される会社とそうでない会社。経営陣に技術がわかるかどうか。エンジニアが自分がこれだけやれているんだという気持ちをもって、アピールする。チームの中での当事者意識。下請けの意識や使われているという意識をやめるべき。

まとめ

  • 比企さん　クラウドをつかって成果を上げて欲しい。特に地方の方。
  • 堀内さん　エンジニアは勝ち組。好きだを一つ極めていくといいかも。

17:00-

懇親会今回もやります！ 熱いLTバトル！A-1 GP！ #a1gp

お疲れ様でした