Google Custom Search APIを叩いてみた

まえがき

ふーむ、と思ってちょっと調べてみました。
Googleのことだから多分検索用のAPI用意されてるだろうし、そこにデータ入ってないかな?がスタートです。

Google Custom Search APIについて

調べてみたら、Google Custom Search JSON APIというものがあるみたいです。

qiita.com

手順については上記ブログで記載があるので割愛します。
一箇所だけ、get_search_response.py内の

def getSearchResponse(project_id, keyword_id, keyword):

は呼び出し元がtarget_keywordだけしか使って使っていなさそうだったので、それ以外の引数を消しました。

def getSearchResponse(keyword):

取れたデータについて

target_keywordを自分のブログのURLを指定してみました。

    target_keyword = 'https://www.st1t.com/entry/2018/12/27/174532'
$ jq . data/response/response_20181228.json 
{
  "snapshot_ymd": "20181228",
  "snapshot_timestamp": "2018/12/28 20:34:11",
  "response": [
    {
      "kind": "customsearch#search",
      "url": {
        "type": "application/json",
        "template": "https://www.googleapis.com/customsearch/v1?q={searchTerms}&num={count?}&start={startIndex?}&lr={language?}&safe={safe?}&cx={cx?}&sort={sort?}&filter={filter?}&gl={gl?}&cr={cr?}&googlehost={googleHost?}&c2coff={disableCnTwTranslation?}&hq={hq?}&hl={hl?}&siteSearch={siteSearch?}&siteSearchFilter={siteSearchFilter?}&exactTerms={exactTerms?}&excludeTerms={excludeTerms?}&linkSite={linkSite?}&orTerms={orTerms?}&relatedSite={relatedSite?}&dateRestrict={dateRestrict?}&lowRange={lowRange?}&highRange={highRange?}&searchType={searchType}&fileType={fileType?}&rights={rights?}&imgSize={imgSize?}&imgType={imgType?}&imgColorType={imgColorType?}&imgDominantColor={imgDominantColor?}&alt=json"
      },
      "queries": {
        "request": [
          {
            "title": "Google Custom Search - https://www.st1t.com/entry/2018/12/27/174532",
            "totalResults": "1",
            "searchTerms": "https://www.st1t.com/entry/2018/12/27/174532",
            "count": 1,
            "startIndex": 1,
            "language": "lang_ja",
            "inputEncoding": "utf8",
            "outputEncoding": "utf8",
            "safe": "off",
            "cx": "000541688366129963034:bisdpfb8q-4"
          }
        ]
      },
      "context": {
        "title": "カスタム検索エンジン"
      },
      "searchInformation": {
        "searchTime": 0.142453,
        "formattedSearchTime": "0.14",
        "totalResults": "1",
        "formattedTotalResults": "1"
      },
      "items": [
        {
          "kind": "customsearch#result",
          "title": "検索システムを作る上で役立つ本 - infra.log",
          "htmlTitle": "検索システムを作る上で役立つ本 - infra.log",
          "link": "https://www.st1t.com/entry/2018/12/27/174532",
          "displayLink": "www.st1t.com",
          "snippet": "1 日前 ... ... 初めて見たくらい良書だと思いました。 買うのが不安な方は立ち読みだけでもいい\nのでまずは見てもらうといいのかなーと思います。 https://www.kindaikagaku.co.jp/\nimg/book/ · https://www.kindaikagaku.co.jp/information/kd0577.htm ...",
          "htmlSnippet": "1 日前 <b>...</b> ... 初めて見たくらい良書だと思いました。 買うのが不安な方は立ち読みだけでもいい<br>\nのでまずは見てもらうといいのかなーと思います。 <b>https</b>://www.kindaikagaku.co.jp/<br>\nimg/book/ &middot; <b>https</b>://www.kindaikagaku.co.jp/information/kd0577.htm&nbsp;...",
          "cacheId": "61D4dXdaVo0J",
          "formattedUrl": "https://www.st1t.com/entry/2018/12/27/174532",
          "htmlFormattedUrl": "<b>https</b>://www.<b>st1t.com/entry</b>/<b>2018/12/27/174532</b>",
          "pagemap": {
            "cse_thumbnail": [
              {
                "width": "170",
                "height": "216",
                "src": "https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcShrcLWXuO7jeYzIprdKhrVSMarpKuAKRZZyzQUgBSu4_Dm_JVH-wAukx8"
              }
            ],
            "metatags": [
              {
                "viewport": "width=device-width, initial-scale=1.0",
                "og:title": "検索システムを作る上で役立つ本 - infra.log",
                "og:type": "article",
                "og:url": "https://www.st1t.com/entry/2018/12/27/174532",
                "og:image": "https://www.kindaikagaku.co.jp/img/book/KD0577-170.jpg",
                "og:description": "まえがき 最近Elasticsearchを触る機会が増えつつあるのですが、 そもそも検索を行う際に何をどうしたら良いのか全くわからんって時のためおすすめの書籍をいくつか紹介したいと思います。 また、達人出版社さんから冬休み合同フェアというのが開催されており、 こちらだと電子書籍が半額で買えるのでオススメです。 tatsu-zine.com 初級編 Elasticsearch実践ガイド book.impress.co.jp 全文検索を行おうと思ったら大体最近の流れはElasticsearchにいきつくパターンが多いかと思います。 ただ、公式のドキュメントは英語だったり、そもそも全文検索の界隈で当…",
                "og:site_name": "infra.log",
                "article:published_time": "1545900332",
                "twitter:card": "summary_large_image",
                "twitter:image": "https://www.kindaikagaku.co.jp/img/book/KD0577-170.jpg",
                "twitter:title": "検索システムを作る上で役立つ本 - infra.log",
                "twitter:description": "まえがき 最近Elasticsearchを触る機会が増えつつあるのですが、 そもそも検索を行う際に何をどうしたら良いのか全くわからんって時のためおすすめの書籍をいくつか紹介したいと思います。 また、達人出版社さんから冬休み合同フェアというのが開催されており、 こちらだと電子書籍が半額で買えるのでオススメです。 tats…",
                "twitter:app:name:iphone": "はてなブログアプリ",
                "twitter:app:id:iphone": "583299321",
                "twitter:app:url:iphone": "hatenablog:///open?uri=https%3A%2F%2Fwww.st1t.com%2Fentry%2F2018%2F12%2F27%2F174532",
                "twitter:site": "@st_1t"
              }
            ],
            "article": [
              {
                "name": "検索システムを作る上で役立つ本 - infra.log",
                "image": "https://www.kindaikagaku.co.jp/img/book/KD0577-170.jpg"
              }
            ],
            "cse_image": [
              {
                "src": "https://www.kindaikagaku.co.jp/img/book/KD0577-170.jpg"
              }
            ]
          }
        }
      ]
    }
  ]
}
$ 

