Was this before the introduction of the IOSS rules? I can't imagine picking something up directly at customs. International shipping volume has increased a lot, customs does not have the capacity to store much.
The new rules have actually made shipping from Aliexpress easier. VAT is displayed and payed to Aliexpress, they handle customs (as long as total order value is less than €150). In practice they consolidate packages from several sellers into one shipment where possible (although of course with a long-tail delay), and fly it to their new distribution center in Luik.
Customs has a small presence, but because VAT is paid they're mostly concerned about other things such as counterfeits.
Last-mile shipping is then done by postal service, without any additional fees.
That actually is via the postal service (BPost). The postage rates are reasonable, it's just the fee that they add for handling the customs administration that is unreasonable.
And this is more or less the same for the other shipping companies such as DHL, UPS, and FedEx.
Because the fee is per shipment, it's not that bad if you're receiving several hundred euros worth of products. But if you just want to receive a book, it can easily double the cost.
The issue isn't the import duty and VAT, the issue is the 20€ or more fee that the shipping companies charge for the privilege of handling the customs administration for you.
In Belgium for example books have 0% import duty and 6% VAT. Adding 20€, long delays, and a terrible customer experience (good luck trying to correct any data submitted to customs) to that is rarely worth the hassle.
context: "Tomorrow on @oxidecomputer and Friends, @ahl and I will be joined by our colleagues @SyntheticGate and @cliffle to talk about the role of rapid hardware prototyping in building a system -- and specifically how our ability to go quickly from ideation to hardware in hand has been essential for a surprisingly wide range of tasks at Oxide."
Displacement is 1000nm, so 3 orders of magnitude less than 1mm. As for frequency response, looks like they tested up to 1000Hz. I see no reason why it wouldn't work at any frequency from 0Hz up to 1000Hz, and even higher. But because the displacement is so small you really need the higher frequencies to be able to sense the actuation.
That's just piezo's, you need to stack several layers to get a usual displacement. You do get high force, so they're typically used for high precision positioning.
I've been looking at piezo bimorph actuators as used in braille displays. Because they're cantilevered you're trading displacement for force (and size). That could perhaps be used to create a high resolution array with enough displacement at low frequency. Not really wearable like a glove, but certainly portable.
I strongly agree, the innovation needed is in haptics on the actuator side.
Can you expand on the static and low frequency? My impression was that if you're aiming for fingertips, higher frequency has more resolution. Iirc braille is mostly sensed by the vibration of the ridges of your fingerprint, when moving your finger over the dots. For this reason single character braille displays never really took off, you need an entire row (typically 40 characters) to make a usable refreshable braille display.
It's made with "standard" multilayer pzt actuators, with a displacement of 1000nm at 60V. That's apparently above the sensing threshold, but imho not enough for practical applications.
I am curious about the fabrication methods though. The 1mm actuators are in a checkerboard pattern, and apparently reflow soldered. I'm curious how they did that while staying below the curie temperature of the actuators (typically <150°C for PZT), and if that is mechanically sufficient.
1) That "ADHD is overdiagnosed" metastudy is frequently referenced, but always for the wrong reasons:
"Overdiagnosis is defined here as occurring when a person is clinically diagnosed with a condition, but the net effect of the diagnosis is unfavorable. Misdiagnosis (when a child is incorrectly labeled with an ADHD diagnosis instead of an alternative condition) and false-positive diagnosis (when a subsequent clinical encounter reveals a wrong initial diagnosis) are not the focus of this article."
Unfavorable here is:
- medication can have side effects
- it might be used as an excuse to stop trying/caring
- there's a social stigma
2) Your second link provides no evidence of drug-seeking behaviour. It only claims that it's possibly to get a high score on an ADHD checklist with fake answers. It makes no claim that people without ADHD actually seek an ADHD diagnosis to get prescription stimulants.
Note that I'm not claiming they aren't, just that this article doesn't support that claim.
3) The third link is just an article on time with the headline that 1 in 4 adults who seek treatment are faking it. I can't find any reference to this number in the article body, nor a link to the paper.
Color me surprised: this one does actually support the claim that 22% are exaggerating symptoms.
There are of course some limitations to this study. And it makes no claim that those that are exaggerating symptoms are doing so to seek medication (again, I'm not claiming otherwise).
The good news is that there are methods to identify these patients. And given that this study is from 2010, I hope that those are in use to aid with (mis)diagnosis today.
Mitchdoogle, do you have any other evidence to support your claim of overdiagnosing and drug-seeking?
In the future, please take the time to read through the articles you link.
And please take the time to read the last paper before you reply.
The api looks very simple and easy, that's a very good sign.
We've been doing similar stuff in python, mainly in combination with Pulumi automation.
You can do some very fancy things, and I'm sure Dagger would be a nice addition to that. But honestly the thing I'm missing most is a nice UI above all that. How to present realtime and historic logs (and state) for multiple concurrent actions is still not as easy as I think it could be.
I really like the Mikado Method [0] when you find yourself shaving yak, at least when coding.
When you see something that bothers you, you've got two choices: either fix it now, or don't fix it now. Don't fix it now is easy: make a note and move on.
But if you need to fix it now: stop what you're doing and _roll back your changes_. This forces you to keep your changes small and self contained. There are other steps involved, such as writing down your steps to build a dependency graph, but the simple act of rolling back your changes is quite powerful. Don't want to throw everything away? Then maybe the thing you're trying to fix is not that urgent, and you can deal with it later.
Tangentially related: I wish there was a way to record my code changes as executable actions on the AST, and attach it as metadata to a commit. As a simple example: I want to change the signature of a method, rearrange the parameters and add a new one. All you get from source control is some text changes, without an understanding of what those changes mean. If you need to reapply those changes you're stuck with the diff tools of a text editor. But if my IDE could understand those changes, it would be trivially easy to redo the refactoring actions. It might not be automatic (what value should this new parameter have if there is no default?), but at least you have some higher level tools available for dealing with that. To take this further: the changes might not even be in your codebase. A library was updated with breaking changes? Just execute the changes you can, and prompt for action when the changes fail.
I feel that recording your changes as actions on the AST is a powerful concept that needs further exploring. Sure, some things don't make sense to record on a higher level. If I add a new method it's much more readable to just add the code as text. But for anything remote complex it would be great if I can express my intentions as executable actions instead of (or in addition to) textual changes. Find all calls to functionA where parameterX is-a typeY and parameterY.value2 is not null, and make sure the caller sends the result of functionA to functionB in a new transaction. Kind of like how you can record steps with Selenium IDE and use that to create something with clean api calls.
And the best part: because you've already made the change it's easy to test if your higher level change results in the same change in your source code.