But let's assume for a second that your installation goes without a hitch. NPM gives you a grand success message and everything was installed without a hiccup. You then proceed to type gulp watch or whatever your task manager of choice and then the whole process crashes followed by you slamming your fist on your desk in frustration.

The two examples that were listed above are more common than we would like to admit. It can be just as simple as a syntax error or as bad as a deprecated package that simply doesn't exist anymore. As I'm sure that most developers are aware of, one of the largest and problematic issues of working with legacy projects is how to manage project dependencies.

While this fiasco persists within all facets of development, for the sake of this post, we will focus on the front-end side (whew).

Diagnosing the problem

While I don't consider myself a genius when it comes sifting threw the needle in a haystack that is an error log, for most developers a npm install error log can deciphered with ease. I can say that most NodeJS packages now-a-days do a pretty good job of explaining what the problem is in layman terms. It could be just as simple as saying that a package doesn't exist or something is undefined, and this can remedied by performing an additional installation command.

Where diagnosing becomes difficult is when multiple dependencies of a NodeJS module and in turn their dependencies start throwing errors. As I'm sure most of us can agree, this is what we as developers begin to lose sleep over.

A couple different solutions

In my experience, the two scenarios that I briefly outlined above can be solved about 80-90% of the time with a couple different or a combination of tactics.

NodeJS version

If the project that you are trying to work on is more than 2-3 years old, it is very possible the version of NodeJS that is installed on your machine is too recent for the dependencies that are listed within the package.json that accompanies your project.

NodeJS modules

A common mistake that we all make when we are building our package.json file and utilizing the npm install command is that we just tell NPM to retrieve the most stable and recent version of a package and added as a dependency. In doing so, our dependency list could look like this:

"dependencies": {
    "bower": "^1.7.2",
    "connect-redis": "1.4.5",
    "ejs": "~0.8.4",
    "grunt": "0.4.2"
}

The issue with this JSON object is the ~ and ^ punctuation (source) before the version numbers. What these mean, respectively, is the version is approximately this number or it needs to be compatible with the listed version. While for one package it is not detrimental, spreading this level of variability throughout the entire project can be disastrous.

So what's next?

Yeah so what's next? Well here are a couple routes you can take to trouble shoot these issues that can creep up during an installation/run.

Using n to change your version of NodeJS

NodeJS gives a tool called NVM (Node Version Manager) to control our versions of NodeJS that are active on our machines. I have found that this module can be clunky at best and the command line syntax is just weird.

I recommend using n. n is a simpler version of NVM and allows you to easily transition between versions of NodeJS on your machine.

How to install/use n

1. Before we install anything, we need to make sure that your user has read/write access to the /usr/local/bin/ directory on your machine so we can modify the "node" directory that will live there. To do this, enter the following command followed by your user password:

\( sudo chown -R \)(whoami) /usr/local

2. After that is complete, now we need to install n globally on your machine like so:

$ npm install -g n

Note: If you computer asks you to perform this action as an Administrator, simply prefix this command with sudo.

3. Now that n is installed, we can see all of the actions that are available to us by simply entering the following command:

$ n

which should look like this:

Note: Once versions of NodeJS are installed, to be able to return to this screen use the n --help command.

4. Before we start getting crazy with installing all sorts of NodeJS on your machine, lets give ourselves a good baseline to work from by install the current version of NodeJS on our machine. First enter:

$ node -v

The result that is outputted should look like this: v5.3.0. Note the version number (not including the v) and then enter this command:

$ n [your current version]

This will install your current version of NodeJS within n. Next enter this command to install the most recent stable version of NodeJS:

$ n latest

Once finished, enter the n command again and you should see something like this (note your version numbers could be different):

Now you can use your arrow keys to navigate the versions installed and then hit Enter to select your version, or just use Ctrl + C to exit. Go ahead and select the newest version that you have, and then hit Enter. Give your machine a second to process the change and then it will exit the screen. Afterwards test your version with:

$ node -v

Note: Make sure you have killed all of your NodeJS servers/process!

Assuming you did everything correctly you should see your version change. But that's not all! You can go back as easily as you can go forward. If you enter:

$ node ls

