Wednesday, October 20, 2010

Not ready for primetime

Not getting a good feeling with this stuff. It just still feels really, really unpolished and not ready for prime-time. Here's the latest issues I've run in to:


The gist is the on an item update, the CouchDBRestStore is applying the return to the item, which means we end up with an extra id, ok, and rev fields. I've patched around that myself, but the other one stinks. For the other one, you can't delete an item using the store at all. It isn't passing along the doc rev with the DELETE call.

I know I can work around both of these, but yet another case of basic, rudimentary functionality that just doesn't work. Yes, I realize that I am using stuff from dojox. The reality is that most people are using stuff in there (e.g. grids especially) so I'm thinking that the dojox submission process needs to be much more rigorous.

Tuesday, October 19, 2010

Really?


var selItem;
if (items.length == 0) {
selItem.type = "player";
}


So I realize that this was a coding error on my part, but the fact you get nothing, not even a Firebug console message really, really sucks. selItem.type = "player" throws but I guess Dojo is eating an exception somewhere.

Monday, October 18, 2010

Dojo Woes

So far things are going slowly. Lot's of layout issues. I would have had the UI skeleton done in a couple of hours in Flex or Silverlight. My issues aren't really with javascript itself, but more with Dojo. There's some things you need to do (like call startup) or not do (like create grids hidden); and if you don't, you're going to spend hours trying to troubleshoot why you can't get something to layout properly. And then that's where you start sprinkling in startup() and setTimeout(resize, 0) everywhere until something works. It is stuff like this that makes me pull my hair out. So far these are the specific problems I've hit:

"In order to set the overall size of a BorderContainer to the full size of the viewport, the element needs an explicit size set as well as a size on the BorderContainer itself. Otherwise, the computed style of the BorderContainer will report 0 rather than the browser-calculated size of the viewport."
"You can use a BorderContainer inside your own dijit template with a bit of care to call startup() on your dijit after it has been added to the DOM, so that its contained BorderContainer can lay itself out."
"It is not possible to create a grid as a child of a node which is set to be not displayed (display: none). If you need to do this though for some reason you can set the grids visibility to "hidden" and its position offscreen"

Yeah, I know, RTFM, but this is exactly the type of learning curve I am trying to avoid. The fact you get no indication that you violated some rule or just did something that's not supported sucks. Sure you have the same problem in other languages, but seems to be much worse in the js world.

Friday, October 15, 2010

Newbie CouchApp developer

So this month's pet project is to re-do a website that I wrote in ASP.Net on a beta version of .NET probably back around 2001/2002 or so. The website is for managing my company's (at the time) golf league. It was an opportunity to learn .NET even though we were so far removed from using it at the time. Anyway, this time I'm going to do it using CouchDB and Dojo. My goal is to add one new feature, or work through one bug, per day. On some days that'll mean just getting the Dojo grid to size properly, on other days it may mean implementing a validation function -- small steps since I probably don't have more than an hour or so per day to work on this.

So far I have CouchDB setup locally and I also have couchapps installed to make pushing changes to the database easier. For those who don't know, Couch is the DB as well as the web server, so in order for XHR calls to work, your pages needs to be served from the DB as well. Kind of quirky, but I'm ok with it. Oh, and since your pages are in the DB, you get Couch's replication and versioning for free. Sort of like a poor man's source control system. In any case, it is kind of a pain to quickly make javascript changes and continuously have to push them into the database. Fiddler to the rescue!

Open the FiddlerScript tab and in OnBeforeResponse add this:
var tUrl: String = oSession.fullUrl;
var sString: String = "http://127.0.0.1:5984/myapp/_design/test/";
if (tUrl.StartsWith(sString) == true) {
tUrl = tUrl.Substring(41); //probably should just to a .length
oSession["x-replywithfile"] ="C:/cygwin/home/userName/couchapps/test/_attachments/" + tUrl;
}

You'll need to change paths in there, but I think you get the idea. This sniffs for requests to my app pages in the database and redirects the request to my local filesystem. So now I can modify the file, save it, reload the page and see my changes instantly. Please note that this will not work if trying to load Dojo, since dojo will attempt to load some resource files that do not exist and you'll get errors. What I did to work around that was NOT push dojo up to the DB. I'll do that once I'm further along. Instead I put dojo in c:/{folder where couch is installed}/share/couchdb/www/script/. In your html, load dojo from here:
src="/_utils/script/dojo-release-1.5.0-src/dojo/dojo.js"

As you can see I also use the source/sdk distro when developing. Makes finding errors much easier, although loads much slower.

Bringing the hobbyist back?

Over the years I have shelved dozens of personal programming projects. They were either too ambitious or I would have had to learn too many new techs at a time to actually bang out my idea. Without getting into too many details or flame wars, I've come to understand it is primarily the result of the complexity of J2EE stacks. They really aren't friendly to the computing hobbyist - generally speaking the barrier to entry is too high in terms of time and complexity. That's why I am excited about some of the new technologies that are being touted today. No, I don't believe they are a silver bullet or anything like that, but they have lowered the barrier of entry to the point where you don't have to spend a lot of time configuring or troubleshooting your infrastructure and instead you can focus on your idea. Specifically I am talking about techs like CouchDB. I'm not coming at this from the angle that NoSQL dbs are good or not - forget about that. As a hobbyist, or even a small startup, I don't really care if I can scale, or need high-availability, etc, etc. I just want to work on my pet project of the day. It has brought back the feel and simplicitly of developing for a 2-tier stack. You don't have to worry about OR/M, or whether or not your struts actions and servlets are configured correctly. You don't have to worry about what JVM you're running. You don't have to worry about your JDBC connections. So and and so on. With something like Couch, there really is no middle tier (or 3rd tier, whatever). It is just you in your browser making XHR calls to your database. That's it. Done. Only 2 points to troubleshoot - your javascript code or the data you stuffed in your DB is wrong. And no, I am not a javascript fanboy, far from it. See one of my previous (now dated) posts on the subject. I have been working with Javascript, specifically Dojo on and off for just over a year. I still choke on it everyday, but I'm willing to overlook the crappy IDE's, quirks, etc, etc and give this "new" approach to development a shot. Seems to me right now, that there are some cool innovations coming out in the js space. For whatever reason, the folks in the js and NoSQL worlds seem to be the only ones embracing simplicity and at least trying to innovate in ways the java world is not (yes, I know blanket statement). JAX-RS/Apache Wink in the java world is a start, but at this point they are a step behind wrt simplifying things. Similarly, even though apparently the Spring frameworks attempt to make things simpler, there is still a big stack there and all the learning that comes with it (tried it on a previous pet proj so not an expert, but exactly the type of learning you don't have with Couch and js).