Is That A Reg Flag?

I am adopting a slightly different meaning to the phrase "red flags"; which in colloquial usage refers to a warning signal or something that demands attention. Although my modified meaning also can be seen as a warning signal; the new meaning I am ascribing to the phrase is based off the Red Flag Traffic Laws

The Red Flag Traffic Laws were laws in the United Kingdom and the United States enacted in the late 19th century, requiring drivers of early automobiles to take certain safety precautions, including waving a red flag in front of the vehicle as a warning.

The law as defined from Wikipedia. Emphasis mine.

An interesting part of the enactment:

  ...[a person] shall carry a red flag constantly displayed, and shall warn the riders and drivers of horses of the approach of such locomotives, and shall signal the driver thereof when it shall be necessary to stop, and shall assist horses, and carriages drawn by horses, passing the same.

To people of today's world; this policy definitely sounds absurd and backwards. But at the time it was put in place, it was done so as to address a real concern; safety to others in a world where self propelled locomotive is about to become more common...

But the absurdity of it is not my primary concern but the limitation the policy would have placed on the expression of a new technology. For one, having someone always in front of the locomotive means that the locomotive theoretically is not allowed to move faster than a particular speed. A big advantage of having a self propelled locomotive is then lost! Why have a car when you can only drive at a much slow pace?

And this is where my new internal usage of Red Flags takes it meaning. It expresses propositions, way of thoughts, policies that stifles the expression of innovation not with the intention of doing so but as a result of taking actions that intends to protect a valid concern.

And some characteristics of these kind of thinking; "these Red flags" can easily be spotted by taking a look at some of the characteristics of the Red Flag Traffic Law itself:

1. The law was put in place in good faith. The intention was not to stifle expression of an emerging technology; but to protect the populace. But the outcome, invariably  limited the expression of a new technology
2. The law was focusing on established way of life instead of embracing and exploiting a new way.
3. Although the concern expressed by the law is valid; it tried addressing these concerns from the same paradigm level.

Making sure all self propelled locomotive have a hoot would have been a solution that sufficed. This is how addressing the concern from a different (or higher) paradigm would have largely addressed the concern without having to put an artificial limitation on the workings of the self propelled locomotive.

So when we are confronted with any new concepts; innovations or technologies that has the potential of disrupting the safety of well established way of doing things and we have a strong urge to put things in place that would address these concerns; we need to be aware that our actions might lead us to just be enacting our own versions of the Red Flag Traffic law. We don't want to do that.

In Software, You Build To Change Too

There are moments when differently considering how a domain is captured and expressed leads to an epiphany of sort: A much clearer insight into the matter at hand.

It could be a slight or simple change of point of consideration, but the insight it leads to, could be quite profound.

The Earth moved. A simple change in the way the solar system is viewed but a change that led to a significant upheaval of not just how we understand the cosmos; but a change that also rattled the political and power structures at that time.

I recently had a similar change with regards to how I internally conceptualize Software Development (or construction) and Software Architecture. Not surprisingly, my internal modelling has largely been shaped by the type of architecture that I am most exposed to: which is the civil type: how buildings are made, roads, bridges etc. And in these domains, the primary concern is building to last. The success of the architecture of a bridge is judged on how long it can last without fail. Same goes for high rise buildings. Building to change is not primary in these domain. 

This view has been projected onto how I primarily perceive Software Architecture. A great Software Architecture is the one that creates software that can always keep performing no matter what. This is the building to last metaphor.

But just as building to last applies to software; building to change is (should) also be core too. In fact; how well a software facilitate easy change would determine how long it may last.

Software is meant to mutate, by its very nature, with time. And a good software architecture is one that enables for easy change to the system while ensuring the system continues to provides its utility.

So when approaching a software creation process; keep in mind that building to change is as much important as building to last and let this fashion the architectural decisions you make.

Configuring Hibernate in Spring Framework.

tl;dr to configure Hibernate in Spring, you need to configure a bean that implements org.hibernate.SessionFactory. Configuring this bean involves specifying the data source, the Object-to-Database mapping (if you using xml for the mapping) and the hibernate properties.

Last post in the Configuring Spring series looked into how to configure data sources, a basic requirement, regardless of the actual method in which your application would communicate with the database server: either via plain JDBC or via an ORM tool.

This post would look into how to configure Spring to use Hibernate. Hibernate is an object-relational mapping library for the Java language, that provides a framework for mapping an object-oriented domain model to a traditional relational database.

In how to configure data sources in Spring, we saw how the data source is the entry point to having your application communicate with a database server; how it is configured and retrieved for use in your application by classes that are specifically created to handle interaction with the database (DAO classes)

