If you really had the choice, would you pick cronyism over meritocracy? Even in today's enlightened society, where productivity and efficiency are very desirable traits in both the public and private sectors, one can still find cronyism. In my opinion, cronyism is the undesirable side effect of relying too much on who you know, or who knows you.
Many of us have heard that it is not as much what you know that gets you a job, but instead, who you know. So we network to increase our chances of success when seeking employment. Living in Richmond, VA, I can attest to this notion. The Richmond IT community is very small and somewhat incestuous when it comes to employment. It's hard to find someone new in our IT community that a 1st, 2nd, or 3rd degree contact has not at least heard of or knows outright.
I have had more success researching and networking opportunities through friends then applying coldly through an online job site. In fact, online job sites are mainly used for finding the jobs. Once the job is located, one is better off if they research where the job is and skip the online job site, or least follow-up through networking channels.
As long as a candidate is qualified for a position, checking his or her credentials through mutual contacts is not necessarily a bad move. LinkedIn and Facebook have become the De facto method of choice for researching contacts. In fact, my current position was the result of a LinkedIn search, followed by a check on me by a recruiter. The recruiter looked at my LinkedIn profile and asked folks in her office if they new me. Luckily, someone that she solicited feedback from not only knew me and my work, but was able to give me a good recommendation. This all happened unbeknown to me, but I would still consider it networking, albeit anonymous and unsolicited networking.
While personal contacts are valuable, they are certainly no substitute for technical interviews. However, I have witnessed numerous times where interviews are not even granted for candidates that do not pass the litmus test that anonymous networking has become.
On the flip side, this approach goes horribly wrong when it devolves into cronyism. Cronyism is when a person exhibits unwarranted partiality towards a friend of theirs and places that friend into a job or other position of authority based solely (or mainly) on that friendship and not on what should be considered: technical and cultural fitness for the position.
I recently witness unbridled cronyism. It was so blatant that it is both sickening and comical at the same time. In order to protect the innocent (and the guilty) I will not name names here. Suffice it to say that it was a commercial, C-level executive that passed on an otherwise very qualified individual, in order to satisfy a false sense of loyalty to a peer that was in fact instrumental in the cronyism. This peer was another executive that was staffing an already ailing IT organization with only folks that he knew. No one outside his circle of contacts had a chance. This even went as far as involving HR to interview folks, while the executives knew all along that only candidates from within the so-called "inner circle" were worthy. At the least this was disrespectful to the candidates that came in for a false interview. At the most, it was immoral and possibly even illegal. Plausible deny-ability would most likely prevent the latter from being true.
At the end of the day, the process is broken when cronyism is involved. We have all witnessed it in the news, and we have frowned on those political figures that got caught in cronyism-related scandals. Yet, this doesn't stop some folks from exercising their rights to compromise their own integrity and that of their organizations by participating in practices that they know are both morally bankrupt and, at the end of the day, counter intuitive to successful long term execution of human resource management and staffing.
These folks no longer deserve the mantle of authority and leadership that has so falsely been granted them. If all is right in the world, this poor decision making will, in the end, bring the house of cards that was built so haphazardly, by embracing poor hiring practices, down on their collectively empty skulls. Moreover, they will find themselves without redress when they have to explain to their management why they ignored qualified candidates to hire poor performing friends. It may take a while for this to happen, but "nature abhors a vacuum", and equilibrium will be achieved. One can only hope to be around to see the imbalance between stupidity and intelligence righted.
Sunday, January 22, 2012
Thursday, January 12, 2012
Lotus Notes: One of the First NoSQL Databases - No Really!
Depending on who you talk to, NoSQL means NO SQL at all or Not-Only SQL. I like the latter meaning as I find it makes the technology more flexible and adoptable for those that have primarily worked with SQL databases. Regardless of the meaning, there are over 100 databases that can be labeled as NoSQL. These databases range from wide-column , document storage, and key-value tuple stores to object stores and graph databases, with several types in between. Included in this list of 100+ NoSQL databases is Lotus Notes/Domino.
I started working with Lotus Notes in the early 90's, right after I started with HTML and VB. Back then it a was a great tool to allow remote users to collaborate on common data, via replication. Over the years (more than a decade) Notes evolved to include the Domino server-side technology, while including a host of other technology integration: HTML, Java, C, C++, JavaScript, XML, Web Services, etc. In fact, Lotus Notes was my springboard to move to Java.
To me, the two biggest strengths of Lotus Notes/Domino were its approach to non-structured data storage, and its replication technologies. There are a whole host of other Domino features that make the platform very robust, such as agents, routing, and security, not to mention the robust HTTP stack.
Notes has been much maligned over the years as being mostly a productivity tool or email tool. However, I was very happy working with Lotus Notes/Domino. I think there are several reasons for the bad press surrounding Lotus Notes. My top four reasons are below:
1. IBM's incredible (dare I say colossal) mismanagement of the Lotus brand, especially in the wake of the WebSphere brand
2. The lack of standards and design patterns, as well as documented ALM for Lotus Notes development (at one point I heard Notes referred to as a virus).
3. The lack of forward momentum on modernizing client and web UI tools
4. The lack of management understanding what Lotus Notes was and wasn't, while developers tried to make every solution a nail to be handled by the Notes hammer.
However much I lament the downward slide of Lotus Notes, there is truth to my NoSQL claim.
Notes stores data in documents, or more precisely, notes. There are also design notes (forms, views, etc.) and administrative notes (ACL and replication). Based on that alone I would label it a document-based NoSQL database.
In Notes, the container model is quite simple. Items contain data, notes (document notes) contain items, and database (NSF files) contain notes. Items are of two types, summary and non-summary. For the most part, only summary data can be displayed in a Notes view. Non-summary data, while accessible at the note level, is generally not seen in a Notes view. Notes views don't really contain document notes as much as they collect and index them. Using views, designers can build views into Notes data based on the need of users and the data contained in document notes. In this way, they are somewhat similar to views found in relational databases.
Non-summary items are those items usually bigger than 60K and/or composite, like rich text items. These items can contain rich text, file attachments, images, multimedia, etc.
Notes forms are generally used to create, edit, and view document notes in the UI. To that end, forms are designed for those functions with fields added to the forms to contain the data when document notes are displayed or edited in a form. Forms contain fields, however, fields are not the same as items. Items contain data, fields will temporarily show and allow editing of item data when the form is used to open a document note. However, document notes can and do contain items that don't exist on any forms. Multiple forms can be used to view or edit document notes. In this fashion, forms are actually decoupled from document notes. While document notes are item, and therefore data, containers, forms are merely the template used to view, edit, or create documents.
Forms are mostly UI concerns. In fact, items contained in document notes can be, and often are, mutated, without forms. Moreover, document notes can be created without ever using a form.
So, in the grand scheme of things, Lotus Notes, at its core, is a document-based NoSQL database for unstructured data. You can store data within documents. These documents can be related (or not) by data contained in items. These items can be summary (simple) data or non-summary (composite) data. Notes forms and views can be used to enter data (including tags and metadata) and view collections or related documents. Notes replication ensures that documents contained in one database instance can be eventually synchronized with data in another Notes database with the same replica ID.
Given these features, which are comparable to many other NoSQL databases, Lotus Notes NoSQL is a reality, now.
I started working with Lotus Notes in the early 90's, right after I started with HTML and VB. Back then it a was a great tool to allow remote users to collaborate on common data, via replication. Over the years (more than a decade) Notes evolved to include the Domino server-side technology, while including a host of other technology integration: HTML, Java, C, C++, JavaScript, XML, Web Services, etc. In fact, Lotus Notes was my springboard to move to Java.
To me, the two biggest strengths of Lotus Notes/Domino were its approach to non-structured data storage, and its replication technologies. There are a whole host of other Domino features that make the platform very robust, such as agents, routing, and security, not to mention the robust HTTP stack.
Notes has been much maligned over the years as being mostly a productivity tool or email tool. However, I was very happy working with Lotus Notes/Domino. I think there are several reasons for the bad press surrounding Lotus Notes. My top four reasons are below:
1. IBM's incredible (dare I say colossal) mismanagement of the Lotus brand, especially in the wake of the WebSphere brand
2. The lack of standards and design patterns, as well as documented ALM for Lotus Notes development (at one point I heard Notes referred to as a virus).
3. The lack of forward momentum on modernizing client and web UI tools
4. The lack of management understanding what Lotus Notes was and wasn't, while developers tried to make every solution a nail to be handled by the Notes hammer.
However much I lament the downward slide of Lotus Notes, there is truth to my NoSQL claim.
Notes stores data in documents, or more precisely, notes. There are also design notes (forms, views, etc.) and administrative notes (ACL and replication). Based on that alone I would label it a document-based NoSQL database.
In Notes, the container model is quite simple. Items contain data, notes (document notes) contain items, and database (NSF files) contain notes. Items are of two types, summary and non-summary. For the most part, only summary data can be displayed in a Notes view. Non-summary data, while accessible at the note level, is generally not seen in a Notes view. Notes views don't really contain document notes as much as they collect and index them. Using views, designers can build views into Notes data based on the need of users and the data contained in document notes. In this way, they are somewhat similar to views found in relational databases.
Non-summary items are those items usually bigger than 60K and/or composite, like rich text items. These items can contain rich text, file attachments, images, multimedia, etc.
Notes forms are generally used to create, edit, and view document notes in the UI. To that end, forms are designed for those functions with fields added to the forms to contain the data when document notes are displayed or edited in a form. Forms contain fields, however, fields are not the same as items. Items contain data, fields will temporarily show and allow editing of item data when the form is used to open a document note. However, document notes can and do contain items that don't exist on any forms. Multiple forms can be used to view or edit document notes. In this fashion, forms are actually decoupled from document notes. While document notes are item, and therefore data, containers, forms are merely the template used to view, edit, or create documents.
Forms are mostly UI concerns. In fact, items contained in document notes can be, and often are, mutated, without forms. Moreover, document notes can be created without ever using a form.
So, in the grand scheme of things, Lotus Notes, at its core, is a document-based NoSQL database for unstructured data. You can store data within documents. These documents can be related (or not) by data contained in items. These items can be summary (simple) data or non-summary (composite) data. Notes forms and views can be used to enter data (including tags and metadata) and view collections or related documents. Notes replication ensures that documents contained in one database instance can be eventually synchronized with data in another Notes database with the same replica ID.
Given these features, which are comparable to many other NoSQL databases, Lotus Notes NoSQL is a reality, now.
Tuesday, December 6, 2011
Dynamic Groovy Edges and Regression Isolation
In JEE application architecture, components are grouped into functional layers. In a typical multi-tier enterprise web application, there are N layers, N-1 layer junctions, and (N-1) x 2 layer edges. In the diagram below, for example, there are three layers, two layer junctions, and four layer edges.
Designing and implementing interfaces between application layers can be painful, especially if you don't have a span of control or even influence design and/or implementation. Interfaces are notorious change zones. Even with well-defined interface contracts, development teams are routinely confronted with interface changes that require quick turnaround times, compounded by development, test, and deployment overhead.
If we examine why we have interfaces in the first place, we soon realize that we need interoperability (data sharing) between different systems. It would be desirable to design systems with intrinsic interoperability, but that is a lofty goal that is seldom realized outside of SOA boundaries. No, we have different datasets in different systems. So we have interfaces.
It is not only the data that is different, the pace with which different systems and layers evolve is also different. Junctions are by default, separations between different layers changing at different paces. For example, the web presentation layer changes rapidly, as the services layer more slowly and the data layer even slower still. In architecture, we design with "pace layering" in mind, so that we can provision the appropriate interfaces to allow for change, for evolution, at different paces.
If the reader is interested in "pace layering", here is one of the best descriptions of Pace Layering, from Donna Maurer, that I have ever read:
Lately our teams have been looking at creative ways to use existing Java technologies to create more nimble application interface edges. The first step was to ask ourselves, what Java tool allows us to quickly change code without having to redeploy our applications?
My first thought was JRebel from Zero Turnaround. Using JRebel, developers can "instantly see any code change made to an app without redeploying." However, unless I am mistaken, JRebel is primarily for non-production use. There may be valid reasons to use JRebel in production systems. However, I have never worked on a project where that type of JVM manipulation was allowed in production, especially triggered from developer desktops. There is usually so much bureaucracy and change control processes to tangle with.
Redeploying an application contained in an EAR or WAR to production is the choice of last resort. On top of the overhead of following the proper change control processes (ITIL anyone), there is the large regression analysis and testing that needs to happen. It would be great if we could isolate the most dynamic areas of our application (interfaces), so that we could change them in reaction to external changes beyond our control. It would also be desirable to make these changes in an isolated manner so as not to require an EAR or WAR redeployment.
To solve this dilemma, the initial knee-jerk reaction is to write so-called "smarter" interfaces to account for known possible changes. That approach will only get you so far. Nay, the solution to this muddle is to step back and unlearn what we thought we learned earlier in our careers. Actually, the approach that I am getting ready to espouse is similar to the Dale Carnegie approach to handling problems. The one thing that stuck with me from my class on Human Relations was to consider the worst scenario, accept that scenario if you could not prevent it, and then plan on a mitigation strategy.
So, the worst case scenario is that our interfaces will change; systems will evolve at different paces and our junctions will be affected. Accept that which we cannot change. Now, how do we make this situation better? Well, do what we already know how to do: write code to satisfy the change. For JEE applications, this means writing Java...or does it? What if we could write code that would execute as Java byte code in the JVM, but would not require us to redeploy our entire application. That would be Groovy. Yes, the pun was intended.
No matter what you think about the Groovy language, it does offer a solution to our dilemma, provided that we also include certain other "standard" components. First, the solution is seen below. we are talking about creating dynamic groovy edges. With "Groovy Edges" our interfaces are now bracketed by dynamic code components that can actually be isolated from the rest of the application stack.
What is it about Groovy that best suits it for this task?
The solution starts with a JRockit JVM. Since we will be parsing and compiling Groovy scripts at run-time to execute in the JVM, there will be some impact to class-loading resources. Unfortunately, for this solution, Hotspot is not adequate, unless of course we define huge heaps with huge permgens in a 64 bit environment. However, the Java 7 JVM shows promise with how it manages class-loading resources.
Next we need Spring; that should be no issue as many JEE applications use Spring. Spring allows us to leverage Spring Bean Factory configurations to point to where our "Groovy Beans" scripts are stored. For this solution, we will store these Groovy scripts outside of the JEE EAR (or WAR) files to preclude the need for deployments when the Groovy changes, and reduce application-wide regression testing and analysis.
In the code snippet above, the SpringBean "GroovyEdgeObject" is loaded from a URL that is resolved by the Spring EL in the "script-source" attribute. The "refresh-check-delay" attribute is set to refresh the object in Spring's IOC container every second if changes in the script are detected between object method calls. With this approach we could store the remote scripts in a CMS or even Amazon Simple Storage Service (S3). The key point is that the Groovy script is stored outside of our typical regression boundary. And, Spring will take care of updating the IOC container when changes are detected in the script.
There is additional magic happening with the Spring EL value in the "script-source" attribute above. This argument, "${groovyInterfaceEdge}", is known as a property placeholder. Spring uses the "PropertyPlaceholderConfigurer" to load a properties file and then get values from that properties file that match the placeholder keys in bean definitions.
In the code just above, the services.properties file is loaded from the classpath and the key/value pairs are made available to bean definition attributes using Spring EL placeholders. So, "${groovyInterfaceEdge}" is resolved to a value in the services.properties file found on the application classpath. In this example, the "${groovyInterfaceEdge}" would resolve to a URI that can be accessed via the application to load the Groovy script stored in the remote script storage facility.
In this example, the Groovy script is accessible via a web URI. Depending on how the CMS is configured in your environment, it may not provide this URI access to all resources. In this case, we would build and configure a "Content Proxy" that could use the API supplied by the CMS vendor to get at the script on the behalf of the Spring Bean Factory. When a content proxy is used, the URI resolved by the Spring EL placeholder and PropertyPlaceholderConfigurer API would be an endpoint.
The code just above is an example of just such a content proxy, though mileage may vary depending on what flavor of CMS is used. This class, along with the Jersey REST API creates a RESTful web service endpoint that will take in content proxy requests and return the script file from the CMS. The REST approach is well suited for this type of service, where we simply want to parse the URI components to get at the parameters of the service call.
Putting it altogether, the services.properties file entry above shows how we would configure the URI to call the RESTful content proxy endpoint. This URI is then returned to the Spring Bean Factory when the Groovy Bean is asked for by the application. The content proxy returns the Groovy script file (*.groovy) to the application where the Groovy class loader takes care of loading into the JVM for use by the application.
With this solution, we have used convention and well known frameworks to build a sustainable and dynamic interface edge framework. However, this solution opens up many other possibilities for our applications. There may be other areas where we would like to load Spring Beans that are dynamic, so that we can change key behavior of volatile areas within our application without having to incur the load or redeployment and major regression testing.
Designing and implementing interfaces between application layers can be painful, especially if you don't have a span of control or even influence design and/or implementation. Interfaces are notorious change zones. Even with well-defined interface contracts, development teams are routinely confronted with interface changes that require quick turnaround times, compounded by development, test, and deployment overhead.
If we examine why we have interfaces in the first place, we soon realize that we need interoperability (data sharing) between different systems. It would be desirable to design systems with intrinsic interoperability, but that is a lofty goal that is seldom realized outside of SOA boundaries. No, we have different datasets in different systems. So we have interfaces.
It is not only the data that is different, the pace with which different systems and layers evolve is also different. Junctions are by default, separations between different layers changing at different paces. For example, the web presentation layer changes rapidly, as the services layer more slowly and the data layer even slower still. In architecture, we design with "pace layering" in mind, so that we can provision the appropriate interfaces to allow for change, for evolution, at different paces.
If the reader is interested in "pace layering", here is one of the best descriptions of Pace Layering, from Donna Maurer, that I have ever read:
Complex systems can be decomposed into multiple layers, where the layers change at different rates. The “fast layers” learn, absorb shocks and get attention; the “slow layers” remember, constrain and have power. One of the implications of this model is that information architects can do what they have always done–slow, deep, rich work; while tagging can spin madly on the surface. If it is worth keeping, it will seep down into the lower layers.I agree with Isaac Asimov: "The only constant is change..." And, it is difficult to design for constant change. You just can't code for every event that could possibly happen. Applications would be woefully bloated and impossible to maintain. So, we must embrace change, and plan the best methods for reacting to change. In JEE applications, the best method is the one that introduces the least amount of change to the overall application. We must also avoid regression loads, during change, if possible.
Lately our teams have been looking at creative ways to use existing Java technologies to create more nimble application interface edges. The first step was to ask ourselves, what Java tool allows us to quickly change code without having to redeploy our applications?
My first thought was JRebel from Zero Turnaround. Using JRebel, developers can "instantly see any code change made to an app without redeploying." However, unless I am mistaken, JRebel is primarily for non-production use. There may be valid reasons to use JRebel in production systems. However, I have never worked on a project where that type of JVM manipulation was allowed in production, especially triggered from developer desktops. There is usually so much bureaucracy and change control processes to tangle with.
Redeploying an application contained in an EAR or WAR to production is the choice of last resort. On top of the overhead of following the proper change control processes (ITIL anyone), there is the large regression analysis and testing that needs to happen. It would be great if we could isolate the most dynamic areas of our application (interfaces), so that we could change them in reaction to external changes beyond our control. It would also be desirable to make these changes in an isolated manner so as not to require an EAR or WAR redeployment.
To solve this dilemma, the initial knee-jerk reaction is to write so-called "smarter" interfaces to account for known possible changes. That approach will only get you so far. Nay, the solution to this muddle is to step back and unlearn what we thought we learned earlier in our careers. Actually, the approach that I am getting ready to espouse is similar to the Dale Carnegie approach to handling problems. The one thing that stuck with me from my class on Human Relations was to consider the worst scenario, accept that scenario if you could not prevent it, and then plan on a mitigation strategy.
So, the worst case scenario is that our interfaces will change; systems will evolve at different paces and our junctions will be affected. Accept that which we cannot change. Now, how do we make this situation better? Well, do what we already know how to do: write code to satisfy the change. For JEE applications, this means writing Java...or does it? What if we could write code that would execute as Java byte code in the JVM, but would not require us to redeploy our entire application. That would be Groovy. Yes, the pun was intended.
No matter what you think about the Groovy language, it does offer a solution to our dilemma, provided that we also include certain other "standard" components. First, the solution is seen below. we are talking about creating dynamic groovy edges. With "Groovy Edges" our interfaces are now bracketed by dynamic code components that can actually be isolated from the rest of the application stack.
- Groovy can be written as a script and parsed at run-time and compiled into Java byte-code and then loaded by the Groovy class loader.
- Groovy scripts can contain Groovy and Java syntax in the script file (*.groovy).
- Groovy can use the same Java APIs that are used by traditional Java code.
Next we need Spring; that should be no issue as many JEE applications use Spring. Spring allows us to leverage Spring Bean Factory configurations to point to where our "Groovy Beans" scripts are stored. For this solution, we will store these Groovy scripts outside of the JEE EAR (or WAR) files to preclude the need for deployments when the Groovy changes, and reduce application-wide regression testing and analysis.
<!-- insert the following for debugging - refresh-check-delay="1000" -->
<lang:groovy id="GroovyInterfaceEdge" script-source="${groovyInterfaceEdge}" refresh-check-delay="1000" >
<lang:property name="key" value="value"/>
</lang:groovy>
In the code snippet above, the SpringBean "GroovyEdgeObject" is loaded from a URL that is resolved by the Spring EL in the "script-source" attribute. The "refresh-check-delay" attribute is set to refresh the object in Spring's IOC container every second if changes in the script are detected between object method calls. With this approach we could store the remote scripts in a CMS or even Amazon Simple Storage Service (S3). The key point is that the Groovy script is stored outside of our typical regression boundary. And, Spring will take care of updating the IOC container when changes are detected in the script.
There is additional magic happening with the Spring EL value in the "script-source" attribute above. This argument, "${groovyInterfaceEdge}", is known as a property placeholder. Spring uses the "PropertyPlaceholderConfigurer" to load a properties file and then get values from that properties file that match the placeholder keys in bean definitions.
<!-- Read service related properties from the classpath -->
<bean id="services.propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location">
<value>classpath:services.properties</value>
</property>
</bean>
In the code just above, the services.properties file is loaded from the classpath and the key/value pairs are made available to bean definition attributes using Spring EL placeholders. So, "${groovyInterfaceEdge}" is resolved to a value in the services.properties file found on the application classpath. In this example, the "${groovyInterfaceEdge}" would resolve to a URI that can be accessed via the application to load the Groovy script stored in the remote script storage facility.
In this example, the Groovy script is accessible via a web URI. Depending on how the CMS is configured in your environment, it may not provide this URI access to all resources. In this case, we would build and configure a "Content Proxy" that could use the API supplied by the CMS vendor to get at the script on the behalf of the Spring Bean Factory. When a content proxy is used, the URI resolved by the Spring EL placeholder and PropertyPlaceholderConfigurer API would be an endpoint.
package com.ironworks.restwebservice.content;
import java.io.InputStream;
import java.text.SimpleDateFormat;
import javax.servlet.http.HttpServletResponse;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.UriInfo;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import com.bea.content.AuthenticationException;
import com.bea.content.AuthorizationException;
import com.bea.content.ContentContext;
import com.bea.content.NoSuchPropertyException;
import com.bea.content.Node;
import com.bea.content.Property;
import com.bea.content.RepositoryException;
import com.bea.content.expression.Search;
import com.bea.content.federated.ContentManagerFactory;
import com.bea.content.federated.INodeManager;
import com.bea.content.federated.ISearchManager;
import com.bea.content.paging.ContentListKeys;
import com.bea.content.paging.ISortableFilterablePagedList;
//NEXT 999 LINES SUPPRESS LineLength
@Path("/contentProxy")
public class ContentProxy {
@Context
UriInfo uriInfo;
private static final Log log = LogFactory.getLog(ContentProxy.class);
private static SimpleDateFormat dateFormat = new SimpleDateFormat("EEE, dd MMM yyy HH:mm:ss z");
@GET
@Path("/{directory}/{nodename}")
@Produces(MediaType.TEXT_HTML)
public final InputStream contentLookup(
@PathParam("directory") final String directory,
@PathParam("nodename") final String nodename,
@Context HttpServletResponse response) {
final Search search =
new Search("/WLP Repository/" + directory, -1, "",
" cm_nodeName= '" + nodename + "'");
final ISearchManager searchManager =
ContentManagerFactory.getSearchManager();
final INodeManager nodeManager = ContentManagerFactory.getNodeManager();
final ContentContext cc = new ContentContext();
cc.setParameter(ContentListKeys.BATCH_LOADING_SIZE_KEY, -1);
ISortableFilterablePagedList<Node> results = null;
try {
results = searchManager.search(cc, search);
} catch (Exception anything) {
// fatal. We cannot handle it.
throw new RuntimeException(anything);
}
for (Node oneNode : results) {
try {
if (oneNode.getProperty("copy").getType() == Property.BINARY) {
response.setHeader("Last-Modified", dateFormat.format(oneNode.getModifiedDate().getTime()));
return nodeManager.getStream(new ContentContext(),
oneNode.getId(), "copy");
}
} catch (AuthorizationException e) {
e.printStackTrace();
} catch (AuthenticationException e) {
e.printStackTrace();
} catch (NoSuchPropertyException e) {
e.printStackTrace();
} catch (RepositoryException e) {
e.printStackTrace();
}
}
return null;
}
}
The code just above is an example of just such a content proxy, though mileage may vary depending on what flavor of CMS is used. This class, along with the Jersey REST API creates a RESTful web service endpoint that will take in content proxy requests and return the script file from the CMS. The REST approach is well suited for this type of service, where we simply want to parse the URI components to get at the parameters of the service call.
groovyInterfaceEdge=http://<HOST>/restServices/contentProxy/scripts/groovyInterfaceEdge
Putting it altogether, the services.properties file entry above shows how we would configure the URI to call the RESTful content proxy endpoint. This URI is then returned to the Spring Bean Factory when the Groovy Bean is asked for by the application. The content proxy returns the Groovy script file (*.groovy) to the application where the Groovy class loader takes care of loading into the JVM for use by the application.
With this solution, we have used convention and well known frameworks to build a sustainable and dynamic interface edge framework. However, this solution opens up many other possibilities for our applications. There may be other areas where we would like to load Spring Beans that are dynamic, so that we can change key behavior of volatile areas within our application without having to incur the load or redeployment and major regression testing.
Thursday, December 1, 2011
Richmond Times Dispatch - 2011 state employee salary database - AGAIN!
I received this email from the RTD:
The Times-Dispatch and TimesDispatch.com will publish our annual report on state employee salaries this Sunday, Dec. 4. This year's searchable database includes salaries for all 104,554 state employees, including names and positions for all employees who earn above the state's average of $52,547.
They did the same thing last year. Here is how I felt last year when I was a state employee caught up in this database:
On LinkedIn.com you refer to your company as “the leading provider of high-quality news…in central Virginia.” I think at best that claim is suspect, and at worst, you are providing false panoply of episodic capabilities to the public, to hide the depth of your desperation to remain a viable news source. The Richmond Times-Dispatch has a few redeeming qualities, but taken in aggregate you offer very little to your customers that they could not more freely obtain from a multitude of other online outlets. There are times when publishing FOIA information is warranted; however, this is not one of them, at least not in its current form. It is especially unwarranted when the purpose is to fuel a negative agenda. In economically challenging times, Federal and State employees are easy targets for efficiency and effectiveness ratings. However, I submit that there are many employees that work very hard and that would and could make more money should they move to the private sector and leave public service behind. Your irresponsible action in publishing the salaries of state employees, SEARCHABLE BY NAME, smacks of arrogance and sensationalism and is bereft of any dignity or integrity that your newspaper claims to still retain. As far as I am concerned, my name in the context of my agency and position is “Personally Identifiable Information” and as such should not be used.
The damage of your actions far outweighs the value delivered to your readers and the general public. There is absolutely no constructive reasoning that justifies listing employees names in your database. From your actions it is clear that you completely disregarded the negative impact that such a database would have on state employees. These same state employees are also your customers. With this contemptible action, your organization is morally and ethically bankrupt, and you owe your readers an apology for wasting their time with such twaddle.
I would be very interested to know the salaries of each of your employees making over $50K, as well as their job titles. And of course, I would need the names of said employees to more easily target my public disdain for your obviously poor value proposition and the gross mismanagement of your financial resources. If that makes no sense to you, then you now realize the situation in which thousands of state employees find themselves, without redress. I am sure that your employees would not mind; after all, your customers are paying you for your information services. Do they not have the right to get the best value for their money? Are not the salaries of your employees just more information about which someone, somewhere would want to read? Is that not how you choose to publish these days? Of course you need not answer these rhetorical questions; your actions speak volumes about your motivations.
Just because you can, should not be a license to pursue a course of action that has no real probative or news value and genuinely provides a divisive tool for someone’s personal agenda. Your misguided exploit is completely irresponsible and in my opinion an abuse of said state employees, your customers, and the spirit of the Freedom of Information Act. It is also an abuse of your power and a misuse of your first amendment rights. Furthermore, your actions underpin my long held belief that nothing useful comes from your disgraceful and at times, Yellow-Journalistic tabloid. You may have temporarily boosted your circulation or at best your web site traffic, but you have undoubtedly isolated yet another large customer segment and undermined the public’s trust. Moreover, if more of your readers were affected by this debauched deed you would undoubtedly apologize or even redact said folly. Indeed, you misunderstand, in entirety, the meaning of cultivating long-term customer value and loyalty. This entire episode has been a tactless and colossal waste of our time and attention. You may be the press, but you are also a business. I think you should cease acting as the self-anointed herald of worthless hokum and actually cover creditable news that makes our lives better and provides at least a modicum of value to your customers. However, if you are disinclined to act appropriately, one can only hope that your readers recognize how shallow, foul, and jaded you have become and move on to better outlets of information. For myself, I am almost giddy with the thought that I do not have a subscription to your worthless paper. I now find it less than suitable to line the bottom of my dog’s crate!
Thursday, November 10, 2011
JEE Developers: Embrace the Polyglot in You
Are you a polyglot programmer? The term almost has a guttural pronunciation. In short, a polyglot person has the ability to speak multiple languages. So, a polyglot programmer is one who can write code in multiple languages. Most programmers I know are polyglots out of necessity or career evolution. I started out with BASIC, then moved to LabVIEW, HTML, Visual Basic and even Lotus Notes, settling into Java and its cohorts later on. Along the way I wrote C and C++ when the need arose, as well as the suite of UNIX/Linux scripting languages (Perl, Korn, Python, etc.).
Most of us have started out in one language only to switch later to more modern, and/or more expressive languages. Occasionally we may digress, if the situation calls for older skills, but in general we have moved forward, building on previous knowledge. I can hear some of you saying right now that true expertise takes years to build. I can agree with that, to a degree. It should take years to become an expert in some languages or technologies. However, expertise is a relative term, and it should not take decades. Furthermore, most projects don't staff all experts; there is room for intermediate levels as well.
There are those that have stayed with older languages, for whatever reasons; comfort not being the least of these. However, it seems to be harder for those individuals to adapt to modern needs, and that makes them less desirable to recruiters. To remain relevant, we need to stretch outside our comfort zones. Stories are legion these days of folks searching for work, only to find out that their skills are simply outdated. When I hire, I try to hire for organizational fit first and then skills second. However, in this economy, recruiters are buyers in a buyer's market. Some would say, that without the correct buzzwords on resumes or applications, otherwise competent resources are getting overlooked and ignored. I would say that the skills of these programmers have become less relevant. As one of my friends would say, "They may have placed themselves in a position to be unlucky." If your skills are no longer relevant to the strategy of your company or its competitive advantage, you may be unlucky sooner than you would like.
I say embrace the polyglot way. A good software architect chooses the right systems or layers for the right processing. Polyglots are not only able to understand the code, they frequently write the code in those different systems or layers. For example, in Oracle, if you need to process large data sets in a iterative and procedural manner, use PL/SQL. PL/SQL also gives you better application management and performance, if done correctly. Do high-level field translation and validation in the HTML form or view layer with JavaScript to enhance the UX. Do more in-depth data validation in the business layer for data quality and security reasons.
As a software developer you can ill afford to dedicate your focus on one language while ignoring the rest. Especially if your language (or framework) has complementary cohorts that are used routinely in application implementation. If you call yourself a JEE developer, then you already have a lot of Java APIs to master. On top of the JEE technologies, you should also know Spring and Hibernate, intimately, including Spring MVC and EL as well as HQL. Groovy is also a good language to know especially if your web application needs dynamic integration, rapid prototyping, and/or can leverage ECMS.
You'd better know SQL, and if you work on Oracle projects, know PL/SQL. If you are writing JEE web applications, know HTML, CSS, and JavaScript. I am not saying that backend developers have to be frontend experts, but one should know what goes on over the fence from them. In fact, for all networked applications, know the protocols you would be using (TCP/IP, HTTP/HTTPS, etc).
If your applications are deployed in a UNIX/Linux environment, know scripting languages. For view-layer integration, know AJAX and JSON. Finally, almost nothing is possible without XML. Do you know what it means to be well-formed and valid? Do you know DTDs and XSDs? Could you translate XML to something else with XSL/XSLT? If you are not developing some sort of web service or other integration with XML you most likely have XML configuration files in your application.
In short don't limit yourself when applying for positions or choosing projects because you only focus on Java or .Net. Know the cohort technologies as well. You don't need to be an expert in all things, just as an IT generalist is also in low demand. You need to balance depth with width. Focus on core technologies, and then be familiar with complementary technologies. Develop more depth in the non-core technologies when you have sufficient comfort level in the core. This is not fake-it-to-you-make-it either. From time to time you will have the opportunity to be a temporary expert in more ancillary technologies or languages or frameworks. You may even develop a temporary monopoly in new technologies or approaches. That is where real value is added to your organization. Even if you can get projects with your older skills, will you be happy with those projects?
If you know enough about the side technologies to spin-up quickly, that should be enough for most projects. Scope the landscape for relevant technologies and then choose wisely when looking to enhance your capabilities. In my experience, it is easier to keep current in these technologies if they are complementary, and if you have the chance to use them for real deliverables. Don't place yourself in a position to be "unlucky". Be cognizant of the relationship between your skills and the strategy of your organization and the direction in which you wish your career to proceed. Embracing the polyglot approach can differentiate you from your contemporaries, making you more relevant to your organization and the job market.
Most of us have started out in one language only to switch later to more modern, and/or more expressive languages. Occasionally we may digress, if the situation calls for older skills, but in general we have moved forward, building on previous knowledge. I can hear some of you saying right now that true expertise takes years to build. I can agree with that, to a degree. It should take years to become an expert in some languages or technologies. However, expertise is a relative term, and it should not take decades. Furthermore, most projects don't staff all experts; there is room for intermediate levels as well.
There are those that have stayed with older languages, for whatever reasons; comfort not being the least of these. However, it seems to be harder for those individuals to adapt to modern needs, and that makes them less desirable to recruiters. To remain relevant, we need to stretch outside our comfort zones. Stories are legion these days of folks searching for work, only to find out that their skills are simply outdated. When I hire, I try to hire for organizational fit first and then skills second. However, in this economy, recruiters are buyers in a buyer's market. Some would say, that without the correct buzzwords on resumes or applications, otherwise competent resources are getting overlooked and ignored. I would say that the skills of these programmers have become less relevant. As one of my friends would say, "They may have placed themselves in a position to be unlucky." If your skills are no longer relevant to the strategy of your company or its competitive advantage, you may be unlucky sooner than you would like.
I say embrace the polyglot way. A good software architect chooses the right systems or layers for the right processing. Polyglots are not only able to understand the code, they frequently write the code in those different systems or layers. For example, in Oracle, if you need to process large data sets in a iterative and procedural manner, use PL/SQL. PL/SQL also gives you better application management and performance, if done correctly. Do high-level field translation and validation in the HTML form or view layer with JavaScript to enhance the UX. Do more in-depth data validation in the business layer for data quality and security reasons.
As a software developer you can ill afford to dedicate your focus on one language while ignoring the rest. Especially if your language (or framework) has complementary cohorts that are used routinely in application implementation. If you call yourself a JEE developer, then you already have a lot of Java APIs to master. On top of the JEE technologies, you should also know Spring and Hibernate, intimately, including Spring MVC and EL as well as HQL. Groovy is also a good language to know especially if your web application needs dynamic integration, rapid prototyping, and/or can leverage ECMS.
You'd better know SQL, and if you work on Oracle projects, know PL/SQL. If you are writing JEE web applications, know HTML, CSS, and JavaScript. I am not saying that backend developers have to be frontend experts, but one should know what goes on over the fence from them. In fact, for all networked applications, know the protocols you would be using (TCP/IP, HTTP/HTTPS, etc).
If your applications are deployed in a UNIX/Linux environment, know scripting languages. For view-layer integration, know AJAX and JSON. Finally, almost nothing is possible without XML. Do you know what it means to be well-formed and valid? Do you know DTDs and XSDs? Could you translate XML to something else with XSL/XSLT? If you are not developing some sort of web service or other integration with XML you most likely have XML configuration files in your application.
In short don't limit yourself when applying for positions or choosing projects because you only focus on Java or .Net. Know the cohort technologies as well. You don't need to be an expert in all things, just as an IT generalist is also in low demand. You need to balance depth with width. Focus on core technologies, and then be familiar with complementary technologies. Develop more depth in the non-core technologies when you have sufficient comfort level in the core. This is not fake-it-to-you-make-it either. From time to time you will have the opportunity to be a temporary expert in more ancillary technologies or languages or frameworks. You may even develop a temporary monopoly in new technologies or approaches. That is where real value is added to your organization. Even if you can get projects with your older skills, will you be happy with those projects?
If you know enough about the side technologies to spin-up quickly, that should be enough for most projects. Scope the landscape for relevant technologies and then choose wisely when looking to enhance your capabilities. In my experience, it is easier to keep current in these technologies if they are complementary, and if you have the chance to use them for real deliverables. Don't place yourself in a position to be "unlucky". Be cognizant of the relationship between your skills and the strategy of your organization and the direction in which you wish your career to proceed. Embracing the polyglot approach can differentiate you from your contemporaries, making you more relevant to your organization and the job market.
Friday, October 7, 2011
PMI CVC PMP 2011 Fall Workshop - Framework Talk
I will be presenting on October 15 for the PMI Central Va Chapter during their Fall 2011 PMI Certification Workshop. My topic will be the Project Management Framework. My talk goes from 10:00 AM to 11:15 AM and touches on items found in sections 1 & 2, chapters 1, 2, & 3, of the PMBOK, version 4.
I have been presenting this topic for the PMI CVC for about a year. In my session I will be discussing these topics and more:
This workshop is a great way to come up to speed for the PMP exam as well as gain valuable study tips from fellow project managers that have already passed the exam. The workshop is also a great opportunity to gain the PDUs needed to maintain existing PMP certifications. Best of all, attendees receive copies of all the slides presented at the workshop as well as other resources to help them study for the exam.
I have been presenting this topic for the PMI CVC for about a year. In my session I will be discussing these topics and more:
- Projects, Portfolios, and Program
- Process Groups, Knowledge Areas, and Processes
- PMO
- Project Life Cycle vs. Product Life Cycle
- Stakeholder Management
- Organizational Structure
This workshop is a great way to come up to speed for the PMP exam as well as gain valuable study tips from fellow project managers that have already passed the exam. The workshop is also a great opportunity to gain the PDUs needed to maintain existing PMP certifications. Best of all, attendees receive copies of all the slides presented at the workshop as well as other resources to help them study for the exam.
Monday, September 26, 2011
Greed is a Terrible Thing - Goodbye to the SCEA
Industry pundits have speculated on Oracle's ability to be stewards for Java. Since when does a good technology steward prevent adoption of said technology? Can you say greedy-failure?
I tried to register for the Oracle Certified Master, Java EE 5 Enterprise Architect (formerly SCEA) certification today. After the initial sticker shock of $900 for the cert, I soon realized that Oracle has increased the price by making it mandatory to take one of their training classes in order to gain this certification. I guess they do this for several of their other certifications. That is another several thousand or so. Mind the reader, they are not requiring that you take all the courses that would teach you about the different technology concerns in the architecture certification. So, where is the value of making candidates take a class if they can choose the simple "Web Component Development with Servlets & JSPs" or "Java Programming Language"? What architect cannot write servlets and JSPs, or not understand their positioning? What architect does not know the difference between HashMap and a Hashtable?
In my opinion, this is a blatant act of greed and a splendid display of stupidity. Oracle (and its mindless sycophants) can certainly argue that this move strengthens the value of this certification. Utter twaddle-speak says I! Pricing a certification to make it unreachable does not make it more valuable to the industry in aggregate; it just makes it unreachable. This benefits no one, but Oracle and those already certified.
I (along with several contemporaries) believe this will severely limit the certification to those of us not already engaged in austerity measures (self imposed or not), brought on by the poor economy. Are those the boundaries that Oracle was actually hoping for? With this callous, and extremely short-sighted folly, they have effectively isolated a segment of Java architects not backed financially by an organization willing to pay the ridiculous expense. They have created a class of Java technologists based solely on monetary funds available to the technologist. Way to go Oracle!
Instead of making the exam more valuable by making it harder to pass (currently you need a 57% to pass the "multiple-guess" exam, part 1 of the exam trilogy) , they seem to be trying to make it more valuable by placing it out of reach, monetarily. Technology is supposed to facilitate the crossing of economic boundaries, not put in place those of its own making. This myopic move will only further dilute the viability of Java as an enterprise solution. There is already a split within the Java community, many of us embracing the simplicity and reuse of the multiple technologies (Spring, Hibernate, Freemarker, Groovy, etc.) not directly espoused by the EE spec and leaving the complexities of EJBs and JSF behind. I mean, I can certainly specify and write EJB 3.x and JSF; I just choose not to in most cases. And do not even get me started on Oracle's WebLogic platform.
Large corporations seem to have a knack for destroying technologies with "kinetic stupidity". IBM and Lotus Notes/Domino anyone? However, isolating an entire segment of your long-time supporters just to make a few more dollars is just a colossal failure. They had an opportunity here to move in a positive direction. In true monolithic fashion, they took the opportunity to miss that opportunity. It seems that they chose to increase their bottom-line at the expense of the community that has bolstered Java for the last decade or so.
I tried to register for the Oracle Certified Master, Java EE 5 Enterprise Architect (formerly SCEA) certification today. After the initial sticker shock of $900 for the cert, I soon realized that Oracle has increased the price by making it mandatory to take one of their training classes in order to gain this certification. I guess they do this for several of their other certifications. That is another several thousand or so. Mind the reader, they are not requiring that you take all the courses that would teach you about the different technology concerns in the architecture certification. So, where is the value of making candidates take a class if they can choose the simple "Web Component Development with Servlets & JSPs" or "Java Programming Language"? What architect cannot write servlets and JSPs, or not understand their positioning? What architect does not know the difference between HashMap and a Hashtable?
In my opinion, this is a blatant act of greed and a splendid display of stupidity. Oracle (and its mindless sycophants) can certainly argue that this move strengthens the value of this certification. Utter twaddle-speak says I! Pricing a certification to make it unreachable does not make it more valuable to the industry in aggregate; it just makes it unreachable. This benefits no one, but Oracle and those already certified.
I (along with several contemporaries) believe this will severely limit the certification to those of us not already engaged in austerity measures (self imposed or not), brought on by the poor economy. Are those the boundaries that Oracle was actually hoping for? With this callous, and extremely short-sighted folly, they have effectively isolated a segment of Java architects not backed financially by an organization willing to pay the ridiculous expense. They have created a class of Java technologists based solely on monetary funds available to the technologist. Way to go Oracle!
Instead of making the exam more valuable by making it harder to pass (currently you need a 57% to pass the "multiple-guess" exam, part 1 of the exam trilogy) , they seem to be trying to make it more valuable by placing it out of reach, monetarily. Technology is supposed to facilitate the crossing of economic boundaries, not put in place those of its own making. This myopic move will only further dilute the viability of Java as an enterprise solution. There is already a split within the Java community, many of us embracing the simplicity and reuse of the multiple technologies (Spring, Hibernate, Freemarker, Groovy, etc.) not directly espoused by the EE spec and leaving the complexities of EJBs and JSF behind. I mean, I can certainly specify and write EJB 3.x and JSF; I just choose not to in most cases. And do not even get me started on Oracle's WebLogic platform.
Large corporations seem to have a knack for destroying technologies with "kinetic stupidity". IBM and Lotus Notes/Domino anyone? However, isolating an entire segment of your long-time supporters just to make a few more dollars is just a colossal failure. They had an opportunity here to move in a positive direction. In true monolithic fashion, they took the opportunity to miss that opportunity. It seems that they chose to increase their bottom-line at the expense of the community that has bolstered Java for the last decade or so.
Subscribe to:
Posts (Atom)