I forgot the codez...

So I was at a project where data was somewhat sharded. We had a customer, which was part of a customer database (accessible by webservice calls), however, we had some additional customer data. This led to the (I think somewhat unfortunate) situation where the application reasoned from their own business object, and, when necessary, retrieved data from the relation system. I feel this is flawed, ideally the entirety of the customer data should be invisible to the business logic of the application. Where I normally would like to have an anemic domain model, this data sharding makes it hard. Let's say you have relation R, and our extended data S. In our application, we want to reason about RS (or at least, not have to make that distinction). So maybe S has some additional attribute which may (or may not) be filled, depending on whether R is available or not. That sounds like a nice idea, but everywhere when R is necessary (and S is available), R needs to be retrieved. And that is ...

A quickie: When you have a class with a builder, and you want to subclass that class, you also want to subclass the builder. But things get nasty quickly, as your subtypes' builder doesn't work nicely. A good solution from Stackoverflow: http://stackoverflow.com/questions/17164375/subclassing-a-java-builder-class Also, a thingie on sizes. When is a class too big, when is a method too big, when is a package kinda big: https://www.javacodegeeks.com/ 2012/12/rule-of-30-when-is-a- method-class-or-subsystem-too- big.html Although I don't agree on the rule of thirty (I think it's too big. Maybe 30/10/10 is more appropriate), it's a good start, and has some nice references.

Yesterday I had one of those days where all of a sudden I'm shown my code isn't as good as it should be. Oh dear. So, something to learn, because they were right . Two things: Static methods Static methods are 'horrible'. After discussing about the why, finally a good argument came up: They inhibit extension! You cannot override them, and usually it is a sign of functional programming style. That may not be bad per se, but being able to override functions is a good thing. So: BE CAREFUL TO MARK METHODS STATIC. USUALLY, IT CAN BE DONE BETTER. Strategies Strategies are cool. However, I tend to push into that direction. That my not be necessarily bad, but strategies are only for compile-time decisions. Ther is a difference between implementing classes which are injected, and thereby selected at 'compile time', and actual runtime by using, say an abstract factory to determine which strategy to use for the current run. So, note to self: only name an i...

So I had a discussion about stateless session beans and them containing state. Coming from spring, I expected stateless to mean no state what so ever. This is because the default scope for beans in spring is Singleton. This allows beans to be shared (and wired) on application startup, ensuring that no real bean pool management is necessary. The container decides to use separate beans for injection, or all the same, since there is no real 'pool' to speak of. Compare this to EJB, which has a stateless session bean. This compares with a stateful session bean. A stateful session bean contains the state through the entire session. A stateless session bean does not. However, a stateless session bean can contain state. Stateless session beans are request scoped , meaning that any state they have they can access within the request. This, of course, comes from EJB's Stateful and Stateless EJB's of old, where it was made that way. Spring made sure that stateless = no ...

So I was working with JPA and transactions. Consider the following: In bean 1, with implicit TX 1, managed entities are loaded/created,and returned in bean 2, with implicit TX 2, entities are modified in bean 3, with NO TX, bean 1 is called, and the results are passed to bean 2. and bean 4 is similar to bean 3, but with it's own transaction, TX3 What happens when bean 3 finishes: are the entities updated? What happens when bean 4 finishes, are the entities updated? The answer to this is simple; entities are managed through a persistance context. That context is tied to the transaction. So in bean 2, there is a difference. When called from bean 3, it runs in a different transaction then bean 1, and thus a different persistance context, and thus the entities are not managed 'by this transaction'.When called from bean 4, it all runs in the same transaction, TX3, and the results are persisted.

Well, I've always felt that minify was useless if you had gzip on. Turns out, I'm not the only one saying that, and people have put their money where their mouth is. So there's actually quite a bit of reserach on it. http://stackoverflow.com/questions/807119/gzip-versus-minify https://css-tricks.com/the-difference-between-minification-and-gzipping/ Long story short: gzip is better then minify. gzip AND minify is even better. advantages of minify are that it can create a big ball of javascript, requiring only one GET reqeust

Some articles regarding design philosophies: Domain models: rich or anemic? World is at fire, both have advantages, disadvantages. Personally, I'm more of a data-driven anemic model. Where business logic is governed by the business layer, and persistance by the persistance layer, the question is where the domain model resides. I like it more in the persistance layer. This does allow one to hopelessly mutilate the domain model in not allowed ways, but it also SOLID, since it only has one responsibility. http://techblog.bozho.net/on-domain-driven-design-anemic-domain-models-code-generation-dependency-injection-and-more/ https://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/ http://stackoverflow.com/questions/23314330/rich-vs-anemic-domain-model And of course wikipedia: https://en.wikipedia.org/wiki/Anemic_domain_model For me, this is also because I'm not much of an OO-fan. Luckily, I'm not the only one: http://www...