DEV Community: John

Visual Studio Code on a remote server

John — Sun, 08 Sep 2019 02:14:35 +0000

These days, it is easy to set up a web server where you can program remotely using virtually any client device.

It is not difficult to do this using secure shell alone, but here are a few methods that can enhance this experience using the Visual Studio Code editor.

Definitions

CL = Command Line
FS = File System

Pre-Requisites

This tutorial assumes that you are already famaliar with using secure shell (SSH).

You should at least be famaliar with logging into a remote server using key-based authentication.

Method 1 : code-server

Code-server creates a web server with an instance of a web version of Visual Studio Code that you can access via a browser.

Install code-server on your server.
Access server's CL via SSH.
On server, run code-server <path to workspace or directory>.
You can access server's FS and CL through password-secured web interface at :8443

Method 2 : sshcode

Sshcode works similarly to code-server (it's actually built on top of it) but uses a client program to set up the web server. Additionally, if you're using chrome, it will open a customized window with Visual Studio Code keybinding in tact.

Install chrome and sshcode on client
On client, run sshcode <user>@<serveraddress>
Access server's FS and CL through chrome window.

Method 3 : Visual Studio Code

Install Visual Studio Code on client
Install Remote - SSH extension
From extenison menu, connect @
Access server's FS and CL through Visual Studio Code
From extension menu, tunnel ports from server to client.

Next Steps

To supplement the above methods, you may want to learn about:

mounting file remote folders locally and using any editor you want using sshfs
accessing other resources on your remote maching via tunneling.
mitigating unstable remote [mobile] connections with mosh.
customizations and pitfalls of above programs by reading their documetion.

Angular Done Right: Part 1 — Binding and Directives

John — Sun, 08 Sep 2019 02:13:52 +0000

Originally Published: https://medium.com/@iamjohnhenry/angular-done-right-part-1-binding-and-directives-6112a43aa1dc

Author’s Note: While I no longer program heavily using angular, in favor of using smaller, more modular libraries, the reader will find the ideas presented in this series useful.

Angular is hard, right?

Well, one thing that’s for sure is that Angular is a massive. It’s a full application framework made of components including directives, controllers, services, and much much more. It’s shrouded in strange new concepts such as “Dependency Injection” and “Transclausion”. Despite it’s overall allure, anyone creating an angular app for the first time must accept that he or she is in for a steep learning curve due before being able to build anything fun or useful.

That’s the approach that most tutorials on the web take. In this series we take different approach. We’ll gradually build upon the most basic concepts in angular; first introducing the bare minimum needed to build an application and building upon it as we go along.

Installing Angular

We’ll start with a very basic HTML page. Create a basic html page with the following code inside:

    <!doctype html>
    <html>
     <body>
     </body>
    </html>

The next thing that you need to do is to download and include the angular.js file. You can download it directly from the Angular JS homepage, or, if you perfer, using the Bower package manager. I won’t go into specifics, on how exactly how to do that, but having made it this far, I doubt that you’ll have any trouble :).

Once you’ve included the angular file in your app, your file should look something like this:

    <!doctype html>
    <html>
     <body>
     <script src=”path/to/angular.js”></script>
     </body>
    </html>

Bootstrapping

Bootstraping is a term used for connecting your angular application to the web page. Don’t get it confused with the popular UI framework.

There are two ways of bootstrapping an application. The easiest and most reliable way is to add the *ng-app *directive to an html element. That element and all of it’s children will be part of your angular app.

“What are directives?”, you must be wondering… Well, for now, just think of them as attibues that you can add to your html that let your app interact with angular. We’ll learn more about directives very soon, and in a later part of the series.

We could put it on any element — the tag; a tag — but lets go ahead and put it on the top level “html” element. This way, the entire page will be available to our application.

    <!doctype html>
    <html ng-app>
     <body>
     <script src=”path/to/angular.js”></script>
     </body>
    </html>

There is another way to bootstrap your application (it actually uses the angular.bootstrap method!), but I have found it to be much more error-prone, so I wont at least into that method… at least not today.

Binding

— ng-model and ng-bind

Now that you’ve set up the application, binding data is the simplest thing that you can do in angular. Try modifying your html to look like this:

