Cal EvansSpecial Episode: Meet Cal Evans (Part 1) (20.11.2014, 14:47 UTC)

Cal sits down with Jeffrey (jam) McGuire

Show notes

PHP ClassesPHP and JavaScript Innovation Award Report November 2014 Edition - August 2014 nominees (20.11.2014, 08:22 UTC)
By Manuel Lemos
This is the November edition of the Innovation Award podcast hangout recorded by Manuel Lemos and Arturs Sosins to comment about the outstanding features of all the past month nominees and winners PHP and JavaScript packages, the prizes that the authors earned, starting with the nominees from the month of August 2014.

Listen to the podcast, or watch the hangout video, or read the transcript to learn why the nominated packages were considered to be innovative.
Piotr PasichHow to meet your estimations with the deadline (20.11.2014, 08:16 UTC)

Estimate a project or a task is a huge issue for all developers. Even if your experience allows you to be pretty sure that your estimations are complete and you shouldn’t exceed them then there always might occur some problems. The thing I struggle with is I always think as a developer. So, in the result, I give the expected time of development and a due date set with this estimation could be confusing or even wrong. Think about the Definition of Done – it’s a complex and long process between the moment when you get the information about the task and the date when it would be deployed on production environment. The development is only one of those steps and good estimations should cover the whole process and give you a space for coffee, xbox, wii and soccer table.

There are a couple techniques and methods to achieve this. Some of them are purposed to a different stage of the project or for preliminary estimations. I can be pretty sure that you know almost every of them and, most likely, used them to estimate some of your project as I did. But, it’s a good idea to have them written down in one place, just to remember.

Analogous Method

This is kind of my favourite of the very beginning of the project or before, when you get a specification, read and have no clue where to start, but you caught an idea, because you did quite similar project in the past. So, let’s compare example two projects from very high level point of view. Project 1 is the project I done, or you, and the Project 2 is our unknown future.

Project 1 Project 2
Business logic complexity Pure Quite Complicated
Amount of CRUDs 5 Probably 10
Amount of webservices 1 7
Amounts of users roles 2 7
Spent hours 700 ?

I can assume you that the specification of Project 2 seemed to be simple on the very beginning, but after a few months of work we realized that every single word matters and changes a lot. We had estimated this by two techniques. First, going through whole specification and writing down all necessary tasks, estimating them one at the time and counting all hours. Second, the Analogous Technique. The difference between results was just tremendous – about 300% (1000h vs 3000h), and the second was more accurate.

Moreover, time spent for working on estimations also differed. As you can see, there is no much things to compare in our table. You do not need to focus a lot on all aspects and risks of the project. Because you compare this to previous work with all problems, missing deadlines and features out of scope included, which cut the time necessary to devote.

As you can see I’ve written down only a couple of points to compare, but I recommend you to add there as much as possible. This will makes you able to see more differences and makes your estimations more accurate.

Expert Judgement

I call it as an estimation by recursion, because you have to ask an expert for help and he will try to estimate your project by one, picked method. One of methods to choose is, of course, the expert judgement.

It’s natural to ask somebody for help, so, do not hesitate to do this. Sometimes going to somebody works like an exercise with a rubber duck debugging. You explain your scope to the colleague and experience glare.

Three Point Estimate

This is one of my favourite. Programmers always have a problem with underestimated tasks, because of surely optimistic point of view. I must admit I’m an optimist too. During your planning sessions or even if you ask somebody there, you could meet a person who will tell – “I can do this in 8 hours”. But you thought that will take about 14 hours. Moreover, your Product Owner is indeed malcontent person and frequently changes his mind, so probably you will work about 20 hours. Your estimation is somewhere between these values, but where?

There are a few formulas which might be used to count the result value of your estimations. Most likely the result of all of them will be approximated, so I’d like to present only the one:

E = (o + 4m + p) / 6

Where the following signs mean:
– o – Optimistic estimation
– m – Most likely estimation
– p – Pessimistic estimation

To be more accurate in our Software Development’s estimations

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

