Get your Groove(y) on JIRA

Without doubt many of you might have heard about JIRA – Project Tracking tool. Well, I had a chance to get close with JIRA. Basically, I got to work on customizing JIRA. It is just like customizing any normal software. You could find lots and lots of documentation on how you can create your own workflow, how to create custom fields, blah… blah... blah… Life was going smooth until, I had to write custom scripts that made JIRA go out of box.

We came across the plug-in for JIRA called “Script Runner”. It was a nice plug-in, except that there was not too many examples or documentation for all of its capabilities. So, I turned to my best friend “Google”. But alas, help was not available easily. I had to dig in deep, ransack my brain to come up with a search term which might get me results. Why not save the pain for some other people. So, here is my $0.02.

Script Runner plug-in allows you to write and execute Groovy scripts, for that matter, any scripts provided you have the JAR files for that language. Once, you install this plug-in, you can insert your groovy script into any of the operations that you perform.
For e.g., you can assign a set a value to a custom field during a state transition or you could write your own assignment logic during state transition.

So, in this post, I thought I would share some of the simple Groovy code snippets that I had created and used.

Updating a Custom Field:
As I was mentioning earlier, updating a custom field is simple and yet could be done in multiple ways, some easier and some not so easier :). The first approach that I came up with looked something like a Visu movie.

import com.atlassian.jira.ComponentManager
import java.text.*;
import java.util.*;
import com.atlassian.jira.issue.fields.CustomField;
import java.sql.*;
// Get the component manager & custom field manager instance for the script
def componentManager = ComponentManager.getInstance();
def customFieldManager = componentManager.getCustomFieldManager();
def cf = customFieldManager.getCustomFieldObjectByName("CreatedOn");
IssueChangeHolder changeHolder = new DefaultIssueChangeHolder();
Format formatter = new SimpleDateFormat("MM-dd-yyyy hh:mm:ss");
String timeStamp = formatter.format(new Date());
cf.updateValue(null, issue, new ModifiedValue([], timeStamp ),changeHolder);
cf.store();

Don’t even think. I am not going to explain this horror. Unable to store a Date field, I had stored the value as a string. Then, as a mature programmer would do, same functionality was re-factored to a simple this.

import com.atlassian.jira.ComponentManager
import com.atlassian.jira.issue.fields.CustomField;
import com.atlassian.jira.issue.*;
import java.util.*;
// Get the component manager & custom field manager instance for the script
def componentManager = ComponentManager.getInstance();
def customFieldManager = componentManager.getCustomFieldManager();
CustomField cf = customFieldManager.getCustomFieldObjectByName("CreatedOn");
cf.createValue(issue, new java.sql.Timestamp(new Date().getTime()));

Well, all we do here is get the Component Manager, which is the source for providing manjority of the JIRA objects required like Custom Field Manager, Project Manager or Authentication Manager. It is almost like a Manager Factory :). Using this we can then get the required Custom Field object by passing in the name of the custom field, “CreatedOn” in this case. Once, you get the object it’s a piece of cake. The JIRA takes only SQL TimeStamp value, even if you declare the field as a Date Field and not a DateTime field. I know, easy isn’t it, that is if you already know that.

You can get the list of JIRA objects available and their documentation here.

In the next coming posts, we will discuss on the JQl (JIRA Query Language) and how to use it in the Script Runner scripts and also other client APIS to access JIRA from outside JIRA.
Until then

Desire!!! Indulge!!! Inspire!!!

Aspect Oriented Programming in WCF - The Solution

I feel a great sense of satisfaction with myself.. It seems I have solved a problem which no one else can even think of.. i mean.. i don't see any comments on the blog.. so the only resolution that i can up is this.

The Problem:

Anyways, going on with the issue, the exact problem was "Transaction Management". You see as explained before, a single command was designed to perform a single operation. So, the logical decision was to keep the transaction at the command level. Ah!! Now do you see the problem?Initially this might be the best approach but then bringing reusability into the picture, this turns out to be a nightmare. You save a person data, the person name gets committed but his employment details address may get lost because both these are placed in 2 different commands, which translates to 2 transaction.

