Latest Entries »

The ACE project is a standalone programmers editor written entirely in JavaScript.

You can take ACS for a spin in the project homepage at, you’ll notice is supports multi-language syntax highlighting, parenthesis matching, regular expression and full text searches, although I didn’t see code completion (which would be nice). Judging by the amount of other projects that make use of ACE, it’s fast becoming a de facto for browser based editors.

According to the authors of the system, the mission of ACE is to rival existing native editor like Eclipse. The editor is already used as part of the cloud9 IDE.

So go take a look at the website and see the impressive list of projects that are making use of ACE.

I know I will when need arises.

I know I’m off subject again, just bare with me, its exciting stuff.

There are new interesting things happening at chip manufacturer AMD.

What is HSA (Heterogeneous Systems Architecture)

HSA put simply is a multi-core processor combined with a GPU(s) that are all on one piece of silicon. In the full vision it’s AMD’s goal is to have all these parts functioning in the same address space with little memory conflict, in other words they’ve figured out have to make all the bits of the chip play nicely without bumping into one another, thus faster.

What makes HSA so cool?

Today’s GPU’s and CPU’s are on entirely different memory maps, so you need to copy data to and from different memory maps, this is tedious and slow. The goal is, AMD’s HSA will allow you to access all the the parts of this chip in one unified memory space, which will speed everything up and make programming much simpler. It will be really fast and I mean fast.

What could I do with HSA?

AI, Realtime processing, pattern recognition, photo realistic 3D, all of the things that programmers dream about. There will also be a block of silicon ‘sub-routines’ for doing specific kinds of processing, probable more mathamatical in nature (I’m guessing).

AMD has an ambitious plan, they have committed themselves to producing the finished product within 2 years.

You can find more info at:


Here’s just a quick update on the up and coming release of MoSync 3.0.

It seems that MoSync is the only SDK, where you can create native UI across Android, iPhone & Windows phone 7, it works with JavaScript, So MoSync is the only product that really provides consistency across, JavaScript, HTML 5 and Native UI.

Also here’s an up to date list of features for MoSync 3.0

  • JavaScript libraries to access to native features, including native UI
  • Windows Phone 7 support
  • New deployment model based on platforms, not devices
  • Multichannel Sound API
  • Ads (iOS and Android)
  • Notifications (iOS and Android)
  • Improved development workflow (quicker turnaround)
  • Automatic updates
  • Local SQL Database support

If you have questions, just comment:)

Do you remember Mophun ? Those nice little chunky pixeled retro games on old phones ?

For those of you who don’t or have never heard of it, here’s the low-down.

Mophun was a mobile phone games SDK, it was released in 2002 and had a huge community of 30’000 developers, there were 200-300 games were written for it. It was also the first platform that had an AppStore (stolen by Apple & Nokia:) ) and had deployment via mobile operators world-wide.

For a little more info on Mophun take a look at

Is There Interest

So should Mophun be made open source, is there enough interest.

The Games

There are hundreds of Mophun games out there, these games are not really doing anything, so why not make them open, or at least make the binaries open and free. I will make a appeal to some of the original authors of these games, I feel fairly confident that I cam get at lease 50%.

If there is enough interest, I will write a clean-room version of the run-time engine (to avoid being sued) on MoSync .
I have the domain, I just need to know if anyone’s interested before I do it.

So leave a comment now, or vote on the poll!

In the past year there has been a real buzz around cloud computing, why should use it?

1. No Hardware, No hassle.

We don’t to own hardware, we don’t want to buy a rack and host it, we don’t want to be responsible for it’s up-time. It will cost us more, but the total cost of ownership is too frightening. The downside, it’s one size fits all and it’s more expensive.

2. It Scales.

The Amazon elastic cloud promises us 99.99r up-time and total scale-ability, the choice of OS. But don’t forget, you still need to write the service/server. I always thought that good scale-ability came out of good software architecture, apparently cloud services provide this automatically:)

3. The singular solution

The reasoning for using the cloud goes something like this:

Singular Solutions

“Buying computers and hosting them somewhere has limitations, therefore we will use a cloud service, because we are building for the future, when millions of people use our service every day, we will be able to handle all of them. We will create our service and make it scale across multiple servers, so we can grow as more people use our service.”

Here’s the problem: Business people think they understand this!!

This sound like utopia, the holy grail, I smell a rat!

 4. The Reality

What’s important, is it the infrastructure, the software/servers or the users of the software.  In what priority should these things done,

Firstly. Study the Users – Clearly the most important, who will use your software, how big is the market, how should your software solve the uses problem, get some use cases.

Secondly. Prototype your software – Now you know what the users want, you can design something quick to solve their problem, it’s not a university project just get on with it. Prototype your software first, just go ahead and write something quick and dirty (search for “Duck Tape Programming”), do this before creating a real design, you will learn more now than at any other time, set yourself a deadline and work to it. If you created a design at this time, it would change constantly and you would end up with deep limitations.

Thirdly. Design your software – Do it properly based on everything you learnt in your prototype. You must be able to create and debug this software with the fastest turnaround in the simplest configuration. Test with a smaller group first, by doing this you can shorten development time, cost and reduce development risk.

Fourthly – Cloud services. Since you already know the scale of your users in step one, you should have taken this into consideration in the software step. Perhaps you don’t need a cloud server or a high level of scale-ability, perhaps you do.


You don’t need cloud services/servers at the beginning, in fact it’s better not to have them, you just need to be prepared in advance. Remember software is king, content is the king of kings and users  are god.

P.S. I know that this doesn’t relate to JavaScript, sometimes I just need to get something off my chest.

Recently I have been working on a small example game for my friend Alex. The game is a version of traditional PONG, two bats and a ball. The difference between my PONG and other PONG’s, is that it’s played on two phones, each player uses their own phone, one player could be in Bangkok and the other in Stockholm, anyway, here’s what happened.

Step 1 – Writing the pong game, this went very well, I had it working in about 2 hours, scores and all. (If your reading this Nolan, I won’t sell the game and I promise, I’ll buy you a beer:)

Step 2 – I had already written an IRC class in MoSync, I’d noticed that IRC was essentially bomb proof and pretty quick. So I implemented the multi-player part of the game, using (don’t laugh) IRC. This worked pretty well, the only problem was flow control, sometimes you get 20 messages a second, other times nothing for a second, then 40 messages.

Step 3 – So I decided to write my own server. I based this on a java server I wrote in 1998, there were some horrific deprecation problems, so I thought I’d try a few other routes.

Step 4 – I wrote a server from scratch in C, this was even more troublesome that Java, I just hate the socket/communications API’s in C, they are just horrible mystical bits of unreadability.

Step 5 – I went back to Java, started at 6am one morning and was finished by 12am, so the moral is, I should have just stuck with step 2 and fixed my deprecated code.

The Point

Finally I had a server that was:

1. Quick.

2. Multi-channel (like IRC but binary)

3. Could handle vast amounts of connection over many channels simultaneously.

4. It’s simple just a 10k  jar file (and growing).

5. It’s easy to run on any computer, regardless of OS.

6. It can be used in conjunction with the JavaScript web sockets API.

7. Its thoroughly generic and multipurpose.


There are so many instances where people create servers, just to connect two (or more) devices together, who would have thought this could be such a problem. Most people will write their own cloud service service, when it really isn’t necessary, all because there isn’t a simple generic server that does just that. So GenServ was born.

Being something of an open source advocate, I fully intend to solve this problem by releasing my server in the next few weeks.

If you would like to help me out write writing some example code or have opinions about my server just comment or drop me a mail.

P.S. IRC can be a good way for devices to communicate, so long as latency and flow control aren’t a problem.

Remy Sharp has written a great blog article, where you can find more info about cross-browser communications methods:



As promised I’m back with some more info on the up and coming release of MoSync 3.0. After my last post several people  approached me and asked why I hadn’t mentioned MoSync Window Phone 7 support. To be quite honest I just forgot to put it in, still it gives me areason to write another post about the new MoSync release.

It seems that Windows Phone 7 is the talk of the town at the moment. At the AT&T conference in Vegas every other developer was showing off theirs!

Basically almost everything that you can do with MoSync Android & iPhone you can do on the Windows Phone 7 version of MoSync, it supports:

1. Full HTML5 & JavaScript integration, so you can program in JavaScript and it will work on Android, iPhone & Windows Phone 7.

2. Full C/C++ native code, You can code in C/C++ (if you like that) it will also work on all the devices.

3. You can use the C/C++ as extensions to you JavaScript app (if you like).

4. You can use the w3c native mobile standard framework with all the devices.

For those of you that are technically inclined, the system produces c# code with is compiled using the standard MS compiler,so its really quick.

I hope this is enough, if I’ve missed anything out just comment me or email me.

The new version of MoSync 3.0 is due for release in the beginning of febuary. Now I’m quite excited about MoSync 3.0, the reason for this is the new features and capabilities
that are I think really interesting. As you may know , I work at MoSync, so I’ll try to be unbiased.

Here’s dome of MoSync 3,0’s new features :

W3C compliant Mobile JavaScript API

This is a new set of native bindings that follow the JavaScript Native API specification set by w3c, it’s based on the PhoneGap API, although its has been vastly improved. This API and all its capabilities can be edited directly within the MoSync base package, there no need to rebuild it independently. So accessibility is now king and nobody is ever dependent on other developers to build this API for you. There’s a big up-side here for existing PhoneGap developers, since they now have the freedom to do whatever they want!

Native UI in JavaScript

Most of the capabilities of both the Android UI & iPhone UI have been included into a rather nice cross-platform JavaScript library, it’s called the JSNativeUI library, it gives you access to a large selection of the native UI widgets and even handles the differences between the devices. Whats more it even has its own HTML mark up, I think this is very cool, because you can be a web app developer and get Native UI at no cost.

Thats all for the moment, I’ll come back later with more.

For more information go to and read the product road-map or the blogs.

Great article by Brian O’Conner of Universal Mind, its well written and to the point,
the only downside is that is doesn’t mension MoSync anywhere (No self publicity allowed, well not much anyway:).

Mobile HTML5: PhoneGap vs Appcelerator Titanium

If I remember rightly jQuery is 26K and growing, still I like the ideal of people optimizing
their libraries, I wonder if there are any drawbacks to this library.

You can read more about the Zepto JavaScript framework at Thomas Fuchs (I’m a bit of a fan) website:


Get every new post delivered to your Inbox.

%d bloggers like this: