forgotpw1123

PR comments I agree with, but after believing in unit tests for years I'm drifting slowly into the "waste of time" camp.

I'm convinced that unit tests don't usually find bugs. IMO, most bugs are edge cases that were an oversight in the design. If the dev didn't handle the case in code they're not going to know to test for it. Fuzzing is a much better approach.

At my current position I have the opportunity to work with two large code-bases, built by different teams in different offices. One of the projects has ~70% code coverage, the other doesn't have a single test. Exposure to both of these systems really bent my opinion on unit tests and it has not recovered.

The project with high code coverage is basically shit and has so many bugs that we regularly cull anything marked less than "medium" severity as "not worth fixing". This project was written by a team that loves "patterns", so you can find all sorts of gems like Aspect Based Programming, CQRS, N-tier, etc. well mixed into a featureless grey Java EE goo. We get so many bug reports that its someones job to go through them.

The other project with no tests is a dream to work on. Not a single file over a few hundreds lines, everything linted and well documented. Almost no methods that don't fit on the screen, no recursion. No bullshit "layering" or "patterns". I can't remember the last time we had a bug report, since our monitoring picks up any exception client and server side. Every bug I've worked on was identified by our monitoring and fixed before anyone noticed.

Whats the difference between teams that developed these vastly different applications?? I've worked with both teams for a while, and honestly, the engineers that wrote no tests are of far higher caliber. Use Linux at home, programming since they can remember, hacking assembler on the weekends and 3D printing random useless objects they could easily buy. The other team went to school to program, and they do it because it pays the bills. Most of the bad programmers know what they're doing is wrong, but they do it anyways so they can pad their resume with more crap and tell the boss how great they are for adding machine learning to the help screen that nobody has ever opened.

If your developers are great then tests would hardly fail and be fairly useless, and if they're terrible tests don't save you. Maybe there's some middle ground if you have a mixed team or a bunch of mediocre devs??

the more esoteric corners of Java. It's like someone just offered to support windows XP forever. I highly recommenced donating to the Eclipse Foundation, they have made an impact far out of proportion to their size close to Bill Gates, but what they're doing for the good of us all might not be profitable.

... Until the first person ports QT or GTK and suddenly WASM is just pushing 60 PNG frames a second into a canvas.

holy shit

The authors main complaints seem to focus around "but Typescript isn't ES6". I don't have a problem with this because Typescript compiles down to very clean vanilla JS. Unlike C++ to C, Clojure, and Babel the compilation down to JS is extremely good in comparison.

Good enough that I usually debug the Javascript output. Typescript has the cleanest transpilation I've ever seen so I don't have any problems with using it. And if Typescript ever falls out of vogue I'm confident just compiling down to JS one last time and being done with it. Really the language is so easy to get rid of its harmless.

Yup for me I would say over 30%. I'm sure Consumer Reports will do a study soon and find that near 50% are counterfeit and the stock will drop like a rock.

Because Amazon makes too much money off it to do anything about it. They could easily track everything... but they obviously don't.

+1 for B&H. They're replaces amazon for all my audio and general electronics purchases. Generally the same prices without a chance of counterfeits.

Or any type of wireless headphones. Not sure the percentage, but never got a pair that was real.

In fact I don't buy anything from Amazon anymore...

the website and even the domain name are suspect.

Weather is a huge issue for Disney parks. Both are busy all year round and a third park would be no different. It makes no sense to open parks that can only make money part of the year. The data shows the busiest times are December, March, and May so it would be really stupid to put a park anywhere those months have bad weather.

This leaves the South and West Coast. Dallas and Oklahoma City are the only realistic places for another park that's easier to get to from the Midwest.

the last part was just for the lulz. I figured a facebook quality post needed some facebook quality comments.

I don't think it's anywhere near conclusive yet that more layers = better. It's pretty telling that the current state-of-the-art is combining a bunch of layers together in a pseudo random fashion. Nobody understands how these things work to the point that we can make a formula or equation to produce better CNN's, or even predict which models will be more effective to any accuracy. You think more layers is better, because the best models we have happen to have the most layers? Some deep understanding of concepts there.

This comment is absurd. "Your CNN sucks, I know this because I work with better ones all the time. (insert metric that doesn't mean much)"

Oh, BTW I do ML consulting lol

>My next company will have explicit rubrics for what it takes to get fired, and your status will be tracked daily

>You'll know at all times exactly how close you are to getting fired with how much severance

Good luck getting anyone to stick around! People want job security, they don't want to feel like they're walking on eggshells every day. You seem to think the only thing people want out of a job is money.

>Anyone we fire we'll sit down in the exit interview and write a plan for how they can get re-hired in a few weeks or months if they're interested.

I don't think you know what firing means. It's not a mutual decision and you really don't want that employee working for you at that point. It's a serious legal risk to re-hire fired employees.

Like I said, the major exception is SIMD instructions. AV and heavy math are a tiny fraction of applications. For these you can use JNI.

