asvanberg

lazy val concatCoffeeScript = taskKey[Seq[File]]("Concatenate .coffee")
lazy val concatCoffeeScriptFiles = settingKey[Seq[(String, Seq[String])]]("Files to concatenate, in order")

concatCoffeeScriptFiles := Seq(
  "javascripts/app.coffee" → Seq("javascripts/product.coffee", "javascripts/person.coffee", "javascripts/main.coffee")
)

concatCoffeeScript <<= (sourceDirectory in Assets, concatCoffeeScriptFiles, WebKeys.webTarget) map { (d, fs, t) ⇒
  fs map { case (concatenated, parts) ⇒
      val cf = t / concatenated

asvanberg

-- original
SELECT DISTINCT
    `zipkin_spans`.`trace_id_high`,
    `zipkin_spans`.`trace_id`,
    MAX(`zipkin_spans`.`start_ts`)
FROM
    `zipkin_spans`
        JOIN
    `zipkin_annotations` ON (`zipkin_spans`.`trace_id_high` = `zipkin_annotations`.`trace_id_high`
        AND `zipkin_spans`.`trace_id` = `zipkin_annotations`.`trace_id`

asvanberg

Zipkin query optimization

Test setup

• MariaDB (10.1.23-MariaDB-9+deb9u1)
• Virtual server (2.5Ghz single core, 3GB RAM)
• 701,241 spans
• 3,508,959 annotations

Queries

asvanberg

package io.github.asvanberg.http.webpush;

import javax.crypto.Cipher;
import javax.crypto.KeyAgreement;
import javax.crypto.Mac;
import javax.crypto.spec.GCMParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import java.nio.ByteBuffer;
import java.security.GeneralSecurityException;
import java.security.KeyPair;

asvanberg

return (function () {

  // Price must be this percentage of resting value to buy during slow climb
  const slowClimbBuyThreshhold = 0.50;
  // Sell when stable this close to market ceiling
  const stableSellThreshhold = 0.96;
  // Price must be this percentage of resting value to buy during fast climb
  const fastClimbBuyThreshhold = 100.0;

  const numberFormat = new Intl.NumberFormat([], { 'style': 'currency', 'currency': 'USD' });

asvanberg

/*
 This showcases how to use a Testcontainers provided database to test a Spring
 Boot application while isolating every test so that changes to the database
 does not interfere with other tests.

 It accomplishes this without any reliance on implementation details to empty
 out specific tables or anything else. There is no global "rollback only"
 transaction semantics. You can run assertions against the actual data in the
 database if desired, including any schema changes.