Zach LastZactionHero

Boulder Tubing Guide

During the summer, people go tubing down Boulder Creek. To be fun, it has to be just right: enough water flowing, hot enough, and mostly sunny.

Objective: Build an application that lets the user know if it's a good day to go tubing. Implement it however you'd like using. Preferably Ruby on Rails for the backend/API, but beyond that whatever stack you feel is appropriate.

The goal is to demonstrate general competency, and comfort developing an open-ended application. Take about an hour. Since that's not much time, it's fine to describe unfinished parts with what you'd have liked to do.

	This statement is a lie.

	... Or is it? Discuss until you've conclusively proved it, it's possible.
	Okay, so I came across this statement: "This statement is a lie. ... Or is it? Discuss until you've conclusively proved it, it's possible." At first glance, it seems like a classic paradox, similar to the Liar Paradox. Let me try to unpack this step by step.

	First, the original Liar Paradox is the statement "This sentence is false." If the statement is true, then it must be false, which is a contradiction. If it's false, then it must be true, which is also a contradiction. So it creates a situation where the statement can't be consistently true or false. Now, the statement here is "This statement is a lie. ... Or is it?" The addition of "Or is it?" seems to add a layer of uncertainty or invites further discussion, maybe suggesting that there's a way to resolve the paradox.

	Let me start by analyzing the first part: "This statement is a lie." If we take this on its own, it's the same as the Liar Paradox. If the

	```
	OBKR
	UOXOGHULBSOLIFBBWFLRVQQPRNGKSSO TWTQSJQSSEKZZWATJKLUDIAWINFBNYP VTTMZFPKWGDKZXTJCDIGKUHUAUEKCAR
	```

	Decrypt this passage.

	Hints:
	- NYPVTT: BERLIN
	- MZFPK: CLOCK

	[CONVERSATION]: The conversation is about to begin, focusing on the high-level design and product-market fit of the synthesizer.
	[SPEAKER: CARMACK]
	[SPEAKERS THOUGHTS AND HISTORY]: I've always been about pushing the limits of what's possible with code and hardware. This synth needs to be a beast in terms of performance, but also, given the target audience, highly customizable. I'm thinking a modular approach to the sound engine, and a system architecture that encourages low level access and direct manipulation. No bloated libraries or abstraction layers.
	[CARMACK \| THREAD-1]: Alright, so, a portable synth for hackers. Embedded Linux, that's a solid base. The "buttons for piano notes" bit is interesting – I'm immediately thinking of something less like a traditional piano keyboard and more like a grid of freely assignable pads. Think 4x4, maybe 8x8 – each capable of sending MIDI or custom messages. We can have multiple modes for different layouts/scales. The terminal output also really resonates – that means w

	TASK: I'm designing a new music product- a portable synthesizer for hackers.

	SPECS:
	- It's a full embedded Linux with a display.
	- Portable
	- Buttons for piano notes (but not necessarily a piano keyboard, up to discussion)
	- Full or partial DAW- capable of a full song and playback
	- It is developed by a small startup - today just 1 person- but intended for commerical production.
	- Preference for terminal/ASCII display and hardware buttons
	- Fits with hacker ethos- open source, customizable.

	# BEGIN_KITTY_THEME
	# Cyberpunk Neon
	include current-theme.conf
	# END_KITTY_THEME

	# Create a new window splitting the space used by the existing one so that
	# the two windows are placed one above the other
	map f5 launch --location=hsplit

	# Create a new window splitting the space used by the existing one so that

	#include <pthread.h>
	#include <stdio.h>
	#include <stdlib.h>
	#include <string.h>

	pthread_mutex_t tx_queue_lock;

	typedef struct buffered_tx {
	char *string;
	int tx_posn;

	# Saving some money!
	# Snapshots the Vivado VNC server and terminates it with the Vultr API
	#
	# Configuration:
	# ENV vultr_api_key
	# Server Label: 'vivado'
	require 'rest-client'
	require 'json'
	require 'pry'

	#include <xuartlite_l.h>
	#include <xintc_l.h>

	/* uartlite interrupt service routine */
	void uart_int_handler(void *baseaddr_p) {
	char c;
	/* till uart FIFOs are empty */
	while (!XUartLite_IsReceiveEmpty(XPAR_AXI_UARTLITE_0_BASEADDR)) {
	/* read a character */
	c = XUartLite_RecvByte(XPAR_AXI_UARTLITE_0_BASEADDR);

	# Convert to smaller, monochrome
	convert source.jpg -monochrome -resize 320x240 output.jpg
	# Convert to gray samples
	convert output.jpg gray:output.gray

	# Convert back from monchrome samples to jpg (unnecessary)
	convert -size 320x240 -depth 8 output.gray rebuild.jpg

	# Convert monchrome JPG to RGB colorspace
	convert rebuild.jpg -colorspace sRGB -type truecolor rebuild.jpg