| stage "preparation" | |
| node { | |
| parallel ( | |
| phase1: { sh "echo p1; echo phase1" }, | |
| phase2: { sh "echo p2; echo phase2" } | |
| ) | |
| sh "echo 42 > data" | |
| stash includes: '*', name: 'binary' | |
There are 3 plugins for generating to create a JAR-File in maven:
maven-jar-plugin:This plugin provides the capability to build and sign jars.But it just compiles the java files under src/main/java and /src/main/resources/.It doesn't include the dependencies JAR files.
<!--exclude all xml files from the jar-->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
Rich Hickey • 3 years ago
Sorry, I have to disagree with the entire premise here.
A wide variety of experiences might lead to well-roundedness, but not to greatness, nor even goodness. By constantly switching from one thing to another you are always reaching above your comfort zone, yes, but doing so by resetting your skill and knowledge level to zero.
Mastery comes from a combination of at least several of the following:
| ################################################ | |
| # Dockerfile to run Groovy containers | |
| # Based on Java 8 image | |
| ################################################ | |
| FROM java:8u40-jdk | |
| MAINTAINER Cédric Champeau | |
| # Install GVM |
This bash script offers quick shortcuts to simulate slower network connections. It is useful when you need to simulate a wireless network on a Linux network server, especially when you are using a virtual machine guest on your local machine or in the cloud.
slow 3G # Slow network on default eth0 down to 3G wireless speeds
slow 3G -l 600ms -p 10% # slow network on eth0 and setup latency to 600ms packetloss to 10%
slow reset # Reset connection for default eth0 to normal
slow vsat --latency=500ms # Simulate satellite internet with a high latency
slow dsl -b 1mbps # Simulate DSL with a slower speed than the default
Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.
For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.
But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.
SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
Both command sourcing (CS) and event sourcing (ES) rely on determinism for correctness.
The correctness condition for ES is the determinism (purity) of the function State -> Event -> State. Given that this function is deterministic, aka it always maps the same inputs to the same ouputs, we can rely on it to reconstitute state at any point in time. Determinism is typically achieved by ensuring that the Event has all required information to make the state transition, ie no side effects. The Event then is a sort of "closure" of all pertinent information about the event.
The correctness condition for CS is the determinism of the function State -> Command -> Event. Herein lies one of the distinctions between command sourcing and event sourcing - a program can control its output, but it not its input. Since one can't control the input, aka command, one can't in general, enrich it with all required information to make the above function deterministic. A consequence of this is that you can't simply replay a
| App configuration in environment variables: for and against | |
| For (some of these as per the 12 factor principles) | |
| 1) they are are easy to change between deploys without changing any code | |
| 2) unlike config files, there is little chance of them being checked | |
| into the code repo accidentally | |
| 3) unlike custom config files, or other config mechanisms such as Java |
| #!/bin/bash | |
| # This gist contains pre-commit hooks to prevent you from commiting bad code or to the wrong branch. | |
| # There are six variants that I have built: | |
| # - pre-commit: stops commits to master/main/develop branches. | |
| # - pre-commit-2: also includes a core.whitespace check. | |
| # - pre-commit-3: the core.whitespace check and an EOF-newline-check. | |
| # - pre-commit-4: only the core.whitespace check. | |
| # - pre-commit-5: elixir formatting check. | |
| # - pre-commit-6: prettier formatting check. | |
| # Set the desired version like this before proceeding: |
