PHProjekt V6 kicks out of the door on March 18th


PHProjekt V6, our little beastbee and Open Source project management software, kicks out of the door on March 18th as GA. It’s a complete rewrite (and thus, a major version update was needed) with Zend Framework and dojo and now licensed under LGPL (earlier versions were licensed under GPL). You may ask what you want to do until March 18th? Well, besides eating popcorn for Film@11:

 

 

The bee is watching you!

A comet over PHProjekt 6

So far PHProjekt 6 (P6, see http://phprojekt.com) is already enhanced with nice AJAX workflows and snappy user-experience. Nevertheless, we discussed a way to provide synchronous communication and direct information within the application.

Everybody knows GoogleMail with its easy to use frontend. Maybe you use it for your daily work. In GoogleMail, there is no need to refresh the page to receive a new mail, Google informs you automatically whenever a new mail is available. But how is this possible? The answer to this question is really simple: The server triggers a signal informing that a new mail is available. This technology is called Comet and describes a way how the server communicates with the client [see http://en.wikipedia.org/wiki/Comet_(programming) ].

Is there a way to use Comet for P6? As P6 works with a lot of users, it is important for me as a user to be informed when somebody has changed something in my projects or has added an urgent todo. The list where a notification could be triggered is long, but at the moment, only email notifications are sent immediately. So, what we need in P6 are real-time notifications. With real-time notifications, for example, every time somebody changes something in my project, I receive a message in form of a highlighted info box. This looks like a typical use case for using Comet. And yes, Comet would be great for realizing this kind of real-time notification! But since the users love the handy system requirements (Apache Server and MySQL) and the ease of installation, something different is needed than a real Comet architecture, because all the Comet magic is based on a so called application server, e.g. Jetty, Persevere. Therefore, I decide to implement another (Comet-) technology, called Long Polling. You can find the name AJAX Polling for this technology, too.

The technology behind Long Polling is to open a connection from the client to the server and not to close this connection immediately. Ok, that´s fine, but how to open a connection and „hold“ it? Opening a connection to the server is easy, a simple AJAX will do the trick. P6 uses the Dojo Toolkit for all its AJAX, so in this case I used the Dojo.xhrPost.

dojo.xhrPost({
  url: myUrl,
  error: function(error, handle) {
    handleError(myUrl, error);
  },
  load: function(response) {
    if (false != response.data) {
    showToaster(response.data);
  }
},
  handleAs: 'json'
});

 

Since the HTTP protocoll is connection-based, at the server-side, a process is also needed that holds the connection and does not return . So, what I do to hold this connection open is to set a simple timeout during the execution of the server-side script, in my case I use sleep(). This is the basic idea of long polling, but the gimmick of this approach is to return earlier if something happens on the server-side. In other words, I open a connection to the server and check whether there are any changes, if not, the connection stays open for the maximum polling time. If yes, the response will be returned to the client immediately.

This diagram shows the basic workflow, and the lines below show the possible solution in PHP:

$counter = 0;
$maxLoops = 4;
$data = array();

while ($counter != $maxLoops) {
  $counter++;
  $data = $this->getMessage($userId); // get data from database
  if (false === empty($data)) {
    return $data; // there is something new, return immediately
  }
  sleep(5); // nothing is new, sleep for 5 sec.
}

return $data; // return the empty array

 

For P6 this means that I always save the following: the person who triggers an event, the event itself (e.g. somebody adds a new note), the item, the project, the creation time, the time until this message is valid, and the persons who should receive a frontend message from the database. The long polling loop checks whether there is anything new. If yes, it returns the data. If not, the polling loop starts again. Every event is saved in the database for a maximum of two minutes, except events in the future. Itis real-time – so itis possible to miss a message ;-)

One word about the Dojo Toolkit. The AJAX API of Dojo provides several functions to communicate with the server. The easiest way is to use dojo.xhrGet or dojo.xhrPost. I decided to use the Post version. Although the function has a property setTimeout, which allows you to set the time to wait for a response from the server, this is not needed, because of the sleep loops at the server side.

Now, let’s look at the downsides of the long polling approach. Yes, I partly agree with everybody who says that the permanent polling to the server causes massive traffic and server load, especially with an increasing number of users. But in the special case of P6 this is OK, because the number of users is manageable and in most cases, P6 runs in a local network. In addition, the frontend messages are configurable, You can set the polling loop and the number of requests to the database.

Considering all the facts and keeping in mind that P6 is designed to be a lightweight open source groupware, I am positive to say that the Long Polling technology is the right choice for P6.

Dojo Toolkit Workshop, Mai 2009

Anfang Mai luden Uxebu und SitePen zu einem Dojo Toolkit-Workshop, genauer gesagt „Intro to Dojo, Charts, Grids, and Comet“, nach Oberhaching bei München. Mayflower war mit schätzugsweise einem guten Drittel aller Workshop-Teilnehmer zahlreich vertreten.

Dylan Schiemann von SitePen, Inc. und Nikolai Onken von Uxebu führten durch das Programm, außerdem konnten die Teilnehmer bei Fragen auf das Wissen und Erfahrung von Wolfram Kriesing (Uxebu), Tobias von Klipstein (Uxebu) und Peter Higgins (Dojo Toolkit) zurückgreifen.

Nachdem das Programm im Laufe der Zeit auf einen Tag reduziert worden war, änderte sich auch das Grundkonzept der Veranstaltung. Diese sollte nun die Benutzung von einigen ausgewählten Widgets zeigen, wobei sich die Auswahl an der Anwendung Stocker orientierte.
http://persevere.sitepen.com/stocker.html

Das Backend (Persevere/CometD-basiert) wurde von Sitepen bereitgestellt. Nähere Details zum Backend bzw. zur Anwedung selbst können hier in Erfahrung gebracht werden:
http://www.sitepen.com/blog/2009/04/01/stocker-advanced-dojo-made-easy/

Die behandelten Widgets waren u.a.:
dijit.layout.BorderContainer
dijit.layout.ContentPane

dojox.grid.DataGrid (mit Anbindung an einen JSON-Store über dojo.data.ItemFileReadStore)
dojox.charting.Chart2D

Aufgrund des engen Zeitrahmens wurde auf den Dojo Parser sowie die CSS-Struktur nur insofern eingangen, als dass man sich die entsprechenden Includes kopieren/abschreiben konnte, mit der man eine Umgebung zum Ausprobieren hatte. Auch wurde nahezu ausschließlich nur das „deklarative“ Dojo-Programmierungsmodel gezeigt, sprich die Widgets wurden über Markup platziert und initialisiert, nicht programmatisch.
http://dojocampus.org/content/2009/04/15/declarative-vs-programatic/
Andererseits ist es wohl genau der Weg, den jemand beim ersten Blick auf Dojo zuallererst einschlagen würde.

Der Ablauf jedes Agenda-Teilschrittes (im Falle der Widgets) war wie folgt:

  • Vorstellung des Widgets inkl. Beispielcode
  • 15-30 Minuten Zeit, in der die Teilnehmer das zuvor Gezeigte selber ausprobieren konnte. In dieser Zeit begutachteten die Tutoren immer wieder den Fortschritt bzw. standen für Fragen zur Verfügung

Natürlich bestand die Agenda nicht nur aus Widgets – diese wurden immer wieder mit anderen Programmpunkten aufgelockert – sei es durch Interessantes von Dylan (ob Geschichte des Dojo Toolkits oder kurze Erklärung von Polling und Comet), ganz banal Mittagessen oder (am Ende) Peters beeindruckende Einblicke in plugd (Erweiterung der Dojo-Basisbibliothek).

Trotz der Ausrichtung auf Anfänger, gab es auch zwischendurch kleinere Tipps, die man auch als erfahrener Dojo-Anwender nicht unbedingt gekannt hatte, z.B.:
Weiterlesen

DOJO.WINE

On March 28th we had the honor to host another dojo event – the dojo.wine().

With the experience from the last dojo.beer in our office in Munich we expected some 20 attendees, but when the event started I counted the incredible amount of 37 people!

Now our conference room is kind of small and I still can’t remember where I got all the chairs from, but we got all people stuffed in there :-)

Maybe one reason for this many attendees is that Würzburg is located in the middle of Germany, which can be proved by the fact that people came from all over the country. Moreover, we had four persons coming up the way from Italy!

After tasting some real good Franconian red wine and some typical cold cuts we started gathering the topics and held the following talks:

  • Introduction to Dojo (Nikolai Onken, uxebu)
  • Dojo data (Tobias von Klipstein, uxebu)
  • Tapestryfly (Andrea Chiumenti (kiuma), wingstech)
  • Video Conference with Pete Higgins (Dojo Project Lead) and Dylan Schiemann (co-founder of Dojo and SitePen)
  • Javascript in High Traffic Environments (Sebastian Schürmann, Chip Xonio Online)
  • Dojo Docs (Tobias von Klipstein & Wolfram Kriesing, uxebu)
  • Dojo Build (Tobias von Klipstein, uxebu)

The slides can be found on the bottom of http://dojo.beer.mixxt.de/networks/wiki/index.dojo_wine1.

So thanks to all the folks who attended that event! Maybe we will meet again on the dojo.beer() in Munich on May 9th!

dojo.wine() at Mayflower Office Würzburg

Again we are pleased to host a dojo event – this time in our office in Würzburg. According to Würzburg having lots of vinyards all over the hills we called this event „dojo.wine()“ :-)

The event is organized by Uxebu and PHPUG Würzburg and will start on March, 28th, 12:00 in our office in the Pleichertorstraße 2 in 97070 Würzburg.

If you want to join either visit http://dojo.beer.mixxt.de/networks/events/show_event.4156, send a mail to jason.easter {at} mayflower.de or drop a comment to this blog posting.

PHProjekt 6 Developer Preview edition

Today the PHProjekt core team is glad to publish a first edition of PHProjekt 6, the ‚developer preview release‘. More than one year has passed since the first commit into the SVN. In our view, the most important feature of the new version is the state-of-the-art architecture, which  makes a huge difference to all previous versions of PHProjekt.

With the choice of Zend framework in the backend and a complete integration of the dojo toolkit for the frontend, we think that the application is now ready for complex requirements and workflow processes. The MVC and active record pattern support scaffolding, thus allowing an effective and rapid development for new modules and features – in fact, new modules can be built with some mouse clicks.

Furthermore we tried to provide you a software, which makes fun to develop own code.
PHProjekt 6:
– is completely php5-OOP, well structured
– follows php5 coding standards (actually zf coding style)
– has a pretty good code coverage with unit tests
– is completely documented in phpdoc
By following ‚convention over configuration‘, many modules and services show an expected default behaviour. The API and protocol (JSON) between frontend and backend allows a change of single components of the application.

For other webmasters without coding skills, we tried to facilitate the application management with a WYSIWYG module designer.
Last but not least, we changed the licence from GPL to LGPL to give you more flexibility for the distribution of your own modules and extensions.

Lots of changes have been made over the past months by the developer team so we are really looking forward to get feedback from the community.
You can download the developer preview release here. We reopened the phprojekt repository on sourceforge, so you can checkout the source code from SVN there.
On phprojekt.com, we created a new section for PHProjekt 6, which we will fill with content in the next weeks. You can leave general remarks as a comment on this blog entry. For questions and discussions, we installed an own developer mailing list, please subscribe here. Anyone of you who want to inspect it directly, we have a setup a sandbox.
Please keep in mind, that it is only a preview, which means that something weird can frequently happen :-)
Please post your opinion, report bugs or send patches, everyone is welcome. We need you, the people who use it, your testing and reports, and your patches.

We wish you merry christmas … sorry: a lot of fun with the preview of PHProjekt 6!
the PHProjekt development team

Minimizing your JavaScript Code

As
my last projects were mostly web 2.0 online applications I had to do
a lot of javascript programming. Using JS-Frameworks like JQuery or
Dojo the size of all necessary javascript files had added up to more
than one megabyte. Even today with highspeed internet connections one
megabyte needs several seconds to be transferred, so I had to find a
way to reduce the size of the code. For all my previous projects I
used
Dean
Edwards Packer
. This amazing packer was able
to reduce it to appr. a fourth of the original size. Getting this
nice result I was wondering if the tool delivered with Dojo – the
Dojo
Shrinksafe
– or other minification tools
like
JSMin
and the
YUI
Compressor
could do this as well. After some
tests, however, I realized that they couldn’t.

Searching
the web for more information about the best way I found a cool tool /
website that shows the transfer sizes of well known javascript
libraries after minification / packing. It is also possible to let
the tool calculate the results for your own piece of code:
http://compressorrater.thruhere.net/

In
addition, the tool also calculates the size of a transfer with
http-compression (gzip). Before I found this website I did not see
the size after minification / packing and compression in combination.
Perhaps I should have done this before…

Analyzing
the results of CompressorRater it seems that Dean Edwards Packer
might really be the best choice – even with zip compression. Very
interesting is the fact that the results of packing and minification
is nearly the same after zip compression.

Yet
the size of javascript files and their transfer speed is only one
aspect which affects the loading delay of websites. The other aspect
is the time the browser needs to interpret those scripts. As packed
files have to be interpreted twice – first to eliminate the eval
and second to interpret the generated code – their loading delay is
higher than those of minified files.

After
taking a closer look at the loading time of those minimized
javascript files it turned out that the Packer is not always
the best choice: In case of bigger javascript files, the Packer
needs up to several seconds to d’eval the code. This doesn’t matter
so much in web applications where javascript is only loaded and
interpreted once at the beginning but it will slow down a typical
website even more because javascript has to be interpreted at each
site request, even if it is in the browser’s cache. Using a minified
script avoids this.

Summarizing
I suggest to use Packer only if it is not possible to realize an
http-compression.

SitePen’s Dojo Toolbox

Eine API-Referenz auf dem Desktop – das kennt man.
Primitives HTML. Manchmal gepresst in eine CHM-Datei. (Compiled HTML Help).

Getoppt wird dieser klassische Ansatz von Desktop-Referenzen jedoch durch eine
Webapplikation, welche mittels Adobe AIR direkt auf den Desktop gebracht wurde.

Es handelt sich dabei um ein durchaus nützliches Tool, das Dojo-Entwicklern
das Leben leichter machen soll: SitePen’s Dojo Toolbox.

Sie vereint Dojo API-Referenz, Dojo Release-Builder und KnowHow-Linkliste in einem und
kann einem Webentwickler auch in ihrer frühen Version 1.0.1 schon durchaus
einiges "Gegoogle" ersparen ;-)

-> SitePen’s Dojo Toolbox