<!doctype html> <html ng-app> <body > <input ng-model=”input”> <span ng-bind=”input”></span> <script src=”path/to/angular.js”></script> </body> </html>

You’ve added two new directives. The** ng-model **directives allows you to bind a variable to a standard html element that receives user input. This can be either an input element, a textarea element, or select element. (If you’re familiar with jQuery, this might remind you of the val method.)

The ng-bind directive does something similar, but but it works by replacing the inner html of any html element with the bound variable. (If you’re familiar with jQuery, this might remind you of the html method.)

input is the name that we have chosen for the name of the variable to be bound, but we could have chosen pretty much anything.

Note: the variables exist within the scope of the application and not on the page. A variable defined within javascript will not be bound. We’ll learn exactly “where” these variables live in a later chapter on controllers and scope.

<script> var input = “Sorry, I’m not available for binding.” </script>

You can also use the double curly braces syntax, “{{input}}”, instead of ng-bind to add binding anywhere without the need for an HTML element:

<!doctype html> <html ng-app> <body > <input ng-model=”input”><span>{{input}}</span> <script src=”path/to/angular.js”></script> </body> </html>

If you open the page in a browser, you will see an empty box, and when you type box, you’ll see that it’s bound to the span right next to it.

This might be useful for, say, a form:

<form> Name:<input ng-model=”user.name” ng-required=”true”> <br /> Favorite Color: <select ng-model=”user.color”> <option value=”not available”>N/A</option> <option value=”red”>Red</option> <option value=”green”>Green</option> <option value=”blue”>Blue</option> </select> <div style=”background-color:{{user.color}}”></div> <button>Submit</button> </form> <p>Your name is <b ng-bind=”user.name || ‘Blank’”></b> and your favorite color is <b ng-bind=”user.color”></b>. </p>

Notice that the user.name and the user.color properties are bound to other parts of the form.

You may have spotted the ng-required directive on the input tag. That’s prevents a form from being submitted unless the required value is filled out. Try submitting the form below without typing in a name. (Be Warned: This may not work in all browsers.)

It’s also useful to be able to perform calculations on the page. Here’s a simple tip calculator. It a bit off (check out those rounding errors!), but it starts to show you what you can do with an angular app.

Bill: <input ng-model=”bill”> <br/> Tip Percentage: <input type=”number” ng-model=”tip”> % <br/> Total: $<span ng-bind=”(1 + (tip/100) ) * bill”></span>

A Few More Directives

— Showing and Hiding Elements with ng-if, ng-show, ng-hide

Conveniently, attaching the ng-model to a checkbox or radio allows you to bind to its checked property rather than it’s value.

<input type=”checkbox” ng-init=”checked=true” ng-model=”checked”> <span ng-show=”checked”>The box is checked</span> <span ng-hide=”checked”>The box is not checked</span> <span ng-if=”checked”> :) </span>

And we can use this fact to demonstrate a few new directives.

Although I’m not using for it’s single recommended use case, the ng-init
directive allows you to initialize a variable’s value — otherwise it starts off as empty.

The ng-if, ng-show, and ng-hide directives work to show and hide an element. The difference is that ng-if will remove an element from the page, if not visible, while ng-show and ng-hide will simply hide it.

— Repeating Elements with ng-repeat

A final useful directive is the ng-repeat directive that allows one to iterate through collections.

<ul ng-init=”beatles = [ {name : ‘John’}, {name : ‘Paul’}, {name : ‘George’}, {name : ‘Ringo’} ]”> <li ng-repeat=”beatle in beatles”> <span ng-bind=”$index”></span>.<span ng-bind=”beatle.name”></span> </li> </ul>

You’ll notice that in addition to the beatle property, the ng-repeat *directive also provides a **$index* property that can also be bound to the application. This **$index **is equal to the index of the iteration.

— Modifying data with filters

Just for the heck of it, let’s take a sneak preview of filters.

<li ng-repeat=”beatle in beatles | orderBy:’name’”> <span ng-bind=”$index”></span>.<span ng-bind=”beatle.name”></span> </li>

orderBy may look similar to a directive, but it’s not, it’s a filter. Filters work within certain directives to modify the data within them. This particular one changes the order of items within an array. You can read more about this and other available filters here. Like directives, filters are one of the nine or so components that make up an angular app and can be woven together with the others to make powerful applications.

Filters, like Directives, are one of the core components of angular. And we’ll learn a lot more about them in an upcoming entry.

Conclusion

With just few basic built built in components, you can start creating interesting apps with barely any code. I’ll be back soon with another update to this series, but in the meantime, start using Angular to make something cool!

Browsers, Servers, and APIs

John — Tue, 28 May 2019 03:13:36 +0000

Originally Published: https://medium.com/@iamjohnhenry/browsers-servers-and-apis-2f7b10523f39

(Or “The path to Isomorphic Javascript”)

Note: Examples in the article were tested and run using node and browserify.

If you’re a modern JavaScript enthusiast, you’re familiar with isomorphic code — the idea that you can write code that will run in both browser and node environments. Because JavaScript is a standardized language, you might think that this would be a trivial matter. The problem comes not in the language itself, but in the APIs, which are specific to each environment and not standardized to play well with others.

Some actions in one environment do not make sense in the other and so they lack specific APIs. The browser isn’t given access to the file system, so the fs object that comes with node would not make sense here. Conversely, when I was younger, I would make copious use of the window.alert for debugging, but a popup window won’t show up when you’re looking at a command line.

There are some actions, however, that can be done both within node and within the browser. One of the most interesting is creating servers.

Standardizing Servers

Traditionally you wouldn’t set up a server within a browser, but considering what a server does — accepts requests and responds asynchronously, we can think of many use cases.

For instance, a server within a service worker would be able to intercept and respond to requests within the browser, without ever having to make a call across a network.

//example -- service worker
const server = …;//define later

self.addEventListener(‘fetch’, function(event) {
 return event.respondWith(new Promise((resolve, reject)=>{
   const response = server.respondTo(event.request);
   response.on(“finish”, ()=>{
     resolve(req);
   });
 }));
});

We’ll come back to this idea...

Competing Standards

So, I want to put a server in the browser — what are my options? Not long ago, I learned about the new FlyWeb standard that Mozilla is pushing for creating servers within the browser. I was pretty excited until i realized how different it was from anything that already existed in node.

Every other server that I’ve seen follows a particular pattern…

HTTP

Node already has a built in simple API for creating servers via http.

//example -- http
//create server and define action
const server = require(“http”)
 .createServer((request, response)=>{
  ...//process request 
  response.end();//end response
});

//start server
server.listen(/*listening address*/);

This might be considered a standard, but many modern server applications are built to handle complex workflows.

Express

As the http module is quite simplistic, the express module is the de-facto standard for creating servers within node. It separates creating the server from assigning it actions. It also makes handling complex workflows easier. Express servers have a “use” method. It allows the user to chain together multiple functions to act upon a request before a response is sent. These functions are called “middleware”.

//example -- express

//create server
const server = require(“express”)();

//register middleware
server.use((request, response, next)=>{
  ...//process request
  next();//go to next middleware
});

//register middleware
server.use((request, response, next)=>{
  ...//process request
  if(request.endResponse){
    response.end();//end response
  }else{
    next();//go to next middleware
  }
});

//register middleware
server.use((request, response)=>{
  response.end();//end response
});

//start server
server.listen(/*listening address*/);

In addition, express adds additional features such as templating or routing which you may or may not need.

Koa 2

Koa was created by the same people who create express and is considered to be its spiritual successor. It’s also my server of choice, so you should take a look at how it works if you haven’t already.

Koa makes use of asynchronous functions and adding middleware works similarly.

//example -- koa

const server = require(“koa”)();

server.use(async (context, next)=>{
  ...//process request
  next();//go to next middleware
});

server.use((context, next)=>{
  context.res.end();//end response
});

//start server
server.listen(/*listening address*/);

Koa also eschews built in routing and templating in favor of including them externally as middleware.

Please be aware that Koa 2 is still in alpha, but since its API is so much cleaner than Koa 1’s, here’s a tutorial that will help you jump right in,

Rill

Rill is a new server that has basically the same API as KOA 2, but works in the browser as well as in node right out of the box.

//example -- rill

const server = require(“rill”)();

server.use((context, next)=>{
  context.res.end();//end response
});

server.listen(/*listening address*/);

Rill may be overkill for my purposes, as it includes routing features that manipulate the web page, in addition to simply processing requests into responses.

FlyWeb

There’s a basic pattern of that all of the other servers follow.

1 create server

2 add actions

3 start server

While rill or koa would have been a great starting point for a server in the browser, mozilla has taken a different route with their new FlyWeb servers.

//example -- flyweb

//create and start server
const server = await window.navigator.publishServer(/*listening address*/);

//add actions
server.onfetch = (request)=>{
  ...//process request
  request.end();//end response
};

This breaks the pattern of everything we’ve seen so far! Here the server is created and started first. Only afterwards are actions actions added.

Do we really need an entirely new way of doing basically the same thing?

I know. It’s in every article. Perhaps that says something to the importance of the situation. https://xkcd.com/license.html

@Rill/http to the Rescue

The creators of rill are pretty smart. When they created rill to work in the browser and in node, they realized the same thing I did at the beginning of this article — that dissimilar APIs are what make isomorphic code so difficult. So, to ensure that it works in both places, they created their own implementation of node’s low level http module, @rill/http, that works in the browser. Because it follows the same API, it can be, with a few tweaks, swapped into other modules that depend upon http, and allow them to work in the browser.

And that’s exactly what I’ve done with koa-2-browser. It’s literally koa that works in the browser! It’s a light framework, so it integrates easily with other code. And because the changes are relatively minor, I’m working on landing these changes in an upcoming release of Koa as to make it an isomorphic application out of the box. For now, you can take [nearly] all code that you wrote for a koa server in node, and transfer it to the browser.

Revisiting the service worker example above, we have:

//example -- koa-2-browser
const server = require(‘koa-2-browser’)();
server.use(/*middleware*/);
server.listen(()=>{

self.onfetch(function(event) {
    return event.respondWith(new Promise((resolve, reject)=>{
      const response = server.respondTo(event.request,{browserResponse:true});
      response.on(“finish”, (res)=>{
        resolve(res);
      });
    }));
  });

});

//Note:server.RespondTo returns a response, (here identified as "response") object that is not a suitable resolution for the promise passed to event.respond with. Passing the "browserResponse:true" option will cause the "finish" event to be resolved with a suitable instance of window.Response (identified as "res").

It’s important to realize that if we ever want to move towards isomorphic JavaScript, we should really shy away from competing standards within the language itself.

And this is true for open source software as a whole; if two different APIs do the same thing, they should have the same structure. When we set out to create something new, we should pay attention to and work with others who are already doing similar things in other environments. The less time we spend re-inventing the wheel, the more time we have to invent new and exciting stuff (hover-wheel anyone?).

Et tu, Buffer?

Servers aren’t the only competing standards across environments.

**Buffers** are standardized in node and **ArrayBuffers** are standardized in the browser. They are both containers for binary data, but they work slightly differently. This is particularly annoying when attempting to create isomorphic applications. Even worse, some objects that have a “buffer” method, may return an ArrayBuffer instead, meaning that you may have to apply special logic to work with them in different environments.

After many revisions, **Streams** are close to full standardization in node. Unfortunately, **Browser Streams**, an emerging standard, introduce new and incompatible parts of the API. Hopefully, the groups involved can come to an agreement at some point.

There are some other similar topics like importing modules, but that situation is way more complicated to go into her.

Bonus Library!!!

But trying new things is fun! I actually prefer the way that FlyWeb creates servers. Since it it appears that I’m not the only one, I’ve created another library, flyweb-koa. It allows you to use koa in a manner similar to the FlyWeb, while maintaining everything that koa has to offer.

const koa = require(“koa-2-browser”);
//This also works with koa;

const publishServer = require(‘flyweb-koa’)(‘koa’);

const server = await publishServer(/*listening address*/);
server.use(/*middleware*/);
server.onfetch = (context)=>{
...
};
server.respondTo(/*request*/);