Wordpress has been nagging at me to upgrade for a little while, and I finally got around to it. I’m getting more comfortable with shell scripting, and thought that I should script this upgrade process.
I put the script together basically mirroring the manual upgrade instructions given on the Wordpress website. I’ll show you the script, and then walk you through it.
When playing around with ASP.NET membership, I found myself in a situation where I wanted to mock the ASP.NET Providers. This is something the design of providers makes non-trivial. Mark Seemann summarises: “Since a Provider creates instances of interfaces based on XML configuration and Activator.CreateInstance, there’s no way to inject a dynamic mock.”. See Provider is not a pattern.
I followed with some interest the debate around the “mass assignment vulnerability” recently reported in Rails. I dislike the way the whole debate is couched assuming access control at the model level. When you are stating that an attribute cannot be assigned, you are stating that to assign this attribute from the controller, you can’t use the normal update_attributes method, and must update it explicitly.
Wordpress.com wanted to be able to read, update and post to my Twitter account in order for me to authenticate as a commenter.
I extend my previous T4 work to be able to “Duck Type” using a number of interfaces, generating a file per interface.
Duck typing is an interesting concept, and alien to C# generally. But using the techniques of my previous post about T4 and Entity Framework, it is possible to have your entities implement interfaces if they have the required properties, resulting in behaviour similar to duck typing. Please read the previous blog post before reading this one.
All my entities for a current project have a UserName column. I used T4 templating to generate a common interface and an implementation for each entity class.
The application I am currently working on has a requirement to audit which application user last created or updated database records. I used the ObjectContext event SavingChanges to keep this concern out of my application code.
I run a pair of Ruby on Rails sites, http://janeallnatt.co.nz and http://postmoderncore.com. I use Capistrano to deploy updates to both of these sites. Once I built these sites and got Capistrano working, I realised that the database should be deployed as part of the Capistrano deploy.
I recently wanted to build an extensible set of processing classes. Each class can process certain objects it is provided.
I decided the simplest way to do this was to create an processor interface. The set of processing classes then is all classes that implement this interface. I use reflection to then find all the processors: that is, all implementations of the processor interface.
