podcasts that rock

I got my iPod Nano a few weeks ago. The thing that has surprised me a bit is that I haven't listened to very much music on the thing at all since I got it. Instead, I've become enamored with podcasts. I had played around with a few before I got my Nano, but never really got into them. Now that I can transfer them to a portable player, that's about all I listen to anymore. Here's the ones that are currently at the top of my listening list.

The Daily Source Code with Adam Curry
TavernCast
TWiT (This Week in Tech)
Otaku Generation
Dot Net Rocks
Mondays

In addition, I've become addicted to the video blog / podcast phenomenom that is Rocketboom, even though I don't have a video iPod.

I don't have the time left to actually listen to music on my iPod! :)

immutable arrays

I've had a problem for months that, until now, I thought was impossible to solve without writing my own custom code to handle it. I've always wanted to have an immutable (or read-only) collection class. This is quite useful for exposing collections as public properties, but not allowing clients of the code to add, remove, or otherwise alter the collection. To provide good encapsulation, you should most often create methods on the object that contains the collection, so that the container object knows what's happening with the collection it contains. This corresponds to the Encapsulate Collection refactoring.

I've searched Google and every .NET resource I know several times, and it seems many other people have the same problem I do. As luck would have it, I was poking around in the .NET framework using Reflector, and was actually starting to roll my own immutable collection. It was then that I realized that System.Collections.ArrayList has a few static methods that I never noticed before. One of these is exactly what I need: ReadOnly(ArrayList) : ArrayList. Other useful methods I discovered were Adapter(), FixedSize(), Repeat(), and Synchronized. Each of these methods creates collection objects whose types are inner classes to ArrayList.

While I am very thankful that I finally have an answer to my problem, I do have a few gripes about this. Why are these nested classes of ArrayList instead of being more visible outside of the ArrayList class. For that matter, most of these methods take either an ArrayList or the more generic IList. The ones that take ILists create different classes than the ones that take the ArrayList. Why then, are these more generic classes in particular included as nested classes of ArrayList? They don't really have anything to do with ArrayList necessarily.

Of course, what this means now is that I have the nagging urge to go scour my previous code and refactor all those public collection objects in order to encapsulate them. That oughtta take a good long while...