ysavir

I think they mean the "just" in "Do you just want to host repositories?", implying that it's never "just" hosting repositories, and the needs will continue to grow beyond what the simple solution offers.

I've had them all my life. I remember watching a some video a few years back that said they're more noticeable against a bright/white background, which checked out with my past experiences. And judging by your skiing comment, probably for yours as well!

I surprisingly had good results when I told the LLM to only communicate in ASCII memes. It did a fantastic job of summarizing the situation using relevant memes, and the humor was enough to keep things fresh. As silly as it sounds, it's worth trying when you're in that LLM burnout corner.

I think the parent comment is snark. They're saying that since many Firefox users are saying "Let me turn off AI features, please!" for features they don't want at all, and few to no Firefox users are saying "Let me turn on AI features!" because few to no Firefox users want AI features in the first place, Mozilla is making AI features opt-out to "satisfy" the "want" of turning off AI features.

I've seen my cats pull on a cord in order to reel in the toy at the end. I don't find that to be all too different from the cow orienting a scratcher. Should I?

For what it's worth, it happens to me about 5 times each summer. But I also welcome spiders as pest control, so it's not a surprise, and I forget all about it 5 seconds later.

I wouldn't call ChatGPT "brand recognition". People know the term ChatGPT, but I don't think they associate it with OpenAI or any company in particular, in the same way that people might associate Civic with Honda. Instead they'll associate it like they do the terms Bandaid, Kleenex, etc., as a catch-all term for LLM chat interfaces, regardless of who is providing the service. When OpenAI starts ads, I imagine people will start saying "oh, here's a ChatGPT without ads" and point to Claud or Gemini or whatever.

That's all true, but I think the article's point still stands: React trades one set of compromises for another, and regardless of the tool used, software engineers using that tool have to do a lot of lifting to get the tool to work. It's not a question of whether react is better than backbone or vise versa, it's a question of whether we software engineers, as a group, are emphasizing the correct compromises, and what takeaways we can make from examining the compromises of today's popular tools.

It depends a lot on the rate of change of the document.

Documents that experience little change don't need classes because their structure is reliable.

Documents that change often have unreliable structures, and will require frequent updates to the CSS rules to match structure changes. Using classes insulates the CSS from the document structure, mitigating the need to update CSS as the document evolves.

It also depend your development strategy. If using Vue components and writing the CSS in the same file as a dedicated, small-scoped components, it's practical to update the CSS references alongside the document changes. But when there's distance between the HTML and the CSS, or there are components in use who's structures may change unpredictably (such as from 3rd party libraries), classes provide a safer reference.

There's no need to have an ideology of using classes or not using classes. The practical approach is to assess the nature of your work, the rate of change of the documents, and to adopt practices built around those assessments.

Location: Upstate New York, ~ 1 hour north of NYC

Remote: Yes, open to Hybrid in NYC

Willing to relocate: Possibly closer to NYC

Technologies: Ruby, Ruby on Rails, VueJS, React, TypeScript, Git, Postgres, ElasaticSearch, Heroku, AWS, Jira, OAuth

LinkedIn/Résumé: www.linkedin.com/in/yaniv-savir

Email: yaniv@yanivsavir.com

Seasoned software engineer with 11 years of web development and a proven success record using Ruby on Rails, Vue.js, React, and other frameworks. 10 years in startups, as small as 7 employees. Experienced mentor and coach to up-and-coming engineers, and champion of collaboration and efficient communication.

My ambitions are to build products I can be proud of. Software isn't an end, it's a means to an end, and the goal is hit our targets and win customers leveraging software. If you're looking for a level headed engineer who prioritizes a healthy and respectful work environment, a strong communication culture, and a deep understanding of the problems we're facing, reach out and say hi.

I am also open to work with technologies not listed above.

Happy to give you my spin on this. I use Vue, but in personal projects I mix Vue and vanilla JS according to page complexity. On pages that need more state management and would benefit from orderly code (such as the Options API for Vue), I use Vue. For simpler, shallower functionality I use plain JS. I want to emphasize my callout of Vue's Options API, which provides for very nice and easy to read structure to the code. React and Vue's current Composition API, I feel, look like and encourage spaghetti code. But hey, people get better typescript coverage, I guess?

> 1. I see that the event interface specifies detail with `id` and `value` fields. What is the reason for using this? The underlying event already has a target, which will have the id and the value fields anyway. Are the widget's in this system so different that they have different id fields to the DOM elements?

