なぜRDBからCSV + COBOLに変更する事でコスト削減と高速化を同時に実現出来たかの考察 - ブログなんだよもん
そもそも既存はどんなロジック？ RDBなんだからWhere句使ったら？ なぜファイルにすると速くなるのか？ 並列化と分散処理による高速化の可能性 COBOL使う必要あったの？ Javaとかじゃダメだったの？ まとめ TLを見てると以下の記事が少し話題になってました。 tech.nikkeibp.co.jp tech.nikkeibp.co.jp 対象の記事は有料会員じゃないと見れないのだけど事例としては以下みたい。 リソース - ユーザー事例 - COBOL製品 ユーザー事例 : マイクロフォーカス さて、この記事の驚きポイントは「１億レコードくらいのDB処理をRDBからCOBOL + CSVに変更してUnixサーバからWindowsサーバに変える事で性能を維持しつつコストを1/5くらいにした」という事でしょう。 「せっかく7割もあったSQLを全部COBOLに変えるとか時代に逆行しすぎ！」
ふつうのユニットテストのための７つのルール - ブログなんだよもん
最近、久しぶりにコードレビューをすることが増えたのですが、UnitTestのコードを見るとヒドイ部分が多く残念な気持ちになることもあります。 原因のひとつとして、プロダクトコードと違いテストの書き方をあまり書き方を明文化してなかったのが悪かったなと思い、とりあえず明文化してみました。 今回は、命名規則とかそのレベルまではいかず「ユニットテストかくあるべし」ってところまでをまとめます。正直、これ守ってくれたらあとは好みの世界もあるしね。 追記： テクニカルな部分も最低限ですがQiitaに記載しました。 qiita.com 追記： もうちょっと大上段の規約に関してもまとめてみました。 koduki.hatenablog.com 前提 ここではユニットテストを関数レベルのテストをJUnitのような自動テストツールで取り扱う場合に限定します。 また、Mavenでビルド時は常にテストを回すことを想定
Javaを使うメリットはありますか？ はい、それはもちろんあるに決まってます！ - ブログなんだよもん
/.Jに聞け：Javaを使うメリットは？ | スラッシュドット・ジャパン デベロッパー え、ありますよね？ Webアプリに限っても。 というか、上げてるデメリットが現代的じゃないなぁ... 個人的には少数精鋭チームを作れてないならJavaはかなり有りな選択だと思っています。 ※ Java使ってるメンバーがスキルが低いのではなく、LL系で高品質なものを作るのにスキルが必要で、例えスキルがあっても多人数開発にはあまり向かない、という意図 というわけで、自分が思うLL系言語ではなく、JavaでWebアプリを開発するメリットを書いてみます。 静的型づけ言語 HaskellとかOCamlとかScalaとか、その辺の超強力な型付け言語から見ると弱いですが、多くのLLと違い静的型付けな事が特徴です。 これは型というメタ情報を言語仕様に明確に取り込んでいるということです。以下のメリットがあります。 人間が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
