pmjp オフ会 #3 で伝言を伝えてきました。
![及川卓也からの伝言 「PMの心得3条」](https://cdn-ak-scissors.b.st-hatena.com/image/square/3dc29a93f1ead83072c5a538308daff7066f0001/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fdeb337713881481fbe2349e8618187b3%2Fslide_0.jpg%3F6096899)
CrowdWorks Advent Calendar の9日目に入るはずだったポストです。元々は、問題提起とその解決篇をセットにしてご紹介するつもりだったのですが、話が壮大になりすぎて僕の文章力ではまとめきれずに挫折した挙句に〆切に間に合わなくなってしまいました リベンジとして、問題提起の部分だけをピックアップしてご紹介する形にします。解決篇はバッサリ省略。どこか別のポストで紹介できればと思います。アドベントカレンダー的には数日遅れで申し訳ないですが、何かのご参考になれば。 結論 先に結論から書きます。 データ集計で ActiveRecord は忘れろ 用途に合った適切なツールを使おう 前提 ここで言う「データ集計」というのは、だいたいこんな感じのモノを指しています。 サービスのデータベース (RDB) に蓄積された情報を取り出してきて 日次や月次の数字を表とかグラフの形式で見えるようにし
AWS Lambdaのアップデートにより、本記事のワークアラウンドを用いなくても、 rate(1 minute) とすることで、1 分間隔を指定できるようになっています。(2015年4月25日現在)。 Announcement: Scheduled Events now support 1-minute granularity はじめに re:invent 2015でLambdaにスケジュール化されたファンクション(Cron)機能が追加されました。 スケジュールの指定は rate(5 minutes) のように間隔を指定する方法と cron(*/5 * * * ? *) の用にcron形式で指定する方法があります。 Walkthrough 5: Using Lambda Functions to Process Scheduled Events (Python) ただし、スケジュールの最短
コードレビューで土日に安寧を ソーシャルゲームは、ユーザアクセス集中と、それに伴うユーザデータ増加によって劇的に負荷が上がり、(主に土日に)サービスに影響を与えがちです。 問題があるコードは、たとえ負荷テストを行っても、作成したシナリオによっては見つけられない可能性もあります。 そういった見えない不安を払拭するという意味でも、コードレビューは重要だと思っています。 【ステキポイント】 ・ ソースを見ることにより、時限爆弾が土日に爆発するのを解除 ・ スキル共有によってメンバーがレベルアップすることにより、土日に爆発する時限爆弾の設置確率低下 まぁまとめると これに尽きます(4歳の息子談) 今は、gitのプルリクエストという強力なレビューツールもあり、敷居がかなり低くなったのでオススメです! チェックするポイントは5つ コードレビューを行うにあたり、「どんなところをチェックすればいいのか分か
こんにちは、株式会社GunosyにてCTOをしております松本です。 弊社にもこの4月から初めての正式な新卒採用で3名の方が入社しました。 実は自分も、3年ほどまえの大学4年の終わりごろにGunosyに入社しまして、そういう意味では新卒入社とも言えるのかなと思います。 社会人経験としては新卒の皆さんとそう大きく違うわけではないのであまり偉そうなことが言えるわけでもないのですが、自分が新卒の時にどんなことを聞いておきたかったかなと考えながら、主に今年新卒入社された皆さんになにかアドバイスになればと思い久々に技術の話以外でブログを書いています。 今回、3年間働く中で長くエンジニアとして必要とされるために大事だと感じたことについて書きます。 # 長くエンジニアとして活躍していくために自分がエンジニアを始めてからの数年の間にもベースになる技術は多くの進化を遂げており、1年前の状況が今では古いなどと言
Scala勉強会第170回 in 本郷 rpscala.doorkeeper.jp は、サブテーマ「Scalaの言語仕様」であったため、久々に熱弁をふるったところ、特に、メソッドや関数の仕様や区別に関して疑問に思った方が多かったらしく、質問も多かったので、Q&A形式でまとめておきます。 Q: (x1, xN) => body 形式と、{ case pat1 => body1; ... case patN => bodyN }形式の違いは何でしょうか? A: 前者は必ずFunctionN[S1,...,SN,R]型を持つのに対して、後者は期待型(expected type)によって型が異なります: 1: FunctionN[S1,...,SN,R]: この場合、 (x1:S1,...,xN:SN) => (x1,...,xN) match { case pat1 => body1 case
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く