2011/12/30

2012

Since the bow can not always stand bent (according to one Miguel de Cervantes, although I bet he said it in Spanish), I will not bother you with technical stuff at this time of the year.

I can guarantee that the world will not end on December 21th 2012 (nor did the Mayas predict anything like that).
I can guarantee that ROC will pass the 2012 test with flying colours.

And the rest you have to see for yourself !

Best wishes for 2012,
Tom

2011/12/23

Don't know much about technology ...

The ROC paradigm/methodology/<buzzword of the day>/... will enable you to develop both better and faster. It does not take away the need for you to know technologies.

I learned this the hard way and it made my learning curve steeper than it should have been. Not only that, but I spectacularly failed training my first pupil because of the same reason ! So in the remainder of this post I'll discuss the requirements to start ROC'ing with NetKernel.

Base

  1. IT fundamentals.
  2. Programming fundamentals.
  3. XML fundamentals.
  4. Dynamic scripting language.
    Pick one that is supported in NetKernel. If you don't have a preference, Groovy is a good choice.
  5. XSLT.
  6. ROC Fundamentals.
  7. XRL.
  8. DPML.
    This is an optional point. I still advise it.
Note that only 6, 7 and 8 are NetKernel specific.

Put together that would be a three year curriculum for a secondary school, a two year curriculum for a bachelor, a three to six month (depends on prior knowledge) curriculum for a fresh IT professional.

Afterwards you'll be able to think ROC and work independently on back end solutions.

Adding the front end

  1. HTML.
  2. CSS.
  3. Javascript.
    This is also a good time to choose and learn a javascript framework (jquery, qooxdoo, extjs, ...). Serving it from within NetKernel is a very good ROC exercise.
Add six months for the secondary school, three months for the bachelors and IT professionals.

Afterwards you'll be able to work independently on end-to-end solutions.

Advanced
  1. ROC Advanced.
  2. Java.
    NetKernel runs in a JVM. And even though it is true that you can do the job with a dynamic scripting language, for creating core tools or modifications to the existing tools you need Java.
The timeline for this can vary wildly.

Afterwards you'll be able to create core tools and integrate new technologies into the ROC abstraction.

Extra
  1. Databases
  2. Queing systems
  3. ... 
Know at least the basics of the technologies you are using. Even (maybe especially) when you can use them as black boxes.

Practice
As the punchline goes about the man asking about how to get to Carnegie hall ... practice my man, practice ...


The above may look like an enormous task, but while I was writing it I noticed the similarity with my own training to become a mainframe developer (20 years ago now). It took three months to become a productive batch programmer, another three to become independent (and write CICS front ends) and only with lots of practice did I become proficient.

Everything worth knowing takes time and effort and is (no, I'm not going to write looks, I'm not a salesman) hard. ROC and NetKernel are worth knowing !

2011/12/15

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.

2011/12/08

Colon Eighty Eighty

Imagine ... you are showing off this killer NetKernel app (when did we actually stop writing the word application in full ?) that shows ROC in all its intricate beauty to <enter whomever you want to impress here>.

Instead of eyes glazing over you get this question : why is there colon eighty eighty at the end of your URL ? Not quite the reaction you had hoped for.

And maybe you don't know the answer either. This post will answer the question as well as show a couple of ways to eliminate the need for colon eighty eigthy.


Lets start at the beginning. Our server gets questions in the form of http, ftp, ssh, telnet, ... Each of these questions it expects at a port in the Well Known Port range (1 - 1023, managed by IANA). For example, http is expected at port 80 and if your server wants to handle http it will have a daemon/service listening at port 80 for incoming requests.

As an extra security measure on *nix systems only the superuser (root) can start a daemon that listens at a Well Known Port (also known as Privileged Port for that very reason). Yes, that is a security measure, the idea being that if the daemon is started by root, it must be the real deal.

There is however a flip side to that coin. If a malicious request succeeds in breaking through the daemon (code injection, ...) to the underlying system, it does so as root.

That is the reason that - for example - Oracle is running as user oracle and expecting SQL requests at port 1521. You may still destroy the database, but the system will - probably - survive.

