Gallery 2.0 Released

uss_valiant writes "From the Gallery website: "We are incredibly pleased to announce the release of Gallery 2.0! Over three years of design and development have gone into creating the best online photo management product possible. Gallery 2.0 is the natural successor to Gallery 1, and we hope that you like what you see. Don't wait, download Gallery 2 now!" From a developers point of view, the Gallery 2 framework is particularly interesting because it's written with modern programming patterns (OOP, extreme programming, test driven development, MVC, factories, modularity, ...) in mind which is rather unusual for PHP based projects. Over 1500 unit tests ensure correct functionality and its architecture is really impressive."

Comments

Re:paid press release on /.?

[Anonymous Coward]

For some of us, this is like the release of phpBB 3. We've been needing the features this release has for months and even years and we're excited that it is finally ready for production.

So whatever, man....

PHP != Crap Code

[ilkahn]

I have often remarked that a "Writing Maintainable Enterprise Class Systems in PHP" book would be the best thing since sliced bread for the PHP community. There is nothing so wrong with the language and the environment (although some have likened it to training wheels without the bycicle) that can't be remedied with discipline, communication, and the use of mindful quality software development discipline.

PHP has been a wonderful language in which to "put together quick solutions which grow into large projects" for me in fields from accounting to my current work in Industrial / Manufacturing! The interfaces you can write to control PLCs and generate plant floor intelligence using *good* PHP and a web server are light years beyond what is usually available on a shop floor with PanelViews and Vorne displays (Light bars...) Someone out there would be smart to write a PHP-for-software-engineering book.

Re:PHP != Crap Code

[ilkahn]

I guess that's sort of the point I wanted to make, is that with some foresight and proper discipline, those small projects, when they become big projects, don't need to be rewritten from scratch, if maintainability was in mind from day one. Take PEAR::DB or one of the more advanced O/R mapping PHP frameworks (such as Propel), throw a decent templating system on there (such as Smarty), keep your code highly cohesive and loosely coupled, and the benefits of the language and the libraries are *massive*.

I spent 4-5 years trying to get JSP to work as a "rapid development prototype to full scale application" environment, and I constantly ran into issues with Tomcat, Jasper, JAR file surprises, all of the warts that come with the Java language, etc... I switched to PHP for all "non-transactional" code when I did a study whereby I analyzed the amount of time it took one of my teams to react to "changing customer requirements" utilizing PHP/Apache as opposed to how much time it took another team of mine to react to similar requirement changes using JSP/Tomcat. I am not saying that JSP couldn't have worked, it's just that it seemed to not really have as many benefits as I would have liked for an environment that required as much agility as that which I found myself in.

I have to admit, my experience with ASP is nearly nill, as I have not been able to convince any clients to allow me to test out MS platforms controlling plant floor hardware.

All that being said, when my company writes something that requires "transactional integrity", we do pick Java for the backend... it's just that those situations in my field really are few and far between.

Re:PHP != Crap Code

[NickV]

You're comparing a decent templating engine (Smarty) with crap Java technology (JSPs.) Most modern Java programmers disdain JSPs and use other, better templating technologies. Try using Velocity . Requires no recompiling when you make changes and is a very very easy templating language that provides an amazing amount of power (you literally can drop items into a hashtable of VelocityContexts and then access them by using "$" notation... such as "$user.name") If you want something that will really rock your world, check out JSF or Tapestry (it turns web programming into writing an event-driven application, like desktop apps.)

The problem with most PHP applications is that they don't scale. I don't mean that in a "PHP SUXORS! YOU CAN'T WRITE S$!@ IN IT"... I mean that most PHP applications aren't built with any real caching implementations (like this gallery software, or phpbb, or nuke, etc...) and the PHP frameworks that I looked at don't really provide that functionality.

The stuff availble for Java is just so much more powerful. You have the Hibernate OR mapping package that provides an amazing amount of OR work for you, including the ability to plug in multiple transactional caches, session caches, database connection pools (including the ability to have clustered caches across multiple boxes.) You have complex messaging architectures to talk to and keep multiple machines in sync. You have great web service APIs and great search engines that can be plugged in. Stuff to that degree just doesn't exist for PHP.

