Async/await is the same as using promises. It’s just syntactical sugar to make it look synchronous. The javascript engine sees the “await” and stops execution there for you automatically until the promise is resolved/rejected.

I find the javascript promise with ‘.then()’ and ‘.catch()’ is much nicer if you have really simple things to do with the result and the error. But, as soon as you start getting into a bunch of conditionals, from your results, you tend to get a lot of nested promise call statements. So, to save you from promise hell, you just label your function as async, and use the await expression so that you don’t have to be too concerned with promise management. Then hopefully what you do with the final result is simple, and you then resort to using promises. See the testPromise() calls below for examples.

/**
 * @param fail if true, throw an error with a promise.  If false, resolve
 * a delayed response with a promise.
 * @returns {Promise<*>} Always a promise resolve or reject.
 */
function testPromise(fail) {
    if (fail) {
        return Promise.reject(new Error('failed'));
    }
    else {
        return new Promise(resolve => setTimeout(function () {
            resolve('success')
        }, 1000));
    }
}

/**
 * Test calls with promises, awaits, and async.
 *
 * @param fail if true, fail with error.  If false, succeed normally.
 * @returns {Promise<*>} always a promise, as async/await use promises as
 * does Promise.reject and Promise.resolve.
 */
async function testAsync(fail) {
    let result = await testPromise(fail);
    return result;
}

testAsync(true)
    .then(v => console.log('fail: ', v))
    .catch(e => console.log('fail: ', e.message));
testPromise(true)
    .then(v => console.log('fail w/promise: ', v))
    .catch(e => console.log('fail w/promise: ', e.message));

testAsync(false)
    .then(v => console.log('succeed: ', v))
    .catch(e => console.log('succeed: ', e.message));
testPromise(false)
    .then(v => console.log('succeed w/promise: ', v))
    .catch(e => console.log('succeed w/promise: ', e.message));

/**
 * This shows that within an async function you can try/catch instead of
 * then/catch, as long as you use "await".
 *
 * @returns {Promise}
 */
async function testWithTry() {
    try {
        let result = await testPromise(true);
        console.log('fail w/try: ', result);
    } catch (e) {
        console.log('fail w/try: ', e.message)
    }
    try {
        let result = await testPromise(true);
        console.log('fail w/try w/promise: ', result);
    } catch (e) {
        console.log('fail w/try w/promise: ', e.message)
    }

    try {
        let result = await testPromise(false);
        console.log('succeed w/try: ', result);
    } catch (e) {
        console.log('succeed w/try: ', e.message)
    }
    try {
        let result = await testPromise(false);
        console.log('succeed w/try w/promise: ', result);
    } catch (e) {
        console.log('succeed w/try w/promise: ', e.message)
    }
}

testWithTry();

1. Wander over to Docker Squid and start using their squid in a docker image.
2. Once the docker container is up and running, modify their /etc/squid3/squid.conf to change the cache_dir to allow 10G of storage and cache large objects such as 200M (default is only 512kb).  There is an existing line, so search with a regex for “^cache_dir”.  Then change the entire line to something like “cache_dir ufs /var/spool/squid3 10000 16 256 max-size=200000000“, which results in 10G of cache and 200M objects being cachable.
3. Change your Dockerfile to use a RUN line with exports for http_proxy, https_proxy, and ftp_proxy, to point to your host’s IP and port 3128.  Don’t use ENV, as that will permanently set those for the container once it’s created and running. My line looks like “RUN export http_proxy=http://192.168.2.5:3128; export https_proxy=http://192.168.2.5:3128; export ftp_proxy=http://192.168.2.5:3128; \“

Doing this took my docker builds from 6-7 minutes down to about 1.5 minutes.

So, we endeavour to have you up and running with their “Building a RESTful Web Service” tutorial in under 5 minutes, assuming you have a basic java development environment going, meeting their requirements. Please quickly review the first two “What you’ll build” and the “What you’ll need” sections at “Building a RESTful Web Service“, then come back here.

