When someone is empowered to work remotely, and is salaried and not held to specific hours, then it's very hard to identify what work is "theirs" and what work is "the company's" in a legally consistent way. Yes, it's usually obvious from context, but context doesn't always carry to a court of law. It can be particularly messy because the kinds of open source projects one contributes to often overlap with the work they do in their day job.
So most companies which are salaried and allow WFH will usually ask employees to explicitly list any project they work on which they don't want owned by the company, with the expectation being that everything unlisted is owned by the company. It's a bit cumbersome, but generally the least bad option.
At our company we have a form to file if we do work outside of hours on OSS or pet projects, and to the best of my knowledge nobody has ever had their application denied.
edit: it's important because it's symmetric - not only does this define what _isn't_ property of the company, it defines what _is_. So if you come up with a clever solution to a problem for a company purpose and introduce it into an OSS project, it doesn't come back to haunt the company.
> 1. my "fear" would be that if I use the same Postgres for the queue and for my business database...
This is a feature, not a bug. In this way you can pair the handling of the message with the business data changes which result in the same transaction. This isn't quite "exactly-once" handling, but it's really really close!
> 2. also that since it would write messages in the queue and then delete them, there would be a lot of GC/Vacuuming
Generally it's best practice in this case to never delete messages from a SQL "queue", but toggle them in-place to consumed and periodically archive to a long-term storage table. This provides in-context historical data which can be super helpful when you need to write a script to undo or mitigate bad code which resulted in data corruption.
Alternatively when you need to roll back to a previous state, often this gives you a "poor woman's undo", by restoring a time-stamped backup, copying over messages which arrived since the restoration point, then letting the engine run forwards processing those messages. (This is a simplification of course, not always directly possible, but data recovery is often a matter of mitigations and least-bad choices.)
Basically, saving all your messages provides both efficiency and data recovery optionality.
> 3...
Legit concern, particularly if you're trying to design your service abstraction to match an eventual evolution of data platform.
> 4. don't provide "fanout" for multiple things
What they do provide is running multiple handling of a queue, wherein you might have n handlers (each with its own "handled_at" timestamp column in the DB), and different handles run at different priorities. This doesn't allow for workflows (ie a cleanup step) but does allow different processes to run on the same queue with different privileges or priorities. So the slow process (archive?) could run opportunistically or in batches, where time-sensitive issues (alerts, outlier detection, etc) can always run instantly. Or archiving can be done by a process which lacks access to any user data to algorithmically enforce PCI boundaries. Etc.
The distance between a scientific revolution being accessible to the ultra-wealthy and the average consumer is measured in years, and shrinking rapidly.
I would rather billionaires get anti-aging technology 10yrs before I do than never get it at all.
I cringe at the idea that beyond a certain level one stops writing code.
You never stop writing code, unless you truly just don’t enjoy writing code, and if that’s the case please don’t manage engineers.
You do eventually stop shipping critical code, because at a certain point your managerial leverage means there are many other more productive ways to spend your time.
But the day you “stop writing code” is the beginning of the end of your effectiveness, because when your job is augmenting the impact of others, you need to have a deep familiarity with their daily experience.
Consider that any manager who “stopped writing code” five years ago has (probably) never had the daily experience of being a fully remote developer in a fully remote organization, with all the collaboration challenges and focus opportunities that entails.
And a manager who “stopped writing code” two years ago probably doesn’t get how the process changes with the assistance of LLMs, what they can dramatically accelerate and where their limitations introduce risk.
Never stop writing code. Never stop building a local version of your code base. Never stop using your internal build tools and dev environment. Never stop watching production logs and chasing down the occasional bug.
_Do_ stop assuming your code is production-ready. Do stop commenting on code reviews. Do stop assuming that the code you write has meaningful value (except as a way for you to keep your situational awareness.)
Most importantly, stop letting “writing code” be a source of stress or an obligation, and start having fun again doing it. Your organization will thank you for it.
Our house is above the prevailing level, built on a cement slab foundation. We have no basement, and water would have to be >3' high above the land to get into the house, but that's only ~10' above sea level.
We have no electrical wiring below waist height, I think 3'? Our floors are tiles and our load-bearing walls are cement, so if we just had flooding we'd be able to get to ~13' above sea level before being in real trouble. Our furniture would be written off.
Our house is actually a bit more durable than the country. If we had a 15' storm surge, the house might survive, but the island would be toast. That would submerge nearly the entire island, and it would be happening during a hurricane. It would take months to recover even basic infrastructure. Our plan for that is to give up everything we own and return in a year or two to rebuild.
_But_, for a variety of reasons, a 15' storm surge is meteorologically improbable here. It's a once-in-a-millennium event, even accounting for the worst of global warming. Nothing is impossible, but there's no point in planning for it; it's like living within a thousand miles of yosemite national park. ¯\_(ツ)_/¯
As I said in a different response though, when you have a hardened home you fear storm surges, and we do. Our house would probably be obliterated by a 12’ storm surge at high tide.
We’re built on a 3’ high cement slab foundation though, so if we had only 1’ of water around the house we’d be fine. (This is a building code here, it’s nearly impossible to build a basement and your house must be floored 18” above your prevailing level.)
For a variety of meteorological reasons that’s exceptionally unlikely for my specific location, but it’s something we’re acutely aware of and plan ahead for.
As the study concludes, wind will absolutely tear apart a cheap house, or a structure not built to be resilient to wind. And most aren’t.
_But_ once you’re ready for wind , as we are, you live in fear of the storm surge accompanying a major hurricane. Especially since it lasts 4-6 hours and can overlap with high tide, that’s a 15-20’ sea level rise of churning water. No house can be practically hardened against that, and when wind is gusting at 100+mph it’s not safe to run or move.
When we anticipate a major storm surge + storm, we plan for an island-wide evacuation of 50,000+ people to seven small shelters.
I live in the Caribbean, and we get a lot of hurricanes. A few every year.
We build for extreme weather. Our building codes (and common sense) protect us. My house has 10" of concrete on all our exterior walls and 1" concrete shingles on the roof, with no electrical system below waist height. We have 1/4" galvanized sheets of metal in the shed that we can bolt over all our windows when a cat-4 blows through. Don't get me wrong - a cat 2+ is still a giant pain in the ass to live through, but it's not a long-term problem.
Also, most people don't bother with home insurance (unless they have a mortgage) covering storm damage. You build your house in anticipation of repairing it and thus build better.
A lot of our current situation is only possible because we had an island-wide reset in 2004 (https://youtu.be/NzzeDGICjbA), that may be what it takes for Florida.
In my case, I use a Google Apps email account so my family has a shared email domain (and I can better handle tech support and manage my kids’ use). That’s slowly become completely incompatible with nest and any consumer hardware or services, and that process of integration degradation was incredibly frustrating.
Google consumer software/hardware is dead to me now, I just can’t use it even if I weren’t holding a grudge.
Though it still has warts and opportunities for improvement, our house mostly runs on Unifi (for networking and security cameras.)
I am an experienced engineer with twenty five years of infrastructure and protocol development, and my experience setting up an all-Sonos home system is a _saga_ of epic proportions.
Unbelievably frustrating software decisions for otherwise excellent hardware. My favourite(?) part is the “Sonos net” independent network which takes over when one speaker in a group is connected via Ethernet, taking the rest off wifi silently and creating a dedicated wireless network. Then when you connect Ethernet to another speaker in the same group it loses its shit silently, creating and destroying new wifi private networks in an unending cycle, without any notification or visibility in the app. And speakers on a Sonos Net network announce and are discovered differently than spec, which adds a hop and breaks any other subnet connections in a way which is _very _ hard to debug.
And that’s just the setup. My partner and kids use them strictly as airplay targets, and refuse to use the app or voice assistant because of the UX and bugs.
If I didn’t have 5k sunk into the hardware already I wouldn’t touch it with a ten foot pole.
I’m constantly amazed at how differently I learned to do things from my father than from school.
My father had all sorts of approaches similar to this, and it’s how I learned to write essays (outside-in) and research (inside-out), and which I later applied to programming. It made school trivial and fun, and it’s what I’m teaching my kids.
I live in a country which has no local auto industry to protect and can import vehicles from nearly anywhere.
I can confidently say that China has won. There’s just no comparison, and this isn’t just about prices. I’m not even talking about EVs (though this goes double for them.)
Maybe they got to this point through government subsidies and are dumping, I don’t know enough to say. But they’re the best, and cheapest, cars by a long shot.
Pick one single customer and fanatically meet their individual needs. Then add a second. Repeat until you’re no longer needing to tweak your system to delight a new customer. At that point you need sales and you have a business! :)
Though I share your pessimism, “fortunately” the drug companies don’t make much from dementia directly, the cost burden is borne by children and care facilities.
And for what it’s worth, if there were a drug I could buy for nearly any amount of money to get just a few months of slightly improved lucidity for either of my parents, I would pay it in a heartbeat.
Or if they care for their descendants in their later years.
(Not saying fish do this, though I wouldn’t be surprised if giant elder fish clear out predators. A lot of people forget this bit but it’s suspected of being a big factor in insect and lobster longevity, which both capable of recognizing their offspring and not being territorial to their presence.)
The primary way we used it was as the body of a tracking gif, returned as binary. But we also used it as a spacer here and there inline in HTML using the data URI. When embedding in HTML the file size is mostly relevant for brevity.
I went down this rabbit hole about 15 years ago, I ended up hand-rolling a transparent .gif which I think was 15 bytes? Small enough that we inlined it as cdata data urls. (Is that still a thing in HTML? It’s been so long…)
When someone is empowered to work remotely, and is salaried and not held to specific hours, then it's very hard to identify what work is "theirs" and what work is "the company's" in a legally consistent way. Yes, it's usually obvious from context, but context doesn't always carry to a court of law. It can be particularly messy because the kinds of open source projects one contributes to often overlap with the work they do in their day job.
So most companies which are salaried and allow WFH will usually ask employees to explicitly list any project they work on which they don't want owned by the company, with the expectation being that everything unlisted is owned by the company. It's a bit cumbersome, but generally the least bad option.
At our company we have a form to file if we do work outside of hours on OSS or pet projects, and to the best of my knowledge nobody has ever had their application denied.
edit: it's important because it's symmetric - not only does this define what _isn't_ property of the company, it defines what _is_. So if you come up with a clever solution to a problem for a company purpose and introduce it into an OSS project, it doesn't come back to haunt the company.