DEV Community: Francis Cote

Getting Started with Vue.js Plugins [Production-Ready Example]

Francis Cote — Thu, 13 Sep 2018 11:09:48 +0000

It's no secret that we <3 Vue.js.

So much so that it's a key part of our own product's rewriting.

In the last months, we've learned a lot about Vue. From building SEO-friendly SPAs to crafting killer blogs or playing with transitions & animations, we've experimented with the framework thoroughly.

But there's a missing piece in there:

Something most proponents of the framework will have to work with is Vue.js plugins.

For my own pleasure (and yours, hopefully) I crafted a custom plugin to show you how it's done in a step-by-step tutorial.

I'll also use this post to answer important Vue plugins questions:

What's a plugin?
What are they useful for?
What are the popular Vue.js plugins?

Time for the magic!

A short story of Vue.js plugins

What exactly is a plugin?

Plugins aren't something specific to Vue.js, and you'll usually find them in a large range of software. By definition, they indicate that an interface is provided to allow for extensibility.

In other, simpler words, they're a way to add global features to an app.

In Vue.js, a plugin should expose an install method that takes two parameters:

The global Vue object.
An object incorporating user-defined options.

Good news is they're not that intimidating. Basic knowledge of Vue.js will let you start fiddling with plugins right away.

→ Read the full post & technical tutorial here

JavaScript Beginners: Friendly Intro & Exercises

Francis Cote — Thu, 30 Aug 2018 14:50:47 +0000

“Baby steps, & lots of practice.”

That is the most common answer I hear to the How can I learn JavaScript? question.

Because let’s face it:

For JS beginners, the towering ecosystem that is JavaScript can be quite intimidating.

At Snipcart, we have many users who aren’t JS experts—and that’s just fine. We often try to guide them towards a better understanding and best practices. Following the count your keystrokes principle, I decided to create an evergreen resource I could later point to!

This intro for JS beginners will feature:

A rich overview of JavaScript & its ecosystem
A step-by-step learning program & key resources
Two JavaScript exercises for beginners

Let’s take those first baby steps.

→ Read the full post here

Serverless Use Case: Build a calendar feed from scrapped HTML schedules

Francis Cote — Tue, 10 Apr 2018 03:49:32 +0000

This post is not a tutorial. I omitted a lot of implementation details to keep it as short as possible.

I play Ultimate once a week. It's a sport I really enjoy. One stupid thing I struggle with is remembering what time this week's game is. My local Ultimate organization has this website where I can log in and see all that stuff, but the "remember me" feature of the login page, actually doesn't remember me at all.

So, as a classic lazy ass developer, I saw an opportunity to turn this irritant into a neat lifehack experiment.

What I want

So I have this HTML table with all games on the schedule. What I want is to have it all in an ICS file that would ideally:

update itself automatically
be served on the web so I can subscribe to it

Pick the tools

I chose Apify for data scraping. This product allows you to crawl pages, extract data from them, and expose this data through an API endpoint.

To crunch that data into ICS files, I decided to use Azure Function as my serverless platform.

The files generated are stored in Azure Blob Storage.

Collect the data

So, the table looks like this:

Now, I won't go to great lengths to explain how Apify works. Just know that once I figured out how to setup crawler login and cookies retention, I was able to setup the start/pseudo URLs and clickable elements. What I needed to do after that was to code what they call the "page function", i.e. the function that extracts the data on each page crawl. It looks like this :

function pageFunction(context) {
  var $ = context.jQuery;
  var req = context.request;
  var result = null;

  function getTeam(row, order) {
    var teamLink = row.find("td.team a");
    var team = {};
    team.name = $(teamLink[order]).text();
    team.url = "http://www.ultimatequebec.ca" + teamLink.attr("href");
    return team;
  }

  function getPlace(row) {
    var placeLink = row.find("td.place a");
    var place = {};
    place.name = placeLink.text();
    place.url = placeLink.attr("href");
    return place;
  }

  var calendar = req.loadedUrl.match(/calendriers/);

  if (calendar) {

    var games = [];
    var date = "";

    $("table.calendar").each(function () {
      $(this).find("tr").each(function (index) {
        if (index === 0) {
          date = $(this).text();
          return;
        }

        var row = $(this);

        var game = {};
        game.date = date;
        game.hour = row.find("td.hour").text();
        game.place = getPlace(row);
        game.team1 = getTeam(row, 0);
        game.team2 = getTeam(row, 1);
        game.url = "http://www.ultimatequebec.ca" + row.find("td:last-child() a").attr("href");
        games.push(game);
      });
    });

    result = {
      games: games
    };
  }

  return result ? result : {};
}

Pretty ~~ugly~~ basic jQuery bits, right?

Once the crawler has run, its results API endpoint returns the scraped data as expected:

"games": [
  {
    "date": "lundi, 09 avril 2018",
    "hour": "19h30",
    "place": {
      "name": "Marc-Simoneau, C- Bord",
      "url": "https://www.google.ca/maps/place/Centre+sportif+Marc-Simoneau/@46.8616686,-71.2080988,15.5z/data=!4m5!3m4!1s0x0:0x30df80932f5ceacb!8m2!3d46.8617603!4d-71.209124"
    },
    "team1": {
      "name": "Cut in the End Zone",
      "url": "http://www.ultimatequebec.ca/members/teams/cut-in-the-end-zone"
    },
    "team2": {
      "name": "Les muppets",
      "url": "http://www.ultimatequebec.ca/members/teams/cut-in-the-end-zone"
    },
    "url": "http://www.ultimatequebec.ca/members/games/14332"
  }
]

I configured the crawler to run twice a day, so I can have fresh data all the time.

Great! Now, how about some data crunching?

Transform the data

Since Azure Function now runs .NET Core 2.0, I decided to give it a shot. I took the approach of creating a function as a class library.

It is triggered by POST HTTP calls. The Apify crawler has a webhook configuration that pokes the function at the end of each successful run.

Once again, I spare you the ins and outs of the implementation, but the function's Run method looks like this :

public static async Task Run(
    [HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequest req,
    [Blob("uq-schedule", Connection = "TFD_STORAGE")] CloudBlobContainer container,
    TraceWriter log)
{
    var teamsDict = new Dictionary<string, GameCalendarWriter>();

    var fullScheduleBlob = container.GetBlockBlobReference("uq-full-schedule.ics");
    var fullScheduleBlobStream = await fullScheduleBlob.OpenWriteAsync();

    var apiToken = FunctionHelpers.GetEnvironmentVariable("TFD_APIFY_TOKEN");
    var userId = FunctionHelpers.GetEnvironmentVariable("TFD_APIFY_USERID");

    IApifyClient apifyClient = new ApifyClient(apiToken, userId);

    var result = await apifyClient.GetLastRunResultsAsync("ultimateqc_schedule");

    var games = result
        .Where(r => r.PageFunctionResult.Games?.Any() ?? false)
        .SelectMany(r => r.PageFunctionResult.Games)
        .ToList();

    using (var fullCalendarWriter = new GameCalendarWriter(fullScheduleBlobStream))
    {
        foreach (var game in games)
        {
            await fullCalendarWriter.WriteGame(game);
            await (await GetTeamWriter(container, teamsDict, game.Team1)).WriteGame(game);
            await (await GetTeamWriter(container, teamsDict, game.Team2)).WriteGame(game);
        }    
    }

    foreach (var writer in teamsDict)
        writer.Value?.Dispose();
}

This piece of code will generate a global ICS file of all games across all teams, as well as one for each team. All these files will be stored in an Azure Blob Storage container, accessible publicly by their URLs. Here's a snippet of what I get :

Finally, subscribing

I can now log into my Google Calendar and subscribe to my team's ICS file via its URL. Google will keep up to date with changes to that file's content.

I'm all set! I now have access to all my upcoming games in my calendar app. I can setup custom reminders and live a happier, lazier life!

Thanks for reading, hope you enjoyed it :)

English is my second language, so please tell me if you spot a typo, a grammar error or anything that could make this post hard to read. I'm constantly trying to get better at it.

.NET Standard explained to developers: What if it was an interface?

Francis Cote — Tue, 24 Oct 2017 02:24:29 +0000

Quite recently, Microsoft shook the ground of the whole dotnet ecosystem with a new concept : .NET Standard. Lot's of folks like me, who already had a hard time keeping up with all things .NET lately, thought "What is it now?!".

Now, I spent a little while wrapping my head around this and I think I've come up with a developer-friendly explanation to what .NET Standard really is. In fact, I've somewhat materialized it into a little piece of (incomplete) code.

To dumb down things a bit, try to picture each version of .NET Standard as an interface, and each platform implementing them as classes. You'd get something like this :

interface INETStandard_1_0 { /* Lots of methods */ }
interface INETStandard_1_1 : INETStandard_1_0 { /* More methods */ }
interface INETStandard_1_2 : INETStandard_1_1 { /* More methods */ }
interface INETStandard_1_3 : INETStandard_1_2 { /* More methods */ }
interface INETStandard_1_4 : INETStandard_1_3 { /* More methods */ }
interface INETStandard_1_5 : INETStandard_1_4 { /* More methods */ }
interface INETStandard_1_6 : INETStandard_1_5 { /* More methods */ }
interface INETStandard_2_0 : INETStandard_1_6 { /* More methods */ }

// .NET Core Platform
class DotnetCore_1_0 : INETStandard_1_6 { /* Implements methods */ }
class DotnetCore_2_0 : DotnetCore_1_0, INETStandard_2_0 { /* Implements methods */ }

// .NET Framework Platform
class DotnetFramework_4_5 : INETStandard_1_1 { /* Implements methods */ }
class DotnetFramework_4_5_1 : DotnetFramework_4_5, INETStandard_1_2 { /* Implements methods */ }
class DotnetFramework_4_6 : DotnetFramework_4_5_1, INETStandard_1_3 { /* Implements methods */ }
class DotnetFramework_4_6_1 : DotnetFramework_4_6, INETStandard_2_0 { /* Implements methods */ }

// Mono Platform
class Mono_4_6 : INETStandard_1_6 { /* Implements methods */ }
class Mono_5_4 : Mono_4_6, INETStandard_2_0 { /* Implements methods */ }

// and so on...

Now, in the facts, things are a bit more complicated since the API surface defined by .NET Standard includes classes as well as their members, but in essence that's really all this is: An interface, with several implementations.

If you're interested in this, you can head to the official repo where all the work is being done.

EDIT : Someone in the team just told me about David Fowler's take on the subject and of course it is awesome. I suggest you check this out too!

Developer tooling on Windows: A cleaner PowerShell profile

Francis Cote — Thu, 25 May 2017 23:00:26 +0000

Developer tooling on Windows: A cleaner PowerShell profile

I originally published this post in french on 42 lignes Ã l'heure

If you've been talking code with me, there's a chance PowerShell came to the table at some point. Before PowerShell was introduced in 2006, developers on Windows who wanted to take a shot at the command line would have to deal with good old BATCH (cmd.exe). Sure, one can manage to get some things done with it and somehow cope with all its awkward bits, but the fact is that BATCH is far from being a great tool.

Enters PowerShell, that takes us much further by solving several pain points that make developers' life miserable in BATCH. One of them is the lack of native support for profile scripts. That is what this post is about.

This quick guide suggests a simple way to create a reusable, structured and evolutive PowerShell profile.

Create a Git repository for our scripts

This is the obvious way to store profile scripts. I personnaly chose GitHub, but a number of options exist out there. Gitlab and Bitbucket both offer free private repositories, if that matters to you.

Repository structure

powershell-dev-environment/
â”œâ”€â”€ src/
â”‚   â”œâ”€â”€ profile.ps1
â”‚   â”œâ”€â”€ _imports.ps1
â”‚   â”œâ”€â”€ _prompt.ps1
â”‚   â””â”€â”€ _ui.ps1
â””â”€â”€ install.ps1

The entry point

The file profile.ps1 is the entry point of our profile.

# profile.ps1

$env:devProfileDir = $PSScriptRoot

. "$env:devProfileDir\_imports.ps1";
. "$env:devProfileDir\_ui.ps1";
. "$env:devProfileDir\_prompt.ps1";

Note that we define $env:devProfileDir, an environment variable that will store the location of our scripts. It may be of use.

The file _imports.ps1 is used to load all third-party modules that we want to have available in our PowerShell sessions.

# _imports.ps1

Import-Module posh-git
# an so on...

CAREFUL HERE, some modules can take a lot o time to load (yep, I'm totally looking at you Carbon), so be selective on what you choose to include in this file.

Colors

Terminal display colors are configured in _ui.ps1

# _ui.ps1

$console = $host.UI.RawUI

$console.ForegroundColor = "white"
$console.BackgroundColor = "black"

$colors = $host.PrivateData
$colors.VerboseForegroundColor = "white"
$colors.VerboseBackgroundColor = "blue"
$colors.WarningForegroundColor = "yellow"
$colors.WarningBackgroundColor = "darkgreen"
$colors.ErrorForegroundColor = "white"
$colors.ErrorBackgroundColor = "red"

Clear-Host

Prompt function

The Prompt function is a special, kind of "reserved" PowerShell function. It is executed to render the command line prompt. Once you define it in your profile, you have total control over how your prompt will look. Here's mine:

# _prompt.ps1

function Prompt {    
    $realLASTEXITCODE = $LASTEXITCODE

    $Host.UI.RawUI.ForegroundColor = $GitPromptSettings.DefaultForegroundColor

    Write-Host
    Write-Host "$ENV:USERNAME@" -NoNewline -ForegroundColor DarkYellow
    Write-Host "$ENV:COMPUTERNAME" -ForegroundColor Magenta -NoNewline
    Write-Host (Get-Date -Format " | MM/dd/yyyy | HH:MM:ss") -ForegroundColor DarkGray

    Write-Host $($(Get-Location) -replace ($env:USERPROFILE).Replace('\','\\'), "~") -NoNewline -ForegroundColor Gray

    Write-VcsStatus

    Write-Host

    $global:LASTEXITCODE = $realLASTEXITCODE

    return ""
}

Here's how it looks in the terminal :

Execute profile scripts on PowerShell session startup

If you're like me, you like to have all your repositories in the same place. So the path of your newly created repostory might be something like c:\users\me\dev\powershell-dev-environment, and you probably want to keep it this way.

There is a built-in $profile variable that stores the path of the current user's PowerShell profile. It typically points to something like C:\Users\Me\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1. When this file exists, Powershel will automatically execute it on each new session.

Problem is we can't change that path. Our only option is to call our profile directly from there. We just have to tap into this file by adding the following line that calls our script:

. "c:\users\me\dev\powershell-dev-environment\src\profile.ps1"

Because we're all so lazy : a little install script

The previous step can easily be automated with the following bits:

# install.ps1

$installedHint = "#https://github.com/thatfrankdev/powershell-dev-environment"
$installed = $false

if(-not (Test-Path $profile)){
    New-Item $profile
}
else{    
    $installed = (Select-String -Path $profile -pattern $installedHint | Measure-Object).Count -gt 0
}

if(-not $installed){
    Add-Content $profile ""
    Add-Content $profile ". `"$PSScriptRoot\src\profile.ps1`" $installedHint"
    powershell.exe
}

The next step

We now have versatile base structure to build on. That's just a start...

In a next post, I will explore some handy helper functions that can greatly improve your daily flow.

Thanks for reading, hope you enjoyed it :)

English is my second language, so please tell me if you spot a typo, a grammar error or anything that could make this post hard to read. I'm constantly trying to get better at it.

Hi, I'm Francis. Call me Frank.

Francis Cote — Wed, 24 May 2017 03:27:58 +0000

I live in beautiful Quebec City, Canada.

I work for Spektrum, a dev agency.

I mostly program in C# and Javascript, and I tend to like Regex quite a bit.

I am currently learning all things NET Core, and how to designing software in an efficient way for customers (yes, DDD, totally).

I like Jimmy Bogard a lot.

Did I mention Azure? Yeah, big Azure fanboy here.

I just started blogging in french (native language) on 42 lignes Ã l'heure. I plan to port my posts to english on dev.to to reach a wider audience and ignite some discussions on topics that matter to me.

Nice to meet you all folks, stay tuned for my first post!