Small note:
Having looked at geometric algebra, both rotations and translations are based on combining 2 mirror operations.
If the mirrors are parallel it's a translation, otherwise it's a rotation.
1,262 karma · joined March 6, 2013
* The ability to challenge a proposal and figure out you don't need "an xxx with yyy but just a zzz should be enough"
F.e. merging seperate repos to monorepo, simplifying development & CI/CD enormously for a tiny team.
* The ability to understand which solution matches best with your whole context (environment, capabilities, skillset, risk, ...)
Don't go for integrating a rules engine in an MVP with a tight deadline, but just setup a monthly alignment between Product owner & back-end dev.
I cannot imagine the pain you have to go through, having kids myself.
That being said, from a rational point of view, I think what you are looking for is closure.
I'm not sure if a multiple year long trial will bring you closure, but that's something you need to consider yourself.
I do know one person who lost his daughter due to a drunk driver. He took the funds, and founded an org to prevent these kind of situations and create awareness about it. He gives a lot of talks about it, and gets lots of coverage by the press.
My gut feeling tells me that - if I would ever be in a situation comparable to him - I would love to be as strong as he is. But, truth to be told, I'm not sure if I'd have enough stamina to follow through...
Sorry for your loss...
The combination of high/low level development was super productive for the intro-/demoscene.
Unfortunately, like most of these interesting blend experiments, it disappeared into the infinitely deep pits of legacy after a few years...
Anyway, thanks for taking the time to try to explain this to a total layman, but I'll defer engaging into subject matters that I never heard about before; lesson learned...
The Casimir effect is about creating a spacetime "corset" so to speak, that is so tight that even the regular quantum fluctuations don't have "enough room to pass", so they "almost freeze", and when they "come out on the other end", they could for example break or delay entanglement?
On the other hand I think your assumption about the time aspect might be correct as we are talking about spacetime after all. The biggest issue might be that measuring time deltas might be harder than space deltas?
I might have a non-educated theory that could explain negative energy; could you tell me if this is potentially correct or am I completely wrong here?
Disclaimer: I haven't read the article (it doesn't load), and I am (probably) lacking even the basics of the required knowledge.
Let's assume the law of energy conservation applies to the universe: if you assume the total energy in the universe is constant, the negative energy is a relative imbalance instead of an absolute one, caused by the universe expanding at a different speed relative to the "things" it contains.
As the universe is "expanding" constantly, the "energy amount per expanding area" gets "less dense", so the "things" that are not "expanding" at the same speed get "more dense" in comparison. This imbalance creates different types of energy perturbation. From the point of view of the things that do not expand as fast, the energy levels relative to yours seem to evolve in a "negative way".
It's like looking at a stationary train from a train that is moving: from the point of view of the moving train, the train standing still seems to go backwards.
Does this make any sense at all, or am I completely missing the mark here?
Updated: reworded some things and provided extra context.
What surprised me the most is how fake and forced the conversations and interactions looked. It reminded me of those first blue screen effects you see in these old movies from the sixties. I would assume that Facebook/metaverse spent an enormous budget on it, but nevertheless the outcome still looks creepy. In my opinion we have mostly figured out how to avoid the uncanny valley for rendering, so I'd guess improving conversations and interactions are up next. Until the techniques are on par with what we need, I'd heavily avoid trying to model a real world representation in a virtual world. (Think about the early Pixar movies: instead of trying to create the most realistic world possible, they embraced their current constraints and turned them into a feature that made their movies instantly recognizable.)
This being said, I see one big use case for AR/VR adaptation during the next decade: digital twins with simplified, tailored representations for development, marketing, education and operational purposes, as well as amusement. My best guess and personal bet is on this space.
And even though we've had VR and more recently AR getting more accessible to the consumers, it's still at least 5 years too soon for mass adaptation; most people still consider it a novelty.
In my experience interactive 3d will emerge next in the mass-market. Up until now I had the best conversion ratios by having a conventional 2d GUI/wizard and some very conceptually simple 3d drag and drop to create simplified 3d representations of products one could buy (think sheds, carports, verandas etc). First consumers will have to get familiar with 3d annotations, before we can make them interactive as well...
So yes, I see a future for (some version of) the metaverse, but the implementation they showed right now was a bit meh, because they tried to model it just like the real world, and the techniques to do so properly still aren't there yet...
Experience will help you to develop an instinct, and once you understand why everything is the way it is, you need to focus on finding an edge/making a difference/having an impact.
This takes time, experimentation, and most of all the willingness and ability to fail, while you gain deeper and new insights.
Willingness comes from personal grit and belief, but ability usually comes from your network, venture capital, a rich family, or having a successful business in the first place...
Following Taleb's ideas, I'd say that, to find your edge, it would make more sense to try something new 52 weeks in a row, instead of spending 52 weeks on a single idea.
Assume you have the grit and ability to experiment, then you still need a heuristic to determine which ideas are worth pursuing, and that's where luck comes in. Markets do not behave rationally, so reasoning can only bring you so far.
"How to be successful" formulas could be compared to the "how to draw an owl" meme [0]: you need grit, the ability to experiment, and hope that this combination will eventually put you in the perfect context at a time where everything aligns, and where you take the decision to pursue the correct opportunity...
[0] https://www.reddit.com/r/funny/comments/eccj2/how_to_draw_an...
I consider focus on code quality everywhere a form of premature optimization. Only focus on quality where it hurts... But if it hurts (f.e. you had to change it 3 times and it got messier each time), be very disciplined about refactoring to a better model: whiteboard, brainstorm etc and don't start refactoring until you found a better model.
You provided business value ASAP, and, if tech debt was ignored in the beginning, it's probably because there were good reasons to do so.
Your job is to architect a good enough system based on the requirements you have and the assumptions that you make. It might help to document these using something like ADR, but this depends on your context. I found out about a decade ago that documenting these assumptions and estimating impact/risk and potential mitigations might help to motivate your choices.
In hindsight it's always easy to tell why an existing architecture was the wrong choice, but this is a fallacy, as architecture is based on a snapshot, and you have to find a delicate balance between changing architecture and providing business value all the time.
I usually advise against big rewrites, in my own code I try to aim for "making parts easily disposable or replaceable"; if the mess is abstracted away it doesn't seem to matter in 90% of the cases. In the 10% where it does matter, you'll end up refactoring anyway because it's probably your core domain and your insights and learning are evolving faster there, and you will inflict a lot of pain on yourself if you don't respect proper development practices in those parts.
The odds that you'll find one of the second group actively contributing in online communities is rather small.
And about the ageism: yes, you can still be a very experienced developer, even when over 50 or more. I know a few specimen, and they tend to be very efficient and good in what they do, because they already made most of the mistakes one can make, and learned from it...
For me personally, I no longer feel the need to pick a fight if someone is wrong on the internet. [0]
The stackoverflow stats remind me of story from world-war 2 about survivorship bias: People checked planes that survived a dogfight for bullet holes, and assumed they should put extra armour on those spots that were hit the most, to increase the odds of survival. Luckily a guy called Abraham Wald [1] had the insight to put the armour in the spots with the least bullet holes, as the planes that came back obviously survived because they were not hit in certain spots.
I built a company around this [0], but it's not open source, and I haven't exposed the dev platform to the public yet, and might only expose it to licensed partners.
It is a platform to create online 3d configurators for consumers and sales, driven by scripted templates that generate 3d components according to some configuration... Currently I'm leveraging webpack hot reloading, but an online IDE is on the roadmap for next year.
There are a lot of caveats in designing such a system, especially if you want to keep the performance top notch on mobile, and you want to have a modern dev experience.
The biggest value however is in the 3d components itself: simple components that compose well and allow you to build basically anything in a few days if you know what you need...
If I'd need to build it from scratch now (almost a decade later), I could probably build a cleaner, better performing platform in a couple of months in deep crunch mode.
However, if you have never done this before, it might take quite a few mistakes and a lot of refactoring before you get it right. (During the first 2 years I rebuilt the core 5 times because I had yet another use case that didn't fit in the models customers were asking for.)
If you are serious and have lots of houses to design, I might be able to help.
TBH the current website and the configurators on it are old and need some love, but if you want to see a good example of a client leveraging this tool, check this link [1], and click on 3d design.
Upfront: it's not cheap.
We're moving up on the abstraction ladder, and as hacker news has always had an early adopter audience, focus is shifting here first.
Assuming these trends are highly correlated with the Kondratieff cycle, I expect a new trend to emerge about a decade from now. My best bet is focus will shift deep into the implementation again, but now in another context (Maybe on edge devices, data/code floating in the void, more decentralized, ...).
I've put my money where my mouth is, and my personal bet is on interactive 3D, as 3D capable devices are becoming more of a commodity and the current generation of youth (future buyers) will be a very technically literate audience that has grown up playing games and being connected 24/7.
Maybe I should send myself a reminder about this post in 10 years from now; curious to see what will have emerged by then on this site...
Another good example is playing the piano by ear: if you look at YouTube tutorials, they kind of make sense, but if you try to apply those techniques in real life, you tend to fail miserably the first time you try it. I've been playing a bit on the piano everyday, and am now at a point where I can figure out the chords for easy songs in a couple of minutes. There was one video in particular that helped me big-time more recently, but if I had seen the video a month ago, I doubt that it would have been as helpful as it was recently. There might also be lingering some knowledge in my head from videos I watched previously but didn't grasp at the time, so I'll never know for sure.
These kind of skills are all about repetition and growing an intuition for the basics, so you can start thinking at a higher abstraction level...
(for the record: I'm at "campfire level skill": I might take another few decades before you can call me a good player, but it's good enough for having fun and the occasional gig with friends among friends a couple of times a year...)
[0] https://www.slideshare.net/TomJanssens1/selling-ddd
[1] https://twitter.com/huizendveld/status/1440683623628230665
This example clarifies the intent behind DDD: make the implicit explicit and make sure there is awareness about all the edge cases.
It might be as simple as contacting a user in case you have an uncovered edge case, but at least you'd be aware that your system is unable to handle edge case X. (In non-DDD scenarios this would just be a bug that emerges - implicit behavior.)
If your business is talking about updating/deleting/inserting data, you are not describing the actual reasoning behind the change. For DDD, it makes sense to figure out why exactly you are doing the things you do, and model these explicitly in your systems for those parts that matter.
The stereo-typical example for this is an address change: if you model this as an "AddressUpdated", you might as well use CRUD, as this does not specify the intent of the change.
You could change an address because it contained a typo, but you can also change it because someone moved. These might lead to different outcomes, so in DDD you would typically model these as "AddressTypoCorrected" and "ContactMoved".
There are other fine-grained aspects, for example the need of an identity for an object: physical money is considered a value object (so it has no specific ID per instance) in almost all contexts, unless you are the national bank: all of a sudden the identity (serial number of the bill) does matter, so the same "thing" might have different "models" within different parts of the business.
Other examples might be value objects for specific areas, for example weight. Typically weight starts out as a number, and all of a sudden there might be a need to add a precision, mark it as an estimate, or have it "unknown". In order to avoid if-statements all over the code, you construct a "weight value object" that properly manages all of these peculiarities in a single place (i.e. what's the result of an estimate+undefined etc.)
Your story sounds like they implemented a "technical DDD top-level architecture" (TM), whatever that may be. (I'd assume layers of abstractions coupled with logic spread all over the place, without any added benefit.)
You see this a lot when people read some stuff about DDD, and they start experimenting with the technical/tactical patterns, because this is the aspect that makes most sense to a technical audience.
In reality the tactical/technical DDD patterns should only be applied in the core part of your business (i.e. the thing that gives you a strategic advantage over your competitors.), because that typically needs to change a lot, so having a common language/model with the business tends to be worth the extra upkeep required when opting for more flexible models.
Identifying what the core part is of your business (most likely it's not authentication, billing, invoicing, content management, ...) is one of the more important (and most difficult) aspects of DDD.
* The essence of DDD: make the implicit explicit (language, boundaries, code) and evolve your model so it matches the domain *
But to be honest, in hindsight I think it was nothing more than a drip in the ocean, and does not clarify a lot, unless you are already well versed in DDD; it's like those explanations about monads...
As for the CQRS-as-a-top-level architecture:
There are a lot of "beginner experts" and self-proclaimed thought leaders emerging, as DDD is getting more popular... (~= Agile movement)
CQRS-all-the-things is typically a phase that you go through if you are studying DDD. (I've been there, done that, got the T-shirt.)
In my personal opinion a good heuristic to detect "beginner experts" is that they prefer to use a lot of DDD lingo, and focus on the more technical aspects instead of truly trying to understand the business domain first.
Update:
Added the first paragraph with an attempt for a DDD definition.
Mathias is one of the original instigators of the European DDD community: he spent the last decade giving talks all over Europe about DDD and organizing one of the largest DDD conferences in the world: DDD Europe [0].
Next to this he also has a consulting org (recently rebranded to Aardling [1]), and spends a lot of time with DDD gurus like Eric Evans (the "inventor" of DDD, author of the DDD blue book), Alberto Brandolini ("inventor" of event storming), Nick Tune, Paul Rayner, Yves Reynhout, Cyrille Martraire, Romeu Moura, Marco Heimeshoff, ...
As far as I'm concerned, he's the real deal, and has skin in the game. Highly recommended!
After that, I tend to make a distinction between inherent complexity and accidental complexity.
If it has inherent complexity, I tend to spend extra time at the whiteboard to make sure I have the best possible model based on the info I have at that point in time, and I also refactor relentlessly.
For everything else, I try to make the code easy to throw away and replace. Typically things start out simple and grow more complex after a while. Trying to retrofit a proper model usually costs more effort than a rewrite.
For me, spending over a decade deep in the domain-driven design (DDD) community has proven to be the best investment I ever made in that area. However, as DDD is getting more popular, I noticed the emergence of echo chambers and some "beginner expert" thought leaders who are starting to teach before truly understanding DDD, and others relentlessly productizing and pushing their offerings, so make sure you only engage with experts who really care. (A good heuristic to detect a beginner expert tends to be someone who uses too much DDD lingo, but YMMV)
Big orgs always invited me in Michelin star restaurants. Smaller orgs usually invited me to emerging restaurants or well known local places.
If you mostly care about discovering the second kind, I would strongly suggest you to ignore the stars and take a look at Michelin's "bib gourmand rating" [0]: these are restaurants where you don't have as much protocol, food is reasonably priced, and typically places I would go to when I could choose myself...
[0] https://guide.michelin.com/nl/nl/restaurants/bib-gourmand
In the end, trading is betting on arbitrage, and I don't see why an energy producer would stop leveraging this "free money".
A simple example: if there was good weather expected in another country, the org would set up a contract to buy the energy surplus in that country at a cheaper price. Whether or not or bio-gas & coal plants were running or not was mostly based on how much energy we needed after taking into account what happened on the trading floor, the price of our fuel and how much the other country would be charging. Of course, the other country could decide we didn't offer a good price and decide to tone down it's amount of energy it produced.
I recall a lot of market making on the CO2 emission rights for example, but that's another story.
This is a simple scenario, in real life it was way more complex. (Just think about planning something like the delivery of coal at a plant.)
The calculations for plant scheduling took a gazillion of parameters into account (CO2 emission rights, pricings of different kinds of fuel, weather predictions, ...)
These markets not only trade energy, but also fuel, logistics, CO2 emissions, ... (using direct quantities, options, leveraged products, things like insurance, ... If you could imagine it, there was probably someone trading it.)
If you are into this stuff: I built the prototype that validated their portfolio position with the other suppliers; it was a protocol called EPM (Electronic position matching), developed by the EFET (European Federation of Energy Traders). I am not sure how it evolved, as this was the first iteration of the protocol...