1. Make schema changes with sp_repladdcolumn and sp_repldropcolumn

If you attempt to change an article that is published for merge replication, you will get an error message warning:

ALTER TABLE DROP COLUMN failed because ‘columnName’ is currently replicated.

To make schema changes to existing merge replication topologies, use the sp_repladdcolumn and sp_repldropcolumn stored procedures.

2. Re-index articles frequently

If merge replication is setup using filters then make sure those filtered tables have proper indexing which makes queries fast and also those tables needs to be re-indexed frequently.

Also Re-index the MSmerge_contents, MSmerge_tombstone, MSmerge_genhistory and MSmerge_replinfo tables frequently to improve overall replication performance.

3. Execute commands on all Subscribers

You will often be asked to replicate a set of commands to all your Subscribers, such as dropping any article from publication does not drops from subscription. To do this, use sp_addscriptexec with Drop table command. This command will work on all Subscribers that you deployed via UNC subscriptions.

4. Use dynamic snapshots

If you are filtering subscriptions, you will notice that your subscription still contains all of the data, even data that is not part of its filter. For example, if you send a subscription to a sales agent for California, he will receive data for the entire country. To minimize the size of the snapshot, use dynamic snapshots, and your Subscriber will only contain the data that meets the filtering criteria.

5. Wrap your agents to restart on failure

A large number of merge agents will fail due to transitory reasons (such as locking, batch failures, network problems, etc.), and these transitory errors will clear the next time the agent runs. Set your merge agent to restart on failure by right clicking on your merge agent and selecting Agent Properties. Then select Steps and double click on step 3 (”Detect nonlogged agent shutdown”). Click the Advanced tab. Where you see “On success action,” select “Goto Step 1.” As in Figure.

This way if your agent fails, it will restart. If it fails to do an abnormal event, it will not restart. You should collect the contents of MSrepl_errors on your Subscribers and evaluate them to discover exactly why they are failing.

6. Limit concurrent merge agents

For large numbers of Subscribers, you should limit the number of merge agents that can run concurrently. If you select this option, you must also set the StartQueueTimeout property to establish how long a merge agent will remain in a wait queue until other merge agents have completed processing. You may need to set this value to 60s or more from its default of 0 (which means it waits indefinitely). To limit the number of concurrent merge agents, right click on your Publisher and select Properties, click on the Subscriptions tab and check the “Limit the number of concurrent merge processes to the following” box.

7.  Timeout issue while processing snapshot generation.

If there is huge data in any article which you are trying to synchronize without any filter then system timeout if synchronization time exceeds 5 minutes. Merge agent profile run on default setting which has default query timeout as 300 seconds. In such scenario this time needs to be increased to avoid timeout.

8. Snapshot.pre could not be propagated to subscriber while synchronization

There are situation when any new articles are added to existing publication then snapshot gets generated successfully but subscription does not reflect those articles and it throws an error “Snapshot.pre” file cannot be found.

This is the case when account under which merge agent runs does not have proper permission to access UNC/Alternate snapshot folder.

]]> http://blogs.globallogic.com/merge-replication-2/feed http://blogs.globallogic.com/social-network-theory-with-matlab-code http://blogs.globallogic.com/social-network-theory-with-matlab-code#comments Mon, 02 Apr 2012 13:36:35 +0000 PG http://blogs.globallogic.com/?p=2121 In the last few decades, interest in Social Networks has seen explosive growth with Facebook being the poster child. Indeed work had gone on before that time in Physics especially in the area of “random networks” (Erdos and Renyi are famous names). In such networks, each new node is randomly connected to any previous node and its evolution studied.

The work of Barabasi and others showed that while the physics of Random Networks was interesting, it had little to do with “human made” networks such as Web, Internet, friendship networks, etc. They all fall into the category of “Scale-Free Networks”.

Scale-Free Network (SFN) Model:

“Scale-free” refers to the nature of some networks where its diameter (average # of links to reach a node from the present node; remember “six degrees of separation” between people) is mostly unchanged as the network grows in size.

SFN’s degree (# of links per node) is distributed as a power law (and not a binomial distribution which is the case for a purely random network). A well-known example of power law is Pareto distribution (“80/20 rule”). SFNs arise in networks that grow and have preferential attachment property while growing (exhibits “rich get richer” and “first mover advantage” phenomena).

Figure 1: Pareto distribution (example of a Power Law distribution)

If a “fitness” rating is attached to each node, a new phenomenon of “winner takes all” emerges (Google search engine will rate very high among websites as an example). This has been shown to be a “Bose-Einstein” condensate state (somewhat similar to condensation transitions that occur in traffic jams where long queues of cars are found, in wealth distribution models where a few people might have a huge fraction of all the wealth and in operating systems usage where Windows has close to 90% market share).

For more on Social Network Theory, see Scale-Free Networks: A Decade and Beyond by Barabasi for a pain-free summary. (Science, Vol 325, 24 July 2009; pp 412-413).

Real Social Networks:

Real social network has 3 major features:

1. Clusters (of friends who “hang out”).

2. Weak links (to your long forgotten high school classmates).

3.Hubs (politicians and others with massive number of contacts).

Figure 2: Natural social network structure with Cluster Groups

Comparing the Pareto (power law) distribution that governs SFNs, we can see that Hubs with many links (large “k”) are nodes that occur rarely whereas Clusters with few links are nodes that occur very often. Here we elaborate a mid-scale situation where certain nodes have a fair number of links and occur with some frequency – we call them “Cluster Groups”. They arise in cases where a certain Member belongs to multiple Clusters, their family cluster, work cluster, golf club cluster, etc. The same Member belongs to many Clusters that are tightly coupled leading to a Custer Group.

Failure Modes:

Failure modes of SFNs have been widely studied. The main 2 observations are that (1) SFN is robust to Failure and (2) SFN is vulnerable to attacks.

Failure means random loss of network elements such as some computers or local routers going down in the Internet. Attack refers to concerted take-down of major “hub” routers. It has been shown that removal of a small percent (15 to 20%) of “hub” routers will pull apart the network and “cascading failure” will spread (due to routers NOT under attack being unable to carry the extra load from “hub” routers) leading to total network failure.

MATLAB Code: Link to code below.

I have included the ‘m’ file of the MATLAB code that does the following:

1) Network: Will generate Scale Free Network of ‘N’ nodes and ‘d’ degrees (2 is typical for social networks).

2) Plotting routines from MATLAB Central to create “tree” plots of the network generated.

Here are N=10 and N=100 examples; d=2 in both cases.

The N=100 example already shows some interesting features. Remember “Hubs”? One would expect the “root” node at the very top to be a Hub but the left-most node in the 2^nd level seems to be developing into a Hub with lots more “child” nodes.

Further Work:

a) MATLAB jocks may find my code lame; feel free to improve it, make it interactive, etc.

b) When N exceeds a few thousand nodes, my PC runs out of memory! Remember that these are large matrix operations – you may find a way to make the code more memory-efficient by using ‘sparsematrix’ functions in MATLAB.

c) One of the main theoretical and practical interest in Social Networks is identifying Hubs before they fully emerge – the reason is that they are vulnerable to attack and the eventual failure of the whole network. A fun project will be to let the network “grow”, say 100 nodes at a time, and observe its dynamics.

- Can you predict which node has the potential to become a Hub? How early can you predict it?

d) Clearly, there are many other funs projects to do with the MATLAB code I have included. Feel free to contact me for ideas, joint explorations and discussing interesting results you may have generated.

socialnetwork_mfile

Have fun with social networks!

PG

Dr. PG Madhavan is the Associate Vice President–Technical Advisory for Global Logic Inc and Head of Technology for Solavei. He has over 25 years of experience in wireless, signal processing, software and entrepreneurship. He has deep expertise in wireless networking products and services. His extensive experience includes employment at major corporations  such as AT&T, Microsoft, Lucent, Rockwell, and a startup, Zaplah Corp, where he was the Founder and CEO. He has been a faculty member of Electrical Engineering & Computer Science and Neuroscience departments.  He has a Ph.D. in Electrical and Computer Engineering. He has contributed to over 50 publications and has 12 U.S. patents issued. He regularly speaks at industry events, including Microsoft WinHEC and ACM MobiHoc.

A Deloitte report says that “as recently as 2009 there were only a handful of big data projects and total industry revenues were under $100 million. But by the end of 2012 more than 90 percent of the Fortune 500 will likely have at least some big data initiatives under way. Industry revenues will be in the range of $1-1.5 billion.”

On the other hand the analyst and reporters at Wikibon see 10x growth of Big Data over the next five years, topping $50 billion. Increased interest in and awareness of the power of big data and related analytic capabilities will result in a super-charged CAGR of 58% between 2012 and 2017.

So what is the Big Data?

Big data is a term applied to data sets whose size is beyond the ability of commonly used software tools to capture, manage, and process the data within a tolerable elapsed time.

Due to the rapid expansion of social, mobile, location and transaction-based data generated by the users across various industries, Big data analytics will top all other areas of growth in analytics during 2012.

The key attributes of Big data are:

• Variety: Big Data extends beyond structured data, including unstructured data of all varieties: text, audio, video, click streams, log files and more
• Velocity: Often time sensitive, Big Data must be treated as it is streaming into the enterprise in order to maximize its value to the business
• Volume: Big Data comes in one size: LARGE

Big Data can be used by companies to make better decisions and also useful for them to learn more about the needs and behavior of their customers.

Thanks to Apache for supporting Hadoop project that is the open source implementation of Google file system and MapReduce. It is designed to efficiently process large volumes of data by connecting many commodity computers together to work in parallel.

Hadoop is primarily consists of two runtimes, the Hadoop distributed file system (HDFS) and MapReduce.

• HDFS splits large data files into blocks which are managed by different servers in the Hadoop cluster, and ensures that blocks are replicated to other servers (Datanodes)
• MapReduce is a Java framework used to process data stored in HDFS. Self contained jobs are written in MapReduce and submitted to the cluster. The jobs run in parallel on each of the machines in the cluster, processing the data on the local machine

Being open source and highly scalable, Hadoop has been adopted by many fortune 500 companies. There are so many different flavors/products of Hadoop present in the market that clients can evaluate carefully before making a decision on what is right for their organization.

Both the hardware and software technologies handling the Big Data are evolving at a rapid pace, increasingly making it possible to perform fast ‘Big Data’ analysis, but still there is a fairly big gap in the number of trained technologists who are productively using the available tools.

The firms have to invest heavily in training the staff and technologist in Big Data to bridge the gap. The cost may be high but the returns are definitely lucrative and would provide competitive advantage to the firms.

Software design principles represent a set of guidelines that helps us to avoid having a bad design. The design principles are associated to Robert Martin who gathered them in “Agile Software Development: Principles, Patterns, and Practices”. According to Robert Martin there are 3 important characteristics of a bad design that should be avoided:

• Single Responsibility Principle
• Open / Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Single Responsibility Principle

A class should have only one reason to change

In this context a responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handle it.

When we need to make a change in a class having more responsibilities the change might affect the other functionality of the classes.

SRP was introduced Tom DeMarco in his book Structured Analysis and Systems Specification, 1979. Robert Martin reinterpreted the concept and defined the responsibility as a reason to change.

In the context of the Single Responsibility Principle (SRP), responsibility can be defined to be “a reason for change.” If there are more than one motive for changing a class, then that class has more than one responsibility. This is sometimes hard to see. We are accustomed to thinking of responsibility in groups.

Open/Closed Principle

Software entities like classes, modules and functions should be open for extension but closed for modifications.

OCP is a generic principle. You can consider it when writing your classes to make sure that when you need to extend their behavior you don’t have to change the class but to extend it. The same principle can be applied for modules, packages, libraries. If you have a library containing a set of classes there are many reasons for which you’ll prefer to extend it without changing the code that was already written (backward compatibility, regression testing). This is why we have to make sure our modules follow Open Closed Principle.

When referring to the classes Open Close Principle can be ensured by use of Abstract Classes and concrete classes for implementing their behavior. This will enforce having Concrete Classes extending Abstract Classes instead of changing them.

Modules that conform to the open-closed principle have two primary attributes.

