| # Connect to a known RMS and retry every five minutes | |
| RMS=${1-ardop:///OE5XIR?freq=14104} | |
| DELAY_MIN=${2-5} | |
| DELAY=$((60 * $DELAY_MIN)) | |
| SOUND_CARD=$(ardopcf -m 2> /dev/null | grep PnP | grep -o '[[:digit:]]\+' | head -n 1) | |
| rigctld -m 2050 -r /dev/ttyUSB0 -d /dev/ttyUSB0 -p /dev/ttyUSB0 -P RTS -s 9600 & | |
| ardopcf 8515 plughw:$SOUND_CARD,0 plughw:$SOUND_CARD,0 -m > /dev/null 2>&1 & | |
| sleep 2 |
This is a game I was taught by some friends in Sweden, they called it Kabul, but I think it might have another name as Googling for it returned no similar results. I decided to write down the rules as it's actually a pretty great game!
| #!/bin/python3 | |
| import curses | |
| import sys | |
| import os | |
| from math import floor | |
| decks = 6 | |
| bet_unit = 10 | |
| def main(win, decks): |
| SEEDPERSON=$1 | |
| rm output.csv | |
| urls=$(curl -s "$SEEDPERSON" | grep /person/ | grep -v Sammanf | grep grannHeader | sed -r 's/.*href=(.*)>/\1/g' | sed 's/>.*$//' | sed 's/^\//https:\/\/mrkoll.se\//') | |
| #echo "Url, First Name, Last Name, Address, Appt. No., Postcode, DoB, Gender, Res. Since, Phone" >> output.csv | |
| for url in $urls | |
| do | |
| echo -n "$url," >> output.csv | |
| curl -s "$url" | grep -E '(tel:|block_col1)' -A 47 | grep span | sed '/tel:/q' | sed -E 's/<div class=history_span/\n<div class=history_span/' | grep -vE '(history_span|f_head1|förnamn|f_line1|mellannamn)' | sed 's/<[^>]*>//g' | sed -E 's/ lgh ([0-9]{4})/\nlgh \1\n/' | sed s/-XXXX// | sed -r '/^\s*$/d' | sed 's/^herre/M/'| sed 's/^tjej/F/' | sed 's/^dam/F/' | sed 's/^kvinna/F/' | sed 's/^man/M/' | sed '6,7d;' | dos2unix | paste -s -d ',' >> output.csv |
| import { deepEqual } from 'assert' | |
| type RecursiveFn<T> = (xs: T[], out?: T[]) => T[] | |
| type OperatorFn<T> = (T: T, xs: T[], out: T[]) => T | void | |
| type FactoryFn = <T>(fn: OperatorFn<T>) => RecursiveFn<T> | |
| const recursiveFactory: FactoryFn = <T>(fn: OperatorFn<T>) => { | |
| const recursive: RecursiveFn<T> = (xs, out = []) => { | |
| const x = xs.shift() |
| import { Document, Element, parseXml } from 'libxmljs'; | |
| import { VError } from 'verror'; | |
| export class XMLReader { | |
| private document: Document; | |
| private namespaces: Record<string, string>; | |
| constructor(inputXml: string) { | |
| try { | |
| this.document = parseXml(inputXml); |
| // Avoid generating expected results as they are not testing your logic independently | |
| describe('1+1=2 testing antipattern', () => { | |
| describe('add', () => { | |
| const add = (a: number, b: number): number => a + b; | |
| const expected = 1 + 1; | |
| it('should add two numbers', () => { | |
| // This is testing two sets of logic, and doesnt guarantee the correctness of the function | |
| // as the output of expected could also be wrong | |
| expect(add(1, 1)).toEqual(expected); |
| module.exports = function findCodingRange (codingSeq, contig, reverse) { | |
| let codingLength = codingSeq.length | |
| , start = 0 | |
| , end = 0 | |
| , selector = 12 | |
| , fail = false | |
| start = contig.indexOf(codingSeq.substring(0, selector)) | |
| end = contig.indexOf(codingSeq.substring(codingLength - selector, codingLength)) + selector |
I've always had fzf and ripgrep on my radar, and I've finally gotten around to using them together. Good lord it makes a world of difference, especially when added to Vim as well as Bash.
Add the following snippet to your ~/.bashrc, this add's fzf keybindings to bash and gets fzf to use ripgrep by default for faster searching.
[ -f ~/.fzf.bash ] && source ~/.fzf.bash
export FZF_DEFAULT_COMMAND='rg --files --no-ignore --hidden --follow --glob "!.git/*"'
bind -x '"\C-p": vim $(fzf);'
Okay now what can you do?
This is an assessed reflection on some workshops that we did for Agile Methodologies
As part of the course we have done three two hour workshops on Agile methodologies. These have been interesting as they have formalised the practises that I had been doing previously in my industrial year.
For example I wasn't aware that pair programming, test driven development, and continuous integration were part of extreme programming, however I had been using them all year. It was also interesting to see that other practices I had been trained in were closely related to the agile manifesto, such as creating and weighting stories, but we weren't following agile in any formal way.
Pair programming is an excellent tool and from experience of the workshops, personal projects and my industrial year, I can argue that working as a pair is a lot more efficient than working individually. The caveat for this is that both partners are at the same level of familiarisation