Scott Rosenberg says that a new Internet bubble is in full swing, based on his observations at Web 2.0. I definitely think we’re already in the “throw the bad money after the good” phase of investing in “Web 2.0” companies. And once again, it sure looks like another bubble will pass by without my walking away with filthy lucre. So it goes.

Update: $25 million for Weblogs, Inc. Need I say more?

The big news today seems to be that stealth startup 24 Hour Laundry has decloaked, launching Ning. (I sent these guys my résumé a few months ago on a lark, they turned me down.) The idea of the site is to provide people with tools to build their own social applications like del.icio.us, Flickr, and even “Hot or Not.” I guess Yahoo Groups on steroids would be one way to think about it, but I haven’t digged down enough to really tell. I have to subject it to the two vectors of analysis that are required for all interesting new Web applications — what can I use it for and what ideas can I steal for my own applications?

The one big question I had right way was, “How do you build the applications?” Do you just pick components in HTML forms or do you edit source code? What language is the source code in? For more detailed information I’m going to have to wait to see if I get accepted as a developer. In the meantime, it looks like you build the apps using PHP and a proprietary templating language called XNHTML, and that you can either build a new app from scratch or clone any existing application, and that the source to all of the applications is availbale to anyone with a developer account. (The developer documentation is published as one of the applications on the site.)

Congratulations to the guys from Upcoming.org for their acquisition by Yahoo. You can read Andy Baio’s take on it over at waxy.org. The three creators of the site will be working at Yahoo, and I’m sure they were paid for their troubles as well. Not only is this great news for them, but it’s great news for the little guy in general. It’s always nice to be reminded that if you build something cool in your spare time, it can turn into something much bigger.

Update: I also see that NewsGator has continued to roll up RSS aggregator companies, this time purchasing NewNewsWire. Hopefully this is fantastic news for Brent Simmons personally, but we’ll have to see what it means for NetNewsWire users. (I’ve recently just started using it myself.)

Rails creator David Heinemeier Hansson argues that you should keep your business logic in your business layer rather than in your database. In other words, leave those stored procedures, triggers, and constraints aside. This is a debate that I’ve had many times on various projects. I’ve walked into a room more than once and had to face down a customer who wanted to restrict all access to the database to an API composed of stored procedures that my code could call. I’ve won every time but one.

On the project where I lost, the database was massive and complex — the database calls literally took minutes to run, and the customer understood that data better than we ever would. They were hardcore PL/SQL and Powerbuilder programmers, and we were building a Web application in Perl and ColdFusion. There were a number of hoops we had to jump through but things turned out pretty well in the end, and that was definitely the right approach for the project. There was no need to duplicate expertise between their IT staff and the group I was working with, and we got the project done in only four times the amount of time originally allotted. Success!

Every other time, when the database was much simpler (and indeed nearly always designed to the specifications provided by the development team), I’ve been able to avoid shoving logic into the database. I agree with Hansson’s core argument for it, which is that there’s just no reason for it. Your business logic should all live together. I would perhaps make an exception if multiple applications running on different platforms needed to access the database and duplicating the logic wouldn’t make sense, but these days I think a better approach would be to stick a Web service in the middle and use that as the common ground among applications.

One area where he and I might disagree is on the use of constriants. I’m not a fan of stored procedures or triggers, but constraints strike me as a necessary part of a decent database. If you create a child object that must be associated with a specific parent object, including a foreign key relationship costs you nothing and guarantees that your data integrity will not be compromised by someone’s bad code. The constraint still has to be enforced in the business layer anyway, but including it in the database both insures you against mistakes and makes the database layer more clearly documented. If someone comes along later and dumps the database schema they’ll see what the designer intended (without being forced to look at the application source as well).