Evert Potsabre/dav 2.1 released. (20.11.2014, 05:48 UTC)

6 months after the last major release, we just put sabre/dav 2.1 live.

I'm very excited to announce that we finally have support for CalDAV scheduling (rfc6638), which is a big deal and was hard to implement.

This means that invitations can get processed automatically, delivered to other CalDAV users, and clients that support scheduling will be able to accept or decline invites directly on the server, and ask for free-busy information.

We also now support vCard 4.0 (rfc6350), jCard (rfc7095) and converting between vCard 3, 4, and jCard using content-negotiation.

Thanks all! I hope it's well received :)

The full announcement can be found on the website.

As usual, we also prepared a migration document if you are upgrading from and older version.

SitePoint PHPYii 2.0 ActiveRecord Explained (19.11.2014, 17:00 UTC)

The ActiveRecord class in Yii provides an object oriented interface (aka ORM) for accessing database stored data. Similar structures can be found in most modern frameworks like Laravel, CodeIgniter, Smyfony and Ruby. Today, we’ll go over the implementation in Yii 2.0 and I’ll show you some of the more advanced features of it.

Model class intro

The Yii ActiveRecord is an advanced version of the base yii\base\Modelwhich is the foundation of the Model-View-Controller architecture. I’ll quickly explain the most important functionality that ActiveRecord inherits from the Model class:


The business data is held in attributes. These are publicly available properties of the model instance.
All the attributes can conveniently be assigned massively by assigning any array to the attributes property of a model. This works because the base Component class (the base of almost everything in Yii 2.0) implements the __set() method which in turn calls the setAttributes() method in the Model class. The same goes for retrieving; all attributes can be retrieved by getting the attributes property. Again, built upon the Component class which implements __get() which calls the getAttributes() in the Model class.
Models also supply attribute labels which are used for display purposes which makes using them in forms on pages easier.

Continue reading %Yii 2.0 ActiveRecord Explained%

PHP ClassesPHP 7 Release Date Settled - Lately in PHP podcast episode 53 (18.11.2014, 08:27 UTC)
By Manuel Lemos
Now that the main features of PHP 7 are practically decided, the PHP 7.0 release date is also being settled for late 2015. This was one of the main topics discussed by Manuel Lemos and Arturs Sosins on the episode 53 of the Lately in PHP podcast episode.

They also discussed the proposals to provide better Unicode support in PHP 7, as well the plans to remove deprecated features and the proposal to remove the function keywords from class declarations.

They also commented on a new article about accessing OAuth based APIs without user interaction.

Finally they talked about a new PHP and JavaScript best package recommendation system.

Now listen to the podcast, or watch the hangout video, or read the transcript text to learn more details about these interesting PHP topics.
Cal EvansInterview with Mike van Riel (18.11.2014, 05:00 UTC)

Twitter: @mvriel

Show Notes

SitePoint PHPIntroducing OctoberCMS – a Laravel-based CMS (17.11.2014, 17:00 UTC)

October CMS is a lightweight, back to basics content management system built on Laravel, and on a mission to make your web development workflow easy again. It boasts a very simple and fast learning curve, with a guarantee that you’ll be off the ground and up and running in no time at all. It’s scalable and extensible through the plugin system, is easily maintainable through its file-based system, and allows for the effortless creation of administrative back-end interfaces. Before we dig a bit deeper into this promising CMS, let’s look at the foundation a bit.

Built On Laravel PHP Framework

The Laravel PHP framework is lightweight, sturdy, and elegant. According to them, it’s a framework built with a creative user in mind, transforming mundane tasks into effortless, enjoyable ones. The philosophies of both Laravel and October CMS coincide very nicely, and it’s no surprise to see that October has gone with this type of framework. The combination provides the perfect mesh of simplicity, speed, elegance, and artisanal-style programming. Let’s now take a look at setting up our first October CMS project.

Continue reading %Introducing OctoberCMS – a Laravel-based CMS%

SitePoint PHPPractical OOP: Building a Quiz App – MVC (15.11.2014, 17:00 UTC)

In part one of this series we began, using the bottom-up design approach, by creating our Quiz and Question entities, writing a dummy Data Mapper class for the Quiz entities, and sketching the interface for our main service, \QuizApp\Service\Quiz, which will define the flow for a user solving a quiz. If you haven’t yet read the first part, I suggest you quickly skim through it before continuing with part two.

This time we’ll create and flesh out the \QuizApp\Service\Quiz service that will be the backbone of our application. We’ll then write our controllers and views using the Slim MVC framework, and, finally, create a MongoDB mapper to take the place of the dummy mapper we wrote last time.

Continue reading %Practical OOP: Building a Quiz App – MVC%

Matthias NobackPackages: the case for clones (15.11.2014, 15:30 UTC)

Don't reinvent the wheel

There is this ongoing discussion in the PHP community (and I guess in every software-related community) about reinventing wheels. A refreshing angle in this debate came from an article by Phil Sturgeon pointing to the high number of "duplicate" packages available on Packagist. I agree with Phil:

Sometimes these are carbon copies of other packages, but often they are feature-weak versions of established packages.

It doesn't make sense to do the same thing over and over again. At least I personally don't try to make this mistake. If I want to write code that "already exists", at least I don't publish it on Packagist.

However, recently I got myself into the business of "recreating stuff" myself. I released a set of packages related to commands, events, command buses and event buses called SimpleBus. Of course, I'm not the first one to write this kind of code. But here's the thing (and I'm quoting Phil again):

The golden rule is: If they are different, then awesome!

So in my defense, just a quick list of things that I want to offer with SimpleBus, which are different from existing packages. I wanted to offer:

  • Small packages with very simple features that can be used separately from each other.
  • Bridge packages to unlock some powerful features when combining some of the packages in one application.
  • Separate packages for framework integration (in this case Symfony).
  • Separate packages for integration with persistence libraries (in this case Doctrine).

Existing solutions combined way too many features in one package, which is to be considered the cause of people like me "reinventing the wheel". I don't want to have all that code in my project. And I don't want to keep upgrading a package when none of its changes are relevant to me.

When I created the SimpleBus packages, my hope was that maybe these would become the reusable components for other people's efforts to create full-fledged CQRS/event sourcing applications. My packages are very abstract, simple and are certainly not "fancy" in any way. Still they offer the amount of flexibility needed to implement any thing you need with it

A lack of good package design

So I admit, I've been rewriting some existing code (still there are subtle differences which I'll in another post). But why did I do it? Because existing solutions lack good package design. Now, what is good package design? Let me quickly explain about the Package Design Principles (they are much less known than the SOLID principles of class design):

  1. The Release/reuse equivalence principle - You can only reuse code that you release. Release only things that you can reuse.
  2. The Common reuse principle - Release classes together which are reused together. If you use one class in a package, you use (almost) all of the other classes too. In other words: if some classes in a package can be used without using all the other classes, they deserve to be in another package (this is the Interface segragation principle for packages).
  3. The Common closure principle - Packages should have one reason to change. If a package has multiple reasons to change, then split the package (this is the Single responsibility principle for packages).

These first three principles are about package cohesion. They tell you what should be in a package and when it's time to split a package. The second set of principles are about package coupling:

  1. The Acyclic dependencies principle - The dependency graph of packages in a project should have no cycles.
  2. The Stable dependencies principle - Packages should only depend on packages which are more stable than itself. Stable packages are less likely to change. A stable package has no dependencies, but is only being depended upon, i.e. it's a responsible package. Instable packages are dependent packages, and no other package depends upon them, i.e. they are very irresponsible.
  3. The Stable abstractions principle - The more stable a package is, the more abstract things it contains (abstract classes and interfaces). The more instable a package is, the more concrete things it contains (classes).

If all package maintainers would follow these package design principles when creating and releasing packages, there would be much more quality in the world of (PHP) packages. In most cases when I did reinvent the wheel, existing packages that provided more or less the same solution had issues with at least two of the abovementioned design principles.

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

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