Vue.jsで使うGraphQLクライアントライブラリ

Vue.jsでGraphQL使ってみようかと思った時、GraphQLクライアントが結構ゴチャついててどのライブラリを組み合わせて使えばいいのか分かりにくかったのでまとめました

結論

コンポーネント内でリクエストの送信をするなら vue-apollo
Vuexのアクションでリクエストを送信するなら apollo-client
AWS Amplify + AppSyncの組み合わせなら aws-amplify

vue-apollo

コンポーネントに組み込むタイプのやつです。コンポーネントapolloオプション生やしてそこで指定されたリクエストはmountedで呼ばれます。

apolloオプション、ちょっと邪悪感が否めませんが、小さなアプリケーションを使うときはこいつで十分です。コンポーネントのテストにはvue-test-utilsなんかを使えば良いのではないでしょうか。

Vuexのライフサイクルとは合わないのでVuexのアクションでGraphQLエンドポイントにリクエスト投げる使い方をしたい人には向きません。

サンプルソース

<template>
  <div><span>{{ getTodo }}</span></div>
</template>

<script>
import Query from '@/apollo/query.gql'

export default {
  data() {
    return {
      getTodo: {}
    }
  },
  apollo: {
    getTodo: {
      variables: {
        id: 1
      },
      prefetch: true,
      query: Query,
    }
  },
  methods: {
  },
  async mounted () {
    this.$apollo.queries.getTodo.refetch().then(data => console.log(data))
  }
}
</script>

apollo-module

Nuxtでvue-apolloを使うためにvue-apolloをラップしたライブラリです。役割はvue-apolloと同じなので省略。

apollo-client

vue-apolloaws-appsync-sdkの大元になるライブラリです。ドキュメントの最初の方に書いてある通り、ビューレイヤーに組み込むことでキャッシュなどの機能を十分発揮してくれます。

こんな感じで簡単に書くことができます。

import ApolloClient from 'apollo-boost';
import gql from 'graphql-tag';

const client = new ApolloClient({
  uri: 'https://graphql.example.com'
});

client.query({
  query: gql`
    query TodoApp {
      todos {
        id
        text
        completed
      }
    }
  `,
})
  .then(data => console.log(data))
  .catch(error => console.error(error));

apollo-link

ただ単純にGraphQLのリクエストのみを送りたいときはこいつです。query/mutationを送りたいときはapollo-link-httpを使います。

こいつはexecutemakePromiseを組み合わせてよく便利に使っています。

import { execute, makePromise } from 'apollo-link'
import { HttpLink } from 'apollo-link-http'
import gql from 'graphql-tag'
import query from './query.gql'

const operation = {
  query: gql`${query}`
}
const uri = 'http://localhost:4000/graphql/'
const headers = {}
const link = new HttpLink({ uri, headers })

makePromise(execute(link, operation))
  .then(data => {
    if (this.debug) console.log(`received data ${JSON.stringify(data, null, 2)}`)
    return data
  })
  .catch(error => {
    if (this.debug) console.log(`received error :${error}\n${this.baseURL}: ${query}`)
    return { error: error }
  })

aws-amplify

AmplifyでAppSync立てたならこいつを使うのが一番使い勝手良さそうです。というかCognitoのトークン取ってくる機能もAppSyncにリクエスト投げるのもこいつだけで完結できます。

ライブラリとしてすごく便利でいろんなことをやってくれるのですが「お前なんで勝手にそんなことしてるんだよ・・・」みたいな何でも詰め込んだ感じではなく適度に薄く使いやすいやつです。

※vue-apolloのようにコンポーネントに組み込んでよしなに勝手にやってくれるようなことはしません

ドキュメントからのコピペですがこんな感じのコードです。

import Amplify, { API, graphqlOperation } from "aws-amplify";
import * as queries from './graphql/queries';

// Simple query
const allTodos = await API.graphql(graphqlOperation(queries.listTodos));
console.log(allTodos);

// Query using a parameter
const oneTodo = await API.graphql(graphqlOperation(queries.getTodo, { id: 'some id' }));
console.log(oneTodo);

aws-appsync-sdk

apollo-clientをラップしたライブラリで、query/mutationはapollo-clientとほとんど変わらなくてsubscriptionやofflineを使うには少し便利そうです。

コンポーネントに組み込まずに使う方法ありそうですが使ってないので不明です。サンプルではコンポーネントに組み込んでthis.$apolloで参照する使い方しか書かれていません。

感想

apolloさん関係のライブラリを使おうとする度に「俺はただいい感じにGraphQLのエンドポイントへfetch投げてくれるだけで満足するんだ・・・ただそれだけでいいんだ・・・」って気持ちになります。

Main Memory Database Systems: An Overview

読んだ論文

  1. Garcia-Molina, et al., Main Memory Database Systems: An Overview, in IEEE Trans. on Knowl. and Data Eng., 1992

この論文をざっくりまとめます。

要約

インメモリデータベース(MMDB)はデータをメインメモリに保存するデータベースのことである。MMDBは従来のデータベース(DRDB)と比べて高速に処理を行うことができるが(本当か?)、(xxxという欠点がある) この論文では、MMDBが動く仕組みと実際に開発されてきたMMDBの紹介を説明している。

1. INTRODUCTION

メインメモリデータベース(MMDB)はメインメモリにデータを保存するデータベースで、従来のデータベース(DRDB)はディスクにデータを保存するものである。 しかし、MMDBはバックアップとしてデータをディスクに保存し、DRDBはキャッシュとしてメインメモリにデータを保存する。このようにMMDBもDRDBもメインメモリとディスクの両方を使う

MMDBは近年(つっても1992年当時のこと)の半導体メモリチップの低価格化と集積度の向上により実用化されたもので、デッドライン時間が決まっているリアルタイムシステムにおいて効果的に使うことができる。

この論文ではMMDBにおいてメインメモリと磁気ディスクの差による影響に関して論じた。

以下の3つの質問と答えは、MMDBに関してよくある疑問である。

(1) データベースの全体ががメインメモリに収まると考えるのは合理的なことなのですか?

Yes

でも、衛星の画像データみたいな大きなデータだとメインメモリに格納しきれなくなってしまうだろうから、大きなデータと小さなデータは分けて管理する。

データにはよく使われるHotなデータとあまり使われないColdなデータがあって、Hotなデータをメインメモリに格納するようにしてColdなデータをディスクに格納するようにする。この時、MMDBとDRDBの2種類でデータが管理される。

(2) MMDBとめっちゃ大きなキャッシュをメインメモリに持つDRDBはどう違うのですか?

asmsuechan: これは私も真っ先に感じた疑問だからここに答えがあってよかった

まずインデックス構造が問題で、DRDBにおいてメインメモリの中に全てのデータがあったとしてもディスク用の設計が使われてしまう。さらに、データを使用するアプリケーションはデータがディスクに存在するかのようにバッファマネージャーを使うのでこうなるとあまりメリットはなくなる。

でも、良いDBMSはデータがメインメモリに保存されているかのように振る舞うようになるはずなので、将来的にはMMDBとDRDBの違いはなくなると思う。

(3) メインメモリは何か特別なハードウェアによって不揮発で信頼できるものになるのか?

これにはyesともnoとも答えられなくて、MMDBの設計によるとしか答えられない。なぜなら無停電装置を導入したりエラー検出をしっかりしたり冗長性を高めたりしても、それはメインメモリが落ちる確率を下げるだけでどんなに頑張っても0%にはならないから。だからバックアップは必ず必要になる。

2. メモリ常駐データの衝撃

この章ではDBMSにおいて重要ないくつかのコンポーネントにおいてメモリ常駐に関する事柄を説明する。

A. 並行実行の制御

DBの、トランザクションを並行実行する場合におけるデータのロックを制御する仕組みについて。

まず、データがメモリに常駐していてデータの競合が小さいならばロックの粒度を小さくしてもこの利点はないので、ロックの粒度をフィールドやレコードなどの小さい単位からリレーションなどの大きな単位にして良い。

最悪DB全体で1つの単位としてもよくて、実際これの研究も行われていた。これはトランザクション直列実行されることになる。 この場合ロック処理において、セット/リリースやデッドロックへの対処などの制御処理をほぼ無視できるのでトランザクションの直列実行は望ましい。

なお、実際のロック処理(排他ロック)は、2ビットでオブジェクトがロックされているかの情報をそのオブジェクトにトランザクション待ちが発生しているかどうかを表して実現する。

asmsuechan: このセクション、プロセスの並列処理周りの知識がないとちょっと難しい

B. コミット処理

処理の失敗に備えるために、トランザクションのログを取る必要がある。このログはディスクに保存しなければならないので、この保存処理がボトルネックになってスループットを下げてしまうことがある。

ディスクを使うDBでも同じ問題は起きるけど、MMDBではここが唯一ディスクを操作する操作だからよりシビアになってしまう。

今まで研究されてきている、この問題を解決するいくつかの手法を紹介する。

  1. stable メインメモリにログを保存する
    特別なプロセスやプロセッサを使ってstable メインメモリからディスクにデータを保存するようにする。いわゆるキューイングかな。
  2. precommitするようにする
  3. group commitという手法を使う。
    これはページがいっぱいになるまでログを溜めた後にまとめてディスクに保存する手法のことである。

