BigDecimal value = new BigDecimal("0.31");BigDecimal oldValue = new BigDecimal("0.34");BigDecimal ratio = value.divide(oldValue);java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.BigDecimal ratio = value.divide(oldValue, BigDecimal.ROUND_HALF_EVEN);
I had a very annoying problem lately. The deployment of my app to GAE was failing randomly with mysterious errors like this:
com.google.apphosting.utils.config.AbstractConfigXmlReader
getTopLevelNode
SEVERE: Received IOException parsing the input stream for /home/.../war/WEB-INF/web.xml
java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
...
SEVERE: Received exception processing /home/.../war/WEB-INF/web.xml
com.google.apphosting.utils.config.AppEngineConfigException: Received
IOException parsing the input stream for /home/.../war/WEB-INF/web.xml
at
com.google.apphosting.utils.config.AbstractConfigXmlReader.getTopLevelNode( AbstractConfigXmlReader.java:
210)
After an extended googling session I unearthed a solution from this helpful discussion thread. Just replace the doctype declaration in your web.xml file
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
with the following updated version:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5">
That's all, one click deployment is working reliably again!
You worked hard. Your application works like a charm, the concept rocks, the graphics are great, the client is happy. Still, you know there is one more thing to do: test with the dreaded Internet Explorer.
In your case, the app is a standard Facebook iframe application. You went to great lengths to make sure it stays compatible with IE (that means modern CSS/HTML techniques are off limits). Tough luck, you have to try harder my friend. You see, the application does not work at all! With no error message whatsoever.
Oh, wait a minute, there is a stupid eye icon in the status bar. Once you click it you realize that IE is actually blocking Facebook's authentication cookie! In the default security setting, no less. You are royally screwed.
To make a long story short, here is a 'voodoo' solution, offered by a mastermind friend:
response.setHeader("P3P","CP='IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT'");
For the hairy details, get educated by the pros. Groovy!
A few days ago, I needed to center a mini site horizontally *and* vertically (don't you just love client requests?). It 's easy to tackle the horizontal axis using CSS:
<style>
.hcenter {
margin: auto;
width: 320px;
height: 240px;
}
</style>
<div class="hcenter">Horizontally centered text</div>
On the contrary, I thought that CSS can't handle vertical centering (at least in a cross-browser compatible way) and a quick Google session ended fruitless as well. Instead, I wrote a small script to programmatically center the div inside the window. It took a couple of revisions to support resizing, eliminate flickering, ensure cross-browser compatibility, etc. but eventually I got it right.
Today though, I rediscovered an old trick:
<style>
.center {
position: absolute;
width: 320px;
height: 240px;
top: 50%;
left: 50%;
margin-top: -120px;
margin-left: -160px;
}
</style>
<div class="center">Horizontal and vertical centered text is possible.</div>
Duh!
A few days ago, Joyent unveiled the public beta of their NodeJS-based platform-as-a-service contender. Well, this service rocks! From the great no.de domain name to the RESTful procurement/management API and the git-powered deployment, everything radiates coolness.
Even though I posted my hearts to the API end-point (/♥ !!), I haven't received any coupons in return. So there is no review for you. However, the elegant simplicity of the API (combined with the clean-slate design of the underlying NodeJS infrastructure) lights my geeky heart (pun intended).
I am not a NodeJS fan-boy. These days I am evaluating Java/GWT (so far I am positively surprised but I 'll reserve my final judgement for a future post). So, you understand, like everyone who feels overwhelmed by the complexity of the Java ecosystem, I can appreciate a refreshingly simple alternative.
Last year, Google released the Closure suite of tools for JavaScript development. It seemed too good to be true. A robust client-side JavaScript toolkit and UI framework was just what I missed in my stack.
I quickly downloaded the distribution and, like the rest of the world, was immediately disappointed: The source looked like Java, with long name spaces and getters/setters everywhere. The compiler looked interesting but difficult to setup and integrate in the build process. The templating engine looked ugly and required a compile step. I switched back to jQuery faster than you can say 'crap'.
The problem is I wasn't fond of jQuery either. It 's great for improving the interactivity of a page or adding special effects but leaves a lot to be desired when you are building a business-oriented Web application. As I am working on a series of Web applications for deployment through Google Apps Marketplace I decided to give Closure a second chance... moreAppengineJS is a port of the App Engine Python SDK to JavaScript. While we have taken great pains to closely emulate the Python APIs, given the fact that AppengineJS is actually powered by the App Engine Java SDK, it is difficult to emulate the directory structure of Python Web applications. The developer has to maintain a standard Servlet directory organization, with WEB-INF, web.xml, etc. That's a show-stopper for complexity-averse developers.
Not any more! The latest version of the Java SDK (1.3.5) introduces undocumented support for app.yaml, cron.yaml and the rest of the Python's SDK configuration files. The dev_appserver utility, automatically generates and maintains the WEB-INF directory from these configuration files, making simplified file organizations a reality.
I have updated the standard AppengineJS examples (appengine-example and appengine-blog-example) to demonstrate what is possible with app.yaml. I am sure you will find the updated examples much easier to understand. More information about app.yaml in the Java SDK can be found here.
During the initialization of a Web application, Nitro performs a scan of the src/root directory and constructs a sitemap. The Path middleware leverages this structure to intelligently split incoming request paths to the corresponding scriptName and pathInfo components.
The scriptName component is the path of the JSGI application that will handle the request. If the Render middleware is used, the template path is also derived from scriptName. The pathInfo component stores the extra postfix of the request. Let's use an example to demonstrate the concept:
Given the directory structure (sitemap):
/src/root/articles.js
/src/root/articles/view.js
Nitro automagically splits the request path:
/articles/12339
into:
scriptName: /articles
pathInfo: /12339
since /src/root/articles/12339.js does not exist.
We can use the pathInfo component to implement nice, RESTful URLs... more
Unless you 've been living in a cave for the last year, you know that server side (better: 'general purpose') JavaScript is all the rage. Everything started with CommonJS: the emerging standard spawned an ecosystem of compatible implementations competing against each other while advancing the JavaScript state of the art.
Then, NodeJS happened: An async only JavaScript platform, powered by V8, not really interested in CommonJS conformance. RY (the new DHH) managed to grab the attention of the developer community with cool marketing, leaving other implementations in the shadows. One such great implementation that deserves more attention is RingoJS.
Some time ago I switched from Narwhal to Ringo and never looked back. I strongly believe that Ringo is the preeminent CommonJS implementation. Here is why:
Stop drinking the Kool-Aid! Engineer your application on top of a mature, conformant and compatible platform: RingoJS.
Update: Removed a controversial link
As the lead (and lone) developer of an early Rails competitor, I am not particularly fond on DHH & Co. However, there is no denying that good ideas did emerge in the Rails ecosystem. One such idea is the use of inflection to replace configuration with convention.
Some time ago, I needed a simple code generator for one of my projects, thus I looked around for a JavaScript inflection library. After experimenting with a couple of ports of old ActiveSupport code, I decided to implement a subset of the latest ActiveSupport version and package it for CommonJS.
Download the JavaScript inflection library, and try some examples:
var pluralize = require("inflection").pluralize
pluralize("entry"); // "entries"
var singularize = require("inflection").singularize
singularize("words"); // "word"