p@rdus

A sneak peek of the new Horde 5 user interface

noreply@blogger.com (Gunnar Wrobel) — Fri, 11 May 2012 12:38:00 +0000

To get an idea on how Horde 5 will look like: click the link or the image of this post.

Why does Horde 5 get a face lift? Simply because the current UI was mentioned often enough as an issue by many Horde users. And since the Horde 4 release had a very technical focus the switch from Horde 3 to Horde 4 last year did not help - it even degraded consistency between the applications. At the same time the competition does not sleep and there are more and more large installations that offer their user base two different webmails - one of them being Horde for the power users that feel they need a lot of features but that care less about the UI. Time to get our act together.

So what is the primary target of the redesign? First and foremost we want to unify the main user interfaces. At the moment we have the static application views, the dynamic webmailer, and the dynamic calender as the core parts. All looked somewhat different. These are the elements that we wish to give a consistent look. The special views such as the minimal webmailer or the smartphone UI will remain untouched.

We also hope the new design looks somewhat fresher than what we had before but please keep in mind that we are oriented towards people that use the interface for their daily work. We do not aim for a UI that looks like the last hype. It should be functional instead.

The Horde LLC has been the driving factor behind the redesign. At least financially. A subset of the Horde core developers started the LLC a while back as a contact point for people that want to pay for Horde support or feature development. A part of the money that such contracts pay goes to the developers dealing with the particular customer request. But another part of the money remains within the LLC. The idea is to use the latter to drive features that we consider to be important for Horde and its community. The redesign is the first project that has been financed this way. The Horde team tried finding designers interested in contributing to an Open Source project several times before. This was unsuccessful however and paying a designer for the work remained the only reasonable alternative.

We contracted No agency for the design. After several rounds of communication between them and all Horde developers we managed to end up with the draft displayed above. This has been converted to HTML and CSS this week and will be hammered into code during the next week by Jan Schneider. We do hope to present you with an alpha of Horde 5 - including the draft of the new design - on the 22nd May of 2012.

Feedback and comments - as usual - are welcome!

Horde becomes biggest KDE sponsor!

noreply@blogger.com (Gunnar Wrobel) — Thu, 08 Mar 2012 07:45:00 +0000

Here at CeBIT we support our friendly neighbor project with a constant and vital support of gummy bears. As anyone knows these sweet animals can make the difference between one line of brilliant code and a dreadful spaghetti mess. Thus it is probably hard to deny that this fruitful collaboration turned Horde into one of the biggest KDE sponsors.

That being said: KDE, I'm already here, breakfast is ready ;)

Beside having fun in the open source area the second day was already packed with people here at CeBIT. We had plenty of Horde users which provided kind feedback. Some of them we could surprise with features they didn't know about. Others were happy to hear that "GPL" really means that they can use the software and modify it without being harassed with a lawsuit afterwards.

We had Horde newbies as well as free software newbies. Explaining how free software can result in a revenue was the easy part. Explaining why we have no strong interest in a product for obfuscating our code so that there is a decent protection against people trying to find security holes was ... sigh ... harder.

The most fascinating thing was a company that installed Horde and wants to run it from -25°C to 65°C - like putting Horde to the extreme. There were other extremes involved and I omit the details but it is always fascinating what people do with free software.

First day on CeBIT

noreply@blogger.com (Gunnar Wrobel) — Wed, 07 Mar 2012 08:06:00 +0000

Wonderful start at CeBIT yesterday. Meeting people with an interest in Horde face-to-face is a refreshing alternative to the work behind the screen at home or at work. The positive feedback helps tremendously in building up energy.

The most important part yesterday was talking to well known contacts, chatting about the progress of some projects which will hopefully result in a few interesting feature additions to Horde during this year.

I also visited ownCloud at their Univention booth to chat a bit about integrating the tool with a webmailer.

And last but not least it is always fun seeing Jan in person. Nothing against having a "distributed" type of project with people scattered in Germany and US. But it would be so much fun having all of you guys here. Can't really wait for the next hackathon ;)

Recap of the verification that there was no backdoor in the Horde 4 packages

noreply@blogger.com (Gunnar Wrobel) — Wed, 22 Feb 2012 22:21:00 +0000

When we discovered the successful attack on ftp.horde.org two weeks ago we were of course frantic to determine which packages had been affected in addition to the one Horde 3 archive Jan identified as modified initially.

For the Horde 4 packages we had no hashes to verify the file integrity though. While PEAR supports signing of packages via GPG that seems to be a feature which is virtually unused. For one thing not that many PHP based projects use PEAR packaging and in addition there is no way to automatically verify package integrity on the user side when installing via PEAR. So we also didn't consider signing our packages when switching to installing Horde via PEAR.

Obviously you gain a different perspective on that issue once a hacker implanted a backdoor in some of your packages. Of course we invested a lot of time into securing our infrastructure now to ensure that such an event never happens again. On our side the file integrity is constantly monitored now. But we will also have to investigate how we can improve the PEAR based installation procedure so that it also allows for the required amount of security on the user side.

But if we had no hashes how did we ensure the Horde 4 packages were indeed unmodified? Git to the rescue! As we tag all our releases it was a matter of creating a short script to automatically compare the current state of the packages on our PEAR server against the state we had within git.

Without further ado - here is the script I used:

#!/bin/bash

git reset --hard HEAD
git clean -f -d

STAMP=`date +%y%m%d-%H%M`
mkdir ../diffs-$STAMP
mkdir -p ../validate-$STAMP/pear.horde.org
mkdir -p ../validate-$STAMP/rebuild

for package in `cat ../pear-recovery-packages.txt | grep -v ".tar$"`
do
  TAG=${package/.tgz/}
  TAG=${TAG,,}
  PPATH=${package/-*/}
  if [ "x${PPATH/Horde_*/}" == "x" ]; then
      PPATH=framework/${PPATH/Horde_};
  fi
  if [ "x${PPATH/groupware*/}" == "x" ]; then
      PPATH=bundles/$PPATH;
  fi
  if [ "x${PPATH/webmail*/}" == "x" ]; then
      PPATH=bundles/$PPATH;
  fi
  PRESENT=`git tag -l $TAG`
  if [ "x$PRESENT" == "x" ]; then
      echo
      echo "======================================================================"
      echo "Tag $TAG for package $package is missing!"
      echo "======================================================================"
      echo
      echo "$package: TAG MISSING" >> ../status-$STAMP
  else
      rm *.tgz                                                                                                               
      rm -rf ../validate-$STAMP/pear.horde.org/*
      rm -rf ../validate-$STAMP/rebuild/*
      GIT=`git checkout $TAG`
      horde-components -z $PPATH --keep-version
      if [ -e $package ]; then
          cp *.tgz ../validate-$STAMP/pear.horde.org/
          cp ../pear.horde.org/get/$package ../validate-$STAMP/rebuild/
          tar -C ../validate-$STAMP/pear.horde.org/ -x -z -f ../validate-$STAMP/pear.horde.org/*.tgz
          tar -C ../validate-$STAMP/rebuild/ -x -z -f ../validate-$STAMP/rebuild/*.tgz
          DIFF=`diff -Naur ../validate-$STAMP/pear.horde.org/${package/.tgz/} ../validate-$STAMP/rebuild/${package/.tgz/}`
          if [ "x$DIFF" != "x" ]; then
              echo
              echo "======================================================================"
              echo "Diff for package $package detected!"
              diff -Naur ../validate-$STAMP/pear.horde.org/${package/.tgz/} ../validate-$STAMP/rebuild/${package/.tgz/} > ..$
              echo "======================================================================"
              echo
              echo "$package: DIFF" >> ../status-$STAMP
          else
              echo
              echo "======================================================================"
              echo "$package CLEAN!!!"
              echo "======================================================================"
              echo
              echo "$package: CLEAN" >> ../status-$STAMP
          fi
      else
          echo
          echo "======================================================================"
          echo "Failed rebuilding package $package!"
          echo "======================================================================"
          echo
          echo "$package: FAILED REBUILDING" >> ../status-$STAMP
      fi
  fi
done

The script walks through the list of packages we had on the PEAR
server, moves back in time within our git repository to the
appropriate tag, rebundles the package, extracts both the old and the
new package and compares them using diff.

The resulting status list looked quite okay. There were a few release glitches where the tag was not on the exact commit that was used for building the package. In that case usually a small diff resulted. The list was rechecked manually for any malicious traces - Horde_Imap_Client-1.4.3 was the only one were the diff was large but that turned out to be a result from a mishap while releasing that package version. A few times the diff led to a problem with rebuilding the package (indicated by "FAILED REBUILDING"). The package.xml was broken in those cases and needed a fix that was only committed after the tagging. Here I compared the git state directly against the extracted package. There was only a single case ("Horde_ActiveSync-1.1.11") where the tag was missing which required manually identifying the corresponding commit to verify that state against the old package contents.

Once the script was established the analysis ran for about two hours after which we were at least somewhat relieved. Having a backdoor in some Horde 3 packages was already bad enough - having that in Horde 4 would have been even more disastrous.

Horde on CeBIT 2012

noreply@blogger.com (Gunnar Wrobel) — Thu, 02 Feb 2012 22:31:00 +0000

It is official now: Horde gets a booth on CeBIT 2012! Sponsored by Linux New Media the company behind the Linux Magazine. Thanks! Simply awesome!

Hope to see you there!

Wiki time

noreply@blogger.com (Gunnar Wrobel) — Wed, 01 Feb 2012 00:11:00 +0000

Tonight it has been wiki time. The article on IMP from the English wikipedia was a mere stub and I expanded it with a little bit of history. I will hopefully find the time to continue this later. I recently did the same for the Horde article.

In addition I updated the list of Horde deployments in our Horde wiki. I also added a list of Horde hosting providers and a list of alternate installation methods for Horde. I couldn't refrain from adding a short abstract on why we only offer PEAR with Horde 4 to the latter article.

Of course corrections and additions are very welcome!

Horde is calling you

noreply@blogger.com (Gunnar Wrobel) — Mon, 30 Jan 2012 22:59:00 +0000

Yes, it's late... and I should either sleep or try to work for a final hour before collapsing onto a pillow. But instead I feel like writing a few lines. And calling strangers in the US...

I don't know the people I call there. But it is fun, I train my english, and on top they are usually happy about my call.

What we talk about? I explain them what a provider is. And why I'm actually unable to help them. Which maybe helpful information in its own right.

Of course these people called the Horde LLC before. The Horde webmail is running on so many servers around the world that we get a constant stream of requests for help from users that mistake Horde for their service provider. Usually we get a handful of e-mails every day asking whether we could reset the password, restart the server, or in general just "HELP!!!". Once in a week the line

I can't log in. My username is ABC, my password is XYZ.

reminds us how easy phishing is.

E-Mails are simple: sending out a friendly response with a link to one of our most successful wiki pages is an easy thing to do.

Phone calls are a different matter though. The phone number for calling us in the US has been set up by MojoLingo based on Adhearsion a while back. And of course we get a certain number of "I can't get my mail!" calls as well. We usually didn't answer these until MojoLingo helped us with setting up Voip access so that calls into the US generate negligible costs.

So I can sit here, run SipDroid on my little droid and call into US when I need a break or have a minute to spare. A few more pleas for help that do not get lost unanswered.

In case you ever get called by a stranger with a weird German accent after your Horde webmail broke you probably didn't read this blog post.

The Horde release train

noreply@blogger.com (Gunnar Wrobel) — Tue, 13 Dec 2011 22:19:00 +0000

The Horde project did push out 906 releases in the last 8 months since the initial Horde 4 release. PEAR packages, better release management tools and continuous integration seem to pay off. The stream of bug fixes and improvements available to the users has switched to high speed.

At the same the time the use of PEAR packages and automatic DB migrations has lowered the effort of updates on the administrator side to an absolute minimum.

pear upgrade -c horde

And few clicks later you are up-to-date.

The code quality of the basic PEAR tools is an entirely different matter... BUT it is just soo damn cool anyway ;)

Accessing PEAR server information with PHP

noreply@blogger.com (Gunnar Wrobel) — Sun, 13 Nov 2011 21:21:00 +0000

The number of PEAR servers has increased dramatically in recent times. Maybe due to the availability of Pirum - a simple PEAR server. Whatever the cause: there are plenty of package lists and package datasets available on the net these days. Accessing this data is not always easy though.

PEAR servers provide a well defined REST API that is usually queried using the PEAR toolset available via the basic PEAR package. That package however does not provide anything that I would consider to be a decent developers API.

So let me provide you with an alternative that is available via the Horde framework libraries: The Horde_Pear library.

The package comes with the Horde_Pear_Remote class wich provides you with high-level access to the REST interface of a PEAR server.

Creating an instance of this class without providing any arguments to the constructor will allow you to access the PEAR server at pear.horde.org.

$pear = new Horde_Pear_Remote();
print(join("\n", $pear->listPackages()));

Horde_ActiveSync
Horde_Alarm
Horde_Argv
Horde_Auth
Horde_Autoloader
...

Alternative servers can be specified in the first argument to the constructor:

$pear = new Horde_Pear_Remote('pear.phpunit.de');
print(join("\n", $pear->listPackages()));

DbUnit
File_Iterator
Object_Freezer
PHPUnit
...

The full set of the functionality provided by Horde_Pear_Remote is detailed on our website.

The library section of the Horde website supports component documentation now.

noreply@blogger.com (Gunnar Wrobel) — Fri, 04 Nov 2011 11:56:00 +0000

Our new libraries section has been started a while ago to further push the PHP components we offer. Now this section supports publishing the component documentation as well. You can take a look at the documentation of the Cli_Modular package for example. In fact: it is pretty much the only package that fully uses the new system already. So there is still work ahead.

If you use any of the components: We are grateful if you start writing a bit of documenation or describe some examples on how to successfully use the package. It will help us and others tremendously. Thanks!

Let me try to explain how the system is currently intended to work - feedback and critical comments of course welcome:

When creating new documentation for one of the Horde components you start a new section on the developer documentation of our wiki. See the Horde_Cli_Modular link below Library components for example. Please note: It is not mandatory to write the documentation in the wiki. You can have static documentation files within a component as well. This is just meant as an option for those situations where it makes sense to work on documentation files together with people that do not have direct git commit access. Hopefully there will be many component consumers interested in updating and fixing the documentation.
How you structure that new section is up to you. For a simple package you might wish to keep all documentation in a single file but for the more complex one it might make sense to have several files. In that case the new section page should probably just be a link list to the various wiki pages that document the component. In case of Horde_Cli_Modular I used a single page.
Once the documentation has been written in the wiki format it is time to download it into the doc directory of the component. The horde-components helper is what you should use for that operation. The tool expects to find a DOCS_ORIGIN file within the doc or docs (for the applications) directory of the component. This file must conform to the reStructuredText format and map remote URLs to local file paths relative to the component root. The DOCS_ORIGIN from Cli_Modular links the wiki page exported as reStructuredText to the path doc/Horde/Cli/Modular/README. The links can of course point anywhere so you are in principle free to use any remote source. But you should ensure the page provides readable reStructuredText.
Now you can run horde-components fetchdocs and it should fetch the URLs into the respective local files. You can then run horde-components update to refresh the file list in the package.xml file if the documentation files were not included before.
Once a component was released we can now run something like this: horde-components Horde_Cli_Modular webdocs -D ~/git/horde-web/ --html-generator=git/horde-support/maintainer-tools/docutils/html.py --allow-remote in order to update the documentation on the website. Right now this does not happen automatically during a release but I plan to add this soon.

There are of course still a few problems with this approach:

The reStructuredText exporter of our wiki engine "Wicked" is not yet complete. You may experience problems with the export if you use constructs it does not know yet. Please ping me if you experience problems with the export.
The wiki syntax and the syntax required by reStructuredText is not 100% aligned. You can write a wiki page that looks just fine but leads to errors or formatting problems in the reStructuredText export. After creating / updating a new wiki documentation page it make sense to run the horde-components fetchdocs/horde-components webdocs sequence to check for problems.
We still have some components with documentation files not in reStructuredText format. These will result in non-existing links on our website for now but I plan to fix the few faulty packages soon.

Jenkins on ci.horde.org got a major update

noreply@blogger.com (Gunnar Wrobel) — Fri, 04 Nov 2011 09:17:00 +0000

The Horde continuous integration setup saw a major upgrade and a number of fixes during the last week.

The take home message for everyone that does not wish to read the full log: ci.horde.org will now run horde/framework/bin/test_framework after a new commit has been pushed. This reduces the load on the system significantly and you will get results faster. If you develop Horde code you should run horde/framework/bin/test_framework as well in order to check if your recent commits could cause failures on our continuous integration server.

The full recap of the recent changes:

Update to the newest version of the Horde components tool. This allows to use the improved templating system.
New configuration and build templates that allow to reduce the job build time by avoiding to rebuild the set of package dependencies if this is not necessary. This has an important implication: A code change in one package (e.g. Horde_Imap_Client) will be tested against unchanged dependencies (e.g. Horde_Mime). Even if the commit also touched one or several of the dependencies (e.g. Horde_Mime). The packages should be backward compatible - so this should result in no error. The dependencies of one package will only get updated in case the dependency list in the package.xml of that package changes.
Running horde/framework/bin/test_framework has been integrated into the horde-git job. With the new "rebuild dependencies only when necessary" policy (see above) the component jobs do not fully test the integrity of the latest commit anymore. When the dependencies do not get updated the focus of shifts a bit more towards checking for backward compatibility. In order to not loose the integrity check for the "bleeding edge" our test_framework script is now executed right after updating the code from git.
Running test_framework also allows to run component jobs only if the code of the component has actually been touched. This significantly reduces the load on ci.horde.org as it removes the need for rebuilding all components for each and every commit.
An update to the newer CodeSniffer which included an update to the checklist for the Horde style. The new ruleset is available from our horde-support repository.
A customizable ruleset for the PHP mess detector has been added as well. We still need to tweak the exact configuration of PMD to match it with what we consider reasonable defaults for Horde code.
DocBlox has been added to allow generating experimental API documentation. DocBlox is significantly faster and less memory hungry than PHPDocumentor. It has already been adopted by large frameworks such as Zend. So I figured it is worth taking a look at it. Feedback welcome!
The Jenkins configuration has been updated with the latest fixes and improvements from the Jenkins-PHP project.
The setup procedure has been fixed so that it should be possible to generate a local setup - comparable to ci.horde.org - again.

demo.horde.org got updated

noreply@blogger.com (Gunnar Wrobel) — Tue, 18 Oct 2011 06:33:00 +0000

You might have noticed that the Horde homepage received a new Demo button within the main navigation recently. We did indeed manage to get a demo machine up and running at demo.horde.org. The installation got updated to the latest releases just yesterday and Ansel - the Horde photo management application - got added into the mix. Feel free to test drive this new application as well as the other components on demo.horde.org.

If you experience any problems please let us know.

In principle you shouldn't be able to break anything on the installation. It is a virtual EC2 machine and we will update the image every once in a while when there are new releases available. Any data you store on the machine will be resetted at that point.

You should also be able to mail to the two demo users demo@demo.horde.org and guest@demo.horde.org. Mailing to the outside is not possible - for obvious reasons.

Horde_Push now supports sending to Blogger.com

noreply@blogger.com (Gunnar Wrobel) — Fri, 14 Oct 2011 07:42:00 +0000

Horde_Push supports sending to blogger.com now.

The Horde_Push library is a tool to send content elements to various external services. Such as Twitter, Facebook, Blogger and others. Right now it only all
ows sending Tweets, publishing entries on blogger.com and sending e-mails.

The idea is to allow publishing content you curate on a Horde installation to the social networks out there. At the moment the code is not yet there as the
integration into the base horde package is still lacking. Right now there is only a small command line helper that I use for testing.

Anatomy of a Horde test suite - III

noreply@blogger.com (Gunnar Wrobel) — Mon, 20 Jun 2011 22:35:00 +0000

Ready for the next item on the test suite agenda? This time the topic is Autoloading. We use a rather simple autoloading setup for most component test suites. It requires no additional setup and works out of the box if you run php AllTests.php.

That is already nice and allows running the complete test suite without further ado. But I must admit that I want more. My default work mode looks like this:

open test case (and modify it)
hit <f3> <f8> to run phpunit on this single test case
hit <f4> <f4> to to jump to the code line that produced the first error

This allows me to add a new test definition and immediately run it so that I can check for problems. And I don't need to execute the full AllTests.php to get feedback on the new test. So I'm annoyed every time I hit a test case that does not allow me to do that. A working autoloading setup is the key for that.

Luckily not only my own preferences make using an Autoload.php file in a test suite attractive. There are a number of reasons why such a file can be useful. The Wiki page for the Horde_Test component details them and this is a copy of the relevant section:

The Autoload.php file is not required in a test suite but it is strongly recommended that you use it. It's purpose is to setup PHP autoloading so that all tests in the test suite automatically have access to all the classes required for executing the tests. The reason why it is not mandatory is that Horde_Test_AllTests already loads a basic autoloading definition that works for most framework components.

This means that running php AllTests.php usually does not hit any autoloading problems. Running a single test case (e.g. phpunit Horde/Xyz/Unit/UnitTest.php) is a different matter though.

The *Test.php files do not extend Horde_Test_AllTests and thus there is nothing that would magically setup autoloading if you try to run such a test suite in isolation. And running single test cases can be quite convenient if the whole test suite would take a long time to execute. Using an Autoload.php file alongside the AllTests.php file is the recommended way to provide a single test case with autoloading and thus enable commands such as phpunit Horde/Xyz/Unit/UnitTest.php. In addition the file is helpful for any case where you need slightly more complex loading patterns or want to pull in special files manually.

Once you created an Autoload.php file for your test suite it will also be heeded by Horde/Test/AllTests.php. The latter will avoid the basic autoloading setup if it detects the presence of an Autoload.php file for the current test suite. That one will be loaded and is assumed to contain the required autoloading setup.

The content of `Autoload.php`

You should at least require the Autoload.php from Horde_Test in this file. This is also what Horde_Test_AllTests would do when choosing the simple autoloading setup.

require_once 'Horde/Test/Autoload.php';

It also makes sense to adapt the error reporting level to the same standards as required in the AllTests.php wrapper:

error_reporting(E_ALL | E_STRICT);

If you derive your test cases from a central test case definition you should load this one in Autoload.php as well:

/** Load the basic test definition */
require_once dirname(__FILE__) . '/TestCase.php';

