昔の JSON は Object か Array しかルートに書けなかったけど RFC 7159 では true/false/null/number/string を書けるようになってて便利だっておじいちゃんが言ってました。 https://tools.ietf.org/html/rfc4627 https://tools.ietf.org/html/rfc7159
最近 AngularJS 嫌いという言説が多いですが、そういうことを仰る方々は主に先鋭的な JSer のように思います。 ただ、僕なんかの場合には、ユーザー向けの画面の構築などには AngularJS を使って書くことは最近はほとんどなく、JS を書くといえばもっぱら管理画面です。 管理画面の JS を書くにあたっては AngularJS way にのっかってやると非常に楽ですよね。管理画面を書いたりする上では vue-js とかで頑張って書くと見通しが悪くなったりしますし、こった動きなどは必要ないというところで angular.js ワリといいなと思っています。 もっといいものがあれば移りたいですが、コストをかけずに作りやすい管理画面を作るという意味ではやはり AngularJS にまだメリットがあるなあ、と思っています。 2.0 が出た時にこまるというのもありますが、実際は angul
こんにちは。Java 初心者です。 Java 初心者、得に LL から Java に来た人にありがちな問題について社内向けに書いたものをオープンアンドシェアさせていただきます。 前提として、我々は Java 8 でガンガン攻めているということをご承知おきください。 また、自分がこの数ヶ月で「うわー。こうしとくべきだったのかー」と気づいたやつをドヤ顔で語っているということにもご注意ください。 【追記】 対象は中規模 B2C の場合です(中規模というのは facebook より小さいという程度の意味です) 例外を握りつぶさないようにしよう Eclipse が生成する以下のようなコードをそのまま残しているケース。 これは言うまでもなく良くないですね。デバッグが困難になります。 try { } catch (IOException e) { e.printStackTrace(); } Perl
数年前にも同じことかいた気がするけど、最近の状況にあわせてかいてみる。 途中で面倒になってきて説明が雑になっている点をご容赦ください。 言いたいことは「結局、昔はサーバサイドで懇切丁寧なエラーメッセージを出すためにModelではなくControllerでバリデーションに関する知識が必要だったけど 今はJavaScriptでやるから不要だよね111」ってことです。 この表題は、よく話題にあがるところなのだが、理想論としては Model, Controller, Client side のいずれにおいてもきっちりと validation を行うことがのぞましい。 しかし、実際にはなかなか面倒である。ということで、どこをはぶくかというと Controller における Validation であろう。 ユーザーに対する親切なメッセージは JS の側でだすのが理想的。model の validat
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く