Latest revision as of 23:17, 19 October 2009

Notebook

June

20.06 (Paul): Idea to create a bioinformatical softwaresuite for brand new google wave came up. Best all watch the video at wave.google.com.
20.06 (Paul): Kristian applied for an sandboxaccount for google wave.
23.06 (Paul): Meeting: Well work on the GeneWave-Projekt! I should be easy to create basic functionality using Biopython/Biojava.
23.06 (Paul): Google didnt answer on Kristans apply yet. We best all apply for Sandbox-accounts.
23.06 (Paul): Seems that Google doesnt creates accounts for the sandbox right now :/
24.06 (Paul): Presentation of GENwave to Kristians lab.
24.06 (Paul): We'll write google an email in order to get an account. we think they should really like our project...
26.06 (Jörg): After days of waiting, we decided to try contacting google by phone, but also with no effect.
28.06 (Paul): No answer from google yet. Well begin writing a "gadget" with basic functionality which can be tested at http://pygowave.p2k-network.org an early open source wave implementation. 1th gaged: Open/Save seq-files

July

02.07 (Paul): As gadgets are pure Javascript/HTML, i don't see a possibility to download/upload-sequence files. I think we need a robot for this... i don't see a useful thing we can do with gadgets right now...
03.07 (Jörg): To avoid the restrictions for up- and downloads of the gadgets, i tried ways to call an applet within the gadget code...
04.07 (Jörg): Although the calling of applets within gadget code is doable the spare possibilities of javascript-applet communication as well as the security restrictions of applets killed the idea of a pure gadget/applet implementation.
08.07 (Paul): I visited the bioinformatical-lecture at the technical faculty and asked if someone wants to join our team. No one answered jet...
12.07 (Paul): As i took a closer look at the Robot-API the last days, i noticed another problem the might occur: Google currently only accepts robot running on Google App-Engine. I think we don't want to run our system on it permanently, but as i don't have any hope that there will be a working solution to host robots on your own server till the jamboree, we have to write the robots for App-Engine and rewrite them later. App-Engine however does not support the BioPhyton- and BioJava-libraries, so we have to import them manually... so we really SHOULD use only one language to write the robots...
14.07. Meeting
15.07. (Paul): There is a new post in the Google Blog announcing that have just begun to give more developers access to the sandbox. So we'll hopefully get our accounts within about a month.
16.07. (Paul): Took me hole morning to figure out that the Google-Web-Toolkit-Eclipse-Plugin needs both 32-Bit JDK- and Eclipseversions to run. Because of this Google-Plugin Eclipse we'll use Eclipse as Software Development Kit.
19.07. (Jörg): Importing BioJava seems to work; Best we just store the BioJava-objects in the Google proprietary GQL-db to bypass the lack of BioSQL.
20.07. (Paul): Google announced an "almost" public beta of Wave starting at September 30th. So maybe we can have a live presentation at iGEM-Jamboree.
21.07. (Paul): Maybe we'll need a server for wavelet - wavelet - communication to bypass Google-App-Engine limitations.
22.07. (Jörg): We decide to take an server with some more CPU power to enable the usage as an application server (Tomcat). This will give us the possibility to make up- and downloads via java servlets.
22.07. (Paul): We looked at some servers from Dell, and maybe found a fitting one.
23.07.: Meeting
24.07. (Paul): I'm currently working on a class which creates basic Text-views of a DNA-Sequence and its readings-frames
24.07. (Paul): Francois Le Fevre, advisor of a french iGEM-Team is interested in joining our Project.
it seems that GeneWave is a registered trading mark, so well maybe have to change the name of the project, maybe to BioWave, SynBioWave, SynWave?
26.07. (Paul): Dell seems to be to expensive if we want a server with native raid-support. We are looking for one at the locale computer stores here in Freiburg.
27.07. (Paul): We created a "Genewave"-Project at Sourceforge.net ( http://sourceforge.net/projects/genewave/ ) so that we can rapidly start programming when we got our sandbox-accounts.
28.07. (Paul): Still working on my displaySequence-class... while its works fine given the right parameters, I'm now adding some error-handling
30.07. (Paul): We finally bought a server at some locale shop here in Freiburg. Its a bit frustrating that we still did not get Sandbox accounts.
31.07. (Paul): I finally got my sandbox-account! No time to write more at the moment, I'm testing Google-Wave

August

01.08. (paul): Wave is a bit slow at the moment. hope google manages to improves this... But the rest of it looks nice
02.08. (paul): I started playing with the robot api. miss some possibilities to debug at the moment.
02.08. (paul): My Robot just stopped working! cant figure out the problem... it just refuses to talk
03.08. (paul): Today my robot was working again... without any changes... :/ hope that does not happen to often...
Meanwhile i found an other mathematican interessted in our project.
04.08. (paul): No wave today ...
05.08. (paul): testing different ways to communicate with a robot. talk to "igemrobot1@appspot.com" to see current state.
06.08. (paul): its very annoying that robots just stop working from time to time :( hope google fixes that soon.
07.08. (paul): Seems "Genewave" is a registered trademark. After some Emails we decided that SynBioWave is a good (and unused) name.
17.08. (paul): back form holidays and back into synbiowave: playing around with formulars. who to address input-boxes?
18.08. (paul): okay, if you create a formview-element in a blip, formulars work quite fine.
18.08.: Kristian registered the domain http://www.synbiowave.org and set a forward to the official iGEM wiki.
19.08.: Raik created a google-code project: http://code.google.com/p/synbiowave/
20.08. (paul): Maybe Annotations are a possible Way to store information in a blip. i consider that a good idea, one the one hand because ifs a that easy to extract Information of a Blip (if there was some work done in it before) and on the other hand because this opens the possibility to replace the Userinterface generated by robots with Gadgets later...
22.08. (paul): Think child-blips are a good way to report errors. so something like

catch (Exception error) { event.getBlip().createChild().getDocument().append("ERROR:" + error.getMessage()); }

23.08. (paul): Talked to Raik about saving information in waves. there are some possibilities to serializes objects in the api.
24.08. (Jörg): I've coded my first sequence view class. This class produces an inlineblip with a sequence alphabet specific colored sequence with scaling.
25.08. (paul): Playing around with robot-gadget-interactions. As there is no java-script in wave, gadget seem to be the only way to get mouse-menus, what would really be a nice thing to have... on the other hand, we loose the "wave-feeling" if working in gadgets and everything becomes much more complicated...
25.08. (Jörg): I've done my first approach for an intuitive sequence recognition. In this approach i track the user input and check complete words if containing purely one of the three sequence alphabets. If so the word is replaced by my before written sequence view.
26.08. (paul): displaying sequences in textareas don't seem to be a good idea either, because they tend to loose there formating there.
27.08. : Meeting
28.08. (paul): Okay, we now think we got a good feeling for the possibility's of wave and are ready for really going to work work. time seems to be short already... While Jörg creates a robot for basic menus and sequence-import, I'll try do create one doing blast-searches, as blast-searches are a popular example for integration of webservices...
28.08. (paul): To do a blast-search, there are roughly 3 steps my robot has to do:
- First: collection all information needed and send the query to NCBI, and extract the request-id (rid) from the answer.
- Second: Wait for blast to finish and get the result using the rid.
- Third: Extract the information of the result and display it in format of choice...
29.08. (paul): Starting with first step. Doing this via httpservlets does not seem to work right now. The build in HTTPRequest-Class makes problems, too. Finally got i working with lowlevel out- and inputstreams, with is not a good solution, but will do for a while...
30.08. (paul): Most difficult part of step 2 is the waining for blast to finish i suppose. think i read something about cronjob in wave... ill solve this problem later. getting the result was quite easy.
31.08. (paul): Even with existing biojava-classes for third step, this was quite painful to do. but in the end, it works... time to create a useful class out of my code-fragments...

September

01.09. (Paul) Meeting
02.09. (Paul) As discussed in yesterdays meeting, i started to work on a robot who will keep an overview of all the functions the other SynBioWave-Robots in this wavelet offer and creates a menu in the current blip. I think this menu should be inside a Gadget, mainly because different people working in the same wave so got their own Versions of this Menu and do not have to share the same one. This means we have think of a protocol for transporting the information needed to generate a Menu from a Robot to the Menu-Robot and form the Menu-Robot to the Menu-Gadget. I'll began working on the second one.
03.09. (Paul) As the Gadget is written in Javascipt, i think a JSON-string is a good way to transport information from Java (the Robot) to Javascript.
05.09. (Paul) While playing around with JSON and working on the Menu-Gadget, the protocol seems to form. I'll post some kind of visualization of it soon... (is there a standard view of such objects?)
07.09. (Paul) My Menu-Gadget is working well enough to start programming the corresponding robot. Maybe David can make it look much nice with his advanced AJAX/CSS-Skills when hes back from holidays.
08.09. Meeting
08.09. (Paul) As Sourceforge has not managed to rename our Project from GeneWave to SynBioWave, i have created a new one called SynBioWave ( http://sourceforge.net/projects/synbiowave/ ) today. This step breaks the "history"-function of the SVN, so look at the SVN at genewave.sourceforge.net if you are interested in previous versions.
10.09. (Paul) I'm currently learning my robot how to create the JSON-Strings containing the information for the menus. I use Javas JSONWriter-class for this, which seems to be crap and produces invalid JSON. As time is short already i've not time to rewrite it in a proper way, so i have to fix this regular-expressions, which consumes quite time. (Did you know that you have to write "\\\\" in Java, if you want to match a single "\" in a regular-expression, because first Java escapes it and then the regular-expression again...)
12.09. (Paul) My Robot now creates proper menus the Gadgets display, I'm moving on to *-Robot to menu-Robot communication. It easiest Way to do this seems to be not going the long way over JSON but just serialize the menu-Object instead.
13.09. (david): I joined the software team and started to deal with google wave and I started to get a overview of the current project state.
14.09. (Paul) David is back from holidays and i meet him today, introducing me to the menuGadget which he'll continue to work on.
14.09. (Paul) Started importing my posts of your local development-journal to the one at igem.org. More (and the Meetings) will follow in time.
14.09. (david): I started concentrating on client side development. I figured out some possibility of creating graphical User Interfaces. The native UI-possibilities of wave API are limited. Gadgets allow including any HTML / JavaScript Code. Gadgets are included as IFrames inside blips. One can use wave API inside gadgets!!
- advantages of gadgets
  - nearly unlimited features possible
  - implementation of other software like JavaScript Frameworks possible
- disadvantages of gadgets:
  - always rectangularly shape of gadgets
  - only possible to add a gadget into a blip
  - more development cost than using native API
15.09. (Paul) We'll present our project to Kristian's Lab tomorrow, so i spend today making menuGadget and -Robot more presentable...
15.09. (david):Meeting with Paul, Jörg and me. We decided to use the free software project qooXdoo for creating complex GUI (Graphical User Interface). qooXdoo is a powerful (JavaScript) framework for creating Rich Internet Application (RIA) especially for creating GUIs based on JavaScript!
16.09. (Paul) Today we had another long downtime of Google's Wave Server:
Unfortunately we had our whole presentation concepted as a live demonstration of SynBioWave, so that we were totally fooled by this... That was a good lecture for the Jamboree i think.
16.09. (david): It took me nearly two days for getting qooXdoo run inside a gadget. Besides reading up on qooXdoo, googles documentation of gadgets with type="url" does not work in wave :-( Creating GUI widgets with qooXdoo is really easy :-) No real interaction with wave yet.

17.09. (Paul) Today David, Jörg and I met to work on the Dataexchange of the menuRobot and -Gadget together. That was quite effective... Till all Robots stopped working again after 1.5 hours... It was late afternoon when they decided to work again. These days Wave really deserves the label "dev-preview".
17.09. (Paul) None the less David and I totally reworked the menu-exchange-protocol today, making it much more flexible. Think we'll get some nice results tomorrow. I also tried continued the implementation of the robot-robot-communication by serializing objects to string, store these in the wave, read them with another robot and to un-serialize them again to objects. That found a rough end by limitation of AppEngine...
I'll now try to store the objects in Google's Database and just exchange links to them between the robots...
17.09. (david): I am getting more and more familiar with qooXdoo and wave gadgets. Improved my code quality a lot. Only some small visible changes. Implemented an auto-resizing feature. The gadget changes its height on changes of GUI height. Works good with this example. But the solution is not flexible enough! Paul and I updated the existing interface for creating a menu. It will be called qooxwave Software_Current_Ideas#qooxWave_protocol.
18.09. (Paul) Although i used the class for storing Data in Google's Datastore, I'm having a hard time storing my recursive menu-classes. Sometimes it work, but at least about every second try it doesn't. Again i feel left alone with Googles bad documentation. So only thing i can do is keep trying.
18.09. (david): Working a lot on the qooxwave protocol. This will be a powerful tool for realising an abstract robot class as a template for creating application features.
19.09. (david): Paul and I are working on the qooxwave implemenation. Paul on server side robots; me on client side gadget. At the end we have our first working implementation! A nice Menü in a toolbar which is created by the MenuRobot using qooxWave protocol:

20.09. (david): Thinking about a possible implementation of the client to server part of qooxWave protocol. This is needed to handle events. The Robots need to recognize user input! What happens for example if a user presses a button. We have always in mind that we are developing a real-time, multi user application. What happens for example if two people submit contrary data at the same time?
20.09. (Paul) Today i gave up the Datastore totally frustrated. Even having starred a every word in Googles Documentations, followed the "tutorial" word by word twice and doing only minor changes to the code descriped there, i cannot figure out why my program seems to work only sometimes (by accident?). That's nothing we can build a communication protocol on. Jörg was unabel to solve the problem, too. Think I'll need some hours to get my head free...
21.09. (Paul) I'll now build the robot-robot in "the long way", meaning I'll convert the JAVA Objects to JSON-String, place them in the Hidden Part of a wavelet (called Datadokument), read them by another robot and unserialize them back to JAVA Object there again. (And - in case of the menu-robot - convert them to JSON-Strings again after some operations...). At least this seems to work...
22.09. (Paul) Somehow Robots often don't see events triggert by other robots, seems thats not implemented in wave yet. I filled a bug-report hoping to get this fixed soon as the workarounds are really ugly...
23.09. (Paul) The Communication via JSON-Strings now work! I'll clean up my code today, and build an abstract class organizing this for later robots afterward.
24.09. (Paul) It would may be handy to create our own Wave-Event on menu-clicks, but that would require deep changes of the wave-API, which is not an good idea a that early and buggy state of wave i think. I created the abstract class so that every developer has to override mainly 3 functions to create a working SynBioWave-Robot. First, a generateMenu() functions which returns the Menu this Robot offers, second a processSbwMenuEvents() to respont to clicks on this Menu and third a processSbwEvents to recieve the original Wave-Events after they were parsed by the abstract class.
24.09. (Paul) I often meet David these day and be talk about the communication protocols a lot and expand them from time to time.
25.09. (david): Updated the qooxwave protocol so that forms are available. Paul and I implemented this. It looks like that:

25.09. (Paul) I visited a lab meeting of our Wetlab-team today (maybe to be linked later) and talk about how we could collaborate, so we don't have to do work twice. Looks like Freiburg's teams will have the same logo, T-shirts and Wiki-design. I was asked to help them doing their modeling.
26.09. (Paul) I tried the hole day to generate a simple list of all blips of a wavelet, what really should not be too hard... and failed! Seems every Event "sees" only a small part of a wavelet and all the documentation says about this is:

Note: The behavior of this method is dependent on the 'context' settings in the Capabilities XML configuration. 
Child blips may not have been sent with this event.

I found NOTHING neither in the documentation, the Google Wave Group nor in the Web a what context settings i maybe have to set... Getting a list of all Blips is important to updated all Menu's display if a Robots joins or leaves the wavelet.

27.09. (Paul) Meeting
28.09. (Paul) After another many hours of searching, i found out that it is impossible to get a list of all Blips in a Wave, at least at the moment.
30.09. (Paul) As the framework is now somehow working, i took a look on my blast robot again, porting it to use the framework. I gave the Robots the ability to read formulars from the menu-gadget for that.
30.09. (Paul) Today a big update for Wave is ancounted (together with the start of a "closed beta"), hopefully making our life more easy...

October

01.10. (Paul) Time is running out, we have to start implementing more functionality so that we have something to present at the jamboree. Unfortunately after yesterdays update, ALL of my Robots just stop working. I'm really hoping it's not a big issue.
03.10. (Paul) It seems that the updates made nothing easier, but lot of things worse. There is a new Bug that Robots cannot create new Blip's anymore, what was the main reason for nothing working anymore. On top of that an Google developer answered one of my Bug-reports (I'm currently writing several of them every day...) that it is intended that robots often do not react on events triggered by other robots rather than a bug. The communication of the Robots that worked before quite well, now often fails. Seems that Google did some work there, fixing the "bugs" I used...
04.10. (Paul) I got most thinks somehow "working" again ... at least about half of the time (that really drives me crasy) and not in a presentable way. I think it unrealistic that Google will fix all these new issues (and the existing old ones) till the jamboree. Boston, we have a problem.
06.10. Emergency-Meeting.
06.10. (Paul) I started decentralizing our framework. That really helped. Blastrobot is now working in a way that deserves the word. I furthermore tried to integrate a ReBase-function and the generation of a circular sequence view, what failed with both, again due to some appengine-limitations. But I'm optimistic that Jörg can maybe outsource the generation of the sequence view as this should not be so different from the upload he a successfully implemented yet.
6.10. (david): Implemented a fileupload widget. This took me quite long because there is no native implementation in qooxdoo. Besides that, fileupload with html/js is a strange. One needs to use hidden Iframes for uploading target...

10.10. - 12.10 (david): Improved the qooxwave protocol: Forms support upload-items as subitems. This allows a really nice dialog for importing/uploading sequences. Here is one example:

Key features of this change:
- multible upload fields in forms
- There is a submitting sequence: the files are submitted one after the other. Then the form is submitted.
- Many events are fired: upload started and completed (for each file), on form submit
- The changeValue event of the form contains upload infos such as filenames
- The files are send to the target url speciefied in the item structure. This url is modified so that it contains the other form values as GET parameters
- loading icon
- process infos while uploading
- nice groupbox layout ...
12.10: Meeting
15.10: Meeting
17.10 + 18.10 (all): We met the hole weekend to write the missing wiki-pages, to finalize and polish synbiowave. There is still lots of work to do till the jamboree!

@@ Line 69: / Line 69: @@
 </nowiki></code></blockquote>
 * <b>23.08. (paul):</b> Talked to Raik about saving information in waves. there are some possibilities to serializes objects in the api.
+* <b>24.08. (Jörg):</b> I've coded my first sequence view class. This class produces an inlineblip with a sequence alphabet specific colored sequence with scaling.
 * <b>25.08. (paul):</b> Playing around with robot-gadget-interactions. As there is no java-script in wave, gadget seem to be the only way to get mouse-menus, what would really be a nice thing to have... on the other hand, we loose the "wave-feeling" if working in gadgets and everything becomes much more complicated...
-* <b>25.08. (Jörg):</b> In the last days i produce a first try of a sequence
+* <b>25.08. (Jörg):</b> I've done my first approach for an intuitive sequence recognition. In this approach i track the user input and check complete words if containing purely one of the three sequence alphabets. If so the word is replaced by my before written sequence view.
 * <b>26.08. (paul):</b> displaying sequences in textareas don't seem to be a good idea either, because they tend to loose there formating there.
 * <b>27.08. :</b> Meeting

Team:Freiburg software/Notebook

From 2009.igem.org