MLOps Template is a repo created by Microsoft field personnel (CSA, GBB, MTC) that provides several tools and templates to facilitate modern MLOps practices.
In addition to a template for an Active Learning implementation, there are also two sets of materials to facilitate an introductory workshop on modern MLOps practices, one, developed by the West Region CSU, using Azure Machine Learning and GitHub Actions, and another featuring Azure Databricks for ML asset development and Azure DevOps for CI/CD pipelines.
This project welcomes contributions and suggestions. Most contributions require you to agree to a
Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us
the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.
When you submit a pull request, a CLA bot will automatically determine whether you need to provide
a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions
provided by the bot. You will only need to do this once across all repos using our CLA.
This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft
trademarks or logos is subject to and must follow Microsoft’s Trademark & Brand Guidelines.
Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.
Any use of third-party trademarks or logos are subject to those third-party’s policies.
A Clojure(Script) library for keeping your secrets under control.
Motivation
I want to be calm about sensitive data.
This is security and responsibility to my clients.
Specifying categories of sensitive data at the model level gives an understanding of what data we are working with.
Easy to mark up categories of sensitive data at model level and use them when reading configuration files, environment variables and also in the middlewares of the public API.
Installation
Add the following dependency in your project:
;; project.clj or build.boot
[team.sultanov/secret-keeper "1.0.86"]
;; deps.edn
team.sultanov/secret-keeper {:mvn/version"1.0.86"}
██ ██ ██ ██
░██ ░██░██ ░██ Variable VVV 1.12
░░██ ░██ ░░██ ░██
░░████ ░░████ The easiest way to set up
░░██ ░░██ WordPress sites with VVV!
░░ ░░
vv makes it extremely easy to create a new WordPress site using Varying Vagrant Vagrants. vv supports site creation with many different options; site blueprints to set up all your plugins, themes, and more; deployments; and lots more features.
Tired of the time it takes to do a vagrant provision or create new sites? Check out flip, a simple utility to solve that issue.
If you have Homebrew installed, you run the following in your terminal application:
$ brew install bradp/vv/vv
Otherwise, clone this repositoy and edit your $PATH to include the vv core file:
Clone this repo: git clone https://github.com/bradp/vv.git
Add the vv core script to your shell’s $PATH:
If you’re using bash: touch ~/.bash_profile && echo "export PATH=\$PATH:`pwd`/vv" >> ~/.bash_profile
Windows Installation
Clone vv to a folder somewhere.
$ git clone https://github.com/bradp/vv.git
Add that folder to your system path. See here if you need help.
Open an explorer window and go to My Computer (or This PC).
Right click and choose properties
Choose Advanced System Settings
Choose Environmental Variables form the Advanced Tab
Choose the “Path” variable and edit it.
Add a semicolon to end the previous path item and then add the vv folder path (Example: ;C:\Users\Name\Documents\vv)
Open Git Bash and run vv
Alternately, you can use cmd.exe with bash vv.
Props to Vinsanity for these instructions. If you’re having issues, please see this issue.
Linux Installation
Clone vv into a folder.
$ git clone https://github.com/bradp/vv.git
Access the directory that you cloned vv into.
Copy the vv executable to /usr/local/bin
$ sudo cp vv /usr/local/bin
You should now be able to easily run vv from anywhere in your system.
Adding tab-completion to vv
Currently, vv supports tab-completion of arguments and options in both bash and ZSH. To enable this, you’ll first want to make sure you’re on the most current version of vv. Then simply add source $( echo $(which vv)-completions) to the end of your .bash_profile, .bashrc or .zshrc.
Updating
vv is currently under development, and you’ll probably want the latest and greatest version at all times.
You can run vv --update to update to the latest version. This will update via Homebrew if you’ve installed it that way, otherwise vv will bootstrap an update on where ever you’ve installed it.
vv will automatically check for updates and update itself once a week. You can disable this by adding "auto_update_disable": false to the JSON config in ~/.vv-config.
If you have trouble updating, you may want to try some of the options below:
Homebrew sometimes caches a version of Variable VV causing you to receive a message saying you are out of date with the Github version, however running vv --update simply downloads a version you already have installed. In cases like this, there are two safe options you can try.
First, and simplest, run vv --force-update. Second, if that does not work you can safely uninstall Variable VV and re-install it via homebrew, you can do this with these commands: brew remove vv then brew untap bradp/vv and finally, run the install command brew install bradp/vv/vvas mentioned above. You will not lose any settings or sites.
Usage
Once installed, you can run vv anywhere you’d like. If vv can’t automatically find your VVV installation, you will be prompted for the path. It will also save this into a configuration file in ~/.vv-config, so you won’t be prompted again.
At any time, you can run vv or vv --help to see a list of all possible options and flags.
vv will prompt you for a value for any required flags that were not specified.
The main commands are list, create, delete. These will list your sites, create a site, and delete a site. These each have a few aliases, so for example, if you run vv show, vv will know you meant vv list.
To start creating a site, simply do vv create ( you can also do vv --create, or simply vv -c). You will then be prompted for all required options.
Creates a web root for the site in the www folder containing three files: vvv-init.sh, wp-cli.yml, and vvv-hosts
vvv-init.sh tells Vagrant to create a database if one does not exist and install the latest version of WordPress (via WP-CLI) the next time Vagrant is provisioned
wp-cli.yml tells WP-CLI that WordPress is in the htdocs folder
vvv-hosts contains the hosts entry to give your site a nice custom domain (the domain is set in the wizard)
Creates a file in the nginx-config folder to handle server settings for your site
Restarts Vagrant with vagrant up --provision
Provisioning Vagrant takes a couple of minutes, but this is a crucial step as it downloads WordPress into your site’s htdocs directory and runs the installation. If you want to skip provisioning and install WordPress manually, you can run the new site’s vvv-init.sh file directly in the Vagrant shell.
Subdomain Multisite Installation
If you are using a subdomain multisite, you must edit vvv-hosts file inside of that site’s folder with each subdomain on a new line. For example:
mysite.dev
siteA.mysite.dev
siteB.mysite.dev
After this, run vagrant reload --provision and your subdomains should resolve. Please note, any sites set up prior to version 1.7.3 will need more configuration for this, either delete and re-set up the site or ping me on Twitter for help.
Site Deletion
vv delete site_name
You can also leave off site_name to be prompted for it.
Deleting a site does the following:
Halts Vagrant (if running)
Deletes the site’s web root (which deletes the vvv-init.sh, wp-cli.yml, and vvv-hosts files as well)
Deletes the file in the nginx-config folder pertaining to the site
vv supports setting up deployments that work with Vagrant Push. You’ll need to be on version 1.7.0 or later of Vagrant. Simply run vv --deployment-create and walk through the wizard.
To deploy a site, you can do vv vagrant push <sitename>-<deployment_name>.
When removing a deployment, your current Vagrantfile will be backed up as Vagrantfile-backup.
Advanced Usage
Airplane Mode
Using x as the first argument with vv will force airplane mode. This will cut off update checks on usage. This is useful if you’re using vv without an internet connection. The provision state of VVV will probably fail at some point, though.
Flags
Anything that vv prompts you for, you can pass in as an argument. Most of this is realized in the site creation. In fact, there are a few arguments you can pass in that aren’t prompted. This gives you total control over creating a new site.
To create a new site named ‘mysite’ that has the domain ‘mysite.dev’ and is a multisite with subdomains, with WP_Debug turned on would be:
To use a custom database prefix, simply use the vv create --prefix myprefix when creating a new site.
Blueprints
Blueprints allow you to set up different plugins, themes, mu-plugins, options, widgets, menus, or constants that will be installed to a new site you create. First, run vv --blueprint-init to have vv create a vv-blueprints.json file in your VVV directory. You can edit this file to create and set up different blueprints.
The options for plugins, themes, widgets, and menus correspond to the equivalent WP CLI option.
For options, demo content, and constants, please note the :: as a separator between the key and value.
Custom demo content can be imported through the blueprint. Be sure to use a link that points to just the xml code, like this. You can add as many demo content files as you’d like, just separate each line with a comma as usual.
A multisite’s Network Settings can be configured using a network_options array in the blueprint.
You can create as many named blueprints in this file as you would like, all with as many different settings as you’d like.
When creating a site, the name you’ve specified (in this example, “sample”) is what you’ll need to specify to use this blueprint.
You can use ‘SITENAME’ or ‘SITEDOMAIN’ anywhere in the blueprint, and that will be replaced with the actual site name or local domain when installing.
Blueprints for Multisite configurations
Blueprints also let you set up individual subsites in a Multisite network. For example, you can define a blueprint for a multisite network in which certain plugins or themes are activated across the whole network, or just for specific subsites.
To add multisite support to your blueprint, add a sites key to a specific blueprint, like this:
The sites object holds a subsite definition, which has the same capabilities as a regular site’s blueprint (so plugins, themes, etc. are all the same), and also includes keys for WP-CLI’s wp site create command. For example, to create a subsite whose slug is subsite2, titled “Second Subsite” with an admin email address of subsite2admin@localhost.dev with robots.txt exclusions, use:
If your multisite network uses subdomains, you can include a blueprint-level key named like BLUEPRINT_NAME::subdomains to have vv configure your subdomains for you. BLUEPRINT_NAME should match the name of your blueprint, and the value should be a space-separated list of subdomains that match your subsite slugs. A complete example for the sample blueprint shown above using subdomain-based multisite configurations might look like this:
The above installs BuddyPress but activates it only for site2, enables the _s theme for the entire network but activates anp-network-main-v2 for the network’s main site and anp-network-main-child for site3, which is also given its own site admin user.
Be sure to run vv with the --multisite subdomain option when you use a blueprint like this.
Blueprints for Multi-Network configurations
In addition to a multisite configuration, VV recognizes blueprints that will configure a WP Multi-Network (a network of WP Multisite networks). VV’s Multi-Network blueprints work just like Multisite blueprints, but have the following required additions:
A BLUEPRINT_NAME::subnetwork_domains key must be present listing the root domains for each network.
A networks object must be present, whose keys match the domains listed in the BLUEPRINT_NAME::subnetwork_domains member.
For example, this Multi-Network configuration defines two WP Multisite subnetworks (for a total of three WP Multisites) in the blueprint called multinet.
Note that empty network objects are allowed (i.e., path and site_name are optional), but not recommended.
To associate a given subsite with a network, you can either use the network_id key or a network_domain key in the subsite object. A network_domain is recommended. For example, this object will associate the site2 subsite with the main network (because no network_domain or network_id key is defined), and the subsite with slug site3 with the network created at the given domain:
The above will ultimately place site3 at the site3.wpsubnet1.dev URL while site2 will be created as a subdomain of whatever domain you chose when you invoked vv create.
It is not an error for a WP network to be defined with no sites of its own.
Vagrant Proxy
Because vv knows where you VVV installation is, you can run it from anywhere. vv will proxy any commands passed into vv vagrant <command> to your VVV location. So vv vagrant halt will halt your VVV vagrant, no matter where you run it.
vv Options
Option
Description
--help, -h
Show help and usage
--version
Show current vv version number.
--about
Show about screen.
--update
Updates vv to the latest stable version
--debug-vv
Outputs all debugging info needed for bug reporting.
--path, -p
Path to VVV installation
--force-path, -fp
Override vv auto-VVV locating
--force-sites-folder,-fsf
Override sites folder directory locating
--defaults
Accept all default options and skip the wizard. You can also run `yes
Commands
Command
Description
list, --list, -l
List all VVV sites
create, --create, -c
Create a new site
delete, --delete, -r
Delete a site
deployment-create, --deployment-create
Set up deployment for a site
deployment-remove, --deployment-remove
Remove deployment for a site
deployment-config, --deployment-config
Manually edit deployment configuration
blueprint-init, --blueprint-init
Initalize blueprint file
vagrant, v, --vagrant, -v
Pass vagrant command through to VVV.
Options for Site Creation
Option
Description
--name, -n
Desired name for the site directory (e.g. mysite)
--domain, -d
Domain of new site
--webroot, -wr
Subdirectory used for web server root
--bedrock, -bed
Creates Roots.io Bedrock install
--blueprint, -b
Name of blueprint to use
--live-url, -u
Live URL of site
--files, -f
Do not provision Vagrant, just create the site directory and files
--images, -i
Load images by proxy from the live site
--wp-version, -wv
Version of WordPress to install
--debug, -x
Turn on WP_DEBUG and WP_DEBUG_LOG
--multisite, -m
Install as a multisite. Can also pass in “subdomain” or “subdirectory”
--sample-content,-sc
Adds sample content to site.
--username
Admin username
--password
Admin password
--email
Admin email
--prefix
Database prefix to use
--git-repo,-gr
Git repo to clone as wp-content
--path, -p
Path to VVV installation
--force-path, -fp
Override vv auto-VVV locating
--blank
Creates blank VVV site, with no WordPress
--blank-with-db
Creates a blank VVV site, with a database
--wpskeleton, -skel
Creates a new site with the structure of WP Skeleton
--database,-db
Imports a local database export
--remove-defaults,-rd
Removes default themes and plugins
--language,--locale
Install WP in another locale. Need to pass the locale afterwards, like so: vv create --locale fr_FR
Options for Site Removal
Option
Description
--name, -n
Desired name for the site directory (e.g. mysite)
--path, -p
Path to VVV installation
--force_path, -fp
Override vv auto-VVV locating
Options for Deployment Setup
Option
Description
--name, -n
Desired name for the site directory (e.g. mysite)
--deployment-name
Name of deployment (production, staging, other, etc)
--host
Host (if SFTP, define port as host:port)
--username
FTP Username
--password
FTP Password
--passive
Use Passive transfer mode? (y/n)
--secure
Use SFTP? (y/n)
--destination
Destination path ( You probably want / or ~/public_html )
--confirm-removal
Used when removing a deployment to skip the confirmation prompt
.vv-config
The first time you run vv, it will attempt to locate your VVV installation location. If it can’t find it, you will be prompted for it. This will be written to a .vv-config file in your home directory. (~/.vv-config) You can also edit this file if you need to change your VVV path.
Also, if vv detects a .vv-config file in your current directory, this local file will override the one in your home directory. A use case would be to have several different VVV installations, that each contain their own local .vv-config file. Provided that you enter the appropriate directory before sending commands to vv, this effectively allows you to manage several different installations through one user account.
You can also add "auto_update_disable": false to this file to disable auto-update functionality.
vv Hooks
vv has support for extensibility within the ‘hooks’ system present. This allows for quite a lot of extensibility and injection into the vv process. This system allows you to add your own code to run within almost any point with vv.
To get started with hooks, run any vv command with --show-hooks at the end. For example, vv list --show-hooks will run vv list as normal, but will also show all the hooks available.
To create the folder that your hook code should live in, simply make a ‘vv’ folder inside of your VVV folder.
To add code to run for a hook, make a file within your vv folder inside of VV named the hook that you want to add to. This file can be any command line runnable language, and will be executed inline.
For example, saving this file as the name of any hook will output ‘Hello’ when that hook gets called.
#! /usr/bin/phpecho'Hello'
Another example would be running npm install inside of wp-content for all new sites.
Make a file named post_site_creation_finished. This file gets 4 variables passed in: the hook name, the name of the site folder, the site domain, and the VVV path.
This repository contains a collection of C++ lab exercises related to intermediate programming. Each lab exercise focuses on a specific programming problem and includes a PDF file with the problem description and one or more C++ source code files to implement the solution.
Files
Lab Exercise 3.pdf
Description: Instructions for solving the Fibonacci Reciprocals problem.
fibonacci-reciprocals.cpp
Description: C++ source code for calculating the reciprocals of Fibonacci numbers.
Lab Exercise 4 (1).pdf
Description: Instructions for solving Goldbach’s Conjecture in Array problem.
Goldbach's-Conjecture-in-Array.cpp
Description: C++ source code for verifying Goldbach’s Conjecture in an array.
Lab Exercise 5.pdf
Description: Instructions for calculating the standard deviation of records.
standard-deviation-on-record-v1.cpp
Description: C++ source code (version 1) to calculate the standard deviation.
standard-deviation-on-record-v2.cpp
Description: C++ source code (version 2) to calculate the standard deviation.
standard-deviation-on-record-v3.cpp
Description: C++ source code (version 3) to calculate the standard deviation.
Lab Exercise 6.pdf
Description: Instructions for solving the Cylinder Tank Problem.
cylinder-tank-problem/CylinderTank.h
Description: C++ header file defining the CylinderTank class.
cylinder-tank-problem/cylinderTankImp.cpp
Description: C++ source code implementing the CylinderTank class.
cylinder-tank-problem/main.cpp
Description: Main C++ source code for the Cylinder Tank Problem solution.
Lab Exercise 7.pdf
Description: Instructions for implementing a Bank Account system.
bank-account/BankAccount.h
Description: C++ header file defining the BankAccount class.
bank-account/BankAccountImp.cpp
Description: C++ source code implementing the BankAccount class.
bank-account/CheckingAccount.h
Description: C++ header file defining the CheckingAccount class.
bank-account/CheckingAccountImp.cpp
Description: C++ source code implementing the CheckingAccount class.
bank-account/SavingsAccount.h
Description: C++ header file defining the SavingsAccount class.
bank-account/SavingsAccountImp.cpp
Description: C++ source code implementing the SavingsAccount class.
Lab Exercise 8.pdf
Description: Instructions for simulating rolling dice.
rolling-dice-simulation/Dice.h
Description: C++ header file defining the Dice class.
rolling-dice-simulation/RiggedDice.h
Description: C++ header file defining the RiggedDice class.
rolling-dice-simulation/TwoDice.h
Description: C++ header file defining the TwoDice class.
rolling-dice-simulation/diceImp.cpp
Description: C++ source code implementing the Dice class.
rolling-dice-simulation/riggedDiceImp.cpp
Description: C++ source code implementing the RiggedDice class.
rolling-dice-simulation/twoDiceImp.cpp
Description: C++ source code implementing the TwoDice class.
main.cpp
Description: Main C++ source code for testing and running various lab exercises.
How to Use
To use any of the lab exercises, follow these steps:
Clone the repository to your local machine.
Choose the lab exercise you want to work on and open the corresponding directory.
Review the Lab Exercise [Number].pdf file for instructions and problem details.
Implement your solution in the provided C++ source code file (if applicable).
Compile and run the code using your preferred C++ compiler.
How to Contribute
Contributions to this repository are welcome. If you wish to contribute to the lab exercises or make improvements, follow these steps:
Fork this repository to your GitHub account.
Create a new branch for your changes.
Make your modifications and commit them with descriptive commit messages.
Push the changes to your forked repository.
Create a pull request to this repository’s main branch with a detailed explanation of your changes.
Credits
This repository’s lab exercises were created by Sir Michael Anthony Jay Regis as part of the C++ Intermediate Programming course. Credits to him for providing these problems and exercises.
A program to set instructions and get information from an SEN6x. It has been
tested to run I2C communication on UNOR4 Wifi
A detailed description of the findings are in SEN6x.odt
Getting Started
As part of a larger project I am looking at analyzing and understanding the air quality.
I have done a number of projects on air-sensors. This is a version of a working driver + examples.
More work continues to happen to create examples and compare against other sensors.
Prerequisites
Examples 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 have a dependency on other libraries and hardware. Documented in sketch.
Software installation
Obtain the zip and install like any other.
Program usage
Install like any other external library
Program options
See the description in the top of the sketch and read the documentation (odt)
Versioning
Version DRAFT / December 2024
initial draft version
ver draft 1.1 : updates and added example
ver draft 1.2 : updates and added examples
ver draft 1.3 : add opcode structure, added examples
ver draft 1.5 : added examples and update source code routines
ver draft 1.6 : added and updated examples. Updates to SRC-code routines
Version DRAFT / January 2025
ver draft 1.7 : added and updated CO2 examples. Updates to SRC-code routines
ver draft 1.8 : updated examples with CO2 ASc, added example7, Updates to SRC-code routines
ver draft 1.9 : updated example7 with information about RAW values
Version 1.0 / February 2025
Version 1 : added /updated examples and documentation
This project has been abandoned. There will be no further releases. If you wish to revive leveldown-mobile, please open an issue in Level/community to discuss a way forward. Thank you! ❤️
Leveldown for Android, iOS. Also works on Destkop with SpiderMonkey / v8 engine
To use with a mobile node application (i.e. JXcore)
npm install leveldown-mobile
To compile for SpiderMonkey desktop or OpenWrt embedded
jx install leveldown-mobile
A Low-level Node.js LevelDB binding
LevelDOWN was extracted from LevelUP and now serves as a stand-alone binding for LevelDB.
Remarks
This version of Leveldown only works with JXcore and platform independent.
It is strongly recommended that you use LevelUP in preference to LevelDOWN unless you have measurable performance reasons to do so. LevelUP is optimised for usability and safety. Although we are working to improve the safety of the LevelDOWN interface it is still easy to crash your Node process if you don’t do things in just the right way.
See the section on safety below for details of known unsafe operations with LevelDOWN.
leveldown() returns a new LevelDOWN instance. location is a String pointing to the LevelDB location to be opened.
leveldown#open([options, ]callback)
open() is an instance method on an existing database object.
The callback function will be called with no arguments when the database has been successfully opened, or with a single error argument if the open operation failed for any reason.
options
The optional options argument may contain:
'createIfMissing'(boolean, default: true): If true, will initialise an empty database at the specified location if one doesn’t already exist. If false and a database doesn’t exist you will receive an error in your open() callback and your database won’t open.
'errorIfExists'(boolean, default: false): If true, you will receive an error in your open() callback if the database exists at the specified location.
'compression'(boolean, default: true): If true, all compressible data will be run through the Snappy compression algorithm before being stored. Snappy is very fast and shouldn’t gain much speed by disabling so leave this on unless you have good reason to turn it off.
'cacheSize'(number, default: 8 * 1024 * 1024 = 8MB): The size (in bytes) of the in-memory LRU cache with frequently used uncompressed block contents.
Advanced options
The following options are for advanced performance tuning. Modify them only if you can prove actual benefit for your particular application.
'writeBufferSize'(number, default: 4 * 1024 * 1024 = 4MB): The maximum size (in bytes) of the log (in memory and stored in the .log file on disk). Beyond this size, LevelDB will convert the log data to the first level of sorted table files. From the LevelDB documentation:
Larger values increase performance, especially during bulk loads. Up to two write buffers may be held in memory at the same time, so you may wish to adjust this parameter to control memory usage. Also, a larger write buffer will result in a longer recovery time the next time the database is opened.
'blockSize'(number, default 4096 = 4K): The approximate size of the blocks that make up the table files. The size related to uncompressed data (hence “approximate”). Blocks are indexed in the table file and entry-lookups involve reading an entire block and parsing to discover the required entry.
'maxOpenFiles'(number, default: 1000): The maximum number of files that LevelDB is allowed to have open at a time. If your data store is likely to have a large working set, you may increase this value to prevent file descriptor churn. To calculate the number of files required for your working set, divide your total data by 2MB, as each table file is a maximum of 2MB.
'blockRestartInterval'(number, default: 16): The number of entries before restarting the “delta encoding” of keys within blocks. Each “restart” point stores the full key for the entry, between restarts, the common prefix of the keys for those entries is omitted. Restarts are similar to the concept of keyframs in video encoding and are used to minimise the amount of space required to store keys. This is particularly helpful when using deep namespacing / prefixing in your keys.
leveldown#close(callback)
close() is an instance method on an existing database object. The underlying LevelDB database will be closed and the callback function will be called with no arguments if the operation is successful or with a single error argument if the operation failed for any reason.
leveldown#put(key, value[, options], callback)
put() is an instance method on an existing database object, used to store new entries, or overwrite existing entries in the LevelDB store.
The key and value objects may either be Strings or Node.js Buffer objects. Other object types are converted to JavaScript Strings with the toString() method. Keys may not be null or undefined and objects converted with toString() should not result in an empty-string. Values of null, undefined, '', [] and new Buffer(0) (and any object resulting in a toString() of one of these) will be stored as a zero-length character array and will therefore be retrieved as either '' or new Buffer(0) depending on the type requested.
A richer set of data-types are catered for in LevelUP.
options
The only property currently available on the options object is 'sync'(boolean, default: false). If you provide a 'sync' value of true in your options object, LevelDB will perform a synchronous write of the data; although the operation will be asynchronous as far as Node is concerned. Normally, LevelDB passes the data to the operating system for writing and returns immediately, however a synchronous write will use fsync() or equivalent so your callback won’t be triggered until the data is actually on disk. Synchronous filesystem writes are significantly slower than asynchronous writes but if you want to be absolutely sure that the data is flushed then you can use 'sync': true.
The callback function will be called with no arguments if the operation is successful or with a single error argument if the operation failed for any reason.
leveldown#get(key[, options], callback)
get() is an instance method on an existing database object, used to fetch individual entries from the LevelDB store.
The key object may either be a String or a Node.js Buffer object and cannot be undefined or null. Other object types are converted to JavaScript Strings with the toString() method and the resulting Stringmay not be a zero-length. A richer set of data-types are catered for in LevelUP.
Values fetched via get() that are stored as zero-length character arrays (null, undefined, '', [], new Buffer(0)) will return as empty-String ('') or new Buffer(0) when fetched with asBuffer: true (see below).
options
The optional options object may contain:
'fillCache'(boolean, default: true): LevelDB will by default fill the in-memory LRU Cache with data from a call to get. Disabling this is done by setting fillCache to false.
'asBuffer'(boolean, default: true): Used to determine whether to return the value of the entry as a String or a Node.js Buffer object. Note that converting from a Buffer to a String incurs a cost so if you need a String (and the value can legitimately become a UFT8 string) then you should fetch it as one with asBuffer: true and you’ll avoid this conversion cost.
The callback function will be called with a single error if the operation failed for any reason. If successful the first argument will be null and the second argument will be the value as a String or Buffer depending on the asBuffer option.
leveldown#del(key[, options], callback)
del() is an instance method on an existing database object, used to delete entries from the LevelDB store.
The key object may either be a String or a Node.js Buffer object and cannot be undefined or null. Other object types are converted to JavaScript Strings with the toString() method and the resulting Stringmay not be a zero-length. A richer set of data-types are catered for in LevelUP.
options
The only property currently available on the options object is 'sync'(boolean, default: false). See leveldown#put() for details about this option.
The callback function will be called with no arguments if the operation is successful or with a single error argument if the operation failed for any reason.
leveldown#batch(operations[, options], callback)
batch() is an instance method on an existing database object. Used for very fast bulk-write operations (both put and delete). The operations argument should be an Array containing a list of operations to be executed sequentially, although as a whole they are performed as an atomic operation inside LevelDB. Each operation is contained in an object having the following properties: type, key, value, where the type is either 'put' or 'del'. In the case of 'del' the 'value' property is ignored. Any entries with a 'key' of null or undefined will cause an error to be returned on the callback. Any entries where the type is 'put' that have a 'value' of undefined, null, [], '' or new Buffer(0) will be stored as a zero-length character array and therefore be fetched during reads as either '' or new Buffer(0) depending on how they are requested.
See LevelUP for full documentation on how this works in practice.
options
The only property currently available on the options object is 'sync'(boolean, default: false). See leveldown#put() for details about this option.
The callback function will be called with no arguments if the operation is successful or with a single error argument if the operation failed for any reason.
leveldown#approximateSize(start, end, callback)
approximateSize() is an instance method on an existing database object. Used to get the approximate number of bytes of file system space used by the range [start..end). The result may not include recently written data.
The start and end parameters may be either String or Node.js Buffer objects representing keys in the LevelDB store.
The callback function will be called with no arguments if the operation is successful or with a single error argument if the operation failed for any reason.
leveldown#getProperty(property)
getProperty can be used to get internal details from LevelDB. When issued with a valid property string, a readable string will be returned (this method is synchronous).
Currently, the only valid properties are:
'leveldb.num-files-at-levelN': return the number of files at level N, where N is an integer representing a valid level (e.g. “0”).
'leveldb.stats': returns a multi-line string describing statistics about LevelDB’s internal operation.
'leveldb.sstables': returns a multi-line string describing all of the sstables that make up contents of the current database.
leveldown#iterator([options])
iterator() is an instance method on an existing database object. It returns a new Iterator instance.
options
The optional options object may contain:
'gt' (greater than), 'gte' (greater than or equal) define the lower bound of the values to be fetched and will determine the starting point where 'reverse' is not true. Only records where the key is greater than (or equal to) this option will be included in the range. When 'reverse' is ‘true` the order will be reversed, but the records returned will be the same.
'lt' (less than), 'lte' (less than or equal) define the higher bound of the range to be fetched and will determine the starting poitn where 'reverse' is nottrue. Only key / value pairs where the key is less than (or equal to) this option will be included in the range. When 'reverse' is true the order will be reversed, but the records returned will be the same.
'start', 'end' legacy ranges – instead use 'gte', 'lte'
'reverse'(boolean, default: false): a boolean, set to true if you want the stream to go in reverse order. Beware that due to the way LevelDB works, a reverse seek will be slower than a forward seek.
'keys'(boolean, default: true): whether the callback to the next() method should receive a non-null key. There is a small efficiency gain if you ultimately don’t care what the keys are as they don’t need to be converted and copied into JavaScript.
'values'(boolean, default: true): whether the callback to the next() method should receive a non-null value. There is a small efficiency gain if you ultimately don’t care what the values are as they don’t need to be converted and copied into JavaScript.
'limit'(number, default: -1): limit the number of results collected by this iterator. This number represents a maximum number of results and may not be reached if you get to the end of the store or your 'end' value first. A value of -1 means there is no limit.
'fillCache'(boolean, default: false): wheather LevelDB’s LRU-cache should be filled with data read.
'keyAsBuffer'(boolean, default: true): Used to determine whether to return the key of each entry as a String or a Node.js Buffer object. Note that converting from a Buffer to a String incurs a cost so if you need a String (and the value can legitimately become a UFT8 string) then you should fetch it as one.
'valueAsBuffer'(boolean, default: true): Used to determine whether to return the value of each entry as a String or a Node.js Buffer object.
iterator#next(callback)
next() is an instance method on an existing iterator object, used to increment the underlying LevelDB iterator and return the entry at that location.
the callback function will be called with no arguments in any of the following situations:
the iterator comes to the end of the store
the end key has been reached; or
the limit has been reached
Otherwise, the callback function will be called with the following 3 arguments:
error – any error that occurs while incrementing the iterator.
key – either a String or a Node.js Buffer object depending on the keyAsBuffer argument when the iterator() was called.
value – either a String or a Node.js Buffer object depending on the valueAsBuffer argument when the iterator() was called.
iterator#end(callback)
end() is an instance method on an existing iterator object. The underlying LevelDB iterator will be deleted and the callback function will be called with no arguments if the operation is successful or with a single error argument if the operation failed for any reason.
leveldown.destroy(location, callback)
destroy() is used to completely remove an existing LevelDB database directory. You can use this function in place of a full directory rm if you want to be sure to only remove LevelDB-related files. If the directory only contains LevelDB files, the directory itself will be removed as well. If there are additional, non-LevelDB files in the directory, those files, and the directory, will be left alone.
The callback will be called when the destroy operation is complete, with a possible error argument.
leveldown.repair(location, callback)
repair() can be used to attempt a restoration of a damaged LevelDB store. From the LevelDB documentation:
If a DB cannot be opened, you may attempt to call this method to resurrect as much of the contents of the database as possible. Some data may be lost, so be careful when calling this function on a database that contains important information.
You will find information on the repair operation in the LOG file inside the store directory.
A repair() can also be used to perform a compaction of the LevelDB log into table files.
The callback will be called when the repair operation is complete, with a possible error argument.
Safety
Database state
Currently LevelDOWN does not track the state of the underlying LevelDB instance. This means that calling open() on an already open database may result in an error. Likewise, calling any other operation on a non-open database may result in an error.
LevelUP currently tracks and manages state and will prevent out-of-state operations from being send to LevelDOWN. If you use LevelDOWN directly then you must track and manage state for yourself.
Snapshots
LevelDOWN exposes a feature of LevelDB called snapshots. This means that when you do e.g. createReadStream and createWriteStream at the same time, any data modified by the write stream will not affect data emitted from the read stream. In other words, a LevelDB Snapshot captures the latest state at the time the snapshot was created, enabling the snapshot to iterate or read the data without seeing any subsequent writes. Any read not performed on a snapshot will implicitly use the latest state.
Getting support
There are multiple ways you can find help in using LevelDB in Node.js:
IRC: you’ll find an active group of LevelUP users in the ##leveldb channel on Freenode, including most of the contributors to this project.
Mailing list: there is an active Node.js LevelDB Google Group.
GitHub: you’re welcome to open an issue here on this GitHub repository if you have a question.
Contributing
LevelDOWN is an OPEN Open Source Project. This means that:
Individuals making significant and valuable contributions are given commit-access to the project to contribute as they see fit. This project is more like an open wiki than a standard guarded open source project.
A large portion of the Windows support comes from code by Krzysztof Kowalczyk@kjk, see his Windows LevelDB port here. If you’re using LevelUP on Windows, you should give him your thanks!
LevelDOWN is licensed under the MIT license. All rights not explicitly granted in the MIT license are reserved. See the included LICENSE.md file for more details.
LevelDOWN builds on the excellent work of the LevelDB and Snappy teams from Google and additional contributors. LevelDB and Snappy are both issued under the New BSD Licence.
Get notified with Vuex when the stored values change
Why use this plugin
Some reasons why you could consider to use this plugin:
Use a fallback Browser storage method in case the user’s browser has limitations. Safari in Private mode can deny writing data in localStorage.
Easy extensibility with Plugins. Support for expiring stored values at a given time, declare default values, etc.
A consistent API across browsers for a key/value storage functionality.
Easy definition of alternative Storage methods. For example: you could reuse a Vue Component, that relies on a storage method, in the user’s browser (using localStorage) or a mobile app (using NativeScript application-settings module) just by changing the storage method without modifying the internal logic of the component.
Synchronization of stored values changes with Vuex.
Installation
This module is distributed via npm which is bundled with node and should be installed as one of your project’s dependencies:
npm install --save store vue-warehouse
or
yarn add store vue-warehouse
Example of use
Suppose you want to use localStorage by default and cookies as an alternative in case your user’s browser doesn’t allow any interaction with localStorage (Safari Private mode). Besides, you want to define defaults values and an expiration date for all the data that is going to be saved.
Configuration for Vue.js
importVuefrom'vue'importVueWarehousefrom'vue-warehouse'importVueWarehouseSyncfrom'vue-warehouse/sync'importVuexStorefrom'./vuex/store'// vuex store instanceimportVueWarehouseStorefrom'store'// vue-warehouse store instanceVueWarehouseSync(VuexStore,VueWarehouseStore)Vue.use(VueWarehouse,{store: VueWarehouseStore,plugins: [require('store/plugins/expire'),// Expire stored values at a given timerequire('store/plugins/defaults')// Declare default values],storages: [require('store/storages/localStorage'),// localStorage supportrequire('store/storages/cookieStorage')// cookies support]})
// Define defaults valuesthis.$warehouse.defaults({user: {name: 'John Doe'}})// Change current user with an expiration date of 2 hours starting from nowconstexpiration=newDate().getTime()+(3600*2000)this.$warehouse.set('user',{name:'Marie Doe'},expiration)// Get current user valuethis.$warehouse.get('user')// Get current user expirationthis.$warehouse.getExpiration('user')// Remove current userthis.$warehouse.remove('user')// return the default value -> { name: 'John Doe' }// Clear all keysthis.$warehouse.clearAll()// Loop over all stored valuesthis.$warehouse.each(function(value,key){console.log(key,'==',value)})
Vuex State
The last change made to the browser store (localStorage, cookie, etc.) are synced with the Vuex state:
// Store current userthis.$warehouse.set('user',{name: 'John Doe'})// Update the userthis.$warehouse.set('user',{name: 'Marie Doe'})// get state valuesstore.state.warehouse.action// action performed -> setstore.state.warehouse.key// key affected -> userstore.state.warehouse.value// stored value -> { name: 'Marie Doe' }store.state.warehouse.oldValue// last value -> { name: 'John Doe' }
This project is sponsored by me, a Full Stack Developer. If you require Professional Assistance on your project(s), please contact me at https://marquez.co.
Contributing
Please make sure to read the Contributing Guide before making a pull request.
Code of Conduct
Everyone participating in this project is expected to agree to abide by the Code of Conduct.
Before you can build this project, you must install and configure the following dependencies on your machine:
Node.js: We use Node to run a development web server and build the project.
Depending on your system, you can install Node either from source or as a pre-packaged bundle.
After installing Node, you should be able to run the following command to install development tools.
You will only need to run this command when dependencies change in package.json.
npm install
We use npm scripts and Webpack as our build system.
Run the following commands in two separate terminals to create a blissful development experience where your browser
auto-refreshes when files change on your hard drive.
./mvnw
npm start
Npm is also used to manage CSS and JavaScript dependencies used in this application. You can upgrade dependencies by
specifying a newer version in package.json. You can also run npm update and npm install to manage dependencies.
Add the help flag on any command to see how you can use it. For example, npm help update.
The npm run command will list all of the scripts available to run for this project.
Service workers
Service workers are commented by default, to enable them please uncomment the following code.
The service worker registering script in index.html
Then you would import the JS and CSS files specified in library’s installation instructions so that Webpack knows about them:
Edit src/main/webapp/app/vendor.ts file:
To optimize the DocumentApplication application for production, run:
./mvnw -Pprod clean package
This will concatenate and minify the client CSS and JavaScript files. It will also modify index.html so it references these new files.
To ensure everything worked, run:
You can use Docker to improve your JHipster development experience. A number of docker-compose configuration are available in the src/main/docker folder to launch required third party services.
For example, to start a mysql database in a docker container, run:
docker-compose -f src/main/docker/mysql.yml up -d
To stop it and remove the container, run:
docker-compose -f src/main/docker/mysql.yml down
You can also fully dockerize your application and all the services that it depends on.
To achieve this, first build a docker image of your app by running:
./mvnw package -Pprod verify jib:dockerBuild
Then run:
docker-compose -f src/main/docker/app.yml up -d
For more information refer to Using Docker and Docker-Compose, this page also contains information on the docker-compose sub-generator (jhipster docker-compose), which is able to generate docker configurations for one or several JHipster applications.
Continuous Integration (optional)
To configure CI for your project, run the ci-cd sub-generator (jhipster ci-cd), this will let you generate configuration files for a number of Continuous Integration systems. Consult the Setting up Continuous Integration page for more information.