devanl

To add on to what others have already mentioned, the PDF has more details on bisphenols which paints a less dire picture than the press release.

1. There are no EU-wide regulations restricting on BPA concentrations in electronics devices.

2. The ECHA has proposed for limits is 10mg/kg which is also used for the OEKO-TEX Standard 100.

3. In the study's evaluation criteria, for parts to achieve a green rating for bisphenols, the concentration has be below 0.8mg/kg for parts touching the skin and below 10mg/kg for parts not touching the skin.

4. 69% of the tested samples achieved a green rating for bisphenols.

So while there is a gap in regulations ensuring a safe baseline for electronics, the majority of the tested headphones are doing okay as far as bisphenol exposure even under the proposed guidelines.

The black and silver and white and silver sample photos look like they may be using HASL surface finish (aka, solder).

If you're handing out business cards with a HASL finish, make sure to spend extra for the lead-free version.

Huh, that's quite a bit more than I would expect. You already ruled out the 12V battery in the other thread, but there could be some other factors that would keep your car awake.

Does it only happen when you park in front of the garage at home, or does it also happen if you go out somewhere? For example, it might be struggling to connect to your WiFi at home (if you set it up with your home WiFi credentials) to download updates or upload telemetry, which would keep it awake longer than normal as it tries to make do with kilobits per second of usable bandwidth.

While the idle draw is relatively high on Teslas compared to other EVs (even without sentry mode enabled), 7.5% is quite high. I track my stats with Teslamate and it estimates typical SoC loss of 1% over a day.

What I have seen is that the BMS may update its SoC estimate after driving, and I've seen it adjust the estimated SoC up or down by as much as 5% in some cases.

I get that from a planning perspective, it still stinks to have range than you thought you did an hour ago, but it's not all that different from the variation you might get with an analog dial on the gas tank, just that it's much easier to notice and track when it's digital and showed as a precise number.

The typical level 2 charger doesn't have to use HomePlug, but most recent EVs will have a HomePlug modem in order to speak ISO15118 to negotiate the voltage during DC fast charging through the CCS1/2 connector.

The pilot pin that carries the square wave used for J1772 is common to both AC and DC charging, so it's possible for a level 2 charger to incorporate a modem and communicate with the EV.

In many situations it would be an unnecessary expense, but it may become more common even in level 2 chargers in the future since ISO15118 can be used to authenticate the car to the charger for plug-n-charge charging without needing a card or app to authorize the charge.

This feels a bit like a case of a "Python from 10 years ago in my head" vs "Python from 10 years ago in reality" meme.

Chained comparisons have been in Python since I started using it at 2.1. It looks to me like they've been there since at least 1.4:

https://docs.python.org/release/1.4/tut/node40.html#SECTION0...

That's pretty much exactly what they're saying in the video.

They show their off-the-shelf dev kit which features a generic omni-directional rubber-duck antenna with quoted 1dB of gain (essentially nothing) and 21dBm of transmit power.

In Rust, you can't implicitly omit fields when instantiating a struct, so it would have to be a bit more verbose, explicitly using Rust's analog to the spread syntax.

It would have to look something like:

  f({ hours: 2, seconds: 53, ..Default::default() })

As hinted at, but not elaborated on by the first part that mentions temperature monitoring, those wires in free air expand and contract with temperature changes. The cables need to be able to support their own weight without collapsing or touching other conductive objects like other cables or trees.

Adding more conductive material helps with the resistive losses, but also makes the cable heavier. Using an advanced cable that has better tensile strength for the same or better conductivity accounts for those second order effects better than just adding more aluminum.

Taxes in the US are locality sensitive. The county sales tax rate varies by almost a full percentage between counties where I live, so depending on whether I ship something to my home or to the office, the amount of sales tax due is different.

I've observed that Comcast takes advantage of the separation of "fees" into a separate category to increase fees while keeping the service rate the same, allowing them the flexibility to raise prices even if the customer is on a contract that specifies a fixed promotional rate.

So it seems like the current breakdown of charges gives rise to transparency in price, but only because it's in Comcast's favor when it comes to adjusting the numbers. I'm not sure that Comcast would bother continuing to break things down if it no longer gives them an edge.

Setting aside issues that can be safety related where consumer equipment overlaps with legacy equipment, there is a tragedy of the commons effect to not attempting to regulate radio power limits.

It's incredible how well WiFi works for the amount of power it uses.

Obviously turning up the transmit power makes it better... for that one person. For everyone else, that channel has a little bit more noise than before, making it harder to receive their signal.

So maybe their neighbors will also want to increase their transmit power to get better range / speed again. Having a limit across the board for all mass manufactured devices prevents an escalating spiral of vendors selling 30, then 40, then 50dbm etc routers.

As mentioned elsewhere, different countries have different power limits, but it's more economical to make a single radio for all markets with software power limits. One hypothetical way for a vendor to get a market advantage is to sell a radio that is software limited, but wink wink can be patched with easily googled instructions to increase the power to work better. Maybe by downloading a tool from some sketchy website that even actually works and can be spammed across the internet or social media.

So the FCC has to strongly discourage anything that could lead to lots of radios deliberately exceeding the regulatory limits and disproportionately making the spectrum worse compared to a compliant device.

I don't think that necessarily justifies rather invasive schemes like geolocated AFC, but preserving the use of the radio spectrum so that everyone can make efficient use of it is the FCC's mandate.

It's been a while since I've tolerated the git gui interface, but when I used to use it, the line-to-chunk logic would regularly fail on short 2-3 line spans.

There's a stackoverflow discussion [1] that suggests it was fixed in 2018, but for many years it was a terrible experience that pushed me to use other frontends just for reliable partial staging.

1: https://stackoverflow.com/questions/58133092/git-gui-error-f...

I've deployed an internal version of the upstream project (ya-webadb [1]) before. It can be built as a static site, and the upstream version publishes to GitHub pages, so it's really easy to self-host.

1: https://github.com/yume-chan/ya-webadb

In case you haven't seen the UF2 file format, it's specifically designed to be robust w.r.t ensuring that the content makes it to the target intact despite common OS quirks.

https://github.com/microsoft/uf2

  - Data is divided into 512 byte blocks, which lines up with the mass storage transfer size.
  - Each block has an identifying magic sequence, a payload address, and size, which can be used to identify the destination.
    - This allows the emulated storage to ignore metadata blocks and to handle out-of-order and repeated blocks.

I've looked into this in the past. I would suggest using the full GDPR-style takeout-all-my-data request from:

https://www.netflix.com/account/getmyinfo

As one would expect, Netflix's tracking provides quite a bit more detail. Whereas "NetflixViewingHistory.csv" only provides the title and a date, the "ViewingActivity.csv" from the takeout includes:

  - Start timestamp with resolution down to the minute
  - Watching duration with resolution down to the second
  - The reason you watched it (e.g auto play or not)
  - If the thing was one of those autoplaying trailers, as opposed to a real video
  - What Netflix client type you used (e.g browser vs smart TV vs phone)
  - At what timestamp you stopped watching

The initial WebUSB proposal included the notion of "allowed origins", but it was eventually removed in favor of user freedom.

The device can provide a landing page URL for the browser to show when the device is plugged in, but otherwise any site meeting the secure origin requirements and that has user permission can access a USB device, same as any other website.

In my mind at least, the issue with relying on on ownership, especially in a smaller team with limited resources, is that the owner isn't just the person who authoritatively understands that subsystem. The owner ends up being assigned _all_ of the work on that subsystem because it's "their responsibility".

As a result, any work that's assigned to someone else will only interact with at the interfaces / boundaries. And of course, that's sort of the intention with modularity / loose coupling - it's not necessary to learn the gory details of the XYZ subsystem's implementation, only its API. Knowing the details is certainly valuable, but there's no baseline impetus to get the owner to explain the details.

Taking over from someone who's ceding responsibility, but staying at the company, I agree that's manageable. But sometimes people get laid off suddenly (or perhaps get hit by a bus, etc) and there's no chance to get the one person who has it all in their head to explain it to you.

You mentioned high turnover, but if anything, a place with high turnover has less information locked up in a single person's head. If Alice who's worked at the company for 25 years and has always owned the code leaves, you're going to have a much harder time getting all of the tribal knowledge out of her head on two weeks notice compared to Bob who only made it 6 months.

To me, the value of code review is that even at its worst, someone other than the author is forced to look at the code. No process can force a reviewer to take an active interest in a particular subsystem, but at least we can make them look at pieces of it and see if it gets them curious enough to ask further questions of the author and better understand the system.

For myself, knowing that someone else will have to understand my code, even through the limited lens of a code review, makes me more diligent about making sure that the code is clean and the pull request has enough context that someone playing code archeologist will be able to make sense of it, even if I'm not walking them through it in real time. I will admit that this is not a universal thing - I've worked with coworkers where no matter what process is in place, they won't do the basic courtesy of reading their own changelists to see that they accidentally committed random junk files from their local machine.

I agree that good documentation around requirements is valuable. I find pull requests / code reviews are a great opportunity to highlight how the code relates to specific requirements, since the focus is narrower.

I agree that code review is not a great medium to disseminate information about the codebase, but assigning individual ownership and accountability doesn't make the need to share information go away.

Ownership and accountability are workable as long as the same person sticks around long enough to fix all their mistakes. If that person leaves, the code becomes orphaned and it's up to one of their teammates to find out where the skeletons are buried.

I really like the idea of CodeTour, but unfortunately I'm the only person at the office that uses VS Code.

I'm hoping that some day it'll be possible for my coworkers to follow a CodeTour without installing VS Code.

Either when GitHub Codespaces reaches general availability or if I ever find the time and motivation to learn enough about github1s [1] and CodeTour to integrate the two.

1: https://github.com/conwnet/github1s

I have never experienced such an interview, both when I am the interviewer and the interviewee, and I've been thru the entire process at multiple FAANGs.

I've been through the all-day on-site interview at two FAANGs and every coding interview involved me standing at the whiteboard for the entire interview. As the saying goes, data is not the plural form of anecdote, but it's certainly common enough as a format that it has to be considered when discussing whiteboard interviews.

The entire interview has this elevated difficulty. You are constantly being judged and evaluated over the course of the interview. I have consistently asked for people to clarify why the Whiteboard part is elevated over any other technical portion in how stressful it is and how much that impacts performance, and I mostly have been attacked with strawmen.

I agree that the entire interview has elevated difficulty, but which aspects are intrinsic / essential and which parts could we remove with minimal impact to the effectiveness of the interview?

For example, we both seem to be in agreement that writing code with a pen makes the whole interview harder without facilitating what we usually want to measure - the candidate's ability to reason about complex problems and write good code to solve those problems.

From the findings in the paper, just having a proctor in the room is correlated with the candidates performing worse on the programming task (as measured by writing code that passes the test cases). I'm sure there are benefits to being able to observe the candidate directly, but those benefits should be weighed against the drawbacks and evaluated in light of whether or not it's really a net positive, regardless of whether the interview process as a whole will still be stressful in other ways.

I think I'm picking up that your model of how a typical technical interview is structured is different from what the other commenters have in mind.

It sounds to me like you view the technical interview as being split into a high-level whiteboarding phase followed by a separate coding test that is not done on the whiteboard.

In every interview I've had that involved coding and a whiteboard, I was expected to do everything on the whiteboard, from drawing diagrams and working through test cases to writing the actual code under evaluation, all in front of the interviewer.

Under this (very common) interview system, there is no "other piece" for whiteboarding to be more or less stressful than - it's embedded into the entire interview! (Yes, there are other interviews throughout the day that might only involve block diagrams or ask behavioral questions with no coding whatsoever, but I don't think that's what most people have in mind when they're told to prepare for an algorithmic whiteboard interview).

I think the interview process would be a lot better if it started with a no-coding-required whiteboard collaboration phase, followed by coding solo, and then ending with a mini code-review on the whiteboard. This is similar to the private technical interview procedure described in the paper.

As to your other question, I'm not sure why you seem so dead-set against the idea that performing analytical tasks while being evaluated in real-time would be harder than doing so under normal conditions. That's what this paper set out to investigate.

I agree that collaborating in real-time is important, but I disagree that interview conditions allow you to assess real-time collaboration abilities accurately.

In a real life situation, both you and your partner will be generally familiar with the problem at hand; if not there's an expectation that the person with more knowledge will be explaining not just the problem, but also the solutions that are already under consideration, so that everyone is on the same page.

In an interview situation, the solution is obviously withheld because the goal is to make the candidate derive it, so any back-and-forth is artificial - the interviewee is the one who has to do analysis while being scrutinized while the interviewer has already done the work.

And of course, normally your partner doesn't have control over whether you get hired or fired. If you were dropped into a room with the CTO and told that you had to solve a new-to-you problem they had already solved or you would be fired, you would probably find yourself performing much worse than if your team-mate asked you to weigh in on the problem that had been bouncing around on Slack for the past few days.

It's not as important as you would expect for a couple of reasons:

1. The size of the data is often much smaller - the savings from using an nlogn time algorithm vs a n^2 algorithm are much smaller when n=10 versus n=10000. There's a good chance that the constant time setup will dominate for those smaller datasets.

2. To a certain extent, embedded systems don't need to be as fast as possible - they just need to be "good enough" to meet their deadlines so that the rest of the system functions as expected. It'd be nice to be able to compute 1000 CRCs per millisecond instead of only 10, but if it already takes 1 millisecond to transmit the CRC over the serial bus, it's not going to make the system substantially better at its job.

So yes, there is a lot of handcrafted code, but quite often it's just implementing your standard naive brute-force algorithm with minimal code size, minimal memory overhead (preferably without dynamic allocation), and well-understood worst-case latency.