This morning I saw that the Firefox team has released beta 1 of Firefox 3.6. Seems like quite a lot of little changes, but I'm not seeing the kind of speed jumps in JavaScript that would make it a big deal to me. However, it's nice to see the improvements. Maybe in a bit I'll give it a run, but for now, it's nice to know it's there, but I'll pass for today.
With the recent change of Google's home page to the version with the custom buttons, I've had a problem in that they do not respect the width of the browser and in fact, have a fixed minimum horizontal width to make things look nice. I'm not really interested in seeing more whitespace just so I don't have to see the scrollbar, so I was very happy with this hint about how to effect the zoom factor on the Safari page.
I created the file ~/Documents/defaultzoom.css to contain:
body { zoom: 90%; }
and then went to the Preferences, 'Advanced' tab in Safari, and added this as the CSS page. It immediately resized the pages to exactly what I wanted. Very nice.
In general, I think there's a too much whitespace on most sites, and this zoom 'out' by default makes it easier for me to see more information in less space. Great.
Today has been a real up-and-down day. It started out very nicely when I was able to come back in after a day off helping friends in Indy and see that the work I'd done for the persistent state of the alerts I'd been working on last week was really rather good. I had a few typos in the code, and one logical mistake of not returning the value from a map look-up, but that was it. I was really very happy with the way it was working out.
But that happiness didn't last long.
I got an upset call from one of the bigger users and they were very unhappy about the state of the performance of the updates from the system I inherited. There's not a lot I could think to do about the issue, but I had to dig in and give it a go.
What ensued was a day long realization that not a single soul had solid understanding of several key components of data-access code that I was forced to use. It was frustrating to say the least, and because I made very little headway today, I know I'm not going to be out from under it tomorrow.
Yeah, it went from great to crappy in no-time flat.
On Wednesday I got a call from some old friends in trouble. They were the first clients I had when I opened up my own consulting shop in Indianapolis in 1992. Their $2700 for Beacon an office management system for eye doctors kept us in business for several months at the beginning, and made all the difference (in my mind) between relative success and absolute failure. I owe them a lot.
Over the years, they have called every now and then with some problem that they can't get solved. Maybe it's putting in the first network in their shop, or moving shops and doing it all again, or setting up a back-up system or problems with the program they got about 13 yrs ago to replace Beacon.
VSP became big, and something that could deal with it directly had a distinct advantage. I wasn't upset - I'd had a good run, and now it was time for a better solution to their problems.
So when they called on Wednesday it wasn't completely out of the blue.
Their problems this time were really two-fold: iffy system, and bad support. I can't really do a lot about the first, but I can see what I can do about the second. It's a database system where the developer expected the users to realize it's a database system and understand things like records, tables, forms, etc.
Face it, that's not really something you're going to teach someone on the job unless they are critical to your business. People come and go, and systems like this should not require this kind of knowledge. The system I wrote for them was built in Paradox 3.5 for DOS, which was a database system, but it didn't require them to know it. Just use it like a delivered application.
This is really a different way of developing software. The author expected the users to meet him half-way to the problem. I know better. The best software meets the user right where they are. They shouldn't have to move. That's educational software.
So I'm off to help out friends today. It's a long drive, but in the end, I'll be glad I made the trip.
I saw a tweet this morning from OmniGraphSketcher about the release of 1.1 beta 1 with several interesting new features. I think I'm going to give it a whirl and see how it works. Beta, yeah, so I'll understand the limitations, but still might be nice.
Today I was doing a lot of little things to my web app. Nothing really amazing, but in the end, they added an amazing bit of functionality to the alerting system. I added in the thresholds for each desk so that they can be used as variables in the alerts which means that we can make the system a lot more proactive than it is now when it comes to desks getting near their limits. Adding the variables to the code was easy, and not really amazing in and of itself, but the larger effect is pretty nice.
Anyway... lots of work and not a lot of interesting things to show for it.
I had to do some work today with the Google Visualization Table and no matter how I set it up, if I had more rows in the table than would fit in the vertical space allowed in the enclosing div, we'd have a vertical scrollbar and a horizontal one.
I kept fiddling with the width of the div and the width in the table's parameters, and nothing seemed to make any difference. Then I started to see a pattern: the horizontal scroll bar was there only when the vertical scrollbar was - and it was always scrolling only the width of the vertical scrollbar.
It was as if the vertical scrollbar's width was not being taken into account in the sizing of the table, and therefore, a horizontal scrollbar was needed to display it all.
So how to fix it?
Not so easy, it seems.
It's a known bug by Google, but they have not yet released a fix. Nice.
I started playing around with the width parameter in the table's params:
var tableParams = { showRowNumber: false, allowHtml: true, width: '100%', cssClassName: tableStyles };
and when I used the percentage width parameter I started to see that the calculations of the width of the table were done properly. So, by setting it to '100%', I was able to get the maximum width while also getting the vertical scrollbar when I needed it, and not getting the horizontal scrollbar when I didn't.
Wild, that I needed to set the width in that way.
This is an interesting development. The Amazon S3 system has been online for quite a while, and clients like Transmit and Cyberduck already talk to S3. But it's an object-database. Nice in many regards, but not exactly what someone building an application might be looking for. There are just way too many applications that need a general, reliable, relational database - like MySQL.
While I haven't used MySQL a lot, it's pretty much on par with the other open source databases - DB2, PostgreSQL, etc. It's a filesystem database where it's easy to backup the database by simply copying a few files. Nice, compact, and pretty good performance from what I've heard. I've used it in WordPress installs in the past, and it has always worked very well for me.
What is interesting is that Amazon seems to have broken down the costs so that you really are only paying for what you use. Be it CPU cycles to do the queries, or I/O to get the data to/from you machines. It's a pretty wild idea. If you couple this with the EC2 machines where you can bring up a linux box with your software on it, run whatever it is you need hitting this MySQL database with all the data your app(s) need. They even have a reduced I/O rate for transferring between their servers so that if you really can run the application on their end and have a minimal interaction with it, you're liable to be able to get away with a very inexpensive I/O cost.
Of course, this means that you're paying for the CPU cycles on their end... there is no free lunch. So it's an interesting option. If you need to have a cloud MySQL database, this is the only one I've seen. But the question becomes, do you need it? That's tougher to answer.
I was thinking about Coda and the editor it uses - SubEthaEdit. So I fired it up just to see if they had released a new version of the base editor, and indeed they have. SubEthaEdit 3.5.1 has quite a list of features and fixes including several Snow Leopard fixes. Fantastic news.
This morning I noticed that Panic had updated both Transmit 3.6.9 and Coda 1.6.6. The single note in the Transmit release notes indicates a bug in the replacing of folders. The Coda release notes are a little more extensive with fixes for Snow Leopard as well as a few FTP issues and "minor visual fixes".
In all, it's rare to see these guys push out two updates, but I'm happy they did. It always makes me smile to look at Coda - I'm going to be using it more as I move to Mac-based development of these AJAX web sites, and I'm looking forward to it.