From the IEBlog:

As a team, we’ve spent the last year heads down working hard on IE8. Last week, we achieved an important milestone that should interest web developers. IE8 now renders the “Acid2 Face” correctly in IE8 standards mode.

If you’re not a web developer, the details of this blog post probably aren’t all that interesting for you. I’d like you to know that we’re building IE8 for many different customers (consumers, web service providers, independent software vendors, enterprises, web developers, and others), and we’ll cover more details of the non-developer oriented work (e.g. user experience, reliability, security, etc.) in other posts in the future, after MIX.

While web developers will immediately recognize what Acid2 means, I want to step back and offer some context for other readers of this blog who may not be familiar with web standards. Briefly: Acid2 is one test of how modern browsers work with some specific features across several different web standards.

At first glance, this test seems simple. I think it actually offers a view into the subtle and complex world of web standards in a number of ways. Showing the Acid2 page correctly is a good indication of being standards compliant, but Acid2 itself isn’t a web standard or a web standards compliance test. The publisher of the test, the Web Standards Project, is an advocacy group, not a web standards defining body.

When we look at the long lists of standards (even from just one standards body, like the W3C), which standards are the most important for us to support? The web has many kinds of standards – true industry standards, like those from the W3C, de facto standards, unilateral standards, open standards, and more. Some standards like RSS or OpenSearch lack a formal standards body yet work pretty well today across multiple implementations. Many advances in web technologies, like the img tag, start out as unilateral extensions by a vendor. The X in AJAX, for example, has only started the formal standardization process relatively recently. As some comments have pointed out, CSS 2.1, one of the key standards that Acid2 exercises, is not “finalized” yet. Different individuals have different opinions about different standards. The important thing about the Acid2 test is that it reflects what one particular group of smart people “consider most important for the future of the web.”

The key goal (for the Web Standards Project as well as many other groups and individuals) is interoperability. As a developer, I’d prefer to not have to write the same site multiple times for different browsers. Standards are a (critical!) means to this end, and we focus on the standards that will help actual, real-world interoperability the most. As a consumer and a developer, I expect stuff to just work, and I also expect backwards compatibility. When I get a new version of my current browser, I expect all the sites that worked before will still work.

With respect to standards and interoperability, our goal in developing Internet Explorer 8 is to support the right set of standards with excellent implementations and do so without breaking the existing web. This second goal refers to the lessons we learned during IE 7. IE7’s CSS improvements made IE more compliant with some standards and less compatible with some sites on the web as they were coded. Many sites and developers have done special work to work well with IE6, mostly as a result of the evolution of the web and standards since 2001 and the level of support in the various versions of IE that pre-date many standards. We have a responsibility to respect the work that sites have already done to work with IE. We must deliver improved standards support and backwards compatibility so that IE8 (1) continues to work with the billions of pages on the web today that already work in IE6 and IE7 and (2) makes the development of the next billion pages, in an interoperable way, much easier. We’ll blog more, and learn more, about this during the IE8 beta cycle.

Now, with all that context, I’m delighted to tell you that on Wednesday, December 12, Internet Explorer correctly rendered the Acid2 page in IE8 standards mode. While supporting the features tested in Acid2 is important for many reasons, it is just one of several milestones for the interoperability, standards compliance, and backwards compatibility that we’re committed to for this release. We will blog more on these topics. Here’s a relevant video.

For IE8, we want to communicate facts, not aspirations. We’re posting this information now because we have real working code checked in and we’re confident about delivering it in the final product. We’re listening to the feedback about IE, and at the same time, we are committed to responsible disclosure and setting expectations properly. Now that we’ve run the test on multiple machines and seen it work, we’re excited to be able to share definitive information.

While blog posts and links to videos are a good start, publicly available code is even better. We will have a lot more information available at sessions at MIX08 and will release a beta of IE8 in the first half of calendar 2008.

Dean Hachamovitch
General Manager

p.s. The following is the actual code check-in mail from Friday that pushed the code changes from developers’ machines into the central IE build. I’ve removed references to email aliases and UNC paths. “DRTs” are tests that developers check-in along with their code, in case you’re wondering about the .htm .xml and .js below.

Click here for the entire post.

I deal with a lot of database dumps. So this post is a must for me.

We seriously see a ton of customers coming in with the type of databases that are a nightmare to move over. When you’re dealing with special characters in a database, you have to make sure that the charset and collation are dumped *with* the database, so that when you move it to another server the tables and data create properly. The biggest annoyance so far is converting tables back to UTF-8, as when this is done through the MySQL shell or phpmyadmin is had to be done table-by-table. So, I wrote this simple PHP script to do it all at once…

The script is quite simple; I can just simply:

$sql = “ALTER TABLE $table DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci”;

Where $table = each table in the database.

Here is list:

The source has the complete list.

A short but complete tutorial on how to write a Chat Application using PHP, AJAX and XML.

Developers talk a lot about community when the term Web 2.0 comes up. And whether you think it’s hype or not, the idea of engaging your customers or readers in an instantaneous conversation about the topics at hand or the products you’re selling is pretty compelling. But how do you get there? Can you put a chat box on the same page as your product listing so that your customers don’t have to install special software or even Adobe Flash Player? Sure! Turns out, you can do it all with free, off-the-shelf tools such as PHP, MySQL, dynamic HTML (DHTML), Ajax, and the Prototype.js library.

Without further ado, let’s jump right into the implementation.

Now, you can generate charts using Google Chats API. All you have to do is to enter this in your address bar:

http://chart.apis.google.com/chart?cht=lc&chs=200x125&chd=s:helloWorld

And then you will get an image that looks like this:

As simple as that! Anyone could just generate some sort of string to be passed to the URL and then output the image directly from their web application.

Here is a comprehensive comparison between the Symfony Framework and the Zend Framework.

Like the .Net Framework, Zend is a bucket of functions that, together, provide advanced interfaces to the most complex of tasks that web developers need to write regularly. They then leave the developer to work up a quick interface to the application, which they enable with their views structure. Zend’s major strength and weakness is that there isn’t one particular way to do things and that you can pick and choose which libraries you want to use.

Both frameworks are PHP5-native frameworks and won’t function in PHP4. Both are heavily object-oriented and make use of inheritance that’s only offered in PHP>5. Both use the front controller model.

The similarities end there.

Zend uses very little code generation and configuration is all in the front controller; Symfony has a great deal of code generation and a huge amount of configuration overhead. Zend is flexible about it’s directory hierarchy and allows you to heavily customize your directories to use global code libraries; Symfony has a required directory structure that is created when you use the command line tool to create modules. Zend doesn’t require command-line creation of modules.

After the jump, I’ll focus on a few areas where there’s some specific differences.

Getting Started

Symfony has a lot of ‘buzz’ and user support, and there are excellent guides from both the authors and the communities to get users started on the learning curve. Zend doesn’t have as much, and the documentation is really directed at more experienced developers who are old hands with the more complex aspects of object-orientation.
Unit Testing

Symfony provides command-line tasks for unit testing and automatically generates a default (empty) testing object for you when you create a module.

Zend doesn’t have integrated support for unit testing, but all components that go into the framework require unit tests.

Templating

Zend’s templating is immature and doesn’t allow easy nesting without a well-documented hack or two, but will in the next release… or ‘Soon ™’.

Symfony’s templating is extremely mature and uses caching extensively to rapidly deliver content to users. You can plug components and entire other modules into slots in your symfony templates, and you can customize the templates as much as you want through the use of layout scripts.

Plugins

Symfony has an extensive plugin and extension community in it’s community wiki. Zend, as yet, does not. It’s interesting to note that you can pull in the Zend framework’s functionality with Symfony by using the Zend Framework plugin for Symfony.
Database Modules

Zend uses the ActiveRecord model for databases. Symfony allows the user to plug in whatever database manager they want, including Zend_Db.

My issues with Symfony’s two current frontrunning database plugins (propel and doctrine) include the extensive bugs in both (Propel’s issues depend greatly on the lag in changing from Creole to DBO and also the stupidly complex criteron objects, and Doctrine’s as of yet an immature project that recently saw it’s first 1.0 release.) and the code generation / configuration overhead that you end up with when you’re creating hundreds of tables and managing changes to those tables. It gets to be a headache once you get past twenty or thirty tables. Zend’s active record implementation is much easier because all you need to do is direct an object at the item.

For the conclusion, you should read here ;P

Here is an interesting article from Philweavers.

Lucida Sans Unicode looks just like Lucida Grande in normal weight, but because it doesn’t come with a set of variants by default, Windows emulates them. What you get is a bold that’s clunky, and an italic that looks like it’s about to tip over

Click here.

From jansch.nl:

This is not the best way to escape data. The most important reason is security. addslashes can lure you into a false sense of security. As Chris Shiflett points out, there are situations that addslashes doesn’t escape.

Use mysql_real_escape_string instead.

A new version of Zend Framework has been released.  It has 79 fixes for known issues from the previous version. See here for more info. And here for the download.