Freek.dev

Here's another awesome blogpost by my collegue Seb. In this one he explains why you should and how you can create an explicit Vue component API.

When refactoring your UI to components, always keep in mind that props and events are your components public API. Just like when you're modelling your application's domain, try to keep things explicit. Props and events should be enough to tell the outside world everything it needs to know about a component's behavior.

Read more [sebastiandedeyne.com]

Here are some good reasons why you shouldn't use a first name and last name field.

The structure of a name is not the same across cultures. Users who visit your site will consist of a broad range of people from different countries. Your name field should be culturally inclusive so that no one struggles to fill out your form. With most things in life two is better than one. But when it comes to name fields one is better than two.

Read more [uxmovement.com]

Ross Tuck makes the case that not all code is equal.

Most teams follow the Broken Window Theory, fearing even a single tradeoff starts the slide down a slippery slope. This can reduce discussion (read: dissension) in the short term but leads to arbitrary compliance or worse. ... Deciding on a level of quality isn’t like deciding on a coding standard, you can’t have an off-the-shelf-always-okay answer. Quality is the place to have nuanced discussions.

Read more [rosstuck.com]

In another cool blogpost, Matthias Noback explains a few best practices around newing up objects, illustrated with some great examples.

Consider the following rule: "When you create an object, it should be complete, consistent and valid in one go." It is derived from the more general principle that it should not be possible for an object to exist in an inconsistent state. I think this is a very important rule, one that will gradually lead everyone from the swamps of those dreaded "anemic" domain models. However, the question still remains: what does all of this mean?

Read more [matthiasnoback.nl]

Frederick Vanbrabant recorded a new cool video, this time on EditorConfig.

EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable and they work nicely with version control systems.

Read more

Mattias Noback shares how you can migrate a code base that fetches its dependencies using static method calls to code that uses dependency injection.

I've worked with several code bases that were littered with calls to Zend_Registry::get(), sfContext::getInstance(), etc. to fetch a dependency when needed. I'm a little afraid to mention façades here, but they also belong in this list. The point of this article is not to bash a certain framework (they are all lovely), but to show how to get rid of these "centralized dependency managers" when you need to.

Read more [matthiasnoback.nl]

? Super simple clean-up, but the cause of so much "dead code". When using `return` statements within a `switch` block the `break` is unnecessary and is always unnecessary for the `default` case. pic.twitter.com/QxjFmiGcYy

— Jason McCreary (@gonedark) June 11, 2018

Read more [twitter.com]

Marina Posniak, UX writer at Spotify, shares some great tips on how to write error messages well.

To start, ask yourself if you even need the error message. Before writing anything, consider if there’s a way to redesign the experience so there’s no error at all. Is there a way to just make it work? (Really, the best error message is no error message.) But if you do need it, think carefully about the message. When things go wrong and the app “fails,” say something useful. The message should help the user solve the problem and move on.

Read more [thestyleofelements.org]

Rémi Collin shares a cool approach on where to place code that doesn't really belong in a controller. He creates small, reusable, testable, decoratable classes, called Actions.

Using this approach can seems a lot of classes at first. And, of course the user registration is a simple example aimed to keep the reading short and clear. Real value starts to become clear once the complexity starts growing, because you know your code is in one place, and the boundaries are clearly defined.

Read more [medium.com]

In a new video Jason McCreary, the creator of the wonderful Laravel Shift, demonstrates a few good tips to clean up code. In the video below Jason uses a code snippet taken from my side project Oh Dear!

If you're interested in more tips from Jason be sure to check out his upcoming BaseCode field guide.

Meanwhile I've cleaned up (and deployed) the code in the actual app. This is what I ended up with:

class Check
{
    public function needsToRun(): bool
    {
      if (!$this->belongsToTeamOnActiveSubscriptionOrOnGenericTrial()) {
          return false;
      }
			
      if ($this->disabled()) {
          return false;
      }
			
      if ($this->alreadyRunningOrScheduled()) {
          return false;
      }
			
      if ($this->didNotRunBefore()) {
          return true;
      }
			
      if ($this->checkType()->is(CheckType::UPTIME) && $this->latestRun()->failed()) {
          return true;
      }
			
      if ($this->previousRunCrashed()) {
          return true;
      }
      return $this->latestRun()->endedMoreThanMinutesAgo($this->checkType()->minutesBetweenRuns());
    }
		
    protected function checkType(): CheckType
    {
        return new CheckType($this->type);
    }  
}

use MyCLabs\Enum\Enum;

class CheckType extends Enum
{
    const UPTIME = 'uptime';
    const BROKEN_LINKS = 'broken_links';
    const MIXED_CONTENT = 'mixed_content';
    const CERTIFICATE_HEALTH = 'certificate_health';
    const CERTIFICATE_TRANSPARENCY = 'certificate_transparency';
    public function minutesBetweenRuns(): int
    {
        if ($this->getValue() === static::MIXED_CONTENT) {
            return 60 * 12;
        }
				
        if ($this->getValue() === static::BROKEN_LINKS) {
            return 60 * 12;
        }
				
        if ($this->getValue() === static::CERTIFICATE_HEALTH) {
            return 5;
        }
				
        if ($this->getValue() === static::UPTIME) {
            return 3;
        }
				
        throw new Exception("Minutes between runs not specified for type `{$this->getValue()}`");
    }
    public function is(string $type): bool
    {
        return $type === $this->getValue();
    }
}

Read more

John Bonaccorsi, a developer from Tighten, wrote some good ways of structuring model factories in a Laravel app.

Thanks to class-based model factories, our test setup went from being a bloated mess to simple and succinct. The optional fluent methods give us flexibility and make it obvious when we are intentionally changing our world. Should you read this blog post and immediately go and update all of your model factories to be class-based instead? Of course not! But if you begin to notice your tests feeling top heavy, class-based model factories may be the tool to reach for.

https://tighten.co/blog/tidy-up-your-tests-with-class-based-model-factories

Read more

Sebastian De Deyne, package creator and JavaScript wizard at Spatie, gives some good tips on how to report an issue well.

Maintaining a number of open source projects comes with a number of issues. Reporting a good issue will result in a more engaged approach from project maintainers. Don't forget: there's a human behind every project.

https://sebastiandedeyne.com/posts/2018/a-good-issue

Read more

In an older, but still very interesting article, Mattias Verraes has some interesting thoughts on form, command and model validation.

Many of the frameworks I’ve worked with, promise to separate responsibilities with MVC. In practice, they end up coupling everything to everything. The forms are coupled to the models, and there’s a grand unified validation layer. This may be convenient at first, but it breaks down for larger systems, and creates headaches when having to support multiple clients. My approach is to clearly separate the validation for the form itself, from the Command validation and the model validation.

http://verraes.net/2015/02/form-command-model-validation/

Read more

Mattias Noback gives some good tips for refactoring legacy code.

"Combing" legacy code by untangling the strings is a good way to improve it and take back control over it. In existing legacy code, you should stop (re)using existing methods, making them ever more generic. Instead, you create new methods, and copy code from existing ones, allowing you to simplify this copied code and end up with a manageable class.

https://matthiasnoback.nl/2018/04/combing-legacy-code-string-by-string/

Read more

Michael Dyrynda, co-host of the Laravel News and North Meets South podcasts shares his knowledge on how to handle applications that share one or more databases.

It took me a couple of months to get this to a working state, so I hope that I'm able to save you some time should you find yourself in my shoes at some point in the future!

https://dyrynda.com.au/blog/sharing-databases-between-laravel-applications

Read more

If you find yourself having a bunch of slow tests that don't need to execute every time you run the tests, take a look at PHPUnit's defaultTestSuite setting. TJ Miller explains it in a blog post he wrote last year.

To avoid running the interactive test suite with the rest of my tests, manually or via a CI job, I had to explicitly include all the other suites using phpunit --testsuite Api,Feature,Unit. This felt a bit grim and I would rather exclude just that one suite. So I did some digging and found the defaultTestSuite configuration for phpunit.

https://medium.com/@sixlive/separate-interactive-test-suites-f6fd59316ec2

Read more

#30daysWithEloquent customize relations on your models as necessary in your domain. Don't be afraid to add more relations that describe your logic better.

With @laravelphp it's a cinch ??? pic.twitter.com/m3TJXp9C2l

— DRY, DRY, DRY, DRY (@SOFTonSOFA) February 22, 2018

Read more [twitter.com]

Here's a video of a great talk by Sandi Metz she gave at RailConf 2015.

Our code is full of hidden assumptions, things that seem like nothing, secrets that we did not name and thus cannot see. These secrets represent missing concepts and this talk shows you how to expose those concepts with code that is easy to understand, change and extend. Being explicit about hidden ideas makes your code simpler, your apps clearer and your life better. Even very small ideas matter. Everything, even nothing, is something.

Read more

At the assert(js) 2018 conference, Kent C. Dodds dissects this tweet by Guillermo Rauch:

Write tests. Not too many. Mostly integration.

— Guillermo Rauch (@rauchg) December 10, 2016

Read more

On the Hackernoon site Nicolò Pignatelli wrote a good guide on how to write Value objects in a good way.

This is the list you must always check it against:

• it is immutable and no setters defined;
• it reflects the semantics of the domain;
• it shows how information flows and is transformed during runtime;
• it hasn’t default or useless getter methods;
• it can be compared to other Value Objects of the - - same class by reading private properties directly

https://hackernoon.com/value-objects-like-a-pro-f1bfc1548c72

Read more