Its been a tough job configuring this API on various platforms for the project. There was no striaght and simple way I could get from even the Internet.
So writing down my own experience I have followed to configure this SMS API on Windows and Linux Platforms. Hope it would be useful for others who would
need this API to be configured in their projects.

JSMS is a Java API for sending and receiving Short Messages (SMS) and Multimedia Messages (MMS). The API supports a wide range of communication protocols.

1. Supported Protocols

Receiving and Sending of messages by using any GSM Device capable of sending SMS messages and also by using the most common SMSC communication protocols:

• GSM (GSM devices)
• UCP (Universal Computing Protocol)
• CIMD2 (Computer Interface to Message Distribution)
• SMPP (Short Message Peer-to-Peer)
• TAP/IXO (Telocator Alphanumeric Protocol)
• MM1 (MMS over GPRS)
• MM7 (MMS exchange using SOAP messages over http(s))

2. Where to get jSMS?

You can download a copy of the jSMS-API from http:// www.objectxp.com /. The API shipped either as a gzipped tar-archive (UTechnix users) or as ZIP-file (Windows users).

Configuration on Windows Platform

Pre-assumption: Java is installed on the Windows machine and JAVA_HOME is set.

Follow the below steps:
1.  Unzip the downloaded file to your target directory (using a tool like WinZIP)

2.  Copy javax.comm.properties file in the directory jSMS-<ver>\lib to the following locations on windows:
JAVA_HOME\jre\lib
JAVA_HOME\jdk<ver>\jre\lib

3. Make the necessary changes in the jsms.conf file which is at path jSMS-<ver>\bin

4. Copy the license properties that you received via email into the jsms.conf file

5. Change the property connector.serial.port to contain the port that you have the GSM device connected to (e.g. COM1).

6. Copy the following DLL files:

• win32com.dll from path jSMS-<ver>\lib to c:\WINDOWS\system32 folder
• jdunxp.dll from path jSMS-<ver>\lib to c:\WINDOWS\system32 folder

Now you are ready to send the SMS from your machine through the connected GSM device.

Testing on Windows:

1. Change directory to jSMS-<ver>\bin and double click the sms.bat file

2. Give the recipient’s mobile number

3. Specify the message to be sent

4. The message should be sent to the recipient

If received you have done it!

Configuration on Linux Platform

Pre-assumption: Java is installed on the Linux machine and JAVA_HOME is set.

1. Download the java communications API for linux platform from the URL:         http://www.oracle.com/technetwork/java/index-jsp-141752.html

2. unpack the download zip file using the command:

unzip comm3.0_linux.zip

3. Install the library using copy command:

cp commapi/lib/libLinuxSerialParallel.so

JAVA_HOME/jre/lib/ext/libLinuxSerialParallel.so

4. Install the comm.jar using the copy command:

cp commapi/jar/comm.jar

JAVA_HOME/jre/lib/ext/comm.jar

5. Install the javax.comm.properties using the copy command as below:

cp commapi/docs/javax.comm.properties

JAVA_HOME/jre/lib/javax.comm.properties

6. Make the necessary changes in the jsms.conf file which is at path jSMS-<ver>\bin

A. Copy the license properties that you received via email into the jsms.conf file.

B. Change the property connector.serial.port to contain the port that you have the GSM device connected to (e.g. dev/ttsy1).

Now you are ready to send the SMS from your machine through the connected GSM device.

Testing on Linux:

1. Open the terminal navigate to the folder jSMS-<ver>\bin

2. Execute the sms.sh file using the below command:

sh ./sms.sh

3. Give the recipient’s mobile number.

4. Specify the message to be sent.

5. The message should be sent to the recipient

If received you have done it!

• When should I use an abstract class and when I should use an interface?
• What is difference between delegate and event?

Although people know few points of differences, it’s worth to consolidate as many as differences as we can. So I am trying to provide most of the points that can not only compares various concepts, but also helps developers understand concepts better way.

Override vs. Overload

Interface vs. Abstract Class

Value Type vs. Reference Type

Delegate vs. Interface

