Creating new programs

With everything going smoothly we have begun looking to the future. We plan to begin implementing a basic version of a slide show program this week so that we can use it to present all of our future presentations with. This functionality will be very similar to the spreadsheet functionality allowing for simple saving and loading with the most recent user get to keep their change. The basic slideshow program will have the ability to display text and images to the user on different slides. More customization like animations will come later after the slide show creator and presenter work for text and images.

A development server and some cool updates!

We now have a live server that anyone is welcome to test out. You can find it at dev.briefcasedocs.com . It is currently being run on a free heroku server so not to much process power is dedicated to it. In order to register you will need the key: 62657468. Furthermore we also have a working version of the spreadsheet, with scroll bars and all! There are still a few non-critical bugs and a bundle of features that have not been created yet, however we will be moving focus off of the spreadsheet for a short while in order to get the presentation editor off the ground and to bring the code editor to a stable version. The backend has been recreated in order to provide ease of use to the developers, end users, and sysadmins. This was done by creating a “apps” folder inside of the briefcase directory. In order to add a new brifcase application into briefcase you merely drag the application folder into “apps” and restart django. And one last thing for this post is that we have reached 1000 commits for the entire project. I know that along the way I have learned a lot about programming and web development and so far it has been quite fun. I can only hope that it will continue to be fun for the foreseeable future.

– Asher

It has been a while, but we are back

It has been a long time since we last did work on briefcase, about three months. However we are all back and beginning to code once more. The recent lack of work spawned due to most of our members finishing college and going off to look for a job. When coming back we have a few new things to announce. First off one of our memebrs, Josh, is working on creating a packaged installer file. So that installing briefcase eventually may be as easy as typing “sudo apt-get install briefcase”. Secondly we are revamping or documentation pages. After the big overhaul with the back end and getting the first version of multi user editing done we now are pruning our wiki to contain only up to date information and remove the rest of it. We are also including new pages on how the features and implementations work. You can check this all out at https://github.com/Briefcase/Briefcase/wiki

Spreadsheet multi user

Today Asher and I worked on multi-user editing again. Now the database is updated when a user sends in changes. I’m a little worried about performance issues – but we will deal with that in the future. Glad to have a working version for now.

Code Editor and a faster spreadsheet

This past week has been a busy one, but we have been able to squeeze in a few new features to briefcase in the meantime. The first feature is that Jerry is almost done with the core features of the syntax hilighter, tabbing, auto tabbing, and line numbers have almost come to fruition. The Spreadsheet is also getting a slight overhaul from a canvas element to a native table. The result of this will be that we will finally get to implement changing the cell sizes in a rational non-expensive manner. The scroll bars once again are going to be changing to (what I hope to be) their final state. Due to the re factoring nature of the changes in the spreadsheet they are currently located on a new branch.

Begining the multiple user editing

Today we finished the proof of concept for the multiple user editing. When users make an action their action is sent to the server and the server stores the data in an array of changes to send to all the other connected users. Currently only one instance of a document can be opened by any one user or the data will be split between the two browser windows. Soon in the future this will change. I am truly exited for when this features is completed.

– Asher

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

Recreating The Backend

On suggestion of one of our new members, Andrew Karnani, we have begun recreating the back end, almost from scratch. This time making much more use of the full potential of Django. Along with recreating the back end we have changed the way that the Django server communicates with web applications. The new way uses pure JSON instead of some odd custom string. A result of this will be a more simplistic API for application / server communication. During the RCOS hackathon this Saturday (the 22nd) I plan to hammer out the bugs with this new communication system, and if we are lucky we will begin working on instant saving and loading / live editing.

– Asher

New Repo Location

Now that our group has grown in size I have moved the repo to a more public location. The most up to date version can be found in the briefcase organization page. Along with the main repo you will also be able to find all of the utility repos, for example the documentation website, in that organization as well.

github.com/Briefcase

– Asher

Creating a good API

Unlike writing end-user software, writing an API has two purposes. You must be able to have the developers understand how to use it fairly consistently, but you also must write it so that their end users get the performance that they need. In briefcase we have run into this problem in the form of a simple problem: to use multiple javascript files or not. The argument for using many files is that the code become easier to manage, you can create a file for each of the main focuses of your project. The downside and the argument against multiple files is that for each file you need another HTTP request to the server to get it. I believe that we have come up with a clever solution to this problem. The only files that we as the API creators are considering at the moment are the shared libraries, saving and loading, global menu, context menu, hotkey, infinite onload, etc. Our solution is to write them ourselves in multiple files, each section of the code gets its own little file to sit in and contemplate its existence. When we are done, or would like to release a new version the code is “compiled” into one file. Compiling will do two things. The first one is to simply squish all of the libraries into to one file. The second is to minify it, jquery uses a program called UglifyJS but more research definitely needs to be done.

– Asher