The Solution:

Well, how do you solve it.. Just Mix and match some technical jargons and voila you ge tthe solution :). Seriously, the approach for solving the issue would be

1. Either introduce a new layer in between to handle the transactions.

2. or even better introduce AOP.

The concept of AOP is to introduce the cross cutting concerns in a common place or to be specific in an interceptor so that this gets executed auomatically for each operation. So, how is it exactly implemeted. For that you would have to know the following.

1. IOperationBehavior: Contains the methods to control, modify and extend the behavior for operation wide execution.

2. IContractBehavior: Contains the methods to control, modify and extend the behavior for contract wide execution.

3.IOperationInvoker: Contains the methods to execute the operation in either synchronous or asynchronous mode.

Define a class implementing IOperationInvoker with ur new implementation of the operation i.e. perform your custom operation before the invoke method is triggered or after the operation is executed. So, you can create the transaction as a pre process and committ / rollback as post process.

Next step is to plug this new Invoker behavior into the operation behavior. For this create a custom class implementing IOperationBehavior and mention the new invoker as the operation invoker in the ApplyDispatchBehavior(). Similarly, nmake this class implement the IContractBehavior interface and register this class to the list of operation behavior in the ApplyDispatchBehavior().

// IOperation Behavior Method implementation

public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)

{

dispatchOperation.Invoker= new CustomInvoker(dispatchOperation.Invoker);

}

// IContractbehavior Method implementation

public void ApplyDispatchBehavior(ContractDescription contractDescription, ServiceEndpoint endpoint, DispatchRuntime dispatchRuntime)

{

foreach (OperationDescription opDescription in contractDescription.Operations)

{

opDescription.Behaviors.Add(this);

}

}

The CustomInvoker is the custom class that defines the cross cutting operation prefix / suffix. You are done with the basic infrastucture set up. So, how do you apply this to your WCF Service. Simple, make the behavior custom class that we created inherit the Attribute class thereby, you can provide this AOP implementation to Service classes which has this custom class name as an attribute like

[CustomBehaviorAttribute]

public class YourWCFService : IYourWCFServiceContract

{}

So, just with the addition of 2 classes (Custom Inovker & Custom Operation and Contract behavior classes), you are ready to implement your custom operation before / after calling your service operation. Isn't it easy enough.

Desire!!! Indulge!!! Inspire!!!

REST based services in .NET 3.5

.NET 3.5 has provided various features using which we can create WCF services which can be accessed directly over http using REST principles.

