Because on personal blog personal opinion may appear. And personal opinion sometimes does not align with the right opinion. That’s where one loses karma points. That’s why I have paper diary instead of public blog.
Interesting article.
Our PO often almost demands estimations from us. Usually I am already responding in a best/worst case fashion.
In the end PO only seems to remember the best case and takes it as commitment. Since I was fooled by this a few times, I am now collecting a paper trail and am quiet reluctant, when giving "just a ballpark figure".
My key takeaway was, that estimations mostly aren't about accuracy or getting a value, but rather managing people's expectations and navigating corporate politics.
Agreed. I'm much less liberal with my estimates with external stakeholders than I am with close associates, purely for political reasons. If I say 8 weeks to my team, I'll say 11 to management/others. I get no benefit out of delivering on time, a little for delivery early, and a massive loss by delivering late, so I have 0 incentive to give them an "early" estimate. Under promise and over delivery is corporate strategy 101.
"According to France’s privacy watchdog CNIL, Youtube users only had to click once to accept cookies, whereas refusing cookies took multiple clicks.
CNIL’s complaint stated that Google purposefully made the consent mechanisms more complex to push consumers to accept cookies––a clear violation of the GDPR’s requirement that companies provide equally simple ways to opt into or out of data collection."
So these dark patterns are officially violating GDPR.
However there are still tons of websites implementing this.
They were from the start and this was abundantly clear, but given the complete lack of enforcement, people just did whatever the big websites were doing. If these don't get caught, why would they go for random cooking blogs?
Can you elaborate what is improper secret handling in your opinion.
I personally use sealed secrets, but I think generation of them is sometimes tricky (tied to the namespace etc
I don't have an easy answer for you because I'm still struggling to find the "proper" solution myself. That's why I'd kill to have the agencies weigh in.
I'm not a fan of SealedSecrets or managing secrets in-code at all because of this scenario: Secret rotation requires pushing updated code which may take too much time in a compromised situation. Ie, I don't want to hinder secret rotation with CI tests and merge approvals when there's an active incident triage - I want to kill the pwned secret with fire and get a fresh secret in there ASAP.
I've gotten better results by treating secrets as state instead of infrastructure... Like, by coupling your pod to a secret vending service like Vault or Secrets Manager, you can remove potential for programmers to introduce anti-patterns that weaken our posture.
The benefit is that we can keep things encrypted, auto-rotate things behind the scenes, remove the chance of developers to have even an encrypted copy of secrets, and we can get better turn-around on IRs when secrets inevitably get leaked. And, you can still write out the secret as IaC.
To mitigate the potential for single-points of failure when the secrets service goes down is to allow for secret caching client side. Vault and AWS Secrets Manager, which are the only services I can vouch for, both have client-side caching capabilities.
Take that with a grain of salt. I admit, I'm opinionated
Thank you for this post. I agree and feel the struggle as well.
Often the issue is even to communicate that this type of data is, literally, a _secret_ and should be treated accordingly.
I'm looking forward to things like mTLS and solutions with short token lifetimes and automated rotation. This should definitly reduce the amount of encrypted secrets in Git repos and basic auth logins for every 3rd exposed service.
In the end developers rarely care how the secrets gets to the application, or if it's fresh or been in the same namespace for over a year.
Vault is what I would recommend. It's like a password manager for prod. When used correctly almost no one has to know the actual secrets and they can be easily reset and changed as long as you develop with that in mind.
Support with the Kubernetes secrets API is baked in and well documented.
I am not sure if this kind of transparency will be beneficial to the employees or not.
Like the article mentioning there is leverage missing for salary negotiation.
That mean, that some folks would earn less assuming the model was adapted everywhere. However it may clean up inequalities.
In the end people are divers. There are hires with only 2 years delivering better results, than one with 5 years.
The article reads like the author uses Big Tech as synonym for only Google and Facebook/Meta.
However is is making some good points about the future of ad driven revenue streams those two companies heavily rely on.
In the end I think it will definitely not be big tech in total. Apple, Netflix, Airbnb and Uber e.g. have other revenue streams
In my opinion implementing strong interfaces and good modularization is something, that we should talk about more, than doing Microservices. In the end it might be easy to rip of a Microservice, when needed, if the code is well structured.
This is what I do in practice. I've seen it called a "distributed monolith".
One of the good reasons to spend time with Erlang or Elixir is it'll force you to learn how to write your programs with a variety of actors. Actors are generally easy cut points for turning into microservices if necessary. As with many programming languages I appreciate not being forced to use that paradigm everywhere, but it's great to be forced to do it for a while to learn how, so you can more comfortably adapt the paradigm elsewhere. My Go code is not 100% split into actors everywhere, but it definitely has actors embedded into it where useful, and even on my small team I can cite multiple cases where "actors" got pulled out into microservices. It wasn't "trivial", but it was relatively easy.
That's where a lot of the fun of Elixir comes from I think. It's viscerally satisfying to split off functionality into what almost feels like an independent machine that happens to be in the same codebase. It clicked in a way normal object oriented programming never did for me, I guess since it's not feasible to mint 10,000 genservers to use as more complicated structs.
haha I was thinking the same thing. The code base of my startup is a monolith but in reality its a fork on request webserver sending messages to a collection of genservers actings as services.
In essence, creating a microservice with elixir is about the same amount of effort as adding a controller in rails.
> In my opinion implementing strong interfaces and good modularization is something, that we should talk about more, than doing Microservices.
This is my position as well. Strong interfaces, good logical separation of function under the covers, etc. should allow splitting off things at whatever level of micro you prefer.
In my opinion, it is not. I am vaccinated and I used this site to make sure my batch wasn't 'bad' before getting the injection.
Regardless of how you feel about vaccines, 95% of the bad reactions are linked to 5% of the batches. I'm not going to jump to conclusions, but on the surface at least that seems to suggest a manufacturing or quality control issue that may have been missed.
Actually taking a closer look it was a different URL I used, but the same software to make sure I was making the safest most informed decision I was able to. I think the author posted the code somewhere too and open sourced it (I don't have a link as I'm not affiliated, just happy someone built this).
So from my perspective this is an interesting data analysis project, an interesting observation on manufacturing processes, and enables people to more confidently get the jab if they are hesitant due to the known possibility of side effects that this can help mitigate.
Normally I lurk here but today I built an account to make this point, as I don't like to see the chilling effect that labeling anything that isn't all roses as antivax propaganda.
As a sidenote, it seems like the YC anti-abuse system could use a second look and possibly some tuning. Apparently a handful of accounts have been serial downvoting anything that even suggests vaccine manufacturing or preparation errors have occurred.
I cannot, as I'm simply a laypeople. There are a ton of papers I can link to in the literature though!
> COVID-19 VACCINATION ADVERSE EVENTS PAPERS
Abbate, A., Gavin, J., Madanchi, N., Kim, C., Shah, P. R., Klein, K., . . . Danielides, S. (2021). Fulminant myocarditis and systemic hyperinflammation temporally associated with BNT162b2 mRNA COVID-19 vaccination in two patients. Int J Cardiol, 340, 119-121. doi:10.1016/j.ijcard.2021.08.018. https://www.ncbi.nlm.nih.gov/pubmed/34416319
Abu Mouch, S., Roguin, A., Hellou, E., Ishai, A., Shoshan, U., Mahamid, L., . . . Berar Yanay, N. (2021). Myocarditis following COVID-19 mRNA vaccination. Vaccine, 39(29), 3790-3793. doi:10.1016/j.vaccine.2021.05.087. https://www.ncbi.nlm.nih.gov/pubmed/34092429
Albert, E., Aurigemma, G., Saucedo, J., & Gerson, D. S. (2021). Myocarditis following COVID-19 vaccination. Radiol Case Rep, 16(8), 2142-2145. doi:10.1016/j.radcr.2021.05.033. https://www.ncbi.nlm.nih.gov/pubmed/34025885
Aye, Y. N., Mai, A. S., Zhang, A., Lim, O. Z. H., Lin, N., Ng, C. H., . . . Chew, N. W. S. (2021). Acute Myocardial Infarction and Myocarditis following COVID-19 Vaccination. QJM. doi:10.1093/qjmed/hcab252. https://www.ncbi.nlm.nih.gov/pubmed/34586408
Azir, M., Inman, B., Webb, J., & Tannenbaum, L. (2021). STEMI Mimic: Focal Myocarditis in an Adolescent Patient After mRNA COVID-19 Vaccine. J Emerg Med, 61(6), e129-e132. doi:10.1016/j.jemermed.2021.09.017. https://www.ncbi.nlm.nih.gov/pubmed/34756746
Bozkurt, B., Kamat, I., & Hotez, P. J. (2021). Myocarditis With COVID-19 mRNA Vaccines. Circulation, 144(6), 471-484. doi:10.1161/CIRCULATIONAHA.121.056135. https://www.ncbi.nlm.nih.gov/pubmed/34281357
OP’s post history says: yes. Account created a few years ago, has never submitted to FP until yesterday, has new submitted more than a dozen links, half of which are extremely dubious vax/anti-vax articles, plus a bit of anti-evolution/creationist bullshit.
More and more we need a “report suspicious user” button. Too many throwaway and newbie accounts submitting disinformation and propaganda these days. HN is being gamed.
From what I can see VAERS data is just reports, you cannot state that the things reported are caused by the vaccine or just happened after getting the vaccine. Anyone can report to it, there is no checking or anything.
It's useful as input for further research, but making conclusions based on it seems just wrong.
reply