In configuring hibernate to work with Spring Framework, the data source still remains the primary entry point, but it would not be what your application code (or DAO class if you go with this pattern) would have to use directly in other to communicate with the database. With Hibernate, your application code requires something called the SessionFactory

So the process of configuring Spring to work with Hibernate is basically then all about configuration the bean that would make the SessionFactory available for you.

Configuring Data Sources in Spring Framework

This is the second post in the configuring Spring series. It kickstarts the database centric configurations required when building an application that persist data with Spring framework. This post talks about configuring data sources.

There are various ways to enable the ability to persist data in your application. From using any of the available Implementation of Java Database Connectivity (commonly referred to as JDBC) to going the ORM route via any of the popular ORM frameworks (Hibernate, MyBatis, Eclipse Link etc )

But with any of the above mentioned method, a data source is always a requirement; because...well you need to have a source to the data if you want to persist and/or retrieve data. And in Spring the data source ends up as a Bean that you would configure.

Spring provides several options of configuring the data source. You can have:

1. Data sources that are provided via JNDI.
2. Data sources that work with JDBC drive.
3. Data sources that are from a connection pool.

But before we go ahead to look at configuration proper, it would be useful to quickly define some basic concepts you would encounter when dealing with persistency:

The Difference between ServletContext and ServletConfig

The servletContext is used to provide configuration that would be available to all servlets in a web application, while servletConfig is used to provide configuration per servlet level.


Specifying and retrieving servletContext configurations.

To specify servletContext configuration, you do so in your web.xml via the <context-param/> tag. For example:

<context-param>
<param-name>timeout</param-name>
<param-value>60</param-value>
</context-param>

and to retrieve these parameters in any of the defined servlets you have:

String value = getServletContext().getInitParameter("timeout");

Specifying and retrieving servletConfig configurations.

Since servletConfig are available per servlet, the definition is within the servlet definition in the web.xml. This is done using the <init-param/> tag.

<servlet>
    <servlet-name>Polling Servlet</servlet-name>
    <servlet-class>com.foo.pollServlet</servlet-class>
    <init-param>  
        <param-name>timeout</param-name> 
        <param-value>60</param-value> 
    </init-param> 
</servlet>

With this, the specified parameters are only available in the com.foo.pollServlet servlet and can be retrieved by:

String value = getServletConfig().getInitParameter("timeout");

Left to me, I would say the not so intuitive choice of words, used to describe these two configuration type, is the cause of confusion most people usually have. I would rather have had the configurations per servlet level called servletConext while configurations that are on the web app level (that are available to all servlet) called appContext or webappContext.

Configuring Beans in Spring Framework.

This is the first post in the Configuring Spring Series.

Beans in Spring framework are proxies implementation of your classes. And following the Inversion of Control way of doing things, they are managed by the Spring framework container and made available for you to use.

Meaning you basically write your classes like you would normally do when programming in Java. After which, you then need to go through a process of configuration that would guide Spring regarding how your classes would be transformed into managed beans which you can then use to form your business logic.

There are different ways to have this configuration set up. And this post, first in the series of many, that would cover some of the configuration tasks in Spring, covers how to configure Spring to take your classes and have it turned into beans. This process is normally referred to as Bean wiring.

We would look at

1. Configuration via XML
2. Configuration via Java Classes: JavaConfig
3. Configuration via @Component and @Autowired Annotation

Configuring Spring Series

Configuring stuff can be overwhelming when you first start off with Spring framework. You spend an awful amount of time wiring things up and configuring before you actually get to start writing business code to solve the problem you are faced with...

Want to start using SpringMVC? there is a configuration for setting this up. Spring Security? There is a configuration for that. Want to use AOP, then you need to know how to have this configured. Want to access a database? You have to first wire up the datasource, the adapter etc etc

This can feel just too much.

It would fast became obvious to anyone using Spring that in other to get productive, configuration is something that is needed to be sorted out and have nicely filed away in a easily retrievable mental model so as to avoid losing precious time fighting the configurations or falling into configuration mishaps that could be a drag on productivity.

The posts that would follow under a series I called configuring spring is my attempt to do just that. It would be series of posts that covers some of the basic configuration hoop I have needed to jump over before I could get to actual development. And since I have a terrible, horrible memory, these posts would be a place I can also easily run to, to look up how a particular configuration needs to be wired.

This post would serve as an index and would be updated as I add to the series.

Posts so far:

1. Configuring Beans in Spring Framework
2. Configuring Data Sources in Spring for Database Access
3. Configuring Hibernate in Spring
4. Configuring Hibernate JPA in Spring Framework
5. Configuring Spring MVC
6. Configuring Spring Data JPA
7. Configuring Aspects with Spring AOP