JOB has been updated to version 1.1. The changes are minimal and largely to resolve a couple of minor issues;
- The "self." prefix has been removed as it is both unnecessary and mildly irritating (the much touted performance improvements given by the self. prefix are largely illusory).
- Classes can now be nested in classes. There were never any good reasons for this limitation except that it seemed wrong to allow it. Now it seems right - what's so rare about repeatable elements with repeatable elements in them?
In the near future JOB will be seeing a major overhaul, turning it on its head. The main aim is to reduce the need for direct DOM scanning to find JOBjects, and instead to scan the Javascript objects first. This should see a bit of a performance improvement, and also make it easier to indulge in further shenanigans eg. asynchronous JOB HTML loading. Watch this space.
Friday, 30 November 2007
LBI Useful launched at Minibar
On the 16th November, we 'officially' launched LBI Useful at the latest Minibar event.
Minibar is an East London social evening where people "meet and chat about p2p, Creative Commons, web applications, social networking and general Web 2. (3.0) mayhem & fandango". LBi provided enough free red stripe to keep the crowds amused for at least half an hour, and a clutch of individuals from startups gave presentations showing their wares.
more here: http://barcamp.org/minibar
Having shown off the joys of Useful, the LBi team (myself, compere JMarks and projector technician JGarner) retired to the bar and drank the night away. For those who couldn't make it, here's a few of the (decidedly lo-fi) slides:
Minibar is an East London social evening where people "meet and chat about p2p, Creative Commons, web applications, social networking and general Web 2. (3.0) mayhem & fandango". LBi provided enough free red stripe to keep the crowds amused for at least half an hour, and a clutch of individuals from startups gave presentations showing their wares.
more here: http://barcamp.org/minibar
Having shown off the joys of Useful, the LBi team (myself, compere JMarks and projector technician JGarner) retired to the bar and drank the night away. For those who couldn't make it, here's a few of the (decidedly lo-fi) slides:
Tuesday, 16 October 2007
Making your job easier with JOB
JOB, in this instance, being Javascript Object Binding. What does it do? In a nutshell, it automatically binds Javascript objects to DOM elements. What's it for? Making code simpler and easier to maintain.
The problem with DOM manipulation
Most interesting things you can do with javascript rely on DOM manipulation. But it's a painful business - hunting down elements with getElementByID, creating nodes, appending children, and so on. Even with popular JS libraries it's no easier; the syntax is different, but you can still end up with reams of code to create and append new DOM nodes.
It's also messy. It breaks any clean separation of UI (HTML) and behaviour (JS). Writing HTML in JS is a pain to do, difficult to test and even worse to modify. So why not keep the HTML where it belongs - in the HTML - and use the Javascript for the behaviour. This is what JOB is for.
How do you use it?
Simple. If you are creating a HTML 'control' which has javascript behaviours, you identify the HTML elements with an ID that matches the name of the Javascript object. Any "member" elements of the HTML are similarly identified, and references to these become members of the Javascript object. This can be done with single instance objects ("controls") and multiple instance objects which are created on the fly (instances of "classes").
The documentation isn't ready yet, but there is a simple demo in the SVN repository - showing what JOB can do for you.
http://javascript-object-binding.googlecode.com/svn/trunk/JOB/demos/simple%20example/demo.html
The problem with DOM manipulation
Most interesting things you can do with javascript rely on DOM manipulation. But it's a painful business - hunting down elements with getElementByID, creating nodes, appending children, and so on. Even with popular JS libraries it's no easier; the syntax is different, but you can still end up with reams of code to create and append new DOM nodes.
It's also messy. It breaks any clean separation of UI (HTML) and behaviour (JS). Writing HTML in JS is a pain to do, difficult to test and even worse to modify. So why not keep the HTML where it belongs - in the HTML - and use the Javascript for the behaviour. This is what JOB is for.
How do you use it?
Simple. If you are creating a HTML 'control' which has javascript behaviours, you identify the HTML elements with an ID that matches the name of the Javascript object. Any "member" elements of the HTML are similarly identified, and references to these become members of the Javascript object. This can be done with single instance objects ("controls") and multiple instance objects which are created on the fly (instances of "classes").
The documentation isn't ready yet, but there is a simple demo in the SVN repository - showing what JOB can do for you.
http://javascript-object-binding.googlecode.com/svn/trunk/JOB/demos/simple%20example/demo.html
Wednesday, 26 September 2007
LBi Logger
Here in LBi London, as you can see, we are refining our tools to improve our productivity on create, debug and handover our software. An area I felt it could be improved was the debugging.
There are different interesting solutions to debug projects, someone really interesting. Xray, for instance, permits to browse your entire movie and check all the properties of the elements. It contains inside also a simple logger. I've been used to use traces to debug applications, probably also because I find disturbing having to browse all the application structure to get to an item. I believe that logging is still a good way to debug or test applications but that it is an area where the solutions available are not really satisfying or that could be easily improved. Our main IDE is Eclipse, and the two loggers I tested are NTail and LogWatcher. They are quite popular and they can satisfy most of the need when reading logs, but Flash applications, for instance, because of their complexity (they can involve data management, animations, user interactions) can generate quite big and messy logs. My goal was thus to provide a logger to easily organize visually the logs, this can happen adding runtime setting setup (to define log styles to particular logs) and adding some interactivity, like for instance the filtering of Alessandro's FlashTracer.
LBi Logger is a "Highly customizable and interactive Eclipse plug-in to view log files".
The project is still on its early stages, I'm using it daily and since I would like to keep it simple, also for performance reasons, I want to be sure about a feature's need before adding it.
If it sounds interesting to you please have a look at the project page and if you think it can be improved, please tell us your ideas.
There are different interesting solutions to debug projects, someone really interesting. Xray, for instance, permits to browse your entire movie and check all the properties of the elements. It contains inside also a simple logger. I've been used to use traces to debug applications, probably also because I find disturbing having to browse all the application structure to get to an item. I believe that logging is still a good way to debug or test applications but that it is an area where the solutions available are not really satisfying or that could be easily improved. Our main IDE is Eclipse, and the two loggers I tested are NTail and LogWatcher. They are quite popular and they can satisfy most of the need when reading logs, but Flash applications, for instance, because of their complexity (they can involve data management, animations, user interactions) can generate quite big and messy logs. My goal was thus to provide a logger to easily organize visually the logs, this can happen adding runtime setting setup (to define log styles to particular logs) and adding some interactivity, like for instance the filtering of Alessandro's FlashTracer.
LBi Logger is a "Highly customizable and interactive Eclipse plug-in to view log files".
The project is still on its early stages, I'm using it daily and since I would like to keep it simple, also for performance reasons, I want to be sure about a feature's need before adding it.
If it sounds interesting to you please have a look at the project page and if you think it can be improved, please tell us your ideas.
Tuesday, 25 September 2007
Introduction to LBi Useful
We have started off with three projects hosted on Google Code. I will introduce the AS2 libraries here and let Marcus and Christian introduce their projects when they get a moment.
ActionScript 2 Libraries
The ActionScript 2 libraries are modified from libraries that we originally started developing about two years ago when we started working entirely outside the Flash IDE and using Eclipse and FDT with SWFMill and MTASC instead. This was a drastic improvement to our Flash development workflow and is essential for working in teams, as well as providing a solid backbone on which to apply best practices and design patterns from Java and Ruby. Internally we have been using the legacy versions of these libraries (in a com.framfab package rather than the neater and happier com.lbi package :)) but I have refactored out the best bits into the libraries you will find here. I have put as much as possible under test (you can run the unit tests by entering 'rake test' from the project folder - you'll need ruby and rake installed first).
Please note that there may be some bugs in the newly refactored code that will be ironed out over the next few weeks as we officially move over internally to the new codebase.
There are a few basic usage examples for the animation package, and I will publish an introduction to setting up a good environment for those who don't have experience working with MTASC and third-party libraries. In the meantime, here are some useful places to go to get started and get advice:
ActionScript 2 Libraries
The ActionScript 2 libraries are modified from libraries that we originally started developing about two years ago when we started working entirely outside the Flash IDE and using Eclipse and FDT with SWFMill and MTASC instead. This was a drastic improvement to our Flash development workflow and is essential for working in teams, as well as providing a solid backbone on which to apply best practices and design patterns from Java and Ruby. Internally we have been using the legacy versions of these libraries (in a com.framfab package rather than the neater and happier com.lbi package :)) but I have refactored out the best bits into the libraries you will find here. I have put as much as possible under test (you can run the unit tests by entering 'rake test' from the project folder - you'll need ruby and rake installed first).
Please note that there may be some bugs in the newly refactored code that will be ironed out over the next few weeks as we officially move over internally to the new codebase.
There are a few basic usage examples for the animation package, and I will publish an introduction to setting up a good environment for those who don't have experience working with MTASC and third-party libraries. In the meantime, here are some useful places to go to get started and get advice:
- osflash.org/ - hub of the open source Flash community
- www.asserttrue.com - Luke Bayes' blog (co-developer of the asunit library and Sprouts)
- There are plenty of other people I should mention, but I am short of time when it comes to hunting down links...
Subscribe to:
Comments (Atom)