This was another programming exercise to get more comfortable with Kotlin. A deterministic push down automaton (DPDA) is basically a finite state machine with a stack for memory. Since finite state machines (FSM) generally use their states as memory, this allows you to have fewer states in your model. The downside is that you will have more numerous and complex state transitions. Whereas with a finite state machine you consider the current state and a new event to determine the next state, with a push down automaton you need to consider the current state, the incoming event, and the top of the stack before determining the next state and the next action to perform on the stack, either pushing a symbol, popping one off, or doing nothing.
I wanted to learn more about Kotlin, so I implemented a simple finite state machine. In this implementation, if an invalid event is passed to the state machine, then it goes into an “error” state, but we never check for the error state soooo… that’s helpful. Also, a current state and an event can be associated with a particular action. Figuring out how to trigger this action led me to use the
invoke() method, of which I was previously unaware. In a more realistic implementation we’d probably want a pre-transition action, and a post-transition action.
I was not successful setting up a Django server in an AWS Worker Environment, so I set up a Flask server instead. This guide assumes that you have a web server running in another environment, and that you’ve configured an SQS queue to enqueue jobs for your worker. We obviate the need for Celery by using a
cron.yaml file on the Flask worker that can be used to define periodic tasks.
This was my first experiment with Vue.js. I wanted to see how hard it would be to use one custom component inside another. Since this was a toy example, I decided to try to draw a chess board.
A similar solution was posted here. I wanted to look at this problem because it is a classic example of handling interprocess communication.
In this problem one models a stream of customers coming into a Barber Shop. If the waiting room, or
lobby, is full, then they leave, otherwise they take a seat and wait for a haircut. The barber(s) take customers, cut their hair, and then look for the next customer.
In this code one channel is filled randomly with
Customers; some of these will wait in the
lobby, others will look for another barber. Within the
BarberShop function, there is a
barbers slice, and a channel named
syncBarberChan. When the function runs, barbers are initialized and added to the slice. When a customer is selected and paired with a barber, the barber is taken out of the slice. At this point the haircut occurs for some period of time. When the haircut is over, the barber is added to the
syncBarberChan. Next the
syncBarberChan is drained for any idle barbers. If a customer is waiting, that newest barber is paired with a customer, otherwise the barber is added back to the slice of barbers.
In this way, the slice holds idle barbers, and the channel is used to signal that a barber is done with a given task.
You might need to install a fair bit of stuff,
sudo apt-get install unixodbc unixodbc-dev tdsodbc freetds-dev freetds-bin -y
There’s a neat trick you can do to automatically configure FreeTDS on you Ubuntu machine (discussion here: https://gist.github.com/rduplain/1293636)
sudo dpkg-reconfigure tdsodbc
This will write data to
/etc/odbcinst.ini for you. This file configures which drivers FreeTDS will use. You could write this by hand, but this operation reduces the risk for error.
I was trying to access a remote server using
pyodbc and I was providing a connection string like,
import pyodbc conn = pyodbc.connection('DSN=<dsn>;UID=john.doe;PWD=<password>')
For some reason, I wasn’t able to connect at all. It turns out that I needed to put a space after
UID… it’s weird, but it worked. Maybe this is because there was a dot in my UID? I’m not sure. You can also set the UID and PWD in
/etc/obcd.ini, but that’s probably not ideal.
If you’re stuck, you can list the connections on a given host with this,
tsql -H <host> -L
You’ll probably need to install tsql, which I think is located in the
freetds-bin package listed above.
Today I worked out an example of using InfluxDB from Django in Docker. Using Docker containers to run databases greatly reduces the amount of database configuration you need to worry about when you’re trying to work out a proof of concept.
InfluxDB is a great tool for storing timestamped data. Storing a timestamp and a set of measurements, one timestamp per row, in a Postgres database is possible, but inefficient. InfluxDB offers you a way to store a set of values, and a set of indexed meta-data tags per row.
For example, if you’re collecting hourly production data from multiple wells, you can store the rates as data values, and wells as indexed tags. Then looking up the production from a set of wells over some time period becomes very efficient due to indexing. Looking up wells by production rates, however, would be very inefficient, unless you stored rate data as a tag, and well names as values. Learn more here from the InfluxDB documentation.
I thought I’d show some examples of solving some common statistical word problems using Python. Today I’ll look at exponential random variables; this is a continuous random variable used to model the waiting time between independent events. Sometimes this is posed as the waiting time for the first event in a Poisson process.