はてなブックマーク

免責事項 まず最初に・・ タイトルの「時間のかかるコード」とは、time.Sleepや、time.Timer、time.Tickerなどが使用されてるものを想定しています。 CPU計算や外部サービス接続など他の理由で時間がかかるコードなどは本記事の対象外です。悪しからず🙇‍♂️ あと、現時点（2020/12）で "Faketime isn't currently supported on Windows." だそうです。Windows Gopherの方はDockerとか使って下さい🙇‍♂️ それから、本記事は思いつきで始めた実験的内容です。結構大きな罠（後述）もありますのでご了承の上お読み下さい🙇‍♂️ Fake timeとは Fake timeはGo Playgroundに組み込まれた、擬似時間を扱う仕組みです。 ご存知の通りGo Playgrondはユーザーの書いた自由なコードを

問題 time.TimeのSubメソッドを利用すると、２つのtime.Time間のDurationを取得することが出来ます。 例えば↓なカンジで処理時間を計測したりします。 start := time.Now() (何か処理) elapsed := time.Now().Sub(start) fmt.Println(elapsed) このコード自体間違いではないですが、今回実行していて明らかに実際の経過時間を返していない事象に遭遇し、軽くハマりました。 9:02にスタートし9:10に終了しているのに、elapsedに 3m などと出力されたり。 startとnowも出力↓ start:2020-07-08 09:02:00.243095 +0900 JST m=+0.003321332 now:2020-07-08 09:10:25.388989 +0900 JST m=+222.3889

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

１週間前にCloud Datastoreのクエリでがんばるハナシという記事を書きましたが、そこで書いた各種テクニックをサポートするライブラリを作ったので紹介します。 XIAN 注意: 現時点でまだβ版(v0.1.0)です。正式版の前に後方互換のない修正が入る可能性があります モチベーション Search APIあまり使いたくない Datastoreクエリの不足する機能を補う為にSearch APIを併用するテクニックがあります。 Search APIはとても便利ですがいくつかの制限があり、何よりインデックスサイズに上限がある為スケーラビリティに難があります。 参照: GAEでハマったこと(´･ω･`) Search APIに出来るだけ頼らないことが本ライブラリの第一の目的です。 LIKEやINを使いたい Cloud DatastoreはLIKEやIN/OR条件のフィルタをサポートしません。

昨今Cloud SpannerやCloud Firestoreなど上位の製品も出てきて徐々に存在感を失いつつありますが、「オレはまだDatastoreを愛してるんだ」「Spanner使う金ねえし」という人もいると思ってCloud Datastore（以降Datastoreと記述します）のクエリのハナシを書きます。 ※Cloud Firestore(Datastore mode)にも適用可能なハナシです。Native modeでも部分的に有効かと思います はじめに 普段使用されている方はご存知の通りDatastoreのクエリにはRDBのSQLと比較して制限があります。 Inequality Filter(>,>=,<,<=)は単一プロパティにのみ使用可能 複数プロパティソート(ORDER BY)を併用する場合、Inequality Filterは最初にソートするプロパティに対してしか使えない

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

追記＆注意(2017/10/25): 本記事内でauto_id_policy=legacyで実験して発生した問題を提起していますが、もしかしたらscatteredだと問題が発生しないのではないか、という疑惑が生じています。scatteredで実験するよい方法が思いつかないので、とりいそぎ追記のみ（無責任でごめんなさい） 追記＆注意(2017/11/29): 新しく追加されたExporting and Importing Entities使うとID衝突防げるのでは？という噂。未検証です。情報求ム。 近々Google Cloud Platform東京リージョンが発表されそうですね。 どうやらGAEやCloud Datastoreも対応されそう。＼(^o^)／ 東京リージョンが正式公開されたら既存のGAEアプリケーション＆Datastoreを移行したい人も多いと思います。 ・・・が、ここでちょっ

はじめに 2年前のAdvent Calendarで、GAE/Goのハマったところ(´･ω･`)という記事を書きました。 当時betaだったGAE/Goもその後めでたく正式リリースされ、最近では徐々に大きな会社や案件での採用事例も聞こえるようになってきました。数年前の状況を考えると涙がちょちょぎれる程感慨深いです(ToT) 2年前の記事ではGAEのGo SDKに特化したハマりポイントを紹介しましたが、今回はGAE(Google App Engine)自体のハマりポイントを書こうと思います。最近GAEを使い始めた人も多いかと思いますので参考になれば幸いです。 注：GAE runtime共通の話題を取り上げますが、コード例はGAE/Goで書きます Datastore Index爆発でハマった(´･ω･`) GAE Datastoreではカスタムインデックスを作ることで、通常では行えない条件の検索

前置き Goのプロジェクトも大きくなってくると、go testに時間がかかってくる様になりますよね〜 私の愛してやまないGAE/Goの場合は特に、テストケースの度にpythonのローカルサーバープロセスが起動する為、バカにならない時間がかかります。 そこで金の弾丸に物を言わせて、Google Container Engine(GKE)でcoreたくさんぶん回してテストを並列実行してみたらどうだろうか、と思い立ち、実験してみました。 GKEのセットアップは↓をほぼそのまま参考にさせてもらいました。とても簡単にできました＼(^o^)／ GKE を使って golang アプリケーションコンテナを稼働させる ※ 今回はGKEから外向きにポートは開かないので、Serviceの設定は不要です 概要 用意した資材はこちら。 https://github.com/knightso/honeybee とりあ

2016/7/1からCloud Datastore(GAEのDatastore)の課金体系が変わりました。 従来はオペレーション単位で課金されていて、例えば1エンティティ書き込んだとしてもsingle property indexやcustom indexの書き込みも同時に課金されていましたが、新体系ではエンティティ単位での課金になると言います。 これが本当ならばセコセコとプロパティにnoindexつけて課金を節約する、というバッドノウハウは不要になる！素晴らしい！1 ＼(^o^)／ 詳細は下記URLを参照。 英語版のみ「New Cloud Datastore Pricing Starting July 1st, 2016」というところに書かれています。日本語版は未だ古い情報のみ。GCPはドキュメント翻訳がいつも遅いですよね・・・ (´･ω･`) 引用: 従来writeオペレーションは$0

merry Xmas! Advent Calendar 2015も最終日になりました。 ずっとApp Engineばかりだった私ですが今年はついにCompute Engineにデビューしました！ ＼(^o^)／ Compute Engineのpreemptibleインスタンスを数百台instance groupで構成して自動スケールさせています。 各サーバーはTask Queueを監視して動く様になっているので、Queueの滞留サイズ監視して閾値を超えたらslackにアラート飛ばしたいなー、と思ってチャレンジしました。 Google Cloud MonitoringそのものについてはGCP Advent Calendarで他の方が既に記事を書かれてましたのでここでは割愛しますm(_ _)m http://qiita.com/FumihikoSHIROYAMA/items/6846630b4

最近Goがすっかりメジャーになってきて自分の書けるネタもなくなってきたので今年もやっぱりGAE/Goのハナシです。 GAE(Google App Engine)もGoに負けずもっと盛り上がって欲しいですね(^^; 前置き さて、今回のテーマですが・・ GAE/Goでもgoroutine使おうよ！ てハナシです。 GAEの環境は残念ながらGOMAXPROCSが1になっている為1「goroutineを使っても意味がない」と考えている方もいらっしゃるかと思います。 実はうまく使えばとても強力なのです！ どういうことかというと、あるgoroutineがAPI呼び出しなどでI/O待ちに入ると、他のgoroutineにスケジュールされます。 つまり、複数のAPI呼び出しをgoroutineを使うことで実質並列化することが可能なのです。 GAEは基本的にたくさんの用意されているサービス（Datastor

こんにちは。今日はクリスマスですね(^^) 日本人プログラマにとっては忙しい時期だと思いますが・・・(^^; 注：本記事は都合により最新ではないAngularJS 1.2系をベースとしています。おそらく1.3系でも同様に動作すると思うのですが、未確認です。ごめんなさいm(_ _)m こんな問題ないですか？ 製品がほぼ完成した後に顧客から「これじゃない」と言われる 外部設計書やhtmlモックで確認して貰っていたにも関わらず、クライアント側、サーバー側実装完了した段階で顧客に触ってもらったら「この動きは想定していたのと違う」と言われたり。 イテレーションを短くすればある程度手戻りは防げますが、それでももう少し早い段階でちゃんと確認して欲しいと思う事もあります。 で、プロトタイピング クライアント側をhtml+jsでリッチにしてサーバー側とのやりとりをRESTなどのAPIベースに作ることで、サー

以前からconcrete5というPHPのCMSでクライアントのWEBサイトをいくつか運用してました。 そろそろサーバーも寿命でお引っ越しが必要なんだけどせっかくなのでGoogle App Engine(GAE)/php&Google Cloud SQLで動かしちゃおうか！！ って流れでちょっと頑張ってみたのですが、あっさり玉砕しました。(´･ω･`) Cloud SQLの接続は順調に行ったのですが、ファイルアクセス周りをGCS使う様に修正するのがかなりしんどかったです。。 てなわけで、GAE/Goで一からCMS作っちゃうことにしました！！＼(^o^)／ GAEで作るメリット GAEはCMSに以下の点でとても向いています。 データ構造がシンプルなのでDatastore（KVS）と相性がよい ハードの寿命とか気にする必要がない オートスケールするからある日突然ヤフトピに載っても大丈夫！ edg

2016.12 追記: 本記事はGAEのGo SDKに特化した内容です。 GAE全般については↓に記事を書きました。 GAEでハマったこと(´･ω･`) 2014年は半年くらいGoogle App Engine(GAE)/Goのアプリを書く事に費やすことが出来て、とても幸せな一年でした(^^) GAE/Goはご存知の通りずっとbeta(or experimental) (2015/7に正式リリースされました！＼(^o^)／)ですが、個人的にはGAEランタイムの中で最強だと思っています。 何よりspin-upが早い！リクエストの処理もgoroutineでシンプルに高速化出来る！GAEアプリ書くならGoを選ばない理由はない！と思っています。 とは言え書籍や情報の少ないGAE/Goの開発、少なからずハマった箇所もありましたのでそれを技術不足露呈も覚悟の上で共有したいと思います。 あ、GAEに興味

今日は13日の金曜日！ ということでせっかくなのでJSONネタで The Gopher character is based on the Go mascot designed by Renée French. encoding/json GoにはJSONを扱う標準パッケージが含まれています。 encoding/json 3rd partyのJSONライブラリでも探してきて試そうかとも思ったのですがそれ以前に標準パッケージを全然把握していない自分に気付いたので、そちらを試すことにしました。 エンコード 手っ取り早くエンコードするにはMarshal関数を使います。インデント整形したい場合はMarshalIndentを使います。 structのエンコード structをJSONオブジェクトにエンコードします。 package main import ( "encoding/json" "log