From 8a5296da8a4c53eed5f69027c66a7642f854f67f Mon Sep 17 00:00:00 2001 From: iliapolo Date: Sat, 18 Feb 2017 14:48:08 +0200 Subject: [PATCH 1/2] Birth --- .gitignore | 9 ++++ README.md | 133 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 142 insertions(+) create mode 100644 .gitignore create mode 100644 README.md diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..9acd0c6 --- /dev/null +++ b/.gitignore @@ -0,0 +1,9 @@ +###################### +# Intellij +###################### + +*.iml +*.iws +*.ipr +*.ids +*.orig diff --git a/README.md b/README.md new file mode 100644 index 0000000..a8ed6aa --- /dev/null +++ b/README.md @@ -0,0 +1,133 @@ +Wish List +========= + +This repository contains a curated list of ideas. + +Ideas? let me explain. + +Each directory is this repo contains a description of an open source, apache licensed tool that has been suggested +and approved by the community. The "community" is essentialy every one that wants to be a part of it. +A tool can have 3 possible states: + +- I wish + +This means that the idea was proposed, discussed, and approved as a tool that is actually neeeded and people +want to see implemented. If a project is in this state, it is up for grabs by anyone who wants to start working +on it. Hopefully, if multiple people wish to work on the same idea, they can do it together and collabarate. + +- Im on it + +This means that someone was awsome enough to take on the challange and start working on it. +If the project is in this state, its description should contain a link to the appropriate GitHub repo +so that people could keep track of it and participate in its development. + +- Reality + +This means the idea has become a reality and is ready to be consumed by the community. + +**This is the whole point of this repo, for ideas to become reality.** + +Think of it as a proucer-consumer queue of ideas :) + +(God that sounds a bit dushy, sorry about that) + + +## Motivation + +How this whole thing came about? + +Warning, personal story ahead, you can skip it if you dont feel like reading it. + +Well, about two years ago, after working for 5 years in one place, i switched jobs. +Like most people, when they experience a big change in a certain aspect of their life, i kind of start reflecting +on what i have **been** doing, and what i want to **be** doing. I was always really impressed by the open source +community and have benfited from its fruits greatly. I really wanted to be an active part of it, which meant, for me, +producing, not just consuming. So i decided that i was gonna create at least one project that im passionate about and i +think can help the community. + +Unfourtuntely, i couldn't come up with a good enough idea and was hit with a creative block. In addition, this new job +was in a startup that kept me busy pretty much 24/7. The idea died down and i sunk into my day job full power. +It had always bothered me, especially as i started seeing more and more cool open source projects sprouting like +mushrooms. + +Fast forward a few months, i was given an assignment at work that made me think of a cool tool that i thought might +be useful. Finally! i was excited about it, and couldn't wait to start working on it. + +Here is a tip for you: Before you start writing code, you should create a proper README for your repo. +Because if you cant formulate a coherent description of what you want to do, and what is it good for, you probably +shouldn't be writing the code for it. + +And so i did. + +Here is another tip: Once you do finish the README, start working on the code immediately and dont let it sit, even a +single function a day keeps your project alive, under resuscitation, but alive. + +Aaaaaaaaaaaand so I didn't... + +Again, some doubts started creeping in, time was a scarse resource and the project died once more. + +Fast forward 12 months, the idea trickled down my brain again and i wanted to revisit it. However, my own need +for the tool was no longer there, and the passion for it has disipated a bit. It got me thinking +about the process i went through with this project, that essentially started with the idea of participating in +the open source community, and i wondered: "Hmm, perhaps there is a different tool that people want, something more +useful? I wish i had a list of projects to choose from.". + +This is why this endevour was born. + +Another reason i think this list is necessary is because i think this method of collabaration is missing from the +current state of affairs. Seems to me that open source projects are usually created under the following circumstances: + +- You are handed an assignment at work, that either tranformes into or inspires an open source project. +- You come up with some idea on your own, starting writing the code, release an alpha version and start discussing and + collabarating with people. + +Projects are not created from a discussion of the entire community. Also, i feel like even many individually started +projects might benefit from this. + +## Statement of Intent + +I'd like this repo to become a collabaration focal point for the birth and development of many useful open source projects. +It should serve the following purposes: + +- When an idea starts brewing in your brain, feel free to propose that idea here and start a discussion about it. +- If you are looking for something to implement, but just haven't found it yet. This is the place for you. + +This repo is useless without people contributing to it. The beauty is that contributaions can come in the +form of ideas, and i believe people are full of ideas. + +Having said that, this type of process can sometimes actually have an opposite affect, and opress creativity due to the +variety of ideas and people. Sometimes, its better to not listen to what other people think, and do something even if +you dont have a concensus. So, if you are really passionate about a project, you should do it, regardless of what +the community or anyone else thinks. + +## Contributing + +There are three forms of contributions to this repository: + +- Propose a new project. + +To porpose a project all you have to do is create an issue in this repository with a corresponding pull request. +The issue is meant for a general discussion about the idea, and the PR is meant for a +content discussion (More use cases, further elaboration..). The pull request should contain an additional +directory with a minimum of a README file that properly explains your suggestion. When the idea +gets enough votes and if formulated fully, it will be merged to master. + +- Discuss and vote + +Voting will be managed by the reacations feature: + +https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments + +Discussions are done like we are all used to on github. + +- Start working on a project + +You decided to start working on a project, i solute you!. + +To do that, simply create a PR updating the status of a project to "Im on it". +Once you are done, create a PR that changes the status to "Reality". Also, please add a +link to the GitHub repo where the development will take place. + +If you feel like it, join the community of open source project maintainers on Github: + +https://github.com/dear-github/dear-github From 0b85b70e0054a771c651c9b0c6a938f9171dac3e Mon Sep 17 00:00:00 2001 From: iliapolo Date: Sat, 18 Feb 2017 16:36:55 +0200 Subject: [PATCH 2/2] propose nsed - file configuration tool --- nsed/README.md | 73 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 nsed/README.md diff --git a/nsed/README.md b/nsed/README.md new file mode 100644 index 0000000..1e8ca75 --- /dev/null +++ b/nsed/README.md @@ -0,0 +1,73 @@ +Nsed (No to Sed) +================ + +**Say No To Sed** + +## Motivation + +A while back i was given a task to deploy a bunch of software components onto an amazon EC2 instance: + +- Graphite + Grafana +- Elasticsearch + Logstash + Kibana (ELK) +- Nagios +- ... +- ... + +Immediately i thought to myself: "Hey, no sweat, im sure DockerHub has containers for all these guys!". + +This means all i will have to do is write a *docker-compose* file that defines all of them. A quick lookup at the +DockerHub registery revieled that even though containers existed for most of these components, they were not exactly +what i needed. They were either hardcoding some configuration (for example elasticsearch port), or bringing in +extra components that i just did not need (for example StatsD with the graphite container). + +This meant that i had to start writing my own docker files, and configure each component to my needs. And let me tell +you, there was a lot of configuration to do: + +- Retention policies for graphite storage (carbon.conf) +- Elasticsearch port (elasticsearch.yml) +- Grafana datasources and security (config.js) +- Logstash filters (logstash.conf) +- Nagios checks (nagios.cfg) +- ... +- ... + +Effectively, this meant that i had to manipulate a lot of different configuration files from within the Dockerfile. +So i did what every programmer would do: + +1. Bang my head against the table for a while. +2. Freshen up my 'sed' skills. + +After a couple of hours, and with very little hair left, i thought to myself: "Man, wouldn't it be great if every one +of these software components would provide a command line tool for configurating the damn thing?!" + +Imagine that in order to configure the elasticsearch port, all you had to do was: + +`$ elasticsearch config port=9201` + +You may say, im a dreamer...but im not the only one...In fact, you have probably already seen something like this +in action: `$ git config user.email me@gmail.com`. Yeap, linus has done it again... + +I then thought that there was nothing special about elasticsearch configuration. It is just a YAML file that can +be very easily manipulated using some basic python code (YAML can be deserialized into a dict), So why not write +a small python script that does exactly that? i could then use that script to configure any YAML file very easily: + +`$ python yaml_patcher.py /etc/elasticsearch.yml port 9201` + +The script also supprted nested configuration: + +`$ python yaml_patcher.py /etc/elasticsearch.yml security.admin_password pass` + +And even structured data: + +`$ python yaml_patcher.py /etc/elasticsearch.yml security {"admin_password": "pass", "admin_user": "admin"} pass` + +This proved to be extremely useful for me, especially because more and more tools are now switching to +YAML configuration. But i didn't want to stop there, i could do the same thing for many standrad file types: + +- json +- init +- properties +- ... +- ... + +And this is how *fileconfig* came to be, hope you enjoy it! \ No newline at end of file