Hibernate Validator 8.0.1.Final - Jakarta Bean Validation Reference Implementation: Reference Guide
Validating data is a common task that occurs throughout all application layers, from the presentation to the persistence layer. Often the same validation logic is implemented in each layer which is time consuming and error-prone. To avoid duplication of these validations, developers often bundle validation logic directly into the domain model, cluttering domain classes with validation code which i
JSR 349: Bean Validation 1.1でEL 3.0を使ってメッセージをカスタマイズしよう - コンピュータクワガタ
JSR 349: Bean Validation 1.1ではメッセージをEL 3.0を使ってカスタマイズできるようになりました。 今回は、文字列の長さチェックのValidatorをサンプルにEL 3.0を使うとこんなことができますよというのを紹介します。 まず、Bean ValidationをMavenで準備します。Bean Validation本体の他に、参照実装のhibernateのValidator、EL 3.0の実装も別途必要になります。 <dependency> <groupId>org.glassfish</groupId> <artifactId>javax.el</artifactId> <version>3.0.0</version> </dependency> <dependency> <groupId>javax.validation</groupId> <artif
JSR 303 Bean Validationで遊んでみるよ！ - Yamkazu's Blog
その名のとおりJavaBeansの為のValidationの仕様であるJSR303ですが、近頃でもないですがHibernateはもちろん、その他SpringやOvalなどの周辺フレームワークの対応が進んでずいぶん使いやすくなってきました。 ところでアプリケーション作っててValidationの仕組みって毎回悩みませんか？私がJavaでWebアプリケーションつくりはじめた頃なんかだとStruts1.xが全盛期でvalidation.xml、validation-rule.xmlとか使って書いてましたが(今考えれば二度とやりたくないですねｗ)、今でも毎回どのチェックをどのレイヤ(アプリケーションレイヤ？ドメインレイヤ？)に持たせるかとか、データストアに問い合わせしないといけないValidationって画面の入力だけでチェックできるのとどう管理しようかなとか、色々と悩むこともしばしばです。最近D
複数のAndroid端末を同時につないで困ってませんか？それadb-pecoで選択できるよ！ - クックパッド開発者ブログ
モバイルファースト室の@tomorrowkey です。 adb-pecoというスクリプトを作ったので紹介します。 https://github.com/tomorrowkey/adb-peco 不親切なadbの挙動 CookpadではAndroidアプリの開発にGenymotionを使っています。 普段はGenymotionだけを立ち上げて開発しているのですが、時折不具合報告を受けてAndroidデバイスを接続することがあります。 ひとまずlogcatを見ようとしたり、shellを起動してディレクトリ構造を見たりするのですが、こういうエラーが発生します。 Genymotionとデバイスの２つが接続されているので、adbがどちらに接続するのか分からずエラーを返します。 このエラーを見る度にデバイスIDをコピーしてオプションに追加しなければなりません。 $ adb devices List o
microservicesに分割する際に注意するべき5つのこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに マーティンファウラーがmicroservicesの記事で、小さな役割をもったサービス群にアプリケーションを分割することを提案しています。 cookpadが、サービスをマイクロサービス群に分割していることの記事が注目を浴びており、最近急速にバズワード化しているように感じます。 バズワード化して、ポイントが損なわれる前にいくつかの注意点をまとめておきます。 1.インフラコストは基本的に増大する microservicesは、今まで単一のアプリケーションコードで行われていたことを複数のサービスサーバーに分割して管理・運営していくこと
AWS で作るシステムのセキュリティ考 - 水深1024m
AWS アカウントを複数人で使ってシステムを作っていく時に、 セキュリティの面からやるべきことについて。 主に Web アプリケーションを想定した内容ですが、特に書いてあることは特殊ではないと思います。 各所の Blog にも記事書かれてますが思っていることをつらつらと書いてみます。 なんか変なこと言ってたらご指摘ください。 参考: AWSのセキュリティが気になるなら読んでおくべきAWSセキュリティのベストプラクティス - yoshidashingo はじめに (AWS アカウントと IAM ユーザ) 前提というか用語の話。 AWS アカウント アカウント作成時のメールアドレス、パスワードでログインして使うユーザ IAM ユーザ AWS アカウントから発行できる、ユーザ名とパスワードでログインして使うユーザ AWS アカウント周り AWS アカウント (ルートユーザ) で作業できないように
読まれないマニュアルに価値はない | サイボウズ式
【サイボウズ式編集部より】この「ブロガーズ・コラム」は、著名ブロガーをサイボウズの外部から招いて、チームワークに関するコラムを執筆いただいています。今回は、日野瑛太郎さんによる「使われるマニュアルをどう作り、チームの資産にするか」について。 新しいチームにジョインして、それまでとは全然違う仕事を任されたものの、仕事の進め方がわからなくて困ったことはありませんか？ そんな時に、前任者が作成したマニュアルがあると大変心強いものです。マニュアルは自分だけで読み進めることができるので、誰かに質問するのと違って他人の時間を奪いません。また、（業務内容が変化しない限りは）何度でも使いまわせます。マニュアルはチームにとって重要な「資産」です。 もっとも、現実にはこのように理想的な引き継ぎができることばかりではないでしょう。むしろ、マニュアルなどまったく存在せず、自力で業務内容をひも解いていかなければなら
オブジェクト指向の法則集 - Qiita
この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集（リンクとコンテキスト追加）を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集（転載元：http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-principles.html ） なお、この記事の他にも石井さんのオブジェクト指向やRubyに関する多くの記事をオブラブの「まさーるのページ」で読むことができます。では、以下に石井勝さん（旧メールアドレス masarl@nifty.com）の記事を転載します
GitHubに会社の就業規則を公開した - terurouメモ
これです。 ちゃんと社労士チェックを入れて、2014年時点の法運用Validな感じにしてあるので、下手な中小企業はおろか、ろくにメンテされていない大企業の就業規則よりマトモな内容になっているはずです。 なんで就業規則を公開したのか マトモな規則が作ってあれば公開しても特にデメリットはない むしろマトモな会社アピールができてよい 個人的には「無限RedBullです！！！！」みたいな事をアピールする会社よりマトモな広報・求人活動の一環だと思っている 自分で就業規則を作ろうにも、良いサンプルがなかった（後述あり） いわゆるOSS的な話。就業規則にも再利用性が合っても良いはず これを書いてて、就業規則にライセンスを明示するのを忘れていたことに気が付いた GitHubだと、就業規則の改定にプルリクを飛ばせて楽しいし、改定履歴も一目瞭然 零細企業に就業規則って要らないんじゃないの？ 従業員が10人未満
Decompose That WAR! Architecting for Adaptability, Scalability, and Deployability
Decompose That WAR! Architecting for Adaptability, Scalability, and Deployability It’s no longer acceptable to develop large, monolithic, single-language, single-framework Web applications. In this session, you will learn how to use the scale cube to decompose your monolithic Web application into a set of narrowly focused, independently deployable services. The presentation discusses how a modular
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YAPC::Asia 2014 - 半端なPHPDisでPHPerに陰で笑われないためのPerl Monger向け最新PHP事情
http://kamipro.com/blog/?p=16006