Don’t get me wrong- Java is an incredible platform that is able to rock the socks off several other languages in and outside the browser… and certainly this is the case within the server world. However, the language has become rather convoluted over the years… compare the below chart of Java’s infrastructure versus Flash.

Image source: http://java.sun.com/products/hotspot/whitepaper.html

… now compare that with the Adobe scheme:

The moral of the story is K.I.S.S. also applies to higher-level programming languages: KEEP IT SIMPLE, STUPID!

Disclaimer: Some of the Java stuff illustrated in the diagram above are language inherit and not considered bloat… but most of the top and middle parts of the graph still applies. (not to mention 18+ mainstream abbreviations for just different core parts of the language *ick*)

This was a project I actually came up with to do while under a mass power outage in Detroit. I wanted to dabble on exactly what would be required to build a very simple social networking site. The direction I decided to head with was a group meetup system in which people could post what they had planned for a weekend and their friends would be automatically notified. The site hasn’t been worked on for over a year as it was only a development test. The site also includes marketing material for promoting the site as well as legal and press release pages. I decided on programming the site using pure PHP, XHTML, and good ol’ javascript. A few noteworthy accomplishments are image security (capcha), email validation, registration/login, user profile, event editing, and an ajax support form… all done by hand without a CMS package.
Link: http://www.jadbox.com/urgroups/

Tags: html, php

One of the most fascinating concepts I believe in programming is recursive logic (aside from reflection which I will be posting about soon, but I digress). Recursive operations are pieces of functionality that can execute themselves until a desired outcome is achieved. For example, what if you had a random number generator from 1-100 but did not want to include the number 17 if it was chosen? The function could check to see if the random number made was 17 and re-call itself to choose yet another number. Buiding on this idea, quicksorting is a programming methodology for reordering arrays based on value using recursive techniques. The concept partitions out pivots from an input array and recursively rearranged each partition until the entire array is sorted.

Tags: theory

What most users overlook from what I can see on forums and written articles is on the subject of unit testing functions that produce inherently non-concrete returns. For example, how would one go about unit testing a function that generates random numbers? It would be futile to try to only gaged a single outcome of the function as there is no way to anticipate what the return would be. However, this is where pattern matching comes into play. If the function is designed to generate numbers 1-100, run the function 100,000+ times and analyze the results. Did the function return a number higher or lower than 1-100? Did the function return a unique number way more times than randomly likely (for example, the number “20″ was returned 50,000 times)? Was a non-number or decimal number returned? Did each call to the function become progressively slower indicating a memory leak?
While this was a simple example, do not be discouraged of making a unit testing against something seemingly chaotic in design. Most things that seem random are usually rather predictable when viewed from a distance.

Link to Flash and Flex Unit Testing package: http://code.google.com/p/as3flexunitlib/

Tags: theory, unit testing

While working on a class recently, I have discovered an interesting design pattern where a singleton class is able to create instances of itself to perform RPC actions. For example, you could create a singleton called

LoadAndPlaySound.gi.play(
          url:String,
          onLoad:Function,
          onSoundPlayed:Function)

This class would then be able to create an instance of itself for handing the loading process for the sound, any manipulation, or other processes like handing storing and executing callback variables. You will need to lock down the singleton using a kind of enforcer technique so that only the singleton can replicate itself.

Disclaimer: I general do discourage singletons though as if used improperly (like stuffing every variable in an application into it for the point of easy access), it can cause more headaches than they relieve.

Tags: theory

After pondering the matter, an example API for such a function would be:

function subscribe():void {
   Pipes.get("chat pipe").subscribe(callBack);
   // See below for the callBack function that
   // gets executed when a message is sent
}
function callBack(message:*):void {
   // Maybe when creating a pipe, it would be
  //  possible to lock the message type?
}
function sendPipeMessage():void {
   // creates a new pipe is one doesn't exist
   var myPipe:PipeSender = Pipes.get("chat pipe");
   myPipe.send(someObject);
}
function joinOrSplitPipe():void {
   Pipes.get("chat pipe").join("ui pipe");
   Pipes.get("chat pipe").split("ui pipe");
}

So you might be thinking the same thing I was… why use pipes over event listeners??
Well, here are the pros and cons that I can see off-hand…

Pipes function the same as events except:

• Pipes can reach any level of the application… not just parents like events do when they bubble
• Pipes can be setup to enforce a one-way message system to an API or client class
• Pipes can be merged or split
• Pipes can be layered easily by using a new set of unique ids for the pipes. Events, on the other hand, bubble around the application globally climbing up parents which can cause major issues in an application that requires an easy reset, duplication, or tiered structure.

Link to the original article: Pipes theory pt. 1

Tags: theory

Joshua Ostrom posted an interesting article about using PureMVC Multicore with ‘Pipes’. After reading over the implementation, I have to say that there seems to be much easier ways to accomplish what they are trying to do.

With the ‘pipes’ concept, the following conditions need to be met I see:

1. Pipes are only one way
2. Pipe subscribers listen to the pipe for messages pushed through
3. Pipes can be merged together or split
4. For organization, pipes should have a reference lookup string so that application layers can be used

This pipes theory really intrigues me… I will post again on this to suggest with what I can envision as a more straight forward API.

Part 2: http://www.jadbox.com/?p=161

Tags: theory

I programmed these examples several years ago… I’ll edit this blog to explain more but JADRAD is rather impressive for a newbie start in game programming at the time.

This is an RPG engine I programmed using C++ libs and BlitzMax. It is all hand-made as I was doing it for learning purposes. This includes graphics engine, AI, pathfinding, rpg system, map system, and more.
JADRAD RPG Engine (ZIP – 3megs)

On the flip-side, here is another very very simple AI test for swarming:
AIants (ZIP – 600k)