[Grok-dev] megrok.rdb

Fri Mar 10 08:10:13 CET 2017

>From what you say, your take away from Grok was "Too often,
Grok/Zope2/Plone feels like you're fighting against it or bending it to fit
your needs".  I find that very descriptive, and to some probably lesser
extent I have experienced the same thing.

For simple folks like me though, having no desire to actually rewrite
frameworks to bend them to our will, we are what folks like you end up
complaining about having a lack of.  *Users*.

It sounds to me as if Cromplech is a remarkable technical achievement
capable of running large sites.  However, as a *User*, when evaluating
potential frameworks to use, I would start by looking at the following
needs:

   - Is it supported?  How long does it take for bugs to be fixed?  This
   impacts development time.
   - Does it have adequate documentation or Internet resources that can
   guide me as to how to solve problems?
   - Is it in widespread use by others?  This helps in risk assessment.
   - Is the API in flux? or has it matured and settled to a constant.  This
   impacts my risk and technical debt.
   - How easy is it to maintain code that uses the framework?  This impacts
   my costs and ROI.
   - How does the framework help me solve real world problems?
      - Interfacing with data sources
      - Session Management
      - Access control, Authentication methods etc
      - Scalability - factors like efficiency, threading, deployment across
      servers and so forth
      - Extensiblity - ability to add features without breaking existing
      code
   - How affordable and available are development resources?

You see, *Users* like me are what make those technical masterpieces
valuable.  Without people to actually USE the code you write, the code
itself is, by definition,  useless.  Unless your framework can provide the
things *Users* like me are looking for in a framework, you will continue to
have a shortage of *Users*.

I am more than willing as a *User* to contribute my bit to the pot.  I
don't expect everything to be freely given to me.  In case in point, I have
written an extensive users guide to using Grok <http://gfn.aptrackers.com>,
and made it available on the Internet together with the code.

However, as a *User*, the one thing that will drive me away to join the
throngs supporting *AngularJS *and other such perversions, are statements
like: *"zope.publisher.   Just massive and hugely confused.*" or
"*Historically,
the starting point was to remove zope.publisher. It's so entangled in the
rest that we ended up stripping down everything, piece by piece*".  And,
horror of horrors: "*...I would love to rip it out and throw it out*".

As a developer and software architect, I understand the burning desire to
simplify.  However, surely you realise that *zope.publisher* is core to the
whole idea behind Zope, and that you cannot fundamentally change the core
of something without changing the very nature of what lies behind it?

Next I hear "*...without having to rely on a ton of adapters, events and
subscriptions*", which speaks to the heart of what gives the ZTK its value
in the first place;  the fact that it is entirely component based and
everything is part of a pluggable coherent architecture.  Sure, Zope
certainly did not get everything right, and it's not perfect.  I understand
that.  But dismantling "*piece by piece*" the bits upon which the house of
cards rests can only result in the whole thing coming crashing down around
your ears.

You cannot erode the foundation of a house without compromising the entire
structure.

Indeed, in your case you ended up with something a lot less magical.  In
your own words "*It's just a little more DIY, because i've always wanted
less magic.*"

Sorry, Souheil,  but speaking as a User, we LIKE magic.  The more magic the
better!

We also like *stability*- not stagnation, stability.  We like to believe
that if we write code today, that code will still operate and have value
tomorrow.  The bug report that started off this whole thread is a clear
example of some person who decided that a method called "*on_link*" was not
following some or other naming convention (quite probably that abortion
called PEP8) and renamed it to just "*link*" possibly to get rid of some of
the warnings cluttering up his IDE, and ridiculously far reaching impacts
such utterly stupid and unsubstantiated changes can have to dependent
projects.

Regards

On Thu, Mar 9, 2017 at 8:08 PM, Souheil CHELFOUH <trollfot at gmail.com> wrote:

