It is not a toy

I am an old school Oracle/HPUX/Linux Administrator. I write shell scripts to automate my tasks, I know the cron-syntax to schedule them. VI(M) syntax has become second nature. Memory boards in an uncountable number of machines carry my DNA (from nicking my fingers when pressing down the boards). And the best place to manage a machine is at the physical console with the noise of the computerroom as background music.

While this approach still retains its value today, there's a lot of machines that don't exist physically anymore, let alone have a physical console.

GUIs in one form or another rule the world of the administrators and developers these days. For me most of them are toys, good looking toys that are aimed at selling the product but otherwise get into the way of the real business. If I can avoid them they are never used beyond the first day/demo.

So my first opinion of nCoDE went along the lines of ... nice, they finally got a product selling tool out, this will help big time to get NetKernel in the mainstream. And then I ignored it.

I was wrong.

nCoDE fits the second C of Construct - Compose - Constrain, the three stages of ROC development, like a glove.

Lets look at a couple of questions that nCoDE can answer :

• You've developed the toolkit, but who's going to do the testing ? Well, obviously the testteam. In a regular environment they'd have to be at least as language proficient as you. With nCoDE they can just compose the tests they want without even knowing or caring what language you wrote the tools in.

• And why stop at testing ? You've developed the toolkit, but who's going to put the system together ? Who better than the enduser ? Sure, a technically savvy enduser that you might have to sit next to during the process, but how many filtering/interpreting/scheming elements are between you and the enduser today ? And what is the outcome ? Exactly ...

Even when doing everything by yourself nCoDE has enormous benefits. You can think in atoms. Create small (= manageable) tools. Then put away your coding hat and put on your composing hat. And compose molecules. You'll find - as did I - that both activities are different and should not be mingled. nCoDE allows this. You'll start writing better tools too.

Do not take my word for it.

I do not want you to and you do not have to. But do try it yourself. What follows is a minimal module.xml that I borrowed from Chapter 8 of the Practical NetKernel book. Once you have it up and running you can go Explore your very own nCoDE instance. Take care, you will come back but you will be a changed person !

<?xml version="1.0" encoding="UTF-8"?>

<module version="2.0">

  <meta>

    <identity>

      <uri>urn:org:netkernelbook:chapter8:ncode</uri>

      <version>1.0.0</version>

    </identity>

    <info>

      <name>Chapter 8 nCoDE</name>

      <description>NetKernelbook Chapter 8 nCoDE</description>

    </info>

  </meta>

  <system>

    <dynamic/>

  </system>

  <rootspace 

    name="Chapter 8 nCoDE"

    public="true"

    uri="urn:org:netkernelbook:chapter8:ncode">    

    <fileset>

      <regex>res:/etc/system/SimpleDynamicImportHook.xml</regex>

    </fileset>

    <endpoint>

      <name>Chapter 8 nCoDE Endpoints</name>

      <prototype>nCoDERuntime</prototype>

      <operator>res:/resources/endpoints/ncode-state.xml</operator>

    </endpoint>

    <!-- Mutable fileset to save the nCoDE programs          -->

    <fileset>

      <regex>res:/resources/endpoints/.*</regex>

      <mutable>true</mutable>

      <poll>100</poll>

      <private/>

    </fileset>

    <!-- Needed for the nCoDERuntime prototype               -->

    <import>

      <uri>urn:org:netkernel:lang:ncode</uri>

      <private/>

    </import>

    

    <!-- Underneath here come the imports of the tools you   -->

    <!-- want to use.                                        -->

  </rootspace>

</module>

And that concludes this blogentry. If you want to learn more about nCoDE, there's documentation available in the NetKernel instance and the whole of Chapter 8 of the book is dedicated to it.