tabtab

Solution: invent practical flying cars. Musk, git on it!

I think "knackered" is the term you are looking for.

Use 1950's logic: Until it puts an eye out, it's fine.

I wanna Faraday'd House.

Many of these management techniques require a well-run shop to work well. They are not forgiving of riff raff and institutional dysfunction, and may even magnify dysfunction. So yes, they CAN work under ideal conditions, but ideal conditions are too rare, especially for non-IT domains who don't understand & value IT management.

Borrow the best fitting ideas from each methodology, but don't obsess on them.

There are probably tons of memos to public officials saying "we need funding to shore up the system", which were of course ignored.

For quick and dirty data-oriented projects, xBASE is wonderful, there's something clean and minimalistic about it. But I do prefer interpreted versions.

I find it's better to keep abstractions small and independent, so you can mix and match. Too big, and they risk not fitting future change well. Even if the smaller ones create a bit more work or "mini duplication", it's worth it to have that flexibility.

Disney in 2020: "Gambling taints our family reputation, we want a clean record."

July 2023: "Boss, we're plumb out of cash and laying off employees!"

Aug 2023: "We love sports gambling! It's very recreational! Even Mickey does it!'

2B || !2B

"shillouettes" are what politicians use ;-)

Newton, Shmooten, Epicycles worked!, they just didn't add enough layers. I'll put this next to my wonderful flat-Earth globe. https://makingmaps.net/2007/09/19/making-flat-earth-globes/

I frankly don't see many similarities to PRQL.

What are the top embedded usage chips and what is their typical niche?

Except for niches, one is not going to unseat SQL as the primary de-facto standard relational query language unless the replacement is significantly better, not just slightly. Unless a fad storm kicks in, being slightly better is rarely enough to unseat an established standard.

As far as SQL competitor candidates, my personal favorite is SMEQL. It's more composable and uses tables for many operations instead of dedicated commands and syntax, making it more uniform where a handful of idioms do all the work instead of lots of specialized stuff for each task, like what SQL does.

DOM wasn't meant for real GUI's and trying to trick it into being one seems a fool's errand. It was meant for static documents. DOM is the wrong tool for the job.

Time for a new state-ful GUI markup standard so we don't have to rely on the whacky DOM to get expected and common GUI idioms.

Maybe build the "engine" on top of the Tk or Qt kits to avoid starting from scratch.

Nobody has proven that they can predict the future reliably, and I doubt anyone can. They'd be golfing with Warren Buffett if they could. For one, predicting the future requires intimate knowledge of multiple disciplines. A space expert isn't going to understand computer chips well enough, for example.

It may have landed at a steep angle on a boulder, like Viking 1 did. Fortunately, Viking 1 still worked.

In the 1970's many thought we'd be mining asteroids by now for precious metals, making commercial missions profitable, or at least financially viable.

Some try to dress it as science, but when people find the truth, they feel mislead, and want to yank all the funding in frustration. But like I mentioned, it is "body science" and survival lessons.

The internet is crack to conspiracy nuts. They can always find new half-truth tidbits to reinforce their whackadoodle notions.

The Eagle ended up off course, but I've seen multiple reasons given. One is that they modelled the moon as perfectly round, which turned out to be incorrect, mucking up timing plans. The side facing Earth is more dense, due in part to being tidally locked I believe.

The control room was sweating when the landing deadline passed beyond the expected margin of error and they were still flying.

Lesson: always leave a margin of error, especially on the first mission. Armstrong's calmness and clear thinking under duress paid off.

Manned exploration is expensive and risky. In general the science-per-dollar is much higher for unmanned probes. I won't claim on-premises analyses can't be helpful, but the ability of bots to survey more areas usually offsets that advantage. The real benefit of manned missions is learning how to live in space for future colonies and long-distance travel. Space is not easy on the body, we'll have to figure out how to adapt if we want to spread.

How is this news? China has always been snoop-ish for industrial secrets, and "lobbies" to have its views known. This was less of a problem before it became a global super-power. Power brings scrutiny, critics, and caution.

Send the nuttiest of politicians to investigate, it keeps them distracted from important stuff.

(If they are ET, Congress will miss them anyhow.)

Ah Nostalgia. Makes me miss the simplicity of WYSIWYG tools. These "responsive" auto-format CSS/DOM driven things are turning me grey, requiring whack-a-mole tuning & debugging. Most our users are not even using mobile, such that most that complexity is WASTED. I don't know who or what it's "responsive" to, but it's not my code. Must it be convoluted? Geezer thing? I dunno. I wanna git on the WYSIWYG lawn, where is it!

But I learn about the past from National Geographic.

No methodology can make up for bad management. Co's are quick to fire regular employees, but are slow to fire bad managers (or move them to a bitter fit).

And KISS & YAGNI should apply to methodologies just as much as software systems. Don't turn simple things into rocket science just to fit some management fad.

Have "process meetings" with everyone, collect feedback and discuss areas to improve. Be an ear first, mouth second.

Addendum: I suppose we could use sp_addextendedproperty, but it's usually just easier to work with a "regular" table.

> Self-documenting code/schemas are an even better place

But they don't offer enough columns and detail for certain things in my experience. A shop-rolled data dictionary can be "shaped" like shop needs.