Meeting Notes

19 views
Skip to first unread message

Rohit Patnaik

unread,
Jun 26, 2013, 2:53:02 AM6/26/13
to django-...@googlegroups.com
Hello Djangonauts,

Great turnout at the meeting tonight!

For those of you who are interested, here are the notes I took about the presentations at tonight's meeting:

Steven: Automated Unit Testing with tox and travis:
  • Ideal:
    • Test with every supported version of Python
    • Test with every supported database/search
    • Test with every supported dependency
    • Test with every supported combination of the above
  • Without automation:
    • Testing with every supported Python is barely feasible
    • The others (especially combinations) are not feasible at all
  • With automation:
    • Testing with all supported Python, database/search, dependencies is easy
    • Testing combinations is still difficult, but feasible
  • Package Layout
    • Put test code in a test_project
      • Sets up django environment
      • Contains canonical test settings
      • Hides requirements file (prevents people from mistaking test dependencies for runtime dependencies)
    • New requirements file for each version of Python you're testing
    • A good requirements file is reproducible
      • Explicit package versions
      • Git commit IDs when versioning isn't available
  • Tox
    • Tox is a tool for local testing
    • Runs before commit, or before push
    • Specify supported python and environment
    • Specify command to run tests
    • Need to manually compile combinations matrix
      • 2 dimensional matrices feasible
      • Multidimensional matrices are very difficult (combinatorial overload)
  • Travis CI
    • Remote testing service
    • Runs after push
    • Isolated virtualenvs
    • Can test with different versions of Python
    • Github integration
    • Originally for open-source code, but now has paid plans that you can use to build and test your closed source projects
    • Travis can automatically compile your test matrix for you
    • Need switches in django settings to set up multiple databases
    • 2 dimensional matrix is easy
    • Multidimensional matrix is difficult, but feasible
Alec: Better Django Views
  • A good view:
    • Captures the request/response cycle
    • Is reusable
    • Is easy to debug
  • Functional views
    • Captures request/response cycle well - you can see exactly how and where the response is created
    • Not composable or reusable
  • Improved functional view
    • Abstract logic into smaller components and reuse those
  • Class based views
    • Inheritance encourages reuse (in theory)
      • Can use multiple inheritance to do mixins
    • Declarative syntax
    • Can be good, but generic class-based-views are usually bad
      • Hide request response cycle
      • Not as reusable as they seem - in practice, modifying a view leads to a lot of copy/pasted code
      • Hard to debug - response can be generated in one of many places depending on the nature of the request
  • How to improve class based-views
    • Atomic methods
      • Make each method in a class more atomic/standalone
    • Pipeline views
      • Combine the advantages of class based views and functional views
      • Specify pipeline of methods or functions to be applied in turn
      • Response generated by last stage of pipeline
      • Use subscription wrappers or decorators to specify which HTTP verbs you're interested in
      • Inspired by Django Social Auth and Django's own middleware pipeline
  • Advantages and disadvantages of pipeline views
    • Advantages
      • Easy to debug: you have a pipeline with discrete steps and the output from each step of the pipeline forms the input to the next step
      • Explicit - no inheritance magic in deciding which method is applied to the request
      • Encourages modularity - you're encouraged to write atomic functions that can be reused in different pipelines
    • Disadvantages
      • Verbose
      • Subscription based dispatch can be obtuse
Christian: API driven app design
  • API in web context == RESTful endpoints and structured data
  • API driven == dogfooding (your website is just another consumer of your API)
  • APIs are, fundamentally, a means to get data
  • Data is
    • Abstract - don't expose details details about how data is stored or accessed; those may change and you don't want those implementation changes to break the API
    • Stupid - the amount of processing your templates can do is limited, since API consumers will be bypassing normal web templates
    • Consistent - all consumers should get same data; web front-end shouldn't have privileged access to data stores, etc.
    • Structured - data must be presented in a structure that's understandable to multiple parties
  • Compromises
    • Can't lazy load
    • If you put in an API call, you can't easily take it out, especially if you've documented it
    • Handling private data or optional fields can be problematic - how do you signal to clients that this field may or may not have data?
  • HATEOAS
    • Third party client can derive your API by following URLs embedded in the data that you return
    • Easier to document
    • Easier to code against - don't need to explicitly configure endpoints; client can see where it has to send the next request, and when the request endpoint updates, the client "knows" the new location automatically
  • Decisions
    • Impure dogfooding
      • API is used for most things, but not all
      • All writes go through API, however
    • Need to return "real" HTML from all URLs
      • Hard constraint on the type of templating that you can use
    • Don't need to deal with HTML forms, since all writes go through API
  • Templating
    • The need to return real HTML as well as JSON data from URLs makes templating difficult
    • Moustache/Handlebars is too dumb
    • Everything needs to be render-able in both Python and JS
    • Plate.js - Django templates in the browser
    • Limited template context - don't have access to the same things on the client side that you do on the server
    • Tags and filters need to be written twice
  • Unsolved mysteries
    • How do you handle complicated views?
      • Single endpoint that provides a complicated data set
        • Hard to change
        • Hard to repurpose - if I only want some of the data, I still have to request all of the data
      • Multiple endpoints composed together
        • Difficult to intuitively know "all these endpoints go together"
        • Possibly many more round-trips, depending on implementation
