jamescostian
https://www.propertytax101.org/propertytaxbystate
As someone living in Fort Worth and making good money as a Staff SWE, I got a tax refund this year. It was due to paying interest on my house, but still.
I'd recommend asking your sibling see if they qualify for the homestead exemption, it's significant. You or they can check if they're using it and see their exact property taxes here:
It can be hard enough for humans to just look at some (already consistently passing) tests and think, "is X actually the expected behavior or should it have been Y instead?"
I think you should have a look at the abstract, especially this quote:
> 75% of TestGen-LLM's test cases built correctly, 57% passed reliably, and 25% increased coverage. During Meta's Instagram and Facebook test-a-thons, it improved 11.5% of all classes to which it was applied, with 73% of its recommendations being accepted for production deployment by Meta software engineers
This tool sounds awesome in that it generated real tests that engineers liked! "zero human checking of AI outputs" is very different though, and "this test passes" is very different from "this is a good test"
That said, you can back iMessages up to a computer and back up files on your computer. You just can't restore iMessages to different Apple devices like this, but now we're talking about minor grievances to a really tiny segment of the population
I've been on the receiving end of mass applications. If you stopped justifying your spam behind "everyone does it" (no they don't) and started tailoring your applications, leaning on your network (or building one up) you may need a lot fewer.
I have never mass applied, so I may seem idiotic to you. But even during the times I quit a job before looking for another, I've never been on the market for more than 2 weeks.
This clarifies your stance so well that people acting in good faith won't bother you, and anyone who does bother you very likely isn't acting in good faith - easy to ban.
Plus, when you see someone ask questions about your project and interpret them as "a bulleted list of the reasons I suck", it implies that on some level you think "I suck because I'm not giving these projects more of my time". Giving that kind of disclaimer might help you move away from that mindset, and instead feel more at ease with yourself. Your contributions should be celebrated (as the person with those bulleted points did!), and anyone acting in good faith can appreciate them and fork if needed
Third party libraries have bugs sometimes, and other times our usage of them can create bugs. Nothing like a SIGKILL or anything malicious. That's just the way things are and will be. And breaking down like this in dev can be fantastic!
But when a once in a blue moon issue crops up in prod and all other connections are dropped, the fact that a simple defer+recover couldn't have been preemptively placed on all goroutines is a huge nightmare. I'd even take a "you can add defer+recover for any goroutines created further in this callstack" - it's rare that libraries spawn goroutines, I'll already know which ones to trigger that behavior on
IANAL but this seems incorrect. Price discovery is one thing, being contractually obligated to keep prices at a certain level 80% of the time is another. A court can make a ruling about that 80% number in the contract without saying anything that impacts one's ability to discover the prices competitors charge
EDIT: this comment no longer makes sense after the parent comment was edited. It used to be explicitly asking for help and didn't mention any solutions like static IPs, nor did it spell out a general remark about how this complexity in consumer electronics is bad
2. Use let and modify your types as new ones become available - union them with a new object that contains the new property you need
3. How often are you making recursive types?
I agree that all of this could be made easier, but zod is the best we have and great for most normal usage. The reason TS doesn't want to make this available at runtime is that it means so many changes they make will become breaking changes. Perhaps one day when there's less development on TS we'll see this get added
You can't solve healthcare by throwing tech, money, etc at it anymore than you could solve a broken heart with those things. Sure, money could help you get therapy or pay for lobbying for whatever your solution to healthcare is. OTOH, perhaps the person cutting the checks thinks the solution to heartbreak is a raise ("it shows we care"), and the solution to healthcare issues is to lobby for criminalizing generics ("they're probably cutting corners and making people worse off"). People don't even agree on what are the problems in healthcare (and other things in that list), let alone how to solve them
You're right about turning off your brain. But not everyone wants that thing turned off
Android has its own mechanisms: https://www.wikihow.com/Change-the-Screen-Resolution-on-Your...
Put another way, would it help to decrease the DPI rather than only adjusting text?
I'm sure you can imagine how easy it is to compose functions that accept and return `csstype.Properties` objects, and then at the end, you call `styled` with it to make a styled component. You can even pass styled a function, which takes in runtime-adjustable props, and of course, that function can itself use other functions, passing around those same or some derived runtime-adjustable props.
That said, I have no idea what you mean when you talk about ergonomics being better, can you elaborate? I re-read your initial comment but there wasn't anything in it not achievable in TS using the kinds of things mentioned in the "CSS in JS" section, perhaps there's something else I'm just not aware of? I do not know elm, let alone have experience writing it in non-trivial production codebases, so a concrete example would be great
They're building basically the same thing over and over again. This surprised me, given their intro post: https://vercel.com/blog/turbopack
Relevant quote:
> Turbopack is built on Turbo: an open-source, incremental memoization framework for Rust. Turbo can cache the result of any function in the program. When the program is run again, functions won't re-run unless their inputs have changed. This granular architecture enables your program to skip large amounts of work, at the level of the function.
I'd be curious to see if a real-world app (or even one generated with more variety in components) showed comparable performance numbers
In the future, consider arguing differently.
>> So for example, if I were poor enough, I'd buy cases of water instead of a water bottle, EVEN IF I knew the single use water bottle was better for the environment and a better choice long-term!
> I disagree. This seems to be based on pure speculation and projection.
No, it's based on not having enough money. I guess water bottles are a worse example here, you're right, I've done a bad job of making this point here. See my other paragraph for a better job. Here's a more specific example: a homeless person with $10 goes to a store charging $5 for a box of pads and $40 for a diva cup. They will not buy a diva cup. It's that simple. They'll get their pads. "They won't buy a pad at all" people have needs, maybe some won't but this is a matter many wouldn't compromise on. "They will save" what will they save, pennies? Trust me, this is not a winning argument, there are mathematical boundaries you can't cross, and there's also the fact that if you're optimizing so hard on the diva cup, you aren't optimizing as hard (if at all) on something else.
> You seem to be imagining that poor people can't do any long-term economic planning in their own lives, which is false. As if they're somehow trapped in irrational, short-term, self-defeating thinking.
You're looking at a poor person who has the money to save. I'm looking at a poor person who doesn't. My point wasn't about smarts, this is about basic human needs and a lack of money.
It's true that with more money, you can spend it on more green things. I won't disagree with you there - it was actually the central point that started all of this! And we were agreeing that just because they can doesn't mean they will! That poor people are not somehow magically much more eco-friendly, if only they were given more money. They're not some monolith.
> We're not talking about a homeless person with a few dollars to their name, who wouldn't be buying cases of water anyway, because there would be nowhere to put a case of water.
Very good point, my diva cup argument is a much better one than the water bottle one.
>> A case of water bottles [...]. That's an example of the parenthetical, I'm sure you can think of many more
>> [...] pads [...] diva cup
> how much do you think water containers are contributing to global warming
As I hope you can see from my own words, not very much. I'm providing specific examples of a generality. I can do more at other economic levels if you want. How about "how much does a cheap ICE car cost vs a cheap EV"? Of course, keep in mind the idea I have that people aren't all investing the most resources possible into eco-friendliness, as well as how eco-friendliness exists in many dimensions, so if you're saving for the EV it's harder to be saving for other eco-friendly things, the difficulty in finding a cheap used EV nearby, dealing with debts, etc. - and yes, I do think we can construct a lot of scenarios where a person choosing ICE vs EV can afford the EV, but I think we can also see how it can be quite burdensome on average, and that with more money, the person in question could afford to get to and buy a used EV (but again, I'm not saying they necessarily will! Or even that poor people put into this scenario are more likely to choose the EV over a more expensive ICE car, or something else entirely)
Me too, it does not! It's the reverse, the part in parentheses is what causes the larger part. Say I want water. A case of water bottles is a lot "cheaper short-term" than a single, reusable, water bottle. That's an example of the parenthetical, I'm sure you can think of many more. Now, look at how it connects to the part of the sentence outside of the parenthetical, and directly before it: "the more you must go for things that are cheap at the expense of other things"
So for example, if I were poor enough, I'd buy cases of water instead of a water bottle, EVEN IF I knew the single use water bottle was better for the environment and a better choice long-term! Note that I do NOT assert that most or even many poor people, given more money, would switch to reusable water bottles on their own (hence the "government intervention" bit). If you're confused by the first half of that sentence, think of it this way: if I have $10 and you have $1000, which of us can buy more plastic?
> I disagree that the part in parentheses necessarily represents the economic strategy of poor people
This really isn't about poor people being the most environmentally conscious or the least environmentally conscious. It's about "this box of pads costs the cheapest so I'll buy it". Even if you imagine a tree-hugging poor person looking at a diva cup thinking "this is cheaper long-term and it's better for the environment", if they don't have the money for it, or if spending that money means not eating for quite a while, then they're not going to buy it.
> that poor people are buying over and over, more so than wealthier people
Not only is this a line of argument I disagree with, I even explicitly said I disagreed with it in this part of the comment you are replying to:
>> I think the idea is that if more people were middle-class, we'd see consumers make better choices (personally, I don't see that happening without government intervention of some kind
Unfortunately, that idea is more than just an idea: https://www.epi.org/blog/inflation-minimum-wages-and-profits...
So the thing to look at isn't poor people's emissions, it's rich people's emissions, given that (relatively speaking, bc increasing money supply just decreases its worth) the richer rich people are, the more poor people there are (or the poorer the poor people are). This is well-known, you can google and find tons of articles, but here's one from BBC: https://www.bbc.com/future/article/20211025-climate-how-to-m...
The poorer you are, the less you can individually consume, and the more you must go for things that are cheap at the expense of other things (e.g. buying single-use goods over and over is cheaper short-term than buying something made to last). I think the idea is that if more people were middle-class, we'd see consumers make better choices (personally, I don't see that happening without government intervention of some kind, but that could hurt poor people even more if it happened before poor people got more money to afford more eco-friendly choices). And on the opposite side of the spectrum, if rich people weren't quite as rich, they wouldn't consume quite as much in excess, and would lead to less emissions.
Let's say I have a bug in prod. I just adjust my code, or Dockerfile, or some declarative config (say cloudformation or k8s definitions) and push it, and the CD doesn't say "go to existing machines and update them", it says "spin up containers with this new build and configuration, divert traffic to them, and then remove the old containers when safe". For me, provisioning is not something I want to touch outside of setting rules for autoscaling and saying "start using this new build". So arguments about provisioning (for my usecases) don't help - they sound like adding more responsibility onto me that computers already handle for me.
I don't feel that this declarative and abstract model is necessarily ALWAYS better than the imperative model you get with ansible et al. And I can think of an example: if you just need to run 1 command everywhere, ansible (or chef or puppet) is much faster than pushing a commit and waiting for the build and deployment. Or maybe if you needed a custom kernel. But I've never had an instance where those things were valuable or valuable enough; in all my experiences, fine-grain provisioning and treating servers like pets instead of cattle has never been a better choice (especially given bursty traffic), so I'm trying to broaden my horizons and understand where it would be a better choice.
But I think you're right about the more mid-experience developers. It would be nice if things like the 12factor specification weren't driven by Heroku's desire to make people feel like their approach is right, but rather, had a more nuanced approach like "these are our guidelines, we're confident in most cases they should be followed. If you fully understand a guideline and have a reason (driven by the bottom line, not subjective tastes, and not mentioned by us) to avoid following that guideline, do not follow it"