Hey, I’ve came over from Reddit and thought I’ll introduce myself as well. As every programmer, I’ve started way too many pet projects and almost all of them are starving. In terms of framework, I prefer Yii2 over Laravel every day. I feel like Laravel provides you a dozen different (seemingly equally good) ways of doing something. You could say it’s lacking clarity or guidance for the developer.
Hey, welcome! Classic haha, I have far too many pet projects as well 😅
And yeah agreed, it’s a bit dizzying to choose a Laravel “path”. Would probably be helpful to have a documentation page sort of like the Remix Stacks where they talk a little bit about which “path” to choose depending on app needs.
Docs is another topic I really don’t like about Laravel. Why don’t you have a simple API doc with available functions and their parameters instead of that blog-style documentation. And no, I don’t want to watch a video about how to use X, I want to know what functions I can call. Oh and don’t get me started on all their global “helper” functions.
Mainly because you’ve got to setup PHP to be debuggable in the first place.
And setting up PHP is already a hassle. When a dev has to set up php in about 5 separate ways just to figure out which one is actually debuggable, then PHP has a problem.
Final keywords–like locks on a door–are just a suggestion. If someone wants to light a stick of dynamite and play hot potato with it, that’s their own problem. As long as they aren’t wasting upstream dev’s time or publishing packages that depend on this to work, it’s not worth getting upset about.
Just because one person said “final is bad”, the Laravel fanboy herd is flocking to solutions like this. In my opinion, the package per se is not bad, but the unreflected, absolute statement “final is bad” is the problem.
In my opinion, the package itself is bad. It suggests by its very existence that final is bad. It tempts to use dependencies in a way that was not intended by their developers.
This. Can people please stop posting medium articles?
Medium goes against basically everything Lemmy/etc stands for. It’s also just a shitty experience, for example code is rendered in a large font and cropped a 650 pixels without any wrapping. Yuck.
If I remember correctly people said Medium is very limiting and confusing when it comes to ownership of your content.
It seems they can re-use (as in publish) your original content elsewhere, like publishing it in a book.
What I especially dislike is the registration enforcement (register! Use our App! Become a member!).
There are some sources in my feedreader from Medium and they become less and less usable.
Something I stumble upon more often recently is Substack. Actually intended to be a tool for offering paid content and a newsletter publishing tool, I think, but the user experience is much more pleasant. They ask me to subscribe to the publisher’s newsletter each time, but don’t prevent me from going further, if I decline.
Also getting some attention recently is the indieweb movement. People intentionally publish on their private websites, running on various different platforms and techniques. It’s quite interesting to observe and it seems there is a focus on a more tech-savvy audience and publisher group, but I might be wrong.
In the given example they don’t make much sense but I assume they’ve done that in case they want them to be extended with new behaviour for certain ones separate from their strategy pattern section in the future
Yeah I assume the same, but I’d really like to see a concrete example of that being done instead of having to guess (as someone who has never used the Strategy Design Pattern).
I recommend going further than this example and don’t just store the value/currency for your price. You should also store the VAT. And generally anything else that involves division or percentages.
Jump through whatever hoops are necessary to work exclusively with addition and subtraction (and the occasional cheeky multiplication to shortcut repeated addition operations). Percentages and division is where people tend to get into trouble.
Specifically you should avoid the last line of code in this example from the article OP posted:
I’m not sure what they were trying to get at with that example, so here’s a more realistic example where of avoiding percentages:
<span style="color:#323232;">class Product {
</span><span style="color:#323232;"> /**
</span><span style="color:#323232;"> * The price of the product excluding tax. Entered by the user into the database.
</span><span style="color:#323232;"> */
</span><span style="color:#323232;"> public Money $price;
</span><span style="color:#323232;">
</span><span style="color:#323232;"> /**
</span><span style="color:#323232;"> * The amount of VAT to collect for this product. Not entered by the user, but calculated
</span><span style="color:#323232;"> * whenever the product price changes (or, whenever the tax legislation changes). The
</span><span style="color:#323232;"> * value is stored in the database as an integer (and currency).
</span><span style="color:#323232;"> */
</span><span style="color:#323232;"> public Money $vat;
</span><span style="color:#323232;">}
</span><span style="color:#323232;">
</span><span style="color:#323232;">class CartItem {
</span><span style="color:#323232;"> public Product $product;
</span><span style="color:#323232;"> public int $qty;
</span><span style="color:#323232;">}
</span><span style="color:#323232;">
</span><span style="color:#323232;">
</span><span style="color:#323232;">$invoiceTotal = new Money(0);
</span><span style="color:#323232;">$invoiceVat = new Money(0);
</span><span style="color:#323232;">$paymentAmount = new Money(0);
</span><span style="color:#323232;">
</span><span style="color:#323232;">foreach ($cartItem in $cart) {
</span><span style="color:#323232;"> $invoiceTotal
</span><span style="color:#323232;"> ->add($cartItem->product->price)
</span><span style="color:#323232;"> ->multiply($cartItem->qty);
</span><span style="color:#323232;">
</span><span style="color:#323232;"> $invoiceVat
</span><span style="color:#323232;"> ->add($cartItem->product->vat)
</span><span style="color:#323232;"> ->multiply($cartItem->qty);
</span><span style="color:#323232;">
</span><span style="color:#323232;"> $paymentAmount
</span><span style="color:#323232;"> ->add($cartItem->product->price)
</span><span style="color:#323232;"> ->add($cartItem->product->vat)
</span><span style="color:#323232;"> ->multiply($cartItem->qty);
</span><span style="color:#323232;">}
</span>
Avoiding division should also be done everywhere else - for example if your credit card facility charges 30c + 2.9%… don’t fall for the trap of calculating 2.9% of $paymentAmount because chances are you’ll round something in the wrong direction. Also, some cards have higher fees. Instead, when you authorise the payment the credit card facility should tell you that the card fee for that actual transaction is 152 cents. Record that number in your payment record and use it for your own internal reporting on profits/etc.
No Data Checking: It directly uses data from an API without checking if it’s safe or correct.
Dynamic Properties: Adding properties to an object on the fly can make the code hard to manage.
External Data Dependency: Relying on API data structure without checks can lead to issues if the API changes.
If you don’t know the data is safe (it’s not), it’s a lot better to use an associative array. Additionally, if it’s from a json, it’s quicker and easier to iterate over array. Don’t make it complicated for no reason.
php
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.