3 Pasture raised eggs
3 tbs pasture or grass butter
3 tbs plain yogurt
3 tbs green onion
Salt, Pepper

Beat eggs, butter, yogurt with a mixer until fluffy
Pour into moderately hot skillet
Mix with wooden spoon while taking pan on and off heat
Just before cooked and fluffy, add onion, salt, pepper

Governments everywhere in the world are demanding the right to decrypt communications. Every service provider can be expected at some point, to comply.

As long as any centralized system keeps your secrets it has to be considered insecure.

Only a system where you alone maintain your key, is necessary for any reasonable assumption of safety.

Nevertheless, security measures in 2018 are still difficult to understand and operate for the non-technical person.

Simplesign is an effort to simplify and leverage the very basic essentials of public/private key usage. It’s principles are:

Easy to use
Easy to embed
No shared secrets

In development and any contributions consistent with the project goals are welcome.

Its time to get real about YOUR private keys was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

The announcement of the indictments in trolling to influence the 2016 election is not only a big political story, but a big tech story. Now, there’s major legal action about something that’s been going on for a long time.

It brings to the forefront major new ethical and political matters which have been unleashed by the connecting of the world. Hopefully, this will encourage debate about some important issues facing us. We have had some discussions about privacy, and beginning to experience the backlash against the tech titans. But a knee-jerk reaction against the latest powers-that-be (big-tech) or a superficial debate on privacy or the influence of social media won’t cut it long-term.

We need to reaffirm, and if necessary re-evaluate, what our values really are. What kind of world we want to live in, and what changes are necessary. Everyone would agree we need some changes.

I was researching Twitter using their APIs during the election and the trolls were out in force.

This is why nuance and thoughtful debate is good. Not tweets. Pouring gas on a fire is the easiest thing to do.

Liz on Twitter

Chelsea Manning deserves transition treatment, and your taxes should pay for it

Retweets we’re especially suspect in my experience, and there were many thousands every time Trump got going. But, proving “collusion”, in these matters is always a waste of effort, unless one makes a serious mistake — such as recording oval office conversations and letting those tapes get out!

The ability of sympathizers to act on their own gives the leader deniability. This cannot be overcome and the proof cannot be gotten. Without a serious error, collusion can’t be proven.

So, why hasn’t Twitter purged all the bots. Granted some are more obvious than others, but creating bots is much like hacking. As soon as you mount a solid defense, the hackers develop a new technique, and its a never ending game.

AI, of course will make it even easier to fake being human. But where’s the AI to detect bots?

Who needs AWS or hosting charges? With Cloudflare Warp, you can get a server up and running in your home in minutes. All without DNS or DMZ configuration or bulky frameworks.

Just run your web server of choice on your machine, and Warp handles serving it up through Cloudflare. Warp is a new feature which (at time of this writing) is currently in beta.

This frees us from having to get a host. In the past, just running on your home network required opening ports on your firewall. An easy thing to screw up.

Also, by now (2018) everyone should be running ONLY HTTPS.

Configuring HTTPS has gotten easier over the past few years, but the great thing with Warp, you just run your site as an HTTP server and Cloudflare handles the rest.

Let’s get started.

First, we’ll use httpsd, which has binaries for Linux, Win, and Mac.

digplan/httpsd

httpsd is an instant-on web server, whose output is generated by a provided shell script.

Make the shell script, which will be called index.sh here:

cat index.html

and our index.html

<!DOCTYPE html>
<h1>Hello World</h1>

and start it up!

./httpsd ./index.sh --insecure --port=8080

Using the *— insecure* flag will start an http instead of an https server, which is ok, because Cloudflare is going to handle the https in a very easy way.

You can use any web server. For instance, there is Simple HTTP Server for Python:
http://www.pythonforbeginners.com/modules-in-python/how-to-use-simplehttpserver/

Cloudflare Warp, is just a simple binary, that tunnels to Cloudflare servers, and serves up your site.

Cloudflare Warp | Cloudflare

I’ve changed the name of the binary to just warp, which makes things even simpler. With our domain name servers hosted with Cloudflare, we just start it up.

$ ./warp --hostname=www.mydomain.com --url http://localhost:8080

and that’s it, hosting made simple.

Drop Your Hosting Provider With Cloudflare Warp was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here’s a template to get up and running for automated testing and publishing of JS client or server code

There are a lot of dependencies out there. Clearly, the world needs more automated tests. But, we need to get up and running quickly.

Goals:
Must be free, as in money
Must have tiny learning curve, few magic words to learn!
Must be UI free. Test client code using headless Chrome
Use Travis CI for automated testing, with pass/fail badge in github
Run tests on every commit
Easy publish to NPM and memorable URL for including scripts in web pages

So, on every commit to the github repo:

1. Travis CI will start up its testing instance
2. Install the latest Node version, and Chrome browser
3. Start Chrome for headless testing
   (only needed for projects that are client JS)
4. Run two example test scripts. One for testing server apps, and one for browser JS
   (One of these can be eliminated depending on whether yours is a node app, or client script)
5. Show result of testing
6. Publish to NPM if successful
7. Show pass/fail badges for the project in NPM and github.

You can add/remove to this as needed, depending on the needs of your project.

Here’s all the files:

For Travis CI, which will host the testing, just a .travis.yml file is needed.

If the project is a Node app and not client JS, you don’t need the Chrome parts.

It will also publish to npm. For client scripts, we can use a short, easy to remember link using unpkg.com

No fancy testing frameworks to learn here. We simply write our test scripts, which throw errors on failure.

The testing framework is as follows, any native error constitutes a failed test.

For Node applications, test-server.js

main.js is the main file in the app. What is being tested.
If we had called test_fail, the test would fail and Travis would tell us so.

test-browser.js for client scripts.
Since we really want to automate things, we can’t have a UI. No-one will be around to click things. So, headless chrome is used to run tests.

testchrome, is just a simple wrapper on the chrome remote interface used for headless testing.

testchrome happens to use a simplified API, just
.evaluate (JS in the browser)
.get (JSON from a URL)

Alternately, you can use the other headless Chrome testing modules that are available, like puppeteer.

Getting this setup locally on a machine can be unpleasant. Travis CI really shines here!

Going to travisci.org (for public repos), and follow the instructions to set up your repo. Connect your Travis CI acct to github, and specify your repo for testing.

There is one configuration needed on Travis, your NPM token which will let Travis publish the app, in Settings:

Then just commit to the repo, or use the console, to start a test.

Monitor your test in the Travis console:

and view results

One last thing, the badge. In the README.md of the repo:

which always shows our passing/failing badge in NPM and Github.

Finally, we need an easily remembered URL (for client scripts). Using unpkg.com with no additional config required, cause it will pull the latest from NPM.

<script src=//unpkg.com/reponame ></script>

Of course, for server apps, simply

npm install reponame

That’s it, for our framework that provides automated testing and publish. Please comment with any thoughts or suggestions. The example repo is at https://github.com/digplan/learn-ci

Happy testing!

Learn CI: Automated Test and Publish in 10 min was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over time, all software gets bigger and does not necessarily get better.

Current web development tools and processes have made a web that is too hard to build, debug, and support. A myriad of tools is suggested.

Web applications evolved out of static web pages. Not recently, but almost immediately in the 1990s. The need for dynamic web apps is nothing new.

But, as happened with other software, as computing resources and network speeds increased from the mid 1990s to the mid 2010s, they got bigger and more complex.

Security vulnerabilities are rampant, and given the importance of the web in global communication and commerce, is more dangerous than ever.

This is not acceptable.

Larger and more complex applications mean more security problems.
Larger and more complex applications cost more, in every way.

The world is now seeing the birth of the 2nd generation of Internet technicians and programmers, who need a dozen different unproven tools.

In many applications, you can’t simply just read HTML source and make any sense of it. Or you need a build step(s). Text into text. Into text.

Web components do not enjoy widespread use. You can’t easily reuse components like dropping them on a form without expensive and opinionated overhead.

New frameworks proliferate, because many are not satisfied with what’s available.

People will say, the needs have gotten more complex. But unnecessary complexity has outpaced requirements complexity for years.

Every new tool to learn is a barrier.

New technologies are promising, but HTML CSS and JS are fundamental to the web. Maybe they’ll be replaced but not soon.

This is not acceptable and needs to be reformed.

Friday Night Manifesto for Better Web Development was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

A great struggle in moving web dev forward, is the lack of a complete consensus on web components.

This is evidenced by the fact there are frameworks all over, each with their overhead and own ideas, and some common UI components are still developed from scratch.

This is to be expected though, since Frameworks force you into their world, so while a React or Vue component is reusable, you must commit to that framework. Some of us have issues with commitment.

There’s shrinks for that, but they often don’t fix anything.

There is the Web Components standard, born out of the fact that jamming together HTML/JS/CSS is conceptually quite unpleasant.

For instance, we can put Google Maps on our page, as their tutorial instructs.

<div id=”map”></div>

<script>
 function initMap() {
  // Create a map object and specify the DOM element for display.
  var map = new google.maps.Map(document.getElementById(‘map’), {
    center: {lat: -34.397, lng: 150.644}, zoom: 8
    });
 }
</script>
<script src=”https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMap" async defer></script>

But, is exactly the point. It’s on our page, not in our app.

Of course its a problem of needing the script to load before we use the google.maps object. The script tag should be after the HTML. It’s not nice.

In a world where we probably need many components on the page, we’re stuck with initMap as our entry point. We’re probably loading other scripts, etc.. Gets messy.

So, let’s try a different approach. We have to load JS dynamically.

var e = document.createElement(‘script’)
e.src = s; 
document.body.appendChild(e)

For simplicity, we’ll go ahead and call this function load.

const load = async (s) => {
  return new Promise(async r=>{
   for(i=0;i<document.scripts.length;i++)
     if(document.scripts[i].src == s) return r()
   let e = document.createElement('script')
   e.src = s 
   document.body.appendChild(e)
   e.onload = r
  })
}

This promise gets fulfilled when the script has loaded. It also checks first, to see if the script has already been loaded.

So, now we may make our reusable component, a gmap function:

const gmap = async (e) => {
  return new Promise(async r=>{
     e.style.height = e.style.width = e.getAttribute('size')
     let latlng = e.getAttribute('latlng').split(',')
     await load('http://maps.googleapis.com/maps/api/js?v=3')
     let map = new google.maps.Map(e, {
      center: new self.google.maps.LatLng(latlng[0], latlng[1]),
      zoom: 14,
      mapTypeId: google.maps.MapTypeId.ROADMAP
     });
     r(map)
  })
}

This is an async function, which will await the load script to complete. This will ensure everything gets done in order. We may want to have multiple maps on a page.

<div control=gmap size=200px latlng=33.808678,-117.918921></div>
<div control=gmap size=200px latlng=28.3852377,-81.5660627></div>

and feed the Divs to the gmap “component” to create the controls

(async () => {
  let controls = document.querySelectorAll(‘div[control=gmap]’)
  for (var i = 0; i < controls.length; i++)
    await gmap(controls[i])
})()

All dependency-free and in vanilla JS.

The important thing here, there’s very little to remember.
Div, Function, and language features.

Not sure which model will win out, but it is possible to just use the language without the extras, and fun too.

Let’s make Reusable Web Components: Google Maps was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Async/await and its underlying use of promises are taking the JS world by storm. Now supported by a majority of client and server JS platforms, callback programming is becoming a thing of the past.

Surely, callback based programming is ugly.

If you haven’t already, it’s worth getting your mind around async/await and promises. I personally haven’t been a huge fan of promises, before async/await, as you can get code like this:

