Tips

Let’s say that you’ve been working hard on this really awesome data structure. Its fast, its space efficient, its immutable, its everything anyone could dream of in a data structure. But you only have time to implement one function for processing the data in your new miracle structure, so what would it be? Ok, not a terribly realistic scenario, but bare with me here, there is a point to this. The answer to this question, of course, is that you would implement fold. Why you might ask? Because if you have a fold implementation then it is possible to implement just about any other function you want in terms of fold. Don’t believe me? Well, I’ll show you, and in showing you I’ll also demonstrate how finding the right abstraction in a functional language can reduce the size and complexity of your codebase in amazing ways. ...

Tentatively subtitled: “How scale can make fools of us all” This is going to be a real life war story…cause I haven’t done one of those in a while, and this particular case really ticked me off. Here’s the scoop: I’ve got a “service” which is called by other parts of the system. And by “service” I don’t mean something running in its own process and waiting for SOAP/REST requests or messages, I simply mean something that has a defined entry point (a static method in this case), where you pass in some data, and get something back. ...

If you happen to be one of the many people in the unfortunate situation to be stuck working with TFS source control on a daily basis and gaze longingly at the folks using Git or Mercurial wishing you could have some of that distributed goodness for your very own self, I am here to tell you that all is not lost. There are a couple ways you can work with a distributed version control system along side TFS and try and reduce the pain associated with TFS. One way I wrote about here as an answer to a question on StackOverflow. This technique worked fairly well for me dealing with a small codebase with only a few branches. However, it became unmanageable once I started working in an environment which had a large TFS repo with several different branches that I needed to switch between on a regular basis. You can read about some of the issues I ran into within the updated section of the answer, but overall things got messy quickly. ...

I ran into this odd problem recently working with some Linq2SQL based persistence code. There is some code someone put together to commit a list of changed entities to the database as part of a single transaction, which simply iterates through the list and performs the appropriate action. The problem I was having was that I had an object referenced by another object that needed to be persisted first, otherwise there was a foreign key violation. To add to the strangeness there seemed to be some magic going on (most likely utilizing the INotifyPropertyChanged goodness), so that even if I tried to persist just my dependent object first, both were still showing up in the list, and always in exactly the wrong order. Now, I’m okay with magic. Magic makes a lot of things a lot easier. The problem arises whenever the magic is incomplete, and doesn’t follow through to take care of all of the operation. Its like someone comming up to you and saying “Pick A Card”, at which point you do, and put the card back, and they say “I know what your card was” and walking away. Not real convincing. This is what was going on here. There was the smarts to know that changes were being made to more than one entity, and there were even attributes to define what properties contained dependent objects, but no smarts to actually deal with a case when you would want to save more than one object in an object graph at a time. ...