Freek.dev

Jeff Madsen wrote down a good piece that explains how mutable Carbon dates can lead to some nasty bugs. I would't mind if Chronos were to be promoted to the default datetime library in Laravel.

If you hang out on any sort of programming forums you have no doubt encountered “The Great Mutable vs. Immutable Debate”. While I’m sure you know what the words mean, if you are new to programming or don’t have a strong Computer Science background it might not be obvious to you whether this is an important concept to be concerned with, or just more “architecture astronaut” purists arguing some obscure fine point.

To help you answer that for yourselves, I’m going to show you the difference between the two using two popular Php DateTime libraries — Carbon and Chronos, and then demonstrate the danger of using the mutable one of those.

https://medium.com/@codebyjeff/whats-all-this-immutable-date-stuff-anyway-72d4130af8ce

If you want to read more cool articles by Jeff, be sure to subscribe to his excellent newsletter.

Read more

In my day to day work I don't write any css at all, but I still very much enjoyed this blogpost by Adam Wathan where he shares some interesting things about how css should be structured and he makes the case for using utility classes to make visual tweaks.

When you think about the relationship between HTML and CSS in terms of "separation of concerns", it's very black and white.

You either have separation of concerns (good!), or you don't (bad!). This is not the right way to think about HTML and CSS. Instead, think about dependency direction.

...

One of the biggest benefits of using small, composable utilities is that every developer on your team is always choosing values from a fixed set of options.

https://adamwathan.me/css-utility-classes-and-separation-of-concerns/

Read more

Ross Tuck is probably one of my favourite bloggers. He doesn't publish something often (his previous post is from 2015), but when he does it's very much worth your time.

The important takeaway here isn’t “value objects, yay, inline juggling, boo!” It’s that we were able to remove several classes of errors by reducing the precision of the DateTime we were handling. If we hadn’t done that, the value object would still be handling all of these edges cases and probably failing at some of them too.

Reducing the quality of data to get a correct answer might seem counter-intuitive but it’s actually a more realistic view of the system we’re trying to model. Our computers might run in picoseconds but our business (probably) doesn’t. Plus, the computer is probably lying anyways.

http://rosstuck.com/precision-through-imprecision-improving-time-objects

Read more

Grégoire Paris wrote down his opinion on why he dislikes Yoda conditions.

So how do Yoda conditions work? Well it is basically a knee-jerk reaction you have to develop: whenever you write a condition, put the operand that cannot be assigned on the left. This should give you an error message if you make an assignment when you actually meant to make a comparison.

https://dev.to/greg0ire/why-using-yoda-conditions-you-should-probably-not

Personally, I'm not a big fan of Yoda conditions either. My feeling is the the cost of decreased readability is just too high for the small value that Yoda conditions bring to the table.

Read more

?Combining query scopes with explicit model names will help keep code cleaner and easier to understand #laravel pic.twitter.com/ixzDdrZcRT

— Chris Gmyr (@cmgmyr) July 12, 2017

Read more

David Négrier, CTO of the CodingMachine, wrote a nice article on why he likes and how his team uses typehints.

As a developer consuming this function, I know how to use it. And if I’m using it wrong, I’ll know right away because PHP will crash with a nice error message when the function is called rather than with a cryptic error some time later.

https://www.thecodingmachine.com/type-hint-all-the-things/

Personally I like typehints too, because the potential readability improvement the article touches upon.

Note: (I only include this paragraph because it's mentioned in the intro of the article, don't want to stir up a discussion) the fuzz about that "Visual Debt" video was overblown. Even though I didn't agree with all of it, it was nice to hear Jeffrey's way of thinking.

Read more

Brent Roose wrote down his thoughts around how things like fonts, spacing, docblock, ... can influence the cognitive load of a programmer.

As a professional programmer, I'm reading and writing code on a daily basis. I'm working on new projects, doing code reviews, working with legacy code, learning documentation etc. Based on my own experience and that of colleagues, being a programmer often involves a lot more reading than actually writing code. Whether it's your own code or that of others, when you open a file, you have to take it all in. You need to wrap your head around what's going on, before you're able to write your code. Doing this day by day, it's important to find ways to make this process easy. To try and reduce this cognitive load as much as possible. Streamlining the way you take in code, will allow you to not only work faster and better; but also improve your mental state and mood.

https://www.stitcher.io/blog/a-programmers-cognitive-load

Visual debt is real.

Read more

? Go crazy with Blade directives. The simplest things can abstract away tons of visual noise from your templates. pic.twitter.com/p5udGWJkhd

— David Hemphill (@davidhemphill) June 22, 2017

Read more [twitter.com]

Mattieu Napoli shows how you can use non breaking spaces to make long test function names more readable.

