These are more on the intermediate level side. If you’re an advanced CSS developer you may already know about these. Today I bring you:

1. Elements’ widths calculations in CSS under different browsers (most importantly, the difference between IE and Firefox).

hotel furnishing in Bulgaria

2. компютриBest method to implement links with icons next to them.

Later on, browsers begin to support these attributes even in other tags like <div>, and pretty much anything else.

However, as web standards develop over the years and people’s coding practices for the web begin to standardize, it is generally considered bad practice to use them. There are many reasons for this, among others:

1. You cannot attach more than 1 action this way. If you want to do a lot of things in one event, you will need to put a lot of code either in this attribute, or in the function being called from this attribute; and these may very well be unrelated actions. This makes your code less organized and harder to develop.
2. No good separation of presentation (HTML) from functionality (JavaScript). Everything is mixed together. This makes collaboration development efforts difficult; and makes the code hard for you to manage even if you were the sole developer.

Fortunately, we have an alternative solution. They are Event Listeners.

Event Listeners basics

Event listeners are initiated strictly in JavaScript code, not within any HTML tags.

For the remaining of this article, I will assume the use of the Prototype.js framework. I’m aware that there are advanced developers who dislike this library, but it is used fairly commonly (either completely, or their own in-house modified version) among a lot of startups and web apps, so hopefully it’s not unreasonable to depend on it.

With that in mind (with the inclusion of Prototype.js), you can initiate an event listener like this. Assuming you defined a function for handling the “click” event on a div block with an id “main_div”:

var handlerFunction = function(event) {
alert('Hello world!');
};

var my_box = document.getElementById('main_div');
Event.observe(my_box, 'click', handlerFunction);

The main idea is very simple. It is simply this: instead of using onclick (or on-* of any event) in any HTML tags, you have Event.observe in your JavaScript code instead. This way, you can add as many different functions as you like to any elements. They can even come from different .js files. (for more details on how to use Event.observe, see the Prototype.js documentation.)

To see what kind of events are available to you other than “click”, see the DOM Events W3C spec. What you will often be using are in section 1.6.2, mouse events.

Page loading, and Initialization routine

If you understand what the above code means, you can also logically deduce that, your event handler does not start being observed until the point this JavaScript runs. And whether you want it or not, when the Event.observe line executes, it will start.

The implication here is that, it is entirely possible that your HTML document is not ready to handle this. This is because JavaScript runs linearly as your HTML file is being loaded and parsed.

More often than not, your JavaScript resides in the beginning of your file. (It is recommended for web developers to keep their JavaScript at the top) That means you don’t even have any objects on your HTML page yet! Your Event.observe line is sure to fail, because the object by the id “main_div” does not exist yet.

So should you put your JavaScript at the end of your page instead? Of course not! What you want is a way to run all your Event.observe lines after your page is fully loaded.

Event.observe(window, 'load', function() {
Event.observe(my_box, 'click', handlerFunction);
// ... any other event listeners go here
});

Once you have this in your JavaScript, all your event listeners will only initiate after your page is completely loaded. The way this works is simple. The “window” element means the entire browser window. The ‘load’ event for this element means that this handler function will execute when the page is done loading. So the effect is that all your interactive elements on your page will start being interactive when the page is fully loaded.

DOMContentLoaded

But there is still a problem! The key word in the last paragraph was “fully loaded”. What this means is, your interactive elements only work after your entire page is ready. Unfortunately, this means after all images and other binary data have finished loading. When your web page is heavy with data, this might be a long time. If you use event listeners for your navigation dropdown menus, for example, that means they are not going to work until all your images are done loading. It would be very annoying if a user cannot use your navigation menu before the page finishes loading.

*This is why I wrote this article!* The key point is here.

Fortunately, thanks to many wise web developers on the internet, we now have a solution. This solution lets you initialize your event listeners as soon as your HTML finishes loading, and without having to wait for images and all other data on your page.

The solution: DOMContentLoaded.

In simple words, this events.js library will let you do this:

addEvent(window, "DOMContentLoaded", function() {
Event.observe(...);
// ...
});

What will happen now is that, all your event listeners will initiate as soon as the HTML of your page is loaded, without having to wait for anything else. I am not going to go through the details of how and why here (I try to make my blog as close to practical usage lessons as possible without being too academic). If you are interested, the link I gave you above should give you every detail you want.

Conclusion

With all of the above knowledge, there is absolutely no reason one should be using the old ways of “onclick”, “onmouseover”, etc. anymore. Many people attempt to use event listeners, but oftentimes they encounter the problem I stated above of elements having to wait for the page to be fully loaded to become interactive. This has turned many people back to using the old-school methods, which is unhealthy. After having introduced you to DOMContentLoaded, it should solve all concerns you have with using event listeners.

Internet Explorer restricts you to a maximum of 32 @import statements in your CSS file.

For the less advanced developers, you can import another CSS file from within one of your CSS files. Consider it like a #include in C programming, or an include statement in PHP. The syntax would look like this:

@import url("mystyle.css");

When you are developing a complex web application, you are likely to have many CSS files. Admittedly, we haven’t cleaned up the CSS structure and removed any outdated CSS stylings for a while, in our project. We shouldn’t have imported so many. But it struck me as ridiculous for Internet Explorer having such limits. (Needless to say, Firefox has no such ridiculous limits.) To me, it just seems like a programming flaw (using a 5-bit number as indexing for imported files?).

Reference: http://www.juniper.net/security/auto/vulnerabilities/vuln3394.html (the topic discussed in this link is not related, but pay attention to the end of the second paragraph: “Internet Explorer imposes a maximum limit of 32 imports that an individual styleSheet object can hold, and a depth limit of three on the number of style sheets that may be included within the style sheet chain.”)

Update (3/27/08): Apparently, IE doesn’t only impose a number of files limit — but even a file size limit for each CSS file. The IE CSS file size limit seems to be ~288kb. Again, Firefox doesn’t seem to have such limits. Way to go IE, for continuing screwing web developers up.

Interestingly, when these CSS standards were first developed, no one imagined they could become so useful — it’s an important part of what makes web 2.0 applications like meebo possible. (chat windows overlapping others to simulate a desktop application design)

So, when developing web applications nowadays, you could very well have needs to utilize this property. Unfortunately, support for z-index is flaky in browsers. Not every browser interprets code the same way. Unfortunately for developers, Firefox and Internet Explorer, again, have different opinions on z-index.

In this article, I will discuss some potential discrepancies with z-index, and how you can get around them.

Normal Cases

When you are dealing with strictly just absolute-positioned blocks, not nested by anything, you can rely on z-index to be working properly in all browsers. Pretty simple, the higher the z-index number is always on top.

<div style="position: absolute; top: 10px; left: 10px; z-index: 10;">
Box 1
</div>

<div style="position: absolute; top: 20px; left: 20px; z-index: 5;">
Box 2
</div>

Box 1 will appear on top of Box 2 in this example, even though Box 2 came last. Simple enough.

More complicated cases: nesting blocks

Oftentimes, when you are developing web applications, HTML code isn’t so simple. Your view files/the presentation layer could be divided into several files. Plus, to code up a nice user interface, your HTML often gets a little bit complicated and you have a lot of nested div blocks. It’s not uncommon to come across a situation such as this:

<div style="position: relative;">
<div style="position: absolute; top: 10px; left: 10px; z-index: 10;">
Box 1
</div>
</div>


<div style="position: absolute; top: 20px; left: 20px; z-index: 5;">
Box 2
</div>

And now we have a problem. I have written an entry about absolute positioning within a relative block a while ago about what you can do with positioning, so things like the above code are fairly common for advanced CSS coders. Suppose the two blocks above are meant to overlap, with Box 1 appearing on top (you intend so, at least).

Here comes the problem. Firefox still interprets the z-index values and place Box 1 on top. However, Internet Explorer (both IE6 and IE7) does this differently. In IE, Box 2 now appears on top simply because it comes last in the code — because Box 1 belongs in a different stacking context (it’s nested within the parent relative block). The key here is that the parent relative block has no z-index, and by definition it should not create a different stacking context. (it is a different story if the parent relative block defined a z-index value and is, say, 2)

To better illustrate my point in action, here’s a link: IE z-index bug in action.

Try viewing that page in Firefox, and then in IE. It doesn’t matter if you’re on IE6 or IE7.

Detailed readings and work-arounds

It may not be easy to understand what I’m talking about at all in solid terms. The bottom line is, the two major browsers, IE and Firefox, work differently; as witnessed in the above link. The W3C CSS spec for z-index is here for you to read if you are interested.

For a really detailed experiment done on z-index and positioning, here’s a good link: Effect of z-index value to positioned elements. It’s a long read and the examples can be complicated, but it’s worth studying for a good CSS developer.

What I find to be the best work-around is this. For a web application developer, oftentimes we need to create popout div as dialogue boxes (that open when a user clicks something). How do you make sure those boxes’ z-index values work correctly, without anything else (any other elements on the page) appearing on top of it? The simplest way is to make sure all your boxes appear at the end of the page in your HTML, outside of all other blocks.

In my recent work, I actually had complicated enough scenarios where I had to use JavaScript to move my dialogue boxes blocks to the end of the page on page load. I’ll leave it as an exercise for you to think about how to do that; but here’s a tip — appendChild. (Pay attention to “If the node already exists it is removed from current parent node, then added to new parent node.”)

In JavaScript, “null” is not the same as “undefined”.

This was what costed me some debug time recently when working with JavaScript at my job.  I will talk about how I came across this issue, because there are various valuable aspects of this story that could be worth reading for those of you frontend developers.

Actually, scratch that, if you don’t know about jslint, do read the following section too. It is useful, and you won’t regret it.

jslint

First of all, most of you know that JavaScript is a pretty loosely-enforced language.  Most browsers out there (IE, Firefox, etc.) are pretty tolerant to sloppy code, just like HTML. To be fair, it’s not the browsers’ faults completely, since in a lot of cases, JavaScript was defined to be like that. For example, it tolerates missing semi-colons at the end of a line. Nonetheless, JavaScript is very powerful, despite these problems that make programmmers cringe. Here’s a good read: JavaScript: The World’s Most Misunderstood Programming Language.

The problem comes when there are multiple browsers. Each can interpret things a little differently. With Firebug and Venkman, it’s easy to develop for Firefox and pinpoint errors. (I personally just use Firebug, in the short time I’ve tried Venkman, I found it too complicated.) For IE, this is a lot harder. The best free tool I’ve found is MS Script Debugger (free but requires genuine Windows ), possibly along with IE Developer Toolbar (completely free). IE Developer Toolbar is similar to Firebug, but without the JavaScript part. (only CSS and DOM inspecting)

With simple JavaScripts, debugging is usually not a problem. But when you get into object-oriented JavaScript, involving code spreaded out to many files, (IE’s internal-secret-line-numbering doesn’t help) it’s a nightmare. Couple this with the fact that IE has their own strange interpretation rules, you often cannot find where errors are happening.

Fortunately,  Douglas Crockford developed an extremely useful tool, called jslint. It’s even web-based (developed with JavaScript itself!), so you don’t have to install anything. All you do is copy and paste your JavaScript in there, and let it validate. Kind of like a w3c validator for HTML, also kind of like a compiler for C++. The lint program is/can be very strict on your code — this means if your code passes jslint, it is extremely likely that it will work fine in all browsers including IE.

Data types comparisons

In JavaScript, there are a few basic data types you’ll be using a lot, such as integers, strings, booleans. Because of the loosely-enforced nature of JavaScript, comparisons are made to be loose as well. To give an example of what I mean:

var mynum = 0;
var mybool = false;
if (mynum == false) // this evalutes to true
if (mybool == 0) // this evalutes to true

They are all the same in “value”. To further enforce your code logic to make sure you’re doing what you want to do, jslint recommends using === or !== to check for equalities/inequalities when one side involves zero, false, null, empty string, etc. The === or !== operators also check the data type. To give an example, continuing from above:

if (mynum === false) // this evalutes to false
if (mynum === 0) // this evalutes to true

Once you understand this part, let’s move on to the next section.

“null” and “undefined”

In JavaScript, they are different. Null is a value that is only assigned by a programmer. You can set a certain variable to the value null. Undefined is what a variable has if it wasn’t assigned to anything.

I had no idea about any of this before, so I googled it up and found this article: JavaScript Difference Between null and undefined. It has a clear and simple example to demonstrate the point. To be more specific about the kind of problems I ran into, we had something like this in our code.

myFunc = function(arg1, arg2, arg3) {
if (arg3 == null) {
// do something
}
};

This was working fine at first. If you call myFunc without arg3, it goes in the conditional statement and executes whatever is inside. When I ran the code through jslint, and changes the check to (arg3 === null) as it recommends, problems arose. It never went into that condition anymore and the bug travelled very far along the code to some weird behaviors. (because this function happened to be the constructor for a class in our case, making it hard to find at once)

I eventually realized that, when you don’t pass in arg3 to myFunc, arg3 then has the value “undefined”. The value, without the type, is the same as “null”. Initially, it worked fine when we only use ==. But when we add in type-checking, with ===, they are not the same. Thus, the code needed to be fixed to say:

if (arg3 === undefined)

Conclusion

It was a good lesson to me. Even though I’m coding up object-oriented JS left and right, there are still basics about the language that I admit I’m not familiar with. I learned something, and I hope you learned something out of this entry as well.

Then I was reminded that my Wordpress hasn’t been updated in a while. So I ran a check in the source code of my blog for some common hacks (usually an <iframe> code inserted somewhere), and guess what, I found some.

This lead to Google then listing my site as “harmful”. This is a special announcement entry to tell you all (however few regular readers I have) that the badware is removed, and Wordpress is updated to the latest and greatest.

This is also a post to tell you that, if you own a Wordpress blog running a version older than 2.3.2, you should update. More info could be found on this Wordpress support thread. I hope Google didn’t scare anyone off (especially potential new visitors of my blog) by saying it’s a harmful site. And I hope they do the review as soon as possible, as I submitted it for review arleady.

CSS Positioning

If you’re reading this, you probably know what CSS positioning is.

When you define the CSS of a div block with position: relative, any top, left, bottom, right attributes you give it will move the block accordingly, from its original position (where it would be if you didn’t move it). Giving it top: 20px will move it 20px below where it would be.

On the other hand, if you define a div block with position: absolute, you are essentially telling it exactly where it should appear on the screen. Giving it top: 0px and left: 0px will put the block at the very top left corner of the page. It also effectively “floats” the element and put it on top of any page element that are in the way, but don’t confuse this with the float attribute in CSS. Also, you can control which element appears on top with z-index, if you have more than one.

That said, let’s get into what I’m really talking about this time…

Absolute positioning within a relative block

That might sound awfully complicated at first, but the idea is simple. You are putting an absolute-positioned block inside a relative-positioned block, like this:

<div style="position: relative;">
  <div style="position: absolute;">
  </div>
</div>

And the reason you’d be doing this is that, when you define a block as relative, the absolute coordinates inside it are contained. In other words, for that nested absolute block, the coordinates of 0,0 start at the top left corner of the parent relative block, instead of the whole page. Giving the nested block the attributes top: 0px and left: 0px will put it at the top left corner of the containing relative block.

This is very useful for positioning elements at a specific place within a block. It’s logical to use absolute positioning in those cases, but it’s not logical to calculate exactly what pixels they should be in terms of the whole page, because your calculations are likely going to be off in different browsers, operating systems, or even just text size settings. When creating very modularized web applications (as a simple example, Facebook apps), you may often find yourself needing to do that.

Other uses of this would be, for instance, making rounded-corners boxes. In my opinion, the best method to create rounded-corners boxes would be to make the images of only the corners, and position them absolutely at the corners of the containing block (which are, top-0/left-0, top-0/right-0, bottom-0/left-0, and bottom-0/right-0); and then simply giving the containing block position: relative (with no top/left/etc. coordinates needed).