There is precedent for this in Netty where they use a native poll mode driver and everything else Java, and it performs about as fast as pure C code on Techempower benchmarks

a "fix" eh?

This just isn't true. There's many Java ports of C/C++ applications and benchmarks are usually within 30%.

The level of indirection is minimal, basically c++ with garbage collection. That's why they're statically typed.

Both perform within a small margin of native code, with the major exceptions of vector instructions that aren't supported by all CPU's

No. JS is not statically typed and that prevents the vast majority of optimizations and better memory efficiency(native types underneath).

Amazon is finally paying for the rampant counterfeits in their supply chain?

All of those left-pad libraries are a jest, it's trivial to do padding in those languages. I was wrong about Python and removing packages but on Nuget and Maven you can't, its not allowed.

I think it's worth noting that with Java at least, besides not allowing package removal, the namespace is tied to a unique identifier with ownership verification, so the cause of the left-pad fiasco (kik wanting his namespace) is extremely unlikely to happen in the first place.

More like it doesn't work as well as any other package manage I've used :)

There's a ton of annoying little stuff (like doing nothing to prevent path names too long for your filesystem) that could be forgiven for being young, but the big problems are in its architecture.

Node module syntax is non standard and can't be tree shaken, with a little more forethought it could have been designed to support static analysis and they wouldn't have needed to reinvent the module syntax for ES6. You can't reliably tell if a piece of code is using a given package until you run it.

The dependency resolution sucks. It's better now that they finally made it so nested dependencies aren't duplicated, but why the hell do I have to run a manual dedupe command to do so? What that tells me is that npm doesn't actually track dependencies, its hardly more than a fancy file downloading tool.

The repository curation sucks. I'm not sure if you've used Python's package manager, or Java's, or C#'s, or Perls, but npm has zero package curation and is filled to the brim with garbage compared to the others. I have published packages for C# and Java and the semantics are well defined and reasonable, you even cryptographcally sign your code and the system checks to make sure you upload documentation etc... In the case of java, which has the best system I've seen, they even use something similar to DNS validation to make sure you control package namespace.

The above point is the absolute worst thing about npm and drawfs the other problems. Let me give an example by pasting the package publishing guidelines for Maven(Java) vs npm:

Publishing an npm package: >Use npm publish to publish the package. >Note that everything in the directory will be included unless it is ignored by a local .gitignore or .npmignore file as described in npm-developers. >Also make sure there isn't already a package with the same name, owned by somebody else. >Test: Go to https://npmjs.com/package/<package>. You should see the information for your new package.

I had to condense the Java guidelines but it's roughly this: create JIRA account apply for access review requirements verify namespace ownership generate crypto keys package coordinates/versioning project description URL and license info developer info SCM info package deployment generate binaries revolve package dependencies crypto sign package generate documentation online verification

Sounds like a lot of work right? It takes a few hours to setup and verify your domain/keys the first time but after that all of these steps are automated. The signing/building/doc generation/ deployment is totally automated. Npm is a toy in comparison.

from their docs: Why Do We Have Requirements? In order to ensure a minimum level of quality of the components available in the Central Repository, we have established a number of requirements your deployment components have to meet. This allows your users to find all the relevant details about the components from the metadata provided in the Central Repository. The following sections will detail these requirements.

Left-pad is a perfect example of why npm sucks. Nuget, Maven, Phython, and CPAN would have never let something that stupid happen.

This is risky to say but... NPM is a bad package manager. I could blab about why forever but tons of other people already have. I've never used a popular language with a package manager as bad as npm.

That won't work for me because I'm pretty low on the chain. Its hard to show your value when you're treated like a piece of machinery.

I think I just need to make a rainy day fund then go straight into contracting. If I can line up a couple 6 month contracts with no IP assignment clauses I should be good to go

Yes, there are resource controls in MS SQL server as well.

Here's a link to a site I use frequently for these sorts of things. I apologize for not including a citation, I figured most people were familiar with it or similar services. https://www.google.com/search?num=100&q=oracle+benchmarks+ag...

The first result is a blank copy of a license agreement that they presumably forgot was on their website.

I don't like Oracle DB really, but there's one feature that does stand apart from Postgres. Oracle has an internal scheduler that works much like an OS scheduler, allowing you to set priority and resource usage for each user or connection. This made Oracle the go-to database for anyone that needs multi tenant support but wants to allow users to access their own database. If you allow database access its trivial to create a really slow query and the resource limiters prevent one tenant from ruining performance for everybody.

The best example of this is Salesforce, which has their own proprietary SQL-like query language that's clearly just a crappy front end to generate raw SQL to feed their Oracle DB's. Without Oracle's per-tenant limit this would be far too risky because of idiots making bad queries.

An better solution these days is to put each tenant in a Postgres container and let the OS control resource limits for them, but this wasn't an option until recently.

Did you know that Oracle forbids "unauthorized benchmarks" for any users of its database products? It's curious that a database with such amazing performance characteristics would not allow third party benchmarks against other products.