OpenPSA Newshttp://openpsa2.org/news/2013-05-20T15:35:15+00:00FeedCreator 1.8 (info@mypapit.net)Say Hello to Midgard 22013-03-09T21:47:12+00:002013-03-09T21:47:12+00:00http://openpsa2.org/midcom-permalink-e695689c890211e2b9eead8e818be502e502It has taken some doing, but after a final round of fixes, the midgard instance running openpsa2.org has been converted to Midgard2 12.09 and has been serving the very page you're viewing right now.
While there are a couple of newer projects that have been set up on Midgard 2 directly, for legacy systems, this is more or less a first. The database migration (of course facilitated by the fact that this instance used neither Multilang nor Sitegroups) has been done with the update script shipped in openpsa's tools folder. The website code is now organized after the fashion of midcom-project-template, and resides in its own repo on Github, so pull requests are possible and welcome.
Enjoy!
]]>It has taken some doing, but after a final round of fixes, the midgard instance running openpsa2.org has been converted to Midgard2 12.09 and has been serving the very page you're viewing right now.
While there are a couple of newer projects that have been set up on Midgard 2 directly, for legacy systems, this is more or less a first. The database migration (of course facilitated by the fact that this instance used neither Multilang nor Sitegroups) has been done with the update script shipped in openpsa's tools folder. The website code is now organized after the fashion of midcom-project-template, and resides in its own repo on Github, so pull requests are possible and welcome.
Enjoy!
]]>Building a smarter workplace2013-03-08T08:00:00+00:002013-03-08T08:00:00+00:00http://openpsa2.org/midcom-permalink-5ed83c7e942211e2a5fc11bddb49dddbdddbAs part of the SmarcoS project, we have been investigating how to make workplaces smarter through sensors and context awareness. Here is a video showing what we've built:
The idea here is to facilitate collaboration and smoother project communications through various different tools that I'll describe below. While this already does a lot, it is obviously only the first step on the path to making offices smarter.
Office presence
An important part of collaboration is to know who is where. Maybe some people are having a lunch break, or are working remotely? The Office Presence Display system knows these things, thanks to various sensors:
Bluetooth sensors can see smartphones and other mobile devices in the space
WiFi sensor can see what computers are connected
Google Talk sensor knows who are connected and active on their work accounts
With these, we know pretty well when you arrive to the office, and when you leave. Thanks to the sensor watching the company instant messaging system, we also know when people working remotely are available.
In addition to letting people know where the other members of the team are, this system can help with the perpetual annoyance in many companies: having to fill timesheets. We have a logger process that listens to the sensors, and logs the data into a CouchDB database. From there you can easily visualize working hours and availability trends:
In many situations it is of course not enough to know whether people are present, but also to know what they're working on. The next component of the system helps with that.
Electronic Kanban wall
Instead of the clumsy waterfall style, more and more companies are managing their projects in tight, recurring iterations. A Kanban wall is a great way to keep track of tasks as they move through the process, and to see who is doing what, and what could be possible to do next. The One day in Kanban Land post explains the concept well.
If everybody working on a project sits in the same room, and that room is also where all decisions about the project are made, then the traditional solution of whiteboards and Post-It notes is probably the best way to visualize Kanban. But for distributed teams and more flexible work, an electronic version is a lot better option. This way everybody can see the Kanban wall in its current state from their computer, a TV in an office room, or a tablet.
Our Kanban wall implementation provides exactly that. The same wall (or, in case of multiple projects or teams, a set of walls) is available through any web browser. You can also display it on a big screen in an office or a meeting room, and control that screen with the Kinect Air Cursor.
Now, for most companies this is not meant to be the master database of projects and tasks, but instead just to be an alternative view and controlling tool to wherever your project information resides. Maybe you're already using Pivotal Tracker, Basecamp, or OpenPSA? The Kanban wall server has a full REST API available, and so it is easy to integrate with any existing system. If a task is moved on the Kanban wall, it can be updated to the project tracking system, and vice versa.
If you're using both systems, then the Kanban wall is also aware of the presence information. We show a differently colored border around the "person tokens" depending on the availability state. You can also set different Work-in-Progress limits for different people and states.
Interested yet?
So far we've only trialed the system in our own office, but are now looking for some pilot customers to try the system out. If you're interested in making your workplace smarter, get in touch.
For those who like to tinker with these things, all the sensor software is available as open source at http://github.com/nemein.
The idea here is to facilitate collaboration and smoother project communications through various different tools that I'll describe below. While this already does a lot, it is obviously only the first step on the path to making offices smarter.
Office presence
An important part of collaboration is to know who is where. Maybe some people are having a lunch break, or are working remotely? The Office Presence Display system knows these things, thanks to various sensors:
Bluetooth sensors can see smartphones and other mobile devices in the space
WiFi sensor can see what computers are connected
Google Talk sensor knows who are connected and active on their work accounts
With these, we know pretty well when you arrive to the office, and when you leave. Thanks to the sensor watching the company instant messaging system, we also know when people working remotely are available.
In addition to letting people know where the other members of the team are, this system can help with the perpetual annoyance in many companies: having to fill timesheets. We have a logger process that listens to the sensors, and logs the data into a CouchDB database. From there you can easily visualize working hours and availability trends:
In many situations it is of course not enough to know whether people are present, but also to know what they're working on. The next component of the system helps with that.
Electronic Kanban wall
Instead of the clumsy waterfall style, more and more companies are managing their projects in tight, recurring iterations. A Kanban wall is a great way to keep track of tasks as they move through the process, and to see who is doing what, and what could be possible to do next. The One day in Kanban Land post explains the concept well.
If everybody working on a project sits in the same room, and that room is also where all decisions about the project are made, then the traditional solution of whiteboards and Post-It notes is probably the best way to visualize Kanban. But for distributed teams and more flexible work, an electronic version is a lot better option. This way everybody can see the Kanban wall in its current state from their computer, a TV in an office room, or a tablet.
Our Kanban wall implementation provides exactly that. The same wall (or, in case of multiple projects or teams, a set of walls) is available through any web browser. You can also display it on a big screen in an office or a meeting room, and control that screen with the Kinect Air Cursor.
Now, for most companies this is not meant to be the master database of projects and tasks, but instead just to be an alternative view and controlling tool to wherever your project information resides. Maybe you're already using Pivotal Tracker, Basecamp, or OpenPSA? The Kanban wall server has a full REST API available, and so it is easy to integrate with any existing system. If a task is moved on the Kanban wall, it can be updated to the project tracking system, and vice versa.
If you're using both systems, then the Kanban wall is also aware of the presence information. We show a differently colored border around the "person tokens" depending on the availability state. You can also set different Work-in-Progress limits for different people and states.
Interested yet?
So far we've only trialed the system in our own office, but are now looking for some pilot customers to try the system out. If you're interested in making your workplace smarter, get in touch.
For those who like to tinker with these things, all the sensor software is available as open source at http://github.com/nemein.
]]>The Great Refactoring, Present and Future2013-03-03T20:23:30+00:002013-03-03T20:23:30+00:00http://openpsa2.org/midcom-permalink-1e28440369b9748844011e2a9edbffffe3978957895About one week ago, we passed the first anniversary of the superglobal removal in the o9 codebase, and incidentally also the last update on the refactoring effort in general. Some of the changes since then have been touched upon in the release announcements, and a number of others are still brewing.
But before we come to that, let's review: The original codebase of MidCOM has a long history, during which the project has accumulated its fair share of cruft, which made it increasingly difficult to keep up with the times. Therefore, the motivations outlined in the superglobal post, interoperability, Midgard 2 compatibility, maintainability, and probably a bunch of other words that end in „bility“ still apply to the changes we're working on now.
In many cases, these changes mostly consist of removing duplication, simplifying codepaths, and removing workaorunds for long-fixed bugs or shortcomings of forgotten PHP versions. As it is expected in situations like these, the urge to „rip it all out and start fresh“ struck sometimes, but for the most part, the Second System Syndrome has been avoided so far.
The main reason for this is of course the size of the codebase: Aside from the public github repo, there is an unknown number of vendor-specific applications and components, and switching them all over from one API to another just isn't realistic. At the same time, all these different consumers of framework services make a nice „reality check“ for changes that unit tests alone simply cannot provide.
So by and large, the API remained the same, with the notable exception of the superglobals, and several variables in the PHP GLOBALS array that were used all over the tree, most prominently the main configuration. These have been removed where possible, or made accessible via the superglobal replacement getter where unavoidable, but this will likely not be the end of it. Static getter methods are still part of the global state, which is, at least in the predominant technical opinion, evil.
Be that as it may, the fact remains that parts of the code are hard to test and/or hard to customize, and in many situations, the use of global state could be avoided simply by improving the code structure. Of course, this is slow work in a codebase of over 100,000 LOC, but compared to the initial Ragnaroek fork, we're down 25,000 LOC already, and there is still room for improvement.
Currently, there are several compatibility layers and switches in various places of the codebase, and the plan is to centralize them as far as possible, move them into a separate repository and to keep them stable, so that the core API can continue to evolve while old out-of-tree components still have a point of reference. Once this compat repo is set up, we will gradually move more deprecated functionality there, and probably introduce finer-grained controls for setting up which parts of the legacy API should be enabled.
This implies of course that there is a standard way to define dependencies and have them automatically installed during project setup. This can be done via Composer, but it will require a custom installer to take care of all the framework-specific idiosyncrasies. Another unsolved issue with out-of-tree components is that a number of central services assume that all code is located in the framework's central lib/ tree. There has been rudimentary support for using external components (e.g. in conjunction midcom-project-template) for a while now, and recently it saw a number of improvements, but there is still a ways to go before it will be completely seamless.
Once these issues are resolved, we could proceed to the next step, which would be a split of the codebase into smaller, more sensible chunks. In a lot of cases, this will involve further refactorings to have sane interdependencies between the various parts, but it can be done step by step, and there are a few low-hanging fruit that should provide a good starting point.
So there you have it: We've come a long way, but the todo list won't be getting shorter anytime soon. So if you're interested in speeding things up, contributions are most welcome!
]]>About one week ago, we passed the first anniversary of the superglobal removal in the o9 codebase, and incidentally also the last update on the refactoring effort in general. Some of the changes since then have been touched upon in the release announcements, and a number of others are still brewing.
But before we come to that, let's review: The original codebase of MidCOM has a long history, during which the project has accumulated its fair share of cruft, which made it increasingly difficult to keep up with the times. Therefore, the motivations outlined in the superglobal post, interoperability, Midgard 2 compatibility, maintainability, and probably a bunch of other words that end in „bility“ still apply to the changes we're working on now.
In many cases, these changes mostly consist of removing duplication, simplifying codepaths, and removing workaorunds for long-fixed bugs or shortcomings of forgotten PHP versions. As it is expected in situations like these, the urge to „rip it all out and start fresh“ struck sometimes, but for the most part, the Second System Syndrome has been avoided so far.
The main reason for this is of course the size of the codebase: Aside from the public github repo, there is an unknown number of vendor-specific applications and components, and switching them all over from one API to another just isn't realistic. At the same time, all these different consumers of framework services make a nice „reality check“ for changes that unit tests alone simply cannot provide.
So by and large, the API remained the same, with the notable exception of the superglobals, and several variables in the PHP GLOBALS array that were used all over the tree, most prominently the main configuration. These have been removed where possible, or made accessible via the superglobal replacement getter where unavoidable, but this will likely not be the end of it. Static getter methods are still part of the global state, which is, at least in the predominant technical opinion, evil.
Be that as it may, the fact remains that parts of the code are hard to test and/or hard to customize, and in many situations, the use of global state could be avoided simply by improving the code structure. Of course, this is slow work in a codebase of over 100,000 LOC, but compared to the initial Ragnaroek fork, we're down 25,000 LOC already, and there is still room for improvement.
Currently, there are several compatibility layers and switches in various places of the codebase, and the plan is to centralize them as far as possible, move them into a separate repository and to keep them stable, so that the core API can continue to evolve while old out-of-tree components still have a point of reference. Once this compat repo is set up, we will gradually move more deprecated functionality there, and probably introduce finer-grained controls for setting up which parts of the legacy API should be enabled.
This implies of course that there is a standard way to define dependencies and have them automatically installed during project setup. This can be done via Composer, but it will require a custom installer to take care of all the framework-specific idiosyncrasies. Another unsolved issue with out-of-tree components is that a number of central services assume that all code is located in the framework's central lib/ tree. There has been rudimentary support for using external components (e.g. in conjunction midcom-project-template) for a while now, and recently it saw a number of improvements, but there is still a ways to go before it will be completely seamless.
Once these issues are resolved, we could proceed to the next step, which would be a split of the codebase into smaller, more sensible chunks. In a lot of cases, this will involve further refactorings to have sane interdependencies between the various parts, but it can be done step by step, and there are a few low-hanging fruit that should provide a good starting point.
So there you have it: We've come a long way, but the todo list won't be getting shorter anytime soon. So if you're interested in speeding things up, contributions are most welcome!
]]>OpenPSA 9.0beta4 Released2012-12-21T16:04:00+00:002012-12-21T16:04:00+00:00http://openpsa2.org/midcom-permalink-1e24b8808bc1bf44b8811e2af04d976f10b85468546It's this time of the year again...
Right before the holiday season (or the end of the world if you prefer) we give you a shiny new beta of OpenPSA 9.0 to play with. This release has been a long time in the making, and brings among others the following changes:
- Compatibility with PHP 5.4: The testuite now regularily runs on PHP 5.4 environments, too, so with Midgard2, you can now run on the latest crop of distributions. At the same time, the mimum requirement has been bumped to PHP 5.3, allowing us to remove quite a number of legacy workarounds and use more current PHP features and libraries
- Experimental installer: After a long time of being practically only manually installable, we now have an experimental Composer-based installer, which also takes care of installing dependencies (so when updating, you need to run composer install so that PEAR packages and the like can still be found). There is also a Vagrant-based setup in the new MidOM project template, which should get you started pretty quickly.
- UI improvements: All major Javascript dependencies have been updated to their latest versions, and a number of old custom widgets have been replaced for a more streamlined experience. OpenPSA's grid integration has also seen a number of improvements that should make grids much easier to use
- Create.js integration: Via CreatePHP, you can now take an early look at the next-generation RDFa-powered inline editing interface
Apart from that, there is the usual pile of cleanups, modernizations and optimizations. All told, 1822 files were changed since the last release, with 56584 insertions and 38593 deletions. You can view all changes here and the closed tickets here.
You can also try the application on our demo server or download the source here.
Enjoy!
]]>It's this time of the year again...
Right before the holiday season (or the end of the world if you prefer) we give you a shiny new beta of OpenPSA 9.0 to play with. This release has been a long time in the making, and brings among others the following changes:
- Compatibility with PHP 5.4: The testuite now regularily runs on PHP 5.4 environments, too, so with Midgard2, you can now run on the latest crop of distributions. At the same time, the mimum requirement has been bumped to PHP 5.3, allowing us to remove quite a number of legacy workarounds and use more current PHP features and libraries
- Experimental installer: After a long time of being practically only manually installable, we now have an experimental Composer-based installer, which also takes care of installing dependencies (so when updating, you need to run composer install so that PEAR packages and the like can still be found). There is also a Vagrant-based setup in the new MidOM project template, which should get you started pretty quickly.
- UI improvements: All major Javascript dependencies have been updated to their latest versions, and a number of old custom widgets have been replaced for a more streamlined experience. OpenPSA's grid integration has also seen a number of improvements that should make grids much easier to use
- Create.js integration: Via CreatePHP, you can now take an early look at the next-generation RDFa-powered inline editing interface
Apart from that, there is the usual pile of cleanups, modernizations and optimizations. All told, 1822 files were changed since the last release, with 56584 insertions and 38593 deletions. You can view all changes here and the closed tickets here.
You can also try the application on our demo server or download the source here.
Enjoy!
]]>The wiki is not offering wedding dresses any more2012-09-04T19:00:32+00:002012-09-04T19:00:32+00:00http://openpsa2.org/midcom-permalink-1e1f6c2cd01b5d4f6c211e182912738abf381ed81edA major spam infestation has been found and removed in the wiki
This is just a short FYI regarding openpsa2.org's wiki. Recently, a rather massive spam infestation was discovered and almost 25GB of ads and nonsense were removed. So apologies if you did all your shopping through the assorted recommendations on this site. For everyone else, the actual documentation should be in a lot better shape now (although it is still partly outdated, of course.). Furthermore, some additional safety measures were added to prevent another onslaught like this, but please don't let that keep you from editing content.
In other news, the next beta release should hopefully come out real soon now, featuring a brand-new installer and distribution method, but more on that in a later post.
Enjoy!
]]>A major spam infestation has been found and removed in the wiki
This is just a short FYI regarding openpsa2.org's wiki. Recently, a rather massive spam infestation was discovered and almost 25GB of ads and nonsense were removed. So apologies if you did all your shopping through the assorted recommendations on this site. For everyone else, the actual documentation should be in a lot better shape now (although it is still partly outdated, of course.). Furthermore, some additional safety measures were added to prevent another onslaught like this, but please don't let that keep you from editing content.
In other news, the next beta release should hopefully come out real soon now, featuring a brand-new installer and distribution method, but more on that in a later post.
Enjoy!
]]>OpenPSA 9.0beta3 Released2012-04-07T19:31:41+00:002012-04-07T19:31:41+00:00http://openpsa2.org/midcom-permalink-1e180e84d6d834880e811e19fe119f0f87055905590The next beta is upon us!
This release incorporates over three months of development effort, including the following items:
Improved code editing in Asgard: the old EditArea widget has been replaced by CodeMirror, which brings much better robustness and performance
No more Superglobals: All in-tree code has been converted to the new API, a backward compatibility wrapper is provided. Read more here
New slideshow component: A simple, Galleria-based image galery with HTML5 admin backend
More grid-related goodness: Another batch of often-used HTML tables has been converted to the grid widget, which has received a number of new features and improvements
Aside from that, there were lots of smaller fixes, cleanups and usability improvements all over the tree. In total, 1422 files were changed with 37834 insertions and 34082 deletions. You can view all changes here and the closed tickets here.
You can also try the application on our demo server or download the source here.
Enjoy!
]]>The next beta is upon us!
This release incorporates over three months of development effort, including the following items:
Improved code editing in Asgard: the old EditArea widget has been replaced by CodeMirror, which brings much better robustness and performance
No more Superglobals: All in-tree code has been converted to the new API, a backward compatibility wrapper is provided. Read more here
New slideshow component: A simple, Galleria-based image galery with HTML5 admin backend
More grid-related goodness: Another batch of often-used HTML tables has been converted to the grid widget, which has received a number of new features and improvements
Aside from that, there were lots of smaller fixes, cleanups and usability improvements all over the tree. In total, 1422 files were changed with 37834 insertions and 34082 deletions. You can view all changes here and the closed tickets here.
You can also try the application on our demo server or download the source here.
Enjoy!
]]>Open Advice2012-03-19T07:00:00+00:002012-03-19T07:00:00+00:00http://openpsa2.org/midcom-permalink-808252e09afa11e2a31bcb713db89d509d50I seem to have not blogged about this, but Open Advice, our book on Free and Open Source Software: what we wish we had known when we started, was published last month.
The book was edited by Lydia Pintscher and includes essays from 42 authors, many of whom you'll recognize if you tend to go to FOSS conferences. The LWN book review concludes:
Open Advice is a book that will be helpful to those who are new to FOSS, but, because of the individual voices, styles, and tones, it doesn't read like a "how to". It could even be recommended to those who aren't necessarily interested in contributing, but are curious about what this "free software thing" is all about. It is, in short, a great book for a variety of audiences and the (mostly) two or three page essays make it easy to read, while the anecdotes and recollections personalize it. The authors, editor, and everyone else who helped should be very pleased with the result. Readers will be too.
I probably shouldn't give the ending away, but my essay on cross-project collaboration, a subject I've also blogged about, ends with:
Good luck with breaking down the project boundaries! In most cases it works if your ideas are good and presented with an open mind. But even if you do not find a common ground, as long as your implementation solves the use case for you it has not been in vain. After all, delivering software, and delivering great user experience is what counts.
]]>I seem to have not blogged about this, but Open Advice, our book on Free and Open Source Software: what we wish we had known when we started, was published last month.
The book was edited by Lydia Pintscher and includes essays from 42 authors, many of whom you'll recognize if you tend to go to FOSS conferences. The LWN book review concludes:
Open Advice is a book that will be helpful to those who are new to FOSS, but, because of the individual voices, styles, and tones, it doesn't read like a "how to". It could even be recommended to those who aren't necessarily interested in contributing, but are curious about what this "free software thing" is all about. It is, in short, a great book for a variety of audiences and the (mostly) two or three page essays make it easy to read, while the anecdotes and recollections personalize it. The authors, editor, and everyone else who helped should be very pleased with the result. Readers will be too.
I probably shouldn't give the ending away, but my essay on cross-project collaboration, a subject I've also blogged about, ends with:
Good luck with breaking down the project boundaries! In most cases it works if your ideas are good and presented with an open mind. But even if you do not find a common ground, as long as your implementation solves the use case for you it has not been in vain. After all, delivering software, and delivering great user experience is what counts.
]]>Look ma, no Superglobals!2012-02-18T12:33:25+00:002012-02-18T12:33:25+00:00http://openpsa2.org/midcom-permalink-1e15a2cc08d336a5a2c11e1bbc8abafd62bff8dff8dFollowing a long series of search and replace commands, OpenPSA can now run without mgd1 superglobals.
One of the peculiar things about the Midgard 1/MidCOM environment was always the presence of two custom superglobals, $_MIDCOM and $_MIDGARD, where the first one was in fact an entry point to the diverse framework services whereas the second one was an array that held various information about the host setup. It was a very practical arrangement for developing components, since all functionality was easily reachable without having to worry about variable scopes, dependency injection, and other fun things like that.
But at the same time, this caused a few problems: For example, IDEs got confused and would show countless warnings for what they considered undefined local variables, code analysis tools would get the dependencies wrong, and so on and so forth. But more importantly, the custom superglobals isolated MidCOM from the rest of the PHP world, because they constituted a hard dependency on the Midgard PHP extension, meaning that MidCOM code could only run on customized servers.
Of course, the dependency on Midgard runs deeper than the superglobals, anything that is storage-related is still hardwired to the Midgard backend (more on that in some later post...), but the superglobal part always seemed a bit gratuitious. Even more so if you consider that in Midgard2 (where they are marked as deprecated), the superglobals provided are in fact just empty placeholders and all the setup has to be done by the framework anyways.
It soon became clear that a replacement would have to be found, in fact, this is one of the first tickets that were created, but since superglobals were one of the more popular constructs of the framework (the $_MIDCOM superglobal alone was used over 5000 times in the OpenPSA code when the repository was created), some careful planning was required.
The other issue with $_MIDCOM was that, because it was so convenient to use, a lot of functionality was dropped there. Replacing them with an equally large class wouldn't have been much of an improvement, so a total of 29 functions was moved elsewhere and three were removed completely since they were unused. The remaining midcom_application class is still over 1000 lines long, but this step already improved maintainability noticably
The internal API change has been completed quite some time ago, but until recently, most of the code was still using the old $_MIDCOM access points via the midcom_compat_superglobal compatibility wrapper. That has all changed now, and since yesterday, it is possible to run OpenPSA with superglobals disabled.
If you have out-of-tree components you want to run on the o9 branch, you have two choices: You can either keep using the superglobals as long as the Midgard PHP extension supports them, or you can port your code over to the new API. For the most part, this is a simple matter of search and replace, but you can find more detailed information on the wiki.
Enjoy!
]]>Following a long series of search and replace commands, OpenPSA can now run without mgd1 superglobals.
One of the peculiar things about the Midgard 1/MidCOM environment was always the presence of two custom superglobals, $_MIDCOM and $_MIDGARD, where the first one was in fact an entry point to the diverse framework services whereas the second one was an array that held various information about the host setup. It was a very practical arrangement for developing components, since all functionality was easily reachable without having to worry about variable scopes, dependency injection, and other fun things like that.
But at the same time, this caused a few problems: For example, IDEs got confused and would show countless warnings for what they considered undefined local variables, code analysis tools would get the dependencies wrong, and so on and so forth. But more importantly, the custom superglobals isolated MidCOM from the rest of the PHP world, because they constituted a hard dependency on the Midgard PHP extension, meaning that MidCOM code could only run on customized servers.
Of course, the dependency on Midgard runs deeper than the superglobals, anything that is storage-related is still hardwired to the Midgard backend (more on that in some later post...), but the superglobal part always seemed a bit gratuitious. Even more so if you consider that in Midgard2 (where they are marked as deprecated), the superglobals provided are in fact just empty placeholders and all the setup has to be done by the framework anyways.
It soon became clear that a replacement would have to be found, in fact, this is one of the first tickets that were created, but since superglobals were one of the more popular constructs of the framework (the $_MIDCOM superglobal alone was used over 5000 times in the OpenPSA code when the repository was created), some careful planning was required.
The other issue with $_MIDCOM was that, because it was so convenient to use, a lot of functionality was dropped there. Replacing them with an equally large class wouldn't have been much of an improvement, so a total of 29 functions was moved elsewhere and three were removed completely since they were unused. The remaining midcom_application class is still over 1000 lines long, but this step already improved maintainability noticably
The internal API change has been completed quite some time ago, but until recently, most of the code was still using the old $_MIDCOM access points via the midcom_compat_superglobal compatibility wrapper. That has all changed now, and since yesterday, it is possible to run OpenPSA with superglobals disabled.
If you have out-of-tree components you want to run on the o9 branch, you have two choices: You can either keep using the superglobals as long as the Midgard PHP extension supports them, or you can port your code over to the new API. For the most part, this is a simple matter of search and replace, but you can find more detailed information on the wiki.
Enjoy!
]]>Going PHP 5.32012-02-08T22:35:51+00:002012-02-08T22:35:51+00:00http://openpsa2.org/midcom-permalink-1e152a5414c2f6852a511e1814c49588d5896149614This is a small heads-up that the minimum system requirements will be bumped soon
For a great number of years, MidCOM's minimum required PHP version has been 5.1, which increasingly became a burden: Since we couldn't use things like the DateTime class, we had to depend on some ill-maintained PEAR packages, we needed custom JSON encoding functions and so on and so forth. So one the first things that happened after the creation of the OpenPSA repository was to bump the PHP requirement to 5.2, which has helped in quite a few places to reduce the cruft that has accumulated over time.
Now we're approaching a point where 5.2 is becoming a burden as well: There's quite a lot of code that could be replaced with builtin 5.3 functionality, and seeing how 5.2 was EOL'ed more than a year ago and the 5.4 is just around the corner, there seems little point in continuing to maintain backwards compatibility for a shrinking audience. Especially since this also prevents us from working with more modern PHP environments like Symfony2.
So unless there is any major outrage the upcoming beta3 release will be the last one supporting PHP 5.2. If you have any objections, speak up now or forever hold your peace :-)
]]>This is a small heads-up that the minimum system requirements will be bumped soon
For a great number of years, MidCOM's minimum required PHP version has been 5.1, which increasingly became a burden: Since we couldn't use things like the DateTime class, we had to depend on some ill-maintained PEAR packages, we needed custom JSON encoding functions and so on and so forth. So one the first things that happened after the creation of the OpenPSA repository was to bump the PHP requirement to 5.2, which has helped in quite a few places to reduce the cruft that has accumulated over time.
Now we're approaching a point where 5.2 is becoming a burden as well: There's quite a lot of code that could be replaced with builtin 5.3 functionality, and seeing how 5.2 was EOL'ed more than a year ago and the 5.4 is just around the corner, there seems little point in continuing to maintain backwards compatibility for a shrinking audience. Especially since this also prevents us from working with more modern PHP environments like Symfony2.
So unless there is any major outrage the upcoming beta3 release will be the last one supporting PHP 5.2. If you have any objections, speak up now or forever hold your peace :-)
]]>OpenPSA 9.0beta2 Released2011-12-19T21:13:14+00:002011-12-19T21:13:14+00:00http://openpsa2.org/midcom-permalink-1e12a8643744d622a8611e198f8e9c39250ec1dec1dJust in time for the holiday season, a new beta release of OpenPSA 9 is ready for your testing pleasure!
As usual, there has been much development activity all over the tree, the diffstat shows 22227 insertions and 19418 deletions since the first beta release in early September. Some highlights include:
125 new unittests, and greater coverage for many existing ones
a completely overhauled indexing system, which makes reindexing up to 10 times faster, improves index contents and fixes a number of deletion-related issues
Better extensibility through component inheritance: You can now extend exitsting components, overriding only the parts you want to adapt
Updated dependencies: Many bundled third-party libraries like tinymce, jquery and jqgrid have been updated, and deprecated code has been removed
Apart from that, there's the usual pile of new, helpful little features, bug fixes and performance and usability improvements. You can see the whole list of changes here, try the application on our demo server or download the source here.
Enjoy!
]]>Just in time for the holiday season, a new beta release of OpenPSA 9 is ready for your testing pleasure!
As usual, there has been much development activity all over the tree, the diffstat shows 22227 insertions and 19418 deletions since the first beta release in early September. Some highlights include:
125 new unittests, and greater coverage for many existing ones
a completely overhauled indexing system, which makes reindexing up to 10 times faster, improves index contents and fixes a number of deletion-related issues
Better extensibility through component inheritance: You can now extend exitsting components, overriding only the parts you want to adapt
Updated dependencies: Many bundled third-party libraries like tinymce, jquery and jqgrid have been updated, and deprecated code has been removed
Apart from that, there's the usual pile of new, helpful little features, bug fixes and performance and usability improvements. You can see the whole list of changes here, try the application on our demo server or download the source here.
Enjoy!
]]>Business analytics with CouchDB and NoFlo2011-09-21T07:00:00+00:002011-09-21T07:00:00+00:00http://openpsa2.org/midcom-permalink-8068e4549afa11e2a31bcb713db89d509d50The purpose of business analytics is to find data from the company's information systems that can be used to support decision making. What customers buy most? What do they do before a buying decision? What are the signs that a customer may be leaving?
For the last month we've been working in Salzburg to build such a system, the Intelligent Project Controlling Tool needed for running large collaborative research projects like IKS. Since the design we went with can be reused for other business analytics needs, I wanted to write a bit about it.
But first, here is how our system looks like:
Where does the data come from?
There are many ways to gather business data. Often the information systems already contain the data needed. But it may also be hidden in a jungle of spreadsheets. Or maybe some data is simply not available, and has to be filled in manually.
Handling all these cases in one system is a tricky question. To solve it, we went with a two-layered strategy:
All data used for analytics is stored as Linked Data in a CouchDB system
NoFlo workflows are used for gathering data from the diverse sources and convert it to the format needed
In IKS's case, much of the data was available in a series of spreadsheets. With these, we built the necessary workflows for first converting the spreadsheets into XML with Apache Tika, and then extracting the information from them in a sensible subset of JSON-LD.
Because IKS is a collaborative project, information needs to be gathered from a diverse group of partner organizations. Some of them have systems that provide the needed APIs (like Basecamp, which we use), and we can just periodically import the data. But with many we decided on a simple data interchange approach: spreadsheets handled over email.
In this approach, user files a data request into the system. This gets picked up by NoFlo, which sends an email with the appropriate spreadsheet template to the partner. Then it starts waiting for a reply. When a reply arrives, it extracts the data from the attached spreadsheet and imports it to the system.
Our NoFlo processes are mostly initiated by the CouchDB change notification API. We keep them running persistently using forever Node, so whenever some operation needs to be run it happens nearly immediately.
Ensuring data consistency
With any automation, and especially with the email-based data interchange, things can go wrong. Because of this we tag all data that we receive with its origin, whether it was some automated operation or an imported spreadsheet. These origins are called execution documents. Users can browse all completed workflow executions and see what data came in from them. These can then be either accepted or rejected.
This way if some partner accidentally sends faulty data, or something else breaks, the incorrect information received can be easily removed. CouchDB's versioning capabilities help here.
Analyzing the data
CouchDB is built on top of the concept of map/reduce. Here you can modify and combine the data in lots of different ways using simple JavaScript functions. In our case we elected to write all our CouchDB code in CoffeeScript for simplicity. For example, here is the reduce function in CoffeeScript that counts totals of time planned, time used, and time left per task or partner in a project:
(keys, values, rereduce) ->
roundNumber = (rnum, rlength) ->
Math.round(parseFloat(rnum) * Math.pow(10, rlength)) / Math.pow(10, rlength)
data =
planned: 0.0
spent: 0.0
left: 0.0
if rereduce
for reducedData in values
data.planned += reducedData.planned
data.spent += reducedData.spent
data.left = data.planned - data.spent
return data
for doc in values
if doc['@type'] is 'effortallocation'
data.planned += roundNumber doc.value, 1
if doc['@type'] is 'effort'
data.spent += roundNumber doc.value, 1
data.left = roundNumber data.planned - data.spent, 1
return data
If you figure out a new way to look at the data you have, simply write the needed map and reduce functions and save them into the database. CouchDB will then run them against existing data and produce numbers.
Data visualizations
Numbers are good, but to really see the information buried in them you need some visualizations. For this we decided to follow the CouchApp idea where the user interface code is stored in the database together with the data itself. This way no application servers are needed, and you can take the whole system with you just by replicating the database. Think of the possibility of doing some analysis on your company while flying to a meeting!
The visuals are in our case provided by JavaScript InfoVis Toolkit, a nice, MIT-licensed interactive graph library.
CouchDB views handle the number crunching, then CouchDB list functions process the numbers into the format needed for visualization. This leaves only a minimal amount of work for the client side.
This way you have a business analytics environment that is easy to extend with more data when it becomes available. New analysis can be done by writing reasonably simple map/reduce functions, and CouchDB's replication capabilities allow you to take the system and data with you.
Using JSON-LD for the data storage makes a lot of sense, as this way the relations between different pieces of information are easy to handle. And using URIs for data identifiers means you can easily mash up information coming from different sources together.
The two-layered approach of using NoFlo for data imports, and CouchDB for analysis also allows for clean separation of concerns. In our case, I did the workflow part of things, and Szaby built the visualizations.
]]>The purpose of business analytics is to find data from the company's information systems that can be used to support decision making. What customers buy most? What do they do before a buying decision? What are the signs that a customer may be leaving?
For the last month we've been working in Salzburg to build such a system, the Intelligent Project Controlling Tool needed for running large collaborative research projects like IKS. Since the design we went with can be reused for other business analytics needs, I wanted to write a bit about it.
But first, here is how our system looks like:
Where does the data come from?
There are many ways to gather business data. Often the information systems already contain the data needed. But it may also be hidden in a jungle of spreadsheets. Or maybe some data is simply not available, and has to be filled in manually.
Handling all these cases in one system is a tricky question. To solve it, we went with a two-layered strategy:
All data used for analytics is stored as Linked Data in a CouchDB system
NoFlo workflows are used for gathering data from the diverse sources and convert it to the format needed
In IKS's case, much of the data was available in a series of spreadsheets. With these, we built the necessary workflows for first converting the spreadsheets into XML with Apache Tika, and then extracting the information from them in a sensible subset of JSON-LD.
Because IKS is a collaborative project, information needs to be gathered from a diverse group of partner organizations. Some of them have systems that provide the needed APIs (like Basecamp, which we use), and we can just periodically import the data. But with many we decided on a simple data interchange approach: spreadsheets handled over email.
In this approach, user files a data request into the system. This gets picked up by NoFlo, which sends an email with the appropriate spreadsheet template to the partner. Then it starts waiting for a reply. When a reply arrives, it extracts the data from the attached spreadsheet and imports it to the system.
Our NoFlo processes are mostly initiated by the CouchDB change notification API. We keep them running persistently using forever Node, so whenever some operation needs to be run it happens nearly immediately.
Ensuring data consistency
With any automation, and especially with the email-based data interchange, things can go wrong. Because of this we tag all data that we receive with its origin, whether it was some automated operation or an imported spreadsheet. These origins are called execution documents. Users can browse all completed workflow executions and see what data came in from them. These can then be either accepted or rejected.
This way if some partner accidentally sends faulty data, or something else breaks, the incorrect information received can be easily removed. CouchDB's versioning capabilities help here.
Analyzing the data
CouchDB is built on top of the concept of map/reduce. Here you can modify and combine the data in lots of different ways using simple JavaScript functions. In our case we elected to write all our CouchDB code in CoffeeScript for simplicity. For example, here is the reduce function in CoffeeScript that counts totals of time planned, time used, and time left per task or partner in a project:
(keys, values, rereduce) ->
roundNumber = (rnum, rlength) ->
Math.round(parseFloat(rnum) * Math.pow(10, rlength)) / Math.pow(10, rlength)
data =
planned: 0.0
spent: 0.0
left: 0.0
if rereduce
for reducedData in values
data.planned += reducedData.planned
data.spent += reducedData.spent
data.left = data.planned - data.spent
return data
for doc in values
if doc['@type'] is 'effortallocation'
data.planned += roundNumber doc.value, 1
if doc['@type'] is 'effort'
data.spent += roundNumber doc.value, 1
data.left = roundNumber data.planned - data.spent, 1
return data
If you figure out a new way to look at the data you have, simply write the needed map and reduce functions and save them into the database. CouchDB will then run them against existing data and produce numbers.
Data visualizations
Numbers are good, but to really see the information buried in them you need some visualizations. For this we decided to follow the CouchApp idea where the user interface code is stored in the database together with the data itself. This way no application servers are needed, and you can take the whole system with you just by replicating the database. Think of the possibility of doing some analysis on your company while flying to a meeting!
The visuals are in our case provided by JavaScript InfoVis Toolkit, a nice, MIT-licensed interactive graph library.
CouchDB views handle the number crunching, then CouchDB list functions process the numbers into the format needed for visualization. This leaves only a minimal amount of work for the client side.
This way you have a business analytics environment that is easy to extend with more data when it becomes available. New analysis can be done by writing reasonably simple map/reduce functions, and CouchDB's replication capabilities allow you to take the system and data with you.
Using JSON-LD for the data storage makes a lot of sense, as this way the relations between different pieces of information are easy to handle. And using URIs for data identifiers means you can easily mash up information coming from different sources together.
The two-layered approach of using NoFlo for data imports, and CouchDB for analysis also allows for clean separation of concerns. In our case, I did the workflow part of things, and Szaby built the visualizations.
]]>"Off the Grid" - OpenPSA 9.0beta1 Released2011-09-03T18:06:00+00:002011-09-03T18:06:00+00:00http://openpsa2.org/midcom-permalink-1e0d65761329d00d65711e0a31687d47ec6d127d127After more than one year of development and over 2000 commits, we're proud to announce the first beta release of OpenPSA 9.
A lot has changed since the 8.09.9 release last July, both under the hood and in the application's user interface. Large parts of the codebase were refactored and cleaned up quite rigorously, while our growing collection of unit tests helps keeping the code stable. There are usability improvements, new features and fixes all over the place, you can find a small selection of changes in the list of closed tickets, all the details (since the creation of the new repository) in the list of changesets and try the application yourself on our demo server.
The application itself is quite stable and has already proven itself it productive use in a number of installations, even if there are still numerous things we'd still like to implement to realize OpenPSA's full potential.
One of these things is a nice, easy-to-use installer, but if you want to give OpenPSA a go on your own machine and are not afraid to get your hands a little dirty, just install Midgard 2, clone the repository on github, follow the instructions and don't hesitate to contact us on Qaiku, in the comments section or on the Midgard Project's user forum.
Enjoy!
]]>After more than one year of development and over 2000 commits, we're proud to announce the first beta release of OpenPSA 9.
A lot has changed since the 8.09.9 release last July, both under the hood and in the application's user interface. Large parts of the codebase were refactored and cleaned up quite rigorously, while our growing collection of unit tests helps keeping the code stable. There are usability improvements, new features and fixes all over the place, you can find a small selection of changes in the list of closed tickets, all the details (since the creation of the new repository) in the list of changesets and try the application yourself on our demo server.
The application itself is quite stable and has already proven itself it productive use in a number of installations, even if there are still numerous things we'd still like to implement to realize OpenPSA's full potential.
One of these things is a nice, easy-to-use installer, but if you want to give OpenPSA a go on your own machine and are not afraid to get your hands a little dirty, just install Midgard 2, clone the repository on github, follow the instructions and don't hesitate to contact us on Qaiku, in the comments section or on the Midgard Project's user forum.
Enjoy!
]]>True Grid2011-08-07T12:46:06+00:002011-08-07T12:46:06+00:00http://openpsa2.org/midcom-permalink-1e0c0f337d691a6c0f311e0801de5a0595ed4eed4eeLive from Desktop Summit 2011: The second instalment of the "What's changed in OpenPSA 9" series.
After having talked about the refactoring effort and what it meant for OpenPSA's interaction with the Midgard storage backend, it's finally time to get to the management itself, and since the first thing that's likely to catch a user's eye is the user interface, we'll start with that.
If you've played around with the demo server, you will have noticed that the layout of the individual elements and their behavior has evolved quite a bit over the last year, even if the basic OpenPSA look and feel is still there. The focus of the UI changes was not so much to create an entirely new experience than to flesh out and polish the system that we have.
This meant for example to take advantage of more recent CSS features like gradients or shadows, but also a much broader use of Javascript in the interface. Some of the more noticeable examples here include the new datepicker and autocomplete widgets, and the unified search widget. But the most massive change concerns the replacement of many of OpenPSA's list views by interactive data grids:
Up until the most recent 8.09 releases, tabular data was rendered by OpenPSA like in the days of yonder, that is to say straight HTML tables with some CSS slapped on to make them less of an eysore. While these tables had a certain simple charm to them, they were of course terrible for usability, especially once your data sets started to grow: Scrolling down would cause the column headers to disappear, and if you wanted to resize or sort columns, you were out of luck, because HTML tables lack these features.
jqGrid, OpenPSA's current grid implementation of choice, changes all that: In contrast to the old HTML tables which were in essence only specialized formatters, jqGrid approximates the behavior of desktop spreadsheet applications, which many potential users are already familiar with. Of course, proper integration of all possible interactions is a large task that is far from done, but there are already a number of interesting examples in the current o9 repository:
Load table data by AJAX: While not exactly groundbreaking, this is nevertheless a first for OpenPSA and can cut down the page load times considerably, especially when combined jqGrid's builtin paging support. Aside from the regular next/previous paging, it's also possible to load more table rows on demand when scrolling. We have implemented this for the paid invoices grid on the invoicing dashboard: Before, it would show you the six most recently paid invoices and nothing else. Now, it is prefilled with six rows, but by simply scrolling down, you can load as many additional rows as you wish, going all the way back to the first invoice ever created in your database.
Inline editing: On the invoice items grid, you'll see what an editable table could look like: To change an invoice item, just click into the row to start editing. Fill out description, quantity and price per unit, hit return (or click the little „save“ icon), and the appropriate DB entry will get created, causing the invoice's total to be updated accordingly. Adding new invoice items and deleting existing ones is just as simple.
Grouped Rows: Flat tables, especially ones with lots of rows, can get quite confusing, so we dynamically group rows with the same value in a particular column together. Since this happens on the client side, it is very easy to make it interactive. For example, on the task grid, the rows are by default grouped by project, but if you'd rather see all tasks for a particular customer or manager displayed together, you can just change the grouping by selecting the new column from a dropdown, with no new request to the server. Totals for the different groups are automatically recalculated, giving you more possibilities to manage and survey your information.
At this point, data grids are of course nothing revolutionary, but this is really a step that any application that is serious about targetting business users must take. Spreadsheets are the medium of choice in these circles, and with good reason. The sooner we can bridge the gap between web app tables and desktop spreadsheet applications, the easier will it be to actually get business users to move their business processes into the "cloud".
]]>Live from Desktop Summit 2011: The second instalment of the "What's changed in OpenPSA 9" series.
After having talked about the refactoring effort and what it meant for OpenPSA's interaction with the Midgard storage backend, it's finally time to get to the management itself, and since the first thing that's likely to catch a user's eye is the user interface, we'll start with that.
If you've played around with the demo server, you will have noticed that the layout of the individual elements and their behavior has evolved quite a bit over the last year, even if the basic OpenPSA look and feel is still there. The focus of the UI changes was not so much to create an entirely new experience than to flesh out and polish the system that we have.
This meant for example to take advantage of more recent CSS features like gradients or shadows, but also a much broader use of Javascript in the interface. Some of the more noticeable examples here include the new datepicker and autocomplete widgets, and the unified search widget. But the most massive change concerns the replacement of many of OpenPSA's list views by interactive data grids:
Up until the most recent 8.09 releases, tabular data was rendered by OpenPSA like in the days of yonder, that is to say straight HTML tables with some CSS slapped on to make them less of an eysore. While these tables had a certain simple charm to them, they were of course terrible for usability, especially once your data sets started to grow: Scrolling down would cause the column headers to disappear, and if you wanted to resize or sort columns, you were out of luck, because HTML tables lack these features.
jqGrid, OpenPSA's current grid implementation of choice, changes all that: In contrast to the old HTML tables which were in essence only specialized formatters, jqGrid approximates the behavior of desktop spreadsheet applications, which many potential users are already familiar with. Of course, proper integration of all possible interactions is a large task that is far from done, but there are already a number of interesting examples in the current o9 repository:
Load table data by AJAX: While not exactly groundbreaking, this is nevertheless a first for OpenPSA and can cut down the page load times considerably, especially when combined jqGrid's builtin paging support. Aside from the regular next/previous paging, it's also possible to load more table rows on demand when scrolling. We have implemented this for the paid invoices grid on the invoicing dashboard: Before, it would show you the six most recently paid invoices and nothing else. Now, it is prefilled with six rows, but by simply scrolling down, you can load as many additional rows as you wish, going all the way back to the first invoice ever created in your database.
Inline editing: On the invoice items grid, you'll see what an editable table could look like: To change an invoice item, just click into the row to start editing. Fill out description, quantity and price per unit, hit return (or click the little „save“ icon), and the appropriate DB entry will get created, causing the invoice's total to be updated accordingly. Adding new invoice items and deleting existing ones is just as simple.
Grouped Rows: Flat tables, especially ones with lots of rows, can get quite confusing, so we dynamically group rows with the same value in a particular column together. Since this happens on the client side, it is very easy to make it interactive. For example, on the task grid, the rows are by default grouped by project, but if you'd rather see all tasks for a particular customer or manager displayed together, you can just change the grouping by selecting the new column from a dropdown, with no new request to the server. Totals for the different groups are automatically recalculated, giving you more possibilities to manage and survey your information.
At this point, data grids are of course nothing revolutionary, but this is really a step that any application that is serious about targetting business users must take. Spreadsheets are the medium of choice in these circles, and with good reason. The sooner we can bridge the gap between web app tables and desktop spreadsheet applications, the easier will it be to actually get business users to move their business processes into the "cloud".
]]>What has changed in OpenPSA 92011-07-01T20:25:48+00:002011-07-01T20:25:48+00:00http://openpsa2.org/midcom-permalink-1e0a4204eb7d82aa42011e0812e67e327c298399839We slowly but steadily approach the first beta release of O9, so it might be a good time to pose the question what exactly has changed in comparison to the previous 8.09 series.
Actually, the better question might be, what hasn't? One thing that remained the same is the full support for the Midgard 8.09 storage backend. That means existing installations can upgrade without having to make the jump to Midgard2 at the same time. While it is recommended to switch to the file-based startup and theme logic, using Pages and Styles should continue to work like it did in the good ol' days.
The need for a migration path to the Midgard 10.04 LTS storage backend was in fact one of the driving factors behind the OpenPSA 9 endeavor: Since the Midgard 8.09 series' EOL date draws ever closer, compatibility with more recent versions is becoming important for the project's long term viability. Work on this task began right after the creation of the O9 repository in November, and after lots of long, tedious debugging sessions which were greatly supported by the Midgard team (thanks guys!), both Midgard 10.04 and OpenPSA9 are now in a state where they work together quite nicely. A few minor irritations remain, but they should be sorted out in time for the stable release.
For the first release, we will also try to maintain API compatibility with MidCOM wherever possible, which means that getting Ragnaroek components to run on OpenPSA's framework should not require too much work. Some simple search and replaces in the source might be necessary (depending on the age of the component), but compatibility wrappers are in place to cover all the major API differences. The big exception here is Ragnaroek's Multilang feature, which is no longer available in more recent Midgard versions, and has thus been removed from OpenPSA as well.
So this is the base we're having right now: A framework that incorporates the experience gained from years of productive deployments of MidCOM-based systems and that paves the way for all the new Midgard2 hotness, with PHPCR on the horizon and more beyond.
Stay tuned for more articles detailing the actual application features, or, if you're impatient, get OpenPSA from github, play around with it, and let us know what you think!
]]>We slowly but steadily approach the first beta release of O9, so it might be a good time to pose the question what exactly has changed in comparison to the previous 8.09 series.
Actually, the better question might be, what hasn't? One thing that remained the same is the full support for the Midgard 8.09 storage backend. That means existing installations can upgrade without having to make the jump to Midgard2 at the same time. While it is recommended to switch to the file-based startup and theme logic, using Pages and Styles should continue to work like it did in the good ol' days.
The need for a migration path to the Midgard 10.04 LTS storage backend was in fact one of the driving factors behind the OpenPSA 9 endeavor: Since the Midgard 8.09 series' EOL date draws ever closer, compatibility with more recent versions is becoming important for the project's long term viability. Work on this task began right after the creation of the O9 repository in November, and after lots of long, tedious debugging sessions which were greatly supported by the Midgard team (thanks guys!), both Midgard 10.04 and OpenPSA9 are now in a state where they work together quite nicely. A few minor irritations remain, but they should be sorted out in time for the stable release.
For the first release, we will also try to maintain API compatibility with MidCOM wherever possible, which means that getting Ragnaroek components to run on OpenPSA's framework should not require too much work. Some simple search and replaces in the source might be necessary (depending on the age of the component), but compatibility wrappers are in place to cover all the major API differences. The big exception here is Ragnaroek's Multilang feature, which is no longer available in more recent Midgard versions, and has thus been removed from OpenPSA as well.
So this is the base we're having right now: A framework that incorporates the experience gained from years of productive deployments of MidCOM-based systems and that paves the way for all the new Midgard2 hotness, with PHPCR on the horizon and more beyond.
Stay tuned for more articles detailing the actual application features, or, if you're impatient, get OpenPSA from github, play around with it, and let us know what you think!
]]>The Road to OpenPSA 92011-05-13T18:45:32+00:002011-05-13T18:45:32+00:00http://openpsa2.org/midcom-permalink-2e6034387d9111e09cb9c713090c53175317The state of the codebase and the road ahead.
It has been nearly a year since the OpenPSA 8.09.9 release, but that doesn't mean that development has slowed down, in fact, it was quite the opposite: There was so much coding to be done that there simply was no time to write about it, but let's start at the beginning:
Right after the 8.09.9 release, the performance work in the MidCOM core ACL and NAP systems continued, leading to nice performance improvements, while new features like a generic object journal continued landing in OpenPSA, and existing ones like the jqGrid integration for displaying tabular information in a more interactive and useful way where rolled out all over the openpsa tree. Also, the usual refactorings and the grand UI overhaul continued.
Soon, it became apparent that the rate of change became too much for the MidCOM Ragnaroek branch, which was, after all, in stable maintenance mode. So at the Midgard Gathering in November 2010 it was decided to move OpenPSA into it's own repository. Since then, all development is done on github.
Along with OpenPSA, all the necessary dependencies were forked out, which provided the opportunity to work on evolving the MidCOM framework to OpenPSA's benefit without having to worry about the API compatibility requirements of a stable release series too much. This effort has been ongoing for quite some time and has resulted in the removal lots of legacy, unmaintained, unused, duplicated or otherwise unnecessary code.
Also, the framework's PHP usage has been brought a bit more up-to-date: At long last, exceptions were introduced into the codebase to replace the PHP4 era generate_error logic, abstract classes and interfaces are used a bit more widely now, and visibility keywords are actually declared instead of just written in the phpdoc block. There are even the beginnings of a unittest suite, which has a pretty good coverage of the invoicing workflow already
It's clear that the refactoring of the framework will still be ongoing for a long while, but there has been significant progress already, and existing deployments of the system work quite well, so the time might be soon right for a first public release.
The current thinking is that the first beta might be released this summer, so approximately two months from now. But you don't have to wait that long if you don't want to: OpenPSA is free software and can be forked on github.
It has been nearly a year since the OpenPSA 8.09.9 release, but that doesn't mean that development has slowed down, in fact, it was quite the opposite: There was so much coding to be done that there simply was no time to write about it, but let's start at the beginning:
Right after the 8.09.9 release, the performance work in the MidCOM core ACL and NAP systems continued, leading to nice performance improvements, while new features like a generic object journal continued landing in OpenPSA, and existing ones like the jqGrid integration for displaying tabular information in a more interactive and useful way where rolled out all over the openpsa tree. Also, the usual refactorings and the grand UI overhaul continued.
Soon, it became apparent that the rate of change became too much for the MidCOM Ragnaroek branch, which was, after all, in stable maintenance mode. So at the Midgard Gathering in November 2010 it was decided to move OpenPSA into it's own repository. Since then, all development is done on github.
Along with OpenPSA, all the necessary dependencies were forked out, which provided the opportunity to work on evolving the MidCOM framework to OpenPSA's benefit without having to worry about the API compatibility requirements of a stable release series too much. This effort has been ongoing for quite some time and has resulted in the removal lots of legacy, unmaintained, unused, duplicated or otherwise unnecessary code.
Also, the framework's PHP usage has been brought a bit more up-to-date: At long last, exceptions were introduced into the codebase to replace the PHP4 era generate_error logic, abstract classes and interfaces are used a bit more widely now, and visibility keywords are actually declared instead of just written in the phpdoc block. There are even the beginnings of a unittest suite, which has a pretty good coverage of the invoicing workflow already
It's clear that the refactoring of the framework will still be ongoing for a long while, but there has been significant progress already, and existing deployments of the system work quite well, so the time might be soon right for a first public release.
The current thinking is that the first beta might be released this summer, so approximately two months from now. But you don't have to wait that long if you don't want to: OpenPSA is free software and can be forked on github.
]]>Midgard in 20102011-01-11T08:00:00+00:002011-01-11T08:00:00+00:00http://openpsa2.org/midcom-permalink-804720c69afa11e2a31bcb713db89d509d50Wow, 2010 was quite a hectic year in the Midgard world. Here is a quick summary:
On Maemo, Midgard-powered applications like The Tablet of Adventure and MaeCalories provided tens of thousands of Midgard installations on mobile phones
Unfortunately at the same time the Midgard developer community has stayed quite small and insular. This will hopefully improve through easier installation, availability of Midgard libraries in Linux distributions and closer collaboration with the rest of the PHP world as a participant of the Zeta Components ecosystem.
We still also need to solve the project governance question of either running our own association or joining a major organization like ASF. The relation between Midgard and the GNOME project on which we heavily rely on should also be clarified.
On Maemo, Midgard-powered applications like The Tablet of Adventure and MaeCalories provided tens of thousands of Midgard installations on mobile phones
Unfortunately at the same time the Midgard developer community has stayed quite small and insular. This will hopefully improve through easier installation, availability of Midgard libraries in Linux distributions and closer collaboration with the rest of the PHP world as a participant of the Zeta Components ecosystem.
We still also need to solve the project governance question of either running our own association or joining a major organization like ASF. The relation between Midgard and the GNOME project on which we heavily rely on should also be clarified.
]]>Help Testing The OpenPSA Business Suite2010-11-08T14:52:47+00:002010-11-08T14:52:47+00:00http://openpsa2.org/midcom-permalink-d9ee2fa8eb4711dfb957a7e92a59e1a4e1a4As a result of last weekend's Midgard developer meeting in FSCONS, the OpenPSA suite has now been packaged for Debian and Ubuntu.
]]>OpenPSA 8.09.9 Released2010-06-25T13:59:35+00:002010-06-25T13:59:35+00:00http://openpsa2.org/midcom-permalink-e345acda806111df939af54334cc33973397A new version of OpenPSA was released together with MidCOM today.
Aside from the usual set of performance improvements and bug fixes, a number of new features has been added, for example some rather large enhancements to the invoicing workflow outlined here. There also has been a big number of fixes to the directmarketing module, making import of addresses, email sending and unsubscribe a lot more reliable.
The overhaul of the UI made good progress in this release as well, fixing some long-standing irritations and expanding interactivity mostly in the document management system. Last, but not least, there is a new journal/reminder functionality that allows you to add notes and reminders to every database entry that supports the relatedto system.
Enjoy!
]]>A new version of OpenPSA was released together with MidCOM today.
Aside from the usual set of performance improvements and bug fixes, a number of new features has been added, for example some rather large enhancements to the invoicing workflow outlined here. There also has been a big number of fixes to the directmarketing module, making import of addresses, email sending and unsubscribe a lot more reliable.
The overhaul of the UI made good progress in this release as well, fixing some long-standing irritations and expanding interactivity mostly in the document management system. Last, but not least, there is a new journal/reminder functionality that allows you to add notes and reminders to every database entry that supports the relatedto system.
Enjoy!
]]>New Invoicing Features in 8.09.92010-05-23T11:23:55+00:002010-05-23T11:23:55+00:00http://openpsa2.org/midcom-permalink-44131eb0666011dfadc2d1b7f40928d028d0This is a small teaser about the new invoicing functionalities in the upcoming OpenPSA 8.09.9 release
This is a small teaser about the new invoicing functionalities in the upcoming OpenPSA 8.09.9 release
The invoicing workflow is getting a rather large overhaul for the next OpenPSA release. Here's what's in store:
Invoice items
Invoices are now itemized, i.e. every deliverable that is part of the invoice gets its own position which can be edited as necessary. New positions can be added and old ones removed. Invoices from subscription runs get autopopulated with the correct values
Per-customer due date & VAT presets
Up until now, the default due date an VAT for invoices could only be set globally. Startung with 8.09.9, you can set this per customer, thus reducing the amount of manual correction needed later
PDF generation
This one has been on the to do list for quite a while. OpenPSA can now automatically create invoice PDFs based on the installation's layout. Please note that the rendering has to be implemented (based on FPDF) in the OpenPSA instance to allow for custom layouts
That's all for today, but there are more changes in the pipeline, so stayed tuned!
]]>This is a small teaser about the new invoicing functionalities in the upcoming OpenPSA 8.09.9 release
This is a small teaser about the new invoicing functionalities in the upcoming OpenPSA 8.09.9 release
The invoicing workflow is getting a rather large overhaul for the next OpenPSA release. Here's what's in store:
Invoice items
Invoices are now itemized, i.e. every deliverable that is part of the invoice gets its own position which can be edited as necessary. New positions can be added and old ones removed. Invoices from subscription runs get autopopulated with the correct values
Per-customer due date & VAT presets
Up until now, the default due date an VAT for invoices could only be set globally. Startung with 8.09.9, you can set this per customer, thus reducing the amount of manual correction needed later
PDF generation
This one has been on the to do list for quite a while. OpenPSA can now automatically create invoice PDFs based on the installation's layout. Please note that the rendering has to be implemented (based on FPDF) in the OpenPSA instance to allow for custom layouts
That's all for today, but there are more changes in the pipeline, so stayed tuned!
]]>OpenPSA 8.09.8 Released2010-03-27T01:44:00+00:002010-03-27T01:44:00+00:00http://openpsa2.org/midcom-permalink-c109cc7a500311dfa2cef5c580d5f52bf52bThe main focus of this release were workflow and usability improvements, along with the usual assortment of bugfixes and cleanups.
The most noteworthy changes are:
More interactivity with AJAX based filtering, expandable trees and other JS improvements
Rewritten relatedto system for greater flexibility
more options for the invoicing workflow
New form layout
Updated Finnish translations
and many more
OpenPSA can be installed from the MidCOM PEAR channel or from the command line with Datagard.
I seem to have not blogged about this, but Open Advice, our book on Free and Open Source Software: what we wish we had known when we started, was published last month.
