Gallery 2.0 Released 224
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."
Re:paid press release on /.? (Score:1, Interesting)
So whatever, man....
PHP != Crap Code (Score:5, Interesting)
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:Gallery vs. JAlbum vs. ??? (Score:2, Interesting)
How are the Debian packages? (Score:3, Interesting)
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:PHP != Crap Code (Score:4, Interesting)
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:Big deal. (Score:4, Interesting)
My Gallery (Score:2, Interesting)
Re:PHP != Crap Code (Score:5, Interesting)
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 [hibernate.org] 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.
Give me a break. (Score:4, Interesting)
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: (repeated 12 times in one 100 line file!!!!)
Re:Gallery vs. JAlbum vs. ??? (Score:2, Interesting)
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.
Re:PHP != Crap Code (Score:3, Interesting)
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/ [crazyguyonabike.com]
Re:PHP != Crap Code (Score:3, Interesting)
I did mention earlier that it is possible to code a scalable perl/php/mysql/etc application (look at
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
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 (Score:3, Interesting)
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!
http://www.neilgunton.com/spambot_trap/ [neilgunton.com]
Subsequent slashdottings have been no problem, though they haven't actually hit crazyguyonabike itself (yet...)
Fun stuff!
Re:Give me a break. (Score:3, Interesting)
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. (Score:2, Interesting)