Bruno ŠkvorcPHP News You May Have Missed (23.4.2014, 16:00 UTC)

The last month or two have been chock full of small news and releases not warranting a full story in their own right but still interesting, I’ve decided to make a small compilation and direct your attention to the interesting developments around us. Just because we don’t cover something immediately, doesn’t mean we don’t notice or care :)

Ubuntu 14.04. LTS

enter image description here

Not so much PHP related, but still fairly important for our channel and future development purposes, the release of Ubuntu Server 14.04 LTS kind of flew by most people. This release will be supported by Canonical until 2019, which is a big deal as we can now all switch to this newest version as soon as it’s vetted by hardcore users. Stay tuned for upcoming Vagrant boxes predefined for 14.04. soon - we’ll be custom building and publishing some soon.

You can download the server version here and there’s a default Vagrant box available here.

GAE 1.9.1 - 1.9.3

enter image description here

Google App Engine has reached minor version 1.9.3., adding some more features and upgrades since the last time we talked about it:

  • bug fixes regarding Zend Framework, null characters in URLFetch, failed file uploads to Cloud Storage, long POST data, unlimited upload sizes and the fnmatch() function
  • ability to embed images in emails via the Content-Id header was added
  • the zip module is included by default now

The SDK has been updated and you can take it for a spin immediately. To see how you can do that, check out my previous article on GAE.

Continue reading %PHP News You May Have Missed%

Link
Brandon SavageUnit testing is dead? Hardly. (23.4.2014, 12:09 UTC)

Despite what His Majesty, David Heinemeier Hansson may have said, unit testing is by no means dead. And, in fact, system testing is no more a complete testing strategy than 100% test coverage with unit tests. Let me explain.

Test Driven Development (TDD) is a philosophy that asserts testing is so important that the tests should be written first, to emphasize the design of the code. The idea is that by writing a failing test, and then writing code that passes that test, you end up with an overall better architecture.

Of course, TDD has some flaws: namely it’s a “write to the tests” design strategy that, while potentially encouraging better design, can potentially harm your overall design by removing “big picture thinking.”

The problem is, DHH has basically said TDD is worthless, and system testing, not unit testing, is the way to go. And yet, this philosophy has just as many blind spots as TDD does.

Socorro used an “integration test” methodology to accomplish the majority of it’s testing. And while this worked well to avoid regressions in many cases, it also had many holes. One such hole that frustrated me was the complete lack of tests for the stored procedures in the database: I would write a stored procedure, and a middleware to access the results, but because the stored procedure created data on a cron cycle, there was no way to validate it automatically. You can guess which parts of my code often broke on staging.

Of course, system testing has a place alongside unit testing. System testing ensures a high-level assessment of the overall application, and ensures that we are getting the right answer at a high level. It makes sure that all our components come together and do their jobs. Unit tests won’t catch failed or missing database migrations, or Javascript bugs.

Unit testing, on the other hand, provides an opportunity for us to get nitty-gritty and to test specific avenues of our code for accuracy and effectiveness. Unlike a system test, a well-written failed unit test points right to the source of the problem, making it easier to correct. A system test will tell you that the system is broken, but you have to hunt for the cause.

By all means, we should be writing more, not fewer, tests. And we should be testing whole systems as well as specific units of code. Testing is not an either-or situation whereby we can only do one or the other.

Link
Stefan KoopmanschapWeCamp: Everybody is welcome! (22.4.2014, 11:06 UTC)

Last month we announced WeCamp, an event where developers can improve their skills not just by listening to people, but also by actually doing things. Response has been amazing: Many people love the idea, we’ve already sold quite a few tickets, and we’ve even got Magma giving a ticket as a price (At the time of publishing of this blogpost there’s only a couple of hours left, so if you want to win, be fast!). Since announcing the event, I’ve talked to several different people who had the same doubt/question about the event, so I thought I’d clarify things a bit more.

Who should come to WeCamp?

Everyone! We don’t want to exclude anyone and we actually think everyone would be a huge asset to the event. I’ve had people say “I’m not experienced enough in development to attend”, to which I could only respond “untrue!”. The idea of WeCamp is that you don’t just train your technical skills but also your social skills. For a less experienced developer, the practical experience of working in a team with more experienced developers is priceless. In that same team, however, the most experienced developer gets the additional experience of helping a less experienced developer with the work, gaining a lot of experience and knowledge on how you can help others. This social aspect is easily just as important as gaining technical skills. So both developers come out of this gaining experience.

But I’m a frontend developer…

So? If you’re a frontend developer, have a look at the many websites created by pure backend developers… do they look good? Are they accessible? Built according to W3C standards? Most probably not. You’re needed! While we have a focus on PHP, you’ll learn to work with PHP developers: How to communicate with them, how they look at frontend work, what tools are available in the PHP ecosystem for frontend. And I know this may sound scary, but you’d perhaps even get some PHP skills as well.

Additionally: WeCamp is not just about technology. We’ll go through all stages of a project, starting at thinking of a good idea through planning to development, deployment and perhaps even marketing! There’s more than enough to learn throughout this whole process.

But I wonder about…

If you have any more doubts or questions, please let us know! This is the first time we’re organizing WeCamp so we’re still very much looking for what works best with a lot of things. If there’s any unclarity, or you have comments for improvements, let us know! You can always tweet at us @wecamp14 but you can also shoot us an email: we-can@weca.mp. We’re also here to learn, so please help us do just that!

Link
Brandon SavageMeet Composer, your new autoloader (22.4.2014, 11:00 UTC)

Most PHP developers are familiar with Composer’s power as a package manager, and it’s ability to autoload all the packages it downloads. But what fewer PHP developers know about or use is Composer’s ability to load your code automatically, too.

In fact, developers can use Composer’s autoloader to autoload their own code, even if they don’t use one of the PSR standards for namespacing and path construction.

Using Composer with PSR-0 or PSR-4 for your own code

If you already apply either PSR-0 or PSR-4 to your own code, you can make use of Composer with relative ease. If you’re using PSR-0, you only have to give Composer the path and the namespace, like this:

    "autoload": {
        "psr-0" : {
            "Application": "src/"
        }
    }

The key tells Composer that all Application\ namespaced code iwll live in the src/ directory; PSR-0 expects that there will be an Application/ directory inside the src/ directory to contain all the code, too.

For developers who have upgraded to PSR-4, it’s as simple as making two small changes: switching the psr-0 to psr-4, and identifying the fully qualified namespace for the directory:

    "autoload": {
        "psr-4" : {
            "Application\\": "src/"
        }
    }

Using Composer for non-PSR-compliant applications

Legacy code often doesn’t follow the current PSR standards, and developers may find it impractical to switch. But that doesn’t mean that you can’t use Composer to autoload your code. In fact, with classmaps you can.

A classmap is a Composer feature that iterates through a directory and pulls the classes out of the files in that directory, and adds them to a classmap. Even though the application I’m using as an example implements PSR-0, we can still generate a classmap:

    "autoload": {
        "classmap" : [
            "src/"
        ]
    }

This produces a classmap that looks something like this:

<?php

// autoload_classmap.php @generated by Composer

$vendorDir = dirname(dirname(__FILE__));
$baseDir = dirname($vendorDir);

return array(
    'Application\\Controller\\Dashboard' => $baseDir . '/src/Application/Controller/Dashboard.php',
    'Application\\Controller\\Defaults' => $baseDir . '/src/Application/Controller/Defaults.php',
    'Application\\Controller\\Entry' => $baseDir . '/src/Application/Controller/Entry.php',
    'Application\\Controller\\Logbook' => $baseDir . '/src/Application/Controller/Logbook.php',
    'Application\\Controller\\RequiresAuth' => $baseDir . '/src/Application/Controller/RequiresAuth.php',
    'Application\\Controller\\User' => $baseDir . '/src/Application/Controller/User.php',
    'Application\\Model\\LogEntry\\Defaults' => $baseDir . '/src/Application/Model/LogEntry/Defaults.php',
    'Application\\Model\\LogEntry\\Gateway' => $baseDir . '/src/Application/Model/LogEntry/Gateway.php',
    'Application\\Model\\LogEntry\\HourReports' => $baseDir . '/src/Application/Model/LogEntry/HourReports.php',
    'Application\\Model\\LogEntry\\LogEntry' => $baseDir . '/src/Application/Model/LogEntry/LogEntry.php',
    'Application\\Model\\LogEntry\\LogEntryCollection' => $baseDir . '/src/Application/Model/LogEntry/LogEntryCollection.php',
    'Application\\Model\\LogEntry\\Storage' => $baseDir . '/src/Application/Model/LogEntry/Storage.php',
    'Application\\Model\\User\\Gateway' => $baseDir . '/src/Application/Model/User/Gateway.php',
    'Application\\Model\\User\\Storage' => $baseDir . '/src/Application/Model/User/Storage.php',
    'Application\\Model\\User\\User' => $baseDir . '/src/Application/Model/User/User.php',
    / ...
);

This has some definite advantages for projects that are still stuck in legacy mode: the ability to autoload classes automatically, without rewriting massive amounts of the application. Though there is also a significant drawback: unlike PSR-0 or PSR-4, the classmap has to be updated every time a file is renamed or a new class is added. This can be avoided by using the classmap only for legacy classes, and writing new classes to be compatible with a PSR standard.

The bottom line

You don’t have to maintain your own autoloader or rely on outdated technology to keep autoloading your files. Composer offers a great number of options built into a tool you’re probably already using anyway. Give it a shot!

Link
Liip prismic.io content repository as a service (22.4.2014, 10:09 UTC)

Just before Easter I tweeted out an idea that I already threw out there a few weeks ago: Creating a PHP Content Repository (PHPCR) implementation on top of the prismic.io content repository as a service. Well I had a lot of time on the train over Easter, so I decided to make it happen. Obviously coding against a remote service on the train isn't that much fun, so in fact I did a lot of coding, waited for the next train station, hit refresh a few times and so on and on. I briefly tried to setup php-vcr to log all web requests and replay them, but unfortunately the library isn't quite ready to do this yet .. but mit might be soon. Also as prismic.io's content pages are actually all versioned we will soon hopefully get caching provided inside their PHP SDK. But I digress. So without further ado, I present to you an initial working version of PHPCR integration with prismic.io. There are obviously still a ton of todo's left .. fundamentally it works, I can read prismic documents as PHPCR nodes with properties.

Why bother?

At this point you may either be excited or wondering why I am bothering with this. If you are in the former group, you can maybe skip to the next section, if you are in the later group, let me expand. One reason to bother with this is to simply show its possible, that PHPCR indeed fullfils this promise of being able to provide a unified content repository API. We obviously have 3 implementations already but taking such a service seems to push the boundaries a little harder. The next reason is more practical: prismic.io is simply a very useful service with an awesome user experience, especially for people focused on managing content rather than managing pages on a website. And they are doing this with an awesome UI, argueable the main week spot of the CMF (though I am quite excited about the work by the sulu.io team).

The sky is the limit?

Now prismic.io has some major differences in how content can be structured compared to plain PHPCR. Specifically they do not really structure their content into a tree per se. Instead they just have a pool of documents with UUIDs. Now it is possible to reference those UUIDs inside documents which kind of creates a tree structure. There is also native support for tagging and finally a way to bookmark document UUIDs to names. In a first step all I did was create a virtual root node that has the entire document pool as children where the names match the bookmark name (if one exists) or the UUID. All properties, including nested documents, are then mapped to properties on those children. Eventually nested documents should however maybe be exposed as child structures. Another limitation is that prismic.io currently only provides a read API. But given their awesome UI, why would one want a write API? ;)

The sky is the limit!

But there is a lot possible yet. For example they provide a predicate based query API that I am very confident we will be able to map to the PHPCR query languages SQL2/QOM, similar to how we map them to SQL with Doctrine DBAL. They also support versioning, which can probably be mapped to the PHPCR simple versioning concept. They also support node types which I have already mapped but there is still work todo to map all the contraints. They also support custom namespaces which PHPCR also supports. The way they support images (and binaries) also lends itself very nicely to the stream based approach in PHPCR. So with a few more days of work, I think we can provide a pretty powerful PHPCR API for prismic.io. What will make the collaboration easier is that it turns out that Thibault, founding member of the Symfony CMF initative gone Scala-lover, works for zengularity.com who created prismic.io. But Rudy was actually the first one to jump on my tweets and he has already signed up to the CMF mailinglist and given important insights.

Where to go from here?

I am not sure how much time I will have on this in the coming days. The CMF 1.1 release is sti

Truncated by Planet PHP, read more at the original (another 923 bytes)

Link
Bruno ŠkvorcDatabase Versioning with Ladder Migrations (21.4.2014, 16:00 UTC)

Version control systems are invaluable for tracking changes in your code, particularly when you’re working in a team. However, most applications don’t consist solely of application code. Managing changes to the database has always been a little more challenging, particularly when you’re adding new features which require changes to the schema.

Suppose you’re working on a module and realize one of the database tables needs an additional column. You might be tempted to open up a database query tool or the command line and simply add the column. However, this doesn’t leave a record of the change in the same way as version-controlled application code would. This gets exacerbated when working in a team - if a colleague pulls your code changes without running those same database updates, then it’s entirely possible their version of the application will break. This becomes even more problematic when you’re releasing a product update, when it could break the application not just for your fellow developers, but for your users.

One solution is to move responsibility for creating and modifying the database schema into code, using migrations. That way, changes can be managed along with the rest of your application, and features we take for granted in version control - such as being able to compare versions and keep an audit trail - can be used for database changes. It also allows these changes to be seamlessly incorporated into releases, since they can be made part of the same branch or tag.

Many major frameworks have their own migration implementation, but for those that don’t - and if you’re not using any framework - there’s Ladder.

Continue reading %Database Versioning with Ladder Migrations%

Link
Paul M. JonesSubmit To The Central Scrutinizer (21.4.2014, 14:54 UTC)

(N.b.: I was unable to write this post without saying “ssscrrrrutinizer” out loud over and over. I blame my friend Ray Chavarie for inflicting Frank Zappa on me at an impressionable time in my life.)

After finishing Uncle Bob’s excellent Clean Code recently, I have been looking at my own code in Aura v2 even more critically. I started trying to apply more of the Clean Code principles to the different libraries, and thought I had done pretty well. But then I saw a scrutinizer.yml file in Luis Cordova’s Gush project, and I was curious about it.

I visited scrutinizer-ci.com to read up on the project, and man was I floored. Here is a service that will analyze your project on Github and assign it a quality grade that aligns really well with the Clean Code principles (among others). After you register a repository with Scrutinizer and perform the first analysis, you can fine-tune the process with a config file so that the Scrutinizer looks in the right directories for source code, gives you code coverage analysis, and so on.

For one of my first experiments with the Scrutinizer, I started with the Aura.Sql_Schema v2 package. I thought it would come out pretty well, but even after pointing the Scrutinizer in the right direction, it only scored an 8.61 or so. I guess that’s OK — but could we do better?

Using the Hot Spots page I was able to find the worst offenders in the classes and methods. Because we have 100% test coverage on all Aura code, it was a only matter of applying appropriate refactorings — the tests help to assure that changes don’t break anything. (The Scrutinizer will even suggest refactorings for you to apply.)

