NohatCoder

Time for a hot take:

You don't need to make your website fast, all you have to do is not make it slow in the first place.

Partially or fully generating a web site client side can be plenty fast, the slowness tends to come from using some bloated framework to do so.

Will also be a great name down the road if they eventually release an RTX 6000 series.

Game 3 and 4 (The Curse of Monkey Island and Escape from Monkey Island) come with the caveat that they are from the Windows 9x period. Getting them to run reliably on a modern computer is an adventure in its own right.

It is hard to generalise about the suitability of Monte Carlo methods. In practical applications it is almost always used in hybrid systems, combined with analytical methods and problem specific short cuts. How one should apply Monte Carlo methods to a problem tends to be an open ended question.

> I can only speak for Microsoft's ERP, but everything that is impossible or hard to extended within the ERP itself can easily be extended through an outside application. And by doing so, you can probably even make the employees job easier by keeping the process the same, but giving him an UI that isn't overwhelming.

But then, did you really gain anything by using an ERP instead of just a dumb database, which would have worked just as well as backed for those applications?

But people don't run it intelligently. For a lot of stuff the intelligent thing to do is use SAP as a plain database and program your own logic. But now what you really have is an inferior database with an inferior programming interface, and you pay through your nose for the privilege. Of course getting to somewhere useful is a battle if you have to use SAP consultants instead of real programmers.

I don't think it is an error. The Russian fleet is deploying ships to a strategic location. That is proactive if they expect a war with NATO. Though it is definitely also provocative.

Sure, but I'd much rather "interview" someone who is actually excited about contributing than someone to whom it was simply the only way of getting what they needed.

You may have had better luck than me.

It always turns out something like:

"Yes, please make that change, but don't do that refactoring/reordering/shuffling whitespace thing you suggested."

Change comes in, it is the actual wanted stuff, on top of refactoring/reordering/shuffling whitespace thing in the same PR.

I always try to be civil, but I can't deny that there is a possibility that some snark between the lines in my reaction may have scared them away.

It is great if you can get the right people. But if you have someone who just needs one bugfix/feature so they can get on with their own thing, they are rarely the right people.

The person in this case clearly want to contribute, so spending time on them may be worth it in the long run.

Maybe a project in Java and web/JavaScript just tends to attract form over function people.

"We should migrate the whole project to use this framework." "The whitespace does not conform to this style guide." "I don't care if it breaks on old Androids, we should use all the new JS/HTML/CSS features, and I have already begun converting the code."

For anyone in doubt, I'm saying this as a maintainer, random people's patches on average suck. Taking those patches is likely to cost me more time than they save. So why would I be adamant about encouraging strangers to write patches?

I really don't understand OSS maintainers that encourage or require people to fix or change things themselves. For a small patch the work of ensuring that the work of a new contributor is good enough is easily greater than just writing the patch yourself. And the time the contributor spent is likely much more.

Give me someone who does enough work that they get well acquainted with the code, or none at all.

If it is not on the hot path, it is likely free, but not guaranteed. If it is on the hot path then it is wasting a whole cycle. And of course in highly ALU-dependent code it is another instruction, so a fraction of a clock.

You Americans, as opposed to blaming logicalmonster for all the misery. And while there are differences between states, none of them have anything close to western European countries.

As for homeless people, you can't tell that someone is homeless just by looking at them. Your personal statistic include only those very visible people who in addition to being homeless have tattered clothes and are incapable of personal hygiene. The majority look like ordinary people.

It is not like you have enough shelters and/or mental hospitals for all those people anyway, and you certainly don't have anyone paying for admitting homeless people to a hospital.

I think what your experience shows is that food is not that hard to come by in the US, the local shelter or soup kitchen may have sandwiches that are superior to yours. Pizza once in a while is way cheaper than a home, not to mention access to medical care, so they get the luxury they can afford.

Those are strings, yes. And while it is perfectly understandable that shelters may need such rules, they do ultimately cut some people off from help.

Other typical strings include strict bedtimes, including getting awoken early and told to leave. Mandatory religious activities. And a lot of homeless people will report being talked down to at shelters, and generally not being treated well.

The good shelters are always filled, if it is cold enough, the bad ones are as well.

