Sherif's Tech Blog

Just another guy on the Internet with a keyboard…

Category Archives: PHP

What Programming Language Should I Learn

So you want to start learning a programming language? The first question you might have is what language should you start with. Unlike when we’re born where we don’t get to pick the first language that we’ll start learning to speak, read, and write in – in the computer science world you have a choice. However, as a programmer you have a vast array of languages to chose from and sometimes I find people ask me “which is the easiest?”

The truth is whoever you ask will tell you their language is the easiest, best, most powerful, or whatever reason they can think of for you to learn and use that language! As a joke I posted this video on youtube along with others about individual languages, but this one seemed to get the most hits. Is it that people are very inclined to find the one ultimate programming language or just laugh about the rest? Who really knows, but it’s funny…

This is kind of like asking a multilingual person which language they think I’ll find the easiest to learn. While there may be some valid answers, most of them will probably be subjective and they won’t answer the true question one should be asking. That is, what am I going to be using the language for. Just like when you decide to learn French, because you’re either moving to France, or would like to communicate with someone who speaks French, similarly, you pick a programming language because you would like to communicate with a computer in a way that meets your objectives. What you intend to do with the language, and what it can do for you, however, may not always be so apparent at first.

I only recently realized how truly complicated it may be for someone who does not come from a programming or technical background to actually chose their first programming language. Having recently examined a massive comprehensive list of programming languages on wikipedia I found that there are currently over 600 programming languages to chose from and that doesn’t even include the more than 300 dialects of BASIC and some other various esoteric languages. This also probably doesn’t account for some of the lesser-known dialects or derivatives of some of these languages. Since not all programming languages have an official specification they very well may be implemented in dozens of different ways in smaller niches.

If we look at programming languages broken up into categorical or even chronological lists the information still doesn’t help make the choice any easier; or even more useful. However, if you simply attribute languages to their strongest generational origins you can narrow the list down to just a few dozen languages. If you take away some of the older generations and put emphasis on those languages highest in popularity and active use/development you come up with just a few languages and their respective dialects. However, this still isn’t informative enough to help someone decide their first language so I split up languages based on their strongest usage and in the world of computer science this comes down to two broad categories (systems programming and utility or application programming). The most notable distinction between these two types of programming is that systems programming aims to provide software to communicate with hardware while application programming usually aims to provide software for the user that’s sitting at the computer. So while software like a text editor or word processor is considered application software, software like a disk formatting/partitioning utility is considered systems software. Your operating system has to deal with the hardware in your computer directly in order to provide application programs with a means to do things like write to your computers memory while the operating systems page table and memory manager can control how this hardware is being used by the various application programs.

C

By far, still one of the most popular programming languages still around and even though it is still used by many to develop application software it hasn’t lost its popularity or its power.

C is not a language you usually pick to write every-day utility applications. If you chose to start learning C be prepared to start learning a lot of other systems programming concepts and technical hardware documentation as well. Most Computer Science majors take C as one of their first programming language courses in college. This is important, because there is a huge amount of software that’s written in C. For example, most operating system software is either written in C. There may be some C++ in there, but for the most part you’ll find a lot of linux distributions are made up of a huge amount of C code and much smaller portions written in either C++ or some other similar language. You may hear about Assembly language as well when learning or working with C. Essentially, when a C program is compiled into a native binary and run as an executable program it is technically transported to Assembler. You take a high-level language like C and, eventually, to get it to run on the machine it has to become low-level software in bytecodes the machine architecture can execute. C is still a high-level programming language, but it has also been recognized for its lack of agility in relation to programming languages like assembly which is a low-level programming language. Don’t let this confuse you, however, C is a powerful language and in fact many of the popular languages you will likely hear about or discover in this article were written in C. For example, PHP, Python, and Java are languages whose APIs and extensions were written in C.

However, C can be tough. Writing non-buggy C code is costly. It can take a lot of time, because you either have to find the libraries you need and implement them or write them yourself. C is a procedural and somewhat imperative language. It also teaches concurrent programming and programming with side-effects, which is very different from languages like Scheme where you program without side-effects. C programs are like one big global scope where everything can effect everything else. So you have to be very careful about managing your memory in C. You have to worry about pointers and references and data types everywhere in your code. You have the basic constructs like IFs, and loops, and functions, but ultimately you have to learn to do a lot of things other programming languages can make a lot easier, because they already have extensions that implement a lot of these popular C libraries built right into the language.

So, unless you plan on designing an API for a larger program or build some system utility C may not be the right language for you to learn. If you’re a compsci major you’re probably going to learn it as your first language whether you want to or not, but lets face it you chose the degree…

BASIC

BASIC has been around for quite a while as well and it has hundreds of dialects. It was popularized by many hobbyists during the 80s and grew further in popularity on Windows during the 90s with Microsoft’s Visual Basic suite that attempted to keep the language as simple but as powerful as possible. BASIC is not very difficult to learn, but it is also a compiled language like C and has declined in popularity over the last decade. It might not be the best language to work with, but it is still high on the hobbyists list. Much like languages that were once popular to learn just as a hobby and were fun to play with (like LOGO which was a dialect of LISP) not many people take it seriously.

BASIC has the essential control structures you’d find in almost any language like IFs, loops, and GOTOs, but it was fundamentally built on the concept of sequential programming where the entire program is built on one huge sequence of instructions. There are subroutines (like functions) and some dialects implement a lot of other modern features, but for the most part it’s great for when you want to learn programming for fun. If you’re serious about building cross-platform or enterprise-level applications BASIC is far from a first choice.

Java

Java and its other Java-based languages stand out for their compile-once run anywhere trait as opposed to many other compiled languages where you write the code once and then have to compile it for each different platform you chose to run it on. With Java, if you chose to compile your code to Java bytecodes to run in the JVM you will only need to compile it once. The JVM (or the Java Virtual Machine) can pretty much run on any platform (Windows, Linux, MAC OS, etc…) and works with the systems hardware directly through its VM. This enables programmers to be able to compile their Java code on any machine just once and it will run on any other machine in virtually any platform without having to recompile for that specific platform. Java can also be run in JRE (or the Java Runtime Enviornment) so it works as an interpreted language as well. Java’s popularity hasn’t declined much over the years and it’s gained quite the reputation with later adopting open source initiatives.

Java is also popularly taught in compsci courses in colleges, institutes, and universities around the world. It’s similar to C in that it is a statically typed language and has functions and basic loops and other constructs. However, Java is an object-oriented language. C is pretty much procedural in paradigm. You can build structs and things in C, but Java makes abstraction a whole lot easier with its OOP features. You can get a whole lot more done in development in a fraction of the time it might take you to do the same in C. So developing day-to-day applications in Java is a lot more common than with C. It’s just that a lot of the folks that have learned C and know it well have stuck to it over the decades and continue using it. Java is a much newer language. It appeared around the mid 90′s, but it has proven itself in the last 16 years or so. C has been around since the early 70′s and hasn’t changed much. The most current standard of C is C11, its predecessor was C99. Java is at Standard Edition 7.

Java is also considered a fast and secure language for a number of reasons. It is skeptical whether or not all of these reasons hold true, but for the most part they’re built on some solid grounds. First, Java code runs in the JVM, or the Java Vritual Machine, which means the VM can check the compiled bytecodes of the program and make sure they’re valid Java bytecodes before running or executing the code. Second, Java code is cross-platform so it easily translates to the same machine code across different platforms without much concern over the implemented libraries. Java is expected to be very performant because of its JVM. This means your Java programs run directly in a virtual machine that sits on top of the hardware layer allowing direct hardware implementations and interfaces as opposed to some other VM concepts where the program runs in the VM that runs on top of operating system or its implemented libraries that runs on top of the hardware. There’s somewhat of a more direct interaction there. Between Java and some other scripting languages like Perl, Python or PHP – this might be an advantage, but between C and Java it can go either way. In most cases C would easily out-perform Java, but in a few cases it might go the other way around.

PHP

PHP is probably the most popular language on the web. It has many followers and a huge open source community. It’s an interpreted language that was originally developed for producing dynamic web pages. However, today it is seen as a general purpose language. What makes PHP so great is that it works very well with web servers. You can install it as a web server module or run it on the command line. It has many useful built-in features that make web development easier right out of the box. PHP is also built on share-nothing architecture so it scales very easily and doesn’t require much configuration. It offers automatic memory management and it’s somewhat loosely typed so its data types may not be very suitable for edge cases, but that can be debated. For most general purposes PHP works great, but like BASIC it attracts a lot of hobbyists given that it lowers the bar of entry.

Unlike with C, in PHP you do not have to worry about managing your own memory. You can easily build data structures, facilitate external resources to databases or other libraries directly through the PHP extensions, and generate output to standard streams without a lot of fuss. It’s easy to take a general idea and implement it in PHP very quickly. Most people do this with Python and Perl as well to get a working prototype up and running. However, if you build a lot of prototypes, you know that they end up getting tossed out when you start building the real thing. Regardless, PHP is a great language to get code working quickly and very similar in syntax to languages like C and Perl. However, the down side is that these languages are also considered very ugly and have many extensions with poor implementations or interfaces or leaky memory. Not everything about PHP or Perl is great, but it works. At the end of the day it takes a fraction of the time to write PHP or Perl code that would do the same thing in languages like C and with less possibility of bugs since these languages are usually very forgiving and try to account for user error where possible.

PHP is extended by C and is built around the Zend Engine, which is the PHP Virtual Machine. PHP has different SAPIs, or Server APIs, for different web servers and platforms. Among the most popular are probably the Apache httpd module, which is known as mod_php and the fastcgi /fcgi SAPIs. The difference between the two is basically like running PHP inside your webserver as a part of the webserver program (mod_php), and running another program along-side of your webserver that interfaces with it through a CGI (Common Gateway Interface), which is what the cgi/fastcgi SAPIs are built around. There are lots of different implementations, but the module running as a part of the webserver usually trumps the others in performance and scale. PHP also has a CLI SAPI, which allows you to run PHP directly from the command line. You could use this to build command-line scripts like the popular BASH scripting language, on *nix shells. However, most people don’t use PHP to build command-line programs. It’s not the most performant programming language, but it works well for things like the web where you want to build dynamic websites or applications. Just tiny programs that execute for a very short period of time and run independently of one another. When you look into building things like long-running daemons, you usually turn-away from PHP and head for languages like C or even Java.

Other General Purpose Languages

There are many languages considered for both web development and as general purpose languages that are also dynamically or loosely typed and offer automatic memory management and even web server modules just like PHP. Languages like Python, Perl, and Ruby are also exceedingly popular and quite similar to PHP in many ways though they are not all based on the same generational languages. Of course shell scripting is also going to fit under general purpose in most cases and so Bash, sed, AWK, etc.. are also great languages to know.

To some people’s surprise, javascript is now becoming somewhat of a general purpose language itself. Recent VM implementations like Node.js make using javascript faster and a little more powerful than some of its earlier ancestors. One of the best things about javascript is it’s non-blocking nature and event-driven capabilities. It’s a great language for automating event-driven tasks by setting up listeners and such. It’s got a lot of uses on the web and offers multiple paradigms as well.

Beyond

Beyond just looking at what all of these programming languages can do for you it’s important to realize one language isn’t always enough to do what you need. If you’re going to start learning a programming language it’s easier to pick one that won’t require a lot of time to setup and configure. Something llike Python or PHP or even javascript is easy to just install and start writing code and the best part is you can just run that code instantly without having to compile anything and see the result right away. These languages aren’t very hard to learn because they have a lot of free online resources, documentation, and a lot of people already use them so you shouldn’t have too much trouble finding quick tutorials or examples of code that show you how to write short and useful programs. But of course your mileage may vary!

Over time, when you have learned your first programming language very well you may find the need to do some things that aren’t always very easy or even possible with that language (or you may never experience this depending on the language and what you’re doing). This may lead you to start using another language in place of or along side of that language for a similar project or a different project. If you’re a hobbyist doing this for fun you might not be so inclined to learn more languages, but if you’re a professional you will probably need to learn many languages over the years. It doesn’t hurt to have a long list of programming languages on your resume for a job and it certainly won’t hurt to already have some experience with a language you’ll be using on a new project at work. However, most programmers will be quite proficient in just two or three languages and have some overall understanding of others. This is usually all you need in the majority of cases.

WebSockets – Making The Web More Useful

As of the date of this document (October, 2011) the WebSocket protocol has about 18 versions of the ietf-hybi draft. The hixie draft actually has around 71 Internet drafts since the first one in January of 2009. So in less than 3 years there must have been nearly a hundred drafts to this protocol with virtually every main-stream browser providing some different implementation of the spec. The earliest support offered for the WebSocket protocol in Chrome, Safari, FireFox, and Opera have actually been disabled by default in FireFox 4 and Opera 11 and Internet Explorer only has support through HTML5 Labs, which is just a prototype. Microsoft plans to offer better WebSocket support for future versions of IE with the new revised hybi-10 draft, IE10 is the planned release. If that weren’t enough the Gecko-based web browsers 6-7 implement the WebSocket API objects differently requiring developers to write extra code when integrating with existing WebSocket code. Still, it doesn’t even stop there… You now have to worry about the iOS mobile Safari browser (for iPhone) and the BlackBerry Browser in OS7 and how they support WebSockets as well. If it seems like this is all very messy it’s only because it is!
The web started as a place to make information more easily accessible by being able to do simple – but very logical – things like Hyper-Linking. Every document on the web should be able to link to any other document on the web regardless of domain or origin. That’s useful, because it makes information more accessible and efficient. However, today we spend the majority of our time trying to get automated scripts and tools to do most of the information processing for us so that we can ingest the processed information in bite-sized pieces that are easier to swallow. Much like how many of us have become accustomed to the processed meat we buy at the grocery store this is become rather second-nature. The only problem with that is the web was never designed to be this powerful. It doesn’t supply us with the right tools to do many of the jobs we expect it to do today. We simply never envisioned that one day the world would be running Software As a Service as we do today and probably wouldn’t have guessed that the World-Wide-Web was going to be the platform for all of this. The browser — once seen as a window into a strange and unfamiliar part of the Internet — has now become the corner-stone of the PC. We spend more time than ever before inside of our browsers doing many things we were once used to doing outside of the browser. Like playing games, chatting with friends, writing word documents, reading books, watching videos, editing and browsing photos, and much more. The world is now a much different place with the browser being at the center of every computer screen. Disconnect someone from the Internet and all-of-a-sudden their computer feels inert or even incomplete.
How the web works today and how it’s basically worked for the past 18 or 19 years is very simple. Your computer opens something called a TCP socket that connects to a remote server and on the other end the server is listening on a specific port for incoming requests. Once a request is received it processes the request according to a defined spec (called HTTP) and sends back a reply and the connection is terminated on both ends. There is no persistence layer. There are no negotiations to be made or handshakes to be exchanged between the client and the server. It’s all very simple and the protocol name says it all — it’s in plain text because it’s Hyper Text Transmission Protocol. The request may come from any client to a single server or from one client to multiple servers. It doesn’t matter. Each request is independent of every other request and every request must illicit a response. So there’s virtually no complexity in how this protocol can scale. We send off a request, wait for a response, and both the client and server part ways forever. That is, of course, until the next request is made.
To use WebSockets you need to write both a server and client. The client can easily be written in javascript using the WebSocket API (for WebSocket protocol capable browsers). The client can also be written using flash sockets as a fallback or even through long-polling if neither WebSockets or flash are available on the client machine. The server can pretty much be written in whatever server-side language you’d like. You can take your pick from any of the popular server-side languages like Python, PHP, Perl, Java, etc… Now you can even write one using javascript with node.js. I chose to write one using PHP and only implemented WebSockets (so there is no fall-back support for my example, but it works with most mainstream browsers like Chrome, FireFox, and Safari).

You can see a working WebSocket example here…

For some sample code on how to write a socket daemon in PHP you can see my PHP chat server example here as well.

This example basically uses WebSockets to implement a completely web-based chat in the browser. Each user that connects can send a message to the chat room and the message will be relayed to all other users currently in the chat — in real time. There is no database required on the server-side and no nasty long-polling done on the client. The TCP socket is a two-way pipe in full duplex that allows either party to send and receive messages at any time. The client doesn’t have to wait for a response to send the next request and the server doesn’t have to wait for a request to send the next response. It was easy enough to write the daemon in PHP and get it up and running quickly as an example, but you will need to review the specifications of the WebSocket protocol carefully and find a way to implement it that will work for your specific needs.

A useful full-blown framework you can use to help you implement most of this is socket.io but keep in mind if you’re going to be writing the server in a different language (not using node.js) you’ll want to understand the implementation well since it varies wildly and requires fall-back methods incase the client doesn’t support WebSockets.

How To Build A Photo Sharing Application On The Web The Right Way

Personally, as a web developer, I’ve come across a number of clients that seem interested in doing some sort of web-based photo sharing application like flickr, or imgur, or photobucket. These are all pretty popular services on the web that allow you to share your photos with friends, family, colleagues, etc… They seem to be extremely popular and there’s no doubt that it’s evident people love sharing their photos online. Just take a look at facebook; possibly the world’s largest online photo sharing application that claims to get over 100 million uploads per day from it’s now more than 800 million users. With cameras found standard in such personal devices as phones, notebook computers, desktop computers, various other hand-held devices, and even (and don’t ask me why) TVs it’s no wonder we find it easy to store lots of digital photos and inevitably share them with others.

So I had to think long and hard about how I’d build an application or service like this so that it made good use of photos and made them easier to share and more accessible. The first thing that came to mind was checking out all the features these other services already had to offer and how they put them to good use. flickr allows you to do stuff like geotagging where you can tell people where the photo was taken. I remember either facebook or some app I may have tried a long time ago being able to do this as well. Since I log into my facebook account maybe two or three times a year I couldn’t say for sure, but what I do know is that facebook certainly got one thing right and that was not taking their users’ demand in wanting to share photos with friends for granted. When you’re able to point out who is in your photo that makes the information just that much more valuable and apprises the application for making photos more useful and accessible. There’s also a search value in tagging. But it can be pretty boring for a user to have to sit there and manually enter in all the information about each photo so we can rely on things like Exif where embedded information about the photo can be extracted by computers. You can get such information as GPS coordinates of where the photo was taken, a time stamp of when the photo was taken, the camera make and model that the photo was taken with, whether not the flash went off when the photo was taken, and even various other things such as focal length, exposure time, shutter speeds, etc… You can learn a little more about the Exif specifications here. However, keep in mind that not all cameras provide this format and not all of them are equipped to provide all of the different parts in the Exif header. Newer phones like the iPhone 4 are GPS capable and can embed GPS data into your photos if the GPS is turned on. There are also many digital cameras that either come with GPS devices embedded or can be purchased separately. Some other features you might want your application to have to make the process of having the user input information about each photo easier is facial recognition. This doesn’t have to be so sophisticated that it can automatically detect faces found in other pictures and tell you who’s who, but it can be helpful to let the software detect if a face exists in the photo and highlight it so that the user can simply type in who each person is for tagging purposes.

