This is the jumble solver challenge as levied by a company. The goal is to accept a string of letters and return all possible words that can be made from any combination of those letters, including smaller words. Thus; gdo can be dog, god, do, and go.
To use the scan method:
python scan.py wordlist.txt
The following is the notes I took years ago on the book Ultralearning by Scott Young. The bombastic title and promise to learn virtually anything quickly makes it sound as if its the typical marketing-powered fluff-filled nonfiction book stores are overflowing with, but something about this book stuck with me. After finishing it I quickly went back and wrote these thoughts down. While I don't follow his layout of plans regularly, I have used it to guide a lot of my own self education.
I've successfully utilized it when I needed to refresh on mathematics for my Master's degree (a host of skills that atrophied sigificantly for the dozen years between undergrad and the masters). I've also used it to self-study subjects like Robotics and Deep Learning (though I did decide in the end to go for the Master's accreditation).
I share it here with hopes that someone finds it useful.
Alright, so you want to test how your application fares with questionable network reliability. If you can get your application running in a docker container, this write-up will have you covered.
We're going to utilize linux's tc to control the outbound network connection. There's no easy way to do inbound yet. From that we'll be able to throttle and drop packets outbound which should give you a fair test of unreliable networks.
This dockerfile utilizes the ubuntu image which was necessary for my purposes, but can be generalized to other docker imagers as per your use case.
FROM ubuntu
| { | |
| "name": "simplest-typescript-express", | |
| "version": "1.0.0", | |
| "description": "Package.json for the simplest possible typescript service", | |
| "main": "dist/index", | |
| "types": "dist/index", | |
| "scripts": { | |
| "live": "nodemon --exec .\\node_modules\\.bin\\ts-node -- src/index.ts", | |
| "clean": "rm -rf dist/", | |
| "build": "npm run clean && tsc", |
| const cluster = require('cluster'); | |
| const childProcess = require('child_process'); | |
| const cpus = require('os').cpus().length; | |
| const processes = cpus >= 2 ? cpus : 2; | |
| if(cluster.isMaster){ | |
| console.log("Starting server processes"); | |
| for(var i = 0; i < processes; i++){ | |
| cluster.fork(); |
node.js fs module was originally designed to copy linux's standard way of handling files. This means for deleteing files using the unlink functionality. For Windows, however, unlink operates differently - differently enough that I encountered several issues with unlink.
Why on Windows? Electron, mostly - I needed to handle a file post-creation via a child_process (in this case, a terminal execution of ffmpeg).
Windows unlink works by using ZwSetInformation (a low level Windows API/function) to set a file property DeleteFile to TRUE. Windows will then eventually, once the file is no longer being accessed by any process "delete" the file in whatever way it is wont to do (Recycle Bin versus full delete, etc). However, even if a child process created the file, it seems that the file can possibly be linked back to the parent process, preventing the parent process from ever actually deleting the file.
Even if the unlink process fires correctly, if Windows believes the file is stil
| const spawn = require('child_process').spawn; | |
| const exec = require('child_process').exec; | |
| const terminate = require('terminate'); | |
| const ffmpeg = { | |
| camera: "", | |
| audio: "", | |
| //Make sure to set the camera and audio target devices prior to calling this function. See |
| ### Keybase proof | |
| I hereby claim: | |
| * I am hlfshell on github. | |
| * I am keithchester (https://keybase.io/keithchester) on keybase. | |
| * I have a public key ASA9A116w8k3YjRgwNUgFIjPoJN1F4d3zGQ2CrFDc21nUwo | |
| To claim this, I am signing this object: |
| root@beaglebone:~/test# npm install serialport | |
| - | |
| > serialport@2.0.2 install /root/test/node_modules/serialport | |
| > node-pre-gyp install --fallback-to-build | |
| make: Entering directory `/root/test/node_modules/serialport/build' | |
| make: Warning: File `../../../../../usr/include/nodejs/common.gypi' has modification time 7.4e+06 s in the future | |
| ACTION Regenerating Makefile | |
| make: Leaving directory `/root/test/node_modules/serialport/build' | |
| make: Entering directory `/root/test/node_modules/serialport/build' |
Recently, I succeeded in building node-serialport for a windows NW app. This proved quite problematic, and I have decided to write down necessary steps to get it to run.
First, I would like to point out an excellent article written by the writer/maintainer of node-serialport highlighting why it is extremely difficult to keep node-serialport compatible with all the different node runtimes. Read it and appreciate the effort VoodooTikiGod puts in for us.
Before any action is taken, you need to install all pre-reqs for building with node-gyp native C/C++ modules. The most concise set of instructions that always works I've found is here.
The default build instructions for building native modules for an nw-app are here. The instructions I use, specifically, are: