Robert Lemke – On FLOW3, TYPO3 and Fluent Development with PHP

FLOW3 1.1 Beta Releases

Tue, 15 May 2012 09:34:00 +0200

After several months of development, we have now closed the lid of the feature box and are busy preparing the releases. In this post I'll give you a quick overview of what you can expect during the next few weeks. The first feature release after a 1.0 is a special one: with all the feedback we got and the real applications we've been working on ourselves, the ideas for new features and improvements are endless. Without surprise everybody wants to get his own pet tweak into 1.1 and it's hard to draw the line which patches need to be postponed for a later version. FLOW3 1.1 contains various new features but we also took the opportunity to adjust some important APIs, such as the Model View Controller mechanism. The upcoming FLOW3 version is not 100% backwards compatible and this is what we expected. But we found a nice way to ease the upgrade pain: a code migration tool can automatically adjust your code to fit the most important API changes. And for the few parts it can't refactor we'll provide detailed upgrade instructions. We plan to release two beta versions, followed by the stable release of FLOW3 1.1. If necessary, we'd also release additional betas or adjust the timeline in order to meet our quality standards. Each of the beta releases has a specific goal: FLOW3 1.1 beta 1 contains all improvements we want to see in the final version. The goal for this release is to get feedback on the compatibility and stability: does your project still work fine after following our upgrade instructions? What did we miss? Although the first beta contains most of the code of the new major features (HTTP, I18N, content security, ...), those features are not fully documented yet. This is the goal for the second beta release: FLOW3 1.1 beta 2 contains all features, including the big new ones. The goal for this release is to also get feedback on the HTTP foundation, the localization and translation and all the other gems we put into 1.1. We will provide documentation for all of the new features so you know how to test and use them in your own projects. Once we are confident that 1.1 works equally fine for you like it does for us, we are ready for a stable 1.1 release. We currently discuss a few ideas regarding the future release cycle and overall process of releasing new FLOW3 versions. In general we need to satisfy both needs: early access to new features (rather every two weeks than months) and plannable stable releases (rather every three months than every few weeks). What's your take on this, which rhythm fits you best?

FLOW3 Codesprint and FLOW3 1.1

Thu, 22 Mar 2012 08:54:11 +0100

Complaint number one by developers using FLOW3 – and that includes the core team – has been the compilation speed in a development context. There are times FLOW3 needs to flush all code caches which can result in several seconds of waiting time on the next hit, when the proxy classes are rebuilt. In order to tackle this, we scheduled a whole week for a code sprint in Lübeck. The proxy building routines are one of the oldest parts of FLOW3 and although we revised the actual compiler routines some time ago, the logic for matching classes and methods for the Aspect-Oriented Programming support has remained unchanged. Andreas Förthner, Christopher Hlubek and myself discussed ways to optimize the matching and during the past week Andi refined the concept and turned it into code. We always hoped that our approach would speed up compilation time, but we didn't expect the big performance boost we eventually reached. Now, in turns of numbers that is … well, we keep the actual numbers as a little surprise for the first FLOW3 conference, but you'll certainly like it! Christian Müller also joined us here in Lübeck and did a great job going through all pending issues, checking if they are still valid, asking questions to the reporters and solved various tickets right away. Christian really is our good soul when it comes to community support, there's hardly a day or night time you don't spot him in our IRC channel. We seem to have most of the code done for a FLOW3 1.1 release, except the new HTTP support which is still in the making. Nevertheless, you may expect a 1.1 release during the next weeks, including a few neat surprises. We could also fix the few failing tests which gave Smilla reason to cry so desperately (see picture). What are you looking forward to for future FLOW3 releases, what would delight you most?

Conferences in June 2012

Wed, 22 Feb 2012 12:11:51 +0100

This June is packed again with conferences – always a nice opportunity to share some insights we had during the development of FLOW3 and TYPO3 Phoenix. I try to keep the balance between being present at such events and doing my homework (that is, working on our next-gen CMS and FLOW3 versions) but this June I'll attend three conferences within two weeks. First up is the International PHP Conference (spring edition) in Berlin. I'll give some half-day FLOW3 tutorial and additional talks about how third-party libraries can be incorporated into your FLOW3 project. Next is the Dutch PHP Conference which will also feature a 3-hour FLOW3 tutorial and a packed talk giving some distilled overview of FLOW3. Finally, I'll fly to Québec and enjoy our very first Canadian TYPO3 conference. It's awesome that the team around Patrick Gaumond made this happen! The Call for Papers will start soon and if I'm lucky I can hold a talk or two ;-) Looking forward to some inspiring events – even if I need to leave my family at home alone for a while.

Results of the Research & Development Meeting

Tue, 21 Feb 2012 14:40:59 +0100

Back when we designed the structure of the TYPO3 Association, we envisioned the Research & Development Committee to be the body where the high-level technical vision and long term goals were defined. The Steering Committee on the other hand had the task to keep an eye on the overall strategy of the TYPO3 project and its product. With the abolition of the Steering Committee – as a consequence from refactoring of the TYPO3 Association – the need for a new body taking care of the strategy arose. Reason enough for the Research & Development Committee to meet up in Hamburg for working out a proposal. Moving Strategy to the Community The ideas for such a new body have been in the wild for some time already and were discussed every now and then in the Steering Committee but also by individuals during community meetings. For the last Steering Committee meeting in Basel, I couched the ideas into terms and called the new body "Product Board". Meeting Results Apart from polishing the Product Board concept, we had the following points on our agenda: TYPO3 branding work group (TYPO3 Phoenix, TYPO3 Flow, TYPO3 XY) TYPO3 version numbering GSoC 2012 organization admin Joint development budget 2012 (that is, TYPO3 v4 + TYPO3 Phoenix) In short, we have discussed the next steps for finding a consistent naming scheme for the products of the TYPO3 community, agreed on a concept for the version numbering scheme of the active TYPO3 CMS branch, decided on the GSoC 2012 org admin position and discussed the common budget of TYPO3 v4 and TYPO3 Phoenix. You may want to read the full agenda and the protocol for the respective discussion results. Your Feedback As for the Product Board concept, we now ask the active TYPO3 community – and that means, every member of any of the TYPO3 teams you can find at forge.typo3.org – for their comments. You may, at your option, discuss this in your team, leave comments in the Google Doc or simply send an email to one of the participants of the meeting. We'll collect all feedback and propose an updated concept in case it becomes necessary. Just follow this link to the Product Board concept document. And if you run across anybody who might be interested in giving feedback, please point him / her to these documents or blog post. I am quite confident that we have found a good solution which satisfies the wish of many to have a more visible leadership in the TYPO3 project. And all that in a good balance of pragmatism and legitimacy through the community.

I'm Fine with Cross-Country

Thu, 02 Feb 2012 15:02:56 +0100

Olivier Dobberkau sent a few rants today via Twitter, stating that the roadmap of TYPO3 Phoenix is so hard to find (here) and that it's so hard finding information about how to contribute (here). I think that the former doesn't make sense and the latter is not true. First of all, it is – in an Open Source Project – hard, if not impossible, to set up a roadmap which is likely to be kept. The whole development effort relies, even if there's a budget from the TYPO3 Association, mostly on voluntary work. The members of the FLOW3 / Phoenix team are very committed and enthusiastic, but at the same time it can easily happen that they are not available due to customer projects, diploma theses and so on. Volunteers also tend to prefer working on topics which are currently relevant to their own work and what is most fun to do. How could we foresee that and put it into a roadmap? Other projects are in the same situation. Try finding the Drupal roadmap or that of Joomla. Wordpress only mentions the code names of its future releases. Projects like Symfony don't even try to publish a roadmap in the first place. To put it bluntly: I am convinced that publishing a roadmap for an Open Source product which promises certain features until certain dates is neither serious nor realistic. That doesn't mean we have no high-level goals. But they are moving targets and we discuss and document them during our meetings and at TYPO3 Forge. The team and I personally would love to communicate a lot more about TYPO3 Phoenix. We would also love to have a salaried designer, a shared office, a marketing person and two more fully employed developers. There's no website about TYPO3 Phoenix online at the moment because the new website is not ready yet. There is an awful lot of reasons why certain things just don't happen. All a big misery, is it? I don't see it that negative though. I could wish for a lot more, especially more time to spend, but I know that those involved doing their best possible and are flexible enough to adjust to the ever-changing requirements. We always focus on the next step in front of us and regularly exchange ideas about the overall strategy. And we'll continue with that until someone can show (and walk with us) a better path. What's the best way for you to stay in touch with plans for the product? Do you need an outlook further than the next version?

Small Teams for Small Wins

Wed, 12 Oct 2011 10:12:00 +0200

Today I stumbled over a blog post by Dhanji R. Prasanna, a former project member of Google Wave, who describes how even the most talented people cannot come across the complexity of large teams – and what impact it has on motivation and success. Ever since we launched the project with the codename Phoenix, all kinds of people bugged me that one of our primary goals should be to become a reasonably big team so the risk is spread on more shoulders. I can understand that some fear the Bus Factor, but adding more developers to the team doesn't solve it really. We are and always have been open to inviting new members to the team. What's important though is that we can divide the big team into smaller, independent teams of 3-4 people who can pretty much decide on their own. I recommend reading Dhanji's blog post about the Mythical Man-Month at the Google Wave project.

FLOW3 1.0 Training Switzerland

Wed, 31 Aug 2011 17:08:41 +0200

If you're planning to take a closer look at FLOW3 and live in Switzerland or Southern Germany, there's a great opportunity for you to delve right into essentials: I'll give a one day public training in Zürich this September. The full-day workshop will leave you with a comprehensive overview of all essential parts of FLOW3 and gives you enough information for your next steps. As FLOW3 1.0 is right around the corner, there is probably no more effective way to get started in time. snowflake productions organizes the event. The session is held in German (well, no Swiss German, I'm afraid) and you better be quick with signing up if you want to catch the early bird price. All further information can be found on the snowflake website.

Hello World! Part the Second

Tue, 23 Aug 2011 10:04:19 +0200

Watchful followers of my emails and tweets will have noticed that I've been offline for two weeks. It was for the birth of our second daughter, Nika. Needless to say that my wife and me are overwhelmed and very happy to have another gorgeous and healthy daughter. Smilla on her side is pretty excited to have a little sister now and it's touching to see her caring for Nika. We are doing surprisingly well considering what a newborn can potentially do to your daily routine and since Monday I'm back online, working on the upcoming FLOW3 release. I'd like to thank all of you guys who sent us their good wishes. It's so great to get reminded again that the TYPO3 and FLOW3 community actually consists of real humans, and really friendly ones, too ;-) In case you wonder how Smilla looks like today, here's a recent photo of her at Flickr.

How I Started with TYPO3

Thu, 04 Aug 2011 16:00:37 +0200

Today is my tenth anniversary! On August 4th, 2001 I uploaded my very first TYPO3 installation – not knowing that it would change my life. That sounds very pathetic – "it changed my life". But it really did, in many ways. Back then, somewhen in March 2001, I discovered TYPO3 after searching for a tool which allowed me to manage my website and has specific support for image conversion. I saved the bookmark for later and forgot about it until I prepared for a half-year stay in Barcelona. At that point, neither programming nor the web have been part of my daily job. I've been working at Studio Hamburg, a big technical provider for TV and movie productions. I had piled up literally hundreds of extra hours as a video technician and planned to take some time off. To keep my friends and family up to date, I needed a proper website which I could feed from any cibercafé. So eventually on August 4th I uploaded the first zip file with my TYPO3 website to a shared server. Four weeks later I was online with my brand new website (as you can see in the screenshot) – it even featured a guest book! After I returned from Barcelona, my enthusiasm to change the world didn't quite match with the big company I was working in – so I quit my job shortly after my return. I started studying Applied Cultural Studies in Lüneburg, met friends for life and ... my future wife. As I seemed to have reached all possible goals at university (my wife), I decided to work full time as a freelancer building TYPO3 websites. And thus since 2003 I am just that, a TYPO3 developer. How did you start with TYPO3?

FLOW3 Supports PHP Vendor Namespaces

Wed, 29 Jun 2011 12:47:27 +0200

The result of the last big refactoring before FLOW3 1.0 now made it to our review queue (typo3.org login required): vendor namespaces support. This new feature has two great benefits: first of all we don't need a central package key registry (like the one we have for TYPO3 4.x extensions) and secondly, it allows anyone to seamlessly integrate third-party packages, such as Symfony2 components and Zend Framework components or virtually any other PHP 5.3 based library. Namespaces in PHP 5.3 One of the key features of PHP 5.3 was the introduction of namespaces. This can be a big enabler when it comes to mixing libraries developed by different projects and companies (aka "vendors"): Each of them uses their own namespace for class naming, thus avoiding name clashes when the components are put together. Namespaces in a programming language can be compared with the Internet's domain name system – once you own a certain domain, you're completely free with naming your directories and files because the domain name gives you your own namespace to work in. Before we had namespaces, the TYPO3 project was using its own namespace-like system: extension keys. Once you registered an extension key at typo3.org, you could be sure that it's safe to use a class name like "Tx_MyExtensionKey_Foo" in your code. That works pretty well in our part of the universe but also has a few drawbacks: you need to be online for registering a new package key other PHP projects don't have a typo3.org extension key it's difficult to find suitable extension keys because easy names like "news" can only be owned by one registrant FLOW3's Implementation The implementation of vendor namespaces support took some intensive 7 working days. All parts of FLOW3 somehow dealing with packages, package keys or PHP namespace parts had to be adjusted and backed by new tests. The most visible part of all is the new parent namespace of the framework packages. Our de-facto vendor namespace in the past has been "F3" – the namespace of all packages followed the pattern F3\PackageKey\Foo\Bar ... Since FLOW3 is part of the TYPO3 project, the core team decided to choose "TYPO3" as our new vendor namespace. The Object Manager for example is now known under the class name TYPO3\FLOW3\Object\ObjectManager. Here's a comparison between old and new for namespace related features in FLOW3: BeforeAfter Package Key FLOW3FluidMyTwitter TYPO3.FLOW3TYPO3.FluidCom.Acme.MyTwitter Namespace F3\FLOW3F3\FluidF3\MyTwitter TYPO3\FLOW3TYPO3\FluidCom\Acme\MyTwitter Packages/… Framework/FLOW3/Framework/Fluid/Application/MyTwitter Framework/TYPO3/FLOW3Framework/TYPO3/FluidApplication/Com/Acme/MyTwitter resource:// FLOW3/Private/Templates/…MyTwitter/Private/… TYPO3.FLOW3/Private/Templates/…Com.Acme.MyTwitter/Private/… YAML FLOW3: security: enable: y TYPO3: FLOW3: security: enable: y Those third-party libraries we already used (Doctrine, the YAML parser, ExtJS) will be moved into dedicated packages. Doctrine for example will now be located in the directory Packages/Framework/Doctrine/ and its classes can be loaded without further ado by the FLOW3 class loader. Updating Existing Code Such a big change doesn't come without adaption of existing FLOW3 packages. If you're one of those who already created FLOW3-based packages, you'll be happy to know that most of the code adjustments will be done automatically. Along with the new feature, FLOW3 comes with a migration script (located in Packages/Framework/TYPO3/FLOW3/Scripts/) which scans existing packages for necessary changes to PHP code, YAML settings and HTML templates. All references to the FLOW3 framework and its related packages (such as "Fluid" or "Party") will be updated. After the migration your own package will reside in the "MyCompany\[old package key]" namespace (ie. replacing "F3" by "MyCompany") and you will have to do a global search and replace to adjust your package to the vendor namespace you intend to use in the future. As the last step you'll need to manually move your package to the correct directory and flush the caches. Next Steps The FLOW3 core team is currently reviewing my patches and we're migrating our existing code base (TYPO3 5.0, the T3CON11 site and plugin and the Blog). We already were quite busy updating the FLOW3 manuals last week and will continue with that for certainly two weeks. Along the way we'll fix bugs we don't want to see in the 1.0 beta 1 and keep focused on finding the shortest, yet reasonable way to the first beta release. As it seems, we won't be able to keep the tentative release date (scheduled for next week) but we don't want to miss it by months either. As soon as all 1.0 features are basically working and the documentation is updated, we'll release FLOW3 1.0 beta 1 – and it would bug me a lot if that wouldn't happen in July ...

Go Community! The new TYPO3 Association

Thu, 16 Jun 2011 11:15:33 +0200

During the last General Assembly, the Board and Steering Committee of the TYPO3 Association decided on a few important changes to the bylaws. These changes give more power to the supporting members of the Association, remove conflicts of interest regarding the deciders and receivers of the budget and, most importantly, move the strategic decisions to the community. Although the goals, to provide more transparency, democracy and integrity, were easy to agree upon, personally I had to get used to effectively leaving the association I co-founded. Years ago when Kasper, Julle and I first talked about the idea to found a TYPO3 company or foundation, the primary goal was to create a body which raises funds for long term and important development tasks which could not easily be found in daily projects or by one-time sponsorships. Fast forward, in 2011 the TYPO3 Association does what we originally planned it to do, but it also stands for much more which we originally did not intend. Running an association always comes with a lot of politics, opinions and eventually envy and striving for power. If there's an "official" body for the TYPO3 project, it is, for some, very attractive to get there. You could have the impression that being part of the TYPO3 Association means having the power to decide on the TYPO3 project. But there's very little truth to that. In reality, most decisions affecting TYPO3 were taken by the community. It was just the case that some of those who had a say in the community were also member of the Steering Committee or Board (which is also natural, because we tried to build up a group of people who act in the interest of the TYPO3 community). The problem with that is that those who are not part of the Steering Committee might feel excluded and speculate about conspiracies going on behind the scenes. Probably due to our lack of experience with a FOSS association, we communicated wrongly in the beginning. We wrote news like "The TYPO3 Association released a new version of TYPO3" or "The T3A organizes the T3CON". That was plainly wrong – it always have been people and companies from the TYPO3 community who did all the hard work. When we realized this communication mismatch, we started emphasizing the important role of the community members. Now, the decisions we took for the refactoring of the TYPO3 Association set forth this ambition in the most consequent way: We effectively move the Steering Committee to the community. You'll want to read Daniel's article giving some more information on the so called "Perestroika Project". What you can expect during the next months and starting in 2012 when the new bylaws take effect is that we've set up a structure in the TYPO3 Association which takes care of the finances and trademark in a responsible and transparent way and a new team, positioned in the community, discussing and taking decisions on the strategy for the TYPO3 project. I'm really looking forward to these exciting times and feel that we have taken the right decision.

Continuous Delivery – Interview with Jez Humble

Tue, 14 Jun 2011 16:21:35 +0200

At T3CON11SF I had the opportunity to record a short interview with Jez Humble, co-author of the book "Continuous Delivery" and principal at ThoughtWorks Studios. He's a brilliant and funny englishman (working together with guys like Martin Fowler) and a (humble) celebrity in the agile community. At last year's Frankfurt edition of T3CON we started inviting speakers not being involved in the TYPO3 project to bring new insights and perspectives into the TYPO3 community. This perfectly matches with the tendency to further professionalize our work and explore fields way beyond the average PHP developer's scope. In February 2010 I was reading the rough cuts version of a book called "Continuous Delivery". The topic really caught me and while I was talking with Jürgen I mentioned how great it would be having Jez Humble speaking at our conference. Jürgen arranged everything and Jez gladly accepted to hold a keynote in the San Francisco edition of the TYPO3 conference. Continuous Delivery means that your development style and processes lead to stable software which could potentially be released at any time by a click of a button. It's a lot about automation, discipline and a new mindset, it requires configuration management, lots of different kinds of automated tests, is a perfect match for cloud hosting and – just makes a lot of sense. We have designed FLOW3 with these agile processes in mind and are already using a big part of the tools and techniques Jez recommends. If you are somehow in the development, deployment, hosting or management of a software project, you'll want to read that book – and watch the interview of course ;-) Update (15.06.11): The full keynote Jez gave at T3CON11SF is now available at Vimeo – don't miss it!

Flying to T3CON11 San Francisco

Sun, 05 Jun 2011 20:59:57 +0200

In 2005 a group of brave guys organized the very first TYPO3 conference. Jürgen Egeling certainly was the bravest of all, as his company took the financial risk, but not the gain. At one ocasion during the event (which was called Tycon3 back then), Jürgen said that his ultimate goal would be a TYPO3 conference held in San Francisco. Flying to T3CON11 San Francisco from Robert Lemke on Vimeo. I hope that Jürgen won't stop organizing T3CONs now. It's pretty cool that Karsten and I are now actually sitting in the plane to the first T3CON San Francisco edition. We'll stay 10 days in, dare I say, the nicest metropol in the US, preparing conference sessions, meeting with TYPO3 and FLOW3 guys. I'm looking forward to meeting Jez Humble from Thoughtworks, the guys from Sencha, from then Aloha project and in general enjoy the inspiring athmosphere of the bay area. I'll keep you posted and hopefully be able to record the one or the other talk for sharing with you. Rumors say that Kasper brought a truckload of his video equipment again, so coverage of our stay should be granted :-) Follow my tweets and check out my blog for some news soon ...

PHP Conference 2011 in Berlin

Mon, 30 May 2011 12:16:14 +0200

I just finished my talk about FLOW3 1.0 at the International PHP Conference in Berlin. As usual, it was great meeting the usual suspects in the lobby but also see new faces in the session room. This talked aimed on getting an overview of the current state of FLOW3 and its major features. I really had to hurry through a lot of topics to fit in at least some of the exciting parts into the 45 minutes speaking time. Nevertheless I got the impression that my talk was well received and I spent half an hour with some who listened to the talk, discussing some implementation details and answering questions. As usual, my slides are available on slideshare. I recently decided to switch my username there (now "robertlemke"), so make sure to follow my new user if you like. Fluent Development with FLOW3 1.0 View more presentations from Robert Lemke

Roadmap & Missing Features for FLOW3 1.0 Beta 1

Fri, 06 May 2011 11:43:00 +0200

The next release of FLOW3 will be 1.0 beta 1 – that's no big news anymore. However, as we had to adjust the original schedule, you might ask yourself when the first beta version will be available. In order to get a realistic release date, we now ask for feedback by those who already gathered experience with the current Git master version of FLOW3. Direct work on the FLOW3 feature set had to take a back seat for a while as we were quite busy with the development of TYPO3 5.0 and the launch of the T3CON11 website. Both projects were very helpful for finding the weak spots in the current FLOW3 alpha and identify some API changes and missing features we'd like to see in the first beta release. The work on TYPO3 continues to be very intensive over the next weeks, but since some companies and individuals already started using FLOW3 for customer projects we don't want to unnecessarily postpone the FLOW3 final. Today I updated the roadmap for the FLOW3 Base distribution and attached some tentative dates to the next planned versions. Please don't nail us on June 17th for the first beta release – we're aiming for it, but a few factors can still change the date. In the FLOW3 mailing list I sent a call for feedback. I'd like to ask those who are familiar with the current (not yet released) version of FLOW3, what features, concepts, API changes are still missing for 1.0 beta 1. And "beta" from my understanding means that basically all features we plan for the final release are there, API's won't change unless really necessary. It also means that the code still contains bugs, might not be as performant as you wish and documentation is not complete. After maybe three beta releases, which gradually improve stability and performance, we'd publish a release candidate which contains no known bugs anymore. The FLOW3 team is aware of several open tasks, but what I'd love to know now is your assessment – what's missing? Please answer in the related thread in our mailing list, in the comments of this post or – if you spotted a bug – just file it in our issue tracker.

Designing Error Messages

Tue, 15 Mar 2011 17:33:59 +0100

As an A-380 pilot, a warning which says that bit 9 of data package 98887 sent through your ARINC 429 data bus is unexpectedly 0, will keep you busy for a while searching for the actual problem. On the other hand, a nicely crafted error message which states "Engine #3 is on fire" will give you a much better idea of what's currently happening on board. What's so cool about being a pilot is that you have checklists and procedures for almost any situation. Your airborne computer will most likely suggest to activate the fire extinguisher and let the remaining engines take over the load of #3. Funnily most developers – and yes, especially framework designers – don't care much about error messages. Most checks are done at that level a possible error my occur – and the message will state just that, something like "Unexpected Type" or "Invalid Argument Bckblst::$fsPtr". Really helpful. FLOW3 can't really acquit itself from this practice, but it's getting better and better. The strategy (wow, a strategy ;-) we have for error handling and especially for messages is to first and foremost make sure to implement safe guards which protect the API from causing fatal errors. The corresponding messages for these exceptions are very low level, but hopefully telling enough to spot the rough location of a problem. The messages you, a developer using FLOW3, will hopefully see however, are designed differently: They should tellwhat went wrongwhere it went wrongwhat was expectedand what you can possibly do to solve the problem Furthermore we use a unique number (the unix timestamp of the time we were implementing the error message) so you can easily find the related source code and communicate with other developers about the thrown exception. There's a lot more to say about error messages, especially when it comes to the TYPO3 Phoenix UI. A nice introduction into this topic is – you wouldn't expect that – a guideline by Microsoft. It features many bad and some good examples for communicating all kinds of failures. Speaking of burning engines – did your operating system ever confront you with an lp0 on fire error?

Protected vs Private

Fri, 11 Mar 2011 08:07:19 +0100

The Symfony and Doctrine2 project recently changed protected functions and properties into private in order to provide a well defined public API. While I agree with the principle, this has some bad side effects for FLOW3 code. In the TYPO3 project we learned the Open / Closed Principle the hard way. Because TYPO3 started as a PHP3 project more than ten years ago, all methods and properties were public by default – and extension developers made heavy use of many functions of the TYPO3 core which were never meant to be public. This is actually one of the reasons we finally decided to rewrite TYPO3 from scratch – because any refactoring of the core was like playing with the fire, as we couldn't know how many extensions were relying on the part we were going to change. The least we could do was using the public and protected keywords to document which code parts could be used by other classes. However, sub classes still might rely on protected methods which are not meant to be part of the publicly supported API. The logical next step is to mark those methods as private. Problem solved? When we discussed using the private and final keywords two or three years ago, we concluded that this wouldn't solve our problem completely: there are still public methods (which need to be public because they are used by other classes in our framework) which we don't consider part of the public API. So as we cannot prevent usage of these functions technically, we chose to go for a white list approach: all classes, methods and properties which we consider part of the public API (and hence make sure that we stay backward compatible) are labeled with an @api annotation in the respective doc comment. Our API documentation contains only those code parts and give you a clear overview of what API you may use. But why not use final and private keywords for the rest? Because it gives us some headaches with our proxy mechanism. As you might know, FLOW3's AOP implementation (and since recently also our DI support) relies on proxy classes and hence the ability to extend and override the original class. This works fine as long as your class is not final and its methods are either public or protected. While there certainly is a way to circumvent this (I know one, but it makes me shiver), life would be so much easier without private and final. So the question remains: should FLOW3 support and use private / final methods and classes? Or do @api annotations make more sense to you?

