August 2006 - Posts

Learning to learn

I came across the following graphic on retention:

 

Many programs focus on teaching students a mastery of the fundamentals. However, in many technical fields education is short lived and continuous learning is the norm. Does learning to learn then trump a mastery of the fundamentals?

If we become autodidactic masters, would we not then be able to overcome any learning gaps?

Much graduate work at MIT, by its nature, is independent learning. At the undergraduate level I see good efforts in this direction but the promise is still unrealized. In either case, I think MIT does better than most colleges at creating self teachers.

My personal learning cycle is:

1) Build a knowledge base
    - read, read, read

2) Test your knowledge
     - test, experiment, and challenge

3) Summarize and structure your findings
    - write, write, write

4) Teach what you have learned
    - explain it to others

The process is often iterative in steps and in cycle.

Something that was not obvious to me was "self feedback". On a traditional teaching structure, the feedback comes from the instructor. In self teaching, you give feedback to your self.

Java Days

I have been working with Java for the last two weeks.

The plain vanilla Java is pretty poor when it comes to web services. Unless you are using a development platform, the road is rough.

The tools story is not that straight forward either. For code construction, there are the "n" eclipse projects, then there are about 6 different versions of IBM Websphere, the JBoss tools, the BEA, the open source camp, and so on.

Once you get your IDE, you will need an application server. Finding and choosing an application server in yet another adventure.

The space reminds me of the UNIX days. Even though Sun, HP, IBM, etc were all UNIX the variations made for unnecessary complexity and interop problems.

After doing the massive installations of the leading commercial Java platforms I came back to open source tools. Though it may not seem like it, I found this solution to be the lightest and simplest development environment.

I placed the installs at
http://autoid.mit.edu/pickup/Java/

1) Install
  
   jdk-1_5_0_07-windows-i586-p.exe


2) Download and unzip (do not install)

   apache-tomcat-5.5.17.zip

3)  Download and unzip (do not install)

    wtp-all-in-one-sdk-R-1.5.0-200606281455-win32.zip

4) Open WTP and run eclipse – no need to install

5) In eclipse create a new project, add a server, use the tomcat libraries – no need to install

6) When you run your samples, use the server you added through eclipse
 
Once I had everything in place, creating and firing my proxies was pretty smooth :) There are Java-to-.NET issues but I had taken care of those at the interop party.

HTTP GET and HTTP POST Are Disabled by Default

An old one, entered here for reference

<configuration>
    <system.web>
    <webServices>
        <protocols>
            <add name="HttpGet"/>
            <add name="HttpPost"/>
        </protocols>
    </webServices>
    </system.web>
</configuration>

SOAP Living

I have been working on some software that "really" needs to play well with others.

I used my usual tricks with services but there we still some platforms that did not like my SOAP. Getting down into the guts of the problem I found problems with the MS header "SOAPAction". After cleaning up my WSDL and adhering strickty to WSI I found that MS thought all my web methods had the same SOAPAction. After some research I found the magic attribute:

    [SoapDocumentService(RoutingStyle = SoapServiceRoutingStyle.RequestElement)]

The MS error:

The methods getVendorVersion and poll use the same SOAPAction ''. When the RoutingStyle of the XML Web service is SoapAction, SOAPAction values must be unique across methods on the XML Web service. You can change the SOAPAction with the Action parameter to the SoapDocumentMethod or SoapRpcMethod attributes, or you can specify a RoutingStyle of RequestElement on the XML Web service.