C. アクセス手法

MMDBに置いて、B-Treeはあまり有用ではない。それはB-Treeのハッシュの仕組みが領域を大きく消費するからだ。

メインメモリにあるデータへアクセスするには、B-Treeのようにデータをインデックスに保存する必要がない。これは、メインメモリはディスクに比べてアクセス速度が速くポインタでも十分なスピードでデータを見つけることができるからだ。

このことより、インデックス中の可変長のフィールドに関する問題を解決したり、ポインターのサイズがデータより小さい場合は容量を削減したりできる。

D. データ表現

リレーションはデータのポインターのタプルとして表現される。ポインタによりスペースの効率利用が可能で、さらに可変長データの表現が容易になる。

E. クエリ処理

上でも述べたように、データのポインターでリレーションが表現できるなら、リレーション関連の処理が効率よく実行できる。

ここで一番重要なのは、「データがメモリにあるからクエリの速度を上げることができるようなコンパクトなデータ構造が可能である」ということである。

F. リカバリ

揮発性のメモリから不揮発性のメモリにデータをバックアップすることは必須である。

バックアップからデータをリカバリすることで大事なのは、(1) バックアップを最新に保つ処理と(2) 失敗から復旧する処理である。

以前Commitの部分で述べたように、DBに何か問題があったとき、ログからデータを復旧する。

チェックポインティングはなるべくトランザクションの処理を邪魔してはいけないが、どうしてもロックなどの処理が発生する。その代償として動機を行わないfuzzy dumpingが知られている。

G. パフォーマンス

メインメモリデータベースのパフォーマンスはだいたい処理時間に依存する。

H. APIと保護

DRDBに置いて、DBMSとアプリケーションのデータの受け渡しはプライベートバッファを会して行われている。これに対してMMDBではオブジェクトが直接メモリアドレスで参照される。

プライベートバッファをなくしてトランザクション時にオブジェクトに直接アクセスするようにすると、トランザクションがシンプルな場合にはトランザクションにかかる時間のほとんどがビット(?)をメモリからバッファにコピーする時間に費やされることになる。

しかしデータに直接アクセスするときには、DBMSが認知していないデータを変更できてしまうためにこの変更をDBMSが検知できずにログに書かれないという問題がある。

I. データクラスタリングマイグレーション

DRDBではデータオブジェクトはまとまって保存されたりクラスタ化されたりする。

asmsuechan: 空間的局所性やな

MMDBのデータはDRDBのデータと違って分散しているので、このデータをディスクに移すときどのように、またどこに保存するかという問題が発生する。

この解決方法には様々あって、ユーザーがデータの移動(migration)時にどうクラスタリングするかを手動で設定する方法から、アクセスパターンから自動でクラスタを決定する方法まである。

ここで私たちが言いたいのは、データの移動と動的クラスタリングはMMDBの要素であるということである。

3. システム事例

この章では、今まで理論の設計や実装がされてきたインメモリデータベース に関して述べる

A. OBE

OBEはIBMとOffice-By-Exampleの合同チームが開発したプロジェクトであり、IBM 370アーキテクチャの上で実行される。このDBはアドホッククエリの処理に重点が置かれている。

データ表現としてOBEではポインタが多用されていて、リレーションはタプルのリンク付きリストとして’保存される。

ジョインはネストされたループ(nested-loop)で実行され、インデックスはジョインの実行時にその場で作られる。

B-G

下書き保存し忘れて消えた、後ほど復旧。

結論

5分より短い間隔でアクセスされるデータはメモリに置くべきであるという調査がある。これは、データへのアクセスにかかる金銭的なコストから計算したものである。しかし一番大事なのは、メモリの値段が下がるにつれてこの時間も長くなるということだ。

まとめ

この論文はインメモリデータベースの基礎中の基礎を分かりやすく説明してくれているので、かなりしっかり読んでしっかり訳しました。

でも具体例のところは話が古くて正直あまりピンと来なかったところが結構あったのでもっと勉強せねばって気持ちです・・・

Database Systems Lesson #1 Course Introduction and History of Database Systems

www.youtube.com

クイズ

Andy Pavlo先生が毎セメスター出してるクイズ。

Q: なぜSNSとして先に登場したfriendstarというサービスは失敗して後続のFacebookが成功したのか A: FBはDBがしっかりしていたから。friendstarはDBが耐えられなくて遅くなって失敗した。

このコースについて

  • DBが内部でどんな風に動いているかを学ぶ
  • インメモリデータベースの内部構造を学ぶ
  • 分散システムは扱わない
  • SQLとか基礎的なアルゴリズムは事前に理解しておく必要がある
  • マルチスレッドプログラムをGDBデバッグする方法は学んでおく必要がある
  • C++11でプログラムを書く
  • Postgresの一部の大きなコードベースを使ってインメモリデータベースを作る

Reading Assignments

1授業につき1つの論文を読んで 概要(2文)、使われたシステムなど(1文)、評価法(1文) にまとめる。これを授業前までに行う。

Programming Project

Peltonって名前のPostgresをベースとしたインメモリデータベースをC++11で作る。課題は大きく3つに分けられる。

Project #1 and #2

#1はみんな同じものを実装して、#2はグループワークで分散B-Treeを実装する。

コードの剽窃をした人はクラスのwebサイトに永遠に名前を載せるらしい。剽窃に関してはめちゃくちゃ厳しくするって何度も言ってた。

Project #3

これもグループワークで、お題は自分たちで決めたものを実装するらしい。他のグループのコードを見てコードレビューしたり5分でキーポイントをまとめて発表したりする。

この課題は実装したパッチにPelotonのmasterブランチにマージされなければ完成とは認められない。しかもテストとドキュメントをしっかり書く必要もある。

History of Databases

データベースの歴史を1960年代から現在まで簡単に紹介していた。

  • 1960年代: IBM IMSという階層データモデルを採用したDB
  • 1970年代: CODASYLと言うもう使われていないCOBOLで使うためのネットワークデータモデルを採用したDB
  • 1970年代: Ted Coddという人がIBM IMSの開発者を見て辛い気持ちになったのでリレーショナルモデルを考えた
  • 1980年代: リレーショナルモデルがどんどん他のモデルのDBを駆逐していった
  • 1980年代: インスタンスをそのまま保存するオブジェクト指向DBが出たけど標準APIないわクエリが複雑になるわでもう使われなくなった
  • 1990年代: 新しいものが生まれない退屈な時代
  • 2000年代: インターネット時代で企業は大幅なトラフィックの増大に耐えるためにDBを独自にカスタマイズしていた
  • 2000年代: 可用性とスケーラビリティに注目してNoSQLシステムが生まれた
  • 2010年代: NewSQLの時代。「H-StoreというDBは私が書いた」
  • 2010年代: ハイブリットシステム

感想

まとめるために一時停止したり聞き取りにくかったところを巻き戻したりしてたら1回分(70分)を見るのに2時間近くかかった。

こんなん授業についていくのに必死で良い評価取れる気がしないわ・・・

毎週論文一本読んでSummerizeするの、結構楽しそう。

英語がめちゃくちゃ早くてよく聞き取れないところがあった。

オフィスアワーで「Relationshipsの相談も受け付けるよ」って言ってたのは面白かった。

この授業は多分もの凄くハードだけど、必死になってPostgresのような大きなコードベースを読み解くような経験をしたかしなかったかで今後の開発者としての経験値にはだいぶ差がつくと思う。頑張ってやり遂げたい。

Android StudioでConstraintLayoutが自動補完されずにエラーが出る問題の解決

Android Studioで開発している時にドラッグ&ドロップでオブジェクトを追加する時に以下のエラーが出て困りました。

f:id:asmsuechan:20181205212313p:plain

Missing Constraints in ConstraintLayout
This view is not constrained vertically: at runtime it will jump to the top unless you add a vertical constraint  The layout editor allows you to place widgets anywhere on the canvas, and it records the current position with designtime attributes (such as layout_editor_absoluteX). These attributes are not applied at runtime, so if you push your layout on a device, the widgets may appear in a different location than shown in the editor. To fix this, make sure a widget has both horizontal and vertical constraints by dragging from the edge connections.  Issue id: MissingConstraints 

ConstraintLayoutとは

簡単に言うと、「Material Designに準拠したいい感じな場所に勝手に配置してくれる機能」のことをさします。こちらの記事(Androidの新しいLayout、ConstraintLayoutことはじめ)がとても分かりやすいです。

さて、では上の画像でを見てみると上下方向のConstraintsが設定されていないことでエラーが発生しているようです。

解決方法

対象オブジェクトを選択して、上のボタン群の中にある「Infer Constraints」をクリックしましょう。 f:id:asmsuechan:20181205212753p:plain

オブジェクト挿入時に自動でConstraintsを設定するには

でも、最初から自動でConstraintsは設定されてて欲しいですよね?こうするためには上下左右のガイドに従うことが重要です。

f:id:asmsuechan:20181205213019g:plain

こんな感じに、オブジェクトを配置する際に上下左右でガイドが出る場所があるので、ここに配置しましょう。

サンフランシスコでweb開発者として就職活動をした

もう1年半も前の話なのですが、2017年3月からビザなし(ESTA)で滞在できる期間、大学を休学してサンフランシスコ(SF)でweb開発者としてフルタイムの仕事(インターン)探しをしていました。

はじめに

SF滞在中いろんな日本の方にお世話になりました。本当に感謝しています。ありがとうございました。

結論として、SFの会社で働くという目標は達成できませんでしたが、それでも実際に赴いて活動したことで分かったことがあるのでSFで働くことを考えている人のために書いていきます。

一応書いておきますが、決して私は「日本はクソ!海外サイコー!」という意見を持っている訳ではありません。

当時のスペック

当時私は22歳で、大学3年生が終わるタイミングで休学しました。当時の開発者としての経歴を上げると以下のような感じになります。

  • クラウドワークスで1年くらい開発インターン
  • 他でも4社か5社くらいで長期/短期で開発してた
  • BoostnoteっていうOSSのコミッター(渡米時はスター1000弱くらいだった気がする)

まあ、こんな感じでweb系のコードならまあなんとか書けるっしょって感覚でいたつもりです。

渡米自体は結構前から考えていたので英語の勉強はやっていて、Skype英会話などでなんとか英語は話せる状態でした(TOEICは全然受けてなかったけど、大学入学時に受けた585点が当時の最高点数)。

きっかけ

SFに興味を持ったきっかけは2016年3月にあったTECHLAB PAAKのシリコンバレーワークショップへの参加でした。

この中でいくつかSFのスタートアップを訪れる機会があり、その感想として「SFで働きたい」という思いを抱きました。これが一番最初のきっかけです。

他によくサンプルを調べていなかったのでベルリンとかシンガポールとかをもっとよく調べるべきだったなという反省はあります。

そんなこんなでワークショップから帰国後すぐSkype英会話を始め、レジュメを作ってたまにSFの企業に投げるっていう作業を冬くらいまで続けていました。ちなみにレジュメは5000円くらいかけてネイティブチェックをしてもらいました。

10月ごろにUSインターンの斡旋サービスを使おうと思ってしばらくやり取りをしていたのですが、どうも思うような企業が見つかりませんでした。この斡旋サービスでインターンに行った人の話を聞くと、私が思い描く開発インターンではなく技術的に渋いシステムの保守が多かったです。

我儘であることは承知していたのですが、アジャイル開発ゴリゴリやってるスピード感あるスタートアップでどうしても働きたかったので結局斡旋サービスは使わないことにしました。

渡米

2017年の2月1日、偶然の繋がりでSFで会社をやっている日本人エンジニアである@chikathreesixさんに会いました。この方にSFで働くことについて相談したところ「私もSFで働こうと思ったことがあって、日本からレジュメ送っても返事すらなかったから実際にSFに行った」との意見をいただきました。この方はこれでシンガポールで働くことになったので、「自分もやってみる価値はある!」と思い渡米を決意しました。

ここからはめちゃくちゃ早くて、インターンを辞め指導教員に許可をもらって休学届を提出し住んでいた部屋を引き払って3月8日にSFへ到着しました。

渡米中やったこと

渡米中は以下のことをやって仕事を探していました。

  • ミートアップで知り合ったweb系の人に「Could you refer me to your company?」って言いまくる
  • 紹介で人と会う
  • インターネット経由での応募
  • カンファレンスに行く

ミートアップへの参加

メインの活動はミートアップ(meetup.com)への参加でした。SFでは毎日どっかしらで技術系のミートアップがあっていて、なるべくたくさん(1日3つとか参加した日もあった)行っていろんな人ととにかく喋りました。うろ覚えですが確か目標1日10人知らない人と話す、だったような気がします。

ちなみに1ヶ月くらい毎日ミートアップでずっと人と話していたら「この人前話したな」って人が増えてきて少しずつ友達が増えて楽しかったです。

紹介などで人と会う

@chikathreesixさんからSFにいるいろんな人を紹介していただいて、キャリア相談も含めてお話を伺いました。そしてたまにTwitterでSFにいるweb開発者っぽい人にDMしてアポとってお話聞きに行ったりもしました。

インターネット経由での応募

対面で会社の応募をしながらインターネット経由での応募も続けていました。合計100社以上、サービスやメールで応募しました。返事が返ってこないところは返ってくるまでメールを送りました。

カンファレンスに行く

Austinで行われたDockerconPhoenixで行われたRails Confに行きました。ここでスポンサーしてる企業のブースに行ってインターン受け入れてないか聞いたり公式HPから申し込みしたりしました。

こういう大きいカンファレンスのスポンサー企業は外国人受け入れにも寛容であることが多いので働き口を探す時には指針になりそうです。

使ったサービス

ご多分に洩れず私もUSでよく使われる求人サービスを使っていました。

  • LinkedIn(課金ユーザー)
  • indeed
  • Glassdoor
  • Angelist

使い方としては、サービス上の応募に加えてサービスに求人出している会社の公式HPを調べてそこのRecruitページのメアドにレジュメを投げることが多かったです。

仕事を探して感じたこと

アメリカの企業は学生に全然期待していない」というのがインターンを探していて一番感じたことです。

実際、インターンに応募してSkype面接をした時に学生であることを伝えたら「え?学生・・・jQueryって知ってる?」って聞かれたり、インターンの電話面接で学生であることを伝えたら「まず卒業してから応募してくれ」と言われたりしました。

そういえばミートアップで出会ったUCLA卒の人は卒業してから仕事が見つかるまで8ヶ月かかったって言ってました。

先日Mr. ベイエリアさんのこんなツイートを見て「ああ、やっぱりみんなそうなんだ」って思いました。

(追記 20191127) 最近こんな記事が話題になっていました。これはアメリカで活動している中で非常によく感じていて、この記事を読んで「あー、そうだなそういえばー」という気持ちになりました。

note.com

どんな選択肢があるのか

日本の学生がSF(US)で働こうと思った時どんな選択肢があるのか、個人的観測からのオススメ度も含めて書きました。

(1) SFにある企業のOSSにコミットしまくる

オススメ度: ★★★★★

実際に雇ってくれるという保証はありませんが、コードバリバリ書ける人ならこの方法が良さそうです。GitHubからリクルーターに声かけられてSFで働いてるって人もいました。すごい。

(2) 日本企業のSFブランチで働く(もしくは逆)

オススメ度: ★★★★☆

このパターンは結構多いと思います。しかしそもそも1) その企業に入れるか分からない、2) SFに出向できるか分からない、っていう問題はあります。

(3) 斡旋サービスを利用する

オススメ度: ★★★★☆

intraxなどのUSインターン斡旋サービスは、開発環境にこだわりがなければ結構良い選択肢の一つだと思います。

(3) 起業する

オススメ度: ★★★☆☆

ちょっと極端な例なのですが、もしあなたにUSで事業を行うだけの大義名分があって起業が妥当だと思うのであれば行って自分で会社をやるのが早いです。事務手続きめちゃくちゃ大変そうですけど・・・

(4) SFのコミカレや大学(院)に入って卒業する

オススメ度: ★★★☆☆

気の長い話かつ茨の道なのですが、USの学校を出てそこから就職活動をするってのはこれからUSだけでなく世界で働くにはかなり有用だと思います。

(5) 行って探す

オススメ度: ★★☆☆☆

ここで実際に仕事を見つけられる学生は本当のツワモノです。きっとどこでもやっていける事でしょう。

ビザの話

USで働くにあたって重要になるのがビザの問題です。ビザ関連はかなり時間をかけて調べました。USのビザは世界で一番難易度が高いと言われており、これも外国人の学生が就職活動するには不利になっている要因の一つです(まあ当たり前か)。

私はインターンで働くことを目的としていたのでJ1ビザをサポートしてくれる会社を探していたのですが、USの会社の人はあまりビザのことを知りません。言われてみれば自分も日本のビザに関して全然知りません。ですのでそもそも外国人を雇った実績のある会社以外からは「ビザよくわからねえ」みたいな感じで断られていました。

SFでの生活

物価が高くて貯金を使い果たしてしまったのですが、SFでは概ね快適に生活できました(真昼間にめっちゃ近所で人が銃殺されたりたまに銃声っぽい音が聞こえたりしてて不穏ではあった)。

これもまた人の紹介で見つけたダウンタウンのPowell Street Stationのすぐ近くという最高の立地のモーテルに滞在していました。家賃は12万円/月でした。あの辺りはめちゃくちゃ物価が高いのでこれでも超格安です。

f:id:asmsuechan:20181122115001j:plain

モーテルの隣にあったChipotleってチェーンのメキシコ料理屋がめちゃくちゃ美味しくてほとんど毎日通ってました。1食$8くらいでお腹いっぱい食べられて最高でした。

f:id:asmsuechan:20181122114928j:plain

ミートアップがない時はWorkshop CafeAWS Loftでコード書いたりに知らない人と話してたりしてました。

SFにあるデカくて赤い橋。帰る直前にとりあえず一人でフラッと行った。 f:id:asmsuechan:20181122115235j:plain

まとめ

帰国してからしばらくDocerconでお世話になった@toriclsさんのところで働かせてもらっていて、今は@toriclsさんの紹介で@yoshidashingoさんの元で働いています。

