Planet Plone posts
The official website for the Ploneconf 2012, www.ploneconf.org has been launched and made public on plone.org and Twitter. Now we are definitely in business. Over the last few months, we have put a lot of effort in the design, logo and content. For your information, we hereby explain some of the choices we made during the proces.
A short review of Booktype and a comparison with my own Produce & Publish product.
This blog post is a part of Mobilizing websites with responsive design and HTML5 tutorial. For all posts please see the Introduction post. Firefox Mobile and Opera Mini are popular after market browsers the user can install on their device. … Continue reading →
The new Plone Conf 2012 website now has information for everyone wanting to find out more about this event.
BlueDynamics Alliance is proud to be Silver Sponsor for the first German Plone Conference held in Munich. Three days Plone in a row with talks, openspaces and room for personal contact. We also have three talks about topics from our daily work: Johannes Raggam office@programmatic.pro > Save The Dates: The Calender-Framework plone.app.event Jens W. Klein jk@kleinundpartner.at > Failsafe Culture with Plone - Effective redundant Hosting with OpenSource Phil Auersperg phil@bluedynamics.com > and Robert Niederreiter office@squarewave.at > AGX - Code Generation with UML2 We invite you to listen to the talks in real or virtuell after the talks video was published online (stay tuned, we publish the link here). Contact us in case of questions!
Speaking of events , I've been invited over to Munich next week to deliver one of the keynote talks at the Plone Konferenz that is being hosted there. There are 34 talks over three days . Most of the talks will be in German, but a few will be in English. The keynote speakers are: Prof. Udo Helmbrecht - Head of the EU Agency ENISA in IT security Elizabeth Leddy - Plone Framework team - San Francisco, USA Myself, Matt Hamilton - President of the Plone Foundation This is looking like it is going to be a fantastic event, and it is great to see local-language events such as these happening in the Plone community as it shows just how much reach we have. In fact... that is part of what I will be talking about in my keynote " ...It's Like Buying a Relationship ": "Software is developed and sold in many different ways. We will be looking at the relationships between the various parties and looking at what makes Plone CMS quite unique in the world. We will then take a look at Plone across the globe and see how the localization of Plone goes beyond just the software itself to the community as a whole." Alas, I am only going to be able to make a very brief visit and won't be able to stay for the whole event, but will be there from Thursday lunchtime until about Friday lunchtime. I will however make the party on Thursday evening ;) I will also be giving a case-study talk on Friday morning of the ongoing work we have been doing on a Plone-based intranet for Belron® the parent company of Carglass® in Germany (and Autoglass® in the UK). See you there! Add a comment
This article talk about Plone products but I think this is a very general argument that hit every programming language: the lack of modularity in products. Know that: I'm not talking of the Plone core, that is obviously going in the right direction (the plone.* and plone.app.* universe is one of the clearest example) but only of products add-ons. I'm not also talking of bad code (no "Spaghetti code"). Maybe your final result is great and will change the world! I don't care. Your first time If you are not a genius, probably the first Plone product you did was crappy. Apart of the features in it, its structure was probably something like a single product called "Products.MyProjectXy". What this mean is: all Plone features you need in a single product (a real monolith!). Maybe you were already an experienced programmer (so your product was well designed... inside) but the final result was not the best. After some times, when you started looking at other product's code (or if you bough the Martin's book ), you probably quickly learned that splitting the product is good: the Separation of concerns is really important. What is the level of modularity you need to reach? In how many different eggs/packages you need to split your project? I've no a real response about it... we have a Third Normal Form about software design? I don't remember too much of my lessons about program engineering... Thinking modular Let me say: splitting a Plone project in more than one egg is "boring". Sometimes you have the sinister feeling that you are loosing your time (and I also remember times when ZopeSkel wasn't there to help us) and the temptation to ignore this practice. Maybe a Demon of Bad Software is talking at your soul in that moment. An example: you are in a very productive state, lines and lines of wonderful code and new features are flourishing under you fingers ( Daniel Pink call this the "Flow State")... then you develop something you know it's better to be moved away from the module you are developing because you know that this choice, one day, will pay you back. But to do that, you need to stop your "Python Frenzy" for some minutes. Don't know you, but this sometimes hurts me. However I know this is good and must be done so (bleeding) I move the code away. Not later! Immediately! Why? Because the path to "Products.MyProjectXy" is easy... when you are there, it's too late! Every time a customer ask you for a new feature: think if this feature can be made more "general purpose"... ... or if another customer can like it ... ... or if someone else already asked for something similar. If at least one of those answer is true, probably you must develop something "more general". Too famous Plone features (sometime more that the product itself) Some concrete examples. Let me say that sometimes, when you create a Plone product, you don't know how useful to the community it can became in future. Worst, sometimes a feature inside you product can be useful to other... ... is not always easy to "think at future": the list of projects that follow talk about great Plone products I used a lot of times and the saved my time. So probably done by great developers... however inside them I can still found sometimes the problem I'm described above. The Kupu link administration We have all moved away from WYSIWYG Editor Kupu, preferring the famous TinyMCE . However Kupu still have a useful feature inside it (I still remember the first time I see it at one of Plone Conference... woah!): an administrative tool that can transform your links inside documents from "normal" ones to the "Use resolve UID" form, or get back to the normal form. Unluckily this feature is shipped with the Kupu product (and: using AJAX stuff, it need that Kupu si really installed to work properly). The Maps location field and widget The product Maps give us some simple but direct features of integration with Google Maps. Also, it contains a new type of field and widget: the LocationField (that can contains 2 coordinated values) and the LocationWidget (that help filling the LocationField using Google Maps interface). This new field/widget pair can be very useful, but this feature is inside the Maps project, not given as external dependency. Also you are forced to install the product in your Plone site if you need it (having it only in your buildout is not enough). Flowplayer metadata extractions The well know collective.flowplayer is giving simple Plone Video features to Plone. Instead of simply giving you the video player integration, it contains a simple piece of code that extract video metadata from uploaded files using the 3rd party library hachoir . We have two problem there: if you need the metadata extraction feature you need to add Flowplayer to your buildout (minor issue: this time you don't need to install it) but also you are forced to use hachoir, that is not a perfect library (first of all: it brakes you pdb !). Other examples? I'm sure there are other good products that give you additional features you can like to have also outside the products itself. Conclusion Keep you products compact but always think about software reuse. Experience done with your own customers and users can help you to know when a piece of technology need to be moved away and maintained alone. Also: small products are simple to be maintained. So: don't listen at the Demon that say "Enlarge you Egg".