Sometimes it makes sense to pull in the definition of test helpers that may be used throughout the test suite. They are usually not available via autoloading and need to be pulled in explicitely:

/** Load stub definitions */
require_once dirname(__FILE__) . '/Stub/ListQuery.php';
require_once dirname(__FILE__) . '/Stub/DataQuery.php';

Real world examples for Autoload.php helpers can be found in the Horde_Date and the Kolab_Storage components.

Within the test cases you only need to load the Autoload.php file which usually looks like this (and obviously depends on the position of the test case in the directory hierarchy of the test suite):

require_once dirname(__FILE__) . '/../Autoload.php';

You'll find additional background information on autoloading within test suite runs on the Wiki page for the Horde_Test component.

Horde4 debian packages - Second round

noreply@blogger.com (Gunnar Wrobel) — Mon, 20 Jun 2011 21:54:00 +0000

Nearly half a year passed since I started my first attempt at Debian packages for Horde4. Back then it was just about snapshots which I generated via a continuous integration setup. But Horde4 has been released now, there are packages and it is time for the real thing.

I did get a first set of packages installable today but this is just the initial draft. The main point about it is that the majority of it is automated.

If you want more details and the installation steps then I would suggest to follow my discussion with Mathieu Parent on pkg-php-pear@lists.alioth.debian.org. These were the mails exchanged so far (with the last two detailing my current status):