Sound familiar? The beginning of the new year is a natural opportunity to reflect on the past and make resolutions for the future. It’s common that such resolutions rarely survive the month of January, much less the entire year. Is it that we’re not disciplined or motivated enough? Not necessarily. I believe the fault lies in resolutions themselves.

Too often on New Year’s Day, we make spur-of-the-moment promises with no clear action plan of how to achieve them. Most of us expect to see a drastic change in just a few weeks when, in reality, a significant and permanent change can take months to realize.

I have personally stopped making annual resolutions; instead, I embrace the power of continuous improvement. Taking a note from my Agile software teams, I’ve taken to making numerous small changes in my life that, combined together, have a big impact. For example, I recently decided to reduce the carbohydrates and glutens in my diet. I still eat them, just less of them. It may not sound as impressive as completely cutting these foods out of my diet, but it’s a change that I can realistically sustain. Similarly, rather than committing to losing 30 pounds in a year, I have started by trying to loose 3 pounds in 30 days. By layering such incremental improvements on top of each other, I create goals I can achieve. Each small success builds momentum and the confidence that I can permanently change my lifestyle for the better.

So whether you are trying to build a great software product or just fit back into your old jeans, take an Agile approach rather than a “big bang” approach. Commit to one or two small goals at a time, measure their impact, and adjust accordingly to make them permanent features in your life. If you repeat this process over the next year, I’m very confident you will amaze yourself.

I look forward to hearing your stories of resolutions either made or broken, as well as what techniques you’ve found make a lasting difference.

Wishing you all a happy, healthy and prosperous new year!

This Post was an Agile collaboration between Peter Harrison & Mayank Gupta of GlobalLogic

T-Shirt sizing is vague technique - get rid of it

Originally I estimated stories as one, two, three, four or as small, medium, large, extra-large. It was always meant to be understood that a medium was twice the size of a small and a large was twice the size of a medium (and so on), but that never seemed to translate well when it came to planning. Then someone recommended to me that I try powers of two. Suddenly we were speaking a language that the business could understand. They knew that an 8 was significantly bigger than a 1. I believe the sizes one, two, four, eight are also much more appropriate. As stories get larger they almost always contain more unknown and risk. A powers of two scale emphasizes the risk associated with large stories.

Use four values - it helps streamlining

I was once on a project that started with 1, 2, 4, 8 as their estimation values. After the first two estimation sessions less than 5% of the stories were ones and about 30% of the stories were twos. The project manager decided to get rid of the one value because it made his life easier. An interesting thing happened at each subsequent estimation meeting, suddenly only 5% of the stories were twos and many more stories had become fours. I don’t think that the developers consciously changed their scale, but developers are conditioned to be skeptical. Few developers are willing to say with certainty that any given story will be as easy as the scale allows. After witnessing this type of behavior on a few different projects, I prefer a minimum of four point values. I also prefer a maximum of 4 point values. After all, it’s nothing more than an estimate. If you try to give too much precision to an estimate you’ll end up having to account for why you missed the mark. The idea is to get a rough idea, not a rigid plan to live off of.

No averages or numbers not on the scale

Four values allow you to get a rough estimate without spending unnecessary time focusing on precision. Sometimes a story feels larger than a two but smaller than a four. The story should not be estimated as a three. There’s really no reason to use a three. The story carries enough risk or unknowns that it is not a two; therefore, it’s very likely that it will actually be a four. Using an average or an off scale number can briefly (and unnecessarily) confuse a team member or stakeholder. Also, in the big picture of the project, the occasional uncommon estimate isn’t likely to make much of a difference. Keep it simple, stick to the scale.

Vote independently- no baising

It’s human nature to be influenced by other people. If a technical leader says a story is a two, it’s likely that the rest of the team will follow his lead. For this reason I prefer an estimation process that lets each team member vote independently. This can be done by using sheets of paper that no one reveals until everyone is ready. Another option (that I prefer) is to give your estimation rock-paper-scissors (RPS) style. In our estimation meetings we talk about a story until we are ready to estimate then we all “throw” our estimations the same as you would “throw” rock, paper, or scissors. What I mean by “throw our estimation” is that if we think it’s a 1 we point 1 finger. Likewise a 2 is two fingers and 4 is four fingers. If you need to throw an 8, you can use both hands.

