Sunday, April 04, 2010

AES Encryption in Java

I wrote this block of code a couple years ago, but it has served me well. I remember it being quite a challenge to get it to work properly. There was, and maybe still is a dearth of decent examples on using AES encryption from Java. The examples I found didn't deal with Cypher Block Coding (CBC). CBC is essential to decent encryption because it feeds the output of one cyphered block forward into the next, thus creating a cascade of randomness. All you need is an initial random phrase in the data you wish to encrypt. If you don't use CBC, you'll notice that blocks of your encrypted data can easily be recognized as separators in what you are encrypting. For example, let's say I encrypt the phrase "user:bob:password:abc". The substring "user:" and "password:" will cause an identifiable pattern in the encrypted data. If someone has access to snoop the wire, they can literally lift the encrypted username and password out of someone else's transmission, and paste it into their own. While CBC with a leading random phrase will make it impossible to identify such non-randomness, you still have to guard against someone injecting cruft into the encrypted data. This should be done by appending an MD5 hash of the unencrypted data, then encrypting the whole ball of wax.

    private static String encrypt(String encryptMe, byte[] cryptKey, SecretKey secretKey, byte[] iv){
        try {
            Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding", "SunJCE");
            cipher.init(Cipher.ENCRYPT_MODE, secretKey, new IvParameterSpec(iv));
            byte[] raw = encryptMe.toString().getBytes("ASCII");
            if(log.isDebugEnabled())log.debug("unencrypted bytes: " + raw.length);
            byte[] cipherText = new byte[cipher.getOutputSize(raw.length)];
            int ctLength = cipher.update(raw, 0, raw.length, cipherText, 0);
            ctLength += cipher.doFinal(cipherText, ctLength);
            if(log.isDebugEnabled())log.debug("ctLength: " + ctLength);
            if(log.isDebugEnabled())log.debug("cipherText Length: " + cipherText.length);
            //raw = cipher.doFinal(raw, 0, raw.length);
            byte[] copy = new byte[ctLength];
            System.arraycopy(cipherText, 0, copy, 0, ctLength);
            String encrypted = new String(new Base64().encode(copy), "US-ASCII");
            return encrypted;
        } catch (Exception ex) {
            throw new RuntimeException(ex.getMessage(), ex);
        }        
    }

Friday, April 02, 2010

what's in your history?

[ghendrey@geoffunix hadoop]$ cut -f1 -d" " ~ghendrey/.bash_history | sort | uniq -c | sort -nr | head -n 20
    206 hadoop
     44
     27 ls
     23 cd
     18 su
     17 grep
     15 tac
     11 pwd
     10 exit
      8 env
      5 less
      4 /mnt/hadoop/hbase-0.20.3/bin/hbase
      4 man
      4 ifconfig
      3 telnet
      3 start-dfs.sh
      3 source
      3 mount
      3 ant
      2 vi

Tuesday, February 23, 2010

Webscale Computing and Hadoop

I've been using Hadoop extensively for a month or so now at the office. I've been a big fan of Doug Cutting's Lucene technology, so when I heard that Doug Cutting was the guy behind, Hadoop, that pretty much pushed me over the edge and I started using Hadoop for building new types of database indexes from multi-gigabyte datasets.

Hadoop is an incredibly rich software stack consisting of three main pieces:
  1. The Hadoop Distributed File System (HDFS)
  2. A Map/Reduce infrastructure consisting of Daemons that layer services on top of HDFS
  3. A set of APIs allowing a data processing task to be split into simple Map and Reduce phases
There's a fourth piece, which is the many related tools (HBase, Hive, Pig, etc) which are layered on top of Hadoop.

If one was to read the description of map/reduce one might conclude that it is pretty much nonsense. In fact, it sounds to trivial to even be called an algorithm. Put things into groups, operate on the groups. Big deal. It sounds pretty much like common sense. Until you work with Hadoop, you really cannot appreciate all of the benefits that the Hadoop stack brings. It's really the collective benefits of the entire stack that make for the game changing experience that programming with Hadoop really is.

With problems of processing huge datasets, the devil is in the details. Hadoop provides a framework that removes all of the annoying complexity associated with big data sets. In essence you write two simple methods and from that point on you don't care much whether you are operating on 1 byte or 1 TB. This is possible in large part because HDFS allows you to think of terrabytes worth of data as a simple URL such as hdfs://namenode/user/geoff/BigDataSet. HDFS takes care of replicating your data, and figuring out where the data blocks actually reside in the cluster. As an added bonus, Hadoop automatically deals with nuances such as the files being zipped. But wait, there's more. From the hadoop command line, you can run commands to cat and grep these URLs, again, acting as if they were simple local files.

For me, one of the most interesting side effects of running a hadoop cluster has been how it changes ones ability to interact with peers on a webscale computing project. You can now shoot your co-worker a URL to a 200GB file, and they can poke and prod at the contents by doing things like "hadoop fs -text hdfs://namenode/user/geoff/BigData".

I'll try to write more about this later, but for now suffice it to say that Hadoop is quite exciting to work with. I think the criticism by Michael Stonebreaker have totally missed the point of what a good implementation of a map/reduce framework can yield, probably because their criticism focused on the map/reduce algorithm, which in and of itself is trivial. And that's really the point. It's really all about the tools and the entire stack that make map/reduce simply a "part of this complete breakfast" when it comes to hadoop. So don't forget the toast, juice, and yummy Cheerios!

Sunday, February 21, 2010

HATEOAS - Hypermedia As The Engine Of Application State

Roy Fielding's PhD dissertation on Architectural Styles and the Design of Network-based Software Architectures is the seminal paper on the RESTful style of web architecture. Before discussing the paper, let's first discuss what it is, because it seems quite unusual in its approach as a PhD dissertation. Reading this paper in the 21st century, one might conclude that the paper is an "experience paper" (as defined here). However, as noted, "An experience paper that merely confirms that which is well known as opposed to that which is widely believed is of little value." However, in the early 1990's, the topic of the dissertation was probably not widely known. The irony now, is that as the term REST becomes more and more commonplace, and is applied to non-RESTful systems, the level of confusion over REST might be rising, not falling.


I was certainly confused for a long time about what constitutes a RESTful system. Isn't anything that has a URL RESTful? Definitely not, as the presence of resource identifier is just one of several properties that make a system RESTful. Fielding has recently written this article listing the properties he sees as essential to a RESTful system. After working quite a bit on the RESTful system for NextDB.net, it seems that me that the principle of Hypermedia As The Engine Of Application State (HATEOAS), identified on the original dissertation section 5.1.5, might be the most important principle of all. Incidentally, of all the properties outlines in the recent article, Fielding chose to title the article "REST APIs Must be Hypertext Driven". To my mind, that confirms my hunch that HATEOAS is perhaps the least understood principle of REST, and the principle in need of the most discussion and explanation.


The essence of HATEOAS is that the client needs to understand as little as possible. In essence, this is quite similar to the experience a human requires when he browses a website. In order to move from one page to the next, we must be given links that we can navigate. This is our common experience on web pages. Consider an alternative, and less user friendly,  scenario in which the home page simply consisted of a set of instructions (an API, if you will). One instruction might read "To view articles about sports, visit a URL consisting of "http://sitename/topics?name=topic-name" and replace topic-name with 'SPORTS'". You would be forced to manually construct the URL and enter it into the browser. The notion of such a website seems absurd, and yet it describes the scenario common to RPC or "fake REST" APIs in which the client is responsible for constructing the state-transition links rather than being handed a hypermedia document that provides the available state transitions. 


Quoting Fielding: "...all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations".


This is an interesting article that shows how non-HTML hypermedia can be used in keeping with HATEOAS. However, I think there are excellent reasons why Plain Old HTML (POH) is the best hypermedia choice for use with RESTful systems:


  1. HTML was made for hypermedia (it has well known structures for encoding links)
  2.  Your mom knows what HTML is
  3. By using POH for HATEOAS, your RESTful system's content can be indexed by search engines
  4. You can easily view and traverse your system states using a web browser
POH for HATEOAS is the approach taken by NextDB's REST system. In the documentation, we do describe the explicit structure of several of the URL's, but we stick strongly to the principle outlined by Fielding that, beyond the entry point URL, or "bookmark" you shouldn't need to know the structure of any of the URLs. Using POH for HATEOAS, the proof of NextDBs' adherence to this principle is quite straightforward: I simply give you an entry point URL (a bookmark) to a table and allow you to navigate the links served in the POH. For example, here is the bookmark to an account named 'geoff' with a database named 'testchars' and a table named 'lines':


From the URL above you can click on links to visit various pages of the content and sort the content. No knowledge of an API is required. Taken to its logical conclusion, I see no reason why the RESTful service should not be allowed to directly present styled content, when the consumer of the content is human. So that is exactly what we do in NextDB, by allowing the POH to include CSS. Here is an example:


http://nextdb.net/nextdb/rest/geoff/testchars/lines/style/newspaper-a

We're techically violating HATEOAS because we don't provide links to the styled content, rather the developer has to know about the available styles by reading our documentation. However, we'll soon correct this, as well as allowing the developer to pass in links to his own CSS for inclusion in the returned POH.

Finally, not only do we allow you to style the POH, but we also allow you to apply XSLT transformations to the POH in order to alter the structure (as opposed to style) of the POH. Fielding discusses "Processing Elements" or "Transformers of Data" in his thesis. I believe XSLT to be the POH analog for processing elements, in that they are well understood, easily encapsulated in a markup, and supported by a wide array of processors (including browser-side processing, although this tends to be less portable, which is why NextDB opted to perform the transformation on the server).

In summary, NextDB is a truly RESTful database. This is important not because it conforms to a buzzword, but because it has made NextDB so easy to use that even non-programmers are able to embed the POH hypermedia in their sites. Project Have Hope is a great example of one such site. The "catalogs" of sponsorable children and women in Africa is POH served out of NextDB.net.  The HATEOAS architecture is the key to opening the database content to CMS engine-driven sites, as well as accessibility to web search engines.









Monday, February 15, 2010

Spam Bucket

I'm curious to see how much spam accumulates in this database if I put a publicly writable database table on my blog

UPDATE: I have the answer: "A LOT"
"Salad Man", I commend you! "get three inches on your dick!" is a noble spam to leave on my blog, but I am dissapointed you did not include a video!!!

Saturday, February 13, 2010

NextDB REST tables

NextDB REST tables can be easily embedded anywhere on the web. For example:
<iframe src='http://www.nextdb.net/nextdb/rest/geoff/vids/sk8;~cols=PK,video_CONTENT_TYPE,video_FID/style/newspaper-a/pgsz/3' />

Friday, February 12, 2010

An update on JTIdy and XSLT

A couple months back I blogged about JTidy I have an update to that story. If you plan to run your XHTML through an XSLT transformation, don't use tidy.setXHTML(true). The reason for this, I found after a lot of debugging. There are a "named entities", specifically ones such as &acirc; (and many others) that are declared in the XHTML DTD. And guess what? They are NOT valid in XML.

Quick refresher: XML has only five named entities that it supports. 

So you're thinking, no biggie, I don't think my documents will ever have a &acirc; named entity in them so what do I care? Well, they can creep in my accident, if you are allowing users to save inputs into a database. For example, there are ISO-8859-1 (Latin-1) characters with no UTF-8 equivalent. One that I have repeatedly seeen over the years from European users is the "left quote". It doesn't even exist on an american keyboard, and when it gets posted to a system expecting UTF-8 it wreaks havoc, causing a run of several incorrectly decoded characters.

And so, you can get "inadvertant" named entities in your XHTML output due to this sort of character mangling where the UTF-8 byte stream interpretation gets borked. So now, instead of just getting some gibberish in your XSLT, the entire transformation crashes, and you get no output at all except a complaint that the input document had an unsupported character reference. Hence the solution: tell jtidy NOT to produce XHTML, but instead to produce plain old XML, like this: tidy.setXmlOut(true); When you do this JTidy doesn't put these named entities in anymore. 

One other surprise I ran into is that XML actually *DOES* support numeric character entities. So you will still get numeric character entities in the XML output such as &#128, which although specifically forbidden by HTML still render properly in most browsers. So JTidy happily outputs these numeric character entities in its XML output. You are now safe to apply XSLT transformations on a valid XML input, however, just be aware that the XHTML output of your XSLT transformation is in violation of the aforementioned forbidden, but practically allowed, numeric entities.

Confused yet? Me too. Let's all speak Esperanto and adopt 7-bit ASCII as the only allowed character set.


Thursday, January 21, 2010

Character Encoding Hell

Over the years, one of the perennial hassles that web services programmers grapple with, is undoubtedly character encoding. One of the biggest contributing factors to the problem goes all the way back to the fact that the original definition of URL-encoding failed to specify how to deal with UTF-8 or other non-ascii encodings outside the reserved character set. The current spec states that if you want to send UTF-8 strings, for example "てすと   (te-su-to) ", then you should percent encode each byte of the UTF-8 character sequence (%E3%81%A6).

Two excellent pages for test data, should you need to test some multi-byte UTF-8 characters are:

Sadly for AJAX applications, actually generating these percent encoded byte sequences is non-trivial, and doesn't seem to be readily available "off the shelf". I've had to resort to JS source such as this.Without such scripts, various attempts to use "off the shelf" JS methods produce wacky results, such as unicode representations of the strings (like \uXX\uXX) which is completely useless for transmission in a URL.

On the server, there are also problems in receiving and properly decoding the bytes. One of the biggest problems is that Java web servers don't do it in a standard way. For example, when I was working on Tomcat 5.x,  the Servlet getParameter method would assume ISO-8859-1 (Latin 1) encoding, which would garble any properly UTF-8 percent encoded bytes. There is a well hidden setting to switch the default to UTF-8.


On the other hand, Jetty *does* assume the URL is UTF-8 percent encoded (love jetty!!). So without some config tweaks, don't expect servlet containers to *uniformly* deliver properly decoded UTF-8 strings.

My latest installment of UTF-8 Hell comes as I implement some more REST capabilities for Nextdb.net. Here is the content of a message I just posted to Paul Sandoz of Jersey fame (man, that guy must never sleep. he is *on the ball* on the Jersey mailing list). Mad props to Jersey. It is just killer. But I digress:

Hi Paul,

I got to the bottom of this by trying to unmarshal the string in three different ways. As I already mentioned the first way was just to call FormDataBodyPart.getValue().

toString(). This produced the improperly decoded String.

Then I tried two other ways, both of which correctly unmarshalled the bytes from the POST. As supporting information, here is the CURL line I was testing with, and an excerpt from the CURL trace, showing the proper bytes being posted.

curl --trace traced -F line=てすと http://localhost:8080/nextdb/rest/geoff/testchars/lines/rowid/PK/1

The 9 bytes highlighted below are the three japanese characters.

=> Send data, 148 bytes (0x94)
0000: 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d ----------------
0010: 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 63 61 --------------ca
0020: 33 32 31 65 31 30 39 66 36 37 0d 0a 43 6f 6e 74 321e109f67..Cont
0030: 65 6e 74 2d 44 69 73 70 6f 73 69 74 69 6f 6e 3a ent-Disposition:
0040: 20 66 6f 72 6d 2d 64 61 74 61 3b 20 6e 61 6d 65  form-data; name
0050: 3d 22 6c 69 6e 65 22 0d 0a 0d 0a e3 81 a6 e3 81 ="line".........
0060: 99 e3 81 a8 0d 0a 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d ......----------
0070: 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d ----------------
0080: 2d 2d 2d 2d 63 61 33 32 31 65 31 30 39 66 36 37 ----ca321e109f67
0090: 2d 2d 0d 0a          

Both of the following two methods will properly unmarshal the correct String:

method 1: use InputStream to get raw bytes

                    InputStream is = theFormDataBodyPart.
getValueAs(InputStream.class);
                    try {
                        byte[] bytes = Util.readInputStream(is, 1024 * 1024, 1024 * 1024 * 1024);
                        log.debug("this many bytes: " + bytes.length);
                        for(byte b:bytes){
                            log.debug(Integer.toHexString(
0x00FF&b));
                        }
                        String s = new String(bytes, "UTF-8");
                        log.debug(s);
                        return s;
                    } catch (IOException ex) {
                        throw new RuntimeException(ex.
getMessage(), ex);
                    } 

Method 2) use theFormDataBodyPart.
getValueAs(String.class)

Cheers,
geoff

Monday, January 04, 2010

Well said....

The exchange between Churchill & Lady Astor: She said, "If you were my husband I'd give you poison." He said, "If you were my wife, I'd drink it."

A member of Parliament to Disraeli: "Sir, you will either die on the gallows or of some unspeakable disease." "That depends, Sir," said Disraeli, "whether I embrace your policies or your mistress."

"He had delusions of adequacy." - Walter Kerr

"He has all the virtues I dislike and none of the vices I admire." - Winston Churchill 


"I have never killed a man, but I have read many obituaries with great pleasure." Clarence Darrow

"He has never been known to use a word that might send a reader to the dictionary." - William Faulkner (about Ernest Hemingway). 


"Thank you for sending me a copy of your book; I'll waste no time reading it." - Moses Hadas

"I didn't attend the funeral, but I sent a nice letter saying I approved of it." - Mark Twain

"He has no enemies, but is intensely disliked by his friends." - Oscar Wilde

"I am enclosing two tickets to the first night of my new play; bring a friend.... if you have one." - George Bernard Shaw to Winston Churchill

"Cannot possibly attend first night, will attend second... if there is one." - Winston Churchill, in response.

"I feel so miserable without you; it's almost like having you here." - Stephen Bishop

"He is a self-made man and worships his creator." - John Bright

"I've just learned about his illness. Let's hope it's nothing trivial." - Irvin S. Cobb

"He is not only dull himself; he is the cause of dullness in others." - Samuel Johnson

"He is simply a shiver looking for a spine to run up." - Paul Keating 


"In order to avoid being called a flirt, she always yielded easily." - Charles, Count Talleyrand

"He loves nature in spite of what it did to him." - Forrest Tucker

"Why do you sit there looking like an envelope without any address on it?" - Mark Twain

"His mother should have thrown him away and kept the stork." - Mae West

"Some cause happiness wherever they go; others, whenever they go." - Oscar Wilde

"He uses statistics as a drunken man uses lamp-posts... for support rather than illumination." - Andrew Lang (1844-1912)

"He has Van Gogh's ear for music." - Billy Wilder

"I've had a perfectly wonderful evening. But this wasn't it." - Groucho Marx

 

Wednesday, December 16, 2009

JavaOneRadio interview 2009

Was just going through some photos from earlier this year. Here's a shot of the interview I did on JavaOneRadio about location based services and my work at deCarta.



Sunday, December 13, 2009

Nerds!


Saturday, December 12, 2009

a==1 or 1==a

I was in one of Dave Nagle's lectures at Carnegie Mellon in which he explained that he'd once spent an inordinate amount of time on a bug hunt. The cause: 'a=1' ... a typo. He meant to type 'a==1'. To insure he'd never suffer that pain again, he coded all his boolean comparisons with the literal on the left hand side, like this: '1==a'. This prevents the typo '1=a' because the compiler won't allow an assignment to a literal.

After going on the exact same bug hunt myself, many years ago, I kicked myself for not following his advice. I've coded all my Boolean expressions in the "literal on the left" style ever since, and the compiler has saved me many a bug hunt.

To that paradigm I now have a small addition to make. I've started coding my string equals comparisons in literal-left style as follows: "something".equals(a)

This has the nice effect warding off null pointer exceptions when a is null. I think this literal left style is better than (a+"").equals("something") which is another trick for warding off null values of a.

Friday, December 11, 2009

Keep the hot air flowing

This is a funny satire of the climate change talks..."now powered exclusively by wind".

Saturday, December 05, 2009

Keep it on the DL

I came across what has got to be the most rarely used HTML element. Ever heard of <dl>? me neither. Stands for "Definition List". Inside a DL you put Definition Terms (DT) and inside a DT you put a Definition Description (DD). It actually is a very handy way to markup key/value pairs, such as "firstname: bob" or "Age:34". So if you've got some kind of Object and you want to markup its fields, give the DL a try.

Thursday, December 03, 2009

JTidy and handling HTML embedded in database strings

I've been dealing with an interesting issue. A customer's app needs to store documents created by end users. The document's are really just paragraphs created by the end user, using the YUI Rich Text/HTML editor. The user might also use the "plain text" editing mode, in which case they would actually enter tags like < h1> manually. With this freedom comes the inevitable possibility that they will enter invalid HTML. Since these documents will be stored in NextDB the user might also apply an XSLT transformation over the default HTML presentation of the result set.

The problem is that if the user enters invalid XHTML, like they just throw <blort&rt; into their document, then the XSLT will crash. The problem is made gnarlier by the fact that the documents themselves are likely to be fragments (and in fact they have to be fragments so that when they appear in the context of the default HTML presentation that they get treated as a valid portion of the overall document). In other words, if the user puts tags around their document, you have to strip those body tags off, so that the default HTML presentation doesn't have a nested body.

Enter JTidy. The JTidy library is all about handling crapped-up HTML, and fixing it on the fly. The journey to getting JTidy working was longer than I expected due to an unpleasant interaction with Maven. So, despite the fact that I had the most recent version of JTidy on my Netbeans's project's classpath, when I used Maven to startup Jetty using the mvn Jetty plugin, I would get runtime errors complaining that the method I was trying to call (tidy.setPrintBodyOnly(true);) didn't exist. So, like any good bughunt, the fub began. I knew that Tidy.class was somehow sneaking into my runtime classpath. The first place I looked was my local .m2 repository -- no joy. Finally occured to me that this must be an internal inclusion of an old Tidy jar by maven. When I ran 'grep -r Tidy.class' on my maven directory, I found that maven's 'uber jar' (maven-core-2.0.7-uber.jar) did in fact contain the older version of JTidy. Turns out if you look at the internal dependencies for Maven, you find that it depends on an old version of JTidy. So I unzipped the uber-jar, replaced all the JTidy classes with the latest and greatest, rezipped the jar, and ...badabing badaboom...problem solved. Bing bang boom, very good have a drink.

The actual coding took less than 2 minutes. Argghh talk about an 80/20 rule. Anyhow, JTidy does exactly what I want. Fix any crufted HTML that the user might enter, and then extract only the content of the body element (and even better, if the user doesn't include a body, JTidy fixes that first). So it all boils down to this (just to print the tidied content):

Tidy tidy = new Tidy();
tidy.setXHTML(true);
tidy.setPrintBodyOnly(true);
tidy.parse(new ByteArrayInputStream((val+"").toString().getBytes()), System.out);

Epilogue: maybe blogger.com should start using Jquery. Ironically, this rich text editor threw up on some tags I typed into this post, and I had to spend a few minutes cleaning up the mess!!!

Thursday, November 26, 2009

Good news on C02 Emissions


Obama's announcement, combined with China's recent pledge, is the first good news I've heard on climate change -- ever! Happy Thanksgiving!

Wednesday, November 25, 2009

Viterbi Maximum Liklihood Decoding

Last night I was following up on a hunch that the Viterbi Maximum Liklihood Decoding algorithm could have application for spell checking. I remembered this algorithm from a class I took at Carnegie Mellon called Digital Communications. I went back to the course book, and started reviewing the matter. I hadn't remembered this course book as standing out from others, but now I can really appreciate how well written it is. It has very clear treatment of the subject matter with well broken-out examples, that build throughout the topic. Sklar is a great writer, and he clearly loves the subject matter. I like his pithy conclusions at the end of each chapter. He has a flair for understatement:

"In the last decade, coding emphasis has been in the area of convolutional codes since in almost every application, convolutional codes outperform block codes for the same implementation complexity of the encoded-decoder. For satellite communications channels, forward error correction techniques can easily reduce the required SNR for specified error performance by 5 to 6dB. This coding gain can translated directly into an equivalent reduction in required satellite effective radiated power (EIRP), which consequently reduced satellite weight and cost."

After reviewing the Viterbi algorithm, I was curious about who this Viterbi guy was, anway. I'd also seen a chart in the Sklar book, attributed to the "Linkabit" corporation. Turns out Viterbi founded Linkabit, then later Qualcomm, an eventually donated $50 million to USC where the Viterbi school of engineering bears his name. Interesting story.

Oh, and it turns out the Viterbi algorithm does have applications to spell checking.

Sunday, November 22, 2009

Order-invariant Path Parameters with JSR-311 JAX-RS and Jersey

When defining web service resource URLs, you may find yourself in the situation in which you want path parameters to be viable in any order. For example, shouldn't these two URL's both be accaptable, and point to the same resource?

.../person/firstname/geoff/lastname/hendrey
.../person/lastname/hendrey/firstname/geoff

I've found that the best way to do this is to creat a single resource class, in this case Person, and to define subresource locator methods for "firstname/{firstname}" and "lastname/{lastname}". The trick is to return "this" in your subresource locator method, which affectively turns the subresource locators into a means to setting instance fields on the Person instance.

So when we look in the "PersonResource" class, our subresource locator method for 'firstname' is:

@Path("/person")
public class PersonResource{
private String firstname;
private String lastname;

@Path("firstname/{firstname}") //subresource
public Person getSubResource(@PathParam("firstname") String fname){
this.firstname=fname; //set instance field on this resource
return this;
}

@Path("lastname/{lastname}") //subresource
public Person getSubResource(@PathParam("lastname") String lname){
this.lastname=lname; //set instance field on this resource
return this;
}
}
The locator method for lastname follows the same patter. And that's all there is to it! I have not found this pattern covered or described in any of the docs for Jersey, but I have found it indespensible.

Creating "alias" URLs for Jersey JAX-RS JSR-311 resources

In NextDB.net REST we are supporting two syntaxes for accessing resources. Let's call it a "fully qualified" resource, and a "shortcut" to the resource. For example, to view a table with its fully qualified URL, you can enter a URL in the format:

http://nextdb.net/nextdb/rest/home/{account}/db/{db}/tbl/{tbl}

for example: http://nextdb.net/nextdb/rest/home/geoff/db/testchars/tbl/lines

The "shortcut" URL would be:
http://nextdb.net/nextdb/rest/{account}/{db}/{tbl}

for example http://nextdb.net/nextdb/rest/geoff/testchars/lines

There's a simple "trick" you can apply using JSR-311 to make your resource appear at two different URLs. First, start with your "fully qualified resource". For example, here is snippet:

@Path("/home/{account}/db/{db}/tbl/{tbl}")
public class TableResource extends AbstractSelectableResource{
@PathParam("account") protected String account;
@PathParam("db") protected String db;
@PathParam("tbl") protected String table;
...

Now, to make an "alias" or "shortcut" URL, just define a dummy class that extends the resource you want to make a shortcut to. The purpose of this class is simply to "mount" the resource on an additional URL. Be sure to include all the path parameters and their names must be identical.

@Path("/{account}/{db}/{tbl}")
public class ShortcutToTableResource extends TableResource{
//this class is intentionally empty
}

Now your resource will be available on both URLs!

Wednesday, November 11, 2009

Jamwiki

A few weeks ago I installed JamWiki to document the new NextDB REST features:

http://www.nextdb.net/wiki/en/REST

I wasted a lot of time on XWiki, which basically was bloated, didn't work well, and basically produces a constant stream of stack traces. JamWiki works really well, it's nice and clean.

Sunday, November 08, 2009

New ideas for REST in NextDB.net

I've got some more stuff to work on with regard to REST. Here's a
peek:

support for relationships in REST URLs (calling them 'links')

...account/db/link/FRIENDSHIP/from/uname/john/to/uname/tom

The path parameters "from" and "to" describe the tail and the head of
the relationship, respectively. In other words, we can draw a
relationship as an arrow from one table to another table. This makes
'from' and 'to' the natural path parameters.

The REST URL above is equivalent to:

NAME=FIND_FRIEND;
ROW f1 FROM FRIEND;
ROW f2 FROM FRIEND;
f1 RELATED f2 VIA FRIENDSHIP;
WHERE(){
f1.uname='john' AND f2.uname='tom'

}

In the REST URL, you don't have to specify any constraint on the 'to'
side of the relationship. The following URL would retrieve *all* of
john's friends.

..account/db/link/FRIENDSHIP/from/uname/john

is equivalent to:

NAME=FIND_FRIEND;
ROW f1 FROM FRIEND;
ROW f2 FROM FRIEND;
f1 RELATED f2 VIA FRIENDSHIP;
WHERE(TEXT name1){
f1.uname=${name1}

}

You'll also be able to execute your named queries directly via rest:

.../account/db/query/FIND_FRIEND/name1/john

So it all will play nicely with existing queries you have already
defined, and new ones you may define in the future.

I also intend to support cookies. So let's say you wanted to log a
user in via https, and then securely transmit his password with each
subsequent REST URL using regular HTTP (not https). First the user
logs in via a secure (httpS) rest access to a query you named LOGIN.
So the password below would not be in the clear, since the form on the
HTML page would GET to an HTTPS url. The URL is constructed
dynamically by the form on submission:

https://nextdb.net/...db/query/LOGIN/uname/geoff/pwd/xxxxxxx;set-cookie

the 'set-cookie' matrix parameter tells nextdb to return a set-cookie
HTTP header with a value equal to cypher('xxxxxxxx'). I.e., nextdb
will encrypt the value that was sent in your request's REST URL,
wherever it finds ;set-cookie, and tell the browser to pass a cookie
named 'pwd' (in this example) with a value that is the encrypted
version of whatever is in the REST URL for the password in the pwd/
{password} path parameter. The set-cookie matrix parameter can occur
at any path segment in the URL, and would be applied to whatever path
parameter is described by the path segment.

from that point on you can use regular rest URLs and nextdb will
substitute into your URL the encrypted cookie value. So you can use
URL's like this in your application, for later actions that require a
user's password:

.../db/link/ACCOUNT_DETAILS/from/pwd/;get-cookie

The get-cookie matrix parameter int the URL allows an HTML page to be
designed with static URLs, into which nextdb will dynamically
substitute the URL path parameters with values sent by the browser as
cookies. It's a bit of a mind bender but this allows a site be
designed with static URLs. The only dynamic URL ever generated by the
app is the single login query that sets the pwd/{password} path
parameter.

so when nextdb receives the static URL above, it will first see that
the URL incudes a get-cookie matric paramter. NextDB will then look
for a cookie named 'pwd' sent by the browser (or other http client),
decrypt the cookie value, and place the value into the URL where it
finds the get-cookie matrix parameter:

.../db/link/ACCOUNT_DETAILS/from/pwd/xxxxxxxx/

The URL above is then equivalent to this NextQuery expression:

NAME=ACCOUNT_DETAILS;
ROW r1 FROM USER;
ROW r2 FROM ACCOUNT;
r1 RELATED r2 VIA MY_ACCOUNT;
WHERE(){
r1.pwd='xxxxxxxx'

}

The net effect of this new style of REST url for queries and relationship traversal is to vastly reduce the amount of code an applicaiton has to write, and hopefully to make nextdb accessible to HTML/front-end developers.

Native REST support in NextDB.net

I'm really stoked on using REST to access NextDB.net. I've setup a Wiki for NextDB.net and here is our REST wiki page: http://www.nextdb.net/wiki/en/REST


Beeing down with a bad cold the last few days, ironically this has given me
some time to work with Jen from Dartmouth Design on using the REST features
to build some features for Project Have Hope. She has graciously offered to
share the preliminary results. So far we've used nextdb for creating
profiles of children to sponsor. The entire page, including the paging
links, profile data, and paypal buttons, is created by applying an XSLT
transformation to the table served up by nextdb. The result is sourced in an
iframe and loaded into a Joomla module. This appears to be a very nice way
to integrate nextdb content with Joomla. I'm also very stoked to see NextDB
used on such a worthy project.




You can read about the XSLT approach here:

http://www.nextdb.net/wiki/en/REST#XSLT_(reformatting_your_data%27s_presentation


This is the XSLT that is being used by Project Have Hope.
http://nextdb.net/nextdb/rest/dd/phh/config_files/row/1/xslt.xslt

I've just learned XSLT so I think there are many things that can be done
smarter, and there is also a bit of cruft template in the XSLT that is never
used (for example the 'append-pad' template is never used) and needs to be
cleaned up. But that aside, it's an amazingly small amount of XSLT
considering this XSLT is the *only* code required to bring together this
dynamic page.

Monday, August 03, 2009

Three Views of REST resources

whew. Just hacked most of the day away learning how to make a custom JAX-RS provider to generate an HTML view of a resource using an XSLT transformation on the XML.

@Provider
@Produces(MediaType.TEXT_HTML)
public class UsersProvider implements MessageBodyWriter {
@Override
public void writeTo(Users users, Class type, Type genericType, Annotation[] annotations, MediaType mediaType, MultivaluedMap params, OutputStream os) throws IOException, WebApplicationException {
try {
JAXBContext jc = new JSONJAXBContext(JSONConfiguration.natural().build(), new Class[]{users.getClass()});//JAXBContext.newInstance(users.getClass());
DOMResult xml = new DOMResult();
jc.createMarshaller().marshal(users, xml);
StreamSource styleSheet = new StreamSource(getClass().getResourceAsStream("/stylesheet/Users.xsl"));
Transformer transformer = TransformerFactory.newInstance().newTransformer(styleSheet);
transformer.transform(new DOMSource(xml.getNode()), new StreamResult(os));
}catch (Exception ex) {
throw new RuntimeException(ex.getMessage(), ex);
}
}

@Override
public boolean isWriteable(Class type, Type genericType, Annotation[] annotations, MediaType mediaType) {
return (Users.class.isAssignableFrom(type) && mediaType.isCompatible(MediaType.TEXT_HTML_TYPE));
}

@Override
public long getSize(Users arg0, Class arg1, Type arg2, Annotation[] arg3, MediaType arg4) {
return -1;
}

}


In the end it's actually quite easy, but what threw me off was that JAX-RS has built-in support for the serialization of List<t> where T is a JAXB annotated class. The problem is that my custom provider, which applies a stylesheet to the XSL necessarily bypasses the built-in support for collections of JAXB annotated classes. Therefore, the method in my resource can't return a List. Instead, I created the Users (note the plural "s") wrapper class, and JAXB annoted it. Note incredibly annoyingly named accessor method, "getUser". Unfortunately, this had to be named in the singular, due to a quirk of JAXB. Naming it "getUser" produces
<users>
<user>...</user>
<user>...</user>
<!-- etc -->
</users>


versus naming the accessor method in the plural produces (note redundant plural users):
<users>
<user&sgt;...</users>
<users>...</users>
<!-- etc -->
</users>

so here is the JAXB annotated "wrapper" class for use instead of returning a raw List from the Resource method:


@XmlRootElement(name = "users")
public class Users {

private List users;

/**
* @return the users
*/
@XmlElement
public List getUser() {
return users;
}

/**
* @param users the users to set
*/
public void setUsers(List users) {
this.users = users;
}

}


then the Resource method just looks like this (note that it returns the Users wrapper class):


@GET
@Produces({MediaType.TEXT_HTML})
@Path("/users/{user}")
public Users getUsersHTML(@PathParam("user") String username) throws Exception {
Users users = new Users();
if(username.equalsIgnoreCase("*")){
users.setUsers(net.nextdb.SysAdminSearchAccounts.getUsers("%"));
}else{
users.setUsers(net.nextdb.SysAdminSearchAccounts.getUsers(username));
}
return users;
}

JAX-RS and Jersey

I spent the better part of the day messing with Jersey, an implementation of JAX-RS. I really like the built-in support for XML and JSON, as well as the JSONP support. The one thing that feels missing is some build-in support for creating lists of URIs. For example, if you have a User resource at Path .../user/JDoe, then plain old ".../user" ought naturally to return a list of URIs, one for each User. It would be nice if there was some support for that in the framework. Other than that, I really like JAX-RS and Jersey.

I'll probably wind up implementing my own providers for generating simple HTML pages and JSONP-HTML.

Tuesday, July 21, 2009

JSON, in retrospect

In May of 2006, I sent this message to a friend. It's funny that the "see for yourself" page is no longer titled "see for yourself", probably because people actually did "see for themselves" and perhaps reached a conclusion similar to the one I reached below. In hindsight, JSON is wonderful and I still consider it to have different use cases than XML. I continue to heavily use both JSON and XML in my day-to-day tasks.

From: Geoff Hendrey
Sent: Wednesday, May 24, 2006 10:31 AM
To: Brent Hamby
Subject: Json questions

Hey dude,

I went to the json "see for yourself" page: http://www.json.org/example.html to compare the Json equivalent of XML.

I copied each of the examples into notepad and wrote down the size-on disk:

json size (bytes) XML size (bytes) (json size)/(XML size)
===================================================
604 630 95%
252 221 114%
630 656 96%
3554 10708 33%
898 1150 78%

AVG (json size)/(XML size)
=====================
83.2%


Based on an average size compaction to 83.2% of the XML size. Also, if you look at the 4th example they give (line 4 of the table above), they did a Json version of web.xml. Now web.xml is a notoriously bad XML design. It basically doesn't use ANY attributes, so you get pretty nasty tag bloat. So if we drop the 4th comparison, as being kinda silly, we get an average compaction to 95.4% of the original size. Is saving 4.5% really a big advantage?

I also saw several statements on the json web page that I would put in the "wacky" bin. This may just be personal preference, but I found the XML documents much easier to read than their json equivalents. The Json looks, to me, like "code", kinda like a snippet of PERL or something.


Anyway, it seems clear that being able to easily marshal an object representation of your data makes it much easier to develop software in any programming language. But it seems to me that json is munging this idea up with the wire format, which to me are orthogonal concerns.

Saturday, June 20, 2009

JavaScript downloaded function executor

Ran into a really annoying problem trying to use the YUI text editor in a jqueryUI modal dialog. I am using jquery to load a file "richEditor.html" that has my YUI editor on it. Problems:

  1. required YUI script and link tags, that are needed by YUI, are defined on my page richEditor.html. I need to be move said tags from head to body, because jQuery.load function only loads the body of the HTML page.
  2. said script and link tags *begin* downloading from yahoo when jQuery calls your load callback function. That's becuase richEditor.html itself has been downloaded by jQuery, but the said script and link tags referenced ON richEditor.html have only just begun asynchronously downloading. So if you need to access a function in one of the script tags that is downloading, you have no way to be sure the function has completed downloading.
As a solution, I wrote this JS Object that will simply try to invoke your function, and try again, after a configurable delay, up to maxTries. If the function fails to execute maxTries times, a fail handling function, provided by you, is executed.

Here is the Object:


function DownloadedFunctionCaller(funcToInvoke, waitMS, maxTries, _failHandler){
var funcToInvoke = funcToInvoke;
var waitMS = waitMS;
var maxTries = maxTries;
var failHandler = function(){
alert("Unable to access the network. Please reload the page or try again.");
}
if(null != _failHandler){
failHandler = _failHandler;
}
var that = this;
var tries = 0;
this.invoke = function(){
try{
funcToInvoke();
}catch(err){
if(++tries >= maxTries){
failHandler();
return;
}
setTimeout(that.invoke, waitMS);
}
}
}


and here is an example of using it to invoke a function named setEditor that is defined
in an external file, richEditor.html. The setEditor function will only work if all the YUI scripts are downloaded, hence the need to use the DonwloadedFunctionCaller




var div = $("<div></div>");
div.addClass("yui-skin-sam");
div.load("richEditor.html", null, function(content){
var invokeMe = function(){
setEditor("Script loaded and executed.");
}
new DownloadedFunctionCaller(invokeMe, 500,10,function(){
alert("failed to download rich text editor")
}).invoke();
});


If you click on this screengrab, to get a bette look at it, you will see that the text "script loaded and executed" has been set into the YUI editor's text area by the successful invocation of the setEditor method.

Saturday, May 23, 2009

random lines of poetry


I woke up early this morning around 6:30 thanks to Claritin-induced sleep deprivation. I started hacking on server code for automatically building "tables of contents" for very large database tables. I'm using a bunch of Yeats poems, and The Iliad as sample rows in the database. It makes debugging a lot more fun when the data is interesting. It's also a great way to read random lines of poetry. Here is a great stanza from the Iliad:

Generations of men are like the leaves.
In winter, winds blow them down to earth,
but then, when spring season comes again,
budding wood grows more. And so with men--
one generation grows, another dies away. (Iliad 6.181-5)



Did you know the phrase "another one bites the dust" is lifted from the Iliad?

"
Grant that my sword may pierce the shirt of Hector about his heart, and that full many of his comrades may bite the dust as they fall dying round him."

Saturday, April 11, 2009

Tesla rocks...

Aside from the fawning interviewer, this is a great interview with the CEO of Tesla Motors.

http://www.techcrunch.com/2009/04/10/teslas-elon-musk-grows-a-pair-good-for-him/

It would be criminal if Tesla didn't receive the funding they need. To see a loser like GM sloshing in bailout funds is a sickening contrast.

Tuesday, March 31, 2009

Nextdb in 120 seconds

Sunday, March 22, 2009

Back in one piece...

Spent the weekend near Tahoe in Truckie. We got 1.5 ft of snow between saturday night and sunday afternoon. Nevertheless Emily and I decided to drive back as soon as I-80 opened so we could get back Sunday night and not miss Monday at work. Tire chains are a real pain in the butt. Both my chains snapped. Fortunately I was able to pull to the side of the road in a relatively safe location (meaning semis were roaring by like 4 feet from me as I crawled under the car to disentagle the chains from the half axle - getting fairly mired in much at the same time). Tire chains are required at times on I-80, but they honsestly seem like very unsafe garbage. The road is littered with broken chains. My theory is they are designed to be a deterent to drivers, more than an actual functioning safety mechanism. Anyway, chain chaos aside, we had a very relaxing weekend watching snow fall on evergreens (I was tempted to say Snow Falling On Cedars, but I refrained).

Actually, I just checked the DOT report for I-80:

"Enter Highway Number(s)
You can also call 1-800.427.7623 for current highway conditions. Mobile

Click It or Ticket

This highway information is the latest reported as of Sunday, March 22, 2009 at 21:50 .


I 80

[IN NORTHERN CALIFORNIA & THE SIERRA NEVADA]
WESTBOUND TRAFFIC IS BEING HELD AT CISCO GROVE (PLACER CO) - DUE TO AN
ACCIDENT - MOTORISTS ARE ADVISED TO USE AN ALTERNATE ROUTE

CHAINS ARE REQUIRED ON ALL VEHICLES EXCEPT 4-WHEEL-DRIVE VEHICLES WITH SNOW
TIRES ON ALL 4 WHEELS FROM 1 MI EAST OF BAXTER (PLACERCO) TO THE
DONNER LAKE INTERCHANGE (NEVADA CO) "

Wednesday, March 18, 2009

Tuesday, March 17, 2009

From Willow Tea Room, Glasgow

Monday, March 16, 2009

Photos From Scotland

In 2006 I took a trip to Scotland for an OGC meeting, and had the weekend to roam around. I visited the National Library and did a little geniological research. After a fair bit of cross-referenced parish records, pre-census, I believe I located the birth records for my great, great, great, grandfather and grandmother. Unfortunately the library closed right when I pieced it all together, but that's my next trip I guess. The microfilm will still be there!

One of the most fascinating aspects of Edinburgh and Glascow was there role in the Arts and Crafts and Art Nuveau movements. Phoebe Anna Traquair (P.A.T) was one of the female artists who figured prominently in this movement. If you ever have a chance to visit the Mansfield Traquair church, do not miss it.



You can get a better look, here: http://www.mansfieldtraquair.org.uk/nav/cag02.html

If that doesn't blow your hair back, get a look at this amazing painting by P.A.T.. Oh, wait, take a second look, it isn't a painting! It's SILK EMPROIDERY!!


It's almost incomprehensible that a few years ago, the Mansfield Traquair church was being used as a brick storage facility. Thankfully, it was recently rescued an restored. For the life of me I cannot understand why P.A.T. and John Duncan are not better known. Please read this blog to see some more breathtaking work by P.A.T.

I am so awestruck by John Duncan's St. Bride that I recently aquired a canvas reproduction of it from an obscure source on the web. Here is a shot of it gracing my living room.


Scotland has lots of badass wildcats, which came to America as stowaways, and became the big Main Coon cats.

Loch Ness... of course. On the way there we passed the spot where the Battle Of The Shirts (or lack thereof) took place. It turns out that fighting a clan battle in sweltering heat with armor is a good way to die of heat stroke. So it probably seemed like a reasonable idea is to call for a "time out" because of the heat, and take a dip in the loch. Unfortunately, it turned out to be a very bad idea to agree to fight the second half of the battle without armor because of the heat. The horrific mutual slaughter that ensued, fought with claymore broad swords and battle axes left just 12 survivors in total, and the Loch was litterally red with blood for days.
Edinburough....

Sunday, March 15, 2009

Another Gem from William Morris

For the Bed at Kelmscott

The wind's on the wold
And the night is a-cold,
And Thames runs chill
'Twixt mead and hill.
But kind and dear
Is the old house here
And my heart is warm
'Midst winter's harm.
Rest then and rest,
And think of the best
'Twixt summer and spring,
When all birds sing
In the town of the tree,
And ye in me
And scarce dare move,
Lest earth and its love
Should fade away
Ere the full of the day.
I am old and have seen
Many things that have been;
Both grief and peace
And wane and increase
No tale I tell
Of ill or well,
But this I say:
Night treadeth on day,
And for worst or best
Right good is rest.

ProPublica: Jouranlism in the public interest

I'm replacing my daily reading of the New York Times Online Edition with that of Propublica.org

Basically, none of the major news outlets can be trusted. This is just a fact. Remember before we went into Iraq how the New York Times ran breathless stories on Sadam's vast underground bunker complex. It was all just a load of shit.

So now I'm going try getting my news from ProPublica, because their mission is to reinvigorate investigative journalism.

Friday, March 13, 2009

Developers are starting to catch on!

Here is a link to a blog post written by a developer at SolutionSoft, about NextDB.


http://blog.solutionset.com/wpmu/2009/03/11/nextdb-a-front-end-database-solution/


It's a great post, and I think it illustrates how easy nextdb is to learn, and use. Nextb is getting preety close to exiting alpha and entering Beta. During the Beta we will have our "subscribe" buttons up on the site. We are targeting price points that are basically below the noise for even a personal account, so affording nextdb should not be a problem for anyone.

Brent is busy developing and refining a new set of utilities for adding forms to your AJAX apps. The forms will automatically configure themselves based on the content of your table or query, and will be CSS friendly.

I'm working on a notification system that will allow you to receive email when data is inserted into a table. You'll be able to request digests, as well as create email templates that receive data from the inserted row in order to create a personalized, pretty email.

Sunday, January 25, 2009

ulimit -n .... the saga continues

Man, I thought I had put the "ulimit -n issue" to bed once and for all with these configurations in CentOS. So, it was with great chagrin that I recently executed a "ulimit -n" and saw 1024.

Argghhh. Will this issue never end?

I've added "ulimit -n 100000" to my .bash_profile, and now I have confirmed that after logging into a new session, that the new ulimit of 100000 files is in effect.

I'm not happy with putting this in my .bash_profile, but the alternatives looked too dangerous and or flakey.