This is the second in a series of discussions looking at factors that enable Agile teams to be successful. Diversity of gender, culture, opinion, perspective, skills and background is considered to be an important factor in forming and persisting high-performance teams. This news item examines the perspectives from variety of commentators.

Read more at InfoQ.com

Coucou les filles !

J’organise dans le cadre du Poitou-Charentes JUG une journée complète de conférences Java à La Rochelle : le Jug Summer Camp.

Le JUG Summer Camp 2010 se tient le vendredi 10 septembre à La Rochelle. Venez toutes profiter des derniers rayons de soleil de l’été pour une rencontre privilégiée avec les acteurs de la communauté Java dans un cadre magnifique.

Emmanuel Bernard, Alexis Moussine-Pouchkine, Julien Dubois, Nicolas de Loof, et bien d’autres ont répondu présent et vous proposent des présentations de haut niveau réparties sur deux tracks.

L’évènement est francophone, gratuit et ouvert à tous (et toutes ! ). N’hésitez pas à en parler autour de vous.

Le site de la conférence, à deux pas de la gare TGV, est un cadre confortable et convivial pour profiter de cette journée dans les meilleures conditions… et pourquoi pas la poursuivre par un week-end sur la côte Atlantique

Inscrivez-vous vite sur http://www.jugsummercamp.org/inscriptions

Plus d’informations sur http://www.jugsummercamp.org

Voilà !
J’espère que je pourrai croiser plusieurs d’entre vous là bas.

Bonne soirée à toutes,
Orianne.

The Zone—San Francisco’s Hotel Nikko, Hilton San Francisco, and Parc 55 hotels and the surrounding area—will be dedicated to developers during the week of JavaOne and Oracle Develop.

Unparalleled education and practical hands-on sessions, engaging activities, exceptional entertainment, and food and drink in the Zone will be exclusively geared toward the developer community converging at the two conferences. Network, share information, and learn from leading experts in the Java, PL/SQL, rich internet application development, SOA communities, and more.

Discount may have been arranged by your local JUG. Check with your local JUG.

Java2Days conference is premier event in Eastern Europe to present the latest trends in Java development in the following areas:

• Core Java Platform & Desktop
• Enterprise Java
• Java & the Cloud
• Java Web Technologies and Rich User Experience
• Java for Mobile and Devices

The second Java2Days will be held at the Inter Expo Center on 8-9 October, 2010, in Sofia, Bulgaria.

The conference is the first of its kind to be held in Eastern Europe, focused to highlight today’s cutting edge trends in building software applications with Java development tools.

Over two days, more than 600 attendees will meet world famous lecturers, engaged all year round in such events as JavaOne, The ServerSide Java Symposium, Jazoon showcasing their latest knowledge in creating more reliable, scalable and secure solutions using Java technologies in more than 20 technical sessions.

The major purpose of the event is to become a place for passionate Java developers to get in touch with the latest technologies, to become a significant part of the global Java community and to learn from the best.

For Duchess members, we have received a generous offer from the conference organizers: 10 free conference passes (Economy Pass) for each invited official Java User Group and 40% discount of every next pass.

If you want to go, get in touch.

XP Day Benelux is an international conference about Agile methods, intended for people from all walks of life who are involved with IT. It provides a good opportunity for exchanging ideas and sharing experiences and is suited for both experienced participants and beginners in Agile methods. The focus of this conference is on practical knowledge, real-world experience, and active participation of everyone.

The 8th edition XP Days will also be held in Kapellerput in Heeze, near Eindhoven.

Call for Sessions is now open (until July 15)

We’ve applied for a Duchess BOF at Devoxx 2010. Come join us so we can meet each other and find out what has been going on in the Duchess community and how you can get involved.

Join us at the Duchess BOF where we can meet each other and find out what has been going on in the Duchess community and how you can get involved.

Yesterday, I attended a lean architecture seminar given by Xebia. Gerard Janssen, Gero Vermaas, Sander van den Berg, and Denis Koelewijn did a good job in putting together the seminar and taking us through an introduction of Lean Principles and then applied to architecture to become Lean Architecture Prinicples. During the seminar, we discussed architectural challenges and also learned how architecture was done at Bol.com as presented by Serge Beaumont. I left the session re-inspired on how to approach architecture improvements at my current place of work.

Architecture
The 3 C’s of Architecture was introduced: Connection, Cohesion, and Changeability.
You can read about the 3 C’s of Architecture here: http://blog.xebia.com/2010/04/23/the-three-cs-of-architecture/
But here’s my spin:
On first glance, it is not really obvious what is meant by connection. What is meant is: connection to organizational goals. Architecture should be aligned to organizational and business goals and add value by facilitating the achievement of these goals.
Another word for Cohesion is Consistency. I often look for consistency in architecture, software, documents, etc. Consistency is standardization that pays off because it reduces the effort in understanding the architecture, software, documents, thereby reducing time and costs when implementing further changes.
Modern wisdom says that we should architect for change, because “change is the only constant”. For me, the raison d’etre of architecture is to manage complexity thereby ensuring changeability and minimizing the cost of future changes. This is because by definition, software is complex, but the complexity can be managed.

Lean Principles
The Lean Principles that were introduced are:

1. Base management decisions on long term philosophy, even at the expense of short term financial goals
2. Create a continuous process flow to bring problems to the surface
3. Use “pull” systems to avoid overproduction
4. Build a culture of stopping to fix problems to get quality right the first time
5. Use visual control so no problems are hidden
6. Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others
7. Go and see for yourself to thoroughly understand the situation
8. Make decisions slowly by consensus thoroughly considering all options, and implement decisions rapidly
9. Become a learning organization through relentless reflection and continuous improvement

The above principles can be further distilled into 3 quick-win actions:

1. Make work visible
2. Limit work in progress
3. Make work flow

#1 is a quick-win that I have employed and continue to employ. For example, it’s amazing how a continuous integration tool can do to focus the team, and give a pulse on progress.
#2 and #3 are closely related. What we know is that flow is more important than resource optimization. Ensuring the flow by making sure that intermediate products do not pile up often result in faster delivery than if all resources continue to produce at 100% capacity despite the fact that the next person/team in line is not ready. This is counter-intuitive for traditional project management, which is still very prevalent in most large organizations, and it is up to us to teach the concept of flow and other lean principles.

Other resources on lean principles that I have found useful are:

• http://agilesoftwaredevelopment.com/leanprinciples
• http://www.leansoftwareinstitute.com/art_ilsd.php

Principles distill best practices into simple concepts that help us focus on what we need to do. Often, we all know the concepts, but the hard part is the implementation. By putting “abstract” lean principles into the context of architecture, it helps to visualize what needs to be done and brings us one step closer to applying the principles in our specific situations.

Lean Architecture Principles
“Lean Architecture enforces value creation by balancing business and technical values/priorities and converging focus of all stakeholders to required actions at the right time and at the right level of details.”

The Lean Architecture Principles that were introduced are:

1. Architecture initiated by business goals
2. Architecture emerging from projects
3. Incremental development of architecture
4. Focus on (business) value stream
5. Travel light
6. Just in time, just enough
7. Think big, act small
8. All hands on deck early on
9. Always involved
10. Comprehensible over comprehensiveness
11. Freedom where possible, standard where needed

Each principle is further elaborated in the Xebia blog here: http://blog.xebia.com/category/lean-architecture/

Architectural Challenges
Later, we broke into groups to discuss which Lean Architecture Principles can be applied to solve one of the architectural challenges that we came up with. We chose to discuss the challenge of determining how far we should look for architecture. 3 years? 5 years? 10 years?

My first comment is that it’s not about time. It’s about creating a vision and then creating a roadmap (Think big, act small) towards that vision. The time is only an estimate of how long it would take us to get to the vision, which is not really that relevant since architectural improvement should be a continuous process (Incremental development of architecture) and each step is measured for business value. Many of us work in organizations where there is a fair amount of legacy system. When designing from scratch, we know that we should design loosely coupled, flexible systems, but what do we do with systems that are already there? One solution is to create a backlog of architecture changes/refactorings and wait for the chance to include them into project backlogs when the time comes. The architecture backlog should be communicated widely so there will be no surprise.

An insight from Theo Maas of KLM is: “Architecture must mirror your business processes. Even when the organizational structure changes, the business processes often stay the same.”

I would go one step further to say that lean principles can be applied to the business processes themselves to eliminate waste.Companies that dare to improve their processes can benefit from reduced costs and increased productivity in their day-to-day operations. When this is done with business and IT in close collaboration, IT can add value by supporting the new (more efficient) processes.

Bol.com: Service Discovery Workshop
Serge Beaumont shared with us his experience at Bol.com, where he started to run Service Discovery Workshops with full participation from +/- 20 people from all departments and functions who got together to discuss architecture and initiate architectural changes (All hands on deck early on). The goal was to create an architecture that would keep them in business until 2013. I think it is brilliant that people at Bol.com have the foresight to make the effort early on and collaborate on architecture. A simple model was followed to structure the workshop:

1. Domain Objects – Identify and validate (throw out invalid/obsolete ones) domain objects. Identify partitions and cluster closely related stuff. Domain objects can be in one domain only – that helps to remove duplication.
2. Processes – Identify and validate processes.
3. Services – Identify the services needed to execute the processes.
4. Messages – Identify what the services require to do their work.

Conclusion
This seminar has inspired me to refocus my efforts on initiating architectural improvements at my current place of work. I’m glad to have had the opportunity to discuss with fellow architects the common challenges and solutions for initiating architectural changes in organizations. This has confirmed for me what I have known all along and have been doing for awhile, which is that architecture includes both content knowledge as well as process knowledge, and where success is contingent on the ability to initiate and lead changes in both. As with many good ideas, the concepts are simple, but the implementation is hard. I hope that doing my part to spread the word on what we know as a community will help others to improve architecture in their companies.

It’s been a year since I attended a bootcamp for Sun Certified Enterprise Architect and I noticed that I never published these study tips. The course went from fundamental architectural concepts to using current Java technology to design software.

I really liked learning the SunTone Architecture Methodology – specifically the SunTone cube, which helped me visualize and make connections to infrastructure. What I liked less is the focus on Java design patterns, some of which are outdated, and a focus on (although a little understandably) Sun technology. The problem is these days – knowing the Sun way of doing things (EJB3, JSF, etc) is not the only choice. There is definitely a gap there for a more comprehensive Java Architecture course that comprises of all mainstream Java technology and help make the choices between them. Overall, I found that it was a good opportunity to focus and learn for a week on architecture and design. I’m glad to find that UML is still relevant in the face of agile development, although people haven’t talked about it much in more than 10 years.

SunTone Architecture Methodology
To aid in the development of enterprise applications, Sun Java Center formulated the SunTone Architecture Methodology (SunTone AM) in the late 90’s. Enhancing RUP with the SunTone cube, it has now evolved to have more agile influences. SunTone AM introduced the SunTone cube to describe primary concerns in enterprise applications. The three faces on the cube represented layers, tiers, and systemic qualities.

Layers
Layers are usually in the domain of infrastructure architects, where the application sits on top of infrastructure components.

• Application – software
• Virtual Platform – interfaces to the middleware for decoupling
• Application Infrastructure – middleware
• Enterprise Services – OS
• Compute & Storage – hardware
• Network Infrastructure – network

Tiers
Tiers are well-known to application architects. They describe how an application is decomposed into modules to reduce coupling and enhance system flexibility. Annoyingly, tiers are sometimes called layers, when not in the context of SunTone.

• Client Tier – browsers, standalone clients
• Web Presentation Tier – HTTP requests
• Business Tier
• Integration Tier – interfaces with resources
• Resource Tier – DBMS, mainframe, EIS

Systemic Qualities
Systemic qualities help establish the quality of service that a system can deliver. Different systemic qualities impose different constraints on the design of a system. This list correlates to Non-Functional Requirements (NFR) that when prioritized help make choices in system design that take quality, time, and costs into consideration.

• Manifest Qualities
  • Performance
  • Reliability
  • Availability
  • Usability
• Operational Qualities
  • Throughput
  • Manageability
  • Security
  • Serviceability
  • Testability
• Developmental Qualities
  • Realizability
  • Planability
• Evolutionary Qualities
  • Scability
  • Maintainability
  • Extensibility
  • Flexibility

The Multiple Choice Exam
A lot of passing the exam has to do with learning the terminology.
The multiple choice exam tests knowledge from roughly 8 areas:

1. Application Design Concepts + Principles
   • encapsulation, inheritance, separation of concerns
2. Common Architectures
   • 2-tier, 3-tier, multi-tier, rich clients vs. browser/thin clients, web services
3. Integration + Messaging
   • communication w/ external systems, WS+XML over HTTP, JCA, JMS
4. Business Tier Technology
   • Enterprise Beans, Enterprise Classes, Stateful/Stateless Session Beans, Message Driven Beans
   • CMP/BMP, JDO, JPA, ORM, DAO, JDBC, JAX WS, EJB 3.0
5. Web Tier
   • Web Framework, JSPs, Servlets , JSF
6. Applicability of J2EE Technology
   • Designing modular solutions, SOA, measuring NFR, refactoring
7. Design Patterns
   • GoF Design Patterns
   • Core J2EE Design Patterns
8. Security
   • Client-side security: WebStart, applet deployment
   • potential threats
   • encryption, hash, SHA, asymmetric vs symmetric
   • JAAS

Resources

• SunTone Architecture Methodology
• The Java EE 5 Tutorial
• Gang of Four Design Patterns
• Core J2EE Design Patterns

Agile Open Holland is the conference by and for you! Organized by Agile Holland, it is an Open Space conference, where the program is made by the participants at the start of each conference day. You can propose discussions, workshops, simulations, games, coding dojos, whatever topics and formats you are passionate about and want to take responsibility for.

Since the conference is what you make it, you’ll come back to work re-energized, filled with fresh ideas to make your work more fun, more productive and more profitable.

Find out the details and register!

Coding Dojos are inspired by the Socratic Circle, a learning method that involves questions and debate between participants and teacher, illuminating different points of views.

Come learn and practice TDD (Test-Driven Development) with FitNesse, an acceptance testing framework that enables you to communicate progress with business and customers, while improving your programming skills.

You are welcomed to join us on Friday evening, June 18, in the Amsterdam Public Library (Openbaar Bibliotheek Amsterdam) – next to Amsterdam Central Station – for a coding dojo with a focus on TDD with FitNesse.

We are very happy to have Marc Evers from QWAN and Agile Holland lead us through this dojo.

We will start at the La Place upstairs (7th floor) for food at 18:00 and will move to the meeting room (6th floor) to start at 19:00 and go until 22:00 at the latest.

We ask a voluntary 10 Euro participation fee to cover expenses.
Please sign up each attendee individually so we can track attendance.

Space is limited to 20 participants – so first come first serve!

The Amsterdam Public Library is easily accessible by public transport or car.
For those who want to drive, Parkeergarage Oosterdok is the closest parking garage.

Introduction

At JavaPolis 2006 I met Eric Evans where he gave a university session about his book Domain-Driven Design. The session was very intriguing and so I bought the book on the spot. It seemed to promise to teach me a lot about how to go about the difficult task of extracting a model from a real-life situation. Of course that same real life prevented me from reading the book for several years. So now I have finally found the time to actually sit down and read it. And just like it promised all those years ago, it gives a lot of hints, tips and tools to extract a model from a domain. An absolute must-read for programmers and architects. And preferably also to be read by managers, so they will hear from an experienced architect that modelling shouldn’t be done by ivory tower architects.

Part I: Putting the Domain Model to Work

This part of the book presents the basic goals of domain-driven development, it defines the terms used throughout the book and it gives an overview of the implications of using the domain model to drive communication and design.

Chapter 1: Crunching Knowledge

In order to get to a workable domain model which can be used to successfully build useful software, there are five necessary ingredients: binding the model and the implementation, cultivating a language based on the model, developing a knowledge-rich model, distilling the model into a deep model, and brainstorming and experimenting. These taken together can be labeled as knowledge crunching.

Chapter 2: Communication and the Use of Language

A domain model can and should be the core of a common language for a software project, the so-called ubiquitous language. The model is a set of concepts built up in the heads of people on the project, with terms and relationships that reflect domain insight. These terms and interrelationships provide the semantics of a language that is tailored to the domain while being precise enough for technical development.

Chapter 3: Binding Model and Implementation

If the model can not or simply is not be used for implementation, then a lot of knowledge the analysts had is lost. Therefore the model and implementations should be tightly bound together (Model Driven Design). If the people who write the code don’t feel responsible for the model, or don’t understand how to make the model work for an application, then the model has nothing to do with the software. Meanwhile, when a modeler is separated from the implementation process, he never acquires, or quickly loses, a feel for the constraints of the implementation. Therefore any technical person contributing to the model must spend some time touching the code and every developer must be involved in some level of discussion about the model and have contact with domain experts (Hands-On Modellers).

Part II: The Building Blocks of a Model-Driven Design

This part of the book condenses a core of best practices in object-oriented domain modeling into a set of basic building blocks. It focuses on bridging the gap between models and practical, running software. But the main point of this section is to focus on the kinds of decisions that keep the model and implementation aligned with each other.

Chapter 4: Isolating the Domain

The part of the software that specifically solves problems from the domain usually constitutes only a small portion of the software system, although its importance is disproportionate to its size. We need to decouple the domain objects from other functions of the system, so we can avoid confusing the domain concepts wit hother concepts related only to software technology or losing sight of the domain altogether in the mass of the system. One approach is to use a layered architecture.

Chapter 5: A Model Expressed in Software

This chapter focusses on the individual model elements, such as associations, entities, value objects and services. Finally a discussion of modules will drive home the point that every design decision should be motivated by some insight into the domain. The ideas of high cohesion and low coupling can be applied to the concepts themselves. In a model-driven design, modules are part o the model, and they should reflect concepts in the domain.

Chapter 6: The Life Cycle of a Domain Object

Every object has a life cycle. Many of these are simple, transient objects. But other objects have longer life, not all of which are spent in active memory. Managing these objects presents challenges that can easily derail an attempt at model-driven design. This chapter will address these issues through three patterns. First, aggregates tighten up the model itself by defining clear ownership and boundaries, avoiding a chaotic, tangled web of objects. Next the focus turns to the beginning of the life cycle, using factories to create and reconstitute complex objects and aggregates, keeping their internal structure encapsulated. Finally, repositories address the middle and end of the life cycle, providing the means of finding and retrieving persistant objects while encapsulating the immense infrastructure involved.

Chapter 7: Using the Language: An Extended Example

The preceding three chapters introduced a pattern language for honing the fine detail of a model and maintaining a tight model-driven desing. This chapter presents an elaborate example showing the forces that apply and how the patterns of part II can resolve them.

Part III: Refactoring Toward Deeper Insight

This part of the book is about the challenge of assembling the building blocks into practical models that provide the payoff. It delves into modeling principles that can guide choices along the way to gaining deeper insight, and techniques that help direct the search.

Chapter 8: Breakthrough

The return from refactoring are not linear. Usually there is a marginal return for a small effort, and the small improvements add up. But some of the most important insights come abruptly and send a shock through the project. This chapter tells the story of one project and how they arrived at a very valuable deep model.

Chapter 9: Making Implicit Concepts Explicit

Many transformations of domain models and the corresponding code happen when developers recognize a concept that has been hinted at in discussion or present implicitly in the design, and they represent it explicitly in the model with one or more objects or relationships. Most such discoveries come from listening to the language of the team, scrutinizing awkwardness in the design and seeming contradictions in the statements of experts, mining the literature of the domain, and doing lots and lots of experimentation. Three ways of modeling less obvious kinds of concepts are explicit constraints, processes as domain objects and specifications

Chapter 10: Supple Designs

The ultimate purpose of software is to serve users. But first, that same software has to serve developers. When software with complex behavior lacks a good design, it becomes hard to refactor or combine elements. To have a project accelerate as development proceeds – rather than get weighed down by its own legacy – demands a design that is a pleasure to work with, inviting to change. A supple design. In order to get to a supple design you can use several patterns: intention-revealing interfaces, side-effect-free functions, assertions, conceptual contours, standalone classes, and closure of operations

Chapter 11: Applying Analysis Patterns

Deep models and supple designs don’t come easily. Sometimes we can get a leg up from other people’s experience when they have recorded that experience in the shape of an anlysis pattern. It hardly ever is the answer to your particular needs, yet it offers valuable leads in your investigation, and it provides cleanly abstracted vocabulary.

Chapter 12: Relating Design Patterns to the Model

Most of the patterns published to date are more technical in focus than the patterns explained in the book so far. Some, not all, of these can be used as domain patterns. Doing so requires a shift in emphasis. A discussion on the composite and strategy patterns demonstrates how some of the classis patterns can be applied to domain problems by thinking about them in a different way.

Chapter 13: Refactoring Toward Deeper Insight

Refactoring toward deeper insight is a multifaceted process. It will be helpful to stop for a moment to pull together the major points. There are three things you have to focus on: live in the domain, keep looking at things a different way, and maintain an unbroken dialog with domain experts.

Part IV: Strategic Design

This part deals with situations that arise in complex systems, larger organizations, and interactions with external systems and legacy systems. This section explores a triad of principles that apply to the system as a whole: context, distillation, and large-scale structure.

Chapter 14: Maintaining Model Integrity

The most fundamental requirement of a model is that it be internally consistent; that its terms always have the same meaning, and that it contain no contradictory rules. Total unification of the domain model for a large system will not be feasible or cost-effective. This chapter lays out techniques for recognizing, communicating, and choosing the limits of a model and its relationships to others. It all starts wit hmapping the current terrain of the project. A bounded context defines the range of applicability of each model, while a context map gives a global view of the project’s contexts and the relationships between them. This reduction of ambiguity will, in and of itself, change the way things happen on the project, but it isn’t necessarily enough. Once we have a context bounded, a process of continuous integration will keep the model unified. Then, starting from this stable situation, we can start to migrate toward more effective strategies for bounding contexts and relating them, ranging from closely allied context with shared kernels to loosely coupled models that go their separate ways.

Chapter 15: Distillation

How do you focus on your central problem and keep from drowning in a sea of side issues? Distillation is the proces of separating the components of a mixture to extract the essence in a form that makes it more valuable and useful. A model is a distillation of knowledge. As with many chemical distillations, the separated by-products are themselves made more valuable by the distillation process (as generic subdomains and coherent mechanims), but the effort is motivated by the desire to extract that one particularly valuable part, the core domain. Strategic distillation does all of the following: aids all members in grasping the overall design of the system and how it all fits together; facilitates communication by identifying a core model of manageable size to enter the ubiquitous language; guides refactoring; focuses work on areas of the model with the most value; and guides outsourcing, use of off-the-shelf components, and decisions about assignments. Most of the distillation patterns in this chapter show how to change the model and distill the core domain. However, domain vision statement and highlighted core show how the use op supplemental documents can, with a very minor investment, improve communication and awareness of the core and focus development effort.

Chapter 16: Large-Scale Structure

Even with a modular breakdown, a large model can be too complicated to grasp. A “large-scale structure” is a language that lets you discuss and understand the system in broad strokes. Large-scale structure can save a project, but an ill-fitting structure can severely hinder development. This chapter explores patterns for successfully structuring a design at this level, like evolving order, system metaphor, responsibility layers, knowledge level, and pluggable component framework.

Chapter 17: Bringing the Strategy Together

The preceding three chapters presented many principles and techniques for domain-driven strategic design. In a large, complex system, you may need to bring several of them to bear on the same design. The three basic principles of strategic design (context, distillation, and large-scale structure) are not substitutes for each other; they are complementary and interact in many ways. When you are tackling strategic design on a project, you need to start from a clear assessment of the current situation. This can be accomplished by the following steps: draw a context map, attend to the use of language on the project, understand what is important, find out if the technology of the project work for or against a model-driven design, find out if the developers on the team have the necessary technical skills, and find out if the developers are knowledgeable and interested in the domain. Another important question is about who sets the strategy. Traditional handing down of architecture doesn’t usually work well. Strategic design, by definition, must apply across the project. Six essentials for making strategic design decision making work are: decisions must reach the entire team, the decision process must absorb feedback, the plan must allow for evolution, architecture teams must not siphon off all the best and brightest, strategic design requires minimalism and humility, and finally objects are specialists; developers are generalists.

Conclusion

Looking back on some projects described in the book and where they went after the involvement of the author ended, it can be concluded that wrestling a complex domain into a comprehensible software design is an exciting challenge for strong technical people. What is needed are tools that allow sharper ways of exploring domain models and expressing them in working software. But though improved tools will be valuable, we mustn’t get distracted by them and lose sight of the core fact that creating good software is a learning and thinking activity. Efforts to automate what must be the product of thought are naive and counterproductive. With the tools and technology we already have, we can build systems much more valuable than most project do today.

Officiellement lancé au dernier ParisJug, le JDuchess débarque en France ! Mené par Ellene Dijoux (Xebia),  Claude Falguière (Valtech), Mathilde Lemée (freelance) et Laure Némée (Leetchi.com), le JDuchess France compte déjà 16 membres. Cela vous semble peu bien sûr au regard de l’énorme communauté de développeurs java, mais c’est un début prometteur.

Fondé par Clara Ko en Hollande, le JDuchess a pour but de permettre aux femmes du monde Java de se connaître et de se rencontrer, afin d’échanger points de vue techniques et retours d’expériences. Il est de fait important pour les développeuses junior comme moi, ou à venir, de voir que des femmes nous ont précédées dans la technique et s’y sont épanouies.

En effet le constat dressé par les Duchess est le suivant : vers ce qui correspond au milieu de la carrière « classique » d’un développeur, les femmes disparaissent du monde technique. Souvent pour s’orienter vers la qualité, la maîtrise d’ouvrage etc … Alors bien sûr, tout cela donne envie de mener l’enquête.

Pas toujours facile non plus de trouver le courage de se rendre à certains événements de la communauté, tels que Jugs, Bar Camp et CodingDojo. L’envie est là mais la liste des participants ou les photos des précédentes sessions où l’on ne voit que des messieurs intimident quelque peu … et à tort, puisque nous nous apercevons vite que nous sommes les bienvenues !

D’où  la nécessité de se constituer en réseau social, de pouvoir se tenir informées des réunions, conférences et événements à venir, se donner rendez vous et ainsi encourager certaines femmes qui peut être n’osaient pas se montrer à nous rejoindre afin de participer bien sûr, mais aussi pourquoi pas, d’animer ces événements !

Pour nous rejoindre ou suivre notre actualité, vous pourrez nous retrouver sur Twitter, sur le groupe LinkedIn ou encore sur le site jduchess.org. Et surtout n’oubliez pas d’en parler à vos collègues !

It’s back!
Google Code Jam (powered by Google App Engine) is an annual programming competition in which thousands of coders around the world attack algorithmic problems in several 2.5-hour online rounds. If you make it through the first four rounds, you’ll be flown to on-site finals at our EMEA Headquarters in Dublin, Ireland! Once there, you’ll compete with 24 other top coders for the $5000 first prize…and the coveted title of ‘Code Jam Champion’!

Registration opens on April 7th and closes on May 8th 2010 at 23:00 UTC.

Important dates: http://code.google.com/codejam/schedule.html
Contest info: http://code.google.com/codejam
Rules and Terms: http://code.google.com/codejam/rules.html

Please spread the word!  We hope to see you and your friends in Dublin, Ireland!

Happy coding

The Google Code Jam Team