How Time Flies When You Are Having Fun!

Wow!

There is an old saying that states:

Life is what happens when you have other plans.

Definitely holds true for me.

Since I lasted posted to this blog lots of things have happened with the enCore Learning Environment.
Some good some bad.

The Bad is that the enCore Consortium folded. Partly as a result of the unfortunate passing of one of the key movers and shakers, Barbara McManus, and difficulty in getting access to the old domain to maintain the mail list.

The Good is that we now have a JAVA free client for enCore V4 MOOs that is a drop in replacement for the JAVA based Mootcan applet. Jack Lewis at Western Michigan University created and supports the client at Literary Worlds and they have kindly made the client available to all enCore systems.

So where to from here?

I know there is still a lot of interest in enCore, more so now that we no longer have to fight with JAVA restriction policies at many educational institutions.

I know that those of us who have used these systems over the years have collected a fair amount of information tricks and tools and new users and builders could benefit mightily from access to that.

Community support via the old encore mail list was excellent and really helped those of us struggling with making enCore perform all the tricks our imaginations wanted it to.

Thus I have created a new Google Group to become the hub for support of this system.
You can access the Group here: https://groups.google.com/d/forum/encore-learning-environment

This group is not currently open to the public but feel free to request membership and I'll add you.

The Barn is hosted still at Literary Worlds here: http://brn227.brown.wmich.edu/Barn/news.htm

Watch the group and this blog for more interesting MOO news over the coming months.

Thanks for reading.
KJ


 

SOLID design principles

My apologies for the lack of posts.
I've been playing in the Steampunk World lately.
Found this article at TechRepublic and it occurs to me that it applies to MOO code pretty well.
Enjoy
KJ

SOLID design principles improve object-oriented development 
By Justin James October 19, 2012, 1:45 PM PDT

 SRP is the idea that objects should do one thing and one thing only. It is tempting to think this means that a class should represent an entire piece of business logic or data, but that is not quite correct. The idea is not to group all of the functionality that is related together, but all of the functionality that achieves the same goal together.
For example, if you have a class representing printer, putting all of the printer operations (getting toner levels, printing a page, getting an error message) in the printer class may make sense, but it is not really the right approach. Instead, you would put all of the functions related to printing in the same class, and all of the functions for reporting status in a class, and so on. You break the work down into small, digestible chunks. The payoff here is that you can make changes to a select piece of functionality without possibly affecting a ton of other items.

O - Open/closed principle (OCP)

This very simple idea is that classes can allow themselves to be extended but not modified. The source code for the original class should only be modified if a bug is found. The reason behind this is that changing the code will mean that everything depending upon it will need to be retested as well.

L - Liskov substitution principle (LSP)

LSP states that the subclass of an object can be used in place of the superclass without changing things like what the program does, whether it compiles, etc. For example, if class “elephant” is a subtype of class “animal,” then you should be able to use “elephant” where you use “animal,” and the “walk” method will still “walk” (even though the implementation may be different), the “numberOfLegs” property will still return the number of legs (though again, it may be a different number from the base class), the “eat” method will not throw any exceptions that it would not throw in the “animal” class, and so on. It is much easier to make changes and test when you follow LSP.

I - Interface segregation principle (ISP)

ISP dictates that interfaces need to have as little functionality in them as possible. This allows the consumer to only deal with the functionality they are concerned with, which reduces testing needs and the impact of changes to the system.

D - Dependency inversion principle (DIP)

With DIP, high-level objects are abstracted away from low-level objects. It is normal to think of the low-level objects as just being smaller pieces of a bigger one. For example, let’s say that you want to query a database and fill a data set. The temptation is to pass in the database connection information to the data set and let it make the connection. Instead, you pass in a connection that is already configured, and in this way, the database can change without needing to retest the entire data set object.
J.Ja

Inventing on Principle

Thanks to Paul Rayner at Muddle for pointing me to this fantastic presentation.
Enjoy
KJ



Bret Victor - Inventing on Principle from CUSEC on Vimeo.

The Machine

Found this comment in a thread on the PiLuD: free talks on Programming Language Design Google group.

https://groups.google.com/group/pilud/about?hl=en

"OOP is best used to model the program like a big machine - gears, stacks, queues, sensors and actuators, signals and data. If you do this, then a lot of problems are cleanly avoided."

David Barbour   Very apropos to MOO code programming.

I'm in print!

I just received my copy of  Teaching Literature in Virtual Worlds 
This very interesting collection of articles, edited by Dr. Allen Webb of Western Michigan University, includes a chapter by me "On the Building of Worlds". 
Very cool, if I do say so myself.
The articles discuss many of the Worlds created at Literary Worlds, which is hosted at Western Michigan here: http://brn227.brown.wmich.edu:7000/
Ciao
KJ

New AJAX updating Room files available at the Barn

I have put the files for the new room up at the Barn.
You can get the zip file here:
http://www.encore-consortium.org/Barn/files/objects/EnCore/rooms_with_ajax.zip
The zip has two files one, ahah2.js, is the javascript that handles the AJAX communications.  This file should be put in a directory called edit_area in the root of your encore directory.  The other file is an @dump of a room with the  auto updating capabilities for the objects list.
This room has a property called js_base_url which is used if you cannot store the ahah2.js file in the encore directory. As long as the directory you have access to is on the same server as the moo it will work.
It is currently set to my directory at Literary Worlds so make sure you change it to your directory or set it to 0.
Let me know if you have questions or problems and also how it works for you if you try it out.
If you just want to see this room in action you can check out the test room at Literary Worlds by logging in as a guest at: http://brn227.brown.wmich.edu:7000/
Once logged in @go to #5446
There is a box there you can pick up and drop to see the update in action.
Enjoy
Ciao
KJ

New Experiment: Room contents display enCore V4

Continuing along on my experimentation with the user interface in enCore v4, it occurred to me that one of the issues I've had is how the room display is static, relative to the text side.  Where this can be an issue is with a busy class all logged in at once.  The text side is flying with all the comings, goings and chatting amonst the class members, while at the same time the room display, with the list of contents and exits, is frozen. Only a look command or click on the look icon will refresh it.

Several times I have entered a room with people chatting and they did not notice me entering because the text message scrolled past, lost in the chatter, and at the same time the list of the rooms contents didn't change either. They were quite surprised when I started talking!

How to get around that?

Here is my latest experiment... AJAX, Asynchronous Javascript and XML. This is the underpinnings of the infamous WEB 2.0 jazz we've been hearing about for years now.  I found a small javascript file called AHAH, Asynchronous HTML and HTTP, which is a simple implementation of AJAX that only deals with html rather than XML.  You can read about it here: http://microformats.org/wiki/rest/ahah

What this javascript file does is allow us to update PARTS of a webpage on demand or automatically without reloading the whole page. For my experiment I had it update the contents display of the room every second.  The javascript calls a verb on the room that sends back the current list of objects in the room.  The code then checks to see if the contents have changed since the last time and if so it updates the list in the display.

Very cool.

I had to change the SPANs with classes to DIVs with ids, which needed a bit of CSS gigerypokery to line up, but that was it.

The javascript file is very small so does not add any delay to the page when first loaded.

A pleasant surprise was the way the code was able to access the verb on the room, it did not need any path info at all, it knew the host it was being called from and simply returned the verb output without complaint. (Not sure why that works frankly)

This tool should have great use for interactive objects, since pieces of the display can change without having to refresh the whole lot.  Think of communication devices, games, viewports, graphics displays etc. According to the notes with the javascript there can be multiple instances of the updaters on the same page.

I will try to put the code into a package for the Barn in a bit.