Blog, Steven Roussey, Blog!

TIDE – Truly Integrated Development Environment

a year ago by sroussey
Tags debugging ide

For too long the IDE has been separate from the target. That is, the IDE is running its own process, and the code written in it is running in a separate one. I don’t mean to say that this is bad on a technical low level. It is as it should be. I mean from the user experience point of view. And nowhere is that more true than web development.


WE-TIDE – Web Enabled TIDE: The two beasts are so separate for web developers, that completely different tools have emerged. On one hand are the traditional IDEs, like Eclipse and Komodo. Others are in the runtime, like Firebug and Web Inspector. As a Firebug developer, I see requests for saving changes from Firebug back wherever the source is. Many people don’t even know what or where the source is. They might be using WordPress or some other CMS or shopping cart software, and don’t know how the CSS and HTML gets created. They are sometimes surprised to hear that Firebug doesn't know either. But it could…


More importantly to the developer community (that does know where the CSS file is located on a server), neither the IDE nor the runtime knows anything about what you are really doing. It doesn’t know what “Design Patterns” are. It doesn’t know how deployment changes code from the IDE to code in the browser. It is far from an “Integrated” development environment. Even further from an “Intelligent” development environment.


ME-TIDE – Mobile Enabled TIDE: It gets worse in mobile web development. There is no built-in runtime support like there is for a shipping desktop browser. They are stripped out of the mobile versions (generally for good reasons). Not that those companies that make mobile browsers have to develop in such a way. (For example, in an iOS device, go to Settings -> Safari and notice there is an entire Developer menu – but with only one item. That is counter to all the Apple UI guidelines. You just don’t get access to the other items.) There are solutions with various levels of fidelity, however.



“A good player goes where the puck is. A great player goes where the puck is going to be.”

or

“A good developer is using a toolkit. A great developer is using a framework.”


So how do we turn the TIDE? Two trends will force a sea change in web development, and they will strain the current toolset like never before: Mobile, and HTML5 localStorage. Why? Because both push business logic to the client. Latency (including the infinite variety: offline) is a big deal on mobile devices. And, honestly, speed is always an issue, even on the desktop. To handle these issues, data needs to go to the client, and get processed there. Dealing with business logic on both the client and server is a big driver behind node.js, where you can share such logic between both the client and server.


Now developers have to deal with design patterns on the server and the client. The IDE must deal with two runtimes, two debugging interfaces. And the IDE must deal with code changes that affect the next run, and code changes made in the runtime while running. It has to deal with desktop and mobile. It has to deal with code, and it has to deal with design. Getting started on a new project should be so easy that mockups are not created with a different tool. A mockup is working code. Tweaks to design in Firebug should not need to be rewritten on the server. Web Inspector is improving the connection between live styles and source css, for example. But we need integration. We need intelligence.


We need a rising TIDE that floats all boats. I’m doing my part. I have a plan. Who wants to help?
   
   
   
2 Comments
Read More

Debugging Closures: Part 2

a year ago by sroussey
Tags debugging

A while back I discussed debugging closures and, I must admit, I figured Google Chrome would have fixed the issue by now, what with their fast release cycles and all. Nope. Enter Firefox 4.0 beta: yes, it is fixed (and not just their really awful bug that made using Firefox a burden when debugging -- they fixed all instances). Sadly, FF4 is so broken as far as debugging is concerned that it is not much consolation at the moment. But that will change eventually, and definitely (I assume) by the day it ships in March (my guess). So gantlet thrown Google. Sheesh. As a big consumer of your own tools, you would think this wouldn't even be an issue. 

When FF4 ships, I'll update with a Part 3. Unless there is a more interesting development before then...
   
   
   
0 Comments
Read More

Firebug 1.6.0 Released!

a year ago by sroussey
Tags debugging
So we got Firebug 1.6.0 officially out the door today! Here are some helpful links:



And Honza has a bunch of blog posts about specific features, these two are the most noticeable (more found in the release notes):


As for Firefox 4.0... don't expect too much. Perhaps with Firefox 4.0beta8 things will get better, but the plan is for Firebug 1.7 to be released concurrently with Firefox 4.0 next year. The Fx4.0beta7 update changed the JS engine to JaegerMonkey, which currently doesn't allow debugging. Oops. Not much we can do but wait for new APIs from Firefox and support them in Firebug 1.7.

DOWNLOAD!
   
   
   
0 Comments
Read More

Quick Peek at Illuminating Dojo

a year ago by sroussey
Tags debugging dojo illumination
Right clicking to find and inspect something in the Illumination panel of Firebug:

              Illumination-dojo-contextual-2010-11-13_



