Creativity by Rinku - Family/Apple tree

Creativity by Rinku - Best out of waste (Toy Train)

Toy train made up of match box

• Bogies are made up of Match box 
• Tyres are buttons
• Tracks are made up of sticks and matches

Creativity by Rinku - Best out of waste (House)

• Roof is made up of Pista shells
• Clouds are made up of Cotton
• Sun is Button
• Chimney borders are made up of sticks
• House black border is made of woolen threads
• Window's are made up of Aluminium foil
• Window's red border is made up of Red woolen threads
• Garden is made up of small chopped hand made paper
• Door handle and railings are made up of glitters

After Rinku's magical touch

Creativity by Rinku - Mural Name plate

Reading last few lines from a log file using perl

Hi,

Today I will explain you the program which will help you read whole log file or last given number of lines in a file.

use strict;

my $argc = scalar(@ARGV);

# validate command line arguments
if ($argc eq 0)
{
    print "Error :: Log file not provided\n";
    print "\nUsage\n\n";
    print "$0 \n";
    print "where,\n";
    print "log file name = Fully qualified name of the log file\n";
    print "number of last records = Optional parameter.  Specify the number of last  records you want to read\n";
    exit;
}
my $log_file = $ARGV[0];
my $number_of_records = $ARGV[1];

if (not defined $number_of_records)
{
    $number_of_records = "";
}

unless (-e $log_file)
{
    die "Error :: $log_file doesn't exist\n";
}

# Define variables.

my $current_line = 0; # determine current position in file
my $seek_line = 0; # determines line number where we want to jump and start reading


# Get total number of lines from the file
open (FI, $log_file) or die $!;
while ()
{}
my $lines = $.;
close(FI);

print "\nTotal number of lines in file = $lines\n";

if ($number_of_records ne "")
{
    $seek_line = $lines - $number_of_records;
}

print "Seeking line number $seek_line\n";

open (LOG, $log_file) or die $!;
while ()
{
    my $str = $_;

    $current_line++;
    next if ($current_line <= $seek_line);

    chomp ($str);
    print "line number $current_line: $str\n";
}
close(LOG);

Common programming mistakes

Every programmer makes mistake and this is accepted globally as unwritten truth.  And most of the time developer doesn't know what mistakes they are making.  Here are my list of top mistakes to avoid.

Lack of security

There are two aspects programmers forget while coding the system.

1. Strategic aspects
Most programmers start coding the applications with the view of implementing the features from the default security perspective of "allowing all" the user to access and then will start to implement security for the elements (See Tactical aspects & suggestion on which elements to secure).
This happens across the board. Everything from operating systems to fat clients to web-based thin clients are constructed this way.

My strategic suggestion is to start coding from a default perspective of giving "deny all" access to every architectural element, every layer, every object, every method, every variable, etc., and construct them to be inaccessible to anything unless you expressly allow it. This will slow down your productivity a little (at least at first). However, once system is coded this way the delivered code and system will be vastly more secure.

Also, another rule for programmer is "Don't roll your own" or "Don't reinvent the wheel".   Unless you are yourself a security expert and/or cryptographer, always use a well-designed, well-tested, and mature security platform, framework, or library to do the work for you. These things have spent years being thought out, patched, updated, and examined by experts and hackers alike. You want to gain those advantages, not dismiss them by trying to reinvent the wheel.

Now, that's not to say you don't need to learn anything about security. You certainly need to know enough to understand what you're doing and make sure you're using the tools correctly. However, if you ever find yourself about to start writing your own cryptography algorithm, authentication system, input sanitizer, etc, stop, take a step back, and remember this rule.

2. Tactical aspects
In Tactical aspects, here are the common mistakes while coding security and things which every programmer should care about while coding the system.

• Not validating every bit of data from the client and user inputs
• Not considering filesystem permissions when working with files
• Not thinking about the database access permissions and keeping it too wide open for example, providing read-write access where only read is required
• Storing sensitive data in clear text like passwords, etc
• Not enforcing the strong passwords
• Thinking the user sees the system the programmer sees it
• Assuming system will never be attacked
• Thinking its Network Admin's responsibilities to provide security to the Network and applications
• Sending the sensitive data in query strings in websites
• Not taking care of hacking techniques like cross-scripting, SQL injections, etc
• Using third party libraries hastily without validating them
• Thinking login is the only page where security is needed.
• Creating backdoors for Administrative purposes

Improper Code Formatting

Easiest way to differentiate between experienced and inexperienced programmer is how they format their code.  Most of the programming languages doesn't give error because of bad formatting of the code like indentation, use of white space, etc but it makes code extremely unmanageable if its not formatted properly.  Programmers don't understand that indenting code makes one logical structure.  By indenting (using tabs and spaces) functions, loop, conditions, etc makes code readable and manageable not only for others but for ourselves as well. Bad formatted code becomes error prone and difficult to debug.

Another bad habit programmers have is to leave huge chunk of non-required commented code.  Almost everyone do this mistake thinking that we might need this in the future.  Its always good to remove the commented code if its not required.

Improper Variable and/or Function name

