RockyCode

Unit testing is a required part of a healthy software development lifecycle and a balanced breakfast. But test-driven development is a rockin' part of an *awesome* development lifecycle. What's the difference? If you don't test-drive the dev of your MarkLogic XQuery, you may never come back to test again. Test-driven XQuery development will ease your headaches, put you into the plush seat of a developer with confidence, and rocket you down the road to making all your wildest dreams come true. Kachow!

I've seen a number of different ways that internationalized strings get put into Javascript code. Of all of them, I kind of like just bundling the resource bundle of key value pairs in Javascript files themselves, one for each language or something close to that. But, in a recent project, there were a few other constraints, so we did it another way.

If you've created an internationalized website lately, you've probably implemented some sort of language chooser widget in your site ui to allow your users to indicate which language they would like to see content displayed in. What I often forget is that the user may have already made this indication previous to visiting your site, and you might be like to think about respecting their previously indicated preference.

Unit testing is a required part of a healthy software development lifecycle. Business logic in MarkLogic Xquery needs the same insurance of superb testing as any other language.

Principles: Come learn the motivation for unit testing and how test-driven development can increase your productivity writing solid Xquery code in an Agile-coding environment.

Skills: We'll code Xquery examples to learn general skills including the TDD workflow, how to isolate your code for unit testability, and how to test one thing at a time. In each case, we'll address how to apply these skills specifically to development in the MarkLogic ...

In order to improve performance and scalability, sometimes it makes sense to turn html (embedded with some tag library or Xquery code) into real XQuery code. It can then be put in the Modules database making it immediately available for use. This is just like what Java Server Pages does!

Transactions in MarkLogic can sometimes be challenging to work with due to restrictions such as inter-transaction visibility, transaction control, single update limitations, and non-transactional file system updates. Isolating code that updates portions of documents that may be called multiple times during a transaction can be complicated. Check out a simple transaction helper framework that addresses these difficulties.

The demo is a link to a presentation given at the 2011 MarkLogic Conference in San Francisco.

Beyond standard query optimization in MarkLogic, scalability and performance can often be dramatically improved by using strategies or patterns that avoiding making database queries.

The demo is the presentation given at the 2011 MarkLogic Conference.

Have you ever needed to know the location of the actual file that houses the code that's currently executing? Well, if you have then you're not alone. I have been there myself. The answer might not be as interesting as some of life's deeper mysteries unveiled, but I was excited about it nonetheless.

This information seems especially useful in cases where an absolute path to the code is required but you want to avoid hard-coding context information into your app. Your app really shouldn't care where it is deployed to afterall. My love for Django increased ...

How do you log into a MarkLogic application to run as a user besides the default app server user? Use xdmp:login(), baby! User/role management can be awesome -- when it's done and coded. For now, let's sing out a few important things to remember about xdmp:login() and all its hidden secrets.

When a person looks at an Xquery module import, ... um, sorry... he usually gets distracted by something else before he can get to the semicolon at the end of the statement. They're seriously long! Few are the files in which one-line imports adhere to an 80 character width limit. Read on for my other Martin Luther-spirited grievances.

Sometimes you want to ensure that your xml document matches a given schema (xsd). Xquery on MarkLogic gives you a few tools to do this. If you want to validate your xml against an xsd, read on fair reader.

Recently, we've been working on writing an API using xquery. We have wanted to make the API as solid as possible, since we're putting the brunt of the complexity of our system into this module of code. What might typing our parameters and return types give us? We are hoping for safety and readability.

How to examine external variables without risking an error.

My first xquery experience has been on the MarkLogic platform. The project that we just released was written entirely in xquery and on that platform. As our site continues to gains popularity, we continue to realize how little about xquery we knew or know. Sometimes and in some places, the site is just really not that performant. "But I thought MarkLogic/xquery is super-scalable," some exclaim indignantly. If you do it right, an Oracle relational database can be made to scale. Done wrong, a MarkLogic database can be made to not scale at all. There's a lot to be ...

I've been fooling around with a thumbnail gallery that pulls up either an associated video or image. Here is how I got the workings to work.

Have you ever had a problem with ajax requests caching in Internet Explorer. I have, and recently I came across a nicer solution than I have traditionally used. In the past, I have used a unique parameter on the url to keep IE from caching previous requests to the same url, like so: