12/16/2015

Learned
-about using joda time's DateTime to parse a UTC date.
-about using Apache Commons XMLConfiguration to drive strategy
-about one pattern for using strategies in a Java Spring Application:
in beans file add:
    <bean id="byWhichMeansStrategyFactory" class="com.awgtek.byWhichMeansStrategyFactory" factory-method="createStrategy">
<constructor-arg index="0"  ref="myXmlConfig" />
<constructor-arg index="1" type="java.lang.String">
  <value>this_means</value>
</constructor-arg>
    </bean>
   
    <bean id="MyImpl" class="com.awgtek.DoesSomethingImpl">
        <constructor-arg index="0" ref="byWhichMeansStrategyFactory" />
    </bean>

The createStrategy method would instantiate the correct strategy class basd on the "this_means" value. The injected strategy would then be used to e.g. pick a consultant either through "cheapness" defined by some parameters in the strategy or skill, etc. see http://blog.lowendahl.net/design-patterns/strategy-pattern/

-about using Guava, e.g. to import static com.google.common.base.Preconditions.checkNotNull to do checkNotNull statements where needed.

Camel vs Spring Integration (SI)

Camel uses producer templates to access routes.

SI uses gateways to access channels.

Modular JavaScript Articles

http://adripofjavascript.com/blog/drips/variable-and-function-hoisting

http://www.adequatelygood.com/JavaScript-Module-Pattern-In-Depth.html

http://addyosmani.com/writing-modular-js/

Benefits of Dependency Injection

This question is often asked at interviews, and a good list of reasons to use it can be found at http://anandmanisankar.com/posts/angularjs-dependency-injection-demystified/:

• Separate the process of creation and consumption of dependencies
• Let the consumer worry only about how to use the dependency, and leave the process of creation of the dependency to somebody else
• Allow concurrent/independent development of the dependency and the dependent entity, while only maintaing a known contract
• Facilitate changing of the dependencies when needed
• Allow injecting mock objects as dependencies for testing, by maintaining the agreed contract

Use of "Requires New" Transaction in Chunk Processing

One place to use @Transaction "requires new" is on the onXXXError listener methods (or on methods called from them) that fire on error events during chunk processing in Spring Batch because the current transaction might be rolled back (depending on any no-rollback-exceptions set):

With annotation based transaction handling you can put the annotation @Transactional(propagation=Propagation.REQUIRES_NEW) on the method to achieve this.

https://blog.codecentric.de/en/2012/03/transactions-in-spring-batch-part-2-restart-cursor-based-reading-and-listeners/

Configuring Drools Rules Precedence

See how: http://blog.athico.com/2014/04/exercise-1-public-training-san.html

On LazyInitializationException - Example

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

Review how it's possible to get this exception if a Hibernate session is closed via transaction rollback but the exception carries a pointer to the non-greedy loaded object. In the catch clause if the object's children are accessed a LazyInitializationException is thrown because the object is detached and it's lazy-loaded children are uninitialized.

Useful Custom Exceptions

One useful custom exception to cite as an example of "when would you use a custom exception" interview question is the ObjectNotFoundException triggered when accessing an invalid proxy gotten from the session.load() method. Custom exceptions are useful to for conditional logic that is strongly typed and semantically precise and, moreover, more natural then parsing and identifying error codes or String value properties of more generic exception types.

Hibernate's inverse=true on sets, and cascade=all

review this example: http://www.mkyong.com/hibernate/inverse-true-example-and-explanation/

upshot: makes more sense to do inverse=true -- results in fewer SQL statements.

But what if you just want a many-to-one relationship? e.g. a Rectangle that has a instance variable of type Point and Point can be a property of multiple Rectangles. Furthermore, you only need this to be unidirectional. No need to navigate from Point to Rectangles. (Note: a rectangle's location be defined by a single point.) In this case inverse="true" won't help because it can only be applied to a collection not a property. So what if you want to persist the Rectangle with one Hibernate save statement, and not have to first save the point, then save the rectangle to avoid a referential integrity error. The trick was mentioned in passing here: using cascade="all" on the many-to-one element in the unidirectional relationship's only side, in this case Rectangle, or if using annotations @ManyToOne(cascade=CascadeType.ALL) -- with cascade set to all, " if we perform an insert on the child row, Hibernate will automatically create the parent row based on where the child row is pointing." THAT saves a line of code, which can be a HUGE benefit especially if this is a polymorphic Hibernate util, otherwise, you would have to do something like either cast the entity to see if it's a Rectangle and has a point or in which case persist the Point or create a "performPreSave(session)" which is called on all entities where a Rectangle could override and persist its Point. Hacky! So...use cascade="all"...

Update. Rather than cascade="all" to achieve this single-save-cascade effect, should use "save-update" because you don't want to cascade a delete probably ever, if it's a many-to-one, since there could be other shapes like polygon relating to that point and possibly even other rectangles. In fact, cascade delete would probably only ever make sense in a one-to-one, and only ever in a one-to-many if the many-side table (the table holding the foreign key to the one-side table) did not contain foreign key references / relations to other entities. Answer here referencing Hibernate docs agrees with this.

This save-update effect would be useful to the afore-mentioned unidirectional relationship for the purposes of adding the related records upon saving the primary record, in this case the rectangle.