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."
+5 Insightful! (Score:5, Insightful)
Gallery (Score:3, Insightful)
Any other ways to see it (Score:2, Insightful)
Re:paid press release on /.? (Score:2, Insightful)
Re:PHP != Crap Code (Score:3, Insightful)
This is the primary problem with languages like PHP. There is *NO* structure to them, no type strictness, no standard practices. ASP (original) suffered from the same problems.
JSP and ASP.NET have a lot better structure to them, and standard practices, not to mention tools that follow them.
Re:uhh ohh (Score:3, Insightful)
But my favorite part is the bit about "test driven development." Of course it's test-driven... that's how programming generally works.
And Zonk... please tell me what the program is before telling me to "Clickey here! Download Now!". I'm not really looking for online photo management software at the moment, thank you.
Re:Uhm, been running on my server for months.... (Score:5, Insightful)
I've been using it in a high-volume production environment since April Fool's Day. We plan on dumping it next week and moving to our own code. It's a very nice system (and a tremendous leap forward from Gallery 1), but it's wedded to a folder organizational metaphor, and we need a richer taxonomy to support potentially tens of thousands of users.
Re:PHP != Crap Code (Score:3, Insightful)
However, in my particular case, I have different needs. My company writes "shop floor intelligence" systems in which PHP is my *middleware* language. We use Smarty/PHP to generate XML/[other streams] from proprietary interfaces to PLCs or embedded shop floor systems. This XML has to have whatever the state of the machine is *at that moment.* These systems are not neccesserally "Hard real time", but they need to be very performant. We feed the PHP systems XML configurations which tell the middleware which series of registers or memory locations on the "embedded controllers" to look for state, and how to package that state as a message to the decision support systems.
The maintenance engineers / technicians on these machines may go in during a plantwide shutdown and code a series of changes to the flow control logic of a foamer (for example) in ladder logic (or even by wiring relays) and our code has to be able to take the new internal state of these machines, and turn it into a consumable format quickly. Often times, I might add, we're not notified until 4:45 on a Monday after a plant shutdown when the 1st shift build engineers realize that their decision dashboard is giving data that doesn't map the expected state of the machine. Utilizing PHP/Smarty we are able to very quickly either change the XML / whatever template, as well as the actual feed information, and in next to no time, get the line back up and running.
One of the mantras which I used to abhor was: "there can be no unplanned system downtime on a production line" because it implied to me that everyone was lazy and simply didn't want to do their job. What it turns out happens, is that when you are retooling an entire line during a 5 day plant shutdown, sometimes little pieces don't get communicated, and one of the most prized assets of a system is the ability to dynamically reconfigure it to the changes on the line, while minimizing the downtime on the line.
As silly as this sounds, even the 5 minutes neccessary in packing a WAR file, redeploying it, and having the system bootstrap itself (after having compiled it and tested it on your system) are 5 minutes that the line doesn't want to lose.
So, in closing, I 100% agree with a great deal of your sentiment. PHP is most certainly not a splendid language for a great many applications, but I think it's a narrow point of view to believe that it's useful simply for quick one-offs... all the world is not a CRUD web app
(I forgot to add that we use DBs simply as a place to store data until the next time that we request it from the shop floor system... so for our needs, PEAR::DB is a reasonable tool.)
Re:PHP != Crap Code (Score:3, Insightful)
The lack of any real type safety in PHP makes it difficult to track down simple typos (for example, misspelling a variable name). I don't mean syntax errors, since those are easily caught, but typo's that are not syntax errors.
The lack of any real scope in functions and the ability to RAII also make it difficult. Debugging is also pretty difficult, even if you use commercial tools (ie Zend).
Re:+5 Insightful! (Score:5, Insightful)
Mods: The parent post was *informative*. See how it works? Not insightful, but informative.
Re:PHP != Crap Code (Score:2, Insightful)
No, we have seem java sites and
" it died because of a lack of connections since it was making lots of wasted database calls that aren't necessary."
I don't think that's right. In PHP you get to set an absolute limit and once that limit is reached then it stops. You can not presume the database pooling was misconfigured, it probably worked just like the author intended.
"The programmer productivity hit of using Java in a real IDE for something substantial isn't as big as you might think. "
Having done both I don't think I KNOW. I was at least two to three times more productive with PHP.
'Java just seems to have more of these that can scale well than PHP."
That's just your opinion, you have no read data to back that up. Oh also since PHP can call java classes all of those are available to PHP as well.
"Java just seems to have more of these that can scale well than PHP."
This is just misinformation. There is the zend IDE as well as few other PHP IDEs which let you debug your code line by line. Having said that I programmed for four years in PHP using Jedit and never once wished I had a better IDE. I built and maintained a very busy commerce site which made millions of dollars per month and worked like a charm on single low end dell server. I won't say it was as busy as ebay or anything but it was able to take two to 20 hits per second with only 1 or 2 percent CPU utilization and ran comfortably on 512 megs of ram (freebsd).
"Of course, you should always imagine the stuff you build will become as big as ebay or amazon!
Perfect is the enemy of good. That's premature optimization.