chmac

const work = async () => "success";

work().then(
  (result) => {
    console.log(result);
  },
  (error) => {
    console.error(error);
  }
);

chmac

.vc_custom_1556058139992 .wpb_wrapper > div {
      margin-bottom: 10px !important;

}
.vc_custom_1556058110179 .wpb_wrapper > div {
    margin-bottom: 0px !important;
}

    /*Override styles - Retinafunk Mai 2018*/

chmac

Keybase proof

I hereby claim:

• I am chmac on github.
• I am chmac (https://keybase.io/chmac) on keybase.
• I have a public key ASBlXrckkl_qm4RO6yRmMJKdg3soGBOoL32P2C_jxvMS_wo

To claim this, I am signing this object:

chmac

#!/bin/sh

# The error was:
# No certificates found, you can install some with one of these commands:
#     cert-sync /etc/ssl/certs/ca-certificates.crt #for Debian based systems
#     cert-sync /etc/pki/tls/certs/ca-bundle.crt #for RedHat derivatives
# Read more: http://www.mono-project.com/docs/about-mono/releases/3.12.0/#cert-sync

# From here: http://www.mono-project.com/docs/about-mono/releases/4.8.0/#tls-12-support
# The fix was:

chmac

#!/bin/bash
echo "$(/bin/ps auxww)$(/usr/bin/top -bn1)" | /usr/bin/mail -s "HOST high load psauxww" EMAIL

chmac

#!/bin/bash

# Grab the pending updates like 4;2
updates=$(/usr/lib/update-notifier/apt-check 2>&1)

# If there are no pending updates, exit now
if [ $updates == "0;0" ]
then
        exit
fi

chmac

Goals

Show the user a version string which identifies the version of the client code they are running. We don't need to know what version the database or server is running, so any kind of collection or method approach would fail because it will automatically update all clients. We want something hard coded into the client code, yet generated dynamically at build (deploy) time.

Solution

We create a template called version which we include in a remote corner of the UI. As part of our deployment process we put the last git commit hash into that file.

Notes

chmac

---

# A simple playbook to add the ansible dependencies and the foo user.
# The site.yml playbook can then lock down permission (deny root login) and so
# on, so long as this playbook has been run. The site.yml playbook will only
# work once this has been run, so it should be safe.

# Half of this file is commented out because I never got round to fixing the
# issue that some machines need an initial user of root and some ubuntu.

chmac

{
  "swagger": "2.0",
  "info": {
    "version": "1.0.0",
    "title": "PetStore on Heroku"
  },
  "host": "petstore-api.herokuapp.com",
  "basePath": "/pet",
  "paths": {
    "/": {

chmac

# Server
Meteor.publish 'foo', (searchQuery) ->
  return Foo.find
    bar: searchQuery

# Client
Meteor.subscribe 'foo', Session.get 'searchQuery'

# {#each foo} in your template and then to update:
Session.set 'searchQuery', 'some new query'