Posted by Lena Mon, 15 Feb 2010 16:17:00 GMT

How to refactor a long chunk of asynchronous code is one thing I learned during my Javascript & CouchDB project. It's not a difficult thing, but I thought it was before I figured out how to do it, so I guess it might be interesting for Javascript newbies.

Asynchronous code

In the first couple of weeks I struggled with this new style of coding before I got the hang of it. If you're fairly new to Javascript, you're probably used to just assign a variable in one line and use it in the next line. In the asynchronous world you query for a value and do stuff with it in the callback function of the query.

To illustrate - "normal" code looks like this:

1 comment |

Posted by Lena Sun, 31 Jan 2010 21:22:00 GMT

All green!

One major pain at testing with culerity so far was a HtmlUnit bug that causes a ScriptException with PUT AJAX requests in jQuery. When you tried to test an update you got a "java.lang.IllegalArgumentException: The content cannot be null". Fortunately, this bug is fixed now. With latest HtmlUnit build culerity should run fine, and I tell you how.

I assume you have culerity installed already. If not, follow these instructions for testing Rails apps or these for testing Couchapps.

no comments |

Posted by Lena Mon, 04 Jan 2010 12:07:00 GMT

Selecting a unit test framework for a JavaScript-only application - not a task with an obvious answer! Coming from the Rails world, where most people work with either TestUnit or RSpec, I was a bit lost when I started researching. This table on wikipedia was quite helpful for a first overview. But: JsUnit, JSTest, jsUnitTest, jsUnity - these are actually different frameworks, and there's even many more ...

I narrowed the selection down to those being currently developed, or are in use in "big" projects. JsUnit seems to be one of the major players, but I found almost no documentation, and the code base hasn't changed a lot in the last years. That's not a negative thing in itself, but having an active community around is a good thing. QUnit is used for testing JQuery, it looked like you could work with it as well, but its syntax and setup didn't make me go "wow" exactly. Same goes for JQUnit, about which I had read good stuff in several blog posts. It's also what Sammy.js is tested with.

I like RSpec, so when I had my first look at ScrewUnit, I was delighted to find there's BDD syntax for JavaScript too ...

2 comments |

Posted by Lena Tue, 22 Dec 2009 17:37:00 GMT

For the couchapp I'm writing, I recently wanted to do a bulk delete operation with CouchDB, but found very little about it on the web. I don't know if my approach is the best way to go, but well, it works - if you know a better way, I'm happy to learn about it.

In CouchDB, there are a couple of convenience methods in jquery.couch.js to help you dealing with the database, documents and views. There is a method for deletion too (removeDoc), but it only can handle one document at a time. In the style of bulkSave, I added a bulkRemove method:

2 comments |

Posted by Lena Sun, 22 Nov 2009 20:43:00 GMT

The application I'm writing depends heavily on key events. When you press enter in a specific text field, some other field opens, when you press tab, the text fields moves, etc. Of course I need to cover this in my cucumber integration tests. The Celerity API is a bit thin for this purpose: You can fire a, let's say, keydown event - but it doesn't pass through the specific key code.

Actually it's easy when you know how. You can execute any javascript directly on the Culerity RemoteBrowserProxy object. In order to fire a specific key event, you have to create a KeyboardEvent, initialize it with whatever you want, and dispatch it on the element.

no comments |

Posted by Lena Wed, 04 Nov 2009 10:07:00 GMT

Do you know what's behind these buzzwords: CouchDB / Couchapp / Sammy.js? Not really? Then please look at this article now: Sammy.js, CouchDB, and the new web architecture. The title says it all.

This setup happens to be the field of my diploma thesis, friendly sponsored and supported by Upstream. During the next months I'll develop a super duper thing with these technologies, and then I'll write 80 scientific pages about it. Yees, I'm not that much looking forward to the second part! Until then, I'm planning to semi-regularly blog about my findings.

I'm not allowed to share the code before I have the diploma in my hands. But, because my workmate Frank Proessdorf is so jealous of what I do, he and I started working on an app with a similar setup on our Upstream Research Fridays, to try things out. Here it is. Don't expect anything yet.

Today I'm going to tell you about some details of my testing setup.

no comments |

Posted by Lena Tue, 27 Oct 2009 22:27:00 GMT

Comatose is a micro CMS, easy to embed in your Rails app, ideal when the customer wants to update her FAQ once in a while. I work on a few projects where comatose is integrated, and it's been the second time now that one specific problem has given headaches to me and my colleagues. Time to document the solution.

Comatose has a hierarchical structure. All the pages are children of the comatose root page, which is usually not in use. This root page is created by the migration AddComatoseSupport. When we add comatose to a project, we usually create another migration, where some child pages are created and populated (because the customer usually already knows what pages she wants). This can look like this:

no comments |

Posted by Lena Sun, 25 Oct 2009 21:53:00 GMT

In every project I use cucumber (that means, always) there are a few things that I keep reinventing, or I spend a lot of time searching for them in other projects. Here are some of them. They aren't all written by me, but maybe my coworkers like to use this as a reference, too?

When you upgrade to the current cucumber (0.4.2) from an older version some steps will fail, because cucumber doesn't examine the whole html anymore. You can still check the raw html with these steps:

no comments |

Posted by Lena Sat, 24 Oct 2009 21:12:00 GMT

Doing client work for Upstream, I recently had the pleasure of pair programming with fabulous Pat Allan for a month. Here are a few of the things I learned.

  1. Pair Programming is a good thing (not that I haven't known that before). Here is yet another good article about pairing if you aren't convinced yet. Next to improved concentration, keeping each other from getting stuck in stuff, I like the sharing of best practices, Textmate short cuts, syntax tricks etc.
  2. Instead of writing "puts" in, after and before blocks that don't act as expected, use ruby-debug. It's really easy, and gives you so much more information about your situation. Just do:

no comments |