CYDAS Developer's Blog

サイダス技術者ブログ

AWS Summit Tokyo 2日目に参加してきました

こんにちは、たじりん(@ayaka_pespes)です。

AWS Summit Tokyo 2019の2日目に参加してきました。 そのレポートになります。

Serverless/AppSync によるモバイル開発の今

AppSyncとは何か、どういうメリットがあるか、というような内容でした。 AppSyncはGraghQLのマネージドサービスで、セッションを通してGraghQL便利そうだなと思いました。

事例としてグノシーの方が登壇されていました。 以下のような内容を話されていました。

  • グノシースポーツというサービスでAppSyncを使用している
  • リアルタイム更新、スキーマファーストになる、複雑かつnestな構造のデータが取得が可能 といった理由から、AppSyncを選択
  • リアルタイム更新
    • Dynamoに更新があるたびにリアルタイム通知する
  • スキーマファースト
    • GraghQLは先にスキーマを定義し、それに合わせてサーバサイドを実装するため、スキーマファーストとならざるを得ない
  • REST APIだとAPI仕様書が必要だが、API仕様書を記載するコストが高い
  • REST APIだとUIを変更するたびにAPIも修正する必要があったが、GraghQLではそういったことがない
  • バックエンドはUIがデータにアクセスする方法を提供
  • Tips
    • GSI(Dynamo)だけでなく、ElasticSearchも使うと良い
    • lambdaをdatasourceにするときは慎重に(ホットスタート/コールドスタートの問題など)
    • 最適な環境をシュッと作れる

私自身RESTで実装していた時に、API仕様書の記述が面倒・ちょっとした画面の変更でもAPIを直さなければならないことは面倒に感じていました。 GraghQLを使うと、そういった問題が解決できそうです。 今後APIを作成するときはGraghQLも候補に入れて行きたいと思いました。

最後にライブでデモをしていました。 いくつかのコマンドを実行し、少しコードを修正して、簡単にwebサイトが動いていました。

CEO ジム・ローズ来日:CI/CDが変革する開発現場・ビジネスとしてのCircleCIの未来

CircleCIは日本に注力をしているそうです。 日本APAC拡大へのHUBにするといった考えもあり、日本での採用を増やしているそうです。

CD(Continuous Deployment)の話をその後話していていました。 結局本番環境にリリースしてみないとわからないという話でした。 切り戻しが容易にできる、修正がすぐにリリースできれば本番環境にリリースし、問題があればすぐに切り戻したり、修正してリリースすることができます。

開発環境と本番環境の差異やリリース後に仕様が違うと言われることはあると思います。 本番にリリースした後、大丈夫かなとよく不安になります。 しかし、修正してすぐにリリースができれば、リリースのハードルが下がります。 CI/CDちゃんとやりたいなと改めて思いました。

Amazon Alexa音声インターフェースへの新しい挑戦。スマートホームを実現するAWS IoT

スマートホームの話です。 しかし、スマートホームの話だけでなく、使われるスキルを作るヒントを得ることができました。

赤外線リモコンを発売されているラトックシステム様が事例として登場されていました。 以下のようなお話をされていました。

  • AWS IoTを使った赤外線リモコンを発売している
  • スマートホームAPI
    • APIがサポートするデバイスと機能のみ
    • 発話がプリセットされている
    • スキルの呼び出し名不要
    • アカウントリンク必要
  • Alexaで赤外線リモコンを操作するとき
    • Echo → skill → lambda → AWS IoT Core → 赤外線リモコン
  • スマホリモコンから赤外線リモコンを操作するとき
    • スマホアプリ → AWS IoT Core → 赤外線リモコン
  • カスタムスキル
    • 発話を覚えられない
    • 発話が複雑になりがち
    • スキル名を言う必要がある
  • スマートホームスキル
    • 発話がシンプル
    • 発話が統一されている

alexaに対応している赤外線リモコンが10万ユーザーに登り、大ヒット商品となったそうです。 また、作成したスキルは作成したdeveloper以外の人にテストしてもらうのが大事だそうです。 シンプルな発話は大事だと言われてはっとしました。 ついつい、なんでもできる方がいいと思いがちですが、使いやすいのはシンプルなものだったりします。 特に音声で操作するときは一度に提示できる情報が多くないので、いかにシンプルにするかは、かなり重要だなと思いました。

2日目まとめ

他にも2日目にはre:MIXというイベントがありました。 AWSウルトラクイズで上位3名はre:Inventにいけるという特典がありました。 クイズは初心者から上級者まで楽しめて、想像以上に楽しかったです。 セッションやイベントなど、内容が濃く新しい知識を得られた1日でした。

サイダス技術部に5月からジョインしました、たじりんです

初めまして、たじりん(@ayaka_pespes)です。 5月からサイダスにジョインしました。 ちょうど1ヶ月が経ったので、入社エントリーを書きます。

入社までの経緯

2019/2/23にJAWS DAYSに参加したことがきっかけでした。 以前にもサイダスの方がイベントで登壇されているのを拝見して興味を持っていました。

JAWS DAYSの二次会で酔っ払って騒いで転職したいという話をしていたところ、CTOの吉田さんから、サイダスを受けてみないかというお話をしていただきました。 それがきっかけになり、wantedlyから応募をして、ジョインさせていただくことになりました。

入社してよかったこと

  • 1on1やOKRを積極的に行っている
    定期的にCTOとの1on1があります。 1on1を通して、自身のキャリアや今後の目標を改めて考えることができました。 1on1ではOKRの話もします。目標を設定し、共有します。 やはり目標がある方が具体的なアクションをしやすくなると思いました。

  • コミュニティ活動をやりやすい
    サイダスはコミュニティや勉強会などへの参加を推奨しています。 特に登壇は機会があるなら、積極的に登壇することを良しとしています。 私以外にもイベントを開催したり、社外で登壇するような人が多数おり、気持ち的にとても動きやすくなりました。 また、イベントをやる、登壇するという時に応援してもらえるので、前よりも積極的に動けるようになりました。

  • モブワークでコミュニケーションを取りやすい
    私は今チームで開発を行っており、常にzoomをつないだ状態で仕事をしています。 雑談も交えながら、すぐに質問ができ、とてもコミュニケーションを取りやすいです。 まだ、入社して1ヶ月ですが、社内でもくもく会したいと言った時にも参加してくれる人がたくさんいました。 よかったら一緒に勉強しましょうと言いやすい雰囲気だったからこそ、もくもく会もできたと思っています。

  • 会社がおしゃれ
    沖縄本社はとても綺麗です。カフェみたいです。 今はマンスリーマンションに住んでいるのですが、マンスリーよりも会社が好きで、土日も会社にいることが増えました。

入社後のギャップ

  • 日本人以外の方も結構いる
    良いギャップです。 入社前は日本人ばかりかと思っていましたが、日本人以外の人も複数名います。 またこの後も何名か外国の方が増えるようです。 基本は日本語でコミュニケーションをとりますが、私も英語喋れた方がいいと思うようになりました。 基本的にどの国の方でも日本語は厳しいけど、英語はOKという方が多いので、私が英語を喋れることで、コミュニケーションがもっと円滑に取れるのではないかと考えています。

  • 技術部以外の方との交流が少ない
    技術部以外の方はフロアが分かれているため、あまり交流がありません。 一ヶ月に一回納会と言う名の飲み会があり、そこでは交流の機会があります。 しかし、人見知りを発揮してしまい、あまり交流ができなかったので、後悔しています。

そんな感じで1ヶ月が過ぎました。 もっとインプットとアウトプットを増やしていきたいと思っています。 本を読む、勉強会に行くと言ったようなインプットを増やし、ブログや登壇等でアウトプットしたいと思っています。
とても居心地よく感じているので、会社に対してもっと貢献できることを増やしたいです。 またこの技術ブログにも今後登場すると思うので、よろしくお願いします!

Introduction to installable feature of PWA

This article will introduce PWA installable feature which makes web app looks like a native app.

