Code Kata

  • September 13, 2012 · 6:00 PM
  • This location is shown only to members

Hej Pythonistas!


How about meeting and doing some coding together? I suggest we work in pairs on a code kata. I've been looking at some suitable ones, and I was hoping you'd join me in trying out a couple of these exercises:

https://github.com/emilybache/TDDwithMockObjectsAndDesignPrinciples/tree/master/TDDMicroExercises

I've just blogged about my experiences trying them out in Java. I'd be really interested to see how we get on doing them in python, and whether using a dynamic language affects the SOLIDness of the code afterwards.

Before we do any coding I have a short presentation about SOLID design principles in any case.

We can of course all catch up after the summer too. Welcome!

Join or login to comment.

  • Magnus L.

    I found this interview with uncle Bob about SOLID to be helpful http://www.hanselminutes.com/145/solid-principles-with-uncle-bob-robert-c-martin

    September 23, 2012

    • Emily B.

      "dynamic languages
      automatically obey the Interface Segregation Principle
      and obey it in the most extreme way possible. There
      is no way for them to depend on any more than the
      methods that they actually call." I guess we'll be running into this at the next meeting with the other two exercises :-)

      September 24, 2012

  • Olof B.

    Thanks a lot for this code kata! Flamebait: My main objection against SOLID, or actually any of these design ideas is that it is in direct violation of one of my core principles: YAGNI (You Ain't Gonna Need It). That means that I am actually against generalising/"designing" things until the need arises. So in the Alarm example, I would not want to abstract out a "signal reader" interface/abstraction until that is actually needed. Needed in this case means either (1) I really want to make the Alarm class unit testable in a readable fashion (maybe because I've spotted a bug in the implementation) or (2) suddenly we need the alarm class for something more than detecting the specific case of tire pressure failure. Abstraction for abstractions sake is a nice academic excercise, but I don't think it's a good practice for day-to-day-work. Inventing abstractions that doesn't DRY (Don't Repeat Yourself) up the code will, IMHO, actually make it less readable/maintainable. Am I making sense?

    September 13, 2012

    • Olof B.

      Regarding having both YAGNI and SOLID at once: if we assume that the Alarm example/scenario actually was about getting Alarm class under tests because of some bug or some other reason, I think it absolutely makes sense. But generalizing to abstractions/patterns before such a need arises I would not generally do. I'm not saying I'm against generalization/abstracti­ons/SOLID - what I don't like is doing it without a real business reason. (applying patterns without a business push has a sublime scent of over-engineering/BUFD to me)

      September 14, 2012

    • Emily B.

      In fact in Bob Martin's book he admits that it's not possible to come up with a design that will easily accommodate all future contexts - you have to make educated guesses about what suitable abstractions are. (see page 105 discussing the OCP). He says writing tests for your code give you valuable feedback about what you will likely need. Real-life feedback is also valued, but by then it could be expensive/difficult to improve the design.

      September 21, 2012

  • Magnus L.

    Det var intressant, men det är som vanligt att en del design-principer känns lite halv-relevanta för Python, och kator översatta från andra språk speglar kanske inte bäst styrkor, svagheter och fällor i Python. Nåväl, post coitum omne animal tristis est.

    September 18, 2012

  • Samuel Y.

    it was awesome! Maybe we should have started with the Kata before lunch so you could have it beside you while you eat, and think?

    September 13, 2012

  • André L.

    I really like the design aspects of coding, and it's interesting to see people with different backgrounds applying it to Python. Thank you Emily for a good presentation.

    September 13, 2012

  • A former member
    A former member

    I learned a lot, thx everyone!

    September 13, 2012

  • Robert E.

    Sorry for the douchy move of RSVPing and not showing up, I totally had my mind set that this was taking place tomorrow until just now.

    September 13, 2012

  • André L.

    My +1 can't come so there will be one food thingy too much anyway.

    September 13, 2012

  • Olof B.

    I will not be eating tonight, and I see that 9 spots are left so I'll take a chance and show up even if I didn't RSVP on time ;) Cya !

    September 13, 2012

    • Anders A.

      Do do think we could have some food over even.

      1 · September 13, 2012

  • Anders A.

    If you planning to come please make sure you RSVP as soon as possible so we can plan the food list.

    September 10, 2012

8 went

Our Sponsors

  • Bache Consulting

    Paying for the meetup hosting and refreshments at meetings.

  • Dalke Scientific

    sponsors with refreshments for meetings.

  • Software Skills

    Providing a venue and refreshments for meetings.

  • Mecel

    Providing a venue and refreshments for meetings

  • Squeed

    Providing a venue and refreshments for meetings

  • Metrical

    Refreshments at meetings

  • Tajitsu Industries AB

    Providing a venue and refreshments for meetings.

  • Duego

    Providing a venue and refreshments for meetings

  • Spotify

    providing a venue and refreshments for meetings

  • Jeppesen Systems

    Providing a venue for meetings

  • Lavasoft

    Providing a venue for meetings

People in this
Meetup are also in:

Imagine having a community behind you

Get started Learn more
Rafaël

We just grab a coffee and speak French. Some people have been coming every week for months... it creates a kind of warmth to the group.

Rafaël, started French Conversation Group

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy