[Grok-dev] Sprint proposal
prsephton at gmail.com
Sat Sep 26 12:51:21 CEST 2015
On 9/25/2015 12:00 PM, grok-dev-request at zope.org wrote:
> Today's Topics:
> 1. Grok Sprint At Plone Converence? (Christopher Lozinski)
Just in answer to Chris Lozinski's ideas for a sprint:
Warning: Wall of Text Follows....
1) I have found that one of the worst things one can do is run
bin/buildout without first pinning package versions. Quite simply,
newer packages are often incompatible with an existing project's install
base. As I already have quite a few apps in production, and may need to
use grokproject in future to install new bases for these projects, I am
not too enamored of the idea of introducing unnecessary change.
Perhaps we should think of making grokproject version specific, allowing
for a stable base for production apps. If we could specify a version
tag to grokproject, then newer changes to the ecosystem could be done
without fear of breaking legacy stuff.
2) If you don't already have a cert, then the first step is getting
one. Generate a private key using openssl, and make a certificate
signing request (CSR), which is a file containing all of your site
details and your public key. The CSR must then be signed by a
certification authority. StartSSL provides web certs for free, and I
heard recently that the free software foundation have also got
themselves involved as a CA.
Once you have your cert and private key, you need to put those in a
place where Apache can find them (usually /etc/apache/ssl) and configure
apache to use the files. You may also need the CA's certificates which
can be freely downloaded. Normally the permissions on the ssl cert/key
files must be 0600 otherwise Apache ignores them. There's plenty of
Apache docs available on the web for configuring these.
3) Serving JSON from grok is as simple as defining a grok.JSON view.
Similarly for grok.REST. Perhaps I misunderstand the idea of tying this
The corporate marketplace - at least the e-commerce marketplace - no
longer needs programmers. Anyone with some rudimentary skills can knock
together a Wordpress site or configure a shopping cart like Zen Cart.
Unfortunate though this may be, the fact is that unless you are trying
to build something really specific, web apps are a dime a dozen and
freely available. Want a CMS? don't hire a dev, just use a ready made
app off the shelf.
We are no longer in the year 2005. We are a decade on.
As so many of these generic apps are based on PHP, at the most your
corporate client may need a PHP dev or a DBA to customise a few things
around an existing app.
For the same reasons, it makes very little sense to be building
alternate web frameworks these days. There is little interest in web
frameworks outside of the specific non-general needs already catered for
by generic web apps. For example as a server for a specialised phonegap
based mobile app.
In such cases, smart money is likely to follow existing established
trends; python=Django, java=Spring, PHP=Laravel. MySql or perhaps
PostgreSQL if relational otherwise one of the NoSQL variants.
Where would Grok fit into this picture? Unless it brings something
really appealing to the mix, it's choice of a caveman for a logo is
So what can Grok offer that others cannot? In my opinion, the fact that
it is based upon a component architecture brings an unprecedented degree
of plugability and extensibility. The ZCA is it's greatest strength,
but somehow even those in the know find themselves apologising for the
ZCA and how hard it is to learn. Pyramid hides the ZCA as much as it
The idea of using ZCML to configure components to be plugged into the
framework was patently ridiculous. What is needed to make sense of it
all, is a way to discover and configure components via a simple UI. In
Zope-2, dropping in a new PAU was as simple as adding it to the tree at
the appropriate location- that is why Zope-2 was so popular. We need
that ease and simplicity back, and it's very much an attainable goal.
Just as the development of pluggable components is popular for Zope-2
and Plone, there is every reason to believe that this kind of
extensibility would help to popularize Grok.
Pluggability and re-usability of software components need not be a chore.
More information about the Grok-dev