スピード感のために品質を落とすということはチームの成長を諦めるということ - ネットの海の片隅で
サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。 そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。 ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。 ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。 しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。 技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとして
Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基本的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
