AlexTes

Let me guess, you do not work with JavaScript .

As far as I can tell the license is okay unless your product depends on suing Facebook while at the same time being so strongly dependent on React you can't switch it out.

Beautiful, thank you for your story.

I don't think so. The cost would be extremely prohibitive. It would be far cheaper to print it in plastic and then add some reflectie coating.

Why would I use this over Antergos? Which is my current goto for preconfigured Arch.

Ignoring the negativity and taking it as an opportunity to improve your product and / or understanding of a segment of your audience.. I'll remember that!

I've been arguing for using Git Flow. Reading the post I have to say the stand our lead takes against Git Flow and in favour of very cosy CI is perhaos steonger than I realised.

He argues for pushing about as often as possible. With our small team thats very do-able, every push gets tested and linted by the 'blue' or 'green'. You're supossed to only push passing code which you easily can by running the tests and lint locally. So instead of all the pain points mentioned in the post you write passing code, pull and rebase on other passing code, and then push. Little code review, no worries about hasty reverting, few / early conflicts keeping us from trilling each other up or writing incompatible features.

The reason I argue for Git Flow? Our tree is an absolute mess. Most often a single chain, of often linearly scrambled features. In other words removing one feature would be hard and require a bunch of legwork, not a couple Git commands.

If anyone strongly feels there's a better way for a small team than lightning fast CI let me know!

I use near weekly updates of a custom Android 6.0 ROM and daily use Arch Linux which is a rolling release. My work is on the web with npm keeping us bleeding edge. Other people often ask why my system does this little extra thing that's useful. Usually the answer is found by --version.

Life with up to date tools can be real good. So unless I'm simply the only one using good tools, updates can be good.

I disagree with you. In the query "deluge retina", "deluge" is definitely the more important bit. After all you're looking for deluge and are hoping to find it with support for retina. Otherwise you would've written something like "torrent client retina".

Now this is where a bit of guess work comes in but I'd say Google correctly deduces there is no such thing. Even the best result for both terms just talks about some app not supporting retina, and from the looks of it does help with what other client you might want to use if switching to OSX when you were previously a deluge user on Linux (possibly when dealing with retina). But that's not deluge. That's a useless result considering your primary intent was finding deluge. So Google chooses to give you results that might get you what you want over results that (correctly) only disappoint explaining there is no such thing. So in the first three results Google correctly decides that, to get you a relevant result at all it needs to omit the "retina" to get you results that might possibly get you what you want - deluge despite not having retina support - over just giving you the results that are relevant but definitely won't get you what you want. Your query had no results that would get you what you wanted so Google tried to alter the query and see if it could get you something useful anyway.

I think Google trying to give you results that might be hits instead of giving you disappointment in the first place is very sensible behavior.