If you spot any inaccuracies or missing items in the above notes, be sure to reply with a correction :)

Thanks,
Rohit Patnaik

robertlnewman

unread,
Jun 26, 2013, 11:31:22 AM6/26/13
to django-...@googlegroups.com
Hi Rohit,

Thanks so much for this - very useful for those of us who couldn't make the meeting but wanted to see the minutes.

Interesting comments by Alec on GCBV. I would have really liked to have seen that talk. I have not had that negative experience of GCBVs, and especially with custom mixins, find them much better (and modular) than the old function-based GVs.

Hopefully I can make the next meeting.

Best regards,
- Rob Newman

--
You received this message because you are subscribed to the Google Groups "django-seattle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-seattl...@googlegroups.com.
To post to this group, send email to django-...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-seattle.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Benjamin Turner

unread,
Jun 26, 2013, 12:38:31 PM6/26/13
to django-...@googlegroups.com
Rob,

We did record last nights talks so we'll have them available online in the near future. Hope you can make the next meeting!

Rohit, thanks for these notes!
--

Stephen Burrows

unread,
Jun 26, 2013, 4:45:40 PM6/26/13
to django-...@googlegroups.com

Alec Koumjian

unread,
Jun 26, 2013, 4:53:47 PM6/26/13
to django-...@googlegroups.com

Christian Metts

unread,
Jun 26, 2013, 8:32:26 PM6/26/13
to django-...@googlegroups.com
And mine: http://labs.mintchaos.com/code/2013/api-driven-app-design.html

— Xian
> > > > > To unsubscribe from this group and stop receiving emails from it, send an email to django-seattl...@googlegroups.com (mailto:django-seattl...@googlegroups.com).
> > > > > To post to this group, send email to django-...@googlegroups.com (mailto:django-...@googlegroups.com).
> > > > > Visit this group at http://groups.google.com/group/django-seattle.
> > > > > For more options, visit https://groups.google.com/groups/opt_out.
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google Groups "django-seattle" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send an email to django-seattl...@googlegroups.com (mailto:django-seattle%2Bunsu...@googlegroups.com).
> > > > To post to this group, send email to django-...@googlegroups.com (mailto:django-...@googlegroups.com).
> > > > Visit this group at http://groups.google.com/group/django-seattle.
> > > > For more options, visit https://groups.google.com/groups/opt_out.
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > Benjamin Turner
> > > http://www.benjaminturner.me
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "django-seattle" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an email to django-seattl...@googlegroups.com (mailto:django-seattle%2Bunsu...@googlegroups.com).
> > > To post to this group, send email to django-...@googlegroups.com (mailto:django-...@googlegroups.com).
> > > Visit this group at http://groups.google.com/group/django-seattle.
> > > For more options, visit https://groups.google.com/groups/opt_out.
> > >
> > >
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "django-seattle" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to django-seattl...@googlegroups.com (mailto:django-seattle%2Bunsu...@googlegroups.com).
> > To post to this group, send email to django-...@googlegroups.com (mailto:django-...@googlegroups.com).
> > Visit this group at http://groups.google.com/group/django-seattle.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
>
> --
> You received this message because you are subscribed to the Google Groups "django-seattle" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-seattl...@googlegroups.com (mailto:django-seattl...@googlegroups.com).
> To post to this group, send email to django-...@googlegroups.com (mailto:django-...@googlegroups.com).
Reply all
Reply to author
Forward
0 new messages