Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

12 Factor CLI Apps

medium.com

Post reply on HN
Print view View original

221–230 of 253 posts

Re: 12 Factor CLI Apps

#221

Post by twic »

gambler wrote: post #194
emmanueloga_ wrote: post #29

Don't get me wrong! I love command line apps. But I wonder if we all have a bit of an Stockholm syndrome... there are several things that suck about them... While writing this I'm thinking on my experience trying to do anything with ffmpeg or imagemagick... or even find. * For any sufficiently complicated cmd line app, the list of arguments can be huge and the --help so terse as to be become useless. For man pages, t…

Most people who claim that command line is the best tool for power users know nothing about history of GUIs. They think that laughable garbage that Windows calls user interface is "how it's supposed to work", and proceed to smugly lecture everyone on how command line is the only interface that can be composed and easily recorded. (The following paragraph is not directed at the author of the parent post. It's fully rh…

And how you do operate on the data in those objects? How do you filter, project, sort, stash for later, combine with data from elsewhere, edit, etc? How do incrementally build up a composition of operations from repeated experimentation? How do you record that composition in a script?

Re: 12 Factor CLI Apps

#222

Post by cpburns2009 »

013a wrote: post #205
cpburns2009 wrote: post #151

Earlier quoted context omitted.

Why would you put a CLI tool in a docker instance? I'd understand if it were a server environment or web application.

> This can be a great way to get a CLI tool loaded into a bespoke CI environment.

Okay, you have the CLI tool in one or more isolated Docker instances. What then?

Re: 12 Factor CLI Apps

#223

Post by twic »

jstanley wrote: post #48

> Error: EPERM - Invalid permissions on myfile.out > Cannot write to myfile.out, file does not have write permissions > Fix with: chmod +w myfile.out I actually much prefer: "can't write myfile.out: Permission denied" This shows the same information as the first 2 lines combined from the example, and the 3rd line is not necessarily the correct way to fix the problem anyway (e.g. you might be running it as your user w…

It's worth considering the source of this advice. Heroku is a service for which a major customer segment is people who are not adept with unix. A large part of Heroku's power, and success, comes from the fact that it makes it really easy to do things without understand everything that's going on under the hood.

Yes, this is a clear break with the unix tradition! But it's not intrinsically bad - it's just a context to bear in mind.

Re: 12 Factor CLI Apps

#224

Post by 013a »

cpburns2009 wrote: post #222
013a wrote: post #205

Earlier quoted context omitted.

> This can be a great way to get a CLI tool loaded into a bespoke CI environment.

Okay, you have the CLI tool in one or more isolated Docker instances. What then?

No, you start the docker container to run the CLI tool, because the tool is exported as the CMD for the image, like this one [1]

[1] https://hub.docker.com/r/mesosphere/aws-cli/

Re: 12 Factor CLI Apps

#225

Post by bayindirh »

Sean1708 wrote: post #198
bayindirh wrote: post #85

I don't agree with 7 and 8. I like silent apps while working, and actually I'm used to applications saying nothing if everything is correct. Also, "outputting something to stdout just because I can" kills scriptability a lot. Using tables, colors and other stuff requires a lot of terminal support. MacOS terminal, iTerm, Linux terminals supports a lot of stuff, but not always (our team is generally using XTerm for exa…

> Also, "outputting something to stdout just because I can" kills scriptability a lot. The article does specifically recommend using stderr for messages to the user, is there any reason that would kill scriptability?

I missed that. It's actually a much bigger problem. stdout and stderr(or) is two output paths to explicitly diverge error logs and problems from standard output.

stdout / stdin is reserved for user interaction, informational messages (md5sum), actual output (ls, less, etc.), and the like. OTOH, stderr is explicitly for error messages only, and it's very useful (and necessary).

A real use case from my daily job: I'm an administrator of a large system (approx ~1K servers), and I have substantial amount of cattle, and a lot of pets [0]. All of these servers have cron jobs, and other automated tasks on them. All servers can mail to a local mail server to report us problems, so our cron automatically mails any outputs to us.

All the tools we use, and scripts we write have the following properties:

- If everything is OK, they are silent by default.

- They output to stderr, if anything notable happens.

- Also we copy (think tee) all stderr to their respective logs (both local and on a centralized server).

Now consider:

- The (e-mail, log) noise if all the tools were writing their outputs to stdout.

- The work required to silence all tools. What if they don't have any --quiet switches?

- Furthermore, they wrote everything to stderr. How can I know whether thing has worked as it should?

- How can I find the problem quickly if everything is written to "Error" log?

- Furthermore how can I revise the errors happened quickly? Info & Error on the same file. grep galore!

- How can I silent a tool (by redirecting to /dev/null) if both normal and error logs are written via stderr?

These are the simple problems that I can come up on a real, big production system in five minutes. I can find more problematic scenarios which will happen on a daily basis, if I think more.

All these conventions, folklore, recommended usage and facilities are in place because of the needs and the experience acquired in the history of these systems. Running around them amok, just because they enable color, pretty spinners, or justify some narrow usage scenario is not correct.

These conventions and philosophy [1] allowed *NIX systems to scale without needing excessive administrative elbow grease. Ignoring these, and developing tools which use facilities and conventions as they please will degrade the ability to manage these systems with minimal work. I can always grep, but it will be inefficient and not guaranteed to get everything that I want, and also it will cost me and the computer time to do so.

Like algorithms, systems are easier to manage when "n" is small. When "n" gets big, these tasks got really hard, really fast.

So, develop tools to ease tasks. Not to show-off.

[0] https://www.engineyard.com/blog/pets-vs-cattle

[1] https://en.wikipedia.org/wiki/Unix_philosophy

Edit: Tried to increase readability.

Re: 12 Factor CLI Apps

#226

Post by subway »

shoo wrote: post #148
stuaxo wrote: post #143

"12 factor" anything seems to be a symptom of the over-complexity of modern apps, go back and rethink.

i found the original 12 factor website had a number of pretty reasonable suggestions based on experience of people who ran a business doing operations for other people's web apps. sure, web apps are themselves probably over complicated, but given that you're doing a web app, the recommendations arent bad. compare to where things have gone since, with containerisation.

In a lot of ways the "12 factors" have overly simplistic views of the world. For instance, storing your config in the environment is fantastic -- until you remember a great many frameworks will dump their environment to the browser in a number of failure scenarios. There go all your secrets.

Re: 12 Factor CLI Apps

#227

Post by diroussel »

AnIdiotOnTheNet wrote: post #147
emmanueloga_ wrote: post #29

Don't get me wrong! I love command line apps. But I wonder if we all have a bit of an Stockholm syndrome... there are several things that suck about them... While writing this I'm thinking on my experience trying to do anything with ffmpeg or imagemagick... or even find. * For any sufficiently complicated cmd line app, the list of arguments can be huge and the --help so terse as to be become useless. For man pages, t…

At this point I'm not really sure what makes command-line so great. We should have something like it in the GUI sapce that works much better but, like you said, "stolkholm syndrome". Why can't a pipeline be a more complicated multi-io workflow? In a 2D GUI this would be trivial to construct and read, but in a 1D command line it would get confusing in a hurry. And the concept works much better with AV, I can easily co…

Anaconda and similar big data tools are moving into this space. They are for data exploration not general system tasks, but still it’s a nice higher level command line.

Re: 12 Factor CLI Apps

#228

Post by diroussel »

emmanueloga_ wrote: post #29

Don't get me wrong! I love command line apps. But I wonder if we all have a bit of an Stockholm syndrome... there are several things that suck about them... While writing this I'm thinking on my experience trying to do anything with ffmpeg or imagemagick... or even find. * For any sufficiently complicated cmd line app, the list of arguments can be huge and the --help so terse as to be become useless. For man pages, t…

If your command line tool has a man page then fish shell can parse it to automatically know about command line arts for auto completion.

Re: 12 Factor CLI Apps

#229

Post by lousyd »

Only a web programmer could believe that man pages "just aren't used that often". It drives me nuts when compiled cli programs don't have a man page. It says to me that the author of the program doesn't know Unix conventions or doesn't care enough to put the effort into meeting his or her users where they are, and so I'm gonna have to be careful about how I use the program lest it do something unexpected. Use man pages.

The awscli is just terrible in this respect. There's no man page for 'aws' so I say "aws --help". It then literally tells me "To see help text, you can run: aws help". OpenShift's 'oc' sucks at this only a little less, with no man pages and for some inexplicable reason you can only get a list of global options in a dedicated global options help subcommand instead of at the bottom of every help page. The documentation system for 'git' on the other hand is a work of art. Pure beauty.

Re: 12 Factor CLI Apps

#230

Post by gambler »

twic wrote: post #221
gambler wrote: post #194

Earlier quoted context omitted.

Most people who claim that command line is the best tool for power users know nothing about history of GUIs. They think that laughable garbage that Windows calls user interface is "how it's supposed to work", and proceed to smugly lecture everyone on how command line is the only interface that can be composed and easily recorded. (The following paragraph is not directed at the author of the parent post. It's fully rh…

And how you do operate on the data in those objects? How do you filter, project, sort, stash for later, combine with data from elsewhere, edit, etc? How do incrementally build up a composition of operations from repeated experimentation? How do you record that composition in a script?

>And how you do operate on the data in those objects?

You don't. Your question makes as much sense as asking how to do polymorphism in shell commands Not operating on data was the whole point of OOP. (Or at least one of the key points.)

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...

  "I wanted to get rid of data. The B5000 almost did this via its 
  almost unbelievable HW architecture. I realized that the 
  cell/whole-computer metaphor would get rid of data, and that "
The way to integrate unrelated objects in fully OOP UI would be by making them send messages to one another, either directly or indirectly. The way to store this integration for later use would be by creating, modifying and serializing an object that represents it.

Look into Pharo or Squeak, at least watch some demos on YouTube.

Post reply on HN