Faker already provides a lot of generator properties, so-called formatters, out of the box. You can find a list of the available formatters in the official documentation.

But what if no formatter aligns with the business logic? In this case, you can register your custom provider to the existing ones. Here's how to do it in Laravel:

Extending the Base

As a simplified example, let's implement a formatter that returns the name of a PHP framework.

A custom provider usually extends the \Faker\Provider\Base class. Therefore, in your Laravel application, create a new class that returns the data:

namespace App\Faker;
use Faker\Provider\Base;

class FrameworkProvider extends Base
{
    protected static $names = [
        'CakePHP',
        'CodeIgniter',
        'Laravel',
        'Lumen',
        'Phalcon',
        'Slim',
        'Symfony',
    ];
    public function framework(): string
    {
        return static::randomElement(static::$names);
    }
}

Laravel autoloads the file via Composer. Faker will later use the method name as the name of the formatter. The method returns a random element from a given array of strings.

Extending the Service Provider

Next, register the class in Laravel. You can generate a new Laravel service provider via the artisan command:

php artisan make:provider FakerServiceProvider

Make sure to include the additional Laravel service provider in the config file:

'providers' => [
    App\Providers\FakerServiceProvider::class,
],

In the provider, use the register() method to bind into the service container:

use App\Faker\FrameworkProvider;
use Faker\{Factory, Generator};
use Illuminate\Support\ServiceProvider;

class FakerServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        $this->app->singleton(Generator::class, function () {
            $faker = Factory::create();
            $faker->addProvider(new FrameworkProvider($faker));
            return $faker;
        });
    }
}

Factory::create() creates a Faker generator bundled with the default providers where you can attach additional providers using the addProvider() method.

Usage in Factories and Tests

Now you can use the new formatter like the other Faker formatters. In a Laravel factory, the syntax for the custom formatter looks like this:

public function definition(): array
{
    return [
        'name' => $this->faker->framework,
    ];
}

A test could look like this:

use WithFaker;

/** @test */
public function it_matches_any_word(): void
{
    $this->assertMatchesRegularExpression('/\w+/', $this->faker->framework);
}

You can use the formatter in your factories and tests. Keep in mind that fakerphp/faker is a dev dependency in Laravel, which is only available in the development environment.

Summary

Adding custom formatters is a great way to keep test factories short and concise to read whenever you need to generate data that Faker does not represent per default. There are a lot of helpful third-party packages available. I especially like the YouTube URLs package and the package for image placeholders.

Installing Corcel in a Laravel project

Require the latest version of Corcel via Composer:

composer require jgrossi/corcel

And publish the Corcel configuration file:

php artisan vendor:publish --provider="Corcel\Laravel\CorcelServiceProvider"

You can customize the name of the database connection in the configuration file:

'connection' => 'wordpress',

Add the additional database connection to the connections[] in your database configuration file:

'wordpress' => [
    'driver'    => 'mysql',
    'host'      => env('WP_DB_HOST', '127.0.0.1'),
    'database'  => env('WP_DB_DATABASE', 'forge'),
    'username'  => env('WP_DB_USERNAME', 'forge'),
    'password'  => env('WP_DB_PASSWORD', ''),
    'charset'   => 'utf8',
    'collation' => 'utf8_unicode_ci',
    'prefix'    => env('WP_DB_PREFIX', 'wp_'),
    'strict'    => false,
    'engine'    => null,
],

Make sure to define the environment variables WP_DB_HOST, WP_DB_DATABASE, WP_DB_USERNAME, WP_DB_PASSWORD, WP_DB_PREFIX in your .env file.

Usage

Let's start making use of Corcel by building a simple blog based on the WordPress database. Following the logic of WordPress, the blog consists of individual posts.

The first step is to create a Post model which extends Corcel\Model\Post. This step is optional but provides extra flexibility once you need to add custom methods for example view presenters. You can also use Corcel\Model\Post directly.

php artisan make:model Post

use Corcel\Model\Post as Corcel;

class Post extends Corcel
{
    protected $postType = 'post';
}

Next, create the corresponding PostsController:

php artisan make:controller PostsController

Corcel is built on top of the Laravel Eloquent ORM to interacting with the database. In the index() method, get the newest five public posts from the WordPress database and paginate the results using Eloquents paginate() method. In the show() method get the post from the $slug:

use App\Models\Post;
use Illuminate\Contracts\View\View;

public function index(): View
{
    return view('posts.index', [
        'posts' => Post::published()->newest()->paginate(5),
    ]);
}

public function show(string $slug): View
{
    return view('posts.show', [
        'post' => Post::slug($slug)->status('publish')->firstOrFail(),
    ]);
}

To access the view, let's add the routes for the blog overview and the single blog posts in the routes file referencing the methods in the PostsController:

use App\Http\Controllers\PostsController;
use Illuminate\Support\Facades\Route;

Route::get('/blog', [PostsController::class, 'index'])->name('posts.index');
Route::get('/blog/{post:slug}', [PostsController::class, 'show'])->name('posts.show');

In the Laravel Blade front-end template for the index view, loop through the list of posts and display the pagination links using the links() method:

@foreach($posts as $post)
  <a href="{{ route('posts.show', $post ) }}">
    {{ $post->post_title }}
  </a>
@endforeach

{{ $posts->links() }}

Use Cases

WordPress is a widely used CMS. As a developer, you may find it helpful to use built-in and well-tested features (uploads, comments) in addition to the far-ranging ecosystem (page builder, custom fields) without losing the flexibility of a PHP framework like Laravel.

Corcel supports all WordPress post types, including author, taxonomies, attachments, comments, options, users, and even Advanced Custom Fields. Corcel is a full-featured solution to use WordPress as your content management system in the background.

The best part is, this approach also works backward: You can update the WordPress database every time something happens in your application!

Headless WordPress

If you are using WordPress as a decoupled or headless CMS, I recommend the WordPress plugin Headless Mode. The plugin blocks all requests to the WordPress site if the request is not part of a CRON, REST, GraphQL, or admin request (logged-in user). With the plugin installed, you can still use the wp-admin part of WordPress and entirely disable (redirect) the front-end requests.

How do I use Headless Mode?

Activate the plugin and add the constant HEADLESS_MODE_CLIENT_URL to your wp-config.php file. If the (logged-in) user doesn't have the capability of edit_posts a redirect happens:

define('HEADLESS_MODE_CLIENT_URL', 'https://hofmannsven.com');

How can I entirely disable the WordPress front-end?

To also redirect logged-in users, return true in the filter. The setting disables the front-end entirely and redirects all users:

add_filter('headless_mode_disable_front_end', '__return_true');

How do I handle WordPress file uploads?

WordPress is storing the absolute path in the database. To not leak the URL of your CMS, use a subdomain or CDN for your uploads.

You can change the upload path using the pre_option_{$option} hook. Links to images and attachments inside of the $post->post_content are now served from the subdomain or CDN:

add_filter('pre_option_upload_path', function($upload_path) {
    return '/path/to/your/uploads';
});

add_filter('pre_option_upload_url_path', function($upload_url_path) {
    return 'https://cdn.hofmannsven.com';
});

php artisan make:test Http/Controllers/Api/UsersControllerTest

We are going to use a (slightly modified) example from the section Testing JSON APIs from the Laravel documentation:

use WithFaker;

/** @test */
public function a_user_can_create_a_new_user()
{
    $user = factory(User::class)->make();
    $response = $this
        ->actingAs($user)
        ->postJson(route('api.user.store'), [
            'name' => $this->faker->name,
            'email' => $this->faker->safeEmail,
        ]);
    $response
        ->assertStatus(201)
        ->assertJson([
            'created' => true,
        ]);
}

In this test, we act as an authenticated user to send an HTTP POST request to the JSON API endpoint. In the response, we assert the returned HTTP status as well as the returned JSON data.

This test covers the happy path. This means we send valid data (including a user, a name, and an email address) and therefore receive a valid response. This test does not cover the validation of the attributes, like an empty name, or a malformed email address.

Form Request Validation

Validation has its own place in Laravel know as form request validation.

Again, we stick to the example from the documentation and create a form request class, using the Artisan make:request CLI command:

php artisan make:request StoreUser

The authorize() method checks that only authenticated users are authorized to make the request.

The rules() method of the form request object is the place where we can set up all the validation rules for the API controller:

public function authorize(): bool
{
    return Auth::check();
}

public function rules(): array
{
    return [
        'name' => ['required', 'max:255'],
        'email' => ['required', 'unique:users,email', 'email:rfc,dns'],
    ];
}

Now it's time to take a closer look at the controller. We utilize the Artisan make:controller CLI command to scaffold the API controller:

php artisan make:controller Api/UsersController

We can now type-hint the form request in the API controller action and apply the rules defined in the form request object:

public function store(StoreUser $request): JsonResponse
{
    // Handle the valid request.
    $validated = $request->validated();
    // …
    return response()
        ->json([
            'created' => true,
        ], 201);
}

The incoming $request will be validated against the rules provided in the StoreUser class.

If the validation fails, the user will be redirected back. If the request is an AJAX request, an HTTP response with the status code 422 will be returned including all the validation errors.

With the validation being separated from the controller (in its own form request class), how can we make sure the controller method uses the appropriate form request validation?

Testing Form Requests

It turns out Jason McCreary, the creator of Laravel Shift, has built a neat package to solve this issue. The Laravel Test Assertions package provides a set of helpful assertions when testing Laravel applications.

Let's install the package (currently v1.0.0) and give it a try:

composer require --dev jasonmccreary/laravel-test-assertions

We add the trait AdditionalAssertions at the beginning of the test and can now assert that the action for a given controller is linked to the appropriate form request object:

use AdditionalAssertions;

/** @test */
public function store_uses_form_request()
{
    $this->assertActionUsesFormRequest(
        UsersController::class,
        'store',
        StoreUser::class
    );
}

This test gives us confidence that the controller uses the associated form request. We can now be sure the controller action performs the expected validations.

Please note that we do not test the validation rules here! The test only makes sure that the controller uses the form request.

Testing Form Request Validation Rules

While we do not need to test the rules provided by Laravel, we still want to make sure the rules are in place. Let's write another test for the form request:

php artisan make:test Http/Requests/StoreUserTest

The Laravel Test Assertions package offers an assertion to quickly test if the validation rules match:

use AdditionalAssertions;

/** @test */
public function it_verifies_validation_rules()
{
    $formRequest = new StoreUser();
    $this->assertExactValidationRules([
        'name' => ['required', 'max:255'],
        'email' => ['required', 'unique:users,email', 'email:rfc,dns'],
    ], $formRequest->rules());
}

Of course, this test might seem a little brittle on the first look. The test is going to fail as soon as the rules, or the fields are changing. However, changing the rules or the fields should always result in a failing test!

Further reading: Jason McCreary wrote about the real tradeoffs in his post Testing validation in Laravel by asserting a form request.

Testing Form Request Authorization

The authorize() method in the form request determines if the incoming request is an authorized request. We can (and should!) test this behavior as well:

/** @test */
public function it_verifies_authorized()
{
    $user = factory(User::class)->make();
    $this->actingAs($user);
    $formRequest = new StoreUser();
    $this->assertTrue($formRequest->authorize());
}

In the test, we act as an authenticated user and new up the form request. We perform the assertion against the returned value of the authorize() method. This test gives us confidence that we only allow authorized requests.

Writing Tests Takes Time

Laravel is built with testing in mind. Yet testing a controller method with a lot of fields can get out of hand quite fast. The Laravel Test Assertions package offers an option to quickly knock off the main points and gives us confidence that everything is wired up correctly. With the basics covered we can focus on more complex parts of the application like custom validation rules or the business logic of the application.

Keep testing until you have confidence. Jason McCreary

Credits for this post are going to Jason McCreary for his awesome Confident Laravel course, a step-by-step guide to writing tests for Laravel applications.

GitHub rolled out GitHub Actions for everyone in November 2019. GitHub Actions are free to use (up to 2000 minutes per month) for public and private repositories and execute a workflow every time a defined event is triggered on GitHub. GitHub provides quite a lot of webhook events that can trigger a workflow.
So let's explore how to automate the steps of our development workflow when working with Laravel and Laravel Nova.

Workflow file

To get started, you need to create the basic YAML configuration file. This file is located in the repository in the .github/workflows folder.

TL;DR: View the whole workflow file on GitHub.

name: Tests
on: [push]
jobs:
  tests:
    name: Run tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1

The keyword on defines when the action will be executed. In the example above, we listen for the [push] event. It is also possible to chain multiple events [push, pull_request] or restrict the workflow to a specific branch.

The jobs section can hold multiple steps. The first step loads an action actions/checkout@v1 provided by GitHub, imported with the keyword uses.

Workflows run on Linux, macOS, Windows, and even Docker container images. If you're interested in a setup with a custom Docker container image, read the post Using Github Actions to setup CI/CD with Laravel by Luis Dalmolin.

Services

Before adding additional steps to our workflow we want to include a service.

In most cases, Laravel Nova needs a database. For this reason, we're adding the MySQL service to the workflow. My application is still running on MySQL 5.7 so I'm pulling in the official MySQL Docker image for MySQL 5.7 (the image also supports other tags like MySQL 8) that will spin up a MySQL server in the container. Make sure to define the env variables and the port as it will not work without these parameters!

services:
  mysql:
    image: mysql:5.7
    env:
      MYSQL_DATABASE: database_ci
      MYSQL_USER: user
      MYSQL_PASSWORD: secret
      MYSQL_ROOT_PASSWORD: secretroot
    ports:
      - 33306:3306
    options: --health-cmd="mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=3

To not confuse the environments I usually create a separate .env file for the CI environment. Based on the .env.example file create a new file with the name .env.github which is holding the MySQL credentials from above.
You can also find the contents of the file on GitHub.

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=33306
DB_DATABASE=database_ci
DB_USERNAME=user
DB_PASSWORD=secret

Verifying the MySQL connection

We're ready to add the first step. To make sure we've set up everything correctly we start with a step that tests if the MySQL connection is working. This step is optional and not related to the remaining workflow but I find it very helpful to make sure the MySQL connection is actually working.

- name: Verify MySQL connection
  run: |
    mysql --version
    sudo apt-get install -y mysql-client
    mysql --host 127.0.0.1 --port ${{ job.services.mysql.ports['3306'] }} -uuser -psecret -e "SHOW DATABASES"

If you're having trouble setting up the MySQL connection jump to the troubleshooting section below.

Installing dependencies

Now we're good to go to set up the world of our application. In this step, we're going to download and install all of the required dependencies via Composer. To authenticate Nova in the GitHub CI environment add your NOVA_USERNAME and NOVA_PASSWORD to the GitHub Secrets in the repository. The secrets are environment variables that are encrypted and not shared in forked repositories.
You can set your secrets here: GitHub Repository › Settings › Secrets

- name: Install dependencies
  run: |
    php --version
    composer config "http-basic.nova.laravel.com" "${{ secrets.NOVA_USERNAME }}" "${{ secrets.NOVA_PASSWORD }}"
    composer install -n --prefer-dist

Booting Laravel

Next, we're going to boot the main Laravel application including Laravel Nova and all other dependencies. Therefore, we copy our CI credentials from the .env.github file to the .env file. After generating an encryption key we can run other artisan commands.

- name: Boot Laravel application
  run: |
    cp .env.github .env
    php artisan key:generate
    php artisan --version

Migrating the database

Run the available migrations to initiate the main structure of the database. Append the --seed flag in case you'd like to seed the database with default entries e.g. roles or settings. The seed should not be necessary for your unit or feature tests, but may be helpful for other tests.

- name: Migrate database
  run: |
    mysql --version
    php artisan migrate:fresh --seed

Running the build process

To make use of HTTP (feature) tests in our test suite we need to have a fully working application. This requires us to have access to all compiled assets in the CI environment. To compile the assets I'm using yarn but it works with npm as well.

- name: Run yarn
  run: |
    yarn --version
    yarn && yarn dev

Running the test suite

Finally, we are ready to run the PHPUnit test suite:

- name: Run tests
  run: |
    ./vendor/bin/phpunit --version
    ./vendor/bin/phpunit

Be aware of the two different environments:

1. the CI environment: ci
   defined in the .env.github file, copied to the .env file
2. the testing environment: testing
   defined in the phpunit.xml file

Laravel 6 uses an in-memory SQLite database for testing (config on GitHub).
If you'd like to run your tests against a MySQL database, set the DB_CONNECTION to mysql and add the name of the database to DB_DATABASE. Make sure that the database actually exists and is empty.

If you're having trouble setting up the MySQL connection jump to the troubleshooting section below.

Adding security checks

To check if the application uses dependencies with known security vulnerabilities we load and run the open source Symfony Security Checker. I like this step in particular as it adds additional value to the automation workflow.