Take the largest estimate - that’s the safest way

Even when reminded, developers seem to have a hard time estimating with a team in mind. If a developer thinks they can do the story in 1 day, they throw 1 finger. Unfortunately, that developer may not be available to do the story, and then some other team member is stuck working on a story that they thought was a 2 or even a 4. I prefer to always take the largest estimate thrown by any team member. You may consider this to be sandbagging, but in reality it’s likely that each team member has identified different risks and the team member with the largest estimate has probably correctly identified that there is more risk than the other members have thought of.

Taking the largest estimate has additional benefits. If you must agree on a lower estimate then the team member with the larger estimate will need to discuss why they chose a larger value. This discussion can be uncomfortable for developers who are less senior on the team. They may not know how to do something as quickly, based on limited experience with the language or tools. Their concerns are often justified by their skill level, and it would be unfortunate if they felt uncomfortable giving their true estimate because they were afraid to discuss why it was higher.

Any discussion around taking a higher or lower value may lead to the entire team raising their value, or it may lead to that developer uncomfortably lowering their estimate. Either way, you’ll need to spend more time talking and you wont have gained–in the end it’s consistency that matters. You always know how many stories you expect to get done in an iteration by tracking velocity. Therefore, even if your estimates are “bloated” so will your velocity be, thus it has no effect on planning.

Finally, taking the largest estimate can help save time in an estimation meeting. If any member of the team believes the story is an 8 he can speak up at any time while discussing the story and announce that he is going to throw an eight. Unless someone else believes that there is a large estimation gap among team members, there’s no reason to continue talking about the story since it will ultimately become an eight anyway.

Large estimate gaps - something is not right

When estimating it’s usually the exception that the entire team agrees on the size of a story. Like I previously said, I like to handle the mismatch by always taking the larger estimate. However, sometimes a large gap represents a misunderstanding. For this reason any time there is a two value gap in estimation, additional conversation always occurs (e.g. if a team member throws a 1 and another throws a 4, some clarification needs to occur). Discussing large gaps also ensures that taking the largest estimate has less chance of being abused.

Insufficient information - may lead to inaccurate estimates

On occasion a story may need leave the meeting unestimated. It’s better to ask for more information than to give an estimate that you are uncomfortable with. An estimate of 8 implies that it’s a large story, but you expect it to take twice as long as a 4. Therefore, don’t simply estimate ill-defined stories as eights, because you will likely be expected to get it done in the same amount of time as it takes to get two stories estimated as fours completed. The goal of an estimation meeting isn’t to estimate all the stories, it’s to provide estimates on the stories that provide sufficient information.

Business and Developers - the two different line of thoughts

It’s as simple as this, the business wants to know what functionality they can get in the next iteration. To know what to expect they need estimates. Since the business will not be writing the code, they cannot contribute proper estimates. The more they are involved (in the actual estimation), the less likely it is that they will receive realistic estimates. The best domain experts answer questions in meetings, but never assert in any way the level of effort it will take to complete any given story.

Estimation group size - the right number is the trick

Teams come in many different sizes. On smaller teams (6 or less) I suggest the entire team attend the estimation session. The many points of view are likely to solidify vision and positively contribute to an estimate. However, I believe there is a point of diminishing returns. Not everyone on a large team needs to be part of estimating each story. Additionally, it’s an estimate, 6 people should be just as accurate as 15 people would be. If your team is larger than 6 people I suggest breaking into smaller groups for estimation. In general I like to get at least 3 people to estimate any given story, but no more than 6.

New stories - when should they be estimated

