Wednesday, April 28, 2010

This blog has moved


This blog is now located at http://floreysoft-en.blogspot.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://floreysoft-en.blogspot.com/feeds/posts/default.

Wednesday, January 20, 2010

Resellers wanted!

We have launched our reseller portal!
You can now can become a floreysoft reseller very easily. Just sell one of our products to your existing customers (or to yourself) and you'll get qualified to become a reseller.
Have a look at this screencast to see how this works.
Once you are a reseller, you will not only be listed on the reseller page. You'll also get a discount up to 50% for all of our products.
As soon as you sell two products, you'll get a discount of 10%. The discount will increase when reaching the next reseller level.

Monday, January 4, 2010

New website online

I've ported our website to GWT 2.0 to take advantage of the new layout panels.
Some of the CSS styles that I've used are available on Chrome/Safari only. If you are interested in the next generation of HTML/CSS based websites, you should use one of these.
While porting the website I came across a number of bugs in GWT 2.0, especially the new TabLayoutPanel is not working on Internet Explorer :-(

Wednesday, August 5, 2009

shared contacts launched!

We just launched our shared contacts application on Google App Engine (Java)!
This small but powerful application lets you share Google contacts with other Google users.
This is extremely helpful if you are using Google Apps to run your business and you want to share contacts with all your employees.
Up to now you had to upgrade to Google Apps Premier Edition to get sort of shared contacts. But these shared contacts had to be added by using the shared contacts API. And there is still no way to edit these shared contacts in the Google contact manager.
Our application takes a totally different approach: Once you create an address book you'll get two new groups in your contact manager. One group containing the shared contacts and the other group lets you mark existing contacts to be shared with other subscribers of the address book.
More information can be found here.
You can try out our free version with your Google account right now and you can contact us if you'd like do get the full version or a limited version hosted in your own Google apps domain.

Wednesday, July 22, 2009

Google Chrome OS

A while ago Google announced that they work on an OS called "Chrome OS". The basic idea of this new OS is to finally get rid of desktop applications and improve the capability of browser based applications to let them replace their desktop counterparts.
The hardest part when introducing a new OS is to convince users to try it even though there is almost no software available. On the other hand developers may not want to write software for an OS with few users.
To solve this "the chicken or the egg dilemma" Google chose a very clever approach with Chrome OS as you'll get tons of software right away when the OS is launching: All the software available on the web will be there when the OS is launching.

But what about all the limitations that you'll notice today in web based software?
Google is working hard on several projects to extend the boundaries of browser based software:

  • Performance
    Right now browser based software is a mixture of relatively slow JavaScript code and HTML/CSS based layout. Even though the JavaScript engines drastically improved especially in the last two years, native applications are many times faster still. Have a look at the Native Client project to see how Google enables web browsers to run assembler code on the client.
  • Improved user interface
    The WebKit team recently introduced CSS based animations and transformations, both in 2D and 3D (available on Mac only right now).
    Once this feature will be adopted by other browser vendors, this will not only blow away the flash based content. It will also simplify the development of rich user interfaces for browser based apps.
  • Access to local resources
    To make the applications available even when the computer is not online, there is another project that enables developers to access the local hardware in different ways: Google Gears. Gears is a browser plugin that is available not only for different browsers, but also for a number of different platforms including mobile OS.
    Gears lets you not only to store data locally, but also to create desktop shortcuts for browser based applications so that they become desktop applications.
  • 3D capabilities
    To enable game developers to build modern games for Chrome OS, Google recently also demoed the new O3D project. This project is a browser plugin that will provide hardware accelerated 3D graphics.
If you assemble these techniques you'll easily get the picture how Chrome OS will work and look like. It will be the first OS to run only web centric applications, but it will come with the projects above to enable developers to convert almost every application that is available as a desktop app right now into a web application. Of course some specialized applications like sequencers, DAW's etc. will remain, but it is my guess that it is just a matter of time until Google will offer interfaces for improved audio as well.
The big advantage that you'll get when developing software for Chrome OS is that this software will run not only on Chrome OS, but also on all other relevant platforms available today as the projects above are all multi-platform.

Monday, June 15, 2009

Google wave interim report

I have used waves for a while now and I've had fun implementing robots and gadgets - event though nobody ever appreciated my brilliant JDebuggy so far ;-)

Now it's time for an interim report.

I honor the hard work that all the wave developers spent so far to create this product. To build a browser based realtime application that handles concurrent changes of potentially thousands of users is far from being an easy task. I've worked on a realtime GWT based callcenter client in the last years with a limited number of users (<1000 concurrent callcenter agents) and it was quite difficult to build a robust and reliable browser based application.
You have to deal with the persistent connection limit in IE (that might be the reason why wave is not available for IE right now), have to assure that the application state will be restored when the browser crashes or when the user reloads the page and other problems alike.

Despite of being appreciative of the good work of the involved developers - I think wave has a long way to go until it turns into a useful tool. This is why:

Google wave claim to be a potential combination or even replacement for email, blogging, twitter-like instant messaging services, word processors, photo sharing apps etc.
But I've the strong feeling that these particular services are successful, because they target a very specific problem and deliver an extremely simple to use solution.
People like to use Twitter because they can simply start to type and publish with a single click. Flickr has a specific UI for sharing and tagging photos and provides an API that is focussed on accessing photos.
Blogger is cool, because its focus is on creating and editing posts and lets you easily modify the page layout using a simple template mechanism and css for styling without messing around with the posts.
Google docs is very nice, because you have the subset of word processing power that will satisfy the needs of 90% of the usecases and lets you import and export into lots of document formats.
I could go on with the list, but I think you already got the point.

In contrast to these applications Google wave is a more generic approach.
If you know me, you may already know that I'm not a big fan of generic approaches.
You'll find generic design approaches a lot in software projects where unexperienced software architects come up with a idea like this: "Hey, I've a brilliant new generic approach for our API. We can do everything we want in the future without changing the API by simple passing in a generic Map of objects and get back a Map of objects!"
Of course it is cool and very impressive to have just a single-method API that lets you do fairly everything, BUT: you'll wipe out all the improvements that have been made in software languages over the last decades like compile time type checks, strong typing etc.

But that's a totally different story. Let's get back to Google wave.
In wave you'll find tons of potential usecases - and this makes me suspicious because of the reasons described above. But let's do a reality check for the most important ones:


Email
Everyone uses email, because it is the 21 century replacement for letters. Even though you can abuse emails for simply sending documents or photos, it is generally used as the way to send longer private letters to single or multiple persons.

The content is important and so I personally like plain text email and I hate html emails as they'll cause a lot of trouble because the email client may screw it up.

What about wave?
Right now waves are always styled (equivalent to html emails) and even worse: You are encouraged to add so called gadgets to your text. These gadgets are living pieces of software that may use a lot of javascript.
If you use wave to write an email like letter, you may not be amused that all participants (=recipients) can change the email you've sent. If you'll have a look at your text some days later, you may not recognize it as it might be totally changed by someone else.
You have the chance to use the "playback" feature that let's you go through every single revision, but it is very hard to find the changes made and this playback feature is of course only available in the wave client. If you would access the wave in an arbitrary text editor without playback feature, you'd have no chance to see the documents history.
So you are tied to the wave client to access the mail.
Another problem is that you'll see all the changes that someone is making in realtime. So the private character of an email is totally gone. There is a planned "draft" feature to enable you to type first and send later, but I'm concerned about how this will work out when many people are allowed to edit the document at the same time.

But I don't want to be fussy. Here are my suggestions that need to be implemented to improve the email capabilities of wave. I've already posted some of these suggestions to the wave sandbox, but here we go again:
  • Permissions
    To keep the email feeling of being the owner of a document, wave needs to support a fine grained concept of access control. The permissions should directly modify the UI so that only the allowed actions will be accessible.
    You'll need the following permissions to be able to use wave as an email like application: 
    • READ 
    • EDIT 
    • STYLE_TEXT 
    • DELETE 
    • ADD_GADGET
    • REMOVE_GADGET
    • ADD_PARTICIPANT 
    • REMOVE_PARTICIPANT 
    • ADD_ROBOT 
    • REMOVE_ROBOT 
    • CREATE_BLIP 
    • DELETE_BLIP 
    • CHANGE_PERMISSIONS 
    • COPY_TO_NEW_WAVE 
    • PRIVATE_REPLY
    • CHANGE_TITLE
So if you'll use wave wave to write a plain text email to your best friend, you'll:
  1. Create a new wave
  2. Write the text (to write text before adding participants is the only way to avoid them to watch you while typing)
  3. Add your friend as participant
  4. Grant your friend the permissions to read and private reply. If you'll not grant the STYLE_TEXT permission, you friend should not be able to create a reply with styles text in it. As you'll not grant the EDIT permission your text will be untouched in the future.
Right now there are no such permissions in wave. And there is no way to add permissions on a participants level.
  • Templates
    Of course it would be unacceptable to keep the user in charge of going through all these steps just to write an email. In wave you'll also need a way to create wave templates that will automatically add certain permissions to the participants and add certain robots.
    An email template would automatically add the spell checking robot and would grant the proper permissions to every participant added.
  • Default permissions per contact
    Some contacts may have certain roles. So if you have a certain coworker to create shared documents, you automatically want to grant him the EDIT permission if he is being added to a wave. To find out if the permission per contact overweights the template permission set there needs to be a concept like GRANT, GRANT_ALWAYS, DENY, DENY_ALWAYS to calculate the resulting set of permissions per contact.
  
Word processor
When it comes to collaboration on a shared document this is one of the strengths of wave. You'll see the changes of the participants in realtime. It is not yet foreseeable how wave will relate to Google docs in long term.

There is currently no support for existing document formats and the text style capabilities are very limited. So right now it looks as if wave would end up somewhere in between docs and email.
Again here are some suggestions, how to improve wave to deliver a better user experience when it comes to document collaboration:
  • Improved playback history
    Right now it is very hard to follow the changes made to a wave. You are able to step through the document history, but it is difficult to find the changes made in each revision. This can be improved:
    IntelliJ, Eclipse and latest dev build of Chrome search have it: Colored indicators in the scrollbar to jump directly to certain positions in the document. This would be extremely useful in conjunction with the playback feature: Mark the modified positions of the document and let the user directly jump to these positions to be able to track changes made in each step.
  • Annotations
    Modified parts of the wave should be annotated. There are already proven ways to show annotations in OpenOffice and other office suits. A short-term improvement would be to display the author when hovering with the mouse over the text.
    Google docs offers a minimalistic but useful revision compare mode. If would be nice to have such a history view in wave to compare playback steps.
  • Create as new doc
    Instead of being able to create a fresh wave from an existing one it would be very cool to be able to create a Google doc from a wave. So you could start brainstorming in wave and finishing the document in Google doc and don't need to implement a full blown word processor in wave.
I'll try to post my suggestions to the other usecases, but that's it for now. Just found an interesting post addressing similar issues:
    http://jungleg.com/2009/06/04/googles-wave-doesnt-look-like-a-tsunami/

    Thursday, June 11, 2009

    floreysoft is back from Google I/O

    Yesterday we returned from our trip to San Francisco where we joined the Google I/O.
    As I'm suffering from Jetlag and woke up at 4 am I'll use the time where the world is still asleep to let you know what we are currently working on:

    Google wave
    We've been invited to join the so called "Google wave hackathon" at the Google office in Mountain View. The Google folks explained the new product and the API that developers can use to extend it.
    The people at the hackathon received the first accounts on the developer preview of Google wave to play around with the API.
    You can create some server side extensions (robots) and client side gadgets to add additional features.
    After some experiments I figured out that it might be very useful to be able to create and test robots in the local eclipse environment instead of uploading the robot code to appengine to test the code. Also it was a little bit 80's like to not being able to debug the code right in eclipse.
    Instead of complaining I've spent some hours in the hotel room and hacked on a debugging framework and finally got it working!
    To develop and debug robots in your local environment you have to download this tiny jar file containing the local debugging proxy server.
    You can specify a unique name for your robot when launching the jar:

    java -jar wave-debugger.jar myfancyrobot

    Now you can create a new wave and simply add the JDebuggy robot (jdebuggy@appspot.com) to it. This robot will add a gadget where you have to enter the same unique name to start debugging. There is a tab where you can specify exactly which events should be forwarded to you local environment. If you enable the DOCUMENT_CHANGED event you'll get events for each key you are typing so this will cause a lot of traffic and makes debugging quite hard.
    You can change the settings and start and stop debugging by using the gadget and you can test your robot by using the wave as all events will be forwarded to your local environment.
    If you are interested in the technical details of the implementation I'll try to explain it in a few words:
    It has been a little bit tricky to get everything in place as I had to fight with several restrictions:

    • If you create a robot by extending the AbstractRobotServlet the servlet input stream will be consumed by this servlet and is not accessible later on to forward it to the robot that should be debugged. So I had to create a copy of the input and output streams to be able to read it twice and send back the data of either the JDebuggy robot or the robot to be debugged. This sounds easy but the I had to write some mockup classes to fake the ServletRequest etc. 
    • The basic idea was to call your local servlet on your machine to trigger the robot servlet right in the eclipse environment. But your local machine is most likely not visible and reachable from the net as you may be behind a router with dynamic NAT. So I had to find a way to create the connection from your machine to a server. This could be done by polling for new events but this would make it very hard to simulate synchronous communication with the wave server. So I chose creating a open socket connection between your local machine and the server.
    • Unfortunately and for good reason Google appengine will not tolerate to create threads, sockets etc. So I had to find another way to let you establish a socket connection between the two endpoints. I've created a debug proxy server on our floreysoft root server and forwarded all requests and responses from app engine to it after debugging starts. So I now could use all the dirty tricks to get it to work (server sockets, threads etc.).
    So when you start the local wave-debugger.jar you'll establish a connection to the floreysoft debug proxy server and register with the unique robot id. JDebuggy will then consume the wave requests, evaluate them and eventually forward it to the floreysoft proxy adding the unique robot name to the request.
    The floreysoft proxy will distribute the incoming requests to the proper socket to be able to debug many robots at the same time.