Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Spring Into PHP 5

timothy posted about 9 years ago | from the bounder-of-adventure dept.

PHP 229

Michael J. Ross writes "A professional programmer could at any time be tasked with developing a nontrivial application using a language or Web technology with which he or she is unfamiliar. A common response is to quickly scan code snippets in Internet newsgroups and online tutorials, copy and paste code that looks applicable to the task at hand, and then lose valuable time trying to make it all work and control what was created -- not unlike Dr. Frankenstein's experience. A smarter approach is to learn the language basics in sequence as rapidly as possible, not getting bogged down in excessive sample code. For developers seeking to learn PHP using the latter approach, Steven Holzner's Spring Into PHP 5, published by Addison-Wesley, would be an excellent choice." Read on for the rest of Ross's review.

This title is another entry in Addison-Wesley's promising "Spring Into" series, which, as suggested by the name, is aimed at developers who want to jump into a new technology and get up to speed as quickly as possible, but without missing any of the essentials. In the case of Holzner's PHP book, this goal is pursued by presenting the information in so-called "chunks," with each spanning just a few pages. Every chunk attempts to cover only one or a few related ideas, and is designed to build upon earlier chunks. The bulk of the explanation takes the form of code samples, which fortunately are short enough in length and clear enough in composition to be easily digestible. This is in stark contrast to far too many other programming books on the market, whose code samples can span multiple pages, making it difficult for the reader to discern all of the ideas that the author is trying to get across -- especially when the reader has to flip back and forth between pages. Even worse is how some authors (such as Deitel and Deitel) use lengthy code listings -- sometimes even complete applications -- to demonstrate many ideas at once, which can be quite confusing, especially for the newbie reading about a challenging language for the first time. As Holzner notes in his preface, his book is example-oriented, with dozens of tested code samples. But none are overwhelming.

Spring Into PHP 5 was published on 12 April 2005. It is organized into nine chapters, covering a range of topics: PHP essentials; operators and flow control; strings and arrays; functions; PHP in HTML pages; Web forms and input validation; object-oriented programming and file handling; PHP and databases; cookies, user sessions, FTP, e-mail, and hit counters. The book has two appendices. The first one, on PHP language elements, is remarkably complete, considering that it only fills 18 pages. Owners of the book will likely find themselves turning to this material quite frequently. The second appendix lists the most commonly used functions in PHP, particularly those dealing with arrays, strings, and files. These two appendices combined go a long way to making this book more than an approachable primer -- it could serve as a reference book for the language for any reader not required to dig into the more obscure intricacies of PHP. Readers with those needs will have to use more detailed sources, such as the online PHP Manual.

Each one of Holzner's chapters explains the core concepts, using the bite-sized chunks mentioned earlier. This approach is somewhat similar to the "recipes" found in many books published by O'Reilly Media, and it works well here for introducing a computer language. Holzner's writing style is clear yet never condescending, and concise yet never cryptic. The intended reader only really needs an understanding of simple HTML and how to edit text files, to make this book worthwhile and usable. The book is meaty with information, and yet not too lengthy. This is a refreshing change of pace from countless other computer language books that are bloated with redundant sample code and overly wide margins, apparently in an attempt to entice the consumer with maximum page count per dollar.

Some programming books try to move the novice along at too rapid a pace, which can get quite discouraging if and when the reader is unable to follow the discussion, and particularly if trying to follow the author in building a working example. But a far more common mistake among programming books, is to drag out the process with humongous code listings or redundant verbiage (such as following the senseless rule of telling the reader something three times -- a technique that makes far more sense for speechwriting). Holzner sets and maintains an excellent pace, partly by keeping the code snippets reasonably sized, and partly through his modular approach of presenting ideas in chunks.

The physical book itself is well made and attractive, with a readable font face and size, and intelligent use of bolding to highlight those lines of code upon which the reader should focus. My only complaint in terms of the presentation, is that the gray background used for the code samples could be lightened up a bit, to make the text itself stand out more, especially the bold text. All of the screenshots are in black-and-white, which works just fine, as there would be no value in using color in the majority of the sample Web pages.

The author does an excellent job of explaining and illustrating all of the most commonly used and needed elements of the language. But he provides little guidance as to when a particular technique or approach should be used over another. For instance, when explaining how the programmer can use PHP to connect to a MySQL database, the author presents two alternatives -- direct layer and Pear::DB -- but no recommendations as to the choice of one over the other. On the other hand, one might argue that to include recommendations of techniques, as well as language best practices, would require the book to be much longer than it is, which would detract from the book's goal of getting a programmer up to speed on PHP in an efficient manner. The serious programmer who wishes to take PHP to the next level, can be expected to read more advanced books, to learn from expert PHP developers posting in online newsgroups, and to learn from experience as the programmer creates his or her own applications.

Another potential point of criticism could be that the book does not adequately explain how to use PHP with the various available database systems, only covering MySQL (the industry's favorite for use with PHP). But the database chapter, number 8, provides just enough information for the beginner to get started and to try out the basics. For simple database needs, the material in that chapter might be sufficient. Yet for more extensive MySQL usage, including installation and administration, other resources will need to be consulted. This book is clearly not intended to be one of those PHP + MySQL combo books that have proven so popular during the past few years.

The publisher's Web site for the book does not appear to have any collection of errata. Here are some that I found: On page 6, in the NOTE, "scripts can be used" should read "scripts cannot be used." On page 20, "#/ message to the user" should read "# message to the user." On page 49, in Table 2-4, in the last line, the formatting is partly wrong. Examples 3-1 through 4-14 contain incorrect indentation. On page 158, the last line in the $_FILES['userfile'] values is missing $_FILES['userfile']['error']. In Examples 5-19 and 5-20, the <head> and <h1> tags are missing ": Take 1." On page 169, the formatting of Example 6-2 is inconsistent with the others.

Aside from the errata, there were some other weaknesses -- none of them serious: The chapter summaries are useless, like in most other technical books, as there's not enough details to be instructive, and more details would make them even more redundant and space-consuming. On page 176, in Figure 6-6's caption, "Navigating" should be "Redirected." On page 197, the discussion of HTTP authentication is too brief to enable the typical reader to implement it. For instance, there is no mention of where to set $_SERVER[ 'PHP_AUTH_USER' ] to make it work. Chapter 7, on object-oriented programming and file handling, should be split into two chapters. Combining them makes no sense, and the author does not even transition from the first topic to the second.

Like others in the "Spring Into" series, this title is reasonably priced, at only $29.99 list for over 300 pages of quality material. The publisher, Addison-Wesley, has a page on their Web site devoted to the book, which includes a book description, a table of contents, an index, source code from the book, and a link for downloading a sample chapter (in PDF format), namely, Chapter 3, which covers strings and arrays. The site also has a link to a bonus chapter (also in PDF) that explains how to draw graphics interactively on a Web server and then send them back to the browser. Oddly enough, the page's title is "Spring Into PHP 5 - $20.99," but there's no indication as to how to get the book for only $20.99. That could simply be a typo. But there is a link to purchase the book online for $26.99. For those looking to spring into Web server-side development in general, or PHP in particular, it would be money well spent.


Michael J. Ross is a freelance writer, computer consultant, and the editor of the free newsletter for PristinePlanet.com. You can purchase Spring Into PHP 5 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

229 comments

Sorry! There are no comments related to the filter you selected.

PHP (-1, Troll)

Anonymous Coward | about 9 years ago | (#13297169)

sucks grits.

MOD PARENT UP (0)

Anonymous Coward | about 9 years ago | (#13297267)

I hate it if a client is not willing to switch to a sane host and uses the el-cheapo-WalMart-PHP-only-shitshop his 13 year old daughter selected for him.

Re:MOD PARENT UP (0)

Anonymous Coward | about 9 years ago | (#13297536)

Why, exactly? I'm sure we're all dying to know.

wtf? (2, Insightful)

Karaman (873136) | about 9 years ago | (#13297181)

A professional programmer will never do the stupidity described in first paragraphs when dealing with new language and/or tool to perform task at hand. Although the book might be the best for beginners and advanced users, A PROfessional will not need it at all.

Re:wtf? (0, Flamebait)

SolitaryMan (538416) | about 9 years ago | (#13297347)

A PROfessional will not need it at all.

Mostly because PROfessional will not need PHP at all...

Re:wtf? (1)

Karaman (873136) | about 9 years ago | (#13297616)

Well, It depends what you do and how you do it. I use only Delphi and PHP to code for living, although I also know Java,C,C++,Perl,Python. The point is my clients want things to be done fast and furious with as less debugging as possible. And I primarily do web-sites and business software (auditing, etc.). I have practically coded for living in Delphi since delphi 1.0 ;) and PHP for 3 years without stopping. If I have to switch to any other language I can do it in 1 day only (assembler,basic,lisp,fortran and similar excluded). But why should I do it? Why should I reinvent the wheel? I will get no profit :P. I could only reduce coding costs by moving to oss tools. Practically to me there is no difference what language I use, I just write the one I know I will finish the job properly and on time and will be useful to the client for years to come.

Re:wtf? (1)

w98 (831730) | about 9 years ago | (#13297706)

will be useful to the client for years to come.

Funny, I just spent 4 months rewriting some code written in PHP 3 (which only a few years old) 'cause it wouldn't work 100% of the time on the new hosting server they needed to move the application to, 'cause the dope(s) that wrote the original software wrote it in such a way that PHP4 choked on it far too often (mostly with the register_globals or other such things being turned off/on).

In the end, they have a much more secure application that also runs a lot quicker... and since cutting out function calls that will be removed once v5 hits the mainstream, less likely to break down again in the near future.

<?php include ("mytwocents.php") ?>

Re:wtf? (1)

Karaman (873136) | about 9 years ago | (#13297874)

Well, PHP is only an interpreter. Of course, code will need changing one or two things when migrating, but one should not be forced to change the whole mechanism of the program in the process :). on/off registered_globals are too easy to repair in php, just use something like this (you can evolve it if you need security and so on).
foreach ($_GET as $s=>$v) {
${$s}=$v;
}
foreach ($_POST as $s=>$v) {
${$s}=$v;
}
If you look at the PHP5 manual for classes and objects [php.net] you will read this: For backwards compatibility, if PHP 5 cannot find a __construct() function for a given class, it will search for the old-style constructor function, by the name of the class. Effectively, it means that the only case that would have compatibility issues is if the class had a method named __construct() which was used for different semantics. Well, when the old method of using class_name() for constructor becomes obsolete and not supported in new versions, no php4 classes will work :). Some people will have to rewrite the classes constructors :)

Re:wtf? (1)

poot_rootbeer (188613) | about 9 years ago | (#13297720)

Mostly because PROfessional will not need PHP at all...

Oh good, I was hoping this book review could serve as a springboard for Yet Another Language Advocacy Flamewar. Thanks for not letting me down, SolitaryMan.

You jackass.

Pretty Home Pages (2, Informative)

Mateo_LeFou (859634) | about 9 years ago | (#13297420)

I remember this book ... it was terrible. It contained NOTHING specific to PHP5's features. Also it was terrible. It was full of
echo "TD> blah blah blah /td>";
echo "TD> and so on /td>";
echo "/TR";
echo "/TABLE";

ick.
And I remember somewhere it said PHP stands for "Pretty Home Pages"
wtf indeed.

PHP Infinity Loop (0, Offtopic)

SupaDupaKoopaTroopa (906924) | about 9 years ago | (#13297186)

Thousands of website admins are stuck with a PHP recursion attack [overheardintheuk.com] : "PHP = PHP Hypertext Preprocessor = PHP Hypertext Preprocessor = PHP Hypertext Preprocessor = PHP Hypertext Preprocessor"...

Re:PHP Infinity Loop (0)

Anonymous Coward | about 9 years ago | (#13297369)

1. Invent Personal Home Page
2. Rename it to an very innovative and hilarious acronym
3.Claim it is a professional tool, not a toy for clueless 14 year olds
4. ???
5. Profit!!!

I enjoy PHP ... (1)

w98 (831730) | about 9 years ago | (#13297188)

... but it's hard to be considered an 'expert' in a simple language like PHP when everyone and their uncle is writing in it and claims they're also an expert.

So I always try to learn the more complex ideas around the language or bring in ideas from Perl or C to my PHP code to make it look more advanced... so I tend to stay away from "learn ___ quickly" books -- I already know the basics of a lot of different languages and products, I want the more advanced stuff.

Here at work, just about every one of our developers can code in PHP ... Perl is a different story, and I guess that's why I make the big(ger) bucks.

Re:I enjoy PHP ... (3, Insightful)

Momoru (837801) | about 9 years ago | (#13297252)

or bring in ideas from Perl or C to my PHP code to make it look more advanced

Who are you trying to impress? Why don't you just write whatever PHP you need to get the job done, no one cares if your code looks more advanced, it drives me nuts when people have this mentality in my office.

Re:I enjoy PHP ... (1)

Mr. Underbridge (666784) | about 9 years ago | (#13297404)

Who are you trying to impress? Why don't you just write whatever PHP you need to get the job done, no one cares if your code looks more advanced, it drives me nuts when people have this mentality in my office.

Yeah, that crap drives me nuts. What are these "advanced concepts" anyway? "For" loops?

Re:I enjoy PHP ... (1)

jo42 (227475) | about 9 years ago | (#13297509)

Ah, you must be of the "lets slap some sh*t together" school of development...

Keeps many a Real Developers employed cleaning that cr*p up.

Re:I enjoy PHP ... (1)

w98 (831730) | about 9 years ago | (#13297612)

Exactly... I've had more freelance projects to fix or alter other people's code than to write stuff from scratch. And I'm happy to do it: it's usually a long task, and I charge per hour.

And the quality of writing something from scratch, correctly, the first time, is way more valuable to someone, than some high school script kiddie that thinks he's "1337" for cutting and pasting someone else's ideas together as a band-aid solution to a problem.

And now, at my current job, I get assignments like "rewrite 90% of this code to make it more efficient" where someone threw something together that, while functional, isn't the most efficient way of doing something.

Re:I enjoy PHP ... (1)

nocomment (239368) | about 9 years ago | (#13297920)

hehe ya I remember the first commercial use of PHP and it kept spitting things out with escape chars (e.g. " became \") so i jsut created a counter and a loop that printed it out character by character and skipped printing the \. Very innefficient to say the least. Months later I learned about stripslashes(). oops. :-p

It's funny to look back at that ancient code in horror and wonder how I managed to get anything working at all. Some of my code you wouldn't know it worked if you read it before running it (but if you read it you would not have run it).

Re:I enjoy PHP ... (1)

Momoru (837801) | about 9 years ago | (#13297778)

Theres a big difference in making something more advanced and making something look more advanced. The grandparent simply wanted his stuff to "look" impressive. And mixing a bunch of shit in there to make something look impressive is exactly the kind of thing you probably end up cleaning up.

Re:I enjoy PHP ... (1)

Dakrin1 (220684) | about 9 years ago | (#13297448)

agghh. It's people like you that give me a headache. Using 'advanced' techniques that are hard to understand, and harder to debug when a simpler technique would be more fitting and elegant.

Re:I enjoy PHP ... (0)

Anonymous Coward | about 9 years ago | (#13297506)

Yeah, because high-quality programming is complicated. If it's easy, it must be terrible and useless.

Maybe you just don't like people cutting your grass.

Re:I enjoy PHP ... (1)

databyss (586137) | about 9 years ago | (#13297571)

"Perl is a different story, and I guess that's why I make the big(ger) bucks."

It took me a day to install a Perl interpreter and start writing programs to parse several hundred text files.

When did Perl become hard to learn?

Re:I enjoy PHP ... (1)

guaigean (867316) | about 9 years ago | (#13297576)

bring in ideas from Perl or C to my PHP code to make it look more advanced...

You, sir, are a detriment to coding. By using more advanced looking code, rather than equally simple and equally effective, you are hurting yourself, your employer, and whoever has to clean up the mess you leave behind. It's easy to write supremely complex code that no one will understand in a week. I do it all the time in Perl, and if I don't thoroughly comment it, I forget what it did. The difficulty is in writing elegant, clean code which is easily understandable by whoever will eventually replace you.

Re:I enjoy PHP ... (2, Insightful)

justMichael (606509) | about 9 years ago | (#13297737)

So I always try to learn the more complex ideas around the language or bring in ideas from Perl or C to my PHP code to make it look more advanced...
So you intentionally make your code hard to read/maintain so that you can justify your salary? If you really think your code "looks more advanced", chances are it's not.

Is one of these more advanced than the other? Or does it just look that way to someone that's never seen a ternay operator before?
if ($a == $b) {
  $c = $a;
} else {
  $c = $b;
}
 
$c = $a == $b ? $a : $b;
It's a much better plan to justify your existance to your employers by writing rock solid code that can be maintained by others when your l33t skillz get you a better job.

There is also a huge difference between being able to write code in a given language and being able to write GOOD code in that language.

PHP now obsolete? (0, Flamebait)

Colonel Panic (15235) | about 9 years ago | (#13297189)

Isn't PHP obsoleted by Ruby On Rails?

Is the book publishing industry becoming irrelevant? By the time the books come out the technology is often on the way down.

Re:PHP now obsolete? (0)

Anonymous Coward | about 9 years ago | (#13297264)

No because RoR is a boxed in approach. PHP still rules in that arena.

Re:PHP now obsolete? (1)

CatGrep (707480) | about 9 years ago | (#13297303)

RoR is a boxed in approach How so?

Re:PHP now obsolete? (1, Insightful)

lukewarmfusion (726141) | about 9 years ago | (#13297282)

Let's see here...

1. Professional developers are still creating websites using font tags and other deprecated nonsense.
2. Programmers are writing extensive web applications entirely in Perl cgi, often taking months to do simple tasks that PHP or ASP can do in days.
3. Existing sites are built on technologies that may be ten years old. They don't update their software every time a new technology, framework, or component comes out. They have to support old stuff in addition to building new stuff.

Re:PHP now obsolete? (0)

Anonymous Coward | about 9 years ago | (#13297361)

I know engineers who still program in Fortran 77! So it may take a while for PHP to die...

Re:PHP now obsolete? (2, Insightful)

Christianfreak (100697) | about 9 years ago | (#13297383)

2. Programmers are writing extensive web applications entirely in Perl cgi, often taking months to do simple tasks that PHP or ASP can do in days.

Myth #4349: Perl takes longer to develop than PHP

Obviously you've never heard of CPAN or done anything more than pull some data out of a database and put it on a webpage. Anyone doing anything more than that on the web has to know something besides PHP since doing anything complex in PHP simply isn't very easy at all.

Personally I really hope the PHP fad will be over soon since I'm not holding my breath for it to become a better language. ( PHP is barely better than 4. They still didn't fix some of the biggest beefs that many people have with the language ). Of course when it is over we'll all be subjected to the Next Big Thing (tm) instead of using something serious for once.

(and I hope beyond hope the next big thing isn't Ruby on Rails)

Re:PHP now obsolete? (2, Interesting)

lukewarmfusion (726141) | about 9 years ago | (#13297513)

My point wasn't that Perl is the wrong tool for the job. It's just that it isn't always the right tool. That's what this is all about - choosing the right tool for the job.

Having seen horribly written Perl used in the wrong situation, I know that Perl can take longer to develop than PHP to do some things. Maybe it could have been sped up by using CPAN modules, but the entire application could have been built in a matter of days. The Perl version probably took a month to build, based on the sheer amount of code.

PHP isn't going anywhere, just like Perl isn't. ASP/.Net are here to stay. I have complaints about all of the above - but they all have their uses, strengths, weaknesses, and an appropriate time to employ them.

* And after watching the 15 minute demonstration of Ruby on Rails, I'm going to join you in hoping that it isn't the next big thing.

Re:PHP now obsolete? (1)

jadavis (473492) | about 9 years ago | (#13297418)

entirely in Perl cgi, often taking months to do simple tasks

Huh? I don't think the move from Perl cgi to php will turn months of work into days. The development time is relatively close, even if you ignore all of the templating solutions for perl.

I understand people have their preferences one way or another, perl, python, php, whatever. But let's not pretend that the mere choice of language can mean the difference between months and days.

I am more likely to buy it if you're really talking about a big change in the way software is developed, e.g. python instead of C or something.

Re:PHP now obsolete? (1)

ch-chuck (9622) | about 9 years ago | (#13297285)

There's been a few articles [theregister.co.uk] about LAMP losing market share recently.

I don't even know where to begin... (0)

Anonymous Coward | about 9 years ago | (#13297308)

Ruby On Rails, popular as it is with the fanboy set, is not a replacement for every web application framework in existence. Also, PHP is (ostensibly) a language and Ruby On Rails is a framework. Stupid comparison. You might as well ask if Ruby On Rails obsoletes bagel slicers.

PHP was obsolete the day it was born. It wasn't designed, it just happened, and it really shows. I can't fathom why anyone would want to do serious work in it. No, your little weblog package is not serious work.

By the way, you're a little behind on the latest thing to cheer for. I think we're all fapping over Django now, since it's built on what is in my opinion a more sophisticated language.

Re:I don't even know where to begin... (1)

Guido von Guido (548827) | about 9 years ago | (#13297405)

Python is more sophisticated than python? Gotta say I don't see it--although I think they're pretty similar (in terms of sophistication, anyway).

Or do you mean that python is more sophisticated than PHP? Just pretend I never said anything.

Re:I don't even know where to begin... (1)

sjaskow (143707) | about 9 years ago | (#13297417)

Well, I know for a fact that this [cincinnati...wpages.com] is a serious work built on PHP.

As long as you understand the limitations of PHP, it can be a very powerful language.

And Python is the stupidest language ever, white space as block delimiters? What happens when you cut and past from one windows that has tabs into another where the editor doesn't understand them?

Re:I don't even know where to begin... (1)

jadavis (473492) | about 9 years ago | (#13297549)

stupidest language ever, white space as block delimiters?

Everyone always says that, and to a certain extent it's true.

However, everyone I know who's actually tried it, including myself, is surprised at how often what they write does what they expect the first time.

It was really amazing. And in practice, usually editors handle the whitespace quite nicely. Python may not be right for every task, but it's been a wonderful tool to have available.

Re:I don't even know where to begin... (1)

databyss (586137) | about 9 years ago | (#13297651)

"However, everyone I know who's actually tried it, including myself, is surprised at how often what they write does what they expect the first time."

How does this have anything to do with the language?

I don't find very many instances where the code I write does something unexpected, or am I mistaken and you are talking about buying pythons that write code?

Re:I don't even know where to begin... (1)

Mr. Underbridge (666784) | about 9 years ago | (#13297593)

And Python is the stupidest language ever, white space as block delimiters? What happens when you cut and past from one windows that has tabs into another where the editor doesn't understand them?

Oh, it screws it up royally. And don't get me started on linefeeds between windows and unix. And the whole "lambda" function concept...actually, I'm going to have to fight you. I think that's dumber than the whitespace thing, and that's saying something.

Other than that, though, python has some advantages as a deployable rapid development language. It has a ton of support for math and science applications, including an easy interface for precompiled LAPACK binaries and such. You can code very quickly, the code is very readable, and if you've done a good job and avoided loops as much as possible, the code runs fast too.

Basically, you can code in Python almost as fast as you can code in something like Matlab, with the difference being that it's much more portable since python is a more accepted standard and doesn't cost thousands of dollars a seat.

Clarify for me. (1)

Some Random Username (873177) | about 9 years ago | (#13297662)

The whole "lambda" function concept is dumb how exactly? If you mean python having neutered lambdas instead of real ones, sure that's dumb. But the concept of lambdas isn't dumb at all.

Re:I don't even know where to begin... (1)

arkanes (521690) | about 9 years ago | (#13297767)

Python actually correctly handles linefeed differences, and as long as you don't *mix* tabs and spaces in a file, it will execute correctly whether your editor understands tabs or not. On the other hand, if you're actually writing code, in the year 2005, in an editor that doesn't understand tabs you're a fuckup anyway.

Have you even tried python? (0)

Anonymous Coward | about 9 years ago | (#13297597)

From Python whitespace FAQ, or, Python is not Fortran 77 [hotales.org] :
Should I dislike Python's significant whitespace?

No, you shouldn't.

Why not?

Because it's the most natural thing, and, while it's a lovable feature of Python, it's not that big a deal anyhow. It shouldn't be a show-stopper.

But it's ugly and wrong.

No, it's not. It's beautiful and right. But this isn't going anywhere with us arguing whether it's right or wrong. The point is that if the only reason holding you back from trying out Python is its significant whitespace, then you're really stupid. I mean a total idiot. Even if the significant whitespace is only the proverbial straw that broke the camel's back, you're still an idiot for not trying out Python because of this.

You need not like it after you've really tried it. You may as well say that you don't like the significant whitespace because you couldn't get comfortable with it. I would find that odd, but I wouldn't argue with you on that. However, if you dismiss Python as a viable alternative because of its significant whitespace; well, as I said, that's just stupid.

Perhaps it's just the other way around?

Re:I don't even know where to begin... (1)

Guido von Guido (548827) | about 9 years ago | (#13297787)

Eh, I hate the white space thing myself, but if you can't get over it in 20 minutes or working with python you've got more serious problems.

yep, the whitespace thing tripped me up (1)

rebug (520669) | about 9 years ago | (#13297792)

...for about five seconds.

Seriously, if that's the extent of your case against Python, well...you make it clear that you've never actually written anything in Python and are therefore unable to have a valuable opinion of it.

If you're using an editor that doesn't understand tabs or one that can't convert tabs to spaces, well, you should seriously consider getting a new editor.

Re:PHP now obsolete? (1)

Dystopian Rebel (714995) | about 9 years ago | (#13297360)

Isn't PHP obsoleted by Ruby On Rails?


AJAX really changes the game.

Re:PHP now obsolete? (1)

WWWWolf (2428) | about 9 years ago | (#13297456)

PHP isn't obsolete because a lot of people want cheap web hosting, and PHP is what's easily around.

I personally wish it would be dead in favor of Mason and Rails, but right now PHP is like a swarm of super-powered cockroaches - every damn web host in the planet supports it, and it isn't going away because every damn web host in the planet supports it! PHP is great because of its availability and its simple and powerful syntax, but there's little else to keep its head above the water. And with things like Smarty, it isn't *that* awful to work with.

Well, my cheap web host gives me SSH account and I could install SBCL [sbcl.org] . Maybe one day I'll install Rails there too, I've used it on a project and I've liked it a lot.

Re:PHP now obsolete? (1)

jadavis (473492) | about 9 years ago | (#13297644)

PHP is great because of its availability and its simple and powerful syntax

I haven't heard PHP's syntax described that way before. To me, it seems neither simple (think python, C) nor powerful (think ruby, perl).

yeh, seems kinda trollish (1)

Mateo_LeFou (859634) | about 9 years ago | (#13297473)

I'd like there to be an open source web stack that compares to J2EE and .NET

It's fine with me if that eventually is RoR, but considering the much vaster PHP user base, wouldn't P5 be a better starting point?

Re:PHP now obsolete? (1)

poot_rootbeer (188613) | about 9 years ago | (#13297839)

Isn't PHP obsoleted by Ruby On Rails?

Well, PHP has ten years' worth of installed code out there (some good, some bad, some ugly). Ruby on Rails has the buzz among progressive web developers, but how many job postings are there asking for RoR experience? How many major web sites are built on RoR?

Not that I think vanilla PHP is a very good solution for anything but rapid prototyping. But add in some extensions like Pear::DB, Smarty, and php.MVC, and PHP becomes not only a reasonably elegant development platform to use, but also one you can make a living working with.

yes, just what i've been looking for! (-1, Offtopic)

Anonymous Coward | about 9 years ago | (#13297194)

something more interesting [cryingwhileeating.com] than a new php book....

PHP is good but.... (2, Insightful)

jbdodson (815746) | about 9 years ago | (#13297199)

I am not sure the addition of more OOP support is going to take PHP into the "less hackish" language camp in my mind. Moving from PHP development to a Java or Python/Zope based model with more emphasis on MVC patterns and Unit testing, is much better than the old hack way of putting all the controler, model and view code on the same page. I guess for a quick and easy solution, PHP got your back, I am not really in love with how it scales up if you want to move into MVC though. Plus the fact that it is a functional language at its core is not too appealing from a OOP perspective. Though, I use it to program my blog, go figure.

Re:PHP is good but.... (2, Insightful)

bobbyjack (444724) | about 9 years ago | (#13297289)

"Plus the fact that it is a functional language at its core is not too appealing from a OOP perspective. Though, I use it to program my blog, go figure."

I figure that OOP is not the magic bullet many proclaim it to be. That some tasks fit the OOP model very well and others fit the functional model very well. And that PHP is a good language for certain applications, such as your blog.

The point? (1)

op12 (830015) | about 9 years ago | (#13297211)

It sounds like one of many tutorials that are readily available on the internet. I find it much easier to learn by example, but even those that prefer this method can find a tutorial to suit their needs. Actually coding is the only way to really learn the language and its nuances anyways. It seems like a book would be pointless given the vast amount of information available online, and the speed with which the latest information (as new versions are released) could appear online versus in a book.

Re:The point? (1)

op12 (830015) | about 9 years ago | (#13297250)

And of course I neglected to mention for (approximately) the same information:

Learning online $0
Using the book: $30

To buy or not to buy, the reviewer doesn't know! (1, Troll)

garcia (6573) | about 9 years ago | (#13297215)

This book is clearly not intended to be one of those PHP + MySQL combo books that have proven so popular during the past few years.

So, even though most people use PHP + MySQL and books of the type have been popular this one doesn't do that.

Another potential point of criticism could be that the book does not adequately explain how to use PHP with the various available database systems, only covering MySQL (the industry's favorite for use with PHP).

But yet it does explain MySQL? Which is it? I'm not going to buy the book if the reviewer can't figure it out.

The publisher's Web site for the book does not appear to have any collection of errata.

It has errors that a reviewer found (but can't determine if it supports MySQL or not) and no corrections for them. Chalk another point up.

Aside from the errata, there were some other weaknesses -- none of them serious: The chapter summaries are useless.

I don't like to read through everything (I'm not looking for errors to review about) so I'd like a decent summary.

Combining them makes no sense, and the author does not even transition from the first topic to the second.

Mmm, makes me want to run out and buy the book. Bad writing on top of errors and poor teaching. Sounds like a great way to Spring into PHP 5 doesn't it?

Like others in the "Spring Into" series, this title is reasonably priced, at only $29.99 list for over 300 pages of quality material.

From what I have read here it's not much quality. So which is it? MySQL or not, quality or not?

For those looking to spring into Web server-side development in general, or PHP in particular, it would be money well spent.

I'll stick to learning from sample code. It's cheaper, better written, and probably easier.

Re:To buy or not to buy, the reviewer doesn't know (2, Interesting)

Dakrin1 (220684) | about 9 years ago | (#13297423)

If the reviewer is really that confused, it might not be a good idea to take any of the points he makes too seroiusly.

Re:To buy or not to buy, the reviewer doesn't know (1)

garcia (6573) | about 9 years ago | (#13297573)

If the reviewer is really that confused, it might not be a good idea to take any of the points he makes too seroiusly.

Are you inferring that the reviewer thought the book was a joke and that I should assume that from what he wrote?

I took a look at the header above his confused review and saw that he rated it an 8 (I assume out of 10). If you are really inferring that I shouldn't take his review "seriously" and that I should instead assume he was joking around about the book perhaps he should have rated it differently?

author: Steven Holzner
pages: 340
publisher: Addison-Wesley
rating: 8
reviewer: Michael J. Ross
ISBN: 0131498622
summary: A comprehensive and no-nonsense primer on the basics of PHP

If I misinterpreted your statement perhaps I shouldn't pay any attention at all to reviews?

Re:To buy or not to buy, the reviewer doesn't know (1)

Idealius (688975) | about 9 years ago | (#13297547)

Reviewer: "Another potential point of criticism could be that the book does not adequately explain how to use PHP with the various available database systems, only covering MySQL (the industry's favorite for use with PHP)."

Parent post: "But yet it does explain MySQL? Which is it? I'm not going to buy the book if the reviewer can't figure it out."

The reviewer is saying the book explains how to use PHP with the database program MySQL, but not with other database programs such as Lotus Notes or Oracle.

Re:To buy or not to buy, the reviewer doesn't know (1)

garcia (6573) | about 9 years ago | (#13297596)

Read the first line of my post:

This book is clearly not intended to be one of those PHP + MySQL combo books that have proven so popular during the past few years.

So, if it's not meant to be a PHP + MySQL book and it's not showing the other options what exactly is the book doing? The reviewer doesn't know.

Thanks for proving my point.

Re:To buy or not to buy, the reviewer doesn't know (2, Interesting)

Just Some Guy (3352) | about 9 years ago | (#13297705)

This book is clearly not intended to be one of those PHP + MySQL combo books that have proven so popular during the past few years.

[...]

Another potential point of criticism could be that the book does not adequately explain how to use PHP with the various available database systems, only covering MySQL (the industry's favorite for use with PHP).

But yet it does explain MySQL? Which is it? I'm not going to buy the book if the reviewer can't figure it out.

In other words, the book isn't centered around building DB-driven apps using PHP+MySQL, even if it does discuss the topic. The reviewer wishes it also had chapters on PHP+PostgreSQL or PHP+Oracle, but it doesn't. Seems pretty reasonable and consistent to me.

A smarter approach? Learn the idioms and toolkits (2, Insightful)

joelparker (586428) | about 9 years ago | (#13297256)

>A smarter approach is to learn the language basics in sequence as rapidly as possible

In my experience a language becomes useful when you also learn the frequent idioms and know the available toolkits.

Posting anon to protect the guilty (-1, Flamebait)

Anonymous Coward | about 9 years ago | (#13297258)

PHP is a disaster, for two reasons:

First, it has no mechanisms to enforce any kind of good web application design practices. Almost invariably, PHP apps are initially designed by people who are newcomers to programming and the web. There's nothing wrong with that. But PHP doesn't provide any structure to help them make the right decisions, so you end up with no separation between HTML and code, and you end up with an unmaintainable mess.

Second, it's not a full-featured object-oriented programming environment like Java. In Java, I can create objects, store them in sessions, hand them to threads, and store them using persistence frameworks. PHP has only the most rudimentary versions of such features. Within a Servlet environment I can also create filters, something which doesn't exist in PHP.

There is hope. There are some tools like Smarty Templates and PEAR which help a little bit. In fact if beginners would force themselves to use Smarty Templates from the beginning they would get much better results.

Also PHP 5 has objects. It's nowhere nearly as mature as Java's object oriented features. PHP doesn't have strong typing on variables, something which should be a part of any system that needs to be reliable. There's no complition of PHP systems, which means that the only bugs are run-time bugs.

PHP just isn't a good choice.

-------------
mobile search [mwtj.com] - find it on your phone

Re:Posting anon to protect the guilty (2, Insightful)

bobbyjack (444724) | about 9 years ago | (#13297434)

"First, it has no mechanisms to enforce any kind of good web application design practices."

Can you name me a language that DOES have "mechanisms to enforce any kind of good web application design practices"? I'm not sure I can think of anything built into a language (i.e. not just an add-on library which, of course, PHP could provide) that does do this.

"Almost invariably, PHP apps are initially designed by people who are newcomers to programming and the web."

I've seen many state this and have suspected it myself, but have never come across any good statistical proof. Can you post your reference?

"But PHP doesn't provide any structure to help them make the right decisions,"

Can you give an example of this? I'd be interested to see a language feature of [insert other language here] that "helps [newcomers] make the right decision".

"so you end up with no separation between HTML and code, and you end up with an unmaintainable mess."

But what's to stop this from happening in ANY language? And what's to stop it NOT happening in PHP?

"Second, it's not a full-featured object-oriented programming environment like Java."

I'll give the you benefit of the doubt, here, and assume you missed that oh-so-important comma. However, I'd argue that "not object oriented" is not a fundamental flaw of a language. Say we only had OO languages RIGHT NOW. Do you think everything would run quite as smoothly?

"In Java, I can create objects, store them in sessions, hand them to threads, and store them using persistence frameworks. PHP has only the most rudimentary versions of such features."

Good for you. What are the advantages of doing what you're doing that obsolete PHP in every instance?

"Within a Servlet environment I can also create filters, something which doesn't exist in PHP."

Please explain more - I don't know what filters are. I'd be very surprised if PHP could not support whatever-they-are.

"There is hope. There are some tools like Smarty Templates and PEAR which help a little bit. In fact if beginners would force themselves to use Smarty Templates from the beginning they would get much better results."

I'll have to get back to you on Smarty.

"PHP doesn't have strong typing on variables, something which should be a part of any system that needs to be reliable."

WHY? How strong is the typing in the language used to write the OS you're running right now?

"There's no complition of PHP systems, which means that the only bugs are run-time bugs."

Why is a smaller number of classes of bugs inherently a bad thing? Or is that just an objective statement?

"PHP just isn't a good choice."

For what? Why? I'm still not sure I quite understand.

Re:Posting anon to protect the guilty (0)

Anonymous Coward | about 9 years ago | (#13297822)

you don't understand 'cause you're a fewl

Re:Posting anon to protect the guilty (1)

Dan667 (564390) | about 9 years ago | (#13297842)

I realize that alot of Programmers like Java because it has alot of features, but as a user, I have yet to come across a Java website I did not hate. The minute it starts trying to force a loading of a runtime environment or jar files and screws up the back button or other standard controls I want to leave.

Not trying to hate on Java, but please give an example of a Java coded website that has a pleasant user experience or list the object oriented web programming languague you really intended.

Re:Posting anon to protect the guilty (-1, Troll)

Anonymous Coward | about 9 years ago | (#13297522)

[i]PHP doesn't have strong typing on variables, something which should be a part of any system that needs to be reliable[/i]

Bah! Thats a strength I say. And you dont need strong typing to be reliable. Big myth. You need strong code to be reliable. Every language is fundamentally unreliable in the wrong hands.

[i]But PHP doesn't provide any structure to help them make the right decisions, so you end up with no separation between HTML and code, and you end up with an unmaintainable mess.[/i]

Ummm, maybe you do, but my web apps, written using a logical and well separated out framework, with library files and all are squeaky clean, and easy to maintain. And documented too!

[i]Second, it's not a full-featured object-oriented programming environment like Java. In Java, I can create objects, store them in sessions, hand them to threads, and store them using persistence frameworks. PHP has only the most rudimentary versions of such features.[/i]

Bah again! Sure the OOP is not as strong, but rudimentary? Given pointers and inheritance I have all I need. I'm not building freakin video games here.

[i]There's no complition of PHP systems, which means that the only bugs are run-time bugs.[/i]

Wrong. Wrong. Wrong. Wrong. Look up Zend. You can compile. It runs faster that way too. Plus you can embed licensing right in the compiled code and limit it to certain machines, IP's or date ranges.

People who attack PHP as weak, lame, or immature are often the people for whom those same adjectives would describe themselves.

Re:Posting anon to protect the guilty (1)

Dare nMc (468959) | about 9 years ago | (#13297524)

> PHP doesn't provide any structure to help them make the right decisions

I agree I haven't found the equivilent of Lint for PHP, that would solve all your complaints about PHP as a lanuage.

the language a person uses will not make a good programmer bad. And no amount of structured language will make a bad programmer write good programs.

I haven't found a single language, especially not java that does what you claim, their are many many tools for java, and C/C++, etc that do that. And even some of that functionality exists in the popular compilers.

Re:Posting anon to protect the guilty (3, Informative)

Christianfreak (100697) | about 9 years ago | (#13297906)

While I agree that PHP isn't all that great I think you have the reasons wrong.

OO isn't a silver bullet. You almost always trade performance for development time and maintainability when you use it. That's not a bad thing and PHP minimizes the performance hit well enough to make it useful. In PHP its nice when the developer sticks to one or the other, though its obvious that most people don't because PHP is easy and the people writing it tend to be new to programming.

Strong typing isn't a silver bullet either, and I don't see how it makes your code more reliable. PHP tends to die when you perform numeric calculations on a string or vice-versa so problems can be fixed before going to production. I'd prefer it handle more like Perl where usually it does the "right thing" (it doesn't die at the very least).

Here's my problem list that I hoped would be fixed or at least improved in 5. (no such luck it seems)

Error handling is one of my biggest beefs with PHP. There are simply too many options and none of them are sane. Why can't we have a class as an error handler? Why is it that the error messages are spewed the screen as HTML by default? Why doesn't the command line mode revert to text only error messages? Why doesn't PHP just use the server error log like other languages and give you options to change it if you need to? That's what its there for!

References: Worse than PHP 4's objects are its references. Why can't I have references to objects or code? Why can't I pass a reference to any user defined or built-in function? (it used to work for user defined functions then they depricated it)? Seriously why does the function care if it has a reference or a value? To be fair I've heard some of these things have been fixed in 5 but I've still not found definitively if you can have code or object references.

Scoping: I suspect part of the problem with references are due to limitations in scoping. On the surface, having all locally scoped variables and specifying when you want to use a global one makes sense and keeps new programmers out of trouble. The problem is it leads to undefined variables everywhere when the programming forgets to use 'global $foo' in a function. This is also a problem that can be hard to spot initially because PHP doesn't bother to warn you if you've done that. The 'global' keyword also looks like a declaration so when I was first learning the language it was extremely confusing. PHP would be much more tolerable if they adopted something similar to Perl's strict mode where you declare your variable in the global, package, or local scope and it dies when you have variables that are undefined. This method is much better than having silently undefined variables.

Namespace polution: Why are there 14 billion functions I'll never use all in the same scope? Its silly. C came up with the idea of including what you need 35 years ago! Why are we regressing? Even if you don't like having separate namespaces, at the very least functions that go together could all be in a common file to be included and then you only import functions you need. And no OO won't solve this problem because all the core functions are still imported in, even in PHP 5.

Compiled modules: Why do I have to recompile PHP if I want to add image functions or some other module written in C?

HTML Centric: PHP centers around HTML (see my beef about the error messages above) This is a real annoyance if you want to output other things. Also the default embedding in presentation is irritating too. It was a bad idea with ASP, it was a bad idea with ColdFusion and its still a bad idea now and while the developers keep saying "you no longer have to embed it", so what? Make it where it can't be embeded. (yeah yeah, backward compatability and all that) Sure you can cause other languages to print out HTML using print statements, but its not the same. PHP is designed around embedding it within HTML. Print statements make obvious the need for templates. PHP makes a mess without making it obvious until its too late. And as a side note: Smarty isn't a templating engine, its a meta-language and that only compounds the problem.

Unfortunately PHP is still my job so I have to put up with it. However I recommend anyone who has a choice to stay away from it. Maybe the fad will go away.

professionals (0, Flamebait)

Eric604 (798298) | about 9 years ago | (#13297259)

professional don't need to learn php because it's asp.net everywhere.

Bogged down by sample code?? (4, Insightful)

mabu (178417) | about 9 years ago | (#13297262)

A smarter approach is to learn the language basics in sequence as rapidly as possible, not getting bogged down in excessive sample code.

Excuse me? Maybe I'm an anomoly, but I can't think of a better way to learn a language than by example. This suspiciously sounds like and excuse to cover up the fact that the book doesn't offer adequate material to show how one can code in real-world environments.

When I look for a good programming book, be it an introduction, advanced tutorial or reference, the use of lots of examples is one of the main standards by which I judge the value of the publication.

Re:Bogged down by sample code?? (1)

raftpeople (844215) | about 9 years ago | (#13297381)

I completely agree. I am constantly learning new languages quickly through example. Google is my teacher.

Re:Bogged down by sample code?? (1)

Dakrin1 (220684) | about 9 years ago | (#13297527)

The reviewer is not talking about not learning through sample code. It's talking about EXCESSIVE sample code. The review states (in the first paragraph no less):

"The bulk of the explanation takes the form of code samples, which fortunately are short enough in length and clear enough in composition to be easily digestible. This is in stark contrast to far too many other programming books on the market, whose code samples can span multiple pages, making it difficult for the reader to discern all of the ideas that the author is trying to get across"

Re:Bogged down by sample code?? (2, Insightful)

Eric604 (798298) | about 9 years ago | (#13297531)

yeah but too much isn't good either. The last thing you want is crawling through pages of example code while it can be explained just as well in only a few lines.

Re:Bogged down by sample code?? (2, Funny)

zx75 (304335) | about 9 years ago | (#13297643)

I don't know... I rather enjoy learning by counter-example.

Though I imagine for a beginner those nasty regexs of invalid code could bog you down a bit...

PHP vs Ruby On Rails (1, Interesting)

CatGrep (707480) | about 9 years ago | (#13297273)

I'd like to see more comparisons between the two. At this point, it seems to me that if one were just starting out in web programming they might be better off going with Ruby On Rails. I don't see any advantages for PHP now.

Re:PHP vs Ruby On Rails (2, Informative)

Anonymous Coward | about 9 years ago | (#13297355)

Hmm lets see, time to compare a Web programming language vs a Framework.

Now you could compare Ruby to PHP or Rails to an mvc PHP framework like Cake.

But PHP against Ruby on Rails is Apples vs Oranges.

Re:PHP vs Ruby On Rails (1)

Heisenbug (122836) | about 9 years ago | (#13297850)

I haven't used Ruby, but here's the advantages I can think of for PHP. How does Ruby stack up?

1) PHP is the most common. I don't care what the Slashdot summary says, I like being able to find code snippets that have already solved the problem I have.

2) Corollary, PHP runs everywhere. Whatever the hell webhost the client went with, it probably already has PHP installed.

3) PHP is blindingly simple. If you're coming into web programming from desktop programming, you already speak C, and PHP is like C with anything remotely complicated taken out.

Like I said, I'm in no position to say PHP wins on any of those points -- are they still true?

Food Torture! please help it be a net phenom! (-1, Troll)

Anonymous Coward | about 9 years ago | (#13297299)

better idea for a book (1)

cptbarkey (906688) | about 9 years ago | (#13297305)

something more useful would be a book teaching people effective ways of ripping other peoples source code, i very rarely if ever write original source.

informative SPONGESPONGE (-1, Offtopic)

Anonymous Coward | about 9 years ago | (#13297317)

Let'Gs kkep to

just great, (1)

ag-gvts-inc (844888) | about 9 years ago | (#13297344)

I haven't read my php4 book yet

FROST PISS (-1, Troll)

Anonymous Coward | about 9 years ago | (#13297370)

FOR THE GNAA, WIGGERS

From the Incredibly Obvious Dept... (1)

ThePepe (775625) | about 9 years ago | (#13297372)

From the Incredibly Obvious Dept

Learning a programming language is better than doing it half-assed.

Stay tuned for tomorrow's topic, 'Computers are easier to use if you know how to use them'

Re:From the Incredibly Obvious Dept... (1)

Christianfreak (100697) | about 9 years ago | (#13297435)

Learning a programming language is better than doing it half-assed.

If that's the case why aren't people out learning real programming languages instead of messing with PHP?

(yes you may mark it flamebait now)

PHP 5 is trash (1, Informative)

Anonymous Coward | about 9 years ago | (#13297391)

I did some memory profiling on some new PHP5 code I'm working on. The test code only defines classes and no object code is actually executed in these tests. All it does is call require(), no business logic is run. This is the average memory consumption of the script for ten runs on PHP 5.0.4 with various optcode accelerators:

No accelerator: 1,746,752 bytes
eAccelerator: 782,576 bytes
APC: 772,200 bytes
Zend Platform: 333,856 bytes

Apparently the opensource accelerators just don't optimize PHP5's new object syntax much, if at all. Without any acceleration, the god damn script without any business logic uses more memory than the interpreter footprint!

For comparison, here are the same stats for phpMyAdmin 2.6.2-pl1 on this system:

No accelerator: 2,079,744 bytes
eAccelerator: 337,392 bytes
APC: 338,416 bytes
Zend Platform: 391,992 bytes

Notice the opensource accelerators come closer to Zend here. I think this is because phpMyAdmin is not written in the new PHP5 object syntax and uses the old syntax instead.

Basically Zend has made it so PHP limps along like a trash can unless you shell out $1500 per server. It would cost us over $15,000 to use Zend Platform, but without it we can't really move off of PHP4.

i've gotta say.... (1)

rwven (663186) | about 9 years ago | (#13297436)

....php was, for me, the easiest language to pick up. There's a plethora of built in functions to help you do just about anything and the syntax is like a hodgepodge of other languages best points put together. Maybe not everyone feels this way, but it's definatley in my top 5 favorite languages to write in. The only book(s) i think any programmer needs to pick up PHP are the visual quickstart guides from peachpit press. (shameless plug i'm afraid, but i love their stuff.)

Re:i've gotta say.... (2, Interesting)

nocomment (239368) | about 9 years ago | (#13297806)

I second this. I've done PERL BASH, a couple crappy C, yadda yadda. and I was able to pick PHP in an afternoon. Especially with it's similar structure to PERL.

I use php for most everything now, especially since php-cli came out. I even write my shell scripts in it now.

A few weeks ago I had to write a site that would allow users to input obituaries (I work in newspapers) and send off an XML feed and any binary images to an FTP server. The cool part is that the SAME script can be run from a command line or a web browser. Need the (l)users to input the obits? give them the website. If they need to send off a feed immediately (say for instance there is a typo on the website) it's a 1 click option for them. The script creates thubnails in png format from jsut about format you can think of. They can upload EPS, PNG, JPG, GIF, TIFF, BMP, or even a PDF, or anything else support by imagemagick [imagemagick.org]

Need to purge the database? run ./index.php --purge (this is also in a cron), need to troubleshoot an XML file? run ./index.php --xml to create a new file. Sending off a new feed from the command line? ./index.php --xml --ftp.

The users love it because they can edit the obits in real time on the website, removing extra line breaks changing the photo or whatever else they need to do with a live preview.

Time to build it? roughly 4 hours and that includes setting up the PostgreSQL database.

About to migrate... any tips? (1)

markmcb (855750) | about 9 years ago | (#13297443)

I'm about to migrate a site I administer, OmniNerd [omninerd.com] , to PHP5 from PHP4. Any areas of focus from those of you who have already done it? I do a lot of XSLT translations and I've noticed that I'm going to have to recode of xslt_process() calls. Any other major changes I should be looking for?

You might not want to migrate. (2, Insightful)

CyricZ (887944) | about 9 years ago | (#13297611)

If your existing PHP4 setup is working fine, or at least acceptably, you may not want to transition to PHP5. It has been suggested that PHP 5.0.4 suffers from very poor memory usage.

http://books.slashdot.org/comments.pl?sid=158685&c id=13297391 [slashdot.org]

So at this point, it just doesn't sound like a transition may be a very good idea for a site that is already functional and running well.

Proposal for new Slashdot topic/section: (1)

DogDude (805747) | about 9 years ago | (#13297477)

PHP book reviews! Considering that there seems to be about 1-2 week, it would be a pretty good size topic.

PHP's effect on Linux's reputation. (2, Interesting)

CyricZ (887944) | about 9 years ago | (#13297505)

There was some discussion here at Slashdot a few days ago in another topic regarding the effect PHP is having on the reputation of Linux. Considering that it is often grouped with Linux in the LAMP model, and is also one of the more well-known open source projects, there has become a close assocation between the two in the eyes of the general public.

Now it's no secret that PHP has suffered from some pretty serious security issues as of late, such as the XML-RPC flaw. Then there are the routine problems of poorly developed blog and CMS systems being defaced. Many of these problems are attributed to inexperienced users writing what amounts to completely horrible code.

While the developers of PHP itself are very talented and quite respected, the users of PHP are starting to cause problems for the Linux community as a whole. Each time a site is defaced due to some poorly written PHP script, it is often portrayed as a vulnerability with Linux itself. Of course that is more often than not a complete falsity, as the fault does not lie in any way with the Linux kernel or its developers.

So while Linux advocates often promote the use of PHP for developing webapps on Linux, PHP is starting to become more of a liability. Every site running Linux and PHP that gets defaced due to terribly written PHP scripts reflects very poorly on Linux's public image. Now I have to ask: what is the Linux community willing to do about this problem?

Would they even be willing to go so far as to demand that the PHP developers include functionality to severely limit the ability of faulty scripts to run? It's quite difficult to say at this point. But if changes aren't made fairly soon, then things could degrade very quickly.

Re:PHP's effect on Linux's reputation. (0)

Anonymous Coward | about 9 years ago | (#13297605)

So? How many vulnerabilities are in C code? Perhaps we should think about something else, since C is obviously dragging down the reputation.

Re:PHP's effect on Linux's reputation. (1)

CyricZ (887944) | about 9 years ago | (#13297684)

Indeed, C code can often be quite vulnerable. But it isn't often touted publically (ie. to managers, the general public, etc.) as a main reason to migrate to Linux.

Linux advocates often suggest that Linux is a very secure server platform. Indeed, Linux itself often is. But such advocates often advocate the use of a language like PHP for web development. Each time a well-publicized PHP flaw or script is exploited, it tarnishes the reputation of Linux due to the close association between the two.

So what is in actuality a shitty PHP script being exploited is misunderstood by managers and other often non-technical users as being a flaw in Linux itself. That is where the problem lies. While PHP was once instrumental in bringing people to Linux, it is now also a leading cause of disrepute for the Linux community as a whole.

Re:PHP's effect on Linux's reputation. (3, Insightful)

seek31337 (520238) | about 9 years ago | (#13297818)

This is the most rediculously stupid comment I have ever seen. It makes a series of statements as fact, without any proof.

It also makes claims of a solution which is incomplete. WTF? 'Would they even be willing to go so far as to demand that the PHP developers include functionality to severely limit the ability of faulty scripts to run?'

Demand to make C programs unable to be hacked.
Demand that perl programs are unable to be hacked.
Demand that assembly programs are unable to be hacked.

How about looking at the reputation of the group developing the software you morons install? If there's been tens or hundreds of vulnerabilities in the product you want to install, expect more!

Also, see See http://us2.php.net/features.safe-mode [php.net]

Do we need another entry level book? (3, Insightful)

scottsk (781208) | about 9 years ago | (#13297507)

I am not knocking this book by any means. It is probably very good. But can't any developer who knows a C-ish syntax language pick up PHP basics quickly? I learned it in a day or two just by analogy with C/Perl/etc. How much need/demand is there for entry level books like this?

Where computer books have value to me is when they teach me something that would take hours/days/weeks to learn by trial-and-error. Something non-trivial that can't be guessed from reading the doc. (Like setting up user authentication or something.) That's when I start thinking about spending cash on books which have value by saving me time and especially frustration. (The PHP Cookbook, for example.)

A rather large claim (1)

sholden (12227) | about 9 years ago | (#13297626)

Without any evidence at all.

A smarter approach is to learn the language basics in sequence as rapidly as possible, not getting bogged down in excessive sample code.

Define "excessive". And why is that way smarter?

Learning by example is a pretty common pedagogic approach after all.

Wait a minute.... (2, Funny)

mixonic (186166) | about 9 years ago | (#13297698)

Wait, there is still a programmer that doesn't know PHP?

color me stunned!

-mix

Tasked (2, Funny)

NickF (680075) | about 9 years ago | (#13297761)

A professional programmer could at any time be tasked

tasked
Must be an MBA.

I've just started to read this book... (5, Informative)

kenh (9056) | about 9 years ago | (#13297763)

and I've noticed a few things that don't bode well for the book (in no particular order):
  • Lack of labels on early figures/diagrams I noticed that some of the first chapter examples and diagrams were not labeled correctly.
  • Program names in examples don't match text (or vice-versa) The text will refer to an example with one name, but the actual screen print has a different name - not a huge deal, but combined with the previous point, it is a problem.
  • Handfull of errata in first few chapters none really major, but the sum total makes the reader feel the publisher rushed the book.
  • Instructional method not a good fit for early material The examples in the first few chapters are trivial, and strain the idea that this boo is aimed at anyone with programming experience. I would have prefered one big chapter that ends up with one, more complex example.
  • No common theme to examples Again, I'm only in the first few chapters, but the author keeps introducing new premises for the examples - in contrast, the IMS/DB books I read back in my mainframe days all relied on examples from the hospital domain - the lack of consistency across the examples is a distraction to the reader, who has to endure new "let's pretend your a..." setups for each new topic.
  • Inconsistent editing From my quick review of the last few chapters of the book, many of the above complaints are corrected, which makes me wonder about the editing/technical reviewing done on the manuscript.

Overall, this is a pretty good idea for a book, but the editors/author should not have rushed it to press - the quality of the book appears to have suffered.

I would strongly encourage a potential buyer of this book to spend several minutes with the book and see if the style suits your manner of learnig. Personally, I prefer the O'Reilly Learning series [oreilly.com] approach to teaching a topic, but preferences vary.

And I'll say it again... (4, Insightful)

DigitalBlossom (906945) | about 9 years ago | (#13297800)

The only book anyone should be using for learning PHP is the PHP manual. We write it for a reason. The manual is the only resource I know of which is almost always up to date, maintained, and largely error free (We have errors, but as soon as they're reported they are fixed, usually within hours of the report being filed. Most of these types of errors involve spelling or gramatical mistakes.). Books released on the subject all do the same thing: re-write what the manual has already adequately stated while throwing in errors left and right.

Arguably, there are a few books written which at first seem to be written well. Hell, who isn't tempted to pick up a book now and again which has names such as "Rasmus" and "Andi" etc stamped across the front in large gaping print. But these books are just as useless as those written by lesser-known authors, and shouldn't be used because of the same failings of other books: They're error-prone, and almost immediately deprecated. PHP changes rapidly, very rapidly. Possibly too rapidly for its own good, but that's another discussion entirely. Point being that you can't commit changes to the cvs repository of a book as you can to the PHP manual, and as such any printed book will fall far short of being as up to date as the PHP manual.

If you need a resource to "teach you PHP quickly" there is generally only one chapter you need to read in its entirety, and that is php.net/langref. Anyone willing to take the time to do that can pick up the (extremely easy and basic) syntax of PHP within 2 to 4 hours. From there all one need do is hit the extension documentation pages of any API they may wish to use, such as php.net/mysql, php.net/pcre, etc.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>