My experiences were very similar to the author’s when I first started using it. Even though my test coverage was near 100%, the mutations introduced revealed that in large part my tests were fallible due to assumptions I’d made when writing them.
I’ve incorporated mutation testing as the final step in my CI workflow as a test for my tests. It’s a fair bit of work the first time it’s run (especially with larger libraries), but in my opinion vital as a pairing with tests.
I'm not sure why there is a database at all, if you want messages to just appear and not stick around you could do this over websockets and never need to touch a database
I'm brand new to full stack so I have no idea what I'm doing. Kind of figuring it out as I go along. Decided to start with short polling since I was having trouble getting websockets working and just wanted to get a v1.0 out in the wild.
Switching over to websockets eventually is 100% on my mind, but I have a near infinite amount of work to do on all fronts so we'll see when I have time!
Good on you. Learning about DB structure is far more important than websockets when starting out full-stack. You’d need to run your own websocket server anyway or pay through the nose for a service like Pusher (or stay on the free tier and not learn a single thing about either).
I agree absolutely - just want to add that learning when not to use a db, which db to use when you need one, and which network protocols to use for an application, is also important
Not sure what your backend is, but websockets are pretty straightforward with socket.io! Happy to help get you up to speed - don't hesitate to reach out (@maxverse on twitter, email in profile)
Great job figuring things out as you go, and I love the experience. Keep up the good work!
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.ventspace.life/api/v1/ventpost. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
The API returns at most 2000 messages at a time (this might have changed since I last tried), and last I looked the message IDs were around 130K, meaning that's how messages there have been.
over the last ~20hrs, the most common words and their frequencies are "the": 12263, "i": 12212, "fuck": 9015, "you": 8940. with stopwords removed, these become "fuck": 9015, "guess": 4084, "nums": 4062, "cunny": 3728. out of interest "maddie": 857, "covid": 231
Oooof I was assuming it was a different Maddie. But yes that's the most famous Maddie in the UK. Might be a coincidence though. It feels like it was over ten years the Maddie you're thinking of disappeared while on holiday
(Edit: looked it up) Maddie McCann disappeared in may 2007
I found something like this when managed to accidentally break the Drupal.org git parser by adding emojis to a commit message. It wasn't on purpose, I was just on a 2015 emoji kick.
That said, it did uncover a bug that obviously hadn't been tested for which gave the infra team more impetus to solve utf8mb4 support for the database.
It's very important to watch out for useless uses of echo/cat. What is cat, a few megabytes now? Fine for those of us on modern hardware, but you never know what PDP-11 user is going to copy paste your comment into their terminal.
It's relevant information if you're converting to mass, which was probably the intention. Google will return the correct result for "mass 1 cup flour", by comparison.
There is no correct way to turn "1 cup flour" into a mass. For one thing, you can fit more into the same volume by compressing. But more importantly, the material is ambiguous. There are many different kinds of flour with varying physical properties.
Wouldn't the signal have to do a full round trip within the timeout of 3 ms, meaning it could not go beyond 580 / 2 = 290 miles?
Additionally, the connection from A to B is usually not a straight line, and at that time fiber lines were much less widespread. All these factors combines make it unlikely that even 200 miles could be reached...
> Well, to start with, it can't be three milliseconds, because that would only be for the outgoing packet to arrive at its destination. You have to get a response, too, before the timeout will be aborted. Shouldn't it be six milliseconds?
> Of course. This is one of the details I skipped in the story. It seemed irrelevant, and boring, so I left it out.
> That three millisecond time doesn't make sense as the timeout for a connect() call.
> Yes, I know. And it wasn't the timeout, actually. In the story, I make it sound like it took all of ten minutes from being made aware of the 500-mile email limit and determining a 3 ms light-speed issue. In fact, this took several hours, and quite a bit of detective work. The point is, eventually I came up with that figure, ran units, and gagged on my latte. (I'm fairly certain it was a different latte from the one I started with.) So what, in particular, is your question about the 3 ms figure?
I’ve found that using geerlingguy’s Ansible roles for MySQL, Nginx, and PHP, most random PHP applications can be deployed with default configuration. I’ve had them in production with Matomo for the past year or so and had no problems so far.
A lot of the challenges faced with a ‘from scratch’ install will revolve around which PHP version and extensions to install and how to get Nginx to talk to FPM. Neither of which are trivial for someone wanting to test/evaluate without much prior knowledge.
MAP: Marketo
Conversational AI: Drift
Call recording/analysis: Gong
Salesforce dashboard/forecasting: Clari
Outbound/sequencing: Outreach & LinkedIn Navigator
Customer calls: Zoom
Data: Clearbit/Demandbase/6sense