Of course the application-infrastructure might be vulnerable as well in case the user IS the attacker, but it's more difficult to imagine concrete examples at this point, at least for me.
27 karma · joined April 8, 2014
Of course the application-infrastructure might be vulnerable as well in case the user IS the attacker, but it's more difficult to imagine concrete examples at this point, at least for me.
I've found that the history rarely doesn't matter at all to me. Finding out who modified a specific code section (git blame) is usually good enough.
Just feels safer to me to have a printed backup of both stored away in case the tech breaks or gets lost.
Sometimes I prefer Airbnb, sometimes I prefer a hotel, it all depends on the kind of travel experience I'm looking for.
- distance from home
- work-life balance
- tech stack
- smaller project size <50 ppl
- smaller office rooms <5 ppl
In the end I picked the highest paying that fit all the criteria above and so far I'm happy with my choice.
Given that I'm not sure why I should care as long as it works.
As a dev I agree it's technically interesting to find out why, as a user I think it just doesn't matter.
Enough to get useful stuff done, small enough to keep most capacity for feature development. Also depends on the amount of technical tickets deemed relevant by the team
I don't think either devlopers or managers can estimate future savings in most cases, but I still think it's necessary to refactor just to not drown in complexity and slow down overall development speed. My approach is to reserve about 20% for refactoring and technical improvements and let the team decide internally what to use it on.
On every stage (dev, test, prod) I can deploy it automatically up to two times (blue and green) by running a simple shell script. So when I update the application I just deploy it another time on prod, test it one last time by adding the IP of the load balancer in my local hosts file and if I'm satisfied with the result switching the DNS entry to the new version using a weighted DNS record with the ability to switch back until I shut down the old version.
Doing anything continuous doesn't feel worth it in such a small setup with one update every 1-3 months.
What I like most about the approach is that I'm free to change any aspect in the main template without any risk to break something in the live application. Only changes to the elements shared between versions need to be handled carefully.
The main template includes VPC, network, fargate service, loadbalancer, firewall, KMS, DNS records, access rights, database tables, queues, monitoring metrics, email alerts
It excludes everything that is shared from update to update which are defined separately and just referenced from the main template such as some database tables, persistent storage container registry, user groups (Only the groups, not the rights assigned to them)
mind to elaborate on that?
Quote: "If you primarily use your computer with the AC adapter attached and only infrequently use battery power, battery deterioration may occur faster if the battery is constantly charged at 100%. Lowering the charge thresholds for your battery, periodically resetting the battery gauge, using Maximum Lifespan mode, or using Battery Health Mode will help increase its lifespan."
Remote: Maybe
Willing to relocate: Yes, especially to Hong Kong or mainland China.
Technologies: All kinds of over the last decade from embedded to web but primarily Java, C#, C++ and SQL including their common following.
Résumé/CV: https://www.dropbox.com/s/fku2ku9nhorxdqz/cv_a.pdf
Email: michael (dot) bollmann (at) gmail (dot) com