Update Vaadin Flow navigation life cycle cheat sheet
Updated the navigation life cycle diagram from Vaadin Flow Cheat sheets and flow diagrams to represent (not so recent) changes in the framework.
If you are interrested in hiring a consultant for the effective use of open source software on an enterprise grade, take a look around in the About section to see, what I have to offer.
Various snippets or code parts I found useful, so I keep them here for reference.
Updated the navigation life cycle diagram from Vaadin Flow Cheat sheets and flow diagrams to represent (not so recent) changes in the framework.
WREPL no longer is
a standalone program, but since version 0.2 now is integrated into the
Clojure CLI. This makes it
easier to use on a regular Clojurist machine. See the
example-Folder
on how to migrate.
Back when WREPL started there were no official way to quickly spin up
a Clojure REPL any more. Spec was released, but was not part of the
core. So before that you could just run a Clojure REPL with the JAR
file in your ~/.m2/repository/org/clojure/ directory. But with the
additional dependencies into the Spec libraries, this was no longer so
easy.
So WREPL was again a single JAR to run your (standalone) REPL and also allowed configuration of all the "letters" of REPL and some additional stuff (e.g. loading dependencies, run some file on startup, ...). Nowadays, the Clojure CLI is installed on basically every Clojure developer machine and brings back the entry point to quickly spin up a REPL. It brings the facilities to run your own code and pull the dependencies for it.
Yet the part to configure a REPL to your liking is still a usable feature. Integrating "REPL-ish" tools with each other is not convenient. So WREPL remains useful still to e.g. use a different prompt to denote some other state than the current namespace or configure a pretty-printer to your liking in your rebel-readline REPL.
Publishing ports in Docker is done only once at the beginning on the
creation of the container. Yet sometimes there is the need to talk to
the service inside a container, but the container itself does not have
the proper tools to do what you want with it built-in. Yet re-creating
the container just to publish the ports, maybe manifesting it
temporarily in some docker-compose.yml, and then forgetting about it
to open up some security problem is not great.
So the following script allows to temporally proxy to a port of
a running container, whether for manually ran containers or the ones in
a network from Docker-Compose. It tries to find the network and
attaches to it, unless it's bridge, and uses a socat to run the
proxy. The arguments are the container name or ID, the port to proxy
to, and an optional port where to publish (if not given, Docker will
pick one).
#!/bin/sh set -eu if test ! "$#" -ge 2; then echo "$0 <container> <target_port> (<local_port>)" exit 1 fi container="$1" port="$2" network=$(docker inspect --format '{{range $k,$v:= .NetworkSettings.Networks}}{{println $k}}{{end}}' "$container" | head -n1) inner_port=8080 publish="$inner_port" if test "$#" -ge 3; then publish="$3:$publish" fi docker run \ --rm \ --publish="$publish" \ --link="$container:target" \ $(if test "$network" != "bridge"; then echo "--network=$network"; fi) \ alpine/socat \ "tcp-listen:$inner_port,fork,reuseaddr" \ "tcp-connect:target:$port"
Since Groovy 4 record types are supported like in Java. Out of the
box they already come with additional features, that may or may not be
useful for your current project. So the easy way to disable all of
those features is to just define the record in a .java file or under
a source tree, that only the Java compiler sees.
Yet nearly all differences to record .class generated with the Java
compiler can be configured. To generate the same result with the Groovy
compiler (or nearly the same: there are some annotations), use the
following annotations for the record (or make them more easily
available via a groovy.transform.AnnotationCollector).
@TupleConstructor( // disable map and default-value c'tor defaults = false, // do not generate c'tor versions, that default to null values namedVariant = false // do not generate a c'tor with faux named arguments (AKA map c'tor) ) @RecordOptions( // do not generate additional methods for access to the fields toList = false, // list of fields values toMap = false, // map from field name to value size = false, // amount of defined fields getAt = false // access attributes in definition order by index )