I prefer to avoid having commercial links and don't intend to make this a business, but I'll see if I can reduce the text. the challenge is trying to keep this a reference and explain things properly
That's fine. I would still emphasize trying to make it easy for people to get their kits together. Having someone go from no kit to a poor kit is still infinitely better. If you don't have links, something like a clear list of items would be something that I would find helpful.
For example you say "Keep enough water, food and essential supplies for every person and pet in the home for at least two weeks". Ok, how much water is that? Is a pack of water bottles enough?
I have my own spreadsheet in which I keep track of what I have with expiration dates, so that I know when to renew, I was thinking of making this a reusable template
having built two enterprise data platforms in python, I can't disagree more. for a startup, development velocity matters more than code performance especially for a CRUD app even at medium scale. Frameworks like Django simply enable you to do so much and so quickly. and you can reach world scale, that's what Instagram did!
Having built more than two enterprise apps in Python and many others in many other languages I can say it is certainly possible to build it in Python. But it is one of the worst choices out of all possible languages out of all the other mainstream languages.
Django is fast but has become much less relevant in the age of AI. The issue with Django is you hit issues very early. Within 2 to 3 years of using Django the warts of using Django become apparent. Django is mostly a good tool for the first year, but if the tool survives beyond that, Django becomes more of a liability.
You get 80 percent of the convenience of Django with just popular nodejs libs like prisma, zod and express. Once you add in LLS it’s 100 percent.
I have definitely noticed this in our organization as people use more AI tools. At first educating by providing feedback to the developers, then after a few repeat directly requesting that a PR is broken down if there is an obvious way to do it.
But the thing that really made the differences:
1) having a small github action that checks the size of a PR and leave a warning comment if it's large. Obviously some PR have to be large but then the developer has to justify
2) much better: getting early access to Github Stacked PR. we all like the experience and it solves a number of problems. without it even if you are disciplined and break down your work on several PRs, you end up having to deal with rebasing them one by one when the base moves. We modified Claude.md so that it tries to use it when it makes sense and now even AI generated changes result in stack of small PRs
I think it's worth investing in this as there are studies showing that review time is exponential with the size of PRs (or worse you are more likely to let defect go through on a large PRs). And AI agents are also better are reviewing smaller chunks.
I had personally several experiences of asking someone to break down a super large PR into smaller ones and found a defect in PR#2 which wasn't caught in the original AI driven PR review
Over the last 6-9 months, I build an app to calculate the optimum jet lag management plan from a combination of flight. It tells you the optimum times for light exposure, sleeping, taking coffee...
It started with a naive "I know the tricks, let put them in an app" based on my own travel experience and quickly turned into a pretty nasty constrained optimization problem to optimize a cost function while keeping the schedule realist. So far I have been slowly releasing with friends and family, but I am pretty happy with the results as it can handle pretty complex combination of flights and layovers, compared to other similar apps.
After ~20 years of long-haul travel, I spent the last 9 months building Jetlag Coach, in parallel with my busy life (full time job toddler and pregnant wife!). You give it your chronotype and your actual itinerary (multi-leg and layovers included) and an optimization engine generates a personalized schedule for light, sleep timing, caffeine and melatonin to shift your circadian clock toward the destination time zone.
At core it turned out to be a complex optimization problem and a real challenge to tackle. I also put a lot of care in the UI/UX, while I usually focus more on backend work. It's working well, I am just finalizing the handling of some of the nastier edge cases
There is definitely some confusion on the EU part. I am a European citizen, but some of my activity data on some of the sites I host is logged in US Posthog, which means Posthog is subject to the GDPR, even if the data is US hosted!
I think it would be better if there was an EU browser that provided a warning if accessing sites outside of the EU. If an origin site is in the EU then it could be subject to EU regulations.
this is what triggered my post. The announcement pretends that it's not bug deal because of "anonymization" but that's easier said than done. You can send custom events and logs that contain confidential information even if it doesn't contain personal identifiers
I initially used Posthog as an alternative to Google Analytics with more privacy. Now they want to use the data for a business purpose. Working hard towards enshitification?
I prefer to avoid having commercial links and don't intend to make this a business, but I'll see if I can reduce the text. the challenge is trying to keep this a reference and explain things properly
reply