Day 8. Today, it will be one week since I started! I’m rather pleased with my progress and satisfied. My goal today is to finish PHP: The Right Way and watch at least one conference video.

---

I’m reading up on traits again. I still don’t have a good use case in mind. However, one interesting thing I learned is that use in namespaces resolves in the global namespace whereas use in traits is local.

After reading the original RFC and the wiki article on traits I stumbled on this question on SO: Traits in php – any real world examples?

Ok, so the main opinions are either a) you don’t need traits and b) you can use it for isolated cross cutting concerns, e.g. logging.

---

Something new, you can import functions via namespaces since PHP 5.6:

use function My\Namespace\functionName;

---

Composer! Here’s what I need to know

• composer require package:~version to update the composer.json
• composer install to install packages
• require 'vendor/autoload.php' injects composer’s autoloader
• You can add your own files to the autoloader in the compoer.json (supports PSR-4)

You basically map your vendor on a directory:

"autoload": {
    "psr-4": { "Foobar\\": "mysrc/"}
}

Now you can use a namespace like Foobar\Baz\Foo and it will include mysrc/Baz/Foo.php. And if you leave the key in the json (in this case Foobar\\) empty it will search your directory for any namespace!

Sweet!

---

Here’s a nice cheat sheet on using PHP and UTF8

• Set your DB to utf8
• Use mb_string and mb_* functions
• Set headers

---

I’ve looked into Behat – a storyBDD tool – a few days ago. It’s basically like Ruby’s Cucumber. Neat tool, especially nice for the final testing. I think I have a video about that in my queue. So it will come up some time.

---

Regarding caching, there’s APCu which seems to have the same API as APC had. Also important to note, it will cache inside a PHP process. That is, if you’re using (F)CGI, they cache won’t be shared between these processes. Here memchached could be a solution. I also want to look into Redis in the future.

---

And done! Good read, I knew most of the stuff so far – which is what I aimed to. This was probably one of my first exposures since I started and I modeled my goals a bit after that!

---

Before starting the next book I want to read a few articles from PlanetPHP.

---

New terminology from the article Fault tolerant programming in PHP: Circuit breaker. That is a wrapper around a class which can fail (mostly I/O). It will handle the errors through either

• Fallback
• Retry
• Monitors
• Or just fast failing

---

And a new pattern: Repository Design Pattern pack the data to a central place which can be accessed by a public API.

---

Good. Let’s start a new book: Mastering the SPL Library. It’s 182 pages about obviously about SPL. My first critique is that the title is Mastering the Standard PHP Library Library.

Let’s start! The SPL reminds my of C++’s STD on the first sight. The intro is a short essay about complexity.

It also covers the PHP internal hash table. This is the stuff I wanted to know about! So the implementation is pretty standard. They use double linked lists in case of hash collision. That also explains why for large N the look up time of the associate array converges from O(1) to O(n).

The hash table grows automatically – it doubles in size. And every time it does that it has to recalculate hashes!

---

An other talk – in German – I will summarize the most interesting facts:

The title is “Vor BDD und TDD war PDD” which means “Before BDD and TDD there was PDD”.

• PDD is Pain-Driven Development
• They show an actual – and still developed – source file which is just one class, with about 400 methods, and around 25k LoC. Insane!
• Sebastian (the creator of PHPUnit) actually build it because his professor mocked him that he didn’t want to do real software development in Java but in PHP. Sebastian then created the first rudimentary version of PHPUnit in one week which was a clone of JUnit at the time.
• About 6 months after the initial bet he expanded PHPUnit and published it. But for at least 2-3 years nobody really cared.
• A lot of QA tools are made by German developers
• They talked about Code Rank and Manuel’s project PHP Depend has a great overview over different software metrics.
• Code Rank (CR) is basically PR applied on Packages / Classes. The higher the CR the more this entity should be tested
• Use the complexity metric (Cyclomatic Complexity Number) for starters – the goal is between 12 and 14 for a method!

I normally subscribe to the idea that a method / function shouldn’t be longer than your head (or fit on your screen).

• The problem with CCN is that it doesn’t count the number of paths. It just counts the number of branches

If you want to have 100% branch coverage, you need at least one test for each path you can take. You can calculate that number with NPath Complexity.

• A huge amount of duplicated code is often a sign for communication problems in the dev team
• People starting with PHPUnit (or other QA tools) often feel pain and project it onto the tool itself

Incredible good talk! Sadly, only in German.

---

The next talk is titled: Recognising smelly code

• Methods should do a specific task

Code smells:

• High level of nesting (see CCN and NPath!) => decouple
• Bad naming
• Too many parameters => use a Object instead if possible
• Class should be a noun and should have a responsibility

Code smells:

• God object => decouple
• Tight coupling / typing new => DI
• Using arrays instead of objects => check if it makes sense

General code smells:

• Copy & paste
• Speculative Generality => YAGNI

---

This talk is titled: FAIL: The Best Ways to Bring Down Your Website.

So, far interesting war stories! Also failure normally means that your are out of something (CPU, Bandwith, Money, whatever).

The best way to fail is to be inordinately successful!

• Statelessness works great for scaling

Most of the talk is the admin / infrastructure side so far which I didn’t cover.

Even if you don’t care about the infrastructure watch the first 8 and the last 8 minutes for war stories.

---

This talk is titled: The 7 Deadly Sins of Dependency Injection

The first new terminology was Service Locator. I looked it up and it looked similar to a DI container. Here’s an article about the difference: Service Locator vs. DI container

The main difference is in the usage not in the implementation. The idea is that instead of injection all your dependencies you are going to write a class which returns you each dependency.

It also gets covered in the talk (around 33:00). For SL you explicitly call get and anyone could set them. For DIC however, you explicitly set the dependencies!

The problem is that you’re hiding the ‘mess’ with ServiceLocators most of the time.

---

The next terminology is ContainerAware. Here’s my source: ContainerAware considered harmful.

It’s like a DIC (DI Container) but not in the constructor but with one special setContainer() method. And this will be called implicitly at construction time!

They are even worse than ServiceLocators.

---

If there are two many dependencies injected feel free to split the class up into multiple ones.

Use constructor DI. If there’s an optional injection you can use setter injection.

---

The whole talked reminded me of a part of The Zen of Python

Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.

---

Another talked PHP Under the Hood, however a bit newer from 2014:

• Profiling: looks for bottle necks in the call graph, memory usage, etc.
• Benchmarking: actual performance

Jesus, I feel sorry for that guy. He has such a hard time breathing :/

---

Ok, now it goes a bit in depth. All data is stored in zvals (Zend values). The zval saves 4 things (the value, refcount, type and reference). Here’s the struct:

typedef struct _zval_struct {
    zvalue_value value;
    zend_uint refcount__gc;
    zend_uchar type;
    zend_uchar is_ref__gc;
} zval;

An interesting bit is the type zvalue_value which is a union:

typedef union _zvalue_value {
    long lval; // stores ints, bools and resources
    double dval; // float
    struct {
        char *val;
        int len;
    } str;
    HashTable *ht;
    zend_object_value obj;
} zvalue_value;

What’s interesting is that PHP never changes the zvals actual type but rather creates a new zval.

The rest of the talk looks at Opcode from a few simple examples. It’s very understandable!

Generally, pretty approachable talk. However, I would say that you probably need a bit of background. I make this assumption given a note in the description:

Note: This is an advanced talk, you should be extremely familiar with PHP and have some experience with profiling if you are to get the most from this talk.

What helped me is to understand how a VM works, some C, some Assembly and a bit of knowledge about operating systems.

---

Talk: Caching Best Practices

Caching everything that is expensive – either getting it once or once ever so often

I like the generality of that statement. Memorization can also be seen as caching.

---

Cache things that don’t change often

He presents several methodologies with variable flexibility. I quite like the idea of caching widgets and it made me aware about cache invalidation. There are cases when cache invalidation is clear and easy. One example is that, you have a push system. You can cache forever and then invalidate if you push out a change. That’s called update invalidation.

Alternatively, you can directly update the cache. However, it gets problematic if the database changes and the cache and DB get out of sync.

---

Pre-generation strategy: You proactively generate the cache. Facebook used that for new clusters.

---

The ideal form is the biggest-smallest re-usable object. Basically cache everything which doesn’t change often enough but has a big influence on the performance.

---

Solutions:

• APC for one machine, is incredible fast (runs in memory), native PHP interface
• Memcached / Redis for multiple servers

---

Multi-Layer Cache: Store data given access time and staleness.

• PHP instance = immediately
• APC = Quick expiration
• Memcached = longer expiration
• DB = worst case

---

Never store something in cache that you can’t recreate

Also use a DB.

Have external configuration for caching

E.g. in case of a traffic spike you can increase the caching.

Prefix your keys with a version no.

Saves flushing, no problem when rolling out a new version, and no old stale data which might be accessed.

---

The next talk is called PHP Opcache Explained.

That’s interesting: include, require and eval() in source files, are included, then executed and as soon one of these statements appears, these files get compiled again and executed!

---

So a OPcode consists out of an uint (internal numeric representation), an handler (actual function), two operators, a result, an extended value (e.g. a carry), the line no and the type information.

---

OpCache optimizes calculates at compile time which is great. For example, if you’re dealing with time you often write something like:

60 * 60 * 3 // 3 hours

This gets optimized!

---

OPCache just keeps old (wasted) files in the memory. If a threshold is reached it will recompile all the files.

---

Okay, back to the book!

Chapter 3 which presents all data structures.

SplDoublyLinkedList They actually implemented count() as O(1) by saving meta data. Otherwise, the complexity is like expected. What’s pretty cool is that you can set the iterator mode to LIFO and FIFO and so traverse the list backwards.

SplStack This shares the same codebase with the Double Linked List (inherits it) and could be implemented with LIFO mode.

