The line is where ever you need it to be. Some situations will need you to dd a basic install and some pretty rudimentary programming, and that's fine. Other times you'll need to investigate all the way down to almost ever part of the server software stack that you're running in order to get to where you need to be. It's all up to he individual requirements of what you're working on.

The line is where ever you need it to be. Some situations will need you to dd a basic install and some pretty rudimentary programming, and that's fine. Other times you'll need to investigate all the way down to almost every part of the server software stack that you're running in order to get to where you need to be. It's all up to the individual requirements of what you're working on.

A few weeks ago Kicken said learn Laravel and understand it inside out. I am not sure if he ment go Otwell level or CRUD level.

Here is what I mean:

The way I see it, from a commercial point of view it all goes down to simple (but secure) CRUD.

I might be wrong but that's what I think.

Right now I'm making a living with a simple website with multiple funnels I've coded with Codeigniter and Stripe API.

I catch the traffic from ***, send to the opt-in pages, with API put them in email sequencers (Infusionsoft etc etc), add them to my own db and do evergreen product launches hard-core sales to the list every day.

I am probably using 3% of the power of PHP (if...).

Now I want to go for this job offers that they require Laravel I got in Sanfran and NY and they require Laravel.

I'm spending a couple hours a day learning Laravel and in a few months, I will be able to easily write quality code with Laravel to run membership site, do API etc

HOWEVER

Learning and understanding the phuck going on in the background inside laravel is another animal.

This:

PHP Code:

$users = DB::table('users')
->offset(10)
->limit(5)
->get();

I know what it does, I know what it is, I understand the chaining, I know the sql behind it but getting my head around OOP the way Otwell does is way out of my iq.

So I assume I can get the job done but writing a framework is not something I can do.

A few weeks ago Kicken said learn Laravel and understand it inside out. I am not sure if he ment go Otwell level or CRUD level.

I don't recall saying to learn something inside and out. I assume you're referring to my post in your how long to learn laravel thread, which maybe was misunderstood.

My general recommendation with something large like Laravel and Symfony is you learn it as deep as you think you need to. If you just want to use it to develop apps, generally that doesn't require you to get into the gritty details of how the framework is implemented. Instead, you'd focus on things like where and how to hook in your code, higher-level configuration details, higher level API detail, etc.

So for example, knowing that getting a paginated list of users can be done using the code

Code:

$users = DB::table('users')->offset(10)->limit(5)->get();

is probably sufficient, you don't need to know how that ends up getting transformed into the proper query and executed to do what you want to do.

As I mentioned in the other post, when I started with Symfony it took a good 6 months or so for me to get pretty comfortable with it. I wasn't working on it 100% of that time though, I was still working on other projects at the same time. Had I focused exclusivly on symfony I probably could have gotten comfortable with it much sooner. What I define as comfortable is that I felt as though I knew enough that I could

1) Get a new symfony project going quickly and do things like configure services, create CRUD forms, manage authentication, deal with templates, etc mostly from memory (or knew exactly where to look in the manual for a refresher)
2) Take about any well-designed symfony project and tinker with it because I know how it should be structured and where I should be able to find code if needed.

Overall, those goals don't require learning the framework at that deep of a level. It's just the higher level stuff like:
- What kind of configuration exists / where is it located?
- What kind of code structure is expected / where should I put my code?
- How does database interaction work?
- How does authenticate work?
- How does templating work / where do I put my templates?

The struggle for someone like me that is used to doing everything from scratch is learning to let the framework handle things and focus on the bigger picture rather than implementation details. For example switching over to using Doctrine's ORM features rather than manual database queries was a bit of a struggle because often I knew exactly what I wanted to do in terms of SQL code but had trouble translating that into Doctrine's ORM API. Sometimes I'd give up too quickly on such tasks and just run a query directly. It took some time of forcing myself to try and deal with doctrine before I figured out how to do things "the right way", which sometimes is running queries directly, the key is knowing when that is.

To this day there's still a lot about symfony and doctrine that I really don't know how it works, I just know how to deal with those components and that's good enough for 99% of tasks. For example Symfony's firewall/authencation system from what I've seen when doing debugging is pretty involved and complex. I've no idea how it works internally, but I know how to interact with it in a way that lets me restrict access to pages and know when someone logs in.

When I was learning laravel, I did so by building a simple shopping website. If I were to just give you a .zip file of all the code and a sample database and requested that you make a change to the layout, or fix a bug like the quantity not being validated as >= 1 do yo think you could do that in a day? If not, you probably have some more to learn. Otherwise you probably know enough to function in job doing laravel work and could learn more in-depth details as you go.

If you're applying for a laravel job, thinking up and/or looking for potential interview questions and learning enough to compentatly answer them would probably be a good starting point.