timblair

This is actually an explicit decision, designed to maintain consistency of the user experience across GOV.UK services in terms of information architecture and content design. It's not something that departments choose to do (or not), and is codified in the GOV.UK Service Manual: https://www.gov.uk/service-manual/technology/get-a-domain-na...

An employee's use of a company-provided communication channel like Slack isn't covered by GDPR, but the company is liable for the content that's stored in their Slack account. Under GDPR, I, as a customer of Company X, have a right to know about and request a copy of any data stored about me by that company, which includes Slack conversations, in both open and "private" channels. GDPR also applies retroactively, so the old compliance export process wouldn't cover it.

Vaguely related: there's a great episode of the 99% Invisible podcast [1] about how two specific ice cream truck jingles are used to help deal with Taipei dealing with trash disposal.

[1] http://99percentinvisible.org/episode/separation-anxiety/

I don't agree with working like this, but I'd expect that you're generally going to get marginal gains from each extra hour worked (up to a point of exhaustion or burnout), especially in the short term, so it might make sense to have people work in this way _occasionally_. I know I've been on "work all the hours available" projects in the past, and I definitely got a lot more done than I would have just working a 40hr week, even if I did feel like cr*p at the end of it.

I think you're confusing the who the "user" is in this case. It's not Joe Bloggs out on the internet who wants to see fresh content on your site; it's you, the web developer, working on your local machine, building a web site or application.

The live-reload functionality is there as a development workflow tool, to automatically reload the page to see the results of the latest code change, rather than manually switching to the browser and hitting ⌘R/F5.

Regarding (Slack/4)... I believe that toomuchtodo is talking about the following features within Slack:

* Stars: the ability to privately star individual messages (so you can easily find them again)

* Pinning: the ability to publicly highlight specific messages within a channel, much like pinned posts in a forum (effectively channel-wide starring)

* History links: click on the timestamp next to any Slack message and it'll open a canonical URL for that message, allowing you to drop these links to specific messages or points in a conversation into other chats, GH issues or anywhere else you fancy.

I can see this being a really nice idea to use across a team, if such a thing was offered. A few use-cases / benefits:

* An agile team could use this as part of their retrospectives, and could track the data points across multiple sprints to see trends, as well as "scoring" the latest sprint.

* Sometimes an individual in a team can be quite quiet and reserved, and won't physically speak up if something's not going so well. Moving to a system like this may give them a voice.

* The levels can be tracked both by the team and by an individual's line manager to keep an eye on those people who are consistently (or increasingly) bored, frustrated, not learning, or generally unhappy.

* If this were completed every day, then it would effectively become a Niko-niko calendar[1] (although you might want to fill out just a single data point if you're doing it every day).

* Having a daily version would also work as an early-warning indicator of trouble brewing within a team or project.

[1] http://agiletrail.com/2011/09/12/how-to-track-the-teams-mood...

JSON API [1] is an attempt to standardise the request and response formats for JSON APIs, and it supports an extension which permits multiple operations in a single request [2].

Facebook have their own, similar method of supporting batched calls through the Graph API [3], and this even permits you to specify dependencies between operations in a single request using JSONPath [4].

[1] http://jsonapi.org/ [2] http://jsonapi.org/extensions/bulk/ [3] https://developers.facebook.com/docs/graph-api/making-multip... [4] https://code.google.com/p/jsonpath/

I took the article as to be more a case of using Redis as an example of a system which is reaching the limits of performance _given the current state of the kernel it's running on_, rather than a direct comment on the performance of Redis itself.

Also, saying that using Redis is slower than using a local hash table is a truism. There are myriad reasons why using a local, in-memory data structure is not viable: scalability and persistence, for example. It's like saying "I don't need a database, I can store everything in a local variable."

I saw this, but decided to donate anyway.

Same here with the Slack integration: clicked on the link and got a "We couldn't find any hook with this id" response back.

That's because it's the lowest common denominator. Anyone with Git on their system can use the command line and follow along. If you choose to use a GUI for your explanation, then you're likely alienating at least a portion of your readerbase who can't use / don't want to install that interface.

I agree that a GUI can make some tasks a lot simpler but, personally, I've always found that teaching people to use any DVCS from the ground up (i.e. from the command line) ends up with a greater level of understanding. Once you've got that, you can move on to using a GUI to improve your workflow, but with the understanding of exactly what is being abstracted away.

The PATCH version is the "number of commits since last MINOR release (will be reset at 0 when releasing MINOR)" — https://www.ruby-lang.org/en/news/2013/12/21/semantic-versio...

Have a look at the previous instalment of the series: http://globaldev.co.uk/2013/09/es6-part-2/#let_declarations

Care to give some examples where you think this is the case?

Fixed. Sorry about that.

Thanks for that: really clears things up.

It would have been really useful if the upgrade notification had included this level of detail to start with so people could make a much more informed decision about when/if to upgrade, rather than having to dive through bug reports, commits etc just to work out if our apps are vulnerable.

You could raise the same argument about all the time they spend releasing open-source software, or producing the really great presentation slide decks that they do.

Regardless of the fact that a well-designed application encourages people to use it more, the fact that GitHub provide their employees with the opportunity to produce such well-polished interfaces is an incredible marketing tool for potential new recruits.

At the end of the day, it all fosters an environment where developers want to be The Guy That Works at GitHub, and all the great talent they attract just bolsters their position even more.

You can grab it from the Scribd link on the blog post: http://www.scribd.com/doc/52729281/The-Best-Of-edw519

Global Personals, based in Windsor, UK, are looking for smart developers to join our engineering team, as well as Rails devs: http://globaldev.co.uk/jobs/