jqで日付とタイトルを抜き出す

article:published_timeはUNIXタイムなので人が見るときは変換したほうが良いかも。

$ jq '.response[].items[].pagemap.metatags[]["og:title","article:published_time"]' data/response/response_20181228.json 
"検索システムを作る上で役立つ本 - infra.log"
"1545900332"

あとがき

というわけでさくっとやってみたのですが、まだ課題があります。
SEOは門外漢すぎて知らなかったのですが、
このarticle:published_timeはOpen Graph Protocol(OGP)というSEO対策のためにホームページ作成者がよしなにいれこむものみたいでした。
(なるほど、ブログにリンク貼ると以下のように画像と説明がでるのもOGPのおかげだったんですね。。。)

www.asahi-net.or.jp

なので、ものによってはやはりmetaタグがなかったり、article:published_time自体がなかったりしました。
Googleが初めてIndexしたタイミングの日時が取得できることを密かに期待していたのですが、残念💧

検索システムを作る上で役立つ本

まえがき

最近Elasticsearchを触る機会が増えつつあるのですが、
そもそも検索を行う際に何をどうしたら良いのか全くわからんって時のためおすすめの書籍をいくつか紹介したいと思います。

また、達人出版社さんから冬休み合同フェアというのが開催されており、
こちらだと電子書籍が半額で買えるのでオススメです。

tatsu-zine.com

初級編

Elasticsearch実践ガイド

book.impress.co.jp

全文検索を行おうと思ったら大体最近の流れはElasticsearchにいきつくパターンが多いかと思います。
ただ、公式のドキュメントは英語だったり、そもそも全文検索の界隈で当たり前に使われる用語が普通に出てきて辛いという方へちょうど良いと思います。

  • 良い点
    • 日本語の書籍で新しい(2018/6/15発売)
    • 図解が多い
    • 基礎から書いてある
    • 全文検索そのものだけでなくTipsが充実している
    • 日本語の検索も少しだけど載っている
  • ここがあればもっと嬉しかった
    • 日本語検索についてもう少し記述があると嬉しかった(sudachiとか)

Apache Lucene 入門

gihyo.jp

いきなり絶版の本を紹介してすいません。。。
ただ、この本は、全文検索?なにそれおいしいのって方には凄く良かったと記憶しているので、ヤフオクやメルカリで安く手に入りそうだったら購入してみるのも良いかもしれません。

  • 良い点
    • 全文検索の最初の一歩となるところが記載されている
  • ここがあればもっと嬉しかった
    • 電子書籍化
    • 古いので(2006/5/17発売)、改訂版の出版

中/上級編

こちらで紹介する本はまだ私もきちんと読み切っていないのですが、
途中や一部だけでも十分良い本だと思ったのでリンクだけ紹介しておきます。

形態素解析の理論と実装

なんとなくMecabについても書かれているっぽいって噂だけで達人出版社のフェアでゆるふわに買っちゃいましたが、めっちゃ良いです!
日本語における形態素解析についてきちんと書かれているし、数式は学のない自分には難しすぎて頭がフットーしそうですが、
今まで見てきた日本語における形態素解析についてここまでキチンと書かれている本は初めて見たくらい良書だと思いました。
買うのが不安な方は立ち読みだけでもいいのでまずは見てもらうといいのかなーと思います。

https://www.kindaikagaku.co.jp/img/book/KD0577-170.jpg

https://www.kindaikagaku.co.jp/information/kd0577.htm

検索エンジン自作入門

gihyo.jp

Logstashの最近のアップデートで面白そうなものをピックアップしてみた

まえがき

2018年Elastic Stackアドベントカレンダーの20日目の記事で代理で書きます!
今回はLogstash6.1.0から6.5.4までで面白そうなアップデートを簡単に紹介していきます。

qiita.com

Logstash Release notes

www.elastic.co

DNS Filterの更新について

DNS FilterはIPを逆引きしてフィールドに追加することができます。
例えば、Webサーバ等のアクセスログのx-forwarded-forを逆引きでホスト名を引いた情報をElasticsearchに投入することで、アクセス元を簡易的にわかるようにしたりします。
これはセキュリティを意識するときとかに、アクセス元がAWSだったり、海外の全く関係なさそうなところだったらBAN判定の一つの要素にできるときがあります。

アップデート内容について

github.com

Logstash 6.3.1からDNSの問い合わせ結果でキャッシュを有効化したときに、クエリがネームサーバに同期的に問い合わせていたため、応答待ちで他の処理待ちがあった状況を解決しているみたいです。
DNS Filterをキャッシュ機能を有効化にして6.3.0以下のバージョンを使っている場合は試してみるとよいかもしれません。

File input pluginの更新について

こちらのプラグインはおなじみの、ファイルを読み込むためのプラグインですね。

アップデート内容について

github.com

Logstash 6.4.0からgzipファイルをそのままで読み込めるようになりました🎉
この機能のおかげで、例えばログサーバ上においてあるような過去のgzipファイルを解凍せずにそのままデータ読込できるようになります。

Logstashの実行モードについて

アップデート内容について

www.elastic.co

JRubyによる実行以外にJavaで実行できるようになり、
Logstash 6.3.0からは本番運用まであと一歩になりました。
Elasticユーザ会では本番でも使えるっぽいと発言しちゃいましたが、よく見たらあと一歩みたいでした、すいません。。。

We’re happy to announce that the new Java execution engine in Logstash has reached the production candidate stage.

設定方法は「--experimental-java-execution」オプションを起動時に付けるだけ。

GitHubには6.0.0と6.3.0で1.4倍ほど早くなったとか🤔

Pipeline-to-Pipeline Communication (Beta)について

パイプライン同士でデータを受け渡しができるようになりました。
まだベータバージョンですが、以下のような記述で設定できるようです。
ただ、pipeline.ymlが肥大化するのでそれはそれで困るかもという声もあるので、
ここをいい感じに分割できるようになることを期待したいですね🤔

# config/pipelines.yml
- pipeline.id: upstream
  config.string: input { stdin {} } output { pipeline { send_to => [myVirtualAddress] } }
- pipeline.id: downstream
  config.string: input { pipeline { address => myVirtualAddress } }

www.elastic.co

Architectural patternについて

www.elastic.co

アップデートとは違うのですが、
いくつか公式でおすすめの設定パターンがあるようです。

The distributor pattern

単一のinputからデータタイプに応じて処理パターンがあるときにifとかで長くなるところを短縮できるようになるから良いよ!というものみたいです。

# config/pipelines.yml
- pipeline.id: beats-server
  config.string: |
    input { beats { port => 5044 } }
    output {
        if [type] == apache {
          pipeline { send_to => weblogs }
        } else if [type] == system {
          pipeline { send_to => syslog }
        } else {
          pipeline { send_to => fallback }
        }
    }
