Thursday, August 28, 2014

Code Smell

A code smell is an indication of the presence of an underlying problem within a software code. It could indicate a problem with s/w design, or architecture. Code smells are symptomatic of a system bottleneck that prevents / limits the development of s/w or increases the likelihood of a s/w failure.


- Code Smell

- Design Smell

- Architecture Smell


Common Code Smells (Wikipedia)

  1. Duplicated code: identical or very similar code exists in more than one location.
  2. Long method: a method, function, or procedure that has grown too large.
  3. Large class: a class that has grown too large. See God object.
  4. Too many parameters: a long list of parameters is hard to read, and makes calling and testing the function complicated. It may indicate that the purpose of the function is ill-conceived and that the code should be refactored so responsibility is assigned in a more clean-cut way.
  5. Feature envy: a class that uses methods of another class excessively.
  6. Inappropriate intimacy: a class that has dependencies on implementation details of another class.
  7. Refused bequest: a class that overrides a method of a base class in such a way that the contract of the base class is not honored by the derived class. See Liskov substitution principle.
  8. Lazy class / Freeloader: a class that does too little.
  9. Contrived complexity: forced usage of overly complicated design patterns where simpler design would suffice.
  10. Excessively long identifiers: in particular, the use of naming conventions to provide disambiguation that should be implicit in the software architecture.
  11. Excessively short identifiers: the name of a variable should reflect its function unless the function is obvious.
  12. Excessive use of literals: these should be coded as named constants, to improve readability and to avoid programming errors. Additionally, literals can and should be externalized into resource files/scripts where possible, to facilitate localization of software if it is intended to be deployed in different regions.
  13. Ubercallback: a callback that is trying to do everything
  14. Cyclomatic complexity: too many branches or loops; this may indicate a function needs to be broken up into smaller functions, or that it has potential for simplification

Friday, July 25, 2014

Saturday, July 19, 2014

PYPL - Popularity of Programming Languages, SWIFT new entrant in top 10

Apple's Swift launched last month now features in the top ten on PYPL charts holding a 3% share.

Read the full article here:

Wednesday, July 09, 2014

Developer to Tester Ratio


A nice article by Randall Rice on why asking for a developer to tester ratio is inappropriate, and what must be done to properly plan for test resources in a team.

Sunday, May 11, 2014

Wednesday, April 30, 2014

What happened to IPV4 Address Crisis?

Read it here:

The day of reckoning still looms -- it's just been pushed out as the major Internet players have developed ingenious ways to stretch those available numbers. But these conservation efforts can only work for so long.

IPv6 uses a 128-bit address space -- that is, 2^128 -- yielding far more potential addresses than IPv4's 32-bit scheme, and in fact more addresses than there are grains of sand in the Earth's crust.

So, why hasn't everyone just switched over to IPv6?

Well, IPv6 is not backward compatible with IPv4, meaning network operators need to run a dual stack IPv4/IPv6 network for years to come. And for IPv6 to work, it needs to be implemented end to end, meaning IPv6 has to be enabled by network hardware vendors, transit providers, access providers, content providers, and endpoint hardware makers.

Since there's no economic incentive to being the first to invest in revamping your protocol support, many hardware and service providers stood on the sidelines and waited for momentum to build.

For enterprises, it made no sense to upgrade to IPv6 if their ISPs were still running IPv4. As John Brzozowski, fellow and chief architect for IPv6 at Comcast Cable, puts it: We had a chicken-and-egg problem. "Service providers didn't want to implement IPv6 because the content providers weren't there, and content providers didn't want to implement it because the service providers weren't there."

Plus, there were ways to avoid having to face the IPv6 music. One common technique iscarrier-grade network (CGN) address translation (NAT), which translates private IP addresses within a carrier's network to a smaller number of public IP addresses in much the same way that ordinary NAT lets individuals and organisations use multiple internal IP addresses.

However, CGN brings with it a number of issues that limit its appeal. For one thing, it's expensive for carriers, and the money they spend on it could be more productively applied to IPv6-ready hardware. For another, a great deal of Internet infrastructure relies on the premise that a single public IP address uniquely identifies a carrier subscriber. CGN breaks that assumption, which means that it breaks geolocation services and impedes law enforcement organisations' ability to identify users.

Converged Infrastructure...

This figure is from HP and John Wiley & Sons, and represents the complexities that Siloed IT creates.
Let us consider a fictitious company XYX, Inc., which is into Product Development. To make matters simple, let us assume the Company’s IT division uses SAP, Remedy for case management, an online store to market its product; For actual product development, the company uses JSP/.NET which is integrated to its SAP CRM module; it also let us say doesn’t use the SAP HR module and employs PeopleSoft. Then there are two more tools – JIRA for defect management and HP Quality Centre for Test Management.

In all, these are the applications:

·         SAP
·         Remedy
·         Online Store
·         Web Application to interact with SAP CRM
·         PeopleSoft
·         JIRA
·         HP QC

Now, for all these applications, we will need appropriate infrastructure to host them (Physical/virtual Servers, Storage/private public cloud, Networking, Security, Power, etc.). In a typical organization not focusing on infra optimization, typically the above workflow applies for each application. So, every demand for infrastructure goes thru the above process, which can take from weeks to months for a single deployment & commissioning. This should be okay for small organizations with limited software setup and infra needs, although the fact that each set up will be a silo in itself without having the ability to talk to another system is crippling. Also appreciate the fact that, it is not uncommon to see multiple versions of the same tool across different business units. Eventually you have siloed systems spawning even more complexity as the need multiplies, resulting in what is called an IT Sprawl.  

The downside of self-contained infra setups is the enormous duplication of work across business units for the system support and upkeep.

This is where converged infrastructure comes into picture. In this scenario, these entire infrastructures - (Physical/virtual Servers, Storage, Networking, Security, Power, etc.) are integrated with the primary objective of sharing and interoperability. For example, if you have a storage server for HP QC and JIRA having several gigs of space at disposal, you could use it for other application.

Converged infrastructure advances the Shared Services Model by emphasising the need for common processes, human resources.

Read in detail about Shared Infrastructure Here – HP Converged Infrastructure for Dummies