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. (more…)
You love GitHub. Of course you do. You love peer review. You especially love sending a pull request back asking for nits to be picked. So when your submitter claims to have addressed your concerns, how do you check? You could walk the commits. You could diff the entire pull request against master. If only you could diff the HEAD of the pull request against the original state of the pull request, letting you check just the new set of commits…
With github-differ you can!
Simply add this tiny extension[1] to your Chrome, and it will decorate each commit in GitHub’s Commits tab. Pick any two commits, and the extension will redirect you to a page showing the comparison of those two commits! Job done!
[1]The JavaScript involved is so small that it should be trivial to port this to FireFox’s GreaseMonkey framework.
Last month we saw one way how to produce decent error messages while parsing. I’ve also mentioned that parsing with derivatives is a non-blocking parsing technique. What’s that actually mean?
At LShift, we tend to be big fans of functional programming, and in particular I’ve found ideas from languages like Clojure and Haskell do influence how I use more mainstream languages such as Ruby.
One technology that’s been useful to us on a current project is QuickCheck-alike for Ruby, Rantly. Briefly, rather than testing a module in your code by taking a set of (hopefully representative) examples of use and demonstrating that they produce the correct (usually pre-calculated) output, you can have the library generate input data and compare the results to a model.
(more…)Nat Pryce wrote a fun little library the other day called code-words. It rips your source into words, and turns the words into a wordcloud. In short, a visual representation of the most common words in your source, and using font size to indicate the more common terms. The aim is to give an introduction into the concepts the code speaks about. And in playing around with it I noticed something interesting.
I’ve been playing around with Meteor recently for an internal LShift project in which I wanted the browser to have a read-only live view onto some timetracking data from TimeTracker as it changes. When a developer records time spent on a particular task, a row is inserted into a Postgres database. Simples.
One of Meteor’s selling points is its transparent client-server data
synchronisation through its powerful Collections API, which is backed by
MongoDB on the server side. This poses a potential challenge for us: how can we leverage the reactive Collections of Meteor yet feed it with Postgres data?
Well, I did manage to wrestle my fork of Bevan Hunt’s (a Meteor contributor!) excellent Meteor Angular Leaderboard demo into live page update as database insertions occur on Postgres. You could extend this to deal with database updates and deletions as well, an exercise left for the willing.
We like parsers. One of the things that really kills the vibe with parsers is a rubbish error message.
Given the technical interestingness of parsing with derivatives, can we get useful error messages out of them?
You are currently browsing the archives for the Programming category.