There are also some potential uses that I’ve found for OCR (or Optical Character Recognition) in photo sharing. If you can manage to extract enough significant textual data from the image you might be able to make certain aspects of search easier to locate photos. This is probably not going to be easy given that what little time I did spend fooling around with various OCR software proved that it has many setbacks and is clearly in the very early stages of development. Mostly OCR has trouble detecting text if the font size changes through the image, if the text encounters large skewed angles or if the text is rotated so that its orientation is not top-to-bottom and left-to-right. It’s also difficult to detect hand-written text, or text surrounded by other images, logos, or with too much depth or noise. There’s also quite a challenge trying to detect text written in various languages that don’t use the Latin alphabet. If it’s not a scanned image coming straight from the page of a book using a single evenly-spaced sans-serif font, with a fixed font size of around 12-20pt it will prove rather difficult to get any decent results from the OCR software.

So to give you an idea of what some good features of a photo sharing application might look like I put together a small working demo. My example makes use of most of the features I’ve discussed here, but leaves much to be desired, of course.

You can see the working Photo Application Demo here.

Here is a sample photo with embedded Exif information including GPS to demonstrate.

Here is a sample photo that demonstrates the applications ability to utilize some OCR techniques.

A Note About User Experience

OK, so I wanted to make sure this demo illustrates some of the basic functionalities a user might expect in a photo sharing app. The first thing you’ll notice is that uploading large photos and especially a lot of them can be a boring thing to do over HTTP. That’s because HTTP is built on a request/response model. You have to send a request first and then you eventually get a response back. Now if your request happens to be a 10 MB photo or even worse a 250 MB video (or even worse you don’t have high-speed Internet or your ISP offers lousy upload speeds) well… that’s a long wait with no indication at all to the user as to what’s happening on the other end. What’s even worse is if the user is uploading a file they aren’t aware is too large for you server to accept that can be a lot of waiting around for nothing. So I used some javascript combined with a script I found online at phpfileuploader.com and with a few modifications for security and improved user experience I hacked up a somewhat better interface for the user to deal with uploading multiple photos.

One thing you don’t want is to prohibit the user from being able to do anything else while they’re uploading their photos. Pop-up windows are just annoying, in my opinion at least, and forcing the user to wait until the entire upload is done before they can do anything else in the window is even worse. So if you try out my demo you can see that it doesn’t prevent you from browsing other photos on your computer to select for upload even while it’s doing the uploading simultaneously. You can even cancel an upload mid-way or cancel all pending uploads at once. It will also alert you ahead of time if you’ve selected too many files at once or if your images are too large or of the wrong file type. However, not all of these features are entirely reliable for security reasons as the user can easily bypass them. But they are their to improve the user experience. All the real security work is actually done on the server side. Even if you were to rename foobar.exe on your computer to foobar.gif and managed to upload it the server will still detect that it is an incorrect MIME type and reject the upload. This can be done relying on PHP’s File Info extension where it can check the file’s MIME type from the server’s supplied Magic MIME file.

Now, keep in mind that tracking the progress of the upload is just half of the battle. There’s also the part about viewing your photos after you’re doing uploading them. In my demo I used a javascript library called easybox which is based on the lightbox framework, but it plays nice with jQuery and seems to work a lot more smoothly in my opinion. You can download easybox from Google code and try it yourself. On the top right hand side of my demo where you see your gallery you can click on any of the thumbnails and it will use easybox to nicely let you view all of the photos in your gallery in a slide-show fashion without ever having to leave the page. You can also, of course, easily get a permanent link to each of your photos to share with others from the list of recently uploaded files below that. Your session will expire after 30 minutes of inactivity, however, and you will no longer be able to delete those photos. If you have cookies disabled you won’t be able to see what you’ve uploaded, but your photos will remain on the server indefinitely.

A Note About Using Javascript or Flash

One thing I wanted to point out was that your applications should definitely work better with javascript or flash or even Java Applets or whatever client-side components you may want to use to improve the functionality and user experience of your application. However, you should also consider that if your applications can’t work at all (if even with a degraded user experience or a limited use of features) then you’re not degrading your web applications in a graceful manner. In my demo, for example, I made sure even though I’m using a lot of javascript and even some flash to make the upload process a lot more user-friendly you can still use the application even without the javascript or if you don’t have flash installed. You can test this yourself and I even tested it on the Links web browser (which is a completely text-based browser with no javascript capabilities) and I could still manage to uplaod my photos and download them just fine with zero problems. This isn’t always possible, or easy, for every application, but it’s definitely a good idea to at least put in the effort to gracefully degrade your applications so that they can be somewhat usable to browsers of lesser capabilities. I even managed to get it to work on my phone (a Samsung) which is a pretty horrible phone with an even more horrible browser, but hey having a bad user experience is still better than having no experience at all.

A Note About Links

So I wanted to emphasize a little on how the link structure of an App like this should work. One thing is you certainly want to be able to provide permanent links to the uplaoded photos so your users can share their photos with others. The link should be as short as possible. If your links are 500 characters long it’s probably not going to look that great when you paste them in an email or an IM window for a friend to take a quick look. However, facebook and flickr don’t seem to mind too much about how long the link is. I do have to point out, however, that they probably store billions of photos and my system would certainly not scale for them. With that said in my demo you’ll notice every photo gets a random five character alpha-numeric (case sensitive) link that is directly pointing from the application’s web root. This is the same system imgur uses for their gallery links as well. Except that I noticed a few deficiencies in their method. For one thing they don’t seem to care much about the extension you use to directly view the image. For example, if I upload an image to imgur I might get a link that looks something like http://imgur.com/abcde which would give me a web page with my photo and some information about it (much like you see in my demo) and the direct link to my photo would probably look something like http://imgur.com/abcde.jpg or whatever the file extension was. However, if I were to visit http://imgur.com/abcde.gif or even http://imgur.com/abcde.pngabc I would still be able to see my image. However, I can’t go to http://imgur.com/abcde.exe because that seems to give me an image stating the requested image was not found or has been deleted. Upon some investigation I noticed that their servers return the Content-Type header based on whatever the extension you supplied is as long as it starts with an extension they accept such as jpg/gif/png but it doesn’t matter if it’s proceeded by anything else. This is actually pretty bad, because the file still comes back with the same exact MIME type I uploaded it in. So clearly they aren’t providing the same image in various formats just conforming to some loosely thought-out rewrite rules. Basically I have similar features in my demo where the webserver (in my case Apache) uses rewrite rules and conditions to verify the requested URL and route the request to the proper PHP script and with a little magic you have access to all of your photos from the webroot even though the image files themselves aren’t even stored in the same physical directory as the webroot on my server. So far this demo has only been up for a couple of weeks from the date of this blog post and at around 1,000 uploads and 30,000 views it seems to be reasonably responsive enough that it proves scalable with a little work. I’m using GOCR for the Optical Character Recognition stuff, which is an open source tool developed under the GNU Public license and you can visit their website here to download it or to get more information if you’d like.

A Final Note About Photos

Well, that about covers what I wanted to say about sharing photos on the web and building applications that can do this nicely. Just keep in mind there is a lot to be done with photos that we are yet to uncover. So be prepared to make some good use of these features in building your own applications. I hope my demo gave you some ideas to work with. They are all feasible and not incredibly difficult to implement as you can see this brief demo only took me a few hours of work to put together and works rather well for it’s purposes. Sorry for the horrible interface though that’s one thing I didn’t have time to actually work on. Do let me know what your thoughts are on this subject and if you have any photo applications you’ve built or ideas you’d like to share.

Using PDO with MySQL in PHP

The PHP community has been making an effort to steer people away from the old mysql_* functions (an extension that is no longer well maintained by core PHP developers) and encouraging the use of newer and more feature packed interfaces like MySQLi and PDO. MySQLi offers both Object Oriented and Procedural style coding; PDO does not and as far as I know there are no plans for that to change. So if you aren’t familiar with the OOP paradigm this is a good time to start in case you plan on using PDO in future development. This helps encourage more modular development as well. This is important where sometimes your implementation details can be hidden. The old mysql extension has been discouraged for developing new applications for a while now and since MySQL is a very popular Database Management System a lot of developers used to the old interface have been giving some push-back about switching. Personally, I must admit that I have been using mysql_* functions for years with MySQL databases and so I can understand some of the hesitation in switching, but I’d like to address some of the benefits and trade-offs involved. At least the ones I’ve found to stand out most during my encounters with other developers this year.

PDO Is Database Agnostic

This is probably the driving point of most developers – at least the one I’ve seen come up frequently since last year. The PDO extension in PHP is nothing more than a means to interface with various database-specific PDO drivers. In PHP the PDO extension supports a vast array of databases like Cubrid, FreeTDS / Microsoft SQL Server / Sybase, Firebird/Interbase 6, IBM DB2, IBM Informix Dynamic Server, MySQL 3.x/4.x/5.x, Oracle Call Interface, ODBC v3 (IBM DB2, unixODBC and win32 ODBC), PostgreSQL, SQLite 3 and SQLite 2, Microsoft SQL Server / SQL Azure, and 4D. This means you can use the same PDO functions to issue queries and fetch data from any of these databases. Some people were a little confused about this at first and seemed to think this implied you would not have to rewrite your SQL. This is certainly not the case. The SQL is still dependent on your database. However, you will not have to rewrite your PHP code should you chose to switch databases or use different databases in the same project or just reuse a PHP abstract database class in another project with a different database. The PHP code works the same way whether I’m using MySQL, PgSQL, or any other database. Obviously my database’s SQL syntax may vary here and there, but I’m not required to do large refactoring of my PHP code.

Now, in all fairness, the likely-hood of having to use different databases in the same project or switching databases in any project are fairly slim. So some developers don’t see this as such a great benefit. However, should that be the case you suddenly find yourself in a world of hurt if your application relies very heavily on the database and you have thousands of lines of code to rewrite. Which is why it makes sense to just learn an extension like PDO and use it everywhere so that you never have to relearn another extension should you start a project that uses a different database than what your existing extension was built for.

What PDO Is Not

