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!
They're incredibly easy to build. I notice you use puppet. That's enough tooling to push configuration out and restart services for nginx or apache+mod_proxy. You can break configuration out into separate files per agency if you need to.
Varnish is different as that requires restarting.
We do the same with commercial kit (Riverbed) with over 140 HTTP application endpoints and that is higher friction than the equivalent setup yet we manage it with a mere 1 person...
Deployment is a solved problem. No offense but you're not Google!
"OMG we're the government and everything we do is huge and unprecedented so it is impossible for us to use off-the-shelf anything and we can learn nothing from best practises" is step 0 of every failed big government project.
There's significant thawing of that attitude (and gov.uk, for their imperfections, is definitely a very positive part of the trend) but the idea is alive and well.
Yes because a real world organization with IT systems going back 50+ years is exactly like some me to macbook and MBA start up with two men and a pantomime horse in old street.
Are you a price comparison site? Or Experian or Equifax perhaps?
Unless you clearly say you're not just some enterprise business that aren't exactly known for their technical competence this comment is totally ambiguous.
Do you just think you know what you're talking about, or do you actually?
You don't have to take my opinion seriously. I could work in Tescos and be splurging false information out on the Internet. I could be an elaborate hoax!
However, please don't write off people as "just some enterprise business that isn't exactly known for its technical competence" because we all know that startups get it right all the time as well...
As for do I know versus do I think, there is the third option do others know and that is all that is important when it comes to getting paid...
So you are handling a small set of related services to a large number of people. That's hardly comparable to the task of migrating 300+ (distinct) government agencies/services to the new system, along with whatever old systems they currently use.
> Are you saying that NAV etc. aren't valid semantics on applications?
What I mean is that the (supposed) benefits of semantic use of CSS classes go out of the window when you're no longer hosting documents to be read by machines. And the user does not care if the classes of HTML elements are semantic or not.
You can use both in the same file; you just need to declare the dynamic ones using defvar, etc. If you turn lexical-binding on blindly, the compiler will usually tell you which variables you need to mark as dynamic.
It has to be this way to remain backward-compatible. Similar to the issues Perl is going through with things like enabling strict by default (you have to request at least a certain version, I think 5.12), and distinguishing a Perl 6 file from Perl 5 one.
Yes, the article seems to assume that "personal creative projects" need to be something unrelated to software development. But why do they need to be? If a carpenter builds his kids a tree house in his spare time, isn't that a personal creative project even if he employs the same skills that he uses in his day job?