New stories come in two forms: new feature requests and stories that split. I generally wait to estimate new stories based on their priority. If a story needs to be done in the next iteration, it generally requires an immediate estimate. However, if the new stories aren’t going to be played for several iterations it can make sense to hold off until you have enough stories to justify an estimation meeting. I find estimates from estimation meetings to be more reliable, since they come from an environment where everyone is focused solely on estimation. Stories resulting from a split provide an additional complication: they likely already have an estimate. I strongly suggest that the new stories be estimated without taking into consideration the previous estimate. If a story carried enough risk or uncertainty that it required splitting, it’s not likely that the estimate is realistic–ignore the original estimate.

Required participation - this is important

This suggestion is a very important one. In theory, no developer from outside the team should be attending an estimation session. That means that every developer that attends an estimation session will potentially be tasked with working on a story that’s being estimated. If a developer is not comfortable estimating a story, then I’m not comfortable with them working on the story. Of course, there are exceptions.

The merge process failed because it detected a mismatch between the replication metadata of the two replicas, such that some changes could be lost leading to non-convergence. This could be due to the subscriber not having synchronized within the retention period, or because of one of the replicas being restored to a backup older than retention period, or because of the publisher performing more aggressive cleanup on articles of type download-only and articles with partition_options = 3. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199363)
Get help: http://help/MSSQL_REPL-2147199363

The common generation watermark is invalid at this replica since it does not exist or metadata for changes not yet propagated may have been cleaned up. (Source: MSSQLServer, Error number: 21800)
Get help: http://help/21800

———————–

Let us see how replication works: a subscriber connects to the publisher, submitting its knowledge about which generations have already been sent and received.  If the generations sent and received do not match, then the replication will fails by saying non-convergence can happen.

If you look in the table, sysmergesubscriptions, you will see four columns: sentgen, sentguid, recgen, and recguid.  These are the columns that tell the last generations synchronized.  Depending on whether you are looking at the publisher or subscriber will determine what the columns actually mean as far as direction.  If you are looking at the publisher, then sentgen and sentguid refer to the last generation sent to the subscriber.  If you are looking at the subscriber, then sentgen and sentguid refer to the last generation sent to the publisher.  If you get the above error message, then it may be that the values do not match between the publisher and subscriber.

We have to trust either publisher or subscriber for accuracy, So let’s say that we trust the publisher to be accurate on the sentgen and recgen.  All you need to do is copy the values for sentgen and sentguid into the recgen and recguid columns respectively, and the recgen and recguid into the sentgen and sentguid columns respectively at the subscriber.  Your update statement will look something like:

UPDATE sysmergesubscriptions SET sentgen = 8664, sentguid = ‘DD172177-E223-417C-8BFF-9F72561280EA ‘, recgen = 13842769, recguid = 193C40B5-7A23-4A7A-B97E-885EC2A1FFD3′ where subid = pubid and pubid = F6646824-BCCC-443C-875B-0D700F63D075′

In the update statement we have “where subid = pubid.”  That’s because there are two records for every publication at the subscriber, and only the one where the subid equals the pubid is used to track generations.

If synchronization is being taken care by RMO programming then you can also take care of this issue in RMO programming as well.

Today I had the distinct pleasure of speaking to a group of brilliant local leaders on how to Reclaim Your Inbox presented at the Young Presidents’ Organization Washington DC/Baltimore Chapter Retreat in Maryland on January 9, 2012.

View the full presentation: Reclaim Your Inbox by GlobalLogic CEO Peter Harrison

- - - - -

Below is a list of GlobalLogic’s Communications Guidelines for Email. If you have a good email tip or two that’s missing from this list, I encourage you to share them here by adding your comments below.

GlobalLogic’s Corporate Communications Guidelines - EMAIL:

1. Only send mail TO someone when action is requested or when responding (otherwise CC).
2. If information is simply FYI then send using CC, not TO which makes it clear no response is required
3. If you use REPLY ALL, always check that only relevant people remain in TO and CC.
4. If you send TO more than one person, make sure you clearly define who is expected to do what.
5. Consider creating a filter and applying a label to separate incoming CC mail.
6. Do not store processed mail in your Inbox - once you’ve responded/completed a mail move it to another label so you know it is complete.
7. Try to always respond to or acknowledge all TO mail within 24 hrs.
8. If you are not getting a response within the timeframe you need, pick up the phone. Not getting an email response from another person is not a reason to miss your own deadlines.
9. Do not use email for potentially emotional content; use the phone or a meeting instead.
10. If mail is confidential and not to be forwarded include CONFIDENTIAL in the subject line.
11. When you need to share attachments with a group:
12. For completed documents: upload to confluence and include the link in your mail
13. For working documents: use Google docs and share with the group
14. Always use the standard e-signature for all emails. Consider adding the PR boilerplate when sending emails for the first time to any person/prospect/partner - standard signature
15. Please use only the default background provided by Google for all emails. Backgrounds full of color and graphics can make emails difficult to read on mobile devices.
16. Please consider using HTML for emails as opposed to RTF. RTF makes it difficult to find embedded attachments.
17. As of now DELETED emails in Gmail are automatically erased from your mailbox’s memory after 3 weeks. Consider using ARCHIVE instead in order to locate your old emails.

By learning how to gather requirements as user stories, I realized how agile plans are always kept up-to-date, contain only the latest and greatest information, and avoid one of the greatest wastes our industry has ever known—premature up-front analysis.

The key challenges that teams run into when they heavily rely on documentation for their software requirements are that:

• They can’t handle changes effectively
• They build according to specs instead of what the customer wants
• They make bad guess and false assumptions
• They waste a lot of time

So, Is a requirement really a requirement? If I put it in words of Kent Beck, one of the 17 original signatories of the Agile Manifesto, then the term ‘Requirement’ is just plain wrong.

“Software development has been steered wrong by the term requirement, defined in the dictionary as something that is mandatory or obligatory. The word carries a connotation of absolutism and permanence, inhibitors for embracing change. And the word “requirement” is just plain wrong.

Out of the thousands of pages used to describe requirements, if you deliver the right 5, 10 or 20 percent, you will likely realize all of the business benefit envisioned for the whole system. So what were the other 80 percent? Not requirements—they weren’t mandatory or obligatory.”

The problem with gathering requirements as documentation isn’t one of volume—it’s one of communication.

• First, you can’t have a conversation with a document
• Second, it’s just really easy to misinterpret what someone wrote

This leads us to one of the most important principles of agile:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

So, what we need is something that enables us to have a conversation about a requirement, captures the essence of what our customer wants, and is small enough for planning yet descriptive enough to remind us what we are talking about …ENTER A USER STORY

Agile user story is a short description of a promise of a conversation. Agile encourages the user stories on index cards to remind teams that the initial goal of the requirements-gathering exercise isn’t to get into all the details. It’s to write down a few key words to capture the spirit of the feature and file it away for a later date.

Why just few key words? To save us the time and energy of going all in it now and having to redo it all later, we defer diving into the low-level details until later.

User stories have to make sense to business. That’s why we always try to write them in simple terms and try to stay away from any technical jargon. It is better if we put the information in terms that business understands.

A really good user story is one that goes from end to end - slicing through all the layers of the architecture and delivers something of value. The good user stories are Independent, Negotiable, Testable, and Concise that can be Estimated easily.

A few short, well-chosen words are usually enough to remind the team about what a particular user story is about: that brings up our User Story Template in existence

AS A <USER> I WANT <GOAL> SO THAT <REASON>

The nice thing about this template is it answers three important questions about the user story: the who, the what, and the why. It gives a little more context and really emphasizes and focuses on the business, which is a good thing.

]]> http://blogs.globallogic.com/simplifying-agile-the-art-of-writing-user-stories/feed http://blogs.globallogic.com/maven-integration-with-pmd-findbugs http://blogs.globallogic.com/maven-integration-with-pmd-findbugs#comments Wed, 04 Jan 2012 14:49:19 +0000 Rajender Aggarwal http://blogs.globallogic.com/?p=1887 Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project’s build, reporting and documentation from a central piece of information.

In this blog, we will look at integration of Maven with PMD and FindBugs. Apart from PMS and FindBugs, there are various other tools such as Surefire and Corbetura that can be integrated with Maven. Lets look at them …

• Maven Surefire Report Plugin : Generates the test results reports (TEST-*.xml) into HTML format.
• Maven Corbetura Report Plugin : The Cobertura tool is a free and easy to use source code test coverage analyser. It helps you to discover where your source-code lacks in test coverage.
• Maven PMD Plugin : Runs the PMD code analysis tool on your project’s source code and generate a site report with its results.
• Maven FindBugs Report Plugin : FindBugs uses static analysis to inspect Java bytecode for occurrences of bug patterns. FindBugs is better in finding Threading issues than PMD.

Configuring PMD with Maven

At the PMD site there is comprehensive documentation available on what PMD will report about. In PMD there are rules and rulesets. Rulesets are groups of rules and other rulesets. By default PMD provides a ruleset that is packaged with the plugin. To customize this you need to create your own ruleset like described on the PMD site.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<configuration>
<rulesets>
<ruleset>{Location of PMD Rulse Set File};/ruleset>
</rulesets>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>pmd</goal>
</goals>
</execution>
</executions>
</plugin>
Configuring FindBugs with Maven

FindBugs looks for bugs in Java programs. It is based on the concept of bug patterns. A bug pattern is a code idiom that is often an error. Bug patterns arise for a variety of reasons:

• Difficult language features
• Misunderstood API methods
• Misunderstood invariants when code is modified during maintenance
• Garden variety mistakes: typos, use of the wrong boolean operator

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>1.2</version>
<configuration>
<xmlOutput>true</xmlOutput>
<!– Optional directory to put FindBugs xdoc xml report –>
<xmlOutputDirectory>target/site</xmlOutputDirectory>
<threshold>High</threshold>
</configuration>
</plugin>

To conclude, integrating and generating reports with Maven is a great way to monitor the quality of the code. However, to get the real value, one must think about which reports to choose and how to use them. Adding too many reports will lead to information overload and may create confusion over what to fix.

Memory – One of the most valuable resources of digital world; always remains in high demand just like the Gold in real world. Every active application visible or invisible, certainly require memory for its operations. Due to its nature of limited and high demand, runtime environment has to be very cautious in allocating memory space for program’s objects. Runtime employee various techniques/algorithms in order to fulfil the memory demand of various running applications, considering making all of them mutually happy. 

It’s probably hard to imagine and directly going the way these runtime manages, better remain in real world and get conceptual understanding.

Let’s take a simple use case -

Place – Community hall

Capacity – 1000 persons

Objective – Provide the place for each person entering in hall with most convenient way. Convenience can be subjective so let be specific with following–

• Minimize the allocation time
• Minimize the disturbance for other existing
• Smooth capture of empty seats happen due to exit of persons

We have to design a master idea, a virtual program as a solution to above defined use case. Let’s start with simplest one.

Idea 1: Random Allocation.

Person entering can occupy any available location in the community hall. No specific seat allocation rule.

Each time a person enters, he will looks for comfortable place of his choice and occupy. Comfortable location is relative and differs for person to person. Some take front seat, some prefer back, some in center and some might look for seats close to their friends.

As there are no rules Think Time before occupying seat is relatively higher. Each has to think, spend some time his own way.

Idea 2: Sequencing – Force them to sit only next available seat in sequential order.

The moment we apply this rule, Think Time reduced drastically, close to zero. Now places are predetermined, person doesn’t have to spend his time in deciding the place. This idea makes things move faster but it leads into another problem.

Problem - We only considered allocation, and completely ignored the facts of people leaving the hall from any random location. This will create random free seats available, which could be allocated to new person. Our rule does not allow person to sit in empty locations even if they are more preferable/near compare to what next available defined by our rule. Clearly this rule fails to provide the space in least possible time considering empty random locations available.

Idea 3:  Re-arrange

Now to address problem with idea 2 we add another rule, Every time seat freed, we move existing persons, such that vacant locations merged into free location available at the end. Of course we haven’t solved the problem of Idea 2, we just avoided the scenario where problem arising.

At first, things look fine. No empty location remains since every time we move that to end.

Few time later we found ourselves in front of Lion just to avoid barking dogs. We just fall into bigger problem. Doing re-arrangement every time whenever seat gets vacant is overkilling, creating lots of disturbance for the existing mass.

To handle this we have added few sub-idea rules –

• Do not rearrange every time, do it in interval. Like for every 5^th vacant seat.
• Do this rearrangement in free time, break hours etc.

Doing all these does not gain much advantage and we have to move away from this rule.

We can have hundreds of these rules defined and analysed but it will create blogs virtually impossible to read. I might discover few more rules in next blog, but bigger question to be asked why this all discussion is all about.

Now try to map following entities

Community hall  = Available Memory Area

Capacity 1000 persons  = 1000 memory location, allocation units

Now re-read the Idea’s with mapped memory entities. You will understand the very basics essence of memory allocation.

All platform or programming language has their own strategy for memory management having their own set of benefits and drawbacks. At very broader level they are built around following

– Allocating memory in least possible time with most optimized way
– Freeing memory (Memory Recycling / Reclaiming Free memory)
– Arranging memory (Remove memory fragments)

As we go through community hall use case, though these activities might look simple but there is lot to be discussed. Hope to write more soon …

]]> http://blogs.globallogic.com/runtime-memory-management-basics/feed http://blogs.globallogic.com/singleton-design-pattern-using-c-sharp http://blogs.globallogic.com/singleton-design-pattern-using-c-sharp#comments Sat, 31 Dec 2011 07:21:26 +0000 pradip.pathrikar http://blogs.globallogic.com/?p=1812 Design Patterns are recurring solutions to the software design problems you find again and again in real world application development. These patterns are about design and interaction of objects and also serves as the communication platform concerning reusable solutions to commonly faced programming challenges. This post focuses on the main categories of design patterns and the implementation for the Singleton design pattern using C sharp.

Mainly design patterns are categorized in three parts

1) Creational Patterns

These patterns deals with the creation mechanism of objects, trying to create objects in a manner suitable to the situation. This type of design patterns solve the complexity of creating objects by controlling its object creations.

2) Structural Patterns

Structural Patterns are used to identify and implement the relationships between the entities in easy way.

3) Behavioral Patterns

Behavioral Patterns are self explanatory, behavior means the object methods or functions. Hence these types of patterns identifies the common ways of communications between the objects and thus increase flexibility in carrying out the communication.

Singleton Design Pattern - Creational Pattern

Singleton : Singleton design pattern is one of the Creational Patterns which controls the object creation. The main objective of the Singleton design pattern is that it creates and ensures only ONE object will be created during the life time of the application. Ex. Singleton pattern can be used for  maintaining only one database connection object through out the application, maintaining the static information and the reference count of the object accessed or used by the application.

Structure

CSingleton Class Diagram

Implementation: Singleton class using C#

namespace DesignPatterns
{
    public sealed class CSingleton
    {
        private static volatile CSingleton instance;
        private static volatile int counter = 0 ;
        private static object syncRoot = new object();
        private CSingleton()
        {
        }
        public static int Counter
        {
            get
            {
                return counter;
            }
        }
        public static void Release()
        {
            counter--;
        }
        public static CSingleton Instance
        {
            get
            {
                if (instance == null)
                {
                    lock (syncRoot)
                    {
                        if (instance == null)
                            instance = new CSingleton();
                    }
                }
                counter++;
                return instance;
            }
        }

    }
}

• In above example the the class CSingleton is marked as sealed so as to restrict the derivation of this class which could odd instances of this class.
• The variable “instance” will hold the object to the CSingleton class itself, volatile keyword ensures that the assignment to the instance variable completes before instance variable can be accessed.
• Constructor is made as private to prevent creation of the object of CSingleton class by other parts of application.
• Counter data member holds count of the references accessed by the client/other part of the application. This member is used to to know how many clients are using this object.
• Above approach uses the thread safe implementation using the syncRoot data member, double - check locking is implemented to avoid the thread concurrency problems.
• Release method will just decrements the counter by one. Clients should call this method once they are done using CSingleton object. Usually when they don’t require services of this class anymore.