Some developers also seem to think PDO is a full-blown database abstraction layer or even an ORM. Let me assure you that it’s not. You can’t actually perform any database functions using the PDO extension by itself. You have to install the database-specific PDO driver to access the database you want. These drivers basically implement the PDO interface and thus you get to use those database specific features as regular functions of the PDO extension. PDO is not a magical solution or replacement for you DBMS. It does not provide a tool for userland it simply provides an access layer in userland. So if you had any of these misconceptions before, now is a good time to get rid of them.

Developers Migrating to PDO for the MySQL Database

If you’re constantly developing with MySQL databases like me you probably either still use mysql_* functions in PHP or have tried or even switched to MySQLi. If you’re one of the few that have taken the leap to PDO great! If you still have a few reservations consider that whoever told you PDO is too complicated or harder to learn or use is lying to you. They may not even know they’re lying, but you ARE being lied to. First of all PDO is no more difficult to use or learn than MySQLi or mysql_* or any of the other database extensions in PHP. The fact remains that mysql_* functions have been in long-standing plans for deprecation and they will deprecate it. Eventually when mysql_* functions are gone you will be in a much more difficult position were you to continue developing new applications with it than if you were faced with legacy applications that still had a great deal of code relying on the old extension.

The truth is the old extension for MySQL is no longer well maintained. You’d be lucky if any of the core developers went back and made any major improvements or fixed any real bugs (should they happen to arise). For the most part the new MySQL Improved extension MySQLi is still being worked on and can expect further development, but with the old extension it’s just not likely to happen. There isn’t anything fundamentally wrong with the old mysql extension. The purpose of this blog post isn’t to knock on mysql_* functions, but rather to encourage developers to explore the pros and trade-offs that an extension like PDO has to offer. This mainly because I feel a lot of the developers I’ve come into contact with that have reservations about switching to PDO seem to have been completely mislead or just never bothered to learn about what PDO really does.

If you’d like a good tutorial to follow on migrating I recommend taking a look at the PDO Tutorial for MySQL Developers from the ops at hash php (##PHP on freenode on IRC). If you aren’t sure about just how easy it is to use PDO with MySQL I drafted up a small working example of using PDO with MySQL here as well. It’s using the MySQL world sample database and both the code and a working example are provided.

One of the first gatchyas you want to look out for is specifying the character encoding for your connection. In my example above I’m using MYSQL_ATTR_INIT_COMMAND to SET NAMES and SET CHARACTER SET telling MySQL to stick to UTF-8. This is so I don’t break the encoding during transport. Of course you still have to remember to specify the encoding to the client upon output, but this just demonstrates how you can go about making sure the connection to MySQL server uses the proper encoding. The escaping rules should be updated accordingly. Remember you had to do this with mysql_set_charset() in the old MySQL extension.

The first thing you notice when you start using an extension like PDO or MySQLi is that when you use prepared statements where you are binding parameters you don’t have to worry about escaping rules that are otherwise more pertinent in the old string concatenation style used to build SQL queries in mysql_* functions. PDO is actually separating the SQL from the parameters bound to that SQL. This not only prevents SQL injection (which mysql_real_escape_string() could do just as effectively), but it makes it easier for the developer to work the user data into their SQL. This an underlying benefit I’ve come to admire very much with PDO.

Why Is the Global State Bad?

It’s very easy to add global states and very difficult to test in them. This pretty much reflects on why the global state is a bad idea in almost any language. However, in the spirit of being focused on PHP we should make a few things clear that are specific to PHP. In PHP functions, by default, do not retain the global scope. There is a very good reason for this and that’s to avoid adding to the global state by accident. Unlike the javascript world where, by default, everything is attached to the global state of the window the script was compiled in PHP actually attaches the state of a function outside of its global context. In order to take variables from the global scope within a function, in PHP, you have to specifically declare the variable using the global keyword. In javascript in order to separate the variable from the global state you have to declare it using the var keyword, which is the exact opposite of the behavior in PHP. However, I’m not going to try drawing comparisons between different languages. Instead let’s just focus on why this is bad in PHP and then you can draw your own similarities to why it’s bad in virtually every other language you may use.

In PHP we have something called superglobals which are still made available within any scope even though they may not have been declared as global in user-land. The superglobals are things like $_POST, $_GET, $_FILES, $_COOKIE, $_REQUEST, $_SERVER, $_SESSION, etc…

Now, why are these overriding the rules of separating function scope from the global scope, you might ask? The reason is simply because they make using the specific web features of PHP easier. The variables themselves are not normally populated in user-land, but actually populated by PHP using information obtained from the SAPI/webserver, in this case. It’s true that you can certainly write to these variables. In the case of using sessions it makes sense that I would want function foo() { $_SESSION[‘var’] = ‘bar’; } to be available in any scope. After all I don’t expect the garbage collector to cleanup my session if I move through different scopes unless I specifically write-close the entire session file. You just don’t ever expect these variables to be different in any scope unless you specifically change them and so they’ve take on the superglobal concept that we have in PHP. So then does this mean they are bad? Not necessarily. Now, keep in mind PHP also provides a feature called register_globals which has been deprecated as of PHP 5.3.X and is highly discouraged. Please see the manual on register globals for more details. Basically, this directive makes PHP code a nightmare as it injects all sorts of variables into your script (and you would have no way of knowing what the variable names will be). It’s much safer to rely on superglobals and this behavior is now deprecated so it would never be on by default in latest releases (expect it’s removal some time soon).

Let’s start with the simplest concept…

Hello World Scripts are Boring!
This is true, but since almost any idiot’s guide to programming (at one point) started by demonstrating how to write your first program in the form of print “hello world!” we’re going to stoop down to this level for a moment to understand something. For those of us who are a little more advance just bare with me, but for those of us who are a little newer to programmer or to PHP this might be easier to relate to.

	echo 'hello world'; // Yay we can haz PHP!
Let’s say I just installed PHP and will write my very first PHP script ever! I want to write a hello world script. So I open a file called helloworld.php and put the following code in the file. I then run the file from my command line to test it out and make sure it works… Guess, what? It works! But, it’s also very boring. So I want to be able to make it say hello <my name> instead.

Now, I modify the same script and by passing my name in as a command line argument when calling the script with ‘php helloworld.php GoogleGuy’ I get to see my terminal greeting me… yay!

	$name = $argv[1]; // We're just going to take the first command line argument passed to the script and use it as a name
	echo "hello $name"; // Even more PHP awesomeness!
OK, but now I get a little more advanced and start writing longer scripts. At one point I find I am simply repeating the echo “hello $name” code in a lot of places. After learning about functions I decide to write a function so that I can reuse this code.

	$name = $argv[1];
	function greeting() {
		return "hello $name";
	}
	echo greeting(); // Outputs 'hello ' DUH! Uhhh, wait... what happened to $name?

Now, we begin to see our first problem. The variable I’m using was actually defined in the global scope and since it’s easy to add to the global scope I had no problem repeating my code everywhere. Quickly I realize the fix is to just pass the variable along to the function so that it can reference it.

	function greeting($name) {
		return "hello $name";
	}
	echo greeting($argv[1]); // Ahhh now we're getting somewhere!

Well, why didn’t we just declare $name as global inside the function? The reason is because I’m actually putting this function in a different file called greetings.php and including it in my actual script foo.php where I will run lots of other code. Now I want to test that it works before I actually include it and simply make calls directly to the function from the global scope. To do this I have to pass something to the function. If I just test it with echo greeting(‘GoogleGuy’); it will still work. If I use echo greeting($name) and $name is defined as $argv[1] then that works too! Now, what if I decide to use this script in a webSAPI instead of CLI? All I really have to do is change the variable used in the function call to $_POST[‘name’], for example. Or I can define $name as $_POST[‘name’] and call greeting($name) each time. The point is I don’t have to worry about which variable I declared from the global scope in my function. This would require me to go back and look at the function definition any time I make changes to the code using this function. What’s even worse is in order to test it I specifically have to make sure that this variable is never used anywhere else in the global scope. So now, the order in which I write my code has an impact on the behavior of my function and as I keep adding to the global state it isn’t clear how my function is being used unless I go back and review the function definition.

So there are two things to take away from this:

  • Easy to add to the global state, which can cause unexpected behavior of my functions
  • Difficult to test, because calling the same function with the same arguments doesn’t necessarily produce the same result (when we’re relying on the global scope)

Now, this is all very apparent and makes one think “well duh, of course I wouldn’t do that in my code,” but in all reality I meet programmers all the time that understand the problems of relying on the global state yet still insist on using singletons in their code. This is the – not so apparent part. Singletons aren’t always bad just like superglobals aren’t bad in PHP, but what you have to recognize is that they do rely on the global state and that could lead to testability problems, unreadable code, and lengthy debugging. These things are pretty interconnected so having one of these problems extroplates the other.

Remember that the garbage collector doesn’t come around to clean up the global scope until after the entire script exits. This is where all your resources, variables, objects, streams, etc are closed and removed from memory by the garbage collector. If you still work with mysql_* functions it’s common to see people simply declaring the mysql connection resource as global within their functions rather than passing the resource to their functions/methods. This isn’t a good practice to get in the habit of. When you get into OOP you learn more about dependency injection and how that makes instantiating your objects easier and more testable, because when you do unit testing of your individual methods you don’t want to spend a lot of time figuring out what your objects rely on from the global scope. In fact, if your objects rely on anything in the global scope their methods will be much more difficult to unit-test and the objects will be painfully difficult to instantiate. If you’re using singletons to work-around this problem and avoid having to figure out scope/path resolution it’s only going to come back and haunt you during testing.

One of the blogs I enjoy reading the most on and around the topic of clean code and avoiding mistakes like relying on the global state is Misko Hevery’s blog who is a coach at Google and has worked for some pretty big players. He does a lot of talks about clean code and you can find a lot of his vidoes on youtube and on his blog.