This is indeed so true; yet money doesn't buy time. Unless you are in your dream location there's always inherent costs to visiting relatives / friends, match their schedule, or simply go wherever you feel good. So you end-up with a double need for money ;)
OP here, the post is only a simple trick that may be of some use to some people.
Eventually we merged that logic in an in-house app we built back in the days when the containers orchestration tools were still "rare", if i recall https://github.com/toscanini/maestro had just launched but wasn't really usable yet...
I'm perfectly fine with the DNS/DHCP approach, just wondering what are the alternatives out there. That dnsmasq approach worked like a charm for several of our projects for 1+ year.
Always wondering of the extra round-trip on DNS request when we could have a hardcoded value in the host. We're talking local network so the latency ain't much of an issue but still. Then there is the possibility of a dnsmasq restart when a request occur, caching ala nscd could work, but then we're in for a lot more trouble when it comes to expire that cache !
I'd love to hear about other people's workflow when it comes to address that issue - are you simply re-provisoning the all shebang if a critical component is to be updated or change? or relying on etcd/zookeeper as mentioned? or ...
13.04 is vulnerable, just out of the support period of ubuntu (decreased from 18 months down to 6 months in 2013) - basically out of luck, either use a ppa, or upgrade to 13.10
Really? I'm so surprised to see so many "Awesome! Go for it" answers to this.
While I admire the dedication and focus it takes to stay up to such routine, I am certainly concerned by the quality of life and the narrow mindedness of enforcing upon oneself to code on a daily basis. What about days off? Going out friends / family for a weekend or holidays? One would suggest to bring your laptop so you can stick to it? This is madness to me...
I love to code, contribute to OS projects, do code for a leaving and for myself - but for nothing in the world I'd even attempt such thing.
Setting yourself with goals is great and required to some extend but on a proper schedule. Going to the gym 3 times a week can be achieved without being complexed by the fact you didn't go there every single day - and yet you can substantially improve yourself. I don't envy those buffy dudes that stick to it.
I'll stick to enjoying evenings with my wife, do code maybe 1 or 2 times during the week days, spend an extra day on more complex issues on the week end, and rest for the last day. Just saying.
"Unlike manners, there isn’t a universally-agreed objective standard" :)
Manners aren't universally agreed either, they are very much tied to the culture people are evolving in. Burping in the middle-east is appropriate and a courtesy to your host, I doubt it'd be very much enjoyed in a White House dinner. Taking some (good?) wine as bottom's up is respectful to your boss/partners in China, yet I believe some of your guests in France would find this offensive ;)
That's a valid point, probably more brainstorming in the best approach to render the first landing on a repo as it is what effectively is at stake; instead of landing on a blank page the choice was made to display it all, letting you transform the kanban to a dashboard that best fits your need, later visits would re-use your pre-saved board.
Indeed, hence the numerous cheats in the playbook to make things work together.
Still need some digging to figure out the perfect workflow; Dockerfile that runs some git clone vs. add of local code vs. deploy via ansible - the ansible approach still provides the flexibility to have a customized container per dev that includes one custom set of ssh keys for example to fetch code from github or alike...
At the same time all init script are not suitable upstream; keeping the balance between simplicity and features is a hard one. Not every use would require a 10 foot long scripts that cover some awkward features that is seen in 1% of the cases - yet having a repository of capable init scripts seems a good way to mitigate the issue.
The redis init-script in the repo is only a sample I hacked as an example; to avoid an empty repo :)
I've tested and it's working, though I'll perform some more checks tmr and will gladely commit it back.