Header Tags for Structure not Presentation

The often misused header elements (<h1>--<h6>) are where we need to focus. The mis-use usually occurs with the headers not following in immediate descending order. In other words, the headers that should follow an <h1> element are <h2> elements. No <h3> elements should be direct descendants of the <h1> element. This paradigm should continue throughout the document. Also true of header elements is that they are used to convey the document's structure; they are not used for presentation within the document. If you need to create a section of code with larger text, use appropriate markup and do not simply throw in header elements to accomplish the task.

Ajax: the Definitive Guide; O'Reilly 2008. pp 292.

Quote from section on leveraging header elements to drive a table of contents.

When to use Java over Drools

Some caveats to remember when using Drools are that it scales best when a large number of rules are executed against a small number of facts. It also makes more sense to use Drools when the rules are loosely coupled; if many rules depend on each other in a chain, it may make more sense to write an if statement decision tree in Java code instead of presenting the logic as a series of individual rules spread throughout one or more DRL files.

https://www.credera.com/blog/technology-insights/open-source-technology-insights/using-drools-expert-apache-camel-part-3-embark-sample-route/

Volatile accesses are synchronizing

...volatile accesses are synchronizing actions (docs.oracle.com/javase/specs/jls/se7/html/…), as such, they define an order for concurrent events which makes them equivalent to locking on the same monitor. – Cephalopod 

http://stackoverflow.com/questions/3786825/volatile-boolean-vs-atomicboolean

What not to Test in MVP

When unit testing MVP applications, the recommended practice seems to be you should test presenters and not views. Services fall into a similar "don't unit test" category because they'll need to connect to the server-side, which won't be running in a unit testing environment.

https://dzone.com/articles/building-gwt-applications-mvp

Don't test the model either as it's just a glorified bag of getters and setters.

AngularJS is not MVC

Your template drives your application. It's treated as a DSL. You write AngularJS components, and AngularJS will take care of pulling them in and making them available at the right time based on the structure of your template. This is very different to a standard MVC pattern, where the template is just for output.
It's more similar to XSLT than Ruby on Rails for example.

http://stackoverflow.com/a/23606512/2066936

DI Required for Declarative Transactions

[D]ependency injection is the only way that declarative transactions work. You will not get a transactional service if you use the new operator such as new BookService()

http://grails.github.io/grails-doc/2.3.11/guide/services.html

What is a Hibernate Session?

Besides a unit-of-work it's also...

[...]many other things, for example, a cache and a primary API.

https://developer.jboss.org/wiki/SessionsAndTransactions

Private Methods to Separate Classes

...if you have the urge to test a private method, the method shouldn't be private; if making the method public bothers you, chances are, it is because it is part of a separate reponsibility; it should be on another class." [Working Effectively With Legacy Code (2005) by M. Feathers]

quoted by 'blank' at http://stackoverflow.com/questions/7075938/making-a-private-method-public-to-unit-test-it-good-idea

What to Unit Test

Testing of a class should verify that: 1. methods and properties return expected values
2. Appropriate excepts are thrown when an invalid argument is supplied
3. Interactions between the class and other objects occur as expected when a given method is called

Crippledsmurf - http://stackoverflow.com/questions/62625/how-do-you-know-what-to-test-when-writing-unit-tests

Should you test internals (e.g. setting of private variables)? Some say no. On the other hand:

While it is true that there is a certain brittleness where test code knows internal details - this is unit testing, which is, by nature, whitebox, not black box.

http://googletesting.blogspot.com/2009/02/to-assert-or-not-to-assert.html - comment by Christian Gruber