First printer in a computing grid?
Tuesday, April 22, 2008
My friend Diego Mariño has announced in his blog that they have succesfully connected a printer to a computing grid. Think in Grid is a startup from Barcelona with an innovative Grid computing framework. They claim to be able to integrate all kind of devices in a computing grid, just like this printer:
Coming from the M2M busines I know that the Holy Grail of this business is not only the transparent connectivity of heterogenous devices through non-reliable (wireless) networks, but the capability to split and perform complex operations remotely just like if they were performed locally.
Obviously, it sounds promising.
The grails diaries #5: Do you need a software architect?
Wednesday, February 20, 2008
Previous: Grails, is it really worth it?
I think there is a general misunderstanding of what kind of value can give Grails to a development shop. It seems that there are people out there that believe Grails, RoR and other breeds mean the end of Software Architectures in the web layer. The reasoning is: if the workload to develop a web application is shorter probably it means we need less skilled developers to code our applications.
Wrong.
This is a bizarre way of thinking from my point of view. I have heard of this before. Lowering the workload of development does not mean poorer skills in your development team. The workload is lower because these frameworks follow the Don't Repeat Yourself (DRY) principle. This means that all developers (seniors and juniors) can deliver faster because they don't have to perform repetitive tasks. That's all. But developers still have to face problems, and have to take decisions about their design to fix them. And experienced developers can identify better solutions.
Back to the original question: Do you need a software architect in a project with Grails? Yes, you do. But may be you don't need a full time architect. I have identified several scenarios:
- Cowboy developer: Grails is a great framework if you are cowboy developer. The framework can enhance your productivity if you are a freelance developer working alone. If you don't need to work with colleagues it means you probably don't need to integrate with third parties (services, legacy databases, existing code). In this case, the cowboy developer can play the role of the architect, which makes all the sense. But, I'm not sure if Grails can be successful in this scenario: Ruby on Rails can fit better from my point of view (cheaper hosting, more accepted...).
- Development shop: Your customers accept Grails as a valid option (this is a prerequisite, don't' forget to confirm first if they are happy with Groovy on Grails. Running inside a JVM and an application server is not enough!). You have a trained team of Grails developers. You probably have requirements regarding integration with third parties. In this scenario you need an architect (or a senior developer that can take the role) to take decisions about how to do the things and draft a design. Due to the fact that Grails is a very constrained development environment, you can save time of your architects. They will focus on giving the best solution, but they don't have to care about small details that Grails takes care of (remember, convention over configuration).
- IT Departments: Congratulations, you have persuaded your management about the benefits of Grails. You have now a team in your staff of Grails developers plus some contractors. Normally, development teams inside the companies focus on the core business.The projects are evolution of others, there is a lot of service integration and maintenance. So your architect(s) will focus on smooth integrations with existing legacy code and services. In this scenario a strong architect is a must because you need somebody with good skills to design the bridge between your existing legacy systems and your shiny new Grails applications. This architect has to be a Grails believer: otherwise he will lose the faith when the firsts unexpected problems arrive, something common when starting with new frameworks and technologies (do you remember your first experiences with Struts, Maven or Hibernate ?)
Using the Google Chart API from the server side
Sunday, December 09, 2007
You can include a Chart API image in a webpage by embedding a URL within an <img> tag. When the webpage is displayed in a browser the Chart API renders the image within the page.There are some references about how to encode the information in the URLs in javascript. And I was wondering: Can I use it from the server side in my Java applications? Is it difficult? JFreeChart is a good API Chart but it consumes a lot of resources, can I save money in hosting servers delegating the rendering of my charts to Google?
So I wrote this little example about how to use the Google Chart API in Java with the Apache Jakarta Commons HTTP Client. It is very easy, and I wrote a little helper class to avoid the crazy encoding implemented by Google. You can download the source code of the class here. Remember to include these libraries:
- commons-logging.jar
- commons-httpclient-3.1.jar
- commons-codec-1.3.jar
http://chart.apis.google.com/chart?It returns an array of bytes with the image in PNG format. You only need to push it into the output stream of a servlet, or save it in a file like I do. Ok. here goes the snippet:
private String url_ = "http://chart.apis.google.com/chart?";The rest of the class includes some helper methods that wraps the crazy encoding made by Google. The reason for this crazy encoding is to avoid the use of POST parameters normally harder to use in the client side. I have coded the class quick and dirt, so if you think it's possible to do it better you are probably right!
private int timeout_ = 30000; // milliseconds
public byte[] create(String postUrl) {
HttpClient client = new HttpClient();
client.setConnectionTimeout(timeout_);
String url = url_ + postUrl;
HttpMethod method = null;
method = new GetMethod(url);
method.setRequestHeader("accept", "image/png");
byte[] image = null;
try {
client.executeMethod(method);
image = method.getResponseBody();
} catch (Exception e) {
e.printStackTrace();
} finally {
method.releaseConnection();
return image;
}
}
I have performed some tests and the latency of the service is excellent: it never took more 2.5 seconds to render a chart, taking from 300ms to 800ms on average. Normally the network latency of Google is very low (less than 100ms), so the time it takes to render a chart is excellent considering this is a very CPU time consuming activity. As a rule of thumb you should cache the requests made to the Google Servers to avoid requesting twice the same chart. You will respect the Terms of the Service (50000 request per day and user, remember!) and your users will be happy because they will get the charts without any delay.
Finally, I think it's worth to use this API instead of JFreeChart if you need to render a lot of charts with a very high granularity that impacts in the performance of your servers.
The ball and chain of iPhone was not Java: it's Google Android
Monday, November 12, 2007
Sometimes you only need to wait to understand why things happen. When Steve Jobs said 'Java is not worth building in. Nobody uses Java anymore. It's this big heavyweight ball and chain', we were surprised and disappointed because like me a lot of people think that there is still room for Java in the mobile platforms. Of course we have J2ME, but we can do very few things with it. What we need is a full J2SE stack for mobiles. And the iPhone could do it... if Mr. Jobs wants. But he does not want because Java has become the flag of Google to do developers to follow them. He chose to keep Java out of the iPhone to keep a strict control of the platform, to keep Google out of his business.
I have just reviewed what Google Android is, it's architecture and the SDK and I think it's much more than a smart mobile platform: it's a philosophy. Think of what SWT is to the Java User Interfaces and apply it to the Android Architecture. The access to the physical layer has been developed in C/C++ on top the Linux OS, and on top of it there is a pseudo-Java Virtual Machine called Dalvik virtual machine. As they say, "Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included "dx" tool."
J2ME is very similar in the approach, but what looks new is the tight integration with the OS and the use of Java 5 extensions of the language. J2ME is almost JDK 1.0, but if you read the source code of the samples, you can recognize some coding practices of Java 5. I still don't know if the Dalvik VM can do reflection or annotations, I will need some time to test it.
The access to the physical elements of the mobile device are performed thanks to the set of android.* packages. So, it will be a task of the device manufacturer to migrate the C/C++ libraries layer for their devices. I have tried to find some information about how to certificate that the libraries has been migrated correctly. This was one of the key elements for the success of J2ME on the mobile phones, and should be done the same way.
The Java applications are what they call 'Third party applications'. It's not possible yet to develop or modify the underlying Linux OS and the C/C++ libraries. Again, Java runs in a sandbox -sounds familiar, eh?-.
I will continue playing with it. Just some random thoughts, will Sun Microsystems get some money for the licensing of Dalvik VM? How much? Will J2ME be replaced by the Dalvik VM?
Social bugfixing tool: Can corank.com work?
Monday, November 05, 2007
When you start with a third party open source library or project, first thing you do is to check the its activity. If the project is dead or it's a zombie (somebody still there just to make questions in the forums) then it's better to start looking for a new one.
If the project is active and you decide to use it, sometimes (well, most of the times) you cannot dedicate time to give your feedback to the project. You need new functions in that beautiful library, but you don't have time to implement it and you have already seen in the bug list that somebody have already asked for the same kind of enhanced functionality.
The question is: When will The Gods of the library/project will implement those enhancements? And why is it not implemented yet? Nobody knows...
I came across with www.corank.com several months ago. It's a tool to build your own web 2.0 Digg style voting system. And I think it would be a good idea to use it as a voting system to classify the criticity of bugs and enhancements in a complex multi-customer system like popular open source projects.
Do you know of anybody using it this way? Or any other tool?