The Internet Explorer 6 problem

Sounds almost too nice to be true? You are right, there’s gotta be some problems with that. And the problem is Internet Explorer 6. For all you web developers who use Firefox anyway, it wouldn’t be much of a problem; except that Internet Explorer still has 76% of the browser market (as of this writing; I know, surprising eh?) and the majority of those are IE6 users.

The problem is that, when you use this CSS trick, IE6 doesn’t always start calculating coordinates from the containing relative block. It only does that sometimes. In other times, it just starts calculating them from the corner of the whole page, as if you didn’t have the relative block at all. If you didn’t know better, you might even think it seems to be arbitrary with no patterns.

Fortunately, there is actually reason for it; and better yet, there is even a fix for it!

The problem lies in a hidden property of the Internet Explorer browser, called “hasLayout”. It is not a property where you could set with your CSS. It’s basically a hidden variable kept track by the browser program about each element on the page. To read all about it, you can read On having layout.

To make things easy and sum it up for you, you can “give” a block “layout” by giving it attributes such as float, width, or height. (there are more, but these are the more common ones) But as web designers you know that sometimes you just cannot give attributes like that to a block without messing up your design. Fortunately again, there is an IE6-only fix which doesn’t involve any of that. I stole the code below from this page.

<!--[if IE]><style>
.ie_layout {
  height: 0;
  he\ight: auto;
  zoom: 1;
}
</style><![endif]–>

With this defined, all you have to do is give your parent relative block a class called “ie_layout” to fix the issue. To give a brief explanation of why this works: The HTML comments starting with [if IE] is basically an IE-proprietary command that means, only run the code below for Internet Explorer. The height:0 and the very strange he\ight: auto; (which I don’t fully understand; but yes, it is supposed to be that way, including the backslash) are basically properties that don’t do anything at all to the element, but give it a “layout” (i.e. turning “hasLayout” to true for that element).

That’s about it for today. Hopefully, you’ve picked up something useful from this article!

Update (1/25/07): I actually just read (after posting this) that the Microsoft developers working on IE8 are getting back to the right path: Supporting W3C standards and banishing hasLayout. This is certainly good news, but browsers typically take very long for users to adopt. Most IE users nowadays are still on IE6 even though IE7 has been out for a while. It might very well be a good 4-5 years before IE8 becomes the major browser.

A friend of mine has recently requested me to write a starter tutorial for someone (presumably, who already has some programming experience and web site development experience, as he does) to start doing web applications development, particularly in PHP. I thought, hey, maybe I should just write it up here, since I haven’t written anything here for a while.

In this tutorial, I will cover some simple steps on how to setup a web server (Apache), PHP, and a database (MySQL) on your machine. In particular, I will assume the use of the Windows machine. Why? Honestly — if you’re operating Linux already, shouldn’t you know enough to be able to setup all that on your own? I will also be writing some of my preferred methods of managing the server.

Getting a Text Editor

Before I get into anything, let me first talk about text editors. Throughout this tutorial, you will find several instances where you need to be editting configuration files. I recommend a text editor called TextPad. This editor deserves a lot more fame than it has. It is best text editor I’ve ever used. It’s not only good for normal editting, I even use it to code a lot of my PHP web applications. It has an unlimited free trial so if you are poor, this is the way to go. You can also always pay $32 to get rid of the nagging box that asks you to buy it.

Installing Apache

For PHP web applications in particular, the Apache HTTP server is the server of choice. For Windows users who just need to install the web server, unless you need the source code of it for any reason, you can simply download the binary. This Apache archive contains what you need. Download the .msi file of the latest version (2.2.6 at the point of this writing). Apache insists you must also check your downloaded file against the .md5 code for security. (If you are just downloading it for personal use and testing on your local machine, I don’t think it’s necessary.) If you do want to be secure and run a md5 sum of your downloaded file, you can use this MD5summer (since WinXP doesn’t have any md5 tool).

