Older developer are better than young developer :)

http://www.wired.com/wiredenterprise/2013/04/developers-age/ Older software programmers have long complained of age discrimination. But according to study conducted by researchers at North Carolina State University, companies should think twice before hiring a young hot-shot hacker over a seasoned developer. Emerson Murphy-Hill, an assistant professor of computer science at North Carolina State University and co-author of the study, says that veteran developers have more going for them than you might think. “We know certain things get worse, like your eye sight,” he says. “But it’s not all bad. You get better at some things, such as social and emotional intelligence.” He says that we tend to think of programming as something that’s only practiced by the young: you spend your 20s working 80 hours a week, and then you give it up and go into management. But that may not be the best way to play it. To determine whether programmers get better or worse with age, the researchers looked at the top ranked programmers on StackOverflow, a site where coders can ask and answer questions about programming. Users rate answers from fellow developers, and then the site uses those rating to generate a reputation score for each developer. Comparing these reputation scores to the age of each developer, the researchers found that these ratings tended to increase as developers moved into their 50s. The study also they tried to rate the breadth of each developer’s knowledge by tracking how many different subjects they had written about. The researchers found that younger developers replied to questions in a smaller number of subject areas, and that the range of subjects broadened as developers got older. Finally, the study looked at how many questions developers answered about technologies less than 10 years old, and it found that older developers were more knowledgable than younger users about newer mobile platforms such as iOS and Windows Phone. For other technologies, there were was no significant gap between younger and older users. The researchers concluded that any bias against older developers is unsupported by the data on StackOverflow. But the study has its limits. Many StackOverflow users don’t report their age, and it appears that older programmers are under represented on StackOverflow, based on data from the Bureau of Labor Statistics. Older programmers who use the site may making a conscious effort to keep their technologies skills current and to promote themselves. Or they may use the site because they know they are knowledgeable, while their less knowledgeable peers may stay off the site, skewing the results. And, of course, StackOverflow reputation scores don’t necessarily correlate to programming skills. The paper detailing the study, Is Programming Knowledge Related To Age?, will be presented at the Working Conference on Mining Software Repositories in San Francisco on May 18. But it’s just a start. In an effort to draw better conclusions, Murphy-Hill says his team hopes to look at a wider variety of programmer populations. He says they’re also interested in finding out why younger developers contribute more to open source than older developers.

Nokia 920 vs Samsung Galaxy SIII picture quality

Very cool photo comparison tool Welcome to the GSMArena Photo Compare Tool. The tool puts up to three phones and their cameras head to head, testing their performance on three charts. The overview picture on the left shows each chart through the "eyes" of the phone and the windows on the right show a part of the photo zoomed at 100%. You can drag the green viewfinder (or just click on the overview) to pan around the chart. http://www.gsmarena.com/piccmp.php3?idType=3&idPhone1=4967&idPhone2=4968&idPhone3=4238

How can I pad an int32 or int64 with leading zeros replacement of sprintf

#define hexchar(x) ((((x)&0x0F)>9)?((x)+'A'-10):((x)+'0'))
typedef signed long long Int64;

// special printf for numbers only
// see formatting information below
// Print the number "n" in the given "base"
// using exactly "numDigits"
// print +/- if signed flag "isSigned" is TRUE
// use the character specified in "padchar" to pad extra characters
//
// Examples:
// sprintfNum(pszBuffer, 6, 10, 6, TRUE, ' ', 1234); --> " +1234"
// sprintfNum(pszBuffer, 6, 10, 6, FALSE, '0', 1234); --> "001234"
// sprintfNum(pszBuffer, 6, 16, 6, FALSE, '.', 0x5AA5); --> "..5AA5"
void sprintfNum(char *pszBuffer, int size, char base, char numDigits, char isSigned, char padchar, Int64 n)
{
char *ptr = pszBuffer;

if (!pszBuffer)
{
return;
}

char *p, buf[32];
unsigned long long x;
unsigned char count;

// prepare negative number
if( isSigned && (n < 0) )
{
x = -n;
}
else
{
x = n;
}
// setup little string buffer
count = (numDigits-1)-(isSigned?1:0);
p = buf + sizeof (buf);
*--p = '\0';
// force calculation of first digit
// (to prevent zero from not printing at all!!!)
*--p = (char)hexchar(x%base);
x = x / base;
// calculate remaining digits
while(count--)
{
if(x != 0)
{
// calculate next digit
*--p = (char)hexchar(x%base);
x /= base;
}
else
{
// no more digits left, pad out to desired length
*--p = padchar;
}
}

// apply signed notation if requested
if( isSigned )
{
if(n < 0)
{
*--p = '-';
}
else if(n > 0)
{
*--p = '+';
}
else
{
*--p = ' ';
}
}

// print the string right-justified
count = numDigits;
while(count--)
{
*ptr++ = *p++;
}

return;
}

ERROR LEVEL

Errorlevels

The correct name for errorlevels would be return codes.
But since the DOS command to determine the return code is IF ERRORLEVEL, most people use the name errorlevel.

Errorlevels are not a standard feature of every command.
A certain errorlevel may mean anything the programmer wanted it to.
Most programmers agree that an errorlevel 0 means the command executed successfully, and an errorlevel 1 or higher usually spells trouble.
But there are many exceptions to this general rule.

IF ERRORLEVEL construction has one strange feature, that can be used to our advantage: it returns TRUE if the return code was equal to or higher than the specified errorlevel.

This means most of the time we only need to check IF ERRORLEVEL 1 ... and this will return TRUE for every non-zero return code.

In Windows NT 4/2000/XP this may sometimes fail, since some executables return negative numbers for errorlevels!
However, this can be fixed by using the following code to check for non-zero return codes:
IF %ERRORLEVEL% NEQ 0 ...
Use the code above wherever you would have used IF ERRORLEVEL 1 ... in the "past".

To determine the exact return code the previous command returned, we could use a construction like this:

@ECHO OFF
IF ERRORLEVEL 1 SET ERRORLEV=1
IF ERRORLEVEL 2 SET ERRORLEV=2
IF ERRORLEVEL 3 SET ERRORLEV=3
IF ERRORLEVEL 4 SET ERRORLEV=4
•
•
•
IF ERRORLEVEL 254 SET ERRORLEV=254
IF ERRORLEVEL 255 SET ERRORLEV=255
ECHO ERRORLEVEL = %ERRORLEV%
This is perfectly OK if we only have to check, say, 15 consecutive errorlevels.
If we need to check every errorlevel, though, there are better alternatives.

In Windows NT 4 (and 2000?) this won't work, since the SET command itself will set an errorlevel (usually 0)!
(As I learned from Charles Long, in XP the SET command no longer sets an errorlevel itself.)
However, Windows NT 4 and later make it easy by storing the latest errorlevel in the environment variable ERRORLEVEL:
ECHO.%ERRORLEVEL%
will display the errorlevel.

This blog entry by Batcheero explains perfectly why you should never SET the ERRORLEVEL variable.

The safest way to use errorlevels for all DOS versions is the reverse order check.
Start checking the highest errorlevel that can be expected, then check for the one below, etcetera:
IF ERRORLEVEL 255 GOTO Label255
IF ERRORLEVEL 254 GOTO Label254
•
•
•
IF ERRORLEVEL 2 GOTO Label2
IF ERRORLEVEL 1 GOTO Label1
GOTO Label0

:Label255
(commands to be executed at errorlevel 255)
GOTO End

•
•
•

:Label1
(commands to be executed at errorlevel 1)
GOTO End

:Label0
(commands to be executed at errorlevel 0, or no errorlevel)

:End

This will result in many more lines of batch code, but at least it will work in any DOS version.
In DOS for the rest of us, we can use FOR loops to determine the errorlevel:

@ECHO OFF
REM Reset variables
FOR %%A IN (1 10 100) DO SET ERR%%A=

REM Check error level hundredfolds
FOR %%A IN (0 1 2) DO IF ERRORLEVEL %%A00 SET ERR100=%%A
IF %ERR100%==2 GOTO 200
IF %ERR100%==0 IF NOT "%1"=="/0" SET ERR100=

REM Check error level tenfolds
FOR %%A IN (0 1 2 3 4 5 6 7 8 9) DO IF ERRORLEVEL %ERR100%%%A0 SET ERR10=%%A
IF "%ERR100%"=="" IF %ERR10%==0 SET ERR10=

:1
REM Check error level units
FOR %%A IN (0 1 2 3 4 5) DO IF ERRORLEVEL %ERR100%%ERR10%%%A SET ERR1=%%A
REM Modification necessary for errorlevels 250+
IF NOT ERRORLEVEL 250 FOR %%A IN (6 7 8 9) DO IF ERRORLEVEL %ERR100%%ERR10%%%A SET ERR1=%%A
GOTO End

:200
REM In case of error levels over 200 both
REM tenfolds and units are limited to 5
REM since the highest DOS error level is 255
FOR %%A IN (0 1 2 3 4 5) DO IF ERRORLEVEL 2%%A0 SET ERR10=%%A
IF ERR10==5 FOR %%A IN (0 1 2 3 4 5) DO IF ERRORLEVEL 25%%A SET ERR1=%%A
IF NOT ERR10==5 GOTO 1

:End
REM Clean up the mess and show results
SET ERRORLEV=%ERR100%%ERR10%%ERR1%
FOR %%A IN (1 10 100) DO SET ERR%%A=
ECHO ERRORLEVEL %ERRORLEV%

WIX CustomAction deferred versus immediate and the nightmare of Windows platform dotNet dependency

When it comes to using WIX everybody would agree that C# language is on the paper the easiest language to use to write a Custom Action.
When things get more complicated is that if you want to create a WIX installer for both Windows 7 and Windows8 then you need to
build each custom action to target both dotNet Framework 3.5 and dotNetFramework 4.0 unfortunately you will have to create two solution because
unlike Visual Studio C++ project the dotNet dependency applies to the entire solution and not the configuration at least this is what I noticed
on Visual Studio 2010.

You have to be very careful on when to decide that your CustomAction will be immediate and when it will be deferred.
If you use your custom action to install driver, install Windows Services, setup MYSQL ODBC connection, configure IIS or delete file from protected folder
then you need to use a deferred custom action.

While both deferred and immediate custom actions can run in the context of the user initiating the installation, only deferred custom actions can run elevated using the system context.
Deferred custom actions can only be sequenced between the InstallInitialize and InstallFinalize actions in execute sequence tables. Immediate custom actions, on the other hand, can be sequenced
anywhere within any of the sequence tables. Deferred custom actions are not executed immediately. Instead they are scheduled to run later during the execution script. The execution script isn't processed until the InstallExecute, InstallExecuteAgain, or InstallFinalize action is run.
Deferred custom actions cannot access the installation database. In fact, deferred custom actions have very limited access to the installation session because an installation script can be executed
outside of the installation session that created it. Immediate custom actions have access to the installation database and can read and set installation properties, modify feature and component
states, and add temporary columns, rows, and tables among other things.
Deferred custom actions should be used when the custom action must make a change to the system or call another system service. Additionally, only deferred custom actions can run in an elevated
context. If your custom action requires elevated privileges in order to run, your custom action needs to be marked as deferred. Custom actions marked to run in the system context
(msidbCustomActionTypeInScript + msidbCustomActionTypeNoImpersonate) will only run in the system context if the installation itself is elevated.

So let's look at how to solve the dependencencie issue first.

1 I recommend passing an argument to your WIX build script to create an MSI based on the targeted OS




2 Dot Net Dependency

Make sure you know the build in version of dotNet on your targeted OS Win7 is 3.5 with fallback to 2.0
Windows 8 is 4.0 and deprecated support for 3.5




3 CustomAction deferred




Inside your C# CustomAction you can only access property passed to you inside the Value attribute of the CustomAction

session.Message(InstallMessage.Warning,
new Record(new string[]
{
string.Format("MYVARIABLE: {0}",
session.CustomActionData["MYVARIABLE"])
}));

Direct access to the property will fail such as string UILevel = session["UILevel"];
You cannot change MSI property inside the CustomAction but you can cheat and log a dummy property if you expect to parse the installation log during a silent install
to check the response of your custom action. Rolling back custom action is not easy when you messed up with some third party application setting
so in some cases you have to return return ActionResult.Success regardless of the outcome and rely on a result code

EG

string strLog = string.Format("Property(S): ResultCode = {0}", Convert.ToString(1));
session.Log(strLog);

4 CustomAction immediate

For install custom action if your custom action rely on files deployed within your MIS to some target folder then make sure you change Before="InstallFinalize" to
After="InstallFinalize">




In this case you can access any property through the session object EG string UILevel = session["UILevel"]; and you can set a new property before exiting from your CustomAction
session["ResultCode"] = 1


Hope this article will help you solve Windows 7 and Windows 8 Installer issue

a close look at how oracle installs deceptive software with java updates

http://www.zdnet.com/a-close-look-at-how-oracle-installs-deceptive-software-with-java-updates-7000010038/

Very interesting article about Adobe Photoshop source code version 1

pho·to·shop, transitive verb, often capitalized \ˈfō-(ˌ)tō-ˌshäp\ 1.to alter (a digital image) with Photoshop software or other image-editing software especially in a way that distorts reality (as for deliberately deceptive purposes) – Merriam-Webster online dictionary, 2012 http://computerhistory.org/atchm/adobe-photoshop-source-code/