sorted by: recent | see : popular

Content Tagged with front + Utility

Steve Souders is launching Hammerhead today at The Ajax Experience.

What is Hammerhead? I kinda think of it as continuous integration for performance. It is a Firebug plugin that you can setup to monitor the performance of your application. Imagine if you add a new feature that you think will speed things up, this tool will let you know how performance was really affected.

There are also cool features when you just want to whip it up on your own Firebug:

Even if you’re not hammering a site, other features make Hammerhead a useful add-on. The Cache & Time panel, shown in Figure 3, shows the current URL’s load time. It also contains buttons to clear the disk and memory cache, or just the memory cache. It has another feature that I haven’t seen anywhere else. You can choose to have Hammerhead clear these caches after every page view. This is a nice feature for me when I’m loading the same page again and again to see it’s performance in an empty or a primed cache state. If you forget to switch this back, it gets reset automatically next time you restart Firefox.

Finally, Steve Lamm posted on the Google Code blog about testing slower connections as well as the high speed one that you are probably on, and the techniques for doing that with Hammerhead.

Steve continues to come up with small useful tools for Web developers. Thanks Steve!

Tom Robinson has built a useful utility, JSON Diff, which gives you a graphical look at the difference.

Changed portions are displayed in yellow. Additions are displayed in green. Deletions are displayed in red.

The visualization is live itself, so you can move around the nodes using the triangles.

Nitobi has released a cross browser debugging script, NitobiBug:

It's a browser-based JavaScript object logger and inspection tool - similar to Firebug. NitobiBug runs across different browsers (IE6+, Safari, Opera, Firefox) to provide a consistent and powerful tool for developing rich Ajax applications.

With it you can:

The location of the window itself is remembered, and if you click on the "show me" link of a DOM debug window, you will see the element highlighted (if possible).

Opera has posted what looks like a great new Web debugging tool Opera Dragonfly which is released in alpha.

Debug JavaScript, inspect CSS and the DOM, and view any errors – Opera Dragonfly makes developing using Opera easier than ever, both on your computer and mobile phone.

Shawn Lauriat has a nice write-up that tells the story:

It offers most of the familiar tools for DOM inspection (along with a nice DOM editing capability), error logging (with the same granularity as before wrapped in a more polished UI), a JavaScript debugger that rivals WebKit's Drosera, a JavaScript thread logger, and a lot more that I haven't explored yet.

Time will tell whether Dragonfly can get enough developers to use Opera and keep them there, and how much the developers behind the new developer tools listen to the community in the coming iterations, but so far this looks extremely promising.

Features

• Reach breaking point step by step: Opera Dragonfly's fully featured JavaScript debugger makes building sophisticated Ajax applications easier than ever. Step through your code line by line, setting break points along the way. This allows you to make sure your application and scripts are acting as you designed them.
• Redefine your style: Its not just the DOM you can inspect. Check out what CSS rules apply to which element, and what rules are inherited or set by browser defaults. Overridden rules are highlighted so you can see what styles are or aren't applied. Support for editing CSS rules will be added in an upcoming version.
• Spot your errors: An improved error console allows you to see, filter and log any errors in your scripts, pointing to the exact position the error occurred. Use this in combination with the other tools to hunt down and fix your site’s bugs.
• Debug the DOM: View source isn’t much use if you use DOM Scripting to alter the DOM. Opera Dragonfly allows you to inspect the updated DOM and all it's properties. Support for editing the DOM will be added in an upcoming version.

The features that are not there yet, but are upcoming, include support for editing of CSS, JavaScript and the DOM, a single window mode, improved JavaScript thread handling, XHR and HTTP monitoring, improved keyboard navigation, and translation into a number of languages.

Have you checked it out? How do you like it?

Vishal Shah has put together TPHP, which stands for "The Perfect Home Page". It is just an HTML page with a bunch of JavaScript in it, that acts as a command line to a lot of things.

You can type in special codes to do smart things like search wikipedia, access domain tools, or what have you.

Of course, this is primitive compared to something like Enso, which was made open source when the team went to Mozilla. It is also now running on Mac and Linux, and it has the feeling that it could be a nice companion to the browser as a command line.

Jon Brisbin is a Java programmer doing iPhone development, and decided to scratch his own itch for a better iPhone remote debugger, creating iPhoneDebug:

The iPhone Debug Consle is meant to give greater visibility and interactivity on your iPhone/iPod Touch while doing development. I grew frustrated having to go through the "include console.log statement then reload" method of debugging. I wanted something similar to Firebug's fantastic console and debugger.

I grew frustrated with trying to debug my iPhone/iPod Touch apps because I had no interactivity with the page. I couldn't interrogate variable values or CSS values unless I put in a console.log statement and reloaded the page. This is far from ideal.

In trying to find something that would fit my needs, I came across Joe Hewitt's iPhone/Firebug integration, but I wanted something more robust and that worked without firebug and requiring "console.log" in the desktop browser.

I'm a Java programmer, so naturally I thought of using COMET and Jetty to pass messages between a desktop browser and the iPhone. A couple days later, I had a workable solution. It lets you log things in your mobile JavaScript to a desktop console, but the biggest plus for my situation is that I can send JavaScript to the iPhone to be executed there, with the results logged back to my desktop console. Just like in Firebug, I can call methods, retrieve CSS values, and all manner of debugging activities I've grown used to doing while building apps with Firebug. There is also rudimentary UP and DOWN arrow command retrieval on the prompt.

Here it is in action, getting commands from the console:

Thierry Parent has released a new version of TraceTool, his open source tracer program, with a JavaScript client.

The javascript TraceTool API is a cross browser (tested under Internet Explorer 6, Internet Explorer 7, Firefox 2 and Opera for mobile) and cross domain tracing solution (maybe the first one). The viewer can be installed on any windows PC (localHost for example) while you are displaying a page from another server. Debuging a Web page from your mobile is very easy. Just configure the TraceTool JavaScript client to use the viewer on the network.

To allow sending traces to another server as the original page (Cross domain communication), the API does not use Ajax (Single domain) but dynamic script creation. Traces are encoded and passed in parameter to the viewer. Large trace messages are split into multiple scripts.

With this API , you can send simple traces, objects , dump, call stack, manipulate traces (sub traces, delete, append,...) and more.

An ideal complement to firebug and a great enhancement to IE debugging with one API for Java, JavaScript, .Net, Delphi, C++ and ActiveX.

WaveMaker has just released a new version of its open source Visual Ajax Studio v3.1.1. It is similar to TIBCO GI, but built on top of Dojo with JavaScript output that is very terse and even looks like something you may have written (which is rare indeed for a tool).

Studio lets users create database- and web service-driven Ajax web applications using a wysiwyg visual designer. WaveMaker helps users create simple applications without any scripting knowledge, while developers can easily add Javascript, HTML, CSS, and Java code to create complex application behavior.

Studio is a web-based application that leverages the Dojo Toolkit to create pages containing widgets and Dojo Dijits. Users drag and drop to create complex page layouts containing the Dojo grid, Dijit based forms, Google Gadgets, and a variety of other included widgets. Developers can even author their own widgets and include them directly in the designer.

A Java-based backend provides access to database, web, and user created services. Applications are deployed in a standard WAR container for use on a variety of Java application servers. For ease of use, Tomcat is included with the installer. It's also possible for Ajax developers to use their own backend with Studio generated web pages.

Wavemaker Visual Ajax Studio is available under the open source AGPL version 3 license as well as a commercial license. Download Wavemaker Visual Ajax Studio at wavemaker.com.

When you start a new JavaScript library, how do you layout the source files, the tests, the distribution files? Do you have support scripts to generate distributions from source files? Run your JavaScript unit tests? Generators to create new unit test HTML files?

This is why Dr. Nic created newjs, a Ruby script that sets you up to do the right thing by your pet project. No longer will you crack open a .js file and slice and dice your JavaScript willy nilly. Instead, you will use newjs to:

• Setup your directory structure for src, tests, documentation, distribution
• Start building unit tests using unittest.js
• Generate test files
• Run unit tests and get nice HTML output
• Package up your src for distribution
• Create a website for your project (wait. is this maven???? ;)

Jeremy Zawodny of Yahoo! just found the YUI Grid Builder that does what you would imagine... gives you a tool to generate your CSS layout.

Will Duff took that and made YahooPages which adds even more WYSIWYG fun.

We all talk about Firebug, which is a fantastic tool for debugging, but there are some others out there. WebKit comes with Drosera, which until now has been hard to get going on Windows (you could build from source).

Now Drosera is in WebKit nightlies on Windows as Kevin McCullough of Apple told us:

Our JavaScript debugger Drosera is available in the Windows nightlies, and I would love to get some help testing and finding issues. Drosera will not work with the Safari beta, but should automatically connect to the nightly it’s downloaded with. Simply use the run-drosera script that’s now included. I’m excited to bring Drosera to Windows and I hope it becomes a go-to tool for your Windows JS investigating, testing, and development.

Do you care? Are you on Windows and have been jealous of the Apple debugging love?

Triggit has created a very interesting tool. The problem they are trying to solve is that many people want to muck around with their websites, but don't want to grok HTML. They want to integrate with services (mash them up in a manual one off way) such as insert their videos from YouTube, photos from Flickr, and other publishing items. One big one is being able to add advertising to the site.

As techies we often think that things are easy enough, "What? You just put in some embed code.... how hard is that!" Triggit allows you to go meta and put in only one embed code, and then offer a toolbar for users to add content in WYSIWYG style.

How does this all work?

When you put in that script code on your site, it has a hook back to the Triggit platform. Say you want to add a photo from Flickr: In the tool you find the photo and place it on the screen and hit save. The action is saved back to Triggit 'add this photo to that location with this style'. Then when a visitor hits the site, the page is loaded, the JavaScript is run, and the action is sent down to the browser and the DOM is changed to add this image. Zach said that one of the biggest challenges was getting this working across the various browsers, so when you put an image at some place using Firefox (the first browser that is supported for the editor side), it ends up in the right place no matter which browser is used from the visitor perspective.

This means that you now have a logical page, but content is split between you real backend, and the Triggit servers. The advantage to this method is that you can integrate with anything. You don't need to have special code that groks a particular backend service, it is all generic.

So, this is a little out there. You are balancing between making it incredibly easy to update pages, and adding complexity by having content in separate places. The page could jump a little depending on the amount of information coming down, if Triggit gets dugg, or what have you. If successful though, you can see as developers that you could write plugins for the system and allow John Doe to easily tie in your content. That is the future promise.

Fancy giving it a go? Zach gave Ajaxian readers 300 invites (as the product IS in beta!). Head over to the signup page and use the code "ajaxian" and if you are in the first 300 you should be good to go. Oh, and for coolness factor, I believe that Rails, Erlang, and crazy JavaScript skills were used to make this happen.

I got to sit down with Zach Coelius and he discusses the product, and gives us a walk through:

I also have a short demo of it running on my own blog:

And, finally, they have their own screencast of the tool at work.

Press Release

Triggit, a San Francisco based startup, with the aim of making life a lot simpler for web publishers, today announced the beta launch of the first ever WYSIWYG web application for integrating third party elements into websites.

With Triggit, any web publisher can now drag and drop advertisements, Flickr pictures, YouTube videos and more, directly into their site without any skills in web programming. Triggit is free to use, and works on any site that accepts JavaScript. It does not require any downloads, access to FTP, or APIs, and installs easily by pasting one small piece of code in the site.

“Triggit is here to help anyone who would like to take full advantage of the resources of the web for their site who isn’t a programmer and who doesn’t think in code,” says Susan Coelius-Keplinger, Triggit’s COO.

At a time when more and more non-technical publishers are coming online, Triggit is focused on removing the complexity of using code to add third party objects to a page. Whether it is widget, a video of a dog skateboarding, or a banner ad, current technology still requires the use of embedded code to integrate these elements into a website. For publishers accustomed to using graphical user interfaces for all their computing, it can be a daunting task to modify and integrate code into their websites. One area where this is a particular problem is for online advertising networks who continue to lose hundreds of millions of dollars of potential earnings annually to web publishers who can’t integrate and optimize their ad units.

Triggit’s goal is to serve as a feature-rich tool whereby publishers can quickly and easily integrate all manner of widgets, content, advertising units, APIs and data from third party sites. In doing so, it operates as a distribution arm for companies seeking to spread the reach of their advertisements, widgets, content and data on the web. By making it easier for web publishers to integrate these objects into their websites, Triggit helps to expand the ability of these companies to reach larger online audiences and add new revenue streams. Ryan Tecco, Triggit’s CTO says “It is really early days for this technology. There are a lot of things waiting in the wings that we haven’t yet put into the tool. We are very excited to see where this goes”.

Aaron Iba has released AppJet, an online IDE for developing simple web apps. You can
write an entire web app (client-side and server-side) in JavaScript, in 1 file of code. We run JS in a virtualized execution environment
on the server and provide free hosting. We also provide an easy JavaScript object database for persistent storage.

The beta online IDE includes a syntax-highlighting text editor (for JS code, written in client-side JS).

This market is becoming interesting. You have tools such as Bungee Labs, and the Google Mashup Editor, showing that you can do a lot of development directly online, and it does seem that this could be a great future. Let a developer build their application, test it, and just hit "deploy"! Done.

AppJet itself was interesting to play with. Although a little rough around the edges, you can see where it is going.

I asked Aaron a couple of questions, and he kindly went into detailed answers:

What are you trying to accomplish?

The short-term goals are to make it easier to get simple web apps
online and make it easier in general to whip up programs that "run on
the web". By making it easier we hope to appeal to both beginners and
experienced hackers. After all, experienced hackers don't like to do
unnecessary work either.

We hope that this will expose the "long-tail" of web apps. There is
no limit to the number of interesting programs that can be written in
100 lines of an expressive language like JavaScript, but often
100-line-program ideas don't get published as web apps because there
is a lot of activation energy required to get a web app online. We
hope AppJet changes this.

Longer term, we want to be a platform for all sorts of web apps. We
have ideas for how to make AJAX programming easier by doing the whole
app in javascript. (We disagree with the GWT approach, because we
think javascript is a better language than Java for writing apps, all
respects to the GWT team whom I know and regard very highly from my
days at Google).

As a simple first step toward client-server integration, we enable
different "sections" of code to appear in the same source file. You
can specify a section of code to be run on the server, the client, or
shared between both. For instance, the shared code is useful for
running the exact same form validation code on the client and server.

Why did we do this?

Mostly, we were sick of all the hassle of setting up servers,
configuring apache, installing MySQL and php and mod_whatever, just to
get a simple web app online. So we largely did this for ourselves so
we could whip up little apps faster. We also think it would be great
if it were EASIER to write a web app than a desktop app. This would
change things: if you're going to write a simple computer program,
then instead of writing it on your desktop and not sharing it with
anyone, you could make it a web app and other people can benefit.

What kind of applications are particularly well suited to this
kind of development?

Right now, simple web apps that require server-side processing and/or
persistent storage. Like a custom sign-up form, basic input/output.
We also happen to be a really good place to prototype a facebook app.
"The Compliment Machine", for example, is a facebook app we wrote and
has been secretly hosted on AppJet for the past month.

Our app server is currently very efficient about serving high QPS, but
our storage system is capped at 10MB, so if a facebook app on appjet
becomes a hit, then it will probably reach the storage limit. We plan
to offer paid accounts with increased storage.

Longer term, I think we'll also become a good place for AJAX apps and
for mash-ups. Right now our mashup support consists of a server-side
wget() function that downloads a foreign URL, but you could imagine
where we could go with this.

Aren't you tied to the platform?

Our business model does not depend on locking people in to our
platform. The primary value we provide is easy, efficient hosting,
but we will also at least release software that lets yo