VJ's Warez

PHP for Microsoft Ajax Library

vjayblog — Sat, 03 Jan 2009 08:52:16 +0000

Steve Marx has created a PHP library for the Microsoft Ajax 1.0 release that uses the JavaScript piece in PHP land.

The Microsoft AJAX Library is a pure-JavaScript library that’s used by ASP.NET AJAX but is also available as a separate download. Because it’s pure JavaScript, it’s not tied to ASP.NET on the backend. PHP for MS AJAX is code to help you make use of the Microsoft AJAX Library from PHP applications. With this first Alpha release, it simply supports exposing PHP classes as AJAX-enabled web services, just as in ASP.NET applications. In fact, the generated proxies are identical to what you get from ASP.NET, meaning you can have full interoperability.

Hello World

The service on the backend so to speak:

<?php
require_once ‘../../dist/MSAjaxService.php’;
class HelloService extends MSAjaxService
{
function SayHello($name)
{
return “Hello, “ . $name . “!”;
}
}
$h = new HelloService();
$h->ProcessRequest();

And the front end that will talk to it:

</span></a></span>Hello, World!<span style="color:#009900;"><span style="color:#000000;font-weight:bold;">

type=“text/javascript” src=“../../MicrosoftAjaxLibrary/MicrosoftAjax.js”>
type=“text/javascript” src=“HelloService.php/js”>
Name: id=“name” type=“text” />
type=“button” value=“Say Hello” onclick=“button_click(); return false;” />
/>
Response from server: id=“response”>
type=“text/javascript”>
function button_click() {
HelloService.SayHello($get(‘name’).value, function (result) {
$get(‘response’).innerHTML = result;
});
}

Ruby on jQuery and Closures

vjayblog — Sat, 03 Jan 2009 08:49:20 +0000

Sam Ruby has that way about him that sees things very clearly. He just took a peak at jQuery for the first time and was able to really put into words what I think jQuery enthusiasts like about the library:

The notable thing about this is that despite all of the asynchronous events taking place, the code is sequential (nested, but sequential), and that the JSON results of the AJAX call is immediately available to the function that is invoked when the selection changes.

This is based on the following code that he wrote:

$(“#archive”).click(function() {
$.getJSON(‘unscanned.cgi’, {}, function(unscanned) {
// replace realname input field with a selection list
var select = $(‘ +
‘id=”realname” name=”realname”/>’).remove();
$(“#realname”).val(icla[1]);
$(“#pubname”).val(icla[2]);
$(“#email”).val(icla[3]);
$(“#replaces”).val(icla[0] + ‘:’ + icla[3]);
$(“#filename”).val(”).focus();
$(“#archive”).removeAttr(“disabled”);
});
});
return false;
});

Those that love jQuery, love the API.

John himself had an example in the comments:

$(‘:radio[name=is_user]‘)
.change(function(){ $(‘.depends-isuser’)[ this.value == 1 ? ‘show’ : ‘hide’ ](); })
.change();

jQuery 1.3 beta: Sizzling and feature testing

vjayblog — Sat, 03 Jan 2009 08:45:36 +0000

jQuery 1.3 beta 1 has been released with John and the team asking for testing help.

This is a big release as a lot has been changed:

Sizzle has been integrated
No more browser testing: For example, no more if ( jQuery.browser.msie && !jQuery.isXMLDoc(this) ) { which is replaced with if ( !jQuery.support.noCloneEvent && !jQuery.isXMLDoc(this) ) {
Live event delegration: Reglib’s claim to fame was how event delegation was “live” meaning that if you added elements later on, they would also fall into the same delegations. With $("#foo > div").live("click", someFn); you get the same in jQuery
$(this).closest("div");: Returns this or closest ancestor that matches selector
.offset() rewrite – significantly faster, uses no browser sniffing.
.hide()/.show() rewrite – 50% – 200% faster.
.append/prepend/before/after rewrite – 10-15x faster.

YQL – converting the web to JSON with mock SQL

vjayblog — Sat, 03 Jan 2009 08:43:47 +0000

I like getting data from the web and I love JSON – as it is easy to use. The issue is that not many things on the web come as JSON from the get-go. Hence we need converters. You can use cURL and beautiful soup or roll your own hell of regular expressions. Alternatively you can use Yahoo Pipes to build your converter. Pipes is the bomb but a lot of people complained that there is no version control and that you need to use the very graphical interface to get to your data (which was the point of Pipes but let’s not go there).

~~Alas~~Rejoice for there is a solution now available and it is called YQL. YQL is a SQL-style language to get information from all kind of web services, and – using oAuth – even Yahoo’s social graph. There is a test console available for you to get to grips with all the information it gives you access to (which is a lot!):

Here comes the kicker though: for all the open services that don’t need authentication you can use these YQL statements as a REST API with JSON output and an optional callback function for JSON-P by adding it to http://query.yahooapis.com/v1/public/yql?. For example to get the latest three headlines from Ajaxian’s RSS feed as JSON and wrap it in a function called leechajaxian do the following:

http://query.yahooapis.com/v1/public/yql?select title from rss where url=”http://feeds.feedburner.com/ajaxian” limit 3

The result is:

leechajaxian({
“query”: {
“count”: “3″,
“created”: “2008-12-12T09:01:13Z”,
“lang”: “en-US”,
“updated”: “2008-12-12T09:01:13Z”,
“uri”: “http://query.yahooapis.com/v1/yql?q=select+title+from+rss+where+url%3D%22http%3A%2F%2Ffeeds.feedburner.com%2Fajaxian%22+limit+3″,
“diagnostics”: {
“url”: {
“execution-time”: “17″,
“content”: “http://feeds.feedburner.com/ajaxian”
},
“user-time”: “22″,
“service-time”: “17″,
“build-version”: “2008.12.03.14:01″
},
“results”: {
“item”: [
{
"title": "Travians: Sims meets Cultures, with Ajax"
},
{
"title": "Cappuccino 0.6 Released"
},
{
"title": "The fundamental problems with CSS3"
}
]
}
}
});
You can also search the web with YQL: http://query.yahooapis.com/v1/public/yql?q=select title,abstract,url from search.web where query=”json” limit 3&format=json&callback=leechajaxian

leechajaxian({
“query”: {
“count”: “3″,
“created”: “2008-12-12T09:06:41Z”,
“lang”: “en-US”,
“updated”: “2008-12-12T09:06:41Z”,
“uri”: “http://query.yahooapis.com/v1/yql?q=select+title%2Cabstract%2Curl+from+search.web+where+query%3D%22json%22+limit+3″,
“diagnostics”: {
“url”: {
“execution-time”: “43″,
“content”: “http://boss.yahooapis.com/ysearch/web/v1/json?count=10&start=0&format=xml”
},
“user-time”: “45″,
“service-time”: “43″,
“build-version”: “2008.12.03.14:01″
},
“results”: {
“result”: [
{
"abstract": "Introducing JSON ... JSON (JavaScript Object Notation) is a lightweight data-interchange format. ... JSON is a text format that is completely language ...",
"title": "JSON",
"url": "http://www.json.org/"
},
{
"abstract": "The JSON format is specified in RFC 4627 by Douglas Crockford. ... Although JSON was based on a subset of the JavaScript programming language ...",
"title": "JSON - Wikipedia, the free encyclopedia",
"url": "http://en.wikipedia.org/wiki/JSON"
},
{
"abstract": "Matthew Morley has posted his PHP library for JSON-RPC 2.0. ... I am think it is great to see the expanding JSON toolset available in JavaScript libraries. ...",
"title": "JSON",
"url": "http://www.json.com/"
}
]
}
}
});

What about screenscraping? You can get data from any valid HTML document using XPATH with select * from html. For example to get the first 3 tag links on my blog you can do the following:

http://query.yahooapis.com/v1/public/yql?q=select * from html where url=”http://wait-till-i.com” and xpath=’//a[@rel="tag"]‘ limit 3&format=json&callback=leechajaxian

The team is working on making this easier – while we run every page that is indexed through tidy there is still a lot of choking going on (if people wrote valid HTML that wouldn’t happen).

YQL is a pretty easy but also versatile language. You can even use complex aggregation and filtering by for example hosting a lot of URLs in a spreadsheet and loading them one by one before aggregating. The example given in the console is “select * from rss where url in (select title from atom where url=”http://spreadsheets.google.com/feeds/list/pg_T0Mv3iBwIJoc82J1G8aQ/od6/public/basic”) and description like “Wall Street” LIMIT 10 | unique(field=”title”)”

Happy converting!

Why Load Testing Ajax is Hard

vjayblog — Sat, 03 Jan 2009 08:38:36 +0000

Today we are fortunate to have a guest post by Patrick Lightbody, most recently of BrowserMob fame (and previously Selenium work, OpenQA, WebWork, and more). Let’s listen in to him talk to us about load testing, and let him know your thoughts in the comments below:

I’ve been developing and testing complex web apps for a long time. I was the co-creator of WebWork (now Struts 2.0) and an early champion of DWR, writing one of the first AJAX form validation frameworks for Java web apps. But over the years, I noticed that as our web technologies and techniques got more sophisticated, our testing techniques were not keeping up.

That was why I founded OpenQA and helped grow Selenium to the popular testing tool that it is today. Selenium helps with functional testing of complex AJAX apps, but there isn’t an equivalent for load testing, which is why I started BrowserMob, a new type of load testing service.

Traditional load testing

In order to achieve high levels of concurrency, traditional load testing tools (both open source and commercial) work by sending large numbers of HTTP requests as a way to simulate many concurrent users interacting with your web page. These tools work by recording the traffic that comes from a browser session and then requiring that the load tester tweak a generated script so that it worked properly when played back X times concurrently.

Common problems would be that the initial recording would embed in cookie values that were tied to individual sessions. Additional unique state might be encoded in other hidden form elements, all of which required some fine tuning after the fact. If you’ve ever tried to run a load test, this is probably a very familiar process. It has worked reasonably well up until recent years, but AJAX has made this process even more difficult.

Ajax + load testing = hard

The reason Ajax has complicated things is that it encourages more logic and state to run inside the browser session. This means that just watching the traffic across the wire doesn’t necessarily tell the full story. The richer an app gets, the more difficult it gets to simulate the exact effects of hundreds or thousands of users hitting your site.

This is the problem I decided to solve when I started BrowserMob. It’s on-demand, low-cost and uses real browsers to completely change the way load testing is recorded and played back.

Do real browsers really matter?

Real browsers absolutely matter. There are two major reasons:

It simplifies the script creation process by letting you avoid all the complexities and hacks you have to do with traditional load testing tools.
It ensures that you’ll see 100% of the traffic and load against your site that a real user would cause.

We’ll look in-depth at each of these topics separately to see how use of real browsers helps and how a service like BrowserMob compares to existing load testing technologies.

Simplifies script creation

In today’s modern web applications, AJAX is just about everywhere. And we’re not necessarily talking about super rich applications like Google Maps or Yahoo Mail, but even simple sites like google.com now use advanced AJAX techniques. See Google’s auto-complete for a real-world example:

In this case, when typing values in to the search box, the web browser executes JavaScript logic that in turn makes AJAX calls to Google’s search engine, asking for search suggestions to display. It does this on every keystroke that the user types in. This is a standard auto-complete control that most Ajaxian readers are very familiar with.

When recording a script with a traditional load testing tool, one of two things may happen here:

The recorder will see the AJAX traffic and capture it for playback in the load test
The record will not see the AJAX traffic and will only capture the request made when the user clicks the “submit” button

Obviously these Ajax requests are causing real load, so we want to make sure they get played back in a load test. Let’s assume you’re using a tool, such as JMeter, that does capture the AJAX traffic. Here’s what that looks like:

The recorded traffic is effectively:

http://clients1.google.com/complete/search?hl=en&gl=us&q=b
http://clients1.google.com/complete/search?hl=en&gl=us&q=ba
http://clients1.google.com/complete/search?hl=en&gl=us&q=ban
http://clients1.google.com/complete/search?hl=en&gl=us&q=bana
http://clients1.google.com/complete/search?hl=en&gl=us&q=banan
http://clients1.google.com/complete/search?hl=en&gl=us&q=banana

Each key stroke by the user is included in each subsequent search term. Let’s ignore the requirement of validating the results that come back from the AJAX requests for the moment (they are usually in JSON or XML format and difficult to validate using most tools). Instead, let’s just add a twist to the load test requirement for doing searches: the load test must search from 100 different search terms.

Parameterization is very common requirement, since it ensures that the load is realistic and doesn’t get cached in any unnatural way. This means that now in addition to searching for the term “banana”, we’re also searching for “apple”, and “orange”, among others.

However, this means your script can’t just blindly submit requests to those previous URLs either, since those were tied to the “banana” term. Instead, they must search for the sequential characters of the respective search term, such as:

http://clients1.google.com/complete/search?hl=en&gl=us&q=a
http://clients1.google.com/complete/search?hl=en&gl=us&q=ap
http://clients1.google.com/complete/search?hl=en&gl=us&q=app
http://clients1.google.com/complete/search?hl=en&gl=us&q=appl
http://clients1.google.com/complete/search?hl=en&gl=us&q=apple

Unfortunately, this is where even the best traditional load testing tools fall down. They don’t provide any help here, so it’s up to you to figure out how to, if it’s even possible, write complex scripting logic that breaks down the randomly selected search term by characters and then subsequently issue Ajax requests for each character in the term.

At this point, you’re basically rewriting the same logic that the web app developer wrote originally. If you’re a QA engineer, this may be difficult since you don’t know all the internal AJAX logic coded in to the application. If you’re the developer, it’s still annoying because it’s tedious and likely in a language other than the original JavaScript that you wrote your code in.

So how do real browsers help?

Because BrowserMob uses real browsers to both record and playback load, that means you don’t have to worry about trying to simulate the logic in a web browser. Instead, all you have to do is record the human interaction with the browser, such as typing in a randomly selected search term. BrowserMob will then pass those instructions on to the hundreds or thousands of browsers participating in the load test, and those browsers will in turn “do the right thing” and issue the proper AJAX requests.

And if the underlying logic, such as the request URL pattern for those AJAX requests, changes? With traditional load testing it’s up to you to detect and fix the problem. If your test uses real browsers to play back the traffic, your script won’t need to change one bit – the new AJAX logic will be run by the browser in real time.

Ensuring realistic playback

We’ve seen how use of real browsers helps with script creation, but what about playback? As we just learned, using real browsers simplifies the process of recording and shrinks the behavior coded in to the script itself. This means we’re letting the real browser – the same type of program your end users will use – make the decisions about what requests to make.

For example, when visiting http://ebay.com you might see the following page:

But reload the page and now you might see this:

Notice a difference? The upper right section has completely different images displayed. That’s because eBay’s home page chooses what to display based on complex and multi-variant logic determined at runtime. It’s quite likely that it’s going to be impossible for a load tester to know which images will be displayed on any given request.

It’s true that some load testing tools will try to parse the pages in real time and figure out which images should be displayed, but that’s hardly comforting once you’ve already learned they can’t deal with even the most simply Ajax components, as we just saw. And as most AJAX developers know, resources such as images and stylesheets are more and more likely to come from complex JavaScript logic and not due to a simple static reference in an HTML page.

Instead, the only way to guarantee that every single object (image, JavaScript, AJAX request, advertisement from an ad partner, etc) gets requested is to use a real web browser during playback. While it is much more resource intensive, it is also a major time saver on both the front-end, as scripts are much simpler to write, and the back-end, as you can be confident that the most realistic level of load was produced.

So next time you hear of load testing happening on one of your Ajax apps, make sure those doing the testing understand the complexities and difficulties associated with testing a complex web app. Help them be on the lookout for the issues highlighted here.

Thanks to Patrick for writing this. Do you have something important to say? If so, contact us with your idea!

I won’t support IE 6 in 2009

vjayblog — Sat, 03 Jan 2009 08:35:51 +0000

At a New Years Eve party, a friend help up a drink and toasted to his company deciding to discontinue direct support of IE 6 in 2009, and letting users know that the site may work better with IE 7 or another latest browser.

Then, Asa Dotzer puts up a chart of the IE 6 numbers:

Still far too high a percentage and enough to make you grown. Also, the last few pounds are the hardest to lose. The good news for me is that on most Web applications that I personally work, and definitely those that I work on in early 2009 will have much different numbers.

Maybe IE 8, Windows 7, and the great new browser war will help, or maybe some percentage is for lost computer souls.

the secret of PHP

vjayblog — Sat, 03 Jan 2009 08:29:48 +0000

So, another “PHP sucks” post, this time from Jeff Atwood. He actually ends up even kind of praising PHP, surprised by its success. I have a couple of thoughts on that topic too.

First, people really need to stop reading something on PHP written somewhere in 2005 (probably about experiences that happened in 2001) and apply it to PHP as it is now, without even checking around for current trends. It’s as if people would dig up books from middle ages saying that there are only seven metals in existence or debating about phlogiston, and would use it speaking about the modern chemistry. Come on!

Then the next thing apparently wrong with PHP is too many functions. Right. Since when? Since when having a lot of functions is a problem? Does it hurt anybody? Does it make writing PHP code harder? Does it make programmer less successful in achieving his goals?
About keywords I could kind of understand – OK, a lot to remember (though I didn’t see anybody really having trouble to remember such complicated keywords as “while”, “if”, “class” or “public”) and it takes out some good English words that could be used as function/method names to confuse the enemy (who wouldn’t want to have function named endforeach() or static(), not to mention function()? too bad those are not available!). But complaining there’s too many actual functions that allow you to do real useful stuff? That is the thing that is bothering people? That is what scares people away from using the language “for years”?

The next beef with PHP is that people write sucky code on it. No, really, they do? Must be something really wrong with this language. It’s not like people write mind-bogglingly sucky code on every other “good” language on the planet. But I get it. The intent was – PHP makes easy to write sucky code. Yes, this is true. As true as “Porsche 997 makes it easy to drive at 100mph into a brick wall”. PHP makes it easy to write various kinds of code – and if 90% of code written is sucky, then 90% of PHP code would be sucky. But my experience says quality of the production code almost never has much to do with the language, but only with the culture – organizational and personal, and with choosing right ways to do the job. The rest is just bad statistics in play. Like “I know 7-year-old writing websites, and his PHP code sucks”. I bet his Haskell code rules though

That’s not to say PHP couldn’t use improvement. It could. And it does, actually – and there’s enough room for improvement still, in many areas. But it probably would never satisfy purists. It’s practical. Maybe it doesn’t allow you to write whole programs in one line of uncomprehensible character soup or play with high-level math theory concepts, but it allows people to write web applications. So they do – so where’s the surprise when one morning somebody wakes up and discovers there’s a ton of web applications around and they are written in PHP?

P.S. I wish for every 50 “PHP sucks” blogs people would write one good RFC.

Blog Goals for 2009

vjayblog — Sat, 03 Jan 2009 08:24:34 +0000

My blog grew substantially during 2008. I gained thousands more RSS subscribers, my MooTools skills took a giant leap, and I even branched out in jQuery a little bit. That said, I feel like the blog just beginning. I’ve outlined some goals for 2009 — any feedback or requests would be appreciated.

1. New Redesign

I’m not happy with the current “design”. It’s too plain and even though I’m not a designer, I think I could do a lot better. I have a new redesign that’s about 25% done that I really love so far and hope to get out by February 1st. I will be giving peeks via Twitter very soon.

2. Walk the Walk

I write a lot of useful MooTools scripts. The problem is that I don’t actually use many of them on my site. My goal is to avoid overdoing my the MooTools “flash bang” effects but tastefully add enhancements here and there. I think people will like the new effects a lot.

3. More Interaction

I’ve recently implemented polls and I’m going to strive to get more of a “community” feel for the site. I may also add a very basic chat feature in the sidebar. I’d also like to schedule a monthly chat session where I’m available for questions about both web and non-web topics. Not sure how many people would be interested in that though. I’ve decided not to implement forums.

4. Continue the Moo-foolery

I want to continue to write interesting and thought-provoking Moo scripts. This includes original works and ports of existing jQuery / Prototype scripts. MooTools has made writing javascript (and subsequent MooTools posts) fun and I hope my enthusiasm for it becomes infectious.

5. Create a Facebook App or WordPress Plugin

I’ve been putting off doing either of these because of the amount of maintenance that goes into them. I don’t want to release a plugin and then let it go to crap. Hopefully I find the inspiration to follow through on creating a great plugin or app.

Web Predictions For 2009

vjayblog — Sat, 03 Jan 2009 08:22:38 +0000

A new year usually brings hope of better things. It also bring expectations and wonder. Here are my (unfounded) web predictions for 2009.

1. A Javascript Framework Will Fall

I believe that a javascript framework will fall in 2009. I really wouldn’t be shocked to see one go. I don’t want to share which I think will fall, but the popularity of jQuery, coupled with the lack of progress being made on a few of them, makes me feel as though at least one will die off.

2. Firefox’s Usage Will Grow Tremendously…

I believe more businesses will steer their employees toward using Mozilla Firefox and thus increase Firefox’s usage. Internet Explorer’s sluggish performance coupled with Firefox’s feature set will make IE a secondary browser for many businesses.

3. …But IE Will Continue Its Reign

Too many users simply take what they’re given and this will not change. Internet Explorer 6 and 7, and on a lower usage level 8, will continue to dominate the browser market share.

4. MooTools’ Popularity Will Grow

MooTools will release a plugin forge which will quickly become a treasure chest that will attract many web developers.

5. Developers Find Out: Knowing One Framework Isn’t Good Enough

While being an expert with on javascript framework is great, developers will realize that knowing one framework isn’t good enough. Porting plugins from a different framework to the developer’s preferred framework will become tiresome and the process of reinventing the wheel will be the motivation pick up another framework.

Have any predictions of your own? Am I crazy? Share!

Read PDF and Word DOC Files Using PHP

vjayblog — Sat, 03 Jan 2009 08:18:38 +0000

One of my customers has an insane amount of PDF and Microsoft Word DOC files on their website. It’s core to their online services so it’s not as though they’re garbage files up on the server. My customer wanted their website’s search engine (Sphider) to read these PDF files and DOC files so that their clients could get at the documents they needed without going through a bunch of summary pages to get them. I was successful in the task, so let me show you how to read PDF and DOC files using PHP.

Reading PDF Files

To read PDF files, you will need to install the XPDF package, which includes “pdftotext.” Once you have XPDF/pdftotext installed, you run the following PHP statement to get the PDF text:

$content = shell_exec(‘/usr/local/bin/pdftotext ‘.$filename.‘ -’); //dash at the end to output it

$content = shell_exec('/usr/local/bin/pdftotext '.$filename.' -'); //dash at the end to output it

Reading DOC Files

Like the PDF example above, you’ll need to download another package. This package is called Antiword. Here’s the code to grab the Word DOC content:

$result = shell_exec(‘/usr/local/bin/antiword ‘.$filename);

$result = shell_exec('/usr/local/bin/antiword '.$filename);

The above code does NOT read DOCX files and does not (and purposely so) preserve formatting. There are other libraries that will preserve formatting but in our case, we just want to get at the text.