SOC report …

0
1703 days
by

My SoC is going fine and great. Hoping to finish this well ahead of time:) This is a blog + report :)

So i have started with Automation of Firefox.
For the current status of all the test cases i have mentioned here, check this link

The categories under which i have written test cases till now are
1. Firefox 3.0 :: SmokeTests :: Functionality
Most of the test cases in this category are done. certain test cases which are yet to be done are marked as TODO in the status page.

2. Firefox 2.0 :: Basic Functional Tests :: Help
This is a really small category, with just two cases. Both of them working fine, but have to check the closewindow() function which didn’t close the help window.

3. Firefox 2.0 :: Basic Functional Tests :: Options (Preferences)
Have done almost all the test cases. There is again a small issue in this. The objects shown in the preferences window are list-items whose parent is a list. We tried to copy the code for combobox for list but it didn’t work. Have to add functions specific for list in list.c

4. Firefox 2.0 :: Basic Functional Tests :: Printing
This had bug in the print preview option. The CPU just hangs and processor takes 100% load . This bug is already reported in bugzilla.mozilla.org .

5. Firefox 2.0 :: Basic Functional Tests :: Location bar
Works perfectly. Had to use LTFX functions activatewin and typekey .

6. Firefox 2.0 :: Basic Functional Tests :: Popup and Annoyance Blocking
Most of the test cases have been automated. Testing Java and Javascript is a small issue in this.

Some of the important categories which i have started tesing and is in near completion are
1. Bookmarks
2. MenuBar
3. RSS
4. Downloading
5. Addons Manager

Finally, the code for the above tests can be found here.
Finally one small and interesting thing ;-). The icon which shows that the loading of a page ( the circular thing which rotates while a page is loading) is a push button :-) . Was really surprised when i noticed it :P. No clue why is it that way ;)

I got my copy :-)

2
1705 days
by

This is my first post related to my SoC.
So let me just introduce things.
I am doing Google Summer Of Code under Mozilla Foundation . My mentors are Nagappan from Novell, Bangalore and Emily Chen from Sun, China.

When i started working for my SoC, i got a mail from Google SoC team saying
“Hello everyone,

In keeping with last year’s tradition, we will be sending a surprise
to all students. Last year we sent a cool Google notebook (complete
with paper legacy interface), and this year we have something even
cooler in the works.

If you really feel you must, go ahead and start a barrage of “I wonder
what it could be” posts to the list. But please don’t. You’ll have
the ultra-cool surprise in hand soon.

One final reminder, when you get your surprise, please don’t tell the
rest of the world until June 4, 2007. We’d like to keep it a surprise
for as many folks as possible.

After that, by all means blog, post, etc. :)

Cheers,
LH “

The moment someone tells you that you are going to get a surprise, you start thinking only about it and nothing else. :-) . And of course i am no exception. All i knew was it is a book signed by its author. There is long discussion in the Google soc group guessing whether it can be Linus or someone else.

Finally i got the book few days back. It is Producing Open Source Software: How to Run a Successful Free Software Project by karl fogel.

Wow :) i never thought just a book will make me so happy. This is the first book i have ever got which is signed by its author :) and i felt so happy that i can’t describe it here :-)

I really can’t wait to get back to college so that i can scan the first page ;-) and put it up here. Man, just a simple signature with a text saying “Happy Hacking” but whenever i see it ,makes me feel happy and proud :-).

And yes, the best part was that the author was kind enough to post a blog about it. So if you don’t believe what i am telling you, check out his blog about the book here.

The review about the book in one line. “The more i read it, the more i love it.” There are many places where the author has taken care to give appropriate examples, funny incidents, etc.

Finally
Thanks a ton for Google for such a nice idea. :-)

Oath for Software Engineers

3
1706 days
by

Never write a line of code that someone else can understand.

Make the simplest line of code appear complex. Use long counter intuitive names. Don’t ever code “a=b”, rather do something like:

AlphaNodeSemaphore=*(int)(&(unsigned long)(BetaFrameNodeFarm));

Type fast, think slow.

Never use direct references to anything ever. Bury everything in macros. Bury the macros in include files. Reference those include files indirectly from other include files. Use macros to reference those include files.

Never include a comment that will help someone else understand your code. If they understand it, they don’t need you.

Never generate new sources. Always ifdef the old ones. Every binary in the world should be generated from the same sources.

Never archive all the sources necessary to build a binary. Always hide on your own disk. If they can build your binary, they don’t need you.

Never code a function to return a value. All functions must return a pointer to a structure which contains a pointer to a value.

Never discuss things in concrete terms. Always speak in abstract. If they can understand you, they don’t need you.

Never complete a project on time. If you do, they will think it was easy and anyone can do it and they don’t need you.

When someone stops by your office to ask a question, talk forever but don’t answer the question. If they get their questions answered they don’t need you.

Load all sentences either written or spoken with alphabet soup. When someone asks you out to lunch, reply:

