タグ

2019年9月17日のブックマーク (6件)

  • Lookerに関するトレーニングが受講出来る『Looker University』について #looker | DevelopersIO

    小ネタです。 Lookerでは日語ドキュメントや関連コミュニティ等、情報のやり取りも活発で参考になるノウハウも豊富ですが、『Lookerに関するトレーニング』についても専用のサイトが設けられ、関連するトレーニングを受けることが出来ます。それが当エントリで紹介する『Looker University』です。 Looker University ユーザー登録は無料。右上の『Sign In』から『Sign Up』のタブを選択し、別途必要な情報をユーザー情報として登録すればOKです。 受講可能なセッション、トレーニングは以下の通り(2019年09月17日現在)。また数が豊富...とまでは行かないですが、Lookerの基的な部分を学ぶ上では十分過ぎる程のラインナップです。ほぼほぼ無償ですが、幾つか有償のものも存在するようです。 free training Getting Started with

    Lookerに関するトレーニングが受講出来る『Looker University』について #looker | DevelopersIO
  • ズールータイム

    標準時を示すための記号で、アルファベット1文字を使ったズールータイムと言われる表記があります これはUTC±0hにアルファベットのZを割り当てているために、フォネティックコードのZからズールーと呼ばれているようです タイムゾーンが違う地域を移動する、船舶や航空機などで使われることが多いようです 例えば、以下のURLに示す画像はF/A-18のHUDですが、左下に時計が表示されており、最後にZが表示されています これは世界標準時±0時間でのタイムゾーンで時間を表示しているということです https://en.wikipedia.org/wiki/File:F-18_HUD_gun_symbology.jpeg このタイムゾーンのリストは米wikipediaに"List of military time zones"というページで紹介されています https://en.wikipedia.org

  • API Gateway バックエンドのLambdaにおけるジレンマをLayerで解決する | DevelopersIO

    渡辺です。 Developers.IO Cafeのブログドキュメントシリーズ第3弾は、Lambdaの構成に関するトピックです。 Lambdaは小さな独立した処理(プログラム)を実行するには適したサービスです。 一方、多くの関連する処理を行うAPI Gatewayのバックエンドとして利用する場合、必ずしも適したサービスとは言えません。 例えば、一般的なウェブアプリケーションフレームワークでREST APIを構築したとしましょう。 フレームワークは、単一アプリケーションとしてサーバ上で実行されます。 リクエストは、フレームワークでルーティングを解決され、対応する処理(アクション)がキックされます。 前段にELB等のロードバランサが入ることもありますが、雑に言えばこういう仕組みです。 このよう場合、 共通処理を切り出し、各処理から呼び出す構成にする のが一般的です。 そうしなければ、各処理のコー

    API Gateway バックエンドのLambdaにおけるジレンマをLayerで解決する | DevelopersIO
  • CloudFront と API Gateway で SPA の CORS 問題をイイ感じに解決する | DevelopersIO

    渡辺です。 弊社ではお客様の悩みや問題を解決するアンサーブログという文化がありますが、新しく「ドキュメントはブログ」というのを試しています。 現在、 Developers.IO Cafe はSPA(Single Page Application)で構成されています。 SPAとは、単一のウェブページ上でJavaScriptによるルーティングの処理を行うWebアプリケーションです。 一般的に、SPAで内のコンテンツは、APIを通して取得します。 この時、悩ましいのが CORS(Cross-Origin Resource Sharing) です。 エントリーでは、カフェのSPAでとったCORS対策について解説します。 CORSとは? CORSとは、簡単に言うと、 ウェブサイトが異なるドメインに対するAPIリクエストをブロック する仕組みです。 あるウェブサイトを開いている時、まったく関係ない別

    CloudFront と API Gateway で SPA の CORS 問題をイイ感じに解決する | DevelopersIO
  • Developers.IO Cafe でのAWSアカウントとステージの構成 | DevelopersIO

    渡辺です。 Developers.IO Cafe のドキュメントシリーズ第4弾は、AWSの環境周り、つまりAWSアカウントの構成について解説します。 ステージ毎にAWSアカウントを分ける カフェでは、プロダクション環境(PRD)、ステージング環境(STG)、インテグレーション環境(ITG)、開発環境(DEV)のステージ(環境)を持ちます。 原則としては、 このように プロダクトをステージに分ける場合、AWSアカウントを分割する ことがセオリーです。 カフェではさらにIoTアカウントを作成しています(後述)。 AWSアカウントを分割した場合のメリットは多くあります。 各環境でアクセスポリシーが明確になる 例えばIAMでログイン可能なユーザを明確にすることができます。 他の環境へのアクセスは許可しなければできません。 間違えてプロダクションを操作といった誤操作を防止できます。 リソースが混在し

    Developers.IO Cafe でのAWSアカウントとステージの構成 | DevelopersIO
  • Serverless FrameworkでCORSに対応しつつ、認証にCustom Authorizerを使ってみる - サーバーワークスエンジニアブログ

    業務改善の中でChromeExtensionを作成中に、API GatewayのCORS対応をしたのでその内容をご紹介します。 CORSとは? CORSとはCross Origin Resource Sharingのことで、とあるWebアプリケーションから、そのアプリケーションとは異なるドメインにリクエストを行うときの取り決めです。 今回は、ユーザーが表示しているWebページ(google.com)から自分が作成したAPI(xxx.execute-api.ap-northeast-1.amazonaws.com)を叩く、というようなChromeExtensionを開発していました。 このケースの場合、WebページのドメインとAPIのドメインは異なるのでCORS対応を行わない場合には、ブラウザによってレスポンスが捨てられます。 こんなときは、アクセスされる側(今回のケースではAPI Gate

    Serverless FrameworkでCORSに対応しつつ、認証にCustom Authorizerを使ってみる - サーバーワークスエンジニアブログ