AD Authentication with SVN

Frequently with SVN, you would want to integrate with Active Directory to enable users to use their Windows Login and Password with SVN. Here is how you do it:

The Apache module to use in this case is the mod_auth_sspi. Once you have enabled that, set the SSPI configuration section in subversion.conf. the SSPIDomain should be set to the name of the domain you want to authenticate with.

When a user logs into SVN, the user ID they type into the SVN Authentication prompt is the Windows Account (without the domain) and the password is the domain password.

This may not be enough for you if you are using bugzilla integration with SVN using SCMBug. Bugzilla has an integration with AD (which I personally have not used) with enough documentation around it. If you use it, then just change the SCMBug configuration file to pass through the user id from SVN to Bugzilla. I think that should work, but if you find some tweaking is necessary in SCMBug, just post it back in the comments section for this post. I will definitely appreciate it in my next gig!

Interesting case for var -> val conversion in Scala

While Scala supports imperative as well as functional style of programming, it recommends programming in the latter. One of the challenges I faced was getting rid of a counter in the following BFS (Breadth First) style recursion (mutable to immutable variable conversion). I wont go into specifics but rather look at the pattern to be used here:

def BFSCounter(money: Int, coins: List[Int]): Int = {
    var n = 0
    // termination checks
    for (// loop dependent on input parameters
        n += BFSCounter( ...)
    n
}

The above code launches multiple recursions in each call of BFSCounter and the variable n which maintains the count must be incremented and returned. 

The strategy to get rid of the mutable variable is to pass the counter from one call of BFSCounter to another.  To do that we must also make the calls to BFSCounter a constant (independent of variables or input parameters). This means understanding the traversal pattern, termination checks etc. The final code looks like the following:

def BFSCounter2(money: Int, coins: List[Int]): Int = {
    // termination checks
    val count1 = BFSCounter2(...0..)

    BFSCounter2(count1)
}

Note that you may be able to reduce the code to just one call to BFSCounter2 or maybe you will need three calls. The point is that the number of calls should be finite and the counter is passed into the BFSCounter2 and passed back out as return value. The last call's return value is the final return value of the function.

Scala: Parameter-less functions

Scala has a few tripping points for newbies and one of them is parameter-less functions which look just like variable names or field names. I came across a very interesting example when researching the difference between def and val in Scala:

Scala has three ways to define a variable, method name or object:

• def defines a method
• val defines a fixed value (which cannot be modified - these are like Java final variables)
• var defines a variable (which can be modified later). These are discouraged in Scala since they are mutable and are indicative that the program is using an imperative style of programming.

Consider the following example which may fool you (from this question on stackoverflow):

class Person(val name:String,var age:Int )

def person =new Person("Kumar",12) 

person.age=20 

println(person.age)

These lines of code give output as 12. ALWAYS. The reason is that "def person" creates a function definition instead of an object. Thus each time you write person in the code, it refers to a brand new Person object created by the person method. This happens in the assignment as well as the println code!

Another example from the "Programming in Scala, 2nd Edition" - If a function literal

consists of one statement that takes a single argument, you need not explicitly

name and specify the argument. Thus, the following code works and println looks like the name of variable in this case:

args.foreach(println)

Scala: Call by Name

Functional languages typically implement the call by name evaluation strategy natively. There are some special use cases where such an evaluation strategy may boost performance and one of the examples was given here.

The case  in consideration is how log statements within code can be made more efficient while being clean. Typically log level determines if the log statement actually does something in the code. 

For example, lets say you wanted to put the following log statement in the code:

logger.info("ok" + "to" + "concatenate" + "string" + "to" + "log" +"message")

If the check for the log level is done inside the log method, then by the time the check is done, the string concatenation would already have been performed. That would lead to bad performance. So the solution would be to wrap the code above with a check on the log level:

if (logger.isEnabledFor(Logger.INFO)) {
    // Ok to log now.
    logger.info("ok" + "to" + "concatenate" + "string" + "to" + "log" +"message");
}

In a language like Scala, this would be achieved by using a call by name argument to the logger method. The call by name argument is evaluated (pretty much like a parameter-less function call) only when needed. It is different from a lazy evaluation in that it is evaluated each time it is needed (call it lazy with no memory!).

Here is the code quoted from the above article:

def log(level: Level, message: => String) = if (logger.level.intValue >= level.intValue) logger.log(level, msg)

Another excellent example can be seen here.

Design Pattern Reference

Here are some of the best articles on design patterns on the internet. Once you review the examples and discussions, its best to do some comparisons next.

1. Facade.
2. Flyweight
3. Adapter
4. Chain of Responsibility
5. Singleton
6. Observer
7. Composite
8. Command
9. Strategy
10. Proxy.
11. Decorator
12. Broker
13. Builder
14. Dependency Injection
15. State
16. Bridge
17. Interface
18. Prototype

Interesting comparisons to do:

Facade, Adapter: Facade works on an entire subsystem (multiple classes) to make suability simpler and Adapter generally does not target simplicity as much as mapping one set of calls to another.
Proxy, Decorator: Proxy pattern binds the class being proxied with the proxy class at compile time. Decorator does this at runtime. Decorator typically intends to add or remove functionality while Proxy typically exposes full functionality. In most cases, proxy always uses lazy instantiation for the class which is being proxied and decorator will typically instantiate the containing class in the constructor.
Chain of Responsibility, Decorator: Think linked lists v/s wrappers. Linked lists can kill the flow at any time w/o visiting all elements. In addition wrappers implement both pre and post processors.
Decorator, Inheritance: If each operation implemented by a decorator is instead implemented as a sub class, you will have to create multiple combination sub-classes for each combination which can be produced using a decorator sequence. Think m+n v/s m 'times' n for the total number of classes.
Strategy, Dependency Injection: DI is a refinement of Strategy pattern.
Strategy, Command: Strategy pattern can be used when implementations change for a task amongst different classes (which implement the same interface). Command on the other hand is much simpler. It makes sense when the caller does not want to get involved in the details of how a handler implements a certain command.