考察など正味の話、Lambdaで行っている処理などほとんどないので、性能的には大差ないかと思っていたのですが、思ったより特性が出ました。これは処理時間というよりは、関連ライブラリのロード時間な気がしますね。Javaは最初の数回が20秒、実装を改善しても7秒とかなり遅かったのですが、ウォーミングアップが終わった後は200msぐらいまで早くなりました。呼ばれる頻度が高い処理であれば良いのでしょうけど、たまに呼ばれるような処理では、この特性はネックになる気がします。ちなみにJavaだけは192MBで計測しましたが、最初にメモリ128MBで試したところ、30秒ぐらいで処理が強制的に中断されたり、60秒でタイムアウトするなど、計測になりませんでした。いう所を見ても、Javaを使う時にはメモリを多め(CPU性能はメモリと比例して向上)にしなくてはいけない感じでした。Node.jsも少しはウォーミングアップで性能が変わりますが、最初から性能は良い感じです。Goを使った場合は性能が安定しており、ウォーミングアップしても性能が変わりません。メモリ使用量が少ないのも良いですね。Node.jsから呼び出す際のオーバーヘッドがあるせいか、性能的にはウォーミングアップ後のJavaやNode.jsに一歩劣る感じでした。Pythonの実装をしてくれる人がいらっしゃれば、プルリクしていただければ、データを追加したいと思います。繰り返しになりますが、雑なベンチマークなので特性の一部しか掴んでないと思います。そもそもJavaだけメモリが1.5倍になっている(=CPU性能も1.5倍になっている)ので公平ではないですし。「たまに行う処理」を「少ないリソース」で行うという観点では、Goで実装するのが良さそうです。GoはそのうちLambdaでも正式サポートされそうですしね。したベンチマークは、また別の機会にじっくり行ってみたいと思います。2014-12-15■[SpringBoot][SqlTemplate]SqlTemplateっていうJdbcTemplateのラッパーを作ってみました。Bootと組み合わせて簡単に使える、JdbcTemplateのラッパーライブラリを勢いで作ってみました。GitHubに置いています。APIが今風であることの4つを目的にして作りました。いう想いは消えませんが、Spring標準機能のみを使うことによる、政治的な使いやすさを取りました。作りましたって言っても、ただのラッパーですのでソースコードはすっごく小さくて、空行とコメントを入れても600行ぐらいしかありません。ジェバンニでなくとも一晩でやってくれるぐらいのサイズです。利用イメージexampleのプロジェクトも作っておきました。https://github.com/cero-t/sqltemplate/tree/master/sqltemplate-example使う側のソースコードは、こんな感じになります。第三引数以降がSQLにバインドするパラメータです。クリックでSQLファイルを開けるのが嬉しいですね。SQLファイルは、こんな感じになります。:job第三引数に指定したMapやEntityの値を、SQLのパラメータとしてバインドします。内部的にはNamedParameterJdbcTemplateに処理を委譲しているだけです。?第三引数以降に指定した任意の数の基本型(String、Date、Number)をバインドします。こちらは内部的にJdbcTemplateに委譲しているだけです。使うための設定は一つだけ。@ConfigurationアノテーションをつけたクラスにSqlTemplateを返すメソッドを作り、@Beanアノテーションをつけます。pullリクエストで教えてくれました。ありがとう!ちなみにSqlTemplateのコンストラクタの第三引数には、SQLファイルを読み込む際のテンプレートエンジンを指定することができます。SQLにも対応できるというスンポーです。一度も動作確認してないので、動くかどうか分かりません。用意したメソッドの一覧は、以下になります。args)戻り値をMapにする「forMap」とか実案件では欠かせない「batchUpdate」は、まだ作っていません。委譲するだけなので、作っちゃえばいいんですけどね。制限事項的なやつとりあえずコンセプト実証した程度なので、色々できません。上に書いた通り、forMapとbatchUpdateがありません。JSR-310を使っているので、Java8でしか動きません。publicフィールドのないgetter/setterベースのJavaBeansは使えません。パッケージ名が変です。mvnリポジトリに置いてないです。README.mdちゃんと書け。」っていう位置づけです。Calendarの5日目です。Calendarについては、以下のサイトをご覧ください。Service」http://www.akirakoyasu.net/2011/12/04/easily-use-aws-through-sdk/S3、SimpleDB、SESの使い方をサンプルコードつきで紹介しています。セカイ」http://d.hatena.ne.jp/shuji_w6e/20111205/1323098690同じ事前条件(前準備)のテストケースを内部クラスとしてまとめる方法が目ウロコでした。文字コードの話に入りましょう。今回は特別編として、Javaの開発案件で特に頻発する問題や陥りやすい問題についてフォーカスして、お送りします。新人くん(だって先輩、やれって言わなかったじゃないですか・・・)先輩社員「え、何か言った?」いきなり気まずい雰囲気から始まった「いいから俺文字コード」ですが(しつこい)この問題が起きる原因は、十中八九、デフォルトエンコーディングの違いによるものでしょう。結果的に、開発環境と結合試験環境で生成されるファイルのエンコードが変わってしまうという現象が発生しうるのです。「デフォルトエンコーディングを使わない」ことをルールづけたほうが安全です。デフォルトエンコーディングを利用するクラスやメソッドとしては以下のものが、よく使われています。開発環境と結合試験や本番環境で、結果が異なるということがなくなるでしょう。ちなみに私は、Checkstyleの正規表現チェック機能を使ってエンコーディングの指定漏れを検出しています。先輩社員「あぁ、よく化けるよ」キング・オブ・文字化けと言えば、この、チルダ(ニョロ)でしょう。「〜」と「〜」\uFF5Eと、\u301CWindowsでは「綺麗なニョロ」と「汚いニョロ」と呼べば何となく伝わりますが、Macだと同じ形に見えるので、より発見が困難ですね。記号の扱いが異なっています。問題のニョロについて言うと、Windowsで普通に入力できる「〜」(\uFF5E)は「Windows-31j」の文字であり、Macで普通に入力できる「〜」(\u301C)は「Shift_JIS」の範囲にある文字なのです。「問題1」の最後に示したクラスやメソッドの引数に「Shift_JIS」を指定しているWindowsでよく入力する方の「〜」(\uFF5E)を扱うことができず、ただの「?」、半角クエスチョンに文字化けしてしまうのです。対策としては、システム全体として、エンコーディングをUTF-8に統一するのがオススメです。基本的には「Windowsを優遇」しましょう。JavaのソースコードやJSPファイルなどを検索して「Shift-JIS」となっている箇所を「Windows-31j」に置換していけば、きっとそれで問題は解決するでしょう。IEがWindows-31jという文字列を認識できない、という問題があるためHTMLのMETAタグに指定するcharsetだけは、「Shift_JIS」のままにしておいてください。Windows-31j」で検索してくださいね。私自身、いくつかの案件で「Windows-31jで扱える範囲内の文字列だけを許容したい」という仕様を要望されたことがあります。この要件は「JIS第四水準の漢字」や「サロゲートペア」などの機種によっては対応していない文字の入力を防ぐことが目的なのです。イマドキのMacやケータイでも見えるから問題ない、という判断です。この要件自体の是非はさておき、このチェック処理のために以下のようなコードが使われることがあります。実際は上位バイトと下位バイトのチェックをするので、もう少し違うコードになる。除外文字を検出することができず、常にtrueを返し続けます。変換されてしまうのです。「これはWindows-31jの文字だ」と誤判定されてしまうのです。チェックするのが良いのか?私は以下の処理でチェックすることをオススメしています。encoding));詳細については、過去のエントリを参照してください。「変換して、さらに逆変換した文字列が、元の文字列と一致するかどうか」というチェックするのが王道だと、私は考えています。失敬な!さておき、Webアプリ開発においては、もう一つ追加で気をつけなければいけない事があります。それが、文字の「数値文字参照」です。入力ボックスに「euc-jp」の範囲外の文字を入力してsubmitした場合、Webブラウザは、その文字を「数値文字参照」という形式に変換することがあります。「❶」を「&#10102;」という文字列変換して送信してくるのです。「問題3」に書いたチェック処理ではtrueを返してしまい、通ってしまうわけですね。文字への変換を行なう必要があります。サンプルコードは長くなるので割愛します。java」で検索してください。問題5:サロゲートペア対策が必要だと、上の方から言われました。以降の章を楽しむために、このパッチを導入することをオススメします。Vistaが出てくる頃に話題になり、その後は誰も触れなくなってしまった用語、サロゲートペア。「サロゲートペアとは一体何だったのか」というスレとか、立ってそうですよね。サロゲートペアの詳細な話は割愛しますが、Javaにおいては「char2つで、1つの文字を表現する」文字だと考えれば良いでしょう。サンプルコードで見てみましょう。"";System.out.println(str.length());System.out.println(str.toCharArray().length);このコードを実行すると22と表示されるのが、サロゲートペアなのです。多くの場合が「禁止してください」という意味でした。禁止するだけなら、Character#isXxxSurrogateメソッドを使うと簡単です。false;このコードでtrueが返ればサロゲートペアを含んでいるためエラーとし、falseが返れば問題なしと判定してやれば良いのです。問題6:サロゲートペアを許容しろと、上の方から言われました。新人くん(そんな事言うなら、打ち合わせにちゃんと参加してくださいよ)先輩社員「え、何か言った?」さて、最後の問題は、サロゲートペアを許容する場合の話です。人間の目から見れば、どう見ても「1文字」です。サロゲートペアを許容するためには、この差異をなくす必要があります。「最大100文字」まで許容する入力ボックスに、サロゲートペアを51文字入力した場合、Javaとしては「102文字」として扱ってしまい、文字数オーバーとなりますが人間の目には「100文字に到達していないのにエラーになった」ように見えるのです。実際には、こんなことをする人がいないため、サロゲートペアはあまり問題になっていないのでしょう。「バリデーション処理を適切にすること」にあると、私は考えています。見た目の文字数を取得するためには、String#codePointCountメソッドを利用します。str.length()));この処理を実行すると85と表示されます。この「5」が見た目と一致しますね。これまで長さのバリデーションを行なう際にはString#lengthメソッドを利用してきたと思いますが、サロゲートペアに対応するためにはString#codePointCountメソッドを利用して判定を行なう必要があるのです。周辺のミドルウェアがサロゲートペアに対応しているかどうかも必ず確認すべきでしょうね。まとめこの連載は「いいから俺文字コード」シリーズって言うらしい。冷や汗かいてるだろ、そこのお前。お前のことだよ!サロゲートペアなんて危険なもの、禁止にしてしまえ!サロゲートペアに対応するなら、バリデーションでcodePointCountを使うのが肝だ!この連載は「いいから俺文字コード」シリーズって言うらしい。大事なことは、2回言いました。2009-03-15■[Java]考えなしに肥大化する定数クラス。定数クラスというものを見かける。finalなフィールドをたくさん持つクラス。値を利用するクラスで、implementsするという手法も見かける。見た時には、便利な手法だと思ったけど、その後、ひどい定数クラスを目にすることが少なくなかった。定数クラスは、疎結合の考え方と全く合わないと僕は思う。具体的に、悪い例を見ながら話していく。大体の定数クラスというものには、こんな定数が定義されている。環境の定数や、ウィンドウのサイズ、ファイル名、形状のオプション、ログコード、まさにごった煮だが、定数クラスは、得てしてこんな風に肥大化してしまいやすい。この肥大化が、最初の間違い。上の例だと「定数を定義するクラス」っていう曖昧な言葉でしか説明できない。定数の種類ごとにクラスを分けるなどすることが必要だ。環境の定数ならEnvironmentクラス、ログコードならLogCodeクラス、という風に。定数クラスを作ってしまうと、その配下の多くのクラスは、定数クラスに依存する。機能分割ができそうなのに、定数クラスに依存してしまうせいで、JARを分けられないこともある。機能や目的ごとに定数クラスを分割しておくべきだ。"APP001"」みたいに定義するのは最悪だ。なるが、何をロギングするのか全く分からない。意味が推測できるものにした方が良い。大体は、ClassA自身の定数にしておいが方が、疎結合になって使いやすい。「定数クラスとしてまとまっていた方が分かりやすい」っていう意見もあるけど、だからといって全てをまとめるのは、設計を放棄していることに他ならない。変更の頻度、変更のライフサイクル(稼動中か再起動時か)、変更する人は誰か、をしっかり考えてから、設定ファイルか定数クラスか、各クラスに定義するかをよく考えるべきだと思う。Table(shell,SWT.MULTI|SWT.FULL_SELECTION|SWT.BORDER);こんな風に書いたりする。これはこれで便利だと思ったんだけど、どのオプションが有効なのか分からず、そこで手が止まる。某商用プロダクトでは、こんなオプションが数百個あって、どれが実際に使えるのかを理解するために、随分と時間を掛けてしまった。対策としては、Java5以降ならEnumと可変長引数を利用した方が良い。要するに、コンストラクタの定義を、↓のようにする。コンストラクタの処理}ここでTableOptionsとは、Tableのオプションを示すEnum。しておけば、開発環境の自動補完だけでサクサクと開発ができる。Enumはそのためにあるんだから、当たり前か。Java1.4以前ならどうするか。クラスに対応した定数クラスを作るべきだと思う。コンストラクタの処理}引数にはSWTという定数クラスを使わせるんじゃなくて、Tableクラスの定数か、TableOptionsクラスの定数を使わせる。することで、少なくとも利用できるオプションが明確になる。コンストラクタの処理}けど、さすがにこれはちょっとヤリスギだと思うし、やったことはない。最後に、定数クラスをinterfaceにするのは、やめて欲しい。finalで意味は十分に通じるし、インスタンスを作られたくないなら、privateコンストラクタを書けば良い。余計な混乱を生むし、若手に対する教育としても決して良いものではないと思う。書いてきたけど、要するに、僕は定数クラスが嫌いだってこと。定数クラスを見かけたら、何とかして削除できないかを考えるようにしている。ガジェット好きのWeb系エンジニア。最近はWebサービスとトラブルシューティングツールに興味あり。ラスベガスに来ました。Javaは、なぜ1回目と3回目の処理が重いのか?[Lambda]続けて、JavaとNode.jsとGoで外部ライブラリを使わないベンチマークをしてみた。LambdaでJavaとNode.jsとGoの簡易ベンチマークをしてみた。@cero_tカテゴリーSeasar2S2JSFS2DaoS2StrutsS2JFaceTeedaS2PresentationS2JDBCWebPartsJavaScriptPC携帯diaryEclipseTechTracOracleGDD07JPSilverlightS2SilverlightStrutsderbyIrenkaSAStrutsVideoMayaaJavaOneJavaOpenSolarisVisualVMBTraceNetBeansRedmineJGraphJFreeChartVirtualBoxUbuntuDevKan2009関ジャバJavaレビューiPadAndroidKotlinMoneySpringBootSqlTemplateMOAPresentationAWSElasticsearchJMXLambdaSpringOneページビュー2227308。