More Upgrades

With the addition of a whole new back end structure I went forward with recreating the front end a little bit. Aside from a few bugs that exist in the spreadsheet application we now have a new login and user profile page. It is almost the same as the old one but is a bit shinier. The shadows and background moves in response to your mouse to give it some 3D looking effect, not sure if that is going to stay or not though. Jerry Schneider is working on redoing the code editor and got some work done at the hackathon but has not pushed his code yet because of some integration issues with the code editor and the new backed. Hopefully when that is done we will see some of his awesome work.

New Login Screen


New user profile


Meta Javascript

As my work on briefcase revs back up I wanted to figure out how to solve a problem that I ran into with multiple libraries.
The problem is with the ‘onload’ variable
JQuery does a nice job handling this by creating a new function, they even changed the way it works to their own custom implementation that only waits for the html to load not the pictures and ads. However this is not what I was after. I wanted a method that would be able to take two pieces of code that both had onload commands, for example a menu library and the actual application.  After a little bit of research i stumbled upon a function call defineProperty(). Using this function I was able to create the code below.

onload = function () {alert("Not Loaded")};
onload = function () {alert("Loaded")};

// You probably dont want to have two onloads being set
window._onload = [];
window.onload=function(){for(a in _onload) {_onload[a]()}}
Object.defineProperty(window,"onload",{get:function()){return this._onload},set:function(n){this._onload.push(n);}});

// Lets add a few more onloads to test the process
onload = function () {alert("Loaded2")};
onload = function () {alert("Loaded3")};

below This code has four onload functions being created. The first two onload calls are present before the code begins handling the onload commands, the second two appear after.

The very first onload statement will get overwritten by the second, however the third and fourth statements will all get run along with the first

Changing the Spreadsheet rendering method

The current rendering method for the spreadsheet is the HTML5 canvas. Which works remarkably well. However it has two drawbacks that I have run into so far. The first is that it renders raster images, which means that if you zoom in to the page, the input text and menu bar scale fine but the spreadsheet gets very pixelated. The other is speed. Everything drawn onto the canvas is done in javascript which is inherently slow. Due to me not knowing enough about how the HTML5 canvas drawing functions work, I have no doubt that I am causing multiple redrawings to occur each time I want to change the canvas contents. While the canvas version of the spreadsheet will not be going away the focus will shift for the time being onto a native rendering environment. The WYSIWYG editor is still planned to use the canvas, hopefully by the time that begins development we will be better at writing efficient canvas drawing functions.

– Asher

Code Documentation

Documenting code is important. Documenting code is not just commenting code, but also writing pages on how to use your code. Recently I have seen some rookies do things in there documentation similar to:

If you are a user then ask your system admin to set up the server / configuration files

Then never in their documentation include any information for the system admin on how to do so. This kind of documentation is not helpful, you need to have a walk through for each part of the set-up and each part of the usage. Another thing that I have seen recently with projects that include a library or framework is that a link to the installation page for that library is included as the primary source of information about how to install the library that their software depends on.  If you use a library or framework like that then you should try to include a brief summary with a list of instructions on how to install the library or framework under standard circumstances. Then include a link to the external installation page as a backup in case the user needs more information in order to install the package.

While the github wiki is great for documentation it can sometimes be hard to figure out a way to properly display all the information you would like, especially if there is a different way to install the program depending on what operating system you are on. For Briefcase I would like to create a website that has this documentation. A live Briefcase server will also be up and running soon that will allow people to register and test out Briefcase. This will be separate from the dev server that has been running for the past few months, and hopefully more stable.

In other news if anyone is good a graphics design we would love to have you on the project, my claim to fame for graphics design is being able to make the corners curvy and some little photoshop stuff.

– Asher

Multiple Cell Selection

After a while we now have a functional multi-cell selection working! Though at the moment of writing the functionality for manipulating those cells is not yet implemented I do hope that they will be soon. Once the ability to manipulate multiple cell groups is complete I will begin again at tackling the problem of the code editor and how to make it faster.
Multiple Cell Selection Screeshot
Beth is currently working on getting the back-end to handle the live view for multiple users. There are also some problems with database migration that cause the database to be deleted every so often. Once that bug is fixed we will have a public server that people can access in order to test out our software. I also hope to roll out a few new application ideas before too long for interested parties to begin work on if they want to help contribute.

– Asher Glick

Finishing up the year, beginning the summer

Overall this year went pretty well, we became overloaded with work in the past few months but that is all over now. Going into the summer I hope to make applications that are fully featured. I am personally proud of the accomplishments that Beth and I have achieved, and like I say, It’s only going to get better. Looking to the future we will be finishing up the functionality of the spreadsheet and code editor. Live editing will continue to be the top priority and we will be working on making sure the system is solid, secure, and cheap, we would not want processors to be overflowed with benign update calls to the server when the window is not in focus. Also I would like to mention a few other colleague’s programs. BlueMesh: a bluetooth mesh networking library, written by up and coming masters of parallel magic who helped out with some algorithm development for Briefcase. Colin Kubler’s Koala / LDT which provides the base for the syntax hi-lighting in the code editor.

– Asher

Bad code and little documentation

In the past few weeks I have begun writing two new applications for Briefcase: Code editor, and Presentation Editor. The code editor is based off of the LDT syntax highlighter and the presentation editor is meant for use with the BIG presentation system. As I have been rapidly coding there is little to no documentation for these applications and the code base for them is quite horrendous. But that is ok. Why is it ok to have horrendous code? For research, just messing with code to figure out how it works. However, looking back on it I see that it is quite bad. I also tried to see how the LDT would work with a content editable DIV tag. It works, but there are many problems with it. So I am now going to begin working with ranges within text areas in order to implement adding and removing selected text within a text area. If I am able to do that then the entire code editor will be created using a slight derivation of the LDT. The documentation for Briefcase need to be improved quite a bit before I can consider the program even remotely ready for a release.

Undergraduate Research Symposium (UGRS)

On Wednesday, the RPI Undergraduate Research Symposium. Unfortunately they only let on person actually give the oral presentation so Beth decided to not present. I believe that it went well, we used a very similar slide deck to our presentation at university of Albany.
I am going to begin finishing the briefcase fronted re-factor this weekend.

– Asher Glick

Keeping a Simple Development Environment

When going into this project I wanted to create an environment that was very easy for the users to use even if it meant more work on the development end, and I still believe that. Now that I have released the first version of the first application component I believe I fully realise that our users are not just the end users but they are also the developers. I myself have become both and end user and a developer user. When it is easy to contribute code or work to a project more people want to do it. If the development environment requires you to install Django on your laptop even though all you want to do is write some math library in javascirpt, that is a bad development environment. As a result I have tried to keep the environment simple. Django does not like static files, part of the reason why I am leaving all the Django work to Beth, so you cannot just write a web-app in your file-system and expect it to work on Django, you cant even write one using an apache server and expect it to run on just Django. I am not sure exactly what you need to change but there are some elements that do need to be changed. The way it is currently set up is that static files can be accessed but only through absolute paths. The absolute path on the server and the absolute path on your development platform are not going to be the same. So how to fix this problem. In Django the relative paths will not load and in Apache or a file system the absolute paths will not necessarily load. Django has a small fix for the absolute path problem by replacing the root of the absolute path with {{STATIC_URL}} we can create an absolute path with the root from the applications folder. If we include both the absolute path and the relative path depending on which environment you are using one of them will work and the other will not. relative will break on Django but the absolute will work, and  relative will work on everything else but the absolute will not. So by including both we know that the external file will load no matter what environment you are in.

Using JQuery

There are some people in the development community who avoid libraries like JQuery. So this is why we are using JQuery. It provides many features that make javascript simple, like AJAX request and animations. However JQery also has a unique onload method. You use it by passing a function into  $(document).ready(). The reason this is so important is that while docuent.onload can only have one functions set to it, you can add add multiple functions to .ready(). This way we can make plugins and components without having to worry about them overwriting each others onload functions.