What's it all about, Alfie?

David has released DataGraph 1.5 for Mac OS X 10.5 and the DataGraph Framework. This is a nice little upgrade as it adds several plot types for DataGraph and after the emails we have exchanged, I wanted to get the Framework (again) and look into the 'Real Time' example for ideas about plotting tick data or the simulation results.

He's also got a nice facelift to the icon. 🙂

After playing with the new release I started digging into the Framework and the example code for the real time data. Basically, he's sending a completely new data set to the graphing engine each time. This is a little different than I was looking at, but it's a worst case that shows that even in the case of redrawing 1000 points many times a second, DataGraph can keep up. Very smooth drawing. Impressive.

What I'm going to see if I can do is to take the results of one of my simulations and see if I can get this working on a simple 2D graph. I'm not sure how well it'll work out because the best fit right now would be the electrostatic solver and that's completely 3D, so I'll have to have it plot a slice through the workspace, I guess. Alternatively, hooking it into my FORTRAN code is going to be a little more difficult as that's not even generating any GUI and therefore I'll have a lot more work to do to get that going.

Anyway... fun times.

Several months ago, I looked into a graphing package called DataGraph. It's really good for what it does, and it's exceptionally inexpensive - unbeatable combination. I've been looking for something like VantagePoint for Mac OS X in Obj-C and this was looking like it was exactly what I wanted: it had a stand-alone package as well as a Framework for development and looked pretty nice. The only problem was that it was limited to simply 2D data.

The simulations I wanted to use this on are the electrostatic potentials and shark, my thesis work. The problem with these is that they are really 2D displays of 3D data. There was a more feature-rich product called DataTank, but that was $1300/seat. I wanted something in between - something that had the few 3D mapped to 2D graphs I needed without spending major dollars for this. I asked the developer at the time and (understandably) he wasn't as receptive as he might have been.

So I waited.

I decided to post another request on his message board asking if he'd be interested in this - given that I'm certainly willing to pay a few hundred dollars for this package. Lo and behold, he was interested, and emailed me back. I was thrilled!

I've been talking over a few ideas with him since then, and I'm really excited about the possibilities of getting DataImage (that's what he's tentatively calling it) as it will really enable me to do the work on the simulations I want as well as some interesting financial software that I've been thinking about writing. I can't wait to see what he's going to work up.

In the meantime, he's mentioned a few of the examples he delivers with his Framework and how they work with real-time data. I'm going to check those out and see what's up. Additionally, he mentioned that the communication with DataGraph, and therefore DataImage, is through a BSD sockets layer that he's written and Open Sourced. This means that I can have a look and see what it's going to take to integrate the FORTRAN code of my simulator to DataImage. That will be exciting as well.

Exciting times. Yeah!

OK, I think I'm finally over Photoshop. I ordered Photoshop Elements 6 a few weeks ago thinking that I've enjoyed versions 3 and 4 and gotten a lot of use out of them in the process. I'm not a massive graphics artist - I'm a developer, but there are a lot of times that I need to have tools like Elements, and in those times, it's been really nice to have it in the toolbox.

But with Elements 6 it's a different story. Partly because of what Elements 6 is, and partly because of what's cropped up in the indie Mac community in the interim. For example, Elements 6 takes over the entire screen. Why? I hate that. Be a nice citizen of the machine - use your windows, but don't be so arrogant that you think there's no possible way anyone could want to do anything other than be in your app. Jimminy! That's horrible.

I'm sure it's got lots of features, I haven't even really started looking at it in any depth, but when I look at Acorn and DrawIt, I see two different kinds of apps and I'm much happier using them than Elements 6. I'm sure part of it is because I've changed, and part of it is because Elements 6 has changed. I'll try to get Elements 6 looking and acting like it should, but I'm guessing that in the end it's still going to be more obtrusive than I'd like, and come to realize that it's possible to get in other apps.

Too bad... Elements 6 could have been really great.

I was reading this on Red Sweater Blog this morning and I can agree with the assessment, but I think he's being a little hard on Leo. I'm not sure Leo was advocating that everything for a computer be free, but there was a time that a lot of things were little "ditties" done by someone on their off-hours, and they simply posted it to the 'net and people liked it.

I did it. Lots did it.

It wasn't about making a buck, it was about having fun with the development environment, or the system, or the fun of seeing if it could be done. In the blog terms, it's Pure Charity.

Sure, it's not going to pay any bills, but that's what we did. For the Amiga, it was the Fish Disks - if you made it there, then you were living large. Seeing your code on an ftp site was a reason to be excited not upset. But those were the old days.

I don't disagree with Daniel's point. If you want something of quality, you should expect to pay for it. I do. I don't mind paying for good software, I like having good tools, and I let the people know that I like what they're doing, and when I'd like to see something a little different in the app. Totally agree.

But there was a time - and Leo and I remember it. That time may be gone now, and if it has, then OK. But don't slam the guy because he remembers the days when things were different. Hey, you may not have been around then, or even alive, but they were times, and often times we look at current events through the life experiences we've had. Nothing wrong with that.

Cut the man a break... he's not advocating the death of your industry, he might just be talking about days gone by.

I was reading Daring Fireball this morning and saw this post about using high-level languages to make development faster. I read this and had a few thoughts that didn't necessarily coincide with the original author's or John's. The gist of the original article was, I believe, this paragraph:

We couldn’t afford to keep spending time and energy writing software this way. Even if we could afford it, we didn’t want to spend our time this way. Web applications were being developed at an astounding pace in part because of centralized management and deployment (they never have to maintain different versions for Macs and PCs), but also because they were using modern interpreted languages.

and then he went on to say:

With high-level languages and good libraries, small teams can create great products at a rapid pace. We realized that we could write applications for the desktop in the exact same way.

True, very true. But the trade-offs seem to be completely overlooked. I mean completely overlooked. I don't disagree that if you want to reach a broad commercial audience you have to either go with the biggest audience or you have to try to go cross-platform in some kind of way. No disagreement there.

My disagreement with this argument is Why? Simply, Why? If you want commercial success then you need to be writing for the largest platform out there - Windows. Period. There's no need to write for Macs or Solaris or linux... just write for Windows and you're guaranteed to have the largest audience possible. No need to go any further.

When I started my company with my old friend we picked Windows for this same reason. I was a major Mac fan at the time, but the audience wasn't there. It just wasn't, and making a cross-platform anything was a waste of what little time there was in making it cross-platform. We needed clients, and they had Windows, it was as easy as that.

If you're trying to make something cross-platform, then pick a protocol and use that. I've done that numerous times and it works very well - be that a different OS or just a different language for the different APIs. Yes, it's more work, but in the end, it'll pay dividends and that's the point. If you're looking to make a fast buck, then by all means, write code in perl, python, Visual Basic, or Excel. There are people doing it and making a living at it - I did for 5 years. But that's something that we should get past, not aspire to.

Once you can pay the bills, then you should try to stop doing that kind of coding and get to the point that you take advantage of each operating systems' capabilities. There are things that are understandably cross-platform - the engine of the app, but there are a lot of things that need to take advantage of the differences in the different operating systems. Don't settle... write the best code possible. Don't say "Hey, we can, so we should."

I realize this is easy to say from my point of view, but I was there, and I did that work for years, and it paid the bills, and in the end, it was not emotionally fulfilling and so I left. I found something that was better, and while it's not self-employment, it's allowing me to set the terms of my work. I'm way past my 20s, and I'm looking for more than paying the bills at this point in my life.

Anyway... it's something to read and think about. Is it just about the speed and the buck, or is there more to the art of development that that? I think there is.

I'm not a big file-sharer... in fact, I don't think I've gotten more than three files from the 'net in the last two decades - and those were for digital versions of soundtracks that I already owned - Eddie Izzard. So I'm not a big fan of getting stuff off the 'net, but I never liked the way Comcast was stomping on the BitTorrent traffic saying it was standard network management techniques. Bull Cookies. It was to stop those people that paid for high speed internet from actually using it.

So I was excited to hear this morning that Comcast and BitTorrent have reached an agreement that means that Comcast has opened up it's monitoring software and no longer hinders the BitTorrent traffic that it once did. This agreement clearly indicates that Comcast was doing something, and while it's nice that the two are now working together, it's sad that it was in place in the first place.

So I had to try out my BitTorrent client - Acquisition, and sure enough, it was working far far better than it has been in the past. I was able to get connected to several hosts and search for something from Eddie. It was enough to convince me that they have stopped this silly practice, and started playing it a little more open. Good for them.

Doesn't mean I don't think they are pirates, though.

Today was a great day. One of those days that wasn't restful but boy oh boy, was it a great day.

It started off with my daughter wanting to get into a little stop-motion movie making. Additionally, she wanted to get a decent digital camera as her camcorder is nice but doesn't take stills. So we did a lot of Googling about making stop-motion videos with iMovie, and it sort-of worked, but not really as nicely as we had hoped. The minimum frame delay in iMovie HD was 0.15 sec/frame (6.6 frames/sec) and that was too slow for what she wanted to do.

iMovie '08 was not even that good - stopping at 0.20 sec/frame (5 frames/sec). So we did more Googling and found a site that reviewed a lot of stop-motion software for the PC and Mac. One of the packages they talked about was something we had seen in our Googling - iStopMotion. The web site for the software didn't really jump out at us saying "This is what you need", but we took a chance and got the demo. I'm so glad we did.

This is incredible software. There are three versions and we're going to be getting the middle one for Marie as it looks to have the best combination of features. I'd go the 'Home' version but it doesn't allow you to put in the soundtrack. Yes, she can export the video to iMovie, but there are a lot of limitations she's seeing in iMovie HD and iMovie '08, so we'll go with the 'Express' version and get the soundtrack tools. It's really exceptional.

She can take images with her camera... hook it to her MacBook get the photos into iPhoto... open iStopMotion and drag in the images and fiddle with a few things and bingo! She's got a movie. The software will also control the camera or video camera to do time lapse imaging which is really exciting as well. I look at her with this new medium and she's already made two movies today. Incredible.