Installation of Apache is fairly straightforward. On Windows, you have the option of running it as a permanent process (on port 80), or running it per user (on port 8080 by default for this option). For any normal web server, port 80 is what is used. When you type in a URL (say, http://www.agum.com/), port 80 is assumed. You can also specify a port, such as http://www.agum.com:8080/. That is what will happen when you run it per user. Typically, if you are just using this as a developer machine, you should probably just use the 8080 option. Most other options can be left at default for a new developer.

Configuring your web server

Once installed, before you run the web server, the first thing you will want to know is how to configure your web server correctly. This is done by editting the httpd.conf file. This file is located at C:\Program Files\Apache Software Foundation\Apache2.2\conf\httpd.conf, assuming you installed Apache using the default location.

There are many things going on here, but here are a few things of interest, for a beginner.

1. Find the line “Listen 8080″. On my file it’s line #53, so it should be near there. You can change the port number of your web server here if you need to, to pretty much anything (unused). Leaving it at 8080 is fine.
2. Find the line starting with “ServerName” (line #142 here). You can enter your IP address here, or you can enter a hostname if you have one. (places like Dyndns.org gives free hostnames you can use) If you are behind a router/firewall, and you are only going to be needing to test locally with no one else needing to access your server, it might be easiest just to use your LAN IP, or even 127.0.0.1, to save a lot of trouble with port forwarding on the router settings.
3. Now the most important: the line with “DocumentRoot” (line #149 here). This is the location your files are served from. I have this on my test machine:
   DocumentRoot “C:/webserv”
   This means I have created a folder on C drive called “webserv”, and all my html files, image files, php files reside in there. After editting this line, you will also need to edit a line a little below it (line #177 here), it looks like this:
   <Directory “C:/webserv”>
   Obviously, you will want to use the same location for here.

That should cover everything you might need to edit in the configuration. Now, you can run your web server to test it out. If you followed through the typical Windows installation, you can run it from Start -> Program Files -> Apache HTTP Server -> Control Apache Server -> Start Apache in Console. What this does is it will run httpd.exe with the default options. Don’t close that DOS prompt when you run the server. When you close it, Apache closes.

You can test to see if you have everything correct by going to http://127.0.0.1:8080/. It should show whatever you have in C:/webserv (if you have the same setup as me). Put an index.html file in there to try it out.

Installing PHP

When your web server is configured, the next step is to install PHP. Download PHP first. Again, on Windows, you will just really need the Windows binaries. (you really won’t be needing to modify any PHP source, for a while..) You only need to download the one that says “PHP 5.2.5 installer [19,803Kb] - 15 November 2007″ (at the time of this writing, this is the latest version.). You don’t need the PECL extension for now.

While installing PHP, you will run into a screen that asks you what extensions you’d like to install with PHP. Do not be intimidated by this huge list. For a lot of web applications, you don’t even need most of these. The ones that I do think will be needed are: gd2 (for manipulating images), mbstring (for handling foreign languag), mcrypt (encryption), mysql and mysqli (needed for using MySQL). You can pretty much just follow my recommendations if you have no clue what you’re doing.

Configuring PHP

Once installed, the configuration file of interest is C:\Program Files\PHP\php.ini. It’s a very long file, but there aren’t much that you need to pay special attention to. Here are a couple of items you’d want to look for:

1. Look for the line: (line #117 here)
   engine = On
   Make sure it says on. There shouldn’t be any reason it would be off.
2. Shortly after that, find this line: (line #128 here)
   short_open_tag = On
   Make sure this one is on. This is actually important because many pre-built PHP scripts out there (if you are running any) use the short open tag.

There isn’t much else you need to change. You can now test your PHP. Run your web server again the same way you did before. Put a test.php file in your C:/webserv folder. Put some test lines in there, like <?php echo ‘Hello world.’; ?>. See if it runs correctly.

Running phpinfo()

A good way to test out everything in your installation is phpinfo(). It is a function provided by the PHP language. You can simply put this in a file:

<?php
phpinfo();
?>

And save it, then run it from your browser. You should see a very long page detailing all the configurations of your PHP setup and extensions.

Installing MySQL

You can download the MySQL 5.0 Windows binaries here. The “Windows ZIP/Setup.EXE (x86)” option is probably the easiest to install. The installation will prompt you for several things, but should be quite straightforward. You can simply answer them based on how your machine will be used. (as a developer machine, only use part of the memory/cpu for the database, etc.)

One interesting thing I’ve noticed is that, after running through the installation, there is no place that asks you to set your admin password. I always use the way on the MySQL reference manual to reset the password after the installation.

The configuration file is at C:\Program Files\MySQL\MySQL Server 5.0\my.ini. However, there really isn’t anything you need to change in there, so I won’t be going through it.

Once my MySQL database is installed, I personally find it more convenient to have a quick shortcut to start my database, and to stop my database. Here they are.

Starting MySQL:
“C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqld.exe” –standalone

Stopping MySQL:
“C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqladmin.exe” -u root –password=1234 shutdown
(where your password is 1234)

Make a shortcut containing those commands. Correct the paths if you need to. Then, whenever you need to start or stop the database, simply run these shortcuts.

To easily test out your MySQL database installation, you will need a PHP script that uses the database. The easiest way is to download phpMyAdmin.

Installing phpMyAdmin

The phpMyAdmin software basically lets you administer your database from a web interface. To clear out any confusion — if you are fluent with SQL commands, you can simply use the text-based MySQL client (mysql.exe) to do anything that you could do in phpMyAdmin. This software is only an interface, written in PHP, for you to do anything to your database easily from your web browser. Installing it is optional.

Download phpMyAdmin. (There is a Quick Downloads box near the top left) Once downloaded, simply unzip the package to your web server’s document root, which is C:/webserv in the examples I’ve been using above.

There are a few steps in setting up phpMyAdmin. At this point, I’m not sure if my friend needs to do this or not. I will continue this writing when I find out that he does. For now, I’d like to publish this article as soon as I could so I could help out.

Facebook applications originally provided something with very good potential, but unfortunately, it isn’t really working in the way I would hope it should.

Usefulness vs triviality

It is extremely unfortunate that majority of the Facebook applications that “succeeded” (currently) are entirely useless ones such as SuperPoke, X Me, SuperWall, and Top Friends. It is not hard to see how they succeeded.

Slide and RockYou apparently has some sort of partnership with Facebook (correct me if I’m wrong in this); they were able to push out some applications since day 1 of releasing the Facebook apps platform. They created these useless little apps, and made ways of spreading them (mainly the “Invite your friends” page when you first add the app).

Of course, now that everybody knows what that is, everybody just skips that page entirely. But when it first started, people actually invite other people through that.

Normally, an app getting popular, no matter what ways it used to accomplish that, isn’t really a problem. The main problem here lies in the fact that these apps are mostly useless trivial apps — look at SuperPoke, X Me, Free Gifts — they do nothing more than posting a message or an image on a friend’s profile. Top Friends has a little more to it than that, but also doesn’t have much practical uses other than generating hate from your other friends who didn’t get in your Top Friends list. (did anyone actually think of that when they add people to their top friends? I can’t believe how many people actually think Top Friends is cool. It destroys a lot more friendship than improving any.)

All of this gave a really bad example for new developers starting at this stuff. Other programmers see the success of these useless little apps, and they go ahead and make some too. It easily became the norm, then, to make trivial apps on Facebook. This in turn leads regular Facebook users to get used to the fact that Facebook apps aren’t to be taken seriously. It’s just fancy little toys to be added to your profile with no practical uses. Now, the only difference between Facebook Apps and the trash you see on MySpace is that Facebook Apps are more secure and more difficult to program for — other than that, there is no practical difference.

This is really, really sad because Facebook apps would have so much potential otherwise. Facebook could’ve pulled the a great part of web 2.0 applications into their platform if Slide and RockYou didn’t set such bad examples! The possibilities would’ve been endless.

Before Facebook Apps

Did you know that a Facebook development platform existed before Facebook released Facebook applications? You could develop third-party web applications (or even desktop applications!) using Facebook’s social network data to back you up. They would be standalone web sites, only having a Facebook login. All “Facebook Apps” did was to allow you to integrate your application into people’s profile boxes and provide you with a canvas page (which is mostly just an individual web site, for the most part).

Take a look at this: MoochSpot. It lets you “keep track of debts and shared expenses with your friends”. Excellent idea, nicely done using the Facebook platform.

And you know what? That is what Facebook applications should have been like in the first place! Useful web 2.0 web apps integrated into Facebook. NOT trivial little toys to add to the Facebook profile.

Another way to see it

Perhaps, though, Facebook could help us partly solve this problem by fixing their Applications directory. Help those of us developers who actually invest development time into creating a serious application with practical uses, and help the users find out about these things.

Categorize Facebook Apps into two big categories — little toys and serious apps. Or better yet, just call little toys something different altogether, like “profile add-ons” or something. That is where stuff like SuperPoke, Top Friends belong. Facebook Apps should be where stuff like MoochSpot and GoInGifts belong. (That second one, by the way, is what my team has been developing in the past month. The Facebook app, not the standalone web site — that is just a temporary placeholder designed by some web designer.)

Conclusion

Of course, Facebook Apps are still young to really say anything about it significant at all. There could very well be major changes coming up within the year that makes it into something entirely different, maybe working like what I mentioned above. Even the Facebook platform itself isn’t in a stable state yet — changes are being made from their engineering team every week, stuff is getting added, removed, and updated all the time. Let’s hope for the best and hope that Facebook will eventually solve all this out, and not to make it like another MySpace.

Years ago, web designers simply design web sites. They aren’t very different from traditional print designers. Sure, some of them might not only do the design, but also code up their designs in HTML. But a lot of times, web designers are only responsible for the visual designs, and they pass on their work to web developers to convert the visuals into actual web pages. Back then, there wasn’t even much of a term as “web application developer” — what is a web application in 1998? A form mail script? A guestbook? Nobody would do that for a living. Let’s rephrase that — you won’t make a living doing that.

Now we enter the web 2.0 boom. Full-fledged web applications are being developed. Meebo is my favorite example. And there’s Google Docs & Spreadsheets, etc. How are applications developed? By programming, obviously. Just like desktop applications, web applications also have a backend programming element to it, as well as a frontend interface programming element. These are huge applications we are talking about — they are as large as or even larger on scale than desktop applications in the past!

Web applications backend programming is really not much different from traditional programming people have been doing since the beginning of time. (except maybe working with different languages — like PHP, Ruby on Rails now. But people still use Java and C++ too!) When we get to frontend, things get a bit different. We have new technologies like DOM scripting and AJAX. These technologies are still in sort of an infant stage. It really takes a tech-savvy person to bend them at will and do what you need to do. Heck, even writing standard XHTML and CSS and making sure they work across browsers is a challenge!

Needless to say, frontend development work has to be done by programmers as well. Here’s where the problem comes in. As we all know very well, programmers aren’t good designers. What this translates into is a whole bunch of web applications with badly designed interface. You could hire a designer to make things look good, but if an application has a bad interface, that makes it a bad application.

It takes a usability expert and/or a great UI designer to do this frontend work. Very often, the frontend programmer is not this person. Currently, the only solution to fix this problem is to hire somebody who is both a great UI designer and a programmer to do the frontend work. It certainly is a big challenge! There aren’t that many of them out there.

And we come back to the question. Where do you draw the line between designer and developer? I am a web application developer. A lot of times, however, I find myself having to take care of some aspects of the frontend design. So should I be considered a designer in addition? The designer at my company needs to learn some web apps programming in order to improve on her work. She needs to understand how AJAX works, how the DOM elements on the page work, in order to make her designs work. So is she a developer now?

Frontend applications development is an interesting job. It takes both good design knowledge and technical knowledge to do the job — an unusual duo. Frontend developers should really be more valuable than backend programmers, since old-school programmers are a dime a dozen. Why aren’t we getting paid more?