debuggable

When @predominant linked to a OSX release for google chrome the other day I couldn't resist.

My initial feeling: Awesome. Feels much snappier than Safari 4. My only two issues: a) No support for Safari-style keyboard shortcuts for the bookmark bar items. b) Even so chrome integrates with Keychain, it doesn't seem to use my Safari logins.

Lucky for me, Google also just released their Extension API. Two hours down the sink, I created my first extension: Bookmark Bar Shortcuts.

I switched from Firefox to Safari as my main browser a long time ago because I just could not deal with its slowness on OSX. I still have a few issues with Chrome, but I think they are due to the experimental Mac release. Once Chrome goes beta I'm pretty sure Safari won't be running on my computer anymore. Nor will Firefox once somebody ports Firebug to Google Chrome.

-- Felix Geisendörfer aka the_undefined

Update: @reconbot says Ctrl + <1-9> already works on Windows. Can somebody confirm?

Hey folks,

for a current client project of ours we had to build an extensive ACL-like permission system. It had to support roles permissions and specific user permissions, possibly overriding the roles permissions. So, to create a user, you had to first define his "role" or "level" as I called it in a dropdown box in a form.

However, the field users.level is an enum type and can have the values 'guest', 'user', 'admin', 'superadmin' and 'root'. The problem is that it could be possible that new levels were added in the future. There was no need though to have a seperate user_levels table and a UserLevel model there, since the system should simply not be as generic to allow that and adding a new level in the future would require a complete other version of the software. So I went the easy way.
Besides, as we use uuids, the users.level field would contain them and after all we want our database to be readable in our favorite db management system.

So what I came up with is a very simple behavior that can extract the options for any ENUM field. It uses simple caching in order for the query to not be run all the time, so make sure to clear your cache as you update your enum field options in the db.

Here is the behavior:

To put that into the form I did in the controller:

and then in the form:

Enjoy and please give feedback.

-- Tim Koschuetzki aka DarkAngelBGE

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.