Frameworks


23
Oct 10

You’re doing it wrong

The following appeared on a mailing list I subscribe to.

Hi,

I have 3000 definitions in my config.ini .

routes.cates1.route = “list1/:page”
routes.cates1.defaults.module = “default”
routes.cates1.defaults.controller = “list”
routes.cates1.defaults.action = “index”
routes.cates1.defaults.id = 1
routes.cates1.defaults.page = 1
routes.cates1.reqs.page = “d+”

….
….

routes.cates3000.route = “list3000/:page”
routes.cates3000.defaults.module = “default”
routes.cates3000.defaults.controller = “list”
routes.cates3000.defaults.action = “index”
routes.cates3000.defaults.id = 3000
routes.cates3000.defaults.page = 3000
routes.cates3000.reqs.page = “d+”

I think my web site (it isn´t production) is slower than before. This is Okay or I need other solution.

bye

George

Like this post? You might also like Coalmine, my centralized error tracking service for your apps. Coalmine captures errors and all kinds of helpful debugging information, notifies you, and makes it all searchable. Check it out!

7
Nov 08

Zend_Search_Lucene: Not enterprise-ready

Zend Framework has been attracting more and more attention from the PHP community lately, and while it lacks certain things (like code generation) that other frameworks (like Rails) have implemented to great effect, Zend Framework 2.0 is slowly taking shape and it looks like it will be the framework of choice for startups and enterprises alike. (Yes, it will even have code generation.)

But despite having several “enterprise-ready” components, I’ve found that one in particular is not: Zend_Search_Lucene, Zend Framework’s native PHP implementation of Apache Lucene, written in Java.

Don’t get me wrong; Zend_Search_Lucene is great for a small site or blog. However, from extensive personal experience, it is not appropriate for a site with a medium or large index. I think this should be noted upfront in the documentation.

Against my better judgment, the company I work for migrated our previous search solution to Zend_Search_Lucene. On pretty heavy-duty hardware, indexing a million documents took several hours, and searches were relatively slow. The indexing process consumed vast amounts of memory, and the indexes frequently became corrupted (using 1.5.2). A single wild card search literally brought the web server to its knees, so we disabled that feature. Memory usage was very high for searches, and as a result requests per second necessarily declined heavily as we had to reduce the number of Apache child processes.

We have since moved to Solr (a Lucene-based Java search server) and the difference is dramatic. Indexing now takes around 10 minutes and searches are lightning fast. What a difference a language makes.

Like this post? You might also like Coalmine, my centralized error tracking service for your apps. Coalmine captures errors and all kinds of helpful debugging information, notifies you, and makes it all searchable. Check it out!

3
Sep 08

Zend_Paginator

On and off for the last two or three months, Jurriën Stutterheim and I wrote Zend_Paginator, the pagination component for Zend Framework. Yesterday it was officially released as part of Zend Framework 1.6.

This was our first contribution to the framework, and was very much a collaborative working relationship. I first created a proposal in about half an hour on Christmas Eve 2007 for how I thought a pagination component should work after being dissatisfied with existing solutions. It contained some good ideas about flexibility, but on its own it was half an idea, at best. So I promptly forgot about it.

Then Jurriën came along and created a proposal based on his Zym_Paginate component, which was part of Zym Framework, itself an extension of Zend Framework.

At the urging of Zend, we merged our proposals. We refined our ideas, incorporating aspects from each of our proposals in addition to brand new thoughts. Then I wrote a new component from scratch based in part on Jurriën’s existing work. He wrote the excellent unit tests (with 100% code coverage, not always easy to achieve!), and I wrote the DocBook documentation. I also can’t overstate the positive impact the community had, particularly from Bryce Lohr who prompted us to decouple and reorganize major portions of the component.

Anyway, I’m very happy with how it turned out. There are still a few issues, most of them minor—and because of the component’s flexible design, there are almost always workarounds. They should be fixed in time for 1.6.1.

Here’s some praise for the component:

Upcoming Zend_Paginator in 1.6 is absolutely brilliant. Wasted time be gone.
Joakim Nygård

The new Zend Framework 1.6 release candidate includes a Zend_Paginator class, which is an excellent thing to have around because I know I’ve re-invented that wheel on every site I’ve developed. My only criticism of the new Zend_Paginator is it offers a daunting amount of possibilities.
Chris Beer

This really is a beautifully crafted component, very elegant, very classy.
—David Mintz, via e-mail

I’ve seen dozens of different paginators in the last couple of years, and to be honest, this one is by far the best. You got everything right! I can’t wait for this component to hit the incubator.

It’s great, well done guys.
Federico Cargnelutti

Like this post? You might also like Coalmine, my centralized error tracking service for your apps. Coalmine captures errors and all kinds of helpful debugging information, notifies you, and makes it all searchable. Check it out!

30
Aug 08

ORM comes to the iPhone: SQLite Persistent Objects

Although I cut my “programming teeth” on functional database APIs, I happily gave them up years ago in favor of ORM—and I have no desire to go back.

Naturally, the iPhone a certain NDA-bound platform of indeterminate nature has no ORM layer for the bundled SQLite library.

So I was pretty thrilled to stumble onto Jeff LaMarche‘s SQLite Persistent Objects. Think Active Record, except instead of the database telling your model what it’s supposed to look like, the model tells the database what it should look like. Jeff calls the pattern “reverse Active Record”, but I think it looks a lot like Data Mapper.

The best part is that it works exactly like you’d expect:

Person *person1 = [[Person alloc] init];
person1.givenName  = @"John";
person1.familyName = @"Doe";
person1.birthdate  = [NSDate dateWithString: @"1908-11-24 04:12:00 -0800"];
[person1 save]; // Inserts a new row
[person1 release];

Person *person2 = [[Person alloc] init];
person2.givenName  = @"John";
person2.familyName = @"Smith";
person2.birthdate  = [NSDate dateWithString: @"1945-09-13 03:54:00 -0800"];
[person2 save]; // Inserts a new row
[person2 release];

// Oh wait, they both go by Jack

NSArray *people = [Person findByGivenName: @"John"];
for (Person *person in people) {
    person.givenName = @"Jack";
    [person save];
}

It’s still in the very, very early phases of development (it’s at revision 5), so there are some issues to work out, like what happens when the schema changes.

There are also currently a few bugs preventing SQLite Persistent Objects from, uh, compiling at all. I’ve submitted a patch (removed) that addresses these issues. I’ll update this entry when it’s been applied to trunk. (Update: It appears to have been patched.)

Regardless, it’s worth keeping an eye on, even if you don’t use it right away. Seriously, download the source and check it out.

Like this post? You might also like Coalmine, my centralized error tracking service for your apps. Coalmine captures errors and all kinds of helpful debugging information, notifies you, and makes it all searchable. Check it out!

12
Jun 08

The future of PHP

Jurriën Stutterheim posted an interesting article on the future of PHP recently (“PHP… what to say?”). In it he argues that PHP shouldn’t try to maintain complete backwards compatibility in the next release, saying,

“PHP 6 will make or break PHP as a language. For PHP to make it, it needs a clear vision of what it wants to be. Trying to maintain compatibility with ancient and mostly poorly written scripts can’t be part of this vision.”

The language can’t advance, he says, if it’s chained to outdated yet popular open-source projects.

But here’s the problem. If you’re intent on being the lingua franca of the Web, backwards compatibility is critical. It’s part of that compatibility-stability-security triumvirate that users love.

You see this conflict elsewhere in the tech industry. Microsoft’s greatest strength and biggest weakness is backwards compatibility. Users love it because decade-old programs still run in Windows. If you’re, say, a medical transcription company that uses an application written in the late ’90s, your company is going to stay with Windows indefinitely, because no external factor forces you to update that application. And Microsoft isn’t going to do anything to jeopardize that.

This is the same wall that PHP is headed toward. I view it as a wall. Others might not; it’s certainly not a bad place to be at the moment. On the plus side, it means PHP developers have more opportunities afforded to them because of the popularity of the language. The downside is that they can look left and right and see niche languages innovating in compelling ways. The more “cosmopolitan” PHP programmers inevitably develop language envy and move on, but these are exactly the kind of developers PHP should fight to retain.

It doesn’t have to be this way. PHP could flourish as a smaller language. This is the tack that Apple has taken, and it seems to work well for the company and its users. Apple is one of the most innovative companies in the entire tech industry owing in no small part to this strategy.

For my part, I’d like to see first-class functions and closures included in the language. An object-oriented API ($file->read(1024)) alongside the procedural functions (fread($resource, 1024)) would also be welcome.

But none of that will happen, because PHP is a language in decline. Not a decline in usage—it will only continue to expand its reach—but in the addition of innovative features from other languages. There will be no need to evolve; most of the agitators for change will have moved on.

There is one hope for PHP, however: Zend Framework. I think if it can gain a foothold among developers, some of these trends can be reversed. Hopefully (for PHP) everyone hasn’t moved on to Ruby by then.

Like this post? You might also like Coalmine, my centralized error tracking service for your apps. Coalmine captures errors and all kinds of helpful debugging information, notifies you, and makes it all searchable. Check it out!