Yes. This article is about using non-breakable spaces to name tests. And the fact that it’s awesome. And why you should use them too.

public function test a user can add a product to a wishlist() { // ... }

The code above is valid PHP code and works. Non-breaking spaces (aka   in HTML) look like spaces in editors but are actually interpreted like any other character by PHP.

http://mnapoli.fr/using-non-breakable-spaces-in-test-method-names/

It's cool that it works, but I'm not really a fan of this. I very much prefer how test runners like jest go about this by passing the name of the test to a function so you can use spaces.

Read more

In a new post on his blog, my favorite stalwart of the industry Frederick Vanbrabant, gives a explanation on why some projects turn into a big mess and how you can avoid it.

I truly believe that the broken window theory can be applied to software projects. In my personal experiences I’ve rarely seen a project start out as a total mess. If it ended up as a mess, it was gradually. I also believe that this is not necessary the fault of developers working on the project, think of it more as frogs in a pot with gradually increased temperature of water. One morning you just wake up and take a look at the project and realise that it has gotten really messy.

http://frederickvanbrabant.com/2017/06/12/broken-windows-theory.html

Read more

In a new blogpost on vemv.net the author (I couldn't find his real name) argues against using a simple status field.

Dear programmer, do you ever use the name state for your variables? Like state = 42? “Hell no, that’s a terribly generic word. Better to use the domain-specific wording the variable refers to: is_invoiced, visit_count, shopping_cart, things like that.”

Sounds reasonable. But sometimes, you have a database column called status, and use it through your codebase, right? “Yes.”

Were you aware that status and state mean basically the same thing in English? “Uhm…”

https://blog.vemv.net/the-status-antipattern-479c26c7ddf7

Read more

In this article Kent C. Dodds clearly explains what the downsides are of using Class in JavaScript.

Classes (and prototypes) have their place in JavaScript. But they’re an optimization. They don’t make your code simpler, they make it more complex. It’s better to narrow your focus on things that are not only simple to learn but simple to understand: functions and objects.

https://medium.com/@kentcdodds/classes-complexity-and-functional-programming-a8dd86903747

Read more

On the Tighten co blog Caleb Porzio wrote a small post on how you can boot your model traits. It's a very handy feature that's being used a quite a few Spatie packages.

TL;DR Use bootNameOfTrait() instead of boot() in a model trait to avoid being overwritten by the base model’s boot() method.

https://blog.tighten.co/laravel-tip-bootable-model-traits

Read more

This a video of a great lecture Bob Martin gave a couple of years ago. Even if you know the solid principles it's great to hear him talk about the origin of Objective C, what makes object orientation (not) special and so much more.

Read more

On the stitcher.io blog a new post appeared that explains the benefits of generics with a practical example. Generics aren't supported in PHP, but there is an RFC.

In today's blog post we'll explore some common problems with arrays in PHP. All the problems and issues listed could be solved with a pending RFC which adds generics to PHP. We won't explore in too much detail what generics are. But at the end of this read you should have a good idea as to why they are useful, and why we really want them in PHP. So without further ado, lets dive into the subject.

https://www.stitcher.io/blog/php-generics-and-why-we-need-them

Read more

Michael Dyrynda, co-host of both the excellent North Meets South podcast and Laravel News podcast, wrote a short article on how he pragmatically manages forms in a Laravel app.

I personally feel that I'm not gaining anything by bringing in another package just to handle generating HTML on my behalf when it's just as fast to use the tools available to me in my editor. It also means there's no implied knowledge of a now non-standard external package, should a new developer be brought on to the projects that I've worked on. HTML is HTML, after all.

https://dyrynda.com.au/blog/elegant-form-handling-in-laravel

Read more

Ivan Sieder offers a nice tip on how to write better v-for loops in VueJS component templates.

There is really nothing wrong with the above code, but there is a small aspect, which really bugs me. As you can see, we are repeating the product identifier inside the output twice ({{ product.name }} and {{ product.price }}).

We are modern web developers (at least I hope so) and therefore we are going to use modern ES6 functionality. The feature we are going to use is called destructuring assignment. Basically, what the destructuring assignment allows us to do, is to pull a specific property off of an object and store it in a variable.

https://simedia.tech/blog/vue-js-destructuring-assignment-for-loops/

Read more

Matthias Noback explains the value of singleton objects: when used properly they can make your code more developer friendly.

I'm not advocating the use of façades and helper functions per se. I assume they may have good use in specific parts of your application (just as the Laravel documentation states, by the way). My point is that, as long as you build into your libraries both options, you can offer a great developer experience, providing an out-of-the-box working solution of a useful service, which can still be used in a project that uses dependency injection everywhere.

https://php-and-symfony.matthiasnoback.nl/2017/05/the-case-for-singleton-objects-facades-and-helper-functions/

Read more