But, like many who preach in the desert, they’ve been ignored for years for reasons other than their actual message.

However, over the past few years, WebDAV has started gaining traction as the underlying protocol for Subversion repositories over the web and in several other places. That makes this story about a new PHP library for working with WebDAV interesting.

It caught my eye, because I recently set up ALL of my machines to use JungleDisk and to do automatic backups to the WebDAV drives that it provides.

Those WebDAV drives are backed by Amazon’s S3 online disk service, meaning you get an infinite hard drive for storing whatever. Combine that with this new PHP library and you can get simple access to the giant hard drive in the sky for storing and retrieving data, backing things up, etc. Pretty cool in my book.

via PHPDeveloper

There’s always the Payflow and other bank-based systems, but they make you do quite a bit more legwork on things like fraud. They also aren’t great solutions if you just need to process a few site subscriptions or the occasional Craigslist transaction. Google’s checkout is an option, but is more oriented to “stores” and is fairly rigid in its use.

That’s why the announcement of Amazon’s Flexible Payment Service struck me as interesting. And, what struck me as most interesting is the fact that, like their EC2 (on demand virtual server) and S3 (virtual storage) services, this is built from the ground up as an API for developers, not a consumer product.

So, at launch, this isn’t something users use directly. Rather, it’s something you can use to make payments for your subscription site easy or to integrate your own version of micropayments into your content management system, etc. From what I read in their documentation, they’re really providing as deeply flexible of a system as I’ve seen for collecting, moving around and distributing money online.

I really like that approach that Amazon takes. By starting with an API, they don’t lock themselves into a specific solution. They leave it open to innovation and provide a platform instead of a packaged approach. This is far more likely to result in interesting applications than providing rigid “Buy Now” buttons that get shoehorned into sites where the concept doesn’t really apply.

The API is in limited beta at the moment, but there is already PHP code for working with the service if you sign up for and get into the beta. I know I’m looking at it seriously for some subscription/member sites that I’m working on.

In some ways, that makes positioning the Zend Framework as being substantively different from the libraries in PEAR. If you look at what the framework does, there’s not a lot of difference between it and many of the classes in PEAR. I’ll leave it to the reader to decide if these libraries were bundled into a “framework” because frameworks are the hot PHP topic right now or because they really wanted a cohesive approach to web development.

All of that aside, there’s some really useful stuff in the Zend Framework, like the Google Calendar stuff I mentioned a couple of days ago. The fact that ZF does come packaged as what amounts to a PEAR package means you can actually fairly easily use those interesting bits from inside *other* PHP frameworks.

One of the reasons I was messing with the Google Calendar stuff in the first place is that I’m *also* messing with CakePHP to build a homegrown solution for time tracking, invoicing and revenue projection for my consulting business. It’s helpful to be able to mark days like holidays and planned vacations as non-billable so you don’t include them in projections.

At any rate, I went looking for information on including bits from the Zend Framework in my Zend project. It ends up being really simple. This older article covers it pretty well and gives you an idea of how to provide “vendor” wrappers around other 3rd party PHP libraries as well.

Unfortunately, many other languages got lots of utility code in the form of frameworks and things like enterprise service buses, with Java being the center of much of that activity. Of course, I wouldn’t say that ESB’s are always necessary (hardly anything is universally useful or useless), but they certainly can be helpful in many of today’s environments.

Because ESB’s are pretty much built to provide uniform and abstract interfaces to all sorts of different systems and resources, they can be a real godsend in one of those environments that has a real patchwork quilt of technologies built up over time. Those companies often can’t reasonably get rid of or replace those older systems and an ESB can let you revive their usefulness.

At any rate, a new PHP-based ESB announced today, called Blackbird. Their quick explanation is:

Blackbird fits into the physical-entity category. It is designed to allow developers, with minimal code, to write and integrate applications. Developers create classes that are loaded and managed by Blackbird, and Blackbird provides facilities to connect to external resources, such as message queues, application ports (SOAP, SMTP, etc.), databases, and so on.

which is from their “What is an ESB?” FAQ.

Given how much this looks more like the stuff I face every day than the simple Rails-style view of reality that many other middleware projects show, this might very well prove very interesting as far as I’m concerned.

Part of the confusion comes in that authentication and authorization are 2 different things. Authentication answers the question: “Who are you?”. That’s it. Authorization answers the question: “Am I allowed to do X to object Y?”.

As I’ve been messing with CakePHP the last couple of weeks, I’ve done what lots of people do to deal with this whole messy issue: put it off until later. Right now, my CakePHP app is wide open for all activities. There’s no restrictions on anything.

