One of the projects here at LShift uses ansible to configure its EC2 machines. I needed to refactor the playbook in a minor way. But of course “refactor” doesn’t just mean “change the code”. It means “change the code (presumably for the better) while preserving behaviour“. I really didn’t want to check the change by running the playbook against a production deployment! So what to do?
To develop apps for iOS you need an Apple Developer Account. There is the normal developer program which costs $99/year and allows you to distribute apps publically through the app store. However, there is also the Enterprise account which costs $300/year. With the Enterprise account (which only businesses can apply for) you are unable to distribute via the app store, but you can distribute to devices belonging to your organisation directly (“in-house”), without passing through Apple’s approval process, and without having to deal with ad-hoc provisioning.
A client of ours has an Enterprise Account and I was tasked with using their account to distribute the app for testing. To do this I needed to create a Distribution certificate (as opposed to a Development certificate). However, the option was greyed-out – disabled. What to do? Read more…
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. Read more…
We mostly use memory-safe high level languages at LShift (although we’ve done the odd embedded systems dev job), but sometimes a bit of systems programming knowhow still comes handy. I had the misfortune of a pure, i.e. no-JNI java program segfaulting on me with Oracle Java 7 in a non-reproducible fashion. I wanted to find out what exactly the program was up to at the point of the crash. Helpfully, on fatal errors java will generate a slightly obscurely named file
is the pid your deceased java process run under (the
comes from HotSpot, in case you wonder). This file contains amongst other things a VM stacktrace which will tell you were in C-land things went wrong.
But let’s jump straight to the chase and open the core dump file like in gdb like so: