Would recommend this to anyone interested in JS. One email weekly with good content.

At some point, we’re all in the need of parsing a string into an integer, such as a user input. In JavaScript, there is **parseInt** which can be useful, but it can easily do more harm than good if you are not aware of how it works.

parseInt takes two arguments: a *string* and an optional *radix* (base).

`parseInt("150", 10); // => 150`

So far so good. Now, you may assume that if no base is specified, 10 is the default. This is both true and false. There are two scenarios where base 10 does not automatically apply.

```
// Example #1
parseInt("0xff"); // => 255
// Example #2
parseInt("010"); // => 8
```

In the first example, parseInt recognizes the string to be hexadecimal (base 16) because of the leading **0x**, which is kind of cool. But the real problem arises in the second example, where parseInt evaluates the string as octal (base 8). In fact, a string starting with 0 is assumed to represent an octal number and this causes problems with both *08* and *09* which both are invalid octal numbers (no octal number can end in 8 or 9). Just to give a few examples of why this is troublesome:

```
parseInt("01"); // => 1
parseInt("05"); // => 5
parseInt("08"); // => 0
parseInt("09"); // => 0
parseInt("010"); // => 8
```

In other words, if you are validating user input assumed to be decimal and you don’t specify a base, you may be screwed if the user for some reason decides to input the number with a leading zero. In fact, it’s extra troublesome because for some numbers the expected result will be accomplished, while for others it will be completely off. This makes testing harder and if the end number is part of some equation, you can end up with all sorts of weird, random results down the road that are **very hard** to spot. Therefore, make everyone’s life easier by explicitly specifying the radix when using parseInt.

I put this little demo together a month ago in a response to a challenge posted by Paul Rouget. The way the data is displayed is, honestly, next to useless because it only reports how many earthquake occurred in a certain area and ignores more specific details such as magnitude. However, I used this opportunity to learn more about CSS transitions and how new features like border-radius can be used to accomplish nice effects.

A few days ago I was in the need of generating some *relatively secure* passwords, so I went ahead and wrote a small password generator in JavaScript. This is what I came up with:

```
function pwGen(len, charStr) {
var str = charStr || "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#@$"
, chars = str.split("")
, charsLen = chars.length
, output = ""
, len = len || 8
;
for (var i=0; i < len; i++) {
output += chars[~~(Math.random() * charsLen)];
}
return output;
}
```

Now, there are three options in terms of usage here:

- Pass no parameter => password is 8 characters long
- Pass one parameter: length of password
- Pass two parameters: length of password and a custom character list

Results:

```
pwGen(); // "IK6uXOxf"
pwGen(20); // "owN9#vc6R5wWRqEP2!ro"
pwGen(10, "abc123"); // "1a1cc12ca2"
```