peclink

The most interesting concept is "Build & Deploy" and it's a pity that it isn't described even on conceptual level.

I think the "Build & Deploy" for configuration management is the right thing, but it looks like Ansible is not very good tool to implement it (and honestly, I don't know any mainstream tool that is really good at it).

I was trying to implement it as follows:

- part of a role is executed locally, building all the configuration files from templates (build); - configuration built locally is rsynced into dedicated directory on target server, deleting unnecessary files etc (sync); - part of a role is executed remotely, setting up symlinks from real configuration paths into synced dir and running all necessary actions (restarting services etc).

Yes, it's possible to write Ansible playbooks and roles that way, but in practice you are permanently struggling with the default Ansible playbooks and roles organizational structure.

I believe the only devops tool that really supports this style of things now is Nix and all the infrastructure around (and conceptually it's perfect, but in practice it has it's drawbacks).

Do not use wkhtmltopdf for this, use weasyprint instead.

Markdown → Pandoc → HTML → weasyprint → PDF works great, paged media support in weasyprint is good enough and much, much better than in wkhhtmltopdf.

What a great idea, thanks for sharing!

BTW, why using shell scripts to write migrations is so unpopular? We have lots of language/framework specific solutions or some «language agnostic» tools using plain SQL, both ways are rather limiting.

There is Bullet http://bulletphp.com, that inspired us, but it is too simple and lacks some important (for us) features, e.g. recursion.

There are nested routes in Express and some Golang libraries (see gongular near on HN), but they are not resource oriented. And yes, there are resources in Rails, but it's sooo complex and heavy.

> But quite frequently I want to answer this question with just the source code.

Exactly. And that is also a benefit if routes are fetched dynamically from database, e.g. for content application, so your database is really content repository without too many levels of abstraction.

As for source code, it's kinda silly to split your app to fixed «controllers» and «models», you should split it functionally for simple reuse. Most modern PHP frameworks are so unflexible that way (laravel is just terrible IMO).

All these routing libraries are just wrong level of abstraction. In HTTP you have resources, and resources are not flat, they are hierarchical.

And hierarchy of resources defines some connection between then, and some common properties (data, access level etc). So any resource can respond to some HTTP method or can delegate to another, nested resource (if any) for any method.

So (in PHP, from our still proprietary framework):

    // Index resource, just routing, no HTTP method handling.
    class IndexResource extends Resource {
      public function __construct(Application $app) {
        // ...
      }
      // Route nested resources for any request
      public function any(Request $request) {
        // Static path:
        $this->path(
           CollectionResource::Path, new CollectionResource($this)
        );
      }
    }

    class CollectionResource extends Resource {

        const Path = 'items';

        // Parent resource type constraint, you can access
        // parent data using IndexResource API:
        public function __construct(IndexResource $parent) {
          //...
        }

        // Route nested resources for any HTTP method:
        public function any(Request $request) {
           // Regexp pattern for URI segment:
           $this->match(ItemResource::Pattern, new ItemResource($this));
        }

        // Or handle GET
        public function GET(Request $request) {
          // ...
        }
        // Or POST maybe
        public function POST(Request $request) {
          // ...
        } 
    }

    class ItemResource extends Resource {
       const Pattern = '(\d+)';

       public function __construct(CollectionResource $parent) {
          // ...
       }
       public function any(Request $request, $prefix, $id) {
          $this->item = Item::find($id);
       }

       public function GET(Request $request) {
          return JSON::string($this->item);
       }
    }

It's not about routers + controllers etc, it's just resources + delegation to nested resources:

- recursive routes are trivial, so no problems with CMS-like applications; - looks good with type systems; - no long routing tables (in fact, no routing tables at all), so true modular apps; - you can use anything (e.g. database) for resources lookup, good for CMSes again; - it's absolutely RESTful.

Yes, automatic URI building is not so easy, but it's kinda possible, in some semi-automatic way.

I wonder why frameworks built this way are so uncommon (ours were inspired by Bullet BTW).