Relatively Prime

Wednesday, June 2, 2010

A unique take on the BP disaster.

Coutland Milloy has an interesting take on our inability to stop the oil leak in the gulf. He argues that in our desire to hold someone accountable for this disaster we are failing to hold our selves accountable, that our expecations of what is possible are completely out of sync with reality, and that our inability to fix the leak is also, partially, caused by our own misplaced priorities:

When it comes to oil, we seem to be stuck in some infantile stage where it's okay to suckle on the gas pump till the well runs dry. We don't care where the oil comes from, and we'll do anything to get it. Boycott BP? You've got to be kidding. Our appetite is insatiable, and now that gorging has got us in trouble we want Obama to burp us and jump-start our sense of outrage.

Outrage at anybody other than ourselves, of course.

Listen to how incessantly we complain about nobody coming to our rescue. Conditioned by disaster movies to have heroes show up within 90 minutes or so, we are beside ourselves that 44 days have passed and oil is still gushing into the gulf. At this rate, with no end to the leakage expected before August, what is already the worst environmental disaster in U.S. history could come to be regarded as the American Chernobyl, with consequences lasting well into the next century.

The boomers can express faux indignation: If we can put a man on the moon, why can't we fix a busted oil pipe? Could the answer be that we have become a generation of slackers in science and math that grown-ups have been warning about for decades? Can our generation even field a team of engineers smart enough to cap the well -- or do we have to call the help line in India for that, too?

Posted via email from Relatively Prime

Wednesday, May 19, 2010

Netbeans 6.8, Weblogic 10.3.3 and JAX-WS = WSP_1014_POLICY_REFERENCE_DOES_NOT_EXIST

I recently used Netbeans to generate a JAX-WS web service and attempted to deploy it to Weblogic 10.3.3 the result was this :

<May 19, 2010 9:45:17 AM EDT> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to STARTING> May 19, 2010 9:45:22 AM com.sun.xml.ws.transport.http.servlet.WSServletContextListener contextInitialized INFO: WSSERVLET12: JAX-WS context listener initializing May 19, 2010 9:45:24 AM com.sun.xml.ws.transport.http.servlet.WSServletDelegate <init> INFO: WSSERVLET14: JAX-WS servlet initializing May 19, 2010 9:45:25 AM [com.sun.xml.ws.policy.jaxws.BuilderHandler] getPolicySubjects SEVERE: [failed to localize] WSP_1014_POLICY_REFERENCE_DOES_NOT_EXIST(zip:C:/Oracle/Middleware/user_projects/domains/CDIR-NOTIFY/servers/AdminServer/tmp/_WL_user/_appsdir_MockNotificationService-J2EE5_war/royxma/war/WEB-INF/lib/webservices-rt-1.4.jar!/WEB-INF/wsdl/wsat.wsdl#Addressing_policy) May 19, 2010 9:45:25 AM [com.sun.xml.ws.policy.jaxws.PolicyWSDLParserExtension] finished SEVERE: [failed to localize] WSP_1014_POLICY_REFERENCE_DOES_NOT_EXIST(zip:C:/Oracle/Middleware/user_projects/domains/CDIR-NOTIFY/servers/AdminServer/tmp/_WL_user/_appsdir_MockNotificationService-J2EE5_war/royxma/war/WEB-INF/lib/webservices-rt-1.4.jar!/WEB-INF/wsdl/wsat.wsdl#Addressing_policy) May 19, 2010 9:45:25 AM [com.sun.xml.ws.policy.jaxws.PolicyWSDLParserExtension] finished SEVERE: [failed to localize] WSP_1018_POLICY_EXCEPTION_WHILE_FINISHING_PARSING_WSDL()

So naturally I Googled the error and found this thread : http://forums.java.net/jive/thread.jspa?messageID=375589.

The gist of the thread is that this error occurs when there are two versions of the metro runtime jar in the classpath.

Sure enough, when I checked the pom.xml generated by Netbeans I found the following dependency :

<dependency> <groupId>com.sun.xml.ws</groupId> <artifactId>webservices-rt</artifactId> <version>1.4</version> <scope>compile</scope> </dependency>

If you change the scope of this dependency to provided the error goes away and the service will successfully deploy in weblogic:

<dependency> <groupId>com.sun.xml.ws</groupId> <artifactId>webservices-rt</artifactId> <version>1.4</version> <scope>provided</scope> </dependency>

Posted via web from Relatively Prime

Wednesday, March 31, 2010

Handling malformed SOAP messages gracefully in Spring WS

I'm going to discuss how to modify Spring WS 1.5.9 to gracefully
handle malformed SOAP message like this one :

<ArrayObject>

Notice that the ArrayObject tag is not closed. Out of the box if you
send Spring WS a malformed message you will get an HTTP 500 Error
with an stack trace that looks like this:

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1231) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at com.sun.xml.internal.messaging.saaj.util.transform.EfficientStreamingTransformer.transform(EfficientStreamingTransformer.java:393) at com.sun.xml.internal.messaging.saaj.soap.EnvelopeFactory.createEnvelope(EnvelopeFactory.java:102) at com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPPart1_1Impl.createEnvelopeFromSource(SOAPPart1_1Impl.java:70) at com.sun.xml.internal.messaging.saaj.soap.SOAPPartImpl.getEnvelope(SOAPPartImpl.java:122) at org.springframework.ws.soap.saaj.support.SaajUtils.getSaajVersion(SaajUtils.java:159) at org.springframework.ws.soap.saaj.SaajSoapMessage.getImplementation(SaajSoapMessage.java:251) at org.springframework.ws.soap.saaj.SaajSoapMessage.<init>(SaajSoapMessage.java:84) at org.springframework.ws.soap.saaj.SaajSoapMessage.<init>(SaajSoapMessage.java:70) at org.springframework.ws.soap.saaj.SaajSoapMessageFactory.createWebServiceMessage(SaajSoapMessageFactory.java:168) at org.springframework.ws.transport.AbstractWebServiceConnection.receive(AbstractWebServiceConnection.java:90) at org.springframework.ws.transport.support.WebServiceMessageReceiverObjectSupport.handleConnection(WebServiceMessageReceiverObjectSupport.java:86) at org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter.handle(WebServiceMessageReceiverHandlerAdapter.java:57) at org.springframework.ws.transport.http.MessageDispatcherServlet2.doService(MessageDispatcherServlet2.java:148) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571) at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)

