Place holder text for the Hamloak. This file will be removed when some actual work has been completed on this project.

Place holder text for the Crown. This file will be removed when some actual work has been completed on this project.

\[ \mathrm{crown} = \frac{\sin(x)}{x} \]

Place holder text for the Sceptre project. This file will be removed when some actual work has been completed on this project.

Place holder text for the Auto Handle project. This file will be removed when some actual work has been completed on this project.

As CQP’s main blacksmith, I shall in be charge of the creation of the sword. To this end, I have brainstormed several ideas for the blade itself, as well as the hilt, handle, and pommel. Of course, the more elaborate I make the plans, the more effort (and more time) it will take to complete. However, regardless of this, I want the most awesome sword possible.

For the blade itself, I’ve been thinking of a damped harmonic oscillator style of shape. Starting high, it shall elagantly slope downwards before rising again in glorious triumph, if slightly diminished. This shall then asymptote to a straight line, eventually cut and shaped into a point. This blade shall be precisely 1 metre long (or, as close as I can get it). There shall be a double fuller, with the head of CQP inscribed between. The cutting edges will be inscribed with the great works of Quantum, those of Schrödinger, Maxwell, Lindblad and Bloch(-Redfield). After inscribing, the blade shall be coated in titanium nitride and then ground down to a mirror polish, to allow the inscriptions to be inlaid with “gold” (A system will need to be developed for additional inscriptions).

(Placeholder for equations)

For the guard, I haven’t really had too many ideas. The hilt I want to 3-D print in clear resin (because awesome), and the pommel… well. I don’t know. For the guard, I think maybe some sort of mathematical constant, or maybe something based on a certain chaotic system I know Tim is working on. Something like that would look awesome. I’m also thinking that maybe we can get these coated in diamond, for the extra awesome (and cool) factor. Here’s some cool looking hilts, which I’m thinking will be worth considering.

Of course, I am more than happy to entertain outside ideas. So long as the “outside” doesn’t leave the Physics realm. I’m planning on using some CAD software to more fully design the sword (as well as the 3-D file for the handle), so that will be coming soon!

Until then, keep “sharp”! hehehe…

Number of papers

Publish or perish is the name of the game. We look to encourage the number of papers published by adding achievements to our troops.

Number of citations

What good is a publication if no-one talks about it? Here are the awards for citations.

Physical Review Publications

Physical Review, known for reviewing physical things is a time honored journal of which many physicists publish. One goal however is not so easy, that is the coveted alphabet where a physicist has publications in every single journal, we wish to acknowledge said physicist’s path to greatness.

Other APS journals exist but I’m not sure if I should include them.

Programming Language

This is where we celebrate a person’s proficiency in the glorious language of computers.

Other languages to be added.

Other Achievements

Rank

This is also a work in progress. Rank is designated by degree level. Whether someone achieves a rank by beginning a degree or completing it is yet to be decided. Ranks are also a work in progress.

A note from the author

Discussion is acknowledged and encouraged (there is an achievement for inventing a new badge/achievement after all) and so all opinions are welcome. If you think something needs tweaking just give us a buzz.

There are a few ideas for the horn so far. These include using a cow horn such as this or a thing known as a shofar. There are several pros and cons to getting the tone that we require for the Haskell Horn. That is:

[A] baritone blast to penetrate walls…

That’s all just basic things, though. What we really need is a practice horn, so that people who aren’t brass players (i.e. David) can get their Embouchure going. This is particularly important to be able to do correctly when blowing the final horn, as any failure on the part of the blowee would reflect badly upon those who follow Haskell.

Other valid concerns include the size of the horn itself, as space is severely limited. This, however, will affect the tone of the call. Since horns aren’t too expensive, this can be experimented with by the purchase of several different sizes. We, of course, want the deepest tone possible, for the space available. One option would be to curl a larger horn around, sort of like a trombone. This presents problems of its own, as then the horn may start becoming heavy, and I am unsure as to the ease of curling horn.

For now, though, the possibilities are almost endless. Who knows what may lie ahead?

I do.

Awesomeness.

The Teensy arrived in the mail today. It’s actually a lot smaller than I thought:

Depending on how I go today I may start working on the hardware components of the chadburn, but this is unlikely. This post will be completed when the prototype is functioning.

Whilst the panel is ultimately served up by the Web Server, I thought it warranted a separate post.

In the name of doing things as difficult as possible, but the end result being technically and visually awesome, I decided that the Chadburn itself should be constructed as an svg, considering its support for both animation and interactivity; the fact that Inkscape has scared me for quite some time (& this should be rectified) and because flash is, well… no.

I found Inkscape to be usable, although a bit clunky. It’s output is pretty bloated too, but as svg’s are essentially just xml markup they were surprisingly easy to optimise. Fat could just be trimmed out line by line. When it comes to animation time, there are two choices: SMIL or javascript. SMIL is relatively limited in its capabilities (simple motion tweens, transitions; but not interactivity), so I ended up using Snap.svg - which was surprisingly powerful and easy to use.

I won’t go over the code here because it’s essentially straightforward HTML5 and simple javascript. Take a look at panel.html and the static/ on Github if you’re interested.

Here’s a quick look at the panel itself:

Usage is pretty simple. When the mechanical E.O.T. updates, the socket server will broadcast the new state and the red indicator will move to the associated position. To acknowledge this command, the user clicks on the appropriate region, which will send and acceptence back to the mechanical version, as well as update the user’s virtual chadburn state.

A quick example of all of this happening can be watched below. For now I’m not allowing the server visible to the internet so you can’t test it out for your self just now. This will be possible once it’s installed and tested on Fenchurch.

There’s a small π button in the bottom right hand corner that will bring up the debug menu if you want to fiddle. The response commands are listed in the WebSocketHandler class of the server code.

The Web Server component of the E.O.T. will probably be the most complicated, so I started with it. A Github repo has also been created that will hold the panel and the Teensy control code too.

The soft plan at the moment will be to write a number / status value to a file via the Teensy; which will be written in C. Implementing the rest of the stack in C is madness considering we have no need to keep everything embedded.

This means that we’ll need a file watcher connected to a web app for the panel interface (which, with v1.0 will be a soft panel). I know of a decent watcher in Ruby and a couple in Python, and considering I hate Ruby and Fenchurch already has Python (somewhat) installed; it seemed like a good starting point. Python also has a decent http server stack so that’s a plus; but:

with Python… I could argue that this could all be done in Haskell too, but no-one likes and Evangelist.

So next step: I don’t want to have to refresh the page on an update of the E.O.T. (i.e. a modification in the status file), nor do I want to poll the server with a tonne of ajax queries every 30 seconds or so. Although the update doesn’t really need to come through as a push notification, it’s also useless if coffee is called and no notification arrives for 15 minutes…

(Very, very) long story short; I’ve implemented the communication system using Web Sockets. They’re compaitible with most browsers (maybe not if you use IE, but also: if you use IE I don’t care about notifying you of anything anyway) as long as it’s a relatively recent build (Chrome though: you’re good almost as far back as the dark ages).

Tornado is a great Socket server capable asynchronous (threaded) processes. This is quite helpful for us here because our file watcher will need to run in a separate thread. If any of you have worked with async before you’ll know it’s a nightmare if you don’t have things set up right: race conditions, deadlocks etc. etc. It also handles many unique clients - so we can all have the panel open on each of our machines. With the web sockets always open (but not polling), we will have push notifications from the E.O.T. without any overhead on Fenchurch or our local machines.

Once the server is initialised, a callback to Watchdog is added, which watches status.eot: the file written via the teensy, for modifications. If the file has changed (the E.O.T. position has been changed), that value will be instantly read and pushed through the open web sockets to each attached client.

A small amount of debugging has also been implemented (see the on_message member of the WebSocketHandler class below), which is currently accessible via the panel; although it’ll most likely be removed in the future.

Clients are currently identified by uuid, but in the future this can be changed to something more personal, a mac address, something like that. It depends on how much capability we want to put into the panel and if any decent ideas are thought up along the way. One thing that I’ve left out presently is a broadcast update of each client’s acceptance message. I’ve done this because it may be a good way in the future to indicate who is coming to coffee or something.

The only other thing of note is that I’ve implemented a graceful shutdown so Jared (or any other sudoer) can call a kill -2 on the server to halt it if it’s being an ass. It will call shutdown routines for the watcher and allow any further socket communication to cease (with a maximum waiting time of 5 seconds) before ultimately killing itself.

The code for v0.5 is posted below with enough comments to get you by. Most of those reading this will be familiar enough with Matlab to be able to ‘read’ the Python syntax.

server.py