Better than callback hell, but not aesthetically pleasing.

There are many good intros to async/await available, so I won’t go into a full discussion here, but the 15 sec. tutorial is, you have your function return a promise, and then use await (inside an async function) to call the promise.

These examples will also make use of a new-ish JS feature, arrow functions.
If you’re unfamiliar with writing in this style, basically this:

function(a) { return console.log(a) }

now use this,

(a) => console.log(a)

With that, we are ready to make our Wait function.

Using a Wait function, also called Sleep in some environments, is very easy to understand, read, and write. It’s easy to make sense of it. We want execution to wait for a period of time.

Just set a timeout for resolving the promise. We can provide ms for how long to wait.

var wait = ms => new Promise((r, j)=>setTimeout(r, ms))

wait(2000) returns a promise, that will be resolved in 2000ms (2 sec.)

// Promise syntax
var prom = wait(2000)  // prom, is a promise
var showdone = ()=>console.warn('done')
prom.then(showdone)

// same thing, using await syntax
await wait(2000)
console.warn('done')

Using async/await syntax, which is nicer than promise’s .then() syntax. Let’s wrap it in an Immediately Invoked function for brevity.

(async () => { await wait(2000); console.warn('done') })()

Or amidst regular code

var x = 1
var y = 2
await wait(2000)
console.warn(x)

What if we want to wait on an event, instead of just waiting x ms of time?
Just control when the promise is resolved.

We may even timeout the call, if the event never occurs, so the code doesn’t wait forever.

Let’s say we want to wait on a DOM element to be set to “Hello World” in a web page. We’ll check every 100ms and timeout after 2 seconds.

<div id=a>s</div>
<script>

var e = document.querySelector('#a')
  
  var waitForHello = timeoutms => new Promise((r, j)=>{
    var check = () => {
      console.warn('checking')
      if(e.innerHTML == 'Hello world') 
        r()
      else if((timeoutms -= 100) < 0)
        j('timed out!')
      else
        setTimeout(check, 100)
    }
    setTimeout(check, 100)
  })

//setTimeout(()=>{e.innerHTML='Hello world'}, 1000)

  (async ()=>{
    a.innerHTML = 'waiting..'
    waitForHello(2000)
  })()
  
</script>

Un-commenting the setTimeout line will set the DIV after 1 second, otherwise will time out.

As you can see, async/await opens up great new possibilities in your code.

Let’s make a JavaScript Wait function was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

JavaScript ES6 has a variety of new features when compared to its predecessor JavaScript ES5. Let’s take a look at Assignment Destructuring and how it helps programmers simplify their code.

[a,b] = [1, 2]
// a == 1
// b == 2

{a,b} = {a:3, b:4}
// a == 3
// b == 4

Assignment Destructuring allows for easy binding of the same properties to as many variables as desired. It also works in both arrays and objects, further expanding its scope. It makes pulling out specific properties from different objects an easy task and also allows for aliasing of properties too.

Objects default to undefined if no data is provided for that object.

[a, b, c] = [5, 6];
// c === undefined

We can ignore certain values if necessary.

var [a, , b] = [1, 2, 3];
console.log(a, b); // 1 3

We can combine values.

[a, ...b] = [1, 2, 3];
// b == [2, 3]

Assignment destructuring enables operations on objects, such as pulling values out of an object, using this short-hand syntax.

o = {p1: 'foo', p2: 'bar'};
var {p1, p2} = o;
// p1 == 'foo'
// p2 == 'bar'

Assignment Destructuring also allows for swapping of variables in a single function, but unlike others, it allows the same without the use of a temp variable.

var a = 1, b = 2;
[b, a] = [a, b];

// a == 2
// b == 1

Clear and smaller code is its own reward. Assignment Destructuring is a boon for programmers as it helps them to prevent writing extra code, thereby saving time and effort.

What You Should Know About Assignment Destructuring in ES6 was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.