HiJon89

Using observed latency, power of two choices, and requests in flight reminds me a lot of Finagle https://twitter.github.io/finagle/guide/Clients.html#p2c-lea...

Not sure I follow. The function coloring problem is still solved in that scenario. You can apply structured concurrency to any function (there’s no colors), and any function can contain structured concurrency within it (ie, using structured concurrency doesn’t color your function)

Really cool analysis and visualizations! Although there’s an interesting wrinkle with Mario Kart 8 + 200cc - most players don’t want speed over a certain level because you’re too fast to control. So rather than trying to maximize absolute speed stat you may want to minimize the delta from your optimal speed stat

My Plex lifetime pass is still going strong

> Another common example is when you are implementing an interface method or overriding a superclass method

This doesn't seem to be supported and could cause many issues e.g. if a base interface adds an overloaded method with a similar signature. Suddenly we will have a conflict and compilation issues.

I think this is already a risk when modifying interfaces or superclasses. For example, if you add a method to a superclass, a subclass might already have a method with the same name/arguments but different return type, which would break compilation.

A common example is try-with-resources where you don't actually need the resource and are just using it for the closing effect. For example, let's say you have a metrics library that allows you to time code blocks like so:

  try (Timer ignored = Metrics.newTimer("getOrders")) {
    return db.getOrders();
  }

This JEP would allow stronger static analysis rules like "every declared parameter and variable MUST be used", and _ would serve as the canonical escape hatch for edge cases.

One datapoint: searching our codebase for variables named "ignored" produces >1,000 hits. And probably an order of magnitude more unused variables that aren't named ignored.

What if your system is the one actually sending the emails (ie, you are the 3rd party in this scenario)

When do you record the message as processed? If you do it before the processing is complete, you have at-most-once delivery (because processing could fail after you've recorded it as processed, and it won't be retried). If you do it after the processing is complete, you have at-least-once delivery (because marking the message as processed could fail, and it will be retried).

What if the receiver process fails? How do you know which messages it processed successfully? You can shuffle the problem around indefinitely but it doesn’t go away.

If your processing doesn’t have any external side effects (make external API calls, send emails, charge credit cards, etc) then one option is to put your message queue in a relational DB alongside all your other data. Then you can pull a message, process it, write the results to the DB, and mark the message as processed all inside one big transaction. But not many use-cases can fit these constraints and it also has low throughout.

Thanks for making the previous poster’s point for them.

Thanks for the great writeup and the great work!

