We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

What dojos are and how we run them at pyBCN

00:00

Formal Metadata

Title
What dojos are and how we run them at pyBCN
Title of Series
Part Number
42
Number of Parts
173
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language
Production PlaceBilbao, Euskadi, Spain

Content Metadata

Subject Area
Genre
Abstract
Núria Pujol/Ignasi Fosch - What dojos are and how we run them at pyBCN Coding dojos are a very good way to share coding knowledge among members in a community, and, at the same time, introduce people into the language and community. Sometimes, though, the typical approach to set coding dojos may prevent expert coders to join the session. This is the story of the pyBCN's dojos, so far.
Keywords
51
68
Thumbnail
39:40
108
Thumbnail
29:48
BitSicSystem programmingSoftware developerDataflowLevel (video gaming)SineSelf-organizationSoftware developerBitConnectivity (graph theory)Computer programmingWorkstation <Musikinstrument>MereologyDifferent (Kate Ryan album)Physical systemSet (mathematics)Point (geometry)MeasurementDivergenceOntologyLevel (video gaming)TheoryFormal languageSummierbarkeitGroup actionWordGame controllerSystem administratorData miningField (computer science)CodeWebsiteHypermediaLecture/ConferenceComputer animation
CodeCodeProcess (computing)2 (number)AlgorithmSimilarity (geometry)Interior (topology)ProteinPhase transitionTwitterMultiplication signComputer animationLecture/Conference
State of matterWritingSoftware testingRevision controlTheory of relativityContext awarenessLecture/Conference
IterationParameter (computer programming)AuthorizationComputer programmingFiber bundleOffice suiteSoftware developerComputer animation
IterationDirection (geometry)Multiplication signWritingSoftware testingStaff (military)Personal digital assistantData structureCuboidIterationArithmetic meanParameter (computer programming)Order (biology)Computer animation
Arithmetic meanStatement (computer science)Video projectorSoftware testingCASE <Informatik>Configuration spaceEndliche ModelltheorieDecision theoryCondition numberProjective planeSheaf (mathematics)Form (programming)Lecture/Conference
Multiplication signUnit testingRevision controlFeedbackSet (mathematics)Beta functionNumberDecision theoryDevice driverStudent's t-testUniformer RaumComputer animation
Internet service providerIterationDifferent (Kate Ryan album)Task (computing)Logical constantPort scannerComputer programmingMathematicsGame theoryParameter (computer programming)WeightDivisorMereologyWorkstation <Musikinstrument>BitCodeDifferent (Kate Ryan album)ScatteringBasis <Mathematik>Endliche ModelltheorieComplex (psychology)Metropolitan area networkArithmetic meanNetwork topologyAreaMobile WebMultiplication signExecution unitSign (mathematics)Self-organizationTwitterRight angleDecision theoryFamilyFormal languagePlanningConfidence intervalPoint (geometry)Special unitary groupArmCountingError messageGroup actionLibrary (computing)Shared memorySoftware testingProgrammer (hardware)Computer animation
MultiplicationMetropolitan area networkCodeFile formatField (computer science)Multiplication signAbsolute valueArithmetic mean1 (number)CubeIterationCASE <Informatik>Matching (graph theory)Internet service providerPoint (geometry)Different (Kate Ryan album)FeedbackFocus (optics)Direction (geometry)Contrast (vision)Metropolitan area networkExecution unitKeyboard shortcutForm (programming)Bridging (networking)MereologyWorkstation <Musikinstrument>Product (business)Endliche ModelltheorieForcing (mathematics)State observerSequenceQuicksortComputer animationLecture/Conference
HTTP cookiePlanningTheory of relativityControl flowRadiusNeuroinformatikRight angleOperator (mathematics)MultilaterationLecture/Conference
Computer animation
Transcript: English(auto-generated)
First of all, a little bit of us. Okay, just to say that we are not developers, we are organizing. We are organizers in PyBCN, but not really Python developers. I'm an Instrumentation Engineer in FESIC, in a Spanish research council. I'm working in marine technology.
But I use Python everywhere I can. Hi, I am Ignacio. I am an infrastructure engineer. I am working at devx.com. Media site about NGO and international development. I'm more... I'm coming more from the system administration part of the thing. I like to write prams since I was a kid.
So I'm kind of a wannabe developer, not very good. A little bit worse than a system administrator, but trying to balance both. By the way, if you ever come to visit Barcelona or something, you can check in
pybcn.org about our activities or meetups or dojos or whatever. So if you are around, you can feel free to come and give a salad. So we're gonna give a very introductory talk on what we have been doing for the last
nine months, one year, because we started with doing some dojos. Is there anyone who knows what the code is? Right now? Well, quite a few. We will start with a brief story of five Barcelona dojos, how we started doing them, how...
what we have been doing a little bit. Then we will give a small introduction to what a code in dojo is and what related concepts are with it. We will do a small recap on the sessions we own, just choosing some of them. Not all, because it could be quite long. Then we will take a look back on to see what things we learned doing dojos, about what you need to prepare, what things
you need to be aware of. Then we will be talking about the dojo sessions we are going to be running at the EuroPython this year. We will give a very small set of ideas to start with your community. Actually, it's a
pair of points. The five Barcelona dojos started with... actually, we're not related to the five Barcelona group before. We started with a small group of system administrators,
people who was interested in to learn some programming stuff, and then we decided to start using Python, because it looked like a very low-wary, anti-level language, easy to learn and to start working with. The big problem we had is that we did very infrequent sessions. We barely did one every two months.
After having these sessions, or during having sessions in another conference, we were connecting with some five Barcelona members about what we were doing, and they were quite interested in setting up these sessions for the whole Python Barcelona community.
So with them, we started running these sessions monthly, determining the dates every three months, and having different kinds of sessions. Because we felt that there were a lot of different skill levels among the people that were kind of interested in having them.
So we are going to talk about what has passed for the last nine months. Well, for those who don't know, coding dojos is a hands-on session. The first very important target or goal of these sessions is to have fun with code, colleagues and people with similar interests.
The second is learn from others, because usually it comes that there is someone attending that says, yeah, I'm very new, but I don't know anything, or I barely use Python. But there are also other people that master some subjects on Python, or even on just the kind of algorithms we are proposing.
And for the people who know more about Python or master some subjects, it's to share the individual knowledge. We get that because we try to use several techniques that I'm going to explain later.
Also, we use coding dojos just to practice new technical tools, which we don't use to do them in our daily job. For example, writing tests, or doing TDD, or such on.
Then the related concepts, more important to be aware of when you are attending or organizing a dojo, are those of here. The first one is the cata. The cata is the trivial exercise we are going to state for the sessions to complete. It's trivial because it's usually not very difficult.
And it's trivial because it doesn't matter if we come to a solution. We are not trying to cure cancer or to find anything big. And it doesn't matter if individually or within the team we form of, we find a solution.
What we are trying is to learn from what others are doing within the team or with other teams. Usually we use programming also, because this is a very good technique. Especially when you use programming with TDD, for example, it can be kind of fun.
Also, we do iterative development. When we prepare the cata, we tend to have some preparation before, in order to have the steps, the iterations we are going to have. So we can guide people attending. These iterations are done within a time box test structure.
We use the parameter technique, which is just having 25 to 45 minutes to have every iteration. We tend to change the times and it's kind of chaotic sometimes, but it's important to try to enforce these techniques.
Also, we put a very strong emphasis into differentiating testing versus TDD. This doesn't mean that we need to write tests for everything. This doesn't mean that we use TDD in all the sessions. There are some sessions where we enforce much more TDD. There are some sessions where we only want to see some tests to check that everything works.
And even we have some sessions that we are not even looking at the tests in case they are. Also, on each session, after all the iterations, we have... Well, it should be small. Usually it is not a retrospective session with all the attendance, so people can explain what they like, what they don't like,
what they learn and what they are taking off from the session. So we can learn what we are doing good, what we are doing bad and we need to improve, or what we should be taking care of. Sometimes it's very stupid. Sometimes it's just a format, the air conditioner of the room or the quality of the projector or something like that.
But sometimes people explain, yeah, this kind of problem was very nice, but we hadn't a statement before, or we hadn't a statement to check when we were coding. Things like that can be helpful to improve the sessions.
So, this is a small recap on three of the most cool or interesting sessions we had. Some months ago we had the PyTest versus Unittest session. It was intended to be a hands-on on PyTest, with comparing with the Unittest version on the same cutter, very simple and small.
One of the big problems we had with PyTest versus Unittest session, it was that we didn't have so much knowledge of PyTest. We just had the very introductory knowledge. So it was very hard to answer certain doubts that people get. We were trying to, when we did that session, we were trying to provide something more interesting
for people with some experience that are not so interested in starting with TDD, but learning about what they can get from using other tools. And this was one of the problems we had there.
In the Selenium QM Python session, which was based on Peter Hinge and his workshop at EuroPython 2014 last year, it was quite interesting. We had, I think, 18 people attending. It was quite a stress, but it was very, very nice.
The feedback was very good, so we are quite happy. Maybe we should have some more time to learn more about Selenium Qv4. We used to be kind of the procrastinating people. And the feedback was very good. We had a lot of people working with engineering,
interested in engineering also, and so on. And, yeah, sorry. Then we had another session with mocking to introduce the research of the mock library, which is not re-included, but it's very useful to find out,
to fake things happening around our code in the architecture. This session was kind of bad, at least, because we hadn't been very prepared. This was one of the first new kind of sessions we had. We went with a supposed kata that we invented, which we haven't tried.
We will see later. This is one of the very first things you need to do if you want to organize those sessions. Okay, and a little bit about what we have learned doing this, because in these sessions we also learn about people who come and that.
One, the first seems very elementary, but you have to practice your kata before to the other people. And usually we find, we try to think what could be the different solution that people we are going to find, just to guide the session to be fun and to be fast,
and not to be worried, but by the people, yeah. You have, obviously, if you guide the session, you have to have a specific knowledge, but you don't have to be a master. You only have to have a main idea, and usually people who come to our dojos,
when we guide, usually the solution that they show, are almost better than us, or have some points, and all the people in the session learn something, yeah. Then, okay, if you introduce a new library, probably,
you have to take care to show the basics of the library. You have to take time to, all the people start with the same knowledge. And to guide the session, it's really important to have learning skills to learn,
teaching skills and these kind of things. I think it's the most important to feel that, to make feel comfortable, all the people in the room, yeah, and that it's useful, okay. And then it's open to other programmers that come from other languages,
but we try to focus on Pythonic solutions, of course. Okay, and a little bit about the session, we are going to do in EuroPython, okay, on Python sessions, we are going to focus, to explain a little bit baby steps and see how it works.
And yeah, practice pair programming. I don't know if you ever programmed in pairs, but I think it's quite fun, not just to be three hours alone programming, programming alone, okay, sorry. And it's just a game, but programming, usually a pair program the test
and the other program the program, the code to solve, and then change the roles, and I think you learn how to do the test, how to program, and one of the important parts
is, yeah, if you have a Mac and a PC who manage this session, which editor, which, and sometimes you learn new things, sharing with your partner, even more than in the group. Okay, and the Saturday session is going to be a little bit complex, but okay, these two sessions are related to the typical algorithmic problems,
are going to be classical algorithmic problems, okay, just to practice TDD. Okay, Fridays is more for using TDD, and Saturdays is just texting. And in a more complex kata, probably you are going to, if you come,
you are going to practice some refactoring about the problem, okay. The seats are really, really limited because our sessions in Barcelona are in a small group, and we will, we want to be very personal in every group, know what it's doing,
and we think that 20, 25 people in the room, it's how to manage, okay. Then come soon, we are going to publish in Twitter, or I don't know, in that way, we are going to make another bride, you are going to sing it up.
Okay, I think you are going to sing it up, and I want to see you in these sessions. Okay, a little bit about, if you are interested in Python modules,
I think it's a good, it's a good way to spice your community. I'm a Python organizer, since two years ago, and I feel that, okay, you organize meetups and conference, but it's a little bit cold, okay. People come, people sit here, and go away.
I think it's, with PyDojo, we have a community that you know what is developing, what, it's like a family now. We do PyDrenas and these kind of things. I think it's a relationship more, okay, and more, it's more warm, okay.
I think if you are interested, if you want to ask us how to start coding Dojo in your community, or if you want some examples or some experience, if you want to share some experience with us, we are here all the week, and we recommend to read this book
about coding Dojo's handbook, with my Emily Wines. And of course, you can contact us with using Twitter and in person here these days. Any questions?
Yeah. About the katas? Yeah. About the katas, do you prepare it in advance, or do you just go and you ask people what they want to do, and... Yeah, we know a lot about people who usually come.
People repeat, that's an important point. But yeah, we ask if people, new libraries, if we want to try new libraries, we try different formats. Yeah, it depends on the people. For this reason, we think that the feedback that we...
that we get at the sessions are really, really important for us. We still know that it's interesting or not, or what to change in the next session. About the kata preparation, it also depends how much time do you need, because sometimes you can have a very complex kata and then you need more than a week to prepare it.
That doesn't mean that you need to be careful, because if you prepare the kata during one week, you can easily have a kata as long as the time you have for running the session. But if it's simple, you can have it easily in 20, 30, one hour.
I've got loads, actually. I organized the London Python code. Okay, yeah, I know. We asked, actually, we talked with someone, we talked with Rashid about that. Yes. And then we were consulting what you were doing, because you are not doing so much TDD, right?
Yeah, I think we're doing quite differently, actually. How does yours work? You have only two persons at the front and everyone is looking? No. No, you mean like in a randori. The randori format is that two people are working and the rest are looking. No, we have been thinking about trying out different kinds of sessions for the dodgers.
This is one of the ones we haven't considered, but we never did one of those. What we did is to start with pairing people and commenting the kata, explaining what the details that the kata can have for complex and things, and then with the people working in pairs, start working with that. If they got a simple enough to run just one iteration,
then we try to enforce people to switch the teams so they can share with more people in the same session. If they got this more complex, then we just stand with that and go on with preventing complex iterations. Yeah, and usually then we aim the people to share the code and explain how it works.
How many iterations are you doing, roughly? Three, four. Four in the rest of the cases. Why is it the best? Like Shidi said before, there's always someone attending that masters much more than you. We had, for example, one guy with one kata. The guy just solved the first iteration, the second iteration,
and the third iteration using the first one. Oh, well. Yeah, you cannot expect to have this kind of thing. You always have to think more of the stuff, more fun than the time you have because of the people who are coming. Not to be bothered, we try to enjoy all the people.
We also started doing something by the end of the year. We prepare the sessions every three months, every quarter. So we did a very simple kata in the first month and in the second month we do a more complex kata
with less TDD or less test focus. And then we have a third session with, I don't know, for example, a seven cube. With a special field library, yeah. Can I ask more questions? Show me the last one. Okay. How many of you are coming every dojo?
Well, depending also on the lack of festivities and so on, it's very important, especially if the Barca football team is having a match. We have to, we choose the dates in advance. Yeah, absolutely. Three months in advance and sometimes we don't know. But we used to be like 10, 50 people. Okay.
And do you provide beer and pizza or something like this? Well, we had some kind of things. Yeah, cookies. Sometimes I cook pizza, those kind of things, yeah. Yeah, but we're planning to talk with some local brewery to get beer or something. And we're paying for this then? We're paying for the cookies and the beers and...
Uh, yeah, actually. Yeah, we are within the Pirates on a Rook, so everything comes together. Okay, and is it free to attend? Uh, yes, yes. Well, we have only the, we are publishing there and right with 25 seats. Yes, much more people could be kind of difficult to manage.
Thank you very much, I mean... We'll talk later. Okay. Right now, there will be a coffee break and we'll start at quarter to five sharp. And don't forget that you can read this talk at the guideline,
guidebook, sorry. And that's it, that's it, see you after the break. Thank you for coming. Thank you.