jbrechtel
To be explicit about why, for others, this means your shell will search for executables in a 'bin' sub directory of whatever directory you happen to be in BEFORE it searches your normal path.
This allows for common commands like 'ls' to be executed from ./bin, if they're present, instead of /bin (from your system).
Once you've done this you've opened yourself up to an attack where you download a zip from the internet, extract it, cd into the directory and type 'ls' and you may have potentially executed something from that zip which you didn't intend to do.
tldr - relative paths in your $PATH is a bad idea.
Only on average. We are fully capable of being irrational as large groups...
Why not embed HAProxy?
Another possible way to interpret the 'ashamed' statement is that tinco is simply saying we should be trying harder to move forward when we are using such old technologies with such warts. Why can't we get rid of the warts? We should try harder. Perhaps this is what tinco is saying? I think at least equally plausible to the naive position you're projecting onto tinco...that it's 'simple' to replace these things.
Kudos to Neovim for making the effort! It is certainly appreciated.
The top sellers of mining hardware that I could find on Google (Butterfly Labs, Advanced Miners, Cointerra) all accept Bitcoin for payment.
Are you referring to some group upstream of the hardware sellers? I'm curious where you're getting this information from...
This is an important point, regardless. Sometimes new projects are started and it's not a matter of switching. Sometimes verbosity, and the things it negatively impacts, are worth switching. That's what.
When using OSS libraries on commercial products I've found the need to fix bugs or other problems and have sent pull requests with those changes afterwards. Granted not all clients approve this, but I wouldn't describe it as "few-to-no other companies" that allow it.
I personally shy away from .NET shops because they seem to be such a mono-culture.
--- This is totally off-topic so feel free to downvote into oblivion...
What I'm not seeing is why it's a problem when a host such as DO doesn't allow multiple IP addresses on a single machine.
Is it because you may want to host multiple sites on that machine and use one IP address for SSL?
Oh, nevermind. It's because you may want to support multiple SSL sites on the same box without requiring your clients support SNI. That makes sense.
We really need to just EOL everyone who has a browser without SNI. People like to say that there's still a lot of XP users out there but surely even a reasonable chunk of them are using Chrome or Firefox with SNI support, right?
I'd still say it's definitely not true that you "have to" get an SSL cert for all virtual-hosted domains on one IP address if that IP address is responding to SSL requests on 443.
Estimates still come with a cost in themselves though. They're not an end, merely a means. So we should consider alternatives.
An alternative approach I've heard from some teams, though haven't had the pleasure of trying myself, is to break your work into similarly sized small chunks and measure team speed over time in terms of these chunks. This sounds a lot like relative point based estimation often seen on agile teams. However, the difference is that once you establish this sizing rhythm during analysis (with the help of estimation early on to hone in on sizing) then you skip estimation altogether.
I suspect this needs to be calibrated from time to time ("our stories have gotten too big") and exceptions need to be made (e.g. "there's just no way to split this work up and keep it releseable") but those scenarios are exceptions, not the norm.
A world without estimates sounds great to me.
https://opennlp.apache.org/ http://nlp.stanford.edu/
Cloud provider automation libraries
http://jclouds.incubator.apache.org/
Distributed stream computing
https://incubator.apache.org/s4/
Asynchronous event driven IO, battle tested, mother recommended
In-process webserver
....to name a few. It's probably useful to take some thing that you'll need and look in ecosystem X for it (say... .NET) and then compare what's available there to what's available on the JVM. In my experience, the JVM wins out almost every time when it comes to number of options and maturity of options.
My intuition says that complex algorithms get even more advantage from more expressive languages. Java and C++ are usually not counted among the more expressive languages.
My experience on two* different projects in very complex domains...one where we used Java and another Clojure was that the Clojure code was more approachable and modeled the domain in an easier to understand way.
Just my 2 cents.
* One project was in the field of power systems, modeling and predicting power flow through the distribution end a power network.
* The other project was doing personalized treatment recommendations based on analysis of genetic data.
I guess I mean, shouldn't the stigma be attached to unmaintained or immature libraries not simply third party ones?
Terrorism has no value but vehicles do.
Unchecked terrorism, ostensibly, begets more terrorism. This is unlikely to be true with vehicle deaths.
Terrorism also has effects beyond the deaths and injuries it causes and I'd argue those effects are much larger than the same number of deaths in a vehicle accident.
Evil mode is one of the better Vim emulation layers for non-Vim editors...and there are quite a few.