DEV Community: Camilo Payan

In Chess and Code, Move Past the Shiny

Camilo Payan — Wed, 18 Nov 2020 20:36:29 +0000

TLDR: Stressing over tools and languages isn't useful for the new coder. Beginners should focus on learning reusable concepts like iteration, logic, and data structures.

Queen's Gambit is a great show on Netflix that has been exploding chess' popularity. I love it! But!... one scene in the first episode frustrated me. Right after the first few games, Beth's chess friend tells her to learn the Sicilian opening and gives her a book of chess openings!

That doesn't deter her genius play, but it wouldn't work for most beginning chess players. Beginners need to study tactics, not openings.

The shiny

In chess, openings are the shiny objects. They have attractive names like Sicilian Dragon, the Spanish game, or the Caro-Kann defense. People will go passionately instruct you to learn one or the other to win. They'll call other openings "boring" or "lazy" or not for "real players".

Sound familiar?

The same thing happens to beginner programmers.

New coders jump into a bewildering landscape of languages and code tools. "Should I learn Ruby or React?" "Should I start with one kubernet?" "Is JavaScript the same as Java?"

Without context, it's overwhelming. There's a ton of literature and a lot of it is actually quite entertaining. People pick fights constantly on Twitter to push their favorite tool or language.

But these are the shiny objects of programming.

Move past the shiny

I once heard a chess coach say that they teach new players two openings, one for white and one for black. Then players do tactics. Why? Because you're going to spend most of your game either trying to cause or defend against tactics. The openings are just enough to get a player safely to the middlegame, where tactics and strategy are more important.

For new coders, I say move past the shiny.

Learn enough of a language to get started, then move on to problems and projects. Follow a tutorial and make changes to it. Do problems on a site like Exercism.

The core concepts for beginning programmers are:

Logic, like if/else conditionals
Iteration, like loops
Data structures

Get enough knowledge to get to the core concepts and you'll find that the language itself doesn't matter as much. Many in the industry switch languages multiple times a day, and that's because their foundation in the core concepts is solid.

If you liked this, find me on Twitter I'd love to chat about it. Also you can always challenge me to a game of correspondence chess on Lichess or on Chess.com!

Eager Loading In Laravel Route Models

Camilo Payan — Mon, 19 Oct 2020 15:18:47 +0000

TLDR: Override the resolveRouteBinding method on your Eloquent model in order to eager-load relations that you know will be used.

The problem: Limits To Route Model Binding

In a Laravel application I'm writing, I have a few dozen routes that all have basically the same format: /jobs/{job} as a prefix and then particular actions for that job. In Laravel, we have route model binding, which is to say that by convention, you can use the name of a model (the Job model, in this case) in the braces of your route and when your application reaches the controller method, the model is
sent in as a parameter.

For example, with /jobs/{job} this means my controller method signature would look like this:

public function show(Job $job){ /* ... */ }

This is a very powerful function and it saves us a lot of boilerplate Eloquent code searching for the model from the database explicitly in our controller methods.

I'm working on adding notes to each job, which is something I created using a new model JobNote which has a one to many relationship with each Job.

Now one thing that I want to display in my sub-navigation for all these Jobs is a count of how many JobNotes each Job has. In Laravel, we can eager-load the count by running:

$job->loadCount('notes')

on the job model I receive as a parameter.

Here's the issue, I have 40+ routes that use this same job model prefix and they all need the count since they all share the same sub-navigation where the count will be used. This would mean I'd have to add that line to 40+ spots in the code (once for each controller method) as well as remember to write it in when I write new controller methods in this route group.

Not my idea of a simple or maintainable coding experience.

The First Idea: Default Eager Loading

Eloquent has the ability to always load a relationship by default using the protected $with variable on my Eloquent model, but there are two issues here:

I only need the count, not a collection of all the related notes.
The Job index route loads lots of jobs, and doesn't use the single Job model binding, so I don't want to get this relationship there.

That second point got me thinking, "Is there a way to hook into a model when it's being resolved from a route?"

The answer: Yes!

The Real Solution: resolveRouteBinding

Eloquent models have a function, resolveRouteBinding, which can be overriden to add extra functionality.

Since this would only happen when a specific job is being asked for in the route, it would cleanly leave out the job index page, resolving the second problem I had with default eager loading.

The function as I needed it, looks like this:

public function resolveRouteBinding($value, $field = null)
{
    return $this->where('id', $value)
              ->withCount('notes')
              ->firstOrFail();
}

First we search for the actual model, since the id is what's passed in, then we make sure to load it with the count we want, and make sure we only get one model! Now the model is loaded with the field notes_count available, with the data we need by default. We haven't loaded all the notes, which solves the 1st problem I had with the default eager loading.

It's a regular PHP block so I could imagine adding more functionality to support extra loads depending on the route.

Going this route meant that instead of having to add the
$job->loadCount('notes') to each controller method (40+ times just to start!) I just added a few lines to my model code. Much easier to maintain.

If you like this and found it useful, please let me know on Twitter!

Setting Up Vim and the PHP Language Server Protocol

Camilo Payan — Fri, 04 Sep 2020 18:33:47 +0000

Vim is great at editing text, but doesn't have the full language features built
in that devs love in IDEs. At the same time, the Vim plugin ecosystem has
allowed for new languages to quickly ramp up in Vim instead of waiting for
adoption to support a full IDE.

Enter the Language Server Protocol. Originally to support another text editor,
Visual Studio Code, LSP has been embraced by the Vim world as a way to get much
richer language support than we're used to, and now that's available for PHP!

Let's step through how to install Language Server Protocol support for PHP in
Vim.

Assumptions

Some silly assumptions to start!

You have Vim installed and a method of installing plugins you prefer. Why? Because there are multiple plugin managers and I'd like to gloss over instructions for each.
You have Composer installed for your PHP project
You're comfortable on the command line! This seems likely if you're using Vim.

Step 1: Install the LSP client plugin

The most popular Vim plugin for LSP integration is Prabir Shrestha's Vim-LSP
plugin. Go ahead and install this
plugin based on your plugin manager of choice and the instructions at the Github
link. This is your LSP client for Vim!

Step 2: Install the LSP Server

In your project, run:

./vendor/bin/composer require -D felixfbecker/language-server

This will install the language server locally to your project, and add it to
your composer.json dev dependencies. Why do this per project? I have a few
projects and generally avoid depending on a global install if I can help it. If
you have different requirements, you could install it with a global composer
install.

Step 3: Parse stubs

There are plenty of parts of PHP that aren't defined in your code but the
language server still needs to know about! These are things that are in the PHP
standard library, like definitions for DateTime or function signatures for built
in functions like array_map.

From your project, run:

./vendor/bin/composer run-script --working-dir=vendor/felixfbecker/language-server parse-stubs

Step 4: Configure Vim to start and use the LSP

Now we need to configure Vim to use the server. Add this to your vimrc

au User lsp_setup call lsp#register_server({
    \ 'name': 'php',
    \ 'cmd': {server_info->['php',
expand('[PATH TO YOUR COMPOSER VENDOR DIRECTORY]/vendor/bin/php-language-server.php')]},
    \ 'whitelist': ['php'],
    \ })

autocmd FileType php setlocal omnifunc=lsp#complete

Replace the path with your path. I use Vim's support for directory vimrc using
exrc so I replace that path portion with .. But if you have a different
setup, you'll need to make sure it points to the vendor directory where you
installed the language server earlier.

Step 5: Test it out!

Go into your project, and try autocompleting a class or function name using
Ctrl+X Ctrl+O, the keyboard shortcut for Vim omnicomplete.

Backend or Frontend? Where should a fullstack dev start coding?

Camilo Payan — Thu, 03 Sep 2020 15:13:13 +0000

The other day, on Twitter, Angie Jones posted a very interesting poll about whether a full stack web developer would start writing a feature on the frontend or the backend.

// Detect dark theme var iframe = document.getElementById('tweet-1299205848007286784-551'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1299205848007286784&theme=dark" }

Interestingly most people responded that they would start on the backend code, which is also my preference. For me, I prefer to mock up the UI quickly on paper to get an idea of what’s needed, then write the backend, then write the frontend.

Either way, I think it’s interesting to see the pros and cons of each approach, so let’s start with the frontend.

Starting on the Frontend

To be clear, we’re talking about writing the HTML/CSS/JS to display your feature on a page.

1. Clarify your ideas

People mentioned being able to clarify the idea for what is needed. When you write the frontend, you will quickly get a very precise idea of exactly what data is going to be needed. This will clarify what database records you need, or what API calls you need, or if you need something new!

2. Deal with frontend uncertainties sooner

The frontend in web development can be a bit of a mess, with various browser differences and a large number of tools/dependencies that might be in use. It can be very useful to get those parts out of the way as quickly as possible.

Starting on the backend

1. Develop in peace

If you have trouble getting started, the backend can be a great place to start. Everything in that sandbox is usually under your control as the developer, so it may be easier to make progress.

2. You can always come back

Again, the generally controlled nature of the backend means that it’s easier to come back to the backend for tweaks if you realize something is missing as you develop the frontend later.

All in all, it’s really not an either-or proposition. Some repliers, like Martin Fowler, mentioned deciding based on where they felt there was the most uncertainty. I practice a version where I mock up the frontend first, then do the backend, then frontend. There’s no hard and fast rule to follow, especially since so much coding is exploratory.

Lint Your PHP in Vim

Camilo Payan — Tue, 02 Jul 2019 15:40:50 +0000

The objective of cleaning is not just to clean, but to feel happiness living
within that environment.

~ Marie Kondo

Everyone who has written PHP for a while ends up confronted with messy code. The gentle learning curve, the forgiving type system, and the easy execution model all lend themselves to writing PHP that's quick, dirty, and eventually frustrating.

In 2013, the PHP Framework Interoperability Group (PHP-FIG) adopted PSR-2, a standard for code which was intended to "reduce cognitive friction when scanning code from different authors." The result? Reading PHP code by different authors in different projects has never been easier. Whether you're diving into your workplace's proprietary code or Laravel's Eloquent ORM code, you'll find that it's readable (even if not quite understandable!).

Our goal here is going to be setting up automated tools in Vim to clean up your code as you write. By making it part of your regular flow and getting quick feedback, you'll be able to write your code with the confidence that in a year or two when you open up this file again, you'll still be able to read it!

If you clean your bathroom every day, you never have to clean your bathroom.

~ Lindy West's Mother, Shrill: Notes from a Loud Woman

We're going to take advantage of some existing tools: PHP-Code Sniffer
(PHP-CS) and PHP-CS-Fixer.

Installing PHP-CS

To add PHP-CS to your project using composer, run:

composer require --dev "squizlabs/php_codesniffer=\*"

By default, PHP-CS checks against the PEAR coding standard. However it ships with several other configurations, including PSR2. We can run PHP-CS to check for standards violations using the phpcs command.

./vendor/bin/phpcs --standard=PSR2 path/to/file

However, since we're also looking to standardize and automate this in our
project, we are going to create a file in our project that configures PHP-CS. The file that PHP-CS looks for is a phpcs.xml file.

<?xml version="1.0"?>
<ruleset name="Custom Standard" namespace="MyProject\CS\Standard">
  <description>Our custom coding standard based on PSR-2</description>
  <rule ref="PSR2"/>
</ruleset>

Since we're using the PSR-2 standard, our ruleset is pretty simple. The PHP-CS documentation shows many more options, including the ability to exclude some files or rules, or include rules from other coding standards.

Now when we run .vendor/bin/phpcs we're going to get the PSR-2 coding standard checked against every one of our files based on our phpcs.xml file!

Installing PHP-CS-Fixer

Generally we don't only want our computer to tell us when something is wrong, we can also get it to fix our coding issues for us! The tool for this is PHP-CS-Fixer.

Again we'll use Composer to install PHP-CS-Fixer

composer require --dev friendsofphp/php-cs-fixer

And we'll be able to run it using .vendor/bin/php-cs-fixer fix path/to/file.

We'll also create a .php_cs.dist file in our project so we can standardize the rules we're going to enforce. The file will look like this:

<?php

$finder = PhpCsFixer\Finder::create();

return PhpCsFixer\Config::create()
    ->setRules([
        '@PSR2' => true,
    ])
    ->setFinder($finder)
;

Integrating With Vim

To bring these tools into Vim, we're going to rely on the plugin ALE. ALE is capable of a lot of things, including linting (with PHP-CS), fixing (with PHP-CS-Fixer), and even deeper IDE-like features using the Language Server Protocol (going to get into that in a later post).

First, install ALE based on your own Vim setup.

Then we want to add some configuration so ALE knows where to look for our tools. Add the following to your project's .vimrc assuming you're using :exrc to allow for project-based vim configuration.

let g:ale_php_phpcs_executable='./vendor/bin/phpcs'
let g:ale_php_php_cs_fixer_executable='./vendor/bin/php-cs-fixer'
let g:ale_fixers = {'php': ['php-cs-fixer']}

And that should set up ALE with PHP-CS and PHP-CS-Fixer! PHP-CS should be running asynchronously, and the issues it finds will pop up as you type.

In order to run PHP-CS-Fixer, use the command :ALEFix in a file, which will run the fixer and write those changes.

You can also run the fixers every time you save by adding let g:ale_fix_on_save in your .vimrc file.

Moving in Vim

Camilo Payan — Tue, 25 Jun 2019 15:10:55 +0000

Moving in Vim

Everyone who’s tried Vim learns about the wonky hjkl keys to move around a file. These usually make a new user feel one of the only two emotions we need: anger and confusion.

What if I told you that there was a way to make moving around your code feel as smooth as a swan dive and as fast as thought, while making editing a cinch? That’s where Vim movements come in.

Vim movements are commands that move the cursor in some direction. The hjkl keys are all examples of movement commands. In their case, movements that go left, down, up, and right. Vim also has other motions built around text objects as well as the direction you want to go in. If you’d like to go to your next code block, instead of mashing the j key a few times, you can hit } to get to the next empty line, landing you right before your next block of code (you are spacing out your code for readability, right?). Swapping out several hits on the j button with a single } is both a time saver and a finger saver. It helps you get to where you need to be in the code as quickly as you can think.

You can learn about all the available Vim motions in the Vim help file motion.txt accessible by running :help motion.txt in command mode.

If we were only eliminating keystrokes, it would already be worth your time to learn. But Vim motions are composable. This means they can combine movements with Vim’s editing actions to make changes to your file.

Let's go back to our example about moving to a new code block. What if you wanted to delete everything up until your next code block? We already know that moving to the next blank line is }, so we can combine that with the delete command d to create d}. This will delete every line from where our cursor is up until the next blank line.

Now you aren’t only moving faster, you’re editing your file faster, too!

Motions and commands aren't only Vim and Neovim. Vim emulation layers like the IDEAVim plugin for JetBrains IDEs also have motions. The support for all motions might not always be there. My last experience with PHPStorm, for example, meant losing out on some motions. I missed those motions, and I went back to using Vim.

Vim motions and commands in normal mode are the language of Vim. When you learn to speak it, you’ll find that you can jump around files quicker than you ever thought possible.

Netlify Form Submissions With Golang Lambda Functions

Camilo Payan — Tue, 18 Jun 2019 16:44:20 +0000

Static websites are a great way to recapture some of the best parts of the history of the web. They provide low overhead and simple deployments. One of the things that a static website loses, however, is the ability to use your backend to handle form data. Netlify, a static site hosting service, solves this problem by leveraging AWS Lambda. AWS Lambda lets you run backend code without needing to host a whole application: you only run the code you need.

This tutorial will start by setting up a Netlify form. Next we’ll create the Lambda function that processes our form submission. Finally, we’ll deploy that on Netlify. Our use case is going to be a simple contact form that emails the submitter that their contact form was received.

Form Setup

Netlify Forms are forms that Netlify will handle automatically and they are already plenty powerful. By default, a form handled by Netlify has its data dumped into the Netlify admin area for your website, then that data is accessible either through the admin area or through the Netlify API. If you don’t need to do immediate work on your form data, that might be a good way to go!

Our contact form is going to need some basic information: name, email, and a message. To make a form a Netlify form, all we have to do is add data-netlify=true to our form element.

<form name="contact" method="POST" data-netlify="true">
  <p>
    <label>Your Name: <input type="text" name="name" /></label>   
  </p>
  <p>
    <label>Your Email: <input type="email" name="email" /></label>
  </p>
  <p>
    <label>Message: <textarea name="message"></textarea></label>
  </p>
  <p>
    <button type="submit">Send</button>
  </p>
</form>

Pretty simple, right? Now this information will get dumped into our Netlify admin area without any changes, but we want to email the form to the submitter and ourselves as well.

Forms and Functions

AWS Lambda functions give us the ability to run server-side code without needing to run a server. Netlify wraps up AWS Lambda for certain use cases with Event Triggers, mostly around deployments and service coordination. However, there is also a hook for form submissions! That gives us an in. Netlify supports Javascript or Go for these functions; we’re going to use Go.

For this we need some Go code to run, then a way for Netlify to build our Go code into the correctly named file, and then away we go!

Our use case is simple. We want to take the input from the contact form and mirror it back to the submitter, with ourselves BCC’d.

The requirements for a very basic Go function on Netlify are a main function that sets up your lambda handler, and that handler function. You can read the whole code for our function here: https://github.com/camilopayan/netlify-go-function-example/blob/master/main.go

Getting Form Data

Netlify injects the form data into the request body as part of a JSON object. If you’d like a more detailed look at the entire JSON object, then check out https://open-api.netlify.com/

For our use case however, we’ll be using Go’s built-in JSON Unmarshaler to change our request body into Go structs.

type Form struct {
    Name    string `json:"name"`
    Email   string `json:"email"`
    Message string `json:"message"`
}

type Payload struct {
    Form Form `json:"data"`
}

type Body struct {
    Payload Payload `json:"payload"`
}

By using nested structs, with fields tagged as their fields inside the JSON object, we can use json.Unmarshal to slurp our form data into a usable struct!

Getting Secret Data

If we’re going to send emails or plug into any 3rd party service (maybe you want to dump your customer information into Airtable!) then we need a secure way to get those secrets like API keys or SMTP credentials.

For this, Netlify provides Environment Variables, which will come along with your Function. You can set some variables in your netlify.toml file, but this is meant for build variables (npm versions and so on). Secrets should be stored via your Netlify admin dashboard. You can read more about environment vars in the Netlify docs.

To access those environment variables, you can use the built in Go os library.

port, _      := strconv.Atoi(os.Getenv("MAIL_PORT"))
host         := os.Getenv("MAIL_HOST")
senderemail  := os.Getenv("MAIL_SENDER_EMAIL")
smtppassword := os.Getenv("MAIL_PASSWORD")
smtpuser     := os.Getenv("MAIL_USERNAME")

Building Your Function

One of the coolest things about Netlify is its built-in continuous deployment pipeline. If it’s possible for you (using the latest Go), I recommend keeping your life easy and using Go modules.

First, locally you need to run go mod init to create your go.mod file and bring in your dependencies. Commit that to your git repo.

Next I use a Makefile with a very simple set of commands:

mkdir -p functions
go build -o functions/submission-created ./...

This creates the functions directory, where Netlify will look for any functions and also build your go files and compile them into one file called submission-created. You might remember from earlier that submission-created is one of the supported event-triggered functions.

You should also modify your netlify.toml file to run make build as part of your deployment.

With this, you should have enough base information to start writing your own form-crunching functions, all without having to lurch through the AWS Lambda documentation. Netlify Functions are more flexible than this, though, and you could even deploy Functions that implement a full API or just some RPC endpoints to hit from a JS frontend.