> Most of the time knives that are too sharp are much more dangerous than knives that are too blunt.
With a sharp knife, you cut through food very easily so you use very little force. You also use techniques that prevent you from getting hurt, such as the claw ( https://www.thekitchn.com/knife-skills-the-claw-75998 ).
But if someone has used a dull knife for most of their life, they may not have cultivated these skills and may hold their knife in an unsafe way and or use a lot of force when cutting.
For someone like that, a sharp knife could be a lot more dangerous, but if they're trained/using it properly, a sharp knife is a lot more safe as it reduces effort and chance of the knife slipping.
I'm a bit confused at the ways HTMX and Alpine AJAX differ and where they're the same. I know there are header difference, for example, and that HTMX may have some functionality Alpine is missing, etc.
For example, HTMX has websocket support, while it looks like Alpine doesn't. Alpine has Alpine AJAX, but also alpine-morph, etc.
I only saw one article specifically addressing combining the two, but also very little on server side transitioning from one to the other.
I wish there was an article on starting with HTMX and what Ajax looks like in p
> I don't think having the server render the table HTML and you injecting it is a good idea.
HTMX, Alpine AJAX and other similar progressive web frameworks work exactly this way, as do server side rendered React.js and friends.
> What if the server has downtime, and returns a 200 response but with a "maintenance mode" page
If the server is in maintence mode, it should not display the web application/web page, but instead show a "We're in maintenance mode" messages.
> Having it render only on a successful response and correct parsing of JSON data is more reliable.
You're comparing making a simple web page with either no secondary calls or a single secondary call using a few lines of code to writing a client side web application. It's a bit like comparing a car with a bicycle.
> You also start complicating things in terms of separation of concerns. You potentially have to adapt any styling considerations in your API, for instance if the table needs a class adding to it. Overall, not a good idea, imho.
This is certainly an opinion and that works for you, but HTMX and similar actually make much of my life easier, rather than harder since all that styling, etc. can live alongside my server logic, rather than being in an entirely separate second application.
The phone company would have been happy to sell you more phone lines. I knew people who had some.
But you're right that as dumb as it is, it's likely that ISPs would have charged per "device" (ie per IP address).
Before 1983 in the US, you could only rent a phone, not own one (at least not officially) and the phone company would charge a rental fee based on how many phones you had rented from them. Then, when people could buy their own phones, they still charged you per phone that you had connected! You could lie, but they charged you.
Like I said, I have mixed feelings about NATs, but you're right that the companies would have taken advantage of customers.
I'm not the OP or author, but the argument against private network addresses is that such addresses break the Internet in some fundamental ways. Before I elaborate on the argument, I want to say that I have mixed feelings on the topic myself.
Let's start with a simple assertion: Every computer on the Internet has an Internet address.
If it has an Internet Address, it should be able to send packets to any computer on the Internet, and any other computer on the Internet should be able to send packets to it.
Private networks break this assumption. Now we have machines which can send packets out, but can't receive packets, not without either making firewall rule exceptions or else doing other firewall tricks to try to make it work. Even then, about 10-25% of the time, it doesn't work.
But it goes beyond firewall rules... with IP addresses being tied to a device, every ISP would be giving every customer a block of addresses, both commercial and residential customers.
We'd also have seen fast adoption of IPv6 when IPv4 ran out. Instead we seem to be stuck in perpetual limbo.
On team anti-private networking addresses:
- Worse service from ISPs
- IPv4 still in use past when it should have been replaced
- Complex work around overcoming firewalls
I'm sure we all know the benefits of private networks, so I don't need to reiterate it.
I don't think it's the same error, but without a good error message I don't know.
I did manually download the models and associated them, which are great but then the audio didn't work. On the browser version, it never asks me for permission for an audio device, and on the native version, it makes a file of 0 length and then complains it can't read the contents.
My read is that the project looks very interesting, and I'd love a FLOSS replacement for Aqua Voice, but this software isn't ready for everyday use yet, at least not on Linux.
I'd love to help somehow, whether that's a donation or experimenting if you point me to somewhere.
Tried it with AppImage on Linux, attempted to download a model and "Failed to download model. An error occurred." but nothing that helps me track down the error :(
As a new boss who has recently started using Story Points and requiring the devs stick to tickets, I think this article points to problems that are valid, but unrelated to the issue of tickets.
> a factory that forgot what it’s building. Features ship, bugs creep back in, and the codebase becomes an archaeological dig of short-term fixes and forgotten context.
That's tangential to tickets.
We always had tickets to some extent, but our current process involves organized feature planning, design tickets, implementation tickets, and review.
That has imposed a lot more structure, but it's also resulted in a lot less work. Developers know what the priorities are, know what the scope of work is, they know they'll get reviewed.
Issues the article talks about such as short term technical debt being accepted are tangential. If a problem comes up, it's documented and then a decision is made on when to address it. If it's serious, that could be immediately, and if not, it may be put aside until it's encapsulated in other work, such as a refactor or redesign.
Tickets drastically improve context by telling the story of what they're about, connecting to commits, and connecting to merge requests. The code becomes a series of narratives.
> “Yeah, good thought, but just stick to the ticket for now.”
That's bad management. Good management will say "Good thought, make a new ticket for it so we can hear what's on your mind and evaluate it."
> Ask why the feature matters? You’re overstepping.
Ask why the feature matters and you're a good dev!
But before we had this level of structure at my organization, sometimes the devs would override the stakeholder's explicit wishes without informing them!
Now with tickets there's an opportunity for dialog and a paper trail on decisions.
> Suggest a refactor while in the code? Not in scope.
This one is tricky as I just told a dev not to do a refactor this week. The reason was the refactor was tangential to the feature, which was already late to deliver. Instead, a ticket was made and we'll evaluate the decision to refactor next week.
> Improve naming, extract duplication, or add a helpful comment? That’s gold plating now.
Those aren't gold plating, they're part of code quality checks that go into reviews.
The tickets aren't the issue here any more than one might complain about a specific programming language being the problem. The core issue is the environment, and specifically of management.
Before I had tickets, developers worked on what they wanted to work on
I'm interested but I have more questions than answers.
It might make sense to provide some system for figuring out how to create the budget, and then how to track your expenses against it.
In my mind the simplest form of budgeting is so-called "Envelope Accounting", where you have physical envelopes full of money where you pull money out when you spend it.
There are electronic envelope accounting systems which retain the simplicity.
I'm a bit unsure of how this system works, where it differs, etc.
In summary, I'd love to see:
1. An explanation of how to construct a budget using your system.
2. An explanation of how to compare your spending to your budget? (bonus points if I can use my existing plain text accounting system, or at least a csv file)
3. An explanation of how to track my budget over time.
Did you read the statement they put out later that day about Musk, or the day after?
I agree this was a terrible move on the ADL's part, and there have been others, but you're essentially labeling the oldest anti-hate group "fascist" because you disagree with one statement they made.
This dismisses any concerns they raise, or if someone else says the same as them, then they too must be pro-facist.
Demanding moral perfection from an organization in order to believe that discrimination exists is a standard that I don't believe is fair to any group.
Basically, almost any time Zionists are mentioned, they're mentioned in a negative light and with genuine disinformation, such as that Zionism is the belief that Arabs needs to be destroyed. That is like saying the Civil Rights movement in the US was about killing white people.
They also position things in such a way that implies antisemitic things, such as saying that Zionism is only 200 years old, or discussing the Israel wars only or primarily through an Arab lens.
These biases around Jewish topics are small individually but large in aggregate, especially in how they present Jews and Jewish topics.
Multiple Jewish and civil rights organizations have done a more comprehensive job at discussing this, even organizations who don't usually agree on things. While they talk about "anti-Israel bias" Wikipedia articles on or mentioning Zionism (80% of Jews are Zionist) are IMHO just as, if not more damaging, and demonstrate the issue.
Most importantly though, talk to the Jews in your life about this. They will tell you.
The ADL and other Jewish organizations have pointed out that aside from articles about Israel that articles about or mention Jewish topics generally have been editing with disinformation or that made Jews out to be the aggressors.
I agree with you that in order to believe in the ideals of liberal democracy that we must have a core belief in truth. And it's absolutely true that the Trump administration has taken a position that is deeply chilling on the issue of speech. It's clear they want to be the sole arbiters of what "truth" is and they want to use their power to manipulate the reality.
All that said, I cannot as a Jew ignore the fact that Wikipedia is not in itself neutral, and that "more eyes" does not negate systemic bias. What I've seen as a Jew is what the true meaning of marginalized minority is, which is to say that if you are truly a minority and truly marginalized then in a vote of "truth", your reality will be dismissed if it conflicts with the vast majority, and that Jews are only 0.2% of the world population.
While I brought it up, I am not debating the issue of antisemitic bias in Wikipedia[1] as anything other than an illustration of your point of objective truth being true, but also that we can't simply rely on the wisdom of the crowd to materialize that truth.
To preemptively address the issue that's bound to come up when I post this- I'm not arguing that the evils of silencing the entire Wikipedia project are equal to or a fair response to Wikipedia's antisemitic bias. I do believe Wikipedia needs to address its bias problem and that's best done through internal reform.
Two wrongs don't make a right, nor are two wrongs always of equal weight.
[1] Firstly because my point is separate, and secondly because I've encountered the exact issues I've found in Wikipedia elsewhere, which is why I'm sure I'll be voted down.
With a sharp knife, you cut through food very easily so you use very little force. You also use techniques that prevent you from getting hurt, such as the claw ( https://www.thekitchn.com/knife-skills-the-claw-75998 ).
But if someone has used a dull knife for most of their life, they may not have cultivated these skills and may hold their knife in an unsafe way and or use a lot of force when cutting.
For someone like that, a sharp knife could be a lot more dangerous, but if they're trained/using it properly, a sharp knife is a lot more safe as it reduces effort and chance of the knife slipping.