- pipeline.id: weblog-processing
  config.string: |
    input { pipeline { address => weblogs } }
    filter {
       # Weblog filter statements here...
    }
    output {
      elasticsearch { hosts => [es_cluster_a_host] }
    }
- pipeline.id: syslog-processing
  config.string: |
    input { pipeline { address => syslog } }
    filter {
       # Syslog filter statements here...
    }
    output {
      elasticsearch { hosts => [es_cluster_b_host] }
    }
- pipeline.id: fallback-processing
    config.string: |
    input { pipeline { address => fallback } }
    output { elasticsearch { hosts => [es_cluster_b_host] } }

The output isolator pattern

出力先を複数に分けることでどちらかに障害が起きてもデータロストすることを防ぐためのもので、
ディスクにキューイングするpersisted typeにすることでより強固にするためのもののようです。

# config/pipelines.yml
- pipeline.id: intake
  queue.type: persisted
  config.string: |
    input { beats { port => 5044 } }
    output { pipeline { send_to => [es, http] } }
- pipeline.id: buffered-es
  queue.type: persisted
  config.string: |
    input { pipeline { address => es } }
    output { elasticsearch { } }
- pipeline.id: buffered-http
  queue.type: persisted
  config.string: |
    input { pipeline { address => http } }
    output { http { } }

The forked path pattern

今まではcloneやif/elseを使ってLogstashでデータ加工をおこなっていた箇所をストリームをつなげて設定を簡素化できるようになるパターンのようです。
以下の例では、Elasticsearchには未加工でデータを送信し、S3にアップロードするときだけセンシティブなフィールドを削除してからアップロードするようです。

# config/pipelines.yml
- pipeline.id: intake
  queue.type: persisted
  config.string: |
    input { beats { port => 5044 } }
    output { pipeline { send_to => ["internal-es", "partner-s3"] } }
- pipeline.id: buffered-es
  queue.type: persisted
  config.string: |
    input { pipeline { address => "internal-es" } }
    # Index the full event
    output { elasticsearch { } }
- pipeline.id: partner
  queue.type: persisted
  config.string: |
    input { pipeline { address => "partner-s3" } }
    filter {
      # Remove the sensitive data
      mutate { remove_field => 'sensitive-data' }
    }
    output { s3 { } } # Output to partner's bucket

The collector pattern

The distributor patternとは反対に複数のデータソースがあるときに、
output前に共通の処理をはさみたいときに以下のように設定すると設定を簡易化することができるようにしているようです。

# config/pipelines.yml
- pipeline.id: beats
  config.string: |
    input { beats { port => 5044 } }
    output { pipeline { send_to => [commonOut] } }
- pipeline.id: kafka
  config.string: |
    input { kafka { ... } }
    output { pipeline { send_to => [commonOut] } }
- pipeline.id: partner
  # This common pipeline enforces the same logic whether data comes from Kafka or Beats
  config.string: |
    input { pipeline { address => commonOut } }
    filter {
      # Always remove sensitive data from all input sources
      mutate { remove_field => 'sensitive-data' }
    }
    output { elasticsearch { } }

Elastic社のGithubレポジトリで面白そうなものを紹介してみる

まえがき

2018年Elastic Stackアドベントカレンダーの22日目の記事になります。

qiita.com

私からはElastic社のGithubレポジトリで面白そうだったり、こんなのあったんだー的なものをいくつか紹介したいと思います。

GithubのElastic社管理リポジトリについて

結構数が多くてフォークしたものも含めると、記事執筆段階(2018/12/21)で既に265個もあったりします。

github.com

Docker系について

私は今まで知らなかったのですが、個別のデーモンのDocker以外にも、Elastic Stackそのものを立ち上げるDocker Composeリポジトリがあります。

github.com

