I started programming on the MarkLogic platform in 2010. It was a very new experience for me. I don’t program in it these days, but I still think back on the experiences I had with MarkLogic and in general believe that they made me a better programmer. Here’s how.
When ordering a sequence of items in XQuery, sometimes it’s desirable to be able to decide the order based on a parameter value (something dynamic). XQuery doesn’t look extremely elegant when it comes to this feature, but depending on exactly what you want, you should be able to get the job done.
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!
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 environment.
Tools: We’ll also introduce you to in-house-developed tooling for creating unit tests and running them. This tooling provides an all-Xquery method of creating test functions, annotating them as such so they’re runnable in the test runner, isolating certain modules to test, and viewing clear test results.
With a few principles, skills, and tools for unit testing, you can go forward with increased confidence that the Xquery code you write on MarkLogic is more awesome than ever.
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 when I discovered os.path.dirname(file). Here’s an equivalent goody in MarkLogic.
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.