The exciting life of a software developer and nerd
I wish ASP.NET MVC and NHaml existed a year ago when I started my last ASP.NET project. I am in love with the simplicity and elegance. At first, I was worried about losing some of the power of Web Forms. I was way off.
I created my first MVC + NHaml application (CRUD for one model) in a few hours. The same can’t be said for the learning curve of Web Forms. And it is 100% unit tested.
I see much blogging in my future regarding these too libraries.
I have read over Scott Hanselman’s Tool List at least a dozen times. The first time I read it, I saw that Powershell was on his top 10. I knew a little about Powershell from Exchange 2007 but hadn’t taken any time to look at it.
About a month ago, I had to write some server maintenance scripts. Things like deleting files older than X days, SQL Server maintenance, etc. These tasks were perfect for scripting, so I picked up a Powershell book and went to town. It took a while to pick it up, but my overall impression of Powershell is wow. Powershell fills that void in the soul of Windows that developers hate. Now scripting in Windows doesn’t have to involve Cygwin and Perl, even though Perl will always stay close to my heart.
Powershell combines the ease of scripting with the power of .NET. It is a loosely typed language that can work with strongly typed objects from .NET. For me, it boils down to scripting objects instead of text. In Bash, grep and awk had to be used when parsing the output of any program. In Powershell, the output of a program is usually an object, which is much easier to work with.
The following line sums up why I love Powershell. It deletes files older than 14 days in a directory. While this is a trivial example, it is so simple, and so elegant.
gci c:\directory | where { $_.LastWriteTime.AddDays(14) -lt [DateTime]::Now } | ri
public interface IRepository<T> { T Get(object id); void Update(T entity); void Add(T entity); } public interface IEntity { object Id { get; } } public abstract class EphemeralRepository<T> : IRepository<T> where T : IEntity { private IDictionary<object, T> storage; public EphemeralRepository() { this.storage = new Dictionary<object, T>(); } public T Get(object id) { return (this.storage.Keys.Contains(id) ? this.storage[id] : default(T)); } public void Update(T entity) { this.storage[entity.Id] = entity; } public void Add(T entity) { this.storage.Add(entity.Id, entity); } }
The data layer can quickly become a time sink, especially since the amount of change in a new project is so high. There isn’t much value to spending time coding it initially. It is going to change, and you will have to update your repository, schemas, mapping files, etc.
I know I am not the first to offer this advice, but I think reinforcing it is important.
I am playing around with S3’s REST library for fun. I started writing the request signature code and quickly realized something, the .NET HttpWebRequest object doesn’t allow the date header to be set. You can’t send the Date header. No matter what. Unless you implement your own TcpClient…
Am I missing something? Does this make sense to anyone? Encapsulation doesn’t mean restricting behavior, it means restricting knowledge of implementation details. Maybe Microsoft had a reason for enforcing this behavior, but I would like to at least know about it.
Luckily, Amazon supports the alternative x-amz-date header.
The past few days, I have been playing around with mirroring on SQL Server. Even though there is a GUI to guide you through setup, it isn’t that easy until you understand a few things. I won’t go into details since there are tons of great resources to help setting up mirroring, I will just point you towards some of those resources.
Once mirroring has been setup correctly once, the next time is a lot easier. I would highly recommend creating deployment scripts that can set up your entire DB environment because SQL Server setup just has too many steps that are easy to forget or miss.