追われる開発と追う開発 - 邪道（旧）
2つの開発現場を見てみましょう。 ※この物語はフィクションです 開発現場A ビジネスチームが一生懸命アイデアを出して、それを開発チームに依頼する。依頼を受けた開発チームは、要件を確認しながら開発計画を立て、数ヶ月にリリースをするスケジュールを組んで、開発を開始した。 ビジネスチームは、開発期間の間にいろんなことを想像し始める。 競合サービスを研究していると不安になり、「あれがないとダメ！」「これもないとダメ！」という気になって、最初の想定よりもプロダクトはどんどん太っていく。 こういう状況で追加されていく要望は当然ながら検証されていない想像＝妄想なので、実際にリリースしててもユーザーに使われるかどうかはわからない。 * なぜあなたのチームの プロダクトは太ってしまうのか #postudy // Speaker Deckより 当然ながら開発チームは当初想定していたよりもやることがどんどん増え
深層学習 を 用いた 異常値検知 手法まとめ 〜 (Denosing) AutoEncoder, LSTM, TDA（Topological Data Analysis) + CNN - Qiita
オーソドックス な アプローチ（一般的手法） まず は、以下 が よくまとまっている。 株式会社クロスコンパス・インテリジェンス（2016.10.5）「NVIDIA GPU TECHNOLOGY CONFERENCE JAPAN 2016 Industry Deep Learning」 異常値予測 を 行う アプローチ としては、以下 が 一般的な考え方 の ようだ。 （データ量の多い）正常時のデータ挙動の特徴パターンを学ばせて、 新規データが上記の特徴パターンから乖離している場合を、異常とみなす 上記のアプローチをとる理由 は、「異常発生時のデータ」の取得可能件数 は、「正常時のデータ」 に 比べて、取得できるデータの件数 が 圧倒的に少ない から である。 上記のスライド で 挙げられている AutoEncoderモデル や LSTMモデル を 採用し、 AutoEncoderモデル
現場で役立つシステム設計の原則で個人的に面白かったところメモ - Qiita
『現場で役立つシステム設計の原則』という本を付箋を付けながら一通り読んだ?ので 個人的に面白かったところを自分用にメモしておきます。 本当にメモです。 本質とはだいぶ違うところだと思うので買って読んで下さい。。 (付箋はつけていたけどうまく説明できなさそうなところは消しました。) 目的ごとに変数を用意する 段落わけと、目的ごとの変数で分かりやすい。 一度作った変数を変更するのを破壊的代入といい、それをなくすことでコードが安定するそうです。 int basePrice = quantity * unitPrice int shippingCost = 0 if (basePrice < 3000) { shippingCost = 500 } int itemPrice = ... コレクション型を扱うロジックを専用クラスに閉じ込める これをコレクションオブジェクトやファーストクラスコレクシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
