longestdrive

Member Since 7 Years Ago

Experience Points
11,755
Total
Experience

3,245 experience to go until the next level!

In case you were wondering, you earn Laracasts experience when you:

  • Complete a lesson — 100pts
  • Create a forum thread — 50pts
  • Reply to a thread — 10pts
  • Leave a reply that is liked — 50pts
  • Receive a "Best Reply" award — 500pts
Lessons Completed
84
Lessons
Completed
Best Reply Awards
0
Best Reply
Awards
  • start your engines Created with Sketch.

    Start Your Engines

    Earned once you have completed your first Laracasts lesson.

  • first-thousand Created with Sketch.

    First Thousand

    Earned once you have earned your first 1000 experience points.

  • 1-year Created with Sketch.

    One Year Member

    Earned when you have been with Laracasts for 1 year.

  • 2-years Created with Sketch.

    Two Year Member

    Earned when you have been with Laracasts for 2 years.

  • 3-years Created with Sketch.

    Three Year Member

    Earned when you have been with Laracasts for 3 years.

  • 4-years Created with Sketch.

    Four Year Member

    Earned when you have been with Laracasts for 4 years.

  • 5-years Created with Sketch.

    Five Year Member

    Earned when you have been with Laracasts for 5 years.

  • school-in-session Created with Sketch.

    School In Session

    Earned when at least one Laracasts series has been fully completed.

  • welcome-newcomer Created with Sketch.

    Welcome To The Community

    Earned after your first post on the Laracasts forum.

  • full-time-student Created with Sketch.

    Full Time Learner

    Earned once 100 Laracasts lessons have been completed.

  • pay-it-forward Created with Sketch.

    Pay It Forward

    Earned once you receive your first "Best Reply" award on the Laracasts forum.

  • subscriber Created with Sketch.

    Subscriber

    Earned if you are a paying Laracasts subscriber.

  • lifer Created with Sketch.

    Lifer

    Earned if you have a lifetime subscription to Laracasts.

  • evangelist Created with Sketch.

    Laracasts Evangelist

    Earned if you share a link to Laracasts on social media. Please email [email protected] with your username and post URL to be awarded this badge.

  • chatty-cathy Created with Sketch.

    Chatty Cathy

    Earned once you have achieved 500 forum replies.

  • lara-veteran Created with Sketch.

    Laracasts Veteran

    Earned once your experience points passes 100,000.

  • 10k-strong Created with Sketch.

    Ten Thousand Strong

    Earned once your experience points hits 10,000.

  • lara-master Created with Sketch.

    Laracasts Master

    Earned once 1000 Laracasts lessons have been completed.

  • laracasts-tutor Created with Sketch.

    Laracasts Tutor

    Earned once your "Best Reply" award count is 100 or more.

  • laracasts-sensei Created with Sketch.

    Laracasts Sensei

    Earned once your experience points passes 1 million.

  • top-50 Created with Sketch.

    Top 50

    Earned once your experience points ranks in the top 50 of all Laracasts users.

  • Community Pillar

    Earned once your experience points ranks in the top 10 of all Laracasts users.

Level 3
11,755 XP
Jan
14
2 months ago
Activity icon

Replied to Package Development And Relying On Other Packages

Thanks again - I'm not familiar with that concept - some reading and learning to do!!

Jan
13
3 months ago
Activity icon

Replied to Package Development And Relying On Other Packages

Thanks Martin. I started down this path on the basis of trying to share the whole project between two sites, each with different branding and subtle differences.

The alternative was to have the entire project as a package or to make different branches in a repository to share the code.

At the moment I have two nearly identical repositories, I update one then later on update the other one which i don't think is the easiest way of doing this, hence the package route.

Maybe I'm overthinking?

Activity icon

Started a new Conversation Package Development And Relying On Other Packages

Hi

I'm trying to break an app I've made into modules by breaking it up into packages. I'm hoping this will make it easier to maintain the functionality and develop further - but getting confused in a couple of areas. I'm new to developing as a package and currently focussing on one piece, effectively copying and pasting existing code into the package folder and trying to get it to work. I'm using jeroen-g/laravel-packager to help with development which includes Orchestra Testbench

For now, my app until now has used the 'spatie/laravel-permissions' package to protect functionality and routes etc.

I'm now trying to test a controller in the package based on a test I had in my original whole project and working through the test failures which is mainly around setting up the test environment.

My latest error is that a config/permissions.php is not loaded. So a reliance on having that package set up properly in my package - which is where I'm starting to feel I'm doing this wrong.

I can't see a way of publishing a dependant packages config file from within the package development - equally not sure I should as this has potential to add a conflict or lack of flexibility in the final project that relies on my package.

My question then is where a package includes views and functionality that need protection through roles, should I rely on the final project to worry about that or should I use this package as I am at the moment but how do I configure for the development environment?

What's the best practice of bringing in other packages into a package to add functionality - is this a bad practice?

Thanks

Jan
08
3 months ago
Activity icon

Replied to Understanding Approach To Reusing Existing App (git/env/config)

Hi

Hadn't thought of that one - In this case though I think I'll need to keep separate, it's not necessarily complex app but I have unique databases for each site (I could change connection based on environment I suppose).

[Appreciate I've not given much in terms of detail on the app]

I think in this case I want to keep the separation between the two

Thank you

Activity icon

Replied to Understanding Approach To Reusing Existing App (git/env/config)

I thought about that and wasn't too sure whether that was the right approach given 90% of the code for the entire site would be in a package leaving just the config files in the main app.

Will explore that further - maybe that's what I should do if nothing else to get me to organise my code better

Activity icon

Started a new Conversation Understanding Approach To Reusing Existing App (git/env/config)

Hi I have two sites which effectively use the same code base (99%). At the moment they are in separate repositories on Git and have developed independently of each other - often duplicating code and loads of copy and paste - which I appreciate is bonkers.

So, I'm trying to bring this into one repository that the two sites will then "share".

Each site though has unique features such as name, branding, third party services (twilio etc) and admin email addresses etc.

For the most part I can place the passwords etc in a .env file to keep them unique.

So a couple of questions:

  1. Is there a better approach for "sharing" the code base between two sites?
  2. Should branding etc be placed in a config file (that is not pushed to the repository) or are there other ways?

I've thought about developing the site into a package but it's quite extensive and I've not done any package development and due to my poor development ways breaking up into separate smaller packages might be difficult.

Any suggestions on how to approach and start to make my life easier?