Looking around at various widgets, selecting one to see some info on the side properties panel, and the mouse is above it so it is highlighted in blue in the page itself:

 2010-12-10_2255.png


[Edit: 12/11/2010] Here is an example of the Events/Connects side panel

 2010-12-11_1325.png
   
   
   
1 Comment
Read More

Illumination and ExtJS

a year ago by sroussey
Tags debugging extjs illumination
Firebug 1.6 is almost ready for release, and before it goes final I want a few more people to start using, playing with, and testing my extension to Firebug 1.6 called Illumination for Developers:


It makes Firebug know all about ExtJS. And it is very very handy, and so let's discuss a few of the features:


Object Naming

It presents ExtJS objects in a smarter way. It recognizes what they are and shows the whole name, like "Ext.DataView" instead of "Object" in the console and the other Firebug panels. And instead of random properties being appended, it looks for a ID-ish and a Value-ish property to show. This gives you an idea what you are looking at when you are debugging. See the example without and with Illumination:

Illumination-console-2010-11-11_1201.png


Element Highlighting

Now, when you hover the mouse over the Ext.DataView above, it will highlight the component on the page. In the case above, the coder didn't give a descriptive itemId or name, so hovering over it does the trick -- it shows you exactly what that object is all about. This works for Ext Components and for Ext Elements. It even works for Ext Composite Elements -- it highlights all of its nodes on the page!


Contextual Menu

When you right click on an element in Firefox, Firebug adds an "Inspect Element" menu item to open Firebug and bring you to that element in the HTML panel. Illumination does the same sort of thing, but tries to find the best match: ideally some sort of UI widget, else an Ext Element.

Illumination-contexualmenu-2010-11-11_12


Illumination Panel

There is a new panel added to Firebug called Illumination, and when you use the contextual menu above, this is where it brings you. The Illumination panel is the place to inspect ExtJS objects: Widgets (usually derived from Ext.Component, but not always), Data (Ext stores, records, fields), and Elements (Ext.Element and its brethren). These views show the hierarchical structure of your code:

Illumination-2010-11-11_1334.png

It really takes some playing around with all of the above to get a feel of how useful and fun debugging can be again. Try this example page and look at the DataView, inspect the Store (use the side panel to see its records!), and generally browse around. Have fun!
 
   
   
   
0 Comments
Read More

Debugging Closures

a year ago by sroussey
Tags debugging

When you ask a web developer what browser they use most often when developing, you will likely here Firefox followed by Chrome these days. When it comes to debugging closures, a common thing when using module design patterns in JavaScript, those two browsers really bite.

In particular, Firefox 3.6 is really really bad. The older Firefox 3.5 and the current Chrome are just kinda bad. You would have to go back to Firefox 3.0 or switch browsers altogether to get something that is developer friendly on this particular topic (and note, I am just speaking to this topic when I say that, I'm a developer of Firebug for Firefox after all).

Let us take a simple example:

<!DOCTYPE html>
<html>
<head>
<title>Test Case Closures</title>
<script type="text/javascript">
// Similar to firebug test case for issue 2871
function obj()
{
    var _this = this;
    var www = 'asdasd';
    var www2 = 'correct';
    this.ttt = 'asd';
    this.closure = function()
    {
        var w = www;
        var t = _this.ttt;
        rrr = 5;
    }
    setInterval(this.closure, 2000);
}
function init()
{
    var a = new obj();
}
</script>
</head>
<body onload="init()"></body>
</html>

Let us assume that the closure function has an error -- that w is getting the wrong value. Should it be set to www or www2? What are the values of each? Let's look in Firefox 3.6 with Firebug and set a breakpoint on line 16:

 

Firebug-closure-2010-10-25_1159.png

Ick. Let's try it with Chrome:

Chrome-closure-2010-10-25_1201.png

From the two example above, you can see that some closure variables get "Reference Errors" as if they were not defined. If you used them in the closure function, the values would get set, they are really there after all.

Now both of these browsers totally ignore the www2 variable. No www2 for you! Firefox 3.6 will not even let you see the value of www even though w gets set correctly! Obviously this is not the way to help web developers debug their applications.

For reference, Firefox 3.0 would let you see both variables (www and www2). So does IE8. And IE9. And Safari 5. And Opera.

The thing I find most odd about all this is how people at Mozilla and Google would not notice this. Particularly Google, since they are a big creator of JavaScript content applications on the web. If anyone is listening, give us our www2!
   
   
   
0 Comments
Read More