solarized-light-markdown.diff

Add to this the Sublime Markdown Preview plugin and you have my current favorite markdown editing setup.

update: Complete files with my modifs for Solarized Light and Solarized Dark can be found here: https://gist.github.com/1904917

But the real (sarcasm) php dev will create an acl from scratch at every job he have. he will create countless media manager, db layer, session manager, etc. Don’t get me wrong, I think you can’t be a good php developer if you haven’t gone through this stage, but please, for the sake of your coworker sanity, keep you’re “learning process” outside of the workplace and don’t forget that you should stick to “learn-and-throw-away”.

Some bad reason to reinvent the wheel that I hear all the time:

Existing solution does not apply to us

Yeah right, you feel better when you think you are unique, good for you, but unfortunately it’s probably not true. I agree on one thing though, you’re different, everybody is different, that’s why the solution will need to be adapted, but surely not written from scratch.

It’s gonna be faster to create our own solution rather than adapting or learning something else

Yeah right, it’s gonna be faster for the guy doing it this time, but for everybody else trying to use/modify/understand it in the future it’s gonna be a pain in the ass because your solution will be half documented (probably not documented at all) and with no community support. By the time somebody needs help from the original developer, he will probably be working somewhere else, reinventing the wheel again…

There is nothing in the whole universe that remotely resemble what we’re trying to do

Yeah right, again, the “I’m unique” power trip. There’s billion of people on the planet, that have met and fixed billions and billions of problems, a lot of them have written about their solution in books, blogs, code, tweet….

Even if not doing Domain Driven Development, the design patterns usually used by the DDD people are something that can benefit a lot of project. To start learning more about design pattern, “Patterns of Enterprise Application Architecture” by Martin Fowler ¹ is a must read. If you can’t afford the book, then go steal some money (just kidding) or start by reading the free short summary of each patterns available on the author’s website ².

Domain Models are a representation of the data, they represent nouns in you domain, such as User or Invoice. As the domain model contain the business logic, it should be the most important part of the code, thus it need to be easy to understand, easy to modify and easy to test. That’s why they should have no external requirement, no knowledge of the external world, avoid tight coupling at all cost.

Domain models contains the business logic (verbs), mainly in the Entity and Repository, and some in the service layer (if, and only if the functionality does not apply to an entity in particular, reference others object of the system, and is stateless. (ex1: $shippingService->calculateShippingCost($zipcode). this does not belong in the Cart Entity because of the dependency on external object such as shipping company API).

Entities should be totally standalone, they should not be aware of repository or anything else.

Entities and Repositories does not write directly to a database or web service, a database layer is usually used such as ActiveRecord or DataMapper. But, writing an activeRecord of dataMapper layer is a long and difficult job, and it’s generally a better choice to use an existing one, especially because of the fact that this layer contain no business logic, there is not a big Return On Investment on building our own.

Some part of the application might seems like Entity but are in fact Aggregate. Some object can’t exist by themselves, such as OrderDetails, they are Aggregate that are connected to an Aggregate Root Order. This mean that the Aggregate don’t have a repository and if you want to add a row to an order you need to go thru the Order Entity. ex: $order->addDetail(…)

Domain Driven Design (DDD) being a complete development methodology, that means that you can’t learn DDD simply by reading code sample, and a few things are necessary for his success, such as:

• Developers who understand design patterns
• Access to a Domain Expert and close relationship with the client

The domain expert requirement is a big one, you actually need someone from the domain, ie: if you are in the banking industry, you need a banker to have this role, not a developer or an architect who is a self proclaimed domain expert. DDD involve a lot of communication with the domain expert to define the ubiquitous language ² and integrate them in the domain models. To keep using our banking example, a developer who knows absolutely nothing about banking should learn an awful lot about the domain (banking) just by looking at the code for the domain model.

A DDD team will probably be using a bunch of design pattern such as:

• Domain Model
• Service Layer
• ActiveRecord or DataMapper
• LazyLoad
• Repository & Query Object

But the sole fact of using these patterns does not mean you have a DDD team. I can’t find the orignal source, but apparently ³ Eric Evans almost regrets having mentioned these design pattern in the book because they can lead to that false conclusion that DDD is just ‘using some specific design pattern’ when if fact it is so much more and involve discussion and collaboration with clients and domain experts. We can see the same feeling about design patterns and lack of domain expert expressed in the excellent video “7 Reasons Why DDD projects #FAIL” ⁴ by Greg Young.

DDD is not for everybody, if your app is mainly retrieving data from the database to display with some fancy design, DDD would just be adding a layer of complexity on something really simple, ActiveRecord or DataMapper is probably a better solution for your need. Such an example where DDD is overkill, and e-commerce website for Mom & Pop’s shop, as there is little logic, lots or database reading and some cool graphics… But complex subscription plan and pricing and discount model is a good candidate for DDD.

I won’t go deeper into the world of DDD as I have no experience with it and I’m not currently working on any team that can switch to this methodology easily.

I’ll close this part with a great quote from “DDD Step By Step” ⁵

[...] I view Domain Driven Design firstly as a design methodology, secondly as an architectural style, and lastly as some great software patterns.

More Reading

Stack Overflow have some good links to get you started with DDD

http://stackoverflow.com/questions/493068/best-resources-on-the-web-for-learning-domain-driven-design-ddd-in-depth

(my favorite being the InfoQ miniBook, a quick read that give just enough information to get you interested)

change job

If you have only worked for one company, using only one style of coding and project management, and have seen only your code / your friends code, then do everybody a favor (including you) and get out of there, go see how things happens “in the wild”.

share

Write, mentor someone, or contribute to an opensource project, you need to learn to explain clearly and and easily your ideas and what your code is doing. If you can’t you either:

• don’t really understand what you’re doing
• have sucky communication skills

Both issues are worth working on, as they will improve your life and those of people surrounding you.

read

Read lots of books, blogs, essay on programming, etc that expose different concept and point of view.

code

aka don’t read too much

You should code at least as much as you read, or you risk becoming somebody living in Utopia city, the type of guys who abuse design patterns for hypothetical reasons. Once again, to achieve this you can work on a pet project, contribute to an opensource project (better), or turn to code kata, code dojo or somethings like the EdgeCase Ruby Koans that have been ported for many programming language.

plagiate

and throw away (very important)

Yes, it’s still writing code, but writing code is a really important thing to do while learning. Re-implement existing things as a learning exercise. It’s easy to do because you don’t have to spec the project, you already know the desired outcome and you don’t need to find a killer idea (waiting for inspiration is a good way to kill a learning session). But be careful, do this as a learning exercice only, everybody hates a coworker who constantly reinvent the wheel. You need to throw away this code once it’s done. Learning to let go your code is as important as learning to code, a good developer will delete a lot code in his career…

note:

If you really want to read more than you code, you risk becoming one of these pattern abusers I’ve just mentioned. Please, go read this old blog post right now: Head First Design Patterns

update: both projects killed due to total lack of interest and/or php developers in Ottawa

Take a look at the proposal PSR-0 and try the autoloader on your new project. The more people using it, the easier our life will be as a PHP developer.

Note: if you want to give feedback to the group about the proposed standard, you’d better do it on twitter or on your blog, because there seem to be some not so clearly defined rules to be able to join the group… update 2009-11-11: thanks to Nate Abel there is now a public Project Acceptance Guidelines posted so this comment doesn’t hold true anymore. Thanks Nate.

Note 2:: if you’re wondering how nice your code could look by using namespaces in php, check out the lithium framework (#li3) for a good example.