[LRUG] Objects that are neither classes nor records but something in between

[Mark Burns]

Hi Tim

I think you may have had your specific problem addressed. But the idea
of code and data sometimes aligning in this way to raise problems does
strike a chord with me.

Apologies that this is quite probably completely tangential to what you
are talking about. I just got the hint that you may be thinking of this
class of problems. (If this is what you mean, I also can't think of a
name for it)

I've worked on a project that could in simple terms be defined as a CMS
builder.
Not a CMS, but a layer above that.  A tool that can build branded CMS's.

The real eye opening moment for me was when the developer who had worked
on it for the longest and helped me set up my local environment. He had
finally helped get me through all the configuration and setup errors.

Then I hit a completely empty white screen. 

'And there you have it. Done.' he said. He was deadly serious, but I
definitely interpreted it as a deadpan joke.

It was completely set up and ready to go in his eyes.  Obvious to him,
was that I just needed all the right data in the database for it to look
anything like one of the production websites.
But that's "Just Data".

This disparity between production, development and test was all because
it's all "Just Data".
We managed to write a few scripts that would allow us to pull down
realistic sets of seed data, so we could at least test with a reasonable
amount of confidence, that certain key sets of "Just Data" could
reliably continue to work if any of the code changed.

These types of generic upon generic solutions can sometimes bite us in
terms of the trade off of flexibility and complexity. It is sometimes
mind-melting to work at extreme levels of generic abstractions. And
sometimes we, rightly so, crave something simpler and dare I say, more
hard-coded.
It doesn't mean there's no business in building CMS building websites
and API's. It's just it can be a lot of overhead if really you just want
a few specifically branded CMS's.

It can really be simpler to lock yourself into more specific non-generic
concepts. At least for the first few iterations. You lose the
flexibility of having users editing all your persisted domain specific
data in the UI. And you have an overhead of needing a code change in
order to perform any CRUD on one of these entities. But whilst you
crystallize requirements, this can be valuable. And the trade-off
becomes clear in terms of amount of time spent doing code change deploys
for something that could be made user-CRUD-able. 

And when I'm talking about not locking yourself into generic concepts
early on, I'm saying things like: "don't build user-configurable colour
schemes, layouts and themes into your user settings screen, when you
don't know if your users even use the settings screen". Rather than
"hardcode all your user email addresses". 

I think the only way to sensibly draw the line between these things is
in terms of deltas of change per unit of time. How many times per year
does/should this happen being a rough rule of thumb for knowing whether
or not you want to do a deploy of code vs want to maintain a UI or
similar to manage it.

Transactional things like users and their email addresses have a clear
place in the data zone.

Semi-transactional things like 'client website' may have some kind of
middle ground position. Yes you may need your site builder to work
generically for any client and not lock yourself into any specific
client. But you really also need your site to definitely work for your
only two clients that exist. Maybe sometimes it's worth hardcoding
things related to these records. Like writing code in tests around them.
 
Really abstract things _can_ be handled as data. But are sometimes best
kept as code. Like you probably shouldn't build a 'RequestsController'
that creates and shows 'Request' records and routes all the requests in
your application to data backed views that have data persisted to
represent all the routes in your application. Yes it's flexible. But
it's almost certainly not the thing you want to build.

But sometimes the hardcoding trade-off is worth it. Like "hardcode the
theme and layout". Start building your domain model using a "User" with
an "email" instead of an "AuthenticatableEntity" with an
"access_token_ownership_identifier_id" that joins to a table with a
single entry of "email". Or even set the price for the subscription we
sell in the code.

The more 'hardcoding' you do, the more you find that test setup is
simpler. It's cheaper in terms of test run-time. It is more realistic.
And you will be less likely to alter code that breaks one of these "Just
Data" setups. And because maybe that aspect of the data really doesn't
need to change more than once a year.

Sometimes the data is 'the name of the subscription'. And you have 3
subscriptions on Stripe, and it doesn't matter that you're displaying
one specific one of these a certain way and hardcoding it, because
you're almost never going to change the names. And it's not worth
building the CRUD UI that makes the stripe subscriptions configurable on
the website, because that's a bunch of data syncing and API integration
for something that you have no intention of changing very often.

I believe that a key component of a successful "Just Data" setup is
being able to get development and test environments rapidly in sync with
production in a way that will give you confidence that there's no data
and code interplay that could only happen in one of these "Just Data"
environments.
E.g. a rake task that will update some JSON fixtures, or update local
records in your db.

The worst case for the hardcoding approach is to regularly need
developer time and code deploys for trivial data changes.

The worst case for the generic approach is to have 'tenant/client
specific' setup that is difficult to easily replicate in tests and that
results in client sites breaking in production, and that turns out to
not even vary across clients. I.e. all the mental overhead of the
generic solutions where more concrete concepts could have been locked
down earlier and been easier to maintain from the beginning.

Everything we do is either data or code. But there are extremes at
either end we can spend more time on than we gain any benefit from.

Anyway, apologies that this doesn't really address your issue. I'd
imagine that there's some of the data model that you have there, that
may make sense to continue to hard code, and I think sometimes that's
fine. 

But obviously: It all depends.



On June 22, 2021, Andrew Donovan <andrew_donovan at hotmail.com> wrote:
> Hi Tim,
>
> Your db or permanent storage is your source of truth , if you’re using
> Rails then use all the facilities it offers such as ActiveRecord. If
> Product is somehow defining prices and other behaviour for your
> digital items then it needs to be modelled in the db. If you don’t
> have a db schema I’d draw out a simply entity relationship diagram
> which should help in identifying where things are missing or don’t tie
> up. From the gist of the details below it sounds like you have access
> to a database. I’d be wary of using code for defining product
> strategy, amongst other things how do you record product changes over
> time ?
>
> Regards
>
> Andrew
>
>  
>
>  
>
>  
>
> Regards
>
> Andrew
>
>  
>
> From: Chat <chat-bounces at lists.lrug.org> On Behalf Of Tim Cowlishaw
> Sent: 22 June 2021 15:43
> To: Ruby Group <chat at lists.lrug.org>
> Subject: [LRUG] Objects that are neither classes nor records b.ut
> something in between
>
>  
>
> Hi there folks! Hope you're all doing well.
>
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-
> lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20210622/7ff802e9/attachment.html>