> All the packages have READMEs and tests.
> But yes... Most of the work was done by myself and given the amount of
> work needed in the code, the documentation always came last sadly.
> Given the lack of interest initially for the project in the community, It
> failed to gain more attention from people
>
> Cromlech uses some ZTK packages, if they are detached enough from the
> whole stack. The idea is to have something you build from bricks, one at a
> time, not to start with more code than you can understand.
> Having a complete understanding from the request creation to the final
> response was key to produce quick and quality code, for problematics I
> could never resolve with Grok itself.
> Having less overhead and more direct compatibility with generic python
> packages (base WSGI ones especially) is very appreciable.
> It's incredibly satisfying to be able to intervene at the right level in
> the stack, when you need it, without having to rely on a ton of adapters,
> events and subscriptions.
>
> Historically, the starting point was to remove zope.publisher. It's so
> entangled in the rest that we ended up stripping down everything, piece by
> piece.
> Martijn and myself coded "dawnlight", that is the base publisher here and
> Crom/Grokker to use Venusian and more a flexible registration system for
> components.
> These ideas were at the base of Morepath, I took a more grokkish approach
> with Cromlech.
>
> Finally, a lot of effort was put into making the "framework" agnostic,
> regarding the DB and the request/response objects.
> The security system is very light and flexible, allowing a very simple
> security or a very complex one.
>
> In term of productivity, it's very hard to assess.
> What I can definitly say is that we gained a lot of flexibility while
> stripping down the base code to a minimal.
> It's faster, easier to maintain, easier to understand and is a solid base
> to build on.
> Too often, Grok/Zope2/Plone feels like you're fighting against it or
> bending it to fit your needs.
> I think it's profitable to actually code what you need, starting from a
> simple base instead of having to deal with a lot of decisions already made
> for you that may cripple your project.
>
> i hope I make sense in this mail. I can sound confusing as it's difficult
> to summarize years of decisions, code and try to sparkle an interest at the
> same time.
> There is a simple demo here : https://github.com/Cromlech/CromlechCromDemo,
> that does a few things.
> It's interesting to dissect the anatomy of an application, here :
> https://github.com/Cromlech/CromlechCromDemo/blob/master/
> src/cromdemo/src/cromdemo/wsgi.py
> The focus of my work was to have concise, fast and explicit code , i hope
> it speaks for itself.
>
> Thank you for your interest so far.
> - Souheil
>
>
> 2017-03-09 18:36 GMT+01:00 Christopher Lozinski <
> lozinski at freerecruiting.com>:
>
>>
>>
>> On Mar 9, 2017, at 6:10 PM, Souheil CHELFOUH <trollfot at gmail.com> wrote:
>>
>>
>> https://github.com/Cromlech
>>
>>
>> Well I took a look at it.
>>
>> Many of the package names looked familiar.  They all had a one line
>> description of what they do.
>>
>> Sadly more documentation was lacking.
>>
>> But I linked to it anyhow, from Pylang.info.
>>
>> I wonder if your company is similarly much more productive than your
>> competitors?   It would make very good anecdotal evidence.
>>
>> The problem is that there are not that many users.  I share Paul’s belief
>> of staying close to ZTK users.
>>
>> But maybe we can take a step in your direction.  If we could remove one
>> library from Grok/ZTK, and replace it with your stuff, what would it be?
>>
>> My biggest unhappiness is with zope.publisher.   Just massive and hugely
>> confused.  Grok views are confused and tangled up with it.  It even calls
>> zope.app stuff.
>>
>> Grok guys contorted things to work with the ZTK model.  I would love to
>> rip it out and throw it out.
>>
>> I have my own traversal.
>>
>> I have thought of grabbing the Pyramid Publishing software.   Maybe yours
>> would be better.  That would be one or two packages I could take from you.
>> Good for both of us.
>>
>> What do you think?
>>
>> Warm Regards
>> Chris
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.zope.org/pipermail/grok-dev/attachments/20170310/67c5b5eb/attachment-0001.html>