Hello again.
I was not the first to find the key this time, props to EnigmaZer0 for this one! After seeing that everyone enjoyed understanding how the first clues were solved I thought I'd provide an explanation for The Leporine Key.
The second clue dropped early afternoon EDT on (easter) Sunday April 21 2019. The clue can be viewed on the satoshis treasure website here and looked like this:
_____ _ _ _ _ _____
/ ___| | | | | (_| ) |_ _|
Today (April 16th 2019 at noon) the first major clues to discover key #1 was set to be released in a few cities. A QR code with the words 'orbital' were found at these locations and looked like this: (https://imgur.com/a/6rNmz7T). If you read the QR code with your phone you will be directed to this url: https://satoshistreasure.xyz/k1
At this URL you are prompted to input a passphrase to decrypt the first shard. An obvious first guess was to try the word 'orbital' from the QR code. Not suprisingly this worked! This reveals a congratulations page and presents the first key shard:
ST-0001-a36e904f9431ff6b18079881a20af2b3403b86b4a6bace5f3a6a47e945b95cce937c415bedaad6c86bb86b59f0b1d137442537a8.
Now, we were supposed to wait until April 17th to get clues from the other cities for keys #2 and #3 but that wouldn't stop me from digging around with all the new information we had. All that time "playing" notpron (http://notpron.org/notpron/) years ago was going to help me here.
The first thing I noticed was
| # Backup | |
| docker exec CONTAINER /usr/bin/mysqldump -u root --password=root DATABASE > backup.sql | |
| # Restore | |
| cat backup.sql | docker exec -i CONTAINER /usr/bin/mysql -u root --password=root DATABASE | |
| # For example, run "npm install" | |
| docker run -v "$PWD":/usr/src/app -w /usr/src/app node:4 npm install | |
| # This command creates a container (downloading one first if you don't have it locally), runs the command in a current directory and quits the container | |
| # Great Success! |
| #!/bin/sh | |
| # | |
| # puma - this script starts and stops the puma daemon | |
| # | |
| # chkconfig: - 85 15 | |
| # description: Description \ | |
| # goes here... | |
| # processname: puma | |
| # config: /etc/puma.conf | |
| # pidfile: /home/stanislaw/apps/micro-apps/puma/puma.pid |
I'm hunting for the best solution on how to handle keeping large sets of DB records "sorted" in a performant manner.
Most of us have work on projects at some point where we have needed to have ordered lists of objects. Whether it be a to-do list sorted by priority, or a list of documents that a user can sort in whatever order they want.
A traditional approach for this on a Rails project is to use something like the acts_as_list gem, or something similar. These systems typically add some sort of "postion" or "sort order" column to each record, which is then used when querying out the records in a traditional order by position SQL query.
This approach seems to work fine for smaller datasets, but can be hard to manage on large data sets with hundreds (or thousands) of records needing to be sorted. Changing the sort position of even a single object will require updating every single record in the database that is in the same sort group. This requires potentially thousands of wri
| # for more info: https://gist.github.com/1120938 |
