I forgot the codez...

So, I'm on a small project which has some multi-tenancy. Simply put; user A can see the bananas on his trees, and user B can see the bananas on his own trees... but they can't see each others. But it's restfull, so ideally, you'd call something like /tree/{tree-id}/bananas And since we know who's executing the call (since it's authenticated), we can verify that it's user A calling us, and then check which trees he can see. If he's trying to be sneaky, and does a restcall with a treeId of B, a security violation should occur. Okay, so how do we do that? Well, the application has a controller for that, and we'd want to secure it there. So, assume we have the following code: public List<Banana> getBananasOfTree(String tree) Since it's supposed to be annotated, we'd use something like this: @RequestMapping("/tree/{tree-id}/bananas") @Secured // or some other requirement  public List<Banana> getBananasOfTree(@Pat...

So I was on a project without sonar. Oh my. Well, it was an OSGI project, so the problems couldn't be that bad, right? But how good were they (and what things were bad?) I found Stan4j , a code analysis tool for eclipse, which draws nice graphs and can handle osgi pretty well it seems. Now I can see that dependencies/bundle names aren't properly aligned (even though OSGI doesn't complain), etc.

Well, web security is tricky. However, Mozilla can go to the rescue! They have the observatory ( https://observatory.mozilla.org/) It can scan a webpage for you and give it a bit of a rating. Its just a static check, on headers, etc. But it shows how far you've narrowed down your attack surface. Of course, it doesn't say anything against actual attacks (get ZAP for that)

Great stuff: https://vladmihalcea.com/2014/02/01/how-to-detect-the-n-plus-one-query-problem-during-testing/ --> Allows testing with JPA

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