Pathfinder Blog
Topic Archive: Tools

Some Very Modest Good News on Advertising and Ajax

Dietrich Kappe, Thursday, February 28, 2008 @ 5:31 pm

Every month I check in on the state of advertising and Ajax. Nielsen has ditched the page view, but they've really shrugged their shoulders at how to measure traffic for advertising purposes on Ajax-enabled web sites. To make things worse, even Google, a pioneer in many things Ajax, is mum on Ajax and Adsense. Just search through their help forums for all of the unanswered questions on how to make Adsense work with Ajax sites. This deafening silence on Google's part (not even a "don't do it"), leads me to believe that they are either working on a solution but don't want to tip their hand, or that they are just as out to sea as everyone else.

So, the modest good news is that some people are working to solve the measurement problem. In the case of search recommendations, Baynote measures interest in the targets of search results, then reranks those results based on that interest. In other words, if someone goes to a search result, scrolls through the page, leafs through a couple of DHTML tabs, etc., then they probably found the page interesting. If, on the other hand, they only spend a second deciding that the page sucks, then go back to the search results, then they probably found the page uninteresting.

Continue reading »

Topics: , , ,

agile ajax Agile Ajax

The Desktop is Gooey

Noel Rappin, Monday, December 10, 2007 @ 4:44 pm

Dietrich observes the following at the GWT conference:

BTW, many of the developers at the conference seem to be Java geeks who resent their JavaScript brethren and don't want to get left behind when the Ajax bus rolls down the corporate highway. They also applauded "hating the browser with all my heart."

And...

about 100% [of attendees] had some background in desktop GUI's, (AWT, Swing or SWT)

I don't want to make to much of the sample size (most of the participants at Rails Edge were Java refugees, and I'd guess that, like me, a lot of them had desktop GUI experience). Still, this isn't a surprise, right? GWT brings a Java desktop GUI programming experience to the web, if you are already a Java desktop GUI programmer, that's very appealing. GWT is clearly great structure for bringing existing Java desktop applications to the web.

I always felt that one of the reasons why HTML and the web became so appealing was that the extremely low barrier to entry when compared to desktop GUI libraries. (This is one reason why first HTML and later, Flash, beat out Java applets -- they were just much easier to write for the most common tasks.)

Despite HTML's flaws as a layout engine, getting something on the screen is really easy. You don't need to learn the entire Swing object model and event model. This isn't exactly a fair comparison, I guess. But HTML's biggest strength -- managing variously styled text -- is something that is a massive pain in the neck in most traditional GUI systems. That's why so many toolkits have adopted a subset of HTML as a markup system for labels and static text.

It might be true that HTML just feels easier because most web application are, even now, less complex than desktop applications. Still, even as complexity increases, I've always found it much easier to manage layout in HTML/CSS than in Swing layout managers. I find that even easy layouts are hard to mange with any precision in Swing. I've been much more likely to wish that I had HTML or CSS kind of structures in Swing than I've wished for Swing layout managers in HTML. And that's without even counting the fact that Swing, and GUI layout code in general, is notorious for being a tangled mess.

I still think, that there's a middle ground between HTML and Swing -- something like XUL or Flex, combining the best of HTML's easy-to-get-started textual structure with the power of a full object system.

Topics: , ,

agile ajax Agile Ajax

Developer’s Notebook: Mastering (your fear of) regular expressions

Brian Dillard, Friday, September 28, 2007 @ 8:17 am

Regular expressions are one of the most difficult programming concepts for novices and journeymen to wrap their heads around. Take a look at most any blog posting about RegExes and the comments will invariably be littered with words like "hate," "pain" and "AAAAARGH!"

Once you get comfortable with them, though, regular expressions become one of the most powerful tools in your programming arsenal. For Ajax/JavaScript developers, they can lend power and elegance to everything from form validators to keystroke interpreters to JSON, CSS and DOM parsers - in short, many of the thing you'll want to do on the client side of any powerful webapp. Take a look under the hood of any respected Ajax/DHTML library and you'll see RegEx literals being used liberally.

It's no secret that I'm big on programming books, especially O'Reilly ones, but I can think of few books that have been more useful than Jeffrey E. F. Friedl's "Mastering Regular Expressions". One difficult aspect of JavaScript regular expressions is their syntax, which is completely different from the better-known Perl variety. Friedl steps back from the implementation details of individual RegEx engines to explain the central concepts common to them all. After having this book for a year, I still refer to it so often that I can't say when I'll be ready to graduate to Tony Stubblebine's "Regular Expression Pocket Reference." In the meantime, when I'm away from my copy of the Friedl book, there are plenty of online resources to guide me.

Cheat sheets & quick references

These links don't offer really in-depth tutorials, but they do show you the JavaScript RegEx syntax at a glance.

Interactive terminals

Apparently, everybody and their mother decided to build a little DHTML/Ajax app to let you create regular expressions, run arbitrary text against them, and check out the results. This is a fantastic way to play with the technology and get more confident in your abilities. Here are 9 different implementations of the same basic idea. I haven't used all of them, so let me know in the comments which are most useful.

