Show HN: Aws-upload – A delicious CLI Tool for uploading files to ec2

> Delicious rationale:

What I was trying to deliver was the idea of fresh, new, elegant, alternative, easy to use, geek, beautifully designed, young, for future generations.

I tried several combinations before the current tag line but no one of them seems good to me.

+ Some alternatives:

-- aws-upload a great CLI Tool for uploading files to ec2 // simple

-- aws-upload an elegant CLI Tool for uploading files to ec2 // may be, but old

-- aws-upload an alternative CLI Tool for uploading files to ec2 // wired

> Rainbow rationale:

The idea I was trying to deliver was that aws-upload can be "a kind of bridge" between you code on localhost and your servers. And the rainbow looks like a kind of bridge, a magic one if you want.

If you have any idea or suggestion let me know.

"Delicious" has replaced "made with love", "curated", and "machine learning" in on-trend marketing.

Another point that probably it's worth explaining a little bit more is the concept of exploration. aws-upload has been designed with the idea of brain zero.

Which it means: I'm lazy, I don't want to remember all the projects or environments I got.

When I was using the aliases without the scope I had to remember each label for at least each project.

With the trick of the scope I could tab, but with 10 projs with 3 envs each, you start to have 30 suggestions.

Too much noise for my taste.

With aws-upload the only thing to remember it's aws-upload itself. Then I tab.

I hope it clarifies a little bit more.

Sorry you right, the "Why?" section it could be better about the difference with an alias.

So, if you are working alone an alias is perfectly fine. If you are disciplined you could use a convention like `upload_blog_dev`, `upload_blog_stag`, `upload_blog_prod` and everything should be more or less fine.

I say more or less fine because if you are editing an alias 3 lines long you may have some typos or configuration issue (I'll talk later about that) and it can be far away from to immediate to detect the bug, edit the aliases file or the (.bashrc|.zshrc) file and reload the shell.

With aws-upload and tmux, I edit the settings in one panel and test in the other. Real time, no reload.

Which kind of issue can you face with this kind of task?

From my experience, I would say at least 3.

- the folder you are trying to upload doesn't exist (wrong path),

- the pem file you specify doesn't exist (wrong path)

- the pem file exists but it has wrong permissions.

Alias doesn't give you any support to debug these issues, aws-upload has the cmd `check` to do that.

The thing can start to be more tricky if you have a colleague that need the alias for him/her and potentially has exactly to edit these values in the alias.

In this case what you have to do is open the alias file, find the row with the alias you want and send it. In aws-upload you have the setting file in ~/.aws-upload . You send it.

Think that, if you to have a lot of aliases the alias file can start to grow exponentially, and of course, the possibility of mistakes and losing time grows as well.

Instead aws-upload reduce for you the scope of the critical information you have to manage and it tries to support you during the process.

Useful cmd in these situations:

- aws-upload check key // it check folder, pem file and permission

- aws-upload new key // create new setting files

- aws-upload cp oldKey newKey // copy a setting file

- aws-upload edit key // edit setting files

I hope it makes a little bit more sense now.