This is something I rarely use in Vue anymore. I think back in the day, when Angular first emerged and pushed these sort of frameworks, there was a philosophy towards making components embed in code as if they were HTML native elements, and not needing to write JS around the event. If I remember correctly, providing a value field isn't asking it for the value of the event. It's specifying which value in memory should be set to the output of the event... But my memory is dodgy on that. It's confusing and I rarely see it used these days, but maybe that's reflective on the projects I've worked on.

> 2. There does not appear to be a field in the emitted event for the event sub-name (other than the custom name in the event structure itself). What if a component needs to emit something other than a "click" event? Ordinarily we'd get the event name from the event itself, so the handler knows whether it is being called on "focus", "click" "activate", etc. This information is lost with a custom event.

Can you expand on the usecase here? Ordinarily, at least in Vue, there's no need to know the name of the event currently being triggered. The component emits a "change" event (or whatever you call it) and the parent component, when setting up the child component, will specify some sort of 'on-change' attribute that listens for the 'change' event and says which function should be evoked as the callback to it. So basically, instead of having to write `document.getElementById('foo').on('change', respondToFoo)`, you simply write `on-change='respondtoFoo'` directly on the element in the HTML.

It's not the world's biggest win, but it does reduce the amount of code our eyes having sift through in reading the JS, and attaches the event details directly to the element(s) they relate to, which I've found to be more readable.

> 3. I'm still confused why you can't emit DOM elements; I mean, if you said "can't do two-way data binding" or something along the similar lines, it'd (maybe) make sense, but your response makes me think that you have not even considered it. I feel, maybe wrongly, that this library is both unnecessarily crippled and over-engineered - it targets spaghetti-as-a-pattern React, but not the hierarchical DOM?

You can, at least in Vue, but it's working against the grain. There's two reasons why:

1. Separation of presentation and state. These frameworks like to keep the HTML/DOM as simple presentation tools, and store logic and data separately. So when triggering events, we want to be emitting the important data as data, and not be concerned with the presentational layer from which that data may have originated.

2. Reusability of components. Emiting dom elements creates a more tightly coupled environment where there are a lot of expectations of the object being emitted (and little assurance as to what that object contains). By only exposing data and leaving the DOM element behind, it's easier for invoking components to use that data without having to hold expectations of the data structures being passed through.

Seems the opposite way round to me. We couldn't conclusively say that AGI is possible in principle until some physics (or rather biology) discovery explains how it would be possible. Until then, anything we engineer is an approximation as best.

A large part of it is that we maxed out a lot of how communication tech can impact daily life, at least in terms of communication, but economically and culturally got in the habit of looking for new and exciting improvements to daily life.

The 19th and 20th centuries saw a huge shift in communication. We went from snail mail to telegrams to radio to phones to television to internet on desktops to internet on every person wherever they are. Every 20-30 years some new tech made it easier, cheaper, and faster to get your message to an intended recipient. Each of these was a huge social shift in terms of interpersonal relationships, commerce, and diminishing cycle times, and we've grown to expect these booms and pivots.

But there isn't much of where to go past "can immediately send a message to anyone anywhere." It's effectively an endstate. We can no longer take existing communication services and innovate on them by merely offering that service using the new revolutionary tech. By tech sectors are still trying to recreate the past economic booms by pushing technologies that aren't as revolutionary or aren't as promising and hyping them up to get people thinking they're the next stage of the communication technology cycle.

I agree that the quality went down, but I think it might be part of their strategy.

I think when they first started, they tried the HBO strategy of putting big money into big shows that try to win over broad audiences. But over time shifted to focusing on low budget shows that appeal to specific, smaller audiences. Which makes sense, if your goal isn't to have 70% of the total market as paying users but rather 90% of the market as paying users.

My understanding is that this isn't Netflix's fault. They were king when they were the first major streaming service, and studios and networks were happy to get extra income from hosting their content on Netflix. But Netflix knew that any success it has would be mimicked by those same studios and networks, and that they would pull their own content to their own services as soon as they have them up and running, and so Netflix started making its own content in preparation for that day. And that bet paid off.

Thanks for sharing the link, I hadn't seen that before! Very serious allegations there.

> Calling in the guard is not overreach when a city is demanding it through inaction.

Is the city calling for protection, though? There's a big difference between police departments fabricating data and a need for intervention, whether through taking control of the city police or bringing in the national guard. What's the actual situation? Why is the Trump administration militarizing the city instead of running statistics to get actual crime numbers?

What's your take on the article saying that D.C.'s crime rate is at a 30 year low? Do you feel that things in big cities are so bad that an overreach of powers is justified in an attempt to fix it?

Don't forget:

5) One person with a copper mine and a soldering gun.

It wasn't a criticism of what they were saying (a point on which I agree with that poster), but whether the comment itself was contributing to the discussion or not. It was a very low-effort comment that offered no reflection on what the parent said, doesn't tie into the original post, and lacks depth towards its own point.

Downvoted as this comment feels like it's trying to be witty/upshowing the parent comment without actually engaging with it or offering anything of substance. If the comment was along the lines of "yes, but we've also done a lot of good, let's reflect on both", great. But that's not what it was. Instead it feels like a statement that's trying to argue with the parent comment despite the parent comment never saying we haven't done any good.

Nah. We just need one source to scrape them and make the results available for others.

The difference is that human researchers have agency--for better or for worse.

Less that AI is cheating and more that we basically found a way to take the thousand monkeys with infinite time scenario and condense that into a reasonable(?) amount of time and with some decent starting instructions. The AI wouldn't have done any of the heavy lifting of the discovery, it just iterated on the work of past researchers at speeds beyond human.

ahh, okay. I don't use the service, I didn't realize they had a dedicated UI for it. I assumed it was all just embedded in the text.

Makes you wonder whether the affiliate links are actual, valid affiliate links or just hallucinations from affiliate links it's come across in the wild

The thing about facebook/twitter/etc was that everyone knew how they achieve lock-in and build a moat (network effect), but the question was around where to source revenue.

With LLMs, we know what the revenue source is (subscription prices and ads), but the question is about the lock-in. Once each of the AI companies stops building new iterations and just offers a consistent product, how long until someone else builds the same product but charges less for it?

What people often miss is that building the LLM is actually the easy part. The hard part is getting sufficient data on which to train the LLM, which is why most companies just put ethics aside and steal and pirate as much as they can before any regulations cuts them off (if any regulations ever even do). But that same approach means that anyone else can build an LLM and train on that data, and pricing becomes a race to the bottom, if open source models don't cut them out completely.

Hammering can get loud. But not louder than any motorized tool. And hammering being limited by the energy capacity of flesh and blood doesn't last for long bursts, maybe a few minutes at a time. In contrast, motorized tools let out an egregious, sharp hum that can last for an hour or two without pause. Both might draw someone's attention and frustration, but when comparing them objectively, one is clearly worse than the other.

On top of that, carpentry is done on site and isn't mobile. Someone doing carpentry as a hobby will likely be in a garage or some enclosed space that absorbs and muffles the sound. Carpentry being done professionally is temporary and will stop once the construction is finished. Landscaping, though, is everywhere and without end

The comment was not aimed at the carpenter. Nothing he was doing was loud, and nothing I've experienced with carpenters gives me the impression that they are loud or obnoxious. He was doing a great job. If he took what I said as a dig at his profession, that was his connection, not mine.

My take away, after the fact, was that he may have been someone who enjoyed landscaping his own yard and owned several tools that I listed. Nothing to do with his career and services, and nothing that's a reflection of our interaction.

The story wasn't meant to be a win or a competition. It was a reflection on how some people associate some loud sounds, such as motors, as being perfectly fine and other loud sounds, like children at play, being a nuisance.

I've never seen a carpenter use a lawnmower on the job. Seems unwieldy to drag up a ladder.

On a more serious note, most carpentry tools aren't that bad in terms of noise. They can get loud, but they tend to be momentary, getting a cut done, and back to silence. It's the landscaping companies that are running powered tools right up next to people's houses for 30-40 minutes at a time that are the problem. And by the time one company is done, another arrives and revs their own engines.

As for me ruining his attempt at small talk and insulting his profession... Eh. If someone's idea of small talk is trying to make children appear disrupters of the peace for having fun at camp for 6 weeks out of the year, as children ought to do, I'm not too concerned about making a comment expressing a common and often relatable sentiment that makes that person feel bad about their own disruptions of the peace. To the extent that I "insulted his profession", that was him setting himself up. Don't serve a dish you wouldn't want to eat. He could have made small talk in a hundred different ways or found a way to show appreciation instead of annoyance, but he said what he said, and he set the tone.

I live next door to a summer camp. The kind that has kids from the nearby city come for 2 weeks, sleep in bunks, play outside all day, hike, etc.

A few months ago we had a carpenter doing some work on the house, and he was asking me about the camp and living so near to it. Eventually he asked "Are they loud when they play? That must be so annoying. I'd hate that."

I replied "Nah, it's healthy and fun, and it doesn't travel as far as you'd think. The real annoying sounds are all the lawnmowers, weed whackers, and gasoline powered tools that people keep using throughout the summer". He immediately went quiet and sour. Guess I hit a nerve.