benaiah

Unfortunately, GitHub's API does not provide per-repo permissions, so in order to read/write to any repo, the CMS has to get permission to read/write to all of them. This is a fundamental limitation of the GitHub API [0] - we'd love to be able to request more fine-grained permissions. This is a pretty frequent complaint about any application built with GitHub's API.

The r/w access to public keys is specific to setting up continuous deployment from a GitHub repo to Netlify's static hosting service. You can read more about why Netlify requests those permissions for continuous deployment here: https://www.netlify.com/docs/github-permissions/.

While Netlify's continuous deployment is (obviously) the deployment strategy we recommend, you can use the CMS for any static site, as it's totally build/deploy agnostic. You can use the CMS to edit your content and then build that content with Hugo and host on a VPS if you wish. You can also use Netlify to host your content without continuous deployment - it supports updating content with both an in-browser interface and a REST API [1].

The CMS is entirely open source, so you're free to inspect or fork the code - you can find the repository at https://github.com/netlify/netlify-cms/

[0]: https://developer.github.com/v3/oauth/#scopes

[1]: https://www.netlify.com/docs/api/

> sorry, what exactly does this?

It's a CMS that works on static sites. Currently it primarily supports GitHub repos for storage, but the plan is to support other alternatives (it already supports pluggable backends, but the GitHub backend is the only one with significant support at this point).

> How does it compare to other CMSes?

- It doesn't require a database - it works on static files.

- It doesn't handle building or serving websites - just editing their content.

- It has a built-in editorial workflow, which allows you to manage publishing and reviewing entries in a sophisticated manner (it uses Git repositories to do this, currently through the GitHub API), where "publishing" means pushing to a specific branch - you're free to build and deploy your website with any tooling you want.

- It supports arbitrary content types and build tools, by allowing you to describe your content in a config file.

- It is itself usable as a simple set of static files - its entire functionality is implemented as a JS application, so there's no server support required to host it beyond serving files. You can also use it as an npm module for more complex workflows (such as adding custom extensions to the CMS).

> After "Find out more" I know now that it does something with Github, but what exactly?

The current primary backend for Netlify CMS is the GitHub API. This means that it allows you to store your files in a GitHub repo, connect Netlify CMS to it, and it will use that repo to store your changes. A build system could then pull that repo to deploy your site. The CMS itself is entirely build and deploy agnostic.

I work on this project, and it's been a big day for us - Smashing Magazine just released a preview of its new site[0], which uses Netlify CMS as the admin interface. I'm happy to answer any questions about the project.

[0]: https://next.smashingmagazine.com/2017/03/a-little-surprise-...

The output is very flexible - you can define entry types as collections of "widgets", which would include stuff like a title, a cover image, a markdown body, etc. It's designed so you can use it as a CMS for almost any static site generator by defining how your data looks in the config - see https://github.com/netlify/netlify-cms/blob/master/example/c... for an example config (this is a configuration for the in-memory, non-persistent backend which we use for testing and demonstration).

> The best thing would be if one could prove a mathmatically incompatible set of counter functions where data colliding in the hash of one function would prevent the other function from validating correctly.

I'm a rank amateur, so this is completely outside of my wheelhouse, but this sounds suspect. I don't think you can make hash collision impossible, even with multiple functions, unless the combined hashes contain as much data as the originals or the combined functions have restricted inputs. The point of hashes is making collisions hard, not mathematically impossible - the latter is, I believe, itself impossible.

Like I said, I'm totally unqualified to speak on this, so I may well be missing something here.

Author here, if you have any questions.

His friend might not be on the autism spectrum, and it would be blatantly irresponsible to claim he was based on such limited evidence with no qualifications - which is why I didn't.

Rather, I stated that that kind of mindset is usually more common in individuals on the spectrum. It is, in fact, one of its most common and defining features - even if, on its own, it's not sufficient for a diagnosis. It's relevant to the discussion, even if it's not relevant to his friend in particular.

What further qualification could I have added to make myself clearer? I definitely don't want to be encouraging lazy net-diagnoses, as they're harmful to the people who have such disorders, so I'm genuinely curious how you would rather I have phrased this.

Not to diagnose your friend, but more as a general note: that kind of perspective sounds (from my admittedly unqualified perspective) much more typical of people on the autism spectrum or certain other non-neurotypicals than it does of "smart people" in general. It might be worth noting that there's some (mostly-anecdotal) indications that tech, particularly programming itself, may have higher incidence of people on the spectrum than other fields.

Vivaldi is an Electron-based wrapper for Chromium - thus it's Blink, not Presto. Since Opera moved to Blink a while back as well, I'm fairly certain no extant browser uses that rendering engine, and I believe its development has ceased entirely.

> Most of the software engineers at Microsoft are not focused on developing scalable web services architectures.

Uh, MS literally runs Azure, which may not be the biggest IAAS offering, but is certainly vastly larger and more complex than Gitlab. There are certainly numerous engineers at MS who would have experience relevant to Gitlab (though perhaps not with their particular tech stack). It may not be most of the engineers there, but in a company with literally tens of thousands of engineers, there are few things that will be true of most of them.

> Microsoft isn't even in this same field (git hosting)

How is what they're hosting at all relevant to the problem at hand? This could have happened regardless of what the end product was - it's a database issue. In fact, the git infrastructure was explicitly not involved in this issue - it was only their DB-backed features that had data loss.

Additionally, Microsoft is in the business of git hosting, if only tangentially. TFS supports git, and has since 2013: https://blogs.msdn.microsoft.com/mvpawardprogram/2013/11/13/... Your objection is both unkind and factually incorrect. The "mindshare" comment is a bit silly - even though they may not be as active on forums like HN, developers working on MS technologies are still one of the largest groups in programming (as a non-MS developer looking for work in the Pacific Northwest, this is something I'm constantly reminded of). I doubt your estimate of Microsoft's real mindshare is anything close to accurate.

> Are you an employee there or something?

This accusation is eminently not in the spirit of HN, and Microsoft was hardly the only company he mentioned. Whatever your personal vendetta against them, it's absurd to think that Microsoft is not one of the top pools of talent in tech - they're a huge company with a vast variety of offerings and divisions.

Author here, if you have any questions.

    Location: Portland, OR
    Remote: Yes
    Willing to relocate: No
    Technologies: Bash, C#, CSS (Bootstrap/Foundation/Bourbon Neat), Go, JS (Angular/jQuery/Meteor/React/vanilla), LESS, PHP (WordPress), SASS/SCSS, Scheme, VB.NET
    Résumé/CV: http://benaiah.me/resume.pdf
    Email: benaiah@mischenko.com
    Github: https://github.com/benaiah

http://benaiah.me

Polyglot developer, usually working on web frontends and large WordPress systems (though I'd like to move away from the latter if I get the opportunity). A huge Emacs fan, as you can probably tell by my GitHub, though I use Vim bindings in Emacs and Vim itself for working over SSH. Eager to jump in wherever I'm needed - I have widespread tech experience and I'm very fast at picking up new systems. Remote would be ideal, but I'm happy with an office position. Would strongly prefer not to relocate outside the greater Portland area, but I'll consider it for an exceptional offer. Feel free to send me an email at benaiah@mischenko.com

    Location: Portland, OR
    Remote: Yes
    Willing to relocate: No
    Technologies: Bash, C#, CSS (Bootstrap/Foundation/Bourbon Neat), Go, JS (Angular/jQuery/Meteor/React/vanilla), LESS, PHP (WordPress), SASS/SCSS, Scheme, VB.NET
    Résumé/CV: http://benaiah.me/resume.pdf
    Email: benaiah@mischenko.com
    Github: https://github.com/benaiah

Polyglot developer, usually working on web frontends and large WordPress systems (though I'd like to move away from the latter if I get the opportunity). A huge Emacs fan, as you can probably tell by my GitHub, though I use Vim bindings in Emacs and Vim itself for working over SSH. Eager to jump in wherever I'm needed - I have widespread tech experience and I'm very fast at picking up new systems. Remote would be ideal, but I'm happy with an office position. Would strongly prefer not to relocate outside the greater Portland area, but I'll consider it for an exceptional offer. Feel free to send me an email at benaiah@mischenko.com

But that doesn't apply to versions that already had an open license. You can't retroactivally revoke a license, you can only add it to new versions.

Reading his previous comments, and considering the brief age of the account and the consistency of tone in the previous comments, I agree with your decision - I think people forget that the mods here are quite approachable and upfront when it comes to bans and ways to move forward from them.

Thanks dang, you’ve tangibly improved my opinion of both the comments here and their moderation since you’ve come on board.

This is unfortunately not true, though I think the factually incorrect parts (as opposed to those I simply disagree with) are due to misuse of terminology more than anything.

First, the factually incorrect:

> For a long time, lambda-calculus has been seen by a lot of programming language researchers as the foundation of programming to which every other paradigm has to be reduced.

... not really. The lambda calculus is a way to represent computation, which is Turing equivalent; it can encode any computation which a Turing machine can. You can reduce any program to either a Turing machine or the lambda calculus, as they are both capable of representing any computation. The lambda calculus is not inherently functional, or OO, it's much lower level. To be fair, lambda calculus did lead directly to Lisp, which has long been associated with functional programming (though it is also not inherently functional - see Emacs Lisp or Common Lisp).

> Eventually, it became clear that lambda-calculus isn't the basis of all other programming paradigms.

Again, no. The lambda calculus is as much a basis of all other programming paradigms as the turing machine is.

> encoding lambda-calculus into object-orientation

After the above explanation, hopefully it's clear that this statement doesn't really make sense. Again, I'm guessing that this is mostly due to incorrect use of the term "lambda calculus" - you likely meant to use another term.

On to the stuff I just disagree with:

> FP is a special case of OO

Highly disagree. FP and OO are simply two different methods of organizing and connecting code and data - in OO, you have objects that encapsulate state and expose functions to the outside world that modify and retrieve that state. In FP, you write programs as series of functions that transform data. The fundamental difference is that in OO you are treating data and its related functions as a fundamental unit together and structure your program around connecting objects together, and in FP your program is essentially a data pipeline. The other distinctions between OO and FP (immutable vs mutable state, generic collection interfaces vs specialized interfaces for different kinds of data) stem from that fundamental dichotomy.

Scala may combine the two, and may do so elegantly (I really don't know, I've never used it), but even if its particular kind of FP is encoded in an OO system, that doesn't imply that FP at large is a special case of OO. In fact, I'd argue the opposite: a method on an object is simply a function with an implied argument (the object) in a scope where that argument is inacessible from outside. You can see this clearly in pre-ES6 JS, where that's literally how an object is constructed (in the Crockford style - the prototype style is a bit different).

The simplest way to get a drowning person off you is to go down. With your arms at your sides, push up, like the reverse of when you're trying to lunge out of the water. As soon as the drowning person's head goes below water they will let go and you can come back for another attempt.

Don't punch them, it's less effective and can knock them unconscious, which can complicate the rescue.

Source: was a trained and certified lifeguard and swim teacher in my teens.

The problem isn't that people choose routes that are strictly non-optimal, it's that they choose routes that are optimal for them - essentially using a greedy algorithm to choose routes. This is why closing roads can actually improve traffic in certain scenarios. Google Maps won't solve this, unless it starts suggesting routes that are optimal for the network instead of the individual, which is unlikely as they cater to individual drivers. Truly optimal traffic would require central route planning of some sort.

I can do this very easily, and I’ve been able to as long as I can remember. I always assumed everyone could.

Then again, I have weird eyes in general. One has almost perfect vision, the other is really bad (don’t remember the exact prescription, but the big “E” on the vision chart is just a dark blur when I don’t have my single contact in).

Perhaps it would have been better not to make the promise until you had the backing for it. I think that's what's causing most of the negative reactions here.

Sadly, Facebook's Likes are probably the only version of this that has enough of a network to meaningfully make comparisons. It's essentially an upvote-AAS.

You're replying to the guy that wrote HolyC.

These days evil is the goto vim-keybinding package - viper is unmaintained IIRC and hasn't been for some time, and evil works tremendously well.

How is “drop-down” an anti-pattern as opposed to drop-up?

Ah, I see. This is actually one of my favorite features of ido-find-file. I love the fact that I can treat the current path section I'm writing as independent of the path I've already navigated to. To each their own.

I love ido's find-file, but I think that's because I've made it behave much differently than the defaults. The ability to use backspace to go up one full directory, jump to home with ~/ at any point, jump to / with // at any point, and navigate folders quickly with fuzzy matching and RET is really, really nice.

To be fair, most of my file opening is done with projectile, which, when you exclude the right files and use ido, works fantastically well. I can get to nearly anything I've been working on in two commands - projectile-switch-to-project (C-c p p) and projectile-find-file (C-c p f).

I'm not sure what you mean by "how it splits up directory from filename" - could you clarify?

ido-use-virtual-buffers is indeed awesome - I really love it.

"dependencies" was a reference to the numerous plugins I use to get ido in a state that I enjoy. I don't particularly like stock ido, though I prefer it to the standard completing-read.

> That's not true. Helm doesn't just insert .asterisk, which is why it supports out of order matching. If one searches for "file rename" Helm will find rename-file, while typing "filerename" in ido it will not find it. In ido one would have to do "file<C-SPC>rename"

I did forget it supports out-of-order matching, my apologies. Still, it does use a strange, difficult-to-use form of matching, and does not sort the results by default.

I use flx-ido, which supports out-of-order matching to some degree. This is not a knock on helm, as helm (now) has helm-flx, but nevertheless I consider ido's default much better than helm's, as ido at least sorts the results.

> Helm is already criticized by many ido fans for having too many features, now it's also criticized by ido fans for not having more (despite it having way more than ido).

I may have made this point badly, but it's not about features, it's about letting me use those features the way I want. I don't recall the exact discussion, as this was over a year ago, but I asked for the ability to change a specific default and was told "that's the wrong way to do it" - and I'm not the only one who's recounted something like that happening in the project. That's unacceptable for something I use in Emacs - I want to be able to change anything.

> ido is not changing, and most extensions to it are very hacky.

ido does everything I need it to, and works seamlessly with every package I've tried it with. If its extensions are hacky, I haven't noticed - my ido config has literally never broken, whereas when I used helm I dealt with things breaking constantly, and not because of the introduction of grand new features. I don't mind bugs due to newness; I greatly dislike bugs that are due to doing things in a non-standard, difficult-to-customize manner, combined with a lack of care towards not breaking things, which has been my experience with helm.

Helm has a lot more features. That's certainly true. A lot of those features are ones I wished I could have in ido. But in nearly every other aspect helm is significantly deficient, often pointlessly so. Helm had to have extra work put in in order to use custom non-standard windowing functions - extra work that makes the package significantly worse, IMO.

FWIW, I don't mean to say your response is wrong, and I don't mind that people use helm (I use helm a little, though only when I have to). If you can get helm working, and you like it, that's great. I just don't want new users to get disillusioned with emacs because of how finicky and frustrating helm can be - as I mentioned in another comment, I see more people in the #emacs IRC channel having problems with helm than with any other package. Helm is often proselytized without much warning about the issues I listed - I almost quit Emacs when helm, one of its "star packages" according to most Emacs bloggers, caused me so many problems.

More power to you, but I couldn't go back to manually-invoked completion at this point. An environment which gives me as much information as possible as quickly as possible in as few keystrokes as possible is a big priority for me, and I'm willing to have a few extra dependencies in order to get that.

Agreed. Regular melpa is practically a parody of a package repo - sometimes it seems it took the worst option at every possible decision. Building directly from HEAD, using insane version numbering that causes package.el to prioritize it over every other repo (someone more cynical than I might think this was intentional), and yet somehow managing to be by far the most popular way to distribute packages, even more so than melpa-stable (which is actually quite tolerable).