Archive for the ‘Coding’ Category

Making Good Progress, but Slowing for Others

Tuesday, April 7th, 2009

cubeLifeView.gif

Today was a good day for my little project. I have been waiting for a few folks to do somethings for me - get data back to me, set up servers, install a little software - nothing that they can't do, but stuff that normally just takes time. It's a little frustrating, but that's just the way it is working with folks. Gotta take time for these things.

I will say that I'm glad to be working with a good QA Team. These folks are actually doing tests on my stuff that I hadn't thought of. Memory profiling as a function of time is a great little thing because my Google AnnotatedTimeLine is not very memory efficient and can crash IE 6 and 7 if you have it up for a while, and while Firefox 3 works, it's the exception on Windows. But these folks are willing (and interested) in doing the tests to make sure that it's reasonably stable. That's great news.

So today was time to put in new features and get things cleaned up while I wait.

They’re Updating the AnnotatedTimeLine (for me?)

Monday, April 6th, 2009

GoogleVisualization.jpg

I was reading the Google Visualization groups today and 'VizGuy' responded that within the week, we should have the ability to set the format of the date/time in the upper-right hand corner of the AnnotatedTimeLine graph as well as setting the format of the numbers in the legend at the top of the graph. This is excellent news! This means that they are listening, and that I'll be able to get the format set before too much longer.

While I realize this isn't a big deal to Google, it's still a good indication that they are interested in moving this forward in response to user inputs. That's just the best news I've had all day.

Now I just need to sit tight for a few days... yup... it's gonna be tough.

[4/7] UPDATE: true to their word, the AnnotatedTimeLine now has a dateFormat preferences value that does exactly what I wanted it to do. I love it. Excellent work, Google.

Fantastic Little Javascript Date Formatter

Monday, April 6th, 2009

SquirrelFish.jpg

This morning I needed to have a nice, simple, quick, date formatter for my Javascript code. Nothing fancy, but since Javascript really only allows you to manipulate the components of the date, and not really format it nicely, something else is needed. So I went 'a Googling. Found something that's really quite nice.

The idea is that with a simple:

  <script type="text/javascript" src="data.format.js"/>

you can then include in your java script code:

  var label = document.getElementById("label")
 
  label.innerHTML = dateFormat(new Date(), "HH:MM:ss mmmmm dd, yyyy");

where you had tagged the date/time field like this:

  <div id="label">this will be the time</div>

What I get in my code is the updated time and date of the last update to the data. It's pretty nice. A little CSS on the div tag and it's looking pretty nice. I have to say, I'm a little surprised that Javascript didn't have this, but to see it in the open source community makes me feel very good about Javascript. It's there, and it's really being supported by the developers.

So... if you need a Javascript date formatter, give this guy a look.

Adding Polish to My Web App

Thursday, April 2nd, 2009

WebDevel.jpg

I have to admit that the process of adding polish to an AJAX web app is a lot like a regular app. Getting users to hammer on it - including yourself, and working to see what you can do to make it better, cleaner, smoother. The goal should be to have it work exactly like the user thinks it should act. Face it, it's a web page with a few widgets on it - it shouldn't require a manual to operate. If it does, then there are big problems.

So today I did a lot of little things - a few to the back-end, and a bunch to the front-end.

Probably one of the biggest things was the addition of the 'resolution' of the display. Face it, there may not bee the need to show all the data points, but maybe so. What I added was a very simple way of compressing the data (averaging points) so that the data looks 'smoother', but retains a lot of the shape of the original curve. It's going to make it more useful as it's footprint on the client will be smaller, and therefore faster to deal with on older machines.

It looks nice.

Wild Internet Explorer 6 CSS Bug – Fixed!

Wednesday, April 1st, 2009

WebDevel.jpg

For the last day or so I've been battling a nasty bug in Internet Explorer 6 (IE 6) when refreshing my Google Visualization widget with a simple Javascript timer. The problem was that for each refresh, the enclosing HTML table would expand horizontally. No joke. For each update/refresh of the widget, it seemed to "push" the div wider, and after a few minutes, it was twice the size of the initial graph.

Makes no bloody sense. But then again, it's IE 6 and I've read enough to know that I should expect a few of these, and to try and roll with the punches and see if I can't get something working.

The original HTML for the AnnotatedTimeLine wigdet was:

  <tr>
    <td>
      <div id="chart_div" style="align: center; width: 600px;
                                 height: 450px;"></div>
    </td>
  </tr>

and when I finally found this article, I realized that it was as easy as adding the overflow: hidden; attribute to the CSS for the div. The result being:

  <tr>
    <td>
      <div id="chart_div" style="align: center; width: 600px;
                                 height: 450px; overflow: hidden;"></div>
    </td>
  </tr>

With this, my updates of the Google AnnotatedTimeLine don't expand on IE 6, and it doesn't mess up the rendering on Firefox 3, either. Nice thing to know.

Holy Smoke! Building Web Sites is Fun Again!

Tuesday, March 31st, 2009

WebDevel.jpg

