サンプルコード：GitHub React Nativeを使って楽にスマホアプリを作ろうぜってことでまとめてみようと思います。 ReactJSで作る今時のSPA入門（基本編）の続編です。 ReactJSの基本がわかっている前提で説明します。 ちなみに楽と書いたのはネイティブコードでアプリを作るよりは楽という意味です。 （後は開発サイクルが早く回せるという意味で） React Nativeのアーキテクチャ 参考：React Native Architecture : Explained! React Nativeの構成はざっくり次の図のようになっています。 JavaScriptCoreと言われるWebkitにも使われているJavaScriptエンジンでJavaScript Runtime Environmentが作成されています。React NativeのJavaScriptコードはJavaS

まずはじめに Reactはユーザインターフェース構築のためのJavaScriptライブラリです。 React は、インタラクティブなユーザインターフェイスの作成にともなう苦痛を取り除きます。アプリケーションの各状態に対応するシンプルな View を設計するだけで、React はデータの変更を検知し、関連するコンポーネントだけを効率的に更新、描画します。 - React公式より Reactのプロジェクトである程度規模が大きくなっていくと問題になっていくのは きちんと設計しないとビジネスロジック、コンポーネントのステート、表示 これらが入り混じって数百行の巨大なコンポーネント（モノリシックなコンポーネント）ができてしまう場合があることです。 確かにReactはユーザインタラクティブなViewの作成には強力な力を発揮しますが、 綺麗なコンポーネント設計に関しては利用者に委ねられています。 (Re

Promiseは何時呼ばれるのか？ 使う分には今まであまり意識してこなかったのですが、async/awaitを呼ぶことで処理がブロッキングされるのではないかというのを懸念していたのと、そもそもどのタイミングでPromiseのcallbackがされるのか気になったので今更ですが調べてみました。 Promiseが呼ばれる仕組みについては先にEventLoopとmicrotaskについて知る必要があります。 先に結論から書くと以下の感じです。 PromiseはEventLoop内のmicrotaskキューでFIFO実行される。 Timer系の処理(setImmediateやsetTimeout）はmicrotaskが全て実行された後に実行される。（つまり、setTimeout(fn, 0)はmicrotaskを全て実行した後にfnを実行するという意味） async/awaitはPromiseの箇

GTMと聞いて別のサービスを思い浮かべるのは私だけでないはず。 そこで正しいサービスに戻してみようと思います。 ここの記事を参考にさせていただきました。 LGTMを戻す window.onload = function() { var img = 'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAARgAAAC0CAMAAAB4+cOfAAAApVBMVEX///9FhPA5abtYkPE9gPA1Z7pGcr9liMgwZLkoYLiOr/W+y+WIoNE1fO/R4PtBgvAweu+nwPfy9v73+v7s8v1glPLg6fzl7f1+pvQ+bb5Jhe3M2/q7z/l1ofPF1vra5fyYt/a90fmUtfavx/ijv/dqmvJ9pfTS2+5dkvJRi/GOsfWUq9mqvN+Fq/Szyfgmdu98mM9Zf

最近Reactのプロジェクトは全部Gatsbyベースで作ればいいじゃないかな（大体適用できる）と思ったので なぜそう思ったのかまとめてみます。（Gatsbyサイト実装の雛形付き） SPAのメリット・デメリット Reactに代表されるSPAのメリットとしては history APIによる疑似ルーティングでバックエンド無しでページ間遷移ができる（API無しの場合はファイルをホストするだけでWebページが作れる） フロントエンドとバックエンド（API）の棲み分けがはっきりしてる（SSRしない場合） 仮想DOMツリーによる差分レンダリングが高速 逆に動的に仮想DOMツリーを生成するSPAのデメリットとして以下のことが挙げられます。 bundle.jsのファイルサイズが肥大化して読み込みが遅い 仮想DOMツリーの構築に初回のJS実行時間がかかる TwitterやFacebookシェアのOGPを実装し

レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし

ブラウザで動くWebページのプログラミング実装をフロントエンドと呼びます。 最近はJSON色つけ係と呼ばれてたりしますが、 Web開発未経験・初心者向けに最低限知っておいたほうが良い基礎知識とテクニックに関して体系的にまとめておきます。 （CodePenによる動作例付き） 環境構築に関しては（兎に角）早くプロトタイプを作る技術（初心者向け）を参考にしてください。 HTML、CSS、JavaScriptはブラウザ自体の実装に依存します。 この記事では比較的汎用的に使える書き方やHTML、CSS、JSを記載したつもりですが 最新のJavaScript APIやCSS3の機能によってはブラウザによってサポートされていない機能もあります。（特にIE） 各機能に関してはCan I useで現在のブラウザの対応状況を確認することができます。 HTML HTML(Hyper Text Markup La

とにかく早くプロダクトのプロトタイプを作るための技術についてまとめます。 この技術は運用しやすく作る技術とはまた別の技術です。 （綺麗に作るのは後でやる） かなり偏った考え方もあると思いますがご容赦ください。 プロトタイプを作る上でやらないことを決めます。 実はやることよりもやらないことを決めることの方が難しいです。 UXに基づいて後回しにするという意思決定が必要です。 プロトタイプでやるべきこと コンセプトの決定/チャネルの調査： なぜ作るのか、誰をターゲットとして作るのか、競合プロダクトの調査 コア機能の実装： ユーザの苦痛を解消させるプロダクトのコア機能の実装をします。 ここで想定しているコア機能とは一画面に収まるアプリケーションのメイン機能の事を指します。 デザインはモックレベルではなく、ユーザが使う想定のデザインテーマ、レイアウト、アフォーダンス、メンタルモデル、UI、アニメーシ

とにかく早くプロダクトのプロトタイプを作るための技術についてまとめます。 この技術は運用しやすく作る技術とはまた別の技術です。 （綺麗に作るのは後でやる） かなり偏った考え方もあると思いますがご容赦ください。 プロトタイプを作る上でやらないことを決めます。 実はやることよりもやらないことを決めることの方が難しいです。 UXに基づいて後回しにするという意思決定が必要です。 プロトタイプでやるべきこと コンセプトの決定/チャネルの調査： なぜ作るのか、誰をターゲットとして作るのか、競合プロダクトの調査 コア機能の実装： ユーザの苦痛を解消させるプロダクトのコア機能の実装をします。 ここで想定しているコア機能とは一画面に収まるアプリケーションのメイン機能の事を指します。 デザインはモックレベルではなく、ユーザが使う想定のデザインテーマ、レイアウト、アフォーダンス、メンタルモデル、UI、アニメーシ

JavaScriptの文法を理解している人を対象にTypeScriptの導入と型の基本文法の習得をできることを目的とします。 この記事では簡易のため、ts-nodeを使ってTypeScript環境の構築と動作確認を行います。 TypeScriptについて TypeScriptはマイクロソフトによって開発されているオープンソースのプログラミング言語です。 TypeScriptはJavaScriptに対して、省略も可能な静的型付けとクラスベースオブジェクト指向を加えた厳密なスーパーセットとなっています。（JavaScriptの文法を完全包括していて、JavaScriptに後付で型定義ができます。） C#のリードアーキテクトのアンダース・ヘルスバーグがTypeScriptの開発に関わっています。 TypeScriptはクライアントサイド、あるいはサーバサイド (Node.js) で実行されるJa

JavaScriptの文法を理解している人を対象にTypeScriptの導入と型の基本文法の習得をできることを目的とします。 この記事では簡易のため、ts-nodeを使ってTypeScript環境の構築と動作確認を行います。 TypeScriptについて TypeScriptはマイクロソフトによって開発されているオープンソースのプログラミング言語です。 TypeScriptはJavaScriptに対して、省略も可能な静的型付けとクラスベースオブジェクト指向を加えた厳密なスーパーセットとなっています。（JavaScriptの文法を完全包括していて、JavaScriptに後付で型定義ができます。） C#のリードアーキテクトのアンダース・ヘルスバーグがTypeScriptの開発に関わっています。 TypeScriptはクライアントサイド、あるいはサーバサイド (Node.js) で実行されるJa

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近自分の中でWeb開発はReactJS、モバイルアプリ開発はFlutterが良いという結論がでました。 Flutterでの実装はDart言語で行います。 基本的なモダン文法をサポートしているため、他言語から入ってくる人には入りやすい言語だとは思います。 とはいえ、日本語情報でステップバイステップでDart文法がまとまっているところは少ないので まとめてみようと思ったのがこの記事です。 Flutterがよい理由 【翻訳記事】なぜFlutterにおいてDartを使用するのか？ ・hot reloadが高速(AOT、JITの2段階のコンパイ

はじめに 今回のサンプルは以下に用意しました。 Apollo Server & Apollo Clientサンプル 以前こんな記事を書きました。 React(+Redux)+gRPCで実現するクリーンアーキテクチャ＋マイクロサービス構成 BFFのフロントエンドAPI部分に関して、次の記事を見てクライアント通信の部分をGraphQLで実装できるとより柔軟で堅牢な気がしたので試してみました。 世のフロントエンドエンジニアにApollo Clientを布教したい REST API、 GraphQLの違いに関しては下記を参考にしてください アプリ開発の流れを変える「GraphQL」はRESTとどう違うのか比較してみた GraphQLを導入するメリットはざっくり以下の通りです。 APIのインタフェース定義(送信パラメータのデータ型定義)ができる（それにともない、データの型定義によるAPIパラメータの

Javascriptで音を鳴らすにはどうしたらいいかなぁと 色々調べてみました いくつか方法がありますが ①audioタグをJavaScriptで制御する ②WebAudio APIで再生する 今回はローカルの音を鳴らすにはどうしたらいいか考えました。 ①はローカルのリソースをaudioタグのsrcに指定すれば鳴らせます ②はXHRもしくはinputタグのfile属性からのファイル取得（File API）限定なため、 ブラウザの仕様上結構難しい ①でいいじゃないかという声が上がってくると思いますが iPhoneやAndroidではaudioタグの複数同時再生ができなかったりします 逆にWebAudio APIなら複数音同時再生できます。 （上記とは別にスマホブラウザでは①、②ともに ユーザアクションがないと再生できないという制限があります） ちなみに②のinputタグから取得する方法だと、

はじめに イケてるは誇張かもしれませんが社内にデザイナーがいなく、 エンジニアにランディングページを作ってと振られたときのケースを想定して ノンデザイナーでも体系的にCSSコーディングすることでそれっぽいランディングページを作成できることを目的としてます。 デザインは一朝一夕でできるものではなく、ブランディングに関わる部分の画像に関しては、商材の撮影やPhotoShopやIllustratorで専用のアイコンやロゴ画像を別途制作する必要があります。 本格的に作成する場合はやはり本職のデザイナーさんに依頼した方が良いでしょう。 （それっぽいといったのは今回はそれらのブランディングに関わる画像の作成を省いて、素材画像やCSSでごまかしているからです。） 今回はCSS Designerという仮想CSSエディターの商材を想定してランディングページを作成しました。 作ったページ全体のサンプルはこちら

Serverless+SPA構成 最近低費用でサービス運用できないかと、色々試してたのをまとめてみます。 Serverless構成だとEC2と比べて費用が安くなり、SPAであればルーティングがサーバ側制御ではないためS3のバケットに静的html、css、js、画像の配置にてサービス構築が可能となります。 SPAにはReactJSを採用してますが、Vue.jsやUnityとかのサービスでもいけると思います。 良い点ばかりではなく、デメリットも結構あるのでそれを考慮した上で導入しましょう。 個人でお金をかけたくなくてサービス運用したい場合などには良いかもしれません。 （Lambdaの無料枠＋アクセス量のみで計算される。ドメイン費込みでも月約$3程度） メリット ・　とにかく費用が安い ・　AWSの設定周りの変更だけでスケールする デメリット ・　利用しているサービスが多いため、デプロイ時などの

ReactJSで作る今時のSPA入門（基本編）で作成したプロジェクトをリリースビルドしてデプロイする構成についての説明です。 リリースビルド リリースビルド用に次のようなディレクトリ構成に変更します。 client部分だけBabelでリリース用ビルドをするため、 package.jsonをclient、server、プロジェクト全体で持つ構成にします。 distフォルダにBabelのビルド結果を出力して ローカルからAWS EC2サーバにrsyncでデプロイする想定です。 configフォルダにはサーバ、クライアント共通の設定ファイルを格納してあります。（サーバの起動ポート番号など） ├── README.md ├── client │   ├── dist │   ├── package.json │   ├── src │   │   ├── App.js │   │   ├── co

{ // 変数 "const": { "prefix": "c", "body": [ "const $1" ], "description": "定数" }, "let": { "prefix": "l", "body": [ "let $1" ], "description": "変数" }, "var": { "prefix": "v", "body": [ "var $1" ], "description": "変数" }, // デバッグ "console.log": { "prefix": "cl", "body": [ "console.log(${1:val})" ], "description": "console.log" }, "console.dir": { "prefix": "cd", "body": [ "console.dir(${1:obj})" ], "

最近大学時代の同期と飲んだらMSに転職したので 現在から過去の案件で産廃IEくたばれと心底思った発生した事象と対策を書いていきます 他にもこんなことあったぜ！って意見ありましたらお待ちしております。 キャッシュ Windows10のIE11で遭遇した事象 ログイン→ログアウト→別アカウントログイン したときの挙動が最初のログインアカウントの状態のレスポンスが返ってくる Authorization: Bearerヘッダーが再ログインしても前のBearerトークンが残り続ける APIレスポンスが前回のものが返ってくる 対策 JSのすごい人に助けてもらいました・・・ ClearAuthenticationCacheを無効にする リクエストキャッシュしないようにリクエストパラメータ末尾に日付をつける→jQueryでもこの方法で回避しているらしい これIEのバグですよね？ // ClearAuthe

ゴール こんな感じでSonarQubeさんからコードレビューされます。 各種言語のソースコードでダメな内容をLint的な感じで教えてくれます。 リンククリックで該当箇所も表示されます。 コードの品質担保 プロジェクトが大きくなると技術的負債がソースコードに蓄積されていきます。 技術的負債がたまってくると新規機能追加や既存機能改修時に色々悪影響が出てきてプロジェクトが遅延します。 技術的負債がたまるにつれ、リファクタリングコストが高くなり、 最悪作り直しの方が早いという結果にもなりかねません。 何より常時問題がある箇所を直していれば、誰かが書いた負債を引き継がなくて済むというメリットがあるので 精神的な負荷を下げることができます。 手動でのコードレビューはしんどい かといって目見でコードレビューをするには人的コストもかかるし限界もあります。 ツールを使い自動でやる場合は、ソフトウェアメトリッ