| package test | |
| import ( | |
| "bytes" | |
| "encoding/json" | |
| "testing" | |
| "github.com/golang/protobuf/jsonpb" | |
| structpb "github.com/golang/protobuf/ptypes/struct" | |
| "github.com/google/cel-go/cel" |
| blueprint: | |
| name: Frigate Notification (0.10.0) w/ ignoretime | |
| description: | | |
| ## Frigate Mobile App Notification | |
| This blueprint will send a notification to your device when a Frigate event for the selected camera is fired. The notification will initially include the thumbnail of the detection, but include an actionable notification allowing you to view the clip and snapshot. | |
| With this blueprint, you may send the notification to multiple devices by leaving "Device" blank and instead use a [notification group][1]. | |
| ### Software Version Requirements |
Tutorials for running live Kali on OSX often require you have networking on your laptop to apt install the drivers, but without an ethernet adapter you're not going to be able to do that, so this tutorial will cover a method of doing this manually, using another thumbdrive or external data source.
Download the appropriate Kali Linux .iso
I used a 64 bit .iso image, downloaded via HTTP.
This gist is based on the information available at golang/dep, only slightly more terse and annotated with a few notes and links primarily for my own personal benefit. It's public in case this information is helpful to anyone else as well.
I initially advocated Glide for my team and then, more recently, vndr. I've also taken the approach of exerting direct control over what goes into vendor/ in my Dockerfiles, and also work from
isolated GOPATH environments on my system per project to ensure that dependencies are explicitly found under vendor/.
At the end of the day, vendoring (and committing vendor/) is about being in control of your dependencies and being able to achieve reproducible builds. While you can achieve this manually, things that are nice to have in a vendoring tool include:
Locate the section for your github remote in the .git/config file. It looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = [email protected]:joyent/node.git
Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:
| #!/usr/bin/env bash | |
| # Usage: | |
| # ./git_move.sh git@repo_site.com:/my_repo.git origin/folder/path/ /destination/repo/path/ new/folder/path/ | |
| repo=$1 | |
| folder=$2 | |
| dest_repo=$3 | |
| dest_folder=$4 | |
| clone_folder='__git_clone_repo__' |
| #!/usr/bin/env python | |
| """ | |
| Takes snapshot of full webpages using Webkit and Qt4 | |
| usage: | |
| python web2png.py URL [FILE] | |
| example: | |
| python web2png.py http://python.org out.png | |
| see: | |
| http://riverbankcomputing.com/static/Docs/PyQt4/html/qwebview.html#load |
| // package spooler implements a disk-persistent queue. | |
| // | |
| // Spooler uses MDB (LMDB) to implement a queue of byteslices. Its intended usecase | |
| // is to enqueue work items received by a service before later working them off. | |
| // Note that Spooler only flushes to disk up to once every 25ms. As a result, | |
| // if the process or machine crashes unexpectedly, the most recent 25ms of work | |
| // can be lost. This decision effectively increases throughput by 10,000%, | |
| // but makes spooler unsuitable for jobs that absolutely cannot be allowed to fail | |
| // under any circumstances. | |
| package spooler |