The start of Day 20! I just published yesterday’s article and the two reviews. Today, I want to ‘finish’ my current project. And then start with Symfony2.

---

Ok, I pushed my repo to github: SimpleFeedback. I’m done for a while with it. The next step is going to work with Symfony2!

I’m starting to read Symfony The Book.

---

knpbundles.com is a repository for Symfony2 bundles!

Adding a new bundle:

php app/console generate:bundle --namespace=Vendor/FooBundle

---

Pretty cool, symfony supports flash messages. The ones you see only once after a request.

$this->get('session')->getFlashBag()->add('identifier', 'message');

---

Twig is really beautiful. I love it!

Interesting, you can include controllers into the templates. I wonder how good or bad of practice that is. Seems good from a code reuse standard but could be problematic from an organizational one. Hm.

That’s nifty! Asynchronous content with hinclude.js. You can define the default content and just use async loading with just one command. Neat!

It even supports ESI (for caching) natively, Jesus that’s great.

---

Not a lot of notes today which was expected. I spent most of the time writing code and trying stuff out and setting up my dev environment. The next days/weeks will probably be similar. However, I still have some articles in my backlog which I will publish.

---

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, caching, i18n)
• Watch one video per day on average

Progress status

Done

In Progress

• Read Symfony2 the Book [103 of 258 pages]
• Watch one video per day on average [52 of 75]

I’m currently on page 293. My goal is 50 pages which would mean that my goal is up to Chapter 14 (context map).

The last few days were pretty grindy and I try to finish the book as soon as possible. It would be perfect if I would finish today. But let’s see.

---

Refactoring

• Keep the model intact
• Keep the connection to the domain expert alive

---

Bounded context

Multiple models coexist on big projects, and this works fine in many cases. Different models apply in different contexts.

Explicitly:
* define the context within which a model applies
* set boundaries in terms of team organization
* Keep the model strictly consistent within these bounds

And use CI / Automated tests and build to keep the existing system working!

Context map

Code reuse between bounded contexts is a hazard to be avoided.

• Context map describes the point of contact between the models (language, sharing, etc.)

Furthermore, he presents several approaches to a common strategy. However, I found them so clear and obvious that I didn’t include them. The main idea is that either each domain is abstracted as much as possible, something in between or those two teams work together to create one common core.

---

The next chapter is about distillation which means reduce the models and making them simple to understand and more coherent.

Core Domain

• Important and central to the purpose of the system
• Most valuable
• Point of possible competitive advantage
• Small and of high quality

Techniques:

• Generic Subdomains Extract cohesive subdomains which are generic!
• Domain vision statement What is the core domain and how is it valuable?
• Highlighted Core Description of the core and interaction between primary core elements
• Cohesive Mechanisms Extract a cohesive mechanism into a separate framework (extract the what from the how)
• Segregated Core Strengthen the core by extracting supporting players and keep the core highly cohesive
• Abstract Core Abstract the core if it’s too complex and provide easier interfaces

---

The next two chapters are about Large-Scale Strategy which isn’t that relevant to me and my near future. Therefore I won’t go deeply into it but rather skim through it so that I know what possibilities there are.

---

Ok, done. I’ve just written a small review like every time. Great.

---

While reading DDD I had an idea of a DSL. However, I thought about it for a while and thought ‘Hey, this could be made easier by generating code’. All this led me to a topic I haven’t really learned about: XML.

Therefore, I decided to read a book on it, it’s called: XML: Visual QuickStart Guide by Kevin Howard Goldberg.

Interesting enough, one of the few books on XML which a good amount of positive reviews.

---

The layout of the book is awesome. On one side is the text and on the other the code the text is talking about. Absolutely great.

• XLS (eXtensible Stylesheet Language) made of
• XSLT for transformation
• XPath for identification
• XSL-FO for formatting
• DTD (Document Type Definition) defines structure
• XML Schema language also defines structure

---

A valid XML document consists of:

• a declaration
• a single root element
• child elements and attributes

Attributes should be used as meta data, i.e. data about the data!

You can use <!CDATA[ … ]]> to display elements as text.

---

Designing Beautiful Software

The craftsman is somebody who wants to build something that lasts.

That’s a good talk! Nothing new but a great summary of the most important best practices of OOP. That’s one of those talk which can serve as a starting point. Great for new developers!

---

Back to the book: XSLT. You start by entering a href to the xls file.

xml-stylesheet type="text/xsl" href="foo.xsl"?>

Those xls files contain templates (comparable to functions). The templates consists of

• a label which indicates where they apply
• the actual transformation

So, we declare a header again for the xslt file and inside it we can declare two things.

<xsl:template match="/">
    Some content we want to generate. And we can select
    attributes from our xml file:
    

Here the template matches the root.

XLS is basically a template language. There are other functions/tags like , or .

Interesting enough, there’s also the possibility of sorting the file:

<xsl:sort select="foo"
          order="descending"
          data-type="number" />

---

I won’t go into the detail of XSLT, etc. That’s something you can look up if needed. However, it’s interesting to learn about its ability.

---

DTDs aka. Document Type Definitions. It’s basically a schema of a xml file.

Here’s an example:

<!ELEMENT route (start, end, length, stop*)>

<!ELEMENT start (#PCDATA)>
<!ELEMENT end (#PCDATA)>
<!ELEMENT length (#PCDATA)>
<!ELEMENT stop (#PCDATA)>

PCDATA means parsed character data. In constrast to CDATA which means character data. You can also add qualifiers like * or ? or + to indicate how many of these elements should be included. You can do the same for attributes and declare choices.

---

There is also something called a XML Schema.

The same example like in DTD:

<element name="route">
    <complexType>
        <sequence>
            <element name="start" type="string"/>
            <element name="end" type="string"/>
            <element name="length" type="decimal"/>
            <element name="stop" type="" minOccurs="0" />
        </sequence>
    </complexType>
</element>

I think more readable and clearer in intent.

There are also namespaces which work like namespaces in other languages.

---

I just wanted an overview over the whole topic and I got it. It’s an interesting topic and I’m quite surprised how sophisticated the tools are. On the other side it feels bloated with several standards basically doing the same thing. It feels like it is designed by committee.

---

Software Architecture vs Code

There’s a discrepancy between architecture and code. Most architecture is layered architecture. The code however does normally look different.

An approach is architecturally-evident coding style, i.e. naming conventions, packing structure, etc. depended/similar to on the architectural model.

The C4 Model

• System context
• Containers (applications, etc.)
• Components (Services, modules, …)
• Classes (optionally)

Interesting, he suggests to move from a layers into a component. I personally did something similar in my most recent project. It’s nicer to understand. However, the testing becomes trickier.

Interesting talk. It was mainly about thinking for yourself especially towards some dogmas in the software industry.

---

So Long, and Thanks for All the Tests

Kent Beck:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence.

Interesting that a lot of talks are about questioning dogmas. I like that. But I also think that anti-dogmas as dogmas are equally as bad.

What I never understood why some people focus solely on unit tests. They are good for some things but I want to see if my DB connection actually works or if I can upload something. Therefore, I write integration tests. If I find a bug I write a regression test, etc.

I have the feeling that either I don’t get something or I just use my common sense instead of swallowing some dogma.

---

My Take on PHP by Fabien Potencier

Interesting take. Especially the idea of PHP lacks as a language but shines as a platform. I agree with him that PHP got and gets better.

What I found interesting is the background of a lot of speakers in the PHP community. Most of them seem to come from a pragmatic background aka. I needed something to fix and did it. The atmosphere is very different to other languages. In my opinion, more down to earth and less arrogant as some other communities.

---

Another Zed Shaw talk titled The Imaginative Programmer

Good talk.

---

So, enough for today. I think I’m going to edit my project so far that I can publish it to github and then I’m going to test it in production. I don’t really need it anymore which is a bit dumb.

Nonetheless, I’m going to roll it out and implement an interface to test it live. When I’m done with that (which can take longer than just tomorrow) I want to start with symfony. I’m a complete noob in it and I want to build up my knowledge.

---

Updates Goals:

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

Progress status

Done

• Read Domain-Driven Design [done]
• Get a bit more exposure to OOP and OOD
• Read XML: Visual QuickStart Guide [done]

In Progress

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

Today, I will continue with DDD. My goal is 50 pages which is around the start of Chapter 7.

---

Modules (Packages)

Like everything else in a DDD, modules are a communication mechanism.

The same idea still prevails. Try to design to the domain. Modules should flow naturally.

Also keep modules and organization simple. A domain model should be represented as a domain model not a technical one.

---

Aggregates

A cluster of associated objects that we treat as a unit for the purpose of data change.

Consists of:

• Root a Specific entity, only object which can be referenced from the outside
• Boundary defines the content of the aggregate

Factories

Requirements:

1. Each creation method is atomic and enforces all invariants
2. Parameters of factory method should use the abstract type

Invariant checking makes the most sense in the case of value objects because they are immutable. In the case of entities the factory should use the entity’s methods to check invariants.

Repositories

A repository takes care of all queries and summary information about a collection. It’s like a SQL/DB layer however the technology behind it doesn’t matter.

if you find you need to search the database for a preexisting value object, it is worth considering the possibility that you’ve really got an entity whose identity you haven’t recognized.

---

Some terminology:

• Anti-Corruption Layer: \Translation layer between domain model and outside API
• Enterprise Segment: A way to break data down (time, attributes, etc.)

---

Listen to the language the domain experts use. Are there terms that succinctly state something
complicated? Are they correcting your word choice (perhaps diplomatically)? Do the puzzled looks
on their faces go away when you use a particular phrase? These are hints of a concept that might
benefit the model.

And read a book about the domain! It often contains explanations and models.

---

Specification

• states a constraint onto an other object; can test if object fulfils specifications

Purposes:

1. Validate object
2. Select object
3. Constrain creation

---

Supple design

How to strive balance between change and the domain mode

Intention-Revealing Interfaces

But if the interface doesn’t tell the client developer what he needs to know in order to use the object effectively, he will have to dig into the internals to understand the details anyway

Describe what classes and operations do, not how.

Side-Effect-Free Functions

An operation that mixes logic or calculations with state change should be refactored into two separate operations

Standalone Classes

Low coupling is fundamental to object design. When you can, go all the way. Eliminate  all other concepts from the picture. Then the class will be completely self-contained and can be studied and understood alone. Every such self-contained class significantly eases the burden of understanding a module.

Closure of Operations

Where it fits, define an operation whose return type is the same as the type of its argument(s).

---

I quite like his ideas about declarative specifications. The idea is that besides checking specifications you also include boolean operators. So you can write something like:

A.and(B) which returns a new specification which checks for A and B.

---

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 [293 of 560 pages]
• Watch one video per day on average [47 of 75]