This will output all of the versions of NodeJS that are available to install. You can simply copy the version number that you want and then repeat the process to be able to install legacy versions of NodeJS. It's that easy! Once you have found a version that you think will work (it may take some trial and error), purge the node_modules directory and the retrying the install and run commands.

Fix your module versions

As I touched on earlier, another way we can troubleshoot these errors is not allow NPM to install versions of our dependencies that are not explicitly what we ask for. The punctuation marks (^, ~) that are prepended to our version numbers can cause modules to be full feature versions ahead of what we want; causing major compatibility issues.

To fix this, simply remove any prepended ^ or ~ marks within your package.json file, purge the node_modules directory and the retrying the install and run commands.

Disclaimer

Again, restating what I said earlier, I have found these two methods of debugging to solve about 80-90% of my compatibility issues. However keep in mind that other things can go wrong, things that are not covered here. But hopefully this will get you pointed in the right direction.

It has been said that when you attend a conference (technical or creative) the speakers at that conference represent the top 5% of minds in your respective fields. Essentially the cream of the crop. While the attendees can very easily benefit from this type of talent and knowledge, speaking at a conference can benefit you just as much. Surrounding yourself with this type of knowledge is in infectious; which can only improve you as a person, personally and professionally, and as a subject matter expert.

So you may be saying to yourself, "Ok so I can get smarter and/or more knowledgable. Big deal. Is that all?" Well no of course not. Keep reading.

Investing in your skill

I can speak from experience that there is nothing more embarrassing than getting up in front of a group of people and you start receiving questions that you don't know the answers to; especially when you are live-coding. It's awkward for you and the people attending your talk. So how do you avoid this?

It's simple: do your homework.

While you may be pretty comfortable with your subject matter, there is always an opportunity for you to add just a few extra facts to help draw in your audience even more. More often than not, these facts, pointers, or how-to's are items that you probably don't already know. A common requirement for conferences is for you to stage your code on GitHub or any other equivalent with any associated documentation. A bi-product of this requirement is clean code and detailed how-to's; all extremely effective tools who may not be experts. It's these little nuggets that help validate you even more as a speaker.

What it did for me

For example, in preparation for a session that I was going to give on the Ionic Mobile Framework, I had to familiarize myself with multiple deployment platforms. I am an Apple/Mac guy: I have multiple iPads, several iPhones, and a couple Apple computers at home. However to think that everyone else works on the exact same devices I do would be naive and frankly, stupid. So I invested in a cheap PC as well as an Android phone so I could broaden my scope of documentation; allowing me to understand the ins and outs of Android Studio and the Java SDK (software developer kit). Boy am I glad I did. I found more than a couple "gotchas" that could have easily derailed my talk.

All of these items require time. This is time that you spend becoming even more familiar with the documentation and processes and thus committing even more information to memory. In the end you solidify yourself within the minds of your attendees as a subject matter expert.

Building yourself up

If you want to speak publicly, you don't necessarily have to immediately jump into the conference environment. Speaking in front of complete strangers with zero context on who you are or where you come from can be frightening. I get it. Fortunately I can vouch for the fact that there are several other opportunities for you to speak before taking the conference plunge.

Client meetings

One opportunity that commonly gets overlooked is client meetings. While you may not be speaking in a traditional workshop session type setting, you are in fact speaking to people who are not familiar with your content; requiring your to explain in detail how you came to a certain conclusion. What's more is you may receive questions on your conclusions forcing you to think quickly on your feet thus placing even more emphasis on your preparation.

Focus groups

Another type of meeting that is common in the agency setting is a focus group. This can be a meeting that was called between like-minded people to decide on a process for the larger masses, or this could be an open forum during a lunch and learn. Each setting has a different type of audience make up all with unique skillets and knowledge, but each requires you to be prepared and explain your content in detail to ensure no one is left behind.

Screencasts

While not necessarily formal, putting yourself on a YouTube video screencast is another great starting place for you to begin speaking. You don't have the pressure of a live audience, allowing for additional focus on your diction and flow of the presentation. As an added benefit, if your videos get popular you begin to make a little ad revenue as well!

Promotion - self and company

Being in the industry that we are in, it could be safe to say that we take the concept of marketing for granted. We consistently market a product or idea to others while not necessarily putting a lot of effort in marketing ourselves or our employer's brand. It's this notion of brand recognition, of either ourselves or our company, that attracts like-minded talent and brand recognition.

People and thus word of mouth are the best way for a message to spread. I'm sure that all of you social media people can agree. This is how viral threads get started, word of mouth, or a social presence; which is in fact an extension of our voice. The more advocates and content that is in the public eye with your brand being connected to only fuels the message.

In my opinion, a common misconception of brand recognition comes associated with award winning work. Design periodicals and other marketing resources continuously push the draw of awards to their readers. Don't get me wrong, awards are great: they create great magazine material and are awe-inspiring when you enter the front doors of the office, seeing all of those trophies on the walls. However these awards can be all but useless if the message of your brand is lost.

Stereotypically when you speak at a conference, you introduce yourself and the company that you work for. At this moment you are instantly bringing your employer's brand to the fore-front of your attendee's minds. Just like a creative TV advertisement, that recognition will be associated with the content that you are about to present; not only making you appear better but your employer as well.

So you want to speak? Great you have help.

While you prepare for your session, one thing to keep in mind while you prepare is to remember that you do not have to go through this process alone.

Your company leadership has a number of professionals that have attended conferences of various sizes that have an enormous wealth of information. While the subject matter may be different, that doesn't matter. Having a fresh perspective on your content can only help you during the preparation and feedback stages.

Refer to the section above about the various settings that you can utilize to help you get your feet wet in speaking publicly. I understand that this is not an easy task for everyone. I can place myself in that category at one point in time. However just like everything else, practice makes perfect. Keep reviewing your notes and always be open to feedback; good and bad.

At the end of the day, the people who attend your talks want you to succeed. No one attends your sessions looking for you to fail. Determination and hard work yields quality for your talk and for you as a presenter.

Again, using my VueJS-centered brain, I just assumed that I would be able to simply emit up the TemporaryUploadedFile class that Livewire generates with a file-upload. Naturally I was incorrect. My problem: when you attempt to pass this class to a parent/child component all you get is:

Obviously you cannot do anything with this. So after some discovery, I was able to come up with a scalable solution.

The result

For the sake of being thorough, I am going to show you all of my code, so you can replicate the entire component for yourself. It is worth noting that I also used Alpine.JS and Tailwind for this component.

In the next few steps, this is what we are going to build:

Yours MIGHT look a little different as I have modified my tailwind.config.js file a bit.

How I did it

Assuming you have at least skimmed the documentation for Laravel Livewire on file uploads, you can see that once a file is uploaded, Livewire stores the file in a temporary directory within your filesystem; whether it is remote or locally depends on your infrastructure. The response of this action is an object with a bunch of other meta data named Livewire\TemporaryUploadedFile. From there you can extract any information that you need and save/move the file around where you need it. Again, you can refer to the documentation for further details.

Like I said above, if you simply try to use the emit() action to pass the result to other components, all that is passed is the disk path. I even tried JSON encoding the object, but that didn't work either. After dissecting the Livewire\TemporaryUploadedFile class, I discovered there is an exposed method getRealPath() that returns the temporary location of the file. Furthermore, I found that the path of the file is the parameter required to construct a new instance of the TemporaryUploadedFile class. Passing strings with Laravel Livewire is easy, so that was my ticket: emitting the full real path of the temporary file, and then simply re-constructing the TemporaryUploadedFile class in the parent/listening component.

Once finished, then you can either move/save the emitted file like so:

class FileUpload extends Component
{
    use WithFileUploads;

    public $file;
    
    ...
    
    public function fileComplete()
    {
        $this-file->storePubliclyAs(
            'documents',
            'sample',
            config('filesystems.default'),
        );
    }
}

Full code

Child Component Template

<div
    x-data="{ isUploading: false, progress: 0, name: null }"
    x-on:livewire-upload-start="isUploading = true"
    x-on:livewire-upload-finish="isUploading = false; $wire.fileComplete()"
    x-on:livewire-upload-error="isUploading = false"
    x-on:livewire-upload-progress="progress = $event.detail.progress"