1. “Open For Extension” – This means that the behavior of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
2. “Closed for Modification”– The source code of such a module is inviolate. No one is allowed to make source code changes to it.

Liksov Substitution Principle

Derived types must be completely substitutable for their base types.

This principle is just an extension of the Open Close Principle in terms of behaviour meaning that we must make sure that new derived classes are extending the base classes without changing their behaviour. The new derived classes should be able to replace the base classes without any change in the code.

Liskov’s Substitution Principle was introduced by Barbara Liskov in a 1987 Conference on Object Oriented Programming Systems Languages and Applications, in Data abstraction and hierarchy

There is a number of behavioral conditions that subtype must meet. These are detailed in a terminology resembling that of ”design by contract” methodology, leading to some restrictions on how contracts can interact with inheritance:

• Preconditions cannot be strengthened in a subtype.
• Postconditions cannot be weakened in a subtype.
• Invariants of the supertype must be preserved in a subtype.
• History constraint (the “history rule”). Objects are regarded as being modifiable only through their methods (encapsulation). Since subtypes may introduce methods that are not present in the supertype, the introduction of these methods may allow state changes in the subtype that are not permissible in the supertype.

Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they don’t use.

We write our interfaces we should take care to add only methods that should be there. If we add methods that should not be there the classes implementing the interface will have to implement those methods as well. For example if we create an interface called Worker and add a method lunch break, all the workers will have to implement it. What if the worker is a robot?

As a conclusion Interfaces containing methods that are not specific to it are called polluted or fat interfaces. We should avoid them.

This principle deals with the disadvantages of “fat” interfaces. Classes that have “fat” interfaces are classes whose interfaces are not cohesive. In other words, the interfaces of the class can be broken up into groups of member functions. Each group serves a different set of clients. Thus some clients use one group of member functions, and other clients use the other groups.

Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend on details. Details should depend on abstractions.

Dependency Inversion Principle states that we should decouple high level modules from low level modules, introducing an abstraction layer between the high level classes and low level classes. Further more it inverts the dependency: instead of writing our abstractions based on details, the we should write the details based on abstractions.

Dependency Inversion or Inversion of Control are better know terms referring to the way in which the dependencies are realized. In the classical way when a software module(class, framework) need some other module, it initializes and holds a direct reference to it. This will make the 2 modules tight coupled. In order to decouple them the first module will provide a hook(a property, parameter) and an external module controlling the dependencies will inject the reference to the second one.

By applying the Dependency Inversion the modules can be easily changed by other modules just changing the dependency module. Factories and Abstract Factories can be used as dependency frameworks, but there are specialized frameworks for that, known as Inversion of Control Container.

In a nutshell,

Design Principles

Implementing sustainability is an elusive goal that sometimes seems to only reside in a best practices manual. Some employers break projects down into discrete portions like a Ford assembly line to enable employees to work on “autopilot.” Some create elaborate break areas with gym equipment and pool tables to help their employees recharge. In my opinion, neither of these approaches really tackle the core of the sustainability issue (although the recharge zones certainly are welcome!). For me, it’s a matter of treating sustainability as a project requirement, just as you would any other product feature. After all, if the team burns-out and breaks apart then it’s just as much a failure as delivering the wrong features or poor quality.

When planning a new project, most software teams hardly discuss sustainability or how to achieve it. Even in best-case scenarios, it often remains a “nice to have” attribute. I believe software teams need to set realistic expectations about what can be accomplished in a certain amount of time — both for clients and for themselves. Since Agile engineering relies on iterative releases rather than a “one and then done” approach, teams cannot push themselves for the the first few iterations and then slack off as their energy ebbs. Clients will inevitably compare a team’s recent activity with its past accomplishments and be disappointed by the decreased productivity.

But when a team finds its sustainable pace, it always meets its sprint goal, leading to a sense of empowerment and accomplishment. And with the continuous learning involved in Scrum practices, teams begin to set better expectations with their clients on what they are delivering. Stakeholders can count on the team to deliver exactly what they committed to because the goals are realistic and based on the collective wisdom of the team.

One tactic I’ve seen used is the implementation of visual control boards. This tool enables teams to keep track of their progress and the obstacles they are facing, leading to a path of continuous improvement. A commonly used variation of the visual control board is the Kanban scheduling system that is based on the principle of ‘Limiting work in Progress’.   This approach helps teams identify how many tasks they can focus on at a particular time and then build a sustainable pace based on this number. At the heart of this principle resides a “pull system,” which controls the flow of resources in the value chain and allows the addition of new resources only as a replacement of what has already been consumed. This balance between demand and throughput encourages higher software quality, an optimized process, greater team performance and a healthy work environment.

Breaks are essential part of building a sustainable pace. I especially like the Pomodoro Technique that helps you get things done and stay focused by taking breaks after each unit of time. The typical length of a “pomodoro” is 25 minutes. After each pomodoro, the person takes a 5-minute break, which is a real break where he is not allowed to do anything work related. After four pomodoros, a longer break of around 15 minutes is required. These intermittent breaks make the technique more effective by helping the team member maintain concentration and motivation. Pomodoro is an Agile approach to time management, and it includes a number of practices similar to those used by an Agile team such as time-boxing, inspect and adapt, and an emphasis on maintaining a sustainable pace.

Regardless of the tactic used, Agile teams must establish a regular pace and deliver against it consistently. Only by implementing sustainability within a project can a team ensure a steady level of software quality, team productivity and trust with their clients. After all, the hare may sprint faster but it was the tortoise that won the race.

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

Strings in switch statements

static boolean booleanFromString(String s) {
 switch(s) {
   case "true":
     return true;
   case "false":
     return false;
 }
 throw new IllegalArgumentException(s);
}

Binary Literals
The integral types (byte, short, int, and long) can also be expressed using the binary number system. For example,

// An 8-bit 'byte' value:
byte aByte = (byte)0b00100001;

// A 16-bit 'short' value:
short aShort = (short)0b1010000101000101;

// Some 32-bit 'int' values:
int anInt1 = 0b10100001010001011010000101000101;

Comparisons for Enums

boolean isRoyalty(Rank r) {
  return rank >= Rank.JACK && rank != Rank.ACE;
}

Extension methods

import static java.util.Collections.sort;
List list = ...;
list.sort();    // looks like call to List.sort(), but really call to static Collections.sort().

Automatic Resource Block Management

static String readFirstLineFromFile(String path) throws IOException {
try (BufferedReader br = new BufferedReader(new FileReader(path))) {
 return br.readLine();
}
}

Prior to Java 7, it would be written as below:
static String readFirstLineFromFileWithFinallyBlock(String path) throws IOException {
BufferedReader br = new BufferedReader(new FileReader(path));
try {
 return br.readLine();
} finally {
 if (br != null) br.close();
}
}

Language level XML support

elt.appendChild(
<person>
   <name>John</name>
</person>);

Improved Catch Clause

try {
 return Class.forName("com.xyx.Person");
} catch (ClassNotFoundException | ExceptionInInitializerError e) {
 throw new AssertionError(e);

}

Effective software release management is not only meant for the one who is responsible to deliver a software release but also for those who are actively involved in any manner to provide a successful software release to the client. Here are some best practices that we can follow:

1. Release plan

The first and foremost point is to assess the current state of the project and deciding on the release frequency with delivery dates. Are there any dependencies for on-time deliveries? Does it require changing the dates due to these dependencies?

The release cycle must be as accurate as it can be. Do not define the release cycle based on when the Customer wants it, but when it can be delivered with desired quality. Remember that it needs to be tested thoroughly and it becomes really worse if you miss the dates than the release process itself.

2. Release infrastructure

Before you start the next release start thinking in advance about what kind of infrastructural issues/dependencies might be there at Client’s site. The release infrastructure should be in place at an early date for avoiding any fallbacks. In our project, the client planned to move its infrastructure from individual servers to the virtual environment. So, the questions were: What difference does it make for us? What can be the dependencies to deliver the release on time? Do we have access to the new virtual environment? What supporting software(s) are required for our application, are they available? How much time will it take for the complete setup to be available on the release date?

3. Standardization and Automation

It helps in standardizing and automating the release process. The release process should be standardized as to what is contained in a release. What are the common deliverables for all the releases? What additional deliverable is required in particular releases? E.g. in next release, if there are changes to the underlying database schema, then the particular release should have an extra deliverable which is the data migration scripts.

Deliver the release as a software package and automate the deployment process as far as possible.

It’s always better to review the contents before clicking the ‘Release’ button.

4. Release report

Each release is provided with a Release report that should contain all release details i.e. deliverables/artifacts, release scope, issues resolved, known issues, deployment details (e.g. configurations), etc.

5. Setting expectations

Never hide but communicate the importance of a particular release within your team to empower everyone involved in the process.

6. Agility in Release process

The release process should be flexible enough to accommodate for any interim patch releases or any rollbacks to previous releases that are required.

Good software release management always helps in gaining Customer confidence and it needs the skill to review, adapt to improvements and great communication. It also helps in satisfying existing customers and hopefully winning new ones.

CAESAR

Good friends, go in, and taste some wine with me;
And we, like friends, will straightway go together.

BRUTUS[Aside]

That every like is not the same, O Caesar,
The heart of Brutus yearns to think upon!

Julius Caesar: Act2, Scene2 (the scene right before Caesar's death)

I wonder if it is not the same with Agile. Many projects which fail use “something like agile“, think they are using “true agile” and are doomed to die. Caesar did not have the benefit of hindsight and a lot of instances where he saw things “like friendship” dooming him. We do..

I was speaking with one of my friends who had just returned from a project retrospective meeting after it had failed. Following are some excerpts that he recalled:

PMCSM (project manager, a recent convert to scrum master through certification): “We used a lot of agile throughout the development life cycle, yet it failed. Guess waterfall was better”

LSD (Local Scrum Don, and thus the interrogator): So what elements of agile did you use?

PMCSM: Elements? The whole hog man! Bug tracking on Jira, collaboration on wiki, daily stand ups, 3-week sprint releases and what not. We even played planning poker, did not know it will all come to this!

LSD: Planning poker is good fun. Did the whole team play it?

PMCSM: Do I look like I will let the whole team play a game for hours just because some moron wrote you should? The leads and me sorted the stuff out. We used the extra person hours on more productive things

LSD: Did everyone attend the daily stand ups?

PMCSM: Every member, every night, without fail. That is what the book says, right?

LSD: At nights, Oh! And how long were these

PMCSM: Around an hour but sometimes more, we did not miss covering any of the issues. What kind of meeting gets over in 10 minutes, you tell me?

LSD: Did you have sprint demos at the end of each sprint?

PMCSM: No, the damned sprint product never came in a state it could be demo’d. And we were always in a rush to start with the next sprint. But we did everything else on Agile

LSD: And why was that? What did the devs say?

PMCSM: They gave some crap about requirements coming in late. I scrambled a lot to get those to their desk before they started the task. Still they whined. What do I do if the client did not blow up the stories before the sprint started. If I delayed the sprint start, the relationship would have taken a hit.

LSD: And do you think the relationship is in a state of Nirvana today since we did not stop the sprints then. Did you have the retrospective meetings too?

PMCSM: On stopping the sprint, let us not get all too cynical now that it has failed. It is easy for you to say this now. You can not imagine the pressure that was at that point to keep the development going. The client CTO was breathing down my neck to keep it on and please bear with them. The retrospectives sounded like too much. Anyway, everyone was already aware of what went right and what did not and people were busy planning out the next sprint. So, we did away with that

—-

It all lasted for a good two hours. Neither was able to convince the other.

We come across such teams and managers every day. And that makes me think that Scrum is not for the weak at heart, its not for the people who are steeped deep in waterfall and keep counting person hours till the end of time and sweat at the thought of moving a story out mid sprint. If you can not commit to it, Scrum is not for you. You’d have to leave the bird in your hand to find the two in the bush. Else, waterfall is probably a more suitable development model.

The learnings from the above conversation:

Agile is light on processes, not loose on them: Many managers enjoy agile since they feel it frees them up from the process overhead. They are correct, but only partially. Agile, by definition, is a very light-on-processes-framework. However, the few tenets it stipulates must be adhered to. Iteration planning meetings create a sense of belongingness and ownership to the sprint deliverable. Many old school waterfall managers count the person hours spent on this and pass this. That is one of the worst things to do and defeats Scrum even before getting started

Implement and Inspect is not a principle, it is the way of life: Numerous projects get into issues using agile since they do not abide by the rule to give frequent “potentially shippable” releases. The end of the sprint should be a sacred time and the demos/retrospectives as good as written in stone. Else, you are being neither here nor there. We bargained a bullet proof design phase just so that the product gets customer attention regularly and they eventually get what they asked for.

It’s the people, silly: Clients and managers alike, at times, use agile to push things too hard for the team. In the name of bi-weekly releases, a lot of pressure is built on the team and they eventually burn out. The tenet of agile is to make the team all important - seek their opinion on what can be done, let them decide effort estimates, allow them the liberty and will to own the product. By thrusting estimates they have to meet or having them sit on two-hour long night calls in the name of stand up will make them hate all three - the manager, agile and the product - does not augur well for a world class product.

It merits a repeat - agile is not for the weak at heart: Have the courage to delay a sprint start if stories have not come in. Have the courage to scrap a sprint midway if there are too many changes. If you are not doing this, the short term impact is on the morale of the team and the quality of sprint release. The long term impact is that the laxity enters the genes of the business guys. Just delay a sprint by a week or scrap one sprint midway and listen to the music at the other end. It may correct your problem once and for all. If you just keep being too good, you may become the bad guy in the end.

The conversation at the beginning may seem outrageous but it is an everyday story on failed projects who were using something like agile. Much like Caesar, they thought they were in good company and did need not to watch their back. Again, much like Caesar, they meet the same fate - end up dead or dusted.

Thoughts?

Just One Product Does it All
Some .NET plug-ins will simplify data binding, but don’t offer many display options. Others focus on impressive graphics but require extensive, tedious coding. Many of these tools leave you wanting more - they tease you with a slick presentation style on your screen, but the printed version often doesn’t match up. DataWindow .NET provides a variety of sophisticated and adaptable presentation layers with minimal coding, the ability to easily build complex SQL queries, define validation rules, filter, sort, and manipulate data, as well as apply a variety of sophisticated column edit styles - all with point-and-click ease. And now with DataWindow .NET v2.5, you can easily build a DataWindow using a Web Service as a datasource, further simplifying your development tasks.

DataWindow .NET is the perfect data manipulation and reporting component for both WinForm and WebForm .NET projects and it supports Microsoft® Visual Studio 2005, ASP.NET 2.0, and ADO.NET 2.0.

Features & Benefits
DataWindow .Net includes hundreds of built-in functions, properties and declarative programming options, providing developers with high levels of productivity in a virtually code-free tool. The new WebForms for ASP.NET and Microsoft handwriting recognition support makes adding complex forms and signature recognition to application an easy task.

New with version 2.5, DataWindow .NET provides a set of plug-ins that enable developers to create their DataWindows inside of Visual Studio .NET without ever having to leave the IDE. And, with a new Web services DataWindow, you can easily access, manipulate and display data from Web services.

DataWindow .NET components
DataWindow .NET 2.0 is a set of Microsoft .NET assemblies that enable you to use DataWindow® objects in applications built with tools that support the .NET Framework. If Microsoft Visual Studio .NET 2005 is installed on your system, the DataWindow assemblies are integrated into the Visual Studio .NET 2005 Toolbox.

DataWindow Designer 2.0 is a tool that you use to build the DataWindow objects you use in DataWindow .NET.

DataWindow Reference 2.0 provides dynamic Help for the DataWindow assembly in Microsoft Help 2 format. If Microsoft Visual Studio .NET 2005 is installed on your system, the DataWindow Reference is integrated into the Visual Studio .NET 2005 Help system.

Installation
DataWindow .NET 2.0 works with the full release version of Visual Studio 2005. Installation did not work with the Visual Studio 2005 beta or with the C# Express Edition. Installation is simple and straightforward. Sybase uses InstallShield to guide users through the installation.

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!