James Skemp's StrivingLife

There's a difference between self control and killing something off.

Self control is when you hunger for something, but say no. Killing something off is when you no longer hunger for something.

The former is a near-constant struggle, depending upon how often the hunger makes itself known, while the latter is, once the desire is killed, relatively easy, except perhaps during moments of rememberence. Trying to remember what it was like to have a hunger/desire of a particular sort, can be, at times, more painful than the desire itself.

That's not to say that the hunger can't be temporarily killed off. While attempting to satisfy the hunger it can die off. One either continues through the motions, stops, or tries to determine why the desire has disappeared. Which is worse, in such a case, must depend upon the particular circumstances at the time.

I may get to some of these early, but here's a listing of things that I'd like to get done in July 2009. For the most part, they are technical things.

Speed-up my iTunes Playlists to Xml application. The generation of the Xml output takes longer than I would like, and if a DataTable makes sense, it would be worth caching the playlist so clicking on the playlist again doesn't cause another, slow, load. Xml generation also shouldn't freeze the entire application. It seems a BackgroundWorker will resolve this issue.

7/4/2009: iTunes Playlists to Xml 1.3 has been released, and resolves the apparent freezing of the application, during Xml generation.

Have a beta version of Log Parser Plus available for download. (Not completely equal to the site, but it does use the same base application.)

Continue working on the iTunes Sync application (ratings and play count).

Continue working on the iTunes wrapper.

Or, instead of the last two, work on a way to manually update ratings and (more importantly, since it can't be done inside iTunes) play counts via an application.

Work on a new XSLT from the iTunes Playlists to Xml application, one that uses jQuery (?) for sorting, and would allow for both grouping by album, artist, and or song.

Look into whether it's possible to extend the iTunes application (for that play count updater).

7/4/2009: Doesn't appear to be possible, at this point, based on a number of searches on Google.

Get two virtual machines, one with SQL and one without, setup and running so they can communicate, and then document how I did it.

Document how to work with the Log Parser DLL.

Document how to work with iTunes from C#, using the simple example of an application that shows the currently playing song, and allows you to see what played, as well as what's next. Version information is very easy to pull out as well ...

Install CollabNet Subversion on a Windows Server 2003 (supported) and/or Windows Server 2008 (not supported?), and document the process. Probably won't be able to work with it at work this year, but ... maybe I'll setup a virtual server and use that for all my Subversion needs (putting it on a new or existing HP Pocket Media Drive).

7/3/2009: Installing CollabNet Subversion Server 1.6.3 and TortoiseSVN 1.6.3 on Windows Server 2003

Most of these will stretch into August, September, and etcetera, but ... there's nothing wrong with having goals.

While working on a new version of my iTunes Playlists to Xml application, I've been playing around with the existing code, for consolidation and speed.

While looking at memory usage, I played around with the StringBuilder I'm using to create the Xml output. As part of this I tried using Remove, once I had output the Xml, but experienced a large increase in used memory, after doing this.

StringBuilder someSB = new StringBuilder();
someSB.Append("Some data" + System.Environment.NewLine);
someSB.Append("Some more data" + System.Environment.NewLine);
// Trimmed
textBox.Text = someSB.ToString();
someSB.Remove(0, someSB.Length - 1);

This jumped memory usage, on a pull using the defaults, against a 6460 item playlist, from ~17,000 to ~21,000 K, on my up-to-date Windows Vista Ultimate machine. Keeping the Remove() off, or just setting the StringBuilder to null, resulted in no jump of memory usage.

In the past I've used System.Text.StringBuilder.Remove(), thinking it would decrease memory usage faster, but it seems that's not the case.

I don't care all that much to discover why, at the moment, but if I decide to look about, I'll update this post or add a comment.