Freek.dev

Some solid advice for when you're building a product.

Build a product with the help of a hacker. Design it for the benefiter. Sell it to an expert.

Read more [uxdesign.cc]

In a new post David Hemphill argues that you sure can (re)build something that already exists. I fully agree.

Some folks ask this rhetorically, implying there's no good reason when something similar already exists. They ask this question with a smug grin and think they've got you.

Read more [davidhemphill.com]

Mohammed Said wrote some thoughts on FOMO that resonate with me.

It's a constant pressure on me, and I can imagine how hard it can be on people newly joining the career. In my early days it wasn't that bad, things weren't moving that fast, but nowadays it's crazy.

Read more [themsaid.com]

Daniel Elkington comments on the reactions to an important RFC that adds function-based components to Vue.

Today I was amazed to see the usually positive and friendly VueJS community descend into a bitter war. Two weeks ago Vue creator Evan You released a Request for Comment (RFC) for a new function-based way of writing Vue components in the upcoming Vue 3.0. Today a critical Reddit thread followed by similarly critical comments in a Hacker News thread caused a flood of developers to flock to the original RFC to voice their outrage, some of which were borderline abusive

Read more [dev.to]

My colleague Seb gives some good reasons why he personally likes working with React over Vue.

Vue is the default JavaScript framework for Laravel apps. Being part of the Laravel community, I often get the question why I prefer React, so I've decided to write down a few standout reasons.

Read more [sebastiandedeyne.com]

A short and sweet article by my colleague Seb.

I was always adding features because I’d expect other people to expect them. It’s a trap! You’re not making people happier by guessing what they might need. You’re not doing anyone a disservice by building things for yourself.

Read more [sebastiandedeyne.com]

React lead dev Dan Abramov makes the case for naming your ideas and projects.

The problem it’s solving might be so ingrained that we don’t even notice it. It’s the elephant in the room. And we can’t discuss what we never named.

Read more [overreacted.io]

I fully agree with Troy Hunt here.

So in summary, everyone clicks through cookie warnings anyway, if you read them you either can't understand what they're saying or the configuration of privacy settings is a nightmare, depending on where you are in the world you either don't get privacy or you don't get UX hell, if you understand the privacy risks then it's easy to open links incognito or use an ad blocker, you can still be tracked anyway and finally, the whole thing is just conditioning people to make bad security choices.

Read more [www.troyhunt.com]

How to do PHP... Mission Impossible style. ? pic.twitter.com/KpJRqRmuyq

— SammyK, (@SammyK) February 12, 2019

Read more [twitter.com]

Some solid advice from Adel Faiz: do not use a package for authorization unless you really need its functionalities. Laravel's default authorization capabilities are good enough for most use cases.

I don't want to say these packages are useless. They can be useful for projects which needs complicated authorization system, which should be customizable by customer later. Also some projects need dynamic permissions. For all other projects it's too heavy solution. Better to use simple code-based authorization.

Read more [adelf.pro]

Every friend I have with a job that involves picking up something heavier than a laptop more than twice a week eventually finds a way to slip something like this into conversation: “Bro,1 you don’t work hard. I just worked a 4700-hour week digging a tunnel under Mordor with a screwdriver.” They have a point. Mordor sucks, and it’s certainly more physically taxing to dig a tunnel than poke at a keyboard unless you’re an ant. But, for the sake of the argument, can we agree that stress and insanity are bad things? Awesome. Welcome to programming.

Read more [www.stilldrinking.org]

On the PHP internals mailing list Zeev Suraski, a long time core contributor of PHP, started a discussion on what PHP 8 could look like.

As I mentioned a few days ago I intended to send it slightly later - but as Nikita brought up the topic of PHP 8, this is probably as good a time as any to start the discussion. Please note: The goal of this email isn't to discuss in detail each and every topic that's mentioned, but rather to establish whether we want to move to focus on PHP 8 as we go beyond PHP 7.3, based on some of the research projects and PoCs we've been working on.

Read more [externals.io]

On his blog [Hidde De Vries] recaps a talk by Sir Tim Berners-Lee, the inventor of the web, on redecentralising the web.

However, if we’re not careful, Berners-Lee warned, there can also be a vicious circle, a dystopian scenario. This happens when algorithms cause people to meet more people like themselves, narrows down their circle and alienates them from people who are different. Or when websites are used to harvest people’s personal data that are then used for political gain.

Read more [hiddedevries.nl]

My colleague Brent shares some interesting thoughts on which direction PHP could go forward.

Let's take, for example, the debate about strong types in PHP. A lot of people, including myself, would like a better type system. Strong types in PHP would definitely have an impact on my daily work. Not just strong types, I also want generics, better variance and variable types. Improvements to PHP's type system in general would have quite the impact on my programming life. So what's stopping us from reaching a solution?

https://www.stitcher.io/blog/what-php-can-be

Read more

Here's a video of an excellent talk by Chris Hartjens he recently gave at NomadPHP. Don't have time to watch and prefer to read a summary? This blogpost by Michael Heap has got you covered: https://michaelheap.com/how-to-ruin-a-career-in-10-easy-minutes/

Read more

My colleague Brent has some good thoughts on where to place curly brackets.

Dedicating a whole blogpost to curly brackets might seem like overkill but I believe it's worth thinking about them. Not just because of one curly bracket, but because there's a bigger message in all this. Thinking about how we read and write code not only improves the quality of that code, it also increases our own and others ease of mind when working with it. It can improve the fluency of your work and free your mind to think about real important stuff.

https://www.stitcher.io/blog/where-a-curly-bracket-belongs

Read more

Colin DeCarlo, a developer at Vehikl, wrote some thoughts on why PHP has a bad reputation in some circles.

People shitting on PHP isn’t going to go away, it’s a symptom of a few things. PHP has a ridiculously flat learning curve so just about anyone can write code using it, this means a lot of amateurs and ‘get it done’ developers will choose php but won’t really ever level up their skills when it comes to software development.

https://medium.com/@colindecarlo/who-uses-php-anyway-672115ab81de

I agree with Colin on everything he writes in his post. I'm also thinking that the some of the reasons on why people don't like PHP apply to Laravel as well. In my mind Laravel is to PHP frameworks what PHP is to other programming languages. Both Laravel and PHP might not do everything by the "real programming rules", but it sure is easy to use. And when handled properly powerful and maintainable stuff can be built with it.

Because Laravel is an easy framework to get started with, it's a popular choice for newcomers. Even with almost no experience you can build an app. Some of those projects will go to production. If an experienced developer that uses another framework comes by and sees that Laravel app, it might be easy to conclude that the problem lies with Laravel, and not with the inexperience of the junior programmer who just begon his/her journey in coding.

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

DHH explains that there's nothing wrong with a bit a magic.

It’s always better to be explicit! That’s pretty much a programming truism. Rarely directly challenged, lest one betray the foundational tenors of Proper Programming. But challenge it we should, and head on.

https://m.signalvnoise.com/programming-with-a-love-of-the-implicit-66629bb81ee7

Read more