Elegant MicroWeb is a software products and services company working across geographic, cultural, and technological boundaries. With more than 10 years of experience dealing with global clients, we have continuously practiced and refined our offshore delivery model offering great value even in complex situations.
"Keep the user in mind and the rest will follow" is the principle behind development of each product at Elegant MicroWeb. Keeping the users in mind, Elegant MicroWeb has released a new version of ElegantJ Charts, a Java Beans Charts and Gauges library for visualization of data. The new ElegantJ Charts is a collection of charts with features such as 3-D presentation, seamless data handling from different data sources, XML interoperability, N-level Drill-Down and many more.
Programmers have choice to integrate ElegantJ Charts in their application through a comprehensive API, using chart components in their favorite Java IDE, or use ElegantJ Charts Designer for visual configuration with help of hundreds of ready?to?use XML templates. New ElegantJ Charts contains following key features.
Over 50 different types of charts
Three-dimensional view with transparency and depth control
N-level Drill-Down in charts for visual mining
Tooltips and notes for graphs
Comprehensive set of properties and events to configure visual presentations, interactive actions, and data binding
XML template support for integration and interoperability
Graph designer toolkit for visual customization with hundreds of ready-to-use templates
Efficient data binding for varied enterprise data sources
Works with almost all Java architectures
You can download the fully functional evaluation version from Download section or view gallery of snapshots of numerous type and presentation styles of ElegantJ Charts from Gallery section.
Visit http://www.elegantjcharts.com/ for complete information about ElegantJ Charts Library.
2007年5月17日星期四
Geert Bevin: Wrong assumptions about OpenLaszlo
In "Wrong assumptions about OpenLaszlo," Geert addresses some misconceptions people have about OpenLaszlo, including support for multiple runtimes and the use of XML for declaring the UI elements - pointing out that people complain about OpenLaszlo's use of XML, but rarely complain about XHTML being XML as well.
... about OpenLaszlo's support for multiple runtimes... Contrary to Java it doesn't intend to be Write Once Run Anywhere The multiple runtimes however allow you to have exactly the same architecture for building different applications or different parts of the same application. Some things are better done in DHTML (internationalization, accessibilty, native feel, font rendering, execution performance, memory footprint) and others are better done in Flash (video, music, multimedia, rotated fonts, high amount of animations, ...). You can reuse a lot of your code and most of it does work across runtimes, which is a nice benefit. I encourage everyone to try out OpenLaszlo's DHTML engine, it's quite impressive even at this first stable release status.
This brings me straight to Flash support and the apparent fact that Flex and Laszlo are at least on equals footing here. Some people actually seem to think that Flex has the edge since Adobe controls Flash too. In reality however, Flex only runs on Flash 9 while OpenLaszlo runs on Flash 7, 8 and 9 and does proper optimizations for each specific version.
Threaded replies
· Geert Bevin: Wrong assumptions about OpenLaszlo by Joseph Ottinger on Fri May 11 11:28:01 EDT 2007
· Re: Geert Bevin: Wrong assumptions about OpenLaszlo by Ilya Sterin on Fri May 11 15:57:18 EDT 2007
· Re: Geert Bevin: Wrong assumptions about OpenLaszlo by Ilya Sterin on Fri May 11 15:57:55 EDT 2007
· Which to start with by Matt Giacomini on Sat May 12 00:35:39 EDT 2007
· Re: Which to start with by marc schipperheyn on Sat May 12 06:56:15 EDT 2007
· Re: Which to start with by James Ward on Sat May 12 11:49:52 EDT 2007
· Re: Which to start with by Matt Giacomini on Sat May 12 14:33:45 EDT 2007
... about OpenLaszlo's support for multiple runtimes... Contrary to Java it doesn't intend to be Write Once Run Anywhere The multiple runtimes however allow you to have exactly the same architecture for building different applications or different parts of the same application. Some things are better done in DHTML (internationalization, accessibilty, native feel, font rendering, execution performance, memory footprint) and others are better done in Flash (video, music, multimedia, rotated fonts, high amount of animations, ...). You can reuse a lot of your code and most of it does work across runtimes, which is a nice benefit. I encourage everyone to try out OpenLaszlo's DHTML engine, it's quite impressive even at this first stable release status.
This brings me straight to Flash support and the apparent fact that Flex and Laszlo are at least on equals footing here. Some people actually seem to think that Flex has the edge since Adobe controls Flash too. In reality however, Flex only runs on Flash 9 while OpenLaszlo runs on Flash 7, 8 and 9 and does proper optimizations for each specific version.
Threaded replies
· Geert Bevin: Wrong assumptions about OpenLaszlo by Joseph Ottinger on Fri May 11 11:28:01 EDT 2007
· Re: Geert Bevin: Wrong assumptions about OpenLaszlo by Ilya Sterin on Fri May 11 15:57:18 EDT 2007
· Re: Geert Bevin: Wrong assumptions about OpenLaszlo by Ilya Sterin on Fri May 11 15:57:55 EDT 2007
· Which to start with by Matt Giacomini on Sat May 12 00:35:39 EDT 2007
· Re: Which to start with by marc schipperheyn on Sat May 12 06:56:15 EDT 2007
· Re: Which to start with by James Ward on Sat May 12 11:49:52 EDT 2007
· Re: Which to start with by Matt Giacomini on Sat May 12 14:33:45 EDT 2007
Mike Spille: Ember, Eeyore, and the Mad Cow
Mike Spille has written a blog entry that captures the essence of the battle between pragmatism and perfection, in "Ember, Eeyore, and the Mad Cow."
It's intern season at work, and working with people who are fairly new to the business has caused me to consider more deeply what software development's all about. If you look at sites like TheServerSide, or read the mountain of books out there about software development, or even silly blogs like this one, you constantly see deep discussions about design, architecture, scalability, performance, testability, maintainability blah blah blah. You might get the impression that developers work in these high tech, pristine offices and are paid to Think Deep Thoughts.
Or maybe you're more of a slashdot fan. Unlike the squeaky clean Deep Thinkers you read about the Obfuscated C contest, the least amount of code to write a web server, hacking into the phone system with an old sock and a gum wrapper, and deploying a successful e-commerce site on the web with 3 lines of code via Ruby on Rails.
I think the reality for most software jobs spans across both of these viewpoints. For those of us who speak more on the Deep Thoughts side - well, your average guy in IT doesn't spend all day every day diagramming architectures and arguing OO design or critiquing marshalling techniques. Or checking 2-PC state diagrams or the nuances of async event notification via NIO. Some days may be spent doing nothing but fielding support calls. You might lose several days tracking down a single bug. You may even find yourself putting together a quick and outrageous hack to meet a deadline or to hold production together long enough for a real fix to be developed and put in place. And at the end of some days you may look back and realize you did litle more than surf the web and take a break for lunch.
He then goes on to describe what it took to fix what was originally just an obscure bug - one not addressed by containers or dependency injection or (gasp!) the JCP.
[The debugging effort] involved lots of guessing, thinking, arguing, running SQL queries, starting at reports, and hacking together truly ugly scripts to try to pull all the pieces together. A hunk of it was fairly pretty - the initial automated comparison program. But most of it was plug ugly.
His final paragraph is a summary of the job, in a dramatic nutshell:
But this is the job. "Make it work and keep it working". All the skull sweat comes from interpreting that phrase - what does it take to make it work, what does it keep it working, and how do those two priorities interact with each other. At a stupidly high level, what this means is that in some situations you want to be in an ivory tower, puffing on your pipe while you argue abstract ideas around development methodology, and system architecture and code design. And in other situations you put on your filthiest blue jeans and start crawling around in the innards of your system, banging on pipes and checking fluid levels and getting yourself dirtied and soiled while you try to find out what's wrong with the beast. It's a mad mix of fore-thought and off-the-cuff, careful planning and snap decisions, dealing with the long term and the "right now!". To ultimately succeed you cannot afford to be one person with one view, but 3 people, or 7 or 8 or 40, or whatever number it takes to fit the reality. In the end all that matters is "Make it work and keep it working". And ultimately if you won't do it they'll go and find someone who will.
It's intern season at work, and working with people who are fairly new to the business has caused me to consider more deeply what software development's all about. If you look at sites like TheServerSide, or read the mountain of books out there about software development, or even silly blogs like this one, you constantly see deep discussions about design, architecture, scalability, performance, testability, maintainability blah blah blah. You might get the impression that developers work in these high tech, pristine offices and are paid to Think Deep Thoughts.
Or maybe you're more of a slashdot fan. Unlike the squeaky clean Deep Thinkers you read about the Obfuscated C contest, the least amount of code to write a web server, hacking into the phone system with an old sock and a gum wrapper, and deploying a successful e-commerce site on the web with 3 lines of code via Ruby on Rails.
I think the reality for most software jobs spans across both of these viewpoints. For those of us who speak more on the Deep Thoughts side - well, your average guy in IT doesn't spend all day every day diagramming architectures and arguing OO design or critiquing marshalling techniques. Or checking 2-PC state diagrams or the nuances of async event notification via NIO. Some days may be spent doing nothing but fielding support calls. You might lose several days tracking down a single bug. You may even find yourself putting together a quick and outrageous hack to meet a deadline or to hold production together long enough for a real fix to be developed and put in place. And at the end of some days you may look back and realize you did litle more than surf the web and take a break for lunch.
He then goes on to describe what it took to fix what was originally just an obscure bug - one not addressed by containers or dependency injection or (gasp!) the JCP.
[The debugging effort] involved lots of guessing, thinking, arguing, running SQL queries, starting at reports, and hacking together truly ugly scripts to try to pull all the pieces together. A hunk of it was fairly pretty - the initial automated comparison program. But most of it was plug ugly.
His final paragraph is a summary of the job, in a dramatic nutshell:
But this is the job. "Make it work and keep it working". All the skull sweat comes from interpreting that phrase - what does it take to make it work, what does it keep it working, and how do those two priorities interact with each other. At a stupidly high level, what this means is that in some situations you want to be in an ivory tower, puffing on your pipe while you argue abstract ideas around development methodology, and system architecture and code design. And in other situations you put on your filthiest blue jeans and start crawling around in the innards of your system, banging on pipes and checking fluid levels and getting yourself dirtied and soiled while you try to find out what's wrong with the beast. It's a mad mix of fore-thought and off-the-cuff, careful planning and snap decisions, dealing with the long term and the "right now!". To ultimately succeed you cannot afford to be one person with one view, but 3 people, or 7 or 8 or 40, or whatever number it takes to fit the reality. In the end all that matters is "Make it work and keep it working". And ultimately if you won't do it they'll go and find someone who will.
Dealing with asychronous bugs in AJAX
Nick from the BadMagicNumber blog talks about how internet latencies can cause unpredictable in AJAX applications, if a human client clicks around and doesn't wait for a response. The solution is to either lock the view or pass view state down with each web request.
Read AJAX: Best practice for Asynchronous Javascript.
Read AJAX: Best practice for Asynchronous Javascript.
Scalability has nothing to do with language/framework
Brian McCallister, responding to recent blog debates about Ruby on Rails scalability, reminds us that language, library, and platform are almost wholly irrelevent when it comes to scalability. Brian did an interesting analysis on LAMP's "share nothing" caching approach - a good read.
Read Scalability.
Read Scalability.
Jim Driscoll: GlassFish, and Tainted Love
Jim Driscoll brings up Sun's "tainting policy" for Glassfish in "GlassFish, and Tainted Love." (To be specific: he says there isn't one, despite claims to the contrary.)
订阅：
博文 (Atom)