If I never subscribed I always report spam. It only takes very small percentages of recipients to do this for mailer services to start getting agitated about bounce rates.
Not quite the same, and hopefully likely to fail if it hasn't already, but it shows that interest exists in regulating 3D printers. When enough interest exists, things will happen.
Because violent criminals tend to lack wealth, knowledge, and skills. Nobody in the hood about to knock off a 7-11 has a tormach at home and the gcode for a reciever queued up.
Because people rarely go to space, and it was much more dangerous when the last person died than it is today. The vast majority of flights are unmanned, just like this test was.
If you want to continue playing apples to oranges though, nobody has died on a spaceflight in the last twenty years. How many have died on airplanes in that timeframe?
[correction: there was one additional fatal flight in 2014 with the destruction of SpaceShipTwo. I would argue that one doesn't count, though, as it was more akin to a relatively mundane aircraft accident than anything else.]
If Falcon 1 is to be thrown into the ring for consideration due to engine similarity, then we'd have to figure out where Vulcan fits. It already flew the same kind of engines that powered New Glenn.
It would help if they didn't charge $50 for a single raw PCB in low quantity when I can have the same board not just made, but also assembled in China for a fraction of that, shipping included. Literally.
I've often wondered if that's some kind of industry inertia issue, or if there's some underlying additional cost to build in the US.
People here cost a little more. No one here does quite the volume jlcpcb likely does. Perhaps there’s some artificial market factor as well like CCP tends to weigh some scales. There’s board assembly machines made in china as well likely further reducing the cost to build out assembly lines. Perhaps cheaper sources of basic materials like copper.
Likely multitudes of factors at play all of them in favor of China
I could buy that to some degree, but not to the current insane level of price disparity.
PCB production should be one of those things that is or can be mostly automated if it isn't already. Assembly is definitely already a mostly automated process. This is all existing tech. Thus the cost differential doesn't seem justifiable.
I have to think that this is very much "build it and they will come" territory if you can get within 1.5x to 3x the price, so it continues to boggle my mind that nobody has managed to make it happen.
The only blocker I can truly identify is the magnitude of the initial investment. That doesn't explain why the prices at domestic board houses seem to have remained pretty much exactly the same for the last couple of decades, though.
As far as I can tell, they just don't want the business.
The personnel that swaps part dispenser blades in the USA costs more. What's there to understand?
Automated assembly still has setup costs that take real humans walking around physically.
It's more likely that the Chinese companies are offering prototyping at a loss, because they know people won't switch to a different board house, once the prototyping phase is over.
You'd also have to ask when NULL came into common use in C (to which I do not know the answer). AFAIK NULL was not considered to be standard until C89. As far as I'm aware, all C compilers implement it as a #define in a standard header somewhere; it's not actually part of the core language itself.
I wonder who first added that macro? Was it there from the beginning?
Random developer here: in my code, yes they are common. I tend to write modules so that I can route to them from wherever, reuse them, and move them around as I please. Relative links help greatly with such things.
Besides that, they are a very basic part of the spec, and I consider anything that breaks them to be truly fundamentally broken.
Understood, but how do you deal with static asset caching and cache-busting with version markers or similar? Does your framework/build system/whatever automatically add version markers to static assets that are bundled directly with your module?
I tend to keep statics consolidated and slap middleware on those routes to handle expiration headers and whatnot. Versioning is handled where links are generated; an href="{{ linkfor(asset) }}" style resulting in generated urls complete with content hash tacked on. I almost never construct asset links without some form of link generator function because said functions give me a centralized place to handle things just like this.
(edit: I should clarify that I'm mostly working in Go these days, and all my assets are embedded in the binary as part of compilation. That does make some of this much easier to deal with. Javascript-style build mechanisms tend far too much toward "complex" for my tastes.)
OK, wait, you said earlier that you bundle static content like images in the same module as the feature itself, but now you're saying you keep them consolidated in a separate place? You also said earlier that you commonly used relative links but now you're saying you generate them with a link generator function? I'm confused about what you're actually doing...if you look at the link I posted earlier, you can see how I'm doing it. So...are you using relative links like <img src=dog.png> or not?
I was unclear; I bundle them per-module; each module has an asset route with attached middleware. So for a users module, there will be users/assets or some such route, to which various static-related middleware gets attached.
The link gens inherently accept relative paths (foo) and output relative links with appropriate adjustments (foo.png?v=abcdef), though they can generate fully-qualified links if circumstances warrant (eg I often have a global shared css file for theming, though that's all I can think of offhand other than "/" for back-home links). The module can then be mounted under /bar/blort, or wherever else, and the links remain relative to wherever they are mounted.
On occasion I do hardcode links for whatever reason; my rule of thumb is relative links for same level or deeper, or root-anchored if you're referencing a global resource outside the current path, but there aren't many of those in my apps. A rare exception might be something like an icon library, but I tend toward font-based icons.
To put the rule more succinctly, I never use "../foo". Going up and then over in the hierarchy strikes me as a recipe for bugs, but that's just instinct.
I also never use fully-qualified (including hostname) urls to reference my own assets. That's just madness, though I vaguely recall that WordPress loves to do crap like that; there's a reason I don't use it anymore. :)
So the main difference if I understood your link correctly, would be that I would have maybe one or two items in /static/assets by root-anchored urls, and the rest accessed as /path/to/module/assets/whatever (edit: or just assets/whatever from within the module).
Because I'm doing this in go, the module's assets live where the code does and gets embedded in a reasonably standard way. I actually tend to use git commit as my cache buster to avoid having to hash the content, but full hashing can be done as well very easily just by changing the generator functions.
I can then just import the module into an app and call its associated Route() function to register everything, and it just works. Admittedly it's very rare that I reuse modules between apps, but it's easily possible.
For background to my thought process, I originally started using the link gen paradigm long ago to make it easy to switch CDN's on and off or move between them, back before whole-site proxying was considered best-practice. The rest is just a desire for modularity/encapsulation of code. I like to be able to find stuff without having to spelunk, and keeping assets together with code in the source tree helps. :)
Sometimes it even works...