intranation

Openresty and Lua are great, but Go is a more generally applicable language for building web services. So when taken in that context Go makes more sense if we look at it as a learning exercise as well as a new part of the stack.

We did have some configuration - it was stored in Varnish and Nginx. The time cost of shipping new redirects when content is moved or new routing configuration for new tools coming online is non-negligible, particularly as we're in the middle of moving 300+ government agencies onto the GOV.UK platform. Also having all those redirects, friendly URLs, and application mappings in static configuration makes self-service publishing tools very difficult to build.

This is all outlined in the blog post - perhaps not as clearly as I would have liked, though!

Not sure what that has to do with semantics. Are you saying that NAV etc. aren't valid semantics on applications?

PATH, exec-path etc. are mangled because of the way OSX loads environment variables. Here's an Emacs package that fixes that:

https://github.com/purcell/exec-path-from-shell

This is a great move for me, and I hope ultimately for Ben. This way I'm empowered to fix my own issues, and pay someone else to run it for me.

It didn't test well:

http://digital.cabinetoffice.gov.uk/2012/10/03/why-weve-chan...

It's opt-in, otherwise most packages would break.

To enable it per-file use a file-local variable:

  ;;; -*- lexical-binding: t -*-

Not sure about radio, but black and white TVs are cheaper (£49 vs £145.50).

http://www.tvlicensing.co.uk/about/media-centre/news/black-a...

I think the learning programming thing falls under "personal creative projects", and I am with you 100%.

Dashes map more cleanly to existing CSS syntax, eg nth-child, background-color, etc. Much like camelCase looks more like Javascript than my_variable.

It might force the developers to commit more in the granular Git way, but it doesn't force bug reporters and discussions to be more mindful. Looking at my timeline, and following Backbone.js and Handlebars, about half my feed on any given day is discussion from 2 or 3 bugs on each of those projects.

So even though the committers might be mindful, doesn't mean all the users of a project are.

WebSockets don't have much startup time at all really. If you're using Socket.io or another Flash-based abstraction you can expect long lead/start up times due to the Flash policy file, but plain old WebSockets should be as fast as any other TCP connection.

Emacs gets a new release frequently. 24.0 is about to come out (it's in pretest), and 23.4 was just released.

Also, since it's a Lisp machine, it doesn't necessarily need to have IDE features added - you can just write your own extension in Emacs Lisp.

Multi-threading is asked for because when you run a complex thing in a single buffer (i.e editing something over Tramp mode, compilation, magit doing Git operations etc.) it can block the editor.

Hence, multi-threading is a potential solution to that.

Edit: spelling

I was specifically addressing the notion that gambling is risky or "low profile" (which I assume to be a synonym for shady) with regards to the "appetite for risk" reason stated by RBS in their letter.

Disclaimer: I'm a Smarkets employee.

Well it's not entirely clear that it's just related to gambling - Betfair, the UK's largest betting exchange, do all their merchant transactions (customer deposits and withdrawals) through RBS as well - given they're directly linked to credit cards the risk of chargebacks etc. is clearly higher than a day-to-day business account that is mostly used to pay employee salaries (as presented in the article, Smarkets client funds are ring-fenced in a Maltese bank). The obvious difference to me is that Betfair is a multi-million pound company and Smarkets isn't.

`i` is for "italic", and that quote means that you should be using `font-style` instead of an HTML element to make your text italic.

Because it's not an app in the regular sense, it's an email filtering and tagging web service. You'd be paying for their servers crunching your emails over the time you were subscribed to them.

Edit: From their FAQ:

  Mail Pilot is more than an app; it's a comprehensive online software
  service. It runs on servers, and delivers and syncs content between
  every Mail Pilot app that you might use.

  You can access Mail Pilot through a number of desktop, native
  mobile, and web applications. To make this possible, Mail Pilot adds
  services to your existing mail accounts that it syncs between all of
  your devices. Our servers store metadata about your messages (not
  the messages themselves, however!) to bring to you the reimagination
  of email that so many have come to love.

  Mail clients can get away with charging one time. Our apps are all
  free, but the service is paid for, much like other online
  productivity and email enhancement services.

We use Erlang to run our (several million messages a day) WebSockets implementation. It's been fine, way more stable and less resource intensive than the equivalent Tornado server.

Not sure about having an editor in a browser, but if you want a (mostly) decent IRC client in the browser you could try:

https://irccloud.com/

I have 3 invites if anyone wants to email me (my email is on my profile).

If they're using Node (and I assume they are, based on the fact that it's a Node.js podcast), I don't really understand why they wouldn't render the HTML server side (I may be showing my age by asking this) instead of relying on the client to render it.

It's not another JS template engine - it's a pure JS implementation of Mustache that's apparently significantly faster than Mustache.js.

They also support compiling of templates for deployment purposes, which is nice.

Chromium and Chrome are identical except for one compile flag (which means you can at least check it yourself):

http://news.ycombinator.com/item?id=3034755

Working with Javascript off != accessibility. Most screenreaders (the common face of accessibility technology) run on top of regular browsers, so your JS experience needs to be accessible too if you are legally mandated to (or even better if you care).

There's some HN discussion about the new release:

http://news.ycombinator.com/item?id=2059909 http://news.ycombinator.com/item?id=1181589

And another link I found helpful:

http://batsov.com/Emacs/2011/08/19/a-peek-at-emacs24.html

But yes, your plan is a good one. Start by running

  C-h t

to get the native tutorial, then ramp up from there. I'm afraid I don't know many good online tutorials as I work with Emacs power users, but Stack Overflow has always been quite helpful for learning Elisp.

The Emacs book was written in 2004 and is about Emacs 21.3. Current Emacs is 23.3, with 24.0 in pre-test.

I know things are relatively stable in Emacs world, but a fair bit has changed just from 23.x to 24.0.

Not 25 devs (although that doesn't necessarily change the salary question) - if you want to go "full GitHub" and use the issue tracker for everything, you want all your staff to have access.

I hope they're going to offer pro rata on seat volumes between multiples of 20. If I have just 25 users it's $10,000 (assuming their pricing widget is completely accurate).