I've been fine-tuning my webapp this morning, and I have to say that it's a ton more fun to use servlets on the back-end and HTML and Javascript on the front, typical AJAX, than the other schemes I've used. Probably the second best is the Tapestry framework, and there's no reason you can't use AJAX on Tapestry, but the HTML in Tapestry is still going to have to be generated by the server, so it's not as lightweight as the system I'm using, but it's still not bad.

No, I have to say that this is a wonderful little way to put pages together. Certainly, a lot of the credit goes to Google's Visualization API. Without the widgets and the data standard, it would have been possible, but not nearly as powerful and therefore - fun.

Yeah, I think I'm going to have to do a lot more of this and see where it goes. Fun.

Interesting Gotchas with Google Visualization AnnotatedTimeLine

Tuesday, March 31st, 2009

GoogleVisualization.jpg

I have been messing with the Google Visualization's AnnotatedTimeLine widget on my webapp, and while it's wonderful in so many ways, there are a few 'gotchas' that I've run into - and I'm not alone on one of these.

Specifying Column Index in Hiding/Showing Columns

The AnnotatedTimeLine has some really nice methods that allow you to show/hide the lines on the graph (columns in the DataTable):

    chart.hideDataColumns(2);
    chart.showDataColumns(2);

the problem is that the columnIndex that you'd think you needed to pass in would probably be wrong. They are looking for the dataset index and for that, you have to remember that the date data in column 0 of the table is really not considered in this calculation.

So, if you have the name of the column and want to make it disappear, you need to have a function like:

    function toggleView(name, state) {
      var i;
      var colCnt = graphData.getNumberOfColumns();
      for (i = 1; i < colCnt; i++) {
        if (graphData.getColumnLabel(i) == name) {
          // the dataset number is one less than the column number
          if (state) {
            chart.showDataColumns(i-1);
          } else {
            chart.hideDataColumns(i-1);
          }
        }
      }
    }

If you remember to have the right offset, it all works fine.

Showing a Hidden Line Bug

I found a reference to this on the Google Visualization mailing list. It turns out that if you try to show a hidden line, it doesn't work. But if you cycle it twice then it works. Meaning this doesn't work:

    // hide the line on the graph
    chart.hideDataColumns(2);
    // show the line we just hid
    chart.showDataColumns(2);

but this does:

    // hide the line on the graph
    chart.hideDataColumns(2);
    // show the line we just hid
    chart.showDataColumns(2);
    chart.hideDataColumns(2);
    chart.showDataColumns(2);

It's the "second cycle" on the 'show' side of things that makes the difference. This is an acknowledged bug by Google, and the good news is that as soon as they fix it, we're going to get the fix. Nice.

UPDATE: With the 3/30/2009 Release Candidate from Google, this is fixed! Yup, just use the version "1.1" in the google.load() javascript call and you'll set it. It's set to go to production on 4/6, and at that point, version "1" will again get it. Excellent update!

So... just keep these in mind if you're using this widget.

Awesome Day – Loads Accomplished

Monday, March 30th, 2009

cubeLifeView.gif

Today I leave feeling like I've really gotten the webapp into a good place. It's not all done, that's for sure, and I want to fix a lot of things, but it's working. It's got all the features it was supposed to have in it's first cut, and it's ready to show to the users.

It's nice to have a really great day. Get a lot done. Feel like you're a contributing part of the team. It's nice. While today isn't the first time this has happened, it's always nice to have it happen as often as possible.

The app is really close. I can see how it'll finally look.

An Interesting Alternative to AppleScript – JSTalk

Monday, March 30th, 2009

JSTalk.jpg

I've a big fan of Gus M's work at Flying Meat, and this morning I was reading about his alternative to AppleScript - JSTalk. The idea is simple - when creating a Mac app, adding AppleScript support is something most users expect from a high-quality app. But from what I've heard, and Gus seconds this, doing so is not easy which is why not all things you can do in an app can be done within AppleScript. In many cases, it's a limited subset.

So Gus made JSTalk - built on JSCocoa and WebKit's JavaScriptCore, that allows you to write JavaScript and interact with an application on that level as opposed to using AppleScript. He's got a command-line tool, an editor, and a framework for people to put into their apps to allow it to be 'automated' from JSTalk. The examples are compelling. The ideas are pretty sound.

What remains to be seen is how many will adopt it. It's all open source on the MIT license on GitHub, so it's there for the looking, fixing, using. If I had an app, I'd look at using this because there are a lot more people that know JavaScript than know AppleScript. It's just a language that not a lot of folks spend the time to learn.

So I'm going to keep an eye on this... if I make an app, I'll use it. It looks very nice, and all the hard work is done. Glad to see an alternative to AppleScript.

MacVim Snapshot 44 is Out

Monday, March 30th, 2009

MacVim.jpg

There were a few bugs in Snapshot 43, so the MacVim team worked on them and today I got an email notice that Snapshot 44 is out. This fixes various issues with the display as well as the python syntax highlighter.

Glad to hear about it. Got it right away.