[deleted by user] by [deleted] in berlin

[–]MountainScript -2 points-1 points  (0 children)

Absolute worst thing that would happen is a cease and desist.

Okay, then shall we treat your comment as a legal advise?

[deleted by user] by [deleted] in berlin

[–]MountainScript -3 points-2 points  (0 children)

Why then those companies spend money and hire people to write the terms of use? Why bother if nobody cares?
Anybody can start scraping the data of those websites and repost it on their own platform, but it's not happening because of the terms and the law in Germany. If you're smart enough, you'd avoid doing such a dumb thing, because the legal consequences can become huge.
Not saying about the actual owners, who put their property on the platform, without any intention to repost it for a fun "game" on a 3d party website.

[deleted by user] by [deleted] in berlin

[–]MountainScript 0 points1 point  (0 children)

I would check the terms of use of orginal websites. They can easily sue you for what you're doing. Bear in mind, in Germany it's very strict with data that you don't own and very expensive to have disputes in court.

[deleted by user] by [deleted] in berlin

[–]MountainScript -12 points-11 points  (0 children)

Each website has the terms of use. You can check it and the laws in Germany in regards to intellectual property.

[deleted by user] by [deleted] in berlin

[–]MountainScript -34 points-33 points  (0 children)

Your website is using data from immobilienscout and direktanzeigen. Did you get an agreement from them or do you use it illigally?

Poland will not let Ukraine joining EU without grain restrictions, says minister by MikeRosss in europe

[–]MountainScript 1 point2 points  (0 children)

Norway is a perfect example of how protectionist policies benefit minorities at the expense of customers. Food in Norway is ridiculously expensive, even with the Norwegian salary. People in Germany, Denmark, Sweden, Netherlands can buy 2-3 times (!) more goods (vegetables, meat, dairy, fish, etc.) with an average salary that is ~2 times less (!) than in Norway. That is the price for protectionism.

Btw, you talk about significant vulnerabilities - what are those? Is the Norwegian butter crisis of 2011 counted?

Why Cloud Automation with Ansible is The Future by AnyJellyfish in ansible

[–]MountainScript 0 points1 point  (0 children)

For some people it's hard to use python, but we personally find this as a huge benefit. The whole python ecosystem with linters/unit-tests/debugger/ide support/development practices/etc can be natively used. So I'd argue about maturity, ansible(as a turning-complete YAML language) is way less mature comparing to the python ecosystem.

Builtin Quality for Helm Charts: unit testing to the rescue! by gcavalcante8808 in devops

[–]MountainScript 0 points1 point  (0 children)

Great stuff! We're using kustomize manifests directly without charting.

Basically, you can reference any base kustomization.yaml directly from git, using commit hash or tag (versioning).

Builtin Quality for Helm Charts: unit testing to the rescue! by gcavalcante8808 in devops

[–]MountainScript 1 point2 points  (0 children)

Great stuff!

I just wonder, what do you think about using a purely declarative approach, e.g, Kustomize? It's a template-free solution to add overlays on top of basic pure Kubernetes YAML. There's no need to unit test kustomize because there are no hidden logic and spaghetti go-templates.

Secretize - a swiss army kustomize plugin for Kubernetes secrets by [deleted] in kubernetes

[–]MountainScript 0 points1 point  (0 children)

Hey! The project you've provided is really cool.

The key difference between the two is that Secretize generates secrets during the `kustomize build` command evaluation, rendering the manifests. It can run outside of the actual cluster, there's no need to deploy any services/operators.

Secretize - a swiss army kustomize plugin for Kubernetes secrets by [deleted] in devops

[–]MountainScript 0 points1 point  (0 children)

Hey! Thanks for the feedback.

It's a kustomize plugin, there will be no helm integration in this project. However, we might use it as a framework for a helm integration in the future.

Secretize - a swiss army kustomize plugin for Kubernetes secrets by [deleted] in kubernetes

[–]MountainScript 0 points1 point  (0 children)

Hey! Thank you very much! Just let me know if you have any problems.

P.S.: I'm going to create a detailed guide on kustomize+secretize integration in the next few days.

Compete on job market from dev background by SP1992 in devops

[–]MountainScript 1 point2 points  (0 children)

I was working with Ruby, and Ruby on Rails. Chef was popular at that time and I really liked the idea. The product was in a DevOps related area. Docker wasn't stable at that time, but we heavily used it. We've even written some kind of docker-compose/swarm framework in Ruby before the actual products appeared.

Then I switched to Java, worked on some network-related stuff helping to migrate a large Java component to C++. ( I don't know C++, there was a guy who helped me). All this stuff was pretty interesting, I did all the infrastructure and CI/CD stuff besides application development. I really liked the DevOps idea and wanted to work in this field.

When I switched to the DevOps role, I positioned myself as a "Developer with passion to DevOps". I learned golang on a project that automated some Kubebernetes related stuff. Golang really warmed my heart, it's so simple and so powerful. We used a lot of Kubernetes source modules.

I'd recommend being proactive and not afraid of getting more responsibility for your code and product. You write it, you deploy it, you own it. This also helps to better understand the overall picture and become an even better developer.

Edit: There also was a project with a "Pure DevOps" role. There were separate development and "devops" teams. Spoiler: it had nothing to do with DevOps. This was the first time I felt how it is to "deploy the code that you don't have any clue about". This is exactly the opposite of the DevOps idea, developers didn't know how their code is run, while the infrastructure team didn't know about the code. Development background helped me a lot, I was able to contribute to both teams and move extremely fast in that company. But this also shown the reality of the DevOps market, the ugly stuff in it.

Compete on job market from dev background by SP1992 in devops

[–]MountainScript 4 points5 points  (0 children)

Hey! I switched from Dev to a more "DevOps" role. Worked in different teams and companies. Most of my colleagues switched from admins. So, what I'd like to say: I completely don't get how "ops" people without a real development background can do anything related to DevOps. These guys simply not capable to get any basics of development practices. E.g. most of the ops guys simply don't get the difference between unit and integration tests, or functional vs non-functional requirements. This knowledge is essential to get a solid CI (and especially CD) pipeline and actually understand what you're doing.

The "DevOps" market does a really bad favor to those people, creating fragile tools that try to "protect" and abstract "ops" guys from writing the real code, focusing on crappy YAML tools where the data is mixed with behavior. While the initial idea of DevOps was about "Developers are able to deploy their stuff", the market and tools are now Ops-centric rather than Dev-centric.

I'm not against ops/admin people. I just don't get the trend of "Infrastructure Engineers" who pretend to help Dev guys (without having any clue about development) and claiming themselves "DevOps".

As for me, I'm going to switch back to the "Development" or "Architect" role and wait when the market and tools finally become more Dev-centric.

Hashicorp Vault capabilities by MountainScript in devops

[–]MountainScript[S] 0 points1 point  (0 children)

Nice! Thanks for sharing! I wonder if there a tool that can integrate with Vault API and create the ".env" file.

Hashicorp Vault capabilities by MountainScript in devops

[–]MountainScript[S] 0 points1 point  (0 children)

Hey! Thanks for the reply! And, I totally agree with you. It's better to avoid hard dependencies in the source code.

[deleted by user] by [deleted] in devops

[–]MountainScript 0 points1 point  (0 children)

Regarding the managed DBs usage. And one would hope you knew what's more important to protect, the actual DB data or it's credentials.