なぜ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に変えるとか時代に逆行しすぎ！」
問い：Java 8のStream APIは業務でどんな時に使うの？ 答え：あなたがfor文使いたい時 - ブログなんだよもん
※ サンプルがJDK7までとJDK8までで意味が変わっていてわかりにくいという指摘があったので、少し直しました。 ※ boxedを使う書き方だと無駄なAutoboxingが走るとの指摘を頂きましたのでmapToObjを利用するように変えました。 Java8の目玉機能の一つにStream APIがあります。 目玉機能だけあって、先日のJava Day Tokyo 2014を含めて色んな所で発表やブログの記事が公開されているので、どんなものかを知ってる人は多いと思います。 Stream APIといえば「".parallel()"と書くだけで並列化してスピードアップ出来る！」という魅惑的なキーワードで紹介されることが多いので、並列化のための仕様だと勘違いされそうですが、そうではありません。 ※ もちろんそういった記事の中をちゃんと読めばそう単純な話じゃないことも分かります。 むしろ、並列化に関し
OAuth2.0のclient_secretって本当に秘密鍵ですか？ - ブログなんだよもん
OAuthをしているサービスをAndroid + PhoneGap経由で使いたくて調べて見ました。 そして、色々調べたり考えたりした結果、 client_secret ってそもそも秘密鍵にする必要なくね？ という天啓を得たので、つらつらと書いてみます。secretって名前なのに秘密である必要がないなんて、わけがわからないよ。 間違ってる気がしてならないので、誰か指摘をしてください。マジで。 とりあえず、前提として自分のサービスの認証替わりに使いたいわけじゃなくて、純粋にそのサービスを使うのが目的。OAuthなサービスはサーバサイドで使ったことは何度かあるんだけど、クライアントサイドで使うという事で、扱いが困るのがclient_secret。名前の通り、秘密鍵として扱う必要があると思ってたんだけど、正直安全にクライアント側で管理する方法が無い。 公開している通常のソースからは外してビルド時に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
