HN user

dallbee

149 karma

pgp public key: B2CA59B31953BDBF3E4A25030D2777561124F519

Posts0
Comments61
View on HN
No posts found.

I am a hiring manager and we do take home homeworks. I fully agree that this is a key piece of communication. I always take the time to tell candidates that although they have as much time as they want, we expect 2-3 hours of effort at most, to be respectful of their time. Without that, take home problems would seem predatory.

I cannot upvote this hard enough.

I see this all the time with VPNs. By having everything behind the company VPN, application security isn't taken as seriously. As a result, lateral access becomes trivial at these companies.

Keeping everything public internet exposed from the start actually results in better security.

A trick I often use to get the most out of messagepack is using array encoding of structs. Most msgp libraries have support for this.

This gives you a key benefit of protobuf, without needing external schema files: you don't have to pay the space of the keys of your data.

This is simply not something you can do with JSON, and depending on your data can yield substantial space savings.

This was one of my favorite Google products. It worked exactly as advertised, no frills. Since its release, I haven't once needed to pull out my old Brother document scanner.

The maintenance burden for Stack cannot have been significant, and yet I guess I am unsurprised to see Google add another good app to their graveyard.

What do others use for this purpose?

I've found this difficult as well, my mother always jumped right to antibiotics and it had some pretty clear long term consequences.

My approach with my kids has been to use antibiotics only if there's no progression (better or worse). I figure as long as it appears the immune system is doing its job, that's enough for most cases.

So far, we've given our 3-year antibiotics on two occasions. Once for an ear infection that wouldn't clear and for when he had pneumonia.

I will have to see if their NFSv4 implementation has improved any. When I added support for EFS to my company's NFSv4 client we ran into a couple of performance bottlenecks and just general spec non-conformance.

Specifically, we noticed lack of support for these features:

- session trunking (and, in general, multiple channels)

- multiple concurrent requests on a channel (ala ca_maxrequests)

- callbacks

ca_maxoperations was quite low (10, I think?), and they limit the number of parallel clients that you can access EFS with at once.

What this amounts to is that you can reach acceptable performance on file reads/writes, but metadata heavy access patterns have no hope of reaching the advertised IOPs. It's a shame because frankly metadata performance is something NFSv4 excels at.

Unfortunately it's common to have a policy in place disallowing 3rd-party app api access to drive storage. This prevents apps like rclone from working, but the drive client works because it isn't 3rd-party.

This is the practice we use - link to a ticket if it exists.

There's nothing wrong with fixing a bug you discover upon inspection. Forcing tickets for every change discourages code maintenance.

This enables newer cards to have updated security features. If there were no expirations, then you'd just make fake ids targeting older versions.

Your skepticism made me look through the library more carefully. I came across some limitations in comparison to what Go provides:

1. As you suggest, there's no equivalent to the `select` mechanism. To perform the equivalent, you must busy loop and call `csp_chan_try_pop`.

2. It appears you cannot nest coroutines.

3. The mutex implementation does not provide an RWMutex.

4. `csp_yield` seems somewhat necessary for practical applications.

Normally I would not use another language as a basis for comparison to a C library, but that's precisely what the author of Libcsp appears to be aiming for.

All that said, there's a really slick implementation of a lock free RB queue backing this library, and It's a neat project. I think it would stand on its own better than as a "go style in C" library.

You're certainly not alone, but I've had such a wildly different experience. I switched to duckduckgo primarily because I preferred the search results. The privacy aspect was just a bonus.

The only time I ever find myself using the !g escape hatch is when I'm searching something brand new (e.g. a breaking news story). Duckduckgo has a recency filter but it seems to take them a few days to ingest the content.

My understanding of the bill is that the tax would apply to the strike price value. $100,000 in strike price is quite a lot more than what your typical startup employee has, and that first $100,000 per year isn't even taxed. For this to apply to you, you'd have to be receiving a ton of options.

I'm on board with your first suggestion - it all gets a lot simpler (and fairer) if you just tax the realized gains.

For the rest though, it may be worth pointing out that the first $100,000 in qualified stock options _per year_ are not taxed. If you're in a situation where the taxes on $(your annual options) - $100,000 are significant in comparison to your rent, I'd wager you're doing pretty well.

It is a performance hit and I initially had the same reservations. Importantly, the implementation imposes a small overhead on the access time of iteration over a map, but not in a way which changes the scaling behavior. Other map operations are not implicated.

I think the decision was wise - it prevents user code from relying on ordered iteration behavior, which allows the go team to switch to different map implementations without fear of breaking user code.

If the order had been unspecified, but iteration was still ordered in practice, there'd undoubtedly be (incorrect) user code that relied on that behavior.

Amusingly, I now run into engineers who are under the misconception that map iteration is random, and proceed to use maps as an RNG. That's an unfortunate mistake because Go's map iteration is quite non-uniform - it's shuffled just enough to appear random to the untrained eye, while be performant.

PHP in 2020 7 years ago

After years of working with PHP, my take away was similar to C++: There's a great language in there, somewhere. Limit yourself to a subset of the language which is sane, follow all of the PSR standards, and the result is quite nice.

After all of that, you look at your coworkers' code and realize they either (1) picked a different subset than you did, or (2) PHP is their first language and they have no idea what they're doing.

I mostly stay away from web development now, but if I were to do a new web project, I might still choose PHP if I knew I'd be working with a small, experienced team. It's a highly productive language.

Battle Chess 7 years ago

I had Chessmaster 8000 and the engine behind it was always really good at mimicing realistic playstyles. It had presets, and you could control things like pawn weakness, willingness to trade, king safety, and preferred pieces.

Modern chess engines usually have a notion of "contempt". I've found that if you turn contempt way up and limit the number of concurrent lines, in combination with adjusting the target rating, you can get a reasonably good approximation of real play. At casual (< 2100 maybe?) levels of play, this simulates the human tendency to make blunders while fixating on a plan.

A lot of my coworkers were getting hung up on this point too. I think they're just emphasizing that large channel buffers can hide concurrency problems, so you want to be careful when using them.

The last sentence in the recommendation emphasizes this: use them with scrutiny.