After the refactoring processes, the Scrutinizer reported a 9.46. You can see the Scrutinizer report for Aura.Sql_Schema here. There’s still room for improvement, but at least I know where the greatest improvement opportunities are.

Now that I’ve got a few days’ experience with Scrutinizer, I find it a very valuable tool. It’s very helpful as an objective assesment of code quality, so much so that I have added Scrutinizer badges to each Aura v2 package readme. You can see all the badges for all the packages on the v2 packages page.

Maybe the rest of the world knew about Scrutinizer before this, and I’m late to the game. I had not heard about it until recently, and now that I’m aware of it, I think it’s a great service for any developer concerned about code quality. Congratulations to @schmittjoh and everyone else involved in Scrutinizer. Very nicely done!

UPDATE: In response to a question elsewhere: yes, Scrutinizer is free for open-source projects.

Link
PHP ClassesIs the Hack Language Going to Replace PHP? - Lately in PHP podcast episode 46 (21.4.2014, 09:51 UTC)
By Manuel Lemos
The release of the Facebook Hack language has shaken the PHP community since it implements several frequently requested features that were never implemented, many users are considering to drop PHP in favor of Hack.

This was one of the main topics discussed by Manuel Lemos and Arturs Sosins on the episode 46 of the Lately in PHP podcast.

They also talked about the OpenSSL Heartbleed security bug may affect PHP sites or not, ideas for the PHP 6 engine, the need for an official PHP specification, and an advanced email validation that can provide suggestions for address typos like Google did you mean feature.

Now listed to the podcast, or watch the hangout video or read the transcript to learn more about these interesting PHP topics.
Link
Bruno ŠkvorcDatabase Versioning with DBV (19.4.2014, 16:00 UTC)

It’s good practice to always use a version control system in any of your projects. Be it a side-project in which you are the only developer, or a team project where five or more people are working on it together. But the idea of putting your database into version control isn’t really that widespread. Often times we take the database for granted.

But like the source files in our project, the database is constantly changing too. That’s why we also need a way to track the changes that we have made and easily share it to other members of our team.

In this article we will take a look at DBV, a database version control system written in PHP for MySQL databases so you need to have PHP and MySQL installed before you can use it, along with a web server like Apache or Nginx.

An important note about this software is that it is not a stand-alone database version control system, because it needs a version control system such as Git, Mercurial or SVN for syncing changes with your team.

Installing DBV

To start working with DBV, first you have to download the installer from their website, extract it into your project directory then rename the resulting folder to dbv. This will give you the following path:

my_project/dbv

An alternative approach is just cloning from Github.

DBV Configuration

You can start configuring the options for DBV by creating a copy of the config.php.sample file and renaming it to config.php.

The most important things to update here are the first two sections. Just substitute the values for my_username, my_password, my_database for the values in your current database configuration:

Continue reading %Database Versioning with DBV%

Link
Christian WeiskePhancap: Your own website screenshot service (18.4.2014, 21:02 UTC)
Website screenshot
Full page screenshot

My bookmark manager SemanticScuttle is able to show screenshots for bookmarked websites, but always relied on an external service to generate them. The service shut down now - time to look for an alternative.

There are several dozen screenshot services on the internet; some have free plans that would allow you to re-enable screenshots on your self-hosted SemanticScuttle instance for free. But unfortunately this means registering at yet another service and being again dependent. Time for something new!

phancap

Over the last three weeks, I built phancap - a self-hosted website screenshot service. With it, your bookmark manager will never have to depend on an external service again.

It's easy to setup: Simply drop the .phar in your webserver's document root, install xvfb-run, cutycapt and imagemagick, and you're done.

It supports JPG, PNG and PDF output formats. PNG is ideal for screenshots, while full-text PDF is nice for long-time archiving of web pages.

You may configure the browser and thumbnail size, and can choose between a fixed height and full-page screenshots. Authentication may be enabled to prevent others using your server resources.

Download it or grab the source code (github mirror).

Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP