1時間で出来るWordPress環境構築(※永久無料・・・だった)【※2020/7/1より約300円/月が有料になります】 - Qiita
個人用メモです。 !! ======================== !! ※この記事は2019年の記事です。著者はもうWordPressを使用しておりません。この記事で紹介している内容は2019年当時の内容である事を理解した上で、実際に設定する際は最新の情報を確認しながら行ってください。 2019/9/26追記 2020年1月1日より静的IPが有料になる旨Googleから発表がありました。 $0.004/時間=最大約300円/月が有料となります。 それ以外の部分についても無料でなくなり次第記事を更新してまいります。 情報: @mattn 様 2020/3/20追記 まだ請求額が0円だったので「あれ？」って思って調べたら、上記の静的IP有料の変更は1/1から反映されてるものの、キャンペーンで2020/4/1までは割引されている事に気がついたので注釈追記しました。ちなみに割引されなかった
はじめに WASMをブラウザの外で動かすトレンドに関して「Linuxコンテナの「次」としてのWebAssemblyの解説」というタイトルで動画を投稿したのですが、動画では話しきれなかった内容をこちらの記事で補完したいと思います。 2022年もWebAssembly(WASM)の話題が多く発表されましたが、そのひとつにDocker for DesktopのWASM対応があります。FastlyやCloudflareもエッジ環境でWASMを動かすソリューションを持っていますし、MSのAKS(Azure Kubernetes Service)でもWASMにpreview対応しています。WASM Buildersでも2023年のWASMの予想としてWASMのアプリケーションランタイム利用に関して言及されました。 WASMといえば元々ブラウザ上で高速にC++のコードなどを実行するところから始まっている
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
Zennを支える技術とサービス構成
Zennという技術情報共有サービスを作りました。有益な知見をシェアした開発者が、その見返りを得られるようなサービスにしたいと思います。気合いを入れつつも、時間をたっぷりかけて地道に育てていきます。 このページでは、Zennを支えている技術やサービスを紹介します。 フロントエンド Next.js フロントエンドにはNext.js（React）を使っています。開発当初はNuxt.jsを使っていたのですが、TypeScriptとの相性を考えてNext.jsへ移行しました。 技術情報共有サービスなので、主要な流入元はいずれ検索エンジンに落ち着くと予想しています。そのため、検索エンジンにインデックスしてもらいたいページはサーバーサイドレンダリング（SSR）しています。 動的コンテンツもキャッシュ Next.js 9.4からIncremental Static Regenerationという最高の機能
2021年サーバーサイドのエンジニアが使ってよかったもの10選 - KAYAC engineers' blog
こんにちは！ Tech KAYAC Advent Calendar 2021 7日目を担当する荒賀(@ken39arg) です。 カヤックのエンジニアブログには2008年にPHPを使ったガラケー関連の記事を書いたのが最初になります。 それから10年以上たち、ガラケーも弊社でのPHPのプロジェクトもほぼなくなり、メンバーもかなり入れ替わり、私自身も20代だったのがついに40歳になりました。そんな私にとってこのアドベントカレンダーは私は今でもここにいるよというPingのような役割になっているため、年に一度若者に混じってアドベントカレンダーに参加しております。 例年ですと、趣味のマラソンなどに関する実績も書いているのですが、昨年同様、今年も続くコロナ禍により多くの大会が中止となったためこちらに関しては特に特記すべき実績はありません。ただ2020年に走るはずだった東京マラソンは権利は移行を続けてお
yamlについて思うこと
yaml、どうしてこんなに使われているのだろうか。kubernetesにも責任があるというのはありそうな話だけど、色々考えてみるとそこまで簡単な話でもなさそうな気がする。例えばtravis-CIの設定ファイルがyamlであったりというように、この分野ではyamlは割と広く使われていたんじゃないかという気がする。思い起こせばGoogle AppEngineもapp.yamlに設定を書いていたし、設定にyamlというのは割とよくあることであった、のではないかなあ。 しかしなぜyamlなんだろうか。yamlのフォーマットには問題がたくさんあることが知られているし、自分も全く好きではない。 例えばyamlの問題の一つとして、キーに任意のデータ構造を持ってこれるという話があり、これが一部のプログラミング言語で問題を厄介にしている。またエイリアスがあってデータ構造がツリーにならない（複数の経路から同じ
Nuxt.js＋Firebase＋GAEで作った個人サービスが半月で2万PV超えたので実績値を全て公開する - Qiita
こんなサービス作りました 【#拡散希望】 🙌🎉🎊サービス開始🎊🎉🙌 ボケをツイートして 「いいね❤️」「リツイート🔁」 の数でランキング！ Twitter連動型 大喜利サイト 「ついぎり」 サービス開始しました‼️#ついぎりhttps://t.co/bkXfzHyVSs — ついぎり@公式アカウント (@twigiri_app) August 14, 2019 Twitterで大喜利するサービスです。 ８月中頃にローンチしたのですが、有難いことに半月で約2.5万PVいきました。 開発に至ったポエム記事はCrieitに投稿しています。 なぜ大喜利サービスを作ったのか この記事について やっぱり公開直後は怖かったです。 そう、クラウド破産。 Firebaseの設定を間違えて72時間で300万円以上請求されてしまったウェブサービス BigQueryで150万円溶かした人の顔 上記以
ZennではフロントエンドにNext.jsを使っています。もともとはVercelで動かしていたのですが、2021年3月にGoogle Cloudに移行しました。今回は移行を決めた理由や、具体的な構成、移行作業などについて書きたいと思います。 なぜ移行したのか Next.jsのデプロイ先としてVercelは圧倒的に優れています。ISRやImage OptimizationといったNext.jsの強力な機能をサーバー側の追加設定なしで使用できますし、CDNでの静的ファイルのキャッシュなども特に意識しなくてもいい感じにやってくれます。 Vercel以外にデプロイするとなると、Next.jsの一部の機能がうまく動かなかったり、パフォーマンス・チューニングを自分で頑張る必要があったりと自分で面倒を見なければならない部分が多くなります。 しかし、Zennのケースでは以下のような理由からVercelから
Zennのバックエンドを Google App Engine から Cloud Run へ移行しました（無停止！YES！）
Zennは、Next.js + Ruby on Rails（APIモード）を Google Cloud の App Engine へデプロイして稼働していました。最近、Rails の実行環境を App Engine Flexible から Cloud Run へ移行したので、その記録を残します。 ロードバランサーのバックエンドサービスを付け替えることで実現 最初に、どうやって移行したかです。Zennのバックエンドはもともとロードバランサーで構成されていました。以下の図のように、ロードバランサーの Backend Service より背後を切り替えることにより実現しています。Cloud Run とそこにアクセスするための Serverless NEG はあらかじめ稼働させておくことで、ダウンタイムなしで切り替えられました。 参考：負荷分散 | Google Cloud https://clo
Google Cloud で何かアプリケーションを動かしたい時、いつも App Engine (GAE) を第一の選択肢として挙げています。 なのにみ〜んな Cloud Run に行ってしまう。なぜなのか?? 確かに Cloud Run のほうが新しくて公式に露出が多いし、GAE はこういうランディングページからの言及も消えているので無理もない。Google Cloud 的にもあんまり使って欲しくない雰囲気が漂っている。 cloud.google.com App Engine は GCP 最初期からあるサービスで今年で 14 年目になるらしい。 当時学生だった僕はすげーのが出たぞと聞いて GAE を触っていた記憶がある。その頃は Google App Engine 単体で出ていて、他のサービスが続いて Google Cloud Platform になったような気がする1。 そんな歴史あるサ
App Engine VS Cloud Run
Cloud Run CPU 0.08 ~ 8 Core (2nd gen は最小 0.5~) Memory 128 MiB ~ 32 GiB (2nd gen は最小 512MiB~) Deploy App Engine は Deploy (gcloud app deploy) を実行すると Cloud Build が暗黙的に動いて Deploy が行われるが、これがなかなか時間がかかる。 開発環境だと CI でとりあえず main branch に merge されたら、Deploy したりするけど、Deploy を Skip してもよいような時でも CI 回してると Deploy を待つことになって、ちょっとめんどうに感じる。 更にこの仕組みは成果物は Deploy しないと生まれないので、CI と CDを分離しづらい。 Cloud Run は Container Registry a
バッチ処理のスケジューリングパターン
この記事はこの記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 12日目の記事です。 はじめにGoogle Cloud Platform (GCP) でバッチ処理を起動するための以下のパターンについてご紹介したいと思います。以下、８パターンあげてみました。とはいえ、最後の3つは GCP のバッチスケジューリングという観点からは少し外れますが、バッチの起動時に使われるということでご容赦を。 Cloud Scheduler : フルマネージドな cron ジョブスケジューラです。フルマネージドという点が非常に大きなメリットであり、多くの処理を自動化し実行することが可能です。Google App Engine cron サービス : HTTP GET を利用して、特定の URLを呼び出します。Google AppEng
クソアプリ2 Advent Calendar 2019の20日目の記事です。 作ったもの Barcode The Gathering https://barcode-the-gathering.appspot.com/ バーコード（QRではない、商品についてる一次元バーコード）から、ギャザのカードを生成できます。 異なるバーコード3枚スキャンするとデッキとして保存出来ます。 簡単な創作ルールでランダム対戦も行えます。 なんで？ 皆さんはMagic:TheGathering®︎1（略称 ギャザ）をご存知だろうか。 トレーディングカードゲームの元祖であり、「世界でいちばん遊ばれているTCG」を筆頭に７つのギネス記録を持つカードゲームである。 日本では遊戯王やポケモンカードゲームの認知度が高いが、それらは全てギャザが元となっている。 そんなギャザのカード情報を取得するAPIが存在することを知った
Nuxtアプリを無料で公開するときに試した5つの環境まとめ(Firebase/GAE/Netlify/Heroku) - Qiita
最近Nuxtでいろいろ作っているけど、無料で使える環境をいろいろ試してる。 いろいろメリデメあるけど、SPAならNetlify/SSRならHerokuがよさそう。 いままで試したものをまとめてみた。 ほしかったもの 主に開発してるのがCGM系のWebサービスなので、 動的なOGP画像などが設定できる(OGP芸) カスタムドメインが使える 日次のランキング集計などの定期実行ができる が、無料でできて、なるべく実装が楽で、そこまで遅くないのがうれしい。 試した5つのパターン 試したのは以下の5パターン。試してみた順で記載。 Nuxt(SSR) + Cloud Function 起動がかなり遅かった。。実装も大変なのでNG Nuxt(SPA) + Firebase Hosting 構築はかなり楽。ただ、OGP芸が大変でFunctionsが必要 Nuxt(SPA) + Netlify プレレンダリ
株式会社ウェリコで、お客さんのスマートフォンでメニューの閲覧・注文・決済ができるスマートレストランを作ったときに、gqlgenとRelay Modernを使ってGraphQLを採用した話
[Cloud OnAir] Cloud Run Deep Dive ~ GCP で実践するモダンなサーバーレス アプリケーション開発 ~ 2019年9月12日 放送
![[Cloud OnAir] Cloud Run Deep Dive ~ GCP で実践するモダンなサーバーレス アプリケーション開発 ~ 2019年9月12日 放送](https://cdn-ak-scissors.b.st-hatena.com/image/square/faf980322ca4f84c0fa016b0f7e634f3f68d732d/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F0912-190912084632-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
イメージとしては スタンダード環境の方が気楽にはじめられる フレキシブル環境の方がより細かな設定ができる という感じでしょうか。 「料金が安いのはスタンダード」とは限らない ググって見つかる情報を読むと、多くの人は「スタンダード環境の方が安く済みそうだ」という印象を持つと思います。僕もそのような考えから、当然のようにスタンダード環境を選んでいました。しかし、結果として、Zennの場合にはフレキシブル環境の方が料金は大幅に安く済むことが分かりました。 Zennの場合 具体例があった方が読んでいて楽しいと思うので、恥を捨てて実際にかかっていたGAEの料金を載せてしまいます。ほれっ。 ※ 料金の推移は、サービスへのアクセス数とはほぼ相関していない ピーク時には1万円/日近くいってしまっていますが、設定と環境を見直すと¥500/日くらいで済むようになりました。設定をミスらなければPS5を転売ヤーか
g4というサービスを運営しているのですが、ここ数ヶ月間でGCPの月額費用を4万円以上節約したので、経緯を書いておきます。 7月の費用 ¥53,818 9月の費用 ¥18,801 詳しくはこちらのレポート 11月の費用 ¥7,333 詳しくはこちらのレポート 5月はこんな感じでした。 完全にやらかしてますね！！敗因は 無料期間なのもあり利用料金気にせずに使っていた そして無料期間の終わりを忘れていた アラートを設定していなかった です。 まずは、 7月の費用から約3万円節約するために、GAEのオートスケール周りの設定を見直しました 7月の状態は 本番: (GAE flexible/custom cpu x 2) x 2台 ステージング: (GAE flexible/custom cpu x 2) x 2台 （DBに関しては本番とステージングで同じインスタンスを使っています） でした。これは、
Google App EngineでRubyのスタンダード環境でのサポート開始。負荷がないときはゼロインスタンスまで縮退可能
Google App EngineでRubyのスタンダード環境でのサポート開始。負荷がないときはゼロインスタンスまで縮退可能 Google App Engineは、JavaやPython、PHP、Node.js、Goなどさまざまなプログラミング言語の実行環境を提供する、いわゆるPaaS型クラウドサービスです。 利用者はこれらのプログラミング言語で記述されたコードをデプロイするだけで実行可能。負荷に合わせたプロセスの増減などスケーラブルな処理や、万が一プロセスが異常終了したときのフェイルオーバーの処理などもクラウド側で行ってくれるため、運用の手間がかからないなどのメリットがあります。 Google App Engineは2016年から、ユーザーがGoogle App Engineにプログラミング言語の実行環境を持ち込んで実行できる「フレキシブル環境」においてRubyをサポートしていました。
Google App Engineが「Java 11」サポート開始。Spring Boot、Micronaut、Quarkus、Ktorなどのフレームワークも利用可能
Google App Engineが「Java 11」サポート開始。Spring Boot、Micronaut、Quarkus、Ktorなどのフレームワークも利用可能 Java 11は1年以上前の2018年9月にリリースされたJavaです。Javaは6カ月ごとにフィーチャーリリースが登場しているため、現時点での最新版のJavaは「Java 13」となります。 ただし、Javaには3年ごとに長期サポート対象となるLTS（Long Term Support）版が登場します。LTS版以外のJavaは次のフィーチャーリリースが登場するとセキュリティパッチなどが提供されなくなりますが、LTS版は登場から3年間はセキュリティパッチなどが提供されます。 そしてJava 11は、このLTS版としての最新版なのです。 App Engineは、フルマネージド環境でアプリケーションを実行できるクラウドサービス。
Ruby support comes to App Engine standard environment | Google Cloud Blog
We have some exciting news for App Engine customers. Ruby is now Beta on App Engine standard environment, in addition to being available on the App Engine flexible environment. Let's dive into what that means if you’re a technical practitioner running your apps on Google Cloud. There are lots of technical reasons to choose App Engine standard vs. flexible environment (this link explains it if you
Nuxtで毎日やりたいことを習慣づけるWebアプリ「コツコツ忍者」を作った🏃♀️【個人開発】 - Qiita
お久しぶりです。 以前、Nuxt.jsとFirebaseでchocottoというTwitterでお菓子と一緒にメッセージを送れるサービスを作ったG4RDSです。 先週、二十歳を迎えて成人しました🎉 今は高専五年で、編入試験を受けている真っ只中です。 適度にお酒を入れて、今後も個人開発頑張っていこうと思います！ さて、今回作ったWebサービスは「コツコツ忍者」というWebアプリです。 昔ばなしに、忍者は跳躍力向上のために毎日成長していく小さな木を飛び続けた、というお話があるのをご存知ですか？ ある能力を向上させたいのであれば毎日継続してやり続けることが大事である、ということですね。 自分が好きなことは続けられますが、好きではないけど上達したいことは続かないからなかなか上達しません。 そんな「上達したいけど続けられない」ことがある人のために、毎日やったことを記録できるWebアプリを作りました
超簡単 Google App Engineで始めるWebアプリケーション 〜リクエスト分割機能がすごかった〜 | DevelopersIO
どうも、GCPヨチヨチ歩きの城岸です。 本日は、Google App Engine（以下GAE）を使って簡単にWebアプリケーションをデプロイする方法を紹介したいと思います。 アプリケーションのバージョンごとにリクエストを分割できる機能が素敵すぎてブログを書かずにはいられませんでした！ それではいってみましょう！ GAEとは GCP (Google Cloud Platform)が提供するPaaSです。Java、Node.js、Python、Go など好きな言語で作成したアプリケーションをGCPが管理するインフラに簡単にデプロイすることができます。AWSのAWS Elastic Beanstalkと同じカテゴリのサービスです。 詳細は公式ドキュメントをご覧ください。 やってみた 公式のチュートリアルをベースに進めていきます。 アプリケーションはGo 1.11で作成します。 検証環境 ブラウ
GAE 2nd-gen でのサービス間認証
TL;DRGAE 2nd-gen では X-Appengine-Inbound-Appid ヘッダの代わりに、ID Token + Identity-Aware Proxy を使った方式をサービス間認証に使えます。 はじめにGAE でマイクロサービスを構成する場合、各サービス同士を呼び合うときに同一 GAE アプリからのリクエストであるかを確認したい場面があります。シンプルな例だと、サービスがフロントエンドとバックエンドに別れていて、バックエンドはフロントエンドからしか呼び出せないようにしたい場合です。 GAE 1st-gen では X-Appengine-Inbound-Appid ヘッダという魔法のヘッダがありました。このヘッダは URLFetch を使用して別の GAE サービスにアクセスする時に、GCP が自動で呼び出し元の Project ID を入れてくれるヘッダです。そのため
GAEアプリの開発フローにCloud BuildでのCI/CDをいい感じに組み込む - Sansan Tech Blog
関西支店で新規事業開発室に所属する加藤です。私のチームでは、Google Cloud Platform (GCP) で主にGoogle App Engine (GAE) を使ってシステムを構築しています。 GAEはコマンド1つで簡単にデプロイできますが、チームの開発者が増えるにつれて、デプロイ用の設定を共有するのが大変になってきました。 デプロイにも時間がかかって、リリース作業に負荷を感じるようになりました。 そこで、GAEアプリケーションの開発フローに、Cloud BuildによるContinuous Integration (CI) / Continuous Delivery (CD) を組み込み、デプロイを自動化しました。 公式ドキュメントや各種ブログに個別の方法は記載されていますが、開発フローに組み込もうとした時にいくつか考えることがあったので、まとめておきます。 前提 Googl
この記事はMERPAY TECH OPENNESS MONTHの3日目の記事です。 メルペイ ソリューションチームで毎日コード書いたりして遊んでいるvvakameです。 TL;DR AppEngine 2nd genでロックインAPIから解放され大脱出できるようになった AppEngine Log APIはオーパーツ(完全には真似できない) プラットフォーム出力のrequest logを使う アプリではapplication logだけ出力する 高度なフィルターの使い方を覚える 05/23 もらった情報をもとに追記をしました。 AppEngineはいいものだよ & 2nd genの台頭 メルペイではプロダクト提供のためにAppEngineはほぼ使われていません。だいたいのものがGKE上で動いていて、だいたいのDBはSpannerです。しかし、お客様に提供するものではない、internalな
WEARにおけるGAE(Google App Engine)を用いた機械学習アプリケーションの運用について
When Systems Fail: Lessons learned from real life experience's as SRE's
｜DMM inside
こんにちは、エンジニアの@tarr [https://github.com/tarr1124]です。 前回の連載記事 [https://tech.plaid.co.jp/karte-blocks-multicloud/]ではマルチクラウドなどを使い、Blocksでは最大限落ちないようにリスクヘッジをしながらシステムを構築しているという記事を書きました。 * AWSが落ちてもGCPに逃がすことで
Serverless NEG でシステム開発をより柔軟に
はじめに以前 Yuki Furuyama さんが「NEG とはなにか」という哲学的な(?)記事を書かれていましたが、このたび「Serverless NEG」(Serverless Network Endpoint Group)という新しいタイプの NEG が追加されました。(まずは Beta でのご提供です → EDIT(2020–10–14): 2020年10月14日に GA になりました。) これで NEG は Zonal NEG、Internet NEG、Serverless NEG の三種類になりました。 Furuyama さんの Zonal NEG に関する記事には「NEG は Kubernetes の Service に相当するもの、Network Endpoint は Pod に相当するものです」とありましたが、Serverless NEG では「Network Endpoi
https://matopee.com Firebaseを管理画面側に、GAEを公開側に使って、日本語のオノマトペを集めて辞典などとして公開するサービスを作っています。まだまだ不足だらけですが、まずは3200件ちょっと集めたオノマトペの五十音別全一覧を中心に公開しています。 オノマトペにも過不足がありますし、古語や方言はまだほぼ手つかずです。今後は地道に語義を増やし、分類し、論文や書籍、Webなどの参考情報を集め、幾つか毛色の違うコンテンツの準備をしよう、という状況です。 コメントで @scivola と @perpouh からいただいた以下のオノマトペなどを追加し、現在3340件になりました。 以下は語義付きで登録しました。 かこーん ぐすぐす しみじみ ちんちくりん てれてれ どんぶらこ 以下は登録のみ。 ざんぶ, じゃらん, じゃらーん, しゃらん, しゃりん, すぼっ, ぱったり,
「ごめん、同級会にはいけません」 強烈なインパクトを持つこのCM。 これが大好きなので、同級会に誘うと 「今、シンガポールにいます」と 返事を返してくれるLineBotを作ってしまいました。 さらに、ドヤァ感をよりいっそう高める仕様をいろいろモリこみ、 地図には残らなくても、使った人の記憶に残る仕事にしたいと思います！ クソアプリ Advent Calendar 2019 の４日目です。 と、書くまでもなくタイトルから漂うクソアプリ感 使い方： ① 同級会を開く ② おもむろにLineを立ち上げ「綾乃、いまどこ？」と聞く ③ 「ごめん、同級会にはいけません～～～以下略」と返信が来る ④ 「え、シンガポールだって」という感じでみんなでのぞきこむ 実行した時の様子： ※親切に、シンガポールの地図を示してくれる（地図に残る仕事） 他にも形態素解析などの無駄な機能を満載。 LineBot作成のノウ
マンガ『ゲームセンターあらし』をはじめ、数々の人気作で知られるマンガ家・小説家のすがやみつる氏。2020年には新刊『ゲームセンターあらしと学ぶプログラミング入門 まんが版こんにちはPython』を上梓し、注目を集めた。またすがや氏は、京都精華大学マンガ学部の教授として、多くの学生を世に送り出してきた人物でもある。2021年3月の退職を機に、研究者・教育者としての足跡について聞いた（写真はすべてすがや氏提供）。 INTERVIEW＿小野憲史 / Kenji Ono EDIT＿三村ゆにこ / Uniko Mimura（@UNIKO_LITTLE）、海老原朱里 / Akari Ebihara 大学の教員を退職し、再びクリエイター活動へ CGWORLD（以下、CGW）：遅ればせながら、京都精華大学を退職おめでとうございます。 すがやみつる氏（以下、すがや）：2020年3月に専任教員を定年退職して、
swagger.yamlからSwaggerサーバーを自動生成してデプロイする仕組みを作ってみた - Qiita
概要 swagger.yaml を GitHub に push すると CircleCI 経由で Swagger サーバーを Google App Engine (GAE) にデプロイされる仕組みを作ってみました。 swagger-codegen を使うと swagger.yaml から API ドキュメントとモックサーバーを生成することができます。GitHub で swagger-codegen で生成したサーバーサイドのコードを管理して Webhooks を使ったデプロイをする方法もありますが、生成に必要な swagger.yaml だけをソース管理した方が管理しやすいので、その仕組みを作ってみました。 完成物 今回は Swagger Editor で最初に入力されている Petstore のものをそのまま使いました。 API ドキュメント モック API 使用技術 GitHub sw
GitHub - GoogleCloudPlatform/buildpacks: Builders and buildpacks designed to run on Google Cloud's container platforms
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
App Engine を布教したくて Go + Datastore の開発環境を Docker Compose でシュッと立ち上げた話 - Qiita
App Engine を布教したくて Go + Datastore の開発環境を Docker Compose でシュッと立ち上げた話 最新1の Google App Engine Goランタイムの開発環境を Docker Compose で簡単に構築してみた話。 あるいはリーズナブルにサーバーを運用できる App Engine を布教する話。 TR;DR; 環境構築 https://github.com/pistatium/appgengine-go112-datastore-docker-compose 動くサンプルはこちら。 docker-compose up -d で開発環境が立ち上がります。 プロジェクトのテンプレートにするなりご自由に。 App Engine + Datastore の構成 非常に安価でのサーバー運用が可能。 第一世代から第二世代の移行はちょっとつらい。 今から
How I Hacked Google App Engine: Anatomy of a Java Bytecode Exploit
Back in college, I was very interested in Java bytecode. When I got an internship at Google in 2013, I was skeptical of the security of the Java version of Google App Engine and got permission to spend the last week of my internship doing a mini red team exercise, trying to break into App Engine. This is the story of how I found a vulnerability and developed an exploit to break out of the App Engi
フィードバックを送信 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 ホット タブレット Bigtable には、パフォーマンスの問題をトラブルシューティングするため、クラスタ内のホット タブレットを特定してモニタリングする機能があります。このページでは、ホット タブレットの概要、ホット タブレットのリストを取得する方法、ホット タブレットの識別が有益な状況について説明します。このページを読む前に、Bigtable の概要を理解しておく必要があります。 ホット タブレットのリストを取得するメソッドの名前は、使用する言語によって異なります。わかりやすくするため、このドキュメントでは RPC Cloud Bigtable Admin API 名（ListHotTablets）を使用します。ホット タブレットのリストは、以下のものを使用して取得できます。 Goo
Google App Engineでローカル開発をするときにdispatch.yamlをもとにReverse Proxyしてくれるツールを書いた - 時計を壊せ
これです github.com なぜ作ったのか dispatch.yaml や dispatch.xml はGoogle App Engine(以下GAE)のFrontendでルールベースでL7 HTTP Reverse Proxyしてくれるものです。 cloud.google.com これはMicroservicesをやる上では大変便利なものになっています。 一方で、これをローカルで動かす手段が少なくとも自分の知る限りはありませんでした。 なので、いままでは各サービスを連携して動作検証したいときは、GAEにデプロイしてしまうか、 あるいは各サービスをそれぞれ別々のポートで立ち上げながら、各サービスに何らかの方法でそれらのマッピング情報を入れてサービス間で連携が可能なようにするなど工夫をする必要がありました。 別々のポートで立ち上げるところまではよしとしても、めんどくさいのでその後の各サー
サーバ管理なしでWebサービス公開 -Firebase(Authentication, Hosting, Firestore) + GAEで『LogCrow(ログ情報共有サービス)』開発- - Qiita
サーバ管理なしでWebサービス公開 -Firebase(Authentication, Hosting, Firestore) + GAEで『LogCrow(ログ情報共有サービス)』開発- FirebaseとGoogle App Engineを中心に活用し、Webサービスをローンチしたのでそのアーキテクチャ & サービス概要を紹介します。 LogCrow(ログ情報共有サービス) 背景・動機 私は日頃業務で、システムの保守・運用の効率化・改善について検討しており、いろんな運用者の知見が共有できている状態が作れると運用者が幸せになれるのではないかと考えています。 そんな中で、特に保守・運用時にキーポイントとなるログ情報についてフォーカスし、こういうログが出たときには「原因」として何が考えられ、どういった「対処」が必要となるのかといった情報が幅広く共有されると良いのではないかと思っています。 G
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/5b5961cfe7e9736ef0e88bc0290b1599481d2626/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhatenatech%2F20240319%2F20240319125826.jpg)
Linuxコンテナの「次」としてのWebAssembly、の解説
anypicks.jp - anypicks リソースおよび情報
Next.jsアプリをVercelからGoogle Cloudに移行した話
なぜ今も Google App Engine を選ぶのか - ぽ靴な缶
ギャザをドローするクソアプリを作りました - Qiita
スマートレストランでGraphQL を採用した話
[Cloud OnAir] Cloud Run Deep Dive ~ GCP で実践するモダンなサーバーレス アプリケーション開発 ~ 2019年9月12日 放送
Google App Engineのスタンダード/フレキシブル環境を選ぶときのヒントと設定の注意点
Cloud Runは便利！GCPの月額費用を4万円以上節約した話 - Qiita
AppEngineの旧Log APIを脱却したい話 | メルカリエンジニアリング
エンコーダー刷新とマネジメントシステム - DMM inside
リリース後に落ちないように、新規サービスで備えておいたこと
日本語のオノマトペを3000個あつめてGAE/GoとFirebaseでサービスを作る - Qiita
今シンガポールにいますLineBotを作成し、記憶に残る仕事をしたい物語 - Qiita
「教員は学生を育てるクリエイター」～すがやみつる氏に聞く研究者・教育者としての足跡
ホット タブレット | Bigtable のドキュメント | Google Cloud
kusanomido.com
comic-action.com
anond.hatelabo.jp
www.nikkei.com
mainichi.jp
yasashiiijiwaru.com