Re: [python-uk] hexagonal Django

[Chris Withers]

On 05/12/2012 14:13, Jonathan Hartley wrote:

I guess you still need to provide an abstraction for these features,
even if only one backend supports the abstraction.

What I'm reading suggests that if, for example, your app needs to use a
text indexing service, then that's an external system and your
application core should define an API which it will use to talk to it.


Isn't this just the API provided by whatever python library you choose 
to use?



So you still get to use features like this, but you are obliged to put
an API layer (and possible inversion of control) between them, rather
than making the call directly from within your business logic.


What's the actual benefit of this other than an additional layer of 
complexity and one more call in the stack?



Similarly, if your business logic needs a small number of particular
relational-type queries, then perhaps those queries should be the API
defined by your core for talking to persistence.


This would appear to kill the ad hoc querying that makes relational 
databases so powerful. sqlalchemy is about as much of an abstraction as 
I'd ever want...



If your app needs many
such queries, or general-purpose relational querying support, then
perhaps you can create an API which supports general purpose querying
such as the 'repository' pattern.


Again, what's the actual benefit of this other than the theoretical 
ability to switch implementations, which you'll likely never use?


Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
python-uk mailing list
python-uk@python.org
http://mail.python.org/mailman/listinfo/python-uk

Re: [python-uk] Python Developers - ReportLab, Wimbledon, London

[Richard Barran]

On 11 Dec 2012, at 11:38, Andy Robinson  wrote:

> On 11 December 2012 10:51, Andy Robinson  wrote:
>> We are looking for people who are smart, get
>> things done and are good team players.
> 
> 
> For all employers out there  my HR guru goes to all the seminars
> on employment law, and is very current on what we can and cannot do.
> She has told me that our latest round of ads are wrong because
> explicitly asking for SMART people is discriminatory against THICK
> people.   You can ask about skills, but not about innate
> characteristics like age or sex (which we all know), and apparently,
> now, brains.
> 
> Anyone else heard this kind of total bollocks lately?  ;-)

Just say that you meant SMARTLY-DRESSED people :-)

PS Actually, bad idea. You've just dissuaded 95% of the developer population 
from applying for your job.
___
python-uk mailing list
python-uk@python.org
http://mail.python.org/mailman/listinfo/python-uk

Re: [python-uk] hexagonal Django

[Chris Withers]

Yeah, what he said :-)

(joking aside, John has summed this all up very nicely...)

Chris

On 06/12/2012 00:57, John Lee wrote:

On Tue, 4 Dec 2012, Jonathan Hartley wrote:


The last few weeks I've been thinking about the architectural pattern
known as Clean, Onion, Hexagonal, or Ports'n'Adaptors

(http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html).
I'm curious if many people are applying it in the Django world?

I haven't, yet, but I'm thinking of refactoring a vertical slice of
our monster Django app into this style, and I'd love to hear if you
think it's crazy / brilliant / obvious / old-hat, etc.


I have to confess I've only very lightly skimmed the article (which
looks like it says some sensible things), but that's not going to stop
me pontificating in over-general terms and posting a video that I liked:

The best programmers I've worked with have a knack to ruthlessly pick
the simplest possible abstractions to fit the job in hand. They never
stop thinking to settle on any one-size-fits-all programming style. The
problem with those two statements I just made is that everybody can read
them and think that they agree with them. What *I* mean by simple is
close to what Rich Hickey means in the first part of this talk (though I
don't know enough to decide what I think about how he goes on to defend
Clojure and its design principles in those terms):

http://www.infoq.com/presentations/Simple-Made-Easy


(BTW, it's a shame to hear him give security as an example of a
separable concern, because it isn't one)

The best code, you look at the functionality, then the code, and think
"where is all the code?" and "how did such simplistic code happen to
implement exactly what was needed?". That's different from the "OMG,
what is all this stuff for" feeling you get from over-engineered or just
badly-factored code. The best code is easy to change in the sense that
changes in functionality require commensurate coding effort, and it's
clear what code would have to change. But it is also hard to change, in
the sense that any change that leaves the behaviour the same would
clearly make it worse -- including adding or removing abstraction.

I'd agree with Andy that not fighting too many battles with your
framework has a lot to be said for it (and that it's maybe more
important to nail basic coding practices of the kind you'd find in Code
Complete than to take even a single step away from what the django
tutorial tells you to do). But even short programs can gain simplicity
from ignoring the framework or abstracting it a little, where it suits
the problem, as it often does.


John
___
python-uk mailing list
python-uk@python.org
http://mail.python.org/mailman/listinfo/python-uk

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
python-uk mailing list
python-uk@python.org
http://mail.python.org/mailman/listinfo/python-uk

[python-uk] West Yorks. Python Group - Thurs. 13 December - Leeds

[Peter Russell]

== West Yorkshire Python User Group Meeting - Thurs. 13 December ==

= Talk: Simon Davy, Unit testing Django =

Django includes a test framework that is very convenient and widely
used. It includes test database set up, fixtures, and a convenient way
of calling your via Django's framework.

However, it is actually testing your application at integration level,
rather than at unit level. Integration tests are good, but so are unit
tests! (which test smaller areas and run faster).

In this talk we'll look at three different ways to use standard unit
testing techniques when testing django applications to write actual
unit tests.

== Date and Time ==

Thursday 13 December, talk from 7:30pm.

If you want to arrive before the talk, the venue will be open from
about 6.30. We will be finished by 9, and we will be going to the pub
afterwards.

== Location ==

We will be meeting at the offices of The Test People:

Albion Court
Albion Place
Leeds
West Yorkshire,
LS1 6JL


If you have trouble getting in, please call Peter on 07763570860.

== About the Group ==

The West Yorkshire Python User Group (WYPy) have been meeting monthly
since 2007. Our meetings are free, and usually include at least one
talk, as well as a trip to the pub.

Our website is at http://wypy.org.uk . We discuss our meetings on the
Python Yorkshire and Humberside Google
Grouphttp://groups.google.com/group/python-yorks-humber/ and you can
also follow us on Twitter at @WYPython.
___
python-uk mailing list
python-uk@python.org
http://mail.python.org/mailman/listinfo/python-uk

[python-uk] Python/Django meet

[Sally Hall]

Good afternoon all,

It was great to attend the Python/Django meet and to meet so many knowledgeable 
people.

I just wanted to say thank you for the welcome - I hope we weren't too 
"recruitmenty"!
It also looks like we were able to network a few of our clients with some of 
the attendees there, so hopefully that helps a few people.

Just wanted to say it was good to share a drink with a few of you and to see it 
from the other side of the fence.
I was great to see such a vibrant community and to meet a few of you in person, 
rather than just over the phone!

Kind Regards
Sally Hall
IT Recruitment Consultant
01582 394851
___
python-uk mailing list
python-uk@python.org
http://mail.python.org/mailman/listinfo/python-uk