Coding Dojo @DR 003

Below you'll find all details of the Coding Dojo @DR 003 meeting. Please comment on this post with your opinion or concern on any topic. 

This time we'll be practicing with a Kake format (see Little Coding Dojo Intro for a details on each format). We have an open discussion on Google Moderator (http://goo.gl/wKgwu) to select the Kata to be used. Please go to that URL and vote up for your favorite problem(s). We need at least one PC (laptop) on each team, so bring yours; it might be needed.

Newbies, please check the following references before the next meeting:

• Coding Dojo @DR, Gathering post
• What is Coding Dojo post
• Little Coding Dojo Intro
• RandoriKatas format
• PreparedKatas format
• KakeKatas format
• CodeKata, the Coding Dojo's crib
• Test-driven development cycle

I  -Event URL:  http://goo.gl/dkNdT

II -Katas Pool

Go to Google Moderator series http://goo.gl/wKgwu, select your favorite problem(s) or add new ones. We'll pick the one(s) with more votes.

III-Expected attendees: 15 to 20

IV -Expected duration: 3:00 hrs. (3 hours)

V  -Agenda

1. Inform next session date: 1 minutes
2. Share moderator link to decide on a Topic for next session:  1 minute
3. Form groups (3 to 5 members each): 8 minutes
4. Kake Work (Code!): 120 minutes
5. Each group shows their solution: 16 - 32 minutes (up to 8 minutes each)
6. Retrospective. What went well? What was interesting? What was frustrating?: 15 minutes

---

This section will be filled after the event.

VI  -Next event URL: http://goo.gl/BRDR4

VII -Next event date: Tue, Nov 13, 6:30 PM - 9:30 PM

VIII-Actual attendees: 12

IX  -Actual duration: 3:00 hrs.

X   -Worked Katas:
SQL string generator

XI  -Retrospective 

What was frustrating?

• This time nothing but the poor level of detail of the selected Kata for some of the attendees. 

What went well?

• Everyone feels this format (Kake) was more fun than others.
• All groups work, with different levels of detail, the problem and achieve a solution with its set of tests.

What was interesting?

• We "taste" a little of new languages.
• We saw different approaches of solving the problems maid possible by using different tools.

Next meeting agreements:

• We will be rotating the 3 formats (Prepared - Randori - Kake).
• The next format is Prepared
• 3 of us must prepared a Kata (one each). Actually we have 4 candidates +Daniel Paniagua, +Eduardo Burgos, +Rafael George, and +I. 
• Each prepared Kata will last from 30 to 45 minutes.

XII -Action Points

• Confirm availability of the presenters.
• Confirm Kata's themes and duration.

Coding Dojo @DR 002

Below you'll find all details of the Coding Dojo @DR 002 meeting. Please comment on this post with your opinion or concern on any topic. If you haven't read this post, please read it to gain a better understanding about this event.

For this second meeting, I want to emphasize points 3 and 4  of the Agenda. First we need to give a solid an clear introduction to the Coding Dojo Topic (meeting formats, objectives, and rules). Also is  almost mandatory for everyone to understand the TDD cycle and to see, in practice, a solution build using TDD. On the last meeting we noticed that people were unaware of the meeting format and objectives, although several references were given. So, if this is your first meeting; or you have not read the following references, please do it before the next meeting:

• Coding Dojo @DR, Gathering post
• What is Coding Dojo post
• Little Coding Dojo Intro
• RandoriKatas format
• PreparedKatas format
• CodeKata, the Coding Dojo's crib
• Test-driven development cycle

I  -Event URL:  http://goo.gl/ykQWe

II -Katas Pool

We must select (see point 5 of Agenda), one or more Katas to practice on each Dojo session. The following list is an extract of some easy Katas, please review each one to be informed when making your decision. You'll find more Katas at this blog Code Kata's Page.

• Repeat Separator
• KataWordWrap
• Number Persistence[Multiplicative]
• Test data
• Kata Diphthong and Hiatus

III-Expected attendees: 15

IV -Expected duration: 3:00 hrs. (3 hours)

V  -Agenda

1. Decide on date for next session: 5 minutes
2. Decide on a Topic for next session: Just TDD (0 minutes)
3. Coding Dojo and TDD introduction: 15 minutes
4. Code! PreparedKata by Lorenzo Solano (Roman Numerals): 30 minutes
5. Pick a / some Kata(s) for this session: 10 minutes
6. Code! RandoriKata: 45 minutes
7. Mid-session break to discuss how things are going: 10 minutes
8. Code some more: 45 minutes
9. Retrospective. What went well? What was interesting? What was frustrating?: 20 minutes

---

This section will be filled after the event.

VI  -Next event URL: http://goo.gl/2iOTD

VII -Next event date: Tue Oct 30

VIII-Actual attendees: 11

IX  -Actual duration: 3:00 hrs.

X   -Worked Katas:
Roman Numerals (prepared), and Word-wrapping (randori).

XI  -Retrospective 

What was frustrating?

• Low focus on the problem at hand, participants were talking during the hole meeting about other topics.
• Too much noise.
• Some of the attendees were not on time.
• Some people think that we need more "real" problems. By real they mean problems more like the ones we faced every day at work. Also they mention less-algorithmic problems.
• Definitely, we need and external keyboard and mouse.
• Allocate enough time for each problem, so we don't have stop and unfinished solution. 
• Plan to have a meal.

What went well?

• In general this meeting was, by far, more organized than the previous one.
• We cover all points in the agenda.

What was interesting?

• Was interesting to new ones.
• We have knowledge sharing.

Next meeting agreements:

• We'll have a Kake format.

XII -Action Points

• In the future, we won't put more than one meeting format for a dojo session, to ensure that we have the time needed to work on problems.
• For the next meeting, we need to define an "expert" on each programming language to be used on the Kake meeting. 

Coding Dojo @DR 001

Below you'll find all details of the first Coding Dojo @DR meeting. Please comment on this post with your opinion or concern on any topic. If you haven't read this post, please read it to gain a better understanding about this event.

I  -Event URL:  Kodisto Dojo @Google+

II -Katas Pool

We must select (see point 5 of Agenda), one or more Katas to practice on each Dojo session. The following list is an extract of some easy Katas, please review each one to be informed when making your decision. You'll find more Katas at this blog Code Kata's Page.

• Repeat Separator
• KataWordWrap
• Number Persistence[Multiplicative]
• Test data
• Kata Diphthong and Hiatus

III-Expected attendees: 21

IV -Expected duration: 3:25 hrs. (3 hours and 25 minutes)

V  -Agenda

1. Decide on date for next session: 5 minutes
2. Decide on a Topic for next session: Just TDD (0 minutes)
3. Coding Dojo and TDD introduction: 20 minutes
4. Code! PreparedKata by Rafael George (String Calculator): 30 minutes
5. Pick a / some Kata(s) for this session: 10 minutes
6. Code! RandoriKata: 40 minutes
7. Mid-session break to discuss how things are going: 10 minutes
8. Code some more: 70 minutes
9. Retrospective. What went well? What was interesting? What was frustrating?: 20 minutes

---

This section will be filled after the event.

VI  -Next event URL: http://goo.gl/vQ5Xk

VII -Next event date: Thu Oct 18 2012

VIII-Actual attendees: 11 (from 22 confirmed; No-Show 11)

IX  -Actual duration: 4:00

X   -Worked Katas:
Just String Calculator, see retrospective to know why.

XI  -Retrospective (If I forgot something, please comment to let the point registered)

What was frustrating?

• Use a moderator: Discussions took to long, and some of then were pointless. Also we try to talk all at the same time.  
• Respect the Prepared Kata format: We should be listening and looking at the techniques (TDD) presented with the prepared and respect the point of view of the person doing it. If someone does not understand a given step, the expositor must explain it; but that does not imply that both, the expositor and the attendee, must agree on the actual decision. The requirement is "not to move forward if someone does not understand the last step".
• Respect the Agenda: no one respected the agenda, we end-up by working just on one point of it.
• Respect the meeting schedule: only 4 (of 11 participants) arrived at the expected time.

What went well?

• Everyone stick to the usage of the technique (TDD) moving the focus away from resolving the actual programming challenge. 
• We cover all Test Scenarios of the problem.
• We add more Test Scenarios to the solution.

What was interesting?

• When is OK to stop the Refactoring step (of Red-Green-Refactor / RGR cycle)? or Is OK to do Early Refactoring?
• It's OK to put a little of "sugar" on the syntax of the produced code (by using more readable names or by encapsulating standard's API calls with private methods), in order to increase the legibility of the code?
• Those in favor defend the legibility to decrease the maintenance cost, and to increase the  code understanding.
• Those against say that the average developer must understand the code. And also that if we add too many methods we'll end-up with a large call-stack, making it harder when debugging.
• It's OK, or not, to do early optimizations?
• When to add more test scenarios? 
• Most attendees agreed that we must complete the original requirements first, and then add more scenarios to shield our code. 

Next meeting agreements:

1. Next meeting subject: TDD
2. Next meeting language: Java
3. Next meeting format: Randori
4. Place: <TBD>. Go to the Google's Event for more details.
5. Other programming languages options: C#, Ruby, and Python. Withing the attendees were at least one person with enough experience using each language.

XII -Action Points

1. Modify the next agenda to include an introduction to the Technique to be used (TDD, BDD, etc...)
2. Modify the next agenda to include an explanation of the type of meeting we'll have.
3. Include an early step to read the agenda to participants so everyone is on the same page and  respect it.
4. Upload the code of the Kata to a public location (github, bitbucket or similar), so everyone can review it.
5. Test the video recording software before starting with the Kata to ensure it's working as expected.

Kata Diphthong and Hiatus

Advice for all Katas: 

• Try not to read ahead.
• Do one task at a time (the trick is to learn to work incrementally).
• Always use TDD if the Kata is suitable for.

Diphthong and Hiatus

For this Kata try different approaches:  regular expressions, word position traversing, brute force (dictionaries and alike), etc.

Base data and Definitions

Please note that all rules and definitions conform to the Spanish language's rules for Diphthongs and Hiatuses.

This is the classification of vowels in Spanish:

• Strong (open): a, e, o
• Weak (close): i, u

The following files contain a listing of words containing different types of Diphthongs and Hiatuses:

1. Unclassified Diphthongs
2. Falling Diphthongs
3. Raising Diphthongs
4. Hiatuses

The above files will be referred from DF-1 to DF-4 (Data File One to Data File Four).

---

A Diphthong: Refers to two adjacent vowel sounds occurring within the same syllable. 

E1: Create a DiphthongFinder class with a method boolean analyseWord(string word); use the DF-1 to test your code. If you pass the word "caotico" and "aurora" it must output true.

Diphthong classes: 

• Two different vowels of the same type (refer to this type as homogeneous)
• One weak (close) vowel and one open (strong) vowel (refer to this type as heterogeneous)
• Falling: Strong first Weak second
• Raising: Weak first Strong second

E2: Modify your code to distinguish between Homogeneous and Heterogeneous diphthongs; extract words from DF-1, DF-2, and DF-3 to conform your test cases. If you pass the words "triunfo" and "coagular" it must output Homogeneous. If you pass the word "hielo"  it must output Heterogeneous.

E3: Modify your code to distinguish between Heterogeneous diphthongs (Falling and Raising); extract words from DF-1, DF-2, and DF-3 to conform your test cases. If you pass the word "harapiento" it must output Raising. If you pass the word "país" it must output Falling.

---

Extended Definition and the Acute Accent ( ´ )

A Diphthong: Refers to two adjacent vowel sounds occurring within the same syllable, one vowel must be weak (close), no matter their order; if and only if, the weak (close) does not have the acute accent ( ´ ). 

An Homogeneous Diphthong must be composed only of weak (close) vowels.

E4: Now the DiphthongFinder.analyseWord(string word) must indicate that the word "caotico" is not a Diphthong (because 'a' and 'o' are both Strong or Open).  The word "aurora" is a truly Diphthong but not and Homogeneous one. The word "triunfo" is an Homogeneous Diphthong because it has two weak vowels. 

E5: Now if you pass the word "país" instead of returning Falling, it must indicates that this word is not a Diphthong because the weak vowel (i) has the acute (í), becoming a strong one; so we have two strong vowels.

Hiatus: Any word containing two consecutive vowels, but that can't be considered a Diphthong is an Hiatus. In other words: any word with two consecutive strong vowels, or an strong vowel with a weak one with an acute accent is an Hiatus. According to the RAE (Real Academia Española), two adjacent strong vowels do not conform a Diphthong as they are part of two different syllable.

E6: Extend your code to also identify Hiatuses. Pick words from DF-4 to add more tests.

---

Do you want some more?

Consider the following observations, later change your code to support the new specifications:

• As the "h" in-between vowels does not produce sound, it does not block Diphthongs formation. The word "ahilar" is an example.
• In Spanish, the "y" at the end of a word has the same sound as the "i", so it can conform Diphthongs. The words "hoy" and "muy" are two examples. However  the "y" at the beginning or middle of a word remains as a consonant and can't conform a Diphthong.
• An Hiatus Simple is one formed of two different strong vowels.
• An Accentual Hiatus is one formed of one strong vowel and one weak, but accented, one.

Coding Dojo @DR, Gathering

"Raising The Bar"

If you reach this post without any prior knowledge about Coding Dojos, please refer to this entry; then come back here.

Proposal

Short and sweet:
     To start a series of Coding Dojos here in DR.

Please note the word series, I'm not talking about a one time event. I'm taking of a recurrent event (or events) for us to practice our craft, to learn from others, to teach others, to have a playground where we can try new things or concepts. In summary, to Raise The Bar.

My proposal is to have a Coding Dojo event every two (2) month, the first weekend of the corresponding month; specifically on Saturday Morning. If this gathering gets enough attention, then we could start on Sat Oct 06, 2012. As the maximum expected duration for any coding dojo session is of about 3 hrs., my suggestion is to start at 9:30 am, that way if we reach the three hours limit we'll be ending by 12:30 p.m.

Types of Katas for each meeting

As RandoriKatas are more "fun" and collaborative than PreparedKatas, I propouse to have a cycle of 1 PreparedKata every 2 RandoriKatas: Randori - Randori - Prepared - Randori - Randori - ...; but this is just a suggestion.

What we need?

First and more important, we'll need people. Coding Dojo, and all Agile practices characterize for being a collaborative effort. So we need you to join and participate. If you are interested, add a comment to this post, or send me an email. If you are offering one or more of the necessary resources (see next paragraph), please indicate that too.

Second, we'll need resources: some PCs / laptops, a digital projector, a meeting room. Its very easy to find some, 2 or 3, decent computers; the projector is a similar effort, but the showstopper here is the meeting room. We need a room with enough space for 8 to 10 people, with an air conditioner or a good ventilation system. So anyone with the means to get one please add a comment with the details. Finally, a must for that place is to have an UPS or backup generator.

Why?

As the Manifesto for Software Craftsmanship states, Software Craftsmen (us), must come to value:

Not only working software,
     but also well-crafted software

Not only responding to change,
     but also steadily adding value

Not only individuals and interactions,
     but also a community of professionals

Not only customer collaboration,
     but also productive partnerships

But what is the meaning of each practice? Lets review each one...

Well-crafted software

• It is the same as Compact, Elegant and Clean Code
• It requires the usage of Design Patters
• It has Comprehensive Automated Tests

Steadily adding value

• We must achieve an Emergent Design
• We must, continuously, Refactor our code
• We must have a Comprehensive Automated Test suite, and more important we must Respect it

A community of professionals

• We must learn from each other
• We must teach to each other
• We must have respect and trust

Productive partnerships

• We and our clients must have trust, understanding and mutual goals
• We must enhance the communication process with executable specifications

So, this is a call for you to take the responsibility of your craftsmanship and start practicing all required skills.