Home      Updates      RSS Feed      About      Code      Contact

  VPS move March 23 2012  4:26 AM EST

Notice anything different? Well, hopefully you don't ;) The company I buy VPS time (terminology?) from, FanaticalVPS had their second birthday recently. To celebrate, they're offering a 30% for life discount until the end of the month. Being the savvy shopper I am, I went ahead and jumped on the offer ;)

So, currently there is hughes and frost . For a while both were pretty broken due to me updating the non-qualified domain to be frost instead of hughes. Right now, though, both should be pretty equivalent. I don't yet have all the git repositories copied over, so the code page is broken on frost.

So, besides not yet copying everything over, what are the other changes? Well, the VPS model is exactly the same, but it is on a different node. Still in Germany, however. Something that has changed is that I switch from Apache to lighttpd . Why? Well, I wanted to explore with FastCGI and decided to explore with servers too. So far lighttpd is living up to it's reputation of being lighter. As for speed, well, my website is not dependant on the server speed very much at this point. Being that I get one whole visitor (me) on the average week, I think either will do just fine :)

As always, there is a lot more I want to write. For now though, I'm stopping because I just saw a huge spider and freaked shit a little XD Also, it is like 2 in the morning and I should be sleeping.

  What's that horrible "Status" box? February 16 2012  4:32 PM EST

Hello! If you've looked at the code page at all, I'm sure you've noticed that it is often slower than it should be. One of the major issues, I think, is the rather low persistence of cached data. I think there may be some kernel option (some cat 0 > /proc/) that is doing this. I'm not entirely sure. Anyway, currently the page searches through all available repositories, finds out when their recent commits were and decides what three to display at the top. I decided that it would be neat to have some sort of API, and to use it in javascript to fill in this information dynamically.

There have been a number of commits to the code for this site over the last day or so. The /api URL has come into existence, and has had several features implemented. At the moment, there are:

  • status: to get various feed-like status updates I may start making. At this point it only ever returns the hard coded status above ;)
  • cat: to list repositories, branches, files/directories and to actually cat out the files within. The encoding of the returned files is a little funky (\n and \t have been escaped, among others) to have it be proper JSON.
  • clang: to list the repositories using a specific language, or all of them if no argument is given. This is just so that it is easier for me to have features without proper thinking out cat
  • commit: to list commits to a repository/branch, and to get the actual diff from a commit. This is the main thing I need to fix up the code page.

If you want, feel free to play around with the various functions. If you specify no arguments when it needs one, it will hopefully tell you. However, there is no real documentation besides the source, hehe. Perhaps there needs to be a help function added. Edit: I have added the page I was using in testing to the static directory. Check it out.

Some neat structural changes to the site have been made, such as automatically included javascript per directory, if it exists. So, if you request the dgi.d source file from dsrv , there might be several javascript files included. First and foremost, there is js/_.js which is included in all URLs (if it exists). Then, the next possible includes would be:

  1. js/code.js
  2. js/code/dsrv.js
  3. js/code/dsrv/files.js
  4. js/code/dsrv/files/master.js
  5. js/code/dsrv/files/master/src.js
  6. js/code/dsrv/files/master/src/dgi.d.js

and then finally, the old js/main.js file. Now, most of these will never be used, but the first level there might be used. For instance, the about page currently uses javascript that is defined in js/main.js. In the future, this will probably move to js/about.js file.

We now finally get to the glaringly ugly status box :) Essentially, I need some quick test of the API and of the module function system. The module function system is really just an array of functions defined in _.js which can be added to from the other included js files. The window.onload event is then hooked up to a function that calls them all in order. Now, why does the status box look so ugly? Well, I hear the entire site is ugly, without users overriding the CSS with their own (which is what I do). The current setup isn't the easiest to adjust the style with, and it doesn't look completely horrid. In essence, it looks ugly because it will anyway, but I do plan on getting it at least less horrid.

  RNA Folding "game" February 11 2012  9:27 PM EST

You may or may not know that this semester for the Choose Ohio First Bioinformatics scholarship I'm working with Andrew on RNA secondary structure prediction. If not, you do now ;) We've looked over some papers, and found a highly referenced work on the topic, a dynamic programming approach. I'm hoping to come back and make a post about the papers we read and specifically about the algorithm we're currently using. We were able to shortcut some steps because there is a provided reference implementation of the algorithm. We're still working on understanding it, but it should prove as a good starting point and potentially as something we might be able to extend. In addition to that, we've decided we would like to have a visualization of the folded RNA. Not just a static visualization, however, but one you can change to see how the overall energy changes

So, where do we start on something like that? Well, there is a pretty popular piece of software named jmol, which has visualisation. However, it has many more features than we need and because of that might be hard to extend. What we want is relatively simple, so right now we're both trying our hand at implementing it. Andrew is trying in java, and I'm doing it in C.

We don't get something that says "the 33rd guanine goes in these coordinates", so we must come up with something ourselves. I thought about it for a little bit, but couldn't come up with anything satisfactory. So, instead I opted to start off with a Feynman diagram form. For this visualization, the chain is laid out in a circle, and bonds between pairs are arcs between them. This is really neat, because it is very easy to see where there are various structures like hairpins and loops. The last few hours was spent hacking away on it, and I've come up with something I think looks pretty neat (and lets you modify the structure, the main purpose!).

This is a slightly modified result of the optimal RNA secondary structure prediction algorithm, to show off more interesting structures. Before, there were some external bases and one loop, not interesting :) This is an actual screen-shot of the program, and the bonding modifications were made inside the program. The next thing I need to have is text rendering, to say what is selected, what is hovered over, and whether or not those can be paired. In addition, there will be a continuous energy rating somewhere. An idea I had is, once you select or hover over a base, background threads can start exploring modified structures based on altering that pair, and then give you "hints" if it finds a structure that is more optimal than what is there presently.

The main reason I wrote this post, though, is the weighted, arbitrary degree Bézier curve drawer I implemented for this. Basically, the arcs showing bonding between bases went through a few iterations. I knew what I wanted them to look like, but that was too complicated to start with. So, it started out as simple straight lines. The next thing I did was to figure out the "distance" around the circle the bases are (allowing jumping over the hole on the right). Then, I created a circle concentric to the backbone whose radius is inversely proportional to the distance between the bonded bases. Then, the point on that circle at the angle that was half way between the two bases was chosen as an intermediary point between the first and second base. Two straight line segments were drawn, connecting these three points. Finally, a weighted Bézier curve drawing function was implemented to interpolate the points with a weight of 1 for the endpoints and 2 for the midpoint. The Wikipedia article portion about the rational form was succinct, but easy to understand. To calculate the (n choose i)'s I simply started at 1 and calculated the next number to the right in Pascal's triangle by the obvious method (multiply by degree minus i, divide by i).

List of all updates

 

My name is Jeff Chapman; You can reach me at: jac@JAChapmanII.net