TYPO3 Codesprint Berlin 2011

Tue, 08 Mar 2011 11:04:27 +0100

Last week we met with a group of more than 40 members of the core and security team plus additional active members of the community for the TYPO3 Codesprint Berlin. Technische Universität Berlin provided us with enough space again for discussing ideas, new concepts and actually implementing some of them right away. Besides having great coffee we also decided on the next steps for TYPO3 4.6, 5.0 and FLOW3. The goal for this meeting was not so much achieving visible results but rather to foster communication and exchange of ideas between the team members and kickstart implementations or try out solutions. Measured on this scale, the week was a great success because many new topics popped up which we couldn't have planned for before the meeting. On the arrival day we started with a recap and some presentations outlining the current state of TYPO3 4.x, TYPO3 Phoenix and FLOW3. While those parts get you a really unproductive feeling (one guy talking, the rest listening) it was necessary to bring the whole team up to speed. I for my part spent most of the time with Phoenix and FLOW3 related topics, which makes my summary a bit biased. The hostel we booked for most of the team was ... uhm ... rather underwhelming and we'll surely not choose it again. But despite the hard first night on thin mattresses the v4 team dove right into Git, Gerrit and Jenkins. Weeks before a team led by Peter Niederlag and Karsten Dambekalns had prepared the migration from Subversion to Git for the TYPO3 v4 branch – including the well-proven workflow with Gerrit and Jenkins we already introduced for FLOW3 and TYPO3 Phoenix. The migration went flawless but many devs had to handle the Git-first-day shock and get used to the new review tools. Xavier Perseguers (from Switzerland) was elected as the release manager for TYPO3 4.6. While he outlined a few of the plans for the next TYPO3 version, he also revealed the code name for version 4.6: "--rebase". Did I mention the coffee? After our bad experience with greyish water from the local vending machine, Ben van't Ende organized a professional Barista including some luxury equipment who made sure we had some proper espresso and cafe latte for our sessions. This was only possible of course due to our generous sponsors – thanks a lot to you guys! During the sprint the Phoenix team went through open tasks and decided on which to solve in which order. As we are currently working on a real website based on TYPO3 Phoenix, its demands were the natural driver and goal setter for use while we prioritized the next features. Another big topic we're currently addressing is the cleanup and finalization of the two big refactorings (Doctrine 2 support and new proxy mechanism) we recently applied to FLOW3. As a result TYPO3 Phoenix now finally works on top of Doctrine and the all new object management. Once we have optimized and documented these new features, they'll give developers an awesome user experience, you'll see ;-) Present members of the UI team (ie. Jens, Berit, Aske, Christian and Rens) agreed on a transparent workflow for the whole concept-design-implementation-qa cycle and discussed steps to improve communication with the team. Aske, who is our newest member in the team, implemented the page position selector which editors need for creating new pages. Other features we tackled during the week were creation and deletion of content elements, moving existing pages and the switch to ExtJS 4.0. Of course there was also some nice water cooler talk (well, espresso machine talk) circling around common projects for both, the v4 and v5 team. We talked about image building and conversion (aka GIFBUILDER 2), file abstraction layer and resource handling, a common design for the dashboard and of course quirks and other character traits of Gerrit & Jenkins. In total it was an inspiring and also fruitful sprint – not so much on the global side, with big results to present, but many details and future plans could be addressed. I guess most of us left with a idea of where we're going next – and with a cold, because the hostel didn't feature artight windows or warming blankets. There are a bunch of photos from the code sprint in my and Steffen's flickr albums.

Vendor names in PHP namespaces

Thu, 24 Feb 2011 11:37:51 +0100

Since an increasing number of PHP projects are going to use namespaces, it gets more important to agree on a scheme which avoids naming conflicts. The current best practice is to use the "vendor name" as the top level namespace – but who says that your vendor name is unique? The approach of FLOW3 was – until now – to force all its packages to use a schema like "F3\PackageKey\Foo\Bar\..." for the naming of their classes. In order to keep the package key unique, we force suggest that developers register a package at forge.typo3.org. This essentially allows us to guarantee that each fully qualified class name is unique world wide. This approach would work fine within the TYPO3 / FLOW3 universe, but what we really want is to foster code reuse and collaboration among other PHP projects. The PSR0 standard initiative was certainly a good step into this direction and the suggestion by Fabien (ie. essentially to put not any real restrictions on the namespace as long as the top level part is the vendor name) is the way to go. Following the current best practice I'd like FLOW3 to support class names like \[Vendor]\Foo\Bar\Baz. In case of Fluid that would be a namespace like \FLOW3\Package\Fluid (because Fluid is a project of the FLOW3 team). The actual Doctrine2 code would reside somewhere in the \Doctrine\... namespace (Doctrine project is the vendor) whilst a possible Doctrine2 wrapper for FLOW3 would be put into a namespace like \FLOW3\Package\Doctrine2. The big question now is: how can we achieve that the vendor name is almost certainly unique? For its bundles, Symfony2 currently establishes the best practice to use the Github user name as its vendor name. But in the TYPO3 / FLOW3 project we don't use Github as we have our own servers at git.typo3.org. If I would start using "RL" as a vendor name, it is not unlikely that someone will do the same. Even with "RobertLemke" I wouldn't be on the safe side. Do we need a schema or registry for vendor names?

FLOW3 1.0 beta 1 release date

Wed, 23 Feb 2011 08:28:14 +0100

Some of you might have noticed that we let the originally planned release date for 1.0 beta just pass (I announced that it would be February 18th). The reason for it is that Karsten and I were working on some heavy last-minute refactoring of the FLOW3 core, namely the Doctrine2 integration and a new proxy building mechanism. We have solved this so far but still need to clean up code, integrate the commits, review and update the documentation. We also have a full week code sprint next week in Berlin where almost everybody of the TYPO3 v4, v5 and FLOW3 core team is present. Therefore, my current guess on a release date is something like mid March. Making Doctrine2 our default persistence layer gives us a lot of opportunities (and less code to maintain ourselves). This will really be amazing! And with the new proxy building mechanism, you can finally use the "new" operator instead of the ObjectManager->create() function: /** * @scope prototype */ class MyPrototype { /** * @inject * @var \F3\MyPackage\Service\MyService */ protected $myService; public function foo() { $this->myService->do(); } } ... $myPrototype = new MyPrototype(); $myPrototype->foo(); Even though you use the new operator, dependencies like the service above will be injected. Without any further XML / YAML / Brainf*ck configuration ;-)

It takes all kinds to build a world

Tue, 15 Feb 2011 19:15:56 +0100

