redredred

A new release of the week calendar plugin has been published with a number of enhancements and bug fixes. Part of this release included an internal refactoring to base the calendar off the jQuery-UI widget framework. I think this has helped to clean the code up and certainly simplified things. I think there’s still more that can be done in this area and  I expect to refine the internals over the next couple of releases. If anyone’s interested in a run down on the jQuery-UI widget structure, I found this to be a very helpful article.

This release contains the following improvements:

• Added better layout support for overlapping of events (there are still some improvements to be made in this area but it’s a lot better than it was)
• Added ability to supply formatters for dates and times. You can also define your own day, month name arrays to be used by the date and time formatters.
• Added improved demo with creation / editing of events using jquery ui.
• All demos are now served directly out of google code svn
• Added option to only display hours defined in the ‘businessHours’ config option.
• Migrated code-base to extend jquery-ui widget.
• Improved inline method documentation.
• Added ‘readonly’ config option to flag the entire calendar as readonly, preventing creation, dragging, dropping and resizing of events.
• Added ability to configure day, month names for better i18n support
• Fixed bug with IE7 resizing once an event gets to 2 timeslots or smaller
• Added public method for returning an array of valid timeslots  for a given date based on the calendar options. Useful for populating select fields with start and end times.

Thanks to everyone who’s helped submitting bug reports, feature requests. I attempted to get the most pressing ones out in this release and hope to follow it up with another release in the next week or so.

After being inspired by the recent fullcalendar (month based) plugin by Adam Shaw, I decided to port a weekly calendar i’ve been working on into a proper jquery plugin. Until a couple of days ago it was practically impossible to use this calendar functionality outside of it’s host application but now it should be simple to integrate it into any jquery-ui based application.

I made a conscious decision to base the week calendar api off the fullcalendar plugin, using the same event names where it makes sense and most importantly to use an identical data format. The idea being that the two plugins could co-exist utilising an identical data source and similar programming style.

You can see the full details of the plugin on the project page but to summarise the feature set:

• Display of calendar events within a weekly grid
• Calendar events can be supplied as an array, url or function returning json
• Calendar events can be dragged, dropped and resized
• Lots of callbacks for customizing the way events are rendered plus callbacks for drag, drop, resize, mouseover, click etc
• Automatically scrolls to current time
• Extend the core calendar event data structure with your own data
• Compatible with FullCalendar data sources with very similar events

jquery week calendar

At this stage there is only a basic demo in place but when time permits i’ll add a series of demos that help to show how you might extend it to fit your application requirements such as:

• Modification of rendered events based on custom data / logic
• Using jquery ui dialog for creating and editing events
• Using some of the other events to provide a better experience

This plugin is an early release and i’d expect follow up revisions to be coming out very soon. Any feedback, bug reports etc would be welcome.

Check out the full documentation and demo here

Evolve The Future is a “proof of concept” evolution simulator inspired by Thomas Ray’s Tierra application, which he always promised would be a networked environment for digital wildlife. I haven’t created that, but hopefully this is a step in that direction. Little animals run around, reproduce and eat each other. Each animal is written in a custom assembly-code language running on a number of virtual machines. and all of this is written in Javascript.

I wrote this application a couple of years ago, and kind of forgot about it. But now I have dusted it off, ported it to the Google App Engine and updated it a little bit here and there. I am continuing to work on it, new features (like the ability to look around) will be added soon.

Because javascript isn’t really fast enough (yet) to get enough generations through for evolution to be a useful force before my attention span wanes, this is possibly more of an environment to test your skills in writing in assembly code, and competing against the rest of the assembly-code writing world for the title of … (I’ll think of something   ).

The instruction set is not documented yet, and the animals structure is not documented yet (but both of these soon will be.

Each animal (process) has the following properties

• Memory: This is both readable and writable memory addresses starting from address 0 for each animal.
• Threads: Each animal can have multiple threads that communicate via it’s memory.
• CpuTime: Each animal is granted cputime by it’s parent when it is born, and after that is given cputime by the environment (like sunshine) each cycle.
• Position: Each animal has a current (xy) position in the grid
• Direction: Each animal is pointing in a certain direction (this is not currently shown in the display.

Each thread in each animal has the following properties:

• Stack: this is essentially current memory. Operations can put information on the stack, manipulate the top item on the stack, or pop information off the stack.
• Execution Pointer: Each thread is executing the same program, but potentially at a different address (different function) in memory.
• Read Pointer and Write Pointer: These are used for copying operations.
• Memory Pointer: This is used for writing operands only.
• Speed: An animal can choose to operate faster, multiple operations per second. This is expensive for the animal.
• SleepCycles: The thread can sleep for a set number of cycles. It will be woken when this counter reaches 0.

There have so far been two Ancestors created:

1. A simple non-mobile vegetable. This has a single thread that is devoted to reproduction.
   Once all 8 slots around the animal are full, it sleeps for a period and then checks again.
2. A simple mobile vegetable (is this a vegetable??). This has two threads: one is devoted to reproduction, the other moves in a straight line forever.
   When it reproduces, it turns right.

Animals reproduce by allocating memory at the end of their memory, then copying code into the new memory, and then dividing the new memory. This creates a new process.
The copying process has a 1 in 1000 random chance of failing to accurately copy the data requested. This results in the child not always being the same as the parent, and the chance for evolution is created.
Successful species (when a species has had enough animals with the same code, occurs at powers of 10) are sent to the server.
When the application starts it requests the 10 best animals from the server.
Things you can do:

• Click on an individual to see information about it on the “Process Details” tab
• View code of species on server to see what has evolved from the “Progenitors”
• Insert new species into the environment
• Examine the code of any running animal
• Send me patches!!

I really like closures in javascript. I really miss them when I am doing work in Java,  but sometimes when I use them I get a little messed up. Take the following example:

var i;
var objects=[1,2];
for (i=0;i < objects.length;i++) {
    var callback=function() {
        console.log(objects[i]);
    };
    doSomethingAsynchronous(callback);
}

Then you would might expect “1″ and “2″ to be logged when the callbacks come back. This is wrong, instead “2″ and “2″ are logged.

Due to the nature of closures, “i” is one of variables that fall into the scope of the closure by reference, not by value. So, when the value of “i” is updated in the for loop, the current (latest) value is then referenced later on by the closures. So the last item in the list is the item that is accessed.

The way to get around this is to modify the above code slightly, to make the item that you want an argument of a function, rather than accessed through closure scope. Eg:

var i;
var objects=[1,2];
function doSomethingAsynchronousAndLogIt(value) {
    var callback=function() {
        console.log(value);
    };
    doSomethingAsynchronous(callback)
}
for (i=0;i < objects.length;i++) {
    doSomethingAsynchronousAndLogIt(objects[i]);
}

I read an example chapter from Professional JavaScript for Web Developers, 2nd Edition: Chapter 18, “Advanced Techniques” last week and the discussion about currying functions finally made sense to me as in “oh, I see how I would use that”. If you want to understand it better look at the chapter linked above.

I have been using it for callback functions that require extra arguments from the local scope, it is a lot less wordy than the method that I had been using, and I think it better conveys the meaning of what I am trying to do.

Previously I would put the following:

var someValue;
$("#someElement").click(function(e){
    clickHandler(someValue);
});

And now I put this:

var someValue;
$("#someElement").click(clickHandler.curry(someValue));

I implemented this using a method that I placed on the Function.prototype. I think that is a nicer syntax than is recommended in the book.

Function.prototype.curry = function(){
      var args = Array.prototype.slice.call(arguments);
      var fn = this;
      return function(){
          var innerArgs = Array.prototype.slice.call(arguments);
          var finalArgs = args.concat(innerArgs);
          return fn.apply(null, finalArgs);
     };
}