sklivvz1971

Agreed, but they are not alternatives, they are both possible. Also, I was not referring to super hard questions that require practicing "cracking the coding interview" for a month before passing. I've had "popular" candidates that could not shuffle an array, find a substring within a string or do some other relatively simple task that requires the candidate to think a bit. The reality is that of course, people with seven years experience should not need to do such tests, but in practice, there are many candidates with such prerequisites that can't even code anything. How they get the seven years, is beyond me. All I know is that they can't code.

A few more things:

1) Be humble. Don't expect people to take it easy on you because you got street cred (You are a ruby contributor? You still need to show them how good you are at coding Ruby). Many people with creds get offended when they realize they are not as good as their credentials would imply.

2) Know yourself. Most candidates I've seen, including myself, encounter a moment in the interview where they get hit by the nerves. Know that it's going to happen, announce it to the interviewer, recompose yourself, start again when calmer. You are not going to fail an interview because you are nervous. You will not succeed if you are terrified, panic, and shut up.

3) Explain your reasoning. The way you approach a problem, which is a large part of what the interviewer wants to see is in your mind only unless you vocalize it. With a good enough mental approach, you will get a lot of slack on the actual code by most interviewers.

4) Interview your interviewer. Go prepared with smart, non-trivial questions on the job and the company. Ensure your interviewer is an empathic, intelligent, and humble person. Assume anything annoying you experience is going to be relatively permanent at the job -- will that be acceptable or not?

A wild guess: they found an XSS and used it to steal a Dev cookie. Then used that to grant mod status to a throwaway user.

Sorry everyone for the outages on sklivvz.com. @Azure's DNS stopped responding to @Cloudflare and broke the site's CNAME. Added an A record now. I'd like to know what happened to Azure...

>Bottom line: this isn’t a matter of taste.

It is, quite unequivocally, a matter of taste. Please don't pass your personal, unsubstantiated opinions as a matter of fact. :-)

> These solutions didn’t appear out of thin air because people get bored one day.

I certainly did not say these architectures appeared out of thin air. They were invented to solve the problems of internet-scale companies.

> Micro services solve tangible, real world problems.

Incorrect. Microservices solve tangible, real-world problems when they are applied to the correct problems. Microservices might also create tangible, real-world problems whether they are applied correctly or not. In fact, that's one of the points of the article, if you read between the lines.

> gRPC isn’t necessary hard to debug, and it brings a whole host of improvements over whatever ad-hoc mess you used before.

I don't know what you are referring to. If your microservices are well done, good for you. You still need to optimize the transport, which is a cost you pay only because of your choice of architecture. If you used thicker services or a monolith you would have different problems, but not that one.

I found this interesting and an excellent general overview of today's monitoring practices while using microservices.

I have to say, though, that I am always perplexed by these toy microservice architectures because they are not solving a problem but creating it. For example, we would not need sophisticated distributed tracing if we used less moving parts; we would not need to use highly optimized (but hard to debug) protocols like grpc and protobuf if we did not have to rely on a massive graph of calls for each service, and so on.

Of course, there are a bunch of lovely use cases for microservices, mostly around "how do we make 1k developers collaborate over our codebase?" (answer: enlarge the codebase!), which always sounded like a self-fulfilling prophecy to me, but then again, I loathe working for huge companies.

If that is your case, then these tools will make your developer life a little more bearable. If you are playing with microservices because they are fresh and new, please consider a more conservative architecture first.

That's very interesting although I'm not sure we fit their criteria. We are certainly interested in making our badges as recognized as possible.

The author here: I'd be grateful for any feedback (good or bad!)

> I will argue that performance is the last thing you should worry about when you want to scale.

Oh boy, this is in one sentence almost everything that is wrong with Rails...

The author deeply misunderstands Scrum. They also misspell it as SCRUM but that's another story...

Sprints are timeboxes and not deadlines. Stuff is done at a "normal" pace and it either fits (or does not) in that timebox.

Fundamentally, it does not really matter in itself. Noting down whether the estimation was correct or not, though, is important.

The whole point is that a team is supposed to get more _predictable_ over time. They learn how to estimate better, and having a fixed "box" to fill is a very easy way to do so.

So: Scrum is a "scientific" way to reach a sustainable pace ("scientific" meaning: based on objective, repeated measurements).

This is not to say that Kanban does not work. It's just way way harder to do right, because measurements of how good a team is at having a sustainable pace are not as intuitive and are easy to ignore for teams -- and ignore it they do, unless they are very well disciplined.

But all of this is well know in the world of Agile, I remember talking about this ten years ago. Perhaps an agile coach would truly help this person.

Firstly, switches are arguably way, way (waaaay!) more readable than the code proposed. It's a matter of taste for sure, but arguably a basic construct of all curly languages and more is easier to understand than a rather esoteric code where a pattern is substituted for a keyword. Of course though, it is true that switch statements in JavaScript have issues with breaks and code blocks, but any half decent linter will tell you about those.

Most importantly though, the performance profile of the solution proposed scares me a lot. To understand why, consider that it is not uncommon for switches to be JITted as:

- If statements and gotos for small number of options or - Collections of lambdas for high number of choices (note, much more optimized than the lambdas proposed, very likely!)

