Reach Over The Sky, Tear The Sky

オリジン間リソース共有 (CORS)という技術があります。 ドメインAのWebページを表示する際に、一部のコンテンツをドメインBから取得してそれを表示したいといった場合に利用する必要があります。 それは最近のWebでは割とありふれたことだと思います。 なので意識せずともかなりの頻度で利用されているのではないでしょうか。  先日業務でCORSを意識した問題に直面してしまったこともあって、一度きちんとした技術文書を読んだ方が良いと思い、Mozillaが提供している MDN web docsの丁寧なドキュメント を読んでみました。 CORSまとめ WebブラウザがドメインAのページを取得したいが、ドメインAのそのページはドメインBのコンテンツを含むといった場合に、ドメインAのサーバはドメインBのコンテンツを取得して自ページのコンテンツの一部としてWebブラウザに返さなければいけない その時に利用される技術がCORS CDNで画像やスタイルシートやフォントやスクリプトを配信している昨今ではかなりの頻度で利用されていると思われる 基本的にはHTTPヘッダに所定の内容をクライアントとサーバが用意することで成り立つ CORSができるかどうかを確認するために「プリフライトリクエスト」という事前HTTPアクセスが必要である 「プリフライトリクエスト」はOPTIONメソッドで行われる…GETやPOSTではない 「プリフライトリクエスト」が発生しない「単純リクエスト」というCORSリクエストもあるが該当条件が厳しい 特に世の中に多そうなcontent-typeが「text/html」のページは単純リクエスト対象外なので基本的にはほとんどのCORSでプリフライトリクエストが発生すると考えた方が良さそう プリフライトリクエスト時にクライアントから発送される「Access-Control-Request-Method」にはプリフライト後の本来のリクエストでどのメソッドが使われるかが書かれている 同様に「Access-Control-Request-Headers」には次に行われる本来のリクエストでどのようなヘッダが送信されるかについて書かれいる プリフライトリクエストを処理するためにサーバ側（CORSで一部コンテンツを提供するドメインBのサーバ）...

自分が送ったコミットを特定のブランチ（今回はstaging）にマージしてくれと言われて対応した時のメモ。 まずこうやってリポジトリを clone して hub am −3 コマンドを使ってマージしようとした。 git clone git@github.com:(team name)/(repository name).git cd (repository name) git checkout staging hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) 認証失敗 そしたら hub am -3 コマンドが認証失敗になりうまく動かない。 $ hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) Error getting pull request: Unauthorized (HTTP 401) Bad credentials 色々調べたけど結論としては ~/.config/hub に書いてある認証情報が古かったので消すと認証の再要求が発生して解消した $ rm ~/.config/hub $ hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) github.com username: hub am -3 コマンドでマージしようとしたらコンフリクト $ hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) Applying: (this is a comment of commit) Using index info to reconstruct a base tree... M circle.yml Falling back to patching base and 3-way merge... Auto-merging circle.yml CONFLICT (content): Merge con...

結論 5GHz帯のWi-Fiに接続していたものを、2.4GHz帯へ変更すると解消されてインターネットが利用できるようになりました。 Macのサポートサイトに  Wi-Fi や Bluetooth を使用した通信を妨げる要因 というページがあり、そちらを読むと色々原因が書いてありましたが、私の場合は利用するWi-Fiの周波数を変更することでうまくいきました。 ディスプレイは発している周波数と干渉したりしているのかもしれません…。 背景 会社ではMacBookProを貸与されており、許可を得て自宅に持ち帰ったりしています。 休日のトラブルをそれで自宅から対応したり、自宅で興味のある検証をやってみたり、その結果をこのブログに書いてみたり…。 ありがたい環境なので、積極的に活用しようと、自宅の28インチのディスプレイに接続して作業をしようと思ったのですが、なぜかディスプレイに接続するとwi-fiが激重になってインターネットができません。 AWSの管理画面をちょっと覗いたりとかその程度さえできずに困っていました。 ディスプレイ何使ってんの？ ViewSonicです。グレアですがコスパよくておすすめです。 スピーカー内臓なのとHDMIが2ポートあるところが特にお気に入りです。 画面がデカい割に足元が弱いのか画面がちょっと揺れやすいですが、気にならない人にはおすすめです。

