• MY_Session – A custom version of the CodeIgniter session library. This incorporates some fixes and improvements contributed by users on the CodeIgniter forum as well as some of my own ideas. Specifically the following:
  • A new configuration value – sess_persistent_cookie – is used to set whether cookies should persist across browser instances. This value can overridden on a per-session basis.
  • The session id can be updated at any point (even if the normal update interval hasn’t elapsed). This is recommended just after a user has logged in to avoid session-hijacking attacks.
  • Session expiration handling is improved. Setting expiry time to 0 will result in a non-expiring cookie (unless of course sess_persistent_cookie is set to FALSE).

This module depends on uc_stock 6.x-2.0+.

Drupal.org project page: link.

Github: link

License: GPL 2.

Current version: 6.x-1.0

Skip to: Installation Usage e

Installation

1. Download the latest version from the Drupal.org project page.
2. Unzip it into your sites/all/modules folder such that the module is at sites/all/modules/uc_bulk_stock_updater/....
3. Goto Site building > Modules > List and enable the Bulk Stock Updater module.
4. All done!

Usage

Once the module is enabled ensure you assign the bulk update stock permission to the appropriate user roles.

Goto Store administration > Stock > Bulk update and you will see a paged list of your products ordered by SKU. At the bottom is a link to view all the products on one page if you wish.

You will notice that the stock value for each product is displayed as an input field. Once you change the value in an input field it will be automatically submitted to the server via AJAX (you will see a progress indicator while this happens). If any errors occur the field value will be reset to what it was originally and an error message will be shown.

You can refer to the CSS file in the module’s folder to find out which styles need to be overridden in order to customize the look and feel.

So I wrote a cheap and nasty PHP script which stored the input in a local CSV file. Once the page loaded it would fetch the existing story data via AJAX (using jQuery) and the user would submit new data using a simple form at the bottom. We had a quick play around with this in the office and it was quite amusing. Because the AJAX fetch would run only once every 5 seconds you’d often finish inputting your 3 words to continue the story only to find that someone else had already beaten you to the punch. So the story ended up not making much sense but I think this actually made it funnier, especially given how quickly everything disintegrated into a discussion about pooh and other lowbrow stuff (tells you a lot about us, doesn’t it?).

After this successful “pre-alpha” in the office we decided to build it properly and make it public – mythreewords.com. Here’s how it works. The active story is always at the top. You can enter 3 words at a time, no more no less. And you can’t have URLs or HTML tags in your words. If you end your last word with a ?, . or ! then you complete the active story and it gets shifted below. A new story is begun with the first 3 words auto-generated by the system.

Completed stories have a button next to them which allows you to tweet them through your Twitter account (if you have one). Since tweets have a 140-character limit we truncate the story if necessary and insert a link back to the full version of the story using a short alias domain (m3w.in):

For the public release I rewrote the original codebase using Kohana 3 for the framework and MySQL for storing the data. I investigated AJAX Comet techniques and settled on using long-polling to simulate data push from the server to the client. This means is that as soon as someone else adds their three words all the other clients are almost immediately updated.

To further increase performance the system does not write anything to the database until the active story has been completed. Until that point everything is stored in a memcached instance running on the same machine. Once the active story is completed by a user it gets marked as such and a new active story gets created and cached. A cron script running every 60 seconds then processes all completed stories by inserting them into the database (and subsequently removing them from memcached).

I also had a go at providing notification when other users are typing. How it works: when the page loads it generates a unique id. When the user starts entering words into the input field an AJAX call is made to the server which this unique id. The server then stores all such submitted unique ids together in a an array in memcached. Changes to this array are pushed to all clients (using the Comet technique mentioned above) who then indicate how many users are currently typing:

Only upto 5 unique ids are stored on the server so that the array search complexity never exceeds O(5) (clients show this as 4+ typing). The array data is automatically cleared after 5 seconds of no change to avoid stale data. And clients don’t inform the server that they’re typing more frequently than once every 5 seconds.

If you want to understand the internal workings of the site better use Firebug (or your preferred tool) to eavesdrop on the AJAX calls.

So that’s the sum total of the site for now. Implementing it was a lot of fun. I hope you enjoy it too

MyThreeWords.com.

Fast forward many hours of coding and here is a simple demo (click the image to launch it):

The demo consists of 3 separate scenes. You can switch between by simply clicking in the window. Further mouse and keyboard controls are listed in the demo window itself. Debug output from the demo is viewable in the Java applet console

Architecture

I’ve tried to use good object-oriented programming as much as possible throughout. For example, each scene is represented as a hierarchical scenegraph and a Visitor model to perform rendering. The renderer itself is obtained from a Factory which allows for different types of renderers (OpenGL, DirectX, Software, etc.). As is standard practice with scenegraphs, a matrix stack is used to allow for model-level transformations independent to world-level transformations.

At the moment the only available renderer is software-based. But the architecture allows for OpenGL or DirectX-based rendering to be added in future. I use the Graphics2D.drawLine() API call in Java to render the pixels. Everything else (e.g. z-buffer) is manually implemented. The engine supports wireframe-mode rendering and backface culling. There is a single source light in the scene whose direction can be modified (in the demo it’s always pointing forwards from the camera). The rasterizer currently uses flat shading – next would be to add Gouraud and Phong, not to mention texturing.

3D rotation on world objects are performed using matrix multiplication. The camera is rotated using Quaternions since this made it simpler to use the UVN camera model. The third scene in the demo above is animated; this is accomplished using a simple timer thread using which any number of events can be scheduled for execution at given time intervals.

Performance

When programming in Java it’s easy to not worry about memory usage and allocations since the garbage collector handles the freeing up of memory. But for graphics engines every allocation or garbage collection run will impact performance. So from the outset I’ve tried to pre-allocate memory where possible, by constructing temporary vectors and matrices for use during calculations later on. Thus, the vast majority of the matrix and vector multiplication which take place in the render loop don’t allocate any new memory when doing so.

However, when I finally started rendering things I found that the performance bottleneck was actually the rasterizer. The more polygons (triangles) that needed to be drawn and the larger they appeared on screen, the longer each frame took to render. Perhaps I can improve this by optimising the polygon order (e.g. render from farthest to nearest) and improving the raster algorithms. Eventually I want to switch to using OpenGL as the rendering system but since I’ve come so far with the software renderer it would be nice to see if I can improve it a bit more first.

Download

The engine code is licensed under the LGPL and is available here.

• Hierarchical scenegraph including Mesh, Rotation, Translation and Light nodes.
• Triangle primitives with helpers for building cubes
• UVN camera with orthographic or perspective projection
• Timer scheduler for animating the scene.
• Rendering system abstraction
  • Renderers follow Visitor design pattern
• Software-based renderer
  • Wireframe/flat shading
  • Simple directional light
  • Backface culling
  • Pixel-level z-buffer
• Customizable interaction (i.e. user input) handlers

More information can be found in the original blog posting.

Demo

Launch demo (requires Java 1.5+)

Download

The source code for this engine is licensed under the LGPL 3.

Download source code.

Build instructions can be found in README.txt in the download package.

Also, I’ve put up a few Java classes I wrote a while back as a small library called Common-Utils. Included within are the following:

• ArrayUtils – Utility methods to fill an array with a given value or check if it contains a given value.
• DynamicArray – A resizable “static” array for when you don’t quite need the full flexibility of ArrayList.
• NonMutableIterator – Wraps around a normal Iterator and disables use of the remove method.

• ArrayUtils – Utility methods to fill an array with a given value or check if it contains a given value.
• NonMutableIterator – Wraps around a normal Iterator and disables use of the remove method.
• JAbstractApplet and JAppletSimulator – Classes for running applets as standalone applications.

License: LGPL 3.

Current version: 0.1

Download

Download source code and documentation.

Changelog

• 0.1 (Jan 15, 2010)
  • Initial release.

Grab it now from here or the WordPress plugin repository.

For instance, Russia recently announced that it would cut its greenhouse gas emissions by 25% on 1990 levels. In other words in by the year 2020 Russia’s yearly emissions (measured in tonnes of CO2) will be at 75% of what they were in 1990. This sounds good on paper since we generally assume that yearly emissions have increased since 1990 for all countries. But the collapse of the Soviet economy in 1991 led to massive fall in emissions, meaning that a 25% cut on Russia’s 1990 emissions levels actually equates to a 25.6% increase on Russia’s 2007 emissions levels. In other words, they’re allowing themselves to increase their pollution levels!

In order to help other people make sense of the emission targets being pledged by the various countries, over the last couple of days I’ve helped to develop a “target converter” for Sandbag, a non-profit climate change campaign.

It takes an emissions target and a baseline year for a given country and then calculates what the equivalent percentages are for all the other years for which emissions data is available for that country (data source is UNFCCC). So for instance, for Russia’s target of a 25% reduction on 1990 levels we get:

You can find the target converter at http://sandbag.org.uk/targetconverter.

Some users were reporting that the tag editing interface was unusable when used in conjunction with certain other plugins (e.g. the multi-level navigation plugin). Other users were having trouble getting the plugin to work in the latest version of WordPress (2.8.6). This release (hopefully) fixes these issues.

Grab it now from here or the WordPress plugin repository.

Update (Nov20): The plugin has been updated to 0.3.3 now. This fixes a callback bug which was preventing the plugin from initialising on certain installations.