There is not much more to say right now. Any testing and feedback is welcome and there is obviously still a lot of work ahead until this pops up in your default package channels. But it is at least on the horizon and the variant that I ship on files.pardus.de should become useable very soon.

Anatomy of a Horde test suite - II

noreply@blogger.com (Gunnar Wrobel) — Tue, 14 Jun 2011 07:29:00 +0000

This morning I completed the next step on the journey through Horde's test suites and added the description of the AllTests.php file to the wiki page. I am not going to copy the complete text here but instead focus on the use cases for this file as I still have a few question to the audience below.

AllTests.php is the only mandatory requirement for a Horde test suite. Everything else is optional but there has to be an AllTests.php file which serves as an entry point into the test suite.

This is the functionality expected from the file:

It must collect all tests of the test suite.
It must allow to retrieve all tests of the suite via Horde_Xyz_AllTests::suite().
It must allow running the test suite via phpunit AllTests.php.
It must allow running the test suite via php AllTests.php.

The Horde_Test package already delivers a boilerplate AllTests.php class in framework/Test/lib/Horde/Test/AllTests.php and deriving an AllTests.php for a standard test suite becomes rather simple. The full code for this is presented on the wiki page and you can also look at an example from our repository.

Now I wonder if the items listed above are in fact all the requirements we have for this file.

Requirements (1) and (2) are obvious as this is functionality needed for our horde/framework/bin/test_framework helper that runs all framework tests. Though I assume nobody uses this one on a regular basis at the moment.

But I noticed that (3) does not work out of the box with the current PHPUnit. This led to a pull request as it definitely should (and can) work.

I usually run the tests with a rather long command line that ultimately boils down to phpunit Horde_Xyz_AllTests AllTests.php which is tied to a shortcut in Emacs. As the Lisp code I use for that extracts the class name automatically I never noticed that a plain phpunit AllTests.php does not work.

So are most people using php AllTests.php? How do you run the test suites or would like to run them? Can I get some feedback on this (either here, on IRC or via tweet)?

Anything additional I missed about the requirements for the AllTests.php file?

Next in the series will be on autoloading which should allow me to also look at the problems we still have with that in the application components.

The Horde newsletter again

noreply@blogger.com (Gunnar Wrobel) — Thu, 09 Jun 2011 16:25:00 +0000

Time flies and it is soon time for the next issue of the Horde newsletter. Which reminds me to post the link to the last one in case you missed it. You can subscribe to the monthly newsletter here.

As Jan already mentioned in his blog he gave Radio Tux an interview on Horde 4. I just checked by roughly translating half of it to English that I should be able to include a transcript of it in the next newsletter. It delivers a very good overview on all things Horde 4.

Anatomy of a Horde test suite - I

noreply@blogger.com (Gunnar Wrobel) — Thu, 09 Jun 2011 13:24:00 +0000

Just got issue 07/2011 of the the German Linux Magazine in the mailbox and on the final page there is this little abstract about 08/2011 saying...

"PHP Unit and Jenkins - There are two things guarding against programming errors: unit tests covering your code and continuous integration systems that automate the testing. The next issue will demonstrate this based on a real example from a PHP web project." [translated from German].

The "PHP web project" is actually named "Horde" and hm... I guess this means I have to write this thing - ;) . When agreeing to the article I immediately knew I wanted to combine it with an overview on how the Horde test suites are arranged. So far we have been lacking a summary in that area and it should help newcomers to the Horde project to get into testing mode as well.

My mind is currently fully tuned to unit testing and code quality and it is amazing how easy it is to write about this. The initial draft for the article already exceeded all limits when it comes to size. Though I got pretty positive feedback on it I will have to leave some stuff out. Those sections should make it to this blog instead so that I can link to it in the article.

Basically I will make this into a short series of blog entries on unit testing in Horde. I will include parts of the Horde_Test overview, personal musings, and stuff related to the article. Let's hope it is useful to some people out there.

Here we go with the introduction to the Horde_Test overview...

