DirXML Script excellence in elegance contest:
Novell Identity Manager has several languages available to use.
There is the original XML Style sheet Transform language (XSLT) which is still there, and I prefer to avoid using, for a variety of reason. It has its place, but there are better options most of the time now.
There is DirXML Script which was introduced around NSure Identity Manager 2.0 timeframe and keeps getting better with each new release. Each release adds new tokens and features that make the language more powerful.
Within both XSLT and DirXML Script there is the XML Path language (XPATH) that can be used to do a variety of tasks.
Having worked extensively with all these options for several years now, I decided it would be really interesting to share some really elegant examples of things you can do in DirXML Script and XPATH that simplify things.
However, as we all know, getting people to contribute is always hard, when it is totally for free, so to get people motivated and interested in participating, let's have a contest with prizes as well!
The awesome folks at Cool Solutions (Thanks Susans! Both of you!) have volunteered to pony up a prize of Cool Solutions points. These are useful, as they can be used to earn rewards in the form of gifts from the catalog, or in the form of gift certificates to Amazon, iTunes, Think Geek, or others. Check out the Rewards page and see what is available for yourself! On a side note, the Amazon gift certificates CAN be used overseas, at the other Amazon national stores, just converted from US currency.
Additionally, if you keep earning points, there is a scoreboard for the top ten point earners, on the top Cool Solutions page to see how you stand in the rankings. The over all rankings are available as well at: http://www.novell.com/communities/userpoints/list/all (Yes, I happen to be doing pretty well on that list).
It may seem daunting to get into the top ten, but here is a great way to start. First of all, enter the contest, and if you win, we will award 1000 points to first place, 750 to second place, and 500 to third place. Then you can write up your solution with commentary to submit it as a standalone article and earn more points that way. I think the article with commentary is actually the most important part, as this is where you get to explain WHY this is an elegant solution, and what it accomplishes. You get to win and win again! Even if you do not win you can submit your article for points. If you would like help editing it into an article, let me know once you have it written, and I will see what I can do to help you out.
There was some talk of having a prize for absolutely worst idea ever, so let's see if a really bad stinker comes up, and if it is really memorable we can get see about getting some prizes for that one too!
Heck, if you manage to get up into the top 20 or so, that is a useful thing to put on your resume if applying for a job in this space. After all, what better way to show a prospective employer that you know your stuff, than to note you are say #3 in Cool Solutions points (Hey there Aaron!) and they can look at the articles you have written and judge for themselves! I know I used it when I was in 6th place and applied for my current job, and it made a difference with my employer. Ignore any silly employer who says that is free help to potential clients... Nonsense. It just shows your level of expertise.
We are only interested in DirXML Script, but XPATH is of course allowed, if you use it in an XPATH token. Let's stay away from ECMA Script calls via DirXML Script as that opens an entirely other can of worms that is probably another contest in and of itself (though you can see nice ECMA samples at: Open Call for useful ECMA functions to use in Identity Manager.) We do need some kind of boundaries to keep this scorable.
We want to see examples of DirXML Script that is useful in the real world, does something useful, and is elegant. How do we define elegant? Well let's talk about scoring.
Fixing a typo, low score.
Fixing every driver, in a really useful way, that Novell should really include in all default drivers from now on, let's call that a 10.
Does it 7 pages of code: Low score.
Does it one line of XPATH: High score. (Do note that one line is basically the most extreme example, there is nothing wrong with using several tokens to accomplish the task)
Same performance as a brute force approach: Low score
Show an example of a brute force approach that takes 3 minutes, and the example takes 100 ms, let's call that a 10.
Hey we can mark this on a log scale of a bad brute force vs elegant solution, in terms of absolute time, out of ten. Hehe. That would be funny!
Please email your entry to the contest account directly, firstname.lastname@example.org where I will track the entries, and distribute to the judges. We will give this a few weeks to run, let's say till January 1st, 2010, then post our decisions on the winners, with scoring. You can include it as a file, or within the message body, just verify that the XML code makes it through the email.
Please include your code sample, either in an entire rule, or just the snippet itself, if it can be used standalone. Explain the problem you are trying to solve, and why your solution is an elegant one.
Please include contact info you would like published about yourself, if you should win or even when we just post the sample code. If you do not, I will just link to your Cool Solutions account, if I can find one. (If not, please tell me what it is).
If you have Dstrace output showing the time it takes to run, on a reasonable data set, please include that as well, annotated with comments. Obviously, if you wanted to cheat, you could trivially do this here, but do recall, the judges are all pros and if you think editing trace to get make it look fast will get past us, consider that again. That and we have test labs to try it out in.
There is an entire other category for another contest that might be examples of optimizing the default driver config that Novell ships with Identity Manager and Designer. An example of that are these two articles I wrote in the Identity Manager 3.0 timeframe:
In the Identity Manager 3.5 and 3.6 builds many of the ideas were incorporated into the shipping Active Directory drivers. (Now I happen to think it was because they were obvious, and simple to do, not because of the articles but I can dream. Well actually I know why, it was part of the Resource Kit effort, which attempted to generalize and simplify the drivers where possible and these were just some really easy changes to add in).
Let's see how this contest goes, and we can consider running a second one for that entire category of entries. I think those are quite worthwhile, but probably out of scope for this contest.
Since I cannot compete being a judge, allow me to enter an example that I think ought to score well and explain! To be fair, I basically got most of this code from Father Ramon. Allow me to explain what it does, and why it ought to score well. Feel free to explain why you think your example should score well. in your submission, based on our scoring criteria.
In my example, I was querying an eDirectory tree for all ACL's (Access Control Lists) of all users, trying to ferret out users with elevated privileges. The thing is, due to the way eDirectory grants rights, prior to eDirectory 8.8, and the [This] pseudo attribute, every object has a bunch of extra attributes, and I wanted to clean them out of the node set of values, before starting to process them.
In other words, with DirXML Scripts Query token, and even using the srcCommandProcessor Java class (Of course, the Query token in mostly a pretty wrapper around the Java class) you cannot query for only users who have attributes with values, so you cannot filter at query time, like you could in an LDAP query. In LDAP you could use a filter of (manager=*) to return all objects with manager attribute populated, and (!(manager=*)) to return all those without a manager attribute populated.
The number of ACLs in a typical real life tree will surprise you, and if you need to work through all of them, well heck, that can take a long time. If there was a fast way to clean it up in advance, that would be a huge help.
<do-strip-xpath expression="$ACLS//value[(component[@name = 'protectedName'] = '\[Public]')]"/>
I have a node set attribute ACLS that is the result of a Query tokens output for the ACL attribute of all objects in the tree. As you can imagine, that's a big memory load, and took some time to generate. This command removes all grants of public. This does require you to understand what your results look like, what you are interested in seeing, and what is not helpful at all, to know what to strip out.
Thus, this should score nicely in the magnitude of its impact, not a 10, but reasonably high, since it enables you to filter node sets, especially for structure attribute ones, like ACL. When working on large node sets, this can be invaluable to clean up before starting the real work, where the time wasted on discarding uninteresting values can be quite noticeable.
You can use this almost anywhere you find the need to handle large enough node sets with redundant or useless data that you want to strip out. For example if you wanted to get all DirXML-Associations of all objects in the tree, but really only wanted for a specific driver. You could query for Users in the tree, returning the attribute DirXML-Associations, and then use the line:
<do-strip-xpath expression="$DIR-ASSOC//value[not(component[@name = 'volume'] = "~dirxml.auto.driverdn~")]"/>
This would remove from the node set all DirXML-Associations where the associated driver, is NOT this current driver. You can see how much easier that would make processing the node set.
On the simplicity scale, this is hard to beat at one line. Additionally it is easily extensible to other attributes and types, just by changing the input node set (the contents of the ACLS variable) and what you are trying to filter out.
Performance is where this one rules the day. In the real world, on real hardware, on a tree with ten thousand objects, this was executing in millisecond time frames. About 150 milliseconds as I recall.
Prior to doing it this way, I had a for-each loop, and copied only the attributes I wanted from one node set to the other, and for the very large node set (ten thousand objects with at least 5 ACL's each object), it took well over 5 minutes to run. That's a pretty darn good optimization! (On my log scale that is what a 2000 fold improvement, hmm, Log (2000) is only 3.3 ok, so maybe not the log scale then but you get the idea) Now that is also a pretty terrible brute force approach, so the comparison may not be the best.
This is also a nice example of how powerful simple XPATH constructs can be in the real world. Strip by XPATH is amazingly powerful when used with care.
However this loses points because basically it just does a Strip By Xpath expression, with a useful XPATH expression, but is delivered functionality. There is nothing sublime or magical about this, it is doing what Strip By Xpath is supposed to do. However, the exact implementation, when seen with the performance boost it gets can be quite effective. Or in other words, you would not expect it to be so nice and fast from just reading about it in the documentation.
Let's see what the community can come up with. People occasionally send me Designer screen shots of their projects, which usually are pretty darn cool to look at. So I know there are people out there doing amazing and crazy things in Identity Manager, let's see what you are willing to share.
We will post the winners, and probably most of the submissions, because heck, sample code is great and a big win for everybody! There is not enough sample DirXML Script out there, so let's fix that problem right now!