zamber
Tentacrul did a good video on it and more across the years https://m.youtube.com/watch?v=MPyJBJTHyO0&pp=ygUWZmFjZWJvb2s...
It's not a question of what you can do, but where the comfort level reduction outweighs the project importance/pay.
I've had moderate success in throwing a braindump at the llm, asking it to do a .md with a plan and then going with the implementation for it. Specialized thinking prompts seem like overkill (or dumbo-level coding skills are enough for me).
Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/html". Strict MIME type checking is enforced for module scripts per HTML spec.
Ad infinitum for a list of a couple .js files with repeating names.
Guess we'll have to come back in a day or two to experience it in it's full glory :).
They also send phishing warnings when they find active campaigns.
That said, plain old social engineering works well on people. Last week one small-scale influencer fell victim to a bank transfer scam. Got phoned by a bank person telling her that her account is targeted by hackers, then a cybersec police head phoned her and asked to transfer her savings to a 'secure account'.
If you do it for excel it even handles dates pretty well because they're in a numerical format and you can infer that a column is filled with dates because of the range.
The pre-internet conclusion is right. They try to keep backwards compatibility. Also, Excel doesn't handle big data well (1-2M rows) and neither do import libraries (at least in JS land).
The slowdown has numerous issues. They got legal threats, death threats, and threats from some congresswoman to have them banned by the NSA (1).
Stability.ai workers (except for one) have a clause that they can open-source anything they're working on. They do and supposedly will open-source everything because they want to do a ecosystem, not a cash grab in the model of DALL-E.
Also they don't have one central place for all their projects and will scale from 100 to 250 employees in the following year so things should speed up.
1) https://eshoo.house.gov/media/press-releases/eshoo-urges-nsa...
I found that it starts to hang on XLSX files ~50MB because the spreadsheet model it produces get's a bit too big and sheetjs dies. Doing this in a web worker is a good idea because otherwise it will clog the main thread.
For CSV the story is different, because you can read a plain text file in chunks (even in JS) with FileReader and readAsArrayBuffer(file.slice(byteOffset, byteOffset + chunkSize, file.type)).
The actual noise levels may have been higher. Regardless, I think the main reason is ventilation. With coal and wood heating streets were designed to act as valleys pushing air through. Also, I hard that old European cities were built with airflow in mind. Whole streets were uninterrupted with trees while some have them.
Also I heard an opinion that Wrocław is one of the most polluted cities because it got a lot of new buildings that break the airflow on main streets.
Ideally you would have a pipeline building the project on each branch commit so that the backend dev can push, wait 5 min, fetch the artifacts for that branch and run it locally to test it. Or even better - if there's a pipeline chances are there's a Dockerfile doing the build but it will not support live-reload.
Either ways it gets complex as soon as you have to get out of your comfort zone. Especially if the docs are outdated/verbose/non-existent.
What works well then is to do upgrades partially. Each major library separately, fix issues, go with the next one. Otherwise it's hard(er) to track what breaks your app.
My current project has 100 dependencies and 150 devDependencies. Upgrading takes a week if not longer for one experienced dev. We tend to do it every 3-4 months.
[1] - https://github.com/mzgoddard/hard-source-webpack-plugin
Note that it does not mention promises and async/await but it does include it. Promises are essentially syntactic sugar for a setTimeout calling success and failure methods. This also means that promise code will be executed in parallel but on one thread and one heap, so each promise will fight with all other for priority. This is generally fine for async stuff like fetching resources but it would completely destroy performance if it would do anything heavy, like, say unzipping zips with jszip.
Historically the event-driven model of JS enabled Node.js's API to be callback-driven. This lead to what is called "callback hell" and eventually to a proper introduction of promises and async/await to the language.
I wonder how much value there is to this particular use case because it lives somewhere between devtools and an online IDE. Also arguably testing out a library in a codepen is more comfortable than an inline which you potentially can't save.
F12 or Ctrl+Shift+i and Ctrl+c Ctrl+v and you're executing code in the context of the post ;).
It's not a notebook but does the job well enough.
For node.appendChild you have the whole virtual DOM thing leveraged by modern JS frameworks. If you hit issues try using any framework that boasts having a virtual DOM.
The same strategy could be done for the console to some extent.
The built-in console object is over-writable so you can add a layer that would batch console calls (if you do many in a short time). Note that this will break the call address you have on the right-hand side. Also IE11 does strange things with the console object depending if devtools are open or not.
The solution above is doable but it's a hack. If you really have to call console a lot of times in a short time adding a custom log method would be better.
globalThis.__debugLog = [];
globalThis.__printLog = () => globalThis.__debugLog.forEach(i => console.log(i));
const log = (...args) => globalThis.__debugLog.push(args);
// then in code:
log(whatever);
// and once you want to check it, call printLog in the console
__printLog();
For canvas setTimeout on requestAnimationFrame seems to do the trick https://stackoverflow.com/questions/19516307/limiting-framer... I don't to much with canvas besides using it indirectly with libraries.
There is small learning curve for getting to know rpm-ostree and toolbox tends to be a hindrance if you want IDE integration. Also you have to reboot after installing packages to the core OS, that's mainly why they recommend using flatpaks, but it's optional.
Note that it's still beta but pretty reliable as you can always downgrade and wait till they fix stuff that may be broken after an upgrade.
When it comes to actual setup needed it's not much different than a regular distro. No language to learn, no additional setup required.
Initially I played around with toolbox, wrote a 30 line bash script for initial setup for it and eventually ditched using it.
You can still use RPM Fusion and install regular .rpm's.
One thing to note is that they recommend to use the default partition layout as custom ones can (and do) break.
I would agree that it's connected to masculine cultural tropes. The toxic behavior stemming from it is IMO is a derivate of the mental mess it fuels.