Forem: Jake Lacey

Building your first Deno module

Jake Lacey — Sat, 09 May 2020 08:17:19 +0000

First let's understand how modules are loaded in Deno.

import aModule from 'https://some.com/thing/mod.ts'

We can understand a couple of things from this line
1) The modules are loaded in by URLs, so we need to host our modules somewhere?
2) The modules are loaded in directly from their Typescript code, so we don't need any complication step.

So where do we host our modules?

There are a couple of options,

You can either host them yourself, like push them to S3 or something like that.
You can raise a PR for them to be added to the Deno standard library.
If you are using Github to host your code then you can use their raw.githubusercontent.com service to access the raw code.

I think I prefer the third option of using Github and I'll get onto the reason why later down.

So how do we build a module?

I'm not going to go into a lot of detail of testing and all that stuff all I want to do is demonstrate how to build a basic module.

Step 1: Create a mod.ts

// inside mod.ts
const hello = (name: string = 'world') => `Hello ${name}`;
export default hello

Step 2: Create a repo on Github

Step 3: Push the changes to the repo

How do we use the module?

Well I called my repo https://github.com/jakelacey2012/deno-hello-world, so I'd import it something like this.

import hello from 'https://raw.githubusercontent.com/jakelacey2012/deno-hello-world/master/mod.ts'

hello('you');

Thats it you're ready to use the package :woop: :woop:

So why do I prefer this option?

I don't see a package like this needing to be part of the standard library.
I can easily control the version of the package by swapping out master to a release or another branch.

Thanks for reading

If you're having any issues with this, I'd suggest reading up on Deno. That being said feel free to ask questions in this repo https://github.com/jakelacey2012/deno-hello-world

vscode package recommendations

Jake Lacey — Mon, 13 Jan 2020 18:15:28 +0000

I love using extensions in vscode. However one of the things that worries me is what if another engineer on the project doesn't have this installed. How do they discover the package and have the option to install it if they want.

I don't have to worry about this anymore as vscode allows you to create a .extensions file in the ./.vscode directory, within your project. Which can look something like this....

{
    "recommendations": [
        "the-name.of-the-package" // which can be found by looking to the title on the packages page.....
    ]
}

Now when someone does a search for @recommendations, these packages which come up.

This also has the added benefit where I can find an extension for a specific project that I'm working on from time to time, document it in this file and then install it in the future when I come back to the project.

Securing your docker images with Github actions for FREE!

Jake Lacey — Sun, 03 Nov 2019 20:18:34 +0000

Securing you containers is massively important and the consequences of not
doing so will put your customers at risk. However it is really difficult to do with out paying top dollar or having an experienced DevOps team to constantly monitor your images and apply patches.

As developers we want to build our products and build them fast, so if we can automate this process so that we're only notified when they're issues then great!

So today we're going to secure our images using Github actions and Phonito.io for free!

What are Github actions?

GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub. Make code reviews, branch management, and issue triaging work the way you want.

Pretty awesome huh! and you don't have to manage infrastructure like that nasty Jenkins!

What is Phonito.io

Phonito.io is a vulnerability scanning tool for the everyday developer, it scans numerous databases and informs you of the latest vulnerabilities and for CI integrations its FREE to use!

Even if you've never built a Github action before this is a great place to start

So let's get started

Go to the "Actions" tab of a Github repo.
Either add a new workflow by copying the yaml below or add the Scan with Phonito Security step after your Docker build from this example workflow.

name: Build & Scan Docker Image
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1

      - name: Set tag var
        id: vars
        run: echo ::set-output name=docker_tag::$(echo ${GITHUB_REF} | cut -d'/' -f3)-${GITHUB_SHA}

      - name: Build the Docker image
        run: docker build . --file Dockerfile --tag myapp:$@{{ steps.vars.outputs.docker_tag }}

      - name: Scan with Phonito Security
        uses: phonito/phonito-scanner-action@master
        with:
          image: myapp:$@{{ steps.vars.outputs.docker_tag }}
          phonito-token: ${{ secrets.PHONITO_TOKEN }}

Next thing we need to do is get our API key from Phonito.io,
- Register at Phonito.io
- And get your API key 🔑

Add that API as a secret with the name PHONITO_TOKEN to your repo.

And thats it 🎉

Next time you push to your repo this scanner will run and check for any vulnerabilities that you have. Its as simple as that and FREE so there is no excuse to release software which is insecure!! :)

If you're stuck look at this example repo or raise an issue here.

Releasing a project for once in my life!

Jake Lacey — Sun, 06 Jan 2019 11:46:23 +0000

Why is this so important to me?

I've been developing for around 7 years and at the start of my career I would have very simple ideas, unoriginal ideas like a blog engine or an online store. I also had no idea how to deploy an app "correctly". So in my naivety I was able to build something relatively quickly and release it to the world.

Self-aware of this so one of my initial goals in my career was to understand the fundamentals and learn how to do things "correctly".

This had a downside... I just stopped releasing things! I had ideas, almost one every month but for one reason or another the idea would lose momentum and die. Honestly my Github account looks like the church scene in 28 Days Later. The amount of things I felt I needed to do to make it robust enough would just take to long so to be blunt with myself I gave up.

So before the new year was up I made a promise to release a project I was working on during the holidays! https://twitter.com/Jake0Lacey/status/1079126414610309120

I would like to share my experience and what I did that made this endeavour different and hopefully help some other people.

I'm going to split this the next bit into a couple of different sections.

I was building this for me
Design and scope
The technical approach
Accountability
Done it better than perfect

I was building this for me

This was a big motivator, previous projects were interesting technically however I was not the target audience, so they would die as I had no one to play with them. It really does help if your making the app for yourself, it pushes you to find a way to use it.

Design and scope

Because I knew I wanted to use it I needed to find the MVP, what was a good enough idea so I could start using it on the first day!

What I did was sit down and design how I wanted it to look and then stripped back the features so I only had one feature to worry about it had to be a good base to build and iterate everything else on.

This allowed me to focus on what I had to build, nothing more, nothing less.

The technical approach

My approach was a very aggressive one and I don't advice this if your practising a technique or skill but if your wanting to get something released quickly then go for it.

I'd like to expand on what I mean by aggressive, what I mean is that technical dept, duplication, poor performance & no unit/integration tests are welcome. Why because this kinda stuff only matters if the idea is successful and people are using it, then I can shift my focus.

Also this doesn't mean I just assumed things worked, I did test things hahah.

Accountability

Previous ideas I would write on a notebook when I wanted to release something and would have dates on when I would finish x, y and z features. However I've found this really means nothing because the dates can be easily moved around.

So to make sure that you have accountability I would say that you share it with someone, I shared mine with Twitter and go some positive support which made me feel determined to get the work done!

Done is better than perfect

I would love to release something that looks the way I imagined it or works 100% of the time, that doesn't have performance issues, that has 100% test coverage, that has CI/CD, that autoscaled and you get the point.

Perfection is a direction not a destination.

Being able to iterate on an idea that has already been released feels a lot better than slugging away for a couple of months on an idea and constantly asking yourself if its ready yet.

Anyway...

I hope this can help some people, it might be a little bit rambley. Also if you would like to know what I'm working on please do message me on Twitter! Its a project where you track things...

Also I couldn't have done it without @pixeldrift, so thanks!

Also found this little 💎 on my travels!
https://www.youtube.com/watch?v=mT8OCw1ES8M