You would end up with a more secure system from attackers with less resources. For example, you can make your system secure to all common methods used by script kiddies but what happens when a state-level actor is attacking your system? In this case and as your threats get more advanced I agree with the article. In higher levels of threats it becomes a problem of economics.

IME all of the examples this page give are too costly to be worth it, almost all of the time: privilege separation, asset depreciation, exploit mitigation and detection are all very costly to implement while representing only modest barriers to skilled attackers.

How do you figure it’s too costly? If anything, all these things are getting much easier, as they become primitive to deployment environments, and frameworks. Additionally, there are services out there that scan dep. vulnerabilities if you give them a Gemfile, or access to your repo.

Limited resources would be better expended on “perfect” security measures; someone who expended the same amount of effort while following the truism and focusing on eliminating vulnerabilities entirely would end up with a more secure system.

Perfect it all you want. The weakest link is still an employee who is hung over and provides their credentials to a fake GMail login page. (Or the equivalent fuck up) If anything, what’s costly is keeping on your employees to not take shortcuts, and on stay alert to missing access cards, rouge network devices in the office, badge surfing, and that they don’t leave their assets lying around.

Yes, this blog post is stupid.

My experience with Pandoc was not excellent to convert Markdown to LaTeX. Pandoc is a bit complicated to extend as well.

What I did was use a Markdown parser(1) producing an AST(2), plugging into the parsing to extend Markdown syntax to support for instance the glossary use case(3), then write a LaTeX stringifier(4) for this AST. (In this Markdown AST -> LaTeX stringifier I only support standard Markdown syntax, this abbr plugin I wrote gets stringified through yet another plugins package(5) I wrote. It’s straightforward: 6.) Then I simply put the latex doc into some sort of latex template using a custom class, in the latex template you’d have your tableofcontents, glossaries, etc.

I had a bunch of lecture slides written up in org that I was dumping to LaTeX, which was always a bit fragile, and then a change in org-mode broke everything. In the end I wasted more time fixing everything than if I’d just written LaTeX to start with.

I think the best thing is to leverage smart editing (e.g. AUCTeX) as much as possible, and not deal with trying to convert from something else into LaTeX.

Why? Because google has apparently decided that the Accept-Language header is a filthy communist plot and can’t be trusted.

you really couldn’t in the mid-90ies when the internet started taking off (it was normally set to the language spoken by the people who made the browser).

Unlike other things from the 90ies (like websafe colors), this one seems to stick around, possibly because only relatively few people are affected by it and because it doesn’t impact how the site looks on the CEOs machine (unlike websafe colors).

By now Accept-Language is very reliable and should be treated as a strong signal. Much stronger than geolocation or other pieces of magic (which also regularly fail spectacularly in multi-lingual countries. Damn French Youtube ads here in Switzerland)

And what a brain-dead decision not to make switching language the easiest possible UI interaction. At least some sites make it easy e.g. by listing the desired language in that language because guess what - I don’t know what the word English is in Arabic.

Not to mention the fact that there are MULTIPLE valid languages for many locations.
Worse still that so many other sites have blindly copied the idea. God help you if you travel or spend significant time where you don’t understand the local language and don’t want to be forced to log in (or even have an account).

I wrote a greasemonkey script to add a hl=en slug across all google locations and I dread the day they decide not to respect that.

Not in Python, but the web demo code is in there, see for instance the render function.

The takeaway is: Always pin your dependencies (possibly except dev env). We used shrinkwrap for this, now npm provides a lockfile, same for yarn.

The takeaway I read into it is that if your production build process has the ability to install different versions of a million different dependencies than the ones that you previously tested on (for instance because it uses npm install and semver ranges and doesn’t lock things down), then you will at some point get screwed by that fact.

You should have the ability to deploy the exact same code (including deps) that you test. You should have the sense to only do this. You should have tests, and they should not suck. If you do this, you won’t be the guy who said “this caused me hours of fumbling while prod was on fire”, you will be one of the people saying “my build broke, I changed the version pin, it’s OK for now”, which is better.

