Five reasons to kill IT projects

A recent study highlighted the top five reasons IT experts who killed a project gave for terminating projects prior to completion. Check out the five reasons.

Here’s the list, with my commentary on each issue:

1. Business needs changed: 30%

There are many conditions and situations where a business legitimately changes its requirements after starting a project. If the project no longer provides meaningful value, then it’s best to stop throwing good money after bad.

On the other hand, some organizations deliberately obscure a flawed project requirements process by claiming business needs evolved. Obviously, that’s unhealthy and a true sign of failure.

2. Did not deliver as promised: 23%

This is a typical expectation-setting problem: promise anything to get funding and worry about the consequences later. Shortsighted managers don’t realize that funding is less important than delivering substantive value. Failure is inevitable when managers don’t clearly identify and deliver business value.

In some cases, the project really did provide value, which the organization did not recognize due to communication problems. I recently blogged about one CIO seeking a publicist, presumably to address this issue:

Many organizations take a CIO for granted when his IT department consistently delivers the goods without fanfare and attention; sadly, this human failing is all too common. In that case, PR might be a great idea, especially if the CIO isn’t a great communicator. Of course, the CIO should improve his communication skills, but that’s another story.

3. Project was no longer a priority: 14%

If the organization shifted direction without good reason, thus making the project superfluous, then flawed strategic planning was the culprit. However, if business requirements changed for a good reason, as suggested in point one, there’s not necessarily a problem.

In general, and this is an obvious point, canceling projects without a darn good reason is a definite sign of failure.

4. Project exceeded the budget: 13%

On the surface, over-budget projects are the basic metric for failure. I’m actually surprised this number isn’t higher, because unanticipated cost is always such a clear red flag.

At the same time, some projects run over-budget due to intelligent scope increases that provide additional value. For example, while automating two departments, the project team realizes it can add a third department for only marginal increases in cost. In such cases, going forward is probably the right decision despite the higher spend.

Although tempting to use budget performance as simple metric of success or failure, that approach can be overly simplistic and ignore important nuances related to business value. Nonetheless, anytime a project goes over-budget the team must offer a detailed explanation.

5. Project did not support the business strategy: 7%

This classic indicator of failure often suggests a project rooted in poor requirements analysis. However, as with previous points, it’s also possible changing business needs made the original project goals obsolete.

=====

The survey is most interesting to highlight significant issues related to project failure. However, some of the questions are too ambiguous to provide straightforward conclusions. In general, understanding whether a project is successful requires examining the business environment and context.Via: TechRepublic

Remember God...

Protect your JavaScript with obfuscation

JavaScript is the standard language for building powerful Web applications. A drawback of its usage is the ability for others to easily view JavaScript code via the View Source Web browser option. While this isn’t always a concern, there are times when it is better to keep prying eyes away. Thankfully, there are ways to accomplish this via code obfuscation and tools that make it easy to use.

Obfuscation primer

Simply put, the word obfuscation means to make something less clear and harder to understand. Obfuscation involves converting source code into equivalent code that is difficult to reverse engineer. An obfuscator is a tool that makes this possible. Obfuscation does not make it impossible to reverse engineer, but it presents many roadblocks.

Obfuscation is accomplished using various techniques. The following list provides an overview of these techniques:

• Control: Alters the way the code flows, which may include altering: how statements are grouped together, the order in which code is executed, or control by inserting extraneous code.
• Layout: The various elements of code layout may be altered. This includes variable names that may be renamed to hide their purpose; removing or rewording comments; and altering code formatting that affects code readability. In addition, unused code may be removed.
• Data: The various aspects of data may be altered to affect code readability. This includes changing the order of data elements like arrays; changing data structures like splitting arrays into multiple arrays; altering how stored data is interpreted; or changing the scope of variables. Another way to hide variables is through encryption.

A key feature of obfuscation is deobfuscation, which means making it hard to reverse the process. That is, you want to make it difficult to reverse the obfuscation process to discover the original code. With that in mind, obfuscation tools attempt to thwart common deobfuscation techniques and take advantage of known deobfuscation weaknesses.

It is worth noting that obfuscation is not restricted to code; it can be used to hide data as well, but this article focuses on source code. One caveat of obfuscation is the possibility of optimizing your code since extraneous code is often removed. With a basic understanding of the topic, let’s turn our attention to the tools available putting obfuscation in motion.

Obfuscator tools

A simple Google search yields an overwhelming number of results when trying to locate obfuscation tools. The following list provides a sampling of these tools:

• Jasob: A commercial tool that supports JavaScript and CSS obfuscation. A nice feature of this tool is its ability to read JavaScript and CSS source from a variety of sources including PHP, ASP.NET, and JSP files. Jasob promises to optimize and protect your code.

• Javascript Obfuscator: This tool allows you to work with HTML or JavaScript source files. It includes various options for defining how obfuscation is handled. This includes removing whitespace and comments, along with defining how variables may be renamed.
• ObfuscateJS: A command line tool for applying obfuscation techniques to your code. It allows you to compress code by removing whitespace and comments along with renaming variables.
• Stunnix JavaScript Obfuscator: A Web-based tool that works with both client- and server-based JavaScript. It provides encryption and compression features as well.
• Thicket Obfuscator: This tool promises to optimize while securing your code. It allows you to process multiple files at once and map variable names to their counterparts in the obfuscated code, along with defining rules for dealing with comments.

The difference with these tools is the obfuscation techniques they provide. At the most basic level, all the tools allow you to compress code by removing whitespace and comments. The next level is renaming variables, but where do the tools go from there? This is where the tools differentiate themselves.

I like the Jasob tool, but there doesn’t seem to be a consensus within the community about which tool is best. In the end, you utilize what best meets your needs.

In action

Obfuscation doesn’t always have to be a complicated process. I’ll use this simple JavaScript function as the source for an obfuscation example:

// A test function
function test( ) {
// Declare variable to display
var b="Test";
// Display variable in window
alert(b);
}

Now, running this code through a simple obfuscation can yield the following line of code:

function test(){var atv="Test";alert(atv);}

In this case, the obfuscation process included the removal of whitespace and comments. In addition, the variable name was altered. This simple example provides a sampling of what may happen to more robust code.

Protect intellectual property

A lot of hard work goes into developing JavaScript code that meets your needs. While the Web promotes the sharing of such code, there are times when you or a client may not want to share their JavaScript code. This may be due to the sensitive nature of data within the code, proprietary calculations, or any other scenario.

JavaScript obfuscation provides a vehicle for keeping your source code from prying eyes. Of course, a rogue developer may invest a lot of time and money to deobfuscate your code, but the key is not making it simple.

Do you worry about another developer stealing your source code? Do you utilize obfuscation to protect your code? If so, what tools do you prefer? Share your thoughts with the Web Developer community by posting to the article discussion.Via: TechRepublic
Remember God...

Socket Send and Receive [C#]

This example shows how to send and receive data via TCP/IP using Socket in .NET Framework. There are methods Socket.Send and Socket.Receive.

Socket.Send method

Send method sends data from your buffer to a connected Socket. When you call the Send method it returns number of bytes which were „sent“. But it doesn't mean that the bytes were already received by the other side, it only means that the data were stored in a socket buffer and the socket will be trying to send them. If the socket buffer is full a WouldBlock error occurs. You should wait for a while a try to send the data again.

Following method sends size bytes stored in the buffer from the offset position. If the operation lasts more than timeout milliseconds it throws an exception.

[C#]

public static void Send(Socket socket, byte[] buffer, int offset, int size, int timeout)
{
  int startTickCount = Environment.TickCount;
  int sent = 0;  // how many bytes is already sent
  do {
    if (Environment.TickCount > startTickCount + timeout)
      throw new Exception("Timeout.");
    try {
      sent += socket.Send(buffer, offset + sent, size - sent, SocketFlags.None);
    }
    catch (SocketException ex)
    {
      if (ex.SocketErrorCode == SocketError.WouldBlock ||
          ex.SocketErrorCode == SocketError.IOPending ||
          ex.SocketErrorCode == SocketError.NoBufferSpaceAvailable)
      {
        // socket buffer is probably full, wait and try again
        Thread.Sleep(30);
      }
      else
        throw ex;  // any serious error occurr
    }
  } while (sent < size);
}
To call the Send method use following code snippet (suppose
the static Send method is defined in SocketEx class). TCP/IP socket can be obtained using TcpClient class. Use TcpClient.Client property to get the underlying Socket (this property is public since .NET Framework 2.0).

[C#]
Socket socket = tcpClient.Client;
string str = "Hello world!";
try
{ // sends the text with timeout 10s
  SocketEx.Send(socket, Encoding.UTF8.GetBytes(str), 0, str.Length, 10000);
}
catch (Exception ex) { /* ... */ }

Socket.Receive method
Receive method receives data from a bound Socket to your buffer. The method
returns number of received bytes. If the socket buffer is empty a
WouldBlock error occurs. You should try to receive the
data later.

Following method tries to receive size bytes into the buffer to
the offset position. If the operation lasts more than timeout
milliseconds it throws an exception.
[C#]
public static void Receive(Socket socket, byte[] buffer, int offset, int size, int timeout)
{
  int startTickCount = Environment.TickCount;
  int received = 0;  // how many bytes is already received
  do {
    if (Environment.TickCount > startTickCount + timeout)
      throw new Exception("Timeout.");
    try {
      received += socket.Receive(buffer, offset + received, size - received, SocketFlags.None);
    }
    catch (SocketException ex)
    {
      if (ex.SocketErrorCode == SocketError.WouldBlock ||
          ex.SocketErrorCode == SocketError.IOPending ||
          ex.SocketErrorCode == SocketError.NoBufferSpaceAvailable)
      {
        // socket buffer is probably empty, wait and try again
        Thread.Sleep(30);
      }
      else
        throw ex;  // any serious error occurr
    }
  } while (received < size);
}

Call the Receive method using code such this:
[C#]
Socket socket = tcpClient.Client;
byte[] buffer = new byte[12];  // length of the text "Hello world!"
try
{ // receive data with timeout 10s
  SocketEx.Receive(socket, buffer, 0, buffer.Length, 10000);
  string str = Encoding.UTF8.GetString(buffer, 0, buffer.Length);
}
catch (Exception ex) { /* ... */ }


Via : C sharp Examples 
Always Remember God...

Hi , our company Accounting program published .


It's Very Cool program.... We called this AZARHESAB , integrated accounting system.

For more information , please call me...




TAGS: azarhesab , azar hesab , hesab azar , tabriz

Introduction J2ME

Introduction

This tutorial assumes that you have some familiarity with general programming concepts and the Java language.

What is J2ME?

J2ME stands for Java 2, Micro Edition. It is a stripped-down version of Java targeted at devices which have limited processing power and storage capabilities and intermittent or fairly low-bandwidth network connections. These include mobile phones, pagers,wireless devices and set-top boxes among others.

A Sample Wireless Stack would consist of:

• Profiles
• Configurations
• Java Virtual Machines
• Host Operating System

What is a J2ME Configuration?

A configuration defines the minimum Java technology that an application developer can expect on a broad range of implementing devices.

J2ME Connected, Limited Device Configuration (CLDC)

• specifies the Java environment for mobile phone, pager and wireless devices
• CLDC devices are usually wireless
• 160 - 512k of memory available for Java
• typically has limited power or battery operated
• network connectivity, often wireless, intermittent, low-bandwidth (9600bps or less)

J2ME Connected Device Configuration (CDC)

• describes the Java environment for digital television set-top boxes, high end wireless devices and automotive telematics systems.
• device is powered by a 32-bit processor
• 2MB or more of total memory available for Java
• network connectivity, often wireless, intermittent, low-bandwidth (9600bps or less)

These two configurations differ only in their respective memory and display capabilities.

What is a J2ME Profile?

A specification layer above the configuration which describes the Java configuration for a specific vertical market or device type.

J2ME Profiles

J2ME Mobile Information Device Profile (MIDP)

• this is the application environment for wireless devices based on the CLDC
• contains classes for user interface, storage and networking

J2ME Foundation Profile, Personal Basis, Personal and RMI profiles

• these are profiles for devices based on the CDC, which are not addressed in this tutorial

Virtual Machines

The CLDC and the CDC each require their own virtual machine because of their different memory and display capabilities. The CLDC virtual machine is far smaller than that required by the CDC and supports less features. The virtual machine for the CLDC is called the Kilo Virtual Machine (KVM) and the virtual machine for the CDC is called the CVM.

Tools

First make sure that you have the Java 2 SDK, Standard Edition (J2SE SDK), version 1.4.2 (or later). This is essential for development. If you haven't installed it, download it and install it from here http://java.sun.com/j2se/downloads/index.html.
You absolutely MUST have the J2SE SDK installed before you install the Java Wireless Toolkit as you will be needing the tools it contains (such as javac) to compile and run your MIDlets.

Then download the J2ME Wireless Toolkit (WTK) which is available free from Sun here - http://java.sun.com/products/j2mewtoolkit/. I'm going to assume that you'll be installing this in the C:\j2mewtk\ directory, if you use another directory, just modify the paths accordingly.

Paths

Java needs to know where all your files are, so we need to add the location of the Java binaries to the system path.

Windows 95/98

Go to Start->Run. Type in command. Then type

SET PATH=%PATH%;C:\j2mewtk\bin

You should also edit your C:\autoexec.bat file to include this line, so you don't have to enter it every single time you restart your computer. After you've done this, you should be able to run the tools included in the Java Wireless Toolkit from any directory on your system.

Windows 2000/XP

• Go to Control Panel -> System.
• Click on the Advanced Tab
• Click on the Environment Variables button
• Double-click the PATH variable in the System variables box
• At the end of the Variable value field, add the path to your J2ME WTK installation - for me this is something like C:\j2mewtk
• If you had to install the J2SE SDK too, it's a good idea to add the path for that - for me this is C:\j2sdk1.4.2_03 and C:\j2sdk1.4.2_03\bin.

A good way to test if this worked is to type the preverify command without any arguments in the command line. You should see something like this on your screen. C:\> preverify
Usage: PREVERIFY.EXE [options] classnames|dirnames ...

where options include:
-classpath
Directories in which to look for classes
-d Directory in which output is written
@ Read command line arguments from a text file.

Application Development

MIDlets vs Applets

MIDlets are applets for mobile phones. Just like applets, they run in a protected sandbox - the KVM - but unlike applets, they are extremely limited. MIDP 1.0 is currently found on most Java-capable phones and is fairly restrictive. As an example - the KVM doesn't allow you to process floating point numbers yet and MIDlets written for MIDP 1.0 can't access anything outside of the sandbox without proprietary APIs from phone manufacturers. So, put your dreams of developing the ultimate MIDlet with hooks into every part of your phone OS on the backburner for a while. If you want to find out exactly how limited MIDP 1.0 is, you should probably read the spec here. Once you've done that you might want to check out MIDP 2.0 and see what Sun has fixed with that spec. For the time being we're going to write our first MIDlet - a full-featured "Hello MIDlet" application.

Simple HelloMIDlet

We're going to use a program called Ktoolbar from the JAVA WTK which we installed earlier.

• Go to Start->Programs->J2ME Wireless Toolkit 2.1->KToolbar.
• Click on the New Project button and name your project HelloProject and your MIDlet HelloMidlet.
• Once you press Create Project, KToolbar will create a bunch of directories for your project in the apps subdirectory. We're going to ignore most of them for the moment and focus on a few important ones

  C:\j2mewtk\apps\HelloProject - the main directory for your project
  C:\j2mewtk\apps\HelloProject\bin - where Ktoolbar stores .jar, .jar and manifest.mf files
  C:\j2mewtk\apps\HelloProject\classes - where the class files are stored
  C:\j2mewtk\apps\HelloProject\src - where the source .java files are stored
  

• Now, fire up your favourite text editor - I like Textpad- and type in the following code

  /* Hello Midlet - your first program*/
  import javax.microedition.lcdui.*;
  import javax.microedition.midlet.*;
  
  public class HelloMidlet
  extends MIDlet
  implements CommandListener {
  private Form mMainForm;
  
  public HelloMidlet() {
  mMainForm = new Form("HelloMidlet");
  mMainForm.append(new StringItem(null, "Hello, MIDP! \n\nYou and me - we're gonna make sweet MIDlets together! "));
  mMainForm.addCommand(new Command("Exit", Command.EXIT, 0));
  mMainForm.setCommandListener(this);
  }
  
  public void startApp() {
  Display.getDisplay(this).setCurrent(mMainForm);
  }
  
  public void pauseApp() {}
  
  public void destroyApp(boolean unconditional) {}
  
  public void commandAction(Command c, Displayable s) {
  notifyDestroyed();
  }
  }
  

• Save this file as HelloMidlet.java in the C:\j2mewtk\apps\HelloProject\src
• Go back to KToolBar - then click on Build and then Run - you should see something like this.
• Click on the Launch softkey in the emulator to get your MIDlet to say hello. You've just written your first MIDlet!

Provisioning

Okay, now how do I get my code onto my phone?

Once you've created your lovely little MIDlet and ensured that everything worked smoothly in the emulator, the next step is to get it running on an actual device. Provisioning is the name given to the process of deploying your application in such a way that it is easily downloaded and installed on the device.

1. Over The Air (OTA) Provisioning

OTA provisioning allows users to download your application wirelessly using the WAP browsers built into their phones. To begin, we need to take a look at the Java Application Descriptor (JAD) file that is created when you package a MIDlet using the J2ME Wireless Toolkit. The JAD file stores information about your application and lets you modify various parameters of the MIDlet suite such as where the icon resource can be found, which MIDlets are included and where you can download the full version of the application. To edit a JAD file using the Wireless Toolkit, open your project, then click on Settings. This will open up a new window with a number of tabs - API Selection, Required, Optional, User Defined, MIDlets, Push Registry and Permissions.

1. API Selection

   This is where you choose which version of MIDP your application will use and which optional packages (JSRs) are included. The default is set to JTWI (Java Technology for the Wireless Industry) which allows you to use MIDP 2.0 as well as MMAPI and other exciting things. If you're having any problems with your application on your device try changing this to MIDP 1.0.

2. Required

   This tab includes various options which are essential for packaging a MIDlet suite. The MIDlet-Jar-URL attribute is where we will define the location of the packaged JAR file to be downloaded to the device.

3. Optional

   This tab includes optional parameters for your MIDlet - such as the path to the icon for the entire suite, a description and a MIDlet-Info-URL parameter.

4. User Defined

   This tab includes user defined variables that your MIDlet can use - such as a common URL that you don't want to hard wire into the source code.

5. MIDlets

   This tab manages all the settings for the MIDlets within your suite. At the very least you need to have one file here. This is also where you set the path to the MIDlet's icon resource.

6. Push Registry

   This lets you configure the Push Registry which allows your MIDlet to listen and act on information received from a remote source. MIDP 2.0 Only.

7. Permissions

   Under MIDP 1.0, applications could only access libraries packaged inside the suite - this was called the sandbox model. MIDP 2.0 introduces the concept of trusted applications which allow access beyond the sandbox. This section allows you to specify which APIs are accessible.

For our purposes - the most important property is the MIDlet-Jar-URL within the Required tab. Here are the steps you need to take:

1. Create a folder on your web server

   Hopefully you have an account with a web provider - login to that account and create a directory for your MIDlets to live and be served from. I created the directory. Once you've got that, you need to make a few changes to allow your server (assumed to be Apache) to serve JAD and JAR files correctly. Go to the root of your account and edit or create your .htaccess file. Add these lines:
   
   AddType text/vnd.sun.j2me.app-descriptor jad
   AddType application/java-archive jar
   
   Save this file. If you're not using Apache, ensure that your MIME types include the above two settings.

2. Specify the MIDlet-Jar-URL

   Click on Settings then go to the Required Tab. In the MIDlet-Jar-URL field, fill in the absolute URL of your JAR file. This will normally be something like http://mydomain/mydir/HelloProject.jar. For my server, this was http://www.uberthings.com/mobile/midlets/HelloProject.jar.

3. Package your MIDlet

   Click on Project->Package->Create Package. This will create a .jar and a .jad file in your applications bin folder. For my application - this was c:\j2mewtk\apps\HelloProject\bin\HelloProject.jar and c:\j2mewtk\apps\HelloProject\bin\HelloProject.jad.

4. Upload the packaged MIDlet suite

   Upload the JAR and JAD files that the packaging operation created to the folder you created earlier.

5. Test with your device

   Open the WAP browser on your phone and point it to the URL of the JAD file. Using my example, this would be http://uberthings.com/mobile/midlets/HelloProject.jad. Your device should then prompt you to download and install the MIDlet. Carry it around and show it off to all your friends!

2. Cable / Bluetooth

If you've got a Bluetooth adaptor or a USB cable which connects directly to your phone, you can use this to quickly test your packaged midlet.

Windows XP/2000: Browse to the bin folder of your project, right click on the .jar file and select Send To->Bluetooth->YOURDEVICE.
MacOS X: Click on the Bluetooth icon in the menu bar, choose Send File. Send it to your device.
This should send a message to your phone which will install the MIDlet once opened. This should work on most Nokia Series 60 phones (3650, 6600, N-Gage etc).

Source : uberthings

Remember God...