'Don't include "sensitive" configs in your Git repos' should be the correct title.
With regards to external dependencies, Vendoring is a source of debate and I don't think the larger community agrees on one rather than the other. More recently, Golang recommends Vendoring, and last I heard, refuse to support dependency management, so if anything you should look at their arguments for doing so.
Point 1 - a build must always be reproducible and deterministic.
Point 2 - a build that pulls in external dependencies relies on its external dependencies to be reproducible and deterministic.
When Point 2 is not 100% certain (reliability, changeable artifacts), Point 1 goes out the window. Therefore, Vendoring is a crucial strategy from a build engineering perspective.
The most common strategy to mitigate this in a non-vendored build is to have control over the external dependencies by deploying your own dependency platform for your organisation. The latest Artifactory, for example, has proxy support for many mainstream artifact repositories (gems, eggs, dockers, images, modules, bowers, etc.).
Now... this project I inherited has had modifications made to the vendored dependencies... smashes desk with head
NiFi looks very promising for numerous chunks of the ETL capability space, but I'm not sure it can stand alone on the transformation piece. I've been looking into coupling it with python for a full ETL stack.
JPKab - As you explore NiFi more and pair it with your own scripts I'd be curious to hear if you think there are things we can and should do better to be more complete. Let us know at firstname.lastname@example.org Good luck!
For those preferring a self-hosted oss monitoring solution, Jenkins is a good multi-purpose choice (it does more than continuous integration!).
I inherited a legacy application with tons of cron jobs running scripts on the production server. Instead of risking moving our jobs to jenkins, we're simply using jenkin's post endpoint to post job results from the cron jobs themselves. It's not perfect, and doesn't give us all the goodies listed above, but it does give us more visibility on the jobs themselves until we can move them all off reliably. +1 from me if you are in a similar situation.
I think it becomes slightly less offensive when it's ancient and the product/service doesn't really exist anymore - it feels like you're walking through a museum instead of looking at an actual advertisement or something, at least to me
I worked in the Electronics/Sporting Goods (sometimes both when understaffed) and Gardening departments of the local small town K-Mart when I was in high school.
Can't say I was overly fond of the throwback 80s music it played or the cheesy product ads after hearing the same ones for weeks on end. This was 15+ years after the 80s as well. Thanks to this discussion, I unfortunately have them stuck in my head once again after years of suppressing them :(
It was actually a pretty decent job for where I lived and for being in high school (with above average high school pay). However, I never ever liked the radio system or the pre-recorded announcer.
It's just an example. I would never say anything is never a good idea... there just needs to be specific conditions that would require it.
Hypothetically simple scenario could be running WP as user management, and i18n translations, for a single page application.
For the most part, I can imagine a node.js application layer that simply interfaces with wordpress api in the back. WP can be upgraded as and when needed, and the frontend application isn't tied down by clumsy php templating. A separate api with oauth and token authorization could be layered on top for mobile applications.
This is looking towards making wp more open to developers in other ecosystems (an area which is considerably lacking other places like .Net. Umbraco? Sharepoint? ew)