3,099 reputation
713
bio website
location
age
visits member for 3 years, 2 months
seen 18 hours ago

Apr
18
comment Testing abstract class' behavior
Just realized I partly paraphrased @pdr 's last comment. Sorry about that :/
Apr
18
comment Can the DDD repository modify entity in the DB without an entity object?
(I meant save() method not add())
Apr
18
comment Can the DDD repository modify entity in the DB without an entity object?
You might be interested in these articles discussing the problem of save() in repositories : richarddingwall.name/2009/10/22/… codebetter.com/iancooper/2011/04/12/… odetocode.com/blogs/scott/archive/2010/06/13/…
Apr
18
comment Can the DDD repository modify entity in the DB without an entity object?
If not using a Unit of Work-like mechanism, you're probably experiencing problems listed in the second paragraph here : martinfowler.com/eaaCatalog/unitOfWork.html Anyway, you don't have to use repos for DB interaction - clients shouldn't have to see it that way. Again, in the eyes of its consumers, a repo is just like an in-memory collection. If you absolutely want the add() method to be side by side with other data manipulation, at least don't reflect it in the Repository domain abstraction (interface, abstract class) that the world sees, put it at the concrete repo class level.
Apr
18
revised Can the DDD repository modify entity in the DB without an entity object?
deleted 108 characters in body
Apr
18
answered Can the DDD repository modify entity in the DB without an entity object?
Apr
17
answered Testing abstract class' behavior
Apr
17
answered How are design-by-contract and property-based testing (QuickCheck) related?
Apr
15
comment Scrum task over estimation
Sure. However, you can at least expect some amount of improvement every few sprints during, say, the first dozen sprints, which doesn't seem to be the case here. It's only legitimate to point that out during a retro. Any self-respecting agile team should also set itself a higher goal each time, which should psychologically trigger at least a little additional pressure to make further effort. And as you said, even admitting the team plateau's in terms of sheer velocity, there's all sorts of other things you can try to improve : customer satisfaction, performance, documentation, etc.
Apr
15
comment Scrum task over estimation
"overestimating tasks" - you mean user stories right ? Tasks don't have points, stories do. Story points are usually on a coarse grained scale. Since velocity improvement is based on the previous sprint, you can't keep blatantly overestimating them sprint after sprint otherwise you'll end up with enormous values.
Apr
15
comment Scrum task over estimation
My point is precisely that an agile team shouldn't "have more or less the same velocity", they should improve and get more productive over time. Maybe they aren't aware of that. Maybe they think it's just fine to always hit the same score and do whatever they want with the rest of their time. Hopefully, just restating things and reminding them of the upcoming release will ring a bell. Also remember that you're not alone here, the PO might be a reliable ally (see my edit)
Apr
15
revised Scrum task over estimation
added 706 characters in body
Apr
14
answered Scrum task over estimation
Mar
26
comment From a TDD perspective, am I a bad person if I test against a live endpoint instead of a mock?
I have little idea what HTable really does and how you use it, so don't take my wrapper example to the letter. I had mentioned a wrapper/adapter because I thought the thing to wrap was relatively small. You don't have to introduce a one-to-one replica to HTable, which would of course be a pain, let alone a whole framework - but you need a seam, an interface between the realm of your application and that of HTable. It should rephrase some of HTable's functionality into your application's own terms. The Repository pattern is a perfect incarnation of such a seam when it comes to data access.
Mar
24
revised What are good unit tests to cover the use case of rolling a die?
added 56 characters in body
Mar
24
answered What are good unit tests to cover the use case of rolling a die?
Mar
24
awarded  Nice Answer
Mar
21
comment reloading singleton classes and dependency
I guess the general principle is to place UsersDAO in a separate deployment unit from the start. Then redeploy it when it has changed and pray that your web server is able to refresh dependencies without restarting the app ;)
Mar
21
comment reloading singleton classes and dependency
@Jarede what web server/platform are you running on ? You might want to be more specific here.
Mar
20
comment From a TDD perspective, am I a bad person if I test against a live endpoint instead of a mock?
I agree it's not a systematic red tick when they change though - it requires a little discipline to keep contract tests and mock-based tests in sync. Some tools like Bogus in Ruby (relishapp.com/bogus/bogus/docs/contract-tests) can help you do that.