Category : Produits

Create kick-ass software fast

 

 

Twitter Facebook Linked In Del.icio.us Download Urban Turtle Turtlepedia

One of the main orientations is to build Urban Turtle into TFS (as opposed to integrate with). All our design decisions are made to bring as much value-added as possible while creating a seamless experience for existing TFS users and grow with TFS as Microsoft adds new features.

If you are interested about the details of the three releases we have made since the Visual Studio 2010 launch in April, please read the following posts:

  1. April 30th – Urban Turtle 3.0 RTM is now available!
  2. June 4th – Urban Turtle 3.1 now available!
  3. July 8th – Urban Turtle 3.2 now available! – Support Visual Studio Scrum 1.0

We believe this orientation is what allows us to have a product that installs on the server in less than two minutes and gets a team to use it right away. We are very interested in hearing your stories and get your feedback about how we can further improve the experience.

Help us make our Urban Turtle a Chameleon ;)

Also, our tight integration in the Web Access user interface makes the user feel at home and perceive TFS with new capabilities (as opposed to using an extra product). This is a big plus to have a smooth user adoption. We know that adopting scrum is already an interesting challenge; you do not need tools to get in your way but be a possible accelerator.

Again, give Urban Turtle a try and let us know how we succeeded in turning it into a Chameleon.

Migration to JIRA 4.1.x for more than 4 years old plugin

Minyaa is the successor of Kaamelot plugin, initially developped for JIRA 3.7 and maintained until JIRA 3.12.

When Minyaa started to replace Kaamelot, there were more than 120 modules in atlassian-plugin.xml file.

Kaamelot (now Minyaa) comes with improvements for different features in JIRA and many i18n properties.

Following Atlassian documentation, the way to define i18n properties is as follows :

<atlassian-plugin key="jira.plugin.minyaa.core" name="Minyaa JIRA Plugin Core" pluginsVersion="1">
  <module key="ModuleKey" name="ModuleName" ...>
      <resource type="i18n" name="i18n" location="com.myplugin.jira.MyClass" />
   </module>
   <module key="OtherModuleKey" name="OtherModuleName" ...>
      <resource type="i18n" name="i18n" location="com.myplugin.jira.MySecondClass" />
   </module>
</atlassian-plugin>

For some modules, the I18n resources were declared using 2 files, in order to reuse existing i18n resource files without having to duplicate translations.

<atlassian-plugin key="jira.plugin.minyaa.core" name="Minyaa JIRA Plugin Core" pluginsVersion="1">
<module key="ModuleKey" name="ModuleName" ...>
...
<resource type="i18n" name="i18n" location="com.myplugin.jira.MyClass" />
<resource type="i18n" name="i18n.Other" location="com.myplugin.jira.MyOtherClass" />
...
</module>
...
</atlassian-plugin>

Without more detailed documentation, when Kaamelot (Minyaa) required to extend existing i18n properties, the technic used was to append a new I18n Location in the extended WebWork Action, by accessing I18nBean object.

You can imagine that with 120 modules (components, webwork actions, Report, Portlet, Service, Issue Tab Panel, Project Tab Panel, …), extending i18n properties may be a pleasure …

With JIRA 4.0, the Gadgets arrived with new constraints … Minyaa portlets have been migrated into real Gadget (Atlassian Framework 2) only for JIRA 4.1.x.

As Minyaa performs many extensions in JIRA components, it was not possible to migrate Minyaa plugins in OSGi Plugin. Only Portlets have been migrated into Gadget in separate Plugin (jira-plugin-minyaa-xxx-gadgets-4.x.x-x.x.jar).

Gadgets, as any graphical item, require I18n Properties ! How does it work ?

Following Atlassian documentation, it only requires to declare in gadget xml file the supportedLocales macro with a key filter for I18n key. A new component (the I18nResolver) is able to load all I18n resources of all plugins and extend the Gadget definition using the key filter.

Ok, lets go ! For Minyaa Core, my first portlet to migrate was Minyaa Fragment Portlet

  • The Minyaa Core Gadget plugin (jira.plugin.minyaa.core.gadget) is created.
  • The declaration is done as follows :
<?xml version="1.0" encoding="UTF-8" ?>
<Module>
<ModulePrefs ...>
#supportedLocales("gadget.common,portlet.fragments")
</ModulePrefs>
...
</Module>
  • All needed i18n resources definitions are provided by the plugin identified jira.plugin.minyaa.core

Oups … Some of i18n key were not translated!

After many search in documentation, I have connected the debugger in order to understand where the issue was …

Root cause :

The I18nResolver performs a scan of all i18n resources provided by different plugins, and jira.plugin.minyaa.core i18n resources are found and loaded!

Yes, but they are loaded in a Container based on HashMap and using the couple pluginKey + i18nName, as a key.

It means that jira.plugin.minyaa.core i18n resources are loaded using jira.plugin.minyaa.core as pluginKey, and each i18n Resources Name.

Since Minyaa Core plugin contains more than 1 module the i18n Resources were not unique.

Before the migration, the atlassian-plugin.xml modules were declared as follows :

<atlassian-plugin key="jira.plugin.minyaa.core" name="Minyaa JIRA Plugin Core" pluginsVersion="1">
<module key="ModuleKey" name="ModuleName" ...>
...
<resource type="i18n" name="i18n" location="com.myplugin.jira.MyClass" />
<resource type="i18n" name="i18nOther" location="com.myplugin.jira.MyOtherClass" />
...
</module>
<module key="OtherModuleKey" name="OtherModuleName" ...>
...
<resource type="i18n" name="i18n" location="com.myplugin.jira.MySecondClass" />
...
</module>
...
</atlassian-plugin>

Since the migration, each i18n resource has to be unique (per i18n resource file) as follows :

<atlassian-plugin key="jira.plugin.minyaa.core" name="Minyaa JIRA Plugin Core" pluginsVersion="1">
<module key="ModuleKey" name="ModuleName" ...>
...
<resource type="i18n" name="i18n" location="com.myplugin.jira.MyClass" />
<resource type="i18n" name="i18nOther" location="com.myplugin.jira.MyOtherClass" />
...
</module>
<module key="OtherModuleKey" name="OtherModuleName" ...>
...
<resource type="i18n" name="i18nSecond" location="com.myplugin.jira.MySecondClass" />
...
</module>
...
</atlassian-plugin>

I18n translation is important for all plugins, but you need to be aware that for large and old plugins, this is not a small work !

Atlassian Plugin of the month: Talia for JIRA

Talia is delighted to have been chosen as the plugin of the month for JIRA. Register to join the webinar on June 18, 2010 by clicking on the following link  https://www2.gotomeeting.com/register/985138474 .

Dialoog, a subsidiary Pyxis Technologies, has just released Talia for JIRA, the first enterprise-class chat robot that assists project managers with time tracking and issue updates. The product is not just an Instant Messaging interface to your JIRA, it really is a proactive robot specifically devoted to freeing project managers from the monthly time sheet nightmare. Find out more at http://www.dialoogsolutions.com/talia/jira/.

Pre-release of GreenPepper for C++ is available!

We are proud to announce that a pre-release of GreenPepper for C++ developers is available! This release supports both Atlassian Confluence and XWiki wikis.

So C++ comes today to enhance the existing list of software development platforms supported by GreenPepper (Java, PHP, .NET, Ruby). This pre-release has been developped in 2 months in C++ using full test-driven approach thanks to the GoogleTest framework.

Compiled langages (like C++) are pretty challenging regarding the lack of mechanism like runtime type informations (or reflection). Our team took the challenge and got inspired by the same solutions as those retained by Google.

Our team hid complexity as much as possible, to allow GreenPepper C++ users to program with a simple source code (hum… although “simple” with C++ does not mean the same with other langages ;-) )

Want to see what a fixture source code looks like? Below a C++ header file sample :

CalculatorFixture.h

using namespace greenpepper;

using namespace type;

CLASS_FIXTURE_BEGIN(CalculatorFixture)

public:

CalculatorFixture(void);

IntegerType a;

IntegerType b;

void setA(IntegerType a);

void setB(IntegerType b);

IntegerType getA();

IntegerType getB();

IntegerType sum();

REGISTER_METHODS_BEGIN()

REGISTER_PROCEDURE_1(setA, IntegerType)

REGISTER_PROCEDURE_1(setB, IntegerType)

REGISTER_METHOD_0(getA, IntegerType)

REGISTER_METHOD_0(getB, IntegerType)

REGISTER_METHOD_0(sum, IntegerType)

REGISTER_METHODS_END()

CLASS_FIXTURE_END(CalculatorFixture)

If you want to start using executable specifications within you C++ projects, just tell us! Please contact us at grenoble@greenpeppersoftware.com. Download the package here.

Kind regards.

Next Release – Final Sprint with Finish Line on June 2nd

In Urban Turtle’s Next Destination we listed the features that the team intended to produce for the first sprint of the release scheduled for June 2nd. I am as very happy product owner because the team delivered everything that was intended for the sprint and we have more killer features in the next and final sprint of this release.

