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

Silicon Valley Super Ware 2020年7月8日 バックエンド実装の方針　～　「express」で実装！ 今日は、どのような方針でバックエンドのサービスを作るかという話です。 ブラウザで動作しているフロントエンドはコードをサーバからブラウザにダウンロードして ブラウザで実行しています。一方で、バックエンドのコードはWebページ（サイト）の ホスティングをしているサーバーで実行されます。 WordPressはバックエンドサービスにPHPを使っています。 今回のSendGridを使ったメッセージ配信のサービスも当然PHPで作ることもできます。 SendGridもサンプルを提供していますので、こちらに興味がある方は検索してみてください。 この連載では、バックエンドとフロントエンドで共通の言語「JavaScript」で対応するために、 Node.jsを利用してバックエンドサービスを実装していきます。 Node.jsの簡単な紹介！ サーバーサイドの実装としてよく利用されるので、サーバーサイドの開発の為の言語のように見えますが、 プログラミング言語そのものは JavaScript です。 もともとのアイディアは、ブラウザーで動作しているプログラムを普通にＰＣで実行できるようにしたものが Node.jsというわけです。ブラウザーで利用していた実行エンジンを取り出して、ブラウザ以外で実行できる ようにしたものです。サーバーサイドのバックエンドサービスで使われる事が多いですが、npmなど、 PCで動作するアプリの開発も可能な言語です。 サーバー側でNode.jsが実行可能ならば利用できます！ 実は、Node.jsを実行できるサーバー環境はWordPressのPHPが主流のホスティングサービスでは 利用できないサービスも多くあります。 今回は、このブログで積極的に利用している「Firebase」のホスティ...

Silicon Valley Super Ware 2020年7月7日 今回利用するサービス「SendGrid」でメッセージを送る！ 今日はもう少し具体的な内容について説明していきます！ 実際に制作するWebサービスは、「SendGrid」というサービスです。 一言で言うと、メルマガのようなメッセージを配信するためのサービスです。 オリジナルのサービスは アメリカの会社 が提供していますが、 日本でも 構造計画研究所 などが日本語でのサービスを提供しています。 このサービスをWebサービスに組み込んで利用しているケースも多くあります。 今回の様に、試験的に組み込む場合は、「無料」のプランを利用する事もできるので このサービスを実装例に取り上げてみました。 今回作成するのは？ 今回作成するのは、SendGridのAPIを利用して、メッセージを配信する部分を実装してみます。 完全なサービスにするには、他の機能の実装が必要になりますが、要領は同じです。 時間の関係上ブログの連載では「メッセージの送信」に限定してお伝えしていきます。 最初に書いたように、このサービスはアメリカの本社が提供するサービスでも 日本のリセラーが提供するサービスでも利用可能です。 ただし、一つ問題があって、利用できるＡＰＩの仕様が日本とアメリカでのサービスで 若干違っています。 このブログでは日本で、構造計画研究所が提供するサービスを前提に進めていきます。 今日はまず、このサービスに登録するところから始めてください！ 「SendGrid」の新規会員登録はこちらから！ E-mailアドレスを入力すると、確認のE-mailが登録したアドレスに送られてきます。 E-mailアドレスを確認したあと、さらに必要事項を入力します。 登録作業はこれだけですが、実際に利用する為のユーザー名は後から登録した メールアドレ...

