It's not rug pulling, it's simple price anchoring. They'll degrade when it makes financial sense for them. You will pay for it. There's no way around it besides self hosting or using reality metered endpoints like openrouter.
That's exactly what happens. The algo does not judge how hurtful a rabbithole may be - it optimizes for engagement with some moderation sprinkled on top. I've tried to make my facebook feed palatable for a couple months and eventually passed up on trying. I'd rather IM my family about cat photos than engage with their fringe political views. Same goes for colleagues on LinkedIn.
Is this true? I'm getting a feeling that most of this is adding external stucture when coding agents already provide a framework for it.
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 :).
Banks like that exist. mBank from Poland does in-app approve/reject - similar to what you get on an Android phone when you try logging in on a new PC.
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'.
This is an issue with CSV numerical values stored as strings, for numbers it's a bit better. Libraries sometimes allow for a raw import that preserves the internal data type of the format, then you get proper numbers, not adjusted to locale formats.
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).
There was an AMA with Emad yesterday on discord. He got asked this. The promise is that 1.5 will be released in the following week.
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.
Or so you may think. Working with diffs / merge conflicts already exposes you to internals. Knowing that committing big binary blobs is a bad idea also could be categorized as "knowing internals". Knowing why LF/CRLF leads to conflicts (without setting .gitattributes) also is knowing git internals.
For client-side stuff like that, there is sheetjs which has support for XLSX but there are file size limitations. XLSX is a glorified zip file and to parse it you 1st have to unzip it and then build the XLSX file.
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.
I got the same message. Still, having faster builds with one additional plugin without configuration needs on projects locked on 4 or waiting out the transition is a plus in my book :).
Yes, but... chances are your backend dev will have a system-provided or just plain outdated Node version so they'll get a cryptic exception and will have to reach for assistance.
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.
Depends on what packages you use and how well they do semver. Chances are you will get major version bumps for most of your dependencies after 1-2 years of development.
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.
Caching was a major dissapointment for me. DllPlugin is a nightmare to setup and other caching plugins I tried don't really speed things up. What eventually worked for me is HardSourceWebpackPlugin [1] - two lines added and went from 2min to 15s (with a tradeoff of a slightly longer initial build).
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.