DEV Community: Nathan Heffley

Finding Joy While Losing Use of My Hands

Nathan Heffley — Fri, 11 Mar 2022 13:45:57 +0000

Over the past year, especially the last 6 months, I have rapidly lost the ability to use my hands for precise, repetitive actions. Using a keyboard and mouse has become especially difficult. I've had minor pain for several years, but a standing desk, wrist braces, or a vertical mouse would fix the issue for a while. Finally learning how to type on a Colemak keyboard layout helped a bit more, but it wasn't enough.

It started to become a serious conundrum seeing as how typing on a keyboard is my livelihood. Even beyond work, programming is my favorite hobby. The physical act of typing was a big part of that. The keyboard was my instrument.

I needed a way to continue programming so I could keep working at the very least. A more ergonomic keyboard was the first idea, but I knew it would be a temporary fix at best. While searching for alternative input methods I somehow stumbled upon a talk called Perl Out Loud. The speaker, Emily Shea, did a fantastic job demonstrating how powerful voice controls could be. Thanks to her guide to voice driven development I was able to quickly get started.

Overcoming the Loss

The software I had found is called Talon. It comes with a robust voice detection model and total freedom in how you use it. It's not open source but the stable version is free for anyone to use, and the developer works on it full-time. Because it doesn't come with any commands out of the box, though, it requires some diving in to the Talon community. The Slack group is full of friendly and helpful folk so any issue you run into is quickly overcome. There's always someone sharing new ideas and tricks to help make using a computer easier. Even though Talon itself isn't open source, there are tons of additional tools, scripts, wikis, and setups that the community actively maintains as open source projects. Finding a community full of people, where a lot of them are going through the same thing as me or otherwise have difficulty in using a keyboard or mouse, has been crucial in not giving up because of the pain.

Thankfully, the initial learning curve was such that I started using Talon for work within a week. I wasn't nearly as fast as when I used a keyboard, but without any pain I could get into a better flow state for longer periods of time; so it evened out quickly. While I wasn't worried that I'd have to leave my job anymore, I still wasn't enjoying my new setup. I had to completely remove the keyboard from my desk so that I'd stop using it to make a small correction or press a keyboard shortcut that I hadn't bound to a voice command yet. It was depressing enough that I gave up any non-work related programming despite how much I had enjoyed it a few months earlier.

Finding the Joy

After two months or so I was getting pretty frustrated. Going back to using the keyboard was out of the question, so I pressed on, but not happily. I needed to look for some more advanced tooling to improve my productivity and reduce voice strain. The Talon community came to the rescue with a fantastically innovative VS Code plugin: Cursorless. Instead of moving a cursor around with vim-like bindings, I could use short identifiers to target very specific bits of code and manipulate them quickly.

After using it for a few weeks my productivity had skyrocketed, and with it my enthusiasm for programming again. It brought back a feeling of mastery that I had lost when I set aside my keyboard.

I've pulled the keyboard back out for things like video calls so that people don't think I'm trying to talk if I need to type a little bit during the meeting, but I make sure not to use it when I can use Talon instead. I'm still trying to kick my habit of using the mouse; unfortunately there's nothing quite as seamless as Cursorless for the mouse yet. My hands still hurt some days but now I can continue enjoying programming, and some days are even good enough that I can hold a video game controller without pain afterwards.

The Future

When I first started using Talon it was supposed to be a temporary thing. I'll use it for a while, let my hands heal, and then go back to the keyboard. It was always a pipe dream if I'm being honest. I'm not sure exactly what happened to my hands 6 months ago to cause so much more pain than usual, but I do know this disability is unlikely to go away enough to use a keyboard and mouse full-time again.

The one thing that I regret from before all this happened is not being more conscious of really learning how to make accessible websites. I'd watch for the easy wins like making sure colors had contrast and that elements were semantic, but it doesn't take long to learn how hard your projects are to use once you start needing accessibility tools yourself. I've since started learning as much as I can about building accessible websites, hopefully one of these days I understand it better.

So for now I'm enjoying this new form of programming. I joke that I don't need a rubber duck anymore because I'm talking through my code constantly. The ability to put my code up on the TV and pace the room or sit on the couch and code has been a great alternative to being stuck at my desk all day.

Cheers to many more days of coding!

Let me know in the comments if you'd be interested in a series of posts discussing the more technical aspects of how I use Talon and Cursorless.

Can Developers Help #BlackLivesMatter?

Nathan Heffley — Sun, 07 Jun 2020 16:23:16 +0000

Are there any open-source projects that need contributors or other ways that we as developers could use our unique skills to help improve racial equality?

Beautiful, Blocky Slack Messages

Nathan Heffley — Tue, 19 Mar 2019 15:42:34 +0000

Recently Slack released a new message format that apps can take advantage of called Block Kit. This new format allows apps and other software to send very rich messages through API calls or webhooks.

An example of hotel search results as a message, one of Slack's official Block Kit example templates.