What is a Progressive Web Apps

PWAs are web apps developed using a number of specific technologies and standard patterns to allow them to take advantage of both web and native app features

There are some key principles a web app should try to observe to be identified as a PWA. It should be:

  • Discoverable: so the contents can be found through search engines.
  • Installable: so it's available on the device's home screen
  • Linkable: so you can share it by simply sending a URL
  • Network independent: so it works offline or with a poor network connection
  • Progressive: so it's still usable on a basic level on old browsers, but fully-functional on the latest ones.
  • Re-engageable: so it's able to send notifications whenever there's new content available
  • Responsive, so it's usable on any device with a screen and a browser -- mobile phones, tablets, laptops, TVs, fridges, etc
  • Safe: so the connection between you an the app is secured against any third parties trying to get access to your sensitive data.

In this article, We just focus on the Installable feature.

Install a PWA web app

The demo web app is here: https://tsq-demo-app.github.io/coinmarket . It's a SPA and built with Vue.js.

We will use Chrome on Mac, Windows, Android and use Safari on iPhone.

Installation on Mac

mac

Installation on Windows

windows

Installation on iPhone

iPhone

Installation on android

android

How make a website installable

To make the website installable, it needs the following things in place:

  • A web manifest, with the correct fields filled in
  • The website to be served from a secure(HTTPS) domain
  • An icon to represent the app on the device

The key element is a web manifest file, which lists all the information about the website in a JSON.

We can create a file named manifest.json. It should be included in the <head> section of the index.html file via the following line of code:

<link rel="manifest" href="manifest.json">

The content of the file looks like this:

{
  "name": "COINMARKET",
  "short_name": "COINMARKET",
  "description": "An App that displays the mark cap rankings, price, details and more for the top 100 larget crytocurrencies based on overall market cap.",
  "icons": [
    {
      "src": "./img/icons/android-chrome-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "./img/icons/android-chrome-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "start_url": "./index.html",
  "display": "standalone",
  "background_color": "#fff",
  "theme_color": "#00d1b2"
}

let's break down the document and explain them in detail:

  • name: The full name of your webapp
  • short_name: Short name to be shown on the home screen
  • description: A sentence or two explaining what your app does
  • icons: A bunch of icon information, source URLs, sizes and types. Be sure to include at least a few, so that one that files best will be chosen for the user's device.
  • start_url: The index document to launch when starting the app
  • display: How the app is displayed: can be fullscreen, shandalone, minimal-ui, or browser
  • background_color: A color for background, used during install and on the splash screen
  • theme_color: A primary color for the UI, used by operating system

The bare minimum requirement for a web manifest is name and at least one icon (with src, size and type). The description, short_name and start_url and recommended.

Summary

Installable is a very cool feature which makes your website look like a native app. Even though, it's not supportted by all browsers now, I think it will become more and more popular in the future.

If you want to learn more about PWA, the MDN web docs is a good place.

VuexとAtomic Design

f:id:kfukuyama:20190522213224p:plain

大阪からこんにちは、福山健@kenfdev)です。

フロントエンドに関わっているエンジニアであればAtomic Designというのを聞いたことがあるかもしれません。

フロントエンドの開発をしていく上で大事なことの一つに、画面の部品をどのようにComponentに分割していくかというものがあります。

きっとたくさんのフロントエンドエンジニアがこの点については毎回悩まれると思います。

そこで、どのように分割していくと良いかという指標の一つとしてAtomic Designという考え方があると僕は解釈しています。

Atomic DesignはBrad Frostさんという方が提唱したもので、英語であれば下記にて公開されていますし、本を注文することもできます。

atomicdesign.bradfrost.com

また、日本では下の書籍がReactを使って具体的にわかりやすく説明されています。(ただし、SPAフレームワークを触ったことが無いとちょっとつらいかも)

Atomic Design ~堅牢で使いやすいUIを効率良く設計する

Atomic Design ~堅牢で使いやすいUIを効率良く設計する

この記事ではAtomic Designについては詳しく見ないので、そもそもAtomic Designについて知りたい方は上の書籍や、わかりやすいブログ記事も多数あるのでそれらを先に読むことをおすすめします!

ではこの記事で何を述べるかと言うと、Vue.jsのVuexを使ったプロジェクトでAtomic Designを採用した場合に、VuexのStoreとAtomic DesignのComponentがどのようにやり取りすると良いかを紹介します。

あくまでこのやり方は1例に過ぎず、やり方は多数ありますので迷っている方の参考になればと思います!(CYDASでもやり方は日々アップデートしています!)

Atomic DesignとVuexで何に迷うのか

これは「Atomic Designだから」、という問題では無いのですが「誰がVuexを意識するのか?」という課題が常につきまとってきます。

具体的には:

  • 誰がVuex StoreからStateを受け取ることができるのか
  • 誰がVuex StoreにActionをdispatchしていいのか

という2点がポイントになってきます。ここに一定のルールを設けないと、そこら中からStateを受け取ったり、そこら中からActionをdispatchしたりしてどこで何が起きているのかかなり追いづらくなってしまいます。

イメージとしては下図のような状況です。

f:id:kfukuyama:20190521072408p:plain
フローが追いにくい関係

「Pages, Templates, OrganismsはPropsを受け取ることもあれば、Storeからstateを受け取ることもあり、eventを$emitすることもあればStoreにdispatchすることもある。」のがわかります。

これでは流れが追いにくかったり、実装するときも迷いが生じやすくなります。

Atomic DesignとVuexの良い関係

そこで、僕が今のところ良いと思っているAtomic DesignとVuexの関係は下図のようになります。

f:id:kfukuyama:20190521091719p:plain
追いやすくしたフロー

言語化すると、

  • Storeからstateを受け取るのはPagesのみ
  • Pages以外はPropsでしか入力を受け付けない
  • Storeにdispatchして良いのはPagesとTemplatesのみ
  • Pages, Templates以外はdispatchしてはいけない(イベントは$emitするのみ)

というルールになります。

StoreはPagesのみが意識すべきでは?

ここで出てきそうなのが「StoreはPagesのみが意識すべき」という意見です。

ルールとしてはわかりやすいんですけど、実際にやってみるとTemplates→Pagesにeventを$emitして、PagesからStoreにdispatchするのが冗長に思いました。

f:id:kfukuyama:20190522192314p:plain
Templates→Pagesのコピペ感がつらい

Templates→Pagesへの$emitが増えるほどPagesでもイベントハンドラが増えてしまうのです。。。(やり方はいくつかあるにせよ冗長さは避けられないと思います)

そういうわけでCYDASでは「dispatchに関してはTemplatesからやってもいいのでは?」という意見もあってTemplatesまではStoreを意識して良いルールにしています。

Pagesはいつdispatchする?

Templatesがdispatchするなら、むしろPagesはいつdispatchするのか?という疑問も出てくると思います。

基本的にOrganismsより下の層から$emitされたイベントについてはTemplatesからStoreにdispatchします。

なので、Pagesがdispatchするタイミングはmountedなどの、ページ初期化時などのタイミングくらいしか無いのかなと思っています。

TemplatesにPropsは必要なのか?

Templatesからdispatchができるなら、いっそのことstateもStoreから持ってこればいいのでは?という疑問も出てきます。

それをやってしまうともはやPagesが必要なくなると思うのですが、あくまでデータはProps経由でもらうというルールにしています。

というのも、Atomic Design(にこれも限らずですが)とStorybookを組み合わせて使うことも多いかと思います。

storybook.js.org

このStorybook上でTemplatesを表現する際に、Propsで制御できたほうがVuexのセットアップ(gettersだったりstateだったり)が必要なくなります。

標準のVue.jsで、Propsにデータを差し込むだけでいろいろなデータを流し込めるので、変に手間のかかることをせずに済むと思っています。

そういったわけで、TemplatesはPropsでデータを受け取るようにしています。

まとめ

この記事で述べているやり方はあくまで1例にすぎません!大事なのは皆が好き勝手違う書き方をしてしまわないようにルール(コーディング規約)をある程度決めておくことだと思います。

そしてやってみて、フィットしなかったらもっと良いと思う方法に変えていけば良いんだと思います(手戻りは発生してしまうのは覚悟の上で)!

参考

【開催報告】AliEeates Okinawa Meetup #1

こんにちは。エンジニアのしのっちです。 遅くなってしまいましたが、4/24 に開催しました AliEeates Okinawa Meetup #1 の報告です。

Connpass のページ
alieaters-okinawa.connpass.com

石川さんによる Twitter まとめ
togetter.com

Alibaba Cloud概要と海外最新動向紹介

f:id:semnil:20190430111028j:plain Alibaba Cloud の強みである BigData 基盤の活用事例を中心に紹介いただきました。FlyZoo Hotel は未来体験が詰まっていて、すぐにでも用事を見つけて出張申請したい雰囲気でした!

AlibabaCloud基本プロダクトと最新プロダクト紹介

f:id:semnil:20190430110338j:plain 売れる EC サイトが自動生成されてしまうとか驚きでした。 新しいサービスがリリースされていく順番 (中国 → International → 日本) など、興味深いお話が聞けました。

真吾吉田のMVPな話

f:id:semnil:20190430111255j:plain これから盛り上がっていく企業の話とか、そんな中で自分たちが何をやっていかなければいけないかというお話でした。

サイダスエンジニアによる LT 三連発

LT①:Alibaba CloudでServerlessに入門しました

yudy1152.hatenablog.com

「日本語のドキュメントがわかりやすい」というのが印象的でした。

LT②:RAMユーザのパスワード誤入力をSlackに通知させてみた

blog.pirox.dev

実現までに困難が多く、なかなか大変だったようです。

LT③:Alibaba Cloud Container Service で自作キーボードのファームウェアをビルドしてみた

www.slideshare.net

最後は私の LT ですが、完全に趣味全開で自作キーボードを熱く語っただけの内容でした。 当日は時間の都合で泣く泣く割愛した動画もここにこっそり貼っておきます。
Helix キーボードキットを製作している様子 (60 倍速) - YouTube

最後に

Alibaba Cloud は全体的に AWS に似ているところが多いので、経験者なら入門は簡単です。 登録すると無料のクーポンがもらえるので、結構遊べると思います。 今回の LT はサイダスのエンジニア 3 人になってしまいましたが、皆さんの積極的な参加をお待ちしています!

サイダスの技術部にジョインしました、湯です

はじめまして。エンジニアの、湯です! 以下は社内でシェアしている私のトリセツです。

どんな問題に対するソリューションが得意か

フロントエンドとNodejs関連のこと。

そのソリューションについてどの程度エキスパートか?(経験者上位何%など)

経験者上位何%かは難しいところですが、前々職での実績値は上位 50%頃 です。

上司となる人に期待すること

  • 性格がいい。
  • 新しいことにチャレンジしていること。

同僚に対してあなたができる(できそうな)こと

私にできそうな事があれば、なんでも気軽にご相談ください。

同僚となる人に期待すること

チームで助け合う気持ちを持っていること。

ワークライフバランスについてどういう考えを持っているか

健康な生活、楽しい仕事。

リモートワークについてどういう考えを持っているか

今までリモートワークをやったことがないけど、やってみたい。

1年後どのような職業人でありたいか

  • 日本語が上手になる、同僚とよく交流できる。
  • 自分の得意技術は新入社員に教えたい。

3年後どのような職業人でありたいか

プロジェクトのリーダーになりたい。

Cloud Native Developers JP - Serverless で発表してきた

サイダス吉田真吾@yoshidashingo)です。

昨日開催された Cloud Native Developers JP(cndjp) の第11回勉強会でサーバーレスの話をしてきました。 cnd.connpass.com

前回ここに来たのはおそらく7年前のJPOUGの初期の頃のイベントで DataPump について話したときでした。非常に懐かったです。資料は以下のとおりです。