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 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!
“Group Policy is a feature of the Microsoft Windows NT family of operating systems that control the working environment of user accounts and computer accounts. Group Policy provides the centralized management and configuration of operating systems, applications, and users’ settings in an Active Directory environment…Local Group Policy (LGP) is a more basic version of the Group Policy used by Active Directory.” – Wikipedia
There are various settings in Windows that come under the remit of the group policy. Even for computers that do not belong to an Active Directory domain there are settings that can only be changed via the local group policy.
The graphical editor, gpedit.msc, is pretty easy to use. But what to do when we need to script policy changes?
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.Read more…
Reading Japanese govt: Use operator-run app stores, not Google Play reminded me of an app that I use a lot, but who’s permissions are a cause for concern: Ocado on the Go.
The Ocado app wants to use your phone’s video camera, so it can scan bar codes. This is a legitimate requirement: there’s no way to do this using an intent. The trouble is, this is true for any real time use of the video camera. E.g. Samsung are planning to implement scrolling by tracking your eye movement. The video camera is the last thing you want to give unmoderated access to. This is really something for Google to fix.
The Ocado app wants to save your delivery slot in your calendar. Again, this is useful but I can’t see why this isn’t done with an intent, and hence requires no permissions. Instead, the app asks for for permission to ‘add or modify calendar events and send email to guests without owners’ knowledge, read calendar events plus confidential information’. That sounds like something I’d only want Google to be able to do, right? This is one for Ocado to fix: I know the user experience will be compromised a bit, and there’s someone in marketing jumping up and down, but this really is a race to the bottom: if Ocado feel they can justify having this permission, and everyone copies them, Android users won’t be able to reject apps based on their permissions, and hence won’t be able to rely on having a secure calendar.
Actually, Ocado need to fix their app, but where is the incentive? Only Google have an interest in the security of the platform as a whole. Perhaps if Google gave apps a security score calculated from the requested permissions, and made it prominent on the Play store? I’d be tempted to charge for listings on the store, based on the security score. Otherwise, we are back to using only closed stores with vetted apps.
It’s not even possible to fix this using something like Cyanogenmod. The app just uses an API which a user can’t effectively moderate.
Not content with that, Ocado on the Go asks for the following additional permissions for no apparent reason:
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?
We have many tools in our parsing toolbox. Today let’s look at how three different parsing techniques handle ambiguity caused by choice.
Since the dark ages of yesteryear Squeak has had a very interesting button in its Debugger – “create”. Today we’re going to teach it a new trick.