Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基本的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ
初めての個人WEBサービスを作り始める前にやるべき設計
少し前の記事(「プログラミング未経験者がWEBエンジニアになるためにやるべきこと」)の元になったプログラミング初心者の二人が、それぞれ無事Railsのチュートリアルまで終わらせていざ自分のサービスを作りたい！ってなった時に、さて何から手をつけたらいいんやろう？という同じ悩みにぶつかって同じようなアドバイスをしてたので、またその内容をまとめてみました。 初心者に限らず、小規模WEBアプリを作る時にこういうことをしとくといいかなっていう個人的な手法みたいなのをざっくり書いていきます。 SPONSERD LINK 前提 一般的なシステム開発は下記のフローで進んでいきます。 要件定義 設計 開発 テスト リリース ウォーターフォールはこれを1回流して完成、アジャイルはこれを小さく切ってぐるぐる回すというイメージですが、「初めての個人アプリを最初にリリースするまで」という状況では、一番困るのは2の設
テストを書くか書かないかの判断の話
writing_unit_test.md ユニットテストでテストを書くか書かないかの判断の話 お題 メソッドの出力の結果が、true か false のどちらでも返ってくる可能性がある場合、assert 文を書く時は true の場合だけで良いのだろうか テストとは まず、基本の考えとしてなぜテストをするのか？というのがあります。 テストとは、エラーをみつけるつもりでプログラムを実行する過程である。(via ソフトウェアテストの技法 [Glenford J. Myers]) という言葉のとおり、最小の手間でプログラムのエラーを見つけ出そうとする試みがテストです。裏を返せば、エラーが見つかる可能性が低いのにすべてのことを試すのはテストではありません。 判断するときの論点 いくつかこれを判断するときの論点があります (Boolean に限らず、「そのテストは必要か？」と考えるときの観点ともいえ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
