シリコンバレースーパーウエア

Silicon Valley Super Ware 2020年7月30日 2020年8月のテーマは！　～あなたの趣味をサービスに！～ さて、2020年の7月も終わりに近づいてきました。 Webサービスで稼ごう！という事で4月からWebサービスの実装の仕方を中心に連載をしています。 今日は来月のテーマについてです！ サービスを作るために必要な「要素技術」はとりあえずカバーしたので 8月は少し違った観点でお届けしようと考えています。 テーマは、趣味を生かしたWebサービスです！ 以前にも触れた話題ですが改めて取り上げようと考えています。 Webサービスを作る上で大事なのは「専門的知識」です。 より深い知識があるエリアは他にない価値あるサービスにしやすい傾向があります。 趣味の話題はより深くこだわりのある知識を持っている事も多く ユニークなサービスを企画しやすい分野です。 私の趣味は「登山やハイキング」なので、それを生かしたサービスを以前作成しています 今回は、このサービスのリニューアルを考えているので、このサービスの紹介を中心に お届けします。 登山やハイキングの為のWebサービスとは？ まずは、既に稼働しているサービスをご覧ください！ あなたの登山データを解析します！ 簡単に言うと、登山やハイキングのGPSのデータを解析するというサービスです。 別の趣味に、マラソンもあるのですが、ランナーの多くはGPS付きの時計を使って 走った場所、距離、タイム、心拍数などを記録してトレーニングなどに使うのは 一般的になっています。 同じような考え方を登山やハイキングでもやってみようという事で始めたサービスです サイトをご覧いただけるとお分かりかと思いますが、現在提供している機能は 移動距離・標高差のデータ 心拍数のデータ 心拍数の分布 移動速度（歩行時、休

Silicon Valley Super Ware 2020年7月29日 サービスの障害について考える！ 今日は予定を少し変更して、サービスの障害の話にします。 というのも、今回の外部サービスとして利用しているSendGridのサービスに 昨日障害が発生していました。 障害は起こりえる物です！大切なのはそれにどのように対応するかです。 もちろん、障害が起きない方が良いに越したことはありませんが、 完全に障害を取り除くことは現実的には相当ハードルが高いのも事実です。 大企業の提供するサービスには小さな障害が社会的な問題になる事もあるので、 相当なお金をかけて、その可能性を極限まで「ゼロ」に近くなるような努力をしています。 しかし、完全に「ゼロ」にはなかなかできないのが現状です。 逆に言うと、一般的なサービスは障害は起きるものと考えた方が無難です。 障害ではなくても、システムのメインテナンスの為に一時的ですが サービスが中断されることも多いのが現状です。 外部のサービスをあなた自身のサービスに組み込む場合、 あなたの作る部分だけではなく、外部のサービスの障害も 結果的にあなたのサービスの問題になる場合もあるわけです。 障害の影響を見積もる！ サービス一般の話はいろいろな障害の可能性があるので余り役に立つ話はできません。 今回は今回採用した、「SendGrid」のサービスの障害を中心に考えてみます。 今回の連載では、「メッセージの送信」と「メッセージの追跡（トラッキング）」 について実際に使ってみようという趣旨で連載してきました。 実際は完全なサービスにすることを考えると、他の機能も実装する必要があることは 既に触れた通りです。 考えられる障害は メッセージが配信されない 宛先の登録ができない 送信者の登録ができない 配布リストに宛先が登録できない （上記の）情報の

Silicon Valley Super Ware 2020年7月28日 番外編、メッセージの追跡情報の取得！ 7月の残りは、今月実装した、SendGridを利用したサービスの番外編として、 送ったメッセージの追跡（トラッキング）について触れています。 ビジネスの場合、あなたが配信したメッセージが読まれたかどうかは、気になる物です。 SendGridのサービスでは、送信したメッセ時の配信完了、開封、リンクのクリックなどを 追跡してデータを集める事も可能です。 こうしたデータを解析してマーケティング戦略を作れば、より効果的にあなたのビジネスを展開できます。 今回は具体的な実装について解説します。 WebHookの設定 WebHookは、SendGridが検出した、メッセージのイベント情報を希望のサーバー（ＵＲＬ）に 送ってもらうための機能です。 結構いろいろなイベントを検出できます。 通知の有無 グループの再登録 配信完了 グループ登録の解除 スパムレポート(受信者がスパークとしてマークした) エラーで返送（サーバーの受取距離） 遅延（一時的な配信拒否～サーバの障害など） 登録解除 送信処理中（SendGridがメッセージを受け付けた） 開封 リンクのクリック 配信不能（登録解除、無効な宛先リストの指定などで） など結構細かく配信したメッセージの状態を追跡する事ができます。 イベントを検出すると、予め指定したリンクにデータを送信してくれます。 バックエンドの実装例 バックエンドの実装例です。 this.app.post(API_TRACKING_EVENTS, async (req, res) => {    const events: string = JSON.stringify(req.body);    const items: Array = JSO

Silicon Valley Super Ware 2020年7月27日 SendGridのメッセージトラッキングを使う！ SendGridのメッセージ配信のサービスを使う一つの大きなメリットはメッセージのトラッキング（追跡）です。 あなたが送ったメッセージが開封されたり、メッセージのリンクがクリックされたりするイベントを 追跡して、フォローアップに利用できます。 メッセージの受け手の「反応」を知る事で、よりきめ細かな対応が可能になります。 今回はその簡単な仕組みについて書いてみました！ 実際は、特別にWebサービスを作らなくても、SendGridのWebページでも利用できるサービスですが、 あなたのサービスに取り込む事で、あなたが作るサービスに付加価値を加える事が可能になります。 WebHookによる追跡情報の取得 SendGrid自体でも追跡情報を保持していますが、SendGridがサポートするWebHookを使うと 指定したイベント（メールの配信完了、開封、クリックなど）が起きるとその情報を 指定したサーバーに送る事ができます。 この情報を受け取って、イベントを解析する事でメールの受取人の行動を分析する事ができます。 Webサイトのアクセス情報などと同じように、ビジネスの場においてマーケティングに生かす事ができます。 どうやって情報を受け取るかというと、これも「バックエンドサービス」を利用します。 原理はクライアント（ブラウザー）で動作しているフロントエンドがバックエンドにリクエストを送るのと似ています。 送り主がSendGridのサーバーになるだけです。 つまり、受け取り用のURL(API)を用意するだけで後は、送られてきた情報を取り込めばよいだけです。 今月作成した、バックエンドのサービスと同じように「Express」を使えば簡単に実装できます。 単純にメッセージを送るだけの場合、E-Mailと機能的には変

Silicon Valley Super Ware 2020年7月26日 SendGridによるメッセージ配信サービスの魅力！ 前回までで一通りのサービスの実装については終了です。 今回は改めてSendGridのサービスを利用する理由について解説していきます。 単にメッセージを送るだけではありません！いろいろ便利な事があります！ 単純にメッセージを送るだけならば「E-Mail」や、最近のＳＮＳではサポートされているＤＭ（ダイレクトメール）を 使えば出来るのでわざわざSendGridを使う理由は余りないように見えます。 実際は、単にメッセージを送るのが目的ではなく、より「効果的にメッセージを使う」ための仕組みとして 利用価値があります。 インターネットを利用したビジネスでは上手く使うと強力な武器になります！ メッセージのトラッキング 一つの大きな利点は、メッセージのいろいろなトラッキング（追跡）情報を得る事ができます。 トラッキングというのは、「メッセージを送った後」の処理です。 メッセージを送るだけならばわざわざ外部のサービスを利用する利点は余りありませんが、 メッセージを送った後の事もいろいろやってくれるのが便利です。 その中でも強力なのが、メッセージを開封したかどうかが分かるのは大きなポイントです！ メッセージ事に、そのメッセージが届いたか、開封されたか、さらに、開封した回数は何回かといった、 詳細の追跡情報を得ることができます。 こうしたデータは、送ったメッセージがどれくらい読まれているかという貴重なデータをとれるだけではなく、 送り際の相手がどれくらい興味を持っているかなどを測る指標としても使える事になります。 例えば普段余り開封もしない相手に沢山のメッセージを送りつけるのはある意味逆効果になる場合が あります。そうした事を避けるために、メッセージの内容を変えてみたり、送るメッセージを厳選したり

Silicon Valley Super Ware 2020年7月23日 Webサービスのチューニング Webサービス内で外部のサービスに関係するデータを更新すると、 更新した後の処理が必要になります。 この更新後の処理のやり方を工夫すると同じようなサービスでも かなり違った「使用感」になります。 個人向けのサービスでは、既に取得しているデータをそのまま更新するのも 一つの方法です。 データを使うのが基本的に利用中の人に限定される場合が殆どなので この方法でも、利用者の待ち時間を大きく減らす事が可能になります。 しかし、同じような機能のサービスでも会社などで使う場合は状況が変わってきます。 ある人が更新したデータを他の利用者が必要にするケースが多くなるためです。 そのためには、データの更新を上手くやる必要が出てきます。 複数の人が利用する場合のデータの同期 会社などで複数の利用者が顧客情報などの同じデータを共有して利用するサービスの場合 誰かが更新したデータを何らかの方法で取得できると、サービスの利用価値がより 高い物になります。 この場合、個人で利用するサービスの場合の様に、既に取得しているデータだけを更新しても 他の人には最新データはいきわたりません。 外部のサービスのデータ自体は、外部サービスに更新の処理をしているので更新されています。 しかし、更新前に既にデータを取得している利用者がいた場合何らかの方法で 外部のサービスから更新したデータを再取得しないと最新のデータは利用できません。 このように、取得しているデータを細心にする処理は「同期」と呼ばれます。 一つのシンプルな方法は、「使う前に毎回データを取得する」というやり方です。 このやり方を使えば、利用の際は必ず最新のデータを使うことができます。 今回作っているサービスで言えば、毎回宛先のリス

Silicon Valley Super Ware 2020年7月22日 使うのは誰かで変わるサービスの実装！ 前回から、今回作成したSendGridのサービスを利用してメッセージを送るサービスの 「チューニング」についてお届けしています。 前回は、「使い心地」を良くする工夫について考えてみました。 最初に必要な情報を読み取っておく事で、実際にサービスを使っている時の 待ち時間を最小限にする工夫について解説しました。 ちょっとした工夫ですが、実際に使ってみると結構大きな違いになります。 今回は、他の機能、つまり、宛先の登録、削除、更新や、 同様に、登録送信者や、配布リストを管理する機能を含めた完全なサービスにした場合を 考えてみます。 宛先を登録すると、事情が変わる！ 最初に、宛先を登録した倍を考えてみます。当たり前ですが、宛先を新たに登録すると 当然、最初に読みこんんだ宛先とは変わってきます。 今回のサービスはメッセージを送る際にフォームから、登録宛先を選んで送るというサービスです。 宛先を追加したら、登録されている宛先の情報を更新しないと、新たに登録した宛先には送れません。 つまり、フォームで表示される宛先のリストを更新する必要があります。 この場合、最初に読み込みだけではダメという事になります。 一つの方法は、オリジナルの仕様通りにフォームを立ち上げる度に情報を読み込んで更新するという方法です。 この場合、毎回メッセージを送る度に読み込むため、利用者は毎回待つ必要があります。 この待ち時間を 何とか改善できないか というのが今日考える事です。 読者の皆さんならどのように作りますか？ 一つの方法は、新規に登録した直後に、新たな情報を取得して常に最新の情報を保つというのが シンプルで作りやすい方法です。他には良い方法はないでしょうか？ この時に大切な事

Silicon Valley Super Ware 2020年7月21日 レスポンスを改善する！ 前回までで一通りの機能の実装の方針を解説してきましたが如何ですか？ 実際に制作された方はどれくらいいらっしゃるですしょうか？ 実際に制作された方は使ってみてどのような印象をお持ちですか？ メッセージを入力するフォームで「宛先リスト」と「登録送信者のリスト」を 使っていますが、リストの数が増えると取得に時間がかかると思いませんか？ これから何日かに分けて、この改善策を考えて行きます。 どこで「リスト」を取得するか？ これまでに解説してきた方針では、メッセージのフォームを読み込む際に SendGridからバックエンドを介してデータを取得しています。 実際に運用しているサービスではないので、テスト用にせいぜい10名程度の 登録者で実験をしていて「ちょっと遅いな！」と思う感じです。 実際にサービスを使う場合を考えると、フォームを立ち上げるために 読み込むのは少し無駄ですよね？ そこで、読み込む場所を検討してみる事にします。 続けてメッセージを送る事を考えると、フォームを立ち上げる度に情報を取っていては 毎回読み込みの時間の間待たなければいけなくなります。 そう考えると、読み込む場所は検討の余地があります。 一番簡単でユーザーが遅いと感じるケースを減らすには、「サービスの起動時」に 読み込む方法が待ち時間を最小にする方法です。 いずれにしても、読み込みに必要な時間は余り変わりません。 「回数」を減らす事で、複数のメッセージを送る場合の待ち時間を減らすというのが 一つの方法です。サービスの立ち上げ時に多少時間がかかるのは比較的受け入れられやすい というか、ある程度やむをえないと考えてくれる人が多いと考えられるからです。 読み込んだデータはVUEXで管

Silicon Valley Super Ware 2020年7月20日 メッセージを送る　～要領は同じ！ 今日は、メッセージを送る処理についてです。 やる事は前回説明した、宛先リストの取得や、登録送信者の取得と同じです。 メッセージの情報を送る事が主な違いです。 これは、5月に作成したお問合せフォームに似ている部分です。 フォームの情報を取り込んで、SendGridが要求する形でメッセージを作成して 送るだけです。 まずは、SendGridのAPIの仕様を確認！ 以前作成したお問合せフォームの時は送る情報は以下の通りでした お問合せする人のE-Mail お問合せする人の名前 お問合せ件名 お問合せ本文 以上の4項目でした。これを、Firebaseに登録するというのが5月に作った 「お問合せフォーム」です。 今回はもう少し複雑な形が要求されています。 宛先は、「To」「Cc」「Bcc」で指定しますが、複数の宛先を指定できるように しているため少し複雑です。 「personalizations」というタグは宛先のオブジェクトの配列でしてします。 その下の要素に含まれるのが、」 「To」の宛先の配列 「Cc」の宛先の配列 「Bcc」の宛先の配列 です。宛先は「email」と「name」の2つのフィールドが含まれます。 結構面倒な構造ですよね？このうち、最低一つの「Toの宛先」が必要です。 そのほかに必要な情報は 「from（送信者）」の情報 「subject（メールの件名）」 「content（メールの本文）」 これらがSendGridを介してメッセージを送る最低限の情報です。 他にもたくさんの要素が指定できます。 メールに添付ファイルなども付ける事ができます。 詳細はSendGridのメールのAPIを参照してください。 今回は、このメ

Silicon Valley Super Ware 2020年7月19日 Webサービスのバックエンドの実装 今週はバックエンドの実装を中心にお届けします。 先週簡単なバックエンドの実装の例を「Hello World!」で紹介しました。 「express」のフレームワークを使えば意外に簡単にできました！ 今回のバックエンドの基本的な機能は、SendGridのREST APIへのアクセスを 「フロントエンドに代わって行う」のが主な機能です。 やる事は大きく2つです フロントエンドからリクエストが何かを識別 リクエストの内容に応じてSendGridからのデータの取得と、フロントエンドへの応答 これが、今回実装するバックエンドのサービスになります 外部パッケージ（モジュール）で簡単実装！ 実際の実装は外部のモジュールを導入する事で、比較的シンプルなコードで実装できます。 今回利用する主なパーケージは Express Request です。 この２つが上に挙げたポイントとなる処理をやってくれます。 Expressは、フロントエンドが指定したURLを読み取ってそれに応じた処理に 振り分ける役割を担当します。 これが、先週例題で紹介した「Hello World」の例です。 今回は、3つの処理を、振り分けます 宛先リストの取得(contacts) 送信登録者のリストの取得(senders) メッセージの送信(send) これを、それぞれ異なるURLで振り分けます Requestは、SendGridのRest APIを送る役割です。 Expressによる振り分け まずは、Expressによる振り分けです。 this.app. post ( CONSTANTS.API_CONTACTS, async (

Silicon Valley Super Ware 2020年7月16日 フロントエンドの実装 今日はフロントエンドの実装編です！ 具体的な実装についての詳細を考えて行きます 必要なカスタムのＡＰＩは3つです。 「宛先リストの取得」、「登録送信者リストの取得」、「メッセージの取得」です API HTTP method 機能 contacts POST 宛先登録者の取得 senders POST 登録者送信者リストの取得 send POST メッセージの送信 これらのAPIを呼び出す為のクラス（ファイル）を作成してカスタムＡＰＩの処理をまとめます。 今回は、「SendGrid.ts(Typescript)」を作成します。 カスタムＡＰＩを使う専用のファイルを作る 管理しやすいコードのコツは、「似ている機能」をまとめる事です。 今回はカスタムのＡＰＩを使う処理を一つのクラスにまとめてしまいます。 クラスにしなくても、関数を集めたファイルでもかまいません、書きやすい方法でまとめます。 今回は「SendGrid.ts」というファイルに「SendGrid」というクラスを作ってまとめました。 処理に使うメソッドは、クラスのオブジェクトを作らなくても呼び出せるように「static」の メソッドにしました。実質上は関数の集合体にしても同じです。 非同期の処理なので、プロミスを使って書きます！

Silicon Valley Super Ware 2020年7月15日 フロントエンドの設計コンセプト 今日から本格的にSendGridを利用してメッセージを送るWebサービスの設計に入ります。 まずは、フロントエンドサイドの設計コンセプトです。 何回か触れていますが、完全なサービスにするためにはメッセージを送る以外の機能の実装が必要です。 このブログの連載では、「メッセージを送る」部分に特化してお伝えしています。 ぜひ、ご自分で完全なサービスを作ってみてください。 宛先（メッセージ送付先）の登録、更新、削除と登録者のリストの取得 送信者の登録、更新、削除と登録者のリストの取得 送付先リストの新規作成、削除とリストへの登録・削除 メッセージのトラッキング情報の取得・管理 を実装すると本格的なメッセージサービスとして、「メルマガ」や「マーケティングメッセージ」のサービスとして 実際のビジネス向けに利用できるサービスになります。 メッセージ送付サービス 今月、作成するのがこのWebサービスの「コア」機能になる、メッセージを送る部分のサービスです。 フロントエンドでやる事は一言で言うと メッセージを作成してバックエンドに渡す機能です！ 機能的には何度も書いていますが、5月に作成したお問合せフォームと同じような機能です。 宛先の指定 送信者の選択 メッセージのタイトルと本文の入力 入力された情報を加工してバックエンドに渡す（送信処理） 上記の内容がフロントエンドでサポートする処理です。 フロントエンドの構成 メインの作業はUIの作成、つまりメッセージの入力フォームです。 今回考える事は、「使いやすいサービス」です。利用者がより便利に利用できるUIです。 SendGridのサービスでは登録されている宛先に、登録された送信者がメッセージを送るというのが基本です。 この場合、宛先をタイプ入

Silicon Valley Super Ware 2020年7月14日 SendGridを利用するAPI 今日から、SendGridのAPIを利用してメッセージを送るサービスの製作を始めます！ SendGridの無料アカウントは取得されましたか？ まだの方はまず、無料アカウントを作成してください。 日本の代理店経由と、アメリカのサイト経由では若干APIの仕様が違います！ 主な違いは「マーケティング機能」のAPIが違います。 アメリカのサイトから登録したユーザーは「新しいAPI（New Marketing Campaign）」を使いますが、 日本の構造計画研究所から登録したユーザーは「古いAPI（Legacy Marketing Campaign）」を使います。 似ていますが、インターフェースが違うため互換性はありません。 必要なAPIは？ このブログの連載では時間の関係で「メッセージを送る機能」をサポートします。 完全なサービスにするためには、「送付先の登録」、「送信者の登録」などもサポートする必要があります。 要領は同じような感じですので、是非トライしてみてください。 送付先の登録や、送信者の登録は「SendGridのサイトの管理ページ」からできます。 なので、登録者の設定や、送信者の設定はSendGridの管理サイトに任せてしまうような 使いかたにすれば、最小限の機能でも十分に実用になります。 利用するSendGridのAPIは 「V3 Mail Send API」 を利用します。 Node.jsのサンプルもGitHubで公開されています。 GigHubのサンプルはこちら！ 今回のAPIは比較的シンプルなので自分で最初から書いてもそれほど難しくありません。 SendGridの日本語のドキュメントに詳しい仕様が書かれています。 SendGridのV3 Mail

Silicon Valley Super Ware 2020年7月13日 バックエンドサービスの仕組み！荷物の配送に似ています！ 今回作るバックエンドサービスには「express」というモジュールを使っています。 先週はお試しに簡単な機能を実装しましたが、今日はその動きについて簡単に解説します。 簡単に言うと「リクエスト」を受け付けて、その処理をするという事です。 そのリクエストをやる事毎に別々のURLで受け付けるという感じです。 商店街に行くとお店が沢山あって、靴を買うときは靴屋さんに、 食事をする時はレストランにという感じで行く場所を分けますよね？ URLは「お店」に近い概念です。 Webサービスの基本！ Webサービスの場合、インターネット上にサービスを提供するホスト（サーバー）が必要です。 このホストが、リクエストを受け付けてその処理をするわけです。 Webサーバー自身があるいみバックエンドサービスです。 通常のWebページでは、リクエストは「html」ファイルの中身をください！です ホストは要求されたページのHTMLファイルの中身をブラウザーに送るというわけです。 今回のバックエンドサービスは、HTMLファイルの中身の代わりに要求された情報を 送り返したり、送られてきた情報を処理するという事になります。 Expressがやっている事は、利用者が指定したURLとHTTPのメソッドを読み取って 処理をする事です。この処理を「ルーティング」と言っています。 先週の例では「サーバーのURLのあとに"hello"」と指定されたら、 予め設定されたHTMLを返すというのがサービス内容です。 先週の例ではとてもシンプルな処理でしたが、今月のテーマは もう少し複雑で、リクエストに添付されたメッセージを SendGridのサ

Silicon Valley Super Ware 2020年7月9日 本番の前に練習！バックエンドのウォーミングアップ！ 実際に、「SendGrid」のAPIを使う前に、今日は「express」を使ってみます。 バックエンドの枠組みが分かった方がスムーズに行くと思うので今日は実際に 超簡単なバックエンドサービスを作ってみます！ 「Hollo World!」を作ってみましょう！ 今日やってみる事です！ Vue.jsのプロジェクトの作成 Firebaseのプロジェクトの設定 Firebaseの初期化 Expressで「Hello world!」 今回はまだ、フロントエンドは必要ありませんが、このまま拡張していく予定ですので Vue.jsのプロジェクトも作成しています。 今日やるのは、Firebaseの設定とExpressを使った簡単なWebサービスまでです。 早速始めましょう！ まずはVue.jsのプロジェクトを作成してください。5月、6月とVue.jsを使って サービスを作っているのでもう慣れたでしょうか？「vue ui」でも「vue cli」でも いいのでまずはプロジェクトを作ってください 次にやる事が 「firebase-tools」のインストール 「firebase init」でFirebaseの初期化 今回は、「hosting」「functions」「firestore」「storage」を有効にしておきましょう！ > npm install -g firebase-tools > firebase login > firebase init 「firebase init」で、設定する機能を聞かれますが Firestore Functions Hosting Storage Emulators を選択します。 後は殆ど標準