記事の中ではどこの会社からも内定(?)が貰えなかったみたいに書いたのですが、実は1社もらっていました。しかし、メールで勤務地を尋ねたところ「勤務地は南米です」との返事が返ってきたので色々と考えた末に辞退しました。

チャレンジは成功するまで続けるからこそチャレンジなので、そもそもこれはただの旅行だったというのが正直な感想です。次こそは満足する成果が得られるまでやりたいです。

AliEaters#8参加レポート

2018年11月14日に行われたAliEaters#8に参加しました。

alibabacloud.connpass.com

今回は11月11日(独身の日)の直後だったので独身の日にまつわるトピックが多かったです。

ではセッションを1つずつ紹介していきます。

(1) Double 11 独身の日を支えるAlibaba Cloudのテクノロジー

f:id:asmsuechan:20181116082553j:plain

Alibaba Cloud Japanの泉さんによる発表です。

泉さんが強調していたのはアリババクラウドは世界最速・最大規模のクラウドプラットフォームで最高の安定性を持っているということでした。これは、独身の日には1兆5000億件の注文があるそうで、このリクエストをサービスを落とすことなく捌ききっていることが根拠になっています。

世界規模で見ると技術的にはアメリカが一番優れているけど実世界への適用という意味では中国が一番優れている、という意見をどこかで目にしたことがあるのですが、こういう面を踏まえると「ああそうだな」って納得させられますね。

もう一つ泉さんが取り上げていたのが「5GBのファイルを10,000サーバに同時に配信する」ためのシステムであるDragonFlyというものです。

DragonFlyというのはP2Pベースのファイル配信システムのことで、これを使うことでアリババ内部ではどんな大きなファイルでも平均12秒でダウンロードできるようになっているらしいです。

ちなみにDragonFlyはGitHubOSSとして公開されています: dragonflyoss/DragonFly

一言感想

さすが中の人!といった感じでアリババのことがめちゃくちゃ分かりやすくまとまっていました。言いたいことが正確で非常に分かりやすかったので私もこんな発表ができるようになりたいです。

(2) 飞天2.0(Apsara 2.0)

f:id:asmsuechan:20181116111049j:plain

前回のミートアップでは開始5分前にノックダウンして帰宅し発表できなかったキングオブMVPことSBクラウドの森さん(@mosuke5)のリベンジです。

独身の日でもキャッシュサーバーとして使われていたApsaraDB for Redisに関しての発表でした。

ApsaraDB for Redisとは名前の通りAlibaba Cloudで使われているRedisのことです。これの裏側はApsaraCacheというアリババに魔改造されてなぜかmemcacheのプロトコルを喋るようになってしまったRedisくんで動いていて、チューニングが効いててパフォーマンスが30%向上しているらしいです。

Redisはキャッシュサーバーとして利用されるためにReadの方がWriteより多くなるから中国リージョンではReadとWriteのインスタンスを分割しているとのこと。

mosuke5さんは「最近英語での情報発信が増えているので、アリババが国際転換を本気で考えている。嬉しい!」と喜んでいました。私も嬉しいです。

一言感想

技術的な話を根拠を込めてしっかり話されていました。さすが技術の人です。

(3) Maker Fair 深圳レポート -無人コンビニの比較-

f:id:asmsuechan:20181116110922j:plain

最近SBクラウドにジョインされた寺尾さんの深セン無人コンビニ比較です。

寺尾さんは深センで行われたMakers Fairに行くため渡中したそうです。なおMaker Fairには「コナンくんが犯人を見つけた時のメガネ」をかけて参加した模様です。

f:id:asmsuechan:20181116111534j:plain

新鮮にあるwell go、f5未来商店、百鮮GO无人超市という3つの無人コンビニに行ったそうです(詳しくは下のスライドにまとまっています・・・!)。

無人コンビニも決済はQRコードベースで行われているらしいです。また、商品の認識はRFIDで行なっているみたいで誤認識を防ぐ目的で陳列感覚が少し広かったとのこと。

無人コンビニは結構カジュアルにサービス停めるみたいで、少し目を離した隙にメンテナンスのためシャッターが閉まってしまっていたって話に中国っぽさを感じましたw

スライド

www.slideshare.net

一言感想

Makers Fair、中国語初心者なのに中国語で説明頑張ったらしくてめちゃくちゃすごいです。。。

日本でも、無人じゃなくていいからセルフレジをもっとたくさん導入してほしいと願っています。

(4) AlibabaCloudとAWSをゴリゴリいじった結果、便利だと思った機能

f:id:asmsuechan:20181116113212j:plain

スカイアーチ大連から出張で来られた金さんの発表です。めちゃくちゃ日本語うまかった。

この発表では名言が飛び出ました。「アリババクラウドの方が"人間的"なサービスだと思います」。うん、人間的!