While you can run NetKernel as a superuser you are advised not to do so. For the build-in Jetty webserver this is even the default (as an afterthought running as a superuser has been added, but it is still not the default). So NetKernel's http handlers are not supposed to listen at port 80. They listen on port 1060 (Backend HTTPFulcrum) and on port 8080 (Frontend HTTPFulcrum) instead.

When unspecified in an URL, the Well Known Port for the protocol is knocked at. So we can specify http://www.google.com instead of http://www.google.com:80. To reach the Frontend HTTPFulcrum however, you have to specify colon eighty eighty.


So far for the why. And I can hear you say ... fine, fine, but I just failed to impress <enter whomever you wanted to impress here>. To hell with all the good reasons, I want to get rid of that
extension. You can.

There are two main approaches :
  • Let the firewall route inbound requests for port 80 to another port.
  • Let the daemon that listens at the Well Known Port route requests to another port.
The first approach speaks for itself, the second approach sounds a bit weird, but think about it, how many cloud servers come with the webserver on port 80 already preconfigured. Leave it there and let it do the heavy lifting for you !

Here's an iptables entry that can serve for the first approach :
iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080

Here's an apache vhost entry that can serve for the second approach :
<VirtualHost *:80>
  RewriteEngine On
  RewriteRule ^/(.*) http://localhost:8080/$1 [P]
</VirtualHost>


As you can see solutions exist, next time you can focus on being impressive !

2011/12/01

Templates

This is a blog about the practical stuff that softens the learning curve of NetKernel. Now, I've been working with NetKernel since 2006, so my view of the learning curve might be somewhat skewed. Therefore your input on what I should discuss in this blog is welcomed at practical<dot>netkernel<at>gmail<dot>com.

This week I want to take a look at every developers' best friends (if, like me, your answer to the statement : Get a life ! is : Great, where can I download one of those ?) ... templates.

I don't like flame wars (or wars of any kind for that matter), so whatever your favorite development environment is, is fine by me. I use Scite, Eclipse, IntelliJ, NetBeans, Vim, Emacs, Textmate or whatever is available on the system I happen to be working on.

Templates feature in all of them. NetKernel is XML based (= lots of tags) and mostly - nCoDE is an exception - does not (and has no intention to) shield you from the basic layer ... the files.

So you need templates.

Name : nk:importhook
Description : NetKernel SimpleDynamicImportHook.xml Basics
Content :

<?xml version="1.0" encoding="${encoding}"?>
<connection>
  <type>[HTTPFulcrum]</type>
</connection>

Name : nk:books
Description : NetKernel Books.xml Basics
Content :

<?xml version="1.0" encoding="${encoding}"?>
<books>
  <book>
    <id>book:[moduleuri]</id>
    <title>[Module Name]</title>
    <desc>[modulename] documentation</desc>
    <toc>
      <item id="doc:[endpointid]"/>
    </toc>
  </book>
</books>

Name : nk:docs
Description : NetKernel Docs.xml Basics
Content :
<?xml version="1.0" encoding="${encoding}"?>
<docs>
  <doc>
    <id>doc:[endpointid]</id>
    <title>[Endpoint Name]</title>
    <desc>[endpointname] documentation</desc>
    <uri>res:/resources/documentation/doc_[endpointname].txt</uri>
  </doc>
</docs>

Name : nk:palette
Description : NetKernel CDEPalette.xml Basics
Content : 

<?xml version="1.0" encoding="${encoding}"?>
<palette>
  <group name="[groupname]" id="[groupid]" order="[100]"/>
  <endpoint id="[endpointid]" name="[endpointname]" group="[groupid]"/>
</palette>


Name : nk:tests
Description : NetKernel Tests.xml Basics
Content : 

<?xml version="1.0" encoding="${encoding}"?>
<tests>
  <test>
    <id>test:[moduleuri]</id>
    <name>[Module Name]</name>
    <desc>[modulename] unittest</desc>
    <uri>res:/resources/unittest/testlist.xml</uri>
  </test>
</tests>

There you have them. Note that my template system allows for the variable ${encoding}. Yours may or may not, replace with UTF-8 in the latter case. Anything between [square brackets] needs to be replaced or revised.


With those the work in /etc/system is as good as done. And so is the post for this week. Enjoy !