It often shocks me to see so many "Enterprise Level" PHP apps released with no caching implementation... you shouldn't see ANY home page hit a database on every hit. (And yes, you can easily avoid stale content by eviction, injection routines.)

So yes, you can definitely write decent stuff in PHP. But for the highly scalable enterprise environment, the libraries and packages that exist for Java and ASP just don't exist.

The other thing I hate about PHP is that there just is no IDE that is of the caliber of Eclipse for PHP (and PHPEclipse just ain't there yet.) A professional IDE allows me to introspect objects, trace stacks, change variables on the fly per hit and control each thread individually. This kind of power makes debugging and performance testing so much easier and more powerful than a PHP app. Good luck trying to seriously profile a PHP app...

So yea, PHP has it's place. It's wonderful for quick one-offs. I just wouldn't want to code a massive user load, transactional, high availability, multiple machine cluster application on it.

Re:PHP != Crap Code

[ngunton]

I agree, the issue of what to set for the expiration times is critical. I use a combination of approaches: Short expiration times (1 minute) for "what's new" type pages, which ensures that people will never see very old content (one minute is fast enough for anything but real real-time data such as stock quotes, but that's probably a case where you'd be setting 'no-cache' anyway)... this also means that the backend is being called at most once a minute for these pages, which isn't going to be a problem for any db unless the queries are just insane.

Then I also use URL arguments to make links look "new" to the front-end proxy when things change. For example, there is a 'v' field for documents that gets incremented whenever the document is modified. So then if a page is added, then all the links on subsequent generated pages have '&v=123', which looks like a new page and so the user doesn't get stale data. I also use the same technique for user options, which (as well as storing in a cookie) I compress and pass around as 'o=xxx'. This is useful for browsers, some of which do not distinguish pages which are otherwise identical but with different cookies.

Finally, user editing pages get 'no-cache', since these really are dynamic and are only being seen by one person anyway. But if I got slashdotted by someone posting a link to one of the journal pages on a popular site, the server would hardly break a sweat because it would generate that page just once and then serve it to all the other requests as static from the front-end.

I use these techniques successfully on my bike journals website: http://www.crazyguyonabike.com/

Re:PHP != Crap Code

[NickV]

Those are some really interesting and cool solutions to the problems high load presents on a LAMP site. I'm sure lots of those flags and parameters you added came from experimentation and testing (noticing things like IE doesn't really notice pages with different cookies but similar content are new, etc).

I did mention earlier that it is possible to code a scalable perl/php/mysql/etc application (look at /. itself.) It's just that you have to jump through lots of hoops and write alot of non-business-logic code. You had to write an implementation that added the version 'v' field to your URLs, you had to do it for your 'o' fields, you had to muck around with different content-header information for different pages.

Its great that you took the time to essentially code alot of framework or scaffold code. I hope that its extensible and can be reused on different sites (if you ever have to make a new one, hopefully you can take most of this code with you.)

The nice thing about Java (and I have no experience with .NET, but I imagine its similar) is that alot of this stuff is already done for you. You want to handle caching from your DB? Just add one line to an xml file and you're done. Caching across machines? A few more property lines. Connection pooling? Same thing. And the cache is written by the guys at Sun so you can have some confidence that its ok. If not, take one of the many others that implement the standard (or if you're really courageous, write your own.)

The nice thing about large sites (and sites that need scability) is you can focus your time on the logic of the site in Java, and not on various solutions to make sure your caching implementation works correctly.

You can definitely code a php/perl app so that it can scale well, as you did, but it requires alot of work that isn't related directly to the site.

That's all I'm saying.

Re:PHP != Crap Code

[ngunton]

You're right, I did have to code the URL generation routine myself... but the code itself is really trivial (the hard part was thinking of the right way to do it), and yes, it is very portable to other contexts. I also think that the arguments for Java solutions can be applied equally to LAMP, particularly Perl, largely because of the existence of CPAN. I can code up some very powerful stuff very rapidly because just about anything you might need to do is probably already up on CPAN as a module. However that's another (probably endless) discussion - I think which language to use is a matter of taste and style, if you know what you're doing then you can write scalable apps in most any of them.

The stuff I did in Perl isn't really onerous at all, at least no more than any other framework out there, with the added benefit that I have full control over its behavior, and I don't inherit a lot of bloat that I don't need. Making sure to call a particular routine whenever you want to generate a link isn't hard, and as a whole it was fun to do... I keep thinking I should write this stuff up, because I don't think I've seen this approach talked about much (if at all - about all you see is the talk of using a reverse proxy, which itself is more than most people seem to be aware of)...

Ironically, I was driven to do this work with reverse proxies after my first slashdotting - the mod_perl backend was getting hit for every request, and about 40,000 people came to visit! ;-O

http://www.neilgunton.com/spambot_trap/

Subsequent slashdottings have been no problem, though they haven't actually hit crazyguyonabike itself (yet...)

Fun stuff! :)

Re:Gallery vs. JAlbum vs. ???

[Titanium Angel]

Since the functionality is completely separated from display, you can use its easy to customize templating system to completely adapt its look to your needs. I've been using it for a few months, and I must say I'm impressed. Seems to be the best photo gallery in town :)

How are the Debian packages?

[swillden]

Hey, has anyone tried out the Debian gallery2 package? Does it do a good job of migrating the data, or does it install stand-beside? I have a gallery 1 installation that my whole family uses, and I'd like to know if it's safe to upgrade, or if I should wait for the bugs to be worked out.

Re:Big deal.

[DataPath]

unit tests don't just show that your program works, they show that your program STILL works (make great regression tests)

My Gallery

[jelevy01]

If anyone cares here is my gallery: http://pics.jeremylevy.com/

Give me a break.

[saberworks]

If this is an example of good PHP coding someone please shoot me. They use their own internal "require_once" instead of simply using ini_set to set the include directories correctly. They name all their included files *.inc and *.class which can be a severe security issue if these files are available from the web root (which by default they are).

From the code I saw, everything is extremely over-engineered (read: too freaking complicated). It looks like they have some input sanitization functions but they aren't used consistently.

The coding style throughout isn't consistent (but who cares?).

On the plus side, they have used PHPDOC or some similar syntax to document their classes and functions (makes for good API docs). They have used external libraries for some things like templating and database abstraction (can't say much for their choices but at least they didn't rewrite those from scratch).

The error handling also looks particularly nightmarish:

if ($ret->isError()) {
return array($ret->wrap(__FILE__, __LINE__), null);
}

(repeated 12 times in one 100 line file!!!!)

Re:Give me a break.

[Fweeky]

"The error handling code works and I challenge you to find a cleaner way to let the developer know exactly where an error occured so they can fix it."

I'll take "exceptions" for £50, Bob. Unfortunate that PHP5 doesn't seem to be taking off quite like PHP4 did; I wonder if that's because many of the people who would find the new new features attractive are finding other languages suit them better? I know I did, and I used to really love PHP and was dead excited by Zend Engine 2 :/

Re:Give me a break.

[Warren_Canuck]

I'll take 'exisiting installbase' for $100, Bob. The installbase of PHP5 is NOWHERE as near as PHP4 right now and since most of our users don't run their own servers but instead rely on webhosting companies, PHP5 isn't really an option. I agree, PHP5 has a ton of great features and I'm sure they would help greatly with Gallery2 but we simply can't switch to it or we'd be preventing what would amount to probably 90% of our userbase from upgrading to it.

Re:Gallery vs. JAlbum vs. ???

[Anonymous Coward]

I have been using Quick Digital Image Gallery for a few years now. My reasons for choosing it over gallery:
1) much smaller code, much easier to understand, much easier to hack. 2) more secure than gallery. I was scared off by the large number of security problems gallery was having back then (and apparently still are, I'm told but haven't confirmed there was another one discovered recently?).

Qdig isn't for everyone though, as it is rather spartan. It does come with a web-based admin script I've never used, so some of the things I may think it lacks, might be handled by that (probably are). I generally just scp my files to the server though and manage directories (galleries) that way.