Tuesday, September 26, 2006
RIGHT WING PUTSCH ATTEMPT IN BRAZIL
I'll try here to inform people that may not know the situation one week before the presidential elections in Brazil. After having been evinced from the power in 2002, those who always ruled Brazil since its colonisation are trying everything to prevent Lula from being elected again.
Opinions pools were pretty clear since several months ago: Lula was summing about 55% of the vote intentions against less than 30% for the right wing candidate. But the oligarchy -still very powerful in Brazil- tried to biased the public opinion. Journals such as Veja are lying more than Bush, while others like the "Folha de Sao Paulo" are obviously biasing the facts against Lula. The problem is that there aren't yet any mass media to balance those partial views from journals owned by the oligarchy.
Among the most scandalous stuff, are: the national lawyers association (OAB) is trying to impeach Lula; while the government was top blame, because they bought vote from opposition politicians to gain governability, the biggest problem is that the press only persecuted the government without even persecuting those corrupted politicians from the opposition who used to be corrupted for decades. Finally one week ago, a tape proving the corruption of Jose Serra -a former rival of Lula- has been discovered. Instead of investigating this case, the press is only focused on linking Lula with irregularities when obtaining that tape, again, they are trying to impeach Lula despite the total lack of proof and its huge popularity. They are thus trying to shunt the democratic process in Brazil because they fear to loose their privileges inherited from the colonnial situation.
Lula is very popular in Brazil, it's the first president who helped the poorest of the poor of Brazil. He is hopefully going to be elected any way. But still, the putsch attempt should be denounced anyway. It's our duty to blame the PSDB party and the mass media they manipulate wherever they go (that's why I'm telling it in english).
The issue is nothing funny. While the brazilian mass media (mainly Globo) are hiding the facts, they are more people killed in 3 months in Sao Paulo than during the whole second war in Lebanon! Corrupted politicians such as Jose Serra (PSDB) are widely responsible for letting that violence run out of control!
I'm only giving my view here. Others may defend the cause better (PT web site, , blogdareeleicao) , and the good results of Lula and popularity can be verified against numbers from impartial organisms. Here are such indicators:
numbers,
details of numbers
popularity pool
Friday, September 22, 2006
Sun accepted the annoying BeanInfo lookup in XMLEncoder as a bug, vote for it!
Hi,
As I described it here, XMLEncoder is giving too much pain when marshalling javabeans in unsigned applets. I've built up a workaround framework, but still, a few BeanInfo meta classes gets looked up on the server (while they don't even exist, so it's only freezing the network and loading the server). Also I can't tell if my framework really scale to any application and if there is no side effect. If there are they would be hard to debug in such a marshalling context.
We should just be able to disable that codebase lookup. Lots of problems with applets indeed come from the code base lookup, among them: problem with ResourceBundle, Services lookup, XMLEncoder, XMLDecoder (less annoying as the workarround is fully efficient). So I reported that to Sun Microsystems and the bug has been accepted. Here is the link.
So if you find it annoying and want a fast and easy marshalling in applets, if you want a faster and smaller JGraphpad CE, please vote for that bug here:
here
(you should create an account if you don't have one).
Raph.
As I described it here, XMLEncoder is giving too much pain when marshalling javabeans in unsigned applets. I've built up a workaround framework, but still, a few BeanInfo meta classes gets looked up on the server (while they don't even exist, so it's only freezing the network and loading the server). Also I can't tell if my framework really scale to any application and if there is no side effect. If there are they would be hard to debug in such a marshalling context.
We should just be able to disable that codebase lookup. Lots of problems with applets indeed come from the code base lookup, among them: problem with ResourceBundle, Services lookup, XMLEncoder, XMLDecoder (less annoying as the workarround is fully efficient). So I reported that to Sun Microsystems and the bug has been accepted. Here is the link.
So if you find it annoying and want a fast and easy marshalling in applets, if you want a faster and smaller JGraphpad CE, please vote for that bug here:
here
(you should create an account if you don't have one).
Raph.
Thursday, September 21, 2006
Applet revival: JGraphpad CE BLACKJAX applet size cut from 450K down to 110K thanks to Pack200!
Pack200 is an underestimated widely deployed java tool to speed up dramatically the download time of applets or webstart applications.
I was already aware of an other 'BLACKJAX' like applet deploying Apache Derby on the client. Then I heard its creator claimed he cut Derby from 2Mb down to 600kb using Pack200..
So Pack200 is a class compressing/deflating tool deployed along with the JRE since version 1.5 (Tiger). How it works: in short applets and webstart apps are still requesting a jar archive on the server. But on the server side, you catch the fact the a different encoding (pack200-gzip) is requested by java 1.5+ clients. When requested, you'll then return the "packed" jar version, else (JRE prior to 1.5) you'll return the normal jar archive. JRE 1.5+ webstart and applet clients will deflate the packed archive on the fly saving a huge amount of server load and bandwidth.
Of course, this transfer win is only worth the CPU overhead on the client side if your archive was large enough. Make your benchmark.
Results are here:
So what about JGraphpad Community Edition? Without plugins (but with JGraph) - that's configured as the minimal online diagram editor - JGraphpad CE is weighting about 450K. Pack200 cut down the archive to 110K which is a very big win! Frankly I didn't benchmarked the extra overhead against the transfer win, but overall the win is HUGE! Overall, the applet startups 3 times faster!
So, yes it means that JGraphpad CE which is by far a more complex app than TinyMCE or FCKEditor which are 'only' online word processors, is still something 2 times smaller to download!!! (And with our "Javascript sugar", it starts up just as fast). Really amazing.
Now consider that JGraphpad CE is architectured so that you can download some plugins in the background (until you really need them) while diagramming with the core JGraph application, it turns JGraphpad CE really credible for diagram online edition.
Limits: JGraphpad CE require java 1.4.2 at least to run. But with java 1.4.2 you'll have to download the classic jar (it's totally transparent however). Only happy java 1.5 and 1.6 users will get their first download time boosted thanks to the Pack200 compression.
Server Side details:
JGraphpad CE has been designed to be server side agnostic. It only two use standard GET and POST HTTP methods to download/upload a diagram from the server. So you can use what you want to handle your uploads. I personally use Python within the MoinMoin wiki (normal file upload feature), but you could use Java, PHP or Ruby, no problem.
Still getting the Pack200 trick properly configured is server side dependent. It's easy to find out how to do with a Java server.
For an Apache server, the trick is really easy, it's explained in that excellent article.
Finally, if you can't o don't want to bother with Pack200, just put the jar in the root of the applet codebase directory as usual and this will work.
I'll soon provide a bunch of official documentation about that new JGraphpad CE release. Don't hesitate to send your feedback.
I was already aware of an other 'BLACKJAX' like applet deploying Apache Derby on the client. Then I heard its creator claimed he cut Derby from 2Mb down to 600kb using Pack200..
So Pack200 is a class compressing/deflating tool deployed along with the JRE since version 1.5 (Tiger). How it works: in short applets and webstart apps are still requesting a jar archive on the server. But on the server side, you catch the fact the a different encoding (pack200-gzip) is requested by java 1.5+ clients. When requested, you'll then return the "packed" jar version, else (JRE prior to 1.5) you'll return the normal jar archive. JRE 1.5+ webstart and applet clients will deflate the packed archive on the fly saving a huge amount of server load and bandwidth.
Of course, this transfer win is only worth the CPU overhead on the client side if your archive was large enough. Make your benchmark.
Results are here:
So what about JGraphpad Community Edition? Without plugins (but with JGraph) - that's configured as the minimal online diagram editor - JGraphpad CE is weighting about 450K. Pack200 cut down the archive to 110K which is a very big win! Frankly I didn't benchmarked the extra overhead against the transfer win, but overall the win is HUGE! Overall, the applet startups 3 times faster!
So, yes it means that JGraphpad CE which is by far a more complex app than TinyMCE or FCKEditor which are 'only' online word processors, is still something 2 times smaller to download!!! (And with our "Javascript sugar", it starts up just as fast). Really amazing.
Now consider that JGraphpad CE is architectured so that you can download some plugins in the background (until you really need them) while diagramming with the core JGraph application, it turns JGraphpad CE really credible for diagram online edition.
Limits: JGraphpad CE require java 1.4.2 at least to run. But with java 1.4.2 you'll have to download the classic jar (it's totally transparent however). Only happy java 1.5 and 1.6 users will get their first download time boosted thanks to the Pack200 compression.
Server Side details:
JGraphpad CE has been designed to be server side agnostic. It only two use standard GET and POST HTTP methods to download/upload a diagram from the server. So you can use what you want to handle your uploads. I personally use Python within the MoinMoin wiki (normal file upload feature), but you could use Java, PHP or Ruby, no problem.
Still getting the Pack200 trick properly configured is server side dependent. It's easy to find out how to do with a Java server.
For an Apache server, the trick is really easy, it's explained in that excellent article.
Finally, if you can't o don't want to bother with Pack200, just put the jar in the root of the applet codebase directory as usual and this will work.
I'll soon provide a bunch of official documentation about that new JGraphpad CE release. Don't hesitate to send your feedback.
Friday, September 15, 2006
AJAX + Applet = ? ... => BLACKJAX !
OK, apparently I'm not alone thinking Ajax apps and applets can interact together to provide richer Internet applications, see this other blog also. Indeed:
"BLACKJAX" standing for:
Background Liveconnect Applet Code Kicking Javascript and XML.
That's indeed a mix between AJAX and Applet. 'Asynchronous' is better replaced by 'background' which means the same thing but makes a funnier acronyme.
A new tech is born, let's hype arround it!
I'm waiting for your comments. Cheers,
Raph.
- Ajax is better for fast responsive GUI and document centric applications.
- Applets on the other side provide better graphics, DB connectivity, XML processing or any heavy and maintainable business logic.
"BLACKJAX" standing for:
Background Liveconnect Applet Code Kicking Javascript and XML.
That's indeed a mix between AJAX and Applet. 'Asynchronous' is better replaced by 'background' which means the same thing but makes a funnier acronyme.
A new tech is born, let's hype arround it!
I'm waiting for your comments. Cheers,
Raph.
Subscribe to:
Posts (Atom)