サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
nemuzuka.vss.jp.net
やっぱり RDBMS と連携したかったのでやってみました。 参考にしたのは Access a database with MyBatis Micronaut + Kotlin + DomaでTransactionを楽に扱う*1 です。 build.gradle LocalTransactionManager 関連 DomaConfigFactory DomaConfig Dao @DaoConfig TaskDao 接続情報 Dao のテスト TaskDaoTest トランザクション @Transactional TransactionInterceptor TaskUseCase まとめ build.gradle plugins { ... id 'org.seasar.doma.compile' version '1.1.0' } dependencies { ... annotati
12/10に長岡市で、長岡IT開発者勉強会(NDS)が開催されました。 NDSとは、 新潟県長岡市のIT系開発者が、自主的に勉強会を開催するために2008年11月に結成されたグループです。 長岡市での勉強会の開催や、議論をを主な活動とします。 情報処理技術に関するものであれば、プログラミング技術、IT最新情報、開発手法、ITマネージメント、スーツネタなど幅広い範囲での学習を目指します。 とあるように、情報処理技術に絡んでいれば何でもありの勉強会です。 それが50回目の開催でした。おめでとうございます。 @civicさんの地道な活動と人徳は見習うトコロが多いです。 私も半分めくらいから参加しだしているので、賑やかしにはなっているかな、と思うのですが... 第50回勉強会(2016/12/10) - 長岡 IT開発者 勉強会(NDS) セッション内容を見て頂ければわかると思うのですが、都内の勉
JavaでTomcatなWebアプリケーションを作っている時に、Sessionの情報をどう管理しようか、というのが問題になります。 認証済み状態であることをSession上に設定しておき、認証されていないリクエストが来た時にログイン画面に遷移させる、というアプリケーションは多いと思います。 Tomcatのメモリ上にSession情報を配置するのはいいけど、もし、そのTomcatが死んでしまった時、Session情報も無くなってしまいます。 別のTomcatインスタンスにリクエストが飛ばされた時でもユーザに影響が無いようにSession情報を引き継ぎたい、という要望が少なくありません。 イマドキのシステムならDynamoDBで管理なのでしょうか。AWSもそんな事言ってます。 Manage Tomcat Session State with DynamoDB - AWS SDK for Jav
DBCPでコネクションプーリングをやっている時 デフォルトの設定のままだと 長い間使われないコネクションに対して プール上は有効だが、DBMS的には無効になります。 その為に、 validationQuery という設定にて、プールからコネクションを取得する時に 生きてるかチェックすることをする必要があります。 ただ、毎回行うのは何だかナンセンスなので ある程度時間がたった時にチェックするようにすると エレガント。 毎日APサーバーをリブートする運用であれば問題ないですが・・・。 本番運用前に見つかってよかった・・・汗 【考えられる方法】 validationQuery・・・死活監視の為に発行するSQL testOnBorrow・・・getConnectionした時に死活監視のSQLを発行するか? 死活監視スレッド設定 timeBetweenEvictionRunsMillis・・・死活監
SQLアンチパターン 作者: Bill Karwin,和田卓人(監訳),和田省二(監訳),児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 5人 クリック: 550回この商品を含むブログ (11件) を見る 買いました&読みました。開発者であれば読んで損はない良書です。っていうかシステム開発で対価を頂こうって人は読みましょう。 まだまだRDBMSのシステムは無くならないでしょうし、生み出されていくと思われます。転ばぬ先の杖としてこの本の情報があると「あの時ああしとけば良かった」と悔やむことや後任の担当者に恨まれることが少なくなるでしょう。 システム開発を長いことやってて修羅場を経験している人にしてみたら新しい驚きはないと思います。なので、こういう「べからず集」は、情熱はあるけど経験の少ない人にこそ読んで欲しいと考えます。 先人たちの過ちを自
9/22にNDSに参加してきました。 「スーツvsギーク討論会」というテーマでディスカッション形式でした。勉強会でディスカッションってめずらしかったです。皆さんが現在に至るまでの経緯の違いからか、伝えたいことが伝わらず歯がゆく思うこともありましたが、最終的に「ゴールは一緒なので協力しましょうよね」、という落とし所になってよかったと思います。こういう話でムズムズしている人は、社内でやってみたらいいのに、と思いました。そっちの方がわだかまり少なくなると思います*1 僕の勝手なイメージからすると「スーツ」「ギーク」って、自分に壁を作っているだけだと思うんです。僕は「スーツ(ギーク)」だから「ギーク(スーツ)」の話はわからないと言っているように思えて。「俺がこんなに頑張ってるのに報われないのはギーク(スーツ)の奴らのせいだ」って言いやすくしてるだけじゃないかな、なんて歯がゆく思ってましたが、今回の
ござ先輩の記事に触発されたので書いてみる。 自分が書いたプログラムに対してテストをする必要があることについてはご認識の通りでしょう。自分の趣味に留まらず、そのプログラム(で作られたシステム)がビジネスを回す上で必要だったり、「お金」という対価を得る場合は特に。 「ちゃんとテストしました」と自信満々で言われ、いざ使ってみてつまんない実行時エラーが出てきた時、受け取った側はどんな顔をすればいいかわかりません。ましてやそんなのが何回も続くとその人の信用はガタ落ちです。時間をかけにかけまっくてシステムを作って、満を持してユーザに見せた時にそんな状態だと人格そのものを否定される可能性だってあります。 言い訳がましく「入ってるべきデータが入っていなかったからです」と報告しても「なんで落ちたかの説明よりもとっとと直せ。お前が作ったプログラムは信用ならん」と言われるの、切ないですよね。でも、ユーザがあなた
私が携わるプロジェクトでは、 極力SQLでビジネスロジックを書くことを回避してもらってます。 理由は、SQLでロジック書かれると、 JavaとSQLでロジックが分散してしまうからです*1。 SQLだろうが、Javaだろうが、 訳のわからないロジックを書けてしまう事は事実です。 システムの目的はぶっちゃけると、 永続化してデータを貯め、それを参照させること。 システムは生き物です。今のロジックでは問題ないかもしれませんが、 遠くない未来では仕様を満たさなくなるかもしれません。 仕様が変更されると、今まで正しかった振る舞いも 正しくないことになります。 システムとして存在し続ける為に、 正しい振る舞いになるようにロジックを変更する必要があるのですが、 テスト、もしくは動作確認をする際、SQLでビジネスロジックが記述されていると 事前データの準備が必要になってきます。 テスティングフレームワーク
例えば、一定期間に登録・更新したデータを export したい、って要件はまずまずあると思います。 場合によっては期間で絞り込んでも数万件とか対象になることもあるわけです。 そんなデータをメモリにどかんとのせたらどうなるか?OOM 発生が容易に想像できます。 その分メモリを積むことで対処できなくはないとは思いますが、メモリを追加し続けるのにも限度があります。 アプリ側でなんとかするにはいくつか方法が考えられます。 1. アプリ側で適切なサイズに区切る limit, offset を駆使して、抽出対象のレコードを絞り込む方法です。また、offset だと後ろのデータを取得する時の読み飛ばしに時間がかかるので、抽出した塊の最後のレコードの次から塊を抽出する方法もあります(シーク法と言われているみたいですね)。 データの塊毎に SQL を発行するので、SQL 自体が遅いと最後のページにたどり着く
ござ先輩が興味深いエントリーを書いていました。 アジャイルって受託開発との相性が最悪な気がする - GoTheDistance ちょうどそんな感じの問題にぶち当たっているので、私も書いてみよう。 アジャイルを採用する上でのメリット/デメリット 顧客側(システムを使って利益を生み出す側)にとって、 動きもしない自然言語で記述された設計書について あーだこーだと会議をされるより、 実際に動くものを見ながら話をした方がゴールが見えやすく 認識違い、コミュニケーションロスも早めに討ち取れるので メリットは大きいです。絶対。 開発側も仕事してるぜってアピールにもなるし。 長い時間かけて作ったシステムを納品前に初めて見せて、 「これは何の冗談?」と言われることもなくなるでしょう。 ただ、作ってないものに関してはリスクの先送りになるので、 作り始めてから問題点に気づくのは手遅れになります。 なので、アジ
MavenはJavaのビルドを行う際の強力なツールですが 一般的なMavenのお作法では、公開サーバーからjarを取ってくることになっています。 個人的には、公開サーバーより取得するよりも、SVNみたいな構成管理ツールから とってきて全部解決できるようにしたい。 コンパイル&jarに固める時にはpom.xmlに <dependency> <groupId>my-group</groupId> <artifactId>junit-4.5.jar</artifactId> <scope>system</scope> <systemPath>${basedir}/lib/junit-4.5.jar</systemPath> </dependency>と記述すれば、ローカルに存在するjarを参照します。 Eclipseのプロジェクト直下にpom.xmlがあれば、 {Eclipseのプロジェクトディ
私は、テストで重要なのはカバレッジでなく、 「こうあるべき」と定義したAssertionであると思っています。 さらに言うと、データ/状態/操作の組み合わせパターンを変えて、 さまざまなAssertionのパターンを定義できる*1人が テストのスキルを持っていると言えるのではないでしょうか。 JUnitを利用して単体テストを行う時に「実装したソースコードを元にテストクラスを記述すること」は 非常に時間がかかってしまうものです。 実装によっては、そのメソッドが「何をすることを期待しているのか」 定義することが複雑になる為です。 大半の現場では、Assertionが定義しづらく、カバレッジ率のみで 「テストを実施している気になっている」ことが多いのが大半でしょう。 テストしてる感も実感でき、カバレッジ率を出すだけにならないテストクラスにする為には、 実装する前に意識することがいくつかあります。
このページを最初にブックマークしてみませんか?
『nemuzukaの「明日から本気出す」』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く