jvanasco

"""
The following are some code snippets on how i optimized a system using Dogpile cache into native Redis, while still leveraging dogpile.

This is not fully functional code, it's just snippets to explain and help the next person:

General Overview:

* The cached data is a computed value of multiple permissions for an A2B relation.
* The Redis key is `'calculated-a|%s' % id_a`. 
* The payload is stored in a field, via `id_b`.

jvanasco

It's your data. 
It's our responsibility to protect it.
As a new data protection regulation goes into effect in Europe, we are taking the opportunity to make improvements for all 23andMe customers globally. On May 24, 2018, we launched important privacy updates and new tools as part of our ongoing commitment to ensure that you are in control of your data.
We updated our Privacy Statement with additional information about our practices and made it easier to understand.
https://www.23andme.com/about/privacy/

We created a Data Protection Center to help explain the European Union's new regulation and provide information about our approach to compliance.
https://www.23andme.com/gdpr/

We added information to our website regarding our security practices and the measures we put in place to protect your data.

jvanasco

LetsEncrypt DNS Auth HOWTO

This is a quick howto on generating SSL certs via EFF's CertBot using DNS authentication.

This works for domain and wildcard certs.

For security reasons, certbot is run on a local machine.

Wait, Security?

jvanasco

[model]
name = Page
label = {{ this.title }}

[fields.title]
label = Title
type = string

[fields.meta_title]
label = MetaData Title

jvanasco

# -*- coding: utf-8 -*-
"""
this translates unicode codepoints in the input into *NAMED* html entities
a future version may do the html spec supported entities as well

this does not escape unsafe html into entities, as lots of libraries do that and
this function is likely to be used in a pipeline that does that too.

this simply standardizes unicode points into html entities.
"""

jvanasco

# -*- coding: utf-8 -*-
"""
this translates unicode codepoints in the input into *NAMED* html entities
a future version may do the html spec supported entities as well

this does not escape unsafe html into entities, as lots of libraries do that and
this function is likely to be used in a pipeline that does that too.

this simply standardizes unicode points into html entities.
"""

jvanasco

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#
# Use this file to build your own SSCCE
# SSCCE = Short, Self Contained, Correct (Compatible) Example
# see http://sscce.org/
#
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

jvanasco

if True:
    print("===> installing import_logger_orverride")
    import os
    import psutil
    import pdb
    import pprint
    import __builtin__
    import logging
    import sys

jvanasco

if True:
    print("===> installing import_logger_orverride")
    import os
    import psutil
    import pdb
    import pprint
    import __builtin__
    import logging
    import sys

jvanasco

"""
After a bit of thought, I rewrote our response caching.

I stripped it into this gist in case anyone needs a starting point in the future.  it's still rather specialized and hacky... but a bit cleaner than the earlier approach

The general overiew is this:

* We needed to cache responses AND perform some light operations.  99% of a rendered page is cachable as-is.
* We wanted to consolidate where the configuration is, perferalbly with the route_name declaration - but in this case it was better off with the caching code.
* The cached output should be rendered, which mades the `decorators` egress perfect... however some setup code happens in the __init__ phase of view-based classes and the 'decorators' ingress happens too soon.