SplQueue Nothing special about that. Also inherits from `SplDoublyLinkedList but uses FIFO mode.

---

SplHeap This is an abstract class and you need to implement a function called compare(). That’s pretty cool. Otherwise it implements a binary tree internally.

However, there’s a special case in the case something in compare() goes wrong. Then the heap is corrupted and throws an RuntimeException.

SplMaxHeap Like SplHeap but the maximum element is at the top (i.e. compare() is already implemented).

SplMinHeap The opposite of SplMaxHeap.

SplPriorityQueue Similar to the heaps but an other internal implementation. It still compares however, you add a priority when using insert(). It will then push out the most important (highest priority) item at first.

---

SplFixedArray Sweet. Traditional arrays implemented in PHP. You set the size at construction. You can however, also set a new size with setSize(). That’s pretty great.

SplObjectStorage Interesting. A hash map in which objects can be keys.

At the end of the chapter there’s a neat table listing all data structures and their complexities for different operations. Neat!

---

The next chapter is about iterators. There are a lot of iterators which I will talk about later. But how you can work with them is neat.

An example from the book:

$it = new DirectoryIterator("."); // lists all files in the current directory
$it = new RegexIterator($it, "/.mp3$/i"); // extracts only files with matched regex
$it = new LimitIterator($it, 0, 3); // returns only the first 3 

foreach($it as $file) {
    // 
}

That’s super cool!

To create your own iterator you just have to implement Iterator. And for filter iterators (like RegexIterator) implement FilterIterator – which has just one function called accept().

Man, that’s beautiful. I really love those iterators. Let’s see which ones are available in the SPL.

---

• AppendIterator = appends several iterators (key isn’t changed!)
• CachingIterator = caches all ‘old’ elements, can look ahead one and you can specify the __toString() behaviour
• CallbackFilterIterator = apply a callback to filter the elements
• FilterIterator = abstract class which allows to implement a filter
• InfiniteIterator = repeats the given iterator over and over again
• LimitIterator = returns the Xth to Yth elements
• MultipleIterator = returns the elements of several iterators simultaneously
• NoRewindIterator = the iterator can only be used once
• RecursiveIteratorIterator = iterates through all the children
• There are also several recursive iterators and one

---

Okay, enough for today :)

---

Updates Goals:

• Learn about composer
• Learn about caching
• Get an overview of the standard library (SPL)
• Learn the intricacies: how does the interpreter work, the OOP system, etc.
• 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)
• Get a bit more exposure to OOP and OOD
• Watch one video per day on average

Progress status

Done

• Reading PHP: The Right Way [done]
• Learn about composer
• Learn about caching

In Progress

• Mastering the sPL [155 of 186 pages]
• Watch one video per day on average [13 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:

function foo() {
    // ...
    doX();
}

function bar() {
    // ...
    doX();
}

function baz() {
    // ...
    doX();
}

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.

$foo = ...;
function bar() {
    // ...
}

$lua = new Lua();
$lua->assign("lua_foo", $foo); // provide lua access to $foo
$lua->registerCallback("lua_bar", "bar"); // provide lua access to bar()
$lua->include("myfile.lua"); // include and run the file

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.

P 2 # select pen 2
D   # pen down
W 2 # draw west 2cm
N 1 # then north 1
E 2 # then east 2
S 1 # then back south
U   # pen up

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.

class Canvas {
    protected $canvas;
    
    public function __construct() {
        $this->initCanvas();
    }
    
    protected function initCanvas() {
        $this->canvas = array();
        for($i=0; $i < 8; $i++) {
            $this->canvas[] = array_fill(0, 8, 0);
        }
    }

    public function display() {
        echo "\n\n";
        foreach($this->canvas as $line) {
            echo "\t", implode("", $line);
            echo "\n";
        }
    }
    
    
    public function draw($x, $y, $pen) {
        $this->canvas[$y][$x] = $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!

class Painter {
    protected $pen;
    protected $canvas;
    protected $penValue;
    // pen coordinates
    protected $x;
    protected $y;
    
    public function __construct(Canvas $canvas) {
        // start in the middle
        $this->x = 3;
        $this->y = 3;
        $this->pen = 0;
        $this->penValue = 0;
        $this->canvas = $canvas;
    }
    
    public function select($pen) {
        $this->pen = $pen;
    }
    
    public function down() {
        $this->penValue = $this->pen;
    }
    
    public function up() {
        $this->penValue = 0;
    }
    
    protected function moveHelper(array $orientation, $distance) {
        for($i = 0; $i < $distance; $i++) {
            $this->canvas->draw($this->x, $this->y, $this->penValue);
            $this->{$orientation['xy']} += $orientation['-+'];
        }   
    }
    
    public function goWest($distance = 1) {
        $this->moveHelper(['xy' => 'x', '-+' => -1], $distance);
    }
        
    public function goEast($distance = 1) {
        $this->moveHelper(['xy' => 'x', '-+' => 1], $distance);
    }
    
    public function goNorth($distance = 1) {
        $this->moveHelper(['xy' => 'y', '-+' => 1], $distance);
    }
    
    public function goSouth($distance = 1) {
        $this->moveHelper(['xy' => 'y', '-+' => -1], $distance);
    }
}

And now we can test it and it works :)

$canvas = new Canvas();

$painter = new Painter($canvas);
$painter->select(2);
$painter->down();
$painter->goWest(2);
$painter->goNorth(1);
$painter->goEast(2);
$painter->goSouth(1);
$painter->up();

$canvas->display();

---

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.

class Interpreter {
    protected $painter;
    protected $syntax = ['P' => ['parameter' => true,  'function' => 'select'],
                         'D' => ['parameter' => false, 'function' => 'down'],
                         'U' => ['parameter' => false, 'function' => 'up'],
                         'S' => ['parameter' => true,  'function' => 'goSouth'],
                         'W' => ['parameter' => true,  'function' => 'goWest'],
                         'N' => ['parameter' => true,  'function' => 'goNorth'],
                         'E' => ['parameter' => true,  'function' => 'goEast']];
    
    public function __construct(Painter $painter) {
        $this->painter = $painter;
    }
    
    
    public function interpret($input) {
        $splitLines = explode("\n", $input);
        foreach($splitLines as $line) {
            $command = $line[0];
            $parameter = $line[2];
            $this->execute($command, $parameter);
        }
    }
    
    public function execute($command, $parameter) {
        $internalCommand = $this->syntax[$command];
        if($internalCommand['parameter'] === true && $parameter == ' ') {
            throw new Exception("You forgot the parameter for {$command}");
        }
        
        if($internalCommand['parameter'] === false) {
            $this->painter->{$internalCommand['function']}();
        } else {
            $this->painter->{$internalCommand['function']}($parameter);
        }
    }
}

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:

$input =<<<END
P 2 # select pen 2
D   # pen down
W 2 # draw west 2cm
N 1 # then north 1
E 2 # then east 2
S 4 # then back south
U   # pen up
END;

$canvas = new Canvas();
$painter = new Painter($canvas);
$interpreter = new Interpreter($painter);
$interpreter->interpret($input);
$canvas->display();

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:

/*
 * @precondition $x>=0
 */
function sqrt($x) {
    //...
}

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

Done

• 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]