Matthias NobackLean publishing "Principles of Package Design" (26.1.2015, 07:53 UTC)

During the great PHP Benelux Conference 2015 edition I published the final version of Principles of Package Design. Let me tell you a little bit about its history and some of the things I had to deal with.

A bit of history

My first book, A Year With Symfony, was released on September 4th, 2013. Just 6 days later, I started working on Principles of PHP Package Design. As it turned out, it was quite hard to keep the process going. There were several months in which I wrote nothing at all. Sometimes I picked up the work, but then I had completely lost my track and tried to get back on it by revising existing chapters over and over again. Meanwhile all kinds of other projects begged for attention as well, including the release of the backend project of the new website, the preparations for the Hexagonal architecture training and the birth of our daughter Julia ;)

Finally, I took a couple of weeks to focus completely on the book, and as it turned out, there wasn't really much work left. The final sprint consisted mainly of preparing the book interior for print, designing the cover, and thinking of a good way to release it. The PHP Benelux conference seemed like a good place and time to do this. I felt comfortable enough to do it there, given I am familiar with many of the attendees.

Lean/live publishing

Still, I was quite nervous to actually do this. Even though I did it before, to publish a Leanpub book in real-time is always a bit scary. But I pushed the "Publish" button nonetheless, and everything turned out well. While Leanpub was generating fresh PDF, MOBI and EPUB files, I talked a bit about lean publishing and its up- and downsides.

Lean publishing "Principles of Package Design" from matthiasnoback

The main take-aways from this are:

It's great to be able to publish early, and let readers give you feedback. But make some kind of a commitment to finish the book as well. Imagine the early adopters standing in front of you, asking you when you'll finish it and give an honest answer:

Early adopters demanding a finished book, source:

Proof reading

Also, make sure to ask people to read the book before you publish it, and provide you with some feedback. Any feedback is helpful, and also any type of reader: an experienced or an inexperienced programmer, a native English speaker, or a non-native one, etc.

One example of highly useful feedback I got from Peter Bowyer (rephrased):

It seems like you're trying to put two books into one. In the first place there's lots of information about practical PHP package development, working with Git, GitHub, Composer, Packagist, etc. Then there's also lots of information about software design and design principles, which is more theoretical of nature.

This particular comment struck me like lightening and helped me decide to leave out all the PHP-specific things and turn this into a general programming book. I'm really curious how this works out. So far it turns out that people really get a lot of practical advice from it, as well as many things to think about, while they're doing their job.

<script async="" src="//" charset="utf-8"/>

Also, because it took me about one and a half years to finish this book, its style was not really consistent at first. While re-reading the older parts it turned out that I took certain things for granted, sometimes underestimated, sometimes overestimated the audience, sometimes let myself get away with shortcuts, or

Truncated by Planet PHP, read more at the original (another 2813 bytes)

Piotr PasichIt’s Monday, you could use some motivation (26.1.2015, 07:18 UTC)
grannyThree days ago I decided to give you some motivation to start doing a code kata (see the Friday Dopamine Dump). Well, if you forgotten, haven’t got any time, had to do something more important and didn’t even try to try, then stop. No excuses! If you really want to do this – just start. […]
Nomad PHPDefensive Programming (24.1.2015, 17:32 UTC)

Presented by Christopher Pitt @assertchris Defensive programming may sound like something your granddad did after the war, but it’s key to reducing the number of bugs and increasing maintainability. We’re going to look at what defensive programming is and some steps to doing it in PHP.

The post Defensive Programming appeared first on Nomad PHP.

Nomad PHPDatabase Schema Migrations with Doctrine (24.1.2015, 17:28 UTC)

Presented by Diego Sapriza @AV4TAr How do you manage database schema changes in your applications? Do you ever wonder how to push your code AND database changes all at the same time? If you feel you are doing it wrong, I will explain you a way to manage incremental, reversible changes to relational database schemas …

The post Database Schema Migrations with Doctrine appeared first on Nomad PHP.

SitePoint PHPHow to Build an OctoberCMS Widget Plugin (23.1.2015, 17:00 UTC)

In a previous article we talked about the basics of creating an OctoberCMS plugin. In this one, we’re going to go deeper, and we’ll explore how we can extend the OctoberCMS backend using widgets.


What We Are Going To Build

I will assume that many of you have used Wordpress. On the dashboard, we have a quick draft widget. In this article, we’re going to see how we can build a similar one for OctoberCMS.

Quick Notes Widget
Quick Note Widget Listing

Plugin Registration

To start building our plugin, we’ll use a command utility for scaffolding.

php artisan create:plugin RAFIE.quicknote

The command will create a Plugin.php file and an updates folder containing the version.yaml file.

