DEV Community: Clint Winter

Creating a Testable Facade in Laravel

Clint Winter — Sat, 28 Sep 2024 17:00:00 +0000

Here's a cheat sheet on how to make your simple service class more useful by adding dependency injection, a facade, and a way to easily swap in a fake.

The skeleton is simple:

The original service class
Create a contract the service class abides by
In a service provider, register the service class in the container
Create a facade
Create a fake implementation of the contract that can be swapped for testing

The original service class

Here's our original service class that we are starting with (apologies for not having a compelling example, but it isn't really necessary to contrive one for this).

<?php

namespace App\Foo;

class FooService
{
    public function foo(): string
    {
        return 'bar';
    }

    public function fizz(): string
    {
        return 'buzz';
    }
}

The contract

First, we should create a contract so we can ensure that our eventual fake and our original service both meet expectations. As well as any future implementations.

<?php

namespace App\Foo\Contracts;

interface Foo
{
    public function foo(): string;

    public function fizz(): string;
}

Don't forget to make sure the service implements it.

<?php

namespace App;

use App\Foo\Contracts\Foo;

class FooService implements Foo
{
   // ...
}

Binding to the container

Next, we should bind the concrete implementation to the contract in our service provider.

<?php

namespace App\Providers;

use App\Foo\Contracts\Foo;
use App\FooService;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     */
    public function register(): void
    {
        $this->app->bind(Foo::class, FooService::class);
    }

   // ...
}

The facade

Now, we can create our facade class.

<?php

namespace App\Foo\Facades;

use Illuminate\Support\Facades\Facade;

/**
* @method static string foo(): string
* @method static string fizz(): string
*/
class Foo extends Facade
{
    protected static function getFacadeAccessor(): string
    {
        return \App\Foo\Contracts\Foo::class;
    }
}

The facade simply needs the name of the binding it will pull from the container to be returned from getFacadeAccessor. In our case, that's the name of the contract that currently has our service bound to it.

Note that if you want IDE support, you'll have to re-define the method signatures in the doc block above the class.

At this point, we can use our facade.

Usage

<?php

namespace App\Http\Controllers;

use App\Foo\Facades\Foo;

class FooController extends Controller
{
    public function index()
    {
        return response()->json([
            'foo' => Foo::foo(),
        ]);
    }
}

Alternatively, we can also inject it as a dependency.

<?php

namespace App\Http\Controllers;

use App\Foo\Contracts;

class FooController extends Controller
{
   public function __construct(protected Foo $foo) {}

    public function index()
    {
        return response()->json([
            'foo' => $this->foo->foo(),
        ]);
    }
}

Faking the facade

Laravel often offers a neat way to easily fake its facades, e.g. Event::fake(). We can implement this ourselves.

All we have to do is create the fake implementation of our contract, then add the fake method to our facade.

<?php

namespace App\Foo;

use App\Foo\Contracts\Foo;

class FakeFooService implements Foo
{
    public function __construct(public Foo $actual) {}

    public function foo(): string
    {
        return 'fake';
    }

    public function fizz(): string
    {
        return 'very fake';
    }
}

In our fake implementation, we also create a public reference to the "actual" concrete class.

And here is our facade fake implementation. You can see we utilize that reference to actual.

<?php

namespace App\Foo\Facades;

use App\Foo\FakeFooService;
use Illuminate\Support\Facades\Facade;

/**
* @method static string foo(): string
* @method static string fizz(): string
*/
class Foo extends Facade
{
    public static function fake()
    {
        $actual = static::isFake()
            ? static::getFacadeRoot()->actual
            : static::getFacadeRoot();

        tap(new FakeFooService($actual), function ($fake) {
            static::swap($fake);
        });
    }

   // ...
}

A basic test

Now let's write a quick test that hits the controller example we created above.

<?php

namespace Tests\Feature;

use App\Foo\Facades\Foo;
use Illuminate\Testing\Fluent\AssertableJson;
use Tests\TestCase;

class FooTest extends TestCase
{
    public function test_foo(): void
    {
        $response = $this->get('/');

        $response->assertJson(fn (AssertableJson $json)
            => $json->where('foo', 'bar'));
    }

    public function test_fake_foo(): void
    {
        Foo::fake();

        $response = $this->get('/');

        $response->assertJson(fn (AssertableJson $json)
            => $json->where('foo', 'fake'));
    }
}

The tests are not useful but they show how easy it is to use our fake. In test_fake_foo we get foo=fake while test_foo returns foo=bar.

Taking testing further

The fun thing about fakes is that in our fake implementation, we can add extra methods to test anything we may find useful. For example, we could slap a counter in our fake's foo method that increments every time we call foo. Then we could add a method called assertFooCount where we can assert that the method was called as many times as we are expecting.

<?php

namespace App\Foo;

use App\Foo\Contracts\Foo;
use Illuminate\Testing\Assert;

class FakeFooService implements Foo
{
    public int $fooCount = 0;

    public function __construct(public Foo $actual) {}

    public function foo(): string
    {
        $this->fooCount++;

        return 'fake';
    }

    public function fizz(): string
    {
        return 'very fake';
    }

    public function assertFooCount(int $count)
    {
        Assert::assertSame($this->fooCount, $count);
    }
}

As you can see we use Laravel's Illuminate\Testing\Assert to make the assertion. Then our test can look like this.

public function test_incrementor(): void
{
    Foo::fake();

    Foo::foo();
    Foo::foo();
    Foo::foo();

    Foo::assertFooCount(3); // pass!
}

That's it!

Not everything needs a facade, but when you are building tools/packages that are used internally, a facade is often a strong pattern to rely upon.

Here's the repo with all the code: https://github.com/ClintWinter/laravel-facade-example

Digging into Laravel's Conditionable trait

Clint Winter — Thu, 09 May 2024 21:33:57 +0000

Conditionable is a trait that adds two methods to any class: when and unless. They are essentially syntactic sugar. They allow an unbroken chain of method calls that keep the reader from having to continually evaluate whether the next if-block they are looking at is doing anything other than continuing to work with the original object. Its value is most obvious when used by builder classes. A prime example is Eloquent.

A standard implementation of a query that has optional filter parameters would look like this:

<?php

class ContactController
{
    public function index(Request $request)
    {
        $query = Contact::query();
        $search = $request->query('search');

        if ($search) {
            $query->where('first_name', 'like', '%' . $search . '%')
                ->orWhere('last_name', 'like', '%' . $search . '%');
        }

        $contacts = $query->get();

        return view('contacts', ['contacts' => $contacts]);
    }
}

There's nothing wrong with the above solution, to be sure. However, I've seen some mighty complex queries in my time — when there are many conditionals happening, it becomes very confusing to follow along to a conclusive end result.

This is where the Conditionable trait shines! It provides the benefit of keeping all the context of the query in a single chain of events. You see the single block of code and know that it all is related.

Two or three argument variant

There are multiple "variants" of the when method. The method works differently based on the number of arguments, sort of like a poor man's method overloading.

The two to three argument variant is the most commonly seen variant. The first argument is the predicate — the condition being evaluated for true/false. The second argument is the consequent — the callback that's executed when the condition is truthy. The third and optional argument is the alternative — the callback that's executed when the condition is falsy.

$conditionable->when(
    true,
    fn ($cond) => $cond->consequent(),
    fn ($cond) => $cond->alternative(),
);

Here is the previous example re-written using the two argument variant of when afforded by Conditionable:

<?php

class ContactController
{
    public function index(Request $request)
    {
        $contacts = Contact::query()
            ->when($request->query('search'), fn (Builder $query, $search)
                => $query->where('first_name', 'like', '%' . $search . '%')
                         ->orWhere('last_name', 'like', '%' . $search . '%'))
            ->get();

        return view('contacts', ['contacts' => $contacts]);
    }
}

All the logic for building our query is now in a single chain. You'll also notice that the predicate of our condition ($request->query('search')) is provided back to us in the callback ($search), so we don't have to declare an intermediate variable or re-write the expression.

One argument variant

We are going to talk about how this variant and the zero argument variant work in a bit, but first let me explain what they look like.

Here's the syntax:

$conditionable->when(true)->consequent();

The one argument variant moves the consequent from the second argument position of the when method to being chained directly after when. Take a look at this example to see what I mean.

$email = $request->query('email');

$query->when($email)->where('email', $email);

->where('email', $email) is only called if ->when($email) evaluates to true. This variant makes sense if you are calling a single method if the predicate is true.

Zero argument variant

This one is even more niche than the last variant. It looks like this:

$conditionable->when()->predicate()->consequent();

And using a real example, like this:

now()->when()->isWeekend()->nextWeekDay();

We call when(), and we evaluate isWeekend() for truthiness. If truthy, we call nextWeekDay(), otherwise skip it.

Like I said, very niche, but neat if you recognize an opportunity.

Higher-order message

So what black magic is powering this overloaded little trait?

The answer is higher order messages (or proxies).

A higher-order proxy is a shortcut that allows you to chain directly to the method name when doing a basic function.

You may have been using Laravel for years without being aware of their existence, but Laravel uses them everywhere.

HigherOrderWhenProxy — used in Conditionable like we just covered.
HigherOrderCollectionProxy — used by collections, e.g. $collection->map->name.
HigherOrderTapProxy — used by the tap helper and therefor by the Tappable trait.

How does it work?

Well, they work thanks to ✨magic✨. No, seriously — PHP magic methods to be exact. First let's look at Conditionable's when method, and then we can dive into the proxy class.

public function when($value = null, callable $callback = null, callable $default = null)
{
    $value = $value instanceof Closure ? $value($this) : $value;
    if (func_num_args() === 0) {
        return new HigherOrderWhenProxy($this);
    }

    if (func_num_args() === 1) {
        return (new HigherOrderWhenProxy($this))->condition($value);
    }

    if ($value) {
        return $callback($this, $value) ?? $this;
    } elseif ($default) {
        return $default($this, $value) ?? $this;
    }

    return $this;
}

Focusing on the first two if-blocks, we can see the one and zero argument variants are handled here. And those are the ones that use the HigherOrderWhenProxy.

As you can see, the one argument variant uses the value passed to when as the condition, while the zero argument variant does not set a condition because we didn't provide one!

Now let's look at HigherOrderWhenProxy and see how it handles it (once again, comments removed for brevity).

<?php

namespace Illuminate\Support;

class HigherOrderWhenProxy
{
    protected $target;

    protected $condition;

    protected $hasCondition = false;

    protected $negateConditionOnCapture;

    public function __construct($target)
    {
        $this->target = $target;
    }

    public function condition($condition)
    {
        [$this->condition, $this->hasCondition] = [$condition, true];

        return $this;
    }

    public function negateConditionOnCapture()
    {
        $this->negateConditionOnCapture = true;

        return $this;
    }

    public function __get($key)
    {
        if (! $this->hasCondition) {
            $condition = $this->target->{$key};

            return $this->condition($this->negateConditionOnCapture ? ! $condition : $condition);
        }

        return $this->condition
            ? $this->target->{$key}
            : $this->target;
    }

    public function __call($method, $parameters)
    {
        if (! $this->hasCondition) {
            $condition = $this->target->{$method}(...$parameters);

            return $this->condition($this->negateConditionOnCapture ? ! $condition : $condition);
        }

        return $this->condition
            ? $this->target->{$method}(...$parameters)
            : $this->target;
    }
}

Fix your eyes on the __call method here.

__call, as I said earlier, is a poor man's method overloading. __call is triggered whenever we attempt to invoke a method that does not exist on the object that implements it. It takes the method name being invoked and its arguments and you can do whatever you want with it!

The __call method diverges into two distinct branches here.

The first branch is the if-block, ! $this->hasCondition. The zero argument variant does not have a condition. It calls the $method on the $target (in our original example, the target was now() and the method was isWeekend()).

Here's something clever: they call their condition method with the result of the method call and return it. condition() returns $this and acts as a form of recursion because then the following method will only be called (nextWeekDay) if that previous method (isWeekend) was true.

The second branch is the final return statement which, as you can see, simply calls the method if the condition is true. The condition was provided in the when method when it was called.

And that is how the when proxy works! This blew my mind when I first dug into it. So much power in a couple miniscule files. This is what makes Laravel great in my opinion — truly embodying the artisan ethos.

How to implement yourself

The awesome thing about many of these internal patterns, including Conditionable, is that you don't have to do almost any leg-work. To use the power of the Conditionable trait, add it to a class that you think it would benefit.

The caveat is to not get carried away with it since it's so fun to use. Personally, I would reserve its use to Builder pattern classes, or classes that have a large API surface area where many method calls are expected behavior. Other examples where Laravel uses Conditionable are in collections, Carbon, and pending batches.

Conclusion

Some developers operating from a different set of ideals do not like Laravel because of its use of magic like we've seen in this article. Whether you should like it or not is for you to decide. Either way, Laravel has some interesting patterns under the hood, and I encourage you to take the time to look below the surface and understand them. You'll learn a lot, and it'll make you a better developer.

Resources

Use Guard Clauses for Cleaner Code

Clint Winter — Mon, 28 Mar 2022 16:24:52 +0000

The guard clause is a nifty pattern that provides a super-simple way to clean up your code. Their main function is to terminate a block of code early, which reduces indentation of your code and therefore makes your code much easier to read and reason about.

Too often, I see entire method bodies wrapped in if-statements. Every time your code is indented another level, you are adding another piece of context that must be kept track of mentally while reading the code.

Let's look at a simple function that doesn't use the pattern.

function update($contact, $data) {
  if (valid($data)) {
    $contact->update($data);
  }
}

With such a simple example it may not seem like a big deal (and it probably isn't), but let's see what refactoring to a guard clause looks like anyway.

function update($contact, $data) {
  if (! valid($data)) {
    return;
  }

  $contact->update($data);
}

This is the essence of the guard clause. Reducing indentation, which reduces complexity and unnecessary context, and increases visibility of what the function is meant to do.

Let's get right into a more complex piece of code to really see where it shines.

if (! is_null($subscribed)) {
    if ($email = $contact->email) {
        $updated = Contact::query()
            ->where('email', $email)
            ->where('is_subscribed', ! $subscribed)
            ->update([
                'is_subscribed' => $subscribed,
            ]);

        if ($updated) {
            if ($subscribed) {
                event(new Subscribed($email));
            } else {
                event(new Unsubscribed($email));
            }
        }
    }
}

What's awesome about the guard clause is we can take the code here, which, at some points, gets 4 if-statements deep, and reduce it to a single indentation.

The steps to do this are simple:

Invert the if-statement to check for the opposite condition.
Terminate the if-statement before the rest of the code with a return statement inside of it.
Repeat.

The only time this isn't doable is if the if has an else or if there are elseif's.

Let's see one step at a time. First, we will take the if-statement in the first line and turn it into a guard clause.

if (is_null($subscribed)) {
    return;
}

if ($email = $contact->email) {
    $updated = Contact::query()
        ->where('email', $email)
        ->where('is_subscribed', ! $subscribed)
        ->update([
            'is_subscribed' => $subscribed,
        ]);

    if ($updated) {
        if ($subscribed) {
            event(new Subscribed($email));
        } else {
            event(new Unsubscribed($email));
        }
    }
}

Instead of continuing when $subscribed is not null, we terminate when it is null. Mentally, we can now discard this information so we can focus on what the code is doing. However, once again, the code after our new guard clause is wrapped entirely in an if-statement. Let's repeat the process.

if (is_null($subscribed)) {
    return;
}

if (! ($email = $contact->email)) {
    return;
}

$updated = Contact::query()
    ->where('email', $email)
    ->where('is_subscribed', ! $subscribed)
    ->update([
        'is_subscribed' => $subscribed,
    ]);

if ($updated) {
    if ($subscribed) {
        event(new Subscribed($email));
    } else {
        event(new Unsubscribed($email));
    }
}

We've reduced another level of indentation! Now if the contact doesn't have an email, we won't subscribe them. Terminated. We are getting to the core of what this function is actually accomplishing and less focused on what the edge cases are. So much easier to read.

If you look at line 16 above (if ($updated) {), you'll see another chunk of code inside a single if-statement. You guessed it--we are adding a guard clause.

if (is_null($subscribed)) {
    return;
}

if (! ($email = $contact->email)) {
    return;
}

$updated = Contact::query()
    ->where('email', $email)
    ->where('is_subscribed', ! $subscribed)
    ->update([
        'is_subscribed' => $subscribed,
    ]);

if (! $updated) {
    return;
}

// a little extra sugar for fun ;)
$event = $subscribed ? Subscribed::class : Unsubscribed::class;
$event::dispatch($email);

And look at that. We've completely reduced a 4x indented block of code to a single indentation. In my opinion, our result is much more readable.

Since I discovered this pattern I've found places to refactor to it or use it just about every day.

I hope you find it as useful as I do. Good luck!

Laravel's "rescue" Helper Function is Amazing

Clint Winter — Mon, 28 Mar 2022 16:23:41 +0000

The rescue function is an alternative to the traditional try/catch block syntax required when you want to manually handle a thrown exception. It takes a callback and executes it inside of a try block for you. The result of the callback will be returned if no exception is thrown.

Let's look at a typical use-case of a try/catch block.

$country = 'USA';

try {
    $alpha2 = (new ISO3166)->alpha3($country)['alpha2'];
} catch (\Exception $e) {
    $alpha2 = null;
}

What an ugly piece of code for something that is really quite simple.

`rescue` to the rescue

Now let's see that using our fancy new rescue function.

$alpha2 = rescue(fn () => (new ISO3166)->alpha3($country)['alpha2']);

What happens here is when the callback executes without an exception being thrown, what's returned from the callback is assigned to our $alpha2 variable. If an exception is thrown, $alpha2 is assigned null.

But what if you don't want the value to be assigned null? Well, you have some options.

First, you can return a different value. For example, you may want to get false back instead. That's where rescue's second parameter comes in:

$isFalse = rescue(function () {
  throw new Exception;
}, false);

Second, you can make the second parameter a callback, where you can do anything you'd normally do inside of a catch block, and whatever is returned from that callback is returned from rescue if an exception is thrown. You'll even get the exception as an argument to your callback.

rescue(function () {
  throw new Exception;
}, function ($e) {
  // do exception related stuff

  return false;
});

// => false

I don't think this function adds a ton of utility when you're in a situation where you're passing two callbacks to it. However, when you just want to attempt to do something in your first callback and get a different value if it fails, rescue is a handy little helper function.

In my opinion, functions like rescue are what make programming fun. They strip away the syntax-y parts that are distracting, and can leave you with a clean block of code that focuses on what it's actually doing. It's the epitome of clean code. A simple, reusable, beautiful, little function that allows you to ditch the hideousness of the try/catch block when you can.

For your reading pleasure, here is a real, live coding sample that I've written.

public function getCountryByFormat(string $country, CountryFormat $format): array|null
{
    return rescue(fn () => match ($format) {
        CountryFormat::NAME    => (new ISO3166)->name($country),
        CountryFormat::ALPHA_2 => (new ISO3166)->alpha2($country),
        CountryFormat::ALPHA_3 => (new ISO3166)->alpha3($country),
        CountryFormat::NUMERIC => (new ISO3166)->numeric($country),
    }, null, false);
}

NOTE: That third parameter of false tells the function not to report the exception to the error logger. Since we are kind of expecting this exception, we don't want to report it. Watch out for that potential gotcha.

For comparison's sake, here's what it would look like in a try/catch block.

public function getCountryByFormat(string $country, CountryFormat $format): array|null
{
    try {
        return match ($format) {
            CountryFormat::NAME    => (new ISO3166)->name($country),
            CountryFormat::ALPHA_2 => (new ISO3166)->alpha2($country),
            CountryFormat::ALPHA_3 => (new ISO3166)->alpha3($country),
            CountryFormat::NUMERIC => (new ISO3166)->numeric($country),
        };
    } catch (\Exception $e) {
        return null;
    }
}

A pretty sweet improvement if you ask me. Thanks Taylor Otwell!

Now that you know about rescue, I expect you'll be using it all over the place like me. Enjoy!

Don't Use Service Classes with Static Methods

Clint Winter — Mon, 28 Mar 2022 16:22:42 +0000

A service class in the context of this post is a class used to encapsulate domain logic. When creating an endpoint to create a new blog post, for example, many will opt to put the core logic of creating that new post inside of a service class method rather than operate directly in the controller.

The reason developers choose to encapsulate that logic is usually to be able to reuse it in other places within the project. For instance, when creating a blog post may be possible through their front-end implementation or their API.

Why static methods are used in the first place

It's hard to determine exactly why this pattern is used, but my guess would be this: It resembles a clean design (like a Facade pattern could provide) without the overhead. Instead of writing out the boilerplate to turn the class into a usable facade, it's easier to drop a static keyword in front of the method. And just like a facade, it looks clean. You don't have to do any ugly dependency injection.

class PostService
{
  public static function create()
  {
    // do some creating...
  }
}

class PostController
{
  public function store(Request $request)
  {
    // validate and whatever else...
    PostService::create($request->all());

    return back();
  }
}

Doesn't that look awesome?

Why you shouldn't do it

Testing.

You are going to have a hell of a time trying to test anything that utilizes these service classes. Let's say you're testing a controller method that uses a service. That service does a lot of complex logic behind the scenes. You'll have to arrange everything that the service needs to execute without failure from within your test. All just to test this other unrelated thing.

There are ways (sorta) to mock a static method, but is not recommended, which is even stated directly in the Mockery documentation.

The moral of the story is, save yourself a lot of headaches down the road and stick with good, old-fashioned dependency injection. With Laravel, using the container to auto-resolve all of your dependencies is a cinch anyway.

The easiest alternative

class PostController
{
  public function store(Request $request, PostService $service)
  {
    // validate and whatever else...
    $service->create($request->all());

    return back();
  }
}

Let's be honest, the code block above isn't much worse, especially when you think about how much easier testing will be.

How to test

Laravel leverages the container to auto-resolve your dependencies, so they've provided a way to hijack that and sub in a mocked version.

$this->mock(PostService::class, function (MockInterface $mock) {
    $mock->shouldReceive('create')->once();
});

Write Tests Early and Often

Clint Winter — Mon, 28 Mar 2022 16:20:05 +0000

I have a project that I've worked with on and off for the last few years. Writing tests was not a part of my work flow when I started it back then. As the project has grown to have more functionality, I have found that the tests I didn't write are causing my development speed and my trust in the code to plummet.

Writing tests is important, but writing them early is even more important. A young project is not going to have established or well-defined code. You will want to change the way it works and you'll end up breaking things. The only way you're going to know that is with tests. I can't tell you how many times I've decided I didn't like an implementation and changed it. Every time I've done it, some part of the functionality was left unaccounted for and broken.

You end up in a circular situation where, with every change you make, you're forced to click around your project and make sure everything still works. With tests, all you have to do is trigger the test suite. That makes for the best argument against those that believe writing tests is a waste of time. When compared to all of the manual testing that must be done, tests improve your development speed immensely, and that speed increases non-linearly as the project grows.

When you're building some little to-do app, of course testing feels like a pointless endeavor. The bigger the project gets, the more you're going to resist going back and writing all those tests. The problem is, eventually, the drain of having to check your project after every change will outweigh your desire to make those changes, and you will end up abandoning the project.

Once you're working on something significant, you'll see the benefit testing provides. I've worked at companies with large projects that both did no testing at all and encouraged writing tests.

The non-testing company's code-base was always riddled with bugs. We had a full-time QA person, and boy were they busy. Every bug fix had a chance to introduce new bugs, so we were constantly forced to spend a ton of time clicking around to make sure things worked (but the bugs always showed up). Our developers all had to have a mental checklist of things to watch out for that would constantly cause bugs. Imagine we just wrote that checklist out with tests. We would no longer have the cognitive load of keeping those things in mind. We'd never have to worry about that bug cropping up. It would just be tested to ensure correctness.

In contrast, at my current company that encourages writing tests, the user-base is much larger by, I'd guess, at least 100x and we see bugs much less regularly. And when we fix bugs, we add a test and never see it again.

So write those tests early, and write them often!

Advice for Aspiring Developers

Clint Winter — Mon, 28 Mar 2022 16:19:37 +0000

I recently received a message from someone looking to become a developer, who wanted general advice on the road ahead with no degree. This is what I said.

Everyone is going to have a different path, so I suggest getting your mind right and the rest will follow.

Don't give up, this stuff is hard. But if you keep coming back you'll make it far.
Once you find a direction, stick with it and don't let other people shake you. For example, I am a back-end dev working in Laravel/PHP and if I listened to people who said PHP was a stupid, dead language I'd have switched to another framework and put myself further back relearning things.
Don't get suck in tutorial hell. It's easy to watch videos all day and have nothing stick. Make yourself build things and learn to fail. When you hit a wall, do research to find out how to do it, then keep going. Practice is the fastest way to really learn.
Focus on the fundamentals. Read books about Clean Code, SOLID principles, refactoring, OOP/functional programming, design patterns, architecture, etc. Those are the skills that transfer beyond this new framework or that hot new library. The concepts transfer everywhere and will allow you to learn new skills much much faster because you'll see the patterns underneath.

A Cleaner Code Case Study

Clint Winter — Fri, 11 Sep 2020 15:01:18 +0000

I recently had a situation at work where a coworker tried to modify a JavaScript function I wrote, but ended up introducing some bugs. In reviewing their code, it seemed their issue was not fully understanding what the function was doing, but I believe it was my fault because the function was, frankly, poorly written.

Sometimes we have deadlines, and, in order to meet them, we may leave things a mess. I had plans to revisit it, but of course other things took priority. Now that the function was back knocking on the door, I saw an opportunity to fix it.

Often when we share our code with the world, we share our most meticulously maintained material. That is not the reality of a business all the time. At the end of the day, the product and the customers that use it are the priority. When it comes to deadlines vs perfectly clean code, the deadline wins. However, when we get the chance to go back and clean up after ourselves, we should take those opportunities because it's important we balance production with our capacity to continue producing.

I'm going to attempt to remedy the diseased function in steps in order to give you an example of how I go through the process of improving code.

The original code

Let's now look at the original function that gave my fellow developer problems.

function valid(field, visibleField) {
   var state = {
      saved: true,
      requirements: {
         Description: {
            required: true,
            maxlength: 150
         },
         DueDate: {
            date: true
         },
         PriorityID: {},
         TypeID: {}
      }
   };

   if (!state.requirements[field.name]) {
      return true;
   }

   var errorField = visibleField ? visibleField : field;

   // required
   if (state.requirements[field.name].required) {
      if (field.tagName.toLowerCase() == 'input' && field.value.length == 0) {
         errorField.classList.add('inputBorderError');
         return false;
      } else if (field.value === undefined || field.value === '') {
         errorField.classList.add('inputBorderError');
         return false;
      }
   }

   // max length
   if (state.requirements[field.name].maxlength) {
      if (field.value.length > state.requirements[field.name].maxlength) {
         errorField.classList.add('inputBorderError');
         return false;
      }
   }

   // date
   if (state.requirements[field.name].date) {
      if (!moment(field.value, ['MM/DD/YYYY', 'YYYY-M-D'], true).isValid()) {
         errorField.classList.add('inputBorderError');
         return false;
      }
   }

   errorField.classList.remove('inputBorderError');
   return true;
}

Let me also provide some simplified HTML so you can see a sample of the function's usage.

<form id="myForm">
    <div>
        <input 
            name="Description" 
            type="text" 
            oninput="
                if (valid(this)) { 
                    edit(this); 
                }
            "
        >
    </div>

    <div>
        <input 
            name="DueDate"
            type="text"
            oninput="
                if (valid(this, document.getElementById('myForm'))) { 
                    edit(this); 
                }
            "
        >

    </div>

    <button type="submit">Submit</button>
</form>

The function is decently complex, so let's go over it to make sure we understand what's happening. We have a valid() function that takes in the parameters field and visibleField. This is used within the context of an HTML form, so the two parameters are HTML elements. We see a variable immediately declared called state. It has a saved property and a requirements property.

One of the immediate issues you may notice is that the saved property in state isn't even used. Instead of confusing you by explaining it's original purpose, let's just accept that the there was a plan for it on initial development that was since abandoned, making the saved property an artifact of an old design (it never was cleaned out).

The keys in the requirements property in the state object are mapped to field names in the form (Description and DueDate are in our HTML form). The requirements properties' values, which are objects, map to different validations we want to perform on the field. For example, if we have...

// ...
requirements: {
   Description: {
      required: true,
      maxlength: 150
   },
   // ...
}

...our max length if-block catches it and returns false if it fails.

// max length
if (state.requirements[field.name].maxlength) {
   if (field.value.length > state.requirements[field.name].maxlength) {
      errorField.classList.add('inputBorderError');
      return false;
   }
}

We can also see that the function handles displaying the error by adding a class to an element (errorField.classList.add('inputBorderError')). If a visibleField element is provided, that is what the error is displayed on, otherwise it uses the primary field element.

If the field passes through all of the validation rules that apply to it without returning false, the function eventually returns true, so the function always returns a boolean.

Now that we have a basic understanding of how this function works, let's clean it up.

Refactoring

Note: Before we continue, I invite you to make an attempt at improving this function on your own. Feel free to share your solution in the comments along with details of why you did what you did—it might be better than mine!

First, let's start with something easy. As I said earlier, the saved property in state is no longer a part of the solution, so let's remove that.

function valid(field, visibleField) {
   var state = {
      // saved: true,
      // ...
   };
   // ...
}

Second, I don't like that this function is handling the displaying of errors when the validation fails. That's an "invisible" side-effect that makes this function deceptive, and something we should try to avoid as much as possible. Nobody would know that this function does that unless they read the contents of the function, which someone shouldn't need to do every time they need it. The function is called valid, not validateAndDisplayErrors. It's also an extra responsibility, and we want our functions to be focused. Let's remove the error handling altogether.

function valid(field) {
   var state = {
      requirements: {
         Description: {
            required: true,
            maxlength: 150
         },
         DueDate: {
            date: true
         },
         PriorityID: {},
         TypeID: {}
      }
   };

   if (!state.requirements[field.name]) {
      return true;
   }

   // required
   if (state.requirements[field.name].required) {
      if (field.tagName.toLowerCase() == 'input' && field.value.length == 0) {
         return false;
      } else if (field.value === undefined || field.value === '') {
         return false;
      }
   }

   // max length
   if (state.requirements[field.name].maxlength) {
      if (field.value.length > state.requirements[field.name].maxlength) {
         return false;
      }
   }

   // date
   if (state.requirements[field.name].date) {
      if (!moment(field.value, ['MM/DD/YYYY', 'YYYY-M-D'], true).isValid()) {
         return false;
      }
   }

   return true;
}

That allowed us to get rid of our second parameter, making our function that much simpler.

Third, while we are removing responsibilities, let's remove another one. For some reason this function is hard-coding an object that holds the validation rules for one specific form with our state variable. Let's remove that and make each function call pass the validation rules in for that element. Unfortunately, that means adding a second parameter back in.

function valid(field, validationRules) {

   if (validationRules === undefined || validationRules === '')
      return true;

   // required
   if (validationRules.required) {
      if (field.tagName.toLowerCase() == 'input' && field.value.length == 0) {
         return false;
      } else if (field.value === undefined || field.value === '') {
         return false;
      }
   }

   // max length
   if (validationRules.maxlength) {
      if (field.value.length > validationRules.maxlength) {
         return false;
      }
   }

   // date
   if (validationRules.date) {
      if (!moment(field.value, ['MM/DD/YYYY', 'YYYY-M-D'], true).isValid()) {
         return false;
      }
   }

   return true;
}

So now our usage looks like this:

<input 
   name="DueDate"
   type="text"
   oninput="
       if (valid(this, {date:true})) { 
           edit(this); 
       }
   "
>

Fourth, one thing that's bugging me now is the function being dependent on the HTMLElement interface. That's not good for testing, and it's an unnecessary dependency because the field is no longer being used to handle errors. We are wrestling with different tag types in some instances in order to ultimately get the element's value, so let's just pass the value in directly and rid ourselves of that cumbersome burden.

function valid(value, validationRules) {
    if (
        (typeof validationRules === 'object' && Object.keys(validationRules).length === 0)
        || validationRules === undefined
        || validationRules === ''
    ) {
        return true;
    }

    // required
    if (validationRules.required) {
        if (!! value)
            return false;
    }

    // max length
    if (validationRules.maxlength) {
        if (value.length > validationRules.maxlength)
            return false;
    }

    // date
    if (validationRules.date) {
        if (!moment(value, ['MM/DD/YYYY', 'YYYY-M-D'], true).isValid())
            return false;
    }

    return true;
}

This function has improved dramatically from when we started. If you stopped here, you could feel pretty confident in trusting it to accomplish what it needs to. I'm going to take it a little further though.

Fifth, these if-statement blocks feel primitive. I think we can do better. They lack clarity and readability. Instead what I want to do is break these "validators" out into their own functions so that if we want to edit one or add to them, we only need to modify a small part. This allows us to leave our main function that performs the validation alone.

The thought process I'm describing is derived from the SOLID principles. The O in SOLID is the Open-Closed Principle—open for extension, closed for modification. That means we want to make it easy to extend our validation function by being able to add validators without modifying the existing code. It's also the S for Single Responsibility Principle because we are breaking our one big function down into smaller immutable methods that have only a single reason to change.

I still want to keep the function self-contained; see if you can follow what I'm going to do. I want to keep my validator methods within the valid function. Let's pull our validators into their own methods in a local object validators.

function valid(value, validationRules) {
    var validators = {
        required: function(value, parameter) {
            if (!! value)
                return {rule:'required', message:'This field is required.'};

            return false;
        },

        maxlength: function(value, parameter) {
            if (value.length > parameter)
                return {rule:'maxlength', message:'Maximum length is ' + parameter + ' characters.'};

            return false;
        },

        date: function(value, parameter) {
            if (!moment(value, parameter, true).isValid())
                return {rule:'date', message:'Not a valid date format, must match ' + parameter + '.'};

            return false;
        }
    };

   // ...
}

We updated the validators to each return an error object with the rule that failed and a default message the user may want to display. Since we aren't handling the errors in-house anymore, we want to hand back the most information we can that gives the most flexibility to the user. There is a difference between the function doing work that has invisible side-effects and returning data that doesn't do any work on its own.

Sixth, let's rework the logic that checks if our value is valid or not based on the validation rules.

function valid(value, validationRules) {
    var validators = {
        //...
    };

    // bug fix here
    if (validationRules.required === undefined && !value)
    return [];

    var errors = [];
    var result;
    for (var rule in validationRules) {
        result = validators[rule](value, validationRules[rule]);
        if (result) errors.push(result);
    }

    return errors;
}

Now our valid function returns an array instead of a boolean—it will return an empty array if there are no errors, or an array of our error objects that failed validation.

While rewriting this part I found a bug—if the validationRules parameter doesn't include a required property, then we shouldn't bother checking the other rules when the value is empty. I labeled the fix above with the "bug fix here" comment.

To process our rules, we simply loop through the properties of the validationRules parameter and invoke the corresponding validator. If the result that comes back evaluates to true (because it's an object when validation fails), then we push it into the errors array.

Note: I'm aware there are a lack of catches for handling potential issues such as using a non-existant validator in the validationRules, but I want to keep the example straightforward for learning purposes.

Seventh, you may be thinking "Hey, every time you call this function you are re-defining every validator method!" Great catch if you did! It's inefficient to ask the valid() function to define the validators object with all of its methods every time the function is called, so I'm going to turn valid into a variable and assign it to an immediately-invoking, anonymous function that returns a closure. This keeps the validators in the local scope, creates them only one time, and allows me to continue using valid the same way.

var valid = (function() {
    var validators = {
        required: function(value, parameter) {
            if (!! value)
                return {rule:'required', message:'This field is required.'};

            return false;
        },

        maxlength: function(value, parameter) {
            if (value.length > parameter)
                return {rule:'maxlength', message:'Maximum length is ' + parameter + ' characters.'};

            return false;
        },

        date: function(value, parameter) {
            if (!moment(value, parameter, true).isValid())
                return {rule:'date', message:'Not a valid date format, must match ' + parameter + '.'};

            return false;
        }
    };

    return function(value, validationRules) {
        if (validationRules.required === undefined && !value)
        return [];

        var errors = [];
        var result;
        for (var rule in validationRules) {
            result = validators[rule](value, validationRules[rule]);
            if (result) errors.push(result);
        }

        return errors;
    };
})();

That's going to be our final refactor. Let's see how the client utilizes our function now.

<div id="DescriptionContainer">
    <input
        name="Description"
        value="text"
        oninput="
            var errors = valid(this.value, {required:true, maxlength:20});

            if (errors.length) {
                var elErrors = this.nextElementSibling;

                var messages = errors.map(error => error.message);
                elErrors.innerHTML = errors.join('<br>');
                elErrors.classList.remove('hidden');
            } else {
                elErrors.classList.add('hidden');
                elErrors.innerHTML = '';
            }
        "
    >

    <div class="errors hidden"></div>
</div>

We now check the length of the array coming back from the function call to determine if there are any errors. If there are, we can get the element we want to display error messaging in and list the errors in it and display it.

Review

You may be thinking that the way we interact with this function became more complicated since we started, and you're right. However, our goal here was to fix up a specific function. That involves removing the other responsibilities it had that shouldn't have been there. Right now that means we moved that responsibility to the client, but that doesn't mean we can't write another function that uses our valid function to handle errors for us.

What we can do is use our new valid function as a building block for higher-level functions. If we want to have a function that intentionally has the side-effect of displaying errors, we can utilize our valid function within that. But we keep the validation part decoupled from other responsibilities, such as displaying errors.

We also reduced dependencies within the function which greatly expands the usability and flexibility of it. For example, removing our dependency on the HTMLElement interface allows us to use this function for data coming back from an AJAX call before displaying it, which wasn't possible before.

In breaking out the validators and giving each section a single responsibility, we made the function way easier to work with for our future selves and others first getting familiar with it. If we want to add a new validator method, we can see what the input and output of the others are and copy it, or look at how our main processing loop works with them to know how to implement it (In an OO language the validators would likely implement a Validator interface).

When we build a culture of high coding standards where we can assume a function named valid is only performing validation, we increase trust from the developers working with the code because they don't have to read the contents of every new function they come across to make sure there aren't invisible side-effects or other strange interactions happening. We liberate a significant amount of time and brain-power because of this. The less time spent getting reacquainted with messy, complex functions, the more time spent on better things like new features, learning new skills, and more.

Working Toward Your First Job: Mindset

Clint Winter — Thu, 27 Aug 2020 12:09:35 +0000

Reaching a goal like becoming an employed, self-taught developer is a major accomplishment. Once you do something as substantial as that, you realize that there is nothing you can't do. The level of empowerment that comes out of that enables you to go after any lofty goal you want without hesitation. You learn to get out of your own way and enjoy the process for what it is instead of calling your competence into question at every step.

The positive feedback loop is incredible once you get that first accomplishment. That accomplishment for you is getting that first job and validating you as a developer. To do that we have to get your mind right. Without it, this process can wreak havoc on you with stress, frustration, and decimated confidence. So please allow me to take you through some different mindsets that have been crucial for my success. These will help you from the learning process all the way to the negotiation process.

Persistence

Failure is unavoidable. You will get stuck trying to learn a new concept. You will be ignored or rejected by recruiters or employers. Your work will be criticized when exposed to the public. The only way to beat failure is to not let it beat you. The answer is always "be persistent" (when a different direction altogether is not the answer).

When you are stuck learning a concept and you feel the frustration building, take a break. Then come back and look at it again. Find another source that explains it differently. Try implementing it on your own to gain perspective. Reread the content over and over. Whatever it takes—just don't quit.

You only fail if you don't persist. Have you ever heard of someone being stuck forever? Do you know any developers who have said, "I'd love to get a job eventually, but I've been stuck in if-statement hell for 14 months and I just can't figure it out!" Of course not. There's power in knowing that the only thing you have to do is never let failure stop you completely.

You are a great white shark...

...and not only because you scare everyone that sees you. It's because great whites must continue to swim in order to respire or they die (I googled it, so trust me). This is how you have to think about yourself as a developer. To survive you need to perpetually learn, adapt, and improve. The cliche about "being forever a student" is a cliche for a reason.

This industry moves quickly, so that's the life you are signing up for. For some that's a dream come true, but for others a nightmare. If it sounds like a nightmare to you, a different direction might be what you need.

Strong opinions held loosely

The day your thinking becomes dogmatic and ideological is the day you stop growing. While you have your opinion, use it with confidence. Be open to opposition when it is presented, and, if it's convincing, replace it. The last two sentences are not mutually exclusive. In fact, if you notice that you hold an opinion that seems shaky, be proactive and go find something to unseat it before it deals damage.

You are a scientist

That's correct, you are now a shark AND a scientist—things are getting complicated around here. Experimentation is essential in figuring out the best way to do just about anything. For your learning, try doing a video course. For that course try taking notes, try not taking notes and listening carefully, try 1.5x speed, try 0.75x speed, try stopping and practicing after each video, after each section, or at the end of the course. Try reading articles, or books, or discussion with peers. When creating your resume try making it as short as possible, try fluffing it up a bit, try focusing on your credentials, or on your accomplishments, or on the results and the hard data.

You will never learn as much about yourself as when you conduct experiments. You may be missing out on a learning medium that is more effective by a large factor than the first one you picked and stuck with. Keep in mind that everything you read from other people is just their way of solving, thinking, or doing something. Just because it works for them does not mean it works for you. Try their way and, if you don't like it, discard it and try something else. Once you land on what really works, you'll know it.

Employment is a one-man business

For some reason people put themselves down. They, many times, will adopt the belief that they don't deserve certain things which can lead to behavior such as self-sabotage. A trick that I often use is to stop thinking of myself as myself (huh?).

Instead, I separate my work-self into a separate entity that I make myself responsible for. It's my own company of one.

This perspective is applicable top to bottom. It can benefit you in your learning because you suddenly become interested in making your company valuable by learning the most effective languages and technologies. It alleviates the feeling of intimidation or being lesser than the company you are interviewing with because it isn't you under pressure anymore; it's you representing your company in a business transaction and being invested in getting the best deal possible. It extracts you out a level, and gives you enough emotional detachment to handle all types of situations.

These techniques don't have to remain at the forefront of your mind the entire time. If you read these carefully and do your best to adopt them, they will carry you far. The great thing about effective mindsets like these is they benefit every aspect of your career and even your life. It would be wonderful if these can, at the very least, help you reach your goal of getting your first job. Then I hope you will teach me some of your own mindsets you developed along the way.

How to Become a Developer without a Degree or Boot Camp - is it Possible?

Clint Winter — Wed, 19 Aug 2020 15:03:08 +0000

Preface: This post is geared towards people interested in being self-taught because boot-camps or college aren't viable options for them for whatever reason. As a self-taught developer myself, this is the path that I have experience with and can talk about confidently.

Before I started my self-taught journey, I was interested in a potential career in technology. I spent a lot of time figuring out if it was possible, if I was smart enough, if anyone would hire me without a degree, if I'd make decent money, if I was too old, and on and on.

As someone coming in and looking for answers who had no background or experience in or around the industry, my ability to even find the right words when asking questions was severely lacking. So if you are that person trying to get into the technology field right now by making a career switch, I'll try to remember back to when I was you and be as clear as possible.

Side note: If you've read some other posts already that have put you down, I should let you know that there are many gatekeepers in this industry with fragile intellects that will tell you that you have to be 100% passionate about your work and spend 16 hours per day learning and working or you won't make it. That you have to be naturally inclined towards this work, and even then you probably won't make it. That what they do is extremely difficult and only the smartest people will be able to do what they do. These people are more interested in feeling good about themselves than in helping you. Don't let them get you down.

You don't know what you don't know

You might be wondering how you begin getting into this field. Or maybe even what field you should get into. Or maybe even "What fields can I pick from?" As you may imagine, the technology field is pretty vast and there are tons of different paths. However, many of them are more strict with their education requirements.

I'll be straight up with you, and this may be biased since I am one, but being a web developer likely has the lowest barrier to entry of any software job, it doesn't require a degree almost ever, and has a reasonable timeline of learning before you become employable. I know that narrows it down from a lot of different options, but your best chance probably exists in the web world. That world on its own is pretty wide, so it isn't as limiting as you may be thinking.

Once you're a professional and have some years of experience as a web developer, you'll have a much better chance of pivoting to another software career that has more strict standards that interests you more.

This is just me personally, but web development was the most fun to learn as someone who wasn't a child prodigy writing scripts at five years old. In the beginning you are learning HTML and CSS, which are languages that are used to create a web page. When you use them, you are instantly able to see the results of what you have written in the web page, which is fun!

A quick demonstration

If you'd like to do a very quick demonstration that shows you the rewarding feeling of instant visual feedback, follow along below. Otherwise feel free to skip this section.

Open a blank tab in your browser, press F12 or ctrl/ cmd+ shift + i. A panel will open up that should look similar to the image below.

Copy the entire content of the box here:

<html>
<head>
<style>
    @keyframes rainbow {
        0% { color: red; }
        20% { color: orange; }
        40% { color: yellow; }
        60% { color: green; }
        80% { color: blue; }
        100% { color: purple; }
    }
</style>
</head>
<body>
    <h1>This is a header!</h1>
    <p>This is the body text that I can make <b>bold</b> or <i>italic</i> or <span style="color:red">red</span> or <span style="text-decoration:underline;font-size:2rem;font-weight:black;font-family:monospace;animation: rainbow infinite 2s linear;">anything I want</span>.</p>
</body>
</html>

On your new tab, right-click <html> that the red box is highlighting in the above image and click "Edit as HTML". Replace the content of the editable box that opens with the content you copied above. Press ctrl + enter to confirm the changes. Instant feedback!

How long will it take?

Hopefully you're getting a little excited about the idea of this career. Then right after that you're probably hearing all of the negativity and doubts in your head, such as "Yeah cool, but how long is this going to take—years?" Well, it depends quite a bit on your level of dedication and learning abilities.

Learning is a complicated, non-linear activity. When I first started trying to learn web development, I quit on at least three different occasions because of frustration from trying to learn various concepts. But I always ended up coming back, and each time I was a little more resilient to that frustration. Those times I quit put significant gaps between my learning and made it take longer for me. I wasn't perfectly consistent, although I did have a boring job that allowed me to put in quite a few hours on those days without much distraction. I also probably didn't do the most effective learning strategies. A big part of the learning at first will be about yourself and how you learn best.

Given that information and if I remember correctly, it took me about a year to get to a point where I was able to get my first part-time job. Even with my lack of structure and the gaps without learning, that's not a bad timetable, especially when compared to someone spending four years (minimum) in college.

Am I well-suited for this?

Let's first dispel the black and white thinking that some people are born for this and others are not. Nobody is born to do this because typing code on a computer is not part of our evolutionary development, so that makes no sense. More realistically, what you have is people that will initially pick this up faster than others. Those that pick it up more quickly will feel like they are good at it and be excited to keep going. Those that get frustrated earlier will be more likely to drop out and chalk it up to genetics or whatever.

This isn't to say that we are all equal or the same, because we aren't. Personality differences will definitely play a role here. If you are someone with high extroversion, nurturing, and agreeableness, you are probably geared towards working with people more directly and won't be satisfied with this type of work.

You hopefully know enough about yourself to know if this type of work is compatible with your personality. If you don't, I would consider doing some reflection about what other interests you've had throughout your life and if this career makes sense for you or if you're more enticed by money.

Keep in mind that this job doesn't have to be you in a dark room for eight hours per day typing code alone. That's what I wanted it to be when I first started because I'm naturally introverted—however, as I've grown in this career, some of the most rewarding things for me now are collaborating with my team and exchanging knowledge and learning from fellow developers.

Let me also say that if your motivation right now is only money, that's actually okay (at least initially). But it cannot be your only motivation for a long period of time. If you aren't developing any enjoyment for the craft over time, you won't be able to keep yourself motivated to keep going. That's a good thing—don't waste your time on something you really have no love for.

This career does require some dedication. Like many careers, you have to spend a lot of time building up knowledge, dealing with frustration while you try to understand a concept, getting stuck and breaking through walls, and doing some less-desirable parts of the job that come with the territory (like fixing obscure bugs in crappy, old, legacy code).

If you find that the sucky parts of the job are worth doing for the fun and exciting parts, then you're in the right place.

Resources for getting started

The best thing you can do is jump right into learning! If you want to get your feet wet into some web development, it is universal that you will need to learn HTML, CSS, and JavaScript. I don't think you should rely too heavily on any single resource for learning as a self-taught person because that leaves you open to blind spots. So I'll dump a bunch of resources of different types that I've used over time.

Codecademy - This is where I started. It holds your hand quite a bit (at least back when I used it), so make sure you break out of it at some point and start working on things independently from the website.
The Web Developer Bootcamp (Udemy) - A great course that will help you set up a development environment on your own computer, learn the important concepts, and then get you building full-fledged projects.
Mozilla Developer Network (MDN) - This is a website that you can use as a reference whenever you need to remember how to do something or want to learn the basics of the web, such as how the web works.
Free Code Camp - Similar to codecademy. A free, guided course to teach you web development front to back.
The Odin Project - Yet another guided course that gives you options on which stack of technology you want to learn.
Stack Overflow - This is the place that's often going to show up at the top of your search results when searching your code-related questions. It's a great place to get those answers that will help you move along. Learning to use a search engine well is an important part of being a developer!
A collection of resources - This is an extensive list of resources another person has come up with. Some of the ones I shared above are also on this list. It's a couple of years old now so some resources on it may be outdated, but use your discretion.

I think this should be enough options to help you hit the ground running head first into your new career! Let me know if you have any questions and I can answer them directly. If I get a lot, I can write another post that expands on this one.

Give it a try and see if you like it—you don't have to take a huge risk to find out if it's for you. This could turn out to be the beginning of a very lucrative and fulfilling career. I wish you the best of luck on your journey, and I hope to see you out there!

P.S.: Once you're getting started in your career, look out for my posts about how to have a successful career as a developer. They'll be coming soon!