Ten years ago, I'd never have thought that an Open Source project could give me enough fuel to stay for such a long time. And although being part of it can require a lot of energy at times, it was certainly the friendly community which made me eventually quit my old job and dive into TYPO3 completely. Diversity and common value is what drives us ahead personally and in the end also TYPO3. The TYPO3 project has always been a great place to be: many passionate enthusiasts willingly spending their spare time on sometimes tedious work; because we are proud of what the community can create and thrilled about the challenge to make it even better. Personally, this has always inspired me and let me in turn inspire others. That's what some of the "old boys" in the community identified as our common vision during a meeting in Kettrup Bjerge: Inspiring People to Share. Not a marketing claim, but rather a manifest we all could agree on. So far so cosy. But TYPO3 has also always been a rough place to be. Most of us being not native English speakers learned communicating by email the hard way. Everybody soon realized that especially email is a quite misleading communication channel. A lot of very different characters contribute to TYPO3 and each of us has a certain vision of how things should be. This makes it a perfect breeding ground for misunderstanding and personal flame wars. In the history of the core team we had several "bigger issues" between team members. And as far as I can see most of them could have been prevented. What we need to accept and be aware of all the time is that we are diverse, each of us has a different character, mentality and cultural background but we have common values and are part of the project because we love what we can achieve together Although Kasper took an unbelievably big step in creating TYPO3, it was the community and the friendship among its members which made TYPO3 what it is today. It was the diversiveness of the community which brought the project ahead: we managed to put our different ideas together instead of living a my-idea-or-nothing mentality. It is the wisdom of the crowd which made TYPO3 a great CMS, not the wisdom of the crown alone. Where many people, money and power are involved, there is always room for conspiracy. When Julle, Kasper and I first discussed the idea of creating a TYPO3 Foundation (at a McDonald's break on the way back from Amsterdam), we had never thought that this would also mean a lot of politics, justifcations and bureaucracy. The first years of the TYPO3 Association were hard because the TYPO3 community (including us founders) was unsure about what role the Association would take. Today the situation is much better because we managed to bring the T3A into a position we initially imagined for it: as a fundraiser for important community projects and a guardian of the TYPO3 brand. We are also getting better at making the TYPO3 Association transparent. At the General Assembly last week members like Jochen Weiland asked several good and detailed questions about administration costs, budgets and marketing. And we could answer Jochen's questions with pointing to running or accomplished initiatives. Most people in the TYPO3 project highly value constructive criticism and I know from personal experiences and from conferences that TYPO3 is known for this openness even outside our community. But conspiracy doesn't stop at the Association. Community members speculate that Kasper and me must be millionaires, the core team is an elite club who lets nobody in and the organizers of our conferences and snow board tours all drive Mercedes thanks to the expensive tickets. The awkward thing is that you, as the subject of such an affair, come to know about it as the last. You hear it through the grapevine and it is always highly emotional and cumbersome to solve. One way to tackle this is better communication and more transparency. But that's only half of the truth because often I heard myself saying "hey, we posted it on the front page on typo3.org" but the message still missed the recipient (should have posted that on Facebook). I think that the real solution is only a deeper understanding and more considerate communication. We need to be team players and at times cut back our own interests in favor of a viable compromise. We should receive all messages in the most positive manner and not allege that someone is doing us deliberately harm. We should accept that people are different, have different opinions and ways to communicate, but in the end we're striving for a friendly community and a great piece of software. In that sense I wish that whoever currently feels harmed by me or someone else in the community takes a deep breath and considers if that is really the case or be done on purpose. And then: talk to eachother. It takes all kinds to build a world.

Video: Talk about AOP at WebExpo 2010

Mon, 07 Feb 2011 08:51:56 +0100

In September 2010 I gave a talk about Aspect-Oriented Programming at the WebExpo Conference in Prague. The session covered AOP in general as well as its actual use in combination with FLOW3. Although it's been some time ago that it was recorded, I wanted to share the video the WebExpo team took during the conference. Unfortunately there was no microphone for that particular session but certainly you'll understand the most important parts anyway (you might want to use headphones if you're at a crowded place). Enjoy! Talk description and details on the WebExpo website

New Impulses from the PHP Conference

Mon, 18 Oct 2010 14:57:33 +0200

Last week I attended (and spoke at) the International PHP Conference in Mainz, Germany. Besides some very nice discussions and the usual meeting old and making new friends the conference also gave me new impulses regarding collaboration with other Open Source projects, namely Doctrine and Apache Zeta Components. Back when I started developing FLOW3, I also checked out other frameworks and code libraries we could possibly use for TYPO3. Although the not invented here syndrome certainly didn't spare me, it does have its natural limits. You just don't want to implement your own email library, certainly not spend precious months of your life implementing a WebDAV server. The eZ Components team did all that and the result is a high quality component library which was released under the GPLNew BSD License. In the mean time Kore Nordman, Tobias Schlitt and Derick Rethans are not working at eZ Systems anymore but still want to continue with the development of the components (obvious, as they invested quite some energy and some - formerly not - gray hairs). So they made a deal with eZ who agreed to donate eZ Components to the Apache Foundation and make it an Apache Incubator project. Anyway, during the IPC I talked a lot with Kore and Tobias about FLOW3, TYPO3 Phoenix and – the now called – Apache Zeta Components (and certainly many other topics which ought to be discussed only at hotel bars). To me it feels so much better now integrating some of the components into TYPO3 now that it is an independent project housed by the Apache Foundation. And there are some obvious candidates: WebDAV support is something we want for the content repository and resource management. The Document component will become very handy for converting content from one format to another and the Image Conversion component might become the new foundation for a GIFBUILDER replacement in TYPO3 Phoenix. I'd like to try out integrating these components (at some point, it is admittedly not our top priority at the moment) and see how we can make it as easy as possible to integrate any Zeta Component in FLOW3. And I'm looking forward to working with Kore and Tobias on enhancement of existing and possibly development of new components. Then I had the chance to talk with Benjamin Eberlei, a core developer of Doctrine, about possible integration of Doctrine2 into FLOW3. Karsten had already talked with Benjamin and other participants of FrOSCamp about similarities and differences between the FLOW3 persistence layer and the implementation of Doctrine2. It seems like we are going parallel paths here and because we use the same well-proven design patterns (and even similar annotations), it should be fairly easy to replace the corresponding parts in FLOW3 by Doctrine 2. Why not earlier? Well yes, that's a pity. When we started implementing the FLOW3 persistence layer, there was no sign yet of Doctrine 2. And Doctrine 1 is a completely different piece of software, following the Active Record pattern and therefore didn't match the object management and persistence approach of FLOW3 at all. Now that version 2 of Doctrine is near its first final release, backed by a reliable team of developers, we're in a different situation. As a consequence we have now scheduled an exploration task for sprint 5 which is supposed to deliver a good base for decision if FLOW3 should be refactored to use Doctrine2 or not. If you're already using FLOW3 or recently started writing an application based on it – don't be afraid. The persistence API you're using will almost certainly be fully backwards compatible. We rather plan to add functionality than changing or removing it. On the other side we would gain a lot: the Doctrine team invested quite some energy (and with great results) into optimization and stability, which the FLOW3 core team won't be able to offer in its current constellation and size. It's really a different thing if persistence is your main subject or you implement it alongside a CMS ;-) So, that's two new inspiring topics I brought home and I'm curious on the impact they will have on the FLOW3 and TYPO3 Phoenix project. Photo: Benjamin Eberlei and me at the IPC. © S&S Media

I Love Git

Tue, 21 Sep 2010 08:30:49 +0200

I've been very busy implementing the enhanced content repository concept we came up for TYPO3 Phoenix. So busy that I hardly managed to answer my emails. Perfect timing for making the switch from Subversion to Git, don't you think? The current sprint - which ends right during T3CON10 in Frankfurt - is really a challenge. The refined content repository concept (worth a dedicated post) requires a major refactoring and implementation of some complex mechanisms such as workspaces (with TYPO3-style shine-through support) and localization. Anyway, before this sprint I knew that I had to focus on this refactoring as much as possible and therefore had mixed feelings about our transition to Git. I haven't really worked with Git before this and so when we made the switch after the release of Sprint 3, I took a quick crash course by Karsten who had been the driving force behind the whole transition. I had read the Version Control with Git book by O'Reilly some months ago but have to say that without a real project to apply it on it only gives you a rough idea. You can only learn Git by using it - and when you do it suddenly all becomes so logical, elegant, stable (no more svn cleanup for obscure reasons) and powerful! Karsten will surely report in more detail about the tool chain we use. What I'd like to mention already though is that you find our Git repository at git.typo3.org and that we use Gerrit for reviewing patches. And that's basically the reason for my rejoicing - Gerrit and Git are such a great help when working collaboratively! If I find a bug or start implementing a new feature I create a topic branch in my local working copy. Because Git allows me to switch between the master and topic branch effortlessly I can always check if my fix really fixed the problem (well, of course unit tests play their role too). When I'm done, I push the topic branch to Gerrit. My team mates then have a chance to review my patch, give their comments (even inline comments in the code) and finally give their +1. If the patch is not good enough, I can upload a better version and discuss it again. If it's finally approved, Gerrit merges the change into the real master which we use for releasing FLOW3 and TYPO3 Phoenix. If you like you can browse through our patches and discussions at review.typo3.org - just login with your typo3.org username and password. So, in the end my initial fear was unfounded - the transition to Git was much more painless than I expected and improved the workflow and even the code quality of FLOW3 / TYPO3 Phoenix.

TYPO3 Phoenix, Aloha and the AGPL license

Tue, 24 Aug 2010 08:23:42 +0200

TYPO3 Phoenix will use the Aloha Editor to provide its users the smoothest inline editing experience. But contrary to TYPO3, being GPL v3 licensed, Aloha is published under the Affero General Public License Version 3 (AGPL3). What implications does this license have on the development and use of TYPO3? Let me start with a disclaimer: I'm neither a lawyer, nor am I adept in open source license questions. Therefore this blog post doesn't contain a real answer to the question but is more a collection of what I found while searching for background information. According to the FSF the AGPL3 is basically like the GPL3 and thus compatible. The basic idea of the GPL license is that you may modify the software and redistribute it, as long as you pass on the source code. Now the blemish with that license is - in the eye of some people at least - that you can modify the source code and provide it as a service to customers without having to publish the code. Because you run it on a server and don't really pass the application to someone else, the GPL doesn't oblige you to make the sources available. The AGPL is supposed to remove that blind spot by requiring to share the source code even when it's run only over a network. Consequently the AGPL v3 is an extended version of the GPL v3, with the addition of §13 "Remote Network Interaction": "Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph." To me this sounds more complicated and difficult than it – maybe – is. For the core team of TYPO3 it's no big deal at all: Because we publish all our source code anyway, we automatically adhere to the AGPL. But what about companies providing services on top of TYPO3? Or a TYPO3-based cloud service? As far as I understand the license, you need to provide the source code of the Aloha Editor to your customers if you modified it. If that is really the case, it only touches that part of TYPO3 and will rarely ever happen. Even if so, it would not be a big deal because: isn't all source code of Aloha available to anyone using it by the simple fact that it's a .js file downloaded by the browser? Isn't that sufficient? Another question which crossed my mind is if a minified version of Aloha is seen as a "compiled version" or if making it available already satisfies the AGPL requirements. In the end it would be no problem to provide a download link in TYPO3's package manager, if that's really necessary. Finally I wonder why the great guys from Gentics have chosen the AGPL for Aloha. Their motivation surely has been to foster a community around the project. But, after having read a bit about AGPL, I don't know if it will really help or instead might become a contentious issue among its users. What do you think, is this a potential issue for TYPO3? Do you have experience with other AGPL-licensed applications?

Session Handling and Object Serialization

Thu, 19 Aug 2010 08:54:06 +0200

Last night I worked on FLOW3's Object Serializer - it didn't detect recursions in the references of the object tree to be serialized. That's a good opportunity for me to give some insight into FLOW3's session and object serialization capabilities. In a plain PHP script it's quite easy to store data in a session - all you need to do is starting a session with session_start() and store any data in the super-global $_SESSION. There are, however, limitations to this approach. Circular references in the object tree can become a problem and mechanisms like Dependency Injection or the special approach we take for persisting objects are, of course, not supported by PHP's built-in functions. Consider the following domain model: /** * @scope prototype */ class Order { /** * @var integer */ protected $orderNumber; /** * @var \F3\MyApp\Domain\Model\Recipient */ protected $recipient; /** * @var \F3\MyApp\Domain\Model\Article */ protected $article; /** * @inject * @var \F3\MyApp\Domain\Service\OrderNumberGeneratorService */ protected $orderNumberGenerator; /** * Constructs a new order */ public function __construct() { $this->orderNumber = $this->orderNumberGenerator->generate(); } /** * @param \F3\MyApp\Domain\Model\Recipient $recipient * @return void */ public function setRecipient(\F3\MyApp\Domain\Model\Recipient $recipient) { $recipient->addOrder($this); $this->recipient = $recipient; } ... } There are some challenges you need to take in order to store an instance of this Order class in your session: the OrderNumberGeneratorService is a (singleton-scoped) service, injected by the object manager and thus doesn't need to and should not be stored in the session on reconstituting data from the session on the next request, we need to re-inject all dependencies which were not persisted the Order has a reference to the Recipient which in turn has (for demo purposes) a reference to all its orders - a circular reference the Article should not be stored in the session but instead FLOW3 should store the uuid of the already persisted article because FLOW3 manages objects centrally, almost all instances are somehow connected to eachother - trying to serialize one of them would serialize all objects in the system FLOW3 solves these challenges for you - all you need to do is attaching the Order to some object which has a session scope: /** * @scope session */ class ShoppingSession { /** * @var \F3\MyApp\Domain\Model\Order */ protected $order; /** * @param \F3\MyApp\Domain\Model\Order $order */ public function setOrder(\F3\MyApp\Domain\Model\Order $order) { $this->order = $order; } } Storing the Order in the ShoppingSession is now a matter of two lines of code: $shoppingSession = $this->objectManager->get('F3\MyApp\Domain\Service\ShoppingSession'); $shoppingSession->setOrder($order); Of course you can also use Dependency Injection for the retrieval of the ShoppingSession. At the end of the request, FLOW3 analyzes the data attached to session objects. The ObjectSerializer, which is in charge of serializing the object trees, detects that theOrderNumberGeneratorService is of scope Singleton and has been injected - therefore it's omitted during the serialization. At the beginning of the next request, FLOW3 makes sure to re-inject all dependencies which have not been stored in the session data. Because or recipient is declared as an @entity and already exists in the RecipientRepository (i.e. it's not new and has not been modified during the request), it's sufficient to store the object's UUID instead of the whole data. FLOW3's ObjectSerializer automatically creates a reference to the persisted Recipient object. As a consequence, changes to the Recipient data made by someone else will be visible on the next request, because our session doesn't contain the actual Recipient data - only a reference. Finally if you want to explicitly omit the serialization of certain properties which otherwise would be stored in the session, you can tag them by a "@transient" annotation: /** * @var sometype * @transient */ protected $propertyWhichShouldNotBeStored; Anything else you'd like to see in FLOW3's session handling?

Paper Selection Process for T3CON10

Fri, 06 Aug 2010 14:30:21 +0200

Jürgen Egeling, Søren Schaffstein and me just finished the paper selection for this year's T3CON in Frankfurt/Germany. Time to look at the process so far and how we can improve it in the future. Since the first TYPO3 conference in 2005 we invite the community to submit papers for our yearly conference. Personally I am not so much involved in the organization of the conference itself but rather in selecting from the various topics proposed by prospective speakers. Today T3CON is a grown up conference organized only by unpaid volunteers, a fact which amazes me every year again. And after having organized a bunch of conferences, the team around Jürgen has gained quite some experience with handling the nitty gritty details for making such an event reality. But how does the current paper selection process work? How do you get your 45 minutes of fame during the biggest TYPO3 community event? As you probably know, we have a new website each year which allows authors to submit paper proposals. These are managed by a TYPO3 extension which also takes care of the registration of all visitors and other people involved in the conference. After the deadline of the call for papers ends, we invite the community to become a member of the paper selection committee - which this year consisted of 16 individuals. The job of everyone in this team is to carefully read all abstracts and vote for it by marking each proposal with "not interesting this year", "maybe interesting" or "definately interesting". After the committee members have cast their votes, the organization team of the conference meets up and discusses the most interesting proposals again and figure out the number of 45-minute-slots which are available. The result is a prioritized list of papers which then need to be categorized (this year we have "Orientation", "Business", "TYPO3" and "FLOW3") and assigned to the different slots. As soon as the papers fit nicely into the conference's concept we send out emails to the paper authors to tell them if we could fit their proposal in this year's program. During the last months Jürgen, Søren and I (and surely more people I met) discussed new ideas for the organization of the conference, the paper selection process and the website. I'd like to share a few of my thoughts and invite you to give your comments and own ideas. One thing we'd like to do for next year's conference is creating a new application which handles the organizational part and the website (in fact I have already started earlier this year to program such an app - based on FLOW3 - but didn't match our deadline due to the various other activities in TYPO3 Phoenix land). The conference app will give visitors and speakers a much smoother experience while interacting with the conference site and allows us to integration a bunch of new features. For T3CON11 we would give everybody (especially all visitors of course) the chance to vote on papers right after they have been submitted. And not only that – they should also be able to comment on the proposals and give advice on how the talk could be made even more interesting. By that mechanism, paper authors have the chance to upload new versions of their abstracts before the final selection process starts. For each track we imagine to have "track program managers" who have an eye on the quality and fitness of the proposed papers for their respective track. They will take the final decision on what talk and tutorial can be accepted. During the selection process the track managers will communicate with the paper authors by writing short comments - something like "Your abstract is currently too short to give an exact idea of what you plan to address. Please tell more about topic X.", or "Could you make this talk more highlevel so that it's better suited for business people?". I'd also love to see the ability to add a comment to the emails sent to the authors to give them a little hint why their proposal was accepted or rejected. Feedback is very important. Therefore we would like to extend the possibilities for the audience to give feedback to the speakers. We will (probably) start using joind.in this year and would like to integration such a feature into next year's T3CON site. Speakers should also get a chance to see how the audience rated their talks for the best paper award. I see many more opportunities for improvement of the conference website – what's your take?

MacBook Pro in den USA kaufen?

Tue, 25 May 2010 11:10:45 +0200

Durch die iPad-Import-Diskussionen und einen etwas älteren Blogeintrag war ich eigentlich der Meinung, dass es sich eher nicht lohnt, während seines USA Aufenthalts ein MacBook Pro oder andere Apple-Ware zu kaufen. Dass dies aber durchaus günstiger sein kann habe ich nun im Eigenexperiment herausgefunden. Voraussetzung ist allerdings, dass man vorsteuerabzugsberechtigt ist und sich möglichst vor der Reise überlegt, welches Gerät man haben möchte. Denn durch die neuen Unibody Gehäuse ist es nicht mehr möglich, das amerikanische Tastaturlayout durch ein deutsches zu ersetzen. Der Unterschied zwischen beiden ist zwar - bis auf die Beschriftung - minimal, dennoch gibt es feine Abweichungen, zum Beispiel fehlt unten links die < > Taste komplett und die Return-Taste hat eine andere Form so dass man sie aus Versehen benutzt wenn man eigentlich eine Raute # tippen möchte - blöd beim Schreiben von Tweets. Am besten bestellt man sich also einige Zeit vorher ein deutsches Modell zur Abholung im US-Apple Store. Für die Einfuhr von Notebooks aus nicht-EU-Staaten

TypoScript in TYPO3 Phoenix

Wed, 05 May 2010 21:01:02 +0200

We have passed the first half of our first official TYPO3 Phoenix sprint and the sprint goal - to render a simple website - becomes more real every day. One part I've been working on quite intensively during the last days is the TypoScript rendering. To give you some impression of what you can expect from the next generation of TypoScript I'd like to start some loose series of blog posts about it. Before I get down to the nitty-gritty, let me loose some words about the design goals of TypoScript II. And let me warn you: This might sound like a advertising brochure because I'm so consumed by this topic at the moment. So, the most important design goals I can remember right now were: Clear Purpose Consistency Object-Oriented Extensible The clear purpose is supposed to help especially newbies to classify TypoScript in the world of markup languages they might know already. TypoScript II is an object-oriented view configuration syntax This means that we use TypoScript for selecting and processing the content we'd like to display on our website or in some other format. TypoScript won't be used for settings or pure configuration not related to the view - no more "Page TSconfig". This kind of usage caused a lot of confusion in the past and will be replaced by a combination of YAML and user interface controlled settings. Consistency is what I've personally been longing for for years. Why does this property support stdWrap and the other doesn't? Why are there two properties "height" and "width" while another object uses "dim" (dimensions)? Is there life beyond option split? We solved this by making TypoScript truly object-oriented. Each TypoScript object is implemented by a real PHP class which makes it possible to inherit certain common aspects from other objects. The probably nicest feature in that regard is the processors mechanism (I'l cover them in detail in a later post). Processors are basically stdWrap on steroids - they can be chained, put into a certain order, used multiple times on the same property and - most importantly - exist for any TypoScript Object property. There's no need for extension authors to support them explicitly, they are just there. Object-orientendness also means that TypoScript goes pretty well with other PHP objects, such as Domain Models. We adhere to the clean approach we've taken for FLOW3 so you're able to display any PHP object by means of TypoScript. Your favorite TypoScript object is not in the official TYPO3 distribution? No problem, because you can very easily create your own. And even better: you can override behavior of existing TypoScript objects, including the "built-in" objects provided by TYPO3, if you need to. Because TypoScript supports namespaces, you can even switch from one Page object implementation to another by just switching the namespace. And because each TypoScript object is based on a Fluid template you have full control over the HTML output if you want to. Okay, before I end this working day now, here's one detail you might like if you're a fan of systems like Subversion or Git (and if you're not, you're not really a developer, are you?): TypoScript configuration is file-based by default - there's even no need to anchor it or reference to it from pages within your page tree. As long as the directory structure match that of the page tree, TS templates are mounted into the right place automatically. And because of that you can put your whole website, including all of its assets, into a FLOW3 package. But that's another story for somewhere along the way ... What do you miss most with the current TypoScript syntax? And what's your favorite feature?

What I learned from crashing

Tue, 04 May 2010 15:28:34 +0200

My MacBook Pro showed some weird behavior over the last weeks: Apps didn't launch, some froze and shutting down MacOS without brute-force-pressing the power button was a rare matter. So I thought, why not try a fresh install of OSX - probably not a bad idea after a few years collecting clutter. And while I released the mouse button after clicking on the "Erase Disk" button I wondered if I had a working backup. Well, of course it wasn't that unthoughtful. I use TimeMachine for doing my local backups and additional run Crashplan for offsite storage. So I had a good feeling of spring-cleaning freshness while I was watching the progress bar of the Snow Leopard installer. The weird thing is that even on the freshly installed system the problems I had previously persisted - it was impossible to reboot the machine, eventually even Finder refused to start. Only after the 3rd install (and in each case it was a clean install on a freshly formatted hard disk) signs of kaputtheit vanished. Eventually I started to reinstall all my applications and restored my user data and certain preferences. At least that was the plan, because TimeMachine told me that the sparseimage was broken (why didn't it tell me some hours ago when the backup ran through?). Finder also refused to open it. So I thought: Good that you have a second security layer, namely Crashplan. What I didn't consider was that restoring 160GB of data (that's without the OS) takes some time. Even though I have a 50 MBit internet connection, the typical download rate from Crashplan Central varies between a few kBits up to 1-2 MBit. Estimated time of arrival: 4-15 days from now. So, my conclusions for now are: it pays off to have at least two backup strategiesit would be better to have even three After my fresh install I now also have a local backup created by the Crashplan client, stored on my Drobo in the utility room downstairs.

On Speed

Thu, 29 Apr 2010 08:28:20 +0200

In the release notes of FLOW3 1.0.0 alpha 8 I wrote that we'd care more about development speed than execution speed. During a discussion in the typo3-dev list someone pointed out that he's not comfortable with that – so maybe this needs some further explanation. In my opinion, the most important aspect of an application is a positive user experience. And as simple as that is said, many aspects play into that experience: functionality and intuitivity (usability)speed, interaction, "joy of use" (feel)consistent design conveying reliability, trust and sexyness (look) As I mentioned before, I think that a positive UX for the developer is equally important as a positive experience for the user - only motivated programmers will create high-grade code. So we have two of the aspects challenging with each other: joy of use / speed for the developer and speed for the user. Because many automatisms and supporting mechanisms which simplify a developer's life eventually slow down the overall application. Do they? The experience of speed is not the equivalent of speed of the framework. If you build a superhighway, it's not important how fast the pave-laying machines can go - they are just building the roadbed. What's important is the speed experience while driving on the Autobahn. On the same note it's only of secondary importance how fast FLOW3 can render your AOP proxy classes or builds a Fluid template. What counts is how fast the user of your application or the visitor of your TYPO3 website gets a response, it's important that the app feels snappy. In that regard we value speed even higher than speed of development, because if the user experience is bad, the overall product is no good. My point is: a benchmark comparing the rendering time of different frameworks doesn't tell much about the speed a user will experience. Photo: RICarr / Flickr

Dependency Injection (would be nice)

Thu, 22 Apr 2010 07:57:03 +0200

After moving the website of my since-almost-the-first-day TYPO3 customer I realized that emails sent by the contact form would not reach their intended destination. After looking for a possible solution I realized that if TYPO3 had already been developed using dependency injection from the start, I'd now have a walk-over integrating a new mailer. Of course, the Inversion of Control pattern hadn't even been formulated back then when Kasper developed the mail support for TYPO3. And the PEAR mail library was not really usable so that only a custom solution would allow direct mail to send well-formed emails. So this is no rant about TYPO3 but rather an affirmation that DI is the way to go. The relocation of the domain was planned to be done in two steps: the first step was to move the website and secondly to move the email accounts. When I now send an email through the contact form on the new server, the local sendmail uses the new provider's mail server to send the email. Unfortunately this server feels responsible for the website's domain (because it will be the future mail server anyway) and therefore the emails don't reach their original recipient who is still accessing the old mail server. The most simple solution would be to send emails via the old mail server. For that I'd need to tell TYPO3 to send emails through a specific SMTP host - but unfortunately t3lib_htmlmail passes emails directly to PHP's mail() function. Now, if dependency injection would already be in place since the beginning, I could easily create a new mailer class (for example based on Swift Mailer which is also used by FLOW3) and reconfigure the object container to use this implementation instead of the built-in mail class. Instantly all parts of TYPO3 and even all extensions which are totally unaware of Swift Mailer would use this new implementation because they get a mailer injected instead of referring to it with hardcoded class names. Dependency Injection FTW!

Continuous Delivery

Wed, 14 Apr 2010 08:55:23 +0200

For almost two years now we use Hudson - the Continuous Integration server - for automizing tests of the FLOW3 and TYPO3 Phoenix projects. Since then this tool has been an invaluable help for spotting bugs and integration issues right after each commit. Inspired by Martin Fowler's CI article we always sought to automize the testing and release process but it needed another book to really enthuse me for the topic. Always wondered how Flickr is able to deploy more than 10 times a day? The not yet published book Continuous Delivery by Jez Humble and David Farley summarizes many great ideas and best practices of continuously delivering software and gives many answers you might have had for years. Most of it sounds pretty familiar and evident - but I guess that's always the case with pattern books. It's again the compilation of all the agile practices in one book which makes it a valuable read. Why I mention this now? Well, Karsten and I have spent the last week with enhancing our Phing-based build scripts so that we finally can trigger a release of FLOW3 with a single task run by Hudson. When we're done, a release will not only take less time (15 minutes watching the script instead of 1 day manual work), it also excludes many sources for errors - or at least makes them repeatable ... It's a lot of work to automize a release but currently it looks like we'll be able to finish the biggest part for the next FLOW3 alpha release. Ah, we didn't mention that: 1.0.0 alpha 8 will be released this Friday! The new scripts (which are, by the way, located in a directory "Build" of the FLOW3 distribution) are only the beginning. In the future we plan to have proper system tests with and without Selenium which will play an important role in the development of the TYPO3 Phoenix user interface. We'll keep you posted on that! Now if you wonder why your lights go out or door bell rings somewhen Friday afternoon then don't worry, that's only a few side effects of our new release script. We can't test everything on beforehand - or do you know a unit testing suite for Phing scripts?

Debugging FLOW3 Applications

Sat, 20 Mar 2010 12:34:31 +0100

Throughout the years my team and I have gathered quite some experience with debugging complex PHP applications like one FLOW3 is. Since FLOW3 controls the lifecycle, dependencies, proxy classes and scopes of almost all objects used in an application or the framework itself, the central parts contain a lot of references to other objects which in turn might refer back to central places like the Object Manager. Debuggers are very helpful – if you're not using PHP. Honestly, I haven't yet seen anybody who was reliably using Xdebug or Zend Debugger by using an IDE such as Zend Studio, Eclipse or Netbeans. The best results I had so far are Netbeans with Xdebug (nice integration, but inspection of variables is not really working) and Xdebug with MacGDBp (works most of the time). That said, I'm still one of those old-school programmers who tend to echo variables with PHP's var_dump() command. Unfortunately var_dump() doesn't go well with large nested and recursive object structures. If the Object Manager is connected to one of the displayed objects, the browser will simply collapse under the amount of data pushed to it. This has been a problem since the beginning of FLOW3 development and we always wished there was a debug function which takes the special needs of FLOW3 into account. Yesterday I was again debugging a part of some FLOW3 app and concluded to solves this once and for all with a custom var_dump() method. In the screenshot below (sorry, this blog doesn't support image resizing yet, just open the image in a new window) you can see a typical dump of the new function. If you use \F3\var_dump() instead of PHP's built-in function, you'll not only get a filtered view of the object structure (the properties of Object Manager and friends are not displayed), but also some helpful information about each variable. You can see at one glance, if the object is persistable (entity or value object), what scope it has (prototype, singleton, session), if it is proxied by the AOP framework and what UUID and object hash it has (move the mouse over the scope and persistence tags). Each instance is only rendered once – if some other object refers to it at a later stage, only its class is mentioned again in italics. Click on it for jumping to the first occurrence of this instance. Although this is only a start (I have many more features for this in mind), I hope that it'll help you as well with your FLOW3 development. Let me know your ideas and comments!

Managing a big project

Tue, 09 Mar 2010 20:46:07 +0100

Over the last years TYPO3 Phoenix – and in the meantime also its sub projects FLOW3 and Fluid – have become huge and complex projects. Most of us surely underestimated the effort which needs to go in such a venture. On the other hand it doesn't come by surprise that creating a CMS from scratch which aims to excel the current TYPO3 in function, user experience, technology and code quality isn't a walk in the park. The management of such a project is a challenge even under ideal conditions: new technologies and techniques everywhere, no paid employees with a predictable availability, distributed teams without an opportunity to meet regularly in person. However, we don't have ideal conditions. In a perfect world we'd have a dedicated project manager (or better: a product owner and a scrum master) who keeps an eye on the feature set, resources and timeline. But our budget doesn't allow such a position, so we need to be more creative and disciplined to manage ourselves. On the flip side there's a great community which supports us with contribution of ideas, work power, money and certainly not at least with motivating words. Naturally there is a conflict if a developer sets his own goals. He usually chooses what's most interesting technically and has just the right amount of challenge – documentation and boring bug fixes are neglected. Although we surely ran into one or the other trap, we have a simple principle for creating and assigning the tasks to ourselves: the shortest way. We ask ourselves: what do we need technically to display the content section of the TYPO3 backend and allow an editor to create a new page? Well, we need a lot of code for that simple task, especially if we also consider the architectural whislist we have summed up through the years of using and developing with TYPO3 3 and 4. But still, it's possible to analyze this epic requirement and cut it into smaller pieces: How to eat an elephant? Slice-by-slice! So we created (and updated ever since) a list of key features and technologies we imagine for TYPO3 5.0: concerning the content model, localization, templating, resource management, TypoScript, package management, setup, performance, security, content access control, web services, user experience and much more. With the blog example (and other applications which are currently in the works) we set ourselves a closer, intermediate goal which allows us to test the concepts and actual code under realistic conditions. If you look at the features FLOW3 provides today, you'll recognize that they are all providing the low level infrastructure for TYPO3's key features. Of course we can't deny the special attention we put on clean code and a certain luxury for future FLOW3 and TYPO3 developers (and yes, there's possibly one or the other curlycue here and there). But this doesn't come without a reason: first a CMS like we are working on is a huge beast which needs all possible support by the framework to tackle its complexity. And secondly extensions and extension developers play an important role in the TYPO3 ecosystem – we'll enable them to write clean, fast and secure code which will get rid of the problems we face today with thousands of unreviewed extensions. All this said I do think that we can improve. Communication is certainly an issue: whenever I buck up to write some lines or shoot a podcast I'm worried about the time I'll be missing in development (like now, with the difference that I'm missing dinner ;-)). I frequently ask myself: should I develop? organize? communicate? write documentation? speak at more conferences? In these situations I need to get a clear overview of the options and then decide. The principles formulated by Steven Covey are a great help for me to decide what to do next ("The 7 Habits of Highly Effective people" was a book Kasper recommended me years ago, a very good advice). Last week I had the urge again to get a clearer view on the open tasks. Karsten and I are using Merlin since January for planning the development and release of FLOW3 and TYPO3 Phoenix. It's a classic project management software but with the nice look and simplicity you're used to from Mac applications. But although it provided us with a much better overview on the different projects and their schedule, an important piece was missing: the issues we manage at forge.typo3.org. So, yesterday I sat down and did two things: Learn AppleScript and develop a Redmine to Merlin connector. I'm very happy that I succeeded: with one click I can now synchronize all issues of all FLOW3 releases with Merlin. The script not only creates and updates activities, it also sets the estimated work time, start date, completion status and assignments. I hope that this better overview will help us to make better estimates and take more effective decisions on when to develop which feature. But of course this story doesn't end here. We are in touch with several individuals and companies of the TYPO3 community and together we are seeking new ways to adapt techniques and tools for making the TYPO3 and FLOW3 projects more transparent and more effective. And we need to modify them and be creative – because most of them were designed for ideal conditions ...

The purpose of this blog

Mon, 01 Mar 2010 17:46:27 +0100

Developing your own blog is probably not the cleverest thing a busy developer can do. And yet it was very important for the TYPO3 5.0 and FLOW3 project to create this "blog example". My blog serves as a test bed and steady reminder for what we want to achieve with the project Phoenix: A full featured next generation CMS. There are mainly two reasons for me launching this site: Number one: I desperately needed a communication channel which allows me to comment on hot topics in the dev sphere (other frameworks 60 times faster than FLOW3? Hah! – I'll cover that in a future post ...) and spread more information about TYPO3 and FLOW3. Because although my fellows and I are instensively working on 5.0 and FLOW3 throughout the whole year, there's only few information the community gets apart from our release notes. I hope that this blog helps me improving this situation. Number two: We need real world experience with FLOW3. We do work with FLOW3 all the time but what we're lacking is stumbling over nasty bits like incompatibilities with FCGI, unexpected effects by the Suhosin patch or "simple" questions like how to stage new versions of FLOW3 on a live server. This blog is a first start and we've got more in the pipeline. I'm aware of that this blog will cause me a lot of trouble. Because my intention is not to extend the blog app until it can measure up with Wordpress (honestly, I'd love to use WP for my blog!). My goal is to take this as a start for a transition to TYPO3 5.0: As the code of Phoenix evolves, we'll adapt the blog code so that it eventually turns into a plugin for TYPO3. So in the end, this site will maybe the first TYPO3 5.0 powered site, too - unless some brave developer beats me to the draw ... If you have any questions regarding the blog, the progress of FLOW3 / TYPO3 5.0 or our future plans, feel free to ask - here, via private mail or in one of the mailing lists. And now take a sneak peek behind the scenes of this blog: PS: You can check out the source code of this blog app from https://svn.typo3.org/FLOW3/Applications/Blog/trunk – but be warned, it's not all as clean as you expect ;-)

Hello World!

Sun, 28 Feb 2010 17:07:08 +0100

After literally years of development, I am really happy to have my very own first FLOW3 based application online: this blog! But although a Hello World post would be the perfect place for telling the story behind this site, the title refers to something completely different. It's the reason why I won't be at the T3BOARD this year, so ... Almost three weeks ago my wife and I had a very special release on our own: the birth of our daughter Smilla. While some already knew that I'd become a father, others might now understand why I was so hard to catch during the last weeks. And well, what can I say, it's so great to have little baby daughter. What young parents always keep telling you is so true: your whole focus changes, nothing is like before. But fortunately that seems to be only true in a positive sense, in our case at least. Despite this little, uhm, shortfall in sleep budget, I really can't complain. Although my focus shifted a little during the last weeks, I am still passionate about TYPO3. I'm confident that I'll find the right balance between job and family life. In that sense it was very important for me to stay with my girls during these first weeks, even if I had to pass this year's snowboard tour. So, I hope you don't mind that I follow you from this side of the net, and rest assured that I do envy you – just a tiny bit ... If you like you can see a few more photos in Smilla's Flickr album ...