何でも屋エンジニアのブログ

ソフトウェア関連技術、コミュニティ、日々の雑貨

レポート:【パネルディスカッション】Slack, Qiita, GitHub 利用者 & 提供者の視点で見る、クラウドとツールの使いどころ

はじめに

AWSSummit 2016の「【パネルディスカッション】Slack, Qiita, GitHub 利用者 & 提供者の視点で見る、クラウドとツールの使いどころ」の内容をまとめたレポートです。セッション動画が公開されると思いますが、さしあたり参考になれば嬉しいです。

注:ですます/である調が混在しているのでご了承下さい。大きく聞き逃したところもあり、その点は記載してあります。 内容に誤りがある場合は指摘して頂けると嬉しいです。

本編

登壇者紹介

パネリスト
【Slack 利用者】岩瀬 義昌様(エヌ・ティ・ティ・コミュニケーションズ株式会社 技術開発部 エンジニア
【Qiita 提供者】髙橋 侑久様(Increments 株式会社 CTO)
GitHub 提供者】藤田 純様 (ギットハブ・ジャパン合同会社 カントリーマネージャー)

モデレータ
吉羽 龍太郎様(Ryuzee.com)

なぜこれらのツールやクラウドが受け入れられたのか

岩: チャットは昔からよく使われていた。irc hipchatなどあるが、slackは開発者の相性が良い。integrationが豊富でapiが公開されていることが重要。

吉: apiの影響が大きいとうことでしたがその辺どうでしょう。
髙: qiitaチーム、slack、githubは連携ができるというのが大きい。親和性が重要。

藤: api連携をしており、ユーザーがどんな問題を解決したいかが明快で、特定のドメインの問題を解決するに集中できる。 ほかの分野は連携するという感覚で、これがスピード感に繋がり受け入れられたのでは。

岩: 議論がslackで盛り上がった場合、slackはフローの情報でqiitaはstockの情報だが、フローの情報の共有はどうしているか。

髙: slackでというよりは、オフラインの会話をオンラインに持っていくというのが大事だと思っていて、良い方法を模索中。

藤:半分がリモートなのでリモート前提。オフラインの情報は、オンラインに残すように習慣づけるようにすべき。

受け入れられた背景、ビジネス的側面

藤: スピードだと思う。PCDAがあるが、Pの部分がすごく重いので動きが遅くなってしまったり、また、Pが一度決まるとそれを100%守らなければいけなくなってしまう。どうせやってみなければわからないんだから、早くトライして速く失敗して学ぶことが重要で、それを許容する心が組織には必要。

岩: 研究職は早く失敗するというのを求められている。本来やるべきことに集中するためにツールが大事になってくる。

ツールとクラウドの親和性

藤: 本業に集中するという観点から、繰り返しの同じ作業に関してはツールに任せることが大事で、CIなども同じ考え方だが、スピードを上げるために本業に集中し、組織としても強みを発揮する。ツールとクラウドの親和性はスピード、本業への集中。

(筆者:この間の話は聞き逃してしまいました。)

髙: オンプレミスが必要な理由は、結局社内の事情で、スピード感がなくなる。

吉: 逆にクラウドだからこその辛みはあるか。

藤: どこに情報を置くかというのが企業によっては問題になるので辛い。

吉: セキュリティとかポリシーとかですかね。そのような障壁がある場合、どうやってクラウドを導入していけばよいのでしょうか。

岩: エンプラなので導入ハードル高い。社内に通す時、偉い人よりミドルマネジメント層で技術のわかる人を巻き込んで行動した方がいい。slackの時は導入して使えることがわかると偉い人も使い出した。

吉: ラインの偉い人はそれで通るかもしれないが、例えば専任のセキュリティ担当と折衝するケースではどうだったか。

岩: お客様情報など重要な情報に関してはオンプレミス。qiita:teamなどは漏れてもokな情報しか書かない。 お客様の名前など出ていないか最初はチェックしていた。

髙: 導入に関して、ミドルマネジメント層のわかる人を巻き込んでやった方がいいが、いない場合もある。 導入して勝手にそのツールが広まることはないので、率先して使い広める人が必要。

吉: 社内エバンジェリストのような人が必要かな。でも一人だけだと辛い。

岩: 折れてからが勝負!

藤: 導入に関しては、社内のスターを巻き込んで使ってもらう。基本的に組織を管理する人たちにとって、みんなんが幸せに仕事してもらえれば嬉しい。ある例だが、現場からgithubムーブメントが起こり社内に広まった。導入された後に、スターたちが偉い人にお礼のメールをしたら「あ、こういうのが嬉しいんだ」と偉い人が理解したというケースがある。コミュニケーション大事。

岩: 社外コンサルに頼るという手もある

藤: とりあえず試すことが大事。

吉: 評価する前にとりあえず使うことが大事なんですね。

髙: あるツールを使うというよりは、既存の導入しているツールと連携させるイメージで使うような感覚で使うと定着する。

岩: kpiを求められた場合は?

吉: 人件費が一番高いので、今あるリソースを本業にどれだけ避けるようになるかを説得する。

藤: 数字だけでは理解できないものがあるので、その部分をアピールすることが重要。

吉: 合宿みたいに集まって、偉い人も集めて、作っているところを見せて理解を得たことがある。

吉: 言い残したことは?

岩: 内製頑張りましょう!採用にも繋がるので、ブランディングが大事。

髙: 他のツールを敵視(ライバル視)していない。それよも、情報共有の重要性が浸透していない問題に対し一緒に解決を試みる仲間と思っている。 情報共有の重要性に関する世論を形成したい。

藤: 経営資源は遜色ないけど、なぜこんなに外国と差がつくのかという話を聞くことがあるが、失敗を許容するマインドがないというのが大きな違いではないかと考えている。髙橋さんが「ムーブメント」と言っていたが、失敗してもいいムーブメントを起こしたい。不確実性の中、一寸先は闇なので、失敗することは悪ではない。

最後に

登壇者の皆様、非常に興味深いお話ありがとうございました!

参考

プロフィールは以下の詳細ページから取得しました。
http://www.awssummit.tokyo/devcon/index.html

JAWS-UG CLI専門支部 #38に参加してきた。

JAWS-UG CLI専門支部 #38 - 初級者歓迎 復習編: S3 + 静的Webホスティングに参加してきました。

JAWS-UG CLIの勉強会に参加しました。 jawsug-cli.doorkeeper.jp

JAWS-UG CLI専門支部とは

JAWS-UG CLI専門支部とは、AWS CLIの勉強会で、AWSのサービスをマネジメントコンソールからではなくCLIを使用して扱うことに特化した勉強会やイベントを開催している組織です。これまで3度ほど参加させて頂いていたのですが、「初級者歓迎」の回に参加するのは初めてでした。

流れ

  • CLI専門支部についての説明
  • 基本的なAWS CLIに関しての説明
  • S3に関しての説明
  • ハンズオン
  • 自己紹介&はまりどころ
  • 懇親会

メモ

  • CLI専門支部についての説明

    • 主催者の波田野さんがAWS SummitでCLIの専門支部を立ち上げる話をしたら引っ込みがつかなっくなったそうです笑
    • 当時はCLIを使用している人がかなり少なかったそうです。
  • Query(--query)

    • 出力結果から特定のノードを取り出すことができる
    • jqの代替 JAMES-Path表記
    • describe系のサブコマンドのfilterオプションで絞り込みをして、その結果からqueryオプションでノードを取り出す
  • 補完は以下で行えるようになる(bashの場合)

    • complete -C aws_completer
  • jsonlint

    • ヒアドキュメントでjson作るので壊れていないかチェックするために必要
  • CLIのupdate

    • 1.10.0にて(2016 1/21)acm(無料でssl証明書を作るサービス)追加
  • S3の説明

    • S3 はサービス名の頭文字がs3つだから
      • EC2の後がS3で、この後は「何4」がでてくるのかと期待していたそうです笑
    • オブジェクトストレージ(not ブロックストレージ)
    • 動的コンテンツがなければS3のみで完結できる
    • 動的コンテンツはcognitoとの併用で対応可
    • URLをつけないとファイル置き場、つけると外部から見える
    • URL自体をバケット名になるので、S3全体でバケット名はユニークである必要がある
    • オブジェクトは最小単位、内部的にフラットだが、名前で擬似的に階層構造を表現できる
  • cli s3コマンドの説明

    • ハイレベルS3コマンドはデフォルト出力がテキスト形式なので注意
  • その他メモ

    • cognitoと組み合わせて動的サイトも作成可能(cognitoでjsが動く)
    • webサイトホスティングでは、最初にあげたファイルにのみアクセス許可が与えられている(ファイルごとに許可与える)ので、バケット自体に権限を与える処理が必要。ポリシーを自分で与える必要がある( 以下の2.*で設定http://qiita.com/tcsh/items/dd99e9f7ced6406f8818
    • コマンドの成功or失敗に関しては画面に何も出力がないことを確認するかecho $?をする必要がある。基本的に何も出力されなければ成功と思って良い。
    • webサイトホスティングの際に、例えばindexページなどを認識させるためには以下のコマンドを実行する(参考の[JAWS-UG CLI] S3:#2 ハイレベルS3コマンドで静的Webホスティングより抜粋) aws s3 website "s3://${S3_BUCKET_NAME}" \ --index-document index.html \ --error-document error.html
    • バージョンによる挙動の違い
      • S3のバケット名は大文字使用が非推奨ですが、CLIのバージョンによって(もしくはPythonのバージョンなど他の環境によって)バケット名に大文字を使用した際の挙動が異なっていました。サポートして頂いた方や私は大文字バケット名指定によりエラーが出ませんでしたが、隣の方はエラーが出ていたそうです。

感想

今回は初級者向けということで、ゆっくりと進めて頂いたため余裕を持って進めることができました。他の回ではかなり急いでいた記憶があるので対照的でした笑。 初級者歓迎を冠していない回だとCLIを触ったことのない方は敷居が高いかもしれませんが、主催者の方も懇親会でおっしゃっていたように「出席して実行した結果を持ち帰ってもらえば後で復習できる」ので、出席してとにかく手を動かしてみるのが良いと思います。資料もかなり充実しています。 勉強会&懇親会ともに非常に楽しかったです。主催者の方、参加者の方々ありがとうございました。

参考

JAWS-UG CLI専門支部 #38 - 初級者歓迎 復習編: S3 + 静的Webホスティング - JAWS-UG CLI専門支部 | Doorkeeper

[JAWS-UG CLI] S3:#1 ハイレベルS3コマンドを使ってみる (バケットの作成から静的Webホスティング、削除まで) - Qiita

[JAWS-UG CLI] S3:#2 ハイレベルS3コマンドで静的Webホスティング - Qiita

[JAWS-UG CLI] S3:#4 静的Webホスティングのバケットポリシー設定 - Qiita

macのターミナルでvim使用時に、optionキーを押すとカーソルが十字に変わり任意の場所にカーソル移動ができる

macのターミナルアプリでvimを使用するときに、optionキーを押すとカーソルが十字カーソルに変わり、クリックした場所にカーソル移動ができます。

f:id:biibiebi:20150913150742p:plain

例えば、上記では「u」の二文字目にカーソルがありますが、この状態で「option」キーを押下したままカーソル移動したい文字のところでクリックすれば、その文字の箇所にカーソルが移動されています。

こういう子ネタ、以外と知らなくて恥ずかしいんですよね・・・

他には、viで画面が壊れたとき(Enterキーを押しても次のプロンプトが表示されないとき)にclearコマンドで直るとか、最近になるまで知りませんでした・・・恥ずかしいし知っていると便利なのできちんと勉強しないとという感じですね。

疑問点

macでカーソル付きのスクショを取る方法は以下のページに書いてあるんですが、十字カーソルのスクショを取る方法はあるのでしょうか。 どなたか知っている方いたら教えてくださると嬉しいです。 inforati.jp

AWSのELBへSSL証明書アップロード時に「Unable to parse key; the body is encrypted.」エラー

ELBへSSL証明書をアップロードする際に以下のエラーが出ました。

f:id:biibiebi:20150913140340p:plain

原因

  • opensslで秘密鍵を作成する際に、パスワード設定し暗号化していたことが原因だった。

確認方法

  • 秘密鍵を参照し、2行目・3行目に以下の内容がある場合は暗号化されている。
$ cat server.key 
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,E3CB8B1CE0E5CBDF7819D18627823618

〜略〜
-----END RSA PRIVATE KEY-----

対処法

  • 以下のコマンドを実行する。ただし、秘密鍵名は「server.key」、作業ディレクトリは秘密鍵を配置しているディレクトリである。
$ openssl rsa -in server.key -out server.key 
Enter pass phrase for server.key:  # ←ここで最初に秘密鍵を暗号化したパスワードを入力する
writing RSA key
  • 秘密鍵の内容確認。Proc-Type、DEK-Infoの記述がないことを確認する。
$ cat server.key 
-----BEGIN RSA PRIVATE KEY-----
〜略〜
-----END RSA PRIVATE KEY-----
  • 以上が終了したら、ELBに証明書をアップロードする。

f:id:biibiebi:20150913142608p:plain

参考

www.digicert.ne.jp

ELBへ証明書のアップロード方法を知りたい方は以下を参照下さい。

dev.classmethod.jp

Sublime Text 3 で日本語検索ができない問題の解決法

この問題に当たるのは2回目で、1回目は以下の記事を参考に解決できました。

Sublime Text 3 で日本語を検索したとき文字が消える不具合を直す - MEMOGRAPHIX

しかし、一度解決し正常に日本語検索できていたのにも関わらず、同じ問題が発生しました。そこで調べてみたところ

  • 上記ページに書いてある設定は全て反映されている
  • 以下のゴミファイルが ~/Library/Application Support/Sublime Text 3/Packages/Default/ にある
    .Default (OSX).sublime-keymap.un~
    Default (OSX).sublime-keymap~

という2点が判明しました。そこで、これらのゴミファイルを削除したところ正常に日本語検索が出来るようになりました。

駅データ.jpの駅データ保存スクリプトを書きました。

駅データ.jpとは、その名の通り駅データ(鉄道事業者・路線・駅・接続駅)が取得できるサービスです。基本無料で登録しデータを取得でき、より詳細なデータが欲しいときには有料プランも用意されています。

www.ekidata.jp

駅データ.jpから無料プランで取得したデータをデータベースに挿入するスクリプトを作成しました。
ソースは以下にあります。

github.com

  • 動作環境

  • 使い方

    • 事前準備:csvfilesディレクトリに駅データ.jpから取得したCSVを配備します(全ての種類のCSVファイルを登録する前提なので、足りないとエラーになります)。
      環境変数に以下の定義が必要です(MySQLじゃない方すみません)。

      • ユーザー:MYSQL_USER
      • パスワード:MYSQL_PASS
      • ホスト:MYSQL_HOST
    • 実行方法:スクリプトのあるディレクトリに移動し、以下のようにデータベース名を引数に取り実行します。
      [vagrant@localhost LineData]$ ./linedata_insertion.sh DBNAME

  • その他
    テーブル定義については、githubsqlファイルを置いてあるのでそちらをご参照下さい。

参考: 駅とか路線のマスターデータの入手方法 - Qiita

2015/6/17追記: データは駅データ.jpさんで管理しているので、テーブル定義に外部キー制約は入れておりません。

レポート:AWS Summit Tokyo 2015 デベロッパーが切り拓く、次の時代

AWS Summit Tokyo 2015に参加し、DevConの14:20~15:00の枠である
【パネルディスカッション】デベロッパーが切り拓く、次の時代
のメモを取ったので取り急ぎまとめます。

www.awssummit.tokyo

以下、伊藤様の発言は「伊:」大場様の発言は「大:」で表記します。特に表記がない場合(テーマ1など)はまとめている場合です。
また、発言者についてはまとめてしまっている部分もあり、100%ご本人の発言でない場合があります。

テーマ1 変わったこと、変わらないこと

技術的には、かつて技術はBtoBからBtoCへ流れていた。大手のベンダーから技術提案があり、それにキャッチアップすることが重要だった。ベンダーからロードマップが提示され、それにどう対応するかを考える部署すらあった。今は誰もロードマップを提示してくれない。 ロードマップが提示されないのは技術だけでなく、ビジネスも同様である。

テーマ2 技術を取捨選択した際の大原則・考え方はあるか?(個人として)

伊:オープンな方を選択してきたが、それが正解かは分からない。これはBtoCの業界にいたことに由来しているだけ。そもそも、技術を選択してキャリアを作り上げていくという考え方が良くないのでは。

大:技術を選択してこれでいこう!というのは怖い。今までの傾向としては、目的のものが7割8割しかできない、メインストリームからはおもちゃのような技術を選択してきた。おもちゃで遊ぶ感覚。

テーマ2-1 技術を選択するうえで、興味が先か、課題が先か

伊:課題が先。自分の場合、興味は課題から発生する。技術者が今使えるものを使用すると失敗する。この技術はここまでしかできないからという先入観が邪魔する。

大:課題の中で技術を楽しむ。やはり(ある程度は)背伸びはした方が良い。

テーマ3 これからの外部環境の変化をどう迎え撃つか

伊:マネジメント面、先に話に出たが、技術だけでなくリソース・スケジュール全ての面で曖昧になっている。Saasとかになってくると、様々な要素が不透明な状態で進めなければいけない。エンジニアはこの曖昧さに耐性がなければならない。曖昧な中で仕事の中で進まなければならない。

大:マネジメント面、環境は変化するということを受け入れられることが大事。決められた枠組みで粛々と進めたい人だと厳しい。
また、開発部として開発しかしないような枠組みにしてしまうと「開発だけしてれば良い」という考えを生むため失敗してしまった。事業部ごとに分割すると責任は曖昧になって個人にかかる負担が増えて大変だが、それは耐えなければいけない。また、フルスタック指向があるエンジニアでも、その時興味がある技術にロックインされるし、やりたいことがあっても不慣れな分野だと他に自分よりレベルの高いエンジニアがいたら遠慮したりする場合があるので、組織的にある程度ローテーションさせて新しい技術に触れさせる枠組みを作ることが大事。

以上です。

感想

特に印象に残ったのが「曖昧なまま進む強さ」が必要だとお二人ともに同意していた点です。これは私がSier系の下請けからWebサービス(BtoB)分野への転職した際に大変だと感じたことだからです。
当たり前ですが、サービスの場合はそもそも作るものやニーズが確定していません。もちろん、顧客対象となりうる方々からのヒアリング等を実施し可能な限り調査しますが、たとえその場合でも、サンプル数は不足しており無作為抽出ではないので、統計的なことは言えず、「このような分野・機能にニーズがあるという意見がある」としか言えません。そのような状態から、ユーザー目線で試行錯誤し何を作るか決めなければならないのです。
このように、サービスのケースでは不特定多数がお客様であり、ニーズや流れを捉えきれないとサービスを継続することは困難である一方、受託の場合はまず相手が決まっていて、話合いを重ねた上で何を作るか確定させることができます。仕様変更があったとしても(特定の)お客様の要望であるので、考えるべきリスクは仕様変更の影響で生じる工数追加などのコストが主です。これは、サービスの機能追加が必ずしもユーザーからの要望のみで行われるわけではなく、ニーズを生むために先手を打って機能追加を実施するのとは対照的です。当然、この場合はそもそも当該機能が必要とされる100%の根拠はなく、ユーザーの反応によっては徒労に終わるリスクがあります。 ビジネスモデルの差異はエンジニアの意識の違いにも反映されます。前職の場合は機能追加などの指示があっても「何を」作るのかは上から降ってくるので「どの位の期間で」「どのように」作ることだけを報告し考えれば良かったのですが、現職で同様の指示があった場合「それが本当に必要か」「具体的にどのような機能を作るのか」まで一エンジニアが考える必要があるのです。
これは私の経験に基づいた話で、お二人の話す「曖昧さ」が全て上記に合致しているのかを判断することはできませんが、大きくは外れていないのではと思います。 自分でも強く意識していた不確実性への対応が必要という点を、お二人のような方からの口からも聞けて良かったです。色々曖昧なまま進むことが良いのか、判断を先延ばしにしてももう少し不確実性を排除した方がいいのか、転職してからずっと悶々としていて、やはり決まらないことはあるので進みながら試行錯誤しその都度対応していくのが良いんだろうなぁと思いました。

追記 : 誤記を修正しました。感想を追加しました。