In this post I'm going to show you how to have Spring-WS respond to
such messages with a correctly formed SOAP fault that looks like this
:

<SOAP-ENV:Envelope > <SOAP-ENV:Header/> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring xml:lang="en">Could not access envelope: Unable to create envelope from given source: ; nested exception is com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: Unable to create envelope from given source:</faultstring> <detail/> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Spring WS returns a HTTP 500 error when dealing with a malformed
message because it does not catch XML parsing errors. So we need to
find a point in the code where we can easily catch these exceptions,
create a SOAP fault message and return that SOAP fault message. Which
naturally, begs the question of what's the correct point in the stack
to intercept these exceptions?

We want to catch the XML parsing exception as high up in the stack as
possible, this will ensure that the solution works for as many
configurations of Spring WS as possible. This would suggest that we
catch the message in MessageDispatcherServlet2.doService. Which is
the earliest point the code that Spring WS enters into the stack.

However, intercepting the exception in
MessageDispatcherServlet2.doService has a major draw back, we don't
have access to a SOAP message factory at that point in stack. We
could inject a SOAP message factory into the MessageDispatcherServlet2
however this isn't ideal because we'd simply be duplicating
functionality found in the WebServiceMessageReceiverHandlerAdapter.
Given that WebServiceMessageReceiverHandlerAdapter.handle(...) is
called by MessageDispatcherServlet2.doService(...),
WebServiceMessageReceiverHandlerAdapter.handle(...) seems to be as a
good a place as any to catch the exception.

So now we have to write a class that extends
WebServiceMessageRecivierHandlerAdapter and override the handle method
to catch and process XML parsing exceptions:

package org.springframework.ws.transport.http; import java.io.IOException; import java.util.Locale; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.springframework.web.servlet.ModelAndView; import org.springframework.web.servlet.ModelAndView; import org.springframework.ws.context.DefaultMessageContext; import org.springframework.ws.context.MessageContext; import org.springframework.ws.soap.SoapBody; import org.springframework.ws.soap.SoapBodyException; import org.springframework.ws.soap.SoapFault; import org.springframework.ws.soap.SoapFaultDetail; import org.springframework.ws.soap.SoapFaultException; import org.springframework.ws.soap.SoapMessage; import org.springframework.ws.transport.WebServiceConnection; import org.springframework.ws.transport.context.DefaultTransportContext; import org.springframework.ws.transport.context.TransportContext; import org.springframework.ws.transport.context.TransportContextHolder; import org.springframework.ws.transport.http.HttpServletConnection; import org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter; import org.springframework.ws.transport.support.TransportUtils; public class ErrorAwareWebServiceMessageReceiverHandlerAdapter extends WebServiceMessageReceiverHandlerAdapter { @Override public void afterPropertiesSet() throws Exception { //do nothing } @Override public ModelAndView handle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Object handler) throws Exception { try { super.handle(httpServletRequest, httpServletResponse, handler); } catch (Exception ex) { createSoapFaultFromException(httpServletRequest, httpServletResponse, ex); } return null; } protected void createSoapFaultFromException(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Exception ex) throws SoapBodyException, IOException, SoapFaultException { WebServiceConnection connection = new HttpServletConnection(httpServletRequest, httpServletResponse); TransportContext previousTransportContext = TransportContextHolder.getTransportContext(); TransportContextHolder.setTransportContext(new DefaultTransportContext(connection)); try { MessageContext messageContext = new DefaultMessageContext(getMessageFactory().createWebServiceMessage(), getMessageFactory()); SoapBody soapBody = ((SoapMessage) messageContext.getResponse()).getSoapBody(); SoapFault fault = soapBody.addServerOrReceiverFault(ex.getLocalizedMessage(), Locale.ENGLISH); SoapFaultDetail faultDetail = fault.addFaultDetail(); connection.send(messageContext.getResponse()); } finally { TransportUtils.closeConnection(connection); TransportContextHolder.setTransportContext(previousTransportContext); } } }

As you can see I overrode the handle function to call the super
implementation and to catch and convert any exceptions that are thrown
into SOAP messages. The only tricky thing about this class is that it
is a member of the org.springframework.ws.transport.http package.
This is because it uses HTTPServletConnection which is package
protected. This also, unfortunately, means that if the the
HTTPServletConnection class is modified in the future this class will
cease to work.

Finally, you have to modify your application context to use the
ErrorAwareWebServiceMessageReceiverHandlerAdapter rather than the
default WebServiceMessageRecieverHandlerAdapter. You can do this by
adding this line to you ApplicationContext.xml:

<bean id="messageReceiverHandlerAdapter" class="org.springframework.ws.transport.http.ErrorAwareWebServiceMessageReceiverHandlerAdapter" />

Posted via email from Relatively Prime

Handling malformed SOAP messages gracefully in Spring WS.

I'm going to discuss how to modify Spring WS 1.5.9 to gracefully handle malformed SOAP message like this one :

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://namespace.du.jour"> <soapenv:Header> </soapenv:Header> <soapenv:Body> <web:publish> <ArrayObject> </web:publishIirRecord> </soapenv:Body> </soapenv:Envelope>

Notice that the ArrayObject tag is not closed. Out of the box if you send Spring WS a malformed message you will get an HTTP 500 Error with an stack trace that looks like this:

at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1231) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at com.sun.xml.internal.messaging.saaj.util.transform.EfficientStreamingTransformer.transform(EfficientStreamingTransformer.java:393) at com.sun.xml.internal.messaging.saaj.soap.EnvelopeFactory.createEnvelope(EnvelopeFactory.java:102) at com.sun.xml.internal.messaging.saaj.soap.ver1_1.SOAPPart1_1Impl.createEnvelopeFromSource(SOAPPart1_1Impl.java:70) at com.sun.xml.internal.messaging.saaj.soap.SOAPPartImpl.getEnvelope(SOAPPartImpl.java:122) at org.springframework.ws.soap.saaj.support.SaajUtils.getSaajVersion(SaajUtils.java:159) at org.springframework.ws.soap.saaj.SaajSoapMessage.getImplementation(SaajSoapMessage.java:251) at org.springframework.ws.soap.saaj.SaajSoapMessage.<init>(SaajSoapMessage.java:84) at org.springframework.ws.soap.saaj.SaajSoapMessage.<init>(SaajSoapMessage.java:70) at org.springframework.ws.soap.saaj.SaajSoapMessageFactory.createWebServiceMessage(SaajSoapMessageFactory.java:168) at org.springframework.ws.transport.AbstractWebServiceConnection.receive(AbstractWebServiceConnection.java:90) at org.springframework.ws.transport.support.WebServiceMessageReceiverObjectSupport.handleConnection(WebServiceMessageReceiverObjectSupport.java:86) at org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter.handle(WebServiceMessageReceiverHandlerAdapter.java:57) at org.springframework.ws.transport.http.MessageDispatcherServlet2.doService(MessageDispatcherServlet2.java:148) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571) at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)

In this post I'm going to show you how to have Spring-WS respond to such messages with a correctly formed SOAP fault that looks like this :

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header/> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring xml:lang="en">Could not access envelope: Unable to create envelope from given source: ; nested exception is com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl: Unable to create envelope from given source:</faultstring> <detail/> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Spring WS returns a HTTP 500 error when dealing with a malformed message because it does not catch XML parsing errors. So we need to find a point in the code where we can easily catch these exceptions, create a SOAP fault message and return that SOAP fault message. Which naturally, begs the question of what's the correct point in the stack to intercept these exceptions?