これはどの層へ向けたサービスなのかが関わっています。AWSは完全にデベロッパー向けですので複雑で結構難しい(けど使いこなせたら最強)、アリババクラウドはシンプルに設定を行うことができるサービスです。

ただ、シンプルなのはそもそも機能がまだ多くないことが大きな理由です。

あと、シンプルだと明示的に裏側の設定が決められてしまいデフォルトではちょっと高めの課金が行われるってところもちょっと狙われてそうですw

発表で上げられた機能で気になったのは下の2つです。

  • SLBのWeight設定。デフォルトの優先度は100で、この値によってリクエストを振り分ける優先度を決めてくれる。
  • ISP回線の設定。ここを変えるだけでサービスの国際化が楽にできる。

SLBのWeightを変えることで、サーバーのスペックによって振り分けの対象を変えることができるようになります。コストの最適化に有効ですね。

サービスの国際化は金盾がある中国ならではですね。

一言感想

最後にスカイアーチさんへのお問い合わせ窓口のスライドがあってよかったですw

(5) アリババクラウドでサーバレス頑張ってモバイルアプリを作った

f:id:asmsuechan:20181116115125j:plain

私の発表です。詳しい話はAlibaba Cloud Advent Calendar 2018の12/3で書くつもりです!

今回も発表前にビール1リットルくらい飲んでコンディションを整えて臨みました。

簡単に言うとアリババクラウドでFunction Computeを使ってサーバレスやった中での学びやつらみの話でした。

正直この辺の話は実装中戸惑った時に知りたい話なので、その時ググって私のブログ記事を読めば解決します。みなさんアリババクラウドでサーバレスやっていきましょう!

(6) アリババクラウドMVP表彰

アリババクラウドコミュニティへの貢献者に与えられたアリババクラウドMVP(Most Valuable Professional)の表彰式が行われました。

f:id:asmsuechan:20181116120809j:plain

私もいただきました、ありがとうございます!

アフターパーティー(って言うとちょっとカッコよくなるけど普通の懇親会)もめちゃくちゃ盛り上がって楽しかったです。

次回は12月12日です。残り枠少なめなので興味のある方はお早めに!

alibabacloud.connpass.com

Babel7でES6のテストをmochaで走らせようとすると Cannot find module 'babel-core/register'

Babel7でES6のテストをするためにmochani --compilers js:babel-core/register" をつけて実行したところ以下のエラーが起きました。

$ yarn run test
yarn run v1.5.1
(node:86730) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
$ mocha --compilers  js:babel-core/register
internal/modules/cjs/loader.js:583
    throw err;
    ^

Error: Cannot find module 'babel-core/register'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:581:15)
    at Function.Module._load (internal/modules/cjs/loader.js:507:25)
    at Module.require (internal/modules/cjs/loader.js:637:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at program.compilers.forEach.c (/Users/asmsuechan/src/bot/node_modules/mocha/bin/_mocha:503:3)
    at Array.forEach (<anonymous>)
    at Object.<anonymous> (/Users/asmsuechan/src/bot/node_modules/mocha/bin/_mocha:495:19)
    at Module._compile (internal/modules/cjs/loader.js:689:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)
    at startup (internal/bootstrap/node.js:236:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:560:3)
error An unexpected error occurred: "Command failed.
Exit code: 1
Command: sh
Arguments: -c mocha --compilers  js:babel-core/register
Directory: /Users/asmsuechan/src/bot
Output:
".
info If you think this is a bug, please open a bug report with the information provided in "/Users/asmsuechan/src/bot/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

以下のような設定です。

// package.json
  "scripts": {
    "test": "mocha --compilers js:babel-core/register",
    "deploy": "serverless deploy",
    "build": "babel scripts/* -d dist"
  },

  "devDependencies": {
    "@babel/cli": "^7.1.5",
    "@babel/core": "^7.1.5",
    "@babel/preset-env": "^7.1.5",
    "aws-sdk": "^2.9.0",
    "chai": "^3.5.0",
    "chai-as-promised": "^6.0.0",
    "mitt": "^1.1.3",
    "mocha": "^5.2.0",
    "sinon": "^7.1.1"
  }

// .babelrc
{
  "presets": [
    [
      "@babel/preset-env"
    ]
  ]
}

解決

Babel公式の Upgrade to Babel 7 に書いてありました。

The deprecated usage of babel-core/register has been removed in Babel 7; instead use the standalone package @babel/register.

yarn add --dev @babel/register してscriptsを"test": "mocha --compilers js:@babel/register" としたら通るようになりました。

なお、mochaの --compilers オプションはいずれ使えなくなるらしいので --require @babel/register にしましょう。