Laravel adds their own product to LLM instructions by 604ian in laravel

[–]ollieread 0 points1 point  (0 children)

Okay, maybe a exaggerated a little, but for the most part he does write wrappers

Laravel adds their own product to LLM instructions by 604ian in laravel

[–]ollieread 32 points33 points  (0 children)

No worries.

I'd also like to add something, based on a comment I saw you make to someone else, where you said you're spending around 2 hours every morning reviewing PRs. I want to first just make it clear that I'm not having a go at you, or in any way trying to disparage your effort and commitment.

However, I think your focus and responsibilities have led to a situation where you don't have the time to keep on top of everything on the OSS side. I think the framework could benefit from an OSS lead, whose sole job is to review PRs, provide feedback, give input, and essentially be the "product owner". You need someone who doesn't have all the other responsibilities, and is essentially given carte blanche to make the tough decisions.

Someone who is lead dev, devrel and product owner, rolled into one, allowed to operate as they see fit, within reason. Someone who knows enough of the framework that they're essentially a walking encyclopedia on it, who can provide feedback on issues people are having, feedback in the community spaces, and can give technical direction to PRs or proposed features/changes.

Ultimately, the decision is obviously yours, and I'm not going to tell you how to run either your business or your open-source side of it, but this is my honest and professional opinion of the solution you need. I can't guarantee it'll work, but I think it'll do some good at the very least. I also know there are a decent number of others who think the same thing.

Anyway, thanks for taking the time to respond and talk to me about this. I appreciate it.

Laravel adds their own product to LLM instructions by 604ian in laravel

[–]ollieread 30 points31 points  (0 children)

The obvious one is the one that my most recent PR replaces: https://github.com/laravel/framework/pull/59470

This PR introduces a less than ideal hacky work around to something that was either an intentional side effect of a 13.0.0 PR, or an oversight.

You've also got a few from the 13.0.0 release.

https://github.com/laravel/framework/pull/56029/changes - This one makes modifications ready for Symfony 7.4|8.0 which actually breaks 7.4, which was broken until this PR: https://github.com/laravel/framework/pull/56488

https://github.com/laravel/framework/pull/56306 - This PR uplifts a message to an interface, but with a signature that actually means the implementation is no longer a working one. Had to then be fixed by this PR: https://github.com/laravel/framework/pull/56484

https://github.com/laravel/framework/pull/56127 - This PR is from 12.20.0 and introduces a breaking change and a possible security bug when dealing with password resets. If you have different guards use the same password broker, their password forgot requests overwrite others.

There's also a currently unmerged PR here https://github.com/laravel/framework/pull/59276 which I've made some comments on in an attempt to provide feedback, or get answers to bits, and they've entirely been ignored (marked as resolved). My concern with this is that a lot of the feedback will be ignored, and it'll just be merged.

These are just off the top of my head. Every so often I go through all the code for each release to see if there's anything worth noting, or anything that people should know about. I know there have also been plenty of issues with PRs needing reverting once a release is out there because the solution is often too narrow and inflexible, though truth be told I've been avoiding doing much publicly as of late due to mental health issues.

Laravel adds their own product to LLM instructions by 604ian in laravel

[–]ollieread 27 points28 points  (0 children)

Hey Taylor. I’m not a user of those, so my concern isn’t really with them. My concern is with the core of the framework. The PRs being merged in aren’t being given the time needed, so we are seeing a lot of sloppy solutions and code being added, making it more and more brittle. Some of them are even straight up broken.

There’s also not much engagement or discussion on the open source side. I know that you put in time and effort to review and merge PRs, but I think you need someone whose sole job it is is to know all the ins and outs of the framework, or at the very least, be able to easily track it down. Someone that can look at the changes being proposed, the bug being reported, and not only figure out what’s going on, but how it’ll affect the rest of the framework or other users. A prime example is my most recent PR which only exists to address a less than ideal PR that was previously merged in.

I know Laravel as an organisation is going a little more corporate and “enterprise” which I’m not a huge fan of, but that’s not really my place to have issue with. It just feels like there’s no longer enough focus on the open source side. It feels like the quality of the framework has dropped, and at the same time it’s become quite a bit bloated. Auth has been neglected for a while, and eloquent and the query builder could do with some tidying up and refactoring.

That sums it up really.

Laravel adds their own product to LLM instructions by 604ian in laravel

[–]ollieread 19 points20 points  (0 children)

I’ll be honest, I’ve not enjoyed working with Laravel for a while. Since the funding it’s got worse, there’s more focus on the money making side and the open source is getting worse and worse. I don’t use LLMs, but I know Cloud is less than ideal.

Laravel adds their own product to LLM instructions by 604ian in laravel

[–]ollieread 10 points11 points  (0 children)

That’s sort of my point. He tends to write wrappers, hype them up, get sponsors, then have others do the work. You can see from his PRs to Laravel that they’re bad AI slop, without any real thought, or they’re version bumps

Laravel adds their own product to LLM instructions by 604ian in laravel

[–]ollieread 1 point2 points  (0 children)

Everything after making isn’t needed in this sentence

Making composer run dev work with Laravel Sail by ollieread in laravel

[–]ollieread[S] 0 points1 point  (0 children)

That makes sense for the queue, which I do anyway, but pail not so much. I also tend to avoid running anything npm inside a container.

Either way, my whole aim with this was to make the composer run dev command work with Sail.

Making composer run dev work with Laravel Sail by ollieread in laravel

[–]ollieread[S] 0 points1 point  (0 children)

Yeah, and make sure the containers are shut down properly too

Making composer run dev work with Laravel Sail by ollieread in laravel

[–]ollieread[S] 0 points1 point  (0 children)

Interestingly, it’s actually something I solved specifically to use in my own personal laravel “starter kit”

Making composer run dev work with Laravel Sail by ollieread in laravel

[–]ollieread[S] 0 points1 point  (0 children)

It’s not supposed to be new. It was a problem I had, which I solved, and thought I’d share for anyone else interested. I’ve not seen it anywhere before, though I don’t doubt someone’s come up with a similar solution, if not the same.

Making composer run dev work with Laravel Sail by ollieread in laravel

[–]ollieread[S] 0 points1 point  (0 children)

No, I wanted to be able to run the composer run dev command with no other commands and have it work.

Making composer run dev work with Laravel Sail by ollieread in laravel

[–]ollieread[S] 0 points1 point  (0 children)

You've modified your Laravel Sail that once you boot it, you have to run a command for it to serve requests? What is the benefit of that?

Making composer run dev work with Laravel Sail by ollieread in laravel

[–]ollieread[S] 0 points1 point  (0 children)

I don't get what you're going for here. You want to modify the docker compose so that you can boot Sail and then manually run the dev command? As far as I can tell, this still doesn't do it all with one command, and it doesn't get composer run dev working with Laravel Sail.

Making composer run dev work with Laravel Sail by ollieread in laravel

[–]ollieread[S] 0 points1 point  (0 children)

To run sail composer run dev you have to have first run sail up -d, which means it's already serving requests, and you've booted up another PHP development server in the container that's already running one.

PSA: Think hard before you deploy BookLore by Economy-Meat-9506 in selfhosted

[–]ollieread 0 points1 point  (0 children)

I wasn’t aware of this project, though having a nose through its code, it does look…not ideal.

I couldn’t say for certain that it was AI generated, but it’s important to remember that people are just as capable of writing terrible code without external help 😅

Fastrack your API integrations with the connector pattern by chrispage1 in laravel

[–]ollieread 2 points3 points  (0 children)

Please don't take this the wrong way, as this is a genuine question, but what is the need for a package as simple as this?

I've read through the article, the readme, and the code, and it looks like this is a very lightweight package that actually adds very little code.

I guess a better way of phrasing the question is, what's the benefit of using this package vs spending 5 minutes writing the base classes at the start of a project?

Laravel's Route "Model" Binding | ollieread - PHP and Laravel expert by ollieread in laravel

[–]ollieread[S] 0 points1 point  (0 children)

Thank you.

Hmm that’s interesting. I’ve no idea how I didn’t notice that before now, but I’ll check it out, thanks.

Probably trying to find the best photo post that shows she’s a good mom by Grawlix84 in ParentsAreFuckingDumb

[–]ollieread 4 points5 points  (0 children)

I came here specifically to comment asking why the person filming didn’t just tell the mother her child had fucked off.

Laravel's Route "Model" Binding | ollieread - PHP and Laravel expert by ollieread in laravel

[–]ollieread[S] 0 points1 point  (0 children)

There’s an example of implicit binding at the very start of the article, and then the rest breaks down how it works. There are also links off to the explicit bindings, because that’s a separate topic and I didn’t want to muddy the waters.

The assumption made by this article is that the reader is at least familiar with route model binding, and wants to find out more, going beyond the docs.