We want to catch the XML parsing exception as high up in the stack as possible, this will ensure that the solution works for as many configurations of Spring WS as possible. This would suggest that we catch the message in MessageDispatcherServlet2.doService. Which is the earliest point the code that Spring WS enters into the stack.

However, intercepting the exception in MessageDispatcherServlet2.doService has a major draw back, we don't have access to a SOAP message factory at that point in stack. We could inject a SOAP message factory into the MessageDispatcherServlet2 however this isn't ideal because we'd simply be duplicating functionality found in the WebServiceMessageReceiverHandlerAdapter. Given that WebServiceMessageReceiverHandlerAdapter.handle(...) is called by MessageDispatcherServlet2.doService(...), WebServiceMessageReceiverHandlerAdapter.handle(...) seems to be as a good a place as any to catch the exception.

So now we have to write a class that extends WebServiceMessageRecivierHandlerAdapter and override the handle method to catch and process XML parsing exceptions:

package org.springframework.ws.transport.http; import java.io.IOException; import java.util.Locale; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.springframework.web.servlet.ModelAndView; import org.springframework.web.servlet.ModelAndView; import org.springframework.ws.context.DefaultMessageContext; import org.springframework.ws.context.MessageContext; import org.springframework.ws.soap.SoapBody; import org.springframework.ws.soap.SoapBodyException; import org.springframework.ws.soap.SoapFault; import org.springframework.ws.soap.SoapFaultDetail; import org.springframework.ws.soap.SoapFaultException; import org.springframework.ws.soap.SoapMessage; import org.springframework.ws.transport.WebServiceConnection; import org.springframework.ws.transport.context.DefaultTransportContext; import org.springframework.ws.transport.context.TransportContext; import org.springframework.ws.transport.context.TransportContextHolder; import org.springframework.ws.transport.http.HttpServletConnection; import org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter; import org.springframework.ws.transport.support.TransportUtils; public class ErrorAwareWebServiceMessageReceiverHandlerAdapter extends WebServiceMessageReceiverHandlerAdapter { @Override public void afterPropertiesSet() throws Exception { //do nothing } @Override public ModelAndView handle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Object handler) throws Exception { try { super.handle(httpServletRequest, httpServletResponse, handler); } catch (Exception ex) { createSoapFaultFromException(httpServletRequest, httpServletResponse, ex); } return null; } protected void createSoapFaultFromException(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Exception ex) throws SoapBodyException, IOException, SoapFaultException { WebServiceConnection connection = new HttpServletConnection(httpServletRequest, httpServletResponse); TransportContext previousTransportContext = TransportContextHolder.getTransportContext(); TransportContextHolder.setTransportContext(new DefaultTransportContext(connection)); try { MessageContext messageContext = new DefaultMessageContext(getMessageFactory().createWebServiceMessage(), getMessageFactory()); SoapBody soapBody = ((SoapMessage) messageContext.getResponse()).getSoapBody(); SoapFault fault = soapBody.addServerOrReceiverFault(ex.getLocalizedMessage(), Locale.ENGLISH); SoapFaultDetail faultDetail = fault.addFaultDetail(); connection.send(messageContext.getResponse()); } finally { TransportUtils.closeConnection(connection); TransportContextHolder.setTransportContext(previousTransportContext); } } }

As you can see I overrode the handle function to call the super implementation and to catch and convert any exceptions that are thrown into SOAP messages. The only tricky thing about this class is that it is a member of the org.springframework.ws.transport.http package. This is because it uses HTTPServletConnection which is package protected. This also, unfortunately, means that if the the HTTPServletConnection class is modified in the future this class will cease to work.

Finally, you have to modify your application context to use the ErrorAwareWebServiceMessageReceiverHandlerAdapter rather than the default WebServiceMessageRecieverHandlerAdapter. You can do this by adding this line to you ApplicationContext.xml:

 <bean id="messageReceiverHandlerAdapter" class="org.springframework.ws.transport.http.ErrorAwareWebServiceMessageReceiverHandlerAdapter" /> 

Posted via email from Karthik's posterous

Monday, March 8, 2010

Annotated-Based Transaction Managment with Spring 2.5.x and AspectJ Compile Time Weaving

In this post I'll describe how to use annotated transaction management with Spring 2.5.x and AspectJ compile time weaving. This is a short post, so I'll assume you have a working knowledge of Spring, it's transaction management capabilities, and Aspect J.

There are a number of ways to configure transaction managment in Spring for a complete description of the vast number of options available to you, I suggest you persue the Spring documenation. In this post, I'm dealing with the scenario in which you want declare your transaction semantics directly in your code using the @Transactional annotation, and in which you want to utilize AspectJ's compile time weaving rather than interface proxies or load time weaving.

Posted via web from Relatively Prime

Wednesday, February 24, 2010

Testing Code

public void testAfterPropertiesSetNoContextPath() throws Exception { try { JibxMarshaller marshaller = new JibxMarshaller(); marshaller.afterPropertiesSet(); fail("Should have thrown an IllegalArgumentException"); } catch (IllegalArgumentException e) { } }

Posted via web from Iterated Radical

Friday, February 19, 2010

Is our meritocracy working?

David Brooks has an interesting piece in this mornings New York Times entitled The Power Elite. In it he argues that as our society has become more fair and more meritocratic both the reputation of our chief institutions and their quality has decreased. As proof he cites public distrust of journalists, bankers and politicians. He gives five reasons why this maybe the case:

1. Our meritocracy has too narrow a definition of merit. We reward technical and specialized knowledge, which often does correlate well with other qualities we value in our leaders like empathy.
2. A lifestyle gap has emerged between the working class and the elite.
3. The elite are less socially connected then they were in previous generations.
4. Meritocracy encourages short term thinking by removing the incentives to long term thinking that came from a system inherited wealth.
5. Society has become too transparent as a result people now see how the sausage is made, which makes them less likely to trust the process.

I think the first, second, and fourth points are spurious.

As for the first item, our definition of merit is too narrow, I don't think this is the case at all. We value different qualities in different professions. Among our doctors and politicians we value empathy. Among our engineers we value technical knowledge. This is as it should be.

Even a facile examination of history would show us that Brook's second point, the emergence of lifestyle gap between the working class and the elite, is off the mark. The elite have always lead lives that were very different from the common folk. Brook's assertion that if you ran a local bank you "might have married a secretary...You would have had similar lifestyle habits as other people in town." Seems to me to be a nostalgic reading of history more reflective of It's a Wonderful Life than reality. Chances are if your ran a local bank you would have married the socialite daughter of the largest rancher in the county and had a secretary for a mistress. You would have belong to a country club, summered on the east coast or in Europe, and would have never seen the local grocery store because your chef would have handled that.

As for the fourth point, there is some validity to the point that you care more about ensure systemic stability when you know the happiness and well being of your relatives and descendants is at risk than if you're just looking out for yourself. However, I don't think the decline of a system of inherited wealth is to blame for this shift in thinking. I believe a break down in rich social networks is to blame. People no longer feel connected to their families, their friends, their neighbors, their coworkers. Thus, the incentive structure become skewed toward personal, short term gain.

This brings us to Brook's third point: the elite are less socially connected then they were in previous generations. The break down of rich social networks is to blame for much of our countries ills. When people stop feeling connected to each other there are fewer limitations on strife, their are fewer incentives to compromise, more of the worlds business occurs in formal settings that limit out-of-the-box thinking. I think this is the key issue.

So, how can we fix this? I don't

Posted via email from Karthik's posterous

Friday, December 18, 2009

Darwin's Armada.

I just finished reading Dawin's Armada by Iain McCalman. Professor McCalman weaves together the stories of four of England's most important naturalists: Charles Darwin, Joseph Hooker, Thomas Huxley, and Alfred Wallace. According to McCalman each of these men played key roles in the birth of the theory of evolution. Darwin and Wallace formulated the theory independently. Hooker and Huxley were masterful political strategists whose machinations sped the acceptance of the theory; due to their efforts the theory of evolution became widely accepted within seven years of its initial presentation.

What I was struck by when reading this book was the story of Alfred Wallace. Of the four men Wallace was by far the poorest and least educated. However, in my mind his scientific accomplishments easily rival that of the others. Further, the hardships and setback he endured were far beyond anything the others had to face.

Wallace was born to a working class family. His formal education ended when his was thirteen years old. He spent the next twelve years trying his hand at a number of different vocations: teacher, architect and surveyor. In 1848 at the age of 25 he set off to the Brazil with a friend of his to build a career as a naturalist and collector.

The other three scientists also spent time collecting specimens and touring the world. However, they did so with the support of the British Navy, attached to survey ships. Wallace on the other hand set off with little money and no official status; hoping to make money by selling the specimens he collect to wealthy collectors and institutions in the UK. He spent the next four years in the Amazon, traveling and living with various Indian tribes, venturing into parts of the Amazon that had never been travelled to by an European and amassing a massive collection, "including ten thousand bird skins, a large herbarium of dried plants, and an unparalleled collection of bird's eggs." During these four years he suffered the loss of his brother, bouts of malaria and various other tropical diseases.

A month into his journey back to England the ship he was traveling on caught fire and sunk. He lost his entire collection as well as all his notes and sketches. When he finally made it back to England, after a long tortuous journey, he arrived with nothing more than the shirt on his back. Despite this he re-established him self. Managed to write a few papers based on the few notes he had saved as well his memory. Despite not being fully recovered from his previous trip, he decided to set off on another collecting trip.

This time he decided to travel to Southeast Asia. Again he traveled on his own, hoping to make money selling the specimens he collected. He arrived Singapore in 1854, he did not return to England until 1862. During the nearly eight years he was in Southeast Asia he collected an incredible number of specimens; endured bouts of illness; formulated his theory of natural selection; and wrote several papers.

To me, Wallace's story is both amazing and inspirational. Here was a man with no means born into highly hierarchical Victorian England who managed to live a life of adventure and gain the respect and admiration of preeminent naturalists of his day.

Monday, December 14, 2009

Encouraging Creative Thinking.

While sitting in Barnes and Noble eating a cupcake, I ran across a really interesting article in December's Harvard Business review entitled "The Innovator's DNA." The authors argue that there are five skills that separate highly innovate people from the rest of us: associating, questioning, observing, experimenting and networking. They also argued that you could become more innovative by practicing the aforementioned skills.

So what exactly are these five magic skills?

Associating - The ability to make connections between seeming unrelated things. For example, an associative mind would understand the relationship between Chihuahuas and paint balls.
Questioning - Systematically challenging the world around you, trying to understand how and why things work the way they do. Particularly, questioning the validity of basic assumptions.
Observing - Learning to see the world as it is and drawing insights, inspiration, and ideas from it.
Experimentation - Systematically evaluating your ideas, hypothesis; trying new things to see what happens; and of course, pushing any big red buttons you happen to see.
Networking - Talking to and learning from other people. I'm not sure Twittering counts.

Basically, the authors of this article argue that curious people who talk to other smart people and systematically evaluate their ideas will come up with good ideas. At some level this is like arguing that the sky is blue. However, I think it's not as obvious an argument as it seems at first glance. Much of the way the world works is designed to discourage people from asking questions, exploring fields outside of their own, talking to other smart people about work, and trying new things.

Consider modern academia, much of it's structure is designed to discourage people from (1) exploring outside their own fields and (2) questioning consesus. Many will argue that modern the complexity of modern science requires specialists and that inter-disciplinarity is a fools errand. However, almost everyone will agree that when ideas from disaparte fields are meshed together surprising results will emerge.

Of course, academia is designed to speed the process of incremental innovation--adding a clock to whatever gizmo your professor dreamed up. It's not as well suited for promoting revolutionary innovation--proving whatever theory your professor came up with was a bunch of BS. Which, I suppose is why revolutionary innovation is so rare.

Wednesday, November 25, 2009

Chihuahuaball

There was an interesting post on The Rational Entrepreneur a few days ago on the The Law of Small Numbers--"our intuition that we can pick a small sample and confidently extrapolate from it." I love the example, Rolf Nelson - the blogger behind The Rational Entrepreneur--gives:

You and your best friend like paintball and chihuahuas, yet the paintball/chihuahua crossover demographic is completely ignored by big business. Surely you two can't be the only ones who would enjoy combining the experiences; you can extrapolate that there must be many others who would pay for the ability to roam about in camo as you deploy an army of small dogs to hunt down and sink their teeth into the enemy's padded ankles. So you open the world's first Chihuahuaball franchise, and are puzzled when the throngs fail to materialize.

I can't count the number of times that I've seen people fall into this trap. It's easy to believe that you can some how turn your niche passion into a business.

I think it's important, before you decide to turn your weird little fetish, into a business to understand the economics of the business your proposing. Once you understand the ecnomics, you need to figure out if the market is big enough to allow you to make a profit.

Taking Nelson's example, you should figure out how many people will need to play Chihauhuaball on a montly basis in order for you to turn a reasonable profit? Once you know how many people, then you need to figure out if you can realistic expect that many people to show up.

Tuesday, November 17, 2009

Kevin Mitnick & Social Networking Tools

A hacker by the name of Kevin Mitnick was arrested in February of 1995 by the FBI. He spent the next eight months in solitary confinement because law enforcement officials were able to convince a judge that he had the ability to start a nuclear war by simply whistling into the phone.

They eventually let Mr. Mitnick out of solitary, and a few years later he was let out of jail. A few years after that he gave a very interesting and insightful speech at Carnegie Mellon, which I was fortunate enough to attend. During his talk he focused on how humans are always the weakest link in any system's security. His speciality wasn't being a master whistler, but rather being a master con artist. He was an expert at what is known as social engineering--tricking people into giving him their passwords and user names. In other words, computer hacking at the end of the day is as much about people as it is about technology.

This brings me to my point. Many people seem to have forgotten that social networking tools like Facebook and LinkedIn are tools for connecting with real people for forming real relationships. Too many executives, activitists, and organizers have become enamored with social networks as technologies. They focus on their virtual presence and neglect the importance of building real relationships with their target audiences. Just as too many CTOs and CIOs focus on improving the security of their systems through technological means and neglect to teach their employees how to resist con artists.

Monday, November 16, 2009

Scotch in the Antartic.

According to this article on Yahoo! a couple of cases of McKinlay and Co. scotch whiskey have been entombed in ice in Antarctica underneath Sir Schackleton's hut for the last 100 years. The beverage company Whyte & Mackay, which owns the rights to the McKinlay and Co. name, is mounting an expedition to retrieve some of these bottles in order to decide whether or not to relauch the brand.

Does this sound like a load of BS to anyone else? I'm pretty sure that this is the flimsiest excuse in history for launching an expedition to Antartica. Well maybe not the absolute flimsiest, but it's definetly in the top ten. I'm pretty sure this was an idea that was hatched during a whiskey "tasting."

Actually, on closer inspection the idea is brilliant. In 2006 workers restoring Sir Schackleton's hut discover the whiskey. The executives and McKinlay and co see an opporutnity to revivie an old brand, give it a truely romatic image and make lots of moolah. The trick of course is tie the brand to romatic images of Sir Shackleton and antartica. Which is exactly what a modern day expedition to retrieve the bottles does.

Brilliant!

Friday, November 13, 2009

Annual Scotch Tasting!

Last night was the Georgetown Alumni club's annual scotch tasting. Being a fan of scotch, I had no choice but to go; and as usual, I had a fantastic time.

This year the event was held at a small capital hill cocktail bar--Wisdom. I though the bar had an interesting vibe and an eclectic cocktail menu. It was very heavy on gin and absinthe based drinks. My only real complaint about the bar was it's location. It was out in the boondocks. Well not really, it was on the eastern side of Capital Hill which to me is the boondocks. I never go out there.

Anyways, I attended the event with a friend of mine from grad school. We had initially planned to meet for dinner before the event. However, horrible DC traffic derailed that plan. So by the time we finally managed to meet up it was 7:30pm. Since the event was scheduled to start at 8pm and head straight to the bar.

Once we arrived at the bar we realized that we probably shouldn't drink a ton of hard liquor without having some food in our stomachs. So we ordered some hummos. The dish we got was nothing to write home about. So I won't bore you with the details.

The bartenders at Wisdom created three scotch based cocktails to accompany the tasting. I tried one that was mixture of port, vermouth, and scotch. My friend tried another that was a mixture of absinthe, pineapple, and scotch. Both were excellent. Apparently, scotch is a good base for a complex cocktail.

The format of the event was bit chaotic. I guess the initial plan had been for Glenfiddich to send out a number of folks to the bar who would walk everyone through four different scotches the 12,15,18 and 21 year old. Unfortunately, only one person was sent out. They decided to do cycle people through the tasting in batches of three. Naturally, this was a mess. But by that point in the evening we didn't mind the inefficencies of the process.

Wednesday, November 11, 2009

Relearning Mathematics!

I used to know a fair amount of math. I earned a minor in mathematics as well as a degree in computer science. So, at some point I was pretty well versed in math.

These days, however, I'm lucky to be able to add two numbers together correctly! What happened? Well, apparently, if you don't exercise your math muscles you lose them.

So, I've decided my current mathematical illiteracy is unacceptable. I've decided that I'm going to go back and relearn all the math I've forgotten.

As a first step, I went to the library and checked out Concrete Mathematics by Knuth et al. I've been told that this a classic text that all good computer programmers should have read. Needless to say, I've never read it.

I've been slogging my way through the book for a few weeks now. I'm only 4 chapters in and I don't think I've gotten a single problem correct yet. That's probably an exaggeration, but only a small one. What I've come to realize is that I've forogotten how to thing mathematically.

Mathematical thinking is a very specific kind of cognitive process. It requires the strict, almost mechanical application, application of logic. In other words, it's a mode of thinking that has almost no use in our daily lives.

So, the question I'm grappling with is: Is it worth relearning how to think mathematically?

Tuesday, November 10, 2009

Is Facebook making us less social?

One of the things I've been thinking about is whether or not social networking tools are simultaneously increasing the number of relationships we're able to maintain and decreasing the depth of each relationship.

For example, someone I went to high school with got engaged this morning. They posted this information to Facebook. A number of people responded to this post with a congratulatory note.

I considered doing so as well. However, in the end I didn't feel that it was really appropriate. While, I'm 'friends' with this person I have talked to her in nearly nine years. A congratulations from me would be a hollow social gesture, completely devoid of meaning.

So are tools like Facebook making more and more of our social interactions hollow and meaningless?

Monday, November 9, 2009

Pomodoro Technqiue

During the panel discussion at the NFJS conference on Sunday one of the panelists mentioned the Pomodoro Technique for getting things done.

Basically it consists of doing the following :

Choose a task to be accomplished
Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
Work on the task until the Pomodoro rings, then put a check on your sheet of paper
Take a short break (5 minutes is OK)
Every 4 Pomodoros take a longer break

My understanding is that you are suppose to make a dash (vs a check) on your sheet of paper, if you fail to work on the selected task for the full 25 minutes.

The basic goal of the Pomodoro technique is to lengthen your attention span. If your like me, you've developed a number of bad habits over the years:checking email constantly, chatting on IM, constantly checking google reader... The Pomodoro technique is meant to help you break some of these bad habits.

How does it work? I don't know. I'm not even sure I'm going to try it.

What I would like to do, and I'll add this to my ever grown list of potential projects, is build some software times that are geared toward this particular productivity method.

Trying something different.

I've decided that for the next 30 days I'm going to post something on here. I've also decided that I'm not going to start with an "anchor" as is traditional of many blog posts.

The classic formula for a blog post is to start with a news article, another blog post, or something else that you've ran across on the web and to respond to that thing in some way. For example many blog posts follow this format:

Blogger X has a really interesting post up this morning on Subject Y. I have to agree/disagree with him/her strongly. Let me tell you why: ...

While this format has the advantage of "injecting" you into an existing debate and possibly driving traffic to your site through the linkbacks. It doesn't really give you freedom to explore topics that interest you.

It also reduces the amount of thought an creativity you have to invest into a blog post. In many cases this is not a bad thing: I'm less likely to write something if I have to start from scratch.

However, I've come to realize that one of the reasons I want to have a blog is to give myself a space to "think out loud." So I'm going to force myself to do that by putting up at least one post a day that's completely free form.

Let's see how it goes.

Wednesday, November 4, 2009

Sprint outlaws tethering.

Apparently Sprint will no longer allow tethering. The use of your cell phone's Internet connection by your laptop. There are three reasons I use Sprint: their plans structure is simple, they allow tethering, and they have free roaming. While the loss of tethering isn't a deal breaker for me, I am disappointed in Sprint's decision.

Tuesday, September 29, 2009

Shiny Objects.

Lately, I've been in the mood to learn about some new technologies. For the past few months, year I've been fairly head down in the J2EE world learning/using J2EE technologies like EJBs, JMS, Spring, etc... Now I'd like to use some time to branch out and look at some none J2EE technologies.

I find that it's important spend some time outside of your comfort zone every once in a while. Like all technologies the J2EE world expects you to modify your thinking to fit within a certain framework. The more time you spend working within that framework the harder it becomes to think in a different way. One way to keep your mind nimble is to, every once in a while, try something new.

However, learning a new technology with out the pressure of deadlines or the structure of a project to work within is an incredibly frustrating process. When you are learning a technology in order to accomplish a goal, it's very easy to stay focused. You figure out very quickly what's important and what isn't. When your goal is to learn a technology it's very hard to stay focused. To keep from being distracted by every shiny object that you wander across.

Some people blithely suggest, why don't you simply formulate a project and use that project as a learning tool. Formulating a project is difficult. You have to find something that is simultaneously interesting, unimportant, and straight forward. These attributes seem to me to be inherently contradictory.

So the question arises, what is the best way to learn a technology?

Monday, September 28, 2009

Undirected Reading aka Web Surfing.

When things get slow at work I, like most people, surf the web. While some may look view this as a waste of time, I'm more inclined to view it is an important professional development activity.

First, rather than referring to it as web surfing let's call it undirected reading. If you think about it, most of the things we read in life fall into two general categories: stuff we need to read for work, stuff we want to read for fun. However, surfing the web really doesn't fall into either of those categories. Rather, surfing the web is process of discovering what we want to read for fun and what we should read for work.

I'd say, without any statistical basis, that ninety-nine percent of what I read when I surfing the web is neither fun nor useful. Mostly, it's just junk. However, the act of filtering through this great mass of junk does help me clarify my thinking in some hard to define way. It helps me figure out what I'm really interested in.