#project liveblog

[just-evo-now]

woot finished strings, numbers, while, for, and a ton of quality of life fixes.

[just-evo-now]

Intervention of the week: paying myself to work.

I put in way more hours at my job when I was being paid by the hour. I’m not sure if paying myself will work, but it’s potentially very high value.

So: I set aside some part of my paycheck as “required” (rent, food, etc), and the rest is “to be earned”. I then have to work enough hours to earn that money back.

What to do with the money I don’t earn back:

Destroy it?

Donate it?

Give it to a friend?

Spend it in a way I find actively repugnant?

I think I will start with “donate it”, since if it works it’s the best option. (Note that any money I earn back is not part of my donation budget, I’m pretty sure that wouldn’t work).

I also need to decide on an hourly wage. It’s late and I don’t want to do the math out now, but I will probably do something like $to_be_earned / $desired_hours, so that I get everything back if I work enough hours.

[just-evo-now]

fuuuuuck I think I need to switch to Ubuntu if I don’t want to do horrible hacks in order to get NVIDIA drivers (which I need, of course.)

[just-evo-now]

It’s sprint day! Yell at me if you see me posting things that aren’t directly related to sprint day.

Today I will be working on implementing the algorithms from this paper, because that’s what an AI person I talked to suggested. I’ve never implemented anything like this before, so I’m excited.

[just-evo-now]

It’s sprint day again! Unlike the last two I’m not going to be coding, so we’ll see how that goes. Also I’m still on Bay area time so I’m going to be starting an hour later.

[just-evo-now]

Sprint day noon update: 5 issues closed, switched from angular 2 + systemjs to react + webpack.

Now I get to do front end stuff. Oh joy.

[just-evo-now]

Prediction Project: Testing

Like any sane software engineer, I fully endorse setting up a testing environment before writing any actual code.

Like every actual software engineer, I did not do this. Or rather, my testing originally consisted of fucking with the UI and lots of log statements. I think this was kind of dumb, but on the other hand I was feeling slightly overwhelmed by the amount of new information and didn’t want to add more things to my list of things to learn.

My testing architecture is fairly simple and standard: I use jasmine as a test runner, with nodemon for watching files, recompiling from Typescript, and rerunning the tests.

Most of my effort so far has gone into setting up a way to test the server. This is  annoyingly difficult. Node’s built in http library is very low level, and the wrapper libraries I looked at didn’t even work. Also, jasmine doesn’t play nice with asynchronous functions so I had to figure out their hackaround which took forever.

Anyway now I have figured out how jasmine does async, and I’ve written my own wrapper around the http library which is much simpler.

Next step: actually writing some tests.

[just-evo-now]

Prediction Project: Architecture

Core Tools

Pretty much my only architecture requirement was “Use tools I enjoy using”. But when I started this project I didn’t know any web-dev tools, so I did a brief scan of the entire landscape first.

Tools I tried:

Meteor

React

Angular 2 (I’d already used AngularJS)

Ember

Knockout

Backbone

Mithril

Node

Flask

Rails

Django

Mongo

Postgres

(I didn’t try out every combination of these).

Ultimately I settled on a very standard MEAN2 (mongo, express, angular 2, node) stack. I liked all the tools (I’m saddened by mongo’s data integrity but my database needs are minimal), they were popular in industry, and there was pretty good documentation available.

I didn’t like Meteor, Django, Rails, or Ember - far too much magic. I like having complete control over my projects, and I had no intention of spending enormous amounts of time learning the ins and outs of frameworks I might never reuse.

Knockout, Mithril, and Backbone got rejected on the grounds of having relatively small communities.

Mongo got picked over postgres because I thought mongo would have a nicer learning curve (not sure this is the case now that I know both of them).

Node got picked over every other backend because it’s fast and I suspect it will be the future plus I don’t like using more than one language for a project. (This turned out later to be a good idea: I wrote stuff to autogenerate request routes and I wouldn’t have been able to do this if I wasn’t using javascript on both ends).

Angular 2 got picked over React because I had marginally more experience with the former. I like React though.

The whole project is in Typescript because default javascript is just terrible.

Dev Ops Stuff

I use systemjs for front end modules, but I might convert to webpack in the future. Nodemon gets used for building and watching. Jasmine gets used for testing. HTTP route testing gets done with a custom library because I couldn’t get the various libraries I looked at to work and this was easier than debugging them. 

Other Details

I ended up writing my own (partial) implementation of JSON web tokens because the available libraries all sucked. I will probably change that to something else entirely once I actually get around to worrying about security.

I didn’t like Mongoose at all so I wrote my own set of functions to eliminate as much boiler plate as I could. I have code to both create data types (with pre-determined database interactions) and to run ad-hoc database interactions more cleanly.

I find writing HTTP routes extremely frustrating (because you have to write them twice) so I wrote code to generate them automatically (given a bunch of information about what the route should do), and then I attached that code to my database management functions so that I can do stuff like create a class, say what routes it should have, and then have everything (routes, database interface, etc.) be generated. This will probably turn into a horrible kludge if I try to make it do anything more complicated though.