debuggable

Nach einem sehr erfolgreichen Debüt in Berlin, freuen wir uns sehr den ersten exklusiv deutschsprachigen Workshop in München bekannt zu geben.

Unter der Organisation der CakeExperts bietet Debuggable Ltd. erstmalig am 15. und 16. Oktober 2009 im Telekom Center München einen Workshop an, bei dem erfahrene PHP-Entwickler in die Welt von CakePHP eingeführt werden.

Der Workshop findet an zwei aufeinander aufbauenden Tagen statt, in denen den Teilnehmern anhand der Entwicklung einer spezifischen Anwendung in CakePHP die grundlegenden Prinzipien des Frameworks vermittelt werden. Die Kosten für einen Tag betragen 400 Euro, für beide Tage 650 Euro – jeweils zzgl. MwSt.. Während sich der erste Tag stärker um die Grundlagen dreht, dreht sich der zweite um komplexere Problemstellungen und deren Lösung. Parallel dazu können in one-on-one Sessions spezifische Fragen mit den beiden CakePHP erfahrenen Dozenten Robert Scherer und Felix Geisendörfer diskutiert werden.

Robert Scherer, Leiter der CakeExperts in München, ist Spezialist in der Entwicklung PHP-basierter Webanwendungen und Autor des Buchs Webentwicklung mit CakePHP (Erschienen 9/2008 bei O’Reilly Deutschland). Felix Geisendörfer, einer der Köpfe von Debuggable Ltd., ist Mitglied im CakePHP-Core-Entwicklungs-Team und setzt sein tiefgreifendes Wissen über CakePHP seit Jahren in erfolgreichen Kundenprojekten ein.

Das Buchungsformular sowie detaillierte Informationen zur Agenda sind unter www.cake-experts.de/workshops abrufbar. Weitere Workshops finden statt am:
21. / 22.01.2010
15. / 16.04.2010
15. / 16.07.2010.

Die CakeExperts, eine Business Unit der M-Invent GmbH mit Sitz in München, sind zusammen mit der Debuggable Ltd. die deutsche Fachpräsenz des kostenlosen Open Source Frameworks CakePHP. Hinter den CakeExperts stehen die beiden Geschäftsführer Roland Bühler und Jürgen Jacob sowie hoch qualifizierte Mitarbeiter unter der Leitung von Robert Scherer.

Debuggable Ltd. wurde 2008 von Felix Geisendörfer und Tim Koschützki in Berlin gegründet. Die beiden CakePHP core Entwickler schlossen sich zusammen, um gemeinsam kommerzielle CakePHP Dienstleistungen anzubieten sowie an eigenen Projekten zu arbeiten.

M-Invent GmbH
Business Unit CakeExperts
Thierschstrasse 15
80538 München
Deutschland

Tel.: +49 (0)89 385 327 55
Fax: +49 (0)89 385 327 57
www.cake-experts.de

Pressekontakt:
Xpert-Marketing
Eine Business Unit der M-New GmbH
Thierschstr. 15
80538 München

mailto: nicole.thiel@xpert-marketing.com
tel.: +49 (0) 89 - 3585-4470
fax: +49 (0) 89 – 3585-4471
mobile: +49 (0) 179 – 74 96 263
www.xpert-marketing.com

-- Felix Geisendörfer aka the_undefined

Today we are very happy to announce our new startup transload.it.

Transload.it is a video uploading & encoding service that is designed to make developers happy.

You might have had a client before that said something like: "Oh, and it would be cool if you could upload videos in the application.". And he is right, it would be cool - regardless whether it is a client project or something you were working on yourself.

However - implementing a feature like this means work. Hard, tedious, frustrating trial & error kind of work to be exact. I'll spare you the details, but just trust me when I say your average client could not repay you for the suffering.

Meet transload.it - the cure for all video upload suffering out there. Our idea is simple: Create an account --> Include our jQuery plugin --> Done.

But jQuery can't encode videos you might say. This is where the XSS part comes in. Whenever somebody uploads a file on a transload.it-enabled form, the plugin actually takes this file and sends it to our cloud service. Even better, it also shows your users a nice upload progress bar - no flash involved! Try it out.

