LifeHack Engineering Blog

LifeHack by Web or IoT

GMailをGCalendarに登録するサービス rMinc を作ってみた

f:id:silverbirder180:20200216214751p:plain
rMinc

ターゲットユーザー

  • GMailとGCalendarを使っている人

メールを開くって面倒じゃないですか?

例えば、次のようなメールを受信していたとします。

  • アマゾンで商品を購入した際、お届け予定日が記載されたメール
  • 映画館(TOHOシネマ)でネット予約した際、上映日が記載されたメール
  • ホテルをネット予約した際、宿泊日が記載されたメール

『いつ商品が届くのかな?メールを確認しよう』が、面倒と感じませんか?私は面倒と思います。 Googleは気を利かせて、次のような予定を勝手に登録してくれることがあります。(良い悪いがありますが...)

f:id:silverbirder180:20200216115925p:plain
unknownorganizer@calendar.google.com

この気を利かせるかどうかは、Googleの判断によるため未知数です。 先程あげた例のメールも、同様のことが勝手にしてくれたら良いな〜と思っていました。 そこで、rMincというツールを作りました。

※ 昔、gas-for-amazon-calendarという、アマゾンからのお届け予定日が記載しているメールをGCalendarに登録するツールを作りましたが、 アマゾンのメールに特化しすぎてしまい、汎用性がないものとなりました。

rMinc is 何?

www.npmjs.com

rMinc is the Google Apps Script Library that register Mail in Calendar.

以下サービスからのGMailが届いたときに、その内容を抽出してGCalendarに登録します。

  • Amazon
    • 発送のお知らせ (お届け予定日)
  • TOHO CINEMAS
    • チケット購入完了のお知らせ (上映日)
  • 食宅便
    • 配送手配のお知らせ (お届け予定日)

また、これ以外にも対応したいサービスがあると思うので、カスタマイズして使えるようにしました。 詳しくは、README.mdをご確認下さい。

概要はこんな感じです。 overview

  1. 特定キーワードでメールを抽出
    1. アマゾンなら、from:(shipment-tracking@amazon.co.jp) 発送
  2. メールの下記を抽出
    1. タイトル
    2. 本文
      1. イベント開始日&終了日 (予定日とか)
      2. 場所 (配達先とか)
    3. メールのリンク
  3. 抽出した内容をGCalendarに登録

実際に使ってみるとこんな感じになります。 example

小さくて見えないと思いますが、お届け予定日、タイトル、配達先、メールリンクが登録されています。

このツール(sample.js)をGAS上で定期的に動かしておくだけで、自動的にGCalendarへ予定登録されます。当たり前ですが、無料です。

※ RMincは、README.mdにあるAPP IDを登録する必要あり

最後に

Google Apps Scriptは、エンジニアにとって、とても強力な武器です。特に、G Suiteを積極的に使っている人にとっては、欠かせないものです。

こういった かゆいところに手が届く ことができるのは、Google Apps Scriptの魅力的なところです。 ぜひぜひ、積極的に活用していきたいですね!

1コマ漫画検索サービスTiqav2 (Algolia + Cloudinary + Google Cloud Vision API) 作ってみた

画像で会話って楽しい

皆さん、チャットツールでコミュニケーションするとき、絵文字や画像って使ってますか? 僕はよく使ってます。人とコミュニケーションするのに、文字だけだと堅苦しいイメージですよね。 例えば、

『OKです、それで先に進めて下さい。』

というフレーズだけだと、相手がどのような感情なのか読み取りにくいです。

そこで、次のような画像でコミュニケーションを取ると、柔らかい印象を与えることができます。

https://res.cloudinary.com/silverbirder/image/upload/v1580997144/LGTM/golia.png

Tiqav2

Tiqavとは?

画像を使って会話をするためのサービスとして、Tiqavがあります。 dev.tiqav.com

現在は、サービス終了しています。 Tiqav2は、そのTiqavを参考にして作りました。

Tiqav2とは?

Tiqav2は、大きく分けて2つの機能があります。

  1. 画像とテキストを保存
  2. 画像を検索&表示

2つの機能

画像とテキストを保存

f:id:silverbirder180:20200207231047p:plain
Saving flow by Tiqav2

検索する為には、全文検索サービスのAlgoliaを使います。 www.algolia.com

Algoliaに保存する情報は、主に3つです。画像URLと拡張子、そしてテキストです。 画像は画像変換&管理サービスのCloudinaryに保存します。保存後、Cloudinaryより、画像URLと拡張子が手に入ります。 cloudinary.com

テキストは、Google Cloud Vision APIへ画像を渡すことでテキストを抽出します。 もちろん、手動でテキストを設定することもできます。 cloud.google.com

画像を検索&表示

f:id:silverbirder180:20200207074256p:plain
Searching Flow By Tiqav2

テキストで全文検索を行います。その結果のIDとExtensionを組み合わせることで、 画像を表示することができます。Extensionの種類は、Cloudinaryのサポートするもの全てになります。

"gif", "png", "jpg", "bmp", "ico", "pdf", "tiff", "eps", "jpc", "jp2", "psd", "webp", "zip", "svg", "mp4", "webm", "wdp", "hpx", "djvu", "ai", "flif", "bpg", "miff", "tga", "heic"

cloudinary.com

この画像を表示する機能を使うと、次のようにSlack上で画像を送信することができます。

f:id:silverbirder180:20200207230322p:plain
Send Tiqav2 URL on Slack

詳しい機能は、次のリポジトリをご確認下さい。 github.com

SaaSは個人開発には最適

今回、全文検索であったり画像管理は、SaaSに全て任せました。テキスト抽出はなくてもよかったのですが、Google Cloud Vision APIが、そこそこ使えたため、そちらも使いました。

個人で開発する際、リソース(時間、お金、人)は組織に比べてとても小さいです。 SaaSは、1つのことを上手くやってくれるし、個人の利用範囲であれば無料なものが多いです。 ニッチなカスタマイズしたい要求がない限り、SaaSは大体の要望を叶えてくれます。 どんな種類のSaaSがあるか知りたい方は、↓のサイトを見てみて下さい。参考になるはずです。 saasblocks.io

SaaSに面倒なことは任せて、プロダクトコードに集中する』ことは、私にとって、とても大切にしています。 ちなみに今回のプロダクトコードは、CleanArchitecture + InversifyJSで作りました。

終わりに

Tiqav2は、OSSとして公開していますので、誰でも無料で構築できます。 ぜひ、使ってみて下さい。快適なコミュニケーションを目指しましょう!

その他

↓のアカウントで技術的なことをつぶやいています。 twitter.com

Google Apps Script でも テスト がしたい! (Clasp + Typescript + Jest)

f:id:silverbirder180:20200201212044p:plain
Google Apps Script + Typescript + Jest

Google Apps Script(以下,GAS)でライブラリを公開しました。ライブラリを開発する際、テストのフィードバックサイクルを短くするため、Clasp + Typescript + Jest という技術スタックを選択しました。 その開発体験について共有しようと思います。特段変わったことはしていません。

Google Apps Scriptのテストってどうしてますか?

script.google.comにアクセスしてデバッグ実行って、しんどくないですか?

f:id:silverbirder180:20200201234221p:plain
Google Apps Script Debugging ...

  • ネットワーク越しでステップ実行するため、遅い
  • G Suite系のサービスと連携すると、サービス側の調整(データ準備とか)が面倒
  • デバッグ機能が貧弱

とてもストレスフルです。単純なGASなら別に良いんですが、少し複雑なGASを作ろうと思うと、問題に感じます。

ローカルで動かそう

GASをローカル環境で動かすことができる ClaspというコマンドラインツールがGoogleより公開されています。 github.com

また、ClaspはTypescriptをサポートしているため、型を中心としたコーディングが可能となりました。 www.npmjs.com

Typescriptを選択すると、Interface設計が容易になります。もちろん、.gs ファイルでも同様の事は実現できると思います。

次に、Jestと呼ばれるテストツールを組み合わせることで、ローカル環境でテストが可能になります。 jestjs.io

ただ、単純にテストコードが書けません。 例えば、カレンダーイベントを取得するテストをコーディングするとき、次のようなスクリプトを書いたとします。

const calendar: Calendar = CalendarApp.getCalendarById('<your google calendar id>');
calendar.getEvents(new Date('2020-01-01'), new Date('2020-01-02')).forEach((calendarEvent: CalendarEvent)=> {
   console.log(calendarEvent.getTitle());
});

こう書いてしまうと、本当のカレンダーイベントを取りに行ってしまいます。テストであれば、そういった処理は避けたいところです。 そこで、CalendarApp を偽物のオブジェクト、つまりMockオブジェクトに差し替えるため、依存性逆転の原則(dependency inversion principle)を適用します。

interface ICalendarApp {
    calendars?: Array<ICalendar>;
    getCalendarById(id: string): ICalendar;
}

interface ICalendar {
    calendarEvents?: Array<ICalendarEvent>
    getEvents(startTime: Date, endTime: Date): Array<ICalendarEvent>;
}

interface ICalendarEvent {
    title?: string,
    getTitle(): string;
}

class CalendarAppMock implements ICalendarApp {
    calendars?: Array<ICalendar>;

    getCalendarById(id: string): ICalendar {
        return this.calendars![0].calendar
    }
}

class CalendarAppImpl implements ICalendarApp {

    getCalendarById(id: string):  ICalendar{
        const calendar: ICalendar = CalendarApp.getCalendarById(id);
        return calendar;
    }
}

このようなインターフェース・クラスを準備し、先程のコードを次のようにします。

const calendar: ICalendar = new CalendarAppMock().getCalendarById();
calendar.getEvents(new Date('2020-01-01'), new Date('2020-01-02')).forEach((calendarEvent: ICalendarEvent)=> {
    console.log(calendarEvent.getTitle());
});

結果、CalendarApp の代わりにMockオブジェクトを差し込めるようになりました。ローカルテストが可能となります。

もちろん、プロダクトコードでは、CalendarAppMock ではなく、 CalendarAppImpl を使用すれば良いです。 Mockで差し替えるオブジェクトが増えると、InversifyJSのようなDIコンテナを検討してみると良いかもしれません。 github.com

こうすることで、Jestによるテストが動作するようになります。
実際に、開発・公開したライブラリでも十分にテストをすることができました。 www.npmjs.com

CaAT $ npm run test -- --coverage

> jest "--coverage"

 PASS  __tests__/utils/dateUtils.test.ts
 PASS  __tests__/group/groupImpl.test.ts
 PASS  __tests__/member/memberImpl.test.ts
---------------------|---------|----------|---------|---------|-------------------
File                 | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
---------------------|---------|----------|---------|---------|-------------------
All files            |   98.43 |    97.62 |   96.67 |   98.37 |                   
 __tests__           |     100 |      100 |     100 |     100 |                   
  generator.ts       |     100 |      100 |     100 |     100 |                   
 src/calendar        |    93.1 |      100 |   92.31 |   92.59 |                   
  calendarAppImpl.ts |      60 |      100 |      50 |      60 | 6,7               
  calendarAppMock.ts |     100 |      100 |     100 |     100 |                   
 src/group           |     100 |      100 |     100 |     100 |                   
  groupImpl.ts       |     100 |      100 |     100 |     100 |                   
 src/member          |     100 |    94.74 |     100 |     100 |                   
  memberImpl.ts      |     100 |    94.74 |     100 |     100 | 38                
 src/utils           |     100 |      100 |     100 |     100 |                   
  dateUtils.ts       |     100 |      100 |     100 |     100 |                   
---------------------|---------|----------|---------|---------|-------------------

Test Suites: 3 passed, 3 total
Tests:       23 passed, 23 total
Snapshots:   0 total
Time:        2.826s, estimated 6s
Ran all test suites.

ライブラリとして提供する機能のテストが、たったの約3秒で終わります。 ストレスフリーにローカル開発が可能となりました。

詳しくは、実際に作ったライブラリのソースコード(__tests__)を御覧ください。

終わりに

GASは、とても便利です。生産性が向上します。 サクッとAPIを構築できますし、G Suiteとの連携も(当たり前ですが)簡単です。

ただ、メンテナンス性が低いコードになると、陳腐化され誰も面倒が見れなくなります。 常にクリーンであり続けるためには、テストコードは必須です。 GASを運用する方々には、是非ともテストコードを検討下さい。

え、あ、ちょっとまって。ライブラリの紹介!

アジャイル開発で、かつ、Google Calendarで予定管理しているチームには是非とも使って頂きたいライブラリです。 github.com

CaAT is the Google Apps Script Library that Calculate the Assigned Time in Google Calendar.

このツールでできることは、次のとおりです。

  • 指定期間における特定ユーザーのGoogle Calendarで予定されている時間(分)を取得
  • 重複している予定は、連続した予定とみなす
  • 指定の時間・単語は、計算対象外とみなす (ランチなど)
  • 誰がいつ休みなのか、終日イベントから取得

実際にサンプルコードがあるので、ご参考下さい。

github.com

エンジニアのためのスマートホーム化

f:id:silverbirder180:20200116075602j:plain Banner vector created by macrovector - www.freepik.com

エンジニアの皆さん、IoT使っていますか? スマートホームに欠かせないIoT商品を使うことで、生活体験はより良くなります。

この記事では、ご自宅をスマートホーム化するためのIoT商品をリストアップします。 『そんなのあるの?』という気づきがあれば、幸いです。

スマートプロダクト リスト

スマートリモコン

Nature Remo

nature.global

スマートスピーカー

Google Home

store.google.com

スマートロック

SESAME

jp.candyhouse.co

スマートトラッカー

Tile

thetileapp.jp

スマートタグ

Qrio Smart Tag

qrio.me

スマートスイッチ

Switch Bot

www.switchbot.jp

スマートボタン

Qmote S

http://qblinks.com/jaqblinks.com

スマート加湿器

SwitchBot加湿器

www.switchbot.jp

スマートプラグ

www.tp-link.com

スマートスケール

Withings Body +

www.withings.com

スマートスリープ

Withings Sleep

www.withings.com

スマートライト

Light Strip Plus

www2.meethue.com

スマートカメラ

Arlo Ultra

www.arlo.com

スマート歯ブラシ

Philips Sonicare

www.philips.co.jp

スマートカーテン

Mornin' Plus

mornin.jp

SwitchBot Curtain

www.rakunew.com

スマートエアモニター

Awair

jp.getawair.com

スマートクリーナー

iRobot

www.irobot-jp.com

スマートテレビ

Chromecast

store.google.com

スマートウォッチ

Apple Watch

www.apple.com

スマートケトル

iKettle

www.smarter.am

スマートグラス

Focals

www.bynorth.com

スマートエナジーハブ

Nature Remo E

nature.global

Other

食宅便

shokutakubin.com

GDG DevFest Tokyo 2019に参加したら、Webの未来にワクワクした

f:id:silverbirder180:20191215100223j:plain f:id:silverbirder180:20191215100227j:plain f:id:silverbirder180:20191215100242j:plain

GDG DevFest Tokyo 2019というイベントに参加してきました。 最近はプライベートの都合上、中々時間が取れていませんでした。 しかし今回、会社の都合上、良い感じに時間を確保できたため、こちらのイベントに参加してきました。 大阪→東京 でわざわざ新幹線を使ってまで参加しましたが、それに見合う発見が多くありました。 今回、私が学んだ内容について、報告しようかなと思います。

gdg-tokyo.connpass.com

GDG DevFest Tokyo 2019

DevFest は、Google Developer Group (GDG) コミュニティによって世界各地で開かれるデベロッパー向けイベントです。東京では、AndroidGoogle Cloud Platform(GCP)、Web、Firebase、Machine Learning (ML)、Assistant、Flutter、Goといった様々な技術の最新情報や現場でのノウハウを一日で学べるコミュニティイベントとして開催しています。去年に引き続き 4 回目の開催となります。 tokyo.gdgjapan.org

名称 GDG DevFest Tokyo 2019
DevFest Day1
2019年12月14日(土)
Sessions、Codelab、After Party
11:00 開始(開場10:30予定)18:00終了
※終了後、懇親会パーティ開催します。
開催場所:国立大学法人電気通信大学
〒182-8585東京都調布市調布ヶ丘1-5-1
DevFest Day1
2019年12月15日(日)
Special Hands-on、Office Tour
14:00 〜 17:00予定
※14日にご参加いただいた方の中から抽選で100名ご招待
開催場所:Google Japan
〒150-0002 東京都渋谷区渋谷3丁目21−3

私は、DevFest Day1のみの参加でした。 開催場所は、電気通信大学です。スタッフさんの多くは学生さんだったと思います。積極的にサポートされていた姿は、立派だなと勉強になりました。

DevFests

DevFests are community-led developer events hosted by Google Developer Groups around the globe. GDGs are focused on community building and learning about Google’s technologies. devfest.withgoogle.com

DevFests自体は、グローバルで活動されているGDGがホストのイベントです。 下の図は、2019年の活動実績&予定です。全国各地で広く活発的に行われていることが分かると思います。

f:id:silverbirder180:20191215102950p:plain
Find an upcoming community-led 
DevFest near you

また、コミュニティのYoutubeのチャンネルもあります。 www.youtube.com 動画には、文字起こしとして 英語(自動生成)だけでなく、 英語(CC) もあります。 英語のリスニングが苦手な人でも、文字から理解できるようになっています。こういう配慮はさすがですね。

Google Developer Experts (GDE)

今回登壇されている方の多くが、 Google Developer Experts (GDE) という言葉を仰っていました。 最初は『Google社内の何かしらのポジションか?』と思っていましたが、違っていました。

A global program to recognize individuals who are experts and thought leaders in one or more Google technologies. These professionals actively contribute and support the developer and startup ecosystems around the world, helping them build and launch highly innovative apps. developers.google.com

GDEの人は、端的に言うと『Googleのテクノロジを開発者やスタートアップ企業らに対して支援・啓蒙活動をしているGoogle外の人』です。 GDEになるためには、GoogleGoogleパートナーからの紹介から入る必要があるそうです。

Sessions

今回のセッションでは、次のようなカテゴリでグループ分けされていました。

  • Android
  • Assistant
  • Cloud
  • Design
  • Firebase
  • Flutter
  • Go
  • ML
  • Web
  • misc (otherかな)

私は、Webが好きな人なので、そのカテゴリを積極的に選んでいきました。

Keynote2: 円周率世界記録への道

Speaker: 岩尾 エマ はるかさん

こちらの記事が、今回の話のテーマとなります。 it.srad.jp 岩尾 エマ はるかさんのお話は、おおよそWikiに記載があるとおりです。

今回の発表の話にあった、以下の話が印象的でした。

  • Linkedin経由でGoogleからのオファーがあり、『5回面接をして、ようやく合格した』

岩尾さんは、『面接するのは無料』という精神で、何度もTryし続けて合格を勝ち取った人です。同じ大阪出身だそうで、納得しました。(笑)

また、元々英語は得意な方ではなかったという話も紹介されていました。 私も英語について悩んでおり、とても共感する部分が多かったです。 英語ができることによって、選択肢は広がる という当たり前の話があったのですが、 『語学が苦手だけど、Google(海外)で勤務できるようになった』という岩尾さんの経歴を知ると、頑張ってみようと思えました。 とても感謝しています。

Chrome Dev Summit 2019: Recap

Speaker: 矢倉 眞隆さん

Chrome Dev Summit(CDS) は、今まで以下のようなテーマが中心でした。

  • 2013
    • Web API, パフォーマンス
  • 2015
    • PWA

そして、今回のCDSでは今までの ゴリゴリのJS 話から少し外れたものもいくつかあり、 その紹介をされていました。

HTMLとCSS

HTML isn't done.

www.youtube.com

HTMLは、まだ成熟されたものではなく、まだまだ改善の余地があるという考えから、 いくつかの改善提案の話が紹介されていました。 いくつか例の紹介をされていましたが、次のqiitaの記事がわかりやすかったです。 qiita.com

丸裸な純粋のHTMLでも、わかりやすいUIを標準で表現できるのであれば、ユーザーにとっては ありがたいことですよね。だって、いろんなサイトのいろんなUIを知らなくて済むのですから。 個人的(開発者)には、EdgeがChromiumベースになることが、とても嬉しいです。 リリースが2020年1月15日だそうなので、もう間もなくですね。

Next-generation web styling

www.youtube.com

以下の記事にあるようなStylingの機能が提案中となっています。 qiita.com 例えば、scroll-snapという機能は、スクロールの制御をCSSで実現しようとしています。 従来は、Javascriptでハックな技を駆使していましたが、不要となります。 デザイナーだけでなく、JSを担当するエンジニアも必見です。

JS +SEO

SEOの話がありました。 www.suzukikenichi.com

Googlebotが最新のChromiumベースになったことで、Chromeでブラウザを動かすのと同じような振る舞いになるそうです。 今までは、Chrome 41ベースでGooglebotが動いていたため、新しいJavaScript構文やブラウザAPIを使えなかったそうです。 また、ShadowDOMにも対応しているので、これはWebComponentsを推進していることになるのでしょうか。

リアルワールド指向のパフォーマンス

開発環境でJavascriptを動かしたとしても、本番環境で動かすと実は遅かったりします。 それは、Javascriptによる処理が複雑化していることも要因となります。 この現象は、ネットワーク通信が悪い環境(海外)であれば、より明確に実感するはずです。 このようなケースを考慮したテスト環境が必要なのではないかと、私は思います。

以下の記事にある通り、Googleは「遅い」と感じるページに警告を出してくれます。

jp.techcrunch.com

パフォーマンス計測ツールを活用することで、事前に確認しておきましょう。

  • web.dev
  • PageSpeed Insights
  • Lighthouse

また、Javascriptをシングルスレッドによる低パフォーマンスに対するアプローチ方法を紹介されていました。

www.youtube.com

詳しくは、下記をご参考下さい。

medium.com

ネイティブアプリとWebアプリの差を埋めるには:Project Fuguとマルチスレッドプログラミング

Speaker: 清水 智公さん

ネイティブアプリとWebアプリの差

Webアプリは、ブラウザ上で動作するのものです。ブラウザから提供されているAPIを通して、Webアプリを構築します。 しかし、ブラウザからマシンのネイティブな部分、例えばマシンにあるファイルにアクセスしたり、ファイルをマシンに 保存したりする操作はできません。この制限は、ブラウザが安全性を担保するためのトレードオフであり、仕方がありません。

Project Fugu

Fugu’s mission is to close the capabilities gap with native to enable developers to build new experiences on the web while preserving everything that is great about the web. www.chromium.org

Project Fuguとは、ネイティブとのギャップを縮めるために、(Chrome)ブラウザからネイティブな部分を操作する試みのプロジェクトのことです。 ネイティブ部分を操作するため、誤った使い方をするととても危険です。 そのような危険性を、『毒』を持つふぐの名前を借りてProject Fuguというそうです。

提案中の機能一覧は、下記のシートになります。

goo.gle この中には、例えば『Contact Picker API』というものがあります。 名前の通り、ネイティブアプリに登録されている電話帳にアクセスできるようになります。 これにより、例えば『シェアしたいユーザーの情報を電話帳より取得する』ことが実現できます。

Worker

ブラウザは、Task(Event→Scripting→Rendering→Painting)という単位で動作します。 これは、1つのメインスレッドのみで動作します。

ブラウザにおけるfpsの目標値は60fpsだそうです。

60fps のフレームレートがなめらかなパフォーマンスの目標値であり、あるイベントに対して必要なすべての更新に与えられた時間は 16.7 ミリ秒です。 developer.mozilla.org

1Taskを実行するのに16.7ミリ秒を超えてしまうと、ガタガタした動作になってしまいます。 そこで、Web Workerという技術で解決しようと考えました。

Web Worker は、ウェブコンテンツがスクリプトをバックグラウンドのスレッドで実行するためのシンプルな手段です。 developer.mozilla.org

しかし、スレッド間のメッセージパッシングが複雑化してしまう問題があるそうです。 その問題を、さらに解決するため、GoogleChromeLabsは、comlinkなるライブラリを開発しました。

Comlink makes WebWorkers enjoyable. Comlink is a tiny library (1.1kB), that removes the mental barrier of thinking about postMessage and hides the fact that you are working with workers. github.com

Web Workerにおけるメッセージパッシングの複雑さがcomlinkによって減少するそうです。

※ atomics.wait() atomics.notify()の話もありました。

How to Distribute Your Web App? 「インストール」可能なウェブアプリ

Speaker: 宍戸 俊哉さん
タイトル通り、Webアプリをどのようにして配布するのかというテーマで、 様々な手段の紹介をされていました。

PWA

Web好きならご存知のProgressive Web App (PWA)のお話です。 Webアプリに対して、よくあるPWA機能は次のとおりです。

  • オフラインで閲覧
  • Push通知
  • フルスクリーン

PWAは、Webアプリでありながら、ネイティブアプリにとても近い存在に位置しています。

例えば、サンタトラッカーというWebアプリがとても良い例です。 santatracker.google.com

ソースコードも公開されており、PWAとして良い参考例になります。 github.com

このWebアプリを『ホーム画面に追加』し、その追加されたアプリを起動してみて下さい。 ネイティブアプリと似たユーザー体験ができるはずです。

ブラウザのブックマークで良いのでは?

わざわざ『ホーム画面に追加』しなくても、ブックマークを使えばよいのでは? という議論がありました。 話の主となっていたのは、モバイルファーストというキーワードでした。 現在、モバイルからのブックマーク利用率はとても小さいみたいですが、 『え?普通に利用しているけど』と反感してしまいました。私が遅れているのでしょうか。 今の時代、『ホーム画面に追加』が多いのでしょうか。少し疑問です。

インストールを促す手段

PWAをインストールしてもらう場合、Mini-infobarというもので誘導します。 ただ、このMini-infobarはヘルパーとして使われるため、別途UIを用意する必要があるそうです。

The mini-infobar is only meant as a helper, and it will go away in the future. developers.google.com

ただ、既にネイティブアプリがある場合、PWAのインストール要求したくありません。 そんなときは、『既にネイティブアプリをインストールしているかどうか』判断する仕組みが既にあるそうです。(origin trials) web.dev

Desktop PWA

モバイルだけでなく、DesktopにもPWAを適用できます。

先程紹介したサンタトラッカーは、Desktop PWAにも対応しています。 santatracker.google.com アドレスバーにある+ボタンよりインストールできます。

Trusted Web Activities (TWA)

Trusted Web Activity は、Android アプリ内で Chrome ブラウザを全画面で実行します。 developers-jp.googleblog.com

Androidアプリでも、PWAが実現できるみたいです。

TWA は、Android アプリの全画面ウェブ コンテンツで WebView では利用できない Chrome 機能を使いたい場合や、Chrome ブラウザとオリジン ストレージを共有することでユーザーのナビゲーションが便利になる場合などに適しています。

私はAndroidユーザーはないので、GooglePlayからアプリをダウンロードできません。

  • Rakuten Pasha
  • OYO Rooms

のようなものがTWA対応しているそうです。 会社内で使うアプリ(勤怠, 経費, etc)を、TWAとして配信することも1つの使い道と紹介されていました。

TWAの開発には、次のライブラリが便利だそうです。 github.com

Web Packaging

PWAやDestop PWA, TWAといったもので、様々なところからWebアプリを 配布する手段が増えました。では、オフラインの場合はどうでしょうか。 その場合は、Web PackagingのWeb Bundlesが使えます。

github.com

Web Packagingには、大きく2つのものが含まれています。

  • Signed HTTP exchanges
  • Web Bundles

前者は、AMPページのURLをgoogleホストから元のホストへ戻す際に有効だそうです。 amp.dev

後者は、Webのアプリケーションを人まとまりにし、オフライン上で提供することができるそうです。

www.youtube.com

chrome canaryフラグを有効化する必要あり

Yearly Web 2019

Speaker: Jxckさん
2019に起きたWebに関するTopicをざっくりと紹介されていました。 ご本人のブログに、詳細が載っていますので、こちらでは項目だけリストアップします。

blog.jxck.io

Topics 補足
Dark Mode, High Contrast Mode
portal tag 画面遷移をCSSでアレンジするアレ。まだバグが多い
WebAssembly
WebAuthN Authenticatorを使った認証API
ES2019 nullish coalescing/ optional chaining
Intelligent Tracking Prevention 合意のないトラッキングはダメ!ゼッタイ!
Project Fugu
DNS over HTTPS/TLS DNSクエリも暗号化
Edge Chromium
WebPackaging
WebTransport WebCodecs ゲームで役立つ?
WebComponents v0 → v1
Same Site Cookie Lax by default Cookieを同じサイトでしか送られなくする
TLS 1.0/1.1 → 1.2

(宣伝:WebComponentsの入門書、いいぞ〜!) booth.pm

Perspective of Angular in 2020

Speaker:稲富 駿さん

セッション内容は、Angularにおける2019年のアップデート内容と、2020年とその先の未来についてです。 docs.google.com

以下を要チェック!

ちなみに、私はAugularのv2で止まっています。(笑)

Updates in 2019

Angularの価値(values)は、

  • Apps That users to use
  • Apps That developers to use
  • Community where everyone feels welcome

という3点あるそうです。私にとっては、v2へのアップデートで大変つらい記憶がありますが...。

2019年,2020年におけるAngularのバージョンは、

  • 2019-05
    • v7.x
    • v8.x
  • 2020-Q1
    • v9.x
  • 2020-Q3
    • v10.x

こうみると、メジャーアップデートの更新がとても早いですね。 追いつくのが大変そうです。

v7.x

  • Size Budgets by default
    • バンドル時のサイズを制限する機能
    • パフォーマンス向上を期待
  • CDK Drag&Drop
    • 手軽にDrag&Dropを実行可能
  • Virtual Scroll
    • 画面に見えているものだけDOM構築される
    • パフォーマンス向上を期待
  • Bazel
    • gulpのようなビルドシステム
    • Opt-in support

v8.x

  • Differential Loading by Default
    • ブラウザによって、polyfillの量をコントロール
    • レガシーの部分はそのまま。モダンブラウザのpolyfillの量が削減
    • パフォーマンス向上を期待
  • Dynamic Import for Lazy Loading
  • Support Module Web Worker
  • ng deploy
    • production buildしていないdeployが多くなかった。
    • かならず --prodとなる。

主にパフォーマンス向上に取り組んだ1年だったそうです。 AngularはAll-in-Oneなフレームワークなため、どうしてもアプリケーションのコード量が 他フレームワークに比べると多いと思います。そうすると、アプリケーションを読み込む際に、 必要以上にロードされ、パフォーマンスが問題視されていたのでしょうか。

Roadmap 2020

2020年のAngularはどんなものになるのか、紹介されていました。

v9.x

  • Ivy by Default
  • CDK Clipboard API
  • CDK Testing Harness
  • @angular/components
  • Strict Type -checking in templates

2019年はパフォーマンスというユーザーのための取り組みで、 2020年は開発者向けの取り組みが多いという印象でした。

Imagine the Future

今までのAngularは、エンタープライズ向けのアプリや、 小規模のアプリに使われていました。

次は、Billionのユーザ向けアプリをターゲットにするそうです。 そのためには、そのアプリに寄り添った機能提供ができるようにと考えているみたいです。 例えば、SEOアクセシビリティ、国際化といった観点です。

終わりに

Webの進化は早いなと実感した濃い一日でした。 吸収しすぎて、消化が追いつかないですね、ワクワクが止まらないです。

GDEの方々は、どの方も専門領域がとても詳しく、かつ、説明の仕方が上手という印象を持ちました。 私もGDEになってみたいので、得意分野を見つけるところから始めようと思います。

また来年GDGイベントありましたら、参加したいなと思います!

技術書典7で初執筆した経験をすべて公開

技術書典7で初執筆しました。

記事の目的

  • 執筆でどういったことをしたのかの備忘録
  • 執筆を考えている人の助けになりたい

実際に販売する本は↓のものです。 techbookfest.org

きっかけ

大学時代の友人であるcastaneaiくんが技術書典6で初執筆しました。

castaneai.hatenablog.com

castaneaiくんの話を聞いていると、得られるメリット(実績、交流)が大きいことと、 製本までのフローがそこまで難しくないことを知りました。 そこから、私も参加しようと思えるようになりました。 castaneaiくんは、今回の技術書典7も参加するみたいです。興味がある方は是非お立ち寄りください。

techbookfest.org

何をするのか

大きく分けて3つのステップになります。

  1. 文章作成
  2. 製本
  3. 販売準備

それぞれ説明していきます。

1. 文章作成

本は何よりも文章が必要です。 ただ文章を書くだけでは、本になりません。 書籍化するためのツールを使うと効率よく進みます。

1.1. 書籍化ツール

文章を書き、本っぽい見た目にする必要があります。 Re:VIEW Starterというツールを使うと、学習コストゼロで、良い感じの本が出来上がります。

kauplan.org

次のコマンド1つで本のPDFが作られます。

$ docker run --rm -v $PWD:/work kauplan/review2.5 /bin/bash -c "cd /work; rake pdf"

f:id:silverbirder180:20190904204630p:plainf:id:silverbirder180:20190904204703p:plain
ReViewStarter sample page

良い感じの本のPDFが作成されました、最高です。

1.2. 他ツール

他にも次のようなツールがあります。

執筆当初は、これらのツールを調査していました。 しかし、一人で100ページ未満の規模の本を書くなら、特に必要ないかなと思ったので導入しませんでした。 実際、なくても困りませんでした。

1.3. レビュー

文章を書いて終わる訳ではないです。 文章の構成や表現が適切に伝わっているか確認する必要があります。 読んでもらいたい対象読書に近い人を探して、レビューしてもらいます。

1.3.1. 1st レビュー

文章をざっくりと作り終えた時点でレビューしてもらいます。 イメージとしては、各章とそれぞれの第一節ぐらいが書き終えている感じです。

各章の構成がおかしくないかをレビューしてもらいます。構成がおかしいと、読者は困惑してしまいます。 後々になって構成を変更すると、後戻りコストが高く付きます。

※ 実際は時間の都合上していません。

1.3.2. 2nd レビュー

各章の文章をとりあえず書き終えた段階でレビューしてもらいます。 これも、1stレビューと同様の目的です。 2stレビューでは、もう少し細かいレベルで章(節)構成をレビューしてもらいます。

1.3.3. 3rd レビュー

コンテンツの構成に問題なければ、ようやく文章の中身をレビューしてもらいます。 例えば、次のようなものを見てくれました。

  • 口調の統一 (です、ます)
  • 言葉の統一 (本、書籍)
  • 主語の明確化
  • 文章を短くする
  • 内容の誤り修正
  • 誤字脱字
  • 図や表の挿入

また、GoogleDrive上でPDFをレビューするのが便利です。 直接文章にコメントできるので、オススメです。

1.5. 本のタイトル

本を買ってもらうためには、本のタイトルは重要です。 本の内容を推測しやすく、かつ、注目してもらえるタイトルにしようと考えました。 私は、特定の技術の入門書を書いたので、「特定の技術 + 入門」という組み合わせにしようと思いました。 結果、「はじめての WebComponents 入門」というタイトルにしました。

1.6. イラストの作成

本には、文章だけでなくイラストが必要になります。 例えば、次のようなイラストが必要になります。

  • 表表紙
  • 裏表紙
  • 背表紙
  • 文章中に挿入するイラスト

また、少し内容が異なりますが、次のようなイラストも必要です。

表紙用のテンプレートがありますので、それを使います。 www.nikko-pc.com

背表紙の幅はページ数によって変化します。 私は、70ページほど予定していたので4mm幅で背表紙を描きました。 幅計算は、テンプレート内に詳細が記載されていますので、ご参考下さい。 (日光企画のお姉さんに指摘頂きました)

1.6.1. 初イラスト

私はPhotoshopIllustratorを使ったことがありません。 まずは、環境準備からです。

これらを購入しました。 iPadとMagic Pencilを使うと、紙に書いている感覚で、イラストを書けるようになります。 特に良かったのは「手の小指側の面がiPadに接しても無視される」ので、 手の小指側の面をiPadにひっつけながらイラストがかけます。 iPad, Magic Pencilは買って正解でした。 ソフトウェアは、次のとおりです。

お絵かきが苦手だったので、知人に助けてもらい、なんとか作れました。

f:id:silverbirder180:20190829230747p:plain
表表紙

2. 製本

製本には、技術書典オススメの日光企画さんにお願いしました。 製本する際には、用紙の種類であったり綴じ方であったりと決める必要があります。

私は、あまりこだわりがないので一般的なものを選択しました。 それは、次のようになります。

種類 選択
ご予約のセットまたは仕様は? 早割りセット
用紙サイズ A5
表紙込みページ数 72ページ (表表紙+裏表紙+本文(70page))
冊数 300冊
本の閉じ方向
本の閉じ種類 平綴じ
表紙用紙 NPホワイト200kg
表紙の印刷種類 通常4色クリアPP
本文用紙 上質90kg
本文の印刷種類 データ150線印刷
本文はじまりのページ 1ページ目
遊び紙 有り, 上質90kg/イエロー/前

jumpei-ikegami.hatenablog.com を参考にしました。

本文はじまりのページは、nombreをというものを設定する必要があります。 Re:VIEW Starterはnombre対応していて、次のコマンドを叩くだけです。

$ docker run --rm -v $PWD:/work kauplan/review2.5 /bin/bash -c "cd /work; rake pdf:nombre"

用紙についてこだわりたい方は、次のリンクにあるようにサンプルを手に入れると良いでしょう。 natuna.jp

3. 販売準備

3.1. 物品購入

技術書典では、会場で本を販売することになります。 販売するサークルブースを目立たせるために、いくつか物品を準備しました。

名前 店舗 用途 サイズ イラスト
折りたたみカードスタンド ダイソー 値札 110mm×60mm
軟質クリアブックカバー ダイソー 見本誌カバー A5
T型カードスタンド ダイソー 公式後払いQRコード 90mm×128mm
T型カードスタンド ダイソー PixivPayQRコード 90mm×128mm
T型カードスタンド ダイソー 商品紹介 90mm×128mm
T型カードスタンド ダイソー TwitterQRコード 90mm×128mm
あの布 公式サイト テーブル作業 -
テーブルクロス前用紙 印刷業社 宣伝 900mm×600mm
テーブルクロス ダイソー あの布を隠す 900mm×1200mm
テーブルクロス滑り止めシート ダイソー あの布 -
本スタンド ダイソー 見本誌 -
タペストリー用紙 印刷業社 宣伝 728mm×1030mm
タペストリースタンド ダイソー 宣伝 -
名札 ダイソー 著者、売り子 50mm×25mm
硬質カードケース ダイソー お品書き A5
複写式 領収書 ダイソー お客さん -
メモ、ふせん ダイソー 作業 -
養生テープ ダイソー 作業 -
スケッチブック ダイソー 作業 -
ダンボールカッター ダイソー 作業 -

note.mu blog.vtryo.me note.mu

印刷する手段は3つあります。

3.2. 電子書籍の準備

ピクシブ社のサービスであるBoothを利用しました。 booth.pm

特に専門的な知識が必要なことがなく、本のPDFを登録するだけです。 せっかく足を運んで会場に来て頂いた方のために、電子書籍と物理本の違いを出そうと考えました。 (中身のデータは同じです) そこで、物理本を購入して頂いた方には、無料で電子書籍をプレゼントすることにしました。 技術書典ではよくある方法だそうです。

また、サンプルの本をアップロードし、無料でダウンロードできるようにすることで、 事前に本の中身を確認できるようにしました。 silverbirder.booth.pm

ただ、ダウンロード数を見る限り、あまり数は多くありませんでした。 Google Analytics (初登録)とBoothが連携できるので、流入数を見れるのですが、 離脱率が86%という悲しい結果を知りました。ここは改善の余地がありそうです。

f:id:silverbirder180:20190906070005p:plain
Booth on Google Analytics

pixiv ID登録しないとダウンロードできないので、ここが駄目ならサービスを使わない方が良いかもしれません。 見本誌に限っては、GoogleDriveで渡すようにするとかですかね。

3.3. 支払い手段の準備

技術書典では、次のような支払手段を用意しました。

  • 公式かんたん後払い
  • pixiv pay

前者は、技術書典で口座情報を登録すると利用できます。 後者は、アプリをダウンロードして商品を登録するだけです。無料です。

他にもPayPayやKyashといった手段も用意しようか迷ったのですが、やめました。 理由は、支払い方法が若干複雑そうでしたからです。

4. その他

宣伝

この本のことを広く知ってもらうためには、宣伝が必要です。 私が取った宣伝手段は次の通りです。

  1. Twitterで "#技術書典7" タグ
  2. LINEのOpenChatやTL
  3. FaceBook
  4. 本の内容と関係する勉強会ハッシュタグ
  5. 会社
  6. 友人

あとは、勉強会に参加して宣伝する手段もあります。

「興味を持ってくれそうな人」が「多い」場を探す必要があります。 例えば、4番は事前に connpassで関係がありそうな勉強会を調べて、 該当ハッシュタグで宣伝したりしました。 また、積極的に1番を実施していると、他のサークル参加さんがリツイートしてくれるため、とても助かりました。

Twitterで宣伝するために、16:9の画像を用意したりもしました。

被チェック数と販売冊数

被チェック数は、お客さんが気になる本をチェックした数になります。 この数字から、印刷する冊数を決める大きな要因になります。

note.mu

恥ずかしい話になりますが、私は毎朝この数字を見ていました。(笑)

github.com

被チェック数を定期的に取得するAPIをサクッと作って、CloudFunctionで稼働させています。

このようにどの時間やどの曜日にチェックされるのかがわかるようになります。

今回、300冊を印刷することにしました。間違いなく残ってしまうと思うので、 とらのあなさんへ委託しようと考えています。

news.toranoana.jp

残ってしまったいくつかの本は、お家に保存用として持ち帰ろうと考えています。(笑)

公式ツイッター

公式ツイッターアカウントをフォローしておくと、なにかと便利です。

twitter.com

Google カレンダー 登録

技術書典のスケジュールが登録されているGoogleカレンダーを、ご自身のカレンダーにも登録することをオススメします。

いつまでに何をしないといけないのか逆算できるので、知っておいたほうが良いです。

スケジュールと実績

公式予定と私の実績は次のとおりです。

日付 公式予定 筆者実績
07/10 当落通知日 当選
07/12 - 入金済
07/17 入金締切日 入金済
07/20 - 計画立てる&テーマ確定
07/23 - castaneaiくんに
印刷用サークルカット書いてもらう
07/27 - サンプルコード作成完了
07/31 印刷用サークルカット締切日 登録済
08/02 - 原稿作成開始
08/15 - レビュー対応中(2st)
08/21 サークル配置発表日 宣伝済
08/26 一般参加者向け正式サイトオープン 宣伝済
08/29 - レビュー対応中(3st)
08/30 - 原稿作成完了, Booth登録, 製本依頼
08/31 - 物品購入(あの布は事前購入)
09/06 - 現在
09/07 サークル通行証の割当日 -
09/19 見本誌の提出締切 -
09/22 イベント当日 -

※ レビュー依頼中に、表紙等のイラスト作成を並行して進めていました。

サンプルコードを書いている時は、「こんな話も増やそうかな?」と楽しい気分になれました。 原稿を書いている時は、「予定日の◯◯日には終わらせないと…」という苦しい時期がありました。 なんだかんだで、日光企画さんの早割チケットを手に入れれたので満足です。

終わりに

私が今回、初執筆した経験を包み隠さずすべて公開しました。 執筆をやってみてよかったことは次のとおりです。

  • 本を作るのは、意外と簡単
    • ツールやサービスが十分整っている
  • 書いた本が好きになる
    • いろんな人にみてほしい
    • 書いた知識は、とても定着する
  • コミュニティが楽しい

逆につらかったことは次のとおりです。

  • ずーっと本のことを考える
  • 締め切りに追われる
  • 文章力のなさを痛感する

初執筆しようと考えている人にとって、何かの助けになれば幸いです。

あとは、技術書典7 当日を楽しむだけ!!

※ PS. よければフォロー下さい〜! twitter.com

技術書典7 で「はじめてのWeb Components入門」を初出版します!

f:id:silverbirder180:20190829230747p:plain
はじめてのWeb Components入門 表紙

この度、初めて書籍を出版することになりました! 「はじめてのWeb Components入門」本を技術書典7で販売します。

技術書典7って?

コミックマーケットのエンジニア向けみたいなものです。 詳しくは、下記のリンクを参照下さい。 techbookfest.org

あなたは誰?

詳しくは、私のポートフォリオを参照下さい。 silver-birder.github.io

Webアプリケーションが大好きなエンジニアです。 今は、ECサイトのフロントエンドエンジニアをしています。

どんな本?

Web Componentsについて 何も知らない方向けの書籍になります。 書籍の内容の大きな流れは、下記のとおりです。どれもサンプルコードを用意しています。

  1. Web Componentsの基礎
  2. ★ 実際にWeb Componentsを作成
  3. 関連ライブラリの紹介

「実際にWeb Componentsを作成 」について紹介

お題としてTodo Componentsを作ることになります。作る流れは順序立てて紹介しています。

  1. 最小限のコンポーネントを作成
  2. レンダリングの工夫
  3. コンポーネント間のデータ連携

上記のステップを踏むことでTodo Componentsが完成します。もちろん、サンプルコードがあるので動作確認できます。

また、カバレッジ100%テストコードの実装も紹介していますので、TDDも実現できます。Web Componentsのテストコードは、あまりネット上に紹介されていない印象があったので、折角なので混ぜてみました。

最後に、(実際はしていませんが)Web Componentsを公開する手順も紹介しています。

コラムネタ

コラムネタとして下記のようなもの(全てではない)を書いています。

  • cloneNode vs innerHTML
  • html-imports
  • WAI-ARIA
  • slot
  • :host

目次

  • 第一章 フロントエンド開発
  • 第二章 Web Components
    • 概要
    • Web Components 4つの基本機能
    • ライフサイクルメソッド
    • まとめ
  • 第三章 Web Componentsを作ってみよう

    • 作って学ぶ
    • TodoComponentsを作ってみる
    • [実践] TodoItemとTodoInputを作る
    • [実践] renderを工夫してみよう
    • [実践] MyTodoを作る
    • [実践] 各コンポーネントを連携する その1
    • [実践] 各コンポーネントを連携する その2
    • [実践] 各コンポーネントを連携する その3
    • [実践] テストコードを書く
    • [補足] slot
    • Web Componentsの公開
    • まとめ
  • 第四章 Web Componentsの関連ライブラリ

    • Polymer
    • LitElement
    • Material Web Components
    • その他の周辺ライブラリ
    • まとめ

なぜ書いたの?

主に下記のとおりです。

  1. Web Componentsを学習したかったから
  2. ポートフォリオとして残したいから
  3. エンジニアと交流したいから

特に、1番が大きかったです。 Webが大好きな私にとっては、Web Componentsという技術に興味がありました。 けれど、実際に試したことがなかったので、これをきっかけにして使ってみたい!という欲求が大きくありました。

いつ、どこで販売されるの?

2019年09月22日で、「池袋サンシャインシティ 展示ホールC/D」で販売します。 弊サークル「silverbirder」の配置は「う03C」です。

f:id:silverbirder180:20190830002719p:plain
貴サークル「silverbirder」う03C

販売形態は?

本と電子本の2つにするつもりです。 本は日光企画様より製本して頂いたもののみの販売となります。 電子本はBOOTHで販売する予定です。

本を購入された方は、電子本を無料で差し上げます。

終わりに

今回、初物が多すぎました(笑)。
そのせいで、プライベートの時間がほぼなくなりました(笑)。

  • 初技術書典参加
  • 初製本
  • 初Web Components勉強
  • 初クリスタ(イラスト用)

技術書典では、エンジニアそれぞれの書きたいものをアウトプットしています。 そうすると、新鮮な情報をキャッチアップしやすくなるため、非常に情報収集するのが効率的だと思います。 技術書典を参加したことがありませんが、執筆してみて思います。

どの本も絶対面白い!」はずです。

だって、好きなこと書けるんですから(笑)。私も含まれます。

技術書典7当日は、是非とも「う03C」にお越し下さい〜〜!
(他のサークルさんの本買いに行きたい...!!!)

関連リンク

見本誌

silverbirder.booth.pm

技術書典7

techbookfest.org

Twitter宣伝