Why Use A Messaging Service for P2P Connectivity

I think it is preferable for a client to directly call an X service (REST, SOAP, internal, external, whatever) so as to leave out the added complexity of writing to a queue. However I think there are some valid reasons to use a Messaging Service.

1. Lazy error handling. Most messaging systems are rock solid these days and the only reason they go down is for system reboot. X services may not be rock solid and may have a considerable amount of down time. Instead of having to add extra handling for the downtime cases, write to the message service. When the X service comes back up, the message queue will deliver. However, "Lazy" is the key here. If time allows, code error handling in the client.

2. Throttling. This is related to lazy error handling in that if a service becomes too congested, it can stop accepting requests. Write to a message service and the X service will control its own destiny. One obvious consequence of this is that the X service may never catch up. If the X service can handle the load, or it can be clustered to handle the load then call the X service directly.

3. Event triggers. If multiple X services need to react to a single client event. It is easier for the X services to listen for events than for the one client to contact each X service individually. In my opinion, this is truly the only valid reason to use a messaging service.

Option is Iterable

Event though the method exists doesn't exist on the Option class, there is an implicit conversion from Option to Iterable. Exists is a useful method when processing the value contained within option.

def isBefore (a: Option[Int], b: Option[Int]): Boolean = {
  a.exists(x => b.exists(x < _))
}

println("5 is before 3 :" + isBefore(Some(5), Some(3)))
println("3 is before 5 :" + isBefore(Some(3), Some(5)))
println("5 is before none: " + isBefore(Some(5), None))
println("3 is before none: " + isBefore(None, Some(3)))

Produces

5 is before 3 :false
3 is before 5 :true
5 is before none: false
3 is before none: false

Do not use 64bit JDK when coding in Scala

I recently upgraded to 64 bit Ubuntu Linux to make use of the 6 gigs of RAM by boss had bought me. I used the Synaptic package manager to install the JDK because I enjoy the work being done for me.

My machine felt faster and really powerful, except that the multi module maven build, using the maven scala plugin when from 4 minutes to a whopping 8 minutes.

What this boils down to is that the 64 bit JDK does not support client mode (-client), only server mode. Since scalac is pretty short lived, it is really hindered by the startup cost of server mode. Scala builds times double and triple.

This was easy to remedy. Even though 64 bit Ubuntu does not have the 32 bit packages, one can grab the 32 bit binaries from java.sun.com, and they will work just fine.

git in continuum

Git is available in continuum. There may be other ways to do this, but this is how I was able to get it working.

1. download Maven SCM source: 'svn co http://svn.apache.org/repos/asf/maven/scm/trunk maven-scm"
2. build the project "cd maven-scm" "mvn install"
3. install the git providers module "cd maven-scm-providers/maven-scm-providers-git/" "mvn install"
4. download continuum source: 'svn co http://svn.apache.org/repos/asf/continuum/trunk/ continuum"
5. edit the 'continuum-webapp/pom.xml' and add the maven scm git project:

<dependency>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-provider-git-commons</artifactId>
<version>1.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-provider-gitexe<<artifactId>
<version>1.1-SNAPSHOT</version>
</dependency>

6. build the continuum project "mvn install"
7. run continuum "cd continuum-webapp" "mvn jetty:run"

Expected :success, but was zero

I was having an issue with the rails plugin, http authentication, which
resulted in the error message Expected response to be a <:success>, but
was <0>.

This seems to be the result of a before_filter returning false.

IE, Back button, AJAX and DHTML. Solution - exploit onload.

Most people know about the back button feature when developing heavy
AJAX web sites. That is not what this is about.

I created a simple web page to save favorite things. An image titled
"Save" or "Remove" appears on the screen depending if a favorite can be
saved or is saved. When pressed, a simple AJAX request is sent the
server and the images are swapped if the request is successful. I want
the appropriate button to appear no matter how one navigates to the
page. Unfortunately, in Internet Explorer, if I navigated away from the
screen and then 'back' to the page, all the images reverted back how
they were initially loaded -- all DOM changes are forgotten. Firefox
will display the latest DOM, so there are no problems here.

After playing around a little bit, I noticed that IE also runs the
'onload' function when you navigate 'back' to it and so I exploited
this. The onload runs an AJAX call to retrieve ones favorites and then
changes the image to the appropriate image. Since I used get requests,
I also had to append a time stamp to the end of the URL just before
'open' to avoid IE caching.

The advantage of doing this is that it works. The disadvantage is that
the logic is in the javascript and not the JSP.

Odd error in oracle portal for the google gods

Here is the error I was getting:

Portlet X responded with content-type text/plain when the client was requesting content-type text/html

.... some garbled stuff here ....

ate: Mon, 24 Apr 2006 20:12:18 GMT
Server: Oracle-Application-Server-10g/10.1.2.0.2 Oracle-HTTP-Server
Connection: close
Transfer-Encoding: chunked
Content-Type: text/vnd.oracle.mobilexml


There seems to be something in the <fmt:formatdate> tag that caused this. We are using jakarta standar.jar version 1.0. I don't have time to reasearch this right now, instead I made this a scriptlet that uses SimpleDateFormat. (Yes, I feel that this workaround is a cop-out, but that's the way it has to be.