in Back to PHP

My Way to PHP: Day 17 of 75

I just published yesterday’s post and review. I’m thinking about watching some talks today. This is one of the things I want to push forward so I don’t have to care about it anymore.


PHP, Under the Hood

  • SAPI = Server API (e.g. mod_php, fcgi, etc.)

Execution pipeline

  • Startup
  • SAPI <-> Request
  • Shutdown

This happens once per lifetime of the engine.

For each request there’s:

  • Request init
  • Compile Code
  • Execute Code
  • Shutdown request

I wished that the talk would have gone into more depth and covered less. :/


Vertical reusability through components

He talks about building self-contained components which include everything from the model to the view. This reminds me a lot of Presentation-Abstraction-Control. He didn’t talk about that, yet. So let’s see.

  • Data is rendered on the client side (templates can be created on the server)

Here’s how they describe it:

widgets-pac

Looks very similar to PAC.

  • Widgets pull the data they need which is defined in an abstract syntax

Making PHP go fast

 

  • Interesting, no caching but fast page creation
  • Data only generated when it changes

Pretty interesting talk.


How To Stop Sucking And Be Awesome Instead

  • Software sucks but it gets better
  • Boyd’s Law of Iteration:

Speed of iteration always beats quality of iteration


I decided to tackle Domain-Driven Design by Eric Evans. I read that the book is very wordy and a bit abstract. Nonetheless, I like the idea of DDD.

Let’s start:

Effective Modelling

  1. Binding the model and the implementation (prototyping)
  2. Cultivating a language based on the model
  3. Develop a knowledge-rich model
  4. Distilling the model
  5. Brainstorming and experimenting

It’s about understanding the domain you’re modelling. The trick is that you use the existing business knowledge, the abstracts and translate them into your software.

It’s a neat idea because it makes talking about it and extending the system easier. If it there’s in the business it’s there in the software. Of course, you don’t want to model everything there is but nonetheless you know where to connect.


Vocabulary of the ubiquitous language

  • Name of classes and prominent operations
  • Terms about explicit rules
  • Terms about high-level organization (context maps)
  • Frequent patterns

  • Talk out loud about your software to find a better abstraction. It should be crisp and domain-oriented.

The vital detail about the design is captured in the code.

n.c.

the Prolog language is a natural fit for model-driven design. In this case, the paradigm is logic, and the model is a set of logical rules and facts they operate on.

Interesting observation. Prolog is indeed excellent for this task because (theoretically) all you have to do is to define the model and Prolog takes care of the computation.

If the people who write the code do not feel responsible for the model, or don’t understand how to make the model work for an application, then the model has nothing to do with the software

Reminds me of one my favourite and probably most influential talks about software development I’ve heard. The speaker said (approximately): “I need experienced people, people how can write code and model effectively.” He needed and had Architect Developers.

  Every developer must be involved in some level of discussion about the model and have contact with domain experts.


When applying a framework, the team needs to focus on its goal: building an implementation that expresses a domain model and uses it to solve important problems

n.c.

  • Entities Identity, can change state
  • Value objects A state of something else
  • Services Does something on request

Associations

Pretty interesting. He recommends making associations between classes as string as possible. This makes it easier to write code. These are the things he recommends:

  1. Imposing a traversal direction
  2. Adding qualifier
  3. Eliminating non-essential associations

Entities (Reference Objects)

The identity doesn’t change though it state or attribute can. E.g. one gets older, looks different, may change their name, etc. Still the same identity.

Identity is a subtle and meaningful attribute of entities, which can’t be turned over to the automatic features of the language.

Later, he says quite well: A model must define what it means to be the same thing.

The basic principles of database design apply here as well.

Value Objects

  • Are often parameters for messages between objects**
  • Sometimes created and then discarded
  • Used to create an Entity
  • Immutable

Rule of Thumb: You care about only about the attributes!

Services

  • Activities or actions, not things
  • Relationship to other objects
  • Purely defined in terms for what it can do for others

Characteristics of a good service:

  1. Operation doesn’t naturally fit into entities or value objects
  2. Interface is made up by other elements in the domain
  3. Operation is stateless

Clean Code Talks: Don’t Look For Things!

  • Ask only for that what you really want (constructors, etc.)

Isn’t it strange that a car knows how to build a factory and then uses the factory to build an engine for itself.

Love this. This works so nice with the recommended from DDD: Talk about your architecture out loud.

He mentions similar examples later on. I really like that! Definitely a technique I’m going to apply in the future.

  • Ideally, we want nothing but assignments in the constructors

Enough for today! DDD is a slow read but very interesting.


Updates Goals:

  • Get a bit more exposure to OOP and OOD
  • 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)
  • Watch one video per day on average

Progress status

In Progress

  • Read Domain-Driven Design [109 of 560 pages]
  • Watch one video per day on average [47 of 75]

Write a Comment

Comment