Well, this morning I read about an exploit for WordPress 2.8.3 that allows a user to change the admin's password, and effectively lock them out of their own account. Pretty nasty stuff.
Thankfully, SimpleScripts had WordPress 2.8.4 ready to go and I was able to quickly update my installs to the version with the fix. Whew!
Well... when I left last evening, I left my system in a less-than-perfect state: if you restarted the web app in the middle of the day, it's possible that you might not get correct firm totals for P/L, etc. Why? Because it was based on a table trigger, and if you didn't get new rows, they weren't being counted. That's not going to work when some data sources send data only during fixed times of the day. Crud.
And while it's true that I don't restart production mid-day very often, it's still not the sign of a really good app to restart poorly in the middle of the day. The problem was, properly restarting mid-day was a real problem.
First, the firm totals needed to be stored on each alert - thankfully, they already were. Why? Because the alert could be an 11-point moving average filter or a 31-point moving average. In these cases, the firm totals will be different because of the different smoothing employed on the raw data. So it's got to be "local" to the alert.
Second, the firm totals needed to be updated for all incoming data. Initially, I had first checked to see if the portfolio was one of the ones I was interested in, but that was a mistake. I needed to update the firm totals and then filter on the appropriateness of the portfolio. That was a simple fix, so no big deal.
Finally, it's how the data needed to be fed into the alerts in order to get them primed for action on the restart. If there are n alerts, then we need to push n copies of each portfolio. Doing this at the alert level means there's a lot of hits to the database, and while that's logically reasonable, it's not a good plan as the number of alerts grows. So we need a different plan.
This morning I came up with a plan that seems to be working quite well.
In the alert controller code, just after creating all the alerts, I'm going to look at all the portfolios that have sent in data so far today. I'll then look at all the alerts and ask them how many data points they need, add one to that, and know that this is the number of "recent rows" in the data table I need for each portfolio.
I'll then run through all the portfolios, get the maximum number of rows I'll need from the table, and then feed those into each of the alerts, one at a time. Of course, I'll limit the data I feed any one alert to be that which is needs, but there will be at least one that will need all the data I've obtained, and that's not bad. Then, I'll be able to use this to calculate the firm totals for each alert.
What's interesting is that this process is really quite fast. One database connection, and to the H2 in-memory database at that. Most of the pulls there are less than 150 msec. in duration (yeah, I timed them in the code), and then pushing the data to the alerts is really fast as it's all just a bunch of data structures.
In the end, I have firm totals that survive a mid-day restart quite nicely. I'm more than a little pleased that all this work took no more than three hours. I was expecting quite a bit more. Nice surprise.
Well, this morning it was time to reboot my laptop after updating Safari in Software Updates. The release notes talk about the typical round of security fixes and stability enhancements, but this time they also include fixes for logging onto iWork.com and a few non-maintenance things. Sounds reasonable, even though I haven't used iWork.com, they're making progress, and that's good enough for me.
Within the month, I'll probably be getting Snow Leopard, and that will bring a lot of little changes - not the least of which is a much faster system. Looking forward to that.
I can't believe it, but Naperville is getting an Apple Store! Opening August 15th, 10:00 am, I'll have an Apple Store on the way home - or any time I want to hit downtown Naperville.
This is the most amazing news. I just can't believe I'm lucky enough to have one so close to my home. I know Liza won't be thrilled, as it'll mean more trips to the store, and that will mean more purchasing of Apple stuff, but that's the cost of progress.
What a lucky break!
After I had upgraded to Git 1.6.4, I decided to take a little bit of time and push up one of my projects to the gitosis server I have set up at home. It really was as simple as the gitosis docs say: you set up a project in the gitosis.conf file, commit that and push it back to the server, and then push your project to the server. From then on, you'll be able to sync with that server and you're done.
Simple.
OK, maybe not simple, and maybe not exactly easy, but with some notes, it's very reasonable to do and takes only a few minutes. First, get a clone of the gitosis-admin project:
git clone git@git.themanfromspud.com:gitosis-admin.git
and add in the new project, and possibly new team to the gitosis.conf file witin the newly cloned project:
[gitosis] [group gitosis-admin] writeable = gitosis-admin members = drbob@sherman [group myteam] members = drbob@sherman steve todd writeable = Spill MServer
where I've added the [group myteam] section with the users and projects indicated. Then I can simply put this all back up to the server with:
git commit -a -m "Added new Team for Projects with Steve and Todd" git push
and then we're ready to push up the projects.
Simply create the project:
git init
put all the files in there, commit them, do all that normal stuff, and then push it to the server with:
git remote add origin git@git.themanfromspud.com:MServer.git git push origin master:refs/heads/master
and it's done!
At this point, you can pull and push changes to and from the server and you'll not have to hassle with this ever again. It's all linked in. Very nice.
One of the editors that I want to use, but just isn't there - yet, is SubEthaEdit. It's collaborative features and vision of being lightweight and fast are things I want to use, but there have always been a few things that BBEdit or Vim does better and I can't seem to get behind using SubEthaEdit over either one of those.
Well, this morning I noticed that SubEthaEdit 3.5 was out, and I certainly upgraded to see if any of the things I needed were included in the update. Sadly, the big feature improvement is code-folding, and while that's really neat, I've never really used it - regardless of the editor. I've had it in many editors, and I just prefer to see all the code as opposed to seeing just the highlights and then "pop open" a section to work on it. I can see the value, I just never got used to it.
Old School, I guess.
So it's nice to see the update, but it's still not there - quite yet.
Given that I've looked at Mercurial and decided against using it as my main distributed source control system, and my version of Git was 1.6.0.2, I decided to update to the latest version of Git which was 1.6.4 on my laptop, my Intel iMac at home, and my gitosis server at home. It was just time for an update. Plus, I've read that the newer versions have pulled quite a bit of the old wrapper code into the C codebase so that things are more compact and faster. All around, it looked like it was time to upgrade and get on the latest features.
The updates for my laptop and iMac were easy because there's a Google code project for a Git installer for Mac OS X. It's as easy as downloading the package, installing it and running with it. Sure, there are a few things that you might want to do if this is the initial install of Git, and I've documented these previously. But an upgrade is easy-breezy.
The update for my OS X 10.3.9 box, frosty, at home is about as easy. Again, since I've built 1.6.0.2 on it before, it was as simple as:
curl -o git.tar.gz http://www.kernel.org/pub/software/scm/git/git-1.6.4.tar.gz cd git-1.6.4 ./configure make sudo make install
and we're off an running. Yeah, the docs aren't updated, but that's documented in the previous install, and I use my laptop for docs more, anyway.
Getting gitweb updated was pretty simple - just like the original install and it's in the Git distribution. One thing I liked about this time is that I'm a lot more savvy about the use of CSS and layout, so when I updated the code for gitweb, I fixed up the HTML for the gitweb header to be:
<div style="margin: 0px 0px 0px 0px; width: 100%; background-color:#2f2f9d;"> <img src="/icons/repository_title.gif" alt="Dr Bobs Repository" width="344" height="61"/> </div>
so that I get a nice looking header that renders a lot faster than the old TABLE HTML.
In the end, it's been about 30 mins all-told, and we are up to the latest Git at 1.6.4. Not bad at all.
Today I was looking at the fact that my old WordPress passwording scheme was not looking the way it should - clearly from lack of updates and support, and so I went on a search for a better plug-in for password protecting my blog. What I found was Members Only which is a nice plug-in that requires that users have accounts on the blog to read postings, and presents them with the login box if they go to the URL for a posting. Once the authentication is done, it's back to the requested page for a minimum of fuss. It's nice in that it's tied into the regular WordPress accounts. The old one had a single password and to give that to everyone wasn't really a good plan. Better now that I can have accounts and allow them to maintain the passwords, etc.
It's going to make it a lot easier to maintain the blog while allowing those people I know to be able to read the posts without exposing myself to any unnecessary legal exposure. It seems like a very nice balance.
This morning I noticed that many of the traditional news feeds were talking about this:
and I have to agree that the thread of profit for a URL shortening service is not clear to me. While it's possible to track the creator, the target URL, and the hits on that 'shortened' URL, it's not clear why this would be a service that others would want to pay for.
Sure, I can see why a web-based service might want to have URL shortening in it's arsenal of features, but to pay someone else to do this, is a little odd to me. Of course, if they had been able to get a dominate API or enough mindshare - like Google, then I can see it being more of a 'defacto standard'. But that didn't happen because the barrier to entry is so low.
But the cost of maintenance is high: you've got to have a ton of bandwidth and a ton of storage if you're going to be any good at this. So the costs are there, but that's about it for the barrier to entry. The rest is a little script and you can hack that together in a short time.
No, this is Natural Selection at it's best - the weak are weeded out and the strong survive. We don't need a ton of URL shortening tools. Just a few - at most. But for all those people that have these URLs in their blog posts and search pages, it's going to be a mess clearing out the bad data and replacing it with good. It would be nice for someone to take the database and the domain and keep this going - but that's the point of the notice. No one wants to pay for it, and that's why it's shutting down.
Which, of course, is why I don't use URL shortening save when an app does it for me - Twitteriffic.
Well, Liza got her wish and she and I found a gem of a dog at the Humane Society of Plainfield today. Panda (the name given to her by her foster Mom) is a 5.5 month old Black Lab and Australian Cattle Dog mix (they believe). Her birthdate was listed as Feb 21, 2009 and she was the most amazingly calm and well-behaved puppy I've ever seen. She's exceptionally social, and just wants to be around people without really being underfoot.
This picture of Panda and Marie was taken during a 'typical' moment in the house. She's loads of fun outside with our large yard. She's fast, enjoys playing chase and fetch, but also just loves laying out in the grass and investigating her environment.
We had a 5 gal bucket on the deck filled with water for her, and she loved it. She would dunk her head, something they have said we should expect as her background is heavily into water and she's not at all afraid of it.
She's bonding well with Nina and the rest of the house. She's not having any problems with Cole, our 3 year old cat that we rescued two years ago. They seem to allow each other to exist and don't really pay much attention to one another. In the future, I'm guessing they'll be fine with each other, but it's great that now they don't fight.
Panda is a big puppy - 40 lbs, and very large paws. She's going to be a big dog, which is exactly what Liza wanted. I can understand it, she's a Farm Girl, and she misses the big, fun loving, dogs that she grew up with. She says it's for the kids, but we both know that Panda is for her. This is the little missing piece of her childhood that she wants to have back in her life.
I can't blame her, who wouldn't want a little slice of wonderful in their lives. We all need to have a few things to hold onto when the times get rough, and she certainly deserves this as much as anyone. I'm glad Panda has started out live in our house on such a great note.