>whats stopping someone from sticking up a couple of QR codes that link to a fraudulent payment page or some other malware?
This will become a huge problem / is already a problem. Whats the right way to solve this? some sort of https like trust relationship for the whole QR code interation?
I have trouble getting consistency. I tried several methods, like you mentioned starting small, completibg small actions etc.. But I'm not able to consistently do it. It breaks when you are stuck at some problem. And in my job(legacy code base (~13yearrs), me with < 2 years experience, i find it harder to get that momentum.
jacquard has been discontinued. We want to thank all our loyal fans. We understand you may not agree with this decision, but we hope you'll come to love these alternatives as much as you loved jacquard.
We tried a similar chaos tool in our company built in-house. Simulated most of the scenarios mentioned here using SSM/other scripts. At first everyone was interested and after some time the interest faded. Our problem was lack of visualization across the app ecosystem i.e how will it impact the app ecosystem when a batch of ec2 instances are suddenly spiking on CPU and what will be the impact to end user.
Turns out people care only if there is an end user impact and doesn't really care about random anomalies.
And to build the capabilities required for measuring the impact + automating the workflow of the actual chaos tests is a lot of work
Can't this be solved by using IP addresses for hostnames? This can be a part of bootstrap script(which ASG/Launch Configuration already supports via UserData[1])
What I can't understand is -
If your logs are in ELK and metrics in prometheus/grafana - why do you need SSH access? Sounds like thats a good problem to solve
thats interesting. Consider a scenario of a guy with proper attire vs this guy. If the guy with proper attire did the same level of presentation as this guy, who have the probability to "win the clients"
Go for the startup when you are young(<30)
Startup is your best crash course into the industry. It can force you learn lot of things in a short amount of time. Sure, it will be stressful, startup may fail but you got time at your hand and you can move on with your gained experience. If you got into google at this point, your chances of getting into google in the future is on the higher side(+experience from your startup).
>> our Jenkinsfile can assume certain plugins are installed, assume other jobs are configured on the same Jenkins
I think what worked for us in this case was using Jenkins shared library[1]. We provide a common template for the common stacks and expose only few configurable options. This would really help in maintaining sanity across the jenkins env and since you maintain the shared lib, you can control the dependencies.
We provide very generic CI templates for each stack(java,go etc). If teams want any customizations on top of that, they will have to do it themselves. In CD we have some very specific expectations from the package so this make sure that CI part won't go way out of the way even if they make some customizations.
I have always felt this. When I joined my new workplace, I spent quite a lot of out of office hours on learning more in my field. To be honest, it really paid off. Studying after uni really matters.