I'm currently writing my thesis, using LaTeX. As the programming part of my thesis was mostly done in Javascript, I have to include some bits of Javascript source code in the LaTeX document. For this I'm using the listings package. With this package you can "include the source code of any programming language within your document". Unfortunately Javascript is not in the list of supported programming languages. (In return, the list contains languages like Oberon-2, Promela or RSL, which are probably being used way more often than Javascript ... er.)
Luckily @awendt pointed me to these links: Javascript Quelltexte in LaTeX and a thread on a mailinglist. I changed those examples only a bit, I'm posting my result here mainly in the hope it will produce a Google hit for "javascript latex source code" :-)
I recently wrote a testsuite for CouchDB's Javascript HTTP API. Among the things I tested were the security methods. That's those that deal with authentication - like signup, login, logout and so on. The challenge was to make sure my tests wouldn't interfere with the CouchDB setup of the person running the tests.
Background
CouchDB stores the information about the database users in a special database, the authentication_db. The default authentication_db is called "_users". So this is where your user data is saved when you sign up without taking care about the details, e.g. when you use the signup method provided by the JQuery HTTP API. Read more about the ways to interact with the authentication_db in the HTTP API documentation (JQuery methods), and read more about general CouchDB security in the CouchDB Wiki or in The Definitive Guide.
How to set the authentication_db
When you e.g. create database users from within your tests, how can you make sure they don't mess up the actual authentication_db, the one the unsuspecting user might use in production?
Last thursday I gave a talk at the monthly meeting of the Berlin JS Usergroup. I was talking about JSpec, a Javascript Unit Testing framework. Thanks to all who were there to listen and ask questions!
Here are the slides. When you have a look at them, make sure to also read the notes (next to the comments), so the slides make sense to you.
To find more information about JSpec, check out the README on github, or read the blog post I wrote about it recently.
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:
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 ...
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:
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.
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.