Hubber here (same username on github.com). We in GitHub's OSPO have been working on an open source GitHub App to address the use case where organizations want to keep a private mirror of an upstream public fork so they can review code and remove IP/secrets/keys that get committed and squash history before any of those changes are made public. Getting a beta release this week, in fact - check it out, I'm curious what yall think about the approach
Looks like a promising tool and workflow to mitigate the risks we are discussing here. If you haven’t already done so, it might help the discussion here if you could highlight how this app deals with the issues outlined. Is the intent of the mirror repo creation that it’s more-or-less equivalent to “git clone —mirror”? I took a quick look at the code, and didn’t see a direct correspondence with “git clone —mirror” when creating the mirror repository.
As it pertains to the post, since that private mirror is disconnected, none of the concerns about accessing deleted data apply.
The downside is that you don't get any of GitHub's performance and UI affordances from the fork network. But for the use case of private iterations on work headed for a public upstream, that's a trade-off that seems worth making.
FWIW we didn't make a separate extension, it uses the vscode-yaml extension from Red Hat, you just configure it to associate certain filetypes with our json-schema and custom tags. It is awesome for sure.
Huh, I came here to submit this (I'm the author) and it was already in - neat. Would love to hear anybody's hot takes on the piece, there's some matters of taste in this (it's design, after all) but I think most of it is pretty well grounded in my experience living at the command line since the 90s...
I think it's a really great piece, and there's probably a lot more to say here.
I have also been living on the command line since the 90s, and I mainly write command-line systems (in C, but sometimes in bash).
The biggest takeaway for me was "enable progressive discovery." I wrote an essay years ago called "The Mythical Man-Finger" that was all about CLIs and how modern GUIs are often more cumbersome (I was arguing that for many applications, language is a superior interface than "pointing at things").
The biggest objection to my essay was that CLIs make it hard for you to just jump and screw around, and I had to concede that this is mainly right. You won't know how to make things look like chrome by manipulating alpha channels in Photoshop the first time you open it, but . . . you know, this big button probably means rotate. ;)
But it may also be that "optimizing the first fifteen minutes" in this way results in a program that's actually harder and slower to use as you get more familiar with it.
It seems to me that what you're doing is trying "optimize the first fifteen minutes" of the UX with CLIs -- a thing CLIs often do very poorly. It's great stuff.
For me personally: Why am I so addicted to switches and arguments rather than commands? I think my only reason is because I see a lot of other CL programs working that way.
I guess I haven't decided what I think about "bat" (I feel like there's a landmine in there somewhere that makes it so you should be super careful about going upscale in this particular case). But I take the general point. Why are we coding like it's 1975?
Interesting point about "first 15 minutes" - the service (and CLI) we're building will probably guide users into the CLI experience during that first ... maybe first 30-60 minutes, rather than 15, but _really_ early on as they get familiar with it.
From a UX standpoint, that discoverability you describe with the GUI is really about the affordances the user can discern with from the baseline state. That is, the 'rotate' button is visible without the user having to do any discovery at all, it's just _there_. What would the CLI equivalent be - I think part of it is the autocompletion scripts that bash/zsh let programs drop in to the `completions` directory so `command <TAB>` shows you all the possible next steps...? Worth thinking about.
Autocompletion probably has to be part of the solution. In some ways, I feel like we want CLIs to get smarter in the way that compilers have gotten smarter. "Did you mean?" is another really nice UI hack.
What frustrates me is that CLIs are not really part of the "design" conversation in computing at all. I feel like GUIs have so taken over, that no one is even interested anymore in figuring out how to create great language-based interfaces (which is really what CLIs are, I think).
When I say "no one," I mean the professional UI/UX crowd -- who very often come up with miraculous ideas with GUIs. It would be great to see some of that energy being brought to bear on text-based systems.
Well, there are some people doing UX work in this area but it's under appreciated, and I agree that it's largely programmers who give a sh!t about design rather than the other way around.
I was really expecting, given the strong opinions people here have about all things design related, that there'd be some spicy takes :D
I'm a little sad because most of these issues (as I understand your description them) are already fixed or well underway :( It's probably too late for your specific case but I'd like to reply anyway since a lot of this is "conventional wisdom" based on old information. Full disclosure: I'm the product owner for Puppet and before I worked here, I ran it in large-scale production since 2008.
Not quite sure what you mean by 'native support', but gem and pip package providers are built-in. there are high-quality modules for git (puppetlabs-vcsrepo), virtualenv (stankevich-python), npm (puppetlabs-nodejs), etc -- it's a design decision to move much of this into modules and out of core so they can iterate faster.
While the model definitely wants you to describe relationships between resources if you need to send subscribe/refresh messages, there's toggle-able ordering algorithms that will let you run them in manifest order -- I blogged about it here: http://puppetlabs.com/blog/introducing-manifest-ordered-reso...
The parser and evaluator are undergoing a total rewrite to be an expression based grammar, which is explicitly to make better definition around the language and eliminate the gotchas -- https://docs.puppetlabs.com/puppet/3.6/reference/experiments... (this will also be the default on the next semver major)
