Sunday, September 30, 2012

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:
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-1DF-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.

Thursday, September 27, 2012

Phrase of the Software Craftsman 001

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
-Martin Fowler (Refactoring)

Tuesday, September 11, 2012

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.

        Monday, September 10, 2012

        What is Coding Dojo


        This is just a quick reference of what is a Coding Dojo; to go deeper please refer to this source.

        Definition

        A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there have fun and to engage in Deliberate Practice in order to improve their skills.

        Premises


        • Acquiring coding skills should be a continuous process

        Characteristics


        • Non-competitive, collaborative, fun environment
        • All skill levels are welcome
        • Safe to try new ideas

        Requirements


        • Meeting room with enough seats (typical attendance varies between 5 and 20 ?)
        • At least one PC or laptop
        • A digital projector ('beamer')

        Total event duration

        From 2hrs 30mins to 3hrs.

        Who started the movement? 

        Dave Thomas, here you have two valuable resources:


        Sunday, September 9, 2012

        Bad Communication Habits (2 / 3)

        2. Inverted channels priorities

        Background

        I've seen many teammates taking to each other using an inverted priority for the following channels:
        • Phone
        • [Direct] Conversation
        • Emails or other text-based channels
        Any time a person is involved within a negotiation (requirements, specifications, bugs reports, ...); that person will prefer to talk all others involved with the most formal channel in order to protect herself and document all agreements.

        So they, try to send all details first in a written form (email or similar); if that does not help they try with a phone call, usually a conference call for others to listen and be witnesses. Finally, if that does not help; they try with a direct conversation or meeting.
        image/svg+xml email phone conversation

        This approach is not effective for two things
        1. The main focus, the intention behind, is to cover all possible future problems resulting from misunderstandings. The intention is to have (collect), evidences for future blame.
        2. We always get better results, in terms of time and quality, with personal interactions than with any other communication channel.

        Managing this problem

        To manage this problem, we can use some practices:
        • Always honor your promises: if you talk, face to face, with anyone and agree upon something; but later you do not honor your word that person won't trust you in the future. This situation will lead your teammates to collect evidences any time they need your help with something; so they can blame your later when you fail.
        • Prefer, always, the inverse order (conversation, phone, email): if possible try to start any interaction first in person; then by phone and using emails if no other channels were available. If you constantly do this your teammates will start to change their style (at least when interacting with you). Remember to observe the first practice.
        • Structure your interactions: if you start requesting to everybody that they should meet with you personally, some people can argue that you are just too far away and that they prefer to call or email you. Also, they can argue that this approach consumes too much time. The answer to these reactions is to schedule your interactions. If you constantly receive request for changes, manage to have a meeting every X day of your release cycle.

        If you can follow these 3 practices, you'll have better agreements; you'll increase the confidence of your teammates (about you); and finally, you'll invest less time in interactions that do not lead to an easy understanding.

        Today's mood I


        Random thoughts, resources and information that I think are useful in one way or another ...


        Story of Stuff

        EN (Original) http://youtu.be/9GorqroigqM
        ES http://youtu.be/mUMESPBJlQo


        Story of [Bottled] Water

        EN (Original) http://youtu.be/Se12y9hSOM0
        ES http://youtu.be/9ICFp-7RgS4


        Where Good Ideas Come From

        EN (Original) http://youtu.be/NugRZGDbPFU
        EN (ES subs) http://youtu.be/o_QTFPdnrjY




        Born to Learn

        EN (Original) http://youtu.be/falHoOEUFz0
        ES http://youtu.be/I8hKSzv_rRw



        Monday, September 3, 2012

        Effective Practices for Applying Agile: Key points


        Almost two months ago (July 2012), the GAO published a report called: "Effective Practices and Federal Challenges in Applying Agile Methods". Where they list 32 Agile Adoption best practices identified by evaluating the agile implementation on several organizations. In this post I want to highlight several Key-Points found within the report. 

        Motivation

        Why GAO Did This Study
        Federal agencies depend on IT to support their missions and spent at least $76 billion on IT in fiscal year 2011. However, long-standing congressional interest has contributed to the identification of numerous examples of lengthy IT projects that incurred cost overruns and schedule delays while contributing little to mission-related outcomes. To reduce the risk of such problems, the Office of Management and Budget (OMB) recommends modular software delivery consistent with an approach known as Agile, which calls for producing software in small, short increments. Recently, several agencies have applied Agile practices to their software projects.  

        Recommendations

        Because your time is valuable, here you have the GAO's recommendations, after that I'll talk about some key points to be noticed on this report.
        What GAO Recommends
        GAO is recommending that the Federal CIO Council, working with its chair, OMB’s Deputy Director for Management, include practices such as those discussed in this report in the Council’s ongoing effort to promote modular development.

        Modular [Software] Development equals Agile Software Development within this context.


        10 key practices, found in all (5) federal agencies evaluated


        1. Start with Agile guidance and an Agile adoption strategy.
        2. Enhance migration to Agile concepts using Agile terms, such as user stories (used to convey requirements), and Agile examples, such as demonstrating how to write a user story.
        3. Continuously improve Agile adoption at both the project level and organization level.
        4. Seek to identify and address impediments at the organization and project levels.
        5. Obtain stakeholder/customer feedback frequently.
        6. Empower small, cross-functional teams.
        7. Include requirements related to security and progress monitoring in your queue of unfinished work (the backlog).
        8. Gain trust by demonstrating value at the end of each iteration.
        9. Track progress using tools and metrics.
        10. Track progress daily and visibly.

        Sprint (Iterations) expectations: 90 to 120 days

        A common release cycle, for Agile projects, is a Quarterly one (every 4 month). The OMB's expectations are between 90 (approx. 3 months) to  120 days (approx. 4 months). The actual Agile practices can fit this recommendations without much effort.
        For example, the Office of Management and Budget (OMB) recently issued guidance that advocates the use of shorter delivery time frames, an approach consistent with Agile. ... Specifically, OMB’s June 2010 memo on IT financial system reforms and the December 2010 IT management reform plan 5 encourage modular development with usable functionality delivered in 90 to 120 days.

        Agile approaches used (see Appendix IV: Federal Project Profiles)

        • 4 of 5: Scrum
        • 1 of 5: Iterative with some Agile practices

        Costs (see Appendix IV: Federal Project Profiles)

        This cost profile is based on the 5 projects evaluated by GAO, values are expressed in millions of US dollars (USD$)
        • Minimum:      6.60
        • Average:      82.18
        • Maximum: 192.30
        So, next time someone asks Can Agile be used on large projects?, you can say with no doubt Yes!

        Not an easy road (see Federal Challenges in Applying Agile)...

        14 challenges were identified while performing this report, below is the complete list organized in four topics: Organizational Commitment and Collaboration, Preparation, Execution, and Evaluation. To expand each topic please refer to the GAO's report.
        Organizational Commitment and Collaboration 
        1. Teams had difficulty collaborating closely
        2. Teams had difficulty transitioning to self-directed work
        3. Staff had difficulty committing to more timely and frequent input
        4. Agencies had trouble committing staff  
        Preparation
        1. Timely adoption of new tools was difficult
        2. Technical environments were difficult to establish and maintain
        3. Agile guidance was not clear
        4. Procurement practices may not support Agile projects  
        Execution
        1. Customers did not trust iterative solutions
        2. Teams had difficulty managing iterative requirements
        3. Compliance reviews were difficult to execute within an iteration time frame 
        Evaluation
        1. Federal reporting practices do not align with Agile
        2. Traditional artifact reviews do not align with Agile
        3. Traditional status tracking does not align with Agile 


        The full 32 practices list

        Please find the full list in the first entry of this series: 

        Effective Practices for Applying Agile, from the GAO's report 12-681


        Here is a list of 32 practices and approaches identified as effective for applying Agile to software development projects. This list is based on an analysis of practices identified by experienced Agile users. The analysis, and resulting report, is product of the U.S. Government Accountability Office (GAO), the report can be found here "Effective Practices and Federal Challenges in Applying Agile Methods".

        The second entry of this series contains several key point extracted from the GAO's report.

        The list of 32 practices 

        I. Strategic Planning


        1. Strive to be more Agile, rather than simply following Agile methods and steps. This approach encourages adoption of the philosophy, or mindset, rather than specific steps. This is also referred to as being Agile, or having agility versus using it.
        2. Allow for a gradual migration to Agile appropriate to your readiness. Migration steps might include combining Agile and existing methods, conducting pilots, and preparing technical infrastructure.
        3. Observe and communicate with other organizations implementing Agile. For example, those starting to use Agile can consult with others who have more experience, including academic, private sector, and federal practitioners.
        4. Follow organizational change disciplines, such as establishing a sense of urgency and developing a change vision. A clear vision of change helps staff understand what the organization is trying to achieve. Another organizational change discipline is communication strategies.
        5. Be prepared for difficulties, regression, and negative attitudes. This approach reinforces that Agile is not painless and users may backslide to entrenched software methods.
        6. Start with Agile guidance and an Agile adoption strategy. This practice advocates having these elements in place at the start, even if they must be copied from external sources.


        II. Organizational Commitment and Collaboration


        1. Ensure all components involved in Agile projects are committed to the organization’s Agile approach. This practice encourages organizations to ensure that everyone contributing to a project understands and commits to the organization’s approach. This includes those working directly on the project and those with less direct involvement, such as those providing oversight.
        2. Identify an Agile champion within senior management. This practice calls for someone with formal authority within the organization to advocate the approach and resolve impediments at this level.
        3. Ensure all teams include coaches or staff with Agile experience. This practice stresses the importance of including on each team those with direct experience in applying Agile. While training is helpful, hands on experience helps the team members learn and adjust.
        4. Empower small, cross-functional teams. Empowered teams of 7 to 18 people decide what to deliver and how to produce it. The teams should not over-rely on one member’s skills.

        III. Preparation


        1. Train the entire organization in your Agile approach and mindset, and train Agile practitioners in your Agile methods. For example, managers must understand the approach so that they know how it will affect them and teams need to know the specific steps of an iteration to conduct it properly.
        2. Ensure that subject matter experts and business team members have the required knowledge. This practice stresses that staff involved in fast-paced iterations must truly be experts in the  processes being automated in that iteration in order to reduce delays. For example, a team member representing financial customers must be fully familiar with the needs of those customers.
        3. Enhance migration to Agile concepts using Agile terms and examples. For example, use terms like user stories instead of requirements, and Agile Center of Excellence instead of Project Management Office. Provide examples, such as one illustrating the small scope of a user story to teams writing these stories.
        4. Create a physical environment conducive to collaboration. A common practice is to co-locate the team in a single room where they can continually interact. Other ways to enhance collaboration are to reorganize office space and use tools to connect remote staff.
        5. Identify measurable outcomes, not outputs, of what you want to achieve using Agile. An example of this practice is creating a vision statement of project outcomes (such as a decrease in processing time by a specific percent in a set time), rather than outputs (such as the amount of code produced).
        6. Negotiate to adjust oversight requirements to a more Agile approach. This practice notes that teams may be able to adjust oversight requirements by using frequent, tangible demonstrations to gain the trust of reviewers and investors, potentially reducing the need for more formal oversight documents.
        7. Ensure that the definition of how a story will be determined to be done is comprehensive and objective. Comprehensiveness includes defining what constitutes a finished product (i.e., packaged, documented, tested, and independently verified). Objective means measurable or verifiable versus subjective judgment.
        8. Make contracts flexible to accommodate your Agile approach. Contracts requiring waterfall-based artifacts and milestone reviews may not support the frequent changes and product demonstrations in iterations, and may inhibit adoption.

        IV. Execution


        1. Use the same duration for each iteration. An example would be establishing that iterations will be four weeks each within a release to establish a uniform pace.
        2. Combine Agile frameworks such as Scrum and XP if appropriate. Disciplines from different frameworks can be combined. For example, use project management disciplines from Scrum and technical practices from XP.
        3. Enhance early customer involvement and design using test-driven development. Test-driven development refers to writing software code to pass a test. This practice maintains that involving customers in these tests helps to engage them in the software development process.
        4. Include requirements related to security and progress monitoring in your queue of unfinished work (backlog). Including activities such as security reviews and status briefings in the backlog ensures their time and cost are reflected and that they are addressed concurrent with, and not after, iteration delivery.
        5. Capture iteration defects in a tool such as a backlog. This practice calls for queuing issues so that they are resolved in later iterations. For example, lists of unmet requirements generated at end-of-iteration demonstrations should be queued in the backlog for correction in a future iteration.
        6. Expedite delivery using automated tools. For example, tools can track software modifications, and compliant development sites or “sandboxes” help customers conceptualize the software in an environment that meets architectural and security standards.
        7. Test early and often throughout the life cycle. The theme of this practice is that testing during software code delivery instead of after delivery reduces risk and remediation costs.

        V. Evaluation


        1. Obtain stakeholder/customer feedback frequently and closely. For example, feedback is obtained during the iteration and at its completion at an iteration retrospective. This practice was linked to reducing risk, improving customer commitment, and improving technical staff motivation.
        2. Continuously improve Agile adoption at both the project level and organization level. This practice invokes the discipline of continuous improvement, meaning always looking for ways to improve. For example, improvements can be made by adding automated test and version control tools, and enhancing team rooms. These issues can be tracked in project and organizational-level backlogs.
        3. Seek to identify and address impediments at the organization and project levels. This practice encourages organizations to be frank about identifying impediments so that they can be addressed.
        4. Determine project value based on customer perception and return on investment. This practice recognizes that tracking progress only against cost or schedule criteria set before the project began could lead to inaccurate measurement of progress if, for example, major changes in scope occur. Instead, Agile encourages customer feedback as one measure of progress. Comparing solution value to the cost of the solution is also a gauge of success.
        5. Gain trust by demonstrating value at the end of each iteration. Progress can be tracked using tools and metrics such as burn-down charts and velocity, which can be automated, and by success indicators such as “customer delight,” and reduced staff stress and overtime.
        6. Track progress using tools and metrics. This practice includes demonstrating key requirements in early iterations, and showing customers that requirements in the backlog are delivered and not forgotten.
        7. Track progress daily and visibly. This practice stresses that status is checked daily and publicly. For example, a progress chart is posted openly in the team’s workspace, with timely revisions to reflect ongoing feedback.

        Subscribe to our mailing list

        * indicates required
        Email Format