せっかくなので画像付きメモを。 まず開封前の外観です。箱がすごくしっかりしています。 どうやって開けるか少しだけ悩みましたが、側面にシールが貼ってあり、「ここ切ってね」みたいに示されているのでそこから開けられます。 大きさはこんな感じ。手元にいい感じのモノがなかったので3DSLLと比較してみました。 箱の下に２冊の説明書がありました。黒の書と白の書。なんかかっこいい。 黒の書にはいろんな言語で簡単に最初の設定方法が書いてありました。 白の書には取扱上の注意がいろいろ書いてありました。 ポイントは「電池交換不可」なところでしょうか。 電池が切れたら買い換えてね、の製品設計です。 Immutableってやつですね、この辺はクラウド企業らしい。 黒の書の日本語版はこれだけ。 PCのAmazonのアカウントセンターには「Dash端末」という項目がなく、Amazonのスマートフォンアプリからしか設定開始できないようです。 「新しい端末をセットアップ」をタップするとセットアップ画面に移行します。 Dash Button を長押しして、青いランプが点滅するのを確認してからアプリ側の「接続」をタップします。 最初はアプリとDash ButtonはBluetoothで接続するようです。 何回かやってうまくいかなかったのでちょっと悩みました。 もしかしてと思ってスマートフォンの省電力モードを無効にしたあと再度数回チャレンジしたら成功しました。 この画面の前にWi-Fiのアクセスポイントの選択とパスワードの入力の画面がありました。 アプリに入力した設定内容をどうやらBluetoothでDash Buttonに共有して登録させるようです。すごいー。 ということで、無事、大好きなキュキュット ピンクグレープフルーツを購入するためのAmazon Dash Buttonのセットアップが完了しました。 設定完了後にボタンを押すと、黄色で点滅が起こり、その後まるで「注文が完了しました」と言わんばかりに緑のゆったりとした点灯が起こります。注文履歴を見るとちゃんとキュキュットが注文されていました。すごい。 以上、久しぶりのブログ活動でした。

海外向けサービスを構築したときのお話です。 たとえば突然「インドネシア向けサービスを作りたいんだけどさ」みたいなことを言われたとします。 専用サーバを構築するとして、そのサーバの時刻をその国のタイムゾーンで合わせないといけないわけです。 どうやって合わせる…？ていうか時差は何時間？ まずその国の「アルファベット２文字の国コード」を確認します。 例えば このWikipediaのページ で確認できます。 日本なら、「JP」ですね。インドネシアは「ID」です。 次に、 このWikipediaのページ を開いて、その２文字の国コードの行を検索します。 「CC」の列が「ID」の行です。 4つありますね。 これにより、インドネシアにはタイムゾーンが4種類あり、GMT+07:00、GMT+08:00、GMT+09:00の３種類があるわけです。 なので、エンジニアとしては「調べたところ、インドネシアは時差が４種類ほどあるようなのですが、どれにすれば良いでしょうか？」みたいなことを言って確認する必要が出てくるわけです。 以上、簡単ですが、何気に重要なタイムゾーンの選定方法でした。

その時のスライドがこちらです。 Docker study for beginner in My Company 2017/10/19 from Masumi Yoshida 勉強会当日には、主に「Dockerを一ミリも使ったことがないエンジニア」に集まっていただき、Dockerってどんな感じのソフトウェア・システムなのか、自社ではどんな感じで開発に利用してるのかというような観点でお話しました。 デザイナーも来てくれたりしたので、具体的な操作方法は抜きにしてとにかく概要を理解してもらうことに重点を置いたスライドになりました。 本当はハンズオンのパートを作る時間を捻出できなかっただけですが…。 社内では割と好評だったので（そもそも勉強会をオラッっとやる人が少ない…）、次回はECSについて説明するようなスライドを作成できればと考えています。

Docker経験値0だった私も何冊か本を読んで実際にDockerfileを見たりいじったりしてみてECSに試行錯誤でデプロイしてみたりして、ようやく少しずつ慣れてきた感が出てきました。 しかしまだまだ「バッチリできます！」というには力不足間は否めなく…いやそういう話じゃない。 折角本を読んだりネット上の先輩たちの記事を読んだりして色々覚えたのだから、それをまとめておきたいと思います。 実はもうすでに 日本語での公式なDockerfileベストプラクティス が存在するので、意味がないといえばたぶん意味はないのですが、アウトプットをして学習にいったんの区切りをつけるという意味で自己満足も兼ねて書きたいと思います。 Dockerfileについての基本的なこと 1コンテナ1プロセスを起動するつもりでDockerfileを書く 1プロセスとはつまりnginxとmod-phpによるPHPアプリケーションなら2つのコンテナを用意するということ コマンドは大文字で書く（ RUN, COPY, EXPOSE 等） #によるコメントアウトが使える FROM 文は先頭に1行だけ書く CMD 文は末尾に1行だけ書く Dockerfile についてやるべきこと・意識すべきこと DockerHub のイメージは「公式」とわかるもの以外むやみやたらに使わずできるだけ Dockerfile を読んでから利用を判断する DockerHub は Docker イメージの共有サイトだが、有象無象のコンテナイメージが登録されており、（その意図はなくても）セキュリティ的に危険なコンテナが存在する可能性は十分にある。  DockerHubが公式に提供しているNginx  など、ソフトウェアベンダ（団体）の公式イメージ以外は基本的に利用しないことで基本的なセキュリティある程度確保することができる。 構文にはshell形式とexec形式が利用できるものがあるが基本的にexec形式を利用する 例えばCMDコマンドはshell形式とexec形式を利用することができる。 shell形式は指定された文字列を /bin/sh -c に渡すことでコマンドを実行する。 その場合に、exec形式だと/bin/shに対する攻撃のような文字列の実行を回避するこ...