Seconding the Book of the New Sun - It's great as a standalone, and the series is rewarding if you keep reading. It's an excellent 'puzzle' of a story as OP stated.
No idea, but "amplification", "electromagnetic fields", "rotating bodies", and "published in Nature" are the keywords that get all the UAP podcasters drooling.
Get ready for an onslaught of "Physics behind flying saucers LEAKED" clickbait coming to a feed near you. Whether any of it is actually applicable doesn't matter, the clicks must flow.
• To know what keywords get UAP podcasters drooling, you must have watched your fair share of UAP podcasts.
• Your comment is the only one so far to make the association between the article's keywords & UAP, implying that you are yourself making the same association that someone interested in watching UAP podcasts would be making, in which case..:
• ...what is the difference between you and the would-be viewer of the next UAP podcast you are warning away?
Another confirmation. I see it in my /r/all list fairly frequently. I am neither subscribed, a reader of said posts, or a believer in any of that (or at least, i avoid belief until it feels there is reasonable supporting evidence).
Though i don't recognize all of the terminology of OP, so perhaps that disqualifies my observation.
Besides reddit front page, this stuff also appears in enough other pop culture podcasts and the occasional NYT expose that it's out there in the popular zeitgeist. Unfortunately, here it's just my science immune system flaring up on a random internet board.
Also, between the "could this be used for vehicles" parent comment and that downvoted interdimensional energy transfer comment below, it doesn't take a Aliens-Did-the-Pyramids Guy to see what dots were starting to be connected... I might as well be the one to flag it explicitly and earn some imaginary internet points.
But who knows, maybe I'm actually the goberment disinformation agent trying to keep all this under wraps...
I have no exposure to UAP media but the first thing that came into my head was, “like some oddball theory of how a classic ufo works from the 70’s.” That and the send $5 for paper on the secrets of antigravity ad from the back of Popular Science magazine back then.
“The fastest rotation achievable by standard motors is of the order of 10 kHz and a record of 667 kHz is reported for a millimetre-sized magnetically levitated sphere.”
From the spinning metal cylinder you can extract EM energy. It’s like a flywheel. The trick is how do you bring up the spin in the first place. The indication here is I guess that you can amplify the spin with EM waves.
“…depending on its rotation speed Ω compared to the field oscillation frequency ω, it can either absorb or amplify.”
Is there a way to get to get the molecular propeller effect and thereby molecular locomotion, with molecules that contain sugar and a rotating field or a rotating molecule within a field?
Perhaps in reverse (which should be equivalent, since Maxwells laws are time reversible).. rather than having waves amplified by stealing energy from the cylinder, waves could amplify the rotation of the cylinder.
At first glance, the concept appears to serve as the basis for a 'portable' magnetic field generator, which could be installed on an interplanetary spacecraft.
Anybody have any opinions on moving away from Redis for cables/caching/jobs?
I supposed it'd be nice to have one less thing to manage, but I'm wondering if there are any obvious gotchas to moving these features over to sqlite and postgresql.
For caching specifically solid_cache works better for long lived and larger caches than does Redis. If you need short lived and smaller caches Redis will be more performant for you.
That said you can probably get away with caching way more with solid_cache and it's highly dependent on what your use cases are.
Also a thing to note that your DB backing solid_cache might also be using RAM efficiently, giving you a lot of benefits that Redis did.
For new projects I'll be using solid_cache first and adding Redis only on an as-need basis. The cost of Redis is orders of magnitude higher than a DB backed cache.
DHH mentioned 10TB of cache and only 0.5ms increase in latency difference between Redis and SQLite. I wish other could test it out and have some other figures to point to. But if the stated case were true then I think sacrifice 0.5ms for 10 to 20x more cached resources sounds like a very good deal to me.
I had a bad experience with Action Cable + Redis (extremely high memory overhead, tons of dead redis connections), so it's a bit "fool me once" with regard to action cables.
The main argument for caching in the DB (the slight increase in latency going from in-memory->DB-in-memroy is more than countered by the DB's cheapness of cache space allowing you to have tons more cache) is one of those brilliant ideas that I would like to try at some point.
Solid job - i just am 100% happy with Sidekiq at this point, I don't understand why I'd switch and introduce potential instability/issues.
I have used both with rails. (Cable is still going through Redis tho).
Solid cache is perfect for my use case since page caches doesn't change as often, so taking a smaller memory footprint on the server farm is a win.
My take is to measure your cache hit percentage. This will allow anyone to understand their cache eviction rates. If you have high eviction rates maybe using a btree is not the way to go and redis is probably better
I havent used them, and we are not moving to them on our existing app but I can super-appreciate the fact that by default redis is more of a down-the-road decision now. No reason to get into the complexity (+ additional hosting cost) of adding another service into the mix until you choose to later on.
On Rails homepage, it says from “Hello World” to IPO. The idea is that Rails should help you maintain a lean stack by default. You can stick with Postgres for pretty much everything: caching, background jobs, search, WebSockets, you name it.
But, as your app grows, you can swap things out. Redis or Elasticsearch are solid choices if you need them. DHH mentioned that as well, at scale, everyone does things differently anyway. But you do have the option to keep it simple, by default.
For me personally, Rails 8 is great. My new project only need Postgres and that's it. I don't need Redis, multiple gems for background jobs or cache anymore. Able to avoid the chaotic JS ecosystem for frontend. Hopefully it will be easy to setup Hotwire Native too. It really streamlined things, and letting me focus on building features instead.
That said, for my production apps in existing companies, I’m sticking with what’s already working: Sidekiq, Redis, Elasticsearch. If it ain’t broke, why fix it? Will probably revisit this decision again in the future. Too early to tell for now.
Regarding Hotwire Native: I tried Strada a few months ago, but I never got it to work. Hotwire Native was running within 10 minutes on each platform. The docs are miles ahead of the Strada docs imo.
Totally makes sense not to jump in early to make sure kinks are worked out, but it is worth noting that Solid Cache was code extracted from BaseCamp and HEY, so it has seen production at scale for a while now.
"Regarding cognition, both groups improved in attention and spatial memory, but no significant group differences emerged."
So, the dance group showed increase volume of brain matter. Is there a benefit to having the extra brain volume, even if it doesn't lead to improved cognition?
Is it possible that increased volume just helped them become better dancers?
Musical cognition is loosely connected to attention (maybe disconnected entirely by this metric, music seems special) and spatial memory is irrelevant. So "better dancers" seems a bit myopic, they might be improving their understanding of rhythm and melody in a more general sense.
(IMO the headline-level conclusion of this study is unsurprising - dancing is far more cognitively demanding than gym exercise!)
Cognition and memory are easily measurable brain functions but are not the exclusive function of the brain. As a conserving machine a healthy brain building volume is indicative of improvement in some function otherwise it wouldn’t bother building the volume.
I got into dance a few years ago, and N=1 sure, but the big changes I observed as a result were improvements in proprioception, balance, sense of tempo, and I also gained the ability to deconstruct music in my head, and listen to different parts of it (e.g. only pay attention to the guitar or the drums or the vocals).
Like does this make me better at programming? Probably not. But the skills you gain do have other usages outside of dance, and honestly also kind of enrich life in general.
I ran into some scaling challenges with Postgres a few years ago and had to dive into the docs.
While I was mostly living out of the "High Availability, Load Balancing, and Replication" chapter, I couldn't help but poke around and found the docs to be excellent in general. Highly recommend checking them out.
They are excellent! Another great example is the Django project, which I always point to for how to write and structure great technical documentation. Working with Django/Postgres is such a nice combo and the standards of documentation and community are a huge part of that.
Interestingly I have had almost the exact opposite experience being very frustrated with the Django docs.
To be fair, it could be because I'm frustrated with Django's design decisions having come from Rails.
When learning Django a few years ago, I still carry a deep loathing against polymorphism (generic relations[0]), and model validations (full clean[1]),
generic relations are hard to get right, really if you can avoid using them you're going to avoid a lot of trickiness.
When you need them... it's nice to have them "just there", implemented correctly (at least as correctly as they can be in an entirely generic way).
Model validations is a whole thing... I think that Django offering a built-in auto-generated admin leads to a whole slew of differing decisions that end up coming back to be really tricky to handle.
- Model validations aren't run automatically. Need to call full_clean manually.
- EXCEPT when you're in a form! Forms have their own clean, which IS run automatically because is_valid() is run.
- This also happens to run the model's full_clean.
- DRF has its own version of create which is separate and also does not run full_clean.
- Validation errors in DRF's Serializers are a separate class of errors from model validations and thus model Val Errors are not handled automatically.
- Can't monkey patch models.Model.save to run full_clean automatically for because it breaks some models like User AND now it would run twice for Forms+Model[0].
Because of some very old web-forum style design decisions, model validations aren't unified thus the fragmentation makes you need to know whether you're calling .save()/.create() manually, are in a form, or in DRF. And it's been requested to change this behavior but it breaks backwards compat[0].
It's frustrating because in Rails this is a solved problem. Model validations ALWAYS run (and only once) because... I'm validating the model. Model validations == data validations which means it should be true for all areas regardless of caller, except in exceptions, then I should be required to be explicit when skipping (i.e. Rails) where as in Django I need to be explicit in running it - sometimes... depends where I am.
Thanks for your reply. I'm currently in a stage of falling out of love with Django and trying to get my thoughts together on why that is.
I think Django seems confused on the issue of clean/validation. On the one hand, it could say the "model" is just a database table and any validation should live in the business logic of your application. This would be a standard way of architecting a system where the persistence layer is in some peripheral part that isn't tied to the business logic. It's also how things like SQLAlchemy ORM are meant to be used. On the other hand, it could try to magically handle the translation of real business objects (with validation) to database tables.
It tries to do both, with bad results IMO. It sucks to use it on the periphery like SQLAlchemy, it's just not designed for that at all. So everyone builds "fat" models that try to be simultaneously business objects plus database tables. This just doesn't work for many reasons. It very quickly falls apart due to the object relational mismatch. I don't know how Rails works, but I can't imagine this ever working right. The only way is to do validation in the business layer of the application. Doing it in the views, like rest framework or form cleans is even worse.
Yeah definitely understand the frustration. I've been there and while I don't think we've found _the_ solution, we've settled into a flow that we're generally happy with.
For us we separate validations in two. Business and Data validations, which are generally defined as:
- Business: The Invoice in Country X is needs to ensure Y and Z taxes are applied at Billing T+3 days otherwise throw an error.
- Data Validation: The company's currency must match the country it operates in.
Business validations and logic always go inside services where as data validations are on the model. Data validations apply to 100% of all inserts. Once there's an IF statement segmenting a group it becomes business validation.
I could see an argument as to why the above is bad because sometimes it's a qualitative decision. Once in a while the lines get blurry, a data validation becomes _slightly_ too complex and an arguement ensues as to whether it's data vs business logic.
Our team really adheres to services and not fat models, sorry DHH.
To me, it's all so controversial whatever you pick will work out just fine - just stick to it and don't get lazy about it.
Services are definitely better and a solid part of a domain-driven design. The trouble is with Django I think it's a bandaid on a fundamentally broken architecture. The models end up anaemic because they're trying to be two things at once. It's super common to see things like services directly mutating model attributes and set up relationships manually by creating foreign keys etc. All of that should be hidden far away from services.
The ultimate I think is Domain-Driven Design (or Clean Architecture). This gives you a true core domain model that isn't constrained by frameworks etc. It's as powerful as it can be in whatever language you use (which in the case of Python is very powerful indeed). Some people have tried to get it to work with Django but it fights against you. It's probably more up front work as you won't get things like Django admin, but unless you really, truly are doing CRUD, then admin shouldn't be considered a good thing (it's like doing updates directly on the database, undermining any semblance of business rules).
It was over three days (dinner, dinner, lunch), and I was splitting them with friends. Although, I do love dessert and probably could have eaten those all solo.
Let's say an (extremely) successful businessman wants to create a new business that requires a 250m investment to launch. Wouldn't this prevent that individual from starting the business?
If they can't secure loans for it, I suppose it would. Do I think the loss of the ability of extremely successful businessperson to independently launch a business that needs $250m up-front is a huge loss to society? No.
So in this case we would be eliminating the power of the individual to undertake large, risky undertakings that would provide a net benefit to society.
Now you'd have to cobble together a group of investors, but if you can't find people who don't understand your vision, you're out of luck.
Or you could go to a bank, so now the banks have more power, but they probably won't invest in your risky idea anyway.
Okay so I guess, now it's up to the government to undertake this large risky project? Great.
I don't know, I like the fact that motivated individuals can take a large amount of their own capital and take on large projects.
That one or two motivated billionaires start interesting businesses every once in a while is justification for an economic system hundreds of thousands die because of the resulting poverty?
2016 Study: A study published in the Journal of the American Medical Association (JAMA) estimated that approximately 133,000 deaths in the US annually are attributable to poverty.
2019 Study: A report by the National Academies of Sciences, Engineering, and Medicine suggested that around 300,000 deaths could be linked to social factors like poverty and lack of access to healthcare.
2020 Report: The Kaiser Family Foundation estimated that roughly 136,000 deaths in 2018 were associated with poverty-related factors like lack of access to healthcare and healthy food.
Your "please think of the rich guys" argument holds no sway with me.
On balance, I like Rails because you get so much functionality out of the box.
My biggest concern is that when your project deviates from the happy path of that functionality you've got to invent your own architecture and patterns. Knowing when to create a service objects vs say adding more functionality to a model is an example. In that case, you're out of the land of convention and into the land of opinion.
