Computer Science Notes to Myself

Wednesday, June 26, 2013

Curious JavaScript form validation

Here are two curios things about JS: 1) need for "return" for onsubmit attribute and 2) anything but "false" is accepted as "true".

<!DOCTYPE html>
<html>
<head>
<script>
function validateForm()
{
var x=document.forms["myForm"]["fname"].value;
if (x==null || x=="")
{
alert("First name must be filled out");
return false;
}
}
</script>
</head>

<body>
<form name="myForm" action="demo_form.asp" onsubmit="return validateForm()" method="post">
First name: <input type="text" name="fname">
<input type="submit" value="Submit">
</form>
</body>

</html>

Tuesday, June 25, 2013

Oh...JavaScript

I'm breezing through JavaScript and came upon this notation:

person=new Object();
person.firstname="John";
person.lastname="Doe";
person.age=50;
person.eyecolor="blue";

Now this strikes me as one of those error-prone sorts of things that hazardous for PHP: creating object fields on the fly.

Monday, June 24, 2013

PHP vs. Javascript for input validation

I've just moved into Javascript, the first day, and found probably the only piece of Javascript I really need for now. Namely, input validation.

But PHP can also do input validation as the code below suggests.

<!DOCTYPE HTML>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>PHP Form Validation</title>
</head>
<body>



<form action="valid_handler.php" method="POST">
<fieldset>
<legend>Enter a quantity and email address</legend>
<p>Quantity : <input type="text" name="quantity"></p>
<p>Email Address : <input type="text" name="email"></p>
</fieldset>
<p><input type="submit" ></p>
</form>
</body>
</html>

The same (sort of) thing in JavaScript is:

<!DOCTYPE html>
<html>
<body>
<h1>My First JavaScript</h1>
<p>Please input a number.</p>
<input id="demo" type="text">
<script>
function myFunction()
{
var x=document.getElementById("demo").value;
if(x==""||isNaN(x))
 {
 alert("Not Numeric");
 }
}
</script>
<button type="button" onclick="myFunction()">Click Me!</button>
</body>
</html>

Without the benefit of other, more informed PHP-JavaScription opinions, I opinion is JavaScript is better to attempt this than PHP. Why? Because as a general rule, we prefer to do input validation as close to the source as possible. Rather than waiting for the HTML to get to the server, test it in the browser, save Internet latency, and conserve server cycles for when they are really needed.

Off by one errors

I received a phone call this morning from my step-mother. It wasn't even 8 AM and I assumed it was bad news, in this case, about my father. No, the flight reservations I had made for them in February had a bug. The conference they were attending ended on 18 Jul which was the date of departure. But they needed to depart on 19 Jul to make that last day of the conference.

I assumed I had gotten it wrong; rather, this departure date was the info she had given me. I know this because she told me today that she had also made the hotel reservations herself for the same (buggy) departure date. I didn't think at the time to ask about this last day. Then, it occurred to me, this is a boundary condition and an off-by-one-error.

Computer science is probably the formal place where I learned about off-by-one-errors. They come in the form of algorithm flaws and most notably crashes or "array bound exceptions."

I suspect these OBO errors are everywhere in life and the way we deal with them is the same way. If we catch them by testing beforehand, we're not lucky, just diligent. Indeed, there's a methodology called "boundary value analysis" for identifying such bugs. Even if we're diligent, we could still be unlucky. That is, we'll get an exception and deal with it in LA and worse, the day of departure.

Monday, June 17, 2013

LOC and complexity

Conventional wisdom, and dare I say "common sense," says that LOC and complexity are highly correlated. See here. The early data I'm getting for Scala and functional programming suggests there may, MAY, be more to this story. Maybe.

Tuesday, June 11, 2013

Primary, unique, and key constraints

The following query creates a primary key for the id column:

CREATE TABLE IF NOT EXISTS products

(

id INT UNIQUE AUTO_INCREMENT ,

code INT NOT NULL ,

name VARCHAR(25) NOT NULL ,

quantity INT NOT NULL ,

price DECIMAL(6,2) NOT NULL

) ;

So the question is does every unique column a primary key? No.

The reason is the primary key is a type of unique column. A more complete explanation is here.

Monday, June 10, 2013

PHP and JSP

As I have moved further into PHP programming, I'm getting a feeling as to why PHP is so popular.

I, for one, cannot see much difference between PHP and JSP except for one thing: it's PHP and not Java. Duh.

PHP does not have THE "accident" of Java, namely, needing to specify types. PHP uses dynamic typing, that is, the type depends on the context. Part of the problem here for Java is that it is not a scripting language but may need to be one for JSP.

Whereas Java was ready for the Internet when it burst on the scene some 20 years ago, PHP is ready for the web server. Super globals like $_FILE and $_POST, associative arrays, etc. -- all these things seem to make PHP more productive than Java.

JSP and servlets were after-thoughts for Java as an alternatives to Perl and CGI--or at least that's my memory of things. With garbage collection and simple inheritance, Java was definitely an advance over C++ for the tasks for which it was designed. In the same spirit, PHP seems to me an advance compared to Java for server side programming.

And I haven't even gotten to the database tie-in which I'm just about to take up in my learning.