Java 8 の DateTimeFormatter の曜日等のフォーマットについて - tokuhirom's blog
DateTimeFormatter を利用して曜日などのフォーマットを行おうとすると、実際どういうふうにフォーマットされるのかよくわからんということになる。 https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html をちらっと見ると、以下のように書いてあって、各シンボルが何を表すのかよくわからない。 Symbol Meaning Presentation Examples ------ ------- ------------ ------- G era text AD; Anno Domini; A u year year 2004; 04 y year-of-era year 2004; 04 D day-of-year number 189 M/L month-of-year n
Java 8 Date and Time API の実践的なチートシートできたよ~ - tokuhirom's blog
Java8 を使いこなそうとすると､やはり Date and Time API も使いこなす必要がでてくる｡ 我々 Perl 畑出身の人間からすると､Perl の世界では DateTime/Time::Piece というモジュールが一般的に日付の計算に使われており､iandeth.さんのブログエントリがチートシートとしてよく知られている｡このいつも見慣れたエントリの体裁で､一般的な日時の操作を実用的に教えてくれるエントリが欲しくて書いた｡ junit のテストケースとして書いてあるので､適当にコピペして QuickJUnit で動作確認するとよい(assertはしてないけど)｡ なにかあれば教えていただけるとありがたいです｡
LL から Java に移行した人がはまりがちなこと - tokuhirom's blog
こんにちは｡Java 初心者です｡ Java 初心者､得に LL から Java に来た人にありがちな問題について社内向けに書いたものをオープンアンドシェアさせていただきます｡ 前提として､我々は Java 8 でガンガン攻めているということをご承知おきください｡ また､自分がこの数ヶ月で｢うわー｡こうしとくべきだったのかー｣と気づいたやつをドヤ顔で語っているということにもご注意ください｡ 【追記】 対象は中規模 B2C の場合です(中規模というのは facebook より小さいという程度の意味です) 例外を握りつぶさないようにしよう Eclipse が生成する以下のようなコードをそのまま残しているケース｡ これは言うまでもなく良くないですね｡デバッグが困難になります｡ try { } catch (IOException e) { e.printStackTrace(); } Perl
js-xlsx で js で excel のファイルを生成する - tokuhirom's blog
Excel ファイルの生成、めんどくさいですよね。CSV の生成めんどくさいですよね。HTML を出力した上でさらにやるのはだるい、というわけで、HTML の DOM を解析して JS で XLSX 生成してダウンロードさせたらいいんじゃね?と思ってそういうのやれるやつ探したら、js-xlsx ってのがあった。 これをつかって、HTML のレポートから XLSX を生成するコードを書いた。なかなかうまく動く感じしてる。 http://tokuhirom.github.io/js-xlsx-demo/ td タグに class を指定すると数字カラムになる、みたいな感じになってるのがいいかんじです。 js-xlsx で生成したXLSXは、FileSaver.js で保存させてます。 デモで利用している JS は以下のようなものである。簡単でしょ。 "use strict"; var data
AngularJS を本気でつかうための tips - tokuhirom's blog
最近、管理画面で AngularJS をつかってみている。 そんな中で、いくつか工夫した点があるのでそれをシェアさせていただきます。 XHR のエラーを表示する XHR のエラーがおきた際のハンドリングをいちいち手でかくのは非効率。管理画面とか中の人しかつかわないので、エラーがおこった旨を随時報告するだけでよい。 そんなケースでは以下のようにする。 angular.module('myapp.exceptionHandler', []) .config(['$httpProvider', function ($httpProvider) { $httpProvider.interceptors.push(function($q, $log, $rootScope) { return { 'responseError': function(response) { $log.error(res
Web Application の validation はどのレイヤーでかけるべきか - tokuhirom's blog
数年前にも同じことかいた気がするけど、最近の状況にあわせてかいてみる。 途中で面倒になってきて説明が雑になっている点をご容赦ください。 言いたいことは「結局、昔はサーバサイドで懇切丁寧なエラーメッセージを出すためにModelではなくControllerでバリデーションに関する知識が必要だったけど 今はJavaScriptでやるから不要だよね１１１」ってことです。 この表題は、よく話題にあがるところなのだが、理想論としては Model, Controller, Client side のいずれにおいてもきっちりと validation を行うことがのぞましい。 しかし、実際にはなかなか面倒である。ということで、どこをはぶくかというと Controller における Validation であろう。 ユーザーに対する親切なメッセージは JS の側でだすのが理想的。model の validat
O/R Mapper におけるページャーの実装について - tokuhirom's blog
欠点$rs->pager(); のように、クエリをうっているっぽくないのに裏でうってるので、重い処理なのにおもそうにみえなくてさがすのが面倒。お気軽につかえすぎて危険。 HAVING などをつかうクエリの場合、そもそもただしい値がとれてないのに、なんとなくうごいてしまう。まちがった値をかえす API を標準でつけるのはいかがなものか。 得に HAVING などの処理がうまくできないのは自明なので、こういう実装は僕は好きではないです。 → Teng にはついてない。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