Sometimes its looks funny to us when some programmers use long function or variable names like fileForReading, but its actually good to have long meaningful name rather than short meaningless name.   If we give meaningful names to variables and functions then its intent becomes very clear not only while coding for the first time but also during the maintenance.  This will result in less errors as well because using non-meaningful name makes the probability of getting confused why this function and/or variable is created. Worst mistake developer can make is do the spelling mistakes while creating the variable names. It becomes difficult to remember the misspelt variable name and in high probability you will end up causing too many compiler errors. Its always better each developer makes its own naming convention as per their convenience as this will make them write the code faster and will reduce the compiler errors  as well.


Case sensitivity
Some programming languages are case sensitive and some are not. But its always better to use the cases (upper or lower) of the variable and function name properly.  This is also true while creating the hyperlinks and referencing the files.  Windows is case insensitive so it doesn't matter if you use /program or /Program but it does matter in non-windows platforms.  And when you are writing platform independent code always be careful about cases of the objects you use.  Also, each programming language comes with its own convention like Java recommends to use camel case convention where starting letter of first word should be in lowercase and starting letter of remaining words should be in upper case.  Java doesn't throw error if this convention is not used but it looks odd when this is not followed.

Lack of commenting and/or overcommenting

Lack of commenting and doing over-commenting both are crime.  Everyone should self-document their code where programmer explains the use of the variable, function and class names, and overall architecture and communicate the meaning of the code to other programmers and your future self without the need for lengthy comments. Whereas, over-commenting is also not required for example for code $a = $b; developer writes the comment like assigning value of $b to $a.  Even layman programmer can understand what is being done here.  These kind of commenting is useless.  Instead programmers should write why this is done.  We don't need to teach programing language in our code instead we should document how this program works

Not taking backup of your work

How many times does it happen to you that you lost important and good piece of work because you forgot to take backup or saved your programs and your machine restarted or malfunctioned.  There are ample tools available in market now which gives you benefit like auto-saving, versioning control system, etc.  While working on the open source projects I keep checking-in my code into SVN repository or Github which are free to use softwares.

Not using debugging tools

Almost every programming language comes with powerful debugging tool which gives detail errors and help you identify the bugs in your code easily. Some programming languages doesn't comes with inbuilt debugging tools and in that case printing the statement on console or external debugging tools are quite useful.  For example, while doing the web programming, I found developer tools like firebug extremely useful in not only finding the code issues but also the performance issues also.

Start coding without understanding the programming language

Programming languages are no different than our languages which we speak.  Programming languages have vocabulary, grammar and recommendations on how to use it.  Major mistake newbies usually do is start coding the stuff without properly understanding the power of programming language and end up writing lengthy codes which in fact can be done in couple of lines and in no time.

Coding without concentrating on the design

Most programmers are eager to start the coding for the new exciting project at hand.  In this hurry they forget to understand the design of the program and end up creating something which is not customers wanted.  Customer is king for any market and even though you wrote fantastic program which is not useful for customer then it would be of no use.  Most programmers doesn't understand the users perspective and only think from the programmers perspective. Sometimes programmers codes features which are not asked by the customer.  This creates lots of problem. This new feature is useful for the customer or not is another debate but if customer has not asked for this feature then it might not be on his priority list.  Also, this features needs to be tested thoroughly so it consumes more time whereas this time was scheduled for something else.  Also, most important because of free features given to customers, companies might be loosing good revenue opportunity.  So, moral of the story is to stick to the design.

I hope you have enjoyed my list. Keep Coding and enjoy programming.

Development or Scrum team role in Scrum

As we discussed in previous post Everything you want to know about Agile Scrum Team, there are 3 core roles in Scrum. We will discuss Third and the last of these 3 roles in detail which is Development or Scrum Team. 

The Development team or Scrum team (now onwards called scrum team) is responsible for delivering potentially shippable increments (PSI) of the product (Sprint Goals) at the end of each Sprint.  The Scrum Team builds the product that the customer is going to consume like the software, website, etc.  High performing scrum teams are highly collaborative and self-organizing with a very high degree of autonomy and accountability.  The Scrum teams are "cross-functional" and it includes all the expertise necessary to deliver the PSI.

Effectively the Scrum teams are made up of 7 individuals plus or minus 2 with the cross-functional skills who do the actual work (analyze, design, develop, test, technical communication, document, etc.) but can scale up using scrum of scrums.  Also, see Agile Methodology Myths busted. Fewer team members and the team may not have enough variety of skills to do all of the work needed to complete user stories. More team members and the communication overhead starts to get excessive.

The Scrum team have total authority over how the work gets done, which tools & techniques to use, and which team members will work on which tasks. The people who do the work are the highest authorities on how best to do it.  Similarly, if the business needs schedule estimates, it is the team members who should create these estimates.

The Scrum team should possess all of the skills required to create a potentially shippable product. Most often, this means we will have a team of specialists, each with their own skills to contribute to the team's success.

The Scrum Team has the following responsibilities:

• Is cross-functional, with seven (plus/minus two) individuals
• Selects the Sprint goal and specifies work results
• Has the right to do everything within the boundaries of the project guidelines to reach the Sprint goal
• Organizes itself and its work
• Demos work results to the Product Owner.
• responsible for completing user stories to incrementally increase the value of the product
• self-organizes to get all of the necessary work done
• creates and owns the estimates
• owns the “ how to do the work” decisions
• avoids siloed “not my job” thinking