タグ

設計に関するishizawachihiroのブックマーク (3)

  • MacBook Proのメモリー・ストレージのBTO価格が高い理由

    松浦晋也 @ShinyaMatsuura アップルの新MacBook Pro、メモリーとストレージ容量を出し惜しむアップルの悪いクセがもろに出ちゃっている。BTOでメモリー8GB→16GBで2万円って、何の罰ゲームだ。SSDを2TBにすると12万円というのも、市価のほぼ2倍。ユーザーが交換不可能な設計でこれはひどい。 2016-10-28 08:06:32 (๑╹◡╹๑) @tsuchie88 別にAppleの肩を持つわけじゃないのだが、松浦さんまで原価厨みたいなこと言われるとちょっとがっくしくるな。部品を交換不可なロジックボードに載せてしまってる時点で、部品のコスト構造が大きく変わってしまうんだよ。交換可能なモジュールベースのコスト計算で比較はできない。 twitter.com/ShinyaMatsuura… 2016-10-29 17:29:19 (๑╹◡╹๑) @tsuchie88

    MacBook Proのメモリー・ストレージのBTO価格が高い理由
  • エラーメッセージは 2W1H がいいんじゃないか

    良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か

    エラーメッセージは 2W1H がいいんじゃないか
  • 多い日も安心設計 - Qiita

    アプリケーションエンジニアの多くは、眠れない夜を過ごしたことがあるでしょう。特に月に一度の…「月末締めバッチ」の日は。 そんなデータ量の多い日や、初モノのバッチが動く日でも安心して眠れるためのバッチ設計を考えてみます。 ログの設計 まず何はなくともログです。きちんとしたメッセージを出せていれば、専任の人がリカバリ可能にもなるってものです。 Audit用のログなど業務要件の強いものを除いては、だいたい3種類に分けるようにしています。 プログレスログ リカバリログ 例外ログ(調査のため) この分類でファイル単位も分けます。ログを必要とする人が、それぞれ異なるからです。 プログレスログ プログレスログは、特に長時間かかるバッチに対して、現在どのくらいまで処理が出来ているのかを目的として出力します。 トラブル発生時や、大規模移行作業時には、バッチの定期的なモニタリングと報告の必要が出てきます。「あ

    多い日も安心設計 - Qiita
  • 1