Introduction

The Horde Project has always had high standards when it comes to code quality. Of course these standards evolved with time and also with the progress the PHP community made. The code from IMP-1.0.0 (1998) didn't come with unit tests. And somehow it lacked classes. And there is an awful lot of code mixed with HTML. Somehow this looks horribly like PHP3.

Oh, it was PHP3.

Of course PHP development changed over time and so did the Horde project. Nowadays each and every commit into our repository leads to the automatic execution of thousands of unit tests written by the Horde developers and they check our code for failures. Night and day our continuous integration server broadcasts the current test status to us in particular but also to anyone else interested.

With the release of Horde 4 the test suites of the Horde components available via our PEAR server all show some common patterns. There are certain Do's and Don'ts and a lot of playground in between. Often the Horde_Test component is involved. So it makes sense to associate the overview on the anatomy of Horde test suites with this particular module.

I must admit that I really like the way the Horde project approaches unit testing. There is no way we could be unit test purists which would be too extreme given the fact that the project already exists for more than a decade. But at the same time there was also no one complaining when testing entered the equation. It just felt like continuing to adhere to the quality standards that seem so familiar when it comes to Horde code.

So much for now. More technical stuff to follow soon...

Mixing stable Horde components with snapshots

noreply@blogger.com (Gunnar Wrobel) — Wed, 01 Jun 2011 13:14:00 +0000

One thing I completely love about Horde 4 being a component framework is the ability to have stable installations into which I can inject experimental snapshots of packages further developed, patched or hacked in some other way. Just an overview of one such installation:

INSTALLED PACKAGES, CHANNEL PEAR.HORDE.ORG:
===========================================
PACKAGE                   VERSION              STATE
Horde_ActiveSync          1.0.0                stable
Horde_Alarm               1.0.1                stable
Horde_Argv                1.0.1                stable
Horde_Auth                1.0.3                stable
Horde_Autoloader          1.0.0                stable
Horde_Browser             1.0.0                stable
Horde_Cache               1.0.3                stable
Horde_Cli                 1.0.0                stable
Horde_Compress            1.0.1                stable
Horde_Constraint          1.0.0                stable
Horde_Controller          1.0.0                stable
Horde_Core                1.1.2dev201105300702 stable
Horde_Crypt               1.0.2                stable
Horde_Data                1.0.0                stable
Horde_DataTree            1.0.0                stable
Horde_Date                1.0.1                stable
Horde_Date_Parser         1.0.0                stable
Horde_Db                  1.0.1                stable
Horde_Editor              1.0.1                stable
Horde_Exception           1.0.1                stable
Horde_Feed                1.0.1dev201106011224 stable
Horde_Form                1.0.1                stable
Horde_Group               1.0.0                stable
...

How do you get these snapshots? Ensure you have the horde-component helper set up. Then enter the package you wish to snapshot (e.g. Horde_Core) and run:

horde-components snapshot

The snapshot package will be assembled in this directory, can be uploaded to your webserver and installed using:

pear upgrade --offline --force Horde_Core-1.1.2dev201105300702.tgz

What happens if you patched and deployed your package, sent the patch upstream, it gets accepted and a new package released?

pear upgrade horde/Horde_Core

Magic!

Blogging to blogger.com via Horde_Feed

noreply@blogger.com (Gunnar Wrobel) — Wed, 01 Jun 2011 10:55:00 +0000

With Horde 4 being available as PEAR based components a lot of functionality that was hidden behind the Horde groupware applications have suddenly become available as building blocks for your own PHP based software. There is still a lot documentation that should get written. As one piece of the puzzle I will use my blog to post short tutorials on interesting things you might wish to do with the Horde PEAR packages.

Let's start with blog posts today...

Creating Atom blog posts becomes a rather simple task with the help of the Horde_Feed package. Install it via PEAR first:

pear channel-discover pear.horde.org
pear install horde/Horde_Feed

Start with creating an instance of Horde_Feed_Entry_Atom and populate it with content similar to the example below:

$entry = new Horde_Feed_Entry_Atom();
$entry->{'atom:title'} = 'Entry 1';
$entry->{'atom:title'}['type'] = 'text';
$entry->{'atom:content'} = '1.1';
$entry->{'atom:content'}['type'] = 'text';

The type could also be html or xhtml if the text in the corresponding field is not plain text. See the overview on the Atom format for that.

Now it is sufficient to post the entry with:

try {
    $entry->save($blogUri);
} catch (Horde_Feed_Exception $e) {
    die('An error occurred posting: ' . $e->getMessage() . "\n");
}

In most situations this example will be somewhat too simplistic. Most sites will require you to authenticate before being able to add Atom entries. How such authentication information can be transmitted when posting the entry is detailed in the blogger.com example that comes with the Horde_Feed package. At the time I'm writing this the authentication is not yet available in the released package though - you will have to wait for the next release to hit pear.horde.org.

Horde continuous integration got updated

noreply@blogger.com (Gunnar Wrobel) — Tue, 31 May 2011 13:51:00 +0000

The Horde continuous integration server received an update to the most recent version of Jenkins. In addition two new jobs were added to the system: Kolab_Storage and Imap_Client. May they stay forever green! The total number of packages under CI surveillance is 48 by now.

Will have to think about ownCloud

noreply@blogger.com (Gunnar Wrobel) — Tue, 31 May 2011 07:02:00 +0000

While I'm still waiting for the Horde 4 interview with Jan Schneider to appear on Radio Tux I got a reminder to think about ownCloud. While writing this I am listening to the interview about ownCloud.

I'm not yet certain it is actually different to Horde. Of course the way both projects started and the ideas behind them differ. But a lot of the targets seem to be very similar. In any case I need to identify if there are any bridges that could be easily built.

I'm mainly interested in seeing what kind of APIs they provide to the outside and whether this could be offered by Horde as well to support connecting desktop clients. Or maybe Horde could be integrated as a data serving backend. Of course ownCloud still lacks one thing: a decent storage backend. No Kolab support so far ;) ...

A number of Kolab_* releases on files.kolab.org

noreply@blogger.com (Gunnar Wrobel) — Tue, 31 May 2011 05:48:00 +0000

Yesterday and this morning I released Kolab_FreeBusy-0.5.2, Kolab_Server-0.5.1, and Kolab_Storage-0.5.1. All of these are bug fix releases for the Kolab server.

With Horde 4 being deployed via pear.horde.org I cannot release the Kolab_* packages from the Horde 3 branch via that channel anymore. So you can expect updates to hit files.kolab.org exclusively. I don't like that too much but as Horde 3 was not yet released via PEAR and the Kolab_* releases are only targeted at the Kolab server this compromise makes sense.

Is Horde PHP?

noreply@blogger.com (Gunnar Wrobel) — Tue, 17 May 2011 12:34:00 +0000

LinuxTag was really nice for the Horde project because of all that positive feedback to our recent release and the valuable suggestions for stuff that would be nice to have in Horde. Might be worth another blog post. Here I just wanted to log one of the funnier conversations I had ...

"Is Horde PHP?"

"Yes."

"Do you use unit tests?"

"Absolutely. We got about 3000 of those."

"Oh, great. Mind writing an article about PHP Unit testing in Linux Magazine?"

"Deal!"

Video of the Horde 4 talk on CeBIT

noreply@blogger.com (Gunnar Wrobel) — Mon, 16 May 2011 08:26:00 +0000

A while ago I presented a talk for the Horde Project on CeBIT 2011. The link to the corresponding video comes somewhat late but here it is: Horde 4 (the talk is in German).

I could have used better slides, I could have stopped saying "eh", and so on and so on - always nice to see yourself talking in order to improve. But I felt the content is okay and still relevant. Feedback welcome!