alexandersix

alexandersix

Owner at Code & Tailor

Member Since 4 Years Ago

Columbia, SC

Experience Points
19,290
Total
Experience

710 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
178
Lessons
Completed
Best Reply Awards
1
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.

Level 4
19,290 XP
Aug
30
1 month ago
Activity icon

Replied to Catching Cashier Errors

This may be a ridiculous answer, but it’s come back to bite me a few times—did you import your Exception class in this file? If not, you may be trying to catch an Exception that Laravel doesn’t know about at this point in the code.

If you haven’t imported it, I think the quick fix would be to change Exception to \Exception!

Let me know if that does the trick, or if I’m completely off-base!

Aug
23
2 months ago
Activity icon

Commented on Flash Component

Using Blade's includes is still a very viable option within Laravel's ecosystem, just like @jeffreyway was saying during the first video in this series! However, these Blade components are also an extremely viable option for building out front-end templates; really it just comes down to preference.

I, for one, use a combination of both. I tend to find that using Blade includes for my overarching page templates makes more sense in my mind than using Blade components, but, for me, using Blade components to build out the internals of my pages is much more readable because they flow nicely into the HTML.

Again, these Blade components aren't meant to be the new way to make Blade files, they're just another way of looking at the same sorts of concepts. They also make the Blade ecosystem much easier to dive into if you're coming from a JS front-end framework ecosystem, since frameworks like Vue and React rely so heavily on components to build out their pages.

TL;DR -- Blade includes are still viable, Blade components are newly viable, and both have serious benefits and significant uses, depending on the individual who is utilizing them. Viability of features isn't determined by the personal experiences of a single individual, but by how the new features achieve the goal set out by their creator.

Aug
21
2 months ago
Activity icon

Replied to Queue Worker Not Working AWS Elastic Beanstalk

Alright @simonl, let's look into a few other things.

First and foremost, what version of Laravel are you using? That might help us narrow down any potential issues!

Ok, so the fact that your app is storing jobs in the jobs table makes me think that your configuration variables are correct (which is good!), but brings up a few other potential issues:

Firstly, is your site in maintenance mode? If I remember correctly, queues don't process jobs while the app is in maintenance mode.

Also, have you checked your job(s) to make sure that there aren't any errors that are showing up when the code is run on the server? If a job errors out, it will remain in the database table, which makes it seem as though the queue isn't running.

Since your app is working locally but not on the server, there are a few things that I immediately would want to check regarding potential points where your jobs could be failing:

  • Are you running the same version of PHP and MySQL on your local instance and the EC2 instance? Sometimes, certain things will work in your local version that doesn't work on the EC2's version, for example, class property types work with PHP 7.4, but not PHP 7.3).

  • Are your composer packages up to date on both your local machine and your EC2 instance? Again, sometimes packages can change their functionality from version to version, so if there have been a lot of updates between the version you're using locally and the version you're using on the EC2 instance, something could be getting called that doesn't exist in the EC2's version of the package.

  • Do you have the same PHP extensions installed on your local machine and on the EC2 instance? I know that, in the past, I've had to install specific PHP extensions for certain tasks (like rendering out a PDF) that aren't required for running Laravel by default. Usually what happens is that I forget to install the same extension on the EC2 instance, so I get an error on the instance that I haven't gotten before on my local because I've never tried to run the code without the PHP extension installed.

While you're checking the above items, something simple that I always forget to do is checking that your storage and bootstrap/cache have the correct permissions. If they don't, you could be getting errors, but Laravel is unable to actually put them in the logfile because it doesn't have permission to open the file for writing. Check here for another Laracasts post if you need the specific commands to add the correct permissions to those directories.

Try those things out and let me know if any of them solved your problem!

Aug
20
2 months ago
Activity icon

Replied to Queue Worker Not Working AWS Elastic Beanstalk

Hi @simonl!

Without knowing more specifics or seeing any code, it’s a bit hard to come to a firm conclusion, but since you have something working locally that isn’t working the same on AWS, a few things come to mind:

  1. Have you checked to see if your .env file is correct on the Elastic Beanstalk instance? Maybe there are some bad values set there that would make your queue not work.

  2. Relating to #1, did you cache your config files and then proceed to make a change to an .env value that was referenced in those config files? If so, try re-caching your config files and see if that fixes something.

  3. Are you using the same queue driver on the Elastic Beanstalk instance as you are locally? And as a follow-up, are you using the drivers that you think you’re using on Elastic Beanstalk, according to your .env file?

  4. Have you checked your laravel logs to see if there are any system errors when trying to push a job onto your selected queue?

Just from reading your question, it really seems like there is some sort of interruption between your Laravel app and whatever is hosting your queue—almost like the app is pushing the job out, but somehow it’s not going to the right place. I’d start your sleuthing there, and if you want to come back with these answers and potentially some more insight into exactly what’s going on, I’d be happy to help debug further!

Best of luck!

Aug
19
2 months ago
Activity icon

Replied to Controller Per Page Or Controller Per Resource ?

Hi @ravish

I’ve had luck in the past using a slightly different convention than what you’re asking about to decide when I need to create a new controller. Originally, I used to follow the “controller-per-resource” convention like you mention in your question, and that got me really far. Things started to become problematic, though, when I started to need other methods on the controller that weren’t the typical CRUD methods that you’d get in a resource controller, because my controllers got bloated really quickly and it became really hard to determine what exactly each controller was responsible for.

I remedied the situation by following the advice of Adam Wathan (as someone earlier in the thread mentioned) and, instead of having a controller for each resource, I now use a controller for each thing that I want to access in my app. I use thing as my word of choice very intentionally, because, what can happen, is that I end up with a single resource that finds itself in multiple states or has multiple types.

For example, let’s use Property from your question. My recommendation here would be to use a single PropertyController with an index method for the page where users can list all the properties, and create, store, edit, and update methods to handle the pages/functionality for users creating and editing a given Property. Now, if you start to see yourself adding other methods that aren’t one of the basic CRUD methods, consider adding another controller—something like SoldPropertyController, or something similar, for example.

As far as restricting access goes, yes, you can always use a middleware for broad-strokes authorization (like the auth middleware that is bundled into Laravel), but I’ve also had a lot of luck using Policies and Gates to restrict access with a little more fine-grained control. Policies are especially good in this situation, if you follow my advice from above, because they are tightly bound to Laravel Controllers having CRUD methods inside of them. Using a Policy for your PropertyController, you can give public read access to everyone for listing Properties (index), but you can make sure that only the User who listed a Property can edit it (edit and update), for example.

That is the way that I’ve been building Laravel apps for a while, and it seems to work really well, even in the long-term when maintaining older applications normally starts to get difficult! Hopefully that helps!

Jul
04
3 months ago
Activity icon

Awarded Best Reply on Switching From CodeIgniter To Laravel

I'm definitely a little bit biased, but after having used both CodeIgniter and Laravel, I would definitely recommend giving Laravel a shot. Here are a few of the observations that I've made over the past few years about Laravel:

  1. It's possible to do just about anything in CodeIgniter, CakePHP, Wordpress, or any other PHP framework on the market--that's the beauty of code, I suppose. The major difference about Laravel is that it's not just possible to do just about anything with Laravel, it's straightforward and enjoyable. I know it's not a physical, measurable statistic, but writing code in Laravel just feels good.

  2. Laravel is easy to learn, but there's always something more to master or dive deeper on. I'm a big sucker for being able to pick up a framework or language quickly, and Laravel more than succeeds at that with the incredible community that surrounds it (I mean heck, Laracasts is a fantastic place to start). What's cool about Laravel is that there's a seemingly endless well of things to dive deeper on and learn more about. One example that comes to mind immediately is the Eloquent ORM that is packaged with Laravel. On the surface, Eloquent is a great way to quickly and easily get records from a database. But just recently, Johnathan Reinink released his Eloquent Performance Patterns course that does a deep-dive into creating ridiculously performant Eloquent queries. That's just one example, but there are tons out there.

  3. Laravel is continually evolving. The framework itself is constantly adding great new features (and reworks of standout features from past versions like the Blade rework in Laravel 7), but there is also a lot of awesome work being done by people in the community to add functionality to the Laravel environment. A few examples that come to mind are Livewire, Inertia.js, and Spatie's incredibly large list of Laravel packages.

TL;DR--do it! Give Laravel a go! I think you'll be pleasantly surprised with what you find!

Activity icon

Replied to Switching From CodeIgniter To Laravel

I'm definitely a little bit biased, but after having used both CodeIgniter and Laravel, I would definitely recommend giving Laravel a shot. Here are a few of the observations that I've made over the past few years about Laravel:

  1. It's possible to do just about anything in CodeIgniter, CakePHP, Wordpress, or any other PHP framework on the market--that's the beauty of code, I suppose. The major difference about Laravel is that it's not just possible to do just about anything with Laravel, it's straightforward and enjoyable. I know it's not a physical, measurable statistic, but writing code in Laravel just feels good.

  2. Laravel is easy to learn, but there's always something more to master or dive deeper on. I'm a big sucker for being able to pick up a framework or language quickly, and Laravel more than succeeds at that with the incredible community that surrounds it (I mean heck, Laracasts is a fantastic place to start). What's cool about Laravel is that there's a seemingly endless well of things to dive deeper on and learn more about. One example that comes to mind immediately is the Eloquent ORM that is packaged with Laravel. On the surface, Eloquent is a great way to quickly and easily get records from a database. But just recently, Johnathan Reinink released his Eloquent Performance Patterns course that does a deep-dive into creating ridiculously performant Eloquent queries. That's just one example, but there are tons out there.

  3. Laravel is continually evolving. The framework itself is constantly adding great new features (and reworks of standout features from past versions like the Blade rework in Laravel 7), but there is also a lot of awesome work being done by people in the community to add functionality to the Laravel environment. A few examples that come to mind are Livewire, Inertia.js, and Spatie's incredibly large list of Laravel packages.

TL;DR--do it! Give Laravel a go! I think you'll be pleasantly surprised with what you find!