The Loop

I just stumbled accross this article – the subject matter certainly puts questions over the sanity of the author, but, never the less it is actually quite a good example (or tutorial if you can go that far) of how to use Smart Objects within Photoshop.

This is just a quick note; my apologies for the lack of posting lately – its not that I haven’t had anything to write about, quite the opposite… but right now im preparing for a server upgrade and I have already ported the blog data, so yes, Im being a bit lazy, but we should be all ported to the new servers in a couple of weeks.

So bear with me guys, Cheers

If you havent seen it already, then where the hell have you been? iPhone 3G is comming out July 11th, and, yes, like all the other Apple disciples I shall be venturing down to my local store to get one. Sweet mother of god, just look at it…. its got GPS and everything…

I’ve recently started using Amazon EC2 and put quite simply, it could well be the best computing platform the world has ever seen! Its flexible, scalable, and very competitively priced which makes it an attractive proposition for users that are currently on fixed priced virtual machine hosting.

The real differentiator with EC2 is that you are effectively building a linux machine from scratch that can be flug around there cloud to any location. So, that means you could make an image of your running machine using there AMI Tools and have your box running in East Coast America. Pretty straight forward so far. You then get wind (pun intended) that a massive hurricane is about to hit the East Coast, and you’d feel safer if your servers were far far away, right? No problem, with a simple one line command you can re-deploy the image to the West Coast cloud and everything would just pick up where it left off! Amazing!

On top of all that clever trickery, you get pretty decent control over firewall ACL’s and the choice of box configuration is pretty decent – the ‘small’ machine still has 1.7GB of RAM, which is a boat load more than most of VM’s on the market. You can even get 7.5GB and 15GB variants.

Amazon, you have out-done yourselves. Congratulations!

As a number of you are aware, I have spent quite a bit of time wrestling with XMPie uProduce SOAP API with the CXF service framework in Java. I finally (and with quite a lot of disappointment on my part) gave up trying to get that to work. CXF just does not want to play nice and I cant seem to make the XJB bindings work correctly with it and the mish-mash WSDL coming from uProduce

Anyway… with that rant over, I tried to be objective and switched to using Metro – ok, out of the box I still had a whole heap of problems, exactly as I did with CXF. However, I have managed to wangle it!

Step 1

You will need access to an XMPie server with the API’s installed and working. For the sake of this example i just wget’d the WSDL file so the generation code was not so bloated.

Step 2

You’ll need an XSD XJB binding file which looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<bindings xmlns="http://java.sun.com/xml/ns/jaxb" 
          xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
          xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" 
          version="2.0">

  <globalBindings>
    <xjc:simple />
  </globalBindings>

  <bindings scd="~xsd:complexType">
    <class name="ComplexTypeType"/>
  </bindings>

  <bindings scd="~xsd:simpleType">
    <class name="SimpleTypeType"/>
  </bindings>

  <bindings scd="~xsd:group">
    <class name="GroupType"/>
  </bindings>

  <bindings scd="~xsd:attributeGroup">
    <class name="AttributeGroupType"/>
  </bindings>

  <bindings scd="~xsd:element">
    <class name="ElementType"/>
  </bindings>

  <bindings scd="~xsd:attribute">
    <class name="attributeType"/>
  </bindings>
</bindings>

Save this as xsd.xjb (or whatever you like, just make sure the name is reflected in the command below)

Step 3

Actually generate the code! Your command might look different, but heres mine:

  wsimport -b http://www.w3.org/2001/XMLSchema.xsd \
    -b src/xjb/xsd.xjb \
    -keep \
    -s src/java \
    -d target \
    -p com.xmpie.wsapi.icp \
    src/wsdl/InteractiveCampaign_SSP.wsdl

You should then see something like the following in your finder (or other OS file browser if not on mac):

These are the class files created for the InteractiveCampaign WSDL – all 128 of them!

Anyway, I have run out of time for today, but will try and get another blog up soon about how to use this in a client application from a java CLI.

