Meeting Notes

[Rohit Patnaik]

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]

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]

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!

--

Benjamin Turner
http://www.benjaminturner.me

[Stephen Burrows]

The slides from my talk are up at https://speakerdeck.com/melinath/automated-testing-philosophy-and-tools

[Alec Koumjian]

Here are the slides for mine: https://speakerdeck.com/akoumjian/better-django-views

[Christian Metts]

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).