Slashdot Mirror

Recently we started using maxq.
It has two modes.. One is a proxy server which you'd set your browser to. It records the post/get arguments you used for the page and records it into a jython file. The backend then uses HTTPUnit to fire off the pages.

It isn't a complete solution.. I had to create a perl filter work with mime-multi-part data, or indeed any form-data that has carriage returns.

But since it's a simple mixture of python and java, it was relatively easy to apply statistics to the processes and search for all sorts of possible error-types.

The problem with simple non-human web crawlers is two fold. First there are pages that require valid form-data. Secondly, a "nightly sanity test" is going to be operating on production data.. You'll need to carefully manage such data.

Right, because most traditional enterprises use in-house software developed most likely in COBOL.

If you're talking modern enterprises, more likely than not they are using any one or a combination of the following top-of-my-head list: BIND, apache, perl, SQL, GCC, GLIBC.

Sure, some open source screensaver or MyRecipePHPapp will not be used by Wal-Mart any time soon; but you sure as hell know that Wal-Mart uses Open Source Software.

*sigh* Those were the days.

First, I'd like to say that DBI itself is very cool, and I find it really useful.

I read the book as soon as it came out several weeks ago; I was anticipating its release very much. I skimmed most of it, though, as it's kinda lightweight. The first 50 pages deal with flatfiles.. blah. Out of 330 pages, the last 140 of them are appendix -- which is the perldoc pages that you can get a more up-to-date version (and quicker access) of online.

Also, I think it's weird that they'd spend 50 pages on (non-DBI) flatfiles, then only like 125 (excluding appendix) on DBI.

• Interview with the authors
• DBI-users archive
• Old DBI-users archive, but w/index
• Positive review by perl.org (duh..)

And how you may ask -- oh illustrious poster -- do you suppose it was done?

I (the programmer) created a middle layer of code that forced each part of what we would all call an SQL "transaction" into atomic data units, with pass/fails on each step. Alot of extra code yes. A pain to code, yes. But the bottom line is that the code which didn't require this level of commit/rollback ability also didn't have the speed penalty associated with the extra code.

We all agree that if I want transactions, I will have to pay the speed penalty somewhere, either on the database, or in the middleware, and that it is going to be more efficient (when needed) if it's just in the database. However, if I don't need it, then what? By way of example, I wouldn't expect a web site based on PHP/MySQL and transaction logic to be any faster than a PHP/SQL Server web site where the transaction logic is in the database, in fact I would expect it to be slower. But for every non-transactional SQL operation, I would expect PHP/MySQL to have a benchmarkable and reproducable speed advantage, and according to other RDBMS reviewers (one link here), this in fact has proved to be true, against even Oracle on the same machine.

Linux.com happens to be running this article on music creation software under Linux. It mentions projects such as gAlan, a project to create an application for electronic music generation, FreeBirth, an attempt at a ReBirth clone, SoundTracker, Brahms, a MIDI sequencer, and aRts, a analog synthesizer application.
----

You should check out Freebirth

Still nothing even remotely like Cubase tho.

There is an ASP to PHP converter, and an ASP addon for mod_perl.
Also, Apache does support servlets with the jserv module available from java.apache.org. There is even JSP, and GSP which i like better. Available from www.bitmechanic.com/gsp -Lkb