The second great thing that happened was my youngest has been a skate board nut for about two years now and has been trying to drop-in for at least a year. We go to one of the two skate parks in the village and she rides and rides with her 'posse' and has a blast. Except for the drop-in. It's just the fear of standing at the top of that half-pipe. So Sunday was another day. We went because she was convinced that this was the day. After about an hour of trying, it was time to go home - no drop-in.

I walked up to her at the half-pipe. I had her just jump off it. No biggie - he's played flag football, been in karate for years, she can do this, but she's scared. So I knew what she needed.

I told her to stand on the board and I pushed her up the pipe, held her, and let her go.

Whew! That worked. Big smile.

I did it again - a little higher this time. And then a little more... pretty soon she was at the top of the pipe. Next was the drop. So I told her to get on the board at the top of the pipe and hold on to me. I held onto the board, she stood on it. I slowly rotated the board until it was sitting, wheels down, on the pipe - all the while she's holding onto my jacket. Then I let it go.

The look on her face after doing her first assisted drop-in was something to see. Tears in her eyes and a smile as big as Texas. These are the moments you live for, as a parent.

We did it a few more times and then it was really time to go. Here's a picture of us walking back to the car, with the half-pipe just on my right shoulder. It was a great day.

I've been trying to get secure SMTP (SMTP with SSL) working with HostMonster for quite a while, and finally this morning I have it all figured out - I think. There are a few parts to this, and the docs on the HostMonster Help Center are pretty close to what you need, but there are a few things that I believe are important to getting this to work successfully.

First, set up the standard POP in Mail.app in Mac OS X. It's pretty simple with the following parameters:

• Port: 995
• Authentication: Password

For the outgoing SMTP you need to have:

• Server Port: 465
• Authentication: Password

Which is all just as the docs say on the HostMonster Help Center. But the trick, I believe to getting Mail.app to work is in the trusting of the certificate that each HostMonster machine uses. Understandably, to save costs, the HostMonster guys created certificates for themselves and set them to expire in 2034. But Mail.app sees that these are not signed by a Trusted Authority, like Verisign, for instance. I don't care about that, but each time Mail.app starts, it connects to the HostMonster machine and sees that the certificate is not from a Trusted Authority, and asks me to agree to connecting anyway.

Here's the trick... when that comes up, ask Mail.app to Show Certificate to get a look at it. Under the name there will be a little check box saying "Always trust machine when connecting to machine". Check that. Then say OK.

At this point, you're not going to get that question on startup of Mail.app, and you're going to be able to use the SMTP/SSL on the host. Now it's possible that HostMonster changed something on their end, but I think from an email I received from the help desk, this is the key.

you would not use password authentication. When enabling SSH you need to be aware that the SSL is self-signed on the server, and many mail programs are going to give you greif about this. They will require that you click accept every time you sent/receive emails.

So what I'm reading here is that the nature of the certificates that they use are that they are not trusted by most systems, and by overriding that in Mail.app, I'm actually able to connect and get the messages sent. I've verified that they are working, which is a great big load off my mind.

I don't trust insecure Telnet/FTP/POP/SMTP - there's just too many people out there that are too smart and too persistent not to write something that can grab anything in plaintext. I just can't see why people would use plaintext protocols when they have secure alternatives. I'm glad that I have this working with HostMonster. Big load off my mind.

I've written about games that have held my interest over the years, and again I have to mention that the game at the top of that list is Risk - on the Mac it's iConquer. It's not fast-paced... the graphics aren't like individual leaves on trees that you mow down with some flame-thrower... but it's a fun game. The problem is more of trying to get the people together.

My kids play the DS, or the PSP, or the Wii - which can be a lot of fun, but it's not the same as a game like Risk. Turn-based, dice-rolling, fun memories of playing with friends in high-school for hours on end. Alliances made, broken... winning, losing, being one of the last two... being one of the first out. It's just an experience with people as opposed to machines.

I guess it's like a lot of things... it's what you bring to the game that makes it special. And on that score, I bring a ton of great memories, and that's what makes it a great game.

Today I was working on loading up my new price injector with the instrument data from the vendor's system and was originally thinking that if they just made their database layer available to me via their supplied shared library, I'd be able to send the query, read the answer and be done. Alas, they don't allow that.

But what they do have is a stand-alone app that takes a file with a request in it and can generate a file with the output of the command. I was a little concerned about how it'd all glue together, but I shouldn't have been. C/C++ really does have just about everything you could ever ask for in a language, and interfacing with stand-alone apps is no exception.

I was able to build the command, execute it to a temp file that I then read after the command was done. It wasn't as clean as it could have been, but it really wasn't that bad either. Thank goodness that all I had to do was get a list of instrument data.

So in the end, my concerns about the clunky nature of this interaction was really much ado about nothing. C++ made it much smoother than I was afraid it was going to be. Then again, when we fill up disk space and the output file can't be written, I might be singing another tune. But that's for another day.