micksabox

GPT debating game with scoring, judging and Austin powers humour.

Looks like the tic-tac, similar to what Cmdr David Fravor saw off the coast of San Diego in 2004. The well known USS Nimitz incident.

Yes, the term now is UAP, unidentified aerial phenomenon. There is an official UAP Task Force in the Pentagon. Former Senate Majority Leader Harry Reid uses it, Hilary Clinton uses it.

This proves the multi-cloud advocates were right! If Parler used Kubernetes, they could migrate more quickly. /joke

If you don’t touch code, it doesn’t intrinsically degrade.

This is one misunderstanding of code quality which takes an absolute approach to measuring code health. Code health is relative to the changing requirements of it’s use. If you suddenly add a requirement that doesn’t fit existing design assumptions, the code hasn’t changed but the relative to the ideal has deviated...without touching the code.

The tech debt metaphor is not perfect. The pandemic has given us all a better metaphor: the code health epidemic. I’ve written about it here: https://sovilon.com/2020/05/15/atd-epidemic-prevention-respo...

I would be thrilled to hear somebody's theory of consciousness that takes into account the following axioms:

1. Consciousness demonstrates quantum non-locality. The U.S government via 3 letter agencies studied psychic phenomena like remote viewing for over 30 years under various names including Project Stargate(a). and was studied at Stanford Research Institute by scientists like Russell Targ and Hal Puthoff.

2. Consciousness affects matter. The water crystal experiments by Masaru Emoto(b) are the simplest and least fringe example. Project love, hate, anger, etc. to water results in changes to the crystal structure of water when frozen.

I tried to keep it as non-fringey and simple as possible. If you consider these, it leads to the framework that consciousness is not emergent from the physical brain but is instead a field or carrier-wave from somewhere else and brains act like antenna receivers.

References a. https://en.wikipedia.org/wiki/Stargate_Project b. https://mitte.co/2019/10/14/the-curious-study-of-water-consc...

This is incredible, I definitely believe it's possible with psychedelics. I've stuttered all my life and have accepted it as part of my life, but I think I'm going to try it. Definitely not taking an ounce at one time though!

Can I ask what did you try? I've stuttered all my life and have recently come across the potential of psychedelics.

The book Radical Markets has very innovative ideas in combating inequality using market strategies. We are deluded if we don’t acknowledge Inequality is one of the biggest challenges facing us that we have to solve.

Some commenters have asked what kind of business would deploy this kind of technique.

I’ve done it. For MLS syncing software, there are lots of properties, not thousands but can be hundreds. And each MLS RETS has its own Schema, so for any kind of logic portability this is necessary.

Actually, storing the raw data as a blob is a flexibility technique and is a separate concern than the number of fields. As I can’t predict the future set of optimized queries I’ll need, and I don’t want to constantly sync and resync (some MLS will rate limit you), then this way I can store the raw data once, and parse plus update my tables/indexes very quickly.

Can anyone TLDR; the smart contract capabilities outlined in the first paragraph?

We need more definitions. I think it's helpful to distinguish between technical debt patients and technical debt doctors. As a developer (patient), you experience the symptoms of technical debt - slow changes, dev frustration, etc. As a scientist (doctor) you observe this as a naturally occurring phenomena - with a hypotheses, measurement system and literature review. A TD doctor might be your local architect, staff or principal engineer.

There's quite a bit of published literature on technical debt, which appeared quite recently (~5 or 6 years ago). One distinction is between normal technical debt (code level), and architecture technical debt a.k.a ATD (system level) [1]. So far, whether you like the term or not as a patient, it seems useful for scientists to think collectively about the phenomena in these terms.

Some commenters in previous thread say an ideal (reference frame) doesn't exist, from which to calculate the delta of TD currently. The symptoms do exist. That extra few hours it takes to onboard a new developer, fix a bug or whatever are observable. If there exists a possibility to reduce that observable, measurable effort, then that possible future timeline should be the reference frame.

I've risked an appeal to authority in order to transfer better understanding as a random stranger on the Internet. Technical debt seems a topic too fuzzy to fully understand, and that's why I'm pointing out the way scientists are thinking about it. I don't see any other clear path we're going to get industry wide consensus or understanding, if not for the scientific method and institutional support.

That being said, the article did a good job of communicating at least 5 different ways of thinking about TD.

Disclaimer: I'm building an architectural technical debt research tool called RefactorKit.com

1.https://www.researchgate.net/profile/Terese_Besker/publicati...

Building RefactorKit.com to help with this too:

Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills.

Curiously, I'm trying to validate RefactorKit.com which will help with these "soft-skills" like: - stakeholder convincing campaigns - org collaboration signals - consensus building

I've never heard of a principal or staff engineer before. I'm up on Twitter as @refactorkit, find me there, would love to chat

https://refactorkit.com

Well said. I got swept up in the hype and my job suffered for it. This is a negative value.

But I do think in terms of vision and coordination, blockchain has extended the horizons of what can be achieved.

I’m a second generation Ecuadorian-Colombian living in Canada. I run a software development shop [1] helping startups and businesses build their software infrastructure. Would love to connect with devs in South America.

Alguien quiere conectar para desarrollar productos, servicios y aplicaciones? Mándame mensaje a michael arroba Sovilon punto com.

[1] Sovilon.com