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!

Wicked Cool PHP

samzenpus posted more than 6 years ago | from the totally-gnarly-books dept.

131

Michael J. Ross writes "Web developers familiar with a particular programming language, such as PHP, typically turn to books and forums for assistance only when they confront a specific problem that they believe has probably been encountered by many of their peers in the past, and who have published their answers in print or online. Hence the growing popularity of programming "cookbooks", which eschew flowing narratives in favor of self-contained problem descriptions and solutions. One example of a book that combines both styles is Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems, by William Steinmetz with Brian Ward." Keep reading below for the rest of Michael's review.Published by No Starch Press on 9 February 2008, under the ISBNs 1593271735 and 978-1593271732, Wicked Cool PHP aims to provide the reader with a wide-ranging collection of complete PHP scripts and code fragments that solve specific problems frequently encountered by PHP coders. It is not intended for explaining the fundamentals of PHP, but assumes that the reader already understands the basics of the language. The book covers PHP versions 5 and 6. On the book's Web page, visitors can purchase it online, download a sample chapter (Chapter 4: Working with Forms), and download most of the sample code.

The book's material is organized into a dozen chapters, covering a range of topic areas: some simple scripts; configuring PHP; PHP security; forms; text and HTML; dates; files; user and session tracking; e-mail; images; using cURL to interact with Web services; and three intermediate projects. A brief appendix shows the MySQL commands for creating the product_info table used in many of the book's scripts. The book's back cover claims that it offers 76 scripts, but at least one section (#69) does not contain a script.

The first chapter is titled "The FAQs of Life — The Scripts Every PHP Programmer Wants (or Needs) to Know." That's quite a claim, unfulfilled by the chapter's material, which covers only seven narrow topics, such as how to include another file in a script (require_once) and how to print an array (print_r). Furthermore, there is no common theme for the scripts chosen, aside from their addressing questions that one of the authors — who is not identified — sees repeatedly in PHP forums and discussion groups. Some are extremely basic (e.g., print_r), while others address topics that are far more advanced and deserving lengthier treatment (e.g. templating your site with Smarty). That last topic would have been much better presented as an intermediate project in the book's final chapter.

Configuring PHP is an area that can prove perilous for programmers who are new to the language, and are, for whatever reason, having difficulty setting up PHP on their home Web server. For such individuals, Chapter 2 should prove quite useful, because it offers a clear overview of how they can configure their own PHP installations to match their needs. Some of the configuration advice could be a lifesaver, depending upon the reader's circumstances — such as the information on using open_basedir to limit directory access to PHP (and energetic hackers).

However, on page 20, when the authors provide advice on how the reader can find the php.ini file, they suggest that Windows users should look in "C:\php." Actually, the default installation file path is "C:\Program Files\PHP" (unless the reader has altered the value of ProgramFilesDir in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion key in their Windows Registry). They urge the reader to delete any phpinfo() script, for security reasons. But having such a script on a remote server could be quite valuable to the reader, at some point in the future; so it would be wiser to simply rename it, assuming that the reader has not allowed hackers to list file names on his or her Web server.

Several times in the book the authors advise the reader to set the error_reporting configuration option off for production servers — as well as for development servers lacking firewalls — so hackers and others do not see system information contained in error messages. But error_reporting is best used for specifying the level of error reporting, while the display_errors configuration option is best used for disabling the display of those errors to the site visitor. Errors should still be recorded in the Apache error log, so the developer can better diagnose what happened on a production site.

As with most first editions, this one contains several errata: "phpinfo()can" (page 21), "data to encrypted" (page 42), "six years" (page 55; should be 10 years, to match the code), and "timestamp() function" (page 82; should be "time() function").

In any book, a sizable number of minor flaws will prompt the careful reader to begin questioning the editing of the book. This is especially true when encountered in the first paragraph of the first page of the Introduction: "stumbled on to," which should instead be two words. But it goes beyond just issues of line editing — to a question of judgment. That very first page also contains "After you calm down," which is too flippant for what should be a professional work, as are other instances: "living hell" (page 4), "hash-ish" (page 40), and "Mac users... [like] to buy expensive gadgets for the sole purpose of looking stylish" (page 113). The authors frequently use the term "I" without specifying which author is being referred to; presumably it is the first author listed. On page 64, they state that they had previously mentioned the === operator, but I cannot find it anywhere, and neither could whoever created the book's index.

In the sample code, the authors use double quotation marks — instead of single ones — for most of the strings, few of which contain variables. This slows down the PHP interpreter by forcing it to check for variables within the strings, to be interpolated. Moreover, they are not consistent in the usage — occasionally switching over to single quotes instead, for no apparent reason. The same is true of in-line comments, which switch back and forth between Java and C styles.

The code in general is not entirely consistent throughout the book, e.g., using print() in most cases, but echo() in the remaining ones, with no explanation as to why. Perhaps this is the result of having two authors. Most HTML tag names are in lowercase, but a couple are in uppercase.

Some of the book's code appears invalid. For instance, on page 5, one of the statements (abbreviated here), echo "$row[product_name]," generates two errors: "unexpected T_ENCAPSED_AND_WHITESPACE" and "Use of undefined constant key — assumed 'product_name'." The correct code would be: echo "{$row[ 'product_name' ]}." On page 41, $cipher is set to the string "MCRYPT_SERPENT_256," which generates an error, and probably instead should be set to the constant MCRYPT_SERPENT, which works fine. $mode is set to the string "MCRYPT_MODE_CBC," but that should be a constant as well. On page 72, the regex pattern for matching HTML anchor tags does not match an entire opening tag, but just a portion of it. In the downloadable code for section #68, getpage.php fails because "<?" should be "<?php." Readers shouldn't have to debug a book's code just to get it to run without error. Did no one test the sample code before publication?! In the code for section #71, mapdemo.php generates index errors when run without any GET parameters, and does not generate a map when values are entered in the form.

Some of the code may work in certain circumstances, but not in others. For example, on page 70, the pipe character (|) is recommended as a substitute for the forward slash (/) for regex patterns containing many such slashes. But the pipe character is a very poor choice, because it has a special meaning in regex patterns, namely, as the 'or' operator, and thus cannot be used for any pattern that needs to use that operator. In section #49, calculate_time_difference() fails if one or both of the timestamps is the epoch time (time zero). In section #61, get_ip() assumes that two $_SERVER keys are set, and fails when they are not.

