JavaScript syntax checking

I was working through the Crafty tutorial on the fourth part, "Adding a player-controlled avatar," when I get the blank screen below.



By now I know this means there's a typo in the code, specifically, components.js. I learn the PlayerCharacter component on the website does not have a comma, not like the Bush and Tree components:

Crafty.c('PlayerCharacter', {
  init: function() {
    this.requires('Actor, Fourway, Color')
      .fourway(4)
      .color('rgb(20, 75, 40)');
  }
});

So I put on in after the inner closing curly brace, }. Then the game runs fine.

I realized I'm up the creek, so to speak, if Chrome is this sensitive. There's a high chance I'm going to make this mistake, too.

I search around and find JSLint, JavaScript Lint, etc. I tested on JSLint and it gave so many goggledegook messages and not the one to catch the above problem. After checking stackoverflow, I come to the Google Closure Compiler. The interesting thing is it finds three errors related precisely to the commas--namely, the commas shouldn't be there!

After I remove the commas in Tree, Bush, and PlayerCharacter, GCC is happy. However, the GCC is designed for improving code performance by rewriting the code. What I would really like is for a tool to take an html file and follow the links, checking each file in turn for syntax and semantics.

But not today.

JavaScript of my summer

I won't say that I had dismissed JavaScript. I simply had no use for it. Yet need is a b----. I had been working on PHP development the first half of the summer and out of curiosity, looked into JQuery, the utility of which I could appreciate. It's connection to Ajax is especially interesting. Along came Crafty and I was sold. It was the answer to Android's complexity for time which I did not have and simplicity which I sought. But no, what put JavaScript over the top was Underscore. I was in NYC yesterday and we went to the MoMA. If those Picasso's, Braque's, and Matisse's weren't elegant and simple and profound then...what is? I'm not saying Underscore is a masterpiece. I still don't know enough about it. However, on the surface it looks like one of the most interesting tools I'm come across since Scala.

jQueryMobile first look

I was going down the path of full-blown Android app development, which was not appealing for a few reasons.

First, I need a tool quick.

Second, Android app development is full of so much complexity. It's overkill. Whatever happened to the sample days of J2ME?

Third, Android apps are only for, well, Android.

Finally, using an Android app assumes you have the app. I can't see that working for the lost-and-found application too well. I mean, L&F is more likely to be a one-off sort of thing, not something a user will return to time and again unless they lost something.

Thus, jQM caught my attention.

I don't yet know enough about jQueryMobile except that it appears to go further than jQuery adding UI components in a cross-platform manner. This has plenty of advantages. It's disadvantages, of course, are 1) the app needs the browser, 2) the app looks like a browser, and 3) getting access to the sensors, the camera, GPS, etc. is uncertain. I read online that jQM don't have documentation as much as examples. I wouldn't hold this against jQM for examples may be all one needs.

jQuery first thoughts

Thanks to this tutorial I was able to spin up fairly quickly on jQuery. So now that I have some idea what it is about, I can see why some programmers swear by it. As a design pattern, jQuery appears to do exactly what its name implies: "query" and update the DOM more efficiently in LOC than JavaScript alone. I think that's about the gist of it.

Going further, it's kind of like assembly language for the DOM. I say this because, as an outsider looking in, I don't find jQ the most readable language I've used. $ for the jQuery constructor? $("#divA") finds divA? What can I say? It works.

Ajax -- a first look

Here is a technology I had heard much about for years, especially after it was first released in the late 90s. Having taken a closer look at it, I can see its promise but also it curse. It is now clear that popular travel website like Orbitz, Travelocity, etc. probably use some sort of Ajax while the server searches for booking information. This is good.

However, the 'A' stands for "asynchronous"  and from a programmer's perspective that does not spell relief but pain. Multi-threaded programming is by far the most difficult programming, fraught with all manner of hazards, and Ajax is apparently no different.

That aside, there's the complexity of set up / configuration. Then parsing the response. Then, deciding the basic question of when to call upon all of this complexity.

Users will wait, not forever, of course. However, personal experience suggests that only as a last resort, when all else fails, use asynchrony. Otherwise, avoid it. The system will be more stable and predictable.

Android edvelopment and XML

The prevalence of XML in Android development is a mystery: strings.xml, styles.xml, AndroidManifest.xml, one XML file per activity. It all seems anachronistic, to say nothing of error-prone and unwieldy. Eclipse can automate this and perhaps it does. We'll have to see.

Nexus 7

The device arrived on 21 June. It took me about a week to open it, which was just as since the cover arrived about that time.

My first impression is that the Nexus 7 is not an iPad mini. The 7 has a smaller screen and is not as thin. Even the rubber case is not as slick as the magnetic one that protect the mini.

My first goal was to boot it up. Android is rather colorful and I will admit, more so than iOS.

My second goal was to deploy an app, just plug and go, I had hoped. But not so fast on the Mac which did not recognize it. So I plugged the 7 into my Windows machine and the same thing.

Evidently, the 7 needs some special developer tricks (like tapping the screen 7 times) and drivers.

The latter took me on a world-wind tour that led to the Nexus Root Toolkit, uninstalling drivers, and installing drivers. I doubted it would work yet it did!

Furthermore, when I plugged the device into my Mac, that worked, too. The Mac needed not extra software so I can only assume the NRT must have been installed some drivers and reconfigured the 7, too.

Thus, I've successfully deployed two apps from Android/Eclipse to the 7.

In summary, from a hardware POV, the mini wins hands down. However, from a software development POV, being an iOS developer, I don't see how Apple can win this battle with Google.

JavaScript debugging in Chrome

This seems to me more natural. The only trick was finding the source lines: (three bars on upper right of Chrome) | Tools | Developer tools | Sources | "|>" | file name.

This makes eminently more sense with EclipsePDT than Aptana. EclipsePDT can transfer all the files to the web server and single-step PHP. Then let Chrome single-step the JavaScript. Actually I haven't tested the PDTEclipse-Chrome solution all the way through but each piece works separately. I'll need to integration test them

JavaScript on Aptana

I looked for a way to first write JavaScript in an IDE. I found Aptana which looks like Eclipse with the Aptana plugin pre-installed. It's a lovely concept, providing JavaScript (and PHP) syntax highlighting and intelli-sense (or what it is called when you hit "."). The problem with Aptana is I see how to debug JavaScript in it. I mean, why would I want to do that anyhow where there is Chrome debugging of JavaScript?

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>

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.

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.

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.

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.

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.

Eclipse PDT

As I have written earlier, modern software development for me is to automate the "accidents" of computing to reduce errors. Toward this end, I had installed NetBeans which worked beautifully with PHP. However, I failed to get NetBenas to work with IDE debugging of PHP scripts. It was hugely disappointing because NB came with a recommendation and I liked the refactoring of PHP variables. I wasn't crazy about how NB ran the script in the browser window instead in the IDE window but...nobody is perfect.

Thus, I abandoned NetBeans on the Mac and instead installed Eclipse PDT and EasyPHP on Windows 8. I still struggled a bit but managed to get single-step debugging working.

The trick is to put the project on the local server. Unfortunately there are no instructions as to how to do this. Yet after floundering around, I found the option under Preferences | PHP Servers which positions all project scripts under the web server root. Once that is set up, Eclipse will breakpoint every time at the first statement of the PHP script (this is configurable, I believe) and furthermore, the web page displays in the Eclipse IDE.

Variable inspection is available as well as variable inspection.

Unfortunately, Eclipse PDT does not do refactoring except for the script as a whole.

An elemental Scala parser

I've been writing a parser for Scala to gather complexity information. It doesn't need to "compile" Scala, just extract method information. Thus, I'm duly impressed that anyone could possibly parse Scala, given the difficulties and doubts I have that I've gotten it right. Indeed, some people seem to think that one cannot write a parser for Scala without, in effect, running it to compute the types and sort out implicits. However, as I was cleaning house, I came across an CACM article, Inexact Design--Beyond Fault Tolerance. It deals with hardware but nevertheless struck me as a cool idea, that is, of "inexact," "probabilistic," or "approximate" computing. I think that's kind of what my Scala parser is doing.

PHP class properties

The possibility of dynamically creating new properties in a PHP class seems like a slippery slope. Nixon (2012) says to avoid it because of the potential to create bugs. I agree. Then, why is the possibility there. A programming language's job, among other things on the path of automation, is to automate the detection and elimination of errors.

PHP super class constructors

In C++, Java, and Scala, instantiating an object automatically invokes the parent class's constructor. Not in PHP 5. Instead you have to invoke it yourself. I am surprised. This potentially a huge source of awful errors.

And for a silly reason because PHP creators couldn't put in the automatic invocation? Is there some other explanation?

Then again, Obj-C doesn't automatically invoke it's parent constructor. I've been waist deep in Obj-C for the past few years and while I won't say that never caused a problem, I've had far bigger issues with Obj-C (e.g., not crashing when accessing uninitialized variables).

PHP: First impressions

I had heard from others not good things about PHP, how it is used, at least. In fact, it seems that some websites want to hide the PHP behind them.

Working with a beautiful, Edward-Scissorhands-like language like Scala and recently exploring Haskell which I don't get, PHP feels to me like a throwback to another era, specifically C, which was one of the first languages I learned. After completing chapter 3 of Nixon (2012), I've concluded so far that PHP is not as elegant as Awk but (thankfully) appears to lack the obscurity of Perl.  Forget Basic, Fortran, Scheme, and Prolog. It is perhaps closest to Korn shell scripting. The point it seems to me is not what PHP is but what it can do. Scala is my first choice language. Scala is wonderful for what it was designed to do. But I must remember one size does not fit all. If PHP is going to make me more productive, reduce errors, and help deliver innovative, original solutions, what does functional programming have to do with it?

NetBeans with Zend

First thing is to download to right NB, the "All" version which supports PHP.

Did that.

Next to create a PHP project in NB:

File | New Project… | PHP | PHP Application  | (use default Name and Location) | (Run Configuration) Project URL = http://localhost:10088/testing/PhpProject2, check “Copy files from…” = /usr/local/zend/apache2/htdocs/testing/PhpProject2 | Finish

That worked. Meaning, the PHP runs fine.

Now for debugging. Unfortunately I get "Waiting For Connection (netbeans-xdebug)" on the NB status line. Nothing happens.

The URL is localhost:10088/testing/PhpProject2/index.php?XDEBUG_SESSION_START=netbeans-xdebug

which looks correct. My sense is that there is something trivially wrong in the connection between NB and Xdebug.

This link here is not very hopeful. I'll have to decide what to do.

NetBeans vs. Eclipse PHP development

Some developers like to work directly with the source editor, in some cases without even syntax highlighting. Call it old school. Purists. Definitely not me. For electrical engineers it might be designing circuits at the transistor level. Or programmers working only in assembly language. These things might some day be useful but they are not very productive.

An IDE allows the programmer to focus more on the problem at hand, automating more of the "accidents,  as Brooks (1986) observed.

So when I learned there were Eclipse plugins, PHP Development Tools (PDT) and PHPEclipse, I was naturally relieved.

However, I stumbled upon this page comparing Eclipse and NetBeans and this fellow definitely gave NB the edge.

This in turn lead to a more systematic discover of IDEs for PHP here. I was surprised. NB is free and supports not only a PHP debugger but refactoring, too. NB (All option) comes ready "out of the box," where the Eclipse plugins seem to need more configuration.

I've decided to try NB for these reasons.

On testing

Software development is an empirical yet inexact science. It's empirical in that we never write code without exercising it to see if there bugs. It's inexact because exhaustive testing is infeasible except for the most trivial programs--and even then, one has to wonder. And even if we could exercise the code exhaustively there still no guarantee there are no bugs since the specs could be wrong, we misinterpreted the specs, etc. While there are very formal approaches to testing, I have no data on how often they are employed or whether they are effective. It's just that testing is inherently limited by its very nature as Dijkstra observed and therein lies the dilemma. Testing is at least as difficult and probably more so than writing the software being tested. In fact, I spend most of my time and effort, not in formal testing, but informal testing without a test plan. How does that work?

On problem understanding

Problem understanding is really about asking the question, "What to do?" which is a matter of requirements. Why this question is so important is perhaps obvious. The issue is why is there a tendency to jump to the question, "How to do it?" which is about design. I wonder if we somehow instinctively know how hard the "what" is and simply avoid it. Even when it's written in black and white, it is still possible not to understand what to do. That's why there are courts of law and an entire legal system to interpret what is meant by such-and-such and the experts can still get it wrong. Does that mean we really need to understand the entire problem before we start working on it? I have reasons to believe that is impractical and furthermore, doesn't yield good results. Why? Because often we don't know what to do until we do it, or part of it. Only then the picture may become clearer.

After the dust settles

Someone asked Hsueh-dou, "What is the living meaning of Zen?" Hsueh-dou replied, "The mountains are high and the oceans are wide." ~Hsueh-dou (from The Little Zen Calendar)

I sometimes think the same is often true for software development: the mountains are high and the oceans, wide. In other words, there are no shortcuts--or if there are, they aren't yet apparent.

I've worked extensively with three "drag-n-drop" environments that purport to simplify programming: GameMaker, The GameFactory 2, and App Inventor. They are wonderful tools, inventive and colorful. And there are others, perhaps many, like them that I have heard about but not tried.

Yet after the dust settles, after we get past syntax and what Brooks (1986) called the "accidents" of software engineering, what remains?

The things that were there in the first place: problem understanding, testing, and debugging which the above tools, as powerful as they are, do not even begin to address.

Serendipitous driven development

I'm in the middle (quite literally) of working on a Scala research project involving complexity analysis that ostensibly has little to do with Umbo. The effort has been on- and off-again, thinking about it, not thinking about it and not actually writing code for a few weeks. I had other priorities.

I returned to the project today, after realizing during this little hiatus that there was an opportunity to gather more data and generate more interesting results which required writing more code.

So I wrote this extra code today that extracts the method names from the source. Then, I realized that I had tackled the last major hurdle. The only thing was that each obstacle along the path was solved by a separate program, one to strip the comments and count the lines, another to extract the method names, and finally another to parse the byte code instruction count report produced by a third-party utility.

I only needed to integrate these pieces which is a lot easier.

This approach is not new. The Roman empire was built piecemeal, a conquest at a time. We didn't get to the moon with one rocket or even a single launch. I'm just remarking on how the Scala project seemed to come together as such--or at least, there's definitely light at the end of the tunnel now.

What would have been the outcome if I had instead rushed it or been under more pressure to get it done? Suppose that serendipitous hiatus was not there. The effort would probably have lead to a very different solution.

A true story

I was hiking along the path in the park. I was enjoying the exercise, the sun, wind, trees, and grass. It was a beautiful day. I felt very much "present," in the "zone," as it were.

I had been thinking much of the time about the lost & found project, its simplicity and utility, how much I was going to learn and most importantly, what to name it. Every project has to have a code name. It seems somehow to give the effort a kind of center of gravity.

At any rate, a middle age couple, a man and woman, happened to be coming in my direction as I had made my way up the hill. The man stopped, stooped, and picked up an item. I saw it was a necklace, a long chain with a pendant of sorts.

As he stood up and at the instant we passed one another, I overheard him ask his partner, "Do you know if they have a lost and found here"?

Perhaps this was nothing more than a meaningless coincidence. But, I wondered, what was the chance? At that moment, on that day, we're there, the necklace is there, I'm thinking of this, he says that?

I didn't know.

I chuckled and took this little incident to be a hopeful sign of good luck, namely, that I was on the right track--and in more ways than one!

And to acknowledge that sense of good luck and not waste it, I decided to name this project, Umbo, after the  album, Umbo Weti: A Tribute to Leon Thomas (2009), by Babatunde Lea.

User stories

I looked over function point analysis today. It's and old approach from the structured programming days. I had heard much about it in the 80s and today it sounds anachronistic, files, data, physical design, etc. Use cases on the other hand live higher than even the logical view: they are about what to do, not how to do it.

The problem with use cases, however, is the emphasis on documentation and they are "heavy weight" in that sense, not appropriate for agile development.

The user story, as an agile method, cuts right to the chase, as it were: "It captures the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. User stories are written by or for the business user as that user's primary way to influence the functionality of the system being developed." 

Some thoughts on users

However the requirements are expressed, whether in use cases or function points, it seems there are three types of basic users.

1) Someone who lost something
This user needs to report as much as they can about the object of interest, what it is, the location, shape, size, color, version, etc.

Curiously, when I've lost something, it's never one place I'm sure about. It could have been in multiple places. We'll need to deal with that twist.

Also, it would be a knockout if I had a photo of the thing or a link for a version of it.

This person may also want to leave contact information, although the confidential nature of it will need to be protected from casual access.

2) Someone who found something
This user needs to report as much as the can, too, about the object of interest: what it is, the location where it was found, the last location of it (e.g., did they leave it where it was, take it to the lost & found pickup office), etc. And once again having a photo would be dynamite, either of the actual thing or a version of it. And a photo here, too, would be awesome.

This person, too, may want to leave contact information which is protected from casual access.

3) Admins who need to maintain the system
In both of the above cases, these users won't need a login, although something to thwart bots (e.g., CAPTCHA) may be needed.

The admins need to add users who can maintain the system including functions to add other admin users, manage lost & found items, gather statistics, clean out the system, etc.

The admins could also set configuration parameters for the system (e.g., how much old stuff to show, how often to purge the system, etc.).

The admins jobs might also entail contacting the person who lost something. For instance, suppose someone finds a backpack and brings it to the lost & found office. An admin, recognizing that the backpack looks like one reported in the system, could initiate contact with the person looking for their stuff. The admin might simply have the system contact the person via email or text if something was brought to the office and the system notes that fact. If no acknowledgement comes back after say a week, the system might automatically move the item to the recycle bin to be emptied periodically.

Bagging lost-n-found

Ocho Uno (a.k.a., 81) is a cloudy application for managing lost-n-found stuff.

I had for years thought of projects for students to work on until I ran out of ideas. Then it occurred to me: Why should I have all the fun? So for the first time I asked students to come up with their own projects. In turn, they produced some very interesting proposals and ultimately demonstrations, one of them being a system for solving the lost and found problem. They saw the solution as going beyond merely recovering things but furthermore reducing the anxiety of misplacing valuable belongings.

The first student version was an exploration of the concept, namely, the development process. They ultimately implemented a desktop rich client as a prototype per the requirements but we knew it had knockout potential as a mobile app.

I never bored of the idea. They definitely had something that which, at least conceptually, had everything a killer app tended to have: simplicity and utility. Nobody needs to explain it.

Who has ever lost keys, smart phone, book, hat, or rabbit foot? Who has ever found what they were looking for and wasn't deeply grateful?

The lost & found project is an further experiment that builds on all these ideas and experiences.

However, in my view such a system is not about just reporting and/or recovering lost objects. There are the problems of bagging (literally, gathering), matching, cataloging, collating, and often, recycling unclaimed and sometimes unwanted paraphernalia of the throw-away world.