I got a chance to go through code magazine (http://www.code-magazine.com/Article.aspx?quickid=080014) URL today... which explains about REST services, WCF and implementation of REST based services using WCF.

Hope this helps others also...

Aspect Oriented Programming in WCF

Aspect Oriented Programming provides a mechanism of modularizing the application by separating to cross cutting concerns from the application. For implementing an AOP paradigm, you would want to know the following:

Aspect: A concern that cuts across multiple objects like Transaction, logging, exception handling etc…

Join Point: An execution point in the application like a method execution or catch of exception etc…

Advice: Action to be performed in an aspect at a particular join point.

Pointcut: Pointcut determines join points of interest for us to execute the advice. For example, conditions like Function Name or all public functions etc…

In our project or for that matter in any project, we can see a more common problem – dilution of the design guidelines. The project was designed with certain principles in mind. Unfortunately, as time passes by and new team members contribute towards the code, these guidelines get evaporated. One such case in our project was the usage of Command classes.

In order to understand the actual issue, we might have to go back a few years when Raj was designing the application. The architecture was designed like

1. There will be a WCF service exposed by the client for their business operation.
2. Each operation in the service will perform one action requested by the user.
3. The action to be performed will be delegated to a command class.
4. Each command class will perform one and only operation.

Seems a fair enough guideline. But as the team started working on the application, they saw that there were some pieces of code being written again and again. Bling!!! What about code reuse... Brilliant!! Let us have common code written in a separate command and reuse the command. So, what eventually happened was each service operation started comprising of multiple commands, which went on to become a separate command for certain logic even when not reused.

But what is the problem:

I see no harm in reusing, I mean, didn’t we learn that reusability increases code quality.

Come on people!!! What do you think might have been the problem with this? Please post in your comments on the same. I would request the project members not to comment on this as they very well know the issue.

As I would not want to make you read too much of content in 1 post, we will discuss the issue and the solution in the next blog.

Desire!!! Indulge!!! Inspire!!!

nHibernate at its best - High level view

Do you think nHibernate reduces your application's performance? If yes, then there is something fundamentally wrong in the way it is implemented. Lets see at a high level how we can build a good application using nHibernate.

How it works?
nHibernate session is actually meant for a single unit of work. when the application performs a database operation, nHibernate performs it through its session and caches the data for further reference. This behaviour improves the performance of the application; i.e. when application makes another call to retrieve the same data, nHiberate fetches the data from its cache and not from the database.

Where it goes wrong?
As mentioned above nHibernate session is for a single unit of work, but when we use the same session for a long running process, the performance gradually decreases, this is because the session goes on caching all the data which will increase the memory of the session. When next call to the database is made, session traverse through its memory to find if the data is already cached and this operation takes more time than the actual operation. In these scenarios its necessary to flush and clear the session in a regular interval which would improve the performance of the application to a point.

Here comes the million dollar question... is it actually good to use nHibernate for a long running process or batch process?
The answer is NO. nHibernate is designed for OLTP. Its best to use nHibernate for small transactions / online processing.

For batch process always go with native database connectivity.

How Many Design Pattern You Know?

Each time I have been asked this question only few of the design pattern names I used to remember. Even if I go through again I not sure to remember for more than one day. So I thought to come up with simple statement which will make me to remember the name of design pattern( Atleast name :-))

I decided to create single sentence for each type of patterns.

1. Creational

Abstract Factory Creates an instance of several families of classes
Builder Separates object construction from its representation
Factory Method Creates an instance of several derived classes
Prototype A fully initialized instance to be copied or cloned
Singleton A class of which only a single instance can exist

sentence to remember
builder used prototype to build single abstract factory.

2. Structural

Adapter Match interfaces of different classes
Bridge Separates an object’s interface from its implementation
Composite A tree structure of simple and composite objects
Decorator Add responsibilities to objects dynamically
Facade A single class that represents an entire subsystem
Flyweight A fine-grained instance used for efficient sharing
Proxy An object representing another object

sentence to remember
abcd proxy is flying facade.

3. Behavioral

Chain of Responsiblity. A way of passing a request between a chain of objects
Command Encapsulate a command request as an object
Interpreter A way to include language elements in a program
Iterator Sequentially access the elements of a collection
Mediator Defines simplified communication between classes
Memento Capture and restore an object's internal state
Observer A way of notifying change to a number of classes
State Alter an object's behavior when its state changes
Strategy Encapsulates an algorithm inside a class
Template Method Defer the exact steps of an algorithm to a subclass
Visitor Defines a new operation to a class without change

sentence to remember
Interpreter commands mediator to iterate template of memento and Visitor observes state and strategy of chain.

Now I am able to remember all the design pattern names which are given above easily :-).

Managing Browser History in AJAX-style Web pages - .Net way

In one of my project we encountered a problem on utilizing the browser history performed by the user on .Net pages. since we used the updatepanels for updating some parts of the page, this will not trigger the browser to record the change in its history collection.

For example, a user visits Page A and updates some parts in the page A using the partial update(update panels). Now if he refreshes the page, he will lose the changes he had done in the partial update in Page A.

.Net3.5 and ScriptManager gives us a very elegant way to handle this kind of situations even for navigation through browser's NEXT and PREVIOUS buttons.

Please refer the following URL for complete details:
http://msdn.microsoft.com/en-us/library/cc488553.aspx

Detailed explaination coming soon...