なぜ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に変えるとか時代に逆行しすぎ！」
Twitter製のScala向けConfigライブラリのutil-evalが素敵すぎる - ブログなんだよもん
現在作ってるアプリで設定ファイルを作りたくなったので、Scalaで人気の設定ファイルライブラリであるutil-evalを使ってみた。 このライブラリの特徴は何と言っても設定ファイルをScalaで記述できること。XMLやYAML, プロパティファイルじゃなくて内部DSLです。とは言うものの、Railsもrubyで設定を記述しているし、仕事ではPHP使って似たようなことはしているので、これだけだと絶賛するほどじゃなかったり。重要なのはScalaが静的型付け言語だと言うことです！（キリ それの何が嬉しいの？ と言われそうなので、皆さん想像してみてください。モード切替でマジックナンバーや文字列で指定している状況を。入力間違えにより容易に謎のエラーとなります。でも、util-evalならenumやcase classを使うことで特定の値以外が入力されたらコンパイルエラーにできます。もちろん、文字列や
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
