Web Siteにのせるアイコンの画像なんかを適当にGoogle Cloud Storage (以下GCS)で公開する方法について 料金は無料ではないので、無料が良い場合は別の方法をおすすめします。 Step 0 Google Cloud Platform Projectの作成 無料トライアル 辺りから適当にGCP Projectを作りましょう。 Step 1 Bucketを作る GCP ProjectのメニューからStorageを選択 バケットの作成を選択 Bucket名 ファイル公開時のURLに含まれるので、公開されて良い名前かつDNSの命名規則に従う必要がある。 GCS全体でUniqueである必要がある。 Bucket Class Standard を選択する Locale Asia を選択する Step 2 Bucketの中にファイルをUploadする ブラウザ上でUploadする

注意書き この記事は2017年12月の記事です。 現在、Google Cloud FirestoreはUPDATEされて、以下の内容とは異なります。 新しい記事はお待ち下さい！ 記事 Cloud Firestore がBetaで公開されました。 Cloud Firestoreは、Firebase Realtime Databaseの後継に当たるサービスです。 Firebase Realtime DBに存在していたリアルタイム更新やデータベースルール, オフライン機能や、Firebase Authとの連携などを受け継いでいます。 大きく変わったのはバックエンドです。 Firebase Realtime DBは、もともとGoogleが作ったものではなく、Googleが買収したサービスでした。 買収後、FirebaseはAuth, Push通知, Analytics, Remote Config

What is App Engine FE? App Engineのコンテナを、Dockerベースのものに差し替え、Compute Engineの上で動かす機能 旧 Managed VMs (Managed VMs誕生までの歴史を振り返る) App Engine Architecture App Engine Standard Environment 限定されたコンテナ runtime 縛り (Java, Python, Go, PHP) CPUはシングルコアのみ メモリの最大は1GB App Engine Standard Environment ミドルウェア利用不可 local file systemに書き込み不可 好きなportをlistenできない Compute Engine上にコンテナを立てる Dockerコンテナ 自由な世界 App EngineのAPIをそのまま使える ミド

Kubernetesにはとっても便利な Dashboard の機能があります。 KubernetesのフルマネージドサービスであるContainer Engineでももちろん確認できます。 この記事では、Container Engineを操作する時によく利用する Cloud Shell から、Kubernetes Dashboardを確認する方法を説明します。 credential取得コマンドの表示 Cloud ShellからContainer Engine上のNodeにアクセスする場合、最初にCredentialを取得します。 Container Engineの場合は、 gcloud command を利用して簡単に取得できます。 commandの内容はContainer EngineのConsoleで表示してくれます。 Cloud Shell上でkubectl proxyを起動する c

Tableの分割 BigQueryでは日々生まれるデータを扱う場合、TableをDailyで分けていくのが定石としてあります。 現在、BigQueryではDailyで分ける方法が2つあります。 この記事ではそれぞれのやり方をメリット、デメリットをまとめていきます。 Table Wildcard Function Table名の末尾にYYYYMMDDを入れておけば、TABLE_DATE_RANGE Function を使って、指定した期間のTableを1クエリで扱うことができる機能。 Table自体は自分で日付で違うテーブルを作成しているだけ。 2014年春ぐらいにリリースされたような記憶。 Partitioned Table 1つのテーブルのように見えるが、BigQueryの中でDailyに分かれているテーブルを作成する機能。 2016年春にリリースされた。 どんな機能なのかは BigQu

中間テーブルを作成し、分析するクエリを中間テーブルに対して実行するという操作は、パフォーマンス向上や料金の節約のためなどにBigQueryでそれなりによくやる操作です。 一度やるだけならBigQuery Web UIで適当にやればいいんですが、何度も実行する場合や、毎日一回自動でやるという処理をしたい場合、どこからクエリを投げるのか、ちょっと悩むところです。 Compute Engineのcronで設定すると、Compute Engine管理するのが面倒だし、App EngineやGoogle Scriptでやる場合は、そこそこロジック組んであげる必要があります。 ごりごりロジック書ける人は好きな方法でやればいいんですが、今回は適当にブロック繋いでいけば適当にやってくれる MAGELLAN BLOCKS でやるやり方を紹介します。 実行するクエリ bigquery-public-data:

