Here at LShift we take our programming pretty seriously. Which is why we now warm up properly before discussing important topics like static versus dynamic typing, tabs versus spaces and other such crucial aspects of our craft.
An Emacs operator preparing for a discussion with a vim user about text editors.
Occasionally, I’ve found that when doing some refactorings (especially when splitting a class for example), it can be all too easy to include redundant code. Whilst most of the time it’s possible to eliminate that by a combination of careful inspection and keeping the tests green, I’ve found that mutation testing tools can greatly automate the process here.
You’ve done the Right Thing and written extensive class comments, docstrings and the like. But are they really readable?
I’ve often found myself at a loss for blog post topics, so rather than write one myself I decided to let a computer do the heavy lifting!
Markov chains offer a neat trick for generating surrealist blog oeuvres. They work by figuring out the probability of one word appearing after another, given a suitable corpus of input material.
DSL based templating sucks! This looks a very short beep-like sound card. Let paragraphs rely on a sense of data. Roy recently released my mind: In practice of course, it grew features.
Our first local policy at LShift although weâ€™ve had a Meteor is necessary to distinguish this point though, we want to and hence wonâ€™t discuss. Empty is the dark ages trying to wind position when your job to generate input data API calls to understand this blog post. Hello, add our socket buffer, etc.
Iâ€™m glad I have addressed your submitter claims to work out what if we just the two commits! You especially love peer review. Perhaps itâ€™s about the motherboard. Success!
We have been developing Daylight, which is a records management system for Freedom from Torture, a charity dedicated to the treatment and rehabilitation of survivors of torture. Due to the sensitive nature of the data being recorded, Freedom from Torture wanted a way of tracking every change that was made to records.
The application uses Entity Framework as an ORM layer over an SQL database. One option would have been to use database triggers to log changes. However, we wanted to track changes not in terms of the database model, but in terms of the application model. This allows us to then easily query the log at a later point using the same application model and make sense of it. We can directly re-hydrate the logs back into C# objects in different recorded states in a strongly typed manner.
The solution is to override the database context object’s SaveChanges method. However, inside that statement is quite a lot of complexity! I have spent some time over the last few weeks extracting the logging code from the client application and the result is FrameLog, an open source logging library for Entity Framework.
You are currently browsing the LShift Ltd. blog archives for April, 2013.