- Enable the tracer on your xdebug.ini file (see the
xdebug.ini
file). - If you are gonna trace an http request, make sure your
xdebug.trace_output_dir
is writable by the webserver user (www-data). - Execute your script or your request. You can use
produce_segmentation.php
to test. - See the trace file(s) on your
xdebug.trace_output_dir
.
*.json diff=json |
- Orig repo:
INITCOMMIT=$(git rev-list --parents HEAD | egrep "^[a-f0-9]{40}$")
- Dest repo:
git format-patch --git-dir=/repo_orig/.git --stdout $INITCOMMIT..HEAD | git am
git filter-branch --prune-empty --tree-filter '
if [[ ! -e foo/bar ]]; then
mkdir -p foo/bar
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files foo/bar
fi'
Where foo/bar
is the new dir where your files will be placed.
#!/bin/bash | |
RANGE_COMMITS_FROM_HEAD=$1 | |
SCRIPT=$2 | |
if [ -z "$RANGE_COMMITS_FROM_HEAD" ] | |
then | |
RANGE_COMMITS_FROM_HEAD=1 | |
fi |
version: '2' | |
services: | |
mongo: | |
image: mongo:3.4.2 | |
ports: | |
- "27018:27017" | |
restart: always |
I hereby claim:
- I am smoya on github.
- I am smoya (https://keybase.io/smoya) on keybase.
- I have a public key whose fingerprint is 551D 0285 D0FE EF30 4869 23CC BEC8 92D4 C851 AE30
To claim this, I am signing this object:
package main | |
import ( | |
"bufio" | |
"context" | |
"fmt" | |
"io" | |
"log" | |
"net/http" | |
"net/http/httptest" |
This poc tries to demonstrate how "easy" can be exposing CLI tools via HTTP API. The example isn't perfect. It doesn't provide a REST API but it just allow to quickly prototype tooling that can be accessible both via CLI or HTTP.
This is a do not do this at home, however it can be used as starting point for interesting approaches.
I decided to do this insane proof of concept in order to (in)validate the idea of exposing cobra commands via HTTP as a quick prototyping framework. Once built, you just need to create commands and the api will expose them. Even though it could be fast for prototyping, this is not the ideal solution as it's super tricky.
I plan to write periodic updates about the AsyncAPI Spec and parsers every ~2 weeks (I hope you are ok with it). This is not an official AsyncAPI update but a personal summary I volunteer to do.
What do I mean by AsyncAPI Spec ecosystem? As most of the work around the AsyncAPI Spec is not only related with https://github.com/asyncapi/spec, each update will include the most significant recent activity from the following repositories, which I consider them to be part of the same ecosystem: