Peering Behind the Browser

In the first part of this series we looked at the anatomy of a basic JavaScript stored procedure, and in the second part we discussed how to include well-known JavaScript libraries. In this part, we will get to the real meat: scripting the JDBC connection and interacting with the database.
[Read more →]

In the first part of this series we looked at creating and running Rhino-compiled JavaScript stored procedures inside SQL Anywhere. In this part we will look at how to include JavaScript libraries.

As I have mentioned in other posts, JavaScript is best known for its use in the browser. JavaScript in the browser has no concept of including libraries inside the script (similar to import or include in other languages). Instead, libraries are added by adding the appropriate <script type='text/javascript' src='...' /> tags in the HTML file. Under the covers, the browser creates a single JavaScript scope, and it evaluates all of the <script> tags in that scope.

For example, suppose we include the JavaScript JSON2 library inside our HTML file, what happens? Looking at the code in that file, it does two things: First, it creates a JSON object in the global scope. Second, it defines a self-invoking function that adds two methods, parse and stringify, to the JSON object. All future scripts executed in that browser scope will now have access to the JSON object and its methods. The important thing to note here is that it is the browser that is handling combining (executing) all of these scripts inside the same scope. Similarly, if we want to include multiple scripts together in our stored procedure, we will need to do the work of setting up a scope, and executing all the scripts within it.

To accomplish this we will need to write some Java code that manages a Rhino context and scope. To demonstrate it, we will create a stored procedure that returns a JSON-formatted array of the argument to that stored procedure. We will use the JavaScript JSON2 library to generate the JSON object.
[Read more →]

There are a number of open-source scripting languages that have been totally implemented in Java. One benefit of using these languages is that they can run on any system that has a Java Virtual Machine (JVM) installed.

For example, Jython is a implementation of Python written for the JVM. Not only can Jython be run on the JVM, but it can also interact with all of Java’s standard objects. Other popular JVM-based languages include JRuby, Rhino, Groovy, Scala, and Clojure.

Since SQL Anywhere has built-in Java stored procedures, I decided to try experimenting with writing stored procedures in these scripting languages. To begin, I decided to try writing stored procedures using Mozilla Rhino, a JavaScript implementation written in pure Java.

In this post we will create a stored procedure that converts a string to uppercase and prints it out to the message window. We will use the JavaScript toUpperCase() function to perform the conversion. Of course, it would be much simpler to use the SQL UPPER function, but we are simply using this as a proof-of-concept. I will discuss how to script the JDBC connection to do more useful work in another post.
[Read more →]

I am attending and presenting at the the php|tek 2009 show in Chicago this week. The opening keynote was presented by Andrei Zmievski discussing The Future of PHP 6. Although he touched on PHP 6+, he spent a good deal of the time exploring the new features in PHP 5.3. As it turns out, the big new features in PHP 5.3 are closures, and lambda function

If you are attending the show, feel free to pop by the Sybase iAnywhere booth and say, “Hello”.

The first part of this article series ended with the question, “What happens when we call foo(),” in this code sample?

1
2
3
4
5
6
7
8

var foo = function () {  // start of outer function
  var counter = 0;
 
  return function () {   // start of inner function
    counter = counter + 1;
    return counter;      // end of inner function
  }
}();   // end of outer function

The outer function is self-invoked immediately after creation (by the () on the last line). After invocation, the outer function returns the inner anonymous function. However, the inner function references a variable, counter, that was defined in the outer function. What happens when the inner function is invoked?
[Read more →]

As I have been using JavaScript more and more lately, I have become increasingly impressed with the power of closures. Closures aren’t available in C, C++, or Java, and as a result, they aren’t particularly well-known. Before exploring what I like about closures, it is important to first understand how JavaScript treats functions.
[Read more →]

I recently did an interview with Stephan Ahlf of OSExpert.net (and frequent contributor to the SQL Anywhere Web Development forum) about SQL Anywhere: past, present, and future.

The interview is too long to duplicate here, but you can head on over to OSExpert.net and read it there: Rise of the machines: Interview with E. Farrar

One of the interesting features in the developing HTML5 spec is WebSockets. WebSockets are intended to be exactly what they sound like: TCP-like sockets for use in web applications. (For a more detailed description, read WebSocket is neither Web nor Socket).

What does a socket-like communication protocol give you that the current HTTP protocol can’t?

The answer: Full-duplex communication.

That is actually only half true. After all, plenty of web applications appear to get asynchronous notifications from the server today. This is commonly referred to as Comet (in keeping with Ajax’s household cleaner theme), real-time web, or reverse-Ajax. Some of the current methods to do this are:

High Frequency Polling – The browser makes repeated, quick HTTP requests to check if new data is available. The server responds immediately with all available data. The whole cycle repeats itself after a short delay. This method provides the illusion of data being “pushed”, but at the expense of being ‘chatty’.

Long Poll – The browser makes a long-lived HTTP request, but the server defers responding until it has data. Once data is available, the server responds and the cycle starts again. This method is not as ‘chatty’ at the previous one, but in runs into another problem. The current HTML spec only allows browsers to maintain two connections back to the server. The result is you can only have one long-poll in each browser window (unless you do your own multiplexing strategy).

Streaming – The browser makes an HTTP requests, but the server does not close the connection after responding. Instead, it leaves it open indefinitely as a pipe that it can stream data into. However, the pipe is only unidirectional. If the browser wants send data to the server it will need to break the pipe.

In contrast, WebSockets would be appear as proper full-duplex communication pipes that break the current request-response cycle inherent to all HTTP communication (however, under the covers they may still use HTTP). This seems to me to be a natural progression of the web. In considering the early “static content” days of web, the HTTP’s request-reponse cycle made sense. Of course non-browser applications at that time made heavy use TCP sockets because they give an application so much flexibility.

Since it would seem that “browsers are the new desktop”, it makes sense to bring this (decades-old) full-duplex communication protocol to the browser. However the more interesting question is what exactly will developers do with it? After all, the internet is moving more and more towards stateless, RESTful communications which would seem to be at odds with stateful socket-like communication. For one interesting opinion on this, take a look at HTML5 WebSocket and WebJneering.

A few months back I made a post explaining my new-found appreciation for JavaScript. One conclusion I came to in that post was that just because the syntax is similar to some other language, it doesn’t mean you know it. An example of where I have (painfully) learned this is in the way JavaScript handles equality.

Most programmers are aware of the difference between the c-style assignment operator(= ), and the c-style test for equality ( == ):

foo =  1;  // this assigns the value of 1 to foo
foo == 1;  // this tests if foo is equal to 1

Since JavaScript’s syntax looks c-style, it is reasonable to assume that you already know how equality works. Unfortunately, soon you would run into these interesting cases that have caused me much grief in the past:

"0" == 0 // TRUE
"0" == false // TRUE
" 0 " == 0  // TRUE
"" == false // TRUE
0 == false // TRUE

These all evaluate to TRUE because JavaScript actually has two tests for equality. It has a coercing test ( == ), and a non-coercing test ( === ). With the coercing test, one or both of the arguments are converted to another type before doing the test. This can result in some bizarre behavior like the examples above. To avoid these cases it is best to always use the non-coercing version.

"0" === 0 // FALSE 
"0" === false // FALSE
" 0 " === 0 // FALSE  
"" === false // FALSE
0 === false // FALSE

While I think this was a poor design decision by the JavaScript creators (and a clear violation of the Principal of Least Astonishment), it does illustrate why it is dangerous to assume you know one language just because it looks like another one you already know.

Recently I have been hearing a lot of discussion surrounding object-relational mappers, and it is high time I threw my two cents into the mix. My thoughts on ORMs are:

1. ORMs will continue to gain in popularity because they provide a useful abstraction.
2. A lot of the problems with ORMs are because developers are trying to treat them as transparent tools, not opaque abstractions.

I will elaborate on these points by comparing ORMs to scripting languages.
[Read more →]