The fact that half the comments here are dismissive or condescending is such a sad indictment of HN culture :(

With 2 million users, I imagine it would be on the order of thousands of posts per day, and maybe hundreds of reports?

How would that work for something like S3 range requests? Rather than reading an entire object sequentially (which would work fine with transparent compression) you can also ask to read an arbitrary byte range (give me bytes 1,000,000,000-1,000,001,000 from the original file). I guess you could maybe store the compressed file in chunks with metadata about the original byte range inside each chunk.

There was a later tweet clarifying that an update (presumably over-the-air) was released in 2021 but for some reason not all devices received it.

Quote:

Now it seems an update was available and has been rolled out end of 2021. But many H5000 did not get that update and now, as the certificate has expired, this update cannot be installed in the usual way.

I expected the top comment on hackernews to be something this pedantic and irrelevant to the content, and I was not disappointed

  We don’t need to write a test that tests this function as a whole, we can test the parts we care about independently.

Limited driver assist? Are all the videos of people using Tesla full self-driving on YouTube fake?

Or maybe the sad state is that there are still people dying every day from a pandemic THAT WE HAVE A SAFE AND EFFECTIVE VACCINE FOR.

I had to read that sentence a couple of times but I think it’s just poorly worded. He’s not saying that the person is old, he’s saying that the reason for wanting to fire them “you are not doing a great job”, is a “plain old” reason

I think this misses the point, which is called out directly at the top of the site:

"jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application.

If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency."

If you're shipping a big application and need to use a large number of these utilities, by all means use jQuery. But if you're shipping a small library and only need one or two of these functions, you might want to forgo the dependency. Using jQuery in your library forces it as a dependency onto everyone who uses your library, potentially making them deal with version conflicts if your version of jQuery doesn't align with their version of jQuery (or the version that another dependency wants).

For some context, S3 used to provide read-after-write consistency on new objects, but only if you didn't do a GET or HEAD to the key before it was created. So this access pattern is all good:

  PUT new-key 200
  GET new-key 200

  GET new-key 404
  PUT new-key 200
  GET new-key 200/404

  GET com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 404
  PUT com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 200

  GET com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 404

Because updating an existing object in S3 didn't have read-after-write consistency, we could have a publishing flow that looked like:

  GET com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 200 (v1)
  PUT com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 200 (v2)

  GET com.example/example-artifact/1.0-SNAPSHOT/maven-metadata.xml 200 (v1)

We ended up just switching to GCS because it was relatively straight-forward and gave us the consistency guarantees we want.

We used to use S3 for Maven artifact storage. This is mostly an append-only workload, however Maven updates maven-metadata.xml files in place. These files contain info about what versions exist, when they were updated, what the latest snapshot version is, etc. We would see issues where a Maven build publishes to S3, and then a downstream build would read an out-of-date maven-metadata.xml and blow up. Or worse, it could silently use an older build and cause a nasty surprise when you deploy. It only happened a small percentage of the time, but when you’re doing tens of thousands of builds per day it ends up happening every day.

We switched to GCS for our Maven artifacts and the problem went away.

Awesome, thanks for the response. Looking forward to trying out Sourcegraph again

Seems like this is in the works already, but the boolean operators in OpenGrok are so intuitive and powerful. I use them every single day and the lack of support in Sourcegraph immediately disqualified it for us. For example yesterday I was looking for Dropwizard Managed classes not annotated with @Singleton so I did:

Managed && !"@Singleton"

(I'm omitting the fully-qualified class name for brevity)

If I also wanted to look for HealthCheck classes I could update the query to:

(Managed || HealthCheck) && !"@Singleton"

I think it also helps that OpenGrok has a separate input for filtering file paths (completely splitting the "where" and the "what" parts of the query). And this file path search supports the same boolean operators. So if I want to narrow my search to two particular repositories I could put CrmSearch || AutomationPlatform into the File Path input. And because this input only handles file paths, I don't need to remember any special syntax. Whereas if you clump the entire query into a single input, then users need a way to tell you whether a search term applies to file paths or file contents.

For #5 I believe it's not just a self-XSS, but also executes on the support agents browser, allowing you to potentially exfiltrate their cookies:

Anyone can write malicious code into the chatbox and PayPal’s system would execute it. Using the right payload, a scammer can capture customer support agent session cookies and access their account.

How about working to improve those take home projects since it seems to be more promising than the whiteboard interview which is doomed to suck. For example, my company has a take home project that involves hitting some APIs and doing some stuff with the JSON they return. It shouldnt take more than an hour and we give a time limit of 3 hours just so people don't spend days on it.

Engineers: coding exotic data structures on a whiteboard in a time-crunched interview is high-pressure and unrealistic!

...how about we give you a project that more closely reflects problems we solve here day-to-day that you can solve in the comfort of your home on your own hardware in whatever IDE makes you comfortable?

Engineers: That's absurd! I've drawn a line in the sand!

[Copying my reply from reddit]

I can give you some background on the way we structure things in case it's helpful. We use GitHub for our open-source projects, GitHub:Enterprise for our internal code, and our engineering team has about 300 engineers. Each project or feature usually lives in its own repository, and is split into a number of Maven modules. Using the maven-snapshot-accelerator ( https://github.com/HubSpot/maven-snapshot-accelerator ) as an example, it's roughly 1,000 lines of code split into 6 Maven modules (representing a small percentage of what my team owns). There's the root pom which just aggregates the other modules, a core module that contains the POJOs, a REST API module that uses the POJOs, a client module which uses the POJOs to hit the REST API, a module for the maven plugin, and a module for the maven extension. If this was an internal project, it might also have supporting Hadoop jobs, Kafka workers, Spark jobs, etc. depending on how the system was designed. Each of these would usually live in a separate Maven module. I'm not sure how much thought we gave to splitting into Maven modules along these lines, it just kind of seemed natural to us. It also has a few benefits compared to larger modules:

- The dependency trees are smaller, because you're pulling in a more focused set of libraries rather than the kitchen sink

- Our build infrastructure only builds what has changed when you push a commit, but it can only do this at Maven module granularity. So by splitting things up this way, pushing a change to your kafka workers won't rebuild your Spark or Hadoop jobs.

Using one of our larger open-source projects as an example, Singularity ( https://github.com/HubSpot/Singularity ) is split into 15 Maven modules (and represents maybe a third to a half of what that team is responsible for).

Snapshots vs. versions is a whole different topic and probably deserving of its own blog post. More generally, whether we should bend our workflow to the tools or bend the tools to our workflow is a constant tension and something we're always thinking about, so feedback is always appreciated.

Gigafactory is a proper noun referring to the specific battery factory built by Tesla; I just didn't bother to capitalize it

How long will it take them to catch up with Tesla (while Tesla is simultaneously advancing their own battery tech)? And even if they can hit that milestone, they'd presumably have some amount of profit margin built into the prices. So to actually compete with Tesla on battery price (and why would they even want to) they'd need to advance beyond Tesla in terms of manufacturing efficiency and/or volume. I don't know of any company poised to fill this gap in the foreseeable future.