in Back to PHP

My Way to PHP: Day 7 of 75

Ok, like everyday I published yesterday’s article. In The Pragmatic Programmer I’m on page 53 which is the beginning of section 11. My goal is 50 pages. Which is around the beginning of Chapter 4 or section 21.

Something that bugged me in the past was that the highlighting plugin I use (Crayon) didn’t support the new PHP keywords. I just added them and created a PR, let’s see if it works.

I’m looking for more interesting videos on youtube. And I realized how amazing the modern world is in regards to knowledge. I can look at talks to which I a) wouldn’t have access (e.g. Google talks or Facebooks) and/or b) they cost a lot of money (conferences, traveling, etc.). It’s pretty insane.

Idea: DeveloperTV – 24/7 streaming of YT videos about developing, IT sec, etc.

Here’s a talk by Gregor Kiczales about Aspect Oriented Programming (AOP):

He’s one of the main developer of AOP. The idea of AOP is that you have some method to access the direct environment of functions. That could be to do something before/after a specific call of a setter, getter, construction, destructor, etc. And that’s basically it!

The beauty of it is that you don’t have to change your method call to use an aspect. An aspect is something that’s orthogonal to your actual method: Logging, caching, etc.

Then there are join points. These are the points at which you can insert your aspects. And there’s advice which is the actual action taken.

One obvious example is that of an observer. It’s elegant with AOP but not so much with pure OOP.

For me AOP is a great addition to OOP. It makes sense in a Lisp-way.

Let’s say you have code like that:

Let’s also say that there are many more methods and classes and all that stuff. In Lisp you would write a macro. And a more elaborate version of this is AOP which doesn’t just handle calling an advice after a call but on other join points.

After the first 20 minutes most of the talk is about AspectJ which may be interesting if you’re developing Java but otherwise there wasn’t that much additional information.

I just learned that twig – the template engine for symfony2 can be extended. You can basically write a DSL in that. I just skim through the doc about extending it but it seems pretty easy so far. Even adding new language constructs seems pretty manageable. Definitely something I have to keep it mind :)

Here’s a talk about testing set-top boxes:

I really like the idea and the simplicity of it. They recorded the output of the set-top boxes using GStreamer and then did simple pattern matching with OpenCV. It’s a quite elaborate framework (stb-test) but the basics are pretty simple and it’s usable. Kudos!

PHP under the hood:

A talk about the inner workings of PHP. I liked his section about references although I knew the problems I agree with this recommendation writing functions. Don’t mutate the arguments.

Thanks to my functional programming background I’m damaged but really it’s so much clearer. The biggest disadvantage can be performance because PHP didn’t implement a performant immutable type system.

If a PHP script is running longer than a second, in most cases there’s something wrong.

That was fast. My pull request was just accepted. Yay!

Back to the book. In the chapter about DSL they make a good point about Python. You can implement your DSL using Python just as functions and program the interface. It’s pretty easy to read and write syntax wise and you just have to define functions. Alternatively, Lua would be a good idea thanks to the easy integration.

I just looked up lua and PHP and there’s actually an extension.

The interface is really simple. Here’s an example of loading a external file, giving lua access to a variable and function. I looked through the code and found an undocumented function called include which I will use.

I can’t say anything about access escalation. This is something I definitely would look up when I would use Lua. However, it’s probable – given the functions – that it’s a closed system. That is you could actually provide an interface for scripting your application. Pretty nice!

Here’s a cool exercise:

5. We want to implement a mini-language to control a simple drawing package (perhaps a turtle-graphics system). The language consists of single letter commands. Some commands are followed by a single number. For example, the following input would draw a rectangle.

Implement the code that parses this language. It should be designed so that it is simple to add new commands.

I will have two classes. I want one who does the drawing and one who does the interpretation. Let’s start with the drawing one.

I want to draw onto a canvas which will for now just be a 8×8 array. I hardcoded numbers just because this is an exercise and I don’t want to make it too complex. I could also extend some things into other classes but let’s keep it simple.

Ok, while thinking about the problem and trying something out I changed my design a bit. I have one class canvas on which you can draw, display it and set your pen.

I left out any error or boundary checking. Like I said for the sake of simplicity. I also written a Painter class which takes care of all the painting!

And now we can test it and it works :)


Now, let’s look at the parser and interpreter. We have a few things. Each command is in a different line. There are no empty lines. The first character in a line defines the function, which can be followed by one parameter separated by one whitespace. And there’s also comments. I will make an incredible easy parser which doesn’t care about much. There are better ways to do it – of course – but it’s just a small exercise.

Like I said it’s super simple. All it does it take the first character and the third of each line (this also means that no parameter can be bigger than 9 which doesn’t matter because I restricted the canvas to 8×8). Then looks up the command and its function call. Thanks to higher-order function, we can just call the function and we’re done. I’ve written a bit more robust interpreter which takes care of correct syntax, allows variable definition and handles whitespace well but for this example a super simple one is enough imho.

And the final code and test:


It works! Pretty cool exercise. Writing this took me a bit more than an hour – a pretty good investment for that additional ease of use! (Funnily enough, the Painter & Canvas class took way longer than the interpreter)

In the section about estimating there’s a good advice. Iterate and refine your estimates. You can give a fuzzy estimate at the start, e.g. 4-6 months. After a month, you can refine that. And then the cycle repeats.

Embrace the fact that debugging is just problem solving, and attack it as such.

This can be hard. I would also add: If you don’t find the bug after 15 minutes. Do something else for a while. Clear your mind and come back.

What are the disadvantages of using persistent connection in PDO?

Interesting question! And a simple answer. You are fucked if your script dies half-way. That could mean that a transaction is still open or a database is locked, etc.

I liked the idea of Design by Contract when I first heard of it. However, successfully I only applied it to interfaces with team mates. That’s something that works fantastic, btw. Agree what your classes are receiving and sending.

For methods / functions however, I found that Design by Contract either is really hard to do, trivial or basically the same code.

Example for hard to do is that you have an array with some arbitrary content. How do you check it? You probably use your program to do it anyways.

Trivial. Great example is the function sqrt(). You can beautifully check the precondition (input >= 0) and the postcondition (output * 2 = input).

Basically the same code. E.g. a function which returns max and you check that with max.

So, the usefulness wasn’t that great. However, I like one thing and that is that it checks the input variables and you don’t have to clutter your function with it. E.g. in the sqrt() case. You can write something like that:

Instead of putting a if and throw statement in your function.

The Law of Demeter is shortly mentioned. I found a good explanation in the c2 wiki:

You can play with yourself.
You can play with your own toys (but you can’t take them apart),
You can play with toys that were given to you.
And you can play with toys you’ve made yourself.

I’m currently on page 171 and it’s hard. Not that it’s hard to read but it’s a drudge. Like I said I’ve read this book about 8 years ago. And I enjoyed it a lot. However, at the time I was new to software development. I’ve written some code – sure – but I never learned about version control, shell scripting, processes, etc. In the meanwhile I learned all that.

I try to get as far as possible today so that I can get this off my list.

Starting a new project (or even a new module in an existing project) can be an unnerving experience.

I listened to a talk by Zed Shaw yesterday in which he talked about TDD and its advocates. He said that he experienced that people advocating TDD seem to be pretty good at tasks like writing tests. But often have problems coming up with innovative or new things.

After reading this line I have a theory. There are different types of personality. If you look at Big Five factors there is some which stands out. Openness to experience. I quote:

It is also described as the extent to which a person is imaginative or independent, and depicts a personal preference for a variety of activities over a strict routine.

Here’s my theory or better hypothesis: The TDD/Enterprise/JavaBeans guys score lower on the openness score than people like Zed Shaw. They feel comfortable because the style of working and environment fits their personality. People like Zed however want new experiences and embrace them. People like him and me have no problem starting a new project or module. It’s exciting. You have an empty sheet before you and you can create something spectacular. People scoring lower on the openness score however like if they know what to do, if they can work on existing products / code.

Ok, done with that book. I wonder if I would recommend it to a beginner. I think if so then to somebody who wasn’t exposed to the software development community – or not much. Otherwise, you will either get most of the tips from other people or learn it by imitation.

After all that fluff I need some substance. I had this book – which is the only book on the topic – on my reading list. I read one review about it which was bad, so my expectations are pretty low. The book is Functional Programming in PHP. It’s 122 pages long. Let’s start!

The book starts off with a history section and a bit of general foo about FP. One thing that irritates me a lot is the author’s focus on short functions or writing less characters. Really strange.

A lot of whitespace so far. I’m now on Chapter 8 (page 33). The book covered coincidentally the same content which I presented in my oral exam as a presentation at the finals in school (before college). This took about 15-20 minutes.

What I like so far is that he doesn’t write a lot of fluff. It’s up to the point. The question is if somebody without any knowledge about FP can effectively learn.

I quite like the illustrations. Ok, I’m through. Took me about 45 minutes. I’m not pleased but I’ll write a blog post about that so others can get an additional review.

In case you want to read it: Review on Functional Programming in PHP.

That took a while writing the review – I think about as long as reading the book. I have an other book from phparch on my resource list. That’s the same company that published FP in PHP. I’m a bit nervous, however there are several reviewers on Amazon which liked the book.

Great. I want to read through PHP The Right Way. It’s quite short, however I plan to read the linked resources.

While testing the build in server, e.g. php -S localhost:8080 brings up a local server on port 8080. I just realized how easy it is to bring a program to the web. I had only one .php file in the directory – that was my Interpreter from some hours ago and it worked on the web.

I haven’t decided yet if I’m going to develop on Linux or Windows. For the package manager alone I will probably go with Linux. Thanks to Vmbox I can develop on Linux on a Windows host which will be most likely be the one I will have at work.

Vagrant and PuPHPet are incredible. I really like that DevOp movement. Especially if I don’t have to set up all that stuff :P

I downloaded and install Vagrant and generated the config files but it wants me to restart which I will do tomorrow or so.

Ok, next stop is PHP-FIG. I’m going through all standards.

PSR-0: Autoloading Standard Normally, you’re not going to write an autoloader (probably), so the only think to remember is:

  • Namespaces are ()*
  • Each namespace separator is a new subdirectory
  • _ in class names are like directory separators
  • Only alphabetic characters

PSR-1: Basic Coding Standard

Here are the interesting ones (or the ones I want to remember):

Files SHOULD either declare symbols (classes, functions, constants, etc.) or cause side-effects (e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both.

I like that. Makes interop easier. Also reminds me of header files in C.

  • Classes in StudlyCaps: SomethingMaker
  • Methods in camelCase: makeSomething
  • Class constants with underscore and in uppercase HARD_GRANITE
  • Use namespace declarations

I have to say quite sensible so far.

PSR-2: Coding Style Guide:

  • 4 spaces for indenting (oh yeah baby)
  • Opening braces for methods and classes in the next line
  • For control structures in the same
  • abstract and final before visibility, static after

I’m very pleased with that guide. It’s sensible in my opinion. And there are a lot of crazy styles.

PSR-3: Logger Interface: Ok. The most important things are the interface:

There are the following methods: debug, info, notice, warning, error, critical, alert, emergency. There’s also log which logs at a given level.

Pretty good.

PSR-4: Improved Autoloading:

Here underscores don’t matter in classnames. Also it takes a base directory.

Now, there are 3 coding standards: PEAR, Zend and Symfony. I’m going with the latter just because that’s my desired platform.

Symfony coding standard

  • javadoc style comments
  • @param type $parameter description
  • @return type|type description
  • @throws \ExampleException
  • Type hinting if possible
  • Comma after each element in array (even last one)
  • One class per file (exception: private helper class)
  • public methods > protected > private
  • Use sprintf for Exceptions
  • Underscores only for option and parameters names
  • Suffix for Interface, Trait and Exception
  • Abstract prefix for abstract classes

Incredible standards again. Great!

Ok, enough for today. I’m currently at the start of Language Highlights. I also added an additional goal. Watching one video per day – on average.

Updates Goals:

  • Reread the Pragmatic Programmer
  • Learn about functional programming in PHP
  • Learn about coding standards
  • Get an overview of the standard library (SPL)
  • Learn about composer
  • Learn about caching
  • Learn about PHPUnit
  • Learn a bit more about legacy systems and how to handle them
  • Learn a bit more about MySQL
  • Learn Symfony2
  • Write at least one web app using Symfony2 and its core components (templating, testing, forms, validation, security, caching, i18n)
  • Learn the intricacies: how does the interpreter work, the OOP system, etc.
  • Get a bit more exposure to OOP and OOD
  • Watch one video per day on average (75 – 6)

Progress status


  • Reread the Pragmatic Programmer [done]
  • Learn about functional programming in PHP
  • Learn about coding standards

In Progress

  • Reading PHP: The Right Way [13 of 51 pages]

Write a Comment