Quicksearch
Syndicate This Blog
Webinarreihe
Das nächste Webinar findet am 16.05.12 um 14:00 Uhr zum Thema Mobiles Umdenken - HTML5-Apps für Businessanwendungen statt.
Categories
Blogroll
We read:
Planet PHP
Planet MySQL
Exciting E-Commerce
E-Commerce Blog
Fischmarkt
fukami
Lars Jankowfsky
Themenblog
Thomas Bachem
Matt Asay on OpenSource
Joel on Software
Ibrahim Evsan
Hasematzel
Techcrunch
Indiskretion Ehrensache
Sichelputzer
Alexander Schwinn
Managing Tech
F-LOG-GE
trycatchfinally
PHProjekt Developer Blog
phpMyFAQ devBlog
Technorati
Entries tagged as php
Mayflower Blog
Entries tagged as php
Wednesday, September 1. 2010
Mitarbeit am ZendFramework
... über die Mitarbeit an Open-Source-Projekten
Wer hat nicht schon einmal damit angefangen sein eigenes CMS/Framework zu konzipieren? Mittlerweile wird es ja schon aus Lerngründen als "best practice" angesehen, jedoch den ganzen Sicherheitskram von vorne durcharbeiten zu müssen kann genauso stressig wie langweilig sein. Das ist der Punkt wo die meisten Entwickler anfangen zu großen Open-Source-Projekten wie dem ZF oder Typo3 beizutragen. Vielleicht haben sie ja schon einmal damit gearbeitet, und noch ein weiteres CMS/Framework auf dem Markt durchzusetzen, oder gar Entwickler zum beisteuern zu bringen, scheint einem fast nicht machbar. Anstatt sich wieder mit einer eigenen ACL-Implementierung zu beschäftigen, hilft der Entwickler der Software besser zu werden, egal ob er nun Bugs meldet / löst, Erweiterungen oder Dokumentation entwirft (ein weiterer, oft unterschätzter Teil der Mitarbeit). Ebenfalls möchte ich darauf hinweisen, dass jeder einzelne Blog-Eintrag sowie jedes HowTo im Web ebenfalls ein Beitrag an der Software ist. Anfänger-Tutorials im Netz sind wichtig, da jeder von uns in ein neues System erst einmal reinkommen muss, und anhand vieler Tutorials Software für diverse Projekte auch beurteilt wird. Wie man nun vielleicht lesen kann, soll dieser Artikel nicht nur das Beitragen zum ZF zum Thema haben, ich möchte genauso jeden Entwickler dazu ermuntern es einfach einmal auszuprobieren.
... über das Zend Framework
Nach fast einem Jahr im IRC-Support-Kanal kann ich sagen, dass die Jungs wirklich gut drauf sind. Natürlich hat sich das Framework nach einiger Zeit in eine gute Software entwickelt. Ich möchte hier nicht die Vor- wie Nachteile eines Baukasten-Frameworks erörtern, noch möchte seine Benutzung vor {dein bevorzugtes Framework} empfehlen. Doch worüber ich berichten kann ist eine kleine Zusammenfassung der Chatlogs des Kanals. Der weit bekannte Kanal (#zftalk im Freenode-Netz) beinhaltet alle möglichen Arten von Anliegen. Der eine Nutzer findet Bugs, ein anderer hat richtig clevere Ideen zu Verbesserungen von Komponenten, doch wenn man sie um etwas Mitarbeit bittet ist es immer das gleiche: Sie denken entweder, dass es Jahre dauert hier einzusteigen, oder dass sie "nicht gut genug" wären um etwas zu leisten. Selbstverständlich zwingen wir hier niemanden zur Mitarbeit, doch lasst mich den Vorgang etwas entmystifizieren sodass am Ende klar wird: es sind wirklich nur ein paar Minuten. Doch bevor es losgeht, noch ein paar Worte zu letztgenannter Sorte der Entwicklern: Man kann nichts kaputt machen, und jede einzelne eurer Ideen kann zu einer hervorragenden Verbesserung leiten, ob nun bezüglich eures eigentlichen Anliegens oder auf einem ganz anderen Bahnhof. Wir sind froh, dass ihr euch die Zeit nehmt, selbst wenn ihr komplett neu im Bereich ZF seid. Einige Anliegen von Anfängern hat Entwickler dazu gebracht Themen relevante Blog-Einträge zu schreiben, die auch nach einiger Zeit noch im Support-Kanal verlinkt werden.
... am ZF mitarbeiten
Die Mitarbeit in Form von jeglichem Code erfordert das Unterschreiben der CLA, in welcher man offenlegt, dass man jeglichen beigetragenen Code teilen kann, und nicht patentieren darf. Das dient der Geschäftsfreundlichkeit der Codebase bei, und kommuniziert, dass es jeder frei benutzen darf. Genaugenommen muss man einen Vertrag unterschreiben, welchen man später druckt und entweder faxt oder mailt. Dies ist ein wichtiger Schritt, und keinerlei Code wird von unsignierten Entwicklern in offiziellen Paketen verwendet. Als nächstes sollte man sich die Coding- wie Subversion-Standards durchlesen. Wer schon den Code von ZF Komponenten gesehen und sie grob überflogen hat (man wird sich all das nicht das nicht alles auf einmal merken können), kann man das offizielle SVN-Repository aus checken. Bemerkung: Auch nach dem Unterschreiben der CLA hat man noch keine beschränkten Commit-Rechte, aus denen später der Code "zusammen-gemergt" wird. Wo wird denn dann nun gearbeitet? Die ganze Magie hinter dem Bugfixing, um welches es hier gehen soll, findet im Bugtracker statt, ZF´s offizielles Jira. Alle gelösten Bugs wie Erweiterungen werden hier als Tickets behandelt. Wer also einen Bug findet, registriert sich hier um ihn in einem Eingabeformular auszuformulieren. Ein wenig später wird hier, sofern notwendig, in Form von Kommentaren die Notwendigkeit sowie das Vorgehen diesbezüglich diskutiert.
So ziemlich alle hier namentlich gelisteten Personen sind auch unter diversen Synonymen im IRC wiederzufinden, wo ebenfalls Ticket bezogen diskutiert werden darf. Der Code um das Problem zu lösen wird später als eine Patch-File ins Ticket hochgeladen (svn diff > patchFile). Das kann auch von Leuten mit Commit-Rechten passieren, weil man sich vielleicht bei der Vorgehensweise nicht ganz klar ist oder noch Fragen offen sind. Diese Methode des Code-Managements lässt dem ursprünglichen Autor einer Komponente die Möglichkeit zu Entscheiden ob eine Änderung nun vorgenommen werden soll, oder ob Fragen noch zu klären sind (es könnte mit anderen Komponenten kollidieren oder ähnliches).
Der letzte und wichtige Punkt sind unit-tests. ZF macht hier sehr großen Nutzen, was auch der Entwickler tun sollte. Die besten Bugs werden als fehlschlagende Tests mit einer kurzen Fehlerbeschreibung formuliert, und mit einem kurzen Code-Diff und zugleich wieder funktionierenden Tests gelöst.
... Schlussendlich
Wie man vielleicht sehen kann, sobald alle kontaminierten Bereiche sichtbar sind, kann man den Insektenschutz auspacken und die Bugs innerhalb von Minuten ausmerzen. Das Beitragen von neuen Komponenten findet im Wiki in Form von "Proposals" statt, welche später vom Community-Review (Kern-Entwickler des ZF´s) beurteilt werden. Dieser Vorgang ist nicht trivial und umfassender, weshalb ich hier vielleicht einen Folgeartikel nachreichen werde. Wer immer einen Bug löst oder eine Erweiterung abliefert wird im Jira bzw. dessen Übersichtsseite gelistet. Kannst du es dort hin schaffen? Der Platz um dies herauszufinden sind ZF´s offizielle Bug-Hunting-Days, bei denen es jeden Monat ein Shirt zu gewinnen gibt. Als eine Fußnote möchte ich hinzufügen, dass sich die aktive Mitarbeit an einem Open-Source-Projekt in jeder CV gut macht.
Nachdem ich nichts mehr zu sagen habe, möchte ich noch einmal alle Entwickler da draußen aufrufen es auszuprobieren. Ein kurzes Zitat von Ben Scholzen (Kernentwickler des ZF): "I code whenever I feel like it": Schlussendlich zwingt einen weder die CLA noch der Jira-Account zu irgendwas. Sucht euch das Level oder die Komponente aus, auf welcher es sich für euch am besten arbeiten lässt.
Contributing to ZendFramework
... on contribution
Who hasn't ever started writing his own Framework/CMS? It is considered best practice for learning purposes, but going through all the security stuff can be stressful and boring at the same time. That's where most devs start to contribute to big Open Source-projects like Typo3 or the Zend Framework, because they are already experienced working with it and yet evolving another system on the market or even getting people to contribute seems like an unachievable task. Instead of wasting his time on yet another ACL implementation, the developer is taking part in making a software become even better, no matter if he delivers new features, reports / fixes bugs or works on documentation (another, yet an often underestimated part of contribution). It is also worth noting that every single Blog-entry and every HowTo thats put on the web also is a great deal of contribution that helps the software spreading. Beginners articles are important to put on the web since every one of us had it's beginnings and these are the sort of articles where many people decide to either use the software for a certain project or not.
As you might see, this article is not only a guide on contributing bugfixes, but also I want to motivate you to just give it a try.
... on Zend Framework
Having spent almost a year at the IRC support channel, I can tell they're really fun guys to hang around with. Of course, the Framework itself developed into a great piece of software. I do not want to discuss the up or downsides of a use-at-will framework, neither I want to recommend it over {put your favourite software here}. But what I can talk about is a little summary of the support channel's chatlogs. The widely annouced channel (which is #zftalk on Freenode) includes all kinds of concerns. One kind of people finds bugs, the other do have really clever ideas on improvements, but when you ask them to contribute its all the same: they either think it takes years to get into it, the others think they might be "not good enough for this". We sure won't force or threaten people to contribute, but what I can do is taking the fear out of it and demystify the thing, so later you might see that its actually just a few minutes to spend. Let me just loose a few words to the latter ones before we get into it: You can't destroy anything, and every idea of yours can also lead to a great improvement either realted to your concern or in a completely different area. We're glad that you take your time, even if you are completely new to ZF. Some beginners concerns already caused developers to write guides and articles that are still around and are linked at times in #zftalk...
... on contributing to Zend Framework
Contributing any code to ZF requires signing the CLA, which is an agreement that both you have the right to share any code you supply, and that you will not patent that code. This is to ensure that the frameworks codebase remains business friendly, and free to use for everyone. In fact you have to actually sign a paper, having done this you can just scan and mail or fax it. This is an important step, and none of your code will be used in any official package unless you did this.
The next step will be reading the coding & subversion standards. If you already had a look at actual ZF components code you should be familiar with the standards. Once you took a short insight (you probably wont be able to just remember all of this at once), you can check out the official SVN repository. Notice, that you, even having signed the CLA and being confirmed, do not have commit rights. So you might now ask yourself how to contribute then? All magic is taking place in the bugtracker, ZF's official Jira. All bug tickets, additions and improvements are filed as tickets here. So if you find a bug, report it here, and soon there will be a discussion in the comments section of a ticket.
Mostly all of these people, being listed by their reallife names, are also to be found on different names in the support channel, so feel free to ask them any ticket-related stuff.
The code itself will be submitted as a patch file (svn diff > patchFile), and uploaded in the Jira-Ticket. This might also be done by people who do have commit rights, but one might not be sure how to fix a problem, or any question might be left. This method of code management then leaves it to the original package developer to decide whether a change should be made or it should be thought over again (might have side effects on other packages and so on).
The last yet very important point is unit tests. ZF makes heavy use of them and so should you. The best you can do is report bugs as failing tests with a short description, fix them with the code diff and then deliver them with working tests.
... in closing
As you might now see, once the problems and the contaminated areas are visible, you can pull out your armory and kill the bugs within minutes. The contribution of new packages for the ZF are made in the Wiki, filed as proposals that later get discussed by the community review team, but I might do another article about that one as its a not so trivial workflow. Whenever you fix a bug or deliver an improvement you will be listed on the official Jira´s Overview page of top contributors. Can you make it to the top? ZF´s bug hunting days are the place for many contributors to join the battle on a shirt, but you might also see that being an active contributor on an open source project might be a good point of interest on your CV.
Having run out of things to say, I want to call all the devs out there to give it a try. A short quote of Ben Scholzen (ZF Core developer): "I code whenever I feel like it": In closing, remember that neither having an account on JIRA nor Signing the CLA ties you in to any minimum commitment, and you can do as much or as little as you are comfortable with. Just pick the level which feels right for you.
Wednesday, June 16. 2010
Profiling best practices: Benchmarking and optimizing real-world scenarios in a business context
Thursday, March 4. 2010
A comet over PHProjekt 6
Everybody knows GoogleMail with its easy to use frontend. Maybe you use it for your daily work. In GoogleMail, there is no need to refresh the page to receive a new mail, Google informs you automatically whenever a new mail is available. But how is this possible? The answer to this question is really simple: The server triggers a signal informing that a new mail is available. This technology is called Comet and describes a way how the server communicates with the client [see http://en.wikipedia.org/wiki/Comet_(programming) ].
Is there a way to use Comet for P6? As P6 works with a lot of users, it is important for me as a user to be informed when somebody has changed something in my projects or has added an urgent todo. The list where a notification could be triggered is long, but at the moment, only email notifications are sent immediately. So, what we need in P6 are real-time notifications. With real-time notifications, for example, every time somebody changes something in my project, I receive a message in form of a highlighted info box. This looks like a typical use case for using Comet. And yes, Comet would be great for realizing this kind of real-time notification! But since the users love the handy system requirements (Apache Server and MySQL) and the ease of installation, something different is needed than a real Comet architecture, because all the Comet magic is based on a so called application server, e.g. Jetty, Persevere. Therefore, I decide to implement another (Comet-) technology, called Long Polling. You can find the name AJAX Polling for this technology, too.
The technology behind Long Polling is to open a connection from the client to the server and not to close this connection immediately. Ok, that´s fine, but how to open a connection and "hold" it? Opening a connection to the server is easy, a simple AJAX will do the trick. P6 uses the Dojo Toolkit for all its AJAX, so in this case I used the Dojo.xhrPost.
dojo.xhrPost({
url: myUrl,
error: function(error, handle) {
handleError(myUrl, error);
},
load: function(response) {
if (false != response.data) {
showToaster(response.data);
}
},
handleAs: 'json'
});
Since the HTTP protocoll is connection-based, at the server-side, a process is also needed that holds the connection and does not return . So, what I do to hold this connection open is to set a simple timeout during the execution of the server-side script, in my case I use sleep(). This is the basic idea of long polling, but the gimmick of this approach is to return earlier if something happens on the server-side. In other words, I open a connection to the server and check whether there are any changes, if not, the connection stays open for the maximum polling time. If yes, the response will be returned to the client immediately.
This diagram shows the basic workflow, and the lines below show the possible solution in PHP:
$counter = 0;
$maxLoops = 4;
$data = array();
while ($counter != $maxLoops) {
$counter++;
$data = $this->getMessage($userId); // get data from database
if (false === empty($data)) {
return $data; // there is something new, return immediately
}
sleep(5); // nothing is new, sleep for 5 sec.
}
return $data; // return the empty array
For P6 this means that I always save the following: the person who triggers an event, the event itself (e.g. somebody adds a new note), the item, the project, the creation time, the time until this message is valid, and the persons who should receive a frontend message from the database. The long polling loop checks whether there is anything new. If yes, it returns the data. If not, the polling loop starts again. Every event is saved in the database for a maximum of two minutes, except events in the future. Itis real-time – so itis possible to miss a message ;-)
One word about the Dojo Toolkit. The AJAX API of Dojo provides several functions to communicate with the server. The easiest way is to use dojo.xhrGet or dojo.xhrPost. I decided to use the Post version. Although the function has a property setTimeout, which allows you to set the time to wait for a response from the server, this is not needed, because of the sleep loops at the server side.
Now, let’s look at the downsides of the long polling approach. Yes, I partly agree with everybody who says that the permanent polling to the server causes massive traffic and server load, especially with an increasing number of users. But in the special case of P6 this is OK, because the number of users is manageable and in most cases, P6 runs in a local network. In addition, the frontend messages are configurable, You can set the polling loop and the number of requests to the database.
Considering all the facts and keeping in mind that P6 is designed to be a lightweight open source groupware, I am positive to say that the Long Polling technology is the right choice for P6.
Thursday, September 17. 2009
PHP-Unconference 2009
Am vergangenen Wochenende (12.09./13.09.09) fand die dritte PHP-Unconference in Hamburg statt. Organisiert wurde die Unconference von der Hamburger PHP-User-Group im Geomatikum. An dieser Stelle möchte ich gleich dem Team danken, die Organisation war wirklich spitze, es fehlte an nichts.
Dies war meine erste Unconference und im Vorfeld war ich etwas skeptisch, denn es gab keine Liste mit Speakern und eingereichte Vorträge oder einen festen Zeitplan, lediglich auf der Webseite wurden Vorschläge und Interessen der Besucher gesammelt. Aus der Sammlung dieser Vorschläge wurde dann an beiden Tagen abgestimmt, welche Vorträge gehört werden wollen. Jedem Besucher standen dazu am Samstag und Sonntag jeweils drei Stimmen zur Verfügung, die mittels Aufkleber an die Vorträge vergeben werden konnten. An den Ergebnissen dieses Wahlverfahrens konnte man meiner Meinung nach auch erkennen, was die PHP-Community bewegt und vielleicht auch, in welche Richtung sich die Programmierung mit PHP in nächster Zeit entwickeln wird. Das schließe ich daraus, weil Vorträge wie „PHP Enterprise-Skalierbarkeit und Sicherheit“, „QA in Zukunft“, „Domain Driven Design“, „Test Driven Design“, „Scrum“, „Softwaremetriken“, „MVC Design Pattern“ und „Unit testing“ bestens besucht waren und die Diskussionen dazu oft über den Vortrag hinaus andauerten.
In denen von mir besuchten Vorträgen gefiel mir die Diskussionen zum Model View Controller Design Pattern mit Stefan Priebsch und den anwesenden Zuhörern am besten. Weit über den geplanten Zeitrahmen hinaus wurde besprochen, wie „Best Practises“ in der Umsetzung des Entwurfsmusters mit dem Zend Framework aussehen könnten. Aber auch in den anderen Vorträgen wurde eifrig diskutiert. Bei „PHP-Enterprise- Skalierbarkeit und Sicherheit“ wurde von Kris Köhntopp an Hand von vielen Beispielen gezeigt, wie überhaupt eine „Enterprise-Umgebung“ aussieht und welche Anforderungen dabei nicht nur an den Quellcode sondern auch an die einzelnen Softwareentwicklungsprozesse entstehen. Lars Jankowfsky und Johann-Peter Hartmann trugen mit ihren Erfahrungen zur Diskussion bei und belegten die Aussagen von Kris Köhntopp mit Beispielen.
Ein völliger Kontrast bildet der Vortrag „Rich Internet Applications mit Adobe Flex und Zend Framework“. Dabei stand nicht die Entwicklung mit PHP und dem Zend Framework in Mittelpunkt, sondern wurde gezeigt, wie mit PHP eine Schnittstelle zu Actionscript geschaffen werden kann und somit das Flex- Framework genutzt werden kann. Speaker Jörg Ohnheiser argumentierte den Einsatz von Flex mit den reichhaltigen GUI-Elementen die zur Verfügung stehen und der dadurch besseren Usabillity. Ich konnte nicht überzeugt werden und vertrete auch weiterhin den Standpunkt, dass auch mit Javascript- Toolkits, die solche GUI-Elemente enthalten, die Usabillity von Webanwendungen verbessert werden kann- unabhängig von einem einem Browser-Plugin (wie dies der Fall ist bei Flex- Anwendungen). Einzig bei Video- und Audio-Inhalten macht der Einsatz von Flex für mich Sinn.
Das Fazit der Unconference fällt natürlich sehr positiv aus, ich komme nächstes Jahr sicher wieder! Neben den guten Vorträgen stand vor allem das Netzwerken in den Kaffeepausen im Vordergrund und es entwickelten sich viele sehr gute Gespräche und ein reger Meinungsaustausch. Als Location war Hamburg natürlich auch optimal, neben der Unconference bot die Hansestadt genügend Möglichkeiten sich den Abend zu vertreiben, so zog auch der „PHP Mob“ durch verschiedene Bars und Kneipen.
Die folgenden Bilder wurden uns freundlicherweise von Ulf Wendel zur Verfügung gestellt, danke Ulf :-)
Friday, September 4. 2009
Silence of the LAMPs
A well-known but discouraged operator in PHP is the silence operator @, that supresses any output,
that a particular command may yield. Read on to find out how you should not use it.
Continue reading "Silence of the LAMPs"
Monday, August 31. 2009
Presentation Zen Vortrag@Mayflower-Würzburg
"...Vorträge von Entwicklern sind einfach. Die Fachthemen werden priorisiert und hierarchisch geordnet. Die Hierarchie wird "Agenda" genannt, und jedes Thema ergibt eine Folie, die alle Stichworte als Bulletpoints auflistet - welcome to the PowerPoint Hell. Genau 5 Minuten nach Beginn des Vortrags werden die Mails gechecked, nach 7 Facebook, und die Schnarchgeräusche ab Minute 10 lassen sich auch durch lautes Sprechen nicht mehr übertönen. Zwei Wochen kann sich der Zuhörer noch genau an den Titel der Präsentation erinnern, der Inhalt ist vollständig vergessen. Um das zu verhindern hat Garr Reynolds Presentation ZEN entwickelt. Mit ZEN meint er "Zurückhaltung, Einfachheit und Natürlichkeit" und verspricht, dass am Ende mehr hängenbleibt - und es auch mehr Spaß macht. Scheint zu klappen: Er ist der Typ, der mit den coolen Apple-Präsentationen angefangen hat..."
Die „Donnerstags-Vorträge“ werden sowohl in Würzburg als auch in München gehalten. Bei Interesse einfach das Blog beobachten, um auf dem Laufenden zu bleiben!
Wir freuen uns auf viele Teilnehmer!
Design-Patterns in PHP Vortrag@Mayflower-München
Am kommenden Donnerstag, den 03.09.2009 findet wieder ein öffentlicher Vortrag im Mayflower-Büro in München statt (Mannhardtstraße 6, S-Bahn Isartor). Beginn ist um 18:00 Uhr, Thema des Vortrags ist “ Design-Patterns in PHP“.
Sebastian Springer wird Argumente und Hintergründe für den Einsatz von Design-Patterns bei der Entwicklung von PHP-Applikationen präsentieren. Eine Auswahl der gebräuchlichsten Design Patterns, deren Hintergrund und Beispiele aus der praktischen Anwendung werden vorgestellt.
Die „Donnerstags-Vorträge“ werden sowohl in München als auch in Würzburg gehalten. Bei Interesse einfach das Blog beobachten, um auf dem Laufenden zu bleiben!
Wir freuen uns auf viele Teilnehmer!
Euer Weg zu uns
Friday, August 21. 2009
"Domain Driven Design" Vortrag@Mayflower-München
Am kommenden Donnerstag, den 27.08.2009 findet wieder ein öffentlicher Vortrag im Mayflower-Büro in München statt (Mannhardtstraße 6, S-Bahn Isartor). Beginn ist um 18:00 Uhr, Thema des Vortrags ist “ Domain Driven Design: motivation, naming methods, tests“.
Domain Driven Design (DDD) ist eine Methode, die in der Agilen Softwareentwicklung Anwendung findet. Hierbei wird das Hauptaugenmerk auf die Domäne selbst gelegt. Es steht also nicht die verwendete Technik zur Lösung eines Problems, sondern das softwaretechnisch zu lösende Problem selbst im Mittelpunkt.
Nina Schmitt wird bei dem Vortrag die Konzepte hinter DDD vermitteln sowie einige Methoden zu dessen Umsetzung vorstellen.
Die „Donnerstags-Vorträge“ werden sowohl in München als auch in Würzburg gehalten. Bei Interesse einfach das Blog beobachten, um auf dem Laufenden zu bleiben!
Wir freuen uns auf viele Teilnehmer!
Euer Weg zu uns