Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基本的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ
クラスの命名のアンチパターン - Qiita
昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParameter FooResult, FooStatistics, FooSummary FooBuffer, FooList, FooCollection, ... ProductListItem, TranslationTableEntry, etc. Prod
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
PofEAA's Wiki - (ファウラー | 読書会)
PofEAAのWikiです。Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、 パターンカタログの翻訳を行っています。bliki_jaと同じくどなたでも参加可能ですので、是非参加してみてください ;-) ※このサイトは書籍の邦訳とは一切関係ありません。 ■ PofEAAのパターンカタログ and PofEAAのパターンカタログ(邦訳版)ここから読み始めるとよいでしょう。対応表もあります。 ■ 読書会 第12回の開催予定は未定です。 ■ PofEAA読書会メーリングリスト読書会に関する話題を扱っていますが、読者会への参加を強制するものではありません。興味のある方の参加は随時受け付けています。
綺麗な設計を身に付けるためのSandi Metzルール
Webアプリやモバイルアプリの受託開発やコンサルティングを行うthoughtbot社のブログにて、Sandi MetzルールというRubyプログラマ向けのルールが紹介されていました。 Sandi Metz’ rules for developers このルールは、プログラマーでありPractical Object-Oriented Design in Rubyという書籍も執筆しているSandi MetzさんがRuby Roguesポッドキャストに出演した際に紹介していたものです。 そのルールは以下の通りです。 クラス内のコードが100行を超えてはならない メソッド内のコードが5行を超えてはならない 4つより多い引数をメソッドに渡すようにしてはならない（ハッシュによるオプションもパラメーターとみなす） コントローラーではただ1つのオブジェクトだけをインスタンス変数化できる ビューは1つのイン
Rails、あんたなんか嫌いよ - Rails での OO 設計について - tomykaira makes love with codes
2013-06-25 Rails、あんたなんか嫌いよ - Rails での OO 設計について ruby rails 最近はずっと Rails 書いてるんですが、書けば書くほど嫌いになってくるんです。 倦怠期的なやつなんですが、 Rails さんの悪いところばっかり見えてきて、もう一緒にいたくないんです。 でも別れるほどじゃないし… という愚痴にみせかけた Rails での設計についての議論です。 長いけどコードは一切出てこないので通勤中にでもよんでください。 注意 一部にはげしい言葉遣いがでてくるので、読んで不快になるかもしれません。 不快になったとしても責任は負いかねます。 次のような方の期待に沿う結論はでません。残念でした。 Sinatra, Padrino の人 関数型の人 静的型付けの人 C の人 TL;DR Rails にだまされない。 自分の道を見定める。 欺瞞にみちた Ra
API設計に関する10のワーストプラクティス
過半数の開発者が平均で3つ以上のAPIのインテグレーションを実装していると言われている昨今、「使い辛い設計のAPI」を実装するのは開発者にとっては頭の痛い問題ではないでしょうか？ Programable Web上に投稿されたAPIのワーストプラクティスに関する記事が国内外の開発者の目に止まったようです。この記事によると悪いAPIに見られるプラクティスは下記のようなものだそうです。 貧弱なエラーハンドリング HTTPのルールを無視したREST API 裏に潜んだ生のデータモデルの露出 セキュリティの複雑さ ドキュメント化されていない予期せぬリリース 貧弱なデベロッパエクスペリエンス MVCフレームワークが良いAPIにしてくれるという思い込み 開発すれば使ってもらえると見なすこと 不十分なサポート 貧弱なドキュメンテーション APIを利用するだけでなく、APIを提供する場合に上記のようなポイン
NoSQLデータモデリング技法
NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文：NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック
AddinBox(祝日マクロ-1)
自由に各自のマクロに組み込んで利用して下さい。なお、フリー/シェアソフト 開発での利用も可（フリー/シェアでの利用の場合、事後で結構ですので一言 お知らせください）です。ただし、引用に当たっては、マクロの先頭に記述してある コメント（CopyRight ）を必ず一緒に引用する事 を条件とします。 なお、 他サイト上で本マクロを直接引用(マクロ全体を丸々貼り付ける等) する事は、ご遠慮願います。本ページへのリンクによる紹介で対応して下さい。 [ktHolidayName]という関数名そのものは、各自の環境における命名規則に沿って 変更しても構いません。 ＶＢＡ（ＶＢ含む）で利用する場合はマクロのコード構成を一切変更しないでください。 ＶＢＡというレスポンス的に不利な言語でも出来る限りレスポンスを良くする事を前提に 設計してある為､コード内容を変更するとレスポンスが低下
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版
Build seven good object-oriented habits in PHP