Since it is obvious that bullet barrages are a software engineering artifact that should be reused, it's good to know there is an XML dialect which describes them.

Quote:

BulletML is the Bullet Markup Language. BulletML can describe the barrage of bullets in shooting games. (The storm of Progear, Psyvariar, Gigawing2, G DARIUS, XEVIOUS, …) There are many advantages for using BulletML.

• BulletML can describe the complicated barrage of bullets in recent shooting games easily.
• BulletML demo applet is available. Write BulletML document, and check it on this applet.
• BulletML is XML-based language. It offers data portability and reusability.

From http://www.asahi-net.or.jp/~cs8k-cyu/bulletml/index_e.html

Well that's one way to respond to shark jumping allegations (and to Yahoo finally upgrading their email to 1 Gigi).

BTW, what is it with everyone claiming that “only a few people use 1G”? My main (non-Gmail) work mail account has a few hundred meg archived already, and I've only been there since January. At my previous work I had nearly 5 Gig of mail archived (4 years of keeping everything).

I had to unsubscribe a number of mailing lists from my @apache.org address because I foward that to my GMail and it was filling up too quickly – it got to 400M before I deleted some archives. Now I've got 50M in my GMail account and I'm annoyed at how difficult it is to keep organized. (Of course it is hugely better than any other web-based mailing client, but for high volumns of mail it just is too much work)

(And since I'm talking about the jumping the shark article it's not as clear cut as it says that Yahoo's search API is better than Google's. I've been working with a number of engines APIs lately and there isn't a lot to choose between them. A REST interface to Google is the only thing it is missing – but Yahoo doesn't have the SOAP interface, so you can argue that both ways)

JBoss Portal 2.0 looks pretty interesting. Now that it is JSR168 compliant (what were they thinking with not doing that in the initial version?) and has a reasonable feature list it will be good to see some more competition in the open source portal market place. Hopefully the increasing number of players (EXO, Liferay, Jetspeed 2.0 and now JBoss Portal) will increase the quality of the offerings.

More on multi-threaded programming models:

Tim Sweeney resumes:

“You can expect games to take advantage of multi-core pretty thoroughly in late 2006 as games and engines also targeting next-generation consoles start making their way onto the PC.

Writing multithreaded software is very hard; it's about as unnatural to support multithreading in C++ as it was to write object-oriented software in assembly language. The whole industry is starting to do it now, but it's pretty clear that a new programming model is needed if we're going to scale to ever more parallel architectures. I have been doing a lot of R&D along these lines, but it's going slowly.”

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2377&p=4

I've posted previously on multi threaded programming under Java 1.5. The programming model is pretty powerful and worth investigating even now for Hyperthreaded CPUs

Matt Raible links to a description of IE's handling of PDFs. Having done some work in this area (and worked with someone else who had to figure this all out for himself) I can tell you that it isn't fun.

In the “Something that I normally wouldn't bother writing about but some of my readers might find intersting department” I'd just like to report that:

SunGard Data Systems Inc. announced today that it is in discussions with a consortium of seven private investment companies seeking to purchase the financial services disaster recovery service provider for more than $10.5 billion.

From http://www.computerworld.com/securitytopics/security/recovery/story/0,10801,100550,00.html

60% of Sungard's revenue comes from “its software and processing business”. Hmmmm….

From Jonathan Schwartz's Weblog today:

ps. stay tuned for news on Java's open source accessibility, too…

I hope that is what it sounds like.

People seem unaware that it is pretty easy to use a lib directory in Maven builds. Many ant builds use structures like below:

+---lib
+---src
    +---conf
    +---java
    +---test

I find this a useful layout, especially if you have jars that do not exist in the main Maven repository.

In Maven, you might have a dependency declared like this:

<dependency>
	<id>cas</id>
	<artifactId>cas</artifactId>
</dependency>

In your projects.properties file you can override the location of each jars like this:

maven.jar.override=on
maven.jar.cas=lib/cas-2.0.12.jar

You need to add an entry for each jar you want to override the location of. I haven't figured out how to make it work for all the alternate types of dependency declarations, though.

Obviously this (like too many things in Maven) is something that should be a lot easier than it is. I think that the project.xml should be able to specify a build-repository that is checked before the local repository, since that would make self-contained builds a lot easier. In the mean time, this is a useful measure that I've found useful.

With such a large MSS system, a large disk cache is
still essential to deliver data to jobs in reasonable time.
SLAC’s 1.3PB is currently backed by 160TB of disk
cache.

Lessons Learned from Managing a Petabyte

That would make a decent home media server.