- name: Run security checks
  run: |
    test -d security-checker || git clone https://github.com/sensiolabs/security-checker.git
    cd security-checker
    composer install
    php security-checker security:check ../composer.lock

Logs & Caching

We can cache the dependencies from Composer and Yarn. Therefore we use the actions/cache@v1 GitHub Action and a hash of the .lock-file as an identifier.

Ruben Van Assche covered these steps quite well in his post Getting started with GitHub Actions and Laravel so I'm not going to illuminate these steps anymore. The steps are also included in the workflow file on GitHub.

In case of an application error, you can download the logfiles from GitHub.

Running the complete workflow

FYI: Download the workflow file from GitHub.

After we commit and push the workflow file to our repository on GitHub the action runs (see on: [push] above). Booting up the CI server including all dependencies and executing all the steps takes about two to three minutes (up to 2000 minutes per month are free which makes the CI service basically free to use).

Watch the workflow in action in the video below:

Troubleshooting

Failed to initialize, mysql service is unhealthy.

There is a problem with the MySQL port. If not defined, the port number is a random number. You can get the port number from the job service. Use the env key to assign the dynamic MySQL port number to a step manually.

- name: Run tests
  run: ./vendor/bin/phpunit -v
  env:
    DB_PORT: ${{ job.services.mysql.ports['3306'] }}

SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed

The MySQL credentials are incorrect. Make sure to define the MYSQL_USER, MYSQL_PASSWORD and MYSQL_ROOT_PASSWORD in your .env file.
Read this answer on Stack Overflow for an in-depth explanation.

QueryException: SQLSTATE[HY000] [1045] Access denied for user 'user'@'localhost' (using password: YES)

The database does not exist or the database credentials are invalid. Check the .env file and make sure to clear the config cache after a change:
php artisan config:clear

RuntimeException: No application encryption key has been specified.

This error will pop up if the APP_KEY is not set. Make sure to generate an APP_KEY using the php artisan key:generate command before executing any commands using artisan.

Where to go from here?

The future of automation is now. Explore the awesome actions repository and use the available actions to create a release, send a notification or run a deployment. Or even better: Create your own actions!

Update: Freek Van der Herten shared and explained the GitHub workflow file for Ignition in his post Using GitHub actions to run the tests of Laravel projects and packages which contains a test matrix (php, laravel, dependency-version and os) as well as Slack notifications. Make sure to read the post as well!

When distractions are everywhere it's key to find joy in the work. To accomplish my tasks I aim for three things: motivation, discipline, and focus.

Fortunately, I'm very passionate about web development and really like what I'm doing. So most of the time motivation is not an issue for me.

But nobody is constantly motivated, particularly when working on side projects or open source projects over a longer period. When curiosity and excitement wear off, discipline keeps me going, even if I don't feel like it. Persistence and consistency are the gatekeepers.

Get back on track

Start by defining a small and manageable goal and commit to working on it. Start with an easy task and reach for the low hanging fruits, to celebrate a quick win. Making any kind of progress, however small, really helps me to get back on track and more often than not the motivation returns after a while.

In software development, I usually follow the Commit Message Driven Workflow and start by writing out the commit message. With the commit message being written down (the goal), I'm in the mindset to write the code.

Priorities are key

Though, for me, the most important gatekeeper is focus. Without focus — without the right direction — there is no meaningful progress.

In his post How to Be Successful, entrepreneur Sam Altman wrote on the importance of focus:

Focus is a force multiplier on work. Almost everyone I've ever met would be well-served by spending more time thinking about what to focus on. It is much more important to work on the right thing than it is to work many hours. Most people waste most of their time on stuff that doesn't matter.
Once you have figured out what to do, be unstoppable about getting your small handful of priorities accomplished quickly. I have yet to meet a slow-moving person who is very successful. samaltman.com, How to Be Successful

Focus is probably the most underrated gatekeeper. If your priorities are not clear — if you do not know what your goal is — it's hard to make any progress at all. Make sure to be clear about what you are working on and say no to everything else.

Conclusion

It's never been a better time for self-motivated people, wrote James Clear, the author of the book Atomic Habits. To make progress you need to start. A lot of options reveal themselves after starting. Prioritize high-impact tasks. Define a goal. Remove distractions. Stay focused. Make it a habit to work on it every day. Find joy in the work. And from time to time, take a break.

Further reading

• Why We Never Have Enough Time & What to Do About It
• The Attention Diet
• Atomic Habits

Shoutout to David Hemphill who has turned this antipattern into a disestablishmentarian philosophy. While there might be use cases where this makes sense I strongly believe in the value of helpful commit messages, especially when working in a team or an open-source repository.

Commit Message Driven Workflow

So how exactly would a commit message driven workflow look like? First, we start by writing out the commit message. Second, we write the code. As soon as we're done, we commit the code. This is how the workflow looks like:

1. Write the commit message.
2. Write the code.
3. Commit the code.

By writing the draft of the commit message first, we decide what we're working on. The scope of our task is clear now. With the commit message being written down, we're already in the process and in the mindset to write the code to make it happen. We can modify the commit message later, if necessary.

I came across this idea some time ago. Andrew Feeney published the post Commit Message Driven Development and it completely changed my workflow as a professional developer.

This approach helps me to focus on the actual feature I'm working on. After writing out the commit message I continue to write the code. With the commit message in mind, the scope of the commit is clear.

The concept aligns pretty well with the Ivy Lee productivity method. James Clear, the author of the book Atomic Habits, points out what makes the method so effective:

• It's simple enough to actually work.
• It forces you to make a decision.
• It removes the friction of starting.
• It requires you to single-task.

For me the last point is the most powerful: it helps me to focus on one thing at a time because doing anything outside of the scope of the commit message is another task/commit.

If you commit to nothing, you'll be distracted by everything. jamesclear.com, The Ivy Lee Method

Benefits

Here are some of the benefits I discovered while working with this approach:

• Scope
  It helps me to decide what to work on upfront. The commit message defines the scope and holds me accountable. The commit message is like a micro goal.
• Structure
  It helps me to logically group and later review my commits because each commit has a precise goal.
• Focus
  It helps me to remember what I decided to work on.
  It also helps me to remember what I was working on in a previous (unfinished or interrupted) session.

Setup

Following up on the post by Andrew Feeney I use these two bash functions to incorporate the concept into my daily routine (jump to update below):

function aim() { vim ./COMMIT_MSG; }

function fire() { vim ./COMMIT_MSG && ( git commit -F ./COMMIT_MSG $* ) && rm ./COMMIT_MSG; }

Additional Setup

In my global .gitignore file I added the following line to not check in the temporary COMMIT_MSG file by accident:

COMMIT_MSG

Usage

1. Type aim in the Terminal. Write the draft of the commit message in the editor and save the file. This creates a new (temporary) file in the current repository with the name COMMIT_MSG.
   To read or modify the commit message type aim again.
2. Write the code as you'd normally do and add/stage the files you'd like to commit.
3. Type fire in the Terminal. This opens the editor with the pre-written commit message again. Update the commit message if necessary and save the file. The function creates a new commit and deletes the COMMIT_MSG file.

The fire function passes through all options. Feel free to append the available commit options provided by Git. For instance, use fire --amend to replace the tip of the current branch by creating a new commit.

Update: Git CDD

Alexander Goller developed a Git plugin for Linux and macOS to make the commit driven workflow even smoother.
Instead of custom bash functions use the available Git CDD plugin:

Installation

1. Clone the repository:
   git clone git@github.com:alpipego/git-cdd.git
2. Change into the directory and run the installer:
   cd git-cdd && sudo make install

Usage

1. Type git cdd aim -m 'Message' in the Terminal.
   The command creates a new (temporary) file in the current repository with the name CDD_COMMIT_MSG that holds the commit message.

• Type git cdd status to preview the prepared commit message.
• Type git cdd amend to modify the prepared commit message.
• Type git cdd forget to delete the prepared commit message.

2. Write the code as you'd normally do and add/stage the files you'd like to commit.
3. Type git cdd fire in the Terminal. This opens the editor with the pre-written commit message. Update the message if necessary and save the file. The command creates a new commit and deletes the CDD_COMMIT_MSG file.

What's next?

Give it a try! Start your next task by writing down the goal first and see how it feels. For starters complete the following sentence: If applied, this commit will...

It took me a while to get it done and I ended up migrating everything from WordPress to Laravel to fit my needs.

I haven't written a blog post in a few years, so let's sum things up first.