testerator はGoogle App Engine for Go(以下gae/go)のUnit Testを高速化するために生まれたライブラリです。 gae/goはサーバのSpinUp速度がJava, Python, PHPに比べて高速なので、最近App Engine Developerたちの間に人気ですが、いかんせんUnitTestの遅さだけは洒落にならないレベルで遅いです。 それを緩和するために生まれたのが、 testerator です。 testerator がやってくれることを理解するためには、まずgae/goのUnitTestがなぜ遅いのかを理解する必要があります。 gae/goのUnitTestが遅い原因は、テスト環境がgae/pythonの環境に間借りしているからです。 例えば、公式のサンプル にある通り、 aetest.NewContext() を利用すると、裏ではg

image alias Compute EngineのImageには元々Aliasというプロパティがあり、Aliasを指定した場合、その中の最新のImageが使われていました。 例えば、以下のようにdebian-8のAliasを持ったImageが複数あった場合、その中の最も大きい名前のImageが選択されます。 gcloud compute instances create --image debian-8 # debian-8-jessie-v20160606 が使われる

go-lang-idea-plugin をgae/go開発用に設定してみました。 plugin installについては、 IntelliJ の Goプラグイン 1.0αを試す を参考にしました。 IntelliJ外の環境 IntelliJの外の環境としては以下の様な感じ gae/go root $HOME/bin/google-cloud-sdk/platform/google_appengine/root gopath $HOME/go project workspace $HOME/workspace/go-endpoints-unittest-example goapp env $ goapp env GOARCH="amd64" GOBIN="" GOCHAR="6" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOOS="darw

gae/goはSDKの中にgoそのものも内包しているため、GOROOTとGOPATHを切り替えてやる必要が出てきます。 shellで切り替えても良いのですが、環境を切り替えるためのtoolにgoenvがあるので、今回はこちらを使って環境を切り替えるやり方を紹介します。 goenv install goenvのinstallは公式Documentに書いてある通りです。 projectを作る goenvを利用してgae/go用のprojectを作ります。 $ goenv -gae -go /Users/sinmetal/bin/google-cloud-sdk/platform/google_appengine/goroot -deps /Users/sinmetal/go sample Environment /Users/sinmetal/Documents/temp/sample cre

Google Cloud Platformにはエッジキャッシュの機能がある。 あんまりDocumentにも乗ってないので、今回はエッジキャッシュを紹介します。 エッジキャッシュの特徴 エッジキャッシュはGoogleが利用しているキャッシュサーバに、自分のGCP上のコンテンツも乗せることができる機能です。 GCPのキャッシュサーバは全世界にあるため、日本だけで無く、海外も視野に入れたサービスでも有効です。 特徴 すさまじいキャパシティ とっても安価 キャッシュサーバの管理はGoogleで行ってくれる上に、すさまじいキャパシティを誇り、google.co.jpが落ちるぐらいのトラフィックが来ない限りは、問題ないとまで言われています。 料金も非常に安く、うまく使えば課金額を1桁減らしてくれます。 注意点 アクセス制御は使えない キャッシュに乗っている時間はベストエフォート キャッシュを明示的に消

GAEからGCSを利用する場合、Bucketを作成する必要がありますが、DefaultのBucketを作成することができます。 Default BucketはDevelopers ConsoleのApp Engine Settingのボタンから作成します。 GCS Default Bucket のメリット アプリごとにDefaultBucketを取得できる Bucket名はGCS全体でUniqueである必要があるため、テスト用など複数の環境がある場合、それぞれ別のBucket名を指定する必要が出てくる。 しかし、DefaultBucketを利用すれば、アプリごとにUniqueな名前を出してくれるので、そこを気にしなくてよくなります。 5GBの無料枠がある。 Blobstoreは5GBの無料枠があったのですが、GCSにはありませんでした。 しかし、DefaultBucketについては、Blo