Web development is heart-wracking work. Sure, it doesn’t much look like work from the outside; to my kids, it looks like I sit on my butt all day, typing stuff into the computer. But beneath that casual veneer lurks the splintery practices of a perfectionist there’s nothing more disappointing than sitting on my butt all day, styping stuff into the computer, only to find out that said stuff just doesn’t work, and I can’t seem to figure out why. To this end, I’ve compiled a small list of tips, tools and tidbits to help you, young Paduan learner, on your way to becoming a rock star developer:
- Download and install lots of browsers. Sure, your page looks OK in Internet Explorer, but how does it look in Firefox? Safari? Opera? Eeach browser renders your HTML differently, and you don’t know what browser your visitor is using. test in every browser you can think of, and then test in a few you can’t think of. This is what is known as Cross-browser Compatibility.
- If you use Mozilla Firefox as your main browser, download and install the Web Developer Toolbar by Chris Pederick. This handy tool lets you outline tables and table cells, display image paths, display hidden form information, and all sorts of other goodness, all right in your browser. This has saved my butt more than a few times.
- Learn what PHP errror messages mean. It’s not always obvious, and often the parser will complain about one line when your real error happened twenty lines above it. This is usually because that one line twenty lines up didn’t close something, and it wasn’t obvious to the parser until further down the road.
- Integrated Desktop Environments are editors that allow you to write your applications in a testing environment best suited for the language in use. My personal favorite is Eclipse, an Open Source editor that, via plugins, serves as a kind of swiss-army-knife code editor. There are plugins for PHP, Python, C, Cobol…you name it. By default, Eclipse is a Java editor, but the PHP plugin features bracket-matching, an outline-view for class files, listing all of your properties and methods automagically, and a testing server–making it my most-used software.
- Google, Google, Google. If you have a problem, more than likely some developer somewhere has had to deal with it. Most of my time as a developer is indeed spent googling around as a way to research errors and problems.
- Join some mailing lists. All of the languages have thriving user-communities; Usenet’s comp.lang.* mailing lists can provide valuable insight into language-related problems (I read comp.lang.php every day). The main PHP site has links to their mailing lists. But be warned: professional developers get crumpy when you encroach on their playtime with questions, so it’s best to Google, Google, Google before you post, otherwise you’ll be greeted with a flurry of barks telling you to “Read the F—ing Manual!”
With these tips, you’ll greatly reduce your development time…and you may even get to keep your hair
July 31st, 2006
Remember a while back when I said that web developers were by nature lazy people? You may by now be wondering how, when someone has to juggle four different languages in order to get anything meaningful to happen online, any developer has time to be lazy.
The laziness of the web developer is the laziness of the programmer in general, and it’s a very special kind of laziness. Programmers are usually fairly bright people, and fairly bright people become bored easily. Routine tasks have no joy for the programmer; he or she wants to throw bits around and knock bytes together and laugh and play. So, in order to get to playtime, programmers put in some extra hours and developed web applications called Content Management Systems.
A Content Management System is an application that provides a web-based interface for all of your content adding-and-editing needs. It provides a framework through which the content of your web site can be managed; the content you enter is saved in a database, and your web page reads from that database. Content Managers take that four-language overhead and provide simple software to make it easy. And, because these application provide a web-based interface, they can be useful for remote collaboration. If you’ve ever used Blogger or Myspace, you’ve used a Content Manager.
The CMS Matrix is a wonderful site where you can get ratings about the most popular and useful Content management Systems, and will prove invaluable to you as you browse around for the best system for your site. My personal favorite is Drupal, which is written in PHP 4, uses a MySQL database, and runs on an Apache server. Drupal has an extensible architecture via free plugins or modules–small packages that allow you to extend the functionality of your system. With these, one can add image and video galleries, re-write ugly URLs to pure Search-engine friendly sugar, or allow your site visitors to create profiles.
One CMS that’s been generating quite a buzz in the community is Joomla!, my second favorite. Joomla! has taken the extra step in ease of use; installing additional modules can be handled automagically for you via the web-based administrative interface. Because Joomla! provides both a Content Management System and an Apllication Framework (a suite of tools to make developement quick and easy), developers have been fawning over Joomla! since its first release.
July 31st, 2006
In modern web development, there’s specialization. When someone says they’re a “web designer,” that means they design web pages. They’re responsible for the look and feel of a web site; the visual aspects of your experience. Web developers are a different animal: these cretins are programmers, and they’re responsible for how a web site behaves. Think of developers as the headmasters at an obediance school for HTTP…
If you’re an adventurous type, you may have clicked on the “View Source” menu item in your browser, and been confronted with a page of odd-looking text. This text is code; to be more precise, what you’re seeing is HTML and maybe some Javascript. So, while the visual appeal of a web site may be immediate, there’s a lot of just plain text that goes into creating that appeal, and usually that plain text is written by developers.
The languages that make the Internet are various and usually suited to one particular task. While what you may see when you view source a page is mostly HTML and Javascript, some web sites process your requests on the server by handing them off to what is called a “scripting engine,” or parser. This is one way developers deal with the conundrum of the stateless HTTP protocol; your requests fire off logic in the scripting engine, and what you see in the browser has been determined by code written in a language specifically for server interaction. These languages are called Server-side Scripting Languages.
What’s the difference between a scripting language and a normal computer language, like C, you ask? Excellent question! I could tell you were bright. Scripting languages aren’t compiled, like C is; no binary executables are created, no blahblah.exe file is written. Instead, scripting languages are designed to be executed in a specific environment, a scripting engine. Examples of popular server-side scripting languages are PHP(my personal favorite), ASP and Ruby. These posts will focus mainly on PHP, not simply because of my maniacal love of the language, but because it is by far the most popular language in use.
PHP stands for “PHP:Hypertext Preporcessor” or something silly like that (what the acronym has stood for has changed over the years, perhaps due to the identity crisis brought on by its explosive growth). It’s an Open Source language well-suited for web development. It can be embedded directly in HTML, which can be both a blessing and a curse; there’s no uglier code to look at than a file of HTML-spiked PHP, or PHP-spiked HTML, no more hideous monster to debug, but this very fact makes development swift and easy. It’s been said that PHP is very easy to learn, but difficult to master, and my own experience with this language has born this out.
PHP “preprocesses” your hypertext (a fancy word for web page). That is, before HTML gets output to your machine, your server request is routed through the PHP engine. PHP handles all the logic of your request and spits the HTML it thinks you need back at you. Ungrateful PHP! With PHP and some scripting savvy (and a healthy sense of Object-Orientation), it’s possible to write multiple-page sites as one file, handling all your needs, from simple page requests to form validation, submission and processing. PHP is an almost perfect toolbox for general web development.
But PHP is a server-side language, and can only do its processing on the server. What if you don’t want to communicate with the server for every interaction your visitors have with your site? Do you really want so much of your visitor’s experience to be about their internet connection? Javascript provides the missing puzzle-piece there. A general-purpose scripting language (there is sever-side javascript, but it’s extremely rare), Javascript is most often used in situations where you don’t feel a trip to the server is wise or neccessary, client-side–validating the fields of an HTML form, for example. Why not just get it right before you send it off to the server?
Now, about that pesky statelessness of HTTP: one way developers have sussed out to deal with this is to use databases on the web. A database is an ordered collection of records, represented most often as tables. Databases have associated with them languages that allow you to perform relational operations on the data within the database–the whole shebang is known as a Relational Database Management System, and the most popular of those animals in use right now is MySQL. SQL stands for Structured Query Language, and it’s actually a more general language for dealing with records: MySQL is a lightweight subset of the SQL language. Databases are not web-accessible; to interact with them, you have to use a language like PHP, through which you can connect to the database and ask it questions.
Thus, in modern web development, Joe Developer is often juggling at least four different languages: MySQL, PHP, Javascript and HTML for example. This is where most of my hair has gone over the years.
July 31st, 2006
Well, you’re wrong. And you thought this was going to be easy…
Before I begin a discussion of Content Management Systems, you need to be familiar with some of the languages that make dynamic web pages possible. But even before we get into that, we have to delve a bit into the protocol that makes the web work: the HTTP protocol.
A protocol is a set of rules that govern the behavior of entities, and in your average web transaction, the two primary entities are your computer (hereafter referred to as the Client) and a remote computer(hereafter referred to as the Server).
As the above diagram shows, when you request a web page via your browser, your machine sends a request to a machine far off in the misty distance(that’s why the Internet looks like a cloud here–LOL). Your machine says to the faraway computer, “Hey! How about you give me this file I want to look at?” The server says, “Well, you have a kind face, so I’ll let you take a look,” and sends the file through the network to your machine. Presto chango, and POW! You’re browsing a web site.
If you’ve ever done any programming before, you’ll likely be asking yourself, “Where’s the memory that holds variables in this model?” If you’re asking this, you’ve hit upon the one limitation of the HTTP protocol; it’s stateless. The protocol makes no provisions as to where information gets stored, and Lord knows you can’t store information in that cloudy Internet out there. That leaves you with two choices as far as memory is concerned; you either store the information on the client’s computer, or you store it on the server.
You may have heard of cookies on the web; these aren’t those tasty circular bits of sweetened dough we all know and love, but tiny text files holding vital information. Cookies are one way to get a web site to remember you; near the login button on most modern websites, you’ll see a small checkbox that says, “Remember me.” What happens when you click this text box? Information about your login gets written to a cookie and downloaded to your machine, finding a happy home in a specific folder designated by your web browser. The next time you browse that site, the site looks for that tiny text file, and reads it, so you don’t have to login again. Clever, huh?
Well, not so clever, really. What if you’re working at a public terminal? Your cookie’s sitting there in the cookie folder, and some enterprising rogue could use it to gain access to your account on that web site. Because this is insecure, many web programming languages allow for other mechanisms for remembering state.
July 31st, 2006
It used to be so simple.
Back in the wild and wooly early days of the Web, all you needed was a little knowledge of HTML, and you were good to go. Free web space was plentiful; GeoCities was pioneering web homesteading and social networking(predating by far myspace and Hi-5); and I still had most of my hair and teeth. If you were a maverick geek, you knew Perl and Javascript; if you were really forward-thinking, you were experimenting with databases and Java applets. At that time, the idea of a web application was something that was only whispered about, some monster that haunted bash-shell-shocked developers’ dreams.
Those days are looong gone, my friend. Your average web site in 2006 is no longer a collection of static, linked HTML pages with images strewn throughout; it’s a mature piece of software, wherein one can shop, read the news, check your bank account balances, keep track of your stock portfolio, play games, chat with friends, or hook up with old college chums. The Web Application is a reality now, and although sometimes it still is a monster that haunts developers’ dreams, we have, like Shakespeare’s Prospero, harnessed this Caliban for our own ends.
Getting started in web development in 2006 is a daunting task, and the learning curve is steep. Have no fear though; my job, over the next few posts here, is to introduce you to some of the tricks and tools that developers use to create sites like myspace and the seminal image-sharing site Flickr. And who knows? Maybe you will be the one to develop the next brave step in online life; perhaps your application will be the rock star of Web 2.0.
The first concept you’ll have to get your head around is the difference between static and dynamic content. Static content doesn’t change; a static web site is a site that features text and images that are the same every visit. This is suitable for some content; the discography of a rock band long disbanded is a fine example of this. Sure, their record company might release a few compilations and unreleased material might surface, but a web site listing such a discography would tend to be of more archival interest than active use. Static websites work best for archive sites, or sites wherein the content isn’t likely to change anytime soon.
Dynamic sites, on the other hand, feature material that may change weekly, daily, or even hourly. If you depend on a web site to get statistics about your local weather, you’re going to want that web site to be updated fairly often, right? You don’t want to read about an impending snowstorm on a web site, get your winter coat, heavy boots, and fuzzy hat on, only to go outside and realize that it’s in the upper 60s, and the site you just looked at was last updated in 2003.
So how do developers manage to create dynamic sites? Do they spend their days editing page after page of HTML? Don’t kid yourself. Web developers are, by nature, lazy people; they shudder if their job becomes too much like data entry. So, to better facilitate the avoidance of mind-and-finger-numbing clerical work, web developers have put together one of the most valuable tools in the online arsenal: the Content Management System. Just guess what my next blog post will be about.
July 28th, 2006