Silicon Valley Super Ware 2020年7月6日 どこでやるか？境界線をきちんと引く！ 自分のWebサービスでフロントエンドとバックエンドでサービスを提供するのが、 今月のテーマです。 最初に考える事は「今までとは何が違うのか」をきちんと理解することです。 これまでの連載では基本は「フロントエンド」があなたが作る部分でした！ あなたが、作るのはフロントエンドだけで、あとの部分は「既存の物」を使っていました。 これが大きな違いです。 境界線は？ 4月から6月までのテーマの中心は「フロントエンド」を作る事でした。 フロントエンドを作る際に利用していたのが「Firebase」や「REST API」でした 今回は、これ以外に「あなたが作るバックエンド」が追加されます。 これまでは、境界線は「利用する外部のサービスが決めていた」という事です。 Webサービス自体は、一つのサービスですが、 「プログラム」という観点で見るとフロントエンドとバックエンドは 別々のプログラム です 今までは利用していた既存の外部サービスが、提供する機能を決めてそのうえでＡＰＩを決めてくれていました。 つまり境界線はハッキリしていました。 今月のテーマでは、両方あなたが作るので、「あなたが境界線を決める」必要があります。 ここが、カスタムのバックエンドサービスを作る上で今までよりちょっとだけ難しい所です。 どちらでも出来る！ 難しいのには理由があります。やりたい処理の殆どは どちらでやっても出来る からです。 どちらかでしか出来ない場合は簡単で、それを基に線を引けば良いのですが、 どちらでも出来る事は迷いますよね？ 決めるにはある程度方針を決めないといけません。 両方を一人で作る場合と、片方を他の人が作る場合でも違います。 ...

Silicon Valley Super Ware 2020年7月5日 2020年7月のテーマは「バックエンドサービス」 先週は、急ぎの仕事が数件まとめて入ったのでブログの方はお休みを頂きました。 改めて連載を再開させて頂きます。 4月から「Webサービス」で稼ぐをテーマにお届けしている連載ですが、 7月のテーマは「バックエンドサービス」にも触れようと思います。 フロントエンドの方は基本的な事はある程度カバーしたのので バックエンドにも触れて一通りをカバーしておこうというのが趣旨です。 Firebaseを利用すればバックエンドサービスは作らなくても対応できるWebサービスが殆どです！ これが、4月に「Webサービス」を最低限の勉強で作る時の方針でした。 この方針は基本的には変わっていませんが、先月のREST APIの連載で触れたように、 外部のサービスを取り込んで利用する場合はバックエンドのサービスが必要になる 事が多くなります。 最低限のバックエンドサービスを作る！ データベースや認証といったバックエンドのサービスはFirebaseに任せてしまえば あえてカスタムのバックエンドサービスを作る必要はありません。 最低限のバックエンドサービスとは、外部のREST APIなどセキュリティ上どうしても バックエンドで行う必要があるサービスに限定したサービスになります。 例えば、オンライン決済などがその例です。APIキーをサービス利用に使うため サービスキーを見られるのを防ぐためにバックエンドで実装されます 前にも触れましたが、JavaScriptのソースコードはブラウザーで事項されるため、 基本的にブラウザーで見る事が可能です。当然埋め込まれたいたデータも ソースコードの一部として書かれている場合は参照可能です。 つまり、ソースコードを解析すると、悪意で外部の...

Silicon Valley Super Ware 2020年6月25日 Webサービスのテスト 品質の話の最後は、Webサービスのテストについて書いてみました。 実はこのテスト、とても奥が深くてプログラミング言語を勉強するよりも 　大変な場合が多いです。 フリーランスなどは人でも時間も限られているので何をどこまでやるかがポイントです。 理想的な話をしてしまえば、「全部」をテストすればよいわけですが、 全部と言っても範囲を決めるのも難しいのでプログラムの「バグ」が 全部取れないという永遠の課題です。 多くの場合範囲を決められない！ まず最初に問題を言ってしまうと、ある程度の規模のWebサービスになると 「全てをテストする」のは現実的にはできない場合が多いという事です。 Webサービスの場合は、「人」が操作をするわけで、操作の対象となる物も テキストの入力、ファイルの読み込み、ボタンやメニューの選択など かなりの数になります。 しかも、どの順番でどのタイミングで操作するという事まで考えると その組み合わせは事実上全てを検証する事は不可能に近いといえます。 そこで、小さな部品に分けて範囲を限定してテストをするというやり方が 良く使われます。 小さなモジュールに分けてテストすれば、組み合わせを減らせるので テストできる範囲も限定できるのでテストはやりやすくなります。 これを行うだけでも、相当数の問題を見つけて修正する事は可能です。 しかし、組み合わせる事によって起きる問題も多くあるので、 単にモジュールレベルのテストを行うだけでは問題は解決できません。 そこで今日の話は、テストを完璧にやる話ではなくて、最低限やらなければ 行けないテストについて考えるという話です。 まずは、「機能のテスト」です ...

