I will generally create an API which matches my needs as simply and concisely as possible, then implement that API using a 3rd party library.
This means that my main application code is not dependent on the 3rd party library, only on the API which I designed myself. I can then easily adjust the API as I see fit, or even re-implement it using a different library if a better option becomes apparent. The application code is protected from this, as there is no direct dependency on the libraries.
We're currently using GWT to build web-based business applications in Thailand.
Basically, if you're a Java developer, then I don't think it gets any better than this - you can share code between the client and server, and the GWT-RPC works extremely well.
The GWT abstractions means you can create cross-browser applications with a minimum of effort, and their use of "deferred binding" together with agressive compiler optimizations means that the resulting javascript will likely run faster than would be reasonably possible if done by hand.
I'm convinced that there's no way our team (2 people - my girlfriend and myself) would be able to create web-based applications as complex as we're doing in a short time using any other technology with I'm aware of.
Note that I said "our team" - meaning developers who specialize in builing enterprise business applications in Java, who only have enough knowledge of Javascript to get by on. Other developers who use a different server-side language, or who consider themselves javascript ninjas, might not find the benefits as great.
In our spare time we knocked up a puzzle site which uses GWT - see http://puzzles.radworkz.com./ We also have J2ME and Swing versions (not available from the site currently), and will be supporting Android once we get some spare time - all made relatively easy as thanks to GWT we can use the same Java source code on all platforms.
I live in Thailand, have done for the last 10+ years. Thais use spoon+fork for rice-based meals, and chopsticks+spoon for noodle dishes.
Just last night I had a nice plate of "bamee moo daeng" - yellow noodles with red pork - bought from a street vendor, eaten with - OMG!!1!1one!! - chopsticks.
The main advantage I can see with this is allowing each developer to use their own preferred coding style.
For example, at my company our new manager is insisting we change our existing coding standards to match his personal preferences. (I know, this is wrong for all sorts of reasons, I won't go into that here). The article's suggestion of using XML to store the underlying code, and XSLT to display the code would have solved a lot of arguments.
I have been considering developing an Eclipse plugin which would achieve a similar result. The idea being roughly:
code is stored in CVS using an agreed coding style
when a developer checks out code from CVS, it is automatically restyled according to their preferences (using Eclipse's excellent formatting tools)
developers write/debug code in their preferred style
the code is automatically restyled to the standard coding style before checkin to CVS
Slashdot Mirror
Why not get the best of both worlds?
I will generally create an API which matches my needs as simply and concisely as possible, then implement that API using a 3rd party library.
This means that my main application code is not dependent on the 3rd party library, only on the API which I designed myself. I can then easily adjust the API as I see fit, or even re-implement it using a different library if a better option becomes apparent. The application code is protected from this, as there is no direct dependency on the libraries.
Nuts, i was only looking at #101-#200 - still, they're a lot higher up when ranked by profit rather than in terms of revenue.
By revenue maybe, but it looks like they're #1 in terms of profits.
We're currently using GWT to build web-based business applications in Thailand.
Basically, if you're a Java developer, then I don't think it gets any better than this - you can share code between the client and server, and the GWT-RPC works extremely well.
The GWT abstractions means you can create cross-browser applications with a minimum of effort, and their use of "deferred binding" together with agressive compiler optimizations means that the resulting javascript will likely run faster than would be reasonably possible if done by hand.
I'm convinced that there's no way our team (2 people - my girlfriend and myself) would be able to create web-based applications as complex as we're doing in a short time using any other technology with I'm aware of.
Note that I said "our team" - meaning developers who specialize in builing enterprise business applications in Java, who only have enough knowledge of Javascript to get by on. Other developers who use a different server-side language, or who consider themselves javascript ninjas, might not find the benefits as great.
In our spare time we knocked up a puzzle site which uses GWT - see http://puzzles.radworkz.com./ We also have J2ME and Swing versions (not available from the site currently), and will be supporting Android once we get some spare time - all made relatively easy as thanks to GWT we can use the same Java source code on all platforms.
Bullshit.
I live in Thailand, have done for the last 10+ years. Thais use spoon+fork for rice-based meals, and chopsticks+spoon for noodle dishes.
Just last night I had a nice plate of "bamee moo daeng" - yellow noodles with red pork - bought from a street vendor, eaten with - OMG!!1!1one!! - chopsticks.
For example, at my company our new manager is insisting we change our existing coding standards to match his personal preferences. (I know, this is wrong for all sorts of reasons, I won't go into that here). The article's suggestion of using XML to store the underlying code, and XSLT to display the code would have solved a lot of arguments.
I have been considering developing an Eclipse plugin which would achieve a similar result. The idea being roughly:
Insert "Insert ""Insert Joke"" Jok.. nah, forget it.