Once upon a time...

In 2007, I launched my very first website. I was just so excited to be online but then I realized that frames and tables aren't particularly brilliant, so I went back to the drawing board.

Five years later, I launched the blog with WordPress as a CMS and wrote a few blog posts about frontend web development, developer tools, conferences and a lot of open source hardware (mostly Arduino and Raspberry Pi). I released a couple of open source packages on GitHub, got promoted by Smashing Magazine, had the incredible Jon Masterson write a very popular guest post and connected with a ton of awesome people.

What a ride...

In 2018 I rebuilt the front page with Laravel, to display who I am and what I do as a freelance developer.

Now, after this journey of over 10 years, I want to revive the blog to document and share my thoughts on design and development. I always loved writing blog posts, and also liked the balance it gave to my day-to-day work.

Setup

The main website and the blog are now built with Laravel. The articles are stored as individual markdown files in the repository. Additional metadata is placed at the top of the files, formatted as YFM (YAML).

This setup makes it easy for me to maintain and migrate the content and does not require any sort of admin panel or database.

Tech stack

• Laravel
• Spatie YAML Front Matter
• League Markdown parser
• Spatie Response Cache
• Cloudways

Properly cached, this setup makes the loading time of each individual request basically as fast as a static site.

Designed for speed in the backend and for readability in the frontend, this is a new milestone on this blog's journey.

Who am I?

My name is Sven and I'm a freelance web developer from Germany. I'm involved in the open source community on WordPress Stack Exchange and help with the organization of the WordPress Developer Meetup in Berlin. (You can also find me at the PHP and Laravel meetups in Berlin.)

Having a deep relation with open source software and the web, I'm constantly working on new ideas. I'm also interested in interface­ and interaction­ design and like to tinker with new stuff.

Maintenance and next steps

As you might guess, I have many, many ideas to further enhance this blog. I see this as an ongoing project rather than something with a finish line. In the next couple of weeks, I want to add an RSS feed and focus on new content. I will also try to recreate/­rewrite some of my old posts from the archives.

In the meantime, don't hesitate to contact me via email with any feedback or questions, and feel free to connect with me on Twitter. You can also follow me on GitHub and CodePen.

Update: You can now subscribe to the RSS feed.

Ethernet Libraries

Next, download and include the EtherCard Library from the GitHub repo.

Note: The EtherShield Library is no longer maintained. Follow this post on how to migrate from the EtherShield Library to the EtherCard Library.

Debugging

Re-check all of your wired connections and run one of the examples from the library above. The Ethernet Module should work out of the box with any type of Arduino Board.

But the Arduino Ethernet Board especially differs from the other Arduino Boards in one vital way: it does not have an onboard USB-to-serial driver chip. However, you can still use a USB Serial adapter to power the Arduino Ethernet Board as described on the official Arduino website:

The 6-pin serial programming header is compatible with the USB Serial adapter and also with the FTDI USB cables or with Sparkfun and Adafruit FTDI-style basic USB-to-serial breakout boards. It features support for automatic reset, allowing sketches to be uploaded without pressing the reset button on the board. When plugged into a USB-to-serial adapter, the Arduino Ethernet is powered from the adapter. arduino.cc, Arduino Ethernet Board

Using the Sparkfun Basic Breakout with the Arduino Ethernet Board may require a FTDI driver that causes the USB device to appear as an additional port available to the computer. Without this special FTDI driver, your Arduino Ethernet Board will be powered, but it is not possible to upload any sketches. This will be immediately apparent because without the FTDI driver there will be no serial port.

Therefore, you can download the latest version of the FTDI driver for FTDI devices on the official website for Virtual COM Port drivers.

Arduino Ethernet & LiliPad FTDI Basic Breakout

Currently, I'm using the LilyPad revision of the FTDI Basics Breakout which is pretty much the same as the FTDI Basic Breakout (apart from the color and the thickness).

To connect the FTDI Basic Breakout with your computer you can use a USB Mini-B Cable (Type A to Mini-B). As mentioned above, it is possible to power the Arduino Ethernet Board from the adapter via the USB connector.

When uploading a sketch, make sure that you have chosen the right Board and Serial Port in your Arduino IDE (Arduino › Tools › Board respectively Serial Port). There is no hidden feature therein, but sometimes it can be difficult to remember all these little things.