The uploaded files are encoded in FLV, iPhone, iPod or PSP format (you can configure that) and finally stored in Amazon S3. We will add an option for you to use your own S3 buckets as well as your own FTP, SFTP or CDN servers as the final storage targets.

Anyway, enough good stuff. Let's talk about a few sad things. This is an alpha version. We have only a single server online right now, so as people will simultaneously upload their adult video collections (not you of course) things might really fall apart.

We will bring more boxes online over the next week, promised. However to be able to diagnose & debug issues as fast as possible, we opted for a single-box launch.

Now it is your turn to go out there & break things, mention competitors who already launched a product like this 2 years ago or contact us about investment opportunities.

-- Felix Geisendörfer aka the_undefined

Hey folks,

since there is still little public information about CakePHP 2.0 and especially the all-new 3.0, I decided to do a little interview with Nate Abele, lead developer of Cake 3.

Hi Nate. CakeFest is over, and now everybody is slowly catching up on the announcement of CakePHP 2.0 and Cake 3. Can you give me a high-level idea of what those two new version are all about?

Well, CakePHP 2.0 is basically an update of the existing 1.x codebase for PHP5 strict mode compliance. What this means is that, beyond the benefits of shedding some extra code and structure needed for PHP4 compatibility, upgrading to 2.0 will give your applications, on average, a 25% speed bump right out of the gate.

Cake 3.0, on the other hand, is pretty different from the existing core code in a few notable ways. Mainly, it's been re-written from the ground up for PHP 5.3.

Is CakePHP 2.0 going to be compatible with 1.x? We saw a big upgrade from 1.1 to 1.2, is the upgrade to 2.0 going to be an even bigger one?

Actually no, CakePHP 2.0 will be almost 100% API-compatible with the forthcoming CakePHP 1.3, and 1.3 is still API-compatible with 1.2, except for a few deprecated (but still working) methods.

Also, when migrating from 1.2 to 1.3/2.0, we have a small migration guide which will alert developers to the few changes as they update their code.

Awesome, so it's going to be pretty much a free performance boost for all current 1.2 apps?

Yes, exactly.

Ok, back to 3.0. Can you talk a little about the fundamental changes in both PHP as language as well as its impact on the new CakePHP core?

Well, for CakePHP, going from PHP4 compatibility straight to a 5.3-only version is a very big jump, not only because of 5.3's new features, but also because of the features that have been available in PHP5 that we're now able to take advantage of.

One of the biggest new features in PHP 5.3, that has really informed Cake's new architecture is namespaces. The new core is organized into "packages", each of which builds off of other packages.

This not only makes the core itself very modular (i.e. packages can be used in non-Cake applications), but it also makes the plugin architecture extremely simple and powerful. Plugins can now include just as much functionality as any class in an application, or in the core, and can even dynamically replace core class dependencies.

Another of 5.3's new features is closures. Closures are anonymous functions (i.e. functions assigned to a property or variable) that can inherit the context of the scope in which they're defined. This allows us to inject custom functionality directly into classes and methods, and with 3.0, we've leveraged this in an interesting way with the filters system.

In the new core, many object methods implement this filters system, and this allows you to attach custom behavior directly to method calls: modify parameters on the way in, and return values on the way out.

This is extremely powerful, because it makes functionality like caching or logging a snap, as these can be applied in a completely unobtrusive way, without the class in question needing to know anything about how to do those things.

One thing we often struggle with as developers is figuring out which class a piece of logic belongs in, or coupling classes too tightly because each "needs" to know something about how the other works.

With this system, we can keep classes cleanly separated, but still make them talk to each other even though each one doesn't know anything about the other.

Another great feature of the system is that the interface is standard, and all filters can be applied the same way, so if you know how to write filters for one core class, you know how to write filters for all of them.

Do you have a simple example to illustrate this?

As an example, let's say I wanted to see a log of all the queries executed against the database. In Cake 1.2, we have logic built into the database classes to keep a record of queries that get executed, and output them on demand.

However, the database classes are for interacting with databases; they shouldn't have to know anything about logging.

In Cake 3, I can simply do the following:

Connections::get('default')->applyFilter('_execute', function($self, $params, $chain) {
  $out = fopen('php://stderr');
  fwrite($out, $params['sql']);
  fclose($out);
  return $chain->next($self, $params, $chain);
});

In this example, I'm getting an instance of the database object from the Connections class (this is equivalent to calling ConnectionManager::getDataSource() in 1.2), and attaching a filter that intercepts the _execute() method.

Now, I could send the output to a proper logging class, but for now I just want to see the queries sent to the error log, just so I can quickly see what's going on.

This code will now be executed every time a query gets run against that database, and all queries will be logged as I expect.

So filters are always instance specific and do not apply to a class in general?

The example is just a small taste of the power of the filters system.

For instantiated classes, yes, you typically apply them on a case-by-case basis. However, as the framework is still in progress, we have anticipated the need to apply configuration to all classes of a certain type, so in the future this will likely be possible as well.

Additionally, one new utility class available in 3.0 core is the Collection class. This class acts similarly to an array, but has some extra goodies, like allowing you to call a method on all the object instances it contains, just by calling that method on the Collection instance itself.

So in that way, it would be possible to apply the same filter to many classes at once using that technique as well.

Since you are mentioning the Collection class, I heard the Model layer is actually going to see the biggest changes in 3.0. Can you elaborate a bit on your plans for that?

Yes, in many ways the Model will change; in many ways it won't. For example, records are still queried by making calls like $posts = Post::find("all");

This, and much of the rest of the basic Model-interaction syntax, should be immediately familiar to anyone working with Cake currently.

Under the hood, however, the Model layer is completely new. Models now interact with the underlying DataSource architecture through a constrained set of methods using query objects. Query objects are extremely useful, as they allow us to encapsulate much of the query-generation work that was previously spread throughout several different classes. In addition, since the query object works with the data layer to generate queries, and since the core query object can be replaced with custom, user-defined objects, users can easily modify and extend the SQL syntax that Cake supports.

Building off of the Collection class mentioned previously, model return results have also been improved with the introduction of objects, not only for returned records themselves, but also for record sets. The RecordSet object, which extends Collection, acts like an array in that you can iterate over it with foreach and friends, but it has some other notable advantages, like being able to lazy-fetch records as you ask for them.

This reflects a design decision that plays out in many areas of the framework, which is only possible with the new, more object-oriented architecture, which is being lazy.

Any loading or processing that needs to take place, doesn't take place until it actually has to. Referenced classes aren't loaded until they're used, routes aren't compiled until they're queried, database results aren't fetched until you're ready to do something with them.

Aside from the many other architectural improvements, this makes the new core exceedingly efficient.

With all returned records being objects, does this mean CakePHP is moving towards a full ActiveRecord implementation?

Practically speaking, yes, that's where we're at. With PHP 5.3's new Late Static Binding features, we can now properly reference static classes as mentioned above.

Ok. A personal goal of mine is to stop using relational databases for unstructured data in 2009. Is Cake 3 going to be #nosql friendly?

Definitely. With the simplified DataSource interface and looser schema requirements, modeling non-relational data becomes almost as easy. The new model system is also more flexible in how it allows you to define the relationships between models; and with custom query objects, you can implement custom flags and expressions that are specific to whatever data store you're working with.

Fantastic! When can we expect to get our hands on those new goodies? Do you have a general timeline for cake 3?

While the code is immediately available at code.cakephp.org, it's still hard to say when we'll see an official release; but expect to see lots of movement on it in the coming months.

With Cake 3 advancing in both features as well as server-side requirements, how does it compete with frameworks such as Ruby on Rails, Django, etc.?

Well, conveniently, migrating from PHP 5.2 to 5.3 is pretty quick and painless, as very little has changed in the way of existing features. As ever, PHP itself is the easiest to use and easiest to deploy to platform on the web, and provided a host that supports 5.3, it's a simple matter of dropping the files in the web root, just like always. Additionally, with the falling cost of virtualized computing and readily available server configurations with PHP ready to go out-of-the-box, deploying Cake applications, or any PHP application, has never been simpler.

Maintenance for PHP applications has always been equally simple, and in terms of performance, PHP is always at or near the top. With its shared-nothing architecture, you never have to worry about memory management, dead-locked threads, or infrastructure issues when scaling across multiple web servers.

Ok, thank you very much for the interesting interview Nate. If our readers have any questions, will you be available to answer them in the comments?

Sure thing, thanks for having me.

If you are still looking for more CakeFest information, Matt published his CakePHP Digest #18 - The CakeFest Edition post and the first videos are starting to show up at live.cakephp.org.

-- Felix Geisendörfer aka the_undefined

Update: The Cake 3 codebase is still labeled as experimental by the cake project. Play around with it at your own risk, the roadmap is still subject to change.

Story time:

Thursday, July 2nd 2009. Officials announce the death of XHTML2. Multiple suspects, including HTML4, HTML5 and XHTML1 have been taken into pre-trial custody.

The investigation is difficult. XHTML1 seems to have no motive as XHTML2 was his son. The father can barely speak about his loss without bursting into tears. However, he is a very strict man and everybody knew he had extremely high expectations in his son. Could his bad temper have killed XHTML2 for making a simple mistake?

HTML4 however has a motive. He was once the big star in town. But then came XHTML1 and took that fame away. Every theater, including "the Fire Fox", "the Opera" and "the Web Kit" loved XHTML1 and told HTML4 it is time to retire. Not only that, many critics also saw great talent in his son XHTML2 who was competing with HTML5. So did HTML4 kill XHTML2 out of revenge, to free the way for his own son?

The prime suspect of course is HTML5. He was a direct competitor to XHTML2. The two had very different professional opinions. XHTML2, just like his father, was a strict perfectionist. HTML5 however is often characterized as a forgiving, practical performer. But investigators have found that HTML5 had the support of many cutting-edge theaters since at least 2004 and had no reason to fear XHTML2's competition. Did HTML5 feel he had to kill XHTML2 to simply destroy his strict philosophy?

3 years later. Investigations on the XHTML2 case have long been closed. XHTML2's death was classified as suicide. The media said XHTML2 could not gain the support of any major theater and killed himself out of desperation.

Now a new case is erupting the news landscape. HTML5 had a step brother, XHTML5, and his body was just found in a motel room. He was the new leader and last hope of a movement called "the semantic web". Probable cause of death - microformat overdose.

XHTML5's death marks the end of the movement. He and his followers thought they could make performance art accessible to a new audience of robots and intelligent machines. Those machines were very hungry for information, but could not understand performers like HTML4 and HTML5. "The semantic web" thought that by enforcing the strictness invented by XHTML1 and through the heavy injection of microformats they could perform at a level of perfection that could bridge the gap between the visuals and the underlaying information.

From early on, the "semantic web movement" was very violent. Non-supporters were labeled as reactionists. The standards developed by the movement made them totally blind for reality. The biggest theater, known for its greedy operators and huge audience, "the Internet Explorer" simply ignored the movement.

But then came JSON, a theater janitor who would permanently transform the stage. JSON himself was raised by JavaScript, a class of machines invented at the old "Netscape" theater. The JavaScript machines were originally only used to do basic lighting and other low-level work at the theaters and nobody really understood their true power. But through JSON they were able to communicate with other machines. Machines who previously only talked to XHTML1's grandfather - XML.

JSON just happened to be much more eloquent than XML, and his slang became quickly popular among a new generation of machines. And he became friends with HTML4 and HTML5. They could not understand each other directly, but the JavaScript machines were able to express JSONs thoughts to HTML4 & 5. So HTML4 & 5 realized that JSON could take over XML's job as a playwright.

And so the stage was slowly transformed. Plays were written by JSON who then performed them for the machines. JavaScript and other machines enabled HTML4 & 5 to perform the plays in their unique ways that were still more attractive to humans.

The XHTML family died because it wanted to write and perform for humans and machines alike. But the machines were not ready for it yet and wanted their own performances. Accepting this truth ultimately helped the humans who could now enjoy more entertainment & knowledge than ever, thanks to their automated friends.

=== The End ===

If you did not like the performance, entrance fees are unfortunately non-refundable. But feel free to release your grief over the death of XHTML in the comments.

-- Felix Geisendörfer aka the_undefined

We removed our old two-guys-in-a-garage theme and replaced it with the beautiful work of Abhay Singh. We could have kept the old look, but then we would have also had to buy a garage at some point.

We are now also offering commercial support for CakePHP, jQuery and Git.

Let us know what you think. That is other than that we should post more. We got a few goodies queued up already ; ).

-- Felix Geisendörfer aka the_undefined

PS: Be careful with our RSS bug, he does not like to be annoyed.