Whilst at Drupa I was lucky enough to get a back room showing of what Creo will be releasing in Q4 of 2008 and into 2009.

The first impressions are really great – the native UI (Cocoa on OSX and .NET windowing on WinTel) means that no matter what your platform you get widgets that you are familiar with and work seamlessly with the operating system. That really is quite a differentiator when compared to competing products, and one that I am sure a lot of people would welcome as even from personal experience, quite a number of other solutions are using SWNG, or, god forbid, AWT in Java which are clunky and just not up to the modern users expectations.

Plugins

One of the things that really is very good about Darwin is the plugin system they have devised. Whilst I currently have no information on what inner complexities one might face with implementing your own plugin, the architecture I was shown looked very open, and very friendly – which is a massive plus point in my eyes.

Performance

Darwin was awesomely quick too – speed and beauty in the same package! Eliot Harper has blogged some very nice performance testing between XMPie uDirect and Creo Darwin which can be found here

Integration

Creo have changed the way in which the Darwin working environment is persisted – its now a separate DVJ file. This means that when working with InSite, the system can automagically create the darwin files for you. I’d go out on a limb and say that if InSite is able to create those files, then any other system you might want to write would also be able to generate DVJ files – this could really create some interesting options for mash-up style workflows!

What About The Cons?

Ok, so all products have there cons – thats life – at the moment Darwin only supports flat file data-sources. Perhaps that will change over time, but we’ll see I guess. Release is quite some time off so who knows what those guys might come up with!

Kudos Creo , this really is great work.

Another interesting article about Darwin and InSite can be found here

This post is a bit off of the usual code focused articles I write, but having just arrived back from Drupa I feel that I just need to write a quick post about this as I really did think it was awesome!

The product in question is 3D Systems ProJet

No word of a lie, this machine can “print” 3D models of things via an InkJet process – it really is amazing the fine, granular control they have over how it works its magic. Like I said, very off topic, but freaking awesome at the same time!!

How many times have you been using Facebook and received the “Sorry, an error has occurred. We’re working on getting this fixed as soon as we can.” message?

This appears to happen fairly often (relativly speaking) from what I can see. I wonder if this lowers peoples expectations of what uptime they should expect from the big web 2.0 platforms? For instance, I dont ever remember getting such a message on YouTube… but then again a whole lot more people use facebook than use YouTube…

I guess my question is this… Is it acceptable to be having public downtime on such sites/services that are becoming such a part of everyday society? I would say no, its not. Were told that facebook has somewhere in the region of 10,000 servers! So goodness knows why with 10K servers they cant get a decent amount of uptime for most users.

Its been in the wings for some time now but the announcement has finally been made public. This is great news as it means that when were coding in Scala the classes in your web container will automatically be updated without the need to restart the container and redeploy the WAR.

For more on this check out the announcement

I recently read this article and realised that I had never blogged about the resin plugin that works perfectly with lift for development and deployment.

Heres what you need to add to your pom.xml

<build>
   ...
   <finalName>${project.name}</finalName>
   ...
    <!-- resin plugin -->
      <plugin>
        <groupId>com.caucho</groupId>
        <artifactId>resin-maven-plugin</artifactId>
        <version>3.1.6</version>
        <configuration>
          <contextPath>/</contextPath>
        </configuration>
      </plugin>
    ...
</build>

<pluginRepositories>
...
<pluginRepository>
  <id>caucho</id>
  <name>Caucho</name>
  <url>http://caucho.com/m2</url>
</pluginRepository>
...
</pluginRepositories>

Note, the final name var is important, as thats what resin uses to point at. Dont worry tho, as lift already has a name element so provided you haven’t deleted it, your laughing.

Next, to boot the server, just do:

mvn resin:run

That should be it! Enjoy!

Right, as you know, I use the lift framework a lot these days. I also use Resin as my choice container. So, i recently got to thinking, wouldn’t it be cool if i could just bosh together a simple way to expose controllers in lift via the groovy protocols made available by Resin – well, I have here an example of just such a thing.

