What's it all about, Alfie?

Today I had a few minutes, and I wanted to spend a little time messing with the CSS on my work WordPress blog because the CodeHighlighter plugin I'm using is great if the background is white, as this guy is, but it's not so great when the background is black - like the YellowJacket theme for WordPress.

The problem is that I wanted a simple <pre> tag to have the same foreground/background color scheme as the regular text - not the code-ified version that the CodeHightlighter uses. So I had to be a little tricky with the CSS... but in the end, I got it.

The trick for me was to realize that the CodeHighlighter really just set the class of the <pre> tag to the language (give or take). So, if I added those specific tags to the CSS for the theme, I could make the code <pre> tags different from the other <pre> tags and that was the ticket. Trying to make the 'standard' <pre> tag different was a waste - and never got me what I wanted.

So, the CSS looks like this:

  pre.java, .sql, .c, .cpp, .css, .bash, .python {
      font-family: 'Luxi Mono', 'Courier New', Courier;
      font-size: 90%;
      line-height: 100%;
      background: #fff;
      color: #000;
      border: 1px dotted #ccc;
      padding: 0.2em 0.5em;
  }
 
  pre {
      font-family: 'Luxi Mono', 'Courier New', Courier;
      font-size: 90%;
      line-height: 100%;
  }

With this, I can get the code segments with a white background so they look nice with the CodeHighlighter, and at the same time, I get my simple <pre> tags looking like they fit in with the rest of the text. Nice.

UPDATE: I decided that I liked it so much, I saved off my copy of the theme to my WordPress home on HostMonster. Now I don't have to worry about losing it. Sweet.

UPDATE: Another thing to note: Don't put the <pre> tag on a line by itself if you're using a 'language' option. It'll put in an extra line at the top and bottom and thus space out your code more. Keep it tight.

A developer stopped by today asking me about a problem he was having using the BKBaseGraph as it was saying it couldn't lock the dataset for the change - a nasty exception. I got his code which had a section like this:

  private void initGraph() {
    try {
      curveGraph = new BKBaseGraph(0, 1, BKBaseGraph.LINE);
      graphPanel.add(curveGraph, BorderLayout.CENTER);
 
      int pointCount = 10;
 
      // display the points in the graph
      curveGraph.resizeData(pointCount, 1);
 
      for (int row = 0; row < pointCount; row++) {
        curveGraph.setData(row, 0, (Math.random() * 100.0));
        curveGraph.setRowLabel(row, "" + row);
      }
    } catch (Exception e) {
      e.printStackTrace();
    }
  }

The problem comes in line 3 when you are trying to create a zero-row dataset. That's no good. You have to have non-zero rows and columns - default to nothing and let the graph figure it out. For example, it's better to simply say:

      curveGraph = new BKBaseGraph(BKBaseGraph.LINE);

and let it go at that. Alternatively, if you know the numebr of rows, as it appears is the case here, you can put that in and skip the resize alltogether:

  private void initGraph() {
    try {
      int pointCount = 10;
 
      curveGraph = new BKBaseGraph(pointCount, 1, BKBaseGraph.LINE);
      graphPanel.add(curveGraph, BorderLayout.CENTER);
 
      // display the points in the graph
      for (int row = 0; row < pointCount; row++) {
        curveGraph.setData(row, 0, (Math.random() * 100.0));
        curveGraph.setRowLabel(row, "" + row);
      }
    } catch (Exception e) {
      e.printStackTrace();
    }
  }

Either way works, but don't put the zero rows or zero columns.

He came back to me and asked: OK, but how do I display no data on the graph? Well, there are methods on the BKBaseGraph that handle that:

      curveGraph.hideGraph();
      // ...
      curveGraph.showGraph();

the first hides the graph behind a blank white JPanel, and the second brings it to the front. This is useful if you have a lot of updates to do, or you simply want to say "no data - no graph." Simple as that.

I saw today that HostMonster had the update from Fantastico for WordPress 2.6.2 - and I needed to upgrade. These upgrades have become very routine - but the first few were real nail-biters for me. Thankfully, the Fantastico guys know what to do and the upgrades have been flawless.

Now we're on the recent version of WordPress and that's good to know. I have to say that getting an account on HostMonster was an excellent move for me. I can't imagine having a better hosting experience.

This morning I saw that VoodooPad (Pro) 3.5.2 was released with quiet a few fixes and enhancements - some of which are getting the application ready for 4.0 (I've read on the Flying Meat support boards Beta testers are already being sought out).

VoodooPad is the self-Wiki, indexed, free-form database with search capabilities that can form the basis of a nice help-system that you create yourself. I use it to put in all kinds of things that I need to be able to get at occasionally. I know that if I had time, I'd take about a week and put in a lot more, but those docs are OK for the time just being text files and I can search them.

The Pro version has several nice features, and most importantly, it supports the indie Mac developer that goes to all the trouble to make this available. You have to support good work, or there won't be any.

Overly dramatic? Possibly. On target? Dead on.

These last two days have brought a point to light with this product we're trying to integrate into the Shop that is a show-stopper, and we didn't find it out until a week and a half from the completion of all development related to the major deliverables.

Basically, it's insufficient for our needs and we didn't see it until we're virtually done and have spent literally dozens of man-years on the integration. It's like building a car only to find that it's engine is too small to actually move the chassis, and no way to make it bigger.

Major problems.

The vendor is all but saying "Sorry, that's the best we can do for you", and the management tram is scrambling because they know the next question that's going to be asked is "Why didn't you see this coming?" Good question. I wonder why they didn't.

Oh, hey, I know... because they no longer value judgements here - only answers to questions they phrase and then they make the decisions thinking they have all the knowledge necessary. After a while, we stopped trying to do, and moved into a simple reactionary phase. That's all they wanted anyway.

So now we're all sitting on this train... too late to get off, it's a week before the deadline. No way the vendor is going to supply a fix, they've known about this from another customer for 18 months and done nothing about it. Nope... it's a train wreck, all right, and we're stuck on the top of it.

Well... at least I'll have a good view of the fall.

A developer came and talked to me today about the colors of the default second Y axes when using VantagePoint 4.6.4 (the last one I have that allowed this feature) as it defaulted to lime green. Not the ideal choice, I'll agree. So I dug into the code and realized that in my setAxesColor(Color) method on the BKBaseGraph, I set the colors of the X and Y axes, as well as the second X and second Y axes - but only if it was a Hi/Low/Vol graph. That was the mistake.

So I changed it to always set the second Y and then optionally the second X if it was the Hi/Low/Vol graph. Works great. After that, I got to thinking that it'd be even nicer if it allowed the axes to be set independently, as well as collectively. So I wrote the methods and added the applet param tag decoding to deal with the axes independently, and then collapsed the code into a more manageable set.

In the end, I have a lot better coverage of the capabilities of the graphs, and still defaults to something very reasonable for the quick graphs that will be used 90% of the time. Nice.

OK, I'm not a big "pictures leaked" fan, but if this is true, the Kindle has taken a major step backwards. The photos show a much wider Kindle with a larger keyboard (totally unnecessary in my opinion) with a much larger border all around the unit. This is in stark contrast to the new Sony eReader that was announced last week. The Sony is sleek with a touch-interface, and far more compact with the same fantastic screen.

If the photos are true, then I can say that the first generation Kindle is far far better than the second. I can honestly say that had the new Kindle been the only Kindle when I was looking to buy, I would have passed. It's just too big and clunky.

Which is why I hope it's just a rumor. Please, let it be a rumor.

Over the weekend, DrawIt 3.6 was released, and very quickly, it seems, 3.6.1 and 3.6.2 were sent out to address specific problems found by the first few users. I saw this just this morning, and I just got the 3.6.2 update. There are a few significant changes in this codebase - primarily the exclusion of the pixel editing features. Rather, they opted for a cross-licensing agreement with the Flying Meat crew to give you a license to Acorn for those features, and then allow a 'shell out' feature in DrawIt so that the integration is smooth.

I realize the need to specialize, and if you're not that good at one thing, take advantage of the fact that someone else is. Acorn is something that I use daily, and to see that DrawIt is acknowledging that as well is nice, and providing a clean interface to it even nicer. I don't see this as loosing something from DrawIt - as gaining a nice integration to Acorn.

That you get a free license, is nice, but I've already got licenses. No harm.

Two great products. Now specializing in what each does best. That's a great Mac tradition. Keep the faith, Boys! Gotta love it.

This morning I got notice on the mailing list that the MacVim team has released Snapshot 36 to fix the problem in Snapshot 35 of dropped characters when they are input too quickly. Seems the developer was tinkering around with changing the input queueing of the keystrokes, and it ended up dropping things. He fixed that up and also took care of several memory leaks.

Excellent work. I continue to be amazed at the level of integration they are doing with Vim on the Mac. Love it.

This afternoon I was trying to measure the partial, intermediate results of something that we're trying to improve the through-put of on a Vendor's package, and I realized that the data I was looking at was really only good in relation to itself - I'd hit on one of the coolest things in Quantum Mechanics: The act of observation alters the system.

I hadn't run into it like this before, but under independent tests, I know that a singular blob could be processed in a little more than a second. But but placing in the outputting of timing results, I saw the combined time raise to roughly three seconds. That's a factor of three. Then it hit me.

You can imagine the issue: by stopping to get the time, more time was taken. Not a lot, but it added up. Fantastic! Thankfully, I didn't require absolute accuracy - I just needed to know the relative times spent on succeeding steps. For that, this was more than good enough. But it was a kick in the pants to see it happen right in front of my eyes. Sweet!