>

    <div class="overflow-hidden relative w-64 mt-4 mb-4">
        <label class="font-sans py-2 px-4 border border-transparent text-sm font-semibold tracking-wider rounded-md transition duration-150 ease-in-out uppercase border-gray-300 text-gray-700 hover:text-gray-500 focus:outline-none focus:border-blue-300 focus:shadow-outline-blue inline-flex cursor-pointer" x-show="!name">
            <svg fill="#FFF" height="18" viewBox="0 0 24 24" width="18" xmlns="http://www.w3.org/2000/svg">
                <path d="M0 0h24v24H0z" fill="none"/>
                <path d="M9 16h6v-6h4l-7-7-7 7h4zm-4 2h14v2H5z"/>
            </svg>
            <span class="ml-2">Select File</span>
            <input class="hidden" type="file" wire:model="file" x-on:change="name = $event.target.files[0].name">
        </label>
        <div class="text-gray-500" x-show="name">
            <span x-show="isUploading">Uploading... Please wait.</span>
            <div class="flex items-center" x-show="!isUploading">
                <div class="flex-1 truncate mr-2">
                    <span x-text="name"></span>
                </div>
                <button type="button" class="inline-flex items-center justify-center h-7 w-7 rounded-full bg-red-600 hover:bg-red-800 text-white shadow-lg hover:shadow-xl transition duration-150 ease-in-out focus:bg-red-700 outline-none focus:outline-none" x-on:click="progress = 0; name = null; \(wire.file = null; \)wire.fileReset()">
                    <svg class="h-5 w-5" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 20 20" fill="currentColor">
                    <path fill-rule="evenodd" d="M9 2a1 1 0 00-.894.553L7.382 4H4a1 1 0 000 2v10a2 2 0 002 2h8a2 2 0 002-2V6a1 1 0 100-2h-3.382l-.724-1.447A1 1 0 0011 2H9zM7 8a1 1 0 012 0v6a1 1 0 11-2 0V8zm5-1a1 1 0 00-1 1v6a1 1 0 102 0V8a1 1 0 00-1-1z" clip-rule="evenodd" />
                </svg>
                </button>
            </div>
        </div>
    </div>

    <!-- Progress Bar -->
    <div class="relative pt-1" x-show="isUploading">
        <div class="overflow-hidden h-2 mb-4 text-xs flex rounded bg-green-200">
            <div :style="`width: ${progress}%`" class="shadow-none flex flex-col text-center whitespace-nowrap text-white justify-center bg-green-500"></div>
        </div>
    </div>
</div>

Child component

<?php

namespace App\Http\Livewire;

use Livewire\Component;
use Livewire\WithFileUploads;

class FileUpload extends Component
{
    use WithFileUploads;

    public $file;

    public function render()
    {
        return view('livewire.file-upload');
    }

    public function updatedFile()
    {
        $this->validate([
            'file' => 'file|max:8192', // 8MB Max
        ]);

        \(this->emitUp('fileUploaded', \)this->file);
    }

    public function fileComplete()
    {
        \(this->emitUp('fileUpload', \)this->file->getRealPath());
    }

    public function fileReset()
    {
        $this->emitUp('fileReset');
    }
}

Parent Component

<?php

namespace App\Http\Livewire;

use Livewire\Component;
use Livewire\TemporaryUploadedFile;

class ParentComponent extends Component
{
    protected $listeners = [
        'fileUpload',
        'fileReset',
    ];
    
    public $file;
    
    public function fileUpload($payload)
    {
        \(this->file = new TemporaryUploadedFile(\)payload, config('filesystems.default'));
        
        /* When you are ready to store the file */
        /*
        $this->file->storePubliclyAs(
            'documents',
            'sample',
            config('filesystems.default'),
        );
        */
    }

    public function fileReset()
    {
        $this->file = null;
    }
}

Hopefully you can find this useful. I was banging my head against the wall for a couple hours with this, and naturally the solution was easier than anticipated.

I'll come right out and say it: I hate writting documentation; regardless for what it is for. My normal avenue's of implementation documention are via Word document, or even a repository wiki. Recently I even used this awesome documentation package called LaRecipe, that I thorougly enjoyed using. However these solutions didn't solve my pain point of the documentation isn't all in the same place. It required a client to open up another application or web browser and comb through a few different pages. It was these issues that was the inspiration behind a new Nova tool that I built to solve.

Building yet another tool

So like I said, to solve my own pain, I built a new Laravel Nova tool called Nova Documentation (creative name right?).

What this tool essentially does is convert Markdown files and then passes them to the Vue component within the tool. Ultimately it is that simple, however there are a few other things that I added that I think will be useful:

• Syntax highlighting to code blocks (thanks to highlight.js)

• Dynamic navigation/table of contents

• Document nesting with url rewriting

• Flexible configuration settings

Installation

To start, lets install the Nova tool with:

composer require dniccum/nova-documentation

Next, we need to publish the tool's configuration file and a couple markdown files with examples to get you started:

php artisan vendor:publish --provider="Dniccum\NovaDocumentation\ToolServiceProvider"

By default, the sample markdown files that the tool uses to render it's content will be added to resources/documentation path. If you would like to move this directory, be sure to update this setting within the config/novadocumentation.php configuration file:

/*
|--------------------------------------------------------------------------
| Home Page
|--------------------------------------------------------------------------
|
| The markdown document that will be used as the home page and/or entry
| point. This will be located within the documentation directory that resides
| within your application's resources directory.
|
*/

'home' => 'documentation/home.md',

And finally, just like every other Nova tool, we need to register the tool within the NovaServiceProvider:

use Dniccum\NovaDocumentation\NovaDocumentation;

...

/**
 * Get the tools that should be listed in the Nova sidebar.
 *
 * @return array
 */
public function tools()
{
    return [
        // other tools
        new NovaDocumentation,
    ];
}

Assuming that you have done everything correctly, you should see a "Documentation" link in your Nova sidebar with this as a homepage:

Using the tool

Assuming that you are using the default installation configuration, the directory where all of the markdown file will be stored in the resources/documentation directory. Again, if you use the default settings, the home.md file that will be found there will represent the home page:

# Welcome to your documentation

Within this area, you can:

* Define features
* Add how-to's
* Link to tutorial videos/images

To see any other Markdown syntax and examples, please see [the sample](sample.md).

Generating your content

A few things you should note:

• Any and all markdown is allowed in these markdown files.

• You should be able to add any other HTML that you want to render within the page; excluding any Javascript as I am using Vue.js template compiler to build the page and any Javascript-based content probably won't render correctly.

• I did add the necessary CSS to clean up some of the appearance of standard HTML tags like ordered/un-ordered lists, headers, block quotes, etc from the base stylesheet that Taylor Otwell constructed for the Nova dashboard. If you happen to find something that isn't quite styled correctly, drop me a line on the issues page on Github.

• Feel free to organize your markdown files as you wish; whether everything is in the base directory or if you would like to add files within directories. The tool will detect them and build their url's accordingly.

Setting your titles

It is important to note that the H1 tags within each of these files will be dynamically pulled to build the sidebar navigation. With that said, make sure your titles are descriptive yet short in length to prevent the sidebar from becoming cluttered.

Other features?

As you continue to work with this tool, let me know if there are any other features that you would like to add. Thank you for your interest!

By default, the Broadcasting functionality within Laravel serializes any and all classes/models that you pass to the events. What does this mean? Well lets say for example that you have a model that has 15 columns for each result, however during your select method you only query 3 columns; like so:

$user = \App\Models\User::where('id', 6)
	->select(['id', 'name', 'email'])
	->first();

event(new \App\Events\UserLoggedOut($user));

If you pass this model to the event all 15 columns will be queried; regardless of what you select, or the number of unset methods you use. If you are using a service like that of Pusher, you could run into character limits that will ultimately lead to errors and failed messages.

In order to prevent our broadcasts from erroring, we need to customize the payload that is sent to Pusher or any other platform. We can do that by playing a broadcastWith method within our event class. Let's to back to the example above, where we only want to broadcast the id, name, and email address. Our broadcastWith method would look like this:

/**
 * Specifically broadcasts the necessary array keys
 *
 * @return array
 */
public function broadcastWith()
{
    return [
        'user' => [
            'id' => $this->user->id,
            'name' => $this->user->name,
            'email' => $this->user->email,
        ]
    ];
}

By implementing this method, your broadcasts will be significantly simplified and thus carry a light payload. But that's not all! Because this is a method, and not a variable, you can perform additional logic within this method to conditionally add content to the payload. Refer to another example below:

/**
 * Specifically broadcasts the necessary array keys
 *
 * @return array
 */
public function broadcastWith()
{
    $payload = [
        'configuration' => [
            'id' => $this->configuration->id,
            'name' => $this->configuration->name,
            'user' => [
                'first_name' => $this->configuration->user->first_name,
                'last_name' => $this->configuration->user->last_name,
            ],
        ]
    ];

    if (!empty($this->configuration->jurisdictions)) {
        \(jurisdiction = \)this->configuration->jurisdictions->first();

        $payload['jurisdiction'] = [
            'id' => $jurisdiction->id
        ];
    }

    if (!empty($this->configuration->comments)) {
        \(payload['comments'] = \)this->configuration->comments;
    }

    return $payload;
}

What I have done is that I have assigned the initial associative array to a variable and performed some basic if-statements to conditionally add content to the payload.

While this isn't necessarily rocket science, using this method of customizing your broadcasts can simplify your application and save you a bunch of time wrestling with the Pusher/websockets APIs.

Now that Angular 2 has finally been released and is no longer in the purgatory of beta or release candidate, I am starting to see a trend with the support of public projects and the technologies that supports them. This trend is that these new projects are not supported by Bower.

While I would like to note that these trends are somewhat specific to brand new projects like that of Angular 2 and Ionic 2. Projects like Angular 1 and Ionic 1 that are currently being maintained, though not improved, are still supported with Bower compatible packages; I digress...

But why would I be thinking about this? Is there something that Bower did wrong to seal it's demise? I have a few ideas.

It's a NodeJS package

So what if it is a NodeJS package? We use helpers like Grunt and Gulp all of the time to process code and to make our lives easier as developers. Why would Bower be any different? Here's my theory: because it is a required dependency to install further dependencies with its own set of shell commands; automation in other words.

When working with CMS applications like Adobe Experience Manager or even platforms like Laravel (PHP-based), these tools ship with scaffolding tools or provide a tool for you to create your own. The majority of these assets require you to use Node Package Manager (npm) to install and run their associated dependencies. It has become so common that it is second-nature for us as developers to clone a repository and then run $ npm install. Configuring AEM to run this command isn't very hard either. The issues that I can identify lies in the fact that:

• Bower downloads is packages differently than NodeJS does

• It has a different set of configurations and requires additional files to apply these configurations

• It is discouraged to store your Bower-related files or bower_components in the same place as your node modules. Bad things start to happen when you do

Each of these points could become troublesome if you are trying to develop in an existing ecosystem that was never designed to support Bower.

Additionally, in most instances you have to have Bower installed globally on your machine. If not, for instance it is a dependency of your NodeJS application, then you are limited to calling the Bower command like so:

/usr/local/bin/bower install

Now you are liable to manage two different sets errors and feedback. And as I pointed out earlier, if this Bower project has been automated, debugging these errors can be troublesome.

The lack of updates

If you look at the Bower repository release page, you can see that the platform hasn't been touched (at the time of this article being written) since April. A platform that was as widely used as this, and when you throw in the recent macOS update of Sierra, the lack of updates should come as a bit of an alarm to you.

No new project adaptation

As I said above, if you are familiar with Angular 2, Ionic 2, or even Zurb's Foundation, currently none of these projects have developed Bower components. It is also worth touching on that these three projects also have a corresponding command line interface (CLI) to be able to initializes or compile its assets. As you would expect, these CLI's using NodeJS to install their dependencies. With not relying on Bower to install their dependencies applications such as these can scaffold a project without having to call additional shell commands; resulting in both supplementary speed and stability within the applications.

Just a few thoughts

As I draw this techy rant to a close, keep in mind that I am basing my conclusions purely off of observations and some basic research. I proudly disclose that I have not spoken to the Bower guys about the longevity of their project, or do I have any usage metrics to show a decline. Again, just a few thoughts that I tied together into a hypothesis. For all I know, Bower could be alive and well.

But nevertheless, we as developers have to take note of this evidence and begin to make decisions when we are scaffolding a new project or making enhancements to existing projects.