public function pluginDetails(){
   return [
       'name'        => 'Quick Note Widget',
       'description' => 'Add and manage some drafts when you\'re in a hurry.',
       'author'      => 'RAFIE Younes',
       'icon'        => 'icon-pencil'

After registering our plugin we need to update our version.yaml file.

// uploads/version.yaml
1.0.1: First version of quicknote
  - Created Notes Table
  - create_notes_table.php

Continue reading %How to Build an OctoberCMS Widget Plugin%

Stefan KoopmanschapComing Out Of The Box (23.1.2015, 11:30 UTC)

Asking for help. Once you start thinking about it, it is really hard to do. It doesn’t really matter what you need help with, it is hard once you start wondering whether you should ask.

In The Art of Asking Amanda Palmer writes about Anthony. Anthony is a professional therapist who helps people in hard times. Anthony is also Palmer’s best friend. He helps her a lot, either by listening, by asking questions or by giving advice. But once Anthony himself is in a dire predicament, all of a sudden, it was hard for him. She writes about this:

He likes being in control, he loves having answers, he loves fixing and helping people. But he has a really hard time letting people help him. Sometimes, when he gets depressed, he shuts down and doesn’t like to talk. When that happens, I figure it’s time for me to step up, ask him questions, help him through, talk about the problems. Be he clams up and doesn’t like talking to anyone about his own problems. He calls it Going Into The Box.

Triggered by both this book and events in my own life, I’ve been thinking a lot about “asking”, and have been thinking about how I handle asking, and I’ve come to an interesting conclusion. Asking is easy if you just do it. Once you start thinking about it, it becomes hard.

I really recognize myself in Amanda Palmer’s description of Anthony. I, too, have (had?) a tendency to completely turn inward once I have a hard time. The trigger can be anything from worries over something to stress, but not even my wife will be able to get through to me in such a situation. Why? Because I don’t want to ask for help. I don’t want to be a nuisance to other people, don’t want to bother them with my own problems. Recently though, I’ve started talking about it to my wife, asked her for help coping with something, and it turns out that once I do that, the problem gets much easier to handle. I can cope.

On the other hand, when you don’t really think about it, asking is easy. In the preparations of WeCamp, we were so excited about our concept and the way things were shaping up that without much hesitation I sent some people an e-mail asking them to be a coach at the event. Being a coach would basically mean “being on an island working for a week, and not getting paid for it”. But I didn’t think before asking, I just did it. And the response was excellent. Not everyone I approached could to it, for a variety of reasons, but I did not have a hard time asking. Why? Because I did not think about it before asking. I just sent out the e-mails and did it. Because I was really excited about what we were trying to do.

I’m trying to train myself to ask more. Sometimes, this may be annoying but I’ve found asking works. If people do not have the time to help or even answer your question, they’ll just let you know. Most people actually love to help once they’re asked. I know I do, which makes it even stranger that I didn’t understand that asking would probably result in the same help I give when someone asks me.

Try to be like Anthony when it comes to helping. Try to avoid being like Anthony when it comes to asking help. Come out of that box.

Piotr PasichFriday Dopamine Dump (23.1.2015, 06:00 UTC)
4509165024_a41e37c1bd_bWhen we were in Madrid last year, a book was accompanied me – the new edition of Clean Code authored by Uncle Bob. He describes how the professional programmer acts, works, talks and develops himself. Robert C. Martin claims an example from his own life – a quick, 15 minutes, code kata done twice a […]
Nomad PHPApril 2015 – US (23.1.2015, 00:01 UTC)

Symfony2 - The Basics

Presented By
Margaret Staples
April 23, 2015 20:00 CDT

The post April 2015 – US appeared first on Nomad PHP.

Nomad PHPApril 2015 – EU (23.1.2015, 00:01 UTC)

Hack — Why Should I Care?

Presented By
Joel Clermont
April 23, 2015 20:00 CEST

The post April 2015 – EU appeared first on Nomad PHP.

labs @ Qandidate.comProjecting your event stream (22.1.2015, 16:00 UTC)

When you are using a CQRS and Event Sourcing architecture you are separating your writes from your reads. You can fire commands that change state but return nothing and you have queries that return a result but don't change state.

So when you need to query some data, you can replay your eventstream and listen to specific events you are interested in. Although this can work for quite a lot of cases, most of the time this is not very efficient and it doesn't scale very well.

One solution to solve that, is to use projections to create a view that you can query against. Those projections are created with a projector. A projector listens to events and creates a read model from it. With this method it is really easy to create multiple read models at the same time. Because of the nature of your event stream, collecting facts that happened in the past, you can also easily create new read models for events that happened a long time ago.

∞ labs @ Permalink

LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP