What does the author use to measure sound and create those graphs? I'm interested in automatically monitoring an annoying noise that's coming from a neighbour.
As others in the comments have already mentioned, Studio Six makes very nice Audio Tools (at least on iOS/Mac, not sure if they are also on Android). Their SMAART module is the cheapest way to get access to SMAART tools - which can be a thing in and of themselves. I use them to asses what's going on with live sound I occasionally mix. What's really nice is they calibrate fairly accurately to Apple hardware out of the box. More than accurate enough for my purposes.
> I want to preface this by saying yes the practices here are very bad and embarrassing (and we've since added robust unit/integration tests and alerting/logging), could/should have been avoided, were human errors beyond anything, and very obvious in hindsight.
>
> This was from a different time under large time constraints at the very earliest stages (first few weeks) of a company. I'm mostly just sharing this as a funny story with unique circumstances surrounding bug reproducibility in prod (due again to our own stupidity) Please read with that in mind
If they would have made that mistake by writing code and just misunderstood something or oversaw the problem, fine. But making this mistake by copy-pasting from ChatGPT without proper review is just terrible.
I don’t find the source of the error being a careless human writing original code without proper review vs a careless human copy/pasting code without proper review to be significantly different.
If you code for a hobby/fun, yeah, sure, it's a silly mistake.
If you're earning past six figures, are part of a team of programmers, call yourself an professional / engineer, and have technical management above you like a VP of Engineering, yadda yadda....then it's closer to systematic failure of the company's engineering practices than "mistake."
There is a reason we call it software engineering, not software fuckarounding (or, cough, "DevOps Engineeer".)
Software engineering practices assume people are going to make mistakes, and implements procedures to reduce the chances of that making it into production, and reduce the impact of those mistakes if they do make it into production.
I agree, but in fairness, engineering mistakes do happen all the time, in every organisation. A good engineering culture enables mistakes to be acknowledged and reviewed in an emotionally neutral manner, ideally leaning to a learning experience.
Being on the receiving end of an internet pile-on of "OMG you idiots everyone knows the first thing you do when setting up a flerble cluster is spend a week installing grazoono monitoring!" is not conducive towards building a good engineering culture.
Get into the habit of colour-coding your important SSH sessions, red/green/blue can give you a very powerful subconscious check before doing something very silly.
I use iTerm2 and have different profiles for different directories/remote hosts. iTerm switches the background colour automatically for me. I'm sure other terminal emulators would have similar features.
what phist wrote. Color code the backgrounds of your servers, different colors. So anyone who connects to 'take console' in any system is hit by a blinding electric Green/Blue/Red/Yellow and other striking colors.
I assume that all systems already have descriptive names App_DEV_Server1, App_PROD_Server5, etc.
It also helps if (ofc they would be right??) in separate IP groups/WLANS?
If you are running Windows, it's a good idea to use BGINFO.exe by SysInternals (or Winternals as we old people still call it), and display the most relevant info (showing Dev/Prod/UAT/etc.) with big-big-big letters.
Lazy attitude towards proper role management and poor engineering practices. More common in small companies or small teams managing their own service (db and app)
Really all you need is logging and potentially temporary read access to the db if you need some info that you can't derive from the logs.
So, I think this hilarious, but link shorteners have to be stable, right? What happens when link shorteners go offline? Is there a way of decoding shortened links without the server?
"So, I think this hilarious, but link shorteners have to be stable, right?"
Yes, a link shortener does need to be stable but luckily they are extremely simple to operate.
You should be able to run a very popular link shortener on a leftover 1U with very low associated bandwidth and power costs. It's not unrealistic for a person, or group, to commit to this indefinitely.
Thinking about it that is absolutely possible, but only for you personally. A site could store your destination as local storage and translate through a service worker (which runs even if the site is offline). Half a page of JS would do it. Not sure if it is useful though?
All link shorteners, even those that use a readable URL, keep the target URL in a database. It's not possible to decode any of them without the service being available.
The novelty here is that the service deliberately makes itself unusable for comedic effect
I don't know when that was written, but it definitely feels like The Expanse authors read that exact page and built their stealth system to address those points - the stealth ships in the books aren't permanently stealthy (they have to radiate their heat from the internal heatsinks after some amount of time, seemingly on the order of months), and are immediately detected when they light up their engines (and hence coast until they reach their destination).
The main characters also manage to find a stealth ship after coming across coordinates to it - it was parked and completely offline (and unmanned) in the orbit of a small asteroid, which would further obscure any signature it might give off.
Unfortunately for cool space battles, no this still doesn't work for the reasons outlined.
First off you have to remember that when a ship turns it's engine on it's going to be visible effectively to the entire solar system unless there is a planet or something in the way. We already have the capability that we would notice a ship moving in the asteroid belt from Earth and in the Expanse it's going to be even higher. So everyone already will have known when you turned your engines on and can run the calculations to see where you are while you are coasting, so even within the confines of the fiction that shouldn't work.
But let's ignore that and say that for some reason no one was looking when you turned your engines on. Assuming your ship is somehow running with all systems off it's going to be roughly 300 C hotter then the vacuum around it, even with a heatsink like you mention (and a heatsink that can store that heat for months is also unrealistic) you're going to be sticking out like a sore thumb to any infa-red. You're just too hot.
Everything about the mission provided valuable data: especially that damaged blade. Failure modes are useful. Next, it might be useful to try flying anyway.
If not, they still have running cameras, sensors and computer, until Perseverance moves out of range.
The rotors will be unbalanced (even if the other side also broke off, chances of the same amount breaking of are as remote as the thing itself), so it will vibrate and probably tip over if it spins too hard
* There's no endless swiping. Users can only see a handleful of matches, each profile stays visible until users say yes/no on each profile, and the profiles are only topped up twice a day.
* All chatting is in-person, which is much more human than trying to text online. If users match, they can't chat. They both put down a deposit (about double the cost of a drink in a bar), pick a day & time they're avaliable, and Breeze automatically makes a reservation at a local bar (the first drink is free), or a park for a walk.
* Since dates require a deposit, and there's only so many days in the week(!), and users can't make new matches without first planning current matches, users don't get overwhelmed with connections - the existing contacts are prioritised.
* They're not owned by Match.com - which for me is a big plus! More disruption of their monopoly is a good thing.
Looks interesting indeed. Seems to only be available in NL though, as the company seems to be Dutch and they don't say anything about where they are available. Make sense if they do the whole "make a reservation for me" thing.
> They're not owned by Match.com
Let me know in 5-10 years. I'd bet a substantial amount of money that eventually match.com will acquire them as well. Seems to be what ends up with all these dating services.
> Breeze is active in 15 cities: Alkmaar, Amsterdam, Breda, Delft, The Hague, Eindhoven, Groningen, Leiden, Maastricht, Nijmegen, Rotterdam, Tilburg, Utrecht, Wageningen, Zwolle. Beforehand you can choose where you want to date by going to the ‘Date preferences’ menu.
Seems helpful if you are looking for a committed relationship.
Many of us are not. Where can we go?
This is the question that really needs answering; else we will have no option but to continue to flood the same spaces that commitment-seekers use. The relative signal to noise ratio is hurting all of us.
This is only something that would work for the Dutch. That's the whole point of "going Dutch". The fact that women have to pay anything at all would make this a non-starter in the US market.