If you want to be even more careful, then you don’t use ranges at all; you choose your dependencies, you maintain your own copies (so that no one else’s outages or pwnage spill onto you), and you don’t upgrade anything without having someone competent review the changes for any possible effect they have on you. Because code is so malleable, we as programmers make it a habit to replace the support columns in the basement with the newest high-tech design every time we repaint the cabinets in the kitchen… and then every now and then the house falls down in the process.

I don’t think that logic is twisted at all.

There is an implied contract in open source that the maintainer(s) of a project promise constancy of some amount of functionality: that regressions are to be avoided and fixed and even that extensions and intentional changes are broadcasted and controlled. The implied contract holds because there’s an expectation that the maintainer(s) want the project to be successful as measured by the number of people who trust them enough to download and use the project.

But that contract is just implied. For all you know, any one of your dependencies is actually has secret goals of being an art project to see how programmers respond during crisis. Or, more to the point, a con.

The only way a bug or regression or breaking change is the “fault” of the maintainer(s) is if this implied contract holds.

So it’s not so much whether or not you have a Plant B as much as whether you realize that you don’t have actual counterparties in the maintainer(s) who have given you a large amount of functionality you rely on. Whether you, as the responsible party for a service upon which you probably do have a contract for continued existence, support, and provision of services to your customers, are managing systemic risk appropriately.

The obvious solution is to lock down dependencies and reduce “counterparty” risk on open source projects you use. More systemically, however, the solution is to be cognizant of assumptions like these and realize that they’re squarely upon the shoulders of the application maintainer.

If that’s not good enough, then consider making a contract with the open source maintainers. You’ll probably need to pay them.

[Comment removed by author]

Remarq does this. I regularly recommend it to consultants and small businesses for producing nice-looking reports quickly and cheaply.

Case in point:

   (assoc map :key value)

In JavaScript:

   Object.assign({}, {key: value})

Which is both more complex, less obvious and less efficient.

Thank you. I will improve it.

Random finding in my twitter feed after reading your comment: http://www.slideshare.net/dataloop/zero-downtime-postgres-upgrades

It certainly doesn’t give me any confidence that their plans to switch from the cloud to bare metal is going to work out well.

I always figured, and still do, that Gitlab users are happiest when hosting their pwn setup. The CE feels like a very good solution in that, and why not the paid editions as well.

+1, this article left me eager for more.

I’ve been working a lot with TypeScript for the past year, so I can answer some of those.

Is there type inference?

Yes. Both Flow and TypeScript do type inference.

Destructuring?

TypeScript does destructuring. Flow doesn’t, since it’s just a type checker, not a compiler. But you’d usually pair Flow with Babel.

Product and sum types?

TypeScript has sum types. I’m not familiar with product types.

Should I decide just on the basis of existing Angular/React?

Maybe in the case of Angular, since it’s really a TypeScript-first framework. React is less opinionated, and TypeScript has really good support for React, including compiling JSX if desired.

If I don’t use either, which tool should I pick?

TypeScript is a fair bit older and more mature as far as I can tell.

Does one have a noticeably larger, friendlier community?

TypeScript is much larger.

The really big advantage that TypeScript has is the existing ecosystem of third party type definitions which you can install via npm.

Say you want to use LoDash, which isn’t written in TypeScript, but you want to have your usage type checked. Just npm install @types/lodash and you’ll get a community-maintained type definition which the TypeScript compiler will recognize, and automatically match up with the existing lodash JS package in your node_modules.

I suggest this link for a deeper and more exemplified comparison: https://djcordhose.github.io/flow-vs-typescript/flow-typescript-2.html#/

Some kind of gist like system? With the links being in the comments here.

It is indeed.

It’s becoming a common “attack” on many websites, forums, particularly as usernames to impersonate users, or in any user inputs really (like “your website”, …). There’s this small python lib I made to validate user inputs against homograph attacks: https://pypi.python.org/pypi/confusable_homoglyphs/

(edit: How fun, I wanted to help preventing these issues but after posting this I checked if ɢoogle was properly detected as dangerous by my lib and… it isn’t.

The lib builds a small data file containing all characters advertised as “confusable” by the Unicode Consortium. This weird small ‘G’ is ɢ, which according to the Unicode Consortium is only confusable with ԍ, not with G. Too bad.)