# What's that shiny thing over there?

Why it's High Level Language Computer Architecture and building an FFP Machine in Verilog! Here to distract me away from databases.

School's winding down, only four weeks left to go. For a final project in a verilog class I'm going to try and implement a FFP machine architecture, and if I have the time make a Scheme to FFP layer since, while FFP is basically just Scheme with <'s and >'s, Scheme is better.

I'll still be reading about the database when I can and hopefully I'll have a couple blog posts up about it by May at latest. At least I'll be able to share the results of the FFP Machine attempt, since my grade depends on it getting at least mostly working! I'll also give a link dump at some point to all the sources I've found that may be interesting to someone else.

# Let's build a database!

As I may or may not have mentioned, I work with LucidDB in my day-job. It's pretty awesome, and I've learned a lot, though the underpinnings of the database architecture itself are still fairly mysterious to me. I would wager there are some low-hanging fruits in the C++-based Fennel core that could result in significant speedups of certain queries, but it's a complicated code base that it's confusing where to begin.

So! In order to better my own understanding of databases in general, I'm going to build a Persistent Almost-Relational Object Database sYstem. If you're intimately familiar with database literature, perhaps you recognize the PARODY acronym from the book C++ Database Development. Indeed, I recently bought the 1994 book for \$4 (with free shipping) off Amazon. It even came with a floppy disk!

The book grants liberal usage of the code, so long as it's not republished somewhere. Since I'm going to use Python instead of C++, I can avoid this restriction. (Also, I like Python way more, and since this is going to be more of a toy database I don't think the performance penalties of Python really matter.) You can follow my progress on my GitHub account's project page (I'm calling it PARODPY), and I'll occasionally blog about my progress, explaining things (largely to myself, as this is foremost an educational experience) in a similar manner to the book. For particularly interesting bits of C++ code I may show a comparison to the Python, and I'll be relying on fair use laws and the fact that it's from 1994 to protect me from any evil thoughts the author may have about his work being discussed. :)

For whatever reason, my Non-Violence for a modern world post is my most popular post. Yet oddly, my AWStats shows the hit is on the ID based url of 72. Yet Google can't find any link: references to it.

So I'm adding in Google Analytics, because hey, data is useful and I'd rather have data than remain ignorant.

This does bring me one step closer to hypocrisy, however. See, I use NoScript, and I don't allow Google Analytics to track me. Oh well. I can still promise this blog will never have ads.

# Spring Security: basic auth custom message passing

I don't like Spring Security. Nevertheless, it's what I'm using for an application, so I had to learn more about it than I cared for. Let me describe my scenario, and my wishes.

Using basic authentication means sending some sort of authentication token up to the server with each request. This has some downsides, notably sending the password in the clear (it doesn't matter if it's base-64 encoded) every request. While yes sending a session cookie or some other identifier has the same risk of being sniffed in the network, at least when someone hijacks your session they don't also know your password that you might use for other services. This is why sites should ask for the old password before letting you change to a new one.

I wanted to bypass sending the password, and instead pass a UUID. I'm also sending a hashed version of the password (just for the first login request) and its salt, by first hashing it in the same way the server hashes new passwords and letting the server hash the stored database hash with the sent salt and compare with the double-hashed password. I need the UUID because I want unique, persistent database connections for each session rather than each user. The application I'm working on allows for a user to be logged in from multiple places, indeed possibly from multiple users, and I want a separate, distinct DB connection for each of them even if they are using the same database username.

# Poor Japanese

I included the second image because, hey, explosions and floods look awesome, but it's important to remember that they unfortunately are often accompanied by death and suffering. Now, looking at the poor Japanese, I still think: yet 1.8 people die every second. People will forget in a week. This is why I think it's important to remember the simple statistic of 1.8 people dying every second, because it's something easy to remember, and it will keep you fighting for humanity in general rather than splurging a couple bucks of donation to the Japanese (that will probably just end up in the pockets of Japanese corporations) and feeling good about yourself for the year.

If you're planning on donating to the Japanese, whose loss and suffering is no doubt great, and some poor people could definitely use some money, consider donating to the Singularity Institute instead. You can wave it off as sci-fi all you like, just remember how much of our current technology was sci-fi not too long ago. The SIAI exists for the purpose of building a Friendly Artificial General Intelligence, one that can improve itself and become smarter. If it is capable, but does not stop these tsunamis from harming anything, it is not Friendly. If it is incapable, it is not intelligent. We could stop these things from happening, if we were a little bit smarter, or if we had more time with the problem. The SIAI aims to build an AI that would stop such disasters from harming anyone, pointing out a potential bad AI points out a failure mode for them, it does not argue against any of the possible benefits of a Friendly AI.

# Simple abstraction

Abstraction is good. Say you're given the following task: write a script to take in five integers as input, add them together, and print the result. A naive implementation would look like this:

n1 = raw_input('Enter number: ')
n1 = int(n1)
n2 = raw_input('Enter number: ')
n2 = int(n2)
n3 = raw_input('Enter number: ')
n3 = int(n3)
n4 = raw_input('Enter number: ')
n4 = int(n4)
n5 = raw_input('Enter number: ')
n5 = int(n5)
total = n1 + n2 + n3 + n4 + n5
print total


Now, this certainly gets the job done, and if you're new enough that you can't conceive of better abstractions to make the work load a lot less, this will suffice for a first shot allowing you to continue work on launching your product... If you're writing software for a company that's not giant, the first job should be making something that works, the second job is making it work efficiently/elegantly/maintainable. While I'm working I have to stop myself from premature abstraction that I didn't see until I was done with a naive approach. I'll get the obvious things, sure, but a few times I've seen abstractions for the entire code base that I was only allowing myself to do later, not at the moment I saw them.