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:

• #11868: defect: CouchDBRestStore Delete Not Working (409)


• #11838: defect: CouchDBRestStore adding invalid item attributes after save

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.

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.

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.

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).

RIAs powered by Dojo and javascript?

Recently I was thrown into a situation where I had to learn Dojo and javascript quickly to produce a prototype. Being fairly skilled at picking up new technologies and languages I figured how bad could it be. I was wrong! The switch from typed languages to javascript is HARD. What a terrible overall experience. I can't see how the untyped language is a good thing - so far it just lets me be lazy and not create class definitions or hard contracts (have those things really been slowing us down in the typed world?) and lets me just create functions all over the place with no clear "context" for their use. Dojo has some nice features, but it is never clear where Dojo/Dijit ends and plain javascript/Dom stuff begins. And to top it all off you need to learn at least 4 pieces of technology - javascript/dhtml, Dojo, Dijit, and css in order to be productive. This same prototype in Flex would have probably taken me just over a day to put together - instead it took me 5 days to throw some grids up on a page, populate them with data, get the layouts correct and then based upon the selection, interact with a separate flex component.

Dojo/javascript has horrible documentation and lack of good IDE support (please - don't start on Aptana or RAD - they are decent, but nowhere near as easy or helpful as Eclipse JDT, VS w/ Re#, FlexBuilder). Trying to find what the properties and methods to call on various Dojo objects was painful - the Dojo online Docs are hard to navigate - I finally resorted to grabbing the development code so I could just step through and read the comments. That should really be positioned as the primary way to figure out what's going on. Then once I found what to call, figuring out if I called it correctly was also a chore. For instance, if some function took an object that expected certain attributes, making sure I properly created it and added the correct attributes to it was mostly trial and error. Thank God for Firebug.

Now with all that bashing aside, I completely agree with the "if it looks like a webpage and talks like a webpage, then it should be a webpage" argument. Meaning, if you want your webapp to look like a web page and you have links, etc, then you should stick with the "legacy" web technologies of html/js/css, otherwise the UX suffers. When users see what look like hyperlinks they want to be able to click on them and open in new tabs, etc. They also expect that all of the other browser features, like search and bookmarks, work with their pages. That's one of the problems with Flex and Silverlight. Sometimes these types of RIAs look like what could be plain-old webpages, but as soon as you right click a link and try to open it elsewhere, or you try to bookmark something, or search for some piece of text you realize that you cannot and that can be frustrating to the user. Similarly, I think Flex/Silverlight apps that have an MDI like interface need to be careful as well. That approach basically reimplements the same functionality as browser tabs. In most cases I'd prefer to open up each doc as a separate browser tab rather than the app putting in its own top-level tab. I think moving forward it would be nice for those technologies to play a little nicer in the browser.

Hopefully I get over the the learning curve for js/Dojo soon. Most of my development in the foreseeable future will likely be using these technologies so to some extent I just need to get over it and embrace the untyped javascript world. I hope to see the light soon.

Initial Maven v Ant observations

Let me start off by saying that I am by no means an expert in Maven, so these are my initial thoughts. Also, this is on Maven 1.x - we have some plugins that we are using that we can't use on 2.x.

So far I prefer Ant over Maven. With Maven, many things are "hidden" for you. In order to figure out what is going on you have to rely on documentation, which isn't always the best. With Ant, yes, you need to explicitly build up your targets with filesets, etc, but at least by glancing at the build targets you can tell what is going on. With Maven, it is like magic that things work - you don't necessarily know why; the reverse is also true - when things fails you also don't know why. With that said though, I have come across highly structured, templated Ant build scripts/frameworks where you have the same issue of not knowing what to call or why something fails, since many of the details have been abstracted into some main build.xml.

One argument for Maven over Ant is that if you add new projects, files, jars and if you follow the Maven conventions you don't have to update your build files. Yes that may be true, but is all of the black-magic really worth it. It doesn't really take much time at all to update your Ant files and again, you are explicitly in control and can see what is going on. The other Maven argument is dependency management. To me, unless what you are building is absolutely huge, this is entirely manageable in Ant. Worst case is that your CI build breaks because some dependency wasn't updated in your build.xml and someone has to take a few minutes to fix it. In both cases, ongoing build maintanence is required anyway - there is no build solution out there that doesn't require refactoring over time.

I guess what it all comes down to (with frameworks in general) is that there is no silver bullet. You just end up with a different set of problems. At least with Ant it is more obvious what is going on.