The reason they are built this way is performance (another commenter ...commented that performance doesn't matter - they are wrong, a switch can be nested in a hot loop ran millions of times and they do matter). Therefore, it's easily arguable that the presented pattern will significantly worse in some cases (few choices) and that should not be underestimated.

The last step should be "You should use git"

I think the whole point of the article is that k8s solves a different problem: orchestrating large sets of images if your application uses a significant portion of a datacenter.

The problems one _actually_ has on a personal projects are indeed solved with simple tools like rsync.

I think you are confusing the experience as a user of the app (who shouldn't really ever touch SQL) and the experience of a developer (who should be knowing SQL inside out and using it in their day-to-day work).

> As for the "execute query" example, why is it such a headache ? I just "kubectl ssh <container>" and I am in.

It's slow as hell.

> I had an excellent time working with kubernetes

I'm happy for you, seriously, and I'm not claiming general validity of my experience. What I am disputing is the blog post (which does claim general validity).

The list of things mentioned in the article to do and learn for a simple, personal project with k8s is absolutely staggering, in my opinion.

Having used it, there's a sizeable amount of further work needed which the article doesn't mention (e.g. learning how to use the pretty confusing google interface, finding the right logs and using their tools). So the overhead is really huge.

Furthermore, the whole system is slow. Want to run a SQL query against your postgres? You need to use a google cloud command that changes the firewall and ssh's you in on the machine... and this takes a couple of minutes, just enough to make me desist unless I _really_ need to run that query. Abysmal.

Finally, and this is a pet peeve against many advocacy blog posts, they just show you the happy path! Sure, _in the best of cases_ you just edit a file. In a more realistic case, you'll be stuck with a remote management system which is incredibly rich but also a really steep learning curve. Your setup is not performant? Good luck. Need to tweak or fine tune? Again, best of luck.

We've tried to adopt k8s 3-4 times at work and every single time productivity dropped significantly without having significant benefits over normal provisioning of machines. {Edit: this does not mean k8s is bad, but rather that we are probably not the right use case for it!}

...which in turn is usually significantly slower than building your own home server (but that's another story!)

This seems to misunderstand the basics of why we have CSS in the first place, to separate "how something appears" from "what something is", and suggests to mix the two.

The obvious result is that you would end up with similar objects with different styles. A button with "main" role should have a consistent style across instances, not be green in one place and grey in another because you forgot to add the "green" class. Also changing the color of "main" buttons from green to blue should not entail changing each usage of the "green" class to a usage of a "blue" class.

YouTube sent me a takedown request for publishing a video to my own song (which is published on CD only).

They took down the song because I could not "prove" I was the owner.

I guess my name being on the cover and my picture was not enough...

I.e.

- they don't check even if you point out it's a mistake - they always side with the copyright owner by default

All they can do is threaten or terminate your access. And even that is debatable. If I create a new browser with BetterStack as one of its features are they going to mandate which browsers I use? What monetary or image damage can they prove? None.

I hope not, but one could argue that the adage that a quality of a product reflects the company that makes is indeed true...

What many commenters do not understand here is that Facebook is making a killing by allowing this kind of illegal targeting. They know what's going on but they clearly don't care unless they get sued. In the meanwhile they made millions/forced the competition out/made it "standard"...

I can't read that article.

"Unfortunately, our website is currently unavailable in most European countries."

In common: we can't be bothered respecting your privacy.

OK then.

I've been trying that, but so far I don't find a big advantage, but it _is_ a bit annoying to have to annotate all types that could be null.

This is to say: it could be good, or it could be another "exceptions in Java" moment

Not surprised, the stories of artists signing for X and getting never properly compensated (either for X or X-extended-to-anything-else) are countless.

And there's little you can do, unless you can nail down the exact culprit to a specific court.

For example: Apple is selling my music, without my consent or without paying due royalties. If I go to them they say "we pay royalties to the distributor", the distributor says "we only deal with labels" and my label has gone bust. Another label now has the rights. They don't know me. They don't have a contract with me. They have a contract with a deceased label that sold them rights they never acquired. So... yeah, it's never going to be fixed.

Totally agree: further to that, if you had int+bool to represent nullable values, you'd also have to sort the ridiculousness of having a null value with a value, also error prone.

Clearly there's a place for null: most languages have it, most developers have no problem with it, it does represent something (lack of information). It is logical and mathematical--I suggest you read the GEB book for tons of more info on that.

That said, people are _also_ free to experiment with null-free languages, or to avoid null. If it works for their use case, fantastic!

Just the attitude of the post is terrible. For example the user creates a sock puppet and posts a trolling/edgy question to Stack Overflow... just to see if it's toxic.

Sorry, these posts are toxic, in my opinion.

Yep, use https://github.com/gorhill/uBlock

> After realizing that everyone, even future politicians post stupid things, We probably will stop caring about online privacy.

Online privacy is not about posting rude stuff on Twitter, come on

> The rationale, of course, is to feed in values that test each code path

That's the absolutely wrong way to test a function. You want to test a function so _as the implementation changes, the same output follows the same inputs_.

Counterexample: I might refactor that function without those code paths (e.g. write `x*sign(x)` instead). Do I need only one test now?

Morale: DO NOT TEST IMPLEMENTATIONS

A mish-mash of good ideas, uninspiring references to Marxism and clearly xenophobic traits--who according to the author can't be said because it's discriminatory, ye ye ye.

I mean, he totally lost me when he started saying "immigration raises crime rates" and other xenophobic propaganda, which is clearly, pardon my French, bovine excrement that people should feel ashamed of.