And for the over-achievers

For those of you so advanced in your RegEx powers that you've hit the limitations of the built-in JavaScript implementation, check out XRegExp, an open-source regular-expression library that supports named capture and other advanced features.

Technorati tags

Topics: , , , ,

agile ajax Agile Ajax

IE6: The zombie browser

Brian Dillard, Wednesday, September 5, 2007 @ 5:45 am

Paul Graham's much-dissected essay Microsoft is Dead offers some witty and perceptive analysis, but it sidesteps the fact that Microsoft's rotten corpse will take decades to decompose. In the meantime, we still live in a world where most people trawl the Internet with a Microsoft browser. I've already linked to Kevin Hale's perceptive essay On the Tenacity of Internet Explorer 6, and I've already covered Eric Meyer's useful techniques for taking advantage of IE7's power while continuing to support IE6. But I've got a few more links to add to Dietrich's and my back-and-forth about the state of JavaScript tooling. I regularly stop by the IEBlog the same way I keep tabs on the neighbors I don't really like but have to live near. They recently added a more in-depth post about Ajax View, a pretty cool profiler that they'd previously covered along with other IE development tools earlier this summer. In a previous post, I surmised that most front-end developers code for Firefox first, then put off their Safari/Explorer testing till the end. Maybe if IE tooling continues to mature, we'll see less of that.

Topics: , , , , ,

agile ajax Agile Ajax

The awesome state of JavaScript development tools

Brian Dillard, Tuesday, August 14, 2007 @ 6:14 am

Dietrich's post on the depressing state of IE develpment tools got me to thinking about the generally wonderful state of JavaScript tooling. Compared to just a few short years ago, we've got a wealth of productivity-enhancing browser add-ons, TDD frameworks and static-analysis tools at our disposal - most of them open-source. For those who want to get their hands dirty writing POJ, this is a golden era.

Like most developers, my code circa 1998 was filled with commented-out alert() statements. I spent way too many hours cursing IE4's inability to report accurate line numbers in its error dialogs. I relied heavily on Netscape's built-in debugger. Within a couple of years I had graduated to a primitive logging utility that spawned a separate browser window and output messages into it using simple DHTML. At the time, it seemed like a huge advance.

Then came the Firefox era, with its host of disparate add-ons. You could edit your CSS in the sidebar, selectively disable JavaScript and CSS, inspect the DOM .... Once again, the possibilities seemed endless. Now, thanks to Firebug, most of my grab-bag of browser add-ons are gone. Firebug is so powerful and wide-ranging that the only other add-on I use regularly is the venerable Web Developer Toolbar. Yahoo's new Firebug extension YSlow adds some really useful optimization benchmarks to the suite. When a plug-in begins to spawn its own plug-ins, you know you've got a winner.

I'd be interested to know, though, what kind of process UI developers use to debug their JavaScript. Most of us are using similar tools, but how are we using them? (That's an invitation to jump in on the comments, folks.) Every UI person I know develops prototypes in Firefox and Firebug, crossing his or her fingers that there won't be too many implementation-specific issues to tackle in the other browsers. Many rely on a logging utility - heir to that long-ago popup window - to grind away at any such browser bugs.

But beyond that kind of hunt-and-peck debugging, have we arrived at an industry-standard practice for client-side code maintenance? Who's doing true TDD with one of the flavors of JsUnit? Who's using Selenium to test their entire webapp in the browser? Who's picking apart the details of their syntax with Douglas Crockford's JsLint? Who's busting out Fangs or another accessibility test tool on a regular basis? The tools are out there. It would be interesting to know who's using them, and how.

When you're banging your head against a wall trying to figure out why a certain DOM element won't return the same node type from one browser to the next, it's easy to see why there are a hundred competing Ajax frameworks promising to solve all your cross-browser issues for you. Let's just remember how far we've come - and how important it is for real-deal UI developers to maintain the skills that they've honed for over a decade. The more trust we put in frameworks, the more helpless we'll feel when our code fails and we've lost the ability to figure out why.

Topics: , , , , , , , , , ,

agile ajax Agile Ajax

>Fiddler2 Beautifier Plugin

Dietrich Kappe, Thursday, August 2, 2007 @ 5:36 am

You can never have too many good tools for browser-side development. I don't know if you remember fiddler, a nice http proxy that let you inspect XHR and other calls. Very handy. Of course, it has been superseded by a fiddler2. It's a product of the .NET world, but hey, a good tool is a good tool, and lord knows that when we leave the world of Firebug we need all the help we can get.

Fiddler2 takes plugins, and Michael Schwarz has developed a nice Javascript beautifier that expands and pretty prints obfuscated Javascript code. Nice. Check it out.

Fiddler_jsbeautify_0

Topics:

agile ajax Agile Ajax

About Pathfinder

  • We design and build extraordinary applications for companies looking to make the next great idea a reality.
  • learn more

Topics

Blogroll

WordPress

Comments about this site: info@pathf.com