My Way to PHP: Day 36-39 of 75

PHP Annotations: They Exist!

An annotation is a note that is made while reading any form of book or text


  • With PHP 5.1 getDocCoumments() was introduced

  • Get the configuration near the code

The rest of the talk are examples on how to use annotations and write your own ones with the Doctrine engine.


The Myth of the Genius Programmer

  • The myth of writing brilliant code and then reveal it to the world

  • Software is a community process / team effort

There’s a lot cultural stuff in it – I’d even say most of it.

The critique at around 45 minutes is great and perfectly summarizes the problems with the talk itself. Also interesting to see their reaction to that. It feels that they broke down in the Q&A session. Very interesting, indeed.


The Naked Bundle

  • Noback’s principle: Code shouldn’t rely on things it doesn’t need

  • Thus, code shouldn’t rely on a framework’s convention

  • You recognize a framework by the conventions

  • The problem with the bundle approach is that the code isn’t easily reusable outside of Symfony

  • The rest of the talk focuses on getting rid of implicit conventions and make things explicit

Really interesting talk! If you know my background most of my development wasn’t using web frameworks. I often used micro frameworks to just connect the end points. Therefore, my approach is just different. I talk about that a lot of times before yet I still think an application should be nearly independent of its presentation. And a good framework should allow to easily connect a commandline application to the web.


Decoupling with Design Patterns and Symfony2 DIC


There’s no single solution to extensibility. Because extensibility is not a single problem.

Interesting talk. Probably, one of the first talks about design patterns which actually uses them as a tool.



Updates Goals:

  • Learn Symfony2
  • Learn a bit more about MySQL
  • Write at least one web app using Symfony2 and its core components (templating, testing, forms, validation, security)
  • Watch one video per day on average

Progress status

In Progress

  • Watch one video per day on average [73 of 75]

Code Complete

Code Complete by Steve McConnel (2004)

code-completeIntro: I remember buying Code Complete in 2009 – this was before I gone to college. This was one of the books I saw recommended over and over again. Now, 5 years later I want to embark on the journey and read this tome of software construction.

After reading it I can say that it’s still a good book. I think for beginners (< 2 yrs) it’s really valuable. You can pick up some good habits through this book. You can learn things that others learned hard through experience. Definitely worth a look.

For more experienced people there isn’t that much new stuff in it.

The chapter on metaphors was interesting. I never realized how prevalent they were. Since the time of reading the book and writing this article I’ve read some other books who focus more on metaphors but nonetheless interesting. The question is how useful they are. Not in the sense of having a metaphor but in the sense of learning new insights.
So far (Chapter 3) it reads like a programmers guide to talking to managers; which I think is great for beginners into the job world but not that interesting for me personally. I think it has to do that I did quality management for some time so I know about the importance of requirements and uncovering needs and cost of errors in different stages, etc.

Problem description should be in user language

This is a great advice. I like it because it prevents you from jumping to solutions too fast. If you write – we need some PostgreSQL DB with these primary keys, and … – you think in solutions. And often the problem the customer has isn’t the problem you should solve.

5-15 productivity gain of high (Java, Smalltak, VB) over low-level languages relative to C

Not surprised. Interesting is that the gain varies by language. Java is about 2.5 times productive, Smalltalk 6 times and SQL 10 times. It shows to me the strength of Lisp because it allows you easily to build bottom up and thus basically build your own DSL for every problem you encounter.

Interpreted faster than compiled

Also not surprising. It boils down to faster feedback. Some interpreted languages offer a REPL which allows you to get even more timely feedback.

Habits of good programmers

This was a key insight. Good habits make a good programmer. I’ve written about habits ages ago – I sadly don’t have that post anymore. It was about written communication and writing correctly. Back then I talked to friends and some said that they are going to write correctly if they have to. I argued that you’re not going to learn it if you don’t practice – make it a habit. Same thing here.
Most of the stuff in this book wasn’t new to me but I’ve read tons of other books and have some experience in software development. What I noticed while reading the last quarter of the book how great functional programming can be. The author pointed out several problems and pitfalls which are solved if you use functional programming language.

The last interesting fact was:

Average programmer reads less than a book on programming/software development per year

That’s insane. He recommended to read 12 books a year and you will be pretty quickly above average. I know a lot of people read blog posts and online tutorials or stackoverflow. But a book is just different.

All in all, a good book for beginners. I would recommend it to them.

My Way to PHP: Day 33-35 of 75

Decouple your application with (Domain-)Events


  • Big controllers

  • Big models

  • No abstraction of business rules


  • “A significant change of state”

  • No return value

  • No way to stop the execution

  • Use eventDispatcher

  • Event as state approach (enables event sourcing)



The Internet is your Application Blueprint


  • The internet is designed as a decoupled s ystem

  • Why are we building monolithic systems?

  • The return of SOA

  • Comment as a Service (FB, Disque)

  • Authorization as a Service (FB, Twitter, OpenID)

  • Video as a Service (Youtube, Vimeo)

  • Plattform as a Service (AWS, Heroku)

  • Think in protocols / interfaces instead of implementations


The Clean Code Talks – “Global State and Singletons”

  • “It never said that it needed that” (regarding the lack of DI and use of Singletons)


Simplify your code with annotations

  • @Route also able to add

  • Requirements

  • Name

  • Method

  • @Security with has_role()

  • @ParamConverter to convert request parameters to objects

  • @Assert for Validation

  • @Service and @Cache


The sound and video isn’t that good sadly.

Diving Deep Into Twig

The video starts off with a simple overview over Twig and goes into creating own extensions. I’m again surprised how simple this is. The main part is an introduction into the workflow of the Twig compiler.

You could also use Twig templates with meta programming and just compile heavy compilations once and let them generate by Twig.

Updates Goals:

  • Learn Symfony2
  • Learn a bit more about MySQL
  • Write at least one web app using Symfony2 and its core components (templating, testing, forms, validation, security)
  • Watch one video per day on average

Progress status

In Progress

  • Watch one video per day on average [69 of 75]

Hacker And Painters

Hackers and Painters by Paul Graham

Hackers_&_PaintersI read this book December 2008 the first time. I don’t remember a ton of it. I wrote one blog post about the book. But I remember that I enjoyed it.

After rereading it I can say that it’s still a great book. One thing I noticed that he talked about a lot of things I later learned through experience. It’s hard to translate some words into wisdom but imho if you can take away one good idea from a book for around $20 it’s a good investment.

Why Nerds are Unpopular

The first essay  has a different vibe. Back then I felt good about hearing that it will be better in the future. But reading it now I feel sad for pg. It sounds horrible what happened in his high school years and I applaud him for opening himself.

In general, people outside some very demanding field don’t realize the extent to which success depends on constant (though often unconscious) effort. For example, most people seem to consider the ability to draw as some kind of innate quality, like being tall. In fact, most people who “can draw” like drawing, and have spent many hours doing it; that’s why they’re good at it.

If you read my posts for a while you probably know that I’ve started to program half-way seriously when I was around 15. Eventually I got pretty good – with around 19. I remember that some people told me that this was my destiny and I was born to program. But I wasn’t really.

When I was younger I began to play the drums. I think I started at 13. When I was 16 some people said I had a natural talent for playing them. When I started I was horrible – just like my programming. But I put a ton of work in it. I played around 2 hours every day at the drum kit, spend time listening to music and played it the beat with my fingers, I read stuff online, etc.

But this investment was small compared to that into programming. When I started half-way seriously at 15 I spent about 1.5 hour per day into programming. This lasted until I was 17. This was the time I switched school. This meant that Monday – Friday I had about 3 hours per day school-related exposure to programming / cs. Furthermore, around 1 hour talking to friends at school, learning or writing code around 2 hours at home and maybe talking another 1 hour on irc. This makes on average 3+2+1+1 = 7 hours a day. This was 3 years, so I spent around 7000 hours engaging to programming.

I would even say that I took longer at the beginning to learn the fundamentals. Or when I first learned Haskell it took forever. I sat there trying to write code to reverse a list (which is super easy). It took me I think about 4 hours. That’s why I like Lisps / functional programming general because you don’t have to be so clever to understand it. It’s pretty simple and less complex imho.

Hackers and Painters

What hackers and painters have in common is that they’re both makers.

I describe the maker as a creator. It’s the same concept, it’s about making something from nothing.

You should figure out programs as you’re writing them, just as writers and painters and architects do. […] It’s unrealistic to expect that the specifications for a program will be perfect. You’re better off if you admit this up front, and write programs in a way that allows specifications to change on the fly.


When it comes to code I behave in a way that would make me eligible for prescription drugs if I approached everyday life the same way. It drives me crazy to see code that’s badly indented, or that uses ugly variable names.

This is something I developed over the years. Aesthetics plays a role for me. I want to look at code and it should already say what it does just by the form of it. This why I like Python because it forces you to at least indent correctly.

What You Can’t Say

Although fashions in ideas tend to arise from different sources than fashions in clothing, the mechanism of their adoption seems much the same. The early adopters will be driven by ambition: self-consciously cool people who want to distinguish themselves from the common herd. As the fashion becomes established they’ll be joined by a second, much larger group, driven by fear. This second group adopt the fashion not because they want to stand out but because they are afraid of standing out.


Taste for Makers

But if your job is to design things, and there is no such thing as beauty, then there is no way to get better at your job. If taste is just personal preference, then everyone’s is already perfect: you like whatever you like, and that’s it.

A relativistic viewpoint becomes more and more prevalent. pg talks about a more objective standard to beauty. I agree and so does most of science. Even something subjective as the beauty of a face is consistent through cultures and people. I don’t know enough about the subject, yet. So take this with an extra grain of salt.

When you’re forced to be simple, you’re forced to face the real problem. When you can’t deliver ornament, you have to deliver substance.


GOOD DESIGN IS TIMELESS. In math, every proof is timeless unless it contains a mistake. So what does Hardy mean when he says there is no permanent place for ugly mathematics? He means the same thing Kelly Johnson did: if something is ugly, it can’t be the best solution. There must be a better one, and eventually someone else will discover it.

Related to this is Occam’s razor. It’s rather funny that you can look at some piece of code and think “that’s looks way too complicated” and you work on it and finally you found that you can make the code easier and in most cases less buggy.

GOOD DESIGN LOOKS EASY. Like great athletes, great designers make it look easy. Mostly this is an illusion. The easy, conversational tone of good writing comes only on the eighth rewrite.

I thought I’ve written about that but I hadn’t. This is a famous concept in Taoism called Wu wei which translates approximately to non-action. However, there are several interpretations of non-action. Here’s a video which explains these as levels:

  • concisely not acting – you observe
  • Patience – you’re not actually doing something actively
  • Flow / Effortlessness – it’s looks easy because the person mastered it
  • Doing without wanting – very spiritual

GOOD DESIGN IS REDESIGN. It’s rare to get things right the first time. Experts expect to throw away some early work. They plan for plans to change.

n.c. – see Borland Software Craftmanship

Nothing is more powerful than a community of talented people working on related problems.


Design and Research

Design doesn’t have to be new, but it has to be good. Research doesn’t have to be good, but it has to be new.

I love this. I will just comment on the design part. Reusing good design is a good idea. If we apply that to software development there are obviously design patterns or better OOP patterns. I know there are some database and architecture patterns but I never looked into it. Definitely something I will look into it in the future.

And yet, making what works for the user doesn’t mean simply making what the user tells you to. Users don’t know what all the choices are, and are often mistaken about what they really want. It’s like being a doctor. You can’t just treat a patient’s symptoms. When a patient tells you his symptoms, you have to figure out what’s actually wrong with him, and treat that.


To get good design you have to get close, and stay close, to your users. You have to calibrate your ideas on actual users constantly.

This is was bad graphic designer often do. They do aesthetics instead of design. Design follows customer requirements in a sense of ‘what the customer needs’.

In the software world, this idea is known as Worse is Better. Actually, there are several ideas mixed together in the concept of Worse is Better, which is why people are still arguing about whether worse is actually better or not. But one of the main ideas in that mix is that if you’re building something new, you should get a prototype in front of users as soon as possible.


Building something by gradually refining a prototype is good for morale because it keeps you engaged. In software, my rule is: always have working code. If you’re writing something you’ll be able to test in an hour, you have the prospect of an immediate reward to motivate you.

I agree and edw519 had an other great way to say this:

I love this example:

I now have a working program[sic] – Woo hoo! You say you want more features? No problem. Let’s start enhancing it.