This is a weekly roundup of awesome DEV comments that you may have missed. You are welcome and encouraged to boost posts and comments yourself using the #bestofdev tag.
@miguelmota jumped into the Explain Kubernetes to me like I'm Five thread to offer a great explanation using the analogy of cows and a rancher:
Docker images: think of them as blueprints, for example a blueprint for creating a cow.
Docker daemon: think of it as corral for letting the cows run wild.
Docker swarm (and Kubernetes): think of it as a rancher that manages the cows.
Let's say you create many cows (docker containers) with the same blueprint (docker image) and let the cows do their thing in the corral (docker daemon).
You have all the dairy cows in one place but it's getting pretty crowded and they're eating all the stuff around them (resources) and you need to redistribute them to other areas or they will die.
You hire the rancher named Kubernetes and tell him of all the other corrals (nodes). The rancher checks each corrals capacities (resources) that they can handle. The rancher will take care of moving the cows around when the corrals are low on food to more abundant areas and the rancher will also take care of creating new cows for you if cows die for any reason.
The rancher is responsible optimizing your cattle ranch as efficient as possible and making it scale as long as you tell him of all the locations that he's allowed to move the cows to. You can also tell him to only grow the ranch to a certain size or to dynamically scale larger to produce more milk based on the dairy consumption demand by the population (auto-scaling).
The What would the programming language sorting hat pick for you, and why? produced some fun replies. @integerman talked about their likely pick if they put on that programming-sorting-hat:
Turbo Pascal. I'm old enough to remember using it and loving it, it's a 'teaching language' which fits my mentoring bent, and darn it if I still don't think in therms of := for object assignment from time to time.
@andrewbrown provides a wonderful list in response to If you were tasked to conduct a security audit on a server/database-backed web app, where would you start?:
I have a Security Checklist for AWS which you can apply to any Cloud Computing service, it was too painful for me to find the original so I was lazy and linked it from my LinkedIn:
linkedin.com/posts/andrew-wc-brown...
Rails has very sane defaults, Rails Security outline gives you a good idea where to look:
guides.rubyonrails.org/security.html
OWASP top ten is a useful resource:
owasp.org/index.php/Category:OWASP...
A fun way of thing of ways to compromise an app/system is looking at Kali Linux full list of tools for inspiration.
Maybe you are running an old version of Postgres? Exploit DB might have some means for me to find a way in:
exploit-db.com/
- Are you using dependabot?
- Are you using that searches for CVEs? eg. Synk
- Have you tried sniffing for credentials that may be in the git history?
- Are you enforcing MFA? Are you enforcing signing of git commits?
- Do you have tests for all your endpoints? If not that that is a good place to look to abuse access to records I should not have access to
- Are you hosted on AWS? If not I bet lots of you're resources have public-facing addresses, Are you using Sidekiq? That means you're using Redis, maybe Redis is public-facing and you have not kept it up to date and I can gain access via an exploit.
- I would run Metasploit against your servers
A bit busy at the moment but a very fun thing to investigate
There's always a lot of fun conversation surrounding How to exit Vim. @gypsydave5 provides a fairly thorough list of tips for those looking to exit:
Come now, we're just scratching the surface...
Given you're in command mode:
-
:wqawill write, quit all buffers (in case you have more than one) -
:xwill also save and quit -
:exas above -
ZZwill save and quit -
ZQwill just quit -
:1,5wqwill save only lines 1 to 5 and quit
There's more. A lot more. Interested? :h quit will take you to the Vim help section on quitting.
Finally, The Interview Study Guide For Software Engineers was an incredibly popular read. @smitjel talks about something to keep in mind as you study and prepare:
This is all well and good...brings back a lot of memories from undergrad school.
But after enduring such an interview from a company, PLEASE PLEASE PLEASE don't forget to then ask your interviewer how they've used/applied said "algorithms, data structures, design, optimization and honestly just an ever growing basket of subjects" in their CURRENT work.
If you get a blank stare back, you'll know that you were just put through an "interview" that was essentially algorithm hazing and nothing more. I'd seriously question whether or not I'd want to work for this company.
See you next week for more great comments ✌
Top comments (2)
Congrats to @miguelmota , @integerman , @andrewbrown , @gypsydave5 , and @smitjel for making the list this week!
For a second I thought I got on there for my joke comment on the password management post.
Seriously, though, I do miss
:=for assignment. I don't know why. Send help.