Since we do not have a full analysis on a suitable templating technology we decided to use JSF for rendering of HTML but use Spring Webflow to handle the postback. Using Facelets to handle HTML templating and leaving out JSF components produces nice and plain HTML ideal for jQuery (or any other JavaScript framework) on the client.

Using Webflow to handle the postback proved to hold much less surprises than when we used JSF. Most of the tasks required just work. But there is one thing that was missing. There was no way of accessing flow scoped (or view scoped) variables in Spring MVC controller methods handling ajax calls.

Why not use the Webflow’s ajax abstraction? Webflow’s ajax abstraction is based on re-rendering page fragments which is not suitable for retrieving pure data from the server. On the other hand Spring 3 introduced a very appealing ajax simplification (as described here) which significantly cuts down server and client side ajax handling code.

Problem statement

I want to have all data related to the process defined in (and handled by) Webflow conveniently accessible from my MVC controller methods handling ajax calls. While I do not want to define the flow data outside the flow definition xml.

Example: Imagine a user registering an account. The process of creating an account spans several screens and it is defined in a flow. Inside this flow there is a flow scoped variable of type Account. On one of the screens you need to provide a list of available products using an ajax call. The available products depend on data entered on previous screens (this means they are already stored in flow scope) and on data on the current screen (sent via ajax).

Solution proposal

A prefered solution would be to have Spring MVC inject data stored in flow scope as handler method parameters. You could denote these parameters by adding a @Flow annotation to them.

@RequestMapping("/data/availableProducts")
public @ResponseBody List getProducts(@Flow Account account, @RequestParam("query") String query) {
    List<Product> products = // filter using a query and data from the account being created
    return products;
}

Solution implementation

The concept behind the implementation is to expose the current flow execution to the AnnotationMethodHandlerAdapter (adapter handling our ajax requests) in similar fashion as it is done in FlowHandlerAdapter (adapter handling flow requests) and resolve arguments using a custom WebArgumentResolver.

For the @Flow annotation to work we 3 classes:

1. The @Flow annotation itself
2. A custom implementation of the WebArgumentResolver interface (a Spring SPI interface). Implementations of this interface are responsible for resolving arguments of handler methods
3. A custom implementation of the HandlerInterceptor interface (another Spring SPI interface)

@Flow

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.PARAMETER)
public @interface Flow {

    /**
     * Name under which the annotated parameter is registered in Flow scope.
     */
    String value() default "";
}

FlowArgumentResolver

This class does all the work. It contains one “hack” without which all of this would not work. It accesses FlowExecutorImpl the implementation of the FlowExecutor to retrieve the execution repository. If you cannot stomach this, tread no further .

public class FlowArgumentResolver implements WebArgumentResolver, InitializingBean {

    private FlowExecutor flowExecutor;
    private FlowExecutionRepository executionRepository;

    @Override
    public void afterPropertiesSet() throws Exception {
        executionRepository = ((FlowExecutorImpl) flowExecutor).getExecutionRepository();
        //...
    }

    @Override
    public Object resolveArgument(MethodParameter methodParameter, NativeWebRequest webRequest) throws Exception {
        if(isFlowParameter(methodParameter)) {
            return resolveFlowArgument(methodParameter, webRequest);
        }

        return UNRESOLVED;
    }

    private boolean isFlowParameter(MethodParameter methodParameter) {
        return getParameterAnnotation(methodParameter) != null;
    }

    private Flow getParameterAnnotation(MethodParameter methodParameter) {
        return methodParameter.getParameterAnnotation(Flow.class);
    }

    private Object resolveFlowArgument(MethodParameter methodParameter, NativeWebRequest webRequest) {
        FlowExecution flowExecution = getFlowExecution(executionRepository, (HttpServletRequest) webRequest.getNativeRequest());

        Flow parameterAnnotation = getParameterAnnotation(methodParameter);
        if("".equals(parameterAnnotation.value())) {
            return resolveByType(methodParameter, flowExecution);
        } else {
            return resolveByName(methodParameter, parameterAnnotation.value(), flowExecution);
        }
    }

    private Object resolveByName(MethodParameter methodParameter, String name, FlowExecution flowExecution) {
        MutableAttributeMap flowAttributes = flowExecution.getActiveSession().getScope();
        return flowAttributes.get(name);
    }

    private Object resolveByType(MethodParameter methodParameter, FlowExecution flowExecution) {
        Map flowAttributes = filterValues(flowExecution.getActiveSession().getScope().asMap(), instanceOf(methodParameter.getParameterType()));
        return ((Map.Entry) flowAttributes.entrySet().iterator().next()).getValue();
    }

    private FlowExecution getFlowExecution(FlowExecutionRepository executionRepository, HttpServletRequest request) {
        String flowExecutionKeyParameter = // from flowUrlHandler
        FlowExecutionKey executionKey = executionRepository.parseFlowExecutionKey(flowExecutionKeyParameter);
        return executionRepository.getFlowExecution(executionKey);
    }

    // ...
}

FlowHandlerInterceptor

This is only a helper class that initializes ExternalContextHolder. Without this the FlowArgumentResolver would not work.

public class FlowHandlerInterceptor extends HandlerInterceptorAdapter implements ServletContextAware, InitializingBean {

    private ServletContext servletContext;
    private FlowUrlHandler flowUrlHandler;

    @Override
    public void afterPropertiesSet() throws Exception {
        if (flowUrlHandler == null) {
            flowUrlHandler = new DefaultFlowUrlHandler();
        }
        //...
    }

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        ExternalContextHolder.setExternalContext(createServletExternalContext(request, response));
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        ExternalContextHolder.setExternalContext(null);
    }
    private ExternalContext createServletExternalContext(HttpServletRequest request, HttpServletResponse response) {
        ServletExternalContext context = new MvcExternalContext(servletContext, request, response, flowUrlHandler);
        context.setAjaxRequest(ajaxHandler.isAjaxRequest(request, response));
        return context;
    }

    // ...
}

Configuration

After we have these three things we register the FlowArgumentResolver and FlowHandlerInterceptor and arguments annotated with @Flow are automagically resolved from the current flow execution.

<bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping">
    <property name="interceptors">
        <list>
            <ref local="flowHandlerInterceptor"/>
        </list>
    </property>
</bean>
<bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter">
    <property name="customArgumentResolvers">
        <list>
            <bean class="com.company.flow.FlowArgumentResolver">
                <property name="flowExecutor" ref="flowExecutor" />
            </bean>
        </list>
    </property>
</bean>

<bean id="flowHandlerInterceptor" class="com.company.flow.FlowHandlerInterceptor"/>

Conclusion

There is one (IMHO fortunate) side-effect here. Since Webflow stores snapshots of flow scoped objects when flow pauses in view states you always access a deserialized copy of your data in Spring MVC handlers. The consequence of this is that you cannot really change flow scoped variables in MVC ajax handlers. And since changing server-side state using ajax calls can get really tricky really fast this is a not as big of a problem as it might seem. (Actions that change data should be recorded in the flow definition as event handlers if needed)

Using these 3 rather short classes and couple of lines of configuration we are able to access flow scoped variables very conveniently just by a simple annotation. Furthermore a similar approach can be adopted to access view scoped variables as well.

/Enjoy

Edit: the full code and a showcase can be found at http://code.google.com/p/webflow-mvc-bridge/

Like everyone during development I find myself writing classes that share a certain set of functionalities. In other words they share the same small number of methods. If you prefer object composition over inheritance (as you should ) you define an interface and make all the classes implement this interface. But then another thing jumps up. You end up writing the same method bodies in every class. So you create one implementation of this interface and let every class use this implementation and just delegate the method calls. And now you’ve effectively created a simple mixin using the delegator pattern and one interface implementation and ended up with a lot of builerplate code. Like this:

// simple interface
public interface Description {

    String getName();

    String getDescription();

    String getVersion();

    void setName(String name);

    void setDescription(String description);

    void setVersion(String version);
}

// one implementation
public final class DescriptionImpl implements Description {
    private String name;
    private String description;
    private String version;

    public String getDescription() {
        return description;
    }

    public void setDescription(String description) {
        this.description = description;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getVersion() {
        return version;
    }

    public void setVersion(String version) {
        this.version = version;
    }

    @Override
    public String toString() {
        return "" + name + " \"" + description + "\" (" + version + ")";
    }
}

// mixin usage
public class Bean implements Description {
    // mixing in the description to this bean
    private final Description description = new DescriptionImpl();

    // HERE IS THE BOILERPLATE DELEGATION CODE
    public void setVersion(String version) { description.setVersion(version); }

    public void setName(String name) { description.setName(name); }

    public void setDescription(String description) { this.description.setDescription(description); }

    public String getVersion() { return description.getVersion(); }

    public String getName() { return description.getName(); }

    public String getDescription() { return description.getDescription(); }

    @Override
    public String toString() { return description.toString(); }
}

I know that this is a really simplistic example but just try to imagine some complex operations taking place in the default interface implementation or possibly some generic code. Wouldn’t it be nice if with the help of an IDE you would be able to write this and end up with the same thing as in the above code fragment?

public class Bean implements Description {

    @Mixin private final Description description = new DescriptionImpl();

// and here imagine the collapsed auto-generated builderplate code here
}

The mixin can depend on the object that mixes it in:

public interface Upcase {

    String toUpcaseString();
}

public final class UpcaseImpl implements Upcase {
    private Object object;

    public UpcaseImpl(Object object) {
        this.object = object;
    }

    public String toUpcaseString() {
        return object.toString().toUpperCase();
    }
}

public class Bean implements Upcase {
    @Mixin private final Upcase upcase = new UpcaseImpl(this);

// and here imagine the collapsed auto-generated builderplate code here
}

The technology is present in (all) modern IDEs but I haven’t seen anything like this yet. Has anybody seen something similar in their IDE? Another question is: does anyone care? (Or is it just me )

While Swing provides a wide range of ready made components that cover a wide range of use cases most of the time if you find yourself needing something more you have to resort to writing it from scratch. After a couple of afternoons of searching the web for a decent open source solution I gave up and started looking for a tutorial that would help me understand the concepts underneath JTable and help me extend it to allow cell spanning. I found this tutorial which builds a fully functional JTable with cells that can span multiple columns. This was a nice start but I needed a little more.

Concepts

Adopting the division of cells from the above mentioned tutorial, there are 4 types of cells: hidden, visible, spanned and logical cells.

• Visible cell – a cell that gets rendered
• Hidden cells – a cell not rendered because it is spanned by another cell
• Spanned cells – a cell which spans atleast 2 columns or rows (thereby hiding other cells)
• Logical cells – every cell is a logical cell, a logical cell is used to query the model

A model holds information that the table displays, using an UI component, including the information about visible and hidden cells and cell spans. A custom UI object filters out the hidden cells to display only the visible ones.

Implementation

Span table and its dependencies

A SpanModel implementation

DefaultSpanModel is a basic implementation of the SpanModel interface. It uses java.util.Maps to store information about cell spans and hidden cells.

public class DefaultSpanModel extends ForwardingTableModel implements SpanModel {
    // decorated model
    private Map<Integer, Map<Integer, Integer>> rowSpans;
    private Map<Integer, Map<Integer, Integer>> columnSpans;
    private Map<Integer, Map<Integer, Cell>>    hiddenCells;

    /**
     * Constructs a new <code>DefaultSpanModel</code> backed by the supplied
     * <code>model</code>.
     *
     * @param model to be extended
     */
    public DefaultSpanModel(TableModel model) {
        super(model);

        Factory hashMapFactory = new Factory() {
            public Map<Integer, Integer> create() {
                return new HashMap<Integer, Integer>();
            }
        };

        rowSpans = MapUtils.lazyMap(new HashMap<Integer, Map<Integer, Integer>>(), hashMapFactory);
        columnSpans = MapUtils.lazyMap(new HashMap<Integer, Map<Integer, Integer>>(), hashMapFactory);
        hiddenCells = MapUtils.lazyMap(new HashMap<Integer, Map<Integer, Cell>>(), new Factory() {
            public Object create() {
                return new HashMap<Integer, Cell>();
            }
        });
    }

    // ...
}

Keep in mind that this is not the most efficient implementation as after the first rendering you’ll have (2 *(# of rows) + (# of columns)) of map instances but it does simplify the implementation of functionality and should keep rendering time independent of the number of spanned cells. Its a start .

The most important trick to it is the custom UI object that filters hidden cells and only displays the visible ones. (Swing components delegate their rendering to utility UI objects to facilitate flexible look and feel as the above tutorial explains). This can be a bit of a problem to the generality of the solution. Because to render the span table you need a custom UI object but if someone changes the UI object then you don’t render the span table correctly. The good news is that most of the look and feels don’t change the rendering of tables (mostly only headers). As a precaution I set the UI object in the contructor and ignore any other UI component setting.

public class SpanTable extends JTable {
    private boolean isSpanModel;

    public SpanTable(TableModel model) {
        super(model);
        // the table UI has to be set to <code>SpanTableUI</code>
        this.setUI(new SpanTableUI());
    }

    @Override
    public Rectangle getCellRect(int row, int column, boolean includeSpacing) {
        if (isSpanModel) {
            // if the model is a span model, we have to check if the cell is spanned or not
            // and expand the area of the cell to reflect it
            Rectangle cellRect = super.getCellRect(row, column, includeSpacing);

            for (int i = 1, n = ((SpanModel) getModel()).getRowSpan(row, column); i < n; i++) {
                // expand the area of the visible cell
                cellRect.height += getRowHeight(row + i);
            }

            for (int i = 1, n = ((SpanModel) getModel()).getColumnSpan(row, column); i < n; i++) {
                // expand the area of the visible cell
                cellRect.width += getColumnModel().getColumn(column + i).getWidth();
            }

            return cellRect;
        }

        return super.getCellRect(row, column, includeSpacing);
    }

    @Override
    public void setUI(TableUI ui) { }

    @Override
    public void setModel(TableModel dataModel) {
        isSpanModel = dataModel instanceof SpanModel;
        super.setModel(dataModel);
    }

    @Override
    public void changeSelection(int rowIndex, int columnIndex, boolean toggle, boolean extend) {
        // only needed for correct repaint behavior
        super.changeSelection(rowIndex, columnIndex, toggle, extend);
        repaint();
    }

    @Override
    public int columnAtPoint(Point point) {
        if(isSpanModel) {
           int row = super.rowAtPoint(point);
           int column = super.columnAtPoint(point);

           // return the column of the hiding cell
           return ((SpanModel) getModel()).getVisibleCell(row, column).getColumn();
        }

        return super.columnAtPoint(point);
    }

    @Override
    public int rowAtPoint(Point point) {
        if(isSpanModel) {
           int row = super.rowAtPoint(point);
           int column = super.columnAtPoint(point);

           // return the row of the hiding cell
           return ((SpanModel) getModel()).getVisibleCell(row, column).getRow();
        }

        return super.rowAtPoint(point);
    }
}

The most importat thing here is the expansion of the spanned cell rectangle in getCellRect().

Here is a simple usage example:

// DATA
String[][] data = new String[][] {
    {"a1", "a2", "a3", "a4"},
    {"b1", "b2", "b3", "b4"},
    {"c1", "c2", "c3", "c4"},
    {"d1", "d2", "d3", "d4"},
    {"e1", "e2", "e3", "e4"}
};

// SPAN TABLE INITIALIZATION
DefaultTableModel model = new DefaultTableModel(data, new String[] { "1", "2", "3", "4" });
DefaultSpanModel spanModel = new DefaultSpanModel(model);

aFrame.getContentPane().add(new JScrollPane(new SpanTable(spanModel)), BorderLayout.CENTER);

spanModel.setColumnSpan(0, 0, 3);
spanModel.setRowSpan(1, 1, 2);
spanModel.setColumnSpan(1, 1, 2);
spanModel.setRowSpan(2, 0, 3);

This is the final result:

A table with 3 spanned cells

A cell spanning 3 columns (edit)

A cell spanning 2 columns and 2 rows (edit)

A cell spanning 3 rows (edit)

Span table

Resources

source code

I have compiled this little cheat sheet for those who like working with arrays in Ruby but not just for Ruby’s expressivness as a language but mostly for the idioms behind it. If you like the way Ruby (and also Smalltalk and others, but I like Ruby the best ) handles arrays but you cannot use Ruby in your projects directly — CollectionUtils from the Apache Commons-Collections library (version 3.0 and above) can maybe be the answer you are looking for. For the price of added Java’s verbosity (compared to Ruby) you can find yourself on familiar ground with your Java collections.

Cheat sheet

each

[1, 2, 3, 4].each { |x| print x }
# >> 1
# >> 2
# >> 3
# >> 4

one possibility how to translate Ruby’s each to Java

List<Integer> i = Arrays.asList(1,2,3,4);
CollectionUtils.forAllDo(i, new Closure() {
    public void execute(Object i) {
        System.out.println(i);
    }
});

select

[1, 2, 3, 4].select { |x| x % 2 == 0 }
# >> [2, 4]

one possibility how to translate Ruby’s select to Java

List<Integer> i = Arrays.asList(1,2,3,4);
System.out.println(CollectionUtils.select(i, new Predicate() {
    public boolean evaluate(Object o) {
        return (Integer)o % 2 == 0;
    }
}));

reject

digits = (1..10).to_a
digits.reject { |x| i < 5 }
# >> [5, 6, 7, 8, 9, 10]

one possibility how to translate Ruby’s reject to Java

List<Integer> i = new ArrayList<Integer>(10);
for (int j = 1; j <= 10; j++) {
    i.add(j);
}
System.out.println(CollectionUtils.selectRejected(i, new Predicate() {
    public boolean evaluate(Object o) {
        return (Integer)o < 5;
    }
}));

collect

[1, 2, 3].collect { |x| x + 1 }
# >> [2, 3, 4]

one possibility how to translate Ruby’s collect to Java

List<Integer> i = Arrays.asList(1,2,3);
System.out.println(CollectionUtils.collect(i, new Transformer() {
    public Object transform(Object input) {
        return (Integer)input + 1;
    }
}));

detect

(1..100).to_a.detect { |i| i % 5 == 0 and i % 7 == 0 }
# >> 35

one possibility how to translate Ruby’s detect to Java

List<Integer> i = new ArrayList<Integer>(100);
for (int j = 1; j <= 100; j++) {
    i.add(j);
}
System.out.println(CollectionUtils.find(i, new Predicate() {
    public boolean evaluate(Object o) {
        return (Integer)o % 5 == 0 && (Integer)o % 7 == 0;
    }
}));

inject

[1, 2, 3, 4, 5].inject(0) { |sum, x| sum += x }
# >> 15

Translating inject is a little tricky because of the anonymous classes involved and the final value retrieval. Here is one possible way how to translate Ruby’s inject to Java. Probably not the best way to do it but still a working solution

List<Integer> i = new ArrayList<Integer>(5);
for (int j = 1; j <= 5; j++) {
    i.add(j);
}
CollectionUtils.transform(i, new Transformer() {
    int sum = 0;
    public Object transform(Object input) {
        sum += (Integer)input;
        return sum;
    }
});
System.out.println(i.get(i.size() - 1));

// lets use an inner class to do the work:
private static class SumAccumulator implements Closure {
    private int sum;

    public void execute(Object o) {
        sum += (Integer)o;
    }

    public int getSum() {
        return sum;
    }
}

// then the sum accumulation would look something like this:
SumAccumulator accumulator = new SumAccumulator();
CollectionUtils.forAllDo(i, accumulator);
System.out.println(accumulator.getSum());

include?

digits = (1..10).to_a
digits.include? 5
# >> true

one possibility how to translate Ruby’s include? to Java

List<Integer> i = new ArrayList<Integer>(100);
    for (int j = 1; j <= 10; j++) {
        i.add(j);
    }
System.out.println(CollectionUtils.exists(i, PredicateUtils.identityPredicate(5)));

compact

["a", null, "b", null, "c", null].compact
# >> ["a", "b", "c"]

one possibility how to translate Ruby’s compact to Java

List<String> s = new ArrayList<String>();
s.add("a");
s.add(null);
s.add("b");
s.add(null);
s.add("c");
CollectionUtils.filter(s, PredicateUtils.notNullPredicate());
System.out.println(s);

As you can see the added finger typing with ‘translated’ Ruby into Java is in orders of hundreds of percent for small examples like these. But these constructs should stay unchanged and the more business logic you have the more efficient they will get. The added bonus is in being able to work with Java collections in somewhat familiar way to Ruby’s array. You could even make your own List interface implementation with each(), select(), reject(), collect(), detect(), inject(), include(), compact() methods added to the mix. And you could end up with something like this:

class MyList extends ArrayList {
    public void each(Closure closure) {
        CollectionUtils.forAllDo(this, closure);
    }

    public MyList select(Predicate predicate) {
        return MyList(CollectionUtils.select(this, predicate));
    }

    // ... and so on ... you get the idea
}

Q: What are the basics concepts of a corporate network on the Windows platform?

When you imagine a basic computer network (for example: a home or small office network) you usually think of a bunch of computers connected via switches, that probably have a router connecting them to the internet and maybe some printers or scanners that they can share among them selves.

Now when I say that “the computers share” printers and scanners I of course mean that one user sitting at a computer with a printer (scanner) lets another user sitting at another computer use his/hers printer (scanner). I say that computers share to illustrate one point: home and small office networks users mostly don’t interchange or share computers. They authenticate only locally (against the username and password stored on the local computer) and have mostly full access to the computer.

Aside from internet access and file/printer/scanner sharing there is usually not much else going on in these networks.

Q: How are the corporate networks different?

There are some obvious and some not so obvious ways. They are obviously bigger. Not only workstations (personal computers) but also servers — computes dedicated to providing services to the network (e.g. File servers, Print servers, DNS servers, etc.) are on the network. The size of the network can vary — laptop users coming and going. And the security on corporate networks must be stricter assuming that the data handled are more sensitive than data handled on a home network also when it provides some sort of access to it from the internet for example a Web server hosting the corporate web applications or the network provides Remote Desktop Connection.

The less obvious reasons can be that the corporate network does not only host a lot of computers (be it workstations or servers) but also can span not only floor in a building or buildings but also cities and even continents. Company specific services (physically located on one side of the globe) have to be accessible to authorized users (even on the other side of the globe). Workstation users can interchange their computers (free-seating). A corporate network has to accommodate companies with complex inner structure without forcing their structure to change and has to be flexible for example in an event of one company buying another.

Now with this in mind we can ask how does the Windows platform accomplish these things?

Q: What do you mean by ‘these things’?

• user authentication – controlling user access to the network
• user authorization – controlling authenticated user access to network resources (data, servers, printers, etc.)
• user account management – controlling user account security (by forcing secure passwords or restricting user local machine privileges like disallowing changes to hardware or network settings)
• network resources management (providing names and lookup services for those names – physical resource location transparency)
• logical grouping of user and network resources to simplify their management

The Windows platform provides many more features but for now lets focus on the above.

Q: So how do I build a network solution on the Windows platform?

First of all you have to understand that your network and its resources are on the Windows platform network solution managed by a service called Active Directory. The Active Directory directory service is provided with Windows servers. So to build a network on the Windows platform you will need a Windows server for example a Windows Server 2003. So lets assume that you have one. What is next? Next you’ll need to understand a little bit about Active Directory and the structures it manages.

Active Directory

We said that Active Directory is a directory service. From Wikipedia:

A directory service (DS) is a software application — or a set of applications — that stores and organizes information about a computer network’s users and network resources, and that allows network administrators to manage users’ access to the resources. Additionally, directory services act as an abstraction layer between users and shared resources.

And more specifically it’s Microsoft’s implementation of the Lightweight Directory Access Protocol or LDAP and was first released with Windows 2000 Server edition.

Active Directory is simply a database of objects which represent users, computers, network resources and groupings of each of them. On the top level Active Directory manages a domain forest which is a grouping of domain trees. A domain forest can also consist of a single domain tree. The picture below shows a more general version of a domain forest.

To understand what a domain forest is and what it is good for lets first discuss what is a domain.

Domain

A domain is a logical grouping of objects (just like the domain forest) but something like a second level grouping. And by second level I mean a more specific grouping. The objects managed in a single domain have the same distinguished name suffix (the domain component part).

Q: What are distinguished names?

Distinguished name (DN) is a notion from LDAP — Active Directory is an implementation of LDAP remember? As you might have guessed DNs are used in Active Directory to identify the specific objects stored in it. Everything in Active Directory has a distinguished name — users, computers, groups, organization units and so on.

The best way to explain this is to look at an example.

Lets say we have our own organization called awesome organization , you are part of the management of the organization and your name is John Doe. Then your distinguished name (the name given to you by Active Directory) would be something like this:

CN="John Doe", CN="management", DC="awesome", DC="org"

Where CN stands for Common Name and DC stands for Domain Component. You can see that the naming in Active Directory is hierarchical. Another thing you can notice is that the domain has a name! And as we’ve discussed above the domain manages objects with the same distinguished name suffices. In the above example that would mean objects whose distinguished names end with DC=”awesome”, DC=”org”.

Q: Do I have to buy a domain called awesome.org to be able to use it with Active Directory?

No you don’t. Domain names in Active Directory are completely independent of domain names on the Internet. You can call you domain local or business or whatever you like. If it bothers you that they look the same it’s just because the method used to resolve domain names on the Internet and in Windows domains is the same namely DNS.

With the notion of domains as a collection of objects with the same distinguished name suffix we can return to the domain forest and see its function. The domain forest is a grouping of domains (domain trees) and that means that a domain forest can manage objects without the need for them to have the same distinguished name suffix.

Domain tree

A domain tree is actually a more general term for a domain. You can think of a domain tree as a domain with zero or more subdomains.

If from our previous example (awesome.org) we wanted to make our management department a whole subdomain its name would be management.awesome.org. And then your DN would be:

CN="John Doe", DC="management", DC="awesome", DC="org"

The CN in front of management changed to DC.

Domain Controllers

OK, so we know a bit about Active Directory. We know that it’s a database of some sorts. It manages objects that represent users, computers, user groups, computer groups, organizational units (more on these later). But where is this database stored physically? The answer is (as the title of this section suggests) Domain Controllers. A domain controller is a piece of software shipped with Windows servers that manages the authentication requests in a windows domain. If a computer is a part of a domain and a user wants to log in he/she provides the username and password. The computer instead of checking that information against something stored locally it contacts a domain controller and asks if it can do the authentication instead. If the domain controller authenticates the user the user is granted access to the local machine and the domain.

Three things to remember:

1. the computer must be part of a domain
2. the computer uses the domain controller to check the users credentials
3. the domain controller does the authentication not the authorization

Resource and user/machine management concepts

There are two concepts: one for managing network resources (access to servers, share files, printers, etc.) and one for managing the user workstations and user accounts.

Access Control Lists

To manage network resources windows domains use Access Control Lists or ACLs. ACL is just an enumeration of users or groups with their rights to use a particular resource. The important thing is that the ACL are stored with the resources. Active Directory does not store them. For example:

You have a File server in your domain. A File server provides the users of the domain with the access to certain folders in its directory structure. On each of those folders you can set an ACL saying which users can read/write/delete(/and many more options) these folders, subfolder and so on. Here is a concrete example setting permissions to Read & Execute, List Folder Contents and Read for the group named Managers on the folder named DATA.

You can imagine that setting permissions for every individual user would be a daunting task. The solution? Groups! Group users, group machines, group groups, group everything and set ACLs on groups instead of individual users.

Group Policies

To manage user accounts and machines you use a Group Policy (GP). Group policies are rules applied to the users workstation at computer startup (Computer configuration) and/or at logon (User configuration). There are around 1000 individual setting you can apply to the users workstation with Group Policies. From the complexity of passwords needed to logon, the contents of the Start menu, access to the Control Panel to write permission of the local hard drive or profile folder redirections.

You can even use GPs to remove the pesky Recycle Bin desktop icon if you don’t want it there

Q: I really don’t want to set all 1000 individual setting. Is there no easier way?

YES, THERE IS! And thank God for that! Microsoft developed the Common Desktop Scenarios which are implementation if GPs for some common types of users and workstations. The scenarios contain GPs for:

• Lightly managed
  • Power users
  • Laptop users
• Highly managed
  • Application station
  • Multi-user station
  • Task stations
  • Kiosk station

In most cases only minor adjustments to those scenarios are necessary to get the desired result.

Additional useful links

http://www.windowsnetworking.com/articles_tutorials/Networking-Basics-Part1.html
http://web2.blogtells.com/

Q: What does metaprogramming mean exactly?

It means writing programs which modify them selves and/or write other programs. At runtime! In Ruby the most common example of metaprogramming is the shorthand for creating attribute readers/writers/accessors (i.e. getters/setters)

class Person
  attr_accessor :name
end

# is extended to (and therefore is equivalent to)
class Person
  def name=(val)
    @name = val
  end
  def name
    @name
  end
end

The attr_accessor is an ordinary class method which accepts symbols (or strings) and based on those symbols defines the methods like name= and name. That is it modifies itself!

Q: Is this it? Is this all we can do with it?

Not at all. Pretty much anything you can do statically (before compilation) you can also do dynamically (at runtime). This includes declaring new classes, adding class and instance methods to those classes, setting their instance variables and so on.

But if you want to do that you need to understand a few things about the inner workings of Ruby. Specifically:

1. How to create new classes at runtime
2. Where are method stored
3. How to programmatically define a method
4. Understand instance_eval, class_eval

How to create new classes at runtime

Creating new classes at runtime is actually the easiest thing of the above four. It’s just a call to the class method of the class Class (that’s quite a mouthful).

Person = Class::new

# is equivalent to
class Person
end

Notice the double colons ( :: ) after Class. It’s there to remind us that we are calling a class method. Class::new creates an anonymous class. When we assign it to a constant we effectively give it a name. We can also supply a superclass to the Class::new method to create a subclass of that superclass.

Where are method stored

Q: Creating classes is great and all but we would really like them to do something useful not just to sit around. So how to we define methods?

The real question is — which methods? Instance methods or class methods? This is a crucial point because instance method actually reside elsewhere then class methods. The picture below (is just an approximation) illustrates the process of resolution of method calls.

Instance method call

Instance method “source codes” reside in classes. In order for an instance of a class to run such a method the instance needs to reach in to its class, find out if the class has the method and then run the method. Imagine we want to call the instance method im on the instanceOfCustom (which is our custom class, duh):

1. instanceOfCustom follows the klass pointer to its class
2. searches for the method im in the repository of methods inside the class
3. invokes the method

Class method call

Q: So if the class holds the instance methods where are the class methods?

Good question. Lets look in the superclass of our Custom class. Nope, not there … just more instance methods. So what if we would follow the same procedure like with the instance method call? We (and by we we mean our Custom class) get a request to run the class method cm:

1. We follow our klass pointer to something
2. then search that somethings repository of methods and are surprised that it actually has one
3. invoke the method

What is that something that lets Ruby have such elegantly similar (i.e. the same) procedure for calling instance and class methods? Well it behaves something like a class but is not quite a class and in fact it’s a metaclass. It’s kinda like a new class hierarchy (see the above picture). Metaclasses are virtual (notice the flag V, you cannot make instance of them) and are created by the interpreter on demand and are not visible in the class hierarchy as you cannot reach them using the superclass reference. The metaclass concept can be hard to understand so try reading why’s seeing metaclasses clearly for more insight.

OK, now that we know where the individual methods reside lets see how can we actually put them there our selves programmatically.

How to programmatically define a method

Now that we know where methods need to be stored to take the property of being instance or class methods we can try to create our own method programmatically. One way to do so is to use instance_eval and class_eval methods and inside their body define the method we want to add. Lets focus on class_eval first.

With class_eval you can run code in the context of a class (it’s just like being inside class … end).

# we'll use the above defined Person class
Person.class_eval do
  def name
    @name
  end
  def name=(val)
    @name = val
  end
end

p = Person.new
p.name = 'John'
p.name
# => "John"

This way you can add the instance and class methods name and name= to whatever class you wish. For example:

def add_name(klass)
  klass.class_eval do
    def name; @name; end
    def name=(val); @name = val; end
    def self.name; self.to_s; end
  end
end

add_name(String)
a = 'hello'
a.name = 'John'
a.name
# => "John"
a.class.name
# => "String"

Q: So what is instance_eval for then? And why did we bother learning about metaclasses?

Good questions. Before answering them lets make it a bit more confusing than it is now but after that the explanation will make more sense. Lets try the same example but change the class_eval for instance_eval.

def add_name(klass)
  klass.instance_eval do
    def name; @name; end
    def name=(val); @name = val; end
    def self.name; self.to_s; end
  end
end

add_name(String)
a = 'hello'
a.name = 'John'
a.name
# => "John"
a.class.name
# => "String"

We get the same result! Surprised? There is no reason to be and this is why: classes are just instances of the class Class. That is why we get the same results with instance_eval and class_eval called on a class.

Q: So what is instance_eval for again?

The reason that you can use instance_eval on classes is a side effect of the fact that classes are instances themselves. The really cool thing about instance_eval is that you can call instance_eval on objects and execute code in their context. So we can for example “cheat” and display private attributes using instance_eval.

class C
  def initialize
    @a = 1
  end
end
C.new.instance_eval { @a }
# => 1

Or even add singleton (object specific) methods to objects!

p1 = Person.new
p2 = Person.new
p1.instance_eval do
  def say_hello
    p 'hello'
  end
end
p1.say_hello
# => "hello"
p2.say_hello
# => NoMethodError: undefined method `say_hello' for #<Person:0x2b8462c>
#            from (irb):9

How cool is that! Only the polite person (p1) can say_hello and the other one (p2) is just rude. The instance_eval method is defined in class Object so everyone can use it but class_eval method is defined in Module and can be used only by modules an classes.

Q: I still don’t see how the metaclasses fit in.

The above examples of adding instance and class methods are perfectly valid but there are things that you cannot accomplish by explicitly defining methods. Sometimes you need to pass stuff from outside into the method definition like symbols, string, blocks and so on. And by starting a definition you effectively cut yourself off from the surrounding scope. For instance you cannot access variables assigned in the outer scope. Understanding variable scope, blocks and Procs takes a longer discussion that’s why I wrote a whole post about this topic.

So assuming you have an idea about variable scope, blocks and Procs you should be able to see the shortcomings of the metaprogramming using explicit method definitions. The way Ruby does metaprogramming without explicit definitions is by providing the define_method private method in the Object class. We can call this method passing it the method name (a symbol) as argument and associate a block with it which will be the method’s body and Ruby defines the method for us. Thanks to this we don’t have to start a new method definition and we have access to variables in the surrounding scope. As the block of the method body is transformed into a Proc (more on this in the post I mentioned above) the context in which it’s defined is associated with it so the block will have access to variables defined in that scope even in a different context (in the context of a class or a instance, etc.). Lets look at an example.

Person = Class::new
var = 5
Person.class_eval do
  def age
    @age ||= var
  end
end
Person.new.age
# => NameError: undefined local variable or method `age' for #<Person:0x2b78764>
#            from (irb):4:in `age'
#            from (irb):8

Person.class_eval do
  define_method(:age) do
    @age ||= var
  end
end
Person.new.age
# => 5

The first time we tried calling the method age we got an error because Ruby cannot find the variable var because it’s not a local variable. But thanks to block turning to Procs the second time everything works fine.

Q: Neat, so we can define instance methods without explicit definition. What about class methods?

The define_method adds a new method definition to a class which has the effect of a new instance method (because the class is the repository of instance methods remember?). Do you see them now?

Metaclasses to the rescue! By now it should be clear that calling the define_method method in a metaclass of a class should add a new method to the method repository of the metaclass a thus effectively making the new method a class method. Yes, it’s exactly the same as with instance methods! There is a little snag though. There is no direct way of getting to the metaclass of a class (presently at least). The way people do it is to open the metaclass’ definition and return a reference to it.

class Person
  def self.metaclass
    class << self
      self
    end
  end
end

# now we can use the metaclass to define a class method
Person.metaclass.class_eval do
  define_method(:max_age) do
    125
  end
end
Person.max_age
# => 125

Piece of cake!

Q: How does the method self.metaclass work?

Two reasons.

First because Ruby allows us to get to so-called per-object classes. The notation class << self is used to open this per-object (singleton) class associated with an object. (You can use this notation as another way of adding methods to a single object.) And since classes are objects too we can access their per-object class the same way but in reality what we get we call the class’ metaclass.

The second reason is that Ruby is a dynamic language. And therefore you can return values from the definition of a class.

class C
  10
end
# => 10

Q: This is all interesting and all but what can I do with it?

Metaprogramming is best suited for automating repetitive tasks (like creating attribute readers/writters), developing frameworks (a great example is ActiveRecord in Rails and how it gets metadata from the database and then builds up your model classes without you having to do anything) and having lots and lots of fun!!!

Ruby code block are chunks of code surrounded by do and end keywords (or single line block with curly braces). Blocks can take arguments. The arguments are declared surrounding variable names by pipe symbols. They can be associated with method calls and evaluated using yield. Passing arguments is accomplished by passing arguments to yield. Any method can be called with a block as an implicit argument. So for example:

# implicit block evaluation
def m1
  yield
end

# passing arguments to implicit block
def m2( param )
  yield param
end

# assigning a name to an implicit block
def m3( param, &block )
  block.call param
end

m1 { puts 'hello' }
# => "hello"

m2( 'hello' ) { |x| puts x }
# => "hello"

m3( 'hello' ) do |x|
  3.times { puts x }
end
# => "hello"
# => "hello"
# => "hello"

In the above example we can see how are blocks associated with method calls and how are blocks evaluated inside a method. In the m3 method call we can see how multi line blocks are associated with method calls.

Q: Whoa! Where is the yield in m3, hmm? And what is the meaning of the ampersand before the parameter block?

You got me The yield is replaced by block.call because we supplied a name for the block being associated (and a very unimaginative one: block) and thanks to that by the time the block gets to the method body it’s no longer a block. It’s actually a Proc. In m1 and m2 the block is anonymous and we evaluate it by calling yield. If we want to give a name to the block (by putting an ampersand before the name of the methods last parameter) we get a reference to it wrapped in a Proc object. And to evaluate a Proc you need to call it’s call method.

The m3 example is interesting in another way also. It shows how blocks handle scope of variables. The block sees the variables in the context (scope) it was declared in. The block { puts x } sees the variable x declared outside of its scope and therefore can print it. And blocks are generous and can provide that kind of scope transcending service to anyone — but only if they go through a self sacrifice and change into a Proc!

Proc

A Proc can be created by associating a block to the call of Proc.new (actually associating a block with any method call does the trick). Proc is a block associated with a context. So for example if we have a local variable say foo and we use it in a block and send the block to a method which automatically converts the block to a Proc then the formally local variable foo can be accessed in the new scope of the method. Pretty cool, huh?

def bar
  yield( 10 )
  puts var # bam! this throws an error
end

var = 1
bar { |value| var = value }
# => 10
# => NameError: undefined local variable or method `var' for main:Object
#            from (irb):3:in `bar'
#            from (irb):6

In the above example we declare a method bar which cannot access the variable var which is defined later in the scope but using a block we can assign a value to it without being able to access it directly (hence the NameError). Since the start of a method (or class) definition opens a new context we cannot assign the value of var in a method and see it change in the outer scope without the cool goodness of Procs. So only an “insane” person would try something like this:

var = 1
def bar
  var = 10
end
bar
puts var
# => 1

And expect var to be 10.

Lambda

Lambda is a Kernel method (so we should write it with a lowercase l – lambda) a call to which is equivalent to Proc.new. Except that a lambda returns a Proc which checks the number of parameters passed when called. If the number of parameters is wrong you get a warning.

l = lambda {|x| 3.times {puts x}}
l.call "hi","you"
# => (irb):2: warning: multiple values for a block parameter (2 for 1)
# => "hi"
# => "you"
# => "hi"
# => "you"
# => "hi"
# => "you"

Lambda vs Proc

From Wikipedia

Both Proc.new and lambda in this example are ways to create a closure, but semantics of the closures thus created are different with respect to the return statement.

def foo
  f = Proc.new { return "return from foo from inside proc" }
  f.call # control leaves foo here
  return "return from foo"
end

def bar
  f = lambda { return "return from lambda" }
  f.call # control does not leave bar here
  return "return from bar"
end

puts foo # prints "return from foo from inside proc"
puts bar # prints "return from bar"

I decided to use RocketDock instead of the desktop icons utilizing its very nice (and free) AutoHide feature.

Being a “purist” I spotted a duplication. RocketDock contains built in icons for My Computer, My Network Places and Recycle Bin and so does my desktop (because I prefer the classic windows start menu). That is why I decided to remove these icons from my desktop.

The cleanup

Removing the My Computer and My Network Places is easy. Delete works just fine. The hard part is removing the Recycle Bin. There are multiple ways how to get rid of the Recycle Bin icon actually:

• A third-party program was used to hide the Recycle Bin.
• The TweakUI program was used to hide the Recycle Bin.
• The registry information for the Recycle Bin was deleted.
• A Group Policy setting was used to hide the Recycle Bin.

I used my Local Computer Group Policy to do the job.
NOTE: Windows XP Home Edition does not support Group Policy.

The procedure

1. Open the Group Policy Object Editor
2. Enable the ‘Remove Recycle Bin icon from the desktop’ option
3. Restart your computer
4. Delete the Recycle Bin icon

Open the Group Policy Object Editor

From the Start menu select Run, type gpedit.msc and press OK.

The Group Policy Object Editor shows up.

Enable the ‘Remove Recycle Bin icon from the desktop’ option

In the Group Policy Object Editor navigate to:

Local Computer Policy -> User Configuration -> Administrative Templates -> Desktop
and double click Remove Recycle Bin icon from desktop option and change from Not configured to Enabled.

Restart your computer

Group policies are applied when a user logs in or the computer boots up. The easiest way to ensure that the new policies have been applied is to simply restart your computer. If you prefer not to you can run the gpupdate /force command which can update most of the changes to policies. But as my windows administration teacher says:

“with windows there are never enough restarts”

Delete the Recycle Bin icon

Now you should be able to select the Recycle Bin desktop icon and delete it out of your clean, icon free, spotless desktop.

For information on how to reverse the removal of the Recycle Bin desktop icon check out this Microsoft’s Help and Support page.