“I can’t because I’ve almost got my RISC-based OSI/TCP/IP client connected by BIBUS VMS VAX using SMTP over TCP sending SNMP inquiry results to be encapsulated in UDP packets for transmission to a SUN 4/280 NFS 4.3 BSD with release 3.6 of RPC/XDR supporting our ONC effort working.”

Never clean your office. Absolutely never throw away an old listing.

Never say hello to someone in hallway. Absolutely never address someone by name. If you must address someone by name, mumble or use the wrong name. Always maintain the mystique of being spaced out from concentrating on complex logic.

Never wear a shirt that matches your pants. Wear a wrinkled shirt whenever possible. Your shirt must never be tucked in completely. Button the top button without wearing a tie. This will maximize your mystique.

Hols are bad for health

2
1708 days
by

Well, i never thought i will ever say this but really
“Hols @home sucks”.
This is the first time i am actually staying at home after joining college (was lucky enough to keep myself busy with something or other during hols :-) ) and i never realized it will be so boring :(.

Not that i don’t like my home but i simply miss college.
Even though i chat with my friends 24*7 , i simply miss people . The best part about being with a group is that you don’t have to do everything alone. You’re with your friends. Working alone is really not the kind of thing which i would like to do and now i have to work all alone. Wish college reopens soon ( even if reopens tomorrow, it is fine with me :-) :-) )

This quote is so true

Just as a puppy can be more of a challenge than a gift, so too can the holidays.
John Clayton

Coding Style …

2
1719 days
by
I have never thought much about coding style before i did my NOSIP in Novell. But once i started coding for ldtprecord, according to the coding style suggested to me by nags, i was surprised to see how nice and neat the final code looks.

Some tips/tricks for nice coding skills are,

1. Do spend some time to think about the variable names and the function names. This sometimes might be bit boring, especially when you want to concentrate much on the program logic and performance. But this is Rule 0 for coding conventions. A variable name “k” can imply anything like “kappa, kozhukattai, katthu, kaadhal, kerala, kozhuppu…” to someone who might have to read your code later. This is again mentioned here clearly. Many thanks to emacs, you can always use the auto complete, if your variable name is too long. :-) .

2. The actual coding convention depends much on the language and the standards your team is using already. The following style won’t work for someone, whose team is already using a totally different style.

A few examples for C is posted here .

Sample Code 1 :

if (a == 5) {

    b = 10;

}
else {
    b = 20;
}

Things to be noticed in the above snippet are.

1. A space between if and “(” .
2. Space in both the sides of the comparison operator.
3. Space between “)” and “{“
4. Space between both the sides of assignment operator (line 2 & 5) . This is true for almost all the operators.
5. Proper indentation of lines 2 & 5. If you are using emacs or vi, check here for your .emacs or .vimrc file .

Well, your code will compile and run even if you don’t give these spaces, but a program coded with a bad coding style is equivalent to an inefficient code.

Sample Code 2

Let us have a function which takes two integers and returns their sum .
The code should be like

int add_numbers (int num1, int num2) {
    return (num1 + num2);
}

The function call will be something like,

int sum;
sum = add_numbers (10, 20);

Things to be noticed in the above snippet is

In the first line in the function declaration,

1. The function name should be as clear as possible.
2. A space between the end of function name and “(” .
3. Spaces are given after every “,” in the function argument list.
4. A space is given between “)” and “{“.

In the second line in the function declaration,

1. A space before “(“. [ This rule is almost global. Apply it everywhere whenever you use "(" ] .

2. There is a space on both the sides of the addition operator. This is again almost global. A space between both the sides of operator makes the code look real neat.

3. The indentation about which was mentioned earlier.

But yes, if your girl friend is a geek or a nerd or a psycho or a fundoo, then you better go for this. ;-)

#define MAGIC “eilouvy43605321″
#define _(p,o,q) (t o#p[0])?(q)
#define __(p,o,q) _(p,o,t-q)
int main(){int t, i; for(i=8;i>0;i–)printf(“%c”, MAGIC[(((t=(MAGIC+7)[i-1])==’_')?62:_(.,==,63):_(@,==,64):__(a,>=,’a'+36):__(A,>=,’A'+10):(t-’0′))]);}

Note :: I wont say the coding style i use is the perfect one. It always depends upon what your team was using till now and how easy it is to read, debug and maintain the code.

Useful Links :

The guide coding standards in GNOME is really a nice one.
Even better was this one i found recently. Though i didn’t read it completely, it was quite interesting.
This article was short and sweet.

Feel My Pain…

0
1721 days
by

One day in heaven, the Lord decided He would visit the earth and take a stroll. Walking down the road, He encountered a man who was crying.

The Lord asked the man, “Why are you crying, my son?” The man said that he was blind and had never seen a sunset. The Lord touched the man who could then see and was happy.

As the Lord walked further, He met another man crying and asked, “Why are you crying, my son?” The man was born a cripple and was never able to walk. The Lord touched him and he could walk and he was happy.

Farther down the road, the Lord met another man who was crying and asked, “Why are you crying, my son?” The man said, “Lord, I am an engineer.”

…and the Lord sat down and cried with him.

« Previous
Next »
Go to Top