GizmoLA.com

One of the first things people learn about using subversion is how to do a "checkout" using svn co. The svn checkout command pulls files from the subversion repository into your "sandbox" and in so doing creates what subversion calls a "working copy". A working copy includes a .svn directory in every subdirectory of the working copy, which is chock full of directories and files that svn uses to determine what you're doing in your sandbox.

A "working copy" is designed to be just that -- a copy of the source tree built with the assumption that you will be making changes and committing them back to subversion. But what do you do if you want the files, but you don't need or want a sandbox?

Continue reading "Get files from subversion without creating a sandbox using svn export" »

The MySQL timestamp is an oddity, being both a mySQL "Data Type" as well as a type of specialty column that provides a built in default. It doesn't help matters, that the timestamp was changed significantly around mysql version 4.1.

The Old TIMESTAMP

In older mysql versions, the TIMESTAMP was not in the same format as a DateTime column, and you could also set up truncation by defining the TIMESTAMP to have a fixed size. For example, you could define a TIMESTAMP column to be a TIMESTAMP(4) which would then only store the 4 digit Year portion of a DateTime value. I won't go into much detail on the pre version 4.1 TIMESTAMP, however, if you're stuck with an older version of MySQL I recommend you read the manual carefully before you attempt to use any of the information here. I'm going to concentrate on the current TIMESTAMP.

TIMESTAMP Properties

At its most fundamental, the TIMESTAMP is really nothing more than a Unix TimeStamp, which is to say, that internally it is stored as an integer value of seconds. Where a MySQL DATETIME column can be used to store any date and time from Jan 1, 1000 to 12/31/9999, the TIMESTAMP is limited in the same ways that the Unix timestamp is currently limited -- it can only store values from Jan 1, 1970 to Jan 9, 2038.

Those familiar with Unix design, will recognize the Jan 9, 2038 date as being the next big "Y2K" computing panic, and if you're young enough, you may realize a large payday in your future, selling remediation services to companies in roughly another 28 years. The folks at http://www.y2038.com/ are already estimating this to be as much as a 10 trillion dollar jackpot, although no doubt by that time most of the coding will be done by the Morlocks from their underground cave cities. Outsourcing of IT to Morlocks will be a major industry trend by the year 2020, mark my words.

Continue reading "Too much information about the MySQL TIMESTAMP" »

You can't add to Null

Here's something about mysql create table definitions that can easily catch you if you aren't careful. Consider this table definition:





What the user wanted was a simple table to keep track of user submitted screen shots. Of course the real table had a submission date, and name column but I've omitted those in order to focus on what can happen when you allow a numeric column to have NULL values.

In the application in question, when a user votes for the screen shot they like, the system should "count" the vote, by increasing the values in the "votes" column by one. Initially the developer working on this application was trying to read the value from the database, and in a PHP web script, they would increment this value and take the result and set "votes" to be equal to it in an UPDATE statement. I explained that this could cause lost votes, because if two or more users were voting at nearly the same time, each would overwrite the value of the "vote" column. In fact there are scenarios far worse than that --- a user with a cached page could vote and set the vote count back days or weeks. I didn't bother to mention the possibility that someone might recognize what was going on in the web form, and start tampering with it, since it was plainly evident that the form was passing the current number of votes.

One of the many benefits of using a relational database is built in concurrency. In an UPDATE statement, you can add to the value of the column without having to know what its original value is, just as computer languages allow assignment to a variable that references the variable's current value (ie. $a = $a + 1, $a++).



All that's needed is to have the serverside language provide a value for a particular "id" and the votes will be tallied and updated correctly. Even more importantly, mysql will serialize the updates, insuring that no votes are lost.

However, given the original Mysql CREATE TABLE statement , what will happen if our code embeds the UPDATE statement provided?

Continue reading "Mysql Update: Null + 1 is Null! " »

Here are the slides for the presentation on subversion I gave at the September 2008 LampSIG meeting. I hope some may find them useful, however they were meant only to provide a skeleton for the talk, and aren't a complete tutorial by any means. The following links to other sites were mentioned in the talk:

The Red bean book, aka Subversion manual
The svnmerge python script
Subversion tips Article
Subversion Cheat Card

A few years ago I published a 3 part LAMP tutorial series entitled LAMP, MySQL/PHP Database Driven Websites on the well known php community website PHPFreaks.com. This series dealt with a slew of practical issues including how a LAMP server works, relational database design using MySQL, many to many tables, SQL inner and outer joins, practical PHP debugging, php documentation tools, basic PHP classes, css, interactive javascript & DHTML with a chooser widget, php HEREDOC and php basics like how to process forms and utilize GET and POST methods.

The series was fairly successful, (a 4.5 of 5 after hundreds of ratings), many pages of comments and questions, and page views to the 100k's+ although PHPFreaks auditing system was turned off at some point and stopped recording views.

Unfortunately, some years ago PHPFreaks.com suffered some fairly catastrophic issues with its publishing system. There were also some bugs, and the site was exploited with some XSS, and the admins simply decommissioned the majority of the site. My series was part of what disappeared. At that point, a couple of college Computer Science courses on web development had taken the series and integrated it into their curriculum, and the professor of one of these courses had converted it into a Word document, which I was able to download and convert to pdf.

I plan to write a compatible publishing addon for gizmola.com so that I can take the original markup and republish it here, but in the meantime, here is the series in pdf format. The conversion utility they used stripped out the original markup, and page breaks are gone, but the text, source code, and illustrations are all still there.

I also offer all the source code for parts 2 & 3 of the series. I'm not sure what happened to the source for part 1, however, it is all included inline in the tutorial. The LAMP, MySQL/PHP Database Driven Websites series is now available in pdf format. Click here.

I have a small phpBB2 forum attached to this site, that I used briefly to support some of my side projects. phpBB has had a checkered past in terms of security, having been the victim of many exploits. To be fair that's one of the costs of having been one of the first and most widely successful php based community projects. The number of phpBB deployments is staggering even to this day. With so many forums out there, spammers quickly figured out that if they could write a bot to create an account and auto post messages, they'd be able to spread their spam messages far and wide. I was getting so much spam, I ultimately disabled the ability of people to authenticate their own accounts, and despite this change, still see as many as ten new signups for the forum every day. Who would bother to sign up for an account they can't use? There had to be a way of determining the bots from the humans who wanted to post to my forum.

CAPTCHA, as the conventional wisdom of the day was concerned, would provide a useful deterrent to this annoyance -- bots arent' smart enough to decipher the captcha images and extract the right combination of numbers and letters depicted in the image, and type them back to into the form in order to unlock the account. Without the account, the spammers couldn't have their bots post their spam messages. While phpBB introduced a CAPTCHA capability relatively late in the game, it is now something you get out of the box, and there is at least one mod that improves on the quality of the CAPTCHA image, which is to say, makes it harder to read.

The problem is that CAPTCHA's are there to defeat dumb machines, but not dumb humans. And as the old saying goes, there's a sucker born every minute who is more than happy to help your local spammer defeat the CAPTCHA image on your site. How might you ask? Well, the scam works something like this: John Q. Sucker visits some site that informs him he's getting something for free -- it could be a free ipod, porn, or an xbox 360. All that is important is that this person believes they will be getting access to this free stuff once they register.

They visit the spammer's site, and are presented a CAPTCHA image in order to register, only, this image didn't come directly from the spammer's site -- it came from YOURS. The spammer writes a simple bot that goes to your site and hits the registration page. It takes the CAPTCHA image your site provided, and presents it to John Q. Sucker on the spammer's site.

Continue reading "CAPTCHA busting -- A sucker born every minute" »