|ウェイブのエンジニアブログ株式会社ウェイブのエンジニアによるテックブログです。Ruby、Vue.jsについてなど技術的な話をしていきたいと思います。株式会社ウェイブのエンジニアブログです。エンジニアの目線から会社の話や技術的な話をしていきます。Pagesを用いてStorybook確認用のWebサイト(社内用)を公開したのでご紹介いたします。Pagesの導入がメインとなります。そのため、GitLabやStorybookの導入に関しては、触れておりません。その他、公開するリポジトリの状態として、StorybookはWebpack管理されており、Docker化されております。各種設定に関してもあくまで一例参考にしていただけたらと思います。Pagesは、GitLabのリポジトリから静的なWebサイトを直接公開できる機能です。独自ドメインを設定してWebサイトを公開することも可能です。GitLab環境があれば、簡単に導入することができます。常に最新のStorybookを確認する方法として静的Webサイトを公開する必要がありました。Pagesの導入には以下のメリットがありました。PagesでStorybookを公開までの流れについてご説明致します。supportで対応しました。この方法では、事前準備として以下の対応が必要でした。Encryptで取得いたしました。今回は、1プロジェクトでお試し導入のため、ドメインを指定してSSL証明書を取得し使用いたしました。PagesはデフォルトでOFFになっております。PagesをONにする必要があります。gitlab.rbに以下のコードを追加致します。"/privkey.pem"設定を追加したら、以下のコマンドで設定を反映させます。今回導入するStorybookは社内向けのため、外部からのアクセス制限を追加する必要がありました。アクセス制限を追加する方法として、以下の2通りの方法がありました。今回は、2.の方法でアクセス制限を追加致しました。controlでアクセス制限しないのか?と疑問に思う方もいるかと思います。発生した不具合に関しては後述致します。次に、それぞれの導入方法についてご説明致します。11.5で追加された新機能です。アクセス制限の種類は公式ドキュメントに明記されております。この機能を用いて、リポジトリごとにアクセス制限を追加することが可能です。controlを追加するための設定はgitlab.rbに以下のコードを追加し再起動するだけです。Permissions内にPagesという項目が追加されます。ここで、アクセス制限の種類を選択することが可能です。次に、なぜ導入を断念したかご説明致します。control導入後、数日間は問題なく動作しておりました。すると、Pagesにアクセスした際、503エラーが発生しアクセス拒否になってしまいました。原因に関して調査しましたが、解決の糸口を見つけることはできませんでした。似たような挙動になる旨のIssuesはありましたが、原因を特定したIssuesは存在せず、かなりハマってしまったため、今回は導入を断念する結果となりました。要件は外部からのアクセス制限を追加することだったため、スピード感を重視し、別の方法での実装に切り替えました。Nginxを用いたアクセス制限方法アクセス制限とありますが、実際にはIPアドレス制限です。Pagesで自動生成されるNginxの設定ファイルに、別途IPアドレス制限用のファイルを読み込ませます。こちらも対応方法はシンプルです。外部読み込み用のconfファイルを作成致します。all;次に、gitlab.rbに以下のコードを追加し、先ほど作成したconfファイルを読み込むように設定致します。/etc/gitlab/hogehoge.conf;"修正は以上で、最後に再起動すればアクセス制限完了です。単純にhtmlファイルを公開するのみであれば、公式ドキュメントの設定で公開することができます。今回は、build-storybook.shというStorybook公開用のスクリプトを作成して実行しております。追加、修正したファイルは以下の通りです。(追加分以外は省略しております。)重要なポイントにコメントしております。この名称はpages固定にする必要があります。public/storybook注意事項として、公式ドキュメントにも記述がある通り、公開できるディレクトリはpublic配下となります。そのため、別のディレクトリを公開対象に設定するとアクセスできないためご注意ください。アクセスすることができます!おわりに最後まで読んでいただきありがとうございました!本記事の内容が少しでも参考になればと思います。Pagesの導入は、弊社で初めてとなりました。ウェイブでは、このような新しい技術に挑戦しやすい環境が整っております。PagesでStorybookを公開するまでの道!!!Tweet2019-06-06JavaScriptのコード実行についてこんにちは。初めまして、システム開発部メンバーのukです。最近、ウェイブが運営する電子コミック配信サイトComicFestaでは、jQueryからVue.jsに移行し、開発と運用がスムーズに行えるようにフロントエンドを改善しています。今回JavaScriptの初心者として、非同期処理についてまとめたいと思います。はじめに一般的にプログラムは、逐次処理でソースコードを上から順に実行します。以下のソースコードは上から順に実行されます。Chromeで動作を確認すると、結果が自分の想定と違っていました。ソースコードを実行する時に、メインスレッドが順番にソースコードを実行して、関数が見つかった時に、まず関数を実行スタックにプッシュして関数の実行が完了すると関数を実行スタックからポップして、ソースコードの最後まで繰り返します。Ajax、APIなどを実行する時は、メインスレッドをブロックさせないために、まずPromiseオブジェクトを返し、JavaScriptランタイムが事前に定義したコールバック関数をタスクキューにプッシュします。メインスレッドが実行スタックにプッシュしたタスクを全て実行した後にFIFO方式でタスクキューから次のタスクを実行します。受け取ったタスクを保存するキューです。JavaScriptエンジンはイベントループを使って実行スタックを常に監視していますので、実行スタックが空になると、タスクキューからタスクを取り出して実行スタックにプッシュして実行させます。macrotasksの二種類があります。違うところを整理します。コールバックより優先的に実行されましたね。これは以下のような理由があります。キューにプッシュされます。実行スタックが空になると、次に実行するタスクをタスクキューから取り出します。その時、macrotaskキューから、一つだけタスクを取り出して実行します。取り出したmacrotaskの実行が完了すると、次に、microtaskキューを確認し、キューにある全てのmicrotask実行してから、次のmacrotaskの実行に移ります。1メインスレッドは下記のソースコードを一つのmacrotaskとして順次実行します。1-3まず、下記の結果が出力されます。コールバック関数が入っているので、全てのmicrotaskを実行します。2までの出力結果はこうなります。完了すると、microtaskのキューが空になり、次のmacrotaskを実行する。console.log('promise3')})console.log('end');最後まで実行された結果はこうなります。今回見たように、コールバックの順番が関数実行する順番と違う場合があります。今回は触れませんでしたが、Node.jsにはまた別分類のnextTickキューがあります。JavaScriptの非同期処理を書くときは、ちゃんとこのことに気をつけた方がいいと思いました。藤久ビル東5号館3Fスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。