m3mnoch

indeed.

tho, the important piece is the network. the network doesn't know or care if random people have a locally downloaded copy of the art. all sites, services, validations, virtual worlds, whatever on the network will hit the ethereum contract which gives up an address which you've proved you own by key signature.

the network can't see nor does it care about your local files.

which means, basically, any other appearance of the art in any other place is just an ad for the current owner of the nft.

it sounds like a lot of the negativity revolves around devops. that's understandable. it's part of a pendulum that swings back and forth. devops and docker as topics aren't really mutually inclusive.

docker, however, is more about the abstraction of complexity stemming from the industry's overall drive toward scalable, distributed applications and development teams. it's more analogous a developer saying, "why do we even use virtual machines?!? bare metal is way faster!"

personally, i always side with greed/effort on this one.

"wait -- we don't have to pay to keep/store/rotate/maintain logfiles? and that's a value proposition? yes! pipe them badboys to dev null!"

we do this at my (very large) company. it's awesome.

the best thing about it? engineers who aren't good at the strategic, human high-touch, or political issues, but excel at execution and implementation aren't managing teams of people -- they're busy executing and getting paid (and further promotions) based on their ability to execute, not on their ability to manage herds of programmers.

as a software engineer, i love that my boss is my boss because he's good at managing teams of software engineers. not because he's the best software engineer in the house.

this article seems to confuse speed reading with skimming.

i took a full semester class back in high school where all we did was train speed reading. i was able to get to 800 wpm with 90% comprehension on tests. that was from a baseline start of ~150 wpm with 80% comprehension. (the tests afterwards weren't easy "what was the name of bob's dog?" questions)

i've, of course, lost it all in the past 25 years of no practice, but i remember the keys being swallowing entire lines instead of words, achieving "flow", and dropping the subvocalization of what you're reading. (when you pronounce words in your head)

we've had an echo for about a year now and we love it.

by 'we', mean my busy family of four. it acts as everything from shopping lists to homework timers to streaming pandora/spotify to telling jokes -- and more. we easily talk to her (she is basically part of the family) a dozen times a day.

i can totally see how someone who doesn't have all this commotion and such would think it useless. for us tho, it's not useless. it's both fun and functional.

i suspect it's more about lua being a really nice, embeddable scripting language. there's a reason game companies all* use it for content developer scripting languages.

language preferences aside, sometimes it's all about the right tool for the job.

* not literally _all_ of them, but lots and lots and lots.

dude! you should update that page! i actually understood what you said!

/shrug

i guess.

i mean, what's the layman's description of a rabi cycle? anyone? if someone can lay on me a description my very smart, but non-techy wife would understand, i'll be happy to update the wikipedia entry.

seems like all you have to do is explain quantum physics to a layman first. then (apparently) how a two-state quantum system interacts with an oscillatory driving field and what that has to do with that original layman's explanation of quantum physics.

piece of cake.

while this process feels like it's hitting the sweet spot for finding out who can write brilliant code, that's half or less of the battle in hiring people. personally (and as a hiring manager), i feel like a majority of the hiring process is dependent (obviously) on the environment you're hiring into.

hiring for that small startup? you'll want multi-hat wearing people first, brilliant programmers second.

hiring for a large enterprise team? you'll want to hire for "plays well with others" first, and brilliant programmers second.

that's not to say you should hire schleps, for sure. they should at least be competent programmers. i guess what i'm saying is (despite how it sounds), hiring someone who can program brilliantly is important, but not as important as hiring someone who can navigate your company's software-making requirements successfully.

firing the brilliant engineer who thinks he's more talented than everyone else in the small company so he keeps demanding to be put in charge? yup, that's a thing. firing the brilliant engineer who fights tooth-and-nail over some inconsequential feature the product team wants to change? that's a thing too. assigning a brilliant engineer to crap, meaningless work because no one else on the team wants to work with them? yuppers -- seen it.

in any organization, you are either the only one in charge or you're following someone else's orders -- both of which require different aspects around working well with others.