The main feature is the integration of areas in the planning board. We were not pleased with the way we had develop this feature in our TFS 2008 version. We think we have a better design that will please all users. We are eager to release it on June 2nd to have your feedback.

As always, feedback is greatly appreciated as comments here or on the forum.

Urban Turtle 3.0 RTM is now available!

Team Urban Turtle is proud to announce that Urban Turtle 3.0 has sim-shipped alongside Team Foundation Server 2010 and is now available for download. During the last two weeks, we’ve been hard at work to fully support the RTM version of TFS 2010. We also manage to squeeze in several UI changes to correct various graphical glitches. We firmly believe this is by far the best version ever of Urban Turtle. We look forward to hearing from everyone about this release!

Answering some common questions about Urban Turtle

Last week we were in Las Vegas at devconnections for the launch of Visual Studio 2010 and to present the new version of Urban Turtle. We often got the following questions :

  1. Do we need to install anything on the workstations?
  2. What happens if I customize the process template to fit the specific needs of my organization?
  3. Does UrbanTurtle interfere with other tools from Microsoft, other vendors or that we could have developed?
  4. What are your plans?
  5. What is your pricing?

Do we need to install anything on the workstations?

From the beginning, our goal is that Urban Turtle users do not feel as if hey are using another product. We want to increase their comfort and simply extend their usage of Team Foundation Server (TFS). To achieve this, we did several things. The main one is that the user interface seamlessly blends in with Web Access of TFS. Therefore, there is just a one-time installation process on the server.

Furthermore when we developed the new installation process for the VS 2010 compatible version, Dominic’s (the Product Owner) condition of satisfaction was that the installation takes less than 5 minutes. The team over delivered because most of the time, the installation takes less than 2 minutes. If your installation takes longer, please let us know.

What happens if I customize the process template to fit the specific needs of my organization?

We know by experience that a lot of organization will want to use a standard process template and customize it by adding some fields to some work items or slightly customize some workflows or … In other words, there is no one way of doing Agile and Scrum. Therefore we designed Urban Turtle to let you take advantage of TFS’s customization capabilities; Urban Turtle is designed to be process template independent. It only needs to know a couple of things about your process template. This information needs to be put in a simple XML file. We will shortly write a blog entry that will explain how to easily create the mapping file. In the meantime, do not hesitate to ask questions on the forum

Does UrbanTurtle interfere with other tools from Microsoft, other vendors or that we could have developed?

No, Urban Turtle does not interfere with any tool.

Again our goal in designing Urban Turtle is that it seamlessly inserts itself in the TFS ecosystem. To achieve this, we decided to rely on standard extension mechanism and not have a separate data store. Urban Turtle directly manipulates work items using the standard APIs.

This allows us for example to validate the workflow transitions in the task board even if you customize your workflows. Also, since you customize your work item fields using standard mechanism and Urban Turtle does not add extra data, the powerful reporting and data warehousing capabilities of TFS will not be affected and will work as documented by Microsoft.

What are your plans?

The team is currently in the last sprint to release version 3.0. The product, the development environment and the team are now in a mature enough state to do solid public releases every 4 to 6 weeks. We will publish a blog every sprint to announce what we are working on.

What is your pricing?

I hope this answers the most common questions. If I missed some, do not hesitate to ask.

Do not hesitate to turtle your TFS, you are less than 5 minutes away!

~francois

Urban Turtle 3.0 Release Candidate

The Urban Turtle team is proud to finally present the release candidate of our Agile Project Management extension to Team Web Access 2010: Urban Turtle 3.0. This new version sports a brand new look, a streamlined user interface and full support for Team Foundation Server 2010. Make sure to download it and request a free 30-day trial, you’ll find that you can’t do Agile in TFS 2010 without Urban Turtle.

In the last few months, we’ve spent quite some time working on our template support. Out of the box, Urban Turtle supports the MSF Agile 5.0 process template. We’re actually quite proud to introduce what we think is the first and only 3-column task board to work with MSF Agile 5.0 without any modifications.

Urban Turtle 3.0 Task Board

But what’s even better is that we support virtually any process template through an xml mapping file. We already provide one such file to support MSF Agile 5.0, but new ones can be added to support your own template.

We’re aiming to sim-ship alongside Team Foundation Server 2010 which has just been made available, meaning the RTM version should be ready before the end of the month. Right now, the release candidate has only been tested with TFS 2010 RC. We recommend using Microsoft’s virtual machine to try Urban Turtle 3.0 RC.

We hope you enjoy this latest release, and please do provide some feedback so that we make the turtle even better!