Share your knowledge and create a knowledgebase.

Archive for the ‘Strategy’ Category



I have known that there are basic differences between Linux and Windows that will always set them apart. This is not, in the least, to say one is better than the other. It’s just to say that they are fundamentally different. Many people, looking from the view of one operating system or the other, don’t quite get the differences between these two powerhouses.

1: Full access vs. no access

Linux belongs to the GNU Public License ensures that users (of all sorts) can access (and alter) the code to the very kernel that serves as the foundation of the Linux operating system. You want to peer at the Windows code? Good luck. Unless you are a member of a very select (and elite, to many) group, you will never lay eyes on code making up the Windows operating system.

You can look at this from both sides of the fence. Some say giving the public access to the code opens the operating system (and the software that runs on top of it) to malicious developers who will take advantage of any weakness they find. Others say that having full access to the code helps bring about faster improvements and bug fixes to keep those malicious developers from being able to bring the system down. I have, on occasion, dipped into the code of one Linux application or another, and when all was said and done, was happy with the results. Could I have done that with a closed-source Windows application? No.

2: Licensing freedom vs. licensing restrictions

With a Linux GPL-licensed operating system, you are free to modify that software and use and even republish or sell it (so long as you make the code available). Also, with the GPL, you can download a single copy of a Linux distribution (or application) and install it on as many machines as you like. With the Microsoft license, you can do none of the above. You are bound to the number of licenses you purchase, so if you purchase 10 licenses, you can legally install that operating system (or application) on only 10 machines.

3: Online peer support vs. paid help-desk support

This is one issue where most companies turn their backs on Linux. But it’s really not necessary. With Linux, you have the support of a huge community via forums, online search, and plenty of dedicated Web sites. And of course, if you feel the need, you can purchase support contracts from some of the bigger Linux companies (Red Hat and Novell for instance). Still, generally speaking, most problems with Linux have been encountered and documented. So chances are good you’ll find your solution fairly quickly.

Yes, you can go the same route with Microsoft and depend upon your peers for solutions. There are just as many help sites/lists/forums for Windows as there are for Linux. And you can purchase support from Microsoft itself. Most corporate higher-ups easily fall victim to the safety net that having a support contract brings. But most higher-ups haven’t had to depend up on said support contract. Of the various people I know who have used either a Linux paid support contract or a Microsoft paid support contract, I can’t say one was more pleased than the other. This of course begs the question “Why do so many say that Microsoft support is superior to Linux paid support?”

4: Full vs. partial hardware support

Years ago, if you wanted to install Linux on a machine you had to make sure you hand-picked each piece of hardware or your installation would not work 100 percent. This is not so much the case now. You can grab a PC (or laptop) and most likely get one or more Linux distributions to install and work nearly 100 percent. But there are still some exceptions. For instance, hibernate/suspend remains a problem with many laptops, although it has come a long way.

With Windows, you know that most every piece of hardware will work with the operating system. Of course, there are times (and I have experienced this over and over) when you will wind up spending much of the day searching for the correct drivers for that piece of hardware you no longer have the install disk for. But you can go out and buy that 10-cent Ethernet card and know it’ll work on your machine (so long as you have, or can find, the drivers). You also can rest assured that when you purchase that insanely powerful graphics card, you will probably be able to take full advantage of its power.

5: Command line vs. no command line

No matter how far the Linux operating system has come and how amazing the desktop environment becomes, the command line will always be an invaluable tool for administration purposes. Nothing will ever replace my favorite text-based editor, ssh, and any given command-line tool. I can’t imagine administering a Linux machine without the command line. But for the end user — not so much. You could use a Linux machine for years and never touch the command line. Same with Windows. You can still use the command line with Windows, but not nearly to the extent as with Linux. And Microsoft tends to obfuscate the command prompt from users. Without going to Run and entering cmd (or command, or whichever it is these days), the user won’t even know the command-line tool exists. And if a user does get the Windows command line up and running, how useful is it really?

6: Centralized vs. noncentralized application installation

With Linux you have (with nearly every distribution) a centralized location where you can search for, add, or remove software. I’m talking about package management systems, such as Synaptic. With Synaptic, you can open up one tool, search for an application (or group of applications), and install that application without having to do any Web searching (or purchasing).

With Windows, you must know where to find the software you want to install, download the software (or put the CD into your machine), and run setup.exe or install.exe with a simple double-click. For many years, it was thought that installing applications on Windows was far easier than on Linux. And for many years, that thought was right on target. Not so much now. Installation under Linux is simple, painless, and centralized.

7: Flexibility vs. rigidity

I always compare Linux (especially the desktop) and Windows to a room where the floor and ceiling are either movable or not. With Linux, you have a room where the floor and ceiling can be raised or lowered, at will, as high or low as you want to make them. With Windows, that floor and ceiling are immovable. You can’t go further than Microsoft has deemed it necessary to go.

Take, for instance, the desktop. Unless you are willing to pay for and install a third-party application that can alter the desktop appearance, with Windows you are stuck with what Microsoft has declared is the ideal desktop for you. With Linux, you can pretty much make your desktop look and feel exactly how you want/need. You can have as much or as little on your desktop as you want. From simple flat Fluxbox to a full-blown 3D Compiz experience, the Linux desktop is as flexible an environment as there is on a computer.

8: Fanboys vs. corporate types

I wanted to add this because even though Linux has reached well beyond its school-project roots, Linux users tend to be soapbox-dwelling fanatics who are quick to spout off about why you should be choosing Linux over Windows. I am guilty of this on a daily basis (I try hard to recruit new fanboys/girls), and it’s a badge I wear proudly. Of course, this is seen as less than professional by some. After all, why would something worthy of a corporate environment have or need cheerleaders? Shouldn’t the software sell itself? Because of the open source nature of Linux, it has to make do without the help of the marketing budgets and deep pockets of Microsoft. With that comes the need for fans to help spread the word. And word of mouth is the best friend of Linux.

Some see the fanaticism as the same college-level hoorah that keeps Linux in the basements for LUG meetings and science projects. But I beg to differ. Another company, thanks to the phenomenon of a simple music player and phone, has fallen into the same fanboy fanaticism, and yet that company’s image has not been besmirched because of that fanaticism. Windows does not have these same fans. Instead, Windows has a league of paper-certified administrators who believe the hype when they hear the misrepresented market share numbers reassuring them they will be employable until the end of time.

9: Automated vs. nonautomated removable media

I remember the days of old when you had to mount your floppy to use it and unmount it to remove it. Well, those times are drawing to a close — but not completely. One issue that plagues new Linux users is how removable media is used. The idea of having to manually “mount” a CD drive to access the contents of a CD is completely foreign to new users. There is a reason this is the way it is. Because Linux has always been a multiuser platform, it was thought that forcing a user to mount a media to use it would keep the user’s files from being overwritten by another user. Think about it: On a multiuser system, if everyone had instant access to a disk that had been inserted, what would stop them from deleting or overwriting a file you had just added to the media? Things have now evolved to the point where Linux subsystems are set up so that you can use a removable device in the same way you use them in Windows. But it’s not the norm. And besides, who doesn’t want to manually edit the /etc/fstab fle?

10: Multilayered run levels vs. a single-layered run level

I couldn’t figure out how best to title this point, so I went with a description. What I’m talking about is Linux’ inherent ability to stop at different run levels. With this, you can work from either the command line (run level 3) or the GUI (run level 5). This can really save your socks when X Windows is fubared and you need to figure out the problem. You can do this by booting into run level 3, logging in as root, and finding/fixing the problem.

With Windows, you’re lucky to get to a command line via safe mode — and then you may or may not have the tools you need to fix the problem. In Linux, even in run level 3, you can still get and install a tool to help you out (hello apt-get install APPLICATION via the command line). Having different run levels is helpful in another way. Say the machine in question is a Web or mail server. You want to give it all the memory you have, so you don’t want the machine to boot into run level 5. However, there are times when you do want the GUI for administrative purposes (even though you can fully administer a Linux server from the command line). Because you can run the startx command from the command line at run level 3, you can still start up X Windows and have your GUI as well. With Windows, you are stuck at the Graphical run level unless you hit a serious problem.

Your call…

Those are 10 fundamental differences between Linux and Windows. You can decide for yourself whether you think those differences give the advantage to one operating system or the other. Lets debate and find out..


Aug 27, 2008 Author: Ashish | Filed under: Strategy

When it comes to programming, more specifically the development of web applications, it is important to consider all the tools of the trade before using the one that is going to be used for the job.

PHP is great. With the release at the time of PHP 4 and now its time for PHP 6. it’’s initial object functionality I started to get up to speed with many of the OOP principles. I was building some pretty amazing Content Management Systems, Digital Asset Management Systems, even Web Top Publishing Systems. My previous commitment to learn Java was fading as my experience grew with PHP was growing, seeing that I could build all the amazing things with what I had originally felt was a subordinate language.

We have search the performance for the PHP and many other languages like python,Perl,java,Vb,and finally ruby, below the difference between all the programming languages as graph which shows the future for the PHP.

Following graph shows the new lines of code in various languages in recent years

Newlinesofcode

PHP dominates the new lines of code and only PHP and Ruby are on a steady curve upward.  Yeah – I know that “number of lines of code” is not a great measure, but none of these languages are overly verbose so it’s an interesting proxy metric.

Activedevs

Active developers tells a different story.  While PHP is growing a little relative to the others, they all seem to have a relatively flat curve.  The well known shortage of Ruby developers is reinforced by this data, as well as the next graph.

Newprojects

Comparison between all the programing language..

Does it prove anything?

This was the chart I found really interesting.  Ruby is clearly the trendy new language.  Given normal supply / demand lags, you’d expect that this is a leading indicator of a significant uptick for Ruby on the other two charts in 2007.  My conclusion is different than Robin’s – while PHP appears to be dominant today, the rapid growth in new projects in Ruby indicates that it is currently positioned as “the language of the next wave of applications.”  This is consistent with what I’m hearing and seeing from many new startups.

Conclusion

I suspect very few people will argue that PHP is a more elegant language or is more powerful than Ruby. Frankly, Ruby is probably may favorite language that I have ever worked with and I have worked with Classic ASP, ASP.NET, VB.NET, C#, Java, and Perl all rather extensively over the years. Ruby is both highly expressive and concise which is rare and refreshing.

Rails is a very comprehensive and effective web development Framework and there’s nothing exactly like it in PHP. You get a huge amount of functionality for free. Developing in Ruby on Rails is also a very fast process because Ruby is a very concise language requiring much less typing than any other language I’ve worked with. Code Igniter is a really nice PHP framework. It will give you a great boost when developing your next PHP application.

The hosting and deployment struggles with Ruby on Rails is a major sticking point for me though. As the owner of a web development company many of our smaller clients do not have the budget for their own VPS account and even if they did, we don’t have the staff to manage a large number of VPS accounts or dedicated servers. Keeping the security updates current, managing any issues that may occur with email, and all the other headaches that go along with managing your own VPS or Dedicated server is more than we care to take on for the relatively small, practical difference between PHP and Ruby. For large projects, it may be worth the trouble, but for small to medium sized projects, PHP is much easier to deploy, less expensive to host, and the language is capable of taking on everything those types of sites require. For our projects, development time with PHP is not noticeably longer than with Ruby on Rails. Ruby on Rails integrates a lot of things for the developer.

There is ActiveRecord for managing the link between models and the database, migrations for keeping development and live databases in sync, built in testing, the ajax – prototype javascript library is included, and you get a well defined file system structure. While it may not all be packaged together as well, PHP can do all of the above.

Thank you for reading this and I would love to read your comments! Also subscribe to our RSS.


Aug 25, 2008 Author: kailashK | Filed under: Development Process, Programming

Normalisation is the term used to describe how you break a file down into tables to create a database. There are 3 or 4 major steps involved known as 1NF (First Normal Form), 2NF (Second Normal Form), 3NF (Third Normal Form) and BCNF (Boyce-Codd Normal Form). There are others but they are rarely if ever used. A database is said to be Normalised if it is in 3NF (or ideally in BCNF). These steps are descibed as follows:

Note: When attribute is used we are speaking of a field in the table

1NF
To put a database in 1N

  • ensure that all attributes (columns) are atomic (which means that any single field should only have a value for ONE thing).

Examples:

In a database a table on Customers would have an address attribute. The address is made up of Company Name, Address Line1, Address Line2, Address Line3, City, Postcode. There are 6 values to this address and as such each should have it’s own field (column).

If your company sold furniture a table on products could have a description attribute. If for example that attribute was ‘Beech Desk 120w x 75h x 50d’. Ideally this would be broken down into a number attributes like ‘Colour’, ‘Type’, ‘Width’, ‘Height’ and ‘Depth’. The reason for this is it would allow you to seach the database for all Desks, for all pieces of Beech furniture, for all desks with a width of 120 etc.

  • Create a separate table for each set of related data and Identify each set of related data with a primary key

Example:


In a general Invoicing table you would have a separate table for Customers, Orders, Products, Invoices and you would probably need tables for OrderDetails and InvoiceDetails as well. Each of these tables must have their own primary key. Each of these tables except for customers would have a foreign key reference to the primary key of another table. (See Relationships below)

  • Do not use multiple fields in a single table to store similar data

Example:
(Underlined fields are Primary Keys and Italicised fields are Foreign Keys)

In a customer order you could have more than one product. That is the customer has ordered more than one item. If you tried to put all of this in one table as {OrderID, CustomerID, OrderDate, Product1, Product2, Product3} what would happen if the customer ordered more than 3 products. There would also be implications for querying the kind or quantiy of products ordered by a customer. Therefore these product fields don’t belong in the order table which is why we would have an OrderDetails table which would have a foreign key refernce to the Orders table {OrderDetailsID, OrderID, ProductID, Quantity}. Using productID as a foreign key to the product table means you don’t have to identify the product attributes here. This also allows you to enter a quantity figure for the product ordered.

Relationships:

All tables should have a 1 to 1 or 1 to many relationship. This means for example that 1 customer can have 1 or many orders and 1 order can have 1 or many details.

normalization_tblDiagram2 Database Normalization and Table structures

Therefore Orders table would have a foreign key reference to the Customer table primary key {OrderID, CustomerID, OrderDate} and the OrderDetails table would have a foreign key reference to the Order table primary key {OrderDetailsID, OrderID, ProductID, Quantity}. This table also contains a foreign key reference to the Products table. As a product is likely to be ordered more than once there is a many to 1 relationship between the OrderDetails and the Products table.

normalization_tblDiagram3 Database Normalization and Table structures

If any tables have a many to many relationship this must be broken out using a JOIN table. For example, Customers can have many Suppliers and Suppliers can supply to many Customers. This is known as a many to many relationship. You would need to create a JOIN table that would have a primary key made up of a foreign key reference to the Customers table and a foreign key reference to the suppliers table. Therefore the SuppliersPerCustomer table would be {SupplierID,CustomerID}. Now the Suppliers table will have a 1 to many relationship with the SuppliersPerCustomer table and the Customers table will also have a 1 to many relationship with the SuppliersPerCustomer table.

2NF

The database must meet all the requirements of the 1NF.

In addition, records should not depend on anything other than a table’s primary key (a primary key can be made up of more than one field, only if absolutely necessary like in a JOIN table).

Example:

A customers address is needed by the Customers table, but also by the Orders, and Invoices tables. Instead of storing the customer’s address as a separate entry in each of these tables, store it in one place, either in the Customers table or in a separate Addresses table.

3NF

The database must meet all the requirements of the 1NF and 2NF.

The third normal form requires that all columns in a relational table are dependent only upon the primary key. A more formal definition is:

  • A relational table is in third normal form (3NF) if it is already in 2NF and every non-key column is non transitively dependent upon its primary key.

In other words, all nonkey attributes are functionally dependent only upon the primary key. All 3NF really means is that all fields (attributes) should be dependent on the tables primary key. If they are not they should be put in their own table. This means that every attribute unless it is a primary or foreign key must be DIRECTLY dependent on the Primary Key of this table and not on some other column.

Example:

The Customer table contains information such as address, city, postcode imagine it also contained a column called shipping cost. The value of shipping cost changes in relation to which city the products are being delivered to, and therefore is not directly dependent on the customer even though the cost might not change per customer, but it is dependent on the city that the customer is in. Therefore we would need to create another separate table to hold the information about cities and shipping costs.

BCNF

A relation is in Boyce-Codd Normal Form (BCNF) if every determinant is a candidate key. BCNF is very similar to 3NF but deals with dependencies within the primary keys. BCNF in it’s simplist terms just says don’t have a primary key made up of more than one field unless it is a join table to disperse a many to many relationship and only contains the two primary keys of the tables it is joining.

Most relations that are in 3NF are also in BCNF. It only happens that a relation which is in 3NF is not in BCNF when the primary key in a table is made up of more than one field and the other columns are not dependent on both fields but only on one or the other.


Jun 3, 2008 Author: Ashish | Filed under: Design Principles, MySQL

When it comes to building and implementing an IT policy, no quick-fix or one-size-fits-all solution will adequately serve your needs. Every business is different, and the approach taken to meet objectives and/or ensure compliance will vary from one environment to another, even in the same industries. But you can take advantage of certain best practices to increase your odds of crafting and implementing a policy that employees will support and that will help protect your organisation.

Executive support

For starters, no policy will succeed without the basic buy-in from senior leadership. Senior executives, directors, and managers should be asked to provide input and some form of approval to the policy. Obtain a clear statement of support before you start creating the policy and continue to keep senior management educated and involved as it is written. When the policy is ready for implementation, request that management formally present it to your organisation, stressing its importance.

Consensus building

As you begin formulating a policy, you should involve all interested parties in the discussion of its establishment by creating a committee. Your committee should consist of the owner of the policy, subject matter experts, frequent users of the policy, and representatives from groups affected by the policy. You may also want to consult specific groups within your particular organisation, such as Human Resources, Financial, and Legal. These groups can make recommendations based on the impact of the policy on the organisation as well as on its viability and legitimacy. This will ensure the policy you develop is fully understood by everyone concerned and that it has their backing once it’s implemented. That broad base of support is one of the best assurances for policy success.

Policy contents

Although policies vary from organisation to organisation, a typical policy should include a statement of purpose, description of the users affected, history of revisions (if applicable), definitions of any special terms, and specific policy instructions from management.

Make sure everyone has a clear understanding of the purpose of the policy. Are you creating this policy because you have to be in compliance with some ruling? Are you trying to cut down on costs or create additional savings? Are you ensuring liability will not be placed on the company?

Creating a uniform policy format to ensure that information will be presented to the reader in a consistent manner is paramount for policy success. A uniform format will make the policy easier to read, understand, implement, and enforce. Keep the scope of your policies manageable as well. Consider making separate, smaller polices that address specific needs.

The language of your policies must convey both certainty and unquestionable management support. Remember, you’re setting policy, not describing standards. A standard would, for example, define the number of secret key bits that are required in an encryption algorithm. A policy, on the other hand, would dictate the need to use an approved encryption process when sensitive information is sent over the public Internet system.

Standards will need to be changed considerably more often than policies because the manual procedures, organisational structures, business processes, and information system technologies change much more rapidly than policies. You can reference standards within a policy and modify that standard as the technology or compliance requirements change.

After you roll out a policy, you may see many examples of inappropriate use or violations, but it’s difficult to anticipate them. So it’s important to have catch-all clauses within your policies, such as:

  • “Viewing or downloading offensive, obscene, or inappropriate material from any source is forbidden.”
  • “The storing and transfer of illegal images, data, material, and/or text using this equipment is forbidden.”

Research and preparation

In drafting your policy, you will want to research related issues both inside and outside the company. Some common areas to research include:

  • Company policy library (if you have one)
  • Forms and documents required to develop or complete the policy: request forms, legal documentation, etc.
  • State and or federal laws that are relevant to your policy
  • Similar policies at other businesses

One of the biggest mistakes many companies often make when they begin designing policies is to create guidelines and restrictions without any understanding of how the company’s business actually works. Although there’s always going to be a factor of inconvenience with any security policy, the goal is to create a more secure environment without making things overly difficult or hard to understand for the people having to use the resources the policy is trying to protect.

Policies made outside the company’s business model will begin to become circumvented over a period of time and the overall environmental state can become worse than before the security measures were implemented. So make sure part of your research involves developing a solid understanding of business processes so that your policy can work with them, rather than against them.

Policy reviews

Even after you’ve finished drafting or updating a policy, the job is not complete. The policy should be reviewed by legal counsel to ensure that it complies with state and federal laws before it’s finalised and distributed to employees. Further, you should review the policies on a regular basis to make sure they continue to comply with applicable law and the needs of your organisation. New laws, regulations, and court cases can affect both the language of your policies and how you implement them.

Most experts suggest a thorough review of your policies at least once a year and the use of a dedicated notification system/service to keep employees informed of changes. And when revised policies are introduced, you should formally distribute and thoroughly explain them to all employees.

Policy pointers

  • Consider holding (depending on the size of your company) a series of meetings that involves all interested parties.
  • Do not fill policies with “techie” terms. Polices must be written in layman’s terms or the concepts may be lost on the end users.
  • Set out what behavior is reasonable and unreasonable and determine procedures for dealing with specific abuses.
  • Try to keep polices to the point. Long written polices are difficult to read and comprehend, and users may be confused or simply give up on trying to understand them.
  • Agree upon a framework for policy review. Usage and technology may change, so you need to be flexible and adapt the policy when it is required.
  • Decide, define and mandate “what” is to be protected.

Done right…

Well-crafted policies show that an organisation and its management are committed to security and expect employees to take it seriously. Such policies provide an overall security framework for the organisation, ensuring that security efforts are consistent and integrated rather than ad hoc or fragmented. A good, regularly reviewed policy can be both an effective employee relations tool and a helpful defense against lawsuits. In contrast, policies that are poorly drafted or misapplied can decrease efficiencies and create roadblocks for normal business activities. Invest the necessary amount of time and effort to make sure your policies are solidly built and properly implemented.


May 12, 2008 Author: Ashish | Filed under: Development Process, Strategy

Identity theft may be on the rise, but you don’t have to make it easy for thieves — take steps to protect the personally identifiable information (PII) of your employees and clients.

Is your organization part of the solution or part of the problem? PII is pouring through the security floodgates and ending up in the wrong hands at an alarming rate.

To protect your organization’s employees and clients, you need to evaluate how well your company protects its PII. Here are seven common mistakes to avoid.

Keep users in the dark

Users will always be the weakest link in any enterprise network — and all of the gadgets and controls in the world won’t change that. If your users don’t know how to identify and handle PII, it’s only a matter of time before one of them discloses this data to the wrong source.

The solution is simple: Educate your users on your company’s policies and mechanisms to process PII. And don’t forget to include regularly scheduled refresher courses.

Partner with the wrong businesses

You’ve made sure your security is rock solid, and you’ve trained your users. But can your business partners say the same? Do you collect or share information with businesses that have little or no security?

If your company collects and shares PII with insecure partners, who do you think will end up in the paper and explaining to law enforcement about how a breach occurred? Your company will.

The solution is just as simple as the last dilemma: Educate and train your business partners on how to protect this sensitive information.Charge them for your expertise if you want, but get the job done.

Keep data around past its prime

What do you do with data once it’s served its purpose? If you aren’t destroying PII when it’s no longer required, then you’re not doing your job. That doesn’t mean throwing it away either — that means destroying it.

Dumpster divers make a living off of old bank statements and credit card receipts. That’s why you need to wipe out PII when it’s no longer necessary.If your organization doesn’t have a shredder, you need to get one today.

Don’t worry about physical security

It’s imperative that you implement physical access controls to prevent unauthorized people — including employees — from gaining access to PII. Get a door lock and a badge reader, and start controlling access.

Don’t lock up your records

If you don’t have specific storage areas on your network (as well as file cabinets) for PII, then how can your properly protect it? Take inventory of your network — and your paper copies — and develop a plan to protect that data. This would be a good time to research encrypting data-at-rest and locking some file cabinets.

Ignore activity on your network

I’ve said this before in columns, but it’s worth repeating: If you’re not going to actively monitor your network for suspicious activity or incidents, then stop collecting the data. Develop a method that’s within your capabilities and budget to monitor your network for suspicious activity or incidents. And while you’re at it, develop a response and mitigation strategy for security incidents.

Audits? Who needs audits?

A lot of businesses either don’t know what security events to audit or don’t read their security logs — or both. If you’re not sure which events to audit, find out. Set up security auditing, and start reviewing your logs today.

Final thoughts

Identity theft may be on the rise, but you don’t have to make it easy for thieves. You can help prevent identity theft both at home and at the office — you just need to take a few extra steps.


May 12, 2008 Author: Ashish | Filed under: Design Principles, Strategy

Advertisement

Adsense