devanl
In my mental model, the tennis ball tells you when you've backed in / pulled in the appropriate distance. I'm not seeing how it would help me back in straight / centered in my garage, or at least not until I've already backed in so far that I'd need to pull out again to try again.
I've been looking for something similar in concept for when I back into my garage from a side street with basically no driveway. It's a very narrow single-car garage. I can consistently back in well enough for myself, but if I'm not dead-on and I have passengers, passengers on one side of the car are going to have to squeeze to get out.
Essentially it can be hard to tell if I'm perfectly parallel with the garage walls and whether I'm off center, or rather if I'm within tolerance to back in even if the angle isn't perfect.
I've looked into building something like range lights [1], but I don't think the math scales down to short distances. Plus if I'm looking in the rearview mirror or my backup camera, neither of which are perfectly aligned with the direction of travel, that might mess with optical navigation aids.
I might have to dig into this moire approach to see if it would be more feasible.
Yes, obviously this is a minor inconvenience that I'm able to deal with on a regular basis, but it's fun to theorycraft.
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.
If you're handing out business cards with a HASL finish, make sure to spend extra for the lead-free version.
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.
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 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.
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...
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.
It would have to look something like:
f({ hours: 2, seconds: 53, ..Default::default() })
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.
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.
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.
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...
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.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 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.
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.
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'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.
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.
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.
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.
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.