Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
def superCalculate(): Int = 42 def hyperCalculate(i: Int): Int = i * i def formatCutely(i: Int): String = "♡♡♡♡♡ " + i + " ♡♡♡♡♡" Some(formatCutely(hyperCalculate(superCalculate()))) ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑ ここが非常にわかりづらい。どういう意味でわかりづらいかというと処理順番と表記順番が逆である点だ。 処理順番は superCalculate hyperCalculate formatCutely Some であるにも関わらず、コードを読むときは Some formatCutely hyperCalculate superCal
昔書いた記事だけど、闇のデータベースが相手なのでアドベントカレンダーにあげておきます。記事には書いてないけどakkaは使っているよ。 序 システム移行などで、先人が作った古臭いデータベースの中身を把握しなければならないことがある。 (私の場合は、かなり古いバージョンのpostgres) こうした場合、psqlなどのSQlコマンドラインツールを使って テーブル一覧を見たり、これは思うテーブルにクエリをかけたりすることになるだろう。 しかし、古臭いデータベースは時として手ごわい。 例えば、本番データとダミーデータとがテーブル上に混在していて、両者をトリッキーな方法で分離しなければならないことなどが次々と起こることがある。加えて、テーブル構造が分かっていないのに個人情報は全て匿名化してくれ、などというげんなりする要求が出てきたりもする。こうした時、SQLだけでは限界があり、やはりプログラム言語の
Laravel と組み合わせて、 GraphQL サーバーを本番運用しています。 Lighthouse というライブラリを使うと、手軽に構築することができました。そのときに溜めた知見です。 結論 Laravel + GraphQL は、 Laravel の柔軟性と GraphQL の堅牢性がいい感じにマッチしている Laravel で GraphQL やるなら、 Lighthouse 良い Schema をダンプしてチームでシェアするといい感じになる GraphQL を現実世界で使う GraphQL を使う動機としては、下記があると思います。 型安全な Web API を作りたい 入出力を明確にしたい フロントとサーバー間の仕様書を、動いているコードから明確に作りたい ただ、障壁となってくるのが 既存のサービスのロジックを使いまわしたい 徐々に移行したい。三ヶ月かかります、みたいなのはきつ
タイトルクソ長い。 8億番煎じ感はあるけどちょいちょい細かいところでハマッたりしたので同じ理由で時間を無駄にする人がもう出ないようにここに残す。 「画面のどこにそれがあるかわからんかった」って自分で躓いたもの以外は基本stringオンリー。 何をしたいんだ slackでコマンド打ち込むとgoogle calendar apiとキャッキャできる 構成 slackからpostされたらapigateway通してlambda関数動かす。 社内ツールだし、高い頻度で使うわけでもない。 が、使いたいときに動かなかったら困る。 => ec2を24365はもったいないからサーバレスでいこう!! AWS SAM 頑張ったけどだめだった。詳しくは後述。 googleCalendarAPIの有効化 これは色々なところで説明されてるので割愛。 自分の場合、Oauthがどうにもうまくいかなかったのでサービスアカウ
package main import ( "flag" "fmt" "github.com/golang/glog" "os" ) func DebugLog(v interface{}) { if os.Getenv("DEBUG") != "" { glog.InfoDepth(1, fmt.Sprintf("%#v", v)) } } func main() { flag.Set("stderrthreshold", "INFO") flag.Parse() os.Setenv("DEBUG", "1") DebugLog("hoge") // ここが20行目 DebugLog("fuga") // ここが21行目 }
GAE/Go SEで運用しているPJで、aetest.NewInstanceをキャッシュした結果50本くらいあるテスト実行時間が全体で5倍速くらいになったので共有します。 背景と概要 GoのWebサーバを立ち上げる時GAE/Goを選択する人は多いのではないでしょうか。 ただエンドポイントのテストを書こうとaetestを利用し始めると途端に問題が発生します。aetestを利用してテストを書くと、裏でPythonサーバを立ち上げるため1リクエストのテスト実行に2-3秒掛かり極めて遅いのです。 そこでaetest.NewInstanceのキャッシュ化に取り組み実行時間を改善することにしました。 singletonパターンでキャッシュを実装 Singleton Pattern in Go を読みながら実装してみました var instance *singleton var once sync.On
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く