ただ、中身を見ていると、Docker Hubに上がっているのとはパット見別物っぽくも見えます。
Docker系の設定は以下の通りいくつかに散らばっているようにも見えますが、今後は自社のDockerリポジトリ(https://docker.elastic.co)に集約させていくのかなと思いました。

Docker Hubに上がっているDockerfileをよく見たら参照先が公式のdocker.elastic.coになっていました。
ただ、Docker Hubのやつは非公式との話も聞いたのでやはりDockerを使って作業するときは$ docker pull elasticsearchではなく、公式を参照先に指定されたほうが良さそうです。

現存するDockerライブラリ

Ansibleについて

AnsibleについてはElasticsearchとBeatsについてはありようですが、LogstashやKibanaについてはなさそうでした。
Elasticsearchの本番運用をDockerでやるのは辛いと思うので、AWS EC2やオンプレミスで運用するときにAnsibleでデプロイするときに役立ちそうです。

github.com

github.com

テストデータ系について

Elastic社でデータセットと、それを使ったサンプルをいくつか提供してくれています。
例えば、以下のelastic/examplesでは、ApacheやNginxのログだけにとどまらず、 アメリカの疾病予防センター(CDC)のデータセットを使ったサンプルや、PHPを使った検索のサンプルApacheのログからGraph機能を使ったセキュリティのサンプルなど多岐に渡って紹介されています。
ある程度触ったことがある方にはこのサンプルでElastic Stackをどう使えば良いか、より具体的なイメージができそうです。

github.com

他にもelastic/makelogsというリポジトリがあり、
こちらはNode.jsを使ってダミーのアクセスログを生成してElasticsearchに投入するもののようです。
簡単にデータを投入してデバッグや動作確認したいときはこれを使ってサクッと試すのに良さそうです。

github.com

Elasticsearchチームのエンジニアリング哲学について

この前GitLab社が公開しているハンドブックが面白くて一部を紹介しましたが
Elasticsearchチームでもエンジニアリング哲学についてGitHub上で公開されていました。

github.com

Elastic Stackのテストについて

まだWIPのようですが、Elastic Stackのテストフレームワークを作っているようです。

github.com

この前Elastic社のテストとリリースについて語っているスライドを見たら、
様々な言語、バージョニング(今は統一されていますが)で大分カオスだったので、確かにこういうテストフレームワークがないと死ぬなーと思いました。

言語について

f:id:st1t:20181221163638p:plain

各プロダクトのバージョンについて

f:id:st1t:20181221163901p:plain

Slackボットについて

Slackを使った簡易ボットのようです。
週末の金曜日にお酒飲みながらサクッと作られたのかな?w
パット見は、localhostのKibanaに問い合わせてDashboardのスクショを撮ってくれたりしてくれそうです。

github.com

あとがき

レポジトリの中身を実際に動かす時間は取れなかったので簡易的な紹介にとどまってしまいましたが、改めて見てみると面白いレポジトリが多いなーと思いました🙂
もし、今使われているプロダクトだけでなくて、Elastic社がどんなことをやっていて、今後どういうことをやろうとしているのか、どういう雰囲気で開発しているのか等気になったらリポジトリから垣間見ることができるのでぜひ見てみてはいかがでしょうか(そして面白いのがあったら教えてくださいw)

明日はfroakie0021さんによる「Canvasやってみたいと思います🌈」です! 乞うご期待!!

GitLab Handbookで面白かったもの@コミュニケーション編

まえがき

GitLab社が公開しているHandbookから良さそうなものをいくつか紹介していこうと思います。
かなりボリュームがあるので、今回の記事からはコミュニケーションの記事から紹介していきます。
※英語の翻訳が変だったり、間違っていたらすいません💧

GitLabのCommunicationについて

about.gitlab.com

内部コミュニケーションについて

Issues are preferred over email, email is preferred over chat, announcements happen on the company call agenda, and people should be able to do their work without getting interrupted by chat.
IssueはEmailより優先され、Emailはチャットより優先され、アナウンスは会社のcall agendaで生じ、人々はチャットによる中断なしに仕事を行うことができます。

Issue > Email > Chatの順番で優先されるため、よくあるチャットの割り込み地獄で仕事の中断の嵐を防ぐ、というものみたいですね。
チャットはリアルタイムで便利な反面、原文でも紹介されているように、常に気にしなきゃいけなかったり、後で重要な箇所を見返すのが難しかったりします。
そこで、GitLab社ではきちんとコミュニケーションの方法について優先度をつけているようです。

称賛の仕方

Don't thank people publicly for working outside of their scheduled work hours. We want to minimize the pressure to do so.
業務時間外で業務を行ったことに対して公の場所で感謝をしないでください。
我々はプレッシャー(業務時間外でも業務に対応すること)を最小限にしたいためです。

SREみたいにアラート対応だとなかなか難しい気がしていますが、
そもそもGitLab社のようにグローバルで働いているチームでは、タイムゾーンの異なるメンバーがいるから24時間誰かしら業務時間内であるからこそ明言できるのかもしれないですね。 グローバル展開するようなところであれば目標にするのは良いことなのかなと思います。

メールの書き方

If an email needs a response, write the answer at the top of it.
もしメールの返信が必要な場合には、メールの冒頭に返答が必要な旨を記載しておいてください。

一つの話題について何度かメールのやり取りをしていて、 終わり際がたまにわからない時があるので、こういう前提があると良い気がします。

相手に効率的に話を伝える方法

Situation-Complication-Implication-Position-Action-Benefit (SCIPAB)

アメリカのマンデルコミュニケーションズという会社がSCIPABと略称してる、会話やプレゼンテーションを始めるときに6つの意識したほうが良いテンプレートフォーマットがあり、これを参考にすると良いよ、というものみたいです。
PDCAのコミュニケーションバージョンといったものでしょうか。
※この和訳は自分にはつらかったので同僚の手助けを得ました・・・サクッと訳していただいたの、神がかっている🙏

SCIPABについて

Situation - Expresses the current state for discussion.
状況について - ディスカッションのために現在の状況について表現する
 
Complication - Summarizes the critical issues, challenges or opportunities.
(問題の)複雑さについて - 致命的な問題、難題、機会について整理する
 
Implication - Provides insight into the consequences that will be a result of if the Complications are not addressed.
推測について - 複雑な問題が対応されなかったために発生した結果に対する見解を提供します。
 
Position - Notes the presenter's opinion on the necessary changes which should be made.
立場について - 実行されるべき必須の変更についての意見に注目します。
 
Action - Defines the expectations of the target audience/listeners.
アクションについて - 聞き手の期待することを定義します。
 
Benefit - Clearly concludes how the Position and Action sections will address the Complications. This method can be used in presentations, emails and everyday conversations. Example - The Management team asking for time to resolve a problem
恩恵について - いかに立場とアクションが複雑さに対応していくのか、を明確に成立させます。このメソッドはプレゼンテーションやメール、そして毎日の会話で使うことができます。

SCIPABをストーリー化したら

S - The failure rate last year for product X1 was an acceptable 1.5%.
製品X1の去年の故障率は1.5%と、許容できるものでした。
 
C - Because of supply shortages in the current fiscal year we are forced to change the material of a key component.
今年度の供給不足のため、我々は主要コンポーネントの材料の切替を余儀なくされています。
 
I - Unfortunately, that resulted in the failure rate doubling this year.
残念ながら、変更したら今年の故障率は2倍になってしまった。
 
P - It is critical we address this problem immediately.
我々がすぐに問題に対応することは、致命的なくらい重要です。
 
A - Please approve the team 5 days to investigate the specific causes of the increase and establish the necessary next steps.
その増加現象に対する具体的な原因と、それに必要な次のステップを確立するための調査のために、そのチームに5日間を承認してください。
 
B - By doing this we will reduce the failure rate to an acceptable level and develop guidelines for preventing such problems in the future. More information can be found at SCIPAB- Six Steps To Reach Your Audience.
これをすることによって、私達は不良率を許容範囲のレベルまで下げ、将来起きうるそのような問題を防ぐためのガイドラインを開発します。

ロボットのビーミーについて

Beamy is our company conference call robot.
ビーミーは私達の会議電話ロボットです。
 
It lives in the San Francisco boardroom.
ビーミーはサンフランシスコの役員室にいます。
 
Its main purpose is to allow those outside of the boardroom a view into the space and people.
役員室の空間や人々を、外から見れるようにすることが主な目的です。
 
When you call in to the beam your face will appear on the screen (so make sure your webcam works) and you can drive the robot around the boardroom.
あなたがビームに電話したとき、あなたの顔はスクリーン(あなたのWebカメラの動作を確認してください)上で表示され、役員室をロボットでドライブすることができます。
 
It simulates being in the space without physically being there.
その場にいなくてもシミュレートします。
 
It is really cool and everyone should try it and have fun with it.
それはとてもクールで、みんな試してみるべきで、楽しめます。
 
~
 
Beamy lives in the GitLab boardroom.
ビーミーはGitLab役員室で活動しています。
 
If there is a meeting going on in the boardroom (which you were not invited to) when you are testing out Beamy, that is great! Do not feel like you are interrupting the meeting.
もしビーミーをテストしているときに役員室で(あなたが招待されていない)会議が行われていたら、とても素晴らしいことです!あなたが会議を中断したと感じないでください。
 
It actually adds to the "cool" factor that we are a 100% remote company and can interact with people from all over the world at any given time.
それはクールな要素を追加します、私達は100%のリモート会社であり、いつでも世界中で交流できます。
 
Introduce yourself and say "Hi" to the room and move on with your tour of Beamy.
部屋であなたの自己紹介とHiと挨拶して、ビーミーのツアーを進めてください。

サンフランシスコの会議室に画面付きロボット(ラジコンっぽいのかな?)がいるみたいで、好きに動かせるようになっているみたいです。
これを使うことで、実際に現地にいるかのように感じられるとか。
面白いですねw

さいごに

拙い翻訳でうまく伝わりづらい箇所も多かったかと思います。 私が初めてGitLabのHandbookを見たときは、日本の会社にはなかなか見ないもの、
それも完全リモートの会社だからこその面白い規約が細かく定義されていてなかなかおもしろいなーと思いました。
今回はコミュニケーション編の概要だけを紹介しましたが、もしよければ他の資料もぜひ見てみてください。
(できれば概要を翻訳して紹介ブログ書いてもらえれると嬉しいですw)

about.gitlab.com

Elasticコミュニティランチに行ってきました

まえがき

日本のElasticコミュニティメンバーが集まって、
Elastic社メンバーとランチするイベントに招いていただいたので行ってきました!
場所は普段全く縁がないGINZA SIX13FのTHE GRAND GINZA
写真は取れなかったですが、お肉もお魚もめっちゃ美味しかったです!

なぜ呼ばれたの?

Elastic社が用意している、Elastic Stackについての質問することできる掲示板があります。
2016年くらいからここで、分かる範囲でたまに質問を答えていたりしたことをきっかけにお声がけいただきました。

当時はElasticの大谷さんがほとんどの質問に答えるという状況で、
サポート費用を貰っているわけでもないのに大変そうだなーと他人事ながら思っていましたw

ほんとどの質問を大谷さんが頑張る図

f:id:st1t:20181211212253p:plain

Elasticコミュニティとの関わり

そんな中で自分はというと、どうしてもログ解析からElasticsearchという切り口だと社内で仲間が増えづらかったりして頭を抱えていました。
一人でやるとどうしても孤立しがちなので、社内ではなく、社外へ仲間を作るために少しでも関わりを持とうとしたのがきっかけでした。

ささいなPRを出してみたり、

Elastic Stack 6系のPioneer Programでバグ報告や、機能についてのIssueを出したりしていました。

github.com github.com

思い返してみれば、このPRが初めて大規模なOSSへのPRでした。
右も左もわからず、IssueやDiscussで修正内容について意見を求めるわけでもなく、
また、Contribute.mdをきちんと見るわけでもなく無知が故に投げてしまった本当にひどいPRでした。。。

そんなひどいPRにも関わらず無視するわけでもなく、
MetricbeatコミッターのRuflinさんtsgさんはきちんとレビューとコメントをしてくれて今でも本当に感謝しています🙏
このPRからコードを読み書きすることやOSSプロダクトそのものの関わりが増えて、
内容はともかく、人生を変えた一つのターニングポイントといっても過言ではなかったです。

閑話休題

どんな会だったのか

参加者は多分15名〜20名くらいいたかなと思います。
最初に自己紹介をしたのですが、
以下の本を書かれている方や、私と同じくDiscussで良く見かける方が多かったです。
テーブルが分かれていたのですが、反対側の方と話すタイミングがなかったのはちょっと残念。
他にも本を書かれていた方がいらっしゃるのですが、リンクが見つけられなくてすいません💧

acro-engineer.hatenablog.com nextpublishing.jp honto.jp

私の席の周りはDiscussでよくお見かけする、mnozawaさんや、
Elastic Stackを使ったセキュリティの発表で有名なフューチャーアーキテクトの日比野さん
Elasticsearch実践ガイドを執筆された惣道さんがいらっしゃいました。

Logstash周りで色々話しができてめっちゃ面白かったです。
以下、話した内容

  • 本当はBeatsだけ、Logstashだけ、Kibanaだけみたいな部分的なポイントではなく、一気通貫で設定する時のポイントを話せたら良いな
    • やりたいけど、発表時間が2,30分メインの中では話すのは厳しそう
  • BeatsプロダクトからS3にPushする機能があればいいのに
  • 旧X-Packは日本のサイトでは「有償オプション」、海外のサイトでは「Elastic Stack Features」だけど、なんて呼べば良いんだろ
    • 途中からShayさんが自分たちの席に来てもらえて、英語のサイトに記載あるElastic Stack Featuresが正しそうだった(うろ覚え)

おみやげ

f:id:st1t:20181211215735j:plain

左:定期や社員証をいれられるやつ、真ん中:ブルートゥースイヤホン、右:海外でも使えるモバイルバッテリー

ブルートゥースは本当に凄いですね、いくらかかっているんだろう🤔
モバイルバッテリーも、各地対応(U.K/EUROPE/USA/AUST)って初めてみました、すごい。
そして個人的には社員証入れられそうなやつがかっこよくて実は一番うれしかったですw

これだけ色々していただいているだけに、
もっとコミュニティに携われるよう頑張っていこうと思います!

来年は技術書展で本書きたいなー

ありがとうございました!

SendGridハンズオンに行ってきた

まえがき

前々から良い評判を聞いていたSendGrid。
アカウントは発行してもらったのですが、まともに触れていませんでした。
時間もできたので日本でSendGridの代理店をされている構造計画研究所さんでハンズオンをやってるのを見かけたので参加させてもらいました。

基本的にはクラスメソッドの濱田さんが書かれていることの通りだったので、
それ以外でいくつか良かった点を上げていこうと思います。

設定等の細かい部分については記載しませんので、興味がある方はぜひ参加してみてください😃

dev.classmethod.jp

良かった点@最初のつまづきポイントを教えてくれる

  • テキストメールを送るための設定
  • Activity機能の注意事項
  • バウンスメールの管理方法
  • Event Webhookの簡易的な動作確認

良かった点@SendGridを使うと何ができるか、便利になるかを把握しやすい

  • 大量のメール送信をテストするためのテスト用ドメインが用意されている
    • 大量メルマガにありがちな数百万通のテストとか実際にやろうとすると相当大変。 かといって、モックでやるとネットワークや負荷、送信処理のライブラリ等の正常性確認ができないので非常にありがたいもの。
  • メール受信機能がある
    • メールボックス機能はないが、受信メール内容をHTTPSでPOSTしてくれる
      これによって空メール受信によるユーザ登録やチケットを切る等の連携ができる。

良かった点@質問しやすい

濱田さんも書かれている通り、サポートされている方の人数が無料とは思えないくらい多かったです。
それもあっていくつか聞いてみました。

メール送信後のステータスがDeferredの場合、最長72時間再送を試みるがどのようにリトライするのか

  • 例えば、100万通投げて100通リトライになったときのことを考えてみる
    • リトライ間隔はどうなるのか
    • いっきに100通リトライするのか、SendGridがよしなに分割して再送するような制御がはいっていたりするのか
  • リトライ方法の仕様はSendGridでは非公開
    • ただし、以前動きを確認してみたら以下の通りだった。
    • リトライ間隔は最初は短かったが、徐々に間隔が長くなっていった。
    • 宛先に応じてSendGridがよしなにリトライを行う動きをしてた。
      • 仮にリトライの一部が受信できても他のリトライメールが受信できているとはみなせない認識で良いか。
        • その通り。

Stats画面から確認できるステータスはアラートで通知できたりするか

  • 現状ではできない。
    Event WebhookでステータスをDBに貯めておいて、そこから確認するしかない。

悩ましかった点@インフラ視点とアプリ視点でのメリットについて

  • 今回のハンズオンは開発者向けではあるけど、メール運用の経験がない人にとってはDKIMやSPFの意味や、Link BrandingやReverse DNSの良さが伝わりづらいかも。
    口頭ではメール到達率を上げるためと説明してもらえたし、インフラ屋からすると、確かにすげー楽、SendGrid神かな?って思うけど、コードを書くのがメインの人にとってはひょっとしたらイメージがつきづらいかも。
    DNSやメールみたいなものの運用は地味に手間がかかって職人芸なところが出てくるうえにインパクトが大きいから少人数でインフラやってたりする人には結構良いアピールになるんじゃないかなーと思いました。 特にSREみたいにコードを含めてサイトの信頼性を担保しなきゃいけないチームにはかなりハマるんじゃないかなと。 そういう意味ではSRE向けにメールシステム効率化のハンズオン?資料?があっても良いかなーと思いました。

今後やってみたいこと

Elastic Stackと相性良さそうな印象を受けたので、Event Webhookで飛んできたJSONをElasticsearchにいれてKibanaのCanvasに入れて可視化したらマーケティング担当の人に喜ばれそうなのでやってみたい

総括

今まで時間がなくてSendGrid触れていなかったですが、もっと早く触っておけばよかったです。
そしてハンズオンをやってもらえた上に、質問もサクッと答えていただいてありがとうございました!!

SMTPサーバの運用で苦しんでいる人や、メールシステムを効率化したい人は悩みやイメージを持ってハンズオンに参加するときっと幸せになれると思うのでオススメです!