Homelessness is mainly a result of poverty, if you want fewer homeless people you should do something for the poor people, so that they may stay or return to being homed. What government programs exist for this purpose are generally woefully inadequate.

Another example of strings attached is SNAP/food stamps. You set up a bureaucratic system in order to give money to poor people that can only be used for food. Those poor people then wonder how they are going to pay rent.

You (Americans) have decided that you don't want to give homeless people help. If the availability of actual no-strings-attached help in the US was more than a footnote, homeless people would come flocking to get it.

While there certainly are individuals whom it is very hard to help, that is the minority.

For a large number of candidates it ends up being approximately 1/e (37%) chance of picking the best candidate, 1-2/e (26%) chance of picking another top candidate, and 1/e (37%) chance of picking a candidate of random skill. That last case occurs when the best candidate was among the first 37% of candidates, which are always rejected, then you run through the rest without finding a better one, and thus end up with the last one interviewed.

If you somehow still have to immediately hire or reject all candidates and care about expected average, instead of just finding the best candidate. The optimal solution will have you reject fewer candidates outright, and then have the criteria for how good a candidate should rank to get hired lower gradually throughout interviewing, and drop sharply towards the end of the candidate list.

Some versions of the problem would have you just pick the last candidate then.

Not really. The problem as described has two issues that makes it unlike most real problems:

1. The problem only deals with optimising finding the best candidate, the "optimal" solution therefore has a high probability of picking a really bad candidate. In reality this failure mode is quite unacceptable.

2. While many real problems will have some opportunity loss by waiting, it is quite extraordinary that options are presented in such a linear fashion. In a real hiring situation you'd generally be able to go back to a candidate you interviewed earlier and hire them.

Shell scripting is just one option for scripting, some popular (and IMO better) options are Perl, Python and JavaScript.

I'm sure there are also people who use C for quick and dirty tasks. Seems weird, yes. But if that is the language you know best it may be the fastest in the short term.

You can use a "real" programming language for anything more complicated than running a program with some parameters. Really, the only thing the various Shell variants have going for them is that you can type it directly into the console. For any lightly complicated programming task they are abysmal languages.

Cost and difficulty versus capture gains probably makes this unfeasible. Making a bog where no bog occurs naturally could be practically impossible.

Always, without fail, whenever the talk falls on taxing CO2, someone will bring up "think of the poor". Usually someone who would otherwise do nothing to help the poor.

It is pretty simple, we have to do something about everyone's emissions, including the poor's. If that places an unbearable burden on the poor, maybe we should do something in addition, in order to help the poor. Like UBI, making public services free, forcing employers to pay decent wages, building sufficient cheap housing, and a lot of other stuff.

This is probably the biggest hole in vanilla js. In particular building a large DOM structure requires so many method calls.

jQuery lets one use an innerHTML-ish style, but it is supposedly guarding against injection attacks in some way. I don't like the hand-wavy way it claims to guard against injections, as basically it has no way to tell what part of a string was meant to be text, and what was meant to be elements.

So I ended up coding my own library. No conversion of strings to elements, so naturally no injections. Very small and simple. But saves a ton of typing when generating DOM structures in JavaScript: https://github.com/NoHatCoder/DOM_Maker

Coming from Denmark I'm impressed that they all use a uk domain, and they even have a system in place to distinguish official government websites from others.

In Denmark we are like: Need a domain for our common ID and login system? How about nemid.nu, where .nu is the TLD of Niue, but "nu" means "now" in Danish, so lol, let's use that. On top of like 7 other domains that users are randomly redirected between during use.

Sure, blame the user, that is the mature response whenever someone is pointing out that modern ID security is a topple tower.

Whatever technical solutions can be made don't really matter unless normal people can and do use them correctly. In any case, simply setting up another non-phone computer to do the job of the smartphone doesn't change the fundamental issue, it can still break, or get stolen, or some account can get closed for spurious reasons.

How could any serious security researcher have been in doubt about Dual EC? The design did not not make any sense at all. Not until you consider that it is designed with a back door, then it is a sleek minimal design that does exactly what it needs to do and not a whole lot more.

If you couldn't see that from a mile away, then you might be too naive to work in security.

They are different, but you can't generally mix and match.