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.
Once again, there's a raft of security fixes necessitating a new release of Firefox. Seems reasonable, but it's amazing the number of security fixes that there are these days. Maybe it's the increased attention each platform is getting, but I have to wonder if it's not, at least in part, due to sloppy coding. Sure, it's a complex bit of software, but still...
Oh well... it's easy enough to update, and so I do - for all the obvious reasons.
Today I needed to set up Tomcat for servlet development and aside from Tomcat itself, the biggest challenge was in getting the new web app set up properly. It wasn't that bad, really, it was just a lot of moving parts with no error messages to speak of to let you know you had the moving parts hooked up wrong. For instance, I made the silly mistake of having my web.xml file in the root of the /web directory in my project. It was supposed to be in the WEB-INF directory in that directory. Without it being in the right place, nothing was seeming to work. But there were no errors indicating my mistake.
While I can understand that this is a user error - I did eventually figure out my mistake, there's nothing to say "Hey, here's a web app with no web.xml file" which would have put me on the right track a lot sooner.
Once I got it all set up properly, things seemed to flow pretty nicely. I was able to get a lot of good work done, and by the end of the day I was very close to a working prototype. I'm guessing by the end of this week I should have the first good cut all done. That will be a great relief.
It's all in the configuration. Watch it.
I think everyone that's looked at the Google Finance page knows the really nice time-series graph that Google puts up on that page to show price history with annotations. Well, today I spent some time checking to see if it would be possible to use that in some time series viewer we're making at the Shop. Turns out, there's an entire API and widget set built around the Google Visualization API. Amazing.
The API is really pretty simple, and they give you a few reference implementations as well as the exact results you need to return for a specific query. But in essence, it's a table of data and then it's up to the widget to take that DataTable and turn it into a nice looking visualization. They even make a toolkit to bridge these to Java - which is a big plus.
The test code is simple, easy to follow, and after a couple of hours of reading, it was very clear to me that this was going to be an ideal way to partition the data-generating back-end from the front-end visualization. Oh sure, I have more reading to do, and there's plenty of coding yet to do, but my goal is to put some kind of in-memory database, backed by a SQL database, in a Tomcat instance and then put this request/response on top of that and then slap the GUI widgets in a simple web page on top of that.
It's clean, simple, and most of all - beautiful. Let's face it... the visualizations they have already done are nothing short of stunning.
So I'm going to be going down a road that I haven't spent a lot of time on - Javascript and Google APIs. I think it's going to be an interesting ride.
This morning Marc Liyanage tweeted that someone had used his build process to build PHP 5.2.9 for Leopard and posted it to Marc's web site. I downloaded and installed it and when I tried to run my old info.php I was surprised to get nothing:
<? phpinfo() ?>
When I checked Marc's website I saw that hist test info.php was slightly different:
<?php phpinfo() ?>
Trying that, it worked like a charm. I'm wondering if that's something in PHP 5 that I have been missing up to this point in time. I'll have to check and see what my other PHP scripts have to say about the matter.
Yup, it's the default setting on PHP - to require the 'long form' of the script start. It's configurable in the php.ini file, but that's a little dangerous as there might not be this setting in the web servers it runs on, etc. So I went through all my PHP code for the North Hollow Farm site and fixed it up.
[3/15] UPDATE: OK, so I took the time this morning to clean up the North Hollow project and then repoint the workarea to the right repository on frosty. It was a little bit of a hassle, since I hadn't touched this since I got it off my SGI box, but still, it was not horribly hard. Now I have something that works with the default PHP install and the PostgreSQL database is permissioned for the user _www as opposed to the older www. Minor change, but a pain to figure out.
There's a pretty decent lightweight word processor called Bean out there for the Mac, and I noticed today that ver 2.2 was just released. The real advantage of Bean is that it's less than Pages, but more than TextEdit, and reads/writes Microsoft Word docs pretty nicely. It's not spectacular, but it's a wonderful little tool for a niche that so often goes unnoticed by the major players.
I saw a tweet from Wil Shipley about problems with the socket communications, and I felt for him... it's not a lot of fun getting your socket library working with all the problems that can arise in networking code, and Gus Mueller tweeted that he needed to look at BLIP. So I took a little look-see and realized that for Mac OS X, it is probably something I need to look at deeper.
There are a ton of things to remember to make a socket library work well in all kinds of conditions. I've spent the better part of a year getting one written in C++ for both linux and solaris - where the differences are really more striking than you'd expect, and I know it's not easy. So I'm all for making use of something that's already there - assuming it's written well, and flexible enough to allow me to do what I want to do without having to sacrifice something in order to work with the library.
BLIP looks to be a pretty nice system. It's written in ObjC and meant to work with the Mac OS X frameworks. There are classes for listening and connecting, for sending and receiving packets of information... it looks pretty good. It appears to be designed for the primary activity being information request/response, and that's nice as it's a big chunk of what I do, but there's also the more interactive things (chat) and FTP, and such. All nice to have in a toolkit.
Like I said... I need to give it a second look.
This morning I saw that Firefox 3.0.7 was released and so I updated it on my laptop. I'm sure it's just another round of 'security and stability' enhancements, but hey, I use it every day and I might as well be as secure and stable as possible. There's no reason to tempt fate and ask for problems.
It's still not as nice as the new Safari 4 Beta, but hey... they don't have all the Apple developers working on it either. I have to say, Firefox is nice for compatibility, but Safari is the best browsing experience I've ever had.
A little while ago, Marc Liyanage looked at the ClickToFlash and saw that it was straight ObjC, and with that, he embarked on writing an ObjC plugin for Safari that views XML in a manner similar to how IE shows it - formatted and stylized. The result is XML View Plugin 1.5.
The result is pretty darn amazing:
There's also an automatic updater, as well as the ability to modify the style with CSS and Javascript. Pretty impressive, I must say.
I don't use XML a lot, but when I do, it's really nice to have something that will format and display XML nicely.
As part of migrating from my old MacBook Pro to the new one I got today, I did an 'svn update' on the CorePlot repo - just to see if anything had changed since I'd put in that fix for the Core Animation NSDecimal encoding issue. I was surprised, and a little saddened by what I saw.
Virtually all the changes I'd made were gone. All the comments - Gone. The files looked exactly like the skeleton files I'd seen in the project. I had no idea that's what Drew thought was done. I didn't. Not even close.
Drew's checkin comment was pretty insightful:
Reduced the interface of new CPPlotRange class to make it 'minimal but complete'. Also removed a lot of commentary in the class, which wasn't really necessary, and just made understanding the class more difficult.
Removed the function 'CPMakePlotRange'. It was a quasi-initializer for the old struct, and has been superseded by a class method.
While I understand the comment minimal but complete, I don't think that's what Apple does on it's - init methods. There are a ton of them taking all different kinds of (relevant) data types: double, NSDecimal, NSDecimalNumber - all were valid in this case, but Drew has decided that only the NSDecimal one was needed.
Furthermore, I don't agree at all with his assessment of the comments. I'm clearly a comment-focused person. I live it every single day of my professional life. But it seems that Drew is of the belief that code should be simple enough to be self-documenting, and that's something I simply cannot work with.
So it makes me sad to say that I have no further desire to work with, or even use the CorePlot framework. I respect Drew's ability to do what he wants, but he's going to lead it down the path of a poorly documented pile of junk in a few years. I'd rather stick with commercial and live with the licensing issues and costs. In the end, Drew isn't going to take any real responsibility for the code, and yet he's completely unwilling to see the value of good, solid, commenting.
Too bad.