marten-de-vries

If you're using a web hook to notify your users of changed content, the WebSub standard (https://www.w3.org/TR/websub/; formerly PubSubHubbub; currently a candidate recommendation) is a good option. It solves a couple (though not all) of the problems of web hooks listed in the article, including:

- Uncertain security: signing notifications is in the spec

- Development and testing: ideally, with libraries that implement the spec, you can assume that the websub part will 'just work' and only need to test your handler function.

- Misbehavior is onerous: subscribers need to actively confirm their subscription every once in a while. This might seem complex, but it allows for periodic checks if the server/client is still functioning as expected, and ideally can be handled automatically by libraries.

- Retries: the spec leaves some room here, but again, a library can handle this.

As I decided to use WebSub as an alternative for a 'plain' webhook for a project recently, I wrote a library for the Flask web framework: https://github.com/marten-de-vries/Flask-Websub. I personally hope libraries for other frameworks will follow now the spec is moving less.

Launchpad still has a couple of very nice features you do not see at e.g. Github, in particular for desktop-oriented software:

- Built-in translation support; there's a big community that can (and, in my experience, will!) help you translate your project's .pot files using Launchpad's interface. It also has auto-import and -export of files from the source repository.

- Build recipes; this allows you to build .deb packages for your project, and to put them in a PPA which makes them easily testable for Ubuntu users.

- Detailed progress tracking functionality; using releases, milestones, a nice bug tracker & blueprints.

While I've in the past used Bazaar in conjunction with Launchpad, I'm happy to see them make the switch to Git. With its larger development community and popularity, it's a natural choice. Just a shame it isn't as well integrated yet.

This is how I feel as well. Unity is trivially configurable to get out of your way: my launcher hides by default, and the menu bar disappears into the title bar, which also contains the clock, battery status, wlan indicator, etc.

I will miss features like that. I hope other DEs incorporate them before Ubuntu drops Unity definitively, or otherwise that the community will keep Unity 7 up-to-date.

I've been using this e-reader to read papers last semester. In short, the screen is still a bit small to read A4 sized papers without zooming, but it is actually possible, while I didn't do so with the smaller Kobo's I had before (Aura HD/H2O).

I much prefer the e-reader over a laptop (14" Thinkpad), but there are some downsides. Taking notes on the e-reader is clunky (so I don't do that), and the battery life is less than that of the earlier models (still workable, though).

The color-adjustable backlight is quite nice. The only e-reader I've seen that's better for this kind of thing is the Sony DPTS1, but then you are talking about a completely different price class.

This post makes me wonder how Wine handles PE vs. EFI executables, and also if it could use an overlay file system as well for wine prefixes.

When I started my study (Artificial Intelligence), I came to the conclusion that yes, I was going to spend a lot of time behind a keyboard, and yes, switching might be worth it. At that point, I looked into possible alternatives for QWERTY and decided to try Colemak, mostly because of its closeness to QWERTY which I knew pretty well then.

I went in cold turkey, which was probably easier than for Dvorak, but still a pain. Anyway, after a couple of days I could type slowly again, and from that point on (taking notes using my laptop daily), the situation improved.

After a shorter than expected time, I was up to my old typing speed again. The downside: I lost my ability to type blindly on a QWERTY keyboard. On Macs, smartphones and linux computers this is not a problem as switching them to Colemak is trivial when I have to use them longer, but for Windows computers it is occasionally annoying. I do have a portable executable that switches such a system on a USB-stick I carry on my key ring, but it's still a pain.

Anyway, the end result is that I type faster now then I did, and the smaller distance your fingers travel does result in a more comfortable typing experience. I would definitely make the switch again with the knowledge I have now. That said, it's probably only worth it if you actually type a lot.

The workings of voting computers are opaque to a large part of the voting population. The sad thing here is that this certification process actually sounds quite good if you do not understand the technical details. In my opinion, voting machines are more trouble than they are worth, simply because of the loss of understanding of the workings of the voting process.

That said, it is always interesting to read analyses like this.

It's worth noting that using encryption techniques makes the functioning of a voting system opaque to 99% of the population. In contrast, everyone can understand how voting using paper works.

It's no doubt possible to make digital voting systems with some awesome properties, but in the end, are the improvements they give worth this loss of understanding (which might come with a decreased trust in the system)?

The end result is more comprehendable than the regenerator output, but the code is still modified quite a bit to fit into a Promise chain structure. Some statement types (like loops) more than others (like a simple function call). I haven't paid special attention to source maps and the like yet apart from what Babel itself generates (which is quite a bit), so there's probably still quite a bit to gain here.

I haven't. It probably mostly depends on the JS engine and Promise implementation.

That said, it might be a good idea to hand-optimize that single hot loop, typing the Promise chain out yourself, or even using callbacks directly. It's impossible to beat that using an automated solution like this.

Luckily, you can downcompile to ES5 using the exact same tool: Babel. See for an example: https://github.com/marten-de-vries/kneden/tree/master/test/f...

Anyway, I agree, the sooner Kneden becomes obsolete, the better!

It is, the resulting code is just a bit harder to read, and the babel-polyfill is required. It's quite good considering they're transpiling generators actually, but it's hard to beat something working on a higher level (async/await straight to promises, like Kneden does.)

Author of Kneden here. If generators are avaiable, you should probably indeed be using this.

If they are not though, Kneden will generate code that's probably more readable and smaller (no polyfill except for a Promise implementation).