To me, it seems to be the same as the Norvig algorithm, except that only deletes are considered. Which allows them to pre-calculate misspellings with modest storage cost.
Been in a few orgs. I now think "no rewrites" is a good policy for all but a few orgs. Few orgs have the (1) business luxury (time and money) or, (2) the caliber of people and, (3) team motivation (few teams people even want to improve things) to pull off rewrites.
The best orgs do a rewrite usually in the face of sea changes to the technology stack (e.g., containers vs. VMs) or business use (number of users is now 10X of original etc). Bringing key infrastructure in-house is also a decent reason, but the benefit of building expertise in an existing ecosystem vs. full rewrite should be carefully weighed.
I like functions that return a value to be written in the guard-clause style. [In C++, that's probably better for efficiency since the compiler optimizer doesn't have to remove temporaries by converting the code to guard-clause style.]
However, I'm not convinced that void functions are better written in the guard-clause style. I think the intent of the code is better expressed with nested ifs. Of course, try to factor the ifs so that they're readable.
I'm saying this is more readable if the "do something part" is less than about 15 lines. Thoughts?
void do_something(input) {
if (!input.already_done()) {
// do something.
}
}
No story here. No budget provider I've looked at says they will help you withstand a DDoS attack. [Thanks to the commenter who says OVH does, I will look into them closely.]
I did this due diligence for a 10-user app. These guys have no excuse for not planning for a DDoS with a serious business.
Yeah, I know this is just an Internet forum so who cares what's said right? But ...
But Ask the Korean made an excellent point about culturalism: "The term "culturalism" is my coinage ... is the unwarranted impulse to explain people's behavior with a "cultural difference", whether real or imagined. Because the culturalist impulse always attempts to explain more with culture than warranted, the "cultural difference" used in a cultural explanation is more often imagined than real. To paraphrase Abraham Maslow, to a man with a culturalist impulse, every problem looks like a cultural problem."
Is it still the case that updates from Apple will randomly break a Hackintosh? It used to be the case a few years ago. Has it gotten easier to update a Hackintosh these days?
Thanks for the response. I get the A+ site when I directly visit via IP.
I went through the delta between the reports with a fine-toothed comb and discovered that SNI wasn't the problem. It was a biggie: looks like HSTS wasn't enabled for visits to the static part of the site (like the homepage).
It seems like Nginx is doing something counter-intuitive. I've set HSTS at the server level using the 'add_header' directive.
I've set 'max-age=0, must-revalidate' at the location level using add_header for the static parts of my site. I expected Nginx to add both add_headers, but it only seems to do the "deepest" set of add_headers it finds.
Duplicating the 'add_header' directive at the location level (resulting in two add_header directives) results in HSTS being sent for the static parts also.
I host two sites on the same IP. The first site declared in my nginx conf file got A+. The second one got A with a note that it doesn't work in browsers without SNI.
> everything-is-string semantics make programming an exercise in quoting.
Is your code filled with literal strings? Otherwise why your code be "an exercise in quoting"?
re Python: Remember that EDA tools aren't libraries, they're actual command line program programs. So those tools will still need a command line language. Python is horribly unsuited as a command line language, so the tool will probably continue to have Tcl to present the text user interface.
So you'll then end up with two interpreters in the same tool. Hardly a desirable state of affairs. So yeah, I think the ROI of embedding Python in EDA tools is probably not doing to be worth it.
A lot of the C code backing the Tcl APIs directly build Tcl objects or store pointers to Tcl objects in C. It will be giant task to make those APIs work correctly with Python also.
I had zero problems reading the print version.