I forgot the codez...

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...

We've been there before. enter an emailaddress, get a verification in it. And in test it also sends those mails (and not to some fake location). https://www.mailinator.com accepts all mails, and stores them for a while. So send an email to spamthis@mailinator.com, go to the website, access the mailbox, and voila.

Traditional AOP has aspects, i.e. the classes doing the work, and pointcuts: the places where an aspect squeezes itself into. JEE has some AOP as well, but this is only annotation-bound . So I can define an aspect TimeStuff and an annotation @Timed then all methods or classes need to have an the @Timed annotation added to trigger TimeStuff . This is a bit sad, because it means having to modify code which we might not control, nor want to modify since it's nice and clean. With Spring (or full) AOP, we can define a pointcut which cuts to all the methods/classes which we want (either in configuration, or in the aspect itself with an annotation), and the original code is none the wiser. Lovely! Nothing to see here, nothing to forget here. I want that in JEE. It's not quite so simple, but it's doable. See: https://github.com/softwaremill/softwaremill-common/blob/master/softwaremill-debug/src/main/java/com/softwaremill/common/debug/timing/TimingExtension.java Roughl...

Javascript fatigue (or: why it sucks to learn) Organizing code - by strategy, by component, etc. Configuration building in spring Complete java based config in spring Ungit...?

Oh my. Reflection on generics. That's not always nice. So, here goes. As can be easily found, it is possible to determine the actual type of a generic class at runtime. And in the code we get a number of lists<>... and we want to sort them by class hierarchy (so, String extends Object, and thus List<String> should go after List<Object>) Our compare method then needs to look like this: compare( List left, List right) { Type type = left.getClass().getGenericSuperclass() if(type instanceof ParameterizedType) {// it is a generic   ParameterizedType pType = (ParameterizedType) type;   Type[] actualTypes = pType.getActualTypeArguments();   // and then we have an array, which in this case should be String.class and Object.class, which we can then compare   } ... } This is nice, but spring kinda has the problem that those objects *might* be more then they are... they might be AOP'd! In that case, we do not get the actual objects, but proxie...

So far I have a number of things which I don't like. Abstract classes are evil.It indicates base classes, but inheritance should never be used for code reuse. Use interfaces, factories, strategies for such stuff. Moreover, they give code that cannot be tested (easily) final should not be used, except to designate constant statics. Nothing more, as it is superfluous take-space-on-my-screen crap Builders which cannot be extended. Ideally, a builder should be separate from the value object, and the value object should be extensible. Hence, private constructors are a no-go for the value-object. The disadvantage of using builders is that it is hard to extend them properly, as they are usually not templated and thus do not use a proper signature. E.g. class OldBuilder {     int a;     OldBuilder withInt(int a )   {         this.a=a;         return this;     }     Value...