| #program to record realtime midi input,and then replay it. | |
| #records midi input from say a keyboard, saving data into array tlist | |
| #this can then be replayed. Records, note pitch, time started, | |
| #velocity of key and note duration. | |
| #coded by Robin Newman April 2020 | |
| uncomment do #comment to record, uncomment to replay | |
| tlist=get(:tlist) | |
| puts tlist.length | |
| puts tlist |
| INFO global: Vagrant version: 2.2.5 | |
| INFO global: Ruby version: 2.4.6 | |
| INFO global: RubyGems version: 2.6.14.4 | |
| INFO global: VAGRANT_DEFAULT_PROVIDER="virtualbox" | |
| INFO global: VAGRANT_INSTALLER_VERSION="2" | |
| INFO global: VAGRANT_EXECUTABLE="/opt/vagrant/embedded/gems/2.2.5/gems/vagrant-2.2.5/bin/vagrant" | |
| INFO global: VAGRANT_INSTALLER_EMBEDDED_DIR="/opt/vagrant/embedded" | |
| INFO global: VAGRANT_INSTALLER_ENV="1" | |
| INFO global: VAGRANT_LOG="debug" | |
| WARN global: resolv replacement has not been enabled! |
I've sniffed most of the Tinder API to see how it works. You can use this to create bots (etc) very trivially. Some example python bot code is here -> https://gist.github.com/rtt/5a2e0cfa638c938cca59 (horribly quick and dirty, you've been warned!)
Note: this was written in April/May 2014 and the API may have changed since. I have nothing to do with Tinder, nor their API, and I do not offer any support for anything you may build on top of this
| #!/bin/bash | |
| CLUSTERNAME=mycluster.mydomain | |
| NAMESPACE=default | |
| USERNAME=myclusteruser | |
| GROUPNAME=mygroup | |
| openssl genrsa -out ${USERNAME}.key 2048 | |
| CSR_FILE=$USERNAME.csr |
| #!/bin/bash | |
| # script to find and set the right mtu | |
| # | |
| # Usage | |
| # fix-mtu [INTERFACE] | |
| # | |
| # When not INTERFACE given, wlan0 is used as default. | |
| # check if an interface was given |
We've been dicussing the Aldryn CMS installer and what it needs to make it a very good tool that serve's it's puprose very well.
First i gonna define what I, as a user, believe what an installer must do.
I believe in 80% and more it's the new and/or caual user wanting to testdrive, or setting up the system once a year for development. Experts, longterm and production use will and should always be handled with automated deployments(ansible, chef, puppet), selfmade distribution packages(rpm, deb,..) and such!
That means the installer must be able, to get a ready to use CMS system, for simple use cases, installed as simple and fast as possible, allowing the user to add more specific settings, further features and adjustments and extensions of functionally later as needed.
Here we realize: Its not only the installer, but a combination of documentation, configurability, extensibility, adjustability of the system itself, and the installer has to prepare a system that works well and easy as fast as possible, w
| moved: https://github.com/ceumicrodata/mETL/wiki/Questions-and-Answers |
| #!/bin/bash | |
| set -e | |
| set -u | |
| DEBUG_NOOP="" | |
| # simple snapshot script for raodwarrior systems to make a snapshot of (nearly) the whole | |
| # filesystem, plus some extras like package lists |
| test |