History

A little history behind my personal website…

I purchased ceriously.com in 2010 because owning a dot com was “da bomb” as we used to say back then. I wanted a place to host personal projects and anyone who was cool owned their own domain. Maybe I would pick up blogging too. Who doesn’t like to talk about themselves?

I cobbled together some PHP pages and uploaded some .jar files via FTP because Java was a great way to distribute software back then (narrator: it is not). FTP was fine but then Git started becoming popular so I decided to setup SSH so I could git push to deploy my website.

For new projects, I found myself using GitHub instead of my personal website because it was much easier to manage source code as well as binary downloads (now called Releases). I started linking from my personal website to GitHub because all of the information was already there.

Requirements

Before I could rewrite my website from scratch, I made a few goals:

1. Fast — perf matters, no one waits for a blog that takes several seconds to load
2. No PHP — embrace JavaScript TypeScript and React
3. GitHub — must fetch my projects from GitHub API as source of truth
4. Dark Mode — must support both Light Mode and Dark Mode based on system preference
5. Markdown — must be able to author blog posts with Markdown
6. Domain — must use a sweet gTLD like .dev
7. Deploy — must use be hosted on GitHub and use git push to deploy

Solution

I decided to use Next.js because of a recent SSG feature that feels like SSR but it renders pages at build time. This allowed me to check off number 1 and 2 from the list because I could use TypeScript with React and ensure fast page loads because the generated pages would be static HTML. Next.js also hands client-side transitions which avoids a complete reload when navigating between pages.

For number 3, I utilized Next.js to fetch my projects at build time from the GitHub REST API using a personal access token. I didn’t want to show private or archived repositories so those are filtered out in the query.

I implemented support for Dark Mode and Light Mode by using the CSS media query prefers-color-scheme. It looks something like this:

The beauty here is that this media query respects the user’s system preference so enabling Appearance Auto in macOS Catalina will use the light appearance during the day, and the dark appearance at night. No more burning your eyes out of their sockets.

In order to implement Markdown blog post authoring, I reached for Marked, a project I help maintain that parses markdown and converts it to HTML. And, as you may have guessed, I used Next.js dynamic route segments to dynamically generate a page for each blog post. Is there anything Next.js can’t do?

The domain was easy. I actually purchased styfle.dev a year ago because .dev is the new hotness. Vercel makes it really easy to purchase a domain and assign it to a project in seconds.

Which brings me to my last step, deployment. I set up Vercel GitHub Integration with a few clicks so that each time I git push to my repository, a new deployment is created. The best part here is that Vercel will deploy Pull Requests to a Preview URL and even take screenshots of the modified pages using the Deploy Summary Integration. For example, see PR 13.

Conclusion

Overall, I’m happy with the new design and productivity boost. Perhaps I’ll start blogging again. If you want to see the source code for my website, you can find it on GitHub.

Originally published at https://styfle.dev on May 9, 2020.

In my use case, I wanted to pass back an object (more like a dictionary) that would contain key/value pairs for each localized string in the application. But the magic sauce here is that any missing string should return a See-No-Evil monkey emoji (🙈) because that means the developer mistyped a letter or maybe the string wasn’t translated at all! The monkey will not judge you.

Let’s look at some example JSON that is emitted when a good ol’ chap from across the pond visits our application (someone using en-GB).

{
  "color": "Colour",
  "elevator": "Lift",
  "pants": "Trousers"
}

At first, you might think that the ES5 Getter could solve our problem because you can override a property (such as elevator) and check if there is no value defined. But what about the keys you don't know about? You don't know what you don't know.

Enter the Proxy, where Bruce Lee plays a web developer determined to help capture the missing keys responsible for the death of his sister.

let obj = JSON.parse(json);
let l10n = new Proxy(obj, {
  get(target, name) {
    if (typeof target[name] === 'undefined') {
      console.error(`Localized string is missing: ${name}`);
      return '🙈';
    }
    return target[name];
  }
});

We call the localization object l10n because we're lazy and this abbreviation is commonly used according to Wikipedia and other lazy devs. Ain't nobody got time for typing. Why am I writing this article anyway?

Now back to the topic of Proxy usage…let’s talk about React.

React is great and you should use it because the internet told you so and that one blogger blogged about it on their weblog so don’t challenge the blog. Embrace the blogosphere.

const SelectAColor = (props) => (<div>
  <label>{props.l10n.color}:</label>
  <select>{props.colors.map(c =>
    <option value={c}>
      {c}
    </option>)}
  </select>
</div>);

Now that we have a React component, let’s see how it would render for users from different countries.

USA looks A-OK! Great Britain looks great! Mexico is ¡Ay, caramba! We forgot to translate into Spanish! The monkey does not lie but the monkey is forgiving.

The same would happen if you misspelled props.l10n.color for example props.l10n.colr in which case, the monkey would visit you again, shielding its eyes from your incompetence.

If you would like to see a demo, visit CodeSandbox to see the code in action and witness the magnificent monkey madness!

Originally published at www.ceriously.com on January 1, 2018.

ES6 Proxy and Localization was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today, in 2017, many evergreen browsers support ES6 Modules out of the box. Some browsers have it hidden behind a flag, including Node.js. But is it possible to support old and new environments with the same npm package? Yes!

Editor’s Note: ES6 Modules are sometimes referred to as ES2015 Modules, or ESM, or module scripts, or sometimes even by the extension .mjs pronounced "Michael Jackson Scripts". We are all talking about the same thing so don't get confused if you hear different terms.

I won’t go over the merits of using ES6 Modules or why TypeScript is awesome because there have been many blog posts describing these at length. Instead, I will focus on publishing a package to npm that is written in TypeScript but deployed as .mjs (ESM) and .js (CommonJS) so any consumer can use your package!

Getting Started

The first step is to setup your tsconfig.json file so that TypeScript will use the latest and greatest JavaScript features like so:

{
  "compilerOptions": {
    "module": "es2015",
    "target": "ES2017",
    "rootDir": "src",
    "outDir": "dist",
    "sourceMap": false,
    "strict": true
  }
}

Obviously, we want modules to be es2015 because hey, its in the title of this article so we have to address it at some point! Let's target es2017 so we can use async and await keywords like a JS Ninja. You can name your rootDir and outDir to whatever you want, but its a bit of a convention to use dist for output in JS Land. Source Maps are optional but I like to turn them off until I need them. Strict Mode is also optional but it's easier to start strict and get a little loosey goosey if you need too later. I highly recommend enabling it since it is disabled by default.

Wiring It Up

Now we can discuss the package.json file. Here's an example for a package called copee:

{ 
  "name": "copee",
  "version": "1.0.0",
  "description": "Copy text from browser to clipboard...natively!",
  "repository": "styfle/copee",
  "files": [ "dist" ],
  "main": "dist/copee",
  "types": "dist/copee.d.ts",
  "scripts": {
    "mjs": "tsc -d && mv dist/copee.js dist/copee.mjs",
    "cjs": "tsc -m commonjs",
    "build": "npm run mjs && npm run cjs"
  },
  "devDependencies": {
    "typescript": "^2.5.3"
  }
}

The first four lines define the package name, version, description, and GitHub repository which are self explainatory.

Next, we define files which we simply define as a single folder, dist. These are the files that will be published to npm.

The entry point into your package is defined as main and this is where the magic happens. Notice there is no file extension (such as .js) as one might expect. This will allow Node to pick the file based on the way the consumer is importing your package--either legacy CJS or the new ESM.

Next is types which is necessary for consumers who want to import via TypeScript. If you're writing your package in TypeScript, you should most definitely include types for your fellow TS users to get type saftey! Seriously, it's just the right thing to do.

Now comes the fun part: scripts. These are your build steps which can be run via npm run thenameofthescriptgoeshere. The first build step mjs uses the TypeScript Compiler (tsc) to build our code using the tsconfig.json file we defined earlier, plus a -d flag which emits our .d.ts type definitions. Also note the mv command which moves (or rather renames) the output file from .js to .mjs. This is our ESM output.

Our next script, cjs uses the TypeScript Compiler (tsc) to build the same source code but emit the output as a CommonJS module. This is the module system for Node.js and is understood by browserify, webpack, etc.

Lastly, we have devDependencies which are your build tools. In this case, all we need is typescript which includes the tsc command used above.

Node Usage

I’m going to show you how to write a consumer that imports the package above. If you already use Node regularly, jump to the next section for ESM usage.

First, install the copee package:

npm install --save copee

Then, create a index.js file with the following:

const { toClipboard } = require('copee'); console.log('CJS: We found a ', typeof toClipboard);

The new program can be executed like so:

node index.js

Node ESM Usage

I’m going to show you how to write a consumer that imports the copee package above.

After installing copee, create a index.mjs file. You must use the Michael Jackson Script extension (.mjs).

import { toClipboard } from 'copee';
console.log('ESM: We found a ', typeof toClipboard);

The new program can be executed like so:

node --experimental-modules index.mjs

Browser ESM Usage

Node usage isn’t that spectacular because there have been modules since its inception, but the beauty of ESM is that the same code executing in a Node module will run unchanged in a browser! Yes, it’s true! Feast your eyes on this elegant code snippet below:

<script type="module">
  import {
    toClipboard
  } from 'https://cdn.jsdelivr.net/npm/copee/dist/copee.mjs';

  $('#btn').on('click', () => {
    const win = toClipboard('Wow, "copee" works!');
      if (win) {
        // it worked, check your clipboard!
      }
  });
</script>

We have a new script type for module and we are using jsDelivr to automatically host our code on a CDN. This makes it easy to write a single import line and use the copee package in browsers all over the world!

Legacy Browsers

What about legacy browsers, you say? Not everyone supports ESM? Well this can be solved by bundling as UMD with rollup. After installing rollup, add this to the scripts section of your package.json file.

{
  "umd": "rollup -i dist/copee.mjs -o dist/copee.umd.js -f umd -n copee"
}

You can include both ESM and UMD builds on the same page without conflicts. See the snippet below:

<script nomodule src="https://cdn.jsdelivr.net/npm/copee/dist/copee.umd.js"></script> <script type="module">
  import {
    toClipboard
  } from 'https://cdn.jsdelivr.net/npm/copee/dist/copee.mjs';
</script>

By using the nomodule attribute, you are telling new browsers to ignore the UMD script. By using type=module you are telling old browsers to ignore ESM. Now everyone wins!

You can see a working demo of this solution on the Demo page.

Also, please checkout the GitHub repo for more details and of course, the working source code!

Originally published at www.ceriously.com on October 16, 2017.

ES6 Modules Today With TypeScript was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Okay, well every day is a learning experience so let’s dive a bit deeper and maybe you can learn something new too!

Let’s Get Secure

By now, you probably already have a free HTTPS certificate from the wonderful Let’s Encrypt organization or another reputable Certificate Authority. But HTTPS is just one step in securing your website.

Mozilla Observatory provides a whole suite of tests to check your website for best practices such as HSTS, XSS preventative headers, and sub-resource integrity for any external assets. It will give you a score out of 100 and a letter grade to bolster your self confidence.

The reason for my F was simply ignorance. None of these features were implemented and I received a mere 5/100 score on Mozilla’s scale. My goal was to hit 90, which is considered an A.

Try it on your website now by visiting https://observatory.mozilla.org

How did you do? If you’re like me, you might not be constantly updating your website, blog, or app so maybe your website failed too. No worries.

If you are using Apache as a web server, you can quickly learn from my mistakes and just grab the following .htaccess file and drop it in your web directory. Or view this web.config if your are more familiar with ASP.NET.

The headers are taken straight from the Observatory results where you can read more about the intent and security implications (really, go read the docs). You might want to change the Content Security Policy to be a little more strict and protect against XSS if you website has any user input.

Below the headers, there is a redirect to make sure the browser is always redirected to https://www.* This will make Google (and your visitors) hit the secure www sub-domain. This is good for security, and good for SEO.

I also changed <script> tag to include a sub-resource integrity which will avoid executing a malicious script if the CDN is compromised. This was easy because the jQuery CDN already supports this feature and provides the hash on their download page.

<script src=”https://code.jquery.com/jquery-2.2.4.min.js" integrity=”sha256-BbhdlvQf/xTY9gja0Dq3HiwQF8LaCRTXxZKRutelT44=” crossorigin=”anonymous”></script>

If your CDN doesn’t provide this information, you can use a tool like SRI Hash Generator.

That wasn’t so bad. With the additional headers and one line of HTML, Observatory is reporting the coveted green A with a score of 90!

Compression and Caching

Now that your website is secure, why not make it fast too?

Take a look at the <ifmodule> checks in the .htaccess file above.

The deflate header will compress assets such as html, css, and js before sending it over the network. This means first-time visitors will see your content faster.

The expires header will tell the browser to cache the assets for several days since they likely don’t change often enough to warrant a round trip to the server. This means that returning visitors will see your content really fast.

Adding these two settings gave me a 94/100 from Google PageSpeed Insights on Desktop. Try it on your website and see how you do!

Let's Get Secure | ceriously.com

Web Security: Best Practices in 2017 was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ok so you already knew all that history because you’re a young, hip, state-of-the-art, JavaScript developer who writes hand-crafted, artisan-made code aged to perfection. Big whoop, wanna fight about it?

But did you know that Node.js 8 will have a Promise API shipped in core? No way? Too good to be true? Well yes, I may have fibbed a bit.

Node.js 8 will have a utility to “promisify” any core API. This is just as good and will keep the Node.js core small.

How does it work?

I’ll give you two easy steps: Require and Wrap.

1. Require const promisify = require('util').promisify;
2. Wrap const stat = promisify(require('fs').stat);

Ok so now you’re saying this is exactly what bluebird does because you’re a savvy, hipster code-monkey who started using Promises before they were cool.

You would be correct except that you’re missing how important this is! This means user-land dependencies are no longer needed to write async/await! Hurray! See the following code example.

Get On With It!

Here is is a simple example that updates an existing file or creates the file if it does not exist.

Some say this is callback hell, but we only went a couple layers deep so it’s really more like callback purgatory. Now let’s see how it looks with promisify!

This code is asynchronous but there are no callbacks! The use if/else and try/catch is pretty intuitive and looks like synchronous code.

Now there is a little bit of boilerplate in order to promisify each function. So how about a helper function?

Not too shabby! Now it’s your turn to see what kind of async code you can cook up with Node.js 8!

Promises in Node.js 8.x Core | ceriously.com

Promises in Node.js 8.x Core was originally published in Frontend Weekly on Medium, where people are continuing the conversation by highlighting and responding to this story.