|
Sunday, December 13, 2009
Wednesday, September 16, 2009
I Could Have Done It Too
With application development, the question is not whether you could have done it; it's whether you did it at all.
Do you believe in your idea enough to invest the time and the effort it takes to do it?
Monday, June 29, 2009
Thomanujan Number - 1229
INVALID POST
Thanks to Jeswin for pointing out bug in code.
:S :( Sheepish smile
Thanks to Jeswin for pointing out bug in code.
:S :( Sheepish smile
Wednesday, May 27, 2009
Baseline Semantics
The term Baseline can often be a source of confusion.
In my experience with Configuration Management and other tools (Microsoft Project etc), a baseline is anything “that can serve as a basis for comparison” – this may or may not be approved. SVN, in fact, skirts this baseline issue by defining the alternate terminology “tag” for the same thing!
I believe our problems stem from the–
1) Informal use of baseline as a verb, with the meaning ‘to approve’.
2) Lack of formalization of what type of baseline (and there are many kinds, refer below!) we refer to when we generically use the term baseline
References
Dictionary definition:
Noun: baseline
1. An imaginary line or standard by which things are measured or compared
(TJ: Other meanings for sake of completeness, also note “imaginary” J in 1)
2. The back line bounding each end of a tennis or handball court; when serving the server must not step over this line
3. The lines a baseball player must follow while running the bases
Wikipedia mentions:
Generally, a baseline may be a single work product, or set of work products that can be used as a logical basis for comparison. A baseline may also be established (whose work products meet certain criteria) as the basis for subsequent select activities. Such activities may be attributed with formal approval.
There are different kinds of baselines (from Wikipedia).
Functional Baseline: initial specifications established; contract, etc. Allocated Baseline: state of work products once requirements are approved
Developmental Baseline: state of work products amid development
Product Baseline: contains the releasable contents of the project
Others, based upon proprietary business practices
CMMi itself defines it multiply as (from CMMi-DEV 1.2 )
A baseline is a set of specifications or work products that has been formally reviewed and agreed on, that thereafter serves as the basis for further development or delivery, and that can be changed only through change control procedures. A baseline represents the assignment of an identifier to a configuration item or a collection of configuration items and associated entities. As a product evolves, several baselines may be used to control its development and testing.
For Systems Engineering
One common set of baselines includes the system-level requirements, system-element-level design requirements, and the product definition at the end of development/beginning of production. These are typically referred to as the “functional baseline,” “allocated baseline,” and “product baseline.”
For Software Engineering
A software baseline can be a set of requirements, design, source code files and the associated executable code, build files, and user documentation (associated entities) that have been assigned a unique identifier.
TJ:
In my opinion, attaching extra, “holy” meanings to an-already polymorphic word would not be appropriate. It would be a classic case of jargon-clash and would lead to inter-personal communication problems and possibly conflict!
It would also mean an incurrence of training (un-training) overhead and would be the proverbial seed for discontent in a new adopter.
Thursday, January 01, 2009
INTEGRATE – 2008 - Changes done for 2K9
0 error(s), 0 warning(s), 1 greeting(s)
Wish you a Happy New Year!
Log attached.
Sunday, December 14, 2008
Recipe - Do Something To Each File In Directory
This one is a real life-saver!
To do the same operation on each file, in Windows, you can use the for command.
for /F %i in ('dir *.dbg /s/b ') do @del %i
The above example deletes all *.dbg files under the current directory
Explanation
for /F %i ......... for each %i
in('dir *.dbg /s/b ') ..... in the list returned by the command. dir /s specifies a recursive search, /b causes it to to output just a list, without the file details
do @del %i ...... del %i is the command to delete the file. @ suppresses the display of the command
Recipe Syntax
for /F {%var} in ('{list-builder-command}') do {action-command}
To do the same operation on each file, in Windows, you can use the for command.
for /F %i in ('dir *.dbg /s/b ') do @del %i
The above example deletes all *.dbg files under the current directory
Explanation
for /F %i ......... for each %i
in('dir *.dbg /s/b ') ..... in the list returned by the command. dir /s specifies a recursive search, /b causes it to to output just a list, without the file details
do @del %i ...... del %i is the command to delete the file. @ suppresses the display of the command
Recipe Syntax
for /F {%var} in ('{list-builder-command}
Tuesday, November 11, 2008
Digital Peer
Found a really cool and useful site while browsing around
http://www.digitalpeer.com/
There are tips, tutorials and articles here.
Hope it stays online!
http://www.digitalpeer.com/
There are tips, tutorials and articles here.
Hope it stays online!
Saturday, July 26, 2008
Monday, January 28, 2008
Perly Gates
Tip 1:
Replacing string content with another string when both could contain backslashes.
Explanation:
Basically, you have to use \Q to escape. Otherwise, the contents of the strings (search & replace strings) will be interpreted as escape sequences.
Example:
The following is an extract from a script to get the relative path of a file with respect to a base-directory.
Tip 2:
Replace backslashes with forward slash.
If you do this the regular way, the regex you write will likely look like a squiggly drawing :) Something like /\/\\/ ;), which is a pain to read or debug.
Yeah, it's still ugly and we need to escape the backslash as \\, but that's they way it goes. Use this tip whenever you need to replace
Tip 3:
Get command line output into a variable
Here's a function to do this. Takes two parameters, the command-string to execute and a boolean option for showing the output on the display.
# TODO You may want to capture the error stream separately
Replacing string content with another string when both could contain backslashes.
Explanation:
Basically, you have to use \Q to escape. Otherwise, the contents of the strings (search & replace strings) will be interpreted as escape sequences.
Example:
The following is an extract from a script to get the relative path of a file with respect to a base-directory.
#!/usr/bin/perl
$BASE = "d:\source\";
print "Base : $BASE\n";
$TARGET = "d:\source\temp\test.txt";
print "Original : $TARGET\n";
$TARGET =~ s/\Q$BASE//;
#Replacing with null string
#syntax for replace:
#TargetString =~ is s/SearchString/ReplaceString/
print "Modified : $TARGET\n";
#Target becomes "temp\test.txt"
Tip 2:
Replace backslashes with forward slash.
If you do this the regular way, the regex you write will likely look like a squiggly drawing :) Something like /\/\\/ ;), which is a pain to read or debug.
#!/usr/bin/perl
# In Perl, any character can be used to delimit the regex! Here, using @ as separator
$STRING =~ s@\\@/@g;
Yeah, it's still ugly and we need to escape the backslash as \\, but that's they way it goes. Use this tip whenever you need to replace
Tip 3:
Get command line output into a variable
Here's a function to do this. Takes two parameters, the command-string to execute and a boolean option for showing the output on the display.
sub getCommandOutput
{
my ($COMMAND, $DISPLAYOUTPUT) = @_;
open(COMMAND_OUTPUT, "$COMMAND 2 >&1 |");
my @OUTPUTLINES = <COMMAND_OUTPUT>;
chomp(@OUTPUTLINES);
close(COMMAND_OUTPUT);
foreach $OUTPUTLINE(@OUTPUTLINES){
print "\n$OUTPUTLINE" if $DISPLAYOUTPUT;
}
print("\n") if ($DISPLAYOUTPUT);
return @OUTPUTLINES;
}
# TODO You may want to capture the error stream separately
The function returns the output of the command as an array which you can store into a variable.
Thursday, December 13, 2007
Commentstipation
When it comes to commenting the code, the cat gets the typing fingers of even creative and knowledgeable programmers. Often we are focused on just getting the code working (We'll comment later! The code has to work first!) and then we forget (what was that again? it's obvious, also time to go home...)!
Code should be self-explanatory and hence self-commenting, as far as possible. But this definitely does not mean that there should be no comments.
Good comments are hard to come by because of -
a) I-Am-A-Programmer-Not-A-Writer attitude
Well, you are a writer too.
b) "I don't know English that well" excuse
Grammatical errors are fine, spelling mistakes are also OK. Write in your native tongue and translate it, if need be. And, if what the code does is that tough to explain, then it's also the more reason to document it, it probably needs to be documented!
Remember the programming adage: Documentation is like sex, something is better than nothing! ;-) But, it must be said, inaccurate documentation is worse than no documentation. An addition to the adage is perhaps needed...having it the wrong way is probably worse than not having it at all! ;-)
TIPS
--------
* A comment should, at the very least, explain and focus on what is special in the block of code. A very good comment also explain why it is being done.
* The best comments explain the what and the why succinctly.
* How to comment
1. Ask yourself "What?"
2. Ask yourself "Why?"
3. Write what you would say to someone so that he could do what you have done. Use simple language. (This point intentionally abstruse, to serve as a memory-aid)
4. Review and edit what you have written, the best you can.
* Do not state the obvious! But also remember that what is obvious to you may not be obvious to another person. It's a thin line between advising and preaching.
Code like:
x=0; // Assigning the value 0 to the variable x
is a big no-no. Do not insult the intelligence of the reader. Plus, you'll have to scroll more while editing the code!
Code should be self-explanatory and hence self-commenting, as far as possible. But this definitely does not mean that there should be no comments.
Good comments are hard to come by because of -
a) I-Am-A-Programmer-Not-A-Writer attitude
Well, you are a writer too.
b) "I don't know English that well" excuse
Grammatical errors are fine, spelling mistakes are also OK. Write in your native tongue and translate it, if need be. And, if what the code does is that tough to explain, then it's also the more reason to document it, it probably needs to be documented!
Remember the programming adage: Documentation is like sex, something is better than nothing! ;-) But, it must be said, inaccurate documentation is worse than no documentation. An addition to the adage is perhaps needed...having it the wrong way is probably worse than not having it at all! ;-)
TIPS
--------
* A comment should, at the very least, explain and focus on what is special in the block of code. A very good comment also explain why it is being done.
* The best comments explain the what and the why succinctly.
* How to comment
1. Ask yourself "What?"
2. Ask yourself "Why?"
3. Write what you would say to someone so that he could do what you have done. Use simple language. (This point intentionally abstruse, to serve as a memory-aid)
4. Review and edit what you have written, the best you can.
* Do not state the obvious! But also remember that what is obvious to you may not be obvious to another person. It's a thin line between advising and preaching.
Code like:
x=0; // Assigning the value 0 to the variable x
is a big no-no. Do not insult the intelligence of the reader. Plus, you'll have to scroll more while editing the code!
Monday, December 10, 2007
Coding Nirvana - Cryptic Mystic Droppings
CRYPTIC MYSTIC DROPPINGS
FROM THE ELEVATED STATE
OF CODING NIRVANA
1. Code is just symbols.
2. Code needs a Thread of Life to achieve its Purpose.
3. It's all about the data.
4. It's all virtual. It can be faked but it doesn't really matter; it isn't really matter anyway.
More on each of these droppings (shit!) later.
FROM THE ELEVATED STATE
OF CODING NIRVANA
1. Code is just symbols.
2. Code needs a Thread of Life to achieve its Purpose.
3. It's all about the data.
4. It's all virtual. It can be faked but it doesn't really matter; it isn't really matter anyway.
More on each of these droppings (shit!) later.
Saturday, December 08, 2007
Coding Nirvana - Four Noble Truths
CRYPTIC MYSTIC DROPPINGS
FROM THE ELEVATED STATE
OF CODING NIRVANA
-----------------------------------------------------------
FOUR NOBLE TRUTHS
-----------------------------------------------------------
1. There is suffering
2. There is a cause of suffering. The cause is "Copy-paste"
3. There is the cessation of suffering - "Abstraction Of Commonality"
4. There is a way leading to the cessation of suffering — the Noble Eightfold Path
------------------------------------------------------------
"Copy-paste is the root cause of all programming suffering. Copy-paste is evil. The Eternal Conflict is between copy-paste and the Abstraction of Commonality."
- The Virtual Mystic
FROM THE ELEVATED STATE
OF CODING NIRVANA
-----------------------------------------------------------
FOUR NOBLE TRUTHS
-----------------------------------------------------------
1. There is suffering
2. There is a cause of suffering. The cause is "Copy-paste"
3. There is the cessation of suffering - "Abstraction Of Commonality"
4. There is a way leading to the cessation of suffering — the Noble Eightfold Path
------------------------------------------------------------
"Copy-paste is the root cause of all programming suffering. Copy-paste is evil. The Eternal Conflict is between copy-paste and the Abstraction of Commonality."
- The Virtual Mystic
Subscribe to:
Posts (Atom)