Larry

Yeah, I posted about MongoDB in my blog a few months ago (http://www.larryullman.com/2011/04/12/looking-ahead-mongodb/). It is an interesting concept and one worth keeping an eye on. I was also just reading this discussion of using CouchDB for a project, and then changing to MongoDB: http://seancoates.com/blogs/gimme-bar-no-longer-on-couchdb

For some reason, all of the MySQL Improved functions are hard to find in the PHP manual from a procedural standpoint. I think it has to do with the functions being available in both OOP and procedural approaches. So the function is documented, it just takes some effort to find it.

Thanks for the question. Normally I use MySQLI procedurally. I know lots of people love PDO but I have yet to see the benefit of using it for most projects. In twelve years, I've never once switched the underlying database application (a switch like that would be easier with PDO). To me, using PDO just seems like extra overhead. I'm not against PDO, I'm just saying I haven't felt the need to rely upon it.

Thanks for the question. The answer is that conditional will be TRUE, because the conditional uses the assignment operator, not the comparison operator. So in the conditional, $var is being assigned a new value. I posed this question as it's a common mistake and bug.

yeah, there is no simple set of rules. But continuing on, table and column names never go in quotes. Some people put them in backticks, and if they conflict with a MySQL keyword, you must use backticks. It's not a matter of putting variables in quotes or not, but rather whether the variable's value needs to be quoted (in which case you would quote the variable to get that effect).

I admire your honesty in saying you're not even trying to learn Ajax, but as you can tell, that has an impact in terms of responses. I definitely appreciate the help you've offered others here, but you're going to have to do some work on this one (i.e., be willing to learn some things in the process). What you'd do is a combination of Ajax to update the database on the server and DOM manipulation to make icons appear and disappear as needed. I personally find jQuery the easiest and most reliable way to do Ajax and DOM manipulation these days.

Hmmm...interesting question. Unfortunately, the examples used in the books aren't fair comparatives. With those examples, the goal is teaching certain skills. From a development perspective, it's an artificial starting point. Also, this is one of those places where there's no one right answer. Different people have different approaches and different solutions can work equally well. I can estimate that the second ecommerce example took me maybe a month to develop, although that was while I was writing the book. In the real world, I could have developed that in two weeks, plus another two weeks for testing and tweaking and such, I guess. With actual Web (or other) projects for myself or for clients, I always start with the data: what information will need to be stored, what information will need to be presented? The content always distinguishes one site from another. So I try to find out everything that might be presented to the user and everything that the admin will need to provide and everything that the admin will want to later know (i.e., about what the users did with what). Then I design the database. Let's say that initially takes a week, with the understanding that the database will need to be altered somewhat based upon things that come out of the development process. Then I turn to the Web framework. By that I don't mean an actual framework necessarily, but the basic files and structure: directories, includes, configuration, database connection, etc. Some of those will be fairly final and solid, others will be sketchy to be changed later. A couple of days there to start. Next, I would, depending upon the site, either create the admin interface for populating the database or self-populate the database and work on the public side first. For non-ecommerce projects, most of the work is on the admin side for managing the content. For ecommerce projects, most of the work is on the public side: making it secure, tying it to a payment system, and so forth. After getting the one side done, or mostly done, it's a matter of completing the other side. And making lots of changes along the way. That's how I really work. I will say two things about my own personality here. First, I'm not a designer, so I start with the backend and work my way forward. Someone with better graphical skills might be inclined to go the other way. Second, I'm a little impatient and I need to get my hands dirty. So I never plan things out as far as I should. I plan things out about 70% and then I need to start doing. That's not ideal, but it's how I work. Hope that's useful for you and thanks for the question!

I wouldn't put the song files in the database, just the information about each song. And there will need to be an association made between the song's record in the database and the actual file on the server (e.g., store the file's name along with the rest of the information).

This shouldn't be hard to do, depending upon your skill level. Here's what I would do: 1. Create a database table that records the files. 2. Create a second table that records a file ID, the user's IP address, and a timestamp. 3. For the link to download a file, use a link to a "proxy script", passing along the file ID: download_file.php?id=X 4. The download_file.php script would: A) Add a record to the second table, indicating the file ID, the IP address, and the current time. B ) Serve the file to the user. 5. To display the number of times a file has been downloaded, just do a count for that file ID on the second table. You can add any value you want to this actual count in order to inflate the numbers. That should be enough to get you started. Let us know if you have any questions or problems.

Thanks for the nice words on the books. It is appreciated. In answer to your question, yes, that would improve security, in theory. Which is the same for the session agent. The trick in both cases is that sometimes the ISP (of the user) lumps multiple user's information into one, or provides generic information. For example, at a public library, every computer might have the same agent information (because all computers would be running the exact same software) and every computer might have the same visible IP address. So these two techniques wouldn't prevent someone pulling a trick from the same exact place. But I do think it would add a tad more security, as it limits the likelihood of success from separate computers in separate areas. As another example of using IP addresses, a couple of personal finance sites I use record the IP address that I normally use. If I access the sites from another IP address, secondary security questions and approaches are used to verify it's me.

First, I would consistently use either fid or id. Right now you assume $_GET['id'] but assign this to $fid. Second, you have code that only creates $fid if $_GET['id'] is set and numeric, which is good, but your code later in the script attempts to use $fid in a query whether or not it exists, which is bad.

I think part of the confusion comes from these things being context sensitive. If you could provide examples of where, say, I use $uid and where I use '$uid', I could explain that in particular. Again, context matters here, but in terms of PHP variables in queries, the most important thing is that your query uses double quotation marks or uses single quotation marks and concatenates the variables in. You must wrap arrays in curly braces if it's an associative array. Indexed arrays do not need to be wrapped. I wouldn't say you should always use them, as that's just tedious and unnecessary, but I appreciate the attempt to be consistent. Second, there's the issue of values in MySQL queries, which is separate from, but affects, the use of PHP variables. Numbers and function calls should not be quoted but strings and dates must be. Also keep in mind that there's a difference between what you MUST do and what you SHOULD do. You must quote strings in queries and if you don't, the query will fail. You should not quote numbers, but if you do, the query will still work, just not as optimally.

That would be an alternative solution, and was what I did when writing the book (or working on any new project).

Paul, I LOVE that description. I need to manufacture a picture of me holding up PHP 6. Veruna, I've written about this in my blog (and on Amazon), but filling out what Paul wrote, PHP 6 was being developed when I wrote the book, so I used a development version of PHP 6 to write the book. To be fair, only about 5% of the book requires PHP 6. And, actually, I think all of that 5% can now be done with PHP 5.3, because, as Paul mentioned, many features intended for PHP 6 were folded into earlier versions.

Thanks for the nice words, Lou!

Thanks for sharing your experiences so that others might benefit.

Thanks for the nice words. I'd be curious to see what PayPal says.

I've used SQLite, although not with PHP. It's an excellent database application, but for smaller scale applications. I've used it for desktop applications, with an integrated database. It's actually the most popular database application there is, as it's on most OSes, mobile devices, and so forth. Very easy to use and work with.

Thanks for the nice words. Your BASE_URI and BASE_URL values are fine (kudos). Your absolute references such as /css isn't working because the css directory isn't at the root of the Web site; it's at /ecom2/html/css. Because your site isn't at /, you'll need to change instances (in HTML and CSS) to initial / to /ecom2/html/ Also, your relative references, such as ./css and css/ will work for the index page, but won't when you get to the browse and shop pages, which act as if they're in subdirectories (because of mod_rewrite).

Yep, you should be good that way.

This seems a bit strange to me. I've never been on the PayPal business pages, if those actually belong to PayPal. It's got a valid certificate, but the address of the registrar is different.

Hey Josee, Thanks for the interest in, and nice words on, the Ruby book. I'm glad you like it. I don't know of any incompatibilities, but included versions of languages in OSes tend to be behind. Yes, XCode does cost money now, but it's $5 (US) in the app store, so not significant. It sounds like maybe you want to install Linux anyway. If that's the case, then go for it. Otherwise, I'd be inclined to buy the latest version of XCode and then install Ruby on the Mac.

If I understand your question, that is correct.

You could serialize the object, but I think it'd be easiest and most foolproof to just store it in a session.

There's really nothing special here at all. Just treat it like any other array and treat it like any other property.