Slashdot Mirror

In early versions of Netscape, you could link to a remote font of your own choosing. The font-copyright people were up in arms about this, Microsoft didn't implement it in IE, and it was taken out of Netscape. That's why fonts on the web suck so much. You're either stuck with the lowest common denominator of fonts (Times Roman, Arial, Courier, or Comic Sans MS), or you can put a font into an image, which is silly but standard practice.

That's how we got into this mess.

Here's an example of a page that uses downloadable fonts. Unless you have a very old browser, it will look ugly. There's a more recent attempt to work around the problem with Flash. Wrong answer.

.NET is not code once, run everywhere as people like to believe.

ASP.Net does not always work with Firefox easily. There are issues with "browsercaps"

http://www.webdeveloper.com/forum/showthread.php?t =70011
http://developers.ie/blogs/myblog/archive/2005/03/ 10/646.aspx

Making sure all the essential webapps are certified for IE/Firefox is very important indeed.
Otherwise in the case of .NET, it would be one massive headache trying to find the original source code, fixing and testing page by page, and then recompiling/deploying the DLL

Here's an article from James Mc Parlane's Blog that describes the horrible problem with prototype.js and its ilk that define methods in Object.prototype and Array.prototype.

-Don

James Mc Parlane's Blog

Why I Don't Use The prototype.js JavaScript Library

When it comes to JavaScript there is one issue for which there seems to be two polarised camps, and that is the question of extending the inbuilt JavaScript Array and Object types via the prototype object. There are those who do, and those who don't.

I am most definitely one of those in the "Don't, because it 'would be bad'" camp.

Now, thanks to the Web2.0/Ruby On Rails/Nuevo Bubble phenomena there is a widely used library that makes great use of the prototype object and that is Sam Stephenson's prototype.js library.

I ran into an issue 6 months ago and decided I would never ever use prototype.js, despite the fact, and I don't say this often, that after an examination of the code, prototype.js is an inspired work of art.

What I and many many others have discovered is that using the prototype object on the Array and Object inbuilt types increases the chances that your code will conflict with existing or external code. It makes your code not play well with others, so once you start using prototype.js, you have to keep using prototype's paradigm because by extending Array and Object via the prototype object it secretly modifies some of JavaScripts default behavior.

It's the crack cocaine of JavaScript.

This can be a good thing. If you don't want to waste time writing your own JavaScript libraries and learning how everything really works, then using prototype.js and the libraries that extend it (e.g. Open Rico) is a very good way of developing. You will save time and money and all you need to learn is "the way of prototype.js".

Now the entire tasty raisin for the MetaWrap JavaScript libraries is to allow others to easily remix MetaWrap applications via a client side API that can be invoked via XML. The result is that CSS, HTML and JavaScript can be injected into the application, or XML and HTML at any point in the rendering pipeline of the application.

So I simply had to reject prototype.js because, out of the box, the very first time I tried to use it - it snuck out and cut the throat of the JavaScript I was using that relied on performing a for(x in object) on the contents of an Array.

In JavaScript, value types are subdivided into primitives and objects. Objects are entities that have an identity (they are only equal to themselves) and that map primitive properties to other value types, ("slots" in prototype-based programming terminology) - see these testcase #5 - #7. Because of this behavior JavaScript objects are often mistakenly described as associative arrays or hash tables, while functionally they behave like an associative array/hash table, technically this is not their true nature.

Despite this the JavaScript programming world has come to rely on these objects behaving as predictable associative array/hash tables - and prototype.js breaks this.

There is no object more galactically useful than a good associative array/hashtable. There is no problem that can't be solved with a large enough hash table. In highly granular interpreted languages like JavaScript it provides a way to dip into pure native brute force computing power mostly unhindered by the language interpreter.

For example, searching on Paris Hilton after her little slip-up returned hundreds upon hundreds of affiliates all spamming the same site which, in the end, did not actually have the infamous video. Today, there are much fewer such links.

Similarly, searching on an obscure actor would return hundreds of sites all wanting to sell you posters, DVDs and videos of the movie they had their bit parts in, but little actual information.

That is a good example of information pollution, a term I heard first from Earthlink.

It is the result of affiliation, combined with legions of small-time marketers who all think their affiliate page should be number one in a category. Using the services of firms like Web Position Gold, many succeeded, pushing relevant results off the first ten pages.

Also, Amazon and Ebay have seized most of the keywords, which Google is slowly forcing off onto the paid listings.

I had actually quit Google and went over to MSN, as it had received much less attention by the page spammers and was able to return much more relevant results. But I prefer to browse using an early version of Netscape and for some reason doesn't load MSN well at all.

Google looks a lot cleaner, but spammers still seem to be trying their tricks. For instance, Google cleaned up that meta-refresh fault which would index the text full of keywords and ship you off to the spammed site once you went for it.

But spammers have come back with a javascript substitute that does the same thing.

... but there were definitely other web systems that could deliver content based on user preferences seven years ago.
... The Age of the Customized Web Site
Reprinted from Web Developer(R) magazine, Vol. 1 No.1 Winter 1996
Sic{k}.
CC.

what kind of security issues are involved?

IMO, I think it's important to be comfortable with more than one "type" of IDE when writing Java code. The sophisticated Java IDE's are often very slow to startup, especially if they are written in Java itself (e.g. JBuilder, Forte take upwards of 20 seconds to startup on my machine sometimes - JDK1.3, 512 MB, 400 MHz) which can be a pain in the arse for impulse coding or quick changes to code when the IDE is not running.

Therefore I've found it helpful to have two IDE's I'm comfortable with:

1) A stripped down, quick and dirty text editor which allows you to get in and out of files quick (e.g. notepad, ultraedit under Windows, whatever)

2) A whizz bang do everything for you IDE which provides a huge amount of features (Wizards, code management, plugins) like JBuilder, IBM VisualAge for Java, Forte, Oracle JDeveloper etc etc

See the following links for full lists of Java IDEs out there:

http://www.javaworld.com/javaworld/tools/jw-tools- ide.html

http://www.webdeveloper.com/java/java_ides.html

Personally I've used about 10-15 editors tailored for Java and enjoy using Borland JBuilder5 (Enterprise) at the moment for the following reasons:

Wizards for just about any Java component you would want to create - Servlets/JSPs/EJBs/CORBA/Javabeans/XML. This avoids writing a lot of tedious code.

The ability to code all parts of a Java web app. with proper syntax highlighting, and code completion etc. in the one IDE (HTML, Servlets, JSPs, EJBs). The ability to preview the web. app. in the IDE without starting up the app. server. etc, can be helpful (JBuilder comes bundled with Tomcat (and Cocoon), supports Websphere, Weblogic, Borland Appserver and other plugins).

Code completion and insight - Java has lotsOfLongMethodNamesWhichAreSometimesABitTooDescr iptive and a pain to type

Rapid GUI prototyping (null, XYLayout) for Swing clients (if anyone still builds Swing clients, just joking ;-))

XML support, Cocoon, XML to DTD, DTD to XML, XSLT transformation previews. You'll may need something like XmlSpy for more sophisticated XML development however.

Full customisation of pretty much any part of the IDE, keymappings, toolbars etc - I like to use my own keymappings.

Having all parts of a Java component (e.g. methods, attributes) accessible by clicking on its name in a GUI IDE panel - this can be nice to locate sections of code when a Java class becomes large.

I could go on and on, the full feature matrix is here. Of course JBuilder Enterprise costs a *lot of money* and I probably would'nt buy it for home use.

One problem, I refuse to work on JBuilder with less than 512MB RAM. It's written entirely in Java and although they do a great job to make it as fast as it is (using custom class loaders I've read somewhere), stuff like code insight and code completion is painful with anything less than 512MB RAM.

This is old news for these two companies...

They have been sueing and counter-sueing for quite a while, i.e.:

Macromedia filed a countersuit against Adobe in the U.S. District Court for the District of Delaware that alleged the invalidity of Adobe's '528 patent, and claimed that several of Adobe's software products infringed upon Macromedia patents.

Macromedia's countersuit alleged that Adobe infringed three Macromedia patents:

5,467,443: "System and method for automatically generating derived graphic elements"

5,151,998: "Sound editing system using control line for altering specified characteristic of adjacent segment of the stored waveform"

5,204,969: "Sound editing system using visually displayed control line for altering specified characteristic of adjacent segment of stored waveform"

And so on...

Some good info:

www.cptech.com has some good info and links on the two sueing and counter-sueing.

macweek.com seems to indicate the the whole thing is over the fact that 'that Adobe Premiere violates two patents related to visual display and editing of soundforms. Macromedia also contended that Adobe's patents in the case are invalid and thus unenforceable.'

This seems to be a defense patent battle, in that both sides are trying to invalidate the other sides patents...

A few more links...

www.creativemac.com says 'Macromedia Fires Back at Adobe'

And an editorial by WebDeveloper.com... and I quote:

Adobe and Macromedia have been fighting for Web designers' patronage for years. Now that battle will be entering the court system, as Adobe accuses its rival of patent infringement.

Ultimately, I would say this a standard battle of patents. Such things have taken place many a time, this time it just happens to involve software patents, and thus happens upon the radar of geeks and slashdot...