That’s why, when an article on AuthComponent for CakePHP came across the CakePHP mailing list this morning, I jumped on it. AuthComponent is the de facto solution for authentication and authorization in CakePHP and this tutorial explains how to implement it fairly easily.

Now, I don’t have to spend a lot of time coming up with a solution to keep users’ data separate, I can just focus on the rules that my authorization grid needs to implement.

However, users of those hosting services aren’t really in a position to do the upgrade themselves. Even some of those who are renting dedicated servers are stuck due to those wonderful custom setups that control panels like cPanel use.

The GoPHP5 is pushing to get PHP5 adopted in those critical spots. They’ve got a bunch of applications and hosts that are all planning on going PHP5-only in February. Check to see if your favorite application or your hosting company is on the list.

Project Zero introduces a simple environment for creating, assembling and executing applications based on popular Web technologies.

And, as one would expect, ProjectZero is primarily a Java stack of tools, including the use of Eclipse as a code editing environment. Within the stack, the primary scripting language is, unsurprisingly, Groovy. However, I *was* surprised that the 2nd (and only other) scripting language was PHP and not virtual PHP, but real PHP.

The toolkit looks like it’s got some really nice features, including the fact that it speaks REST natively. Might be worth setting it up and giving it a go.

That’s pretty much where Konstrukt drops into the ecosystem. It’s not trying to be yet another Rails clone. There’s no database abstraction layer, no CRUD stubbing, etc. Just the stuff necessary for doing the REST bits, leaving you to build the rest of your application however you see fit.

Overall, this approach is probably more likely to mean the framework can be used in the real world, where you often can’t change your entire development approach just to match the framework. You can use the existing libraries you’re already comfortable with, but now with REST.

Definitely worth a look.

Once compiled, any of those assemblies can be used from any one of the other languages and it works. And, for the most part, you can then also run them on Mono on Linux and any of the other platforms Linux runs on.

I said all of that to say that finding that these guys managed to get a 4-fold increase in speed for Drupal (the PHP portal management/CMS tool) by running it in a Java environment to be an exciting revelation.

Why?

Because when you achieve this level of decoupling, you use programming languages because of how they let you *work* instead of worrying about how they *run*. If a tool or library or framework can let you cut your development time in half, you can use it, despite the runtime not being the quickest. Deploying it becomes a secondary task and can be optimized separately.

Now, we’re not entirely there yet, but there’s surprisingly large pockets of this stuff popping up and I’ll be standing over here in the cheering section.

First, I hate arguing with anecdotes. Second, if you look at most situations, the following scenario is more representative of what happens more often.

Programmer writes application. Programmer forms company to sell/host application. Company gets investors and builds server farm in anticipation of being mentioned on Oprah. Application never gets more than about 1,000 hits a day and company goes bankrupt.

Now, all of that said, there *are* some ways you can avoid both scenarios. If you are *aware* of the issues in scaling up your application and have a plan for doing so, you can kick in the bigger version as necessary and avoid the high burn rate on hardware while still keeping the application running when the traffic spikes.

Services like Amazon’s Elastic Computing Cloud (EC2) and this handy little article on load balancing MySQL for PHP can give you the tools to handle massive influxes of traffic without breaking the bank or wasting huge amounts of time and effort building the application.

The kind of load balancing the article talks about effectively spreads out the database load for SELECT statements (the ones that dominate most applications) across more than 1 server that all have the same data. INSERT, UPDATE and DELETE’s go to a single “master” server and that one takes care of updating the “slave” servers. Unless your application is really unique in how it needs to work, that strategy gives you quite a bit of room to work with to handle large spikes in traffic.

And, with EC2, you can spawn additional database “slaves” as necessary and shut them back down when the traffic spike is over. That means that if, for instance, you’ve got an application that gets 90% of its traffic between 8am and 3pm, you can vary the number of database servers running to handle that time period and shut them down for the rest of the day instead of paying to have them running idle for 17 hours a day.

Overall, this strategy works because the vast majority of PHP applications are far slower on the database side than on the PHP side. Most database-driven PHP applications fail on the database end of things long before the web server itself falls over. If you throw in a bit of caching for content pages and things that don’t change much, you’ll probably be surprised just how much traffic your site can handle and you won’t have to find a bunch of extra zero’s to pay for it.

However, if you’ve been paying attention, one of the things that people rave most about in the Rails-style MVC frameworks is the ActiveRecord method of getting data from the database/data source.

Hasin Hayder has a short explanation of how you can use an extracted implementation of just that bit out of the CodeIgniter framework.

If that’s the particular pain point that’s been bugging you, this might be just the thing you’re looking for.

That, of course, led me to look in the direction of this site only to witness the shambles that it has become.

I’ve deleted all of the comment spam that got through Akismet, fixed the RSS feeds and am digging for stories to post. I’d also love to have some help. If you’re into PHP and have been looking for an outlet to write about PHP, I’d like to hear from you. This site has decent page rank and surprisingly large amounts of traffic and I’d like to do that all justice by filling it with content.

I’m not saying you should drop proftpd and switch, but it it’s definitely an option. And, if you go digging though the code, it serves as a pretty good example of how to write a server application. So, when it’s time to write your own custom server, you’ve got a good example to work off of.

See, naming your project DOMAss, no matter how funny you and your friends think that is, will pretty much put a complete halt to people using it in professional contexts. When I’m asked to detail what external libraries I used on a $50,000 software implementation, I’m definitely not going to include a bullet point labeled as “DOMAss”. Sorry.

Fortunately, the project owner figured that out and is renaming it, but I see this a lot. Even when we’re not talking about something as obvious, even “silly” names are hard to justify. I’ve actually had to defend the use of “script.aculo.us” on 2 occasions in the last month.

I’m not saying that you need to end up with a dry acronym, but it probably matters more than you think.

This is particularly noticeable when you’ve got people on the business side of development doing the translations in MS Word and trying to copy and paste into the configuration screens and expect things to come out the display end correctly.

So, while it’s been a long time coming, kudos.

Well, apparently, Borland’s decided to morph what “Delphi” means from being only the Pascal-based rapid application development tool it’s been for a long time. That’s because they’ve announced that they’re putting out “Delphi” for PHP (via). The same RAD approach that Delphi’s been known for, but targeting PHP.

They *are* aiming this at web development, rather than desktop development, but did do some mixing in of their VCL (Visual Component Library) bits from Delphi to handle the widgets on the page.

From the screenshots and feature lists, which include browsing data sources and dragging and dropping data onto pages, it looks like it might be a decent contender in the niche. It’s currently priced at that same $300 (retail) mark that lots of other similar tools, like Komodo and Codecharge Studio are at.

I can only hope that they’ll either get a personal version (like the $139 version of Codecharge) or a free version with fewer features, like Komodo Edit as a way to get people up to speed on using it without dropping $300.

At $100, I might buy a copy for myself at work, but $300 means I’m going to have to get approval and go through processes to convince someone it’s the right tool to be using.

Still, it’s an interesting development.

Writing out exactly what you intend the code to do before you put a single bit of executable code into the file can help you understand the problem and your solution better. It also makes collaboration easier and has the extra bonus of leaving you with a well-documented bit of code when you’re done.

It’s a nice guide if you’re curious how to go about it and uses PHP as its example language.

It mostly worked on my test project (links to the frontend_dev, etc. weren’t right. They were missing a directory in the path). The installation is also a bit of a pain, but I’d be really surprised if things don’t smooth out over the coming months.

I’ve watched over and over and over and over again as companies and organizations do things like build clusters of Quad-Xeon servers to serve apps that will never (I mean actually NEVER according to their targetted userbase) see more than about 100 regular users. These are the kinds of apps where if more than 100 ever use it, they’ll be *failing*.

The people in charge of choosing hardware are absolutely terrified of the question that seems to be everywhere, “But will it scale?”. The “but” is usually there because you’ve adequately answered nearly all of the actually important questions about the application or website (you know, the ones like “does it work”), yet the questioner is still feeling uncertain and having doubts and reaches for the first handhold he can find. Ah, yes, “scalability”: the “won’t somebody think of the children” of the tech world.

Now, before someone gets all up in my grill, please note that I’ve actually worked on apps that were part of some of the largest Oracle installations *in the world* (according to Oracle). There is a time and place for the scalability discussion. There’s also a time and a place for the financial planning of a $20 million annual income. It’s just not bloody likely to be *your* time and place.

We’ve seen apps that grows spectacularly ends up having someone out front saying “If we hadn’t done the planning up front”. However, those anecdotes might lead you to believe that the only successful large applications/sites planned their huge scalability from the beginning. That somehow if you don’t do that too, you’ll never manage. That is, like the linked article says, “shark attack” kind of fear.

There are PLENTY of companies/sites/applications that stumbled a bit as they grew beyond their initial plan. There are also plenty of companies who went completely bankrupt spending $50,000 a month on a data center for a product that actually could have been profitable and covered all of its costs on $500 a month in dedicated hosting. And, there are plenty of companies (this is actually the largest category) who didn’t worry about scalability, built something that worked, put it out there, and watched it become a success without scalability ever really entering the picture.

Does it scale?

Yes. Large buildings with an airplane in its hand.