If you're interested in sending messages like this, you'll first have to set up a Slack app. You'll need to have an account and workspace you can use for developing an app. Once you have that all lined up, you'll need to visit https://api.slack.com/apps and press the "Create New App" button.

Name it whatever you want and select the workspace you'll use for testing. The quickest way to start sending messages is to set up a webhook, so click on "Incoming Webhooks" in the sidebar menu and toggle the switch to activate incoming webhooks.

Now at the bottom of the page you should see a button to add a new webhook to your workspace. Clicking on that will prompt you to select a channel and authorize the app. Since you should be able to trust that you won't abuse your own app, go ahead and pick whatever channel you want to send your test messages to and authorize yourself.

You'll be redirected back to the previous page, but now you'll see a webhook for the channel you just selected. Copy that URL because we're going to use it now to send a message!

To make sure your webhook is working, you can send yourself a simple message with the following curl command, just make sure to replace the webhook URL with the one you just copied.



curl -X POST -H 'Content-type: application/json' --data '{"text":"Hello, World!"}' https://hooks.slack.com/services/YOUR/WEBHOOK/HERE

Now, to send a block message, things start to get a little bit crazy. For the sake of simplicity we'll send a full block message with a curl command, but just know that this is a very simple message and I do not condone using curl as your main form of posting Slack messages.



curl -X POST -H 'Content-type: application/json' --data '{
    "blocks": [
        {
            "type": "section",
            "text": {
                "type": "mrkdwn",
                "text": "*<fakeLink.toUserProfiles.com|Iris / Zelda 1-1>*\nTuesday, January 21 4:00-4:30pm\nBuilding 2 - Havarti Cheese (3)\n2 guests"
            },
            "accessory": {
                "type": "image",
                "image_url": "https://api.slack.com/img/blocks/bkb_template_images/notifications.png",
                "alt_text": "calendar thumbnail"
            }
        }
    ]
}' https://hooks.slack.com/services/YOUR/WEBHOOK/HERE

If you type that into your terminal (you don't copy and paste random multi-line commands from the internet directly into your terminal, right?) you'll see a simplified version of another one of Slack's example templates. In this case, it's a simple meeting reminder message with a bit of information and a nice little graphic to let you know that it's a calendar event.

As for how these blocks actually work, let's go over what some of these bits are.

The entire JSON object in the data option is a message payload. Before blocks you would have to include something like a text key like in the first message example. Now with Blocks you can have just a blocks key which will be an array of the blocks you want to include in your message. Because it's an array, you can send as many blocks in one message as you would like. This is what allows for extremely rich blocks like in the image I had at the start of this post.

Within each block object you're required to have at the very least a type property. The most general type you can have is a section, which just means it's a generic type of block. You can also have image, context, actions, and divider type blocks, all of which have slightly different use cases.

In the case of our example block, we included some text in the text property. Text values are themselves an object, and can be either mrkdwn or plain_text. In this case we're using Markdown because the title of the meeting is a bold link. The text's text property is where the actual text goes.

Then finally, this section has a special extra bit called an accessory. An accessory can be an image, button, date picker, or a whole menu. In this case we added an image, specifically the image of a calendar icon.

For a more in-depth dive on these rich message layouts, check out the official Slack documentation on creating rich message layouts!

Block Kit is pretty new, and I haven't seen as much support for it as I'd like to. Since my current framework of choice is Laravel, I tried finding out if there was an easy way to send Block messages. While there is an official package to send notifications to Slack, they've decided to not support Block Kit 😞

I've gone ahead and created a package that basically extends the official one, but with support for Block Kit included. If you use Laravel and are interested in taking advantage of this rich notification system, check out my package on GitHub!

nathanheffley / laravel-slack-blocks

An extension of the official `laravel/slack-notification-channel` package to add support for Slack Blocks.

Laravel Slack Blocks

This package is an extension of the official laravel/slack-notification-channel package.

Note Thes core notifications package has finally built-in support for these rich Slack messages, and as such you should use the official package if you are able.

https://laravel.com/docs/10.x/notifications#formatting-slack-notifications

Usage

Instead of requiring the official package, you should require this one instead.

composer require nathanheffley/laravel-slack-blocks

Because this package is built on top of the official one, you'll have all the functionality found in the official docs.

You can follow those instructions with the slight adjustment of requiring the classes from NathanHeffley\LaravelSlackBlocks instead of Illuminate\Notifications.

Everything supported in the base Illuminate Notifications classes is supported in these extended classes.

If you want to add a block to your Slack message, you need to add the block in an attachment.

use NathanHeffley\LaravelSlackBlocks\Messages\SlackMessage
// ...

public function toSlack($notifiable)
{
    return (new SlackMessage)
        ->attachment(function ($attachment) {
            $attachment->block(function ($block) {
                $block

…

View on GitHub

Do you pay to run any side projects?

Nathan Heffley — Sat, 24 Nov 2018 21:30:39 +0000

I often hear stories about people dropping their side projects as soon as it costs them money to run. I've done it myself many, many times. Sometimes the project just isn't interesting enough or you're not excited enough to justify the cost.

But I want to learn about some side projects that the dev community runs out of love, even though it costs them time (and maybe even some money) to keep it going for little to no return.

So, if you have a side project that you don't monetize but keep working on and make sure it's running, what is it?

How I Host My Buzzword-Powered Blog For Free

Nathan Heffley — Thu, 22 Nov 2018 17:25:38 +0000

My blog is what I like to call "buzzword-powered" since it's my testing ground for new technology I want to try out. In its current form, it's a single-page React app, generated by Gatsby. The entire site is pre-rendered static pages so even if a user doesn't have JavaScript enabled they'll get the regular experience of loading each page over HTTP requests. But if a user does have JavaScript enabled, the site will turn into a single-page progressive web app which will continue to work even if they have a spotty internet connection, or lose access all together.

In short, it's a mobile first, offline capable, pre-rendered static single-page progressive web app using React, generated by Gatsby.

All of these buzzwords make for a fantastic user-experience, I hope. On the first visit, the site loads in about one second and only downloads about 500KB of data (that's only half a megabyte, while the average site these days are several megabytes). Now that the app is loaded, subsequent page loads are, for all intents and purposes, instant. Only a few bytes of data need to be transferred to ensure the page is up to date. Even if the user leaves the site and comes back in the future, the entire site loads even faster. Less than a second to render the site and only a few hundred bytes per page viewed to make sure everything is up to date.

Not only is using my site easy for my readers, but it's easy for me as well. Running a static site is significantly easier and far more secure than other traditional blogging platforms like Wordpress. The biggest road-block to using a static site is that having a CMS is objectively more user-friendly than committing new files to a git repository or uploading new files to a server. That's why I decided to just use a CMS to handle the content for my blog. If you check out the code for my site (over on GitHub) you'll notice that none of my posts are there. That's because when building the site's static pages, it can pull data from Contentful and uses that information to generate the pages. This has allowed me to open-source my blog's framework without giving up my copyright on all the content I write for it.

That brings me to the first part of how I host my content for free...

Free Content Management

Contentful allows you to create different content types with various fields. This works out perfectly for something like a blog. Any time I want to write a new blog post, I just log in to Contentful, create a new post and fill in all the fields, and as soon as I publish the post it starts to go live. Because Gatsby only pulls data from the API when it builds the site, and because it only builds the site when something has changed (either the code or the content) I never have to worry about hitting any sort of rate limits. I'm the only one who writes for my blog, and I certainly don't have dozens of content types or thousands of posts, which allows me to easily stay within the restrictions of their free plan.

Normally, editing content on an external service like Contentful wouldn't cause a site hosted on a different server to update. But because of the power of webhooks, any time I save an update on Contentful it sends a message to my hosting platform to rebuild the site.

Which brings me to the final part of how I actually host my whole site for free...

Free Static Site Hosting

Netlify is a fantastic service if you're looking to host static sites. The biggest restriction is that the free plan only allows for one account, but that's fine if you're a lone-wolf developer (or the kind of person who shares Netflix accounts). If that restriction isn't a problem for you, and none of the extra features are must-haves, then you won't hit any resistance to using Netlify. A site can be pulled directly from your git repository and their server will run whatever build commands you need to run in order to build the site. After the site is built they'll deploy the static files to their CDN.

Any time you make a new commit to your git repository's master branch (or whatever branch you deploy from), Netlify will rebuild your site automatically and deploy it.

More importantly is updating when new content is published in Contentful. As I mentioned, any time I save new content a webhook will be called. More specifically, a Netlify webhook is called with a secret key which triggers a site rebuild. Gatsby grabs the new content and builds a page for it, and updates whatever else needs to be updated when a page is added.

All Together

So that's how my buzzword-powered blog is hosted. I hope this has encouraged you to come up with creative ways you can provide your users with a blazing fast experience that doesn't sacrifice cool features and buzzwords, all without giving up your CMS or paying anything to host it.

Disclaimer: This post was not sponsored. I encourage you to use these services (for free) if you are interested because they are fantastic services that I enjoy using.

Laravel + React: Posting Threads

Nathan Heffley — Fri, 12 Jan 2018 23:39:15 +0000

Originally posted on nathanheffley.com

This is the first lesson in a series on how to create a forum using Laravel and React. If you haven't read the introduction where we plan out the forum you should check it out first!

To get started with a forum, the first thing we need is the ability to create accounts, login, and create threads. Thankfully, Laravel comes with the Artisan make:auth command, which we'll be taking advantage of. Since this is covered pretty thoroughly other places, like in the Laravel Authentication documentation, I won't go over it again. Just know that I simply ran the php artisan make:auth command and didn't change any of the related files.

Creating New Threads

The first goal in making a forum will be allowing users to publish threads. With the default authentication system we get a /home route and page. We'll make use of this to show a user important information, like threads they've created and notifications they've received. For right now though, we'll add a sidebar with a form to create a new page. The template is pretty simple, so replace what's in the auto-generated template with our new home page.

@extends('layouts.app')

@section('content')
<div class="container">
    <div class="row">
        <div class="col-md-5 col-md-offset-7">
            <div id="create-thread"></div>
        </div>
    </div>
</div>
@endsection

That div with an id of create-thread is where our React form will be going. Using React for something simple like a form may seem like a little bit of overkill, but it will allow us to add extra functionality as we move forward and starting out we can make use it to submit an Ajax request instead of forcing the user to load a whole new page. As we add more components to this page, you'll see just how useful using React for all of these interactive pieces can be.

Before we move on to creating the actual React code, lets quickly go over the back-end code that will be powering the creation of new threads.

The Back-End Functionality

To actually create threads, we'll need a database migration. For right now, we need nothing more than an author_id column to reference who created the thread, as well as a title and content column. In the future we'll be adding more columns, but this is good enough to get us started. You can check out the full migration on GitHub. If you're following along, make sure to create that migration (I recommend just running php artisan make:migration create_threads_table --create=threads and editing it to match my file) and refresh your database.

Since threads will be an actual model that we'll be interacting with, we'll need a model as well. Starting out simple, the only thing I've put into the model is a $fillable property so that we avoid mass-assignment exceptions and an Eloquent relationship for accessing the threads author (and of course I added the matching relationship in the User class as well, you can view that diff here). Here is the Thread class.

And finally, none of this would be very useful if we didn't also have a controller to handle incoming requests. You can create a blank controller with php artisan make:controller ThreadsController and then add these few functions.

This one is pretty straightforward and will simply show a single thread.

<?php

public function show(Thread $thread)
{
    return view('threads.show', compact('thread'));
}

This is where we'll actually be storing new threads. First we validate that the title and content data values are present. Then we actually create the thread with the values and also set the author_id to be the id of the currently authenticated user.

<?php

public function store(Request $request)
{
    $request->validate([
        'title' => 'required',
        'content' => 'required',
    ]);

    $thread = Thread::create([
        'author_id' => \Auth::user()->id,
        'title' => $request->title,
        'content' => $request->content
    ]);

    return response($thread, 201);
}

Now that you've seen the two useful functions, go back up to the top of the controller and add a constructor. This is simply to ensure only authenticated users can make a POST request to create a thread. Since we'll be adding more functions in the future, I decided it was best to just require authentication on everything except simply viewing a thread.

<?php

public function __construct()
{
    $this->middleware('auth')->except('show');
}

Finally, we just need some routes for creating and viewing threads and calling these controller functions. Throw these two routes into your route/web.php file to handle that.

<?php

Route::get('/threads/{thread}', 'ThreadsController@show');
Route::post('/threads', 'ThreadsController@store');

Creating Threads With React

Now that the back-end is all setup and ready to go, lets create that form component!

First, go into your resources/assets/js folder and open up app.js. In there you'll see a line that pulls in the Example component. Go ahead and change that so it pulls in a more descriptive file.

require('./components/CreateThread');

Go into that components folder and rename the Example.js file to be CreateThread.js. This will be our form component.

By default, you should see that the file imports React and ReactDOM. Since we're going to making Ajax requests from this component, we'll also require Axios (which comes configured by default in every Laravel project).

import React, { Component } from 'react';
import ReactDOM from 'react-dom';
import axios from 'axios';

First we'll update what comes in the file by default and then add in our own functions to get the functionality we need. Make sure to update the class name definition from Example to CreateThread and do the same for the ReactDOM.render at the end. We need to check if the page has the create-thread id element that we will use anywhere we want this component to load. Since a page will only ever have one of these forms, this simple check will work just fine and is the perfect starting place for our first

export default class CreateThread extends Component {
    // Omitted for brevity right now.
}

if (document.getElementById('create-thread')) {
    ReactDOM.render(<CreateThread />, document.getElementById('create-thread'));
}

Now that the basic setup stuff is taken care of, we can work on rewriting the render method. We'll have the component always output itself as a self-contained panel. The majority of this code is just Bootstrap divs and styling. The important things to pay attention to are the onChange attributes on the input and textarea elements, and the onClick attribute on the button.

render() {
    return (
        <div className="panel panel-default">
            <div className="panel-heading">Create a New Thread</div>

            <div className="panel-body">
                <form>
                    <div className="form-group">
                        <label htmlFor="new-thread-title">Title</label>
                        <input id="new-thread-title" className="form-control" onChange={this.changeTitle}></input>
                    </div>
                    <div className="form-group">
                        <label htmlFor="new-thread-content">Title</label>
                        <textarea id="new-thread-content" className="form-control" onChange={this.changeContent} rows="8"></textarea>
                    </div>
                </form>
            </div>

            <div className="panel-footer">
                <button className="btn btn-primary" onClick={this.postThread}>
                    Publish
                </button>
            </div>
        </div>
    );
}

Now that we have the render function all taken care of, we need to create those changeTitle(), changeContent(), and postThread() functions.

The title and content functions are easiest, since they'll just be updating the components state. The event parameter is automatically passed to the function by React because of how the onChange event attribute is handled. With the event object we simply select the target which will be either the input or textarea element and then select the value from that.

changeTitle(event) {
    this.setState({title: event.target.value});
}

changeContent(event) {
    this.setState({content: event.target.value});
}

The postThread() function is a bit more involved, but we'll start out with the most basic Axios call we can get away with for right now. We'll come back to this function in the future when we add some new features and options for posting threads.

postThread() {
    axios.post('/threads', {
        title: this.state.title,
        content: this.state.content
    })
    .then(response => {
        this.setState({title: '', content: ''});
        document.getElementById('new-thread-title').value = '';
        document.getElementById('new-thread-content').value = '';
    });
}

If you've ever worked with Axios before then this function will be pretty straight-forward. Even if you haven't used it before, I'm sure you're all smart enough to figure it out. We're simply using Axios to make a POST request to the /threads path on our site which we set up earlier to accept POST requests and send them to the ThreadsController. In that POST request we're passing the title and content data which is stored in the components state (put there by the changeTitle and changeContent functions). Axios works using Promises so that after a request has been completed and a response is received, the then function gets called. Inside of that we reset the components state to have empty values and clear out the title and content inputs.

The final bit of this controller that we need is a constructor. We need to setup the initial state of the component, and also bind this to each of the functions we created. I go over why we need to doing this binding in my post on getting started with React.

constructor(props) {
    super(props);
    this.state = {
        title: '',
        content: '',
    };

    this.postThread = this.postThread.bind(this);
    this.changeTitle = this.changeTitle.bind(this);
    this.changeContent = this.changeContent.bind(this);
}

If you want to see the whole file, view it on GitHub.

That's it! We now have a component that can create threads on our forum using React and Axios. Visit your project (or clone it from GitHub) and go to the /home path to see the form. If you try submitting it you might not see much happen, but if you check out your browser's developer tools you should be able to see a POST request going to /threads. After submitting a thread, try visiting /threads/1 and you should be able to see the first thread you created.

This lack of feedback isn't very user friendly, so in the next lesson we'll work on creating some sort of alert component to tell users that their thread was successfully created and give them a link to view it.

Laravel + React: Planning a Forum

Nathan Heffley — Fri, 05 Jan 2018 16:07:34 +0000

Originally posted on nathanheffley.com

After getting React set up in your Laravel project (check out how to get started with React in Laravel 5.5 if you haven't used the new preset before), you may be wondering how to actually use it on your site.

In this series, we'll create a simple forum which uses React components for the main features of the site. Starting out, we'll focus on the main features (creating threads, commenting, etc). Later on we'll explore more advanced features such as voting, popular/hot algorithms, messaging, and following other users.

Let's look at the core components that we'll be creating over the next couple of lessons.

List of Threads

This will be the first thing that users will see when visiting the site. There's no point in going to a forum if you can't see a list of all the threads, right? We'll start out by creating a component that will take data about threads and display them in a chronological order (once we implement voting we can change this to show high-quality threads towards the top). Pagination will also be included in this component, and how to use Laravel's built-in pagination feature to create a React-powered element.

Thread

In order to allow a user to edit or delete their thread, we'll create a component that displays a thread to everyone but only shows the controls to the author. To keep a nice flow on the front-end, we'll also make use of Ajax calls to the back-end which will validate everything of course.

Comments

The comments will be similar to the thread list component, in that we'll paginate and display a list of all the comments for a particular thread. We'll also give the author some controls like on a main thread component.

GitHub

Throughout this series, I'll have a GitHub repo open tracking all the changes. I'll make sure to reference the most recent commit at the start and end of each lesson, so that you can catch up if you fall behind or just skip ahead to the next lesson if you don't want to write the code yourself.

I've already set it up with a basic Laravel project with the React preset already configured (again, check out my previous post to learn more about that). Go on over to my react-forum repository to check that out. Along the way I would love to see issues and pull requests for things I mess up or just for new features/lessons that you would like to see covered in this series!

Next week we'll get started with quickly setting up the authentication system and then allowing users to post new threads, which will give us the opportunity to start creating the Thread List component.

Learning Laravel: Eyeing Up Views

Nathan Heffley — Fri, 29 Dec 2017 21:37:45 +0000

Originally posted on nathanheffley.com

Now that we've started learned how to set up some basic routes (go check out Really Radical Routing if you haven't created any routes yet), lets give our site visitors something to look at that's a bit nicer than some plain text

Views will allow you to use a templating engine called Blade to create HTML pages with ease. You can check out the default page that gets created when you first make a Laravel project inside resources/views/welcome.blade.php.

Within that file, you'll see a basic HTML page with some Blade-specific content. Here's the file with some of the extraneous content taken out:

<!doctype html>
<html lang="{{ app()->getLocale() }}">
  <head>
    <!-- HEAD CONTENT -->
  </head>
  <body>
    <div class="flex-center position-ref full-height">
      @if (Route::has('login'))
        <div class="top-right links">
          @auth
            <a href="{{ url('/home') }}">Home</a>
          @else
            <a href="{{ route('login') }}">Login</a>
            <a href="{{ route('register') }}">Register</a>
          @endauth
        </div>
      @endif
      <div class="content">
        <!-- PAGE CONTENT -->
      </div>
    </div>
  </body>
</html>

The first example of some blade templating is encountered within the first two lines. The most basic way to use Blade is to simply use it as a way to output the value of some PHP code to the page. The way that you let Blade know that you want to evaluate a snippet of PHP code and put the result directly into the HTML code is to use double curly braces.

<html lang="{{ app()->getLocale() }}">

Blade will encounter this line, evaluate the code within the curly braces (in this example it's a call to a function) and then output the result of that function into the lang attribute of the HTML tag. In this example, app()->getLocale() is a special Laravel function to get, of all things, the current locale.

Further down in the file, we encounter something a little more interesting.

@if (Route::has('login'))
  <!-- inner stuff -->
@endif

If you're an astute reader, you may have already guessed that is an if statement just like you would use in regular PHP code. This is simply checking to see if a login route exists. Anything that is within one of these @if/@endif sections will only be output/evaluated if the conditional is true. If you want to get technical, in Blade templating speak, this is called an "if directive". Any time you see an @ symbol with a keyword in a Blade file, you're looking at a directive.

These directives are what make Blade really powerful. In a future post we may look into creating our own directives, but for right now we'll look at a special one that Laravel offers out of the box:

@auth
  <a href="{{ url('/home') }}">Home</a>
@else
  <a href="{{ route('login') }}">Login</a>
  <a href="{{ route('register') }}">Register</a>
@endauth

This directive checks to see if the current user is authenticated (logged in) to the site. Normally you would have to use an if statement to check if the user is authenticated, but this handy-dandy directive hides all that messy code behind and nice simple @auth keyword. Because this is basically an if statement in disguise, you can use else just like you normally would. These directives are what gives Blade some of the magic that makes it much nicer for templating than straight PHP code.

Now that you understand what curly braces and directives mean in templates, let's create our own view to use in place of that boring "Hello, World!" from the last article.

Create a new file in the resources/views directory called layout.blade.php and inside of it we'll setup the outline of any HTML document.

<!DOCTYPE html>
<html>
  <head>
    <title>Learning Laravel</title>
  </head>
  <body>
    @yield('content')
  </body>
</html>

This @yield directive is one of the more important directives that you'll be using when creating Blade templates. It allows you to extend this template file and place more code right where the @yield is. The parameter that yield takes allows you to create multiple sections and place them in different places. You can have as many yield directives as you want as long as they have different names. Pretty nifty! Now let's create the actual view for our route. Make one more file in resources/views and name it hello.blade.php.

@extends('layout')

@section('content')
  <h1>Hello, World!</h1>
@endsection

Here we use the @extends directive to tell Blade which file we want to extend and because Blade is so clever, it knows that all template files will end in .blade.php so we can leave that bit off and just give it the first part of the filename. Then we use the @section directive and pass it the same value that we gave to the @yield directive in the layout file. This is how Blade knows where this section belongs in the layout template.

Now that we have our very own view created, let's go back to the routes/web.php file and open it up again. Go to where we defined our /hello route in the previous lesson and change it so that we return a view instead.

<?php

Route::get('/hello', function () {
    return view('hello');
});

Just like Blade, Laravel knows that our file will end in .blade.php so we can leave that off. Now if you save that and check out your site's route (most likely at localhost:8000/hello) you should see an actual HTML page with an h1 instead of just plain text.

You now how everything you need to create a site with Laravel! You can create routes, display actual HTML pages, and even do a little bit of programming logic if you want. But putting code in the route file isn't a great way to keep things organized, and just returning basic pages isn't very interesting. In the next lesson we'll look at a brief overview of the project we'll build together to learn how you can use Laravel to build real-world projects. Make sure to check back so you don't miss it!

Learning Laravel: Really Radical Routing

Nathan Heffley — Wed, 20 Dec 2017 16:25:51 +0000

Originally posted on nathanheffley.com

Since a route is the first thing every user is going to interact with when visiting your site, it's where we're going to start our Laravel journey.

In most projects, your routes will be contained within the routes\web.php file. When you open it up after creating a brand new project (read the first lesson in this series if you need help setting up a Laravel project) you will see the generic starting route:

<?php

Route::get('/', function () {
    return view('welcome');
});

Let's break this down to figure out what's going on.

<?php

Route::get('/', function () {

First we call the get function on the Route facade. As you may have guessed, this is setting up a route that will respond to GET requests. The first parameter in this function is the actual route itself. In this case the route is set up for the root url. Assuming that our site is being run locally, this route is going to handle any GET requests that are made to localhost:8000. Any other type of request such as POST or any request to a different path like localhost:8000/example will ignore this route and keep looking for a better match.

The second parameter, the function, is what gets called whenever somebody makes a request to the server that matches this route. In upcoming lessons I'll show you how to extract this function to other files, but for right now we'll stick with this. For small projects or simple routes, using a function directly in your routes file is a viable option.

<?php

return view('welcome');

Inside the function we are simply returning this thing called a view. The view function is a special Laravel helper that takes a string that is then translated into the name of a file which is returned. Views will be covered in the next lesson, so make sure to check back in to learn exactly what this is doing. For right now, just rest assured that this is returning a view called 'welcome'. When you create a new project and visit it for the first time at localhost:8000, this view is what displays the large "Laravel" text and several links you see.

All in all, this route is saying that whenever somebody GETs the '/' route they should be sent back the 'welcome' view.

Lets create our own route. We won't worry about other files or views and just return a simple string.

<?php

Route::get('/hello', function () {
    return 'Hello, World!';
});

Now visit localhost:8000/hello and you should see "Hello, World!" output in plain old text on your screen. Congratulations, you've created a fully-functioning route in Laravel!

Of course most routes you create from here on out won't be quite this simple. In the next lesson we'll go over creating views so that you can return fully valid HTML pages. After that lesson you'll be able to use Laravel to create an entire website, albeit with limited functionality.

Although this may have seemed like an overly simple lesson, that's only because Laravel makes it so easy. We'll definitely be revisiting routes in the future as there is a lot more power hidden here, but we need to cover some more of the basics before we can use those features to their full potential!

Learning Laravel: Installation and Configuration

Nathan Heffley — Sat, 11 Nov 2017 16:26:11 +0000

Laravel is the "PHP Framework For Web Artisans" and it's become a hot topic in PHP back-end development over the past few years. Before you can start learning it though, you need to learn how to set up a new project using it.

Note: this article will assume you already have PHP 7, Composer, NPM, and MySQL installed on your development computer. While this is a beginner lesson for Laravel, it isn't a lesson for these other foundational systems. PHP is notoriously difficult to set up on Windows, so for the sake of brevity, I will not be covering that in this article.

Installing Laravel

To get started with Laravel, you'll first need to install the command line tool. This tool will allow you to quickly spin up new projects. All you need to do is use Composer to require the dedicated installer.

composer global require "laravel/installer"

To be able to use this new command anywhere throughout your system, you'll need to make sure your Composer vendor bin as part of your $PATH system variable. Once you have the installer successfully configured, you can test it out by trying to create a new project.

laravel new sitename

If all goes well, you will have a new folder called sitename that now contains a brand new Laravel project.

Downloading The Dependencies

Now that you have your project scaffolding created, cd into your sitename folder and get ready to work. The first thing you'll need to do is install the dependencies. With Composer, this is as easy as possible.

composer install

Wait a little bit depending on your computer and internet connection, and you'll be good to go!

Laravel also comes with a build system built-in that uses Webpack to compile your JavaScript and Sass, as well as serving Vue to the front-end. To take advantage of this pre-configured system, you'll need to install your NPM dependencies as well.

npm install

npm run dev

Anytime you want to compile your assets all you have to do is run the dev command and everything will be compiled down to your public directory.

Once you go to launch your site on a production server, there is also an npm run prod command that you should use instead of dev. While developing, there is also a handy npm run watch command which will recompile your assets any time you make a change to any of them.

With all of your dependencies installed, you can move onto the final step of setting up your project.

Configuring Your New Project

All that's left is to change the actual configuration files. Within your project, there should be a file named .env. If you can't find it, copy the .env.example file and create a .env file yourself. Within this file are where you most important configuration settings belong. If you use source control like Git (and you should) do not commit this file to your repository. It will contain sensitive data, like your database username and password, and any other API tokens or passwords you need while developing your application.

For just getting Laravel up and running we don't actually need to change any settings in here for right now. The first settings you will most likely change though when working on your own projects are the DB_DATABASE, DB_USERNAME, and DB_PASSWORD variables. I'll let you figure out what you should put in each of those when the time comes!

Before you can actually view the site though, you do need to set a value for the APP_KEY variable. You could just type a bunch of random letters and numbers there manually, or you can go back to your terminal and use a built-in command that comes with Laravel.

php artisan key:generate

You should see a message that your Application key [base64:gibberishhere=] set successfully. If you were to look at your .env file again you would see that APP_KEY is now set, and you are all set to finally check out your project in the browser!

If you have a local server system set up like Apache or Nginx, you could create a server that points users to your /sitename/public directory. For development purposes though, you can simply use another one of the built-in artisan commands to spin-up a local server.

php artisan serve

There will be a message saying that a Laravel development server started and a URL. You should be able to visit either http://localhost:8000 or http://127.0.0.1:8000 and see the default welcome page that comes pre-installed!

Congratulations! You're now ready to start creating amazing websites. I can't wait to see what incredible creations you come up with, I'd love to hear about them.

If you're interested in learning more about Laravel or just want to chat, check out my website.

I'd love to hear what you guys think. Anybody interested in more beginner Laravel tutorials?

Getting Started With React in Laravel 5.5

Nathan Heffley — Thu, 02 Nov 2017 20:48:26 +0000

Originally posted on nathanheffley.com

By default, the newest versions of Laravel ship with scaffolding for the JavaScript framework Vue.js. This is great for getting started quickly... if you plan on using it.

Another popular choice for front-end JavaScript is Facebook's React. Previously in Laravel, if you wanted to use React in your project you had to manually remove Vue and add React. While it wasn't terribly difficult, it did require pulling in the packages, adding it to your app.js or bootstrap.js files, fixing your webpack files, and so on.

But now that Laravel 5.5 has shipped, there is a new artisan command available that handles all of this for us.

$ php artisan preset react

This short command replaces all the Vue scaffolding with React. If you would like to follow along with the rest of this lesson, open your terminal and go to wherever you place your Laravel projects.

$ laravel new laravel-react

$ cd laravel-react

$ php artisan preset react

$ npm install

If you'd prefer to just look at the finished project, I have it hosted over on GitHub.

Now that you have a fresh Laravel installation with React scaffolding in place, you're ready to go! Using React within another project such as this can be a little confusing, so we'll build a simple counter component to get started.

When you first run the preset command, you will be given a default React component located at /resources/assets/js/components/Example.js. Rename this to Counter.js, and strip out all the example fluff and we're left with this much simpler component.

import React, { Component } from 'react';
import ReactDOM from 'react-dom';

export default class Counter extends Component {
    render() {
        return (
            <div className="container">
                <p>Counter Component</p>
            </div>
        );
    }
}

if (document.getElementById('counter')) {
    ReactDOM.render(<counter></counter>, document.getElementById('counter'));
}

All we did was rename the component and take out the extraneous code. Since we renamed the component file, we also have to go into our /resources/assets/js/app.js file and update the name there as well So now instead of requiring the Example component, we require our Counter component.

require('./components/Counter');

Finally, to get the component displaying on the screen so we know everything is working as expected, we can edit the welcome.blade.php view to display our component. Simply remove the default <body> and replace it with this bit of HTML.

<body>
    <div class="container">
        <div id="counter"></div>
    </div>
    <script src="/js/app.js"></script>
</body>

Because we used ReactDOM.render(..., document.getElementById('counter')); in our component, it will find that <div id="counter"></div> and turn it into our new Counter component. The script is simply our main app.js script that everything gets compiled down into when you run the build script. Speaking of which, make sure to run that now that we've created our component.

$ npm run dev

Now if you visit your project in your browser, you should see an extremely exciting "Counter Component" paragraph on the page.

Don't worry, it gets better. If you want to catch up with the GitHub project, you can jump to the Install and Run Dev commit.

Now that our component is displaying on the page, it means we can start adding some custom functionality. Since we said this was going to be a counter, let's follow through on that promise.

The first thing we'll do is setup the state for the counter, which is where the current count will be stored. Go back into your Counter.js file and add this constructor just inside the component declaration.

constructor() {
    super();
    this.state = {
        count: 0
    };
}

Since we have the state declared, we may as well start displaying it on the page. Change the render function to output our exciting new count state instead of that boring old paragraph.

render() {
    return (
        <div classname="container">
            <p>{ this.state.count }</p>
        </div>
    );
}

Run your build script again to compile all of this down, and reload your page to see the current count get output to the screen! If you've fallen behind or simply want to see the code, we just completed the Setup State commit.
It's still not very much like a counter though, since we can't actually interact with it to change the state. To make this as generic as possible so it can count whatever types of things you want, we'll simply add two buttons: one to increase the count and one to decrease it. Put these right below where we output the count.

<button onclick="{this.increment}">+</button>
<button onclick="{this.decrement}">-</button>

These buttons would work great, but right now we don't have an increment or a decrement function, so let's add those next. Put these two functions right between the constructor and the render function.

increment() {
    let count = this.state.count;
    count++;
    this.setState({count: count});
}

decrement() {
    let count = this.state.count;
    count--;
    this.setState({count: count});
}

They're pretty straightforward. Running the increment function will increase the count state by one, running the decrement function will decrease the count state by one. Since we are using this inside of a function on a component though, don't forget to bind this to the function. To learn more about why you need to do this and other ways to do so, check out these 6 Ways to Bind JavaScript's this keyword in React.
Personally, I bind the functions at the end of my component's constructor like so.

constructor() {
    [...]

    this.increment = this.increment.bind(this);
    this.decrement = this.decrement.bind(this);
}

Now you can successfully compile your code one more time and have a fully functioning React component inside Laravel! If you check out the site in your browser, you should see the default count of 0 and two little buttons. Clicking on either one should change the count and update the value being displayed just like you would expect.

There you have it! Now you can quickly and easily get started using React in all of your Laravel projects (if you want) without having to fumble around in configuration files.

You can check out the full source code of this example over on GitHub.