Recent submissions

Comment · 7 years ago
We are using it to write Express (node.js) middleware via Neon (https://github.com/neon-bindings/neon). This has a few key benefits:

* Progressively introduce Rust instead of replacing entire applications (Rust really shines in this area)

* Leverage node's strong HTTP and routing story while waiting for this to stabilize in Rust

* Leverage existing tooling for APM, config management, etc.

For example, one middleware verifies the request body with a signature from a header. Another one parses the body from a `Buffer` to JSON, transforms, and serializes as protobuf.

Comment · 8 years ago
The `miscreant` library also does this: https://github.com/miscreant/miscreant. It's really effective. For example, any method that requires a one time pad takes ownership. This allows the borrow checker to validate that you don't accidentally use an OTP more than once.
Comment · 8 years ago
Interestingly, I was able to get an amazing speed improvement without going completely to Rust.

I didn't want to port APM code as well, so I kept node.js/express for routing. Very simple middleware that immediately passed the request and body buffer to Rust for handling. Rust returned a buffer back to express for sending the response.

It's easily able to hit 100k RPM on a single instance before hitting a CPU bottleneck in the Rust code (validating an RSA signature). It only needs to handle 90k RPM total.

Comment · 8 years ago
Comment · 8 years ago
This. I'll also add that in the world of things like Docker and [Insert]CI you don't need to mock most external dependencies like databases.
Comment · 8 years ago
It's interesting that this went _beyond_ a prank. Almost the definition of "fake it until you make it."
Comment · 8 years ago
> "...review design docs"

In my opinion, one of the most important and most difficult parts of the job. Architecture and design shouldn't be limited to senior engineers--it won't be in practice, anyway. Doing so is a sure fire way to stilt the growth of your team.

But, reviewing designs is hard. It requires recapturing much of the context that the engineer gathered in a very short period of time. I also find it sometimes difficult to separate, "this is a fatal design flaw" from "this isn't how I would do it." I really like the suggestion of providing feedback via additional information.

Mistakes are a very important part of learning. I try to make sure everyone has the opportunity to make their own instead of making mine.

Comment · 8 years ago
Comment · 8 years ago
FWIW, I just checked and they don't use an iFrame approach. This means their entire checkout page must be in scope for SAQ-D.
Comment · 8 years ago
Unfortunately, PCI does not put very many restrictions on the parent website. If credit card elements are in an iFrame, the parent site is excluded from most requirements because the iFrame is "secure."

Of course, if you own the parent site you can replace the iFrame with anything you want.

Comment · 8 years ago
Comment · 8 years ago
They may also be uncertain what another driver will do. For example, turning right onto a two lane road may be safe if the right lane is open. However, despite it not being legal, a driver in the left lane may change lanes mid intersection. I'd prefer not to risk it to save myself a few seconds.
Comment · 8 years ago
About as confident as I can be without having insight into their perspective. I'm mostly referring to right turn on red scenarios where I'm not comfortable with the risk. Although, the occasional honking immediately after a light turns green also occasionally happens.
Comment · 8 years ago
Every single time someone honks at me for this, I'm tempted to stay in place longer than necessary. Fortunately--most of the time--I think better of being this petty and passive aggressive.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton