{"action":"created","issue":{"url":"https://api.github.com/repos/jdickey/new_poc/issues/252","labels_url":"https://api.github.com/repos/jdickey/new_poc/issues/252/labels{/name}","comments_url":"https://api.github.com/repos/jdickey/new_poc/issues/252/comments","events_url":"https://api.github.com/repos/jdickey/new_poc/issues/252/events","html_url":"https://github.com/jdickey/new_poc/pull/252","id":63426672,"number":252,"title":"Clawing back Post entities.","user":{"login":"jdickey","id":157938,"avatar_url":"https://avatars.githubusercontent.com/u/157938?v=3","gravatar_id":"","url":"https://api.github.com/users/jdickey","html_url":"https://github.com/jdickey","followers_url":"https://api.github.com/users/jdickey/followers","following_url":"https://api.github.com/users/jdickey/following{/other_user}","gists_url":"https://api.github.com/users/jdickey/gists{/gist_id}","starred_url":"https://api.github.com/users/jdickey/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jdickey/subscriptions","organizations_url":"https://api.github.com/users/jdickey/orgs","repos_url":"https://api.github.com/users/jdickey/repos","events_url":"https://api.github.com/users/jdickey/events{/privacy}","received_events_url":"https://api.github.com/users/jdickey/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/jdickey/new_poc/labels/in%20progress","name":"in progress","color":"ededed"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2015-03-21T16:56:55Z","updated_at":"2015-03-26T10:11:52Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/jdickey/new_poc/pulls/252","html_url":"https://github.com/jdickey/new_poc/pull/252","diff_url":"https://github.com/jdickey/new_poc/pull/252.diff","patch_url":"https://github.com/jdickey/new_poc/pull/252.patch"},"body":"Per Issues #54 and #240. Not as \"unbuilt Rails dependencies\", but the door is very much open for Gemification later should the need/desire arise."},"comment":{"url":"https://api.github.com/repos/jdickey/new_poc/issues/comments/86435309","html_url":"https://github.com/jdickey/new_poc/pull/252#issuecomment-86435309","issue_url":"https://api.github.com/repos/jdickey/new_poc/issues/252","id":86435309,"user":{"login":"jdickey","id":157938,"avatar_url":"https://avatars.githubusercontent.com/u/157938?v=3","gravatar_id":"","url":"https://api.github.com/users/jdickey","html_url":"https://github.com/jdickey","followers_url":"https://api.github.com/users/jdickey/followers","following_url":"https://api.github.com/users/jdickey/following{/other_user}","gists_url":"https://api.github.com/users/jdickey/gists{/gist_id}","starred_url":"https://api.github.com/users/jdickey/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jdickey/subscriptions","organizations_url":"https://api.github.com/users/jdickey/orgs","repos_url":"https://api.github.com/users/jdickey/repos","events_url":"https://api.github.com/users/jdickey/events{/privacy}","received_events_url":"https://api.github.com/users/jdickey/received_events","type":"User","site_admin":false},"created_at":"2015-03-26T10:11:52Z","updated_at":"2015-03-26T10:11:52Z","body":"Right; so what have the last ~5 commits accomplished?\r\n\r\n1. We've broken out the most obviously explicitly presentation-related methods, including a pseudo-attribute (`#post_status`) of the `Post` entity into a module that *is not* mixed in by default. In a live app, it would be mixed in only as part of generating views;\r\n1. We've made relationships within that module's supporting code, that is used *only* by the methods in that module, blindingly explicit.\r\n\r\nCompare this with the approach used for modularising the `User` entity earlier; even though that class now has conceptually clean implementation that should be easy for new developers to pick up and work on, all modules are loaded as part of the \"meta-entity\" `Entity::User`.\r\n\r\nHere, by contrast, `Extensions::Presentation` is not part of the \"main\" `Entity:::Post` class, and must be loaded separately (through a Demeter-compliant method on the `Post` instance being extended).\r\n\r\n#### Continuing On\r\n\r\nWhat other extensions will/might we want to extract here?\r\n\r\n1. Validation, with at least the current methods `#valid?`, `#body_or_image_post?`, `#registered_author?`, `#valid_author_name?`, and `#valid_title?`. One rationale would be that, in addition to any SOLID-based principled argument, that the rules for validation might well change in different contexts, and extracting such a module would be the least painful way to facilitate that;\r\n1. Persistence, with `#slug`, `#created_at`, `#updated_at`, and `#persisted`. The justification here would be analogous to that for validation (above). Again, from the perspective of a value object such as an Entity, any knowledge of the persistence state of an individual entity is almost certainly presentation-related (which would tend to piggyback it onto the just-completed `Presentation` extension).\r\n\r\n#### Ponderables\r\n\r\n1. Even though entity *code* has been separated from depending on an ORM (such as ActiveRecord), the *specs* currently load the entirety of Rails and RSpec for *each  and every example* individually. This slows unit-test execution by at least one order of magnitude, as pointed out by numerous writers;\r\n1. We've invested man-months in building out \"clean(er) architecture in Rails 4\", along the way developing a nearly [Greenspun](http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule)-compliant implementation of DCI, which is one of the two in-production approaches to mitigating Rails and avoiding being [Slashdotted](https://en.wikipedia.org/wiki/Slashdot_effect). The other approach is demonstrated in [this talk](https://youtu.be/naTRzjHaIhE) by [Akira Matsuda](https://github.com/amatsuda), which can basically be summarised as \"iteratively identify the bottlenecks in the Rails Way stack; sic your team on developing patches or replacement tools that ease your pain; iterate, iterate, iterate\". Which is fine if you've a couple of hundred developers and an existing app with *thousands* of models; you've painted yourself into a very small corner that I'd really rather not join you in. Alternatives exist; we should have some intelligent rationale for evaluating them to avoid being sucked into the fad-of-the-week.\r\n\r\nReferences:\r\n\r\n1. [*Skinny Models — the DAO pattern for Ruby persistence](https://jdanger.com/skinny-models-the-dao-pattern-for-ruby-persistence.html), a blog post by Jack Danger Canty dated 20 July 2013;\r\n1. *Trailblazer: A new architecture for Rails*, by Nick Sutterer. [Early-access book website](https://leanpub.com/trailblazer), [Github repo](https://github.com/apotonick/trailblazer).\r\n1. *Fast Rails Tests* by Corey Haines. [Presentation slides](https://vimeo.com/30893836), [Golden Gate Ruby Conference 2011 presentation](https://youtu.be/bNn6M2vqxHE), [original blog post](http://articles.coreyhaines.com/posts/active-record-spec-helper/).\r\n1. [Lotus](https://github.com/lotus/lotus) — another promising future tool for Rails Web development."}}