Team Schmooze crowned as winners !

May 11, 2015

It was my second Hackathon in Outware on 1st May, 2015.  And I’m happy to announce that my team are the winners for the ‘Most Innovative’ category ! Not only did we come out as winners out of the 17 competing teams, we were also the first ever team of Automation test engineers (dominated by) that made the cut.

Schmooze

Schmooze

More about the challenges here.

The Fantastic Four:

Except Celal who is a hardcore iOS specialist others are test engineers specialized in automating mobile apps.

Hari –  Middleware developer

Balaji – Middleware developer

Sivaranjini – App Designer

Celal – iOS developer

The verdict:

This award not only showcases the creative and the technical talent exists in Outware, but also shows what a bunch of individuals who are driven by passion for innovation with lot of hard and team work can do if they chose to wear a different hat for a change.

What an inspiration week !

More about the winners, here.

 

 

Advertisements

Install multiple ipa/app in iOS device using command line

January 31, 2015

This post explains my quest to achieve a solution for iOS devices, similar to batch install in android. Remember my requirement is to smell and taste the coffee rather than installing 18 apps ( multiply that for every dev release + each test device ) sitting in my desk 😉

I used,

  • libimobiledevice for command line deploy
  • And the below script to uninstall and install the apps found in a folder.
#!/bin/bash
for package in `ideviceinstaller -l | grep -i <your-package> | awk '{print $1}'`
do
echo "Uninstalling $package"
ideviceinstaller -U $package >> log
done
for ipa in `ls *ipa`
do
echo "Installing $ipa"
ideviceinstaller -i $ipa >> log
done


Batch install multiple apks

January 26, 2015

There are often a situation where I need to install not few but 18 apps in android for testing. Innumerous devices supported by different versions of android and the bug fixes which translates into more dev and release builds adds more pain to the situation.

As an avid commandline freak, I used the following small script to batch install the apks found in a directory. To use the script, copy all your apks to a dir along with the script and execute it,

I assume adb and aapt in your path already.

#!/bin/bash
$dir=`pwd`
for i in `ls $dir`
do
aapt dump badging $i | perl -ne 'print $2 if /package: name=(.)(.+?)\1/' | xargs -I{} adb uninstall {}
adb install $i
done

You can replace the contents of the for loop with following if you dont worry about reinstalling apps with existing data.

adb install -r $i

Shell Parse Order: Breaking the rules

June 21, 2010

Rules are meant to be broken, hence the Shell parsing order.

There might need arises to skip some of the steps in shell parsing order mentioned in my previous post and we use Quotes ( single & double quotes ) or ‘eval’ command to skip or redo the steps in the parsing order.

Double quotes (“):

Double quotes would run through steps 1, 6, 7, 8 from the parsing order before execution. ie.

1. Tokenize

6. Parameter Substitution

7. Command Substitution

8. Arithmetic Expression

Single Quotes:

Single quotes (‘) would simply skip through all the steps after Tokenize and execute the command.

eval:

While quotes have been used to skip through, the ‘eval’ command has been used to redo the entire sequence of shell parsing once again. ie. The output from the step 11 would be fed to the step 1 and the entire parsing would happen once again.


Understanding the Shell Parsing Order

February 9, 2010

The shell understands the commandline as pipeline and list,

* Pipeline is sequence of one or more commands separated by the character |
* List is sequence of one or more pipelines separated by one of the operators: ; , & , && , ||

For each pipeline it will perform the following steps before executing the command,

1. Tokenize

Splits the commands into tokens that are separated by the fixed set of metacharacters.
Tokens => words, keywords, I/O redirectors and semicolons
metacharactes => space, tab, newline, ;(,),<,>,| and &

2. Compound commands
Checks the first token to see if its a keyword with no quotes or backslashes. It can be opening keyword ( like if , { or () ie. compound command) or control structure middle ( like then, else, do ) , end ( fi , done )

3. Aliases
Checks the first word of each command against the list of aliases.
3.i) if match is found, substitutes the alias’s definition and goto Step 1
eg. ll becomes ‘ls -l *’ ### where alias ll=”ls -l *” defined already
3.ii) Otherwise goto Step 4

4. Brace expansion
Similar to pathname expansion except file names generated need not exist. Its a mechanism by which arbitrary strings may be generated.

eg. a{b,c} becomes ab ac.

5. Tilde expansion
If a word begins with an unquoted tilde character ( ~ ), the characters following the tilde are treated as a possible login name.
eg. cd ~joe becomes cd ‘/home/joe’ ### where /home/joe is the $HOME of user joe

6. Parameter substitution
The value of the parameter is substituted.
eg. # echo ${HOME} becomes ‘/home/joe’

7. Command substitution
Command name will be replaced with the standard output of the command . It is of two forms $(string) or `string`.
eg. # `which find` or $(which find) becomes ‘/usr/bin/find’

8. Arithmetic expression
Performs evaluation of an arithmetic expression and substitute the results. It is of the form $((string)).
eg.1 # $(($a+$b)) becomes ‘9’ ### where a=5; b=4

eg.2 # $(($(cat /tmp/file1 | wc -l) + $b)) becomes 7 ### calculate no. of lines in /tmp/file1 ( 3 lines ) and add it to the value of $b ( 4 )

9. Word splitting
Takes part of the line resulted from parameter, command and arithmetic substitution and splits them into word again using $IFS as delimiters instead of metacharacters used in step 1.

The default value of IFS is exactly [space][tab][newline]

10. Pathname expansion
Also known as filename generation or wildcard expansion. The shell scans for the characters *, ? and [ ie. pattern and replace it with an alphabetically sorted list of file names matching the pattern.
eg.1 # file* becomes ‘file1 file2 file3 file1.txt file2.txt file3.txt’

eg. 2 #file? becomes file1 file2 file3

11. Functions, Built-ins and $PATH

At this stage the command has been already split into words containing a simple command and optional list of arguments. And if that simple command ie. first word, contains no slashes ( not an absolute path ) , the shell will attempt to locate it in the following search order

11.i) Function
If there exists a function by that name, it ‘ll be invoked
11.ii) Built-in commands
If there exists a built-in command, it ‘ll be invoked
11.iii) Search $PATH
Finally searches each element of the path for directory containing the command name. The first file found will be chosen.

12. Redirection
Before a command is executed, its input and output may be redirected. Redirection operators < , > , <<, >>
eg. cat /tmp/file1 > /tmp/file2


Introducing patternchecker

January 24, 2010

Often I need a small utility script/program to check the matched results of regex pattern against known text. So I dont have to execute my lengthy main script/program multiple times to get the correct pattern.

I’ve used the following patternchecker script (PERL) & program (JAVA) while coming up with patterns and for demonstration in my previous posts.

Usage:
# java patterncheck
Enter pattern : (x*)(x)(x+)
Enter string:foxxxxx
Matched : fo<<< xxxxx >>>
group 1 = xxx
group 2 = x
group 3 = x

Perl and Java uses the same regex engine and thus would behave similarly while matching patterns, I’ve listed here the sourcecode in perl and java out of my curiosity although you just need any one of them,

i) perl

#!/usr/bin/perl
print "Enter pattern :";
### Read the regex pattern
chomp($pattern=<STDIN>);

### count the number of paranthesis
$cnt++ while( $pattern =~ /\(/g );
print "Enter string :";
chomp($input=<STDIN>);

### read the string to be tested against
if ( $input =~ /$pattern/ ){

      ### print prematch, match, postmatch
      print "Matched: $`<<< $& >>> $'\n";

      ### print $1, $2, etc
      foreach $i (1..${cnt}) { print "\$",$i," = ",${$i},"\n";}
} else {
      print "No Match\n";
}
<div>

ii) java

import java.lang.*;
import java.io.*;
import java.util.regex.*;

public class patterncheck{
	public static void main(String args[]){
		String pattern, str;
		int groups;

		//Read pattern and string from the console
		Console c = System.console();
		pattern=c.readLine("%s","Enter pattern :");
		str=c.readLine("%s","Enter string:");

		//compile and associate the pattern with the text
		Pattern p = Pattern.compile(pattern);
		Matcher m = p.matcher(str);

		//if there is a match
		if (m.find()){
			// print prematch, match & postmatch
			System.out.println("Matched : "+str.substring(0,m.start())+"<<< "+ m.group() +" >>>"+str.substring(m.end()));

			// print what captured in paranthesis
			if (m.groupCount() != 0) {
				groups=m.groupCount();
				for (int i=1;i<=groups;i++){
					System.out.println("group "+i+" = "+m.group(i));
				}
			}
		}
		else {
			System.out.println("No Match");
		}
	}
}

Regular Expressions: Icebreakers

January 24, 2010

Few days back, there was a knowledge session on regular expressions within my team. After discussing the usual topics like greedy & lazy quantifiers, backreferences, etc, we started analyzing match results for few expressions. I ‘ve familiarity with regex and used them in majority of my throw-away scripts and I thought I knew regex unless been baffled with the simple questions from the team. I list down few of those simplest of the simple patterns and what they match and why ( which actually led to me learn the rules of the game),

Before even starting to look at them, did I mentioned earlier that regex engine would start its search just before the first character of the string ? If not, let me tell you now, it need to start before the first character, if and all the patterns  contains anchors ( ^, \b, etc ), it needs to check them too. And the search would go beyond the last character in the string and now you know why ( to match $, \b, etc ).

(i) x*

pattern : x*

string :foxxx

Matched: <<<  >>> foxxx

Explanation: As mentioned in the rule 2 here,  the greediness would always try to match more, hence read the pattern ‘x*’ as  ‘match more occurrence of x or nothing’. And the engine going to do its search character by character in the string. Since it could not find any ‘x’ to match at the starting position, it tries with its other choice ‘ match nothing’ and it succeeds.

(ii) .*

pattern : .*

string :foxxx

Matched: <<< foxxx >>>

Explanation: ‘.’ matches anything other than ‘\n’. Though the pattern ‘.*’ can be read as ‘match more of any characters other than ‘\n’ or nothing’, the rule of greediness gives the preference to match more characters.

(iii) x*

pattern : x*

string : xxxfoxxx

Matched: <<< xxx >>> foxxx

Explanation: Same greediness favors the match more criteria.