Some of the code works but can give beginners the wrong impression. For instance, on page 25, the authors present a configuration setting (incorrectly referred to as an "extension"): ini_set(max_execution_time, "240"). But max_execution_time is not placed in quotation marks. Even though this does not cause an error, a newbie may do the same with ini_get(), and become confused as to why PHP then (rightly) complains. (One could argue that PHP should also flag the ini_set() call as erroneous.) Section #50 could mislead newbie programmers into using that multi-line script instead of PHP's file_get_contents(). Section #51 similarly re-creates the wheel, namely, file_put_contents().

Lastly, some of the code, comments, and variable naming choices are quite puzzling. For instance, in section #30, validate_cc_number defines a variable as $false = false, but this "variable" never gets changed in the rest of the script. That is what constants are for. In the downloadable time difference scripts for Chapter 6, we find "print abs(5 — 62);" with no apparent purpose. In timediff.php, calculate_time_difference() checks for divide by zero errors for a variable that is never used as a denominator.

Unlike most computer programming books, this one has no acknowledgments of any technical reviewers. Given all of the problems in the code, it is possible that there actually were no technical reviewers, though it is difficult to imagine any reason why a publisher would choose that unwise route.

In terms of formatting of the material in the book, most of the left-hand pages (the even-numbered ones) have the page contents shifted too far to the right, almost running into the crease of the book, and leaving a glaring amount of wasted whitespace in the left-hand margin. The only exceptions are on pages 163, 164, and 172, where portions of code awkwardly jut out into the left margin.

The downloadable code archive is quite flawed, and a fair amount of the code needs to be cleaned up. For example, getpage.php contains a lot of redundant code. Much of the sample code in the book is not included in the archive; incredibly, this includes some of the largest scripts, such as the Smarty code in Chapter 1 and the credit card processing code in Chapter 4. In fact, the archive is missing the code for two entire chapters (2 and 3). Oddly enough, at least a couple scripts in the archive are not mentioned in the book. The archive needs a complete overhaul, including the cleanup or elimination of seemingly leftover scripts such as foo.php (three instances) and captcha_old.php.

On the positive side of the ledger, the book contains information that would be of interest to all levels of PHP programmers. For instance, readers who are just barely familiar with the language will benefit from the discussions concerning superglobals, form input security, date and file manipulation, and how to save user information with sessions and cookies. More advanced developers may profit from the discussions on encryption, PHPMailer, captchas, Web services, and other topics generally found later in the book.

In addition, many of the sections include a special subsection titled "What Can Go Wrong?," in which the authors consider potential problems with the code or overall approach presented in that section. Undoubtedly other technical books provide such information, interwoven with the main narrative; but explicitly identifying potential pitfalls is a worthy practice — one that we can only hope to see in other programming books in the future.

At 224 pages, it is a relatively slim volume, but contains a fair amount of useful information relative to its size — a pithiness welcome in the world of computer books. (Fortunately, the trend in the technical publishing world has shifted away from tomes sometimes exceeding 1000 pages that are padded with poorly-edited material shoveled in by multiple authors.)

Yet all in all, Wicked Cool PHP is largely disappointing. It contains no PHP scripts that could be considered "wicked cool." Moreover, the aforementioned code problems clearly call for an improved second edition, including a complete revision of the downloadable code archive. On the other hand, Wicked Cool PHP touches upon a number of key topics in PHP programming, with minimal fluff, and gets right to the point.

Michael J. Ross is a Web developer, writer, and freelance editor.

You can purchase Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

131 comments

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

O'Reilly's PHP cookbok preferable (5, Informative)

Anonymous Coward | more than 6 years ago | (#22992104)

While Wicked Cool PHP seems useful, I've gotten a lot of mileage out of O'Reilly's PHP Cookbook [amazon.com] . I just wish they would release a new, expanded edition. O'Reilly's cookbook series are really a pleasure to use, giving you just the info you need and not wasting space trying to be funny or zany like far too many CS books out now.

Re:O'Reilly's PHP cookbok preferable (0, Informative)

Anonymous Coward | more than 6 years ago | (#22992264)

I gave up on O'Reilly all together when I saw that their web developers book lists pngs as a fully acceptable image format without a word about the transparency issues in IE6 (currently over 25% of browser share).

Re:O'Reilly's PHP cookbok preferable (5, Insightful)

RealSurreal (620564) | more than 6 years ago | (#22992376)

PNGs are perfectly acceptable. IE6 isn't.

Re:O'Reilly's PHP cookbok preferable (1)

i_ate_god (899684) | more than 6 years ago | (#22992402)

Not in the real world.

Re:O'Reilly's PHP cookbok preferable (4, Funny)

Jaqenn (996058) | more than 6 years ago | (#22992548)

PNGs are perfectly acceptable. IE6 isn't.
(I am not the original AC).

Developing a commercial website which is problematic for 25% of its potential visitors is stupid and unacceptable. Come off of your Microsoft bashing mountaintop and face reality.

Whoever modded you insightful should have chosen Funny instead.

Re:O'Reilly's PHP cookbok preferable (2, Insightful)

mini me (132455) | more than 6 years ago | (#22992612)

Wasting money on ensuring that your website works with an antiquated browser that only 25% of your potential customers use is stupid and unacceptable... unless the revenue generated by that 25% exceeds the cost of the additional development.

Re:O'Reilly's PHP cookbok preferable (1)

TomatoMan (93630) | more than 6 years ago | (#22992938)

Uh-huh, good thinking. And how many potential customers will you lose without ever even knowing about them, given your reputation for blowing off one in four as unprofitable?

Remind me not to hire you. (Never mind, I'll remember.)

Re:O'Reilly's PHP cookbok preferable (1, Insightful)

mini me (132455) | more than 6 years ago | (#22993026)

If you're selling Firefox manuals at $1.00 a piece, you would never get enough IE using customers to justify any kind of IE-specific development. Any good businessman will know their target audience well enough to know if the added expense is justified.

Remind me not to work for you. ;)

Re:O'Reilly's PHP cookbok preferable (1)

djheru (1252580) | more than 6 years ago | (#22993738)

It seems to me that if you're selling Firefox manuals, IE6 customers might be one of your biggest untapped markets, no?

Re:O'Reilly's PHP cookbok preferable (3, Insightful)

h4rm0ny (722443) | more than 6 years ago | (#22993764)

Remind me not to work for you. ;)

I don't think you'll need to. You seriously think writing off 1 in 4 visitors to your site is acceptable business sense? Even in your contrived example of selling Firefox manuals, you'd be driving away business as (a) you'd get people interested in Firefox who are currently using IE at home or browsing from an Internet Café or library or University or work and (b) people such as myself who would think to themselves - if the guy finds it so difficult to make some changes for compatibility then why would I want to read a technical manual from him? And this is ignoring that your Firefox Manual selling site is hardly what you'll be asked to do in the real world as a web designer.

Re:O'Reilly's PHP cookbok preferable (0)

Anonymous Coward | more than 6 years ago | (#22994102)

Remind me not to work for you. ;)

Don't worry...with this kind of backward thinking regarding market share and growth potential you wouldn't pass the interview.

I hate the way M$ plays too but it's dumb to not consider a full 25% of the market because I dislike their tool of choice. Also, I and many others use multiple browsers. If I happen to be in IE for some reason (granted it's a stretch) and happen to hit your site and it doesn't render I'm pretty much going to discount you as unprofessional and look elsewhere to purchase what I need.

Re:O'Reilly's PHP cookbok preferable (1)

civilizedINTENSITY (45686) | more than 6 years ago | (#22996396)

None at Universities (and other environments) whose user agreements preclude use of IE within the LAN for security purposes.

Re:O'Reilly's PHP cookbok preferable (1)

Achromatic1978 (916097) | more than 6 years ago | (#22996438)

I'm going to give you the benefit of the doubt. Show me a University Network Usage Agreement that forbids the use of IE.

Re:O'Reilly's PHP cookbok preferable (1)

civilizedINTENSITY (45686) | more than 6 years ago | (#22996404)

None at Universities (or other institutions) whose user agreement precludes use of IE for security reasons.

Re:O'Reilly's PHP cookbok preferable (4, Insightful)

tobiasly (524456) | more than 6 years ago | (#22993174)

Wasting money on ensuring that your website works with an antiquated browser that only 25% of your potential customers use is stupid and unacceptable... unless the revenue generated by that 25% exceeds the cost of the additional development.

I agree. I design in Firefox, then test in IE7, Safari, and Opera, and finally make sure it isn't too broken in IE6. In fact, if it isn't broken enough in IE6, I'll use some hacks to make it a little more broken, along with prominent dire warnings about how they are using a broken browser that can't support the "advanced features" of my site and they need to upgrade.

Petty and immature? Yeah, probably. But IE6 made my life a living hell for plenty of years and now that it's no longer the dominant browser it makes me feel better to turn some of that pain right back around. If I can get just a small percentage of those 25% users to switch to a better browser, then I will have made the internet a bit better for everyone and that's definitely worth the lost customers I may have caused.

Re:O'Reilly's PHP cookbok preferable (1)

ruda (128152) | more than 6 years ago | (#22995984)

The Internet would be a better place if web "developers" just stop to bitch up.

Re:O'Reilly's PHP cookbok preferable (1)

Billly Gates (198444) | more than 6 years ago | (#22994040)

I say it would exceed. Revenue is revenue.

If you worked in a store would you tell 1 out of 4 customers to go to hell because its cheaper to have less cashiers and clerks?

IE6 will become irrevelent hopefully when it reaches below %10 marketshare but still that is huge too to ignore. Vista is not helping people want to upgrade either.

Re:O'Reilly's PHP cookbok preferable (0)

Anonymous Coward | more than 6 years ago | (#22994848)

"If you worked in a store would you tell 1 out of 4 customers to go to hell because its cheaper to have less cashiers and clerks?"

Well, that's exactly what Ferrari or Cartier does (while with different means and purpouse). Hell, they hitch away much more that 25% of their potential customers, and there they go.

Re:O'Reilly's PHP cookbok preferable (0)

Anonymous Coward | more than 6 years ago | (#22992864)

Sorry but IE6 is an abortion and any Web developer with any brains puts a browser detector and redirects the visitor to a "you are running IE6 please upgrade or use firefox or you will notice strange things on the website due to the faulty browser that IE is..

that works very well and from my low use site (Only 10,000 hits a day) I see that over 70% of those that do hit that page do follow one of the links off to upgrade.

The 30% of the 25% that dont I really dont care if they dont use my site.

Re:O'Reilly's PHP cookbok preferable (3, Interesting)

Ford Prefect (8777) | more than 6 years ago | (#22993048)

Sorry but IE6 is an abortion and any Web developer with any brains puts a browser detector and redirects the visitor to a "you are running IE6 please upgrade or use firefox or you will notice strange things on the website due to the faulty browser that IE is..

Any web developer worth employing knows about browser deficiencies, and will effortlessly code around them using various sniffs, hacks and conditional comments. Giving a significant proportion of visitors a degraded experience just isn't on - coding for one browser is lazy, and choosing, say, Firefox as a preferred platform is no better than choosing Internet Explorer. (Remember IE-only websites?)

Idealistic? Hardly - you may find that the Person Who Pays The Bills is running IE 6... ;-)

Re:O'Reilly's PHP cookbok preferable (1)

Paiev (1233954) | more than 6 years ago | (#22994672)

Hardly - you may find that the Person Who Pays The Bills is running IE 6... ;-)
No, I'm quite sure that my mother is running Firefox. Now excuse me, my daily ten minutes of sun are up, back to the basement now.

Re:O'Reilly's PHP cookbok preferable (1)

pbhj (607776) | more than 6 years ago | (#22995052)

>>> Any web developer worth employing knows about browser deficiencies, and will effortlessly code around them

Ha-ha-ha .. yeah right.

IE5/IE6 support added about 50% (sometimes more!) to projects I did in the past. Maybe I'm not worth employing but IE6 doesn't generally get a look in now (too much cost to bother with, just basic support, no gloss) - most of the sites I work on however are community groups / charities.

I can't imagine any web designer / developer saying that coding round IE6 was effortless!

Re:O'Reilly's PHP cookbok preferable (1)

civilizedINTENSITY (45686) | more than 6 years ago | (#22996458)

I sense a contradiction inherent to "effortlessly" being put next to "sniffs, hacks and conditional comments" in regard to coding around MS browser deficiencies. Doable, yes. Pain-in-the-ass, yes.

In terms of laziness, aren't you pointing at the wrong people? Choosing to code to standards should be the preferred method. Not implementing standards in your browser is lazy (or worse).

Re:O'Reilly's PHP cookbok preferable (1)

billcopc (196330) | more than 6 years ago | (#22993828)

You may not care about IE support on a personal site or blog, but for corporate stuff it's completely reversed, with a heavy majority of business users still running IE6. They may know of Firefox, they may even use it on their home computer, but in the office they're stuck with IE.

Me, I just try my best to support both. I don't see IE6 as the enemy, even though it does create stress... my enemy is Opera/Safari/Konq and all the other one-off niche browsers. For those small players, my rule is "best effort only", which means if I forgot to test in that browser that day, well it sucks to be you.

Re:O'Reilly's PHP cookbok preferable (0)

Anonymous Coward | more than 6 years ago | (#22992898)

PNGs are perfectly acceptable. IE6 isn't.
(I am not the original AC). Developing a commercial website which is problematic for 25% of its potential visitors is stupid and unacceptable. Come off of your Microsoft bashing mountaintop and face reality. Whoever modded you insightful should have chosen Funny instead.
well, substitute another format for png and move on?

Re:O'Reilly's PHP cookbok preferable (0)

Anonymous Coward | more than 6 years ago | (#22993112)

PNGs are perfectly acceptable. IE6 isn't.
Come off of your Microsoft bashing mountaintop and face reality.

Aim... and miss. Sorry, the GP never mentioned Microsoft, only Internet Explorer 6. It's IE bashing, not Microsoft bashing. MS does make IE but they're not the same.

Anyone who has EVER developed on IE6 knows damn well that it's the truth. IE6 is utterly unacceptable as a web browser in terms of a) security b) page rendering c) standards. Come off your own Anti-Anti-Microsoft bashing mountaintop and get a clue.

Re:O'Reilly's PHP cookbok preferable (1)

alex4u2nv (869827) | more than 6 years ago | (#22994278)

Or stick with PNGs, and fix broken browsers with a few simple javascript. I choose this path, because the javascript will soon be useless as people become more security conscious and upgrade their browsers.

So you see? there is a purpose for malware: they encourage system updates that keeps everyone somewhat on the same page.

Now developers could continue moving forward with the latest and greatest.

Re:O'Reilly's PHP cookbok preferable (1)

Anonymous Coward | more than 6 years ago | (#22992636)

I gave up on O'Reilly all together when I saw that their web developers book lists pngs as a fully acceptable image format without a word about the transparency issues in IE6 (currently over 25% of browser share).
It is a perfectly acceptable image format if you don't use 24-bit alpha. Almost all GIFs on the web are 8-bit anyway, so if you use a PNG like you would a GIF, you will have no problems with IE. I don't see what the problem is.

Re:O'Reilly's PHP cookbok preferable (1)

Neil Hodges (960909) | more than 6 years ago | (#22993222)

Umm, GIFs by definition are 8-bit, so it's not "almost." You mean GIF 89a's indexed transparency support, which IE also supports with PNGs.

Considering PNGs yield smaller compression ratios universally in 8-bit (indexed, with support for the indexed transparency) compared to GIF, there's really no reason to use the obsolete format anymore, except for browsers from the early-mid 90's. Heck, even Netscape Navigator 4.0 supports PNG rendering, so the "old browser" argument isn't really useful anymore.

Re:O'Reilly's PHP cookbok preferable (1)

larry bagina (561269) | more than 6 years ago | (#22993880)

PNGs have another problem -- gamma correction [hsivonen.iki.fi] . If you're using transparency or a white background, it's not a problem, but if you try to mix a png's color with a css/html color, it may be painfully obvious.

Re:O'Reilly's PHP cookbok preferable (0)

Anonymous Coward | more than 6 years ago | (#22992862)

a fully acceptable image format without a word about the transparency issues in IE6
The IE <7 PNG fix: http://homepage.ntlworld.com/bobosola/ [ntlworld.com]

Granted, it doesn't fix background images or any overly-complicated, but it works fine otherwise.

Re:O'Reilly's PHP cookbok preferable (0, Flamebait)

kingmundi (54911) | more than 6 years ago | (#22992314)

Or.. maybe you just did a search on popular PHP books on amazon, then provided a link using your reseller ID, in hopes of making a quick buck.

Forget PHP, use Python (1, Interesting)

Anonymous Coward | more than 6 years ago | (#22993492)

Can't we all get along and use Django, a wonderful Python framework which even beats the hell out of RoR?

PHP6? (1, Insightful)

Spazholio (314843) | more than 6 years ago | (#22992164)

The book covers PHP versions 5 and 6. Do they know something we don't? Isn't PHP5 the most recent version?

Re:PHP6? (3, Informative)

BigZaphod (12942) | more than 6 years ago | (#22992282)

No.. they just know something you don't [php.net] . :)

Re:PHP6? (1)

Spazholio (314843) | more than 6 years ago | (#22992394)

Hey, check that out.

Huh.

My apologies - apparently, my due diligence was not due enough.

Thanks!

Re:PHP6? (4, Insightful)

moderatorrater (1095745) | more than 6 years ago | (#22992584)

Writing books about developmental versions of PHP doesn't seem like the smartest move in the world. I remember some books when php5 came out that included the keyword "that" which would be used with a few magic functions. This feature was taken out before php5 was released officially and left a lot of books with false information.

Besides, if these books are really for professionals, shouldn't they be able to adapt the solutions to php6 rather easily?

Re:PHP6? (1)

Fweeky (41046) | more than 6 years ago | (#22992366)

HEAD PHP became PHP6 over a year ago. You can get snapshots [php.net] if you're so inclined.

Re:PHP6? (1)

an.echte.trilingue (1063180) | more than 6 years ago | (#22992520)

6.0 is released, but it's pretty beta. You can download it here [php.net] . It has a lot of changes. You can read about some of the important changes here [corephp.co.uk] .

like the others? (1)

StargateSteve (1054492) | more than 6 years ago | (#22992180)

If this is anything like the Shell Scripts or Java book, it will provide me with many dozens of hours of nerdy enjoyment and glee.

marketing 101 (5, Funny)

Anonymous Coward | more than 6 years ago | (#22992186)

if (title contains wicked | cool)
then
              author && editor == dumb fuck
endif

Re:marketing 101 (1)

nazsco (695026) | more than 6 years ago | (#22995650)

> author && editor == dumb fuck

those are comparissons.

$author = $editor = 'dumb fuck'

php syntaxnazi

Shouldn't it be just "Wicked PHP?" (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#22992214)

I mean, shouldn't it?

Re:Shouldn't it be just "Wicked PHP?" (2, Insightful)

mortonda (5175) | more than 6 years ago | (#22993264)

Yeah, it doesn't quite fit. Wicked PHP - ok. Wicked Cool - Ok. Cool PHP. Nope.

I use PHP all the time. It can be used well, though it has been abused terribly by the masses. But cool? I think it lost its coolness quite some time ago.

The reviewer also nitpicks about the use of single quotes vs double qoutes, as double quotes have to interpolate variables etc... Come on, most code out there has bigger performance problems to deal with. Variable interpolation is not that bad.

I keep finding blogger who benchmark millions of iterations of similar functions to prove method X is faster than method Y, but in the real world, those things just don't matter. Knowing how your data structures and sql code work, and minimizing your Big O runtime is far, far more important.

If you have a site that is getting so many hits that variable interpolation is truly an issue, you need to learn how to scale horizontally, or choose a different language/platform.

Re:Shouldn't it be just "Wicked PHP?" (4, Insightful)

QuoteMstr (55051) | more than 6 years ago | (#22993626)

Any language can be used well, but it's much easier to use some languages well than others. PHP is inconsistent and limiting; why would anyone who knows how to write good code use it instead of a different language?

Re:Shouldn't it be just "Wicked PHP?" (2, Insightful)

MrMunkey (1039894) | more than 6 years ago | (#22994898)

Person X doesn't like items 1, 2, and 3 about language Y. Haven't we all heard this before? Yes, check my post history, I've done it too. There are plenty of people around here who would have issues with Java, .NET, Ruby, etc. To each his own. Me personally? Yeah, I have a bias. I already know PHP, so right now I can program in it faster than others. I know that PHP is inconsistent (string and array function parameter orders top the list), and the complete OO paradigm is not implemented, but php still works just fine for my situation(s). It must have done something right to be as popular as it is. There's also a lot of good PHP web hosting out there, lots of people in the community, and the documentation is pretty darn good at php.net Those might not be enough for some people, and that's why there are other projects out there.

Re:Shouldn't it be just "Wicked PHP?" (1)

Rob Kaper (5960) | more than 6 years ago | (#22995822)

One reason could be the amount of built-in features. The last time I tried image manipulation with mod_perl the script required more include lines alone than the total lines of code in the equivalent PHP script. Even the Perl guru at work had to admit that mod_perl has some disadvantages when you're looking for a platform and not just a language. (use Image::JPEG::ohNoNotTheVersionInCPANWhichDidntCompileAnyway, use GD::ButSomeObscureDownloadBecauseOfADependencyFromHell)

(Don't get me wrong, I don't hate Perl as a language.)

Re:Shouldn't it be just "Wicked PHP?" (0)

Anonymous Coward | more than 6 years ago | (#22996096)

How is this insightful? People use PHP because it's the right tool for the right job -- not necessarily because it's elegant, fast, or easy to use, but often because it's portable, already in place, or preferred by their employer. In an ideal world, I personally wouldn't use any of the popular programming languages, but this isn't an ideal world.

title (2, Funny)

Anonymous Coward | more than 6 years ago | (#22992218)

The title isn't just bad, it's wicked retahded.

Nice title (0)

Anonymous Coward | more than 6 years ago | (#22992370)

Nice title if your boss is a 18 year old kid who you won't mind asking to buy you a book with "Wicked Cool" in the title.

cook book & ideas (1)

erbbysam (964606) | more than 6 years ago | (#22992378)

These books are amazing for random ideas, in my opinion.
Story time:
Not to give a random plug or anything, but a while back I read a PHP cookbook (2006ish) and it had a small section on a plugin called "Ming" which can generate flash animations without using proprietary tools. I took what little was available on the web and (for the past 2 years) have been developing http://www.icanimate.com/ [icanimate.com] which allows users to generate animations(in a java applet) which can be played back in a flash animation(through PHP&Ming) which is stored in a mysql database in a script(text, not image based). I've mostly used the development of this website as a project for my academic programing classes(teachers love this integrated stuff). Gotta love cook books :)

Re:cook book & ideas (1)

h4rm0ny (722443) | more than 6 years ago | (#22993868)


I've read large chunks of the "PHP Cookbook" and it's not bad. There's useful information in there, though the tome is a little indigestible. The absolute best book I've read of this kind is the Python Cookbook. Admittedly, I was still learning Python at the time and so I was enjoying all the little discoveries about the language, but it's a seriously good book and in an age of convenient online references and tutorials, is maybe one of the few programming books that is absolutely worth buying. Absolutely great book both in the full writing and the clever techniques and theory.

PHP is junk compared to Python (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#22992382)

Lets just all get along and use Django, its a nice framework for building web stuff.

You shouldn't need a "cookbook". (3, Insightful)

Chandon Seldon (43083) | more than 6 years ago | (#22992396)

If you actually understand the language that you're using and the basics of programming, you should be able to handle most simple cookbook-type programming problems without any help.

Now, sitting down and reading one of these "cookbooks" (straight through, like a novel) when you're learning a new language might be a good idea; it helps get an idea of the programming style used in the community around the language. But, if you find yourself constantly using one of these things as a reference book for solutions then you should take that as a sign that you should probably go pick up a "Learning Language X" book and actually read it.

Programming patterns = very good "cookbooks" (2, Interesting)

Spy der Mann (805235) | more than 6 years ago | (#22992956)

What has helped me the most to work with PHP is reading articles about programming patterns (i.e. MVC) and reading reviews and technical documentation on frameworks (i.e. joomla). Plunging into the code of these architectural mammoths has really changed my way of thinking, and more than once. For example, after reading a bit of joomla i decided to make a class for form output to organize my form templates (which receive also css parameters), instead of hardcoding the values between control structures like foreach loops for every option in a select. Now my embedded HTML is much cleaner. Compare:

BEFORE
Template file:

(html stuff)
<label for="select_company" class="classname">Choose a company:</label>
(more html stuff)
<select name="company" id="select_company" onchange="(awfully long javascript stuff here)" class="classname" style="(awfully long additional css stuff here)">
<?php foreach($companies as $companyid => $companyname) {
  echo "<option value=\"",htmlspecialchars($companyid),"\"";
  if($companyid == $currentcompanyid) {
    echo " selected=\"SELECTED\"";
  }
  echo ">{$companyname}</option>\n";
}
echo "</select>\n";
// and that was just the first field!
?>
(more html stuff)
AFTER
Data file:

$form_definitions = array(
  'company'=> array(
    'type'=>'select',
    'data'=>&$companiesarray,
... parameters ...
  ),
  'datejoined' => array(
    'type'=>'date_calendar_popup',
... more parameters...
  ),
... more fields ...
);
 
$defaultvalues = array(
  'company'=>'google',
  'datejoined'=>'01/01/2008'
);
Template file:

... preprocessing stuff here ...
$myformobj->process_data($form_definitions,$defaultvalues,$formdata['form1']);
 
// Since we don't have embedded PHP here, we can use heredoc syntax! :)
echo <<< EOD
(non-form html stuff)
{$formdata['form1']['company']['label']}
(more non-form html stuff)
{$formdata['form1']['company']['input']}
(more non-form html stuff)
EOD;
This code is way easier to customize (and looks much clearer in a syntax highlighting editor), besides eliminating the possibility of making a mistake while coding the HTML (the code for making an html select from an associative array is pretty standard, why bother reinventing the wheel with each template?). This alone has saved me not hours,but days of coding (clone the combo 5 times, and change the parameters in only 20 seconds; fiddle around with the inputs - move this up here, exchange these two fields including their calendar popups, etc.) and debugging (try debugging the first example when you're inside massively nested tables!).

Practical examples are a good study, but programming patterns theory and practice is certainly worth the time invested.

Re:Programming patterns = very good "cookbooks" (1)

sarbrot (1024257) | more than 6 years ago | (#22993384)

sorry man but you fail! joomla is one the worst examples of how not to write any code. As much as i love open source software i have to say that joomla really is done badly. I am really looking forward to the next major typo3 release

Re:Programming patterns = very good "cookbooks" (1)

Spy der Mann (805235) | more than 6 years ago | (#22993632)

Thanks for the tip. Joomla may be a worst example, but the idea of having form objects isn't :) In any case, mind enlightening us about why Joomla sucks? It's not a challenge, it's a sincere question - one never stops learning.

Reviewing the review (2, Interesting)

hee gozer (1261036) | more than 6 years ago | (#22992438)

This slows down the PHP interpreter by forcing it to check for variables within the strings, to be interpolated.
Say what?!

e.g., using print() in most cases, but echo() in the remaining ones
They are language constructs, not functions (so your notation is kinda wrong, otherwise valid point).

On page 41, $cipher is set to the string "MCRYPT_SERPENT_256," which generates an error, and probably instead should be set to the constant MCRYPT_SERPENT, which works fine
Their PHP was compiled with libmcrypt version 2.2.x. Big deal.

In the downloadable code for section #68, getpage.php fails because "<?" should be "<?php."
Actually by default that'll work.

Re:Reviewing the review (2, Informative)

Anonymous Coward | more than 6 years ago | (#22992522)

This slows down the PHP interpreter by forcing it to check for variables within the strings, to be interpolated.
Say what?!
Say what, what? Using "" strings which support interpolation is slower than using '' strings which don't (even accounting for the dot operator concatenation of the variables to the '' string). Often "" is preferable anyway for code readability and with the inherent latency of the web for which PHP is most often used it's like a drop in the ocean, but still, any benchmark of PHP will support the fact that "" is undoubtedly quite a bit slower than ''.

Re:Reviewing the review (1)

Firehed (942385) | more than 6 years ago | (#22992792)

Well the latency of the web isn't so much the problem as the scalability of the script. An extra 50ms means nothing to the end user, but if you're getting twenty page views a second, you're going to find your server getting back-logged really quickly.

However, I think (hope) the confusion may have been in the word "interpolated", which should have been 'interpreted', 'substituted', 'replaced', or any number of other words.

Re:Reviewing the review (0)

Anonymous Coward | more than 6 years ago | (#22992846)

As far as "interpolation" goes, I think that's an accurate term. The variables are interpolated within the string. At the very least I believe it's the term used in PHP documentation about it.

Re:Reviewing the review (1)

hee gozer (1261036) | more than 6 years ago | (#22993374)

The correct term is "variable expansion". Besides, double-quoted strings don't just expand variables, they also interpret escape sequences. That's what's in the manual (and it's correct, of course).

Re:Reviewing the review (1)

chromatic (9471) | more than 6 years ago | (#22993274)

However, I think (hope) the confusion may have been in the word "interpolated", which should have been 'interpreted', 'substituted', 'replaced', or any number of other words.

"Interpolated" is actually correct.

Re:Reviewing the review (1)

mortonda (5175) | more than 6 years ago | (#22993356)

Well the latency of the web isn't so much the problem as the scalability of the script. An extra 50ms means nothing to the end user, but if you're getting twenty page views a second, you're going to find your server getting back-logged really quickly.

However, I think (hope) the confusion may have been in the word "interpolated", which should have been 'interpreted', 'substituted', 'replaced', or any number of other words.
"50ms" is a made up number. Show me where a real world profiler (on a realistic php script) has shown interpolation to be a major bottleneck. Don't optimize prematurely - there are almost always far bigger problems to deal with than variable interpolation.

And yes, "interpolation" is the exact correct word in this context.

Re:Reviewing the review (1)

chromatic (9471) | more than 6 years ago | (#22993314)

... any benchmark of PHP will support the fact that "" is undoubtedly quite a bit slower than ''.

If that's actually true to any substantive degree (network latency is likely your biggest bottleneck when talking about HTML generated by PHP), there's something very wrong in the PHP core. The right way to parse code into some sort of AST or optree means that the parser emits a different tree for a double-quoted string with no interpolation than for a double-quoted string with interpolation. That tree should be identical to a single-quoted string with concatenation; it's the same operation. Double-quoted interpolation syntax is a programmer optimization.

Re:Reviewing the review (1)

larry bagina (561269) | more than 6 years ago | (#22994022)

You're right. That's there's something very wrong.

"quoted text with $var" is converted to 'quoted' . ' ' . 'text' . ' ' . 'with' . ' ' . $var.

Re:Reviewing the review (0)

Anonymous Coward | more than 6 years ago | (#22996162)

single quotes is faster than double, as there are less escapes that have to be checked for. it's not a HUGE improvement, but it's worthwhile. and short tags are bad bad bad, so any book that recommends them gets a down check from me

I prefer the PHP Phrasebook (1)

djheru (1252580) | more than 6 years ago | (#22992450)

From Developer's Library. Written by Christian Wenz. It balances the "how-tos" between core PHP and Libraries like PEAR.

Re:I prefer the PHP Phrasebook (1)

ricosalomar (630386) | more than 6 years ago | (#22992654)

I was using that one for a while, but I got to the part about initializing an array, and it said:

My hovercraft is full of eels

all too common problem (3, Insightful)

dslbrian (318993) | more than 6 years ago | (#22992460)

Did no one test the sample code before publication?!

This is one of those things that I just can't understand. I ran into this same thing when trying to get up to speed on C++ on Windows a few years back. I picked up a copy of Visual C++ .NET Bible (only to find out it had almost nothing to do with .NET) and found it's examples were completely bug ridden. I found one example that had something like 20 bugs in it.

One would think on the web where fast publication generally happens you might see this. But in an introductory text, where examples will cause profound confusion, you would think they could at least do a single editorial debug pass through it. More so, it's a freaking dead-tree book, if you are going to publish something that will last for years, and it has your name on the cover, try checking the examples!

BTW, for those who think O'reilly is immune to this, it's not - I have a number of O'reilly texts I bought based on their rep only to find out they published a useless doorstop.

Re:all too common problem (1)

ClamIAm (926466) | more than 6 years ago | (#22994246)

it's examples were completely bug ridden.

Well, hopefully it was less maddening than my class in Unix/C, where I enjoyed the insanity of a (nearly) 40-year-old operating system/language, coupled with the insanity of many typos.

Re:all too common problem (1)

pfleming (683342) | more than 6 years ago | (#22995276)

Did no one test the sample code before publication?!

This is one of those things that I just can't understand. I ran into this same thing when trying to get up to speed on C++ on Windows a few years back. I picked up a copy of Visual C++ .NET Bible (only to find out it had almost nothing to do with .NET) and found it's examples were completely bug ridden. I found one example that had something like 20 bugs in it.

One would think on the web where fast publication generally happens you might see this. But in an introductory text, where examples will cause profound confusion, you would think they could at least do a single editorial debug pass through it. More so, it's a freaking dead-tree book, if you are going to publish something that will last for years, and it has your name on the cover, try checking the examples!

BTW, for those who think O'reilly is immune to this, it's not - I have a number of O'reilly texts I bought based on their rep only to find out they published a useless doorstop.

The things this reviewer complained about the most seemed to me to depend on environmental settings and would be very server specific. He complained about short tags (there are many scripts that rely on short tags, good bad or ugly)when short tags can be set in the server configuration. And complaining about the difference in quoting styles and the difference between print and echo? The review lost any sense of objectivity when he started picking nits.

Re:all too common problem (1)

UCFFool (832674) | more than 6 years ago | (#22995602)

I'd have to agree. I just finished a PHP book (will be available from www.phpreferencebook.com in a few days) and every single chunk of code was copy/pasted into a test.php file and ran with all errors enabled to make sure it was working as expected. Every time. If I changed a word in a comment, I copy/pasted the whole thing and tested it. Period.
Sometimes I wonder. Maybe since I had the luxury of self-publishing I could make sure it was right, but if it isn't right, why bother publishing it!

Is this necessary? (1)

street struttin' (1249972) | more than 6 years ago | (#22992556)

What's wrong with the online documentation? This [php.net] is all I ever needed...

Warnings != errors (1)

Cairnarvon (901868) | more than 6 years ago | (#22992694)

For instance, on page 5, one of the statements (abbreviated here), echo "$row[product_name]," generates two errors: "unexpected T_ENCAPSED_AND_WHITESPACE" and "Use of undefined constant key -- assumed 'product_name'."

Both of those are Warnings, not Errors. And in true PHP tradition, unless it breaks the script completely (which Warnings don't by default), it's not only not wrong, but pretty close to best practices.

Honestly, this sounds like one of those books that gives PHP its bad reputation.

Missing tag! (0)

Anonymous Coward | more than 6 years ago | (#22992698)

Missing tag: oxymoron.

So... (1)

Screamer49 (541759) | more than 6 years ago | (#22992728)

Sounds like you liked it then?

The 80s called ... (4, Insightful)

Bob-taro (996889) | more than 6 years ago | (#22992746)

... they want their slang back. "Wicked cool"? Seriously? While it's entirely possible that this phrase has made a comeback of which I am unaware, I would think using the word "wicked" totally cancels out (or possibly negates) the word "cool". Why not name it "Totally far out PHP"? "Really swell PHP"? From a marketing POV, the slang used in the title of a programming language book should probably not pre-date the programming language itself.

Just my opinion. I'm not an author or a marketer.

Re:The 80s called ... (0)

Anonymous Coward | more than 6 years ago | (#22992950)

I'd vote for "Totally fresh PHP", myself.

Re:The 80s called ... (0)

Anonymous Coward | more than 6 years ago | (#22992996)

"wicked" is a superlative form of good, like "super," primarily used in the North East -- particularly the Boston area. (although I will agree that I don't quite 'get it' as to why).

You may just be far from there.

Re:The 80s called ... (0)

Anonymous Coward | more than 6 years ago | (#22994038)

So, in other words, no one that MATTERS uses "wicked" any more.

Name the last popular thing to involve Boston. Only thing I can think of is some failing Fox sitcom is set there.

Re:The 80s called ... (1)

UrgleHoth (50415) | more than 6 years ago | (#22993002)

"No Starch Press" had another "Wicked cool" book, http://books.slashdot.org/article.pl?sid=06/01/25/1459239 [slashdot.org] on Java.

I'm a transplant to New England, and hear "wicked" used with some frequency. They also say "cool beans." Sometimes I even hear "Wicked cool beans." I think they say that just to be "pissahs."

Re:The 80s called ... (1)

fattmatt (1042156) | more than 6 years ago | (#22993378)

I asked a bunch of old Boston townies, they said the phrase never went out of style and then they drove off in a '86 Monte Carlo SS Aerocoupe, which BTW, was out of style in the showroom.

Re:The 80s called ... (1)

risk one (1013529) | more than 6 years ago | (#22994284)

From a marketing POV, the slang used in the title of a programming language book should probably not pre-date the programming language itself.

So my upcoming title "Awesomely Rad FORTRAN" is still ok?

Re:The 80s called ... (1)

jadin (65295) | more than 6 years ago | (#22995066)

You'd prefer current slang? I can't stand most of today's slang.

Re:The 80s called ... (1)

Geste (527302) | more than 6 years ago | (#22995872)

I agree 100 percent.

It should have been "Wicked Pissah PHP"

"Professional work" (4, Insightful)

graznar (537071) | more than 6 years ago | (#22992816)

...too flippant for a professional work.

You picked up "Wicked Cool PHP" and expected a really stodgy, professional work?

cross-site scripting? (2, Funny)

myowntrueself (607117) | more than 6 years ago | (#22992920)

I sure hope they can help people to program cross-site scripting vulnerabilities...

No book on php could miss examples of how to do this, surely? Its the number one thing that php programmers need to be able to do! Apparently...

Re:cross-site scripting? (0)

Anonymous Coward | more than 6 years ago | (#22992988)

That's the beauty of php: XSS vulnerabilities is embedded into the language, so you don't have to worry about it ;)

am i retarded? (0)

Anonymous Coward | more than 6 years ago | (#22992952)

has anyone actually read the sample chapter provided by the authors on their website?

retarded buttload of crap. i never encountered the problem "Excess Whitespace", nor "Importing Form Variables into an Array", every real programming language returns an array without me explicitly shitting name[] into the markup. "Using Multiple Submit Buttons", this is like "wicked cool cgi programming from the 20th century". Even "Checking Valid Email Addresses" is bullshit, double optin or nothing.

yes, i'm agitated, but its the forcefed crap from years ago, i wouldn't pay a dime!

Professional or Hip? (1)

KalvinB (205500) | more than 6 years ago | (#22992958)

A book titled "wicked cool" may appeal to kids who havn't yet learned that programming will never be mistaken for "cool" but I don't think it will appeal to professionals. Of course PHP tends to be seen as a "script kiddie" language anyway.

From the review seeing "require_once" as the solution to including files shows that code organization is apparently not being taught. It's the "goto" of PHP. Instead of laying out the code in a clean logical fashion that avoids redundant includes you can simply use "require_once" and avoid that whole process.

A lot of time is spent on how to use a language but what really makes life easy on people who will have to fix your code later (including yourself) is how the code is organized.

That would be a good topic for beginner programmers who sometimes don't take the time to not only learn how to use a language better but also how to organize their code better.

Re:Professional or Hip? (1)

mortonda (5175) | more than 6 years ago | (#22993434)

From the review seeing "require_once" as the solution to including files shows that code organization is apparently not being taught. It's the "goto" of PHP. Instead of laying out the code in a clean logical fashion that avoids redundant includes you can simply use "require_once" and avoid that whole process.
It's not always that easy, and the test is simple. It's probably not worth the time to sort out.

PHP isn't the only place this metaphor is used, many C headers have something like:

#ifndef DATA_H /* ... code ... */

#endif


hella awesome gnarly php dude (2, Funny)

fragbait (209346) | more than 6 years ago | (#22993266)

While there are probably some exceptions about the Wicked Cool series of books, the fact that it has wicked cool in the title means I won't buy it. It might as well be named "Hella Awesome Gnarly Bitchin' PHP". I wouldn't buy that book, either.

-fragbait

Re:hella awesome gnarly php dude (0)

Anonymous Coward | more than 6 years ago | (#22994860)

Sadly, it seems your coding isn't gnarly enough to reach the bitchin' threshold and therefore your shit ain't bangin'. Better luck next time.

Re:hella awesome gnarly php dude (1)

WaltBusterkeys (1156557) | more than 6 years ago | (#22995876)

The title ("Wicked Cool") just shows east coast bias. If it were written in San Francisco it'd be "Hella Cool." If it were written in Sacramento it'd be "Hecka Cool." And if it were written in LA it'd have a picture of a babe on a beach on the cover.

php limitations (2, Insightful)

larry bagina (561269) | more than 6 years ago | (#22993704)

For instance, in section #30, validate_cc_number defines a variable as $false = false, but this "variable" never gets changed in the rest of the script. That is what constants are for.

It doesn't sound like it in this case, but if a function returns a value by reference, you would need to put a constant in a variable before returning it.

Just Terrible (1)

CopaceticOpus (965603) | more than 6 years ago | (#22993830)

I just took a quick glance at chapter 4, and I can tell you that this book is complete shit. Their solution to handling web forms is to write some quick and dirty error handling functions. An approach like that guarantees you're going to overlook some security holes, and that every time you want to handle a form you'll be rewriting your code.

Use classes. Take advantage of libraries like HTML_QuickForm or Zend_Form. If those don't meet your needs, build your own. In either case, learn about the common security problems with forms such as XSS attacks and SQL injection. Don't just start barfing out functions into your page, but instead organize your thoughts, and think about how you can generalize the problem. If you expect to be doing the same basic task repeatedly, spend more time on generalization. If not, you can keep it more basic, but you still want to group things together. Don't repeat yourself.

PHP as a language has moved far ahead from its shaky beginnings. It's far from perfect, but it can be used well. Compare the hideous old "formmail.php" script that used to be popular to the shiny new Swift Mailer [swiftmailer.org] to see just how far things have come. It's up to each programmer if they want to challenge themselves to write truly excellent code, or if they just want to keep kludging along. If you make the effort you'll be rewarded many times over.

Writers / Editors Not Reviewers (1)

topham (32406) | more than 6 years ago | (#22993966)

Anybody else think there should be a moratorium on Writers / Editors being reviewers?

Overall I think the review had a few good points, but started devling into a one-upmanship type sitation. It became obvious to me that there was a virtual axe to grind and it was not a suprise to see the reviewer claims to be a writer and editor.

Somewhere it stopped being about real flaws, and became a game of pointing out minutia

Re:Writers / Editors Not Reviewers (0)

Anonymous Coward | more than 6 years ago | (#22994856)

I completely agree. I'd much rather read a review based on the real merits of the book (or problems, as it may be), rather than whether or not he thinks the margins are misaligned.

Inadvertant advertising campaign? (1)

AdamWho (1258590) | more than 6 years ago | (#22995196)

If the book is not quality then why are you advertising it so widely on Slashdot? Granted, you think you are giving a brutal review but wouldn't an Amazon comment be more effective without giving the book such wide exposure. Honestly I would have never heard about the book until it showed up here.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?