Lift Side

Ok, before anyone has a poke at this code… it was a very quick and dirty example, so its not ideal, and obviously your code would be a whole lot more complex, but this article is just about proving concept.

I set up the object that I want to expose via remoting. Critically, there would be nothing stopping me using the persistance built into lift, or anything else available to java or scala for that matter. The key is the traits… as they are like java interfaces (broadly speaking), they let resin know what methods it can call.

package com.timperrett.resin.example.controller

trait HelloTrait {
  def hello: String
}
class HelloWorld extends Object with HelloTrait {
  def hello = "Hello from lift" 
}

Resin Configuration

Next, we add a bit of config to resin so that it knows how/where to expose the service. Critically, we could have used Hessian, Burlap or CXF (for SOAP) and all by being pushed out of the container with zero extra effort.

<web-app id="/lift-remoting-example" 
   root-directory="webapps/lift-remoting-example">
  <servlet-mapping 
   url-pattern="/api/hello-world" 
   servlet-class="com.timperrett.resin.example.controller.HelloWorld">
    <protocol uri="hessian:"/>
  </servlet-mapping>
</web-app>

Client Side (in another language!)

To proove the point, I thought I would just make a simple client in another language (namely ruby):

require 'rubygems'
require 'hessian'

url = http://127.0.0.1:8080/lift-remoting-example/api/hello-world
client = Hessian::HessianClient.new(url)
puts client.hello

Again, a very simple example, but one that proves the point. You should then see “Hello from lift” output in the terminal window.

Project Files

You can download my example from here

If you found this article interesting, or have played with this yourself also, then by all means leave a comment or get in touch.

Web Services for API? Mehhh, haven’t we heard all this before?

Well, frankly, yes, you probably have. But you might not have had the full story. Im not talking about SOAP or other such protocols that require a serious amount of time at remoting-protacol-fat-camp… Today I would like to take some time to talk about the Burlap and Hessian protocols. For the astute readers, yes, those are the same ones that I was banging on about in a previous post when talking about hot technology for 2008. They are both slick remoting systems that run on Resin (they probably can be run on other JEE servers too, but frankly I haven’t tried), and according the chaps at Caucho:

“Hessian and Burlap are compact binary and XML protocols for applications needing performance without protocol complexity. Hessian is a small binary protocol. Burlap is a matching XML protocol. Providing a web service is as simple as creating a servlet.”

Sounds pretty cool doesn’t it? Well they are. I have been playing with Resin running these protocols and evaluating them as methods for creating robust API which 3rd parties can easily integrate with. Before reflecting on what I have experienced during these trials with Burlap/Hessian I would have instantly said that Hessian was better, but then I got to reflecting on use in the world: is it really practical to use binary remoting protocols for services that the 3rd party user does not know well? I think about the times in which I have been developing clients to services I don’t know (or didnt build for that matter) and I do usually end up looking at the message body when trying to troubleshoot any issues that might arise – and Hessian would be totally unworkable in that instance.

Anyway, to conclude, if you or a partner company are working in tandem and have a good working relationship then sure, its got to be Hessian all the way; its fast, its light weight… its all good. However if your exposing services for developers at a 3rd party, then you should really consider Burlap, as it could make someone else’s life so much easier. On the other hand, you could just be greedy and use Resin to expose Hessian, Burlap and SOAP!

It appears that flash has finally gone open source – craziness all round from Adobe at the moment.

http://aralbalkan.com/1332

I appreciate this is a little late in terms of the papervision bandwagon, but I only came across this on the tube this morning. A truly awesome display of what the latest version of flash + papervision is capable of:

My appologies; I hardly ever blow my own trumpet on this blog, but I just cant let this one pass without a good old toot of the proverbial horn.

Today I joined the lift committers. That might not sound much, but when you think that lift will be the next Ruby on Rails size phenomenon to hit the development community, thats pretty dang awesome.

I shall toot no more – respect to David and the rest of the other guys on lift core… you freaking rock!