We have one additional requirement. It’s assumed you’re able to develop from a Linux command line. If you’re not using Linux as a development platform, you really should be.

git clone https://github.com/spring-guides/gs-rest-service.git

cd gs-rest-service/complete

mvn clean install

java -jar target/gs-rest-service-0.1.0.jar

# on a separate terminal
curl http://localhost:8080/greeting

The key components of this tutorial, which are quite self explanatory with a simple explanation, are…

• Application.java – starts the application with an embedded tomcat server
• GreetingController.java – binds the REST url and handles the request
• Greeting.java – serializable object for the framework to return JSON
• pom.xml
  • spring-boot-start-parent – a dependency management parent project
  • spring-boot-starter-web – includes things like the mvc framework and the rest framework
  • For a WAR working in an existing tomcat instance…
    • include spring-boot-starter-tomcat dependency
    • add a pom “packaging” element with a value of “war”
    • make your Application class extend SpringBootServletInitializer

Example for the spring tomcat starter dependency.

        
        
            org.springframework.boot
            spring-boot-starter-tomcat
            provided
        

du -mcs /home/user/* /home/user/.[!.]* | sort -n

I asked VMWare to provision my disk to be larger and then asked Linux to refresh the kernel info:

 $ echo 1 > /sys/class/scsi_device/0\:0\:3\:0/device/rescan 
 $ dmesg
 sdd: Write Protect is off 
 sdd: Mode Sense: 61 00 00 00 
 sdd: cache data unavailable 
 sdd: assuming drive cache: write through 
 sdd: detected capacity change from 171798691840 to 343597383680

I added another partition and then tried to get LVM to use it:

$ fdisk /dev/sdd
 Command (m for help): n
 Command action
 e extended
 p primary partition (1-4)
 p
 Partition number (1-4): 3

But LVM couldn’t see it:

 $ pvcreate /dev/sdd3
 Device /dev/sdd3 not found (or ignored by filtering).
 $ pvcreate -vvvv /dev/sdd3
 #device/dev-cache.c:578 /dev/sdd3: stat failed: No such file or directory
 #metadata/metadata.c:3546 
 #device/dev-cache.c:578 /dev/sdd3: stat failed: No such file or directory

The solution was to use partprobe to inform the OS of partition table changes:

 $ partprobe /dev/sdd
 $ pvcreate /dev/sdd3
 dev_is_mpath: failed to get device for 8:51
 Writing physical volume data to disk "/dev/sdd3"
 Physical volume "/dev/sdd3" successfully created

git config --global alias.graph \
'log --graph --pretty=oneline --abbrev-commit --simplify-by-decoration --decorate --all'
git graph

So, the cronjobs look like this…

0 8-19 * * 1 /home/trenta/backup/monday-rsync.sh
0 8-19 * * 2-5 /home/trenta/backup/daily-rsync.sh

monday-rsync.sh…

#!/bin/bash
# /home/trenta/backup/monday-rsync.sh
/usr/bin/rsync -avH --exclude-from=/home/trenta/backup/daily-excludes.txt /home/trenta/ /media/backup/trenta-home/

daily-rsync.sh…

#!/bin/bash
# /home/trenta/backup/daily-rsync.sh
/usr/bin/rsync -avH --exclude-from=/home/trenta/backup/daily-excludes.txt --link-dest=/media/backup/trenta-home/ /home/trenta/ /media/backup/trenta-home-$(/bin/date +'%w')/

My reply essentially focused around the concept that some developer, or group of developers, decided that they would write a Web Service framework and do some programming for the sake of programming, instead of actually solving a problem.  I’ve always been curious as to why anyone would actually want to do that, but hey, some people like work more than I do apparently.  I enjoying designing software masterpieces, not working.  In other words, I don’t like work, I like to create art.

You know, people love creating solutions before there’s a problem.  Well, more specifically in this case, the problem of needing a way to deliver Web Services was already solved with a protocol that was created in the early 1990s called HTTP.  SOAP was just a useless wrapper for generic requests/responses, when HTTP was essentially already a superior wrapper protocol for the same.  I then proceeded to talk about how when REST came out I kind of chuckled, because I was thinking “Gee, you mean the standard web protocol HTTP is really more than enough? Who would have thunk?”

Apparently he liked that reply, lol.

We need to find the salt (the last four bytes of the hash), and then concatenate PASSWORD+SALT, take the SHA hash, convert to base64, prepend {SSHA}, and then finally base64 encode that whole string again.

Here is what ldapsearch says is the password hash:

userPassword:: e1NTSEF9OWZ1MHZick15Tmt6MnE3UGh6eW94SDMrNmhWb3llajU=

The first step is to retrieve the (binary) salt which is stored at the end of a double base64 encoded hash.  I wrote a perl SSHA Salt Extractor for that:

$ cat getSalt.pl
#!/usr/bin/perl -w

my $hash=$ARGV[0];
# The hash is encoded as base64 twice:
use MIME::Base64;
$hash = decode_base64($hash);
$hash=~s/{SSHA}//;
$hash = decode_base64($hash);

# The salt length is four (the last four bytes).
$salt = substr($hash, -4);

# Split the salt into an array.
my @bytes = split(//,$salt);

# Convert each byte from binary to a human readable hexadecimal number.
foreach my $byte (@bytes) {
$byte = uc(unpack "H*", $byte);
print "$byte";
}
$ ./getSalt.pl e1NTSEF9OWZ1MHZick15Tmt6MnE3UGh6eW94SDMrNmhWb3llajU=
68C9E8F9

See, that is four ASCII characters represented by human readable hexadecimal. Another way to do this is like this:

echo "e1NTSEF9OWZ1MHZick15Tmt6MnE3UGh6eW94SDMrNmhWb3llajU=" | base64 -d | sed 's/^{SSHA}//' | base64 -d | tail -c4 | od -tx1

Now that we have extracted the salt, we can regenerate the salted hash with what we think the password should be.

$ cat openldap-sha.pl
#!/usr/bin/perl

use Digest::SHA1;
use MIME::Base64;

my $p=$ARGV[0];
my $s=$ARGV[1];

# Convert from hex to binary.
$s_bin=pack 'H*', $s;

# Hash the password with the salt.
$digest = Digest::SHA1->new;
$digest->add("$p");
$digest->add("$s_bin");

# Encode PASSWORD+SALT as Base64.
$hashedPasswd = '{SSHA}' . encode_base64($digest->digest . "$s_bin" ,'');

# Encode as Base64 again:
print 'userPassword:: ' . encode_base64($hashedPasswd) . "\n";

$ ./openldap-sha.pl correcthorsebatterystaple 68C9E8F9
userPassword:: e1NTSEF9OWZ1MHZick15Tmt6MnE3UGh6eW94SDMrNmhWb3llajU=

And there you have it.

git fsck --lost-found | cut -f 3 -d ' ' | \
  while read -r commit; do 
    git show $commit | grep responsive; 
    if [ $? -eq 0 ]; then 
      echo $commit; 
    fi; 
  done

The response was…

rm -rf web/src/main/webapp/responsive/.sass-cache/
53fcd5f117f8e19243dfcde24c14524dc99b4c1e

I then just showed the commit blob with…

git show 53fcd5f117f8e19243dfcde24c14524dc99b4c1e
#!/bin/bash

cp -r /media/mount/* web/src/main/webapp/
rm -rf web/src/main/webapp/lost+found/
rm -rf web/src/main/webapp/responsive/.sass-cache/
find web/ -name '._*' | while read -r filename; do 
 rm -f "$filename"
done
rm -rf web/src/main/webapp/META-INF/
git status