Silicon Valley Super Ware 2020年6月24日 早く作るより大切な事 今週は「品質」の話をお届けしています。 仕事でWebサービスを作る場合「納期」はとても大事な物です。 しかし、何度もお伝えしている通り「品質」はそれよりも重要な物です。 納期に間に合っても、品質が悪ければそれを直す作業が必要になります。 結局、手直しが多いと、依頼された仕事を期限前に納入しても実際の運用は 後ろにずれこんでしまいます。依頼主にとってそれは、納期を守れなかったのと同じです。 品質を作る別の方法 前回は、「Typescript」を引き合いに出して、厳格に型をチェックできる仕様の プログラミング言語を使う事でコードの品質を上げる事ができる事を紹介しました。 手間はかかりますが、長い目で見れば検討する価値のある方向です。 前回の投稿で触れていますが、その本質は、Typescriptを使う事ではなく、 型に対する意識をきちんと持てばJavaScriptでも品質を上げて行く事は不可能ではありません。 一番大切なのは、品質の高いコードを書くという「意識」です。 今日の投稿は 今すぐ始められる品質の高いコードを書く「秘訣」 です もちろん、その秘訣もいろいろありますが、今日紹介するのは 「ハードコーディング」を避けるという事です。 ハードコーディングというのはご存じですか？ これは、コードの中に 直接「値」を書く スタイルのコーディングです。 例えば、数値や文字列「"xxxxxx"」みたいな書き方です。 ハードコーディングはどうして「問題」か？ 大きく２つの理由があります コードが読みにくくなる 修正が大変な場合が多くなる これが、大きな理由です。 特に数字の場合は、プログラムを書いている場合は良い...

Silicon Valley Super Ware 2020年6月23日 Typescriptは必要？ 前回は、「品質」の話に触れましたが、「品質を作る」一つの方法は コードの品質を上げるというのは一つの方法です。 最近は、 「Typescript」 が話題に上る事も多くなりましたが、 Typescriptを使うと、コードの品質は上がります。 理由は簡単で、型のチェックが厳しくなる分、コーディングのエラーが減らせるからです では、「Typescript」は必要かという事を今日は考えてみました。 必要な人は？ 絶対に必要な人は、会社などのプロジェクトで「Typescript」で開発する場合は 有無を言わせずに必要です！ 当たり前ですよね！しかし、現在「勉強中」の人や「これから勉強を始める人」はどうでしょう？ 一言で言うと、JavaScriptに比べるとTypescriptは面倒です。 この辺りが判断のポイントになるかと思います。 まだ、JavaScriptの勉強を始めていない人は、最初からTypescriptを勉強するのも 悪くない選択だと思います。要は最初からTypescriptに慣れてしまえば「面倒」とは 思わないものです。どうせ将来勉強するならば、最初からやってしまうというのは 賢明な選択かもしれません。 逆に、既にある程度JavaScriptを勉強されている方は、Typescriptを始めると 殆どの場合、面倒と感じると思います。そう考えると、まずは、「作る事」を 優先して、必要がなければ、先に延ばしても良いかと思います。 なぜ面倒なのか？ JavaScriptは、比較的「型」の扱いが緩いプログラミング言語です。 一方で、Typescriptは「型」を厳密にチェックする事を特徴とするプログラミング言語です。 つまり、変数などを使...