Besides the fact, that this is nothing new, but an ongoing trend that started a couple of years ago, there are three observations I’l like to share:

1. The authors seem to be at home in the Java world, because XML was mentioned as the only feasible data format for Web services. If you are used to work with PHP and/or JavaScript, you probably prefer JSON over XML, because it’s more lightweight and it is the natural choice for Rich Internet Applications that use a JavaScript frontend. The only real advantage of XML is the possibility to use XSL to transform data. Therefore it sometimes makes sense to use XML for server-to-server communication, but probably not when communicating with mobile or JavaScript clients, that don’t use XSL.
2. The list of characteristics of a good service interface does not list API versioning, which is very important for mission critical applications that are mainly based on Web services. Otherwise these applications will break very often.
3. Also, the API should be “stateless”, according to the authors. In reality, you want to use some sort of state for sessions (a shared token is common) and for transactions (to bundle a couple of API calls and only permanently store the data, when everything was successful).

After committing the second flot fix, I found out that you can only send ONE pull request per branch and I didn’t even know how to create new branches. Not to speak about how to move the commits to the right branches. Without the help of Alexandre Salomé from Sensio Labs I would have been totally lost! Here is what he did:

git status
git checkout origin/master -b fix-fonts
git remote
git remote -v
git checkout upstream/master -b tmp
git branch -D fix-fonts
git checkout -b fix-fonts
git branch -D tmp
git log
git cherry-pick 82583fc
git cherry-pick 082e991
git push origin fix-typos
git push origin fix-fonts
git checkout 40d886f9
git checkout -b fix-issue-520
git push origin fix-issue-520
git checkout origin/master
git checkout upstream/master
git branch -D master
git checkout -b master
git push -f origin master

Simple, isn’t it?

I really have to read (and understand) a book about git soon.

I think every experienced JavaScript developers agrees with his statement:

Browser-based JavaScript development is much more complicated than it seems.

Except that I don’t like the word “complicated”. When developers say something is complicated, it means they are too lazy to think about it and/or that they want somebody else to implement a feature. Instead I would say:

Browser-based JavaScript development requires more attention to detail than usual server-side programming languages.

I recently managed to publish my latest project:

chaoticpattern.net

While reading the book Sync, I felt that this is the right name – an explanation can be found on the Web site. There is already some blog with the same name, but it does not seem to be very active. The last post is from May 2009. Hope I don’t cause any confusion.

Chaotic Pattern will be used as an incubator/lab. The Wiki itself is the first in a series of experiments. It fits my personal needs as a publishing platform and is more convenient than any typical word processor out there. You can not only edit documents online, like in every other Wiki, but also produce wonderful PDFs and include content from Flickr, Youtube and Google Maps. If you like it, use it for free. There are no strings attached and I will not sell your documents or your Facebook profile

Also the Wiki is there to demonstrate what you can do with JavaScriptMVC 3.0 and a little bit of PHP. Theoretically, it should scale to billions of users. But as long as I don’t get any venture capital, we will never find out. Anyhow, I want people to use it as a prototype for their own apps. Until end of this year, everything should be properly documented and you can download some of the components.

The next step is to get the Ajax push server finally running, so that you can use the real time features. Ape is installed, but seems to cause connection problems under certain conditions. Either I can fix that with my limited resources or I have to switch to another server. It’s not like I don’t have anything else to do, so please be patient^^

• FuncUnit (the test framework)
• DocumentJS (the documentation engine)
• jQuery (JavaScriptMVC uses a special fork with added bugfixes)
• JavaScriptMVC  (the core framework)
• Steal (the code manager / script loader; sometimes referred to as “StealJS”)
• Phui  (component library for JavaScriptMVC, not part of the core)

These partly independent components (together with Selenium) are bundled using git submodules (http://book.git-scm.com/5_submodules.html) in a repository called “framework” for your convenience:

http://github.com/jupiterjs/framework

A detailed description of the components can be found on the Jupiter JS blog:

http://jupiterjs.com/#news/javascriptmvc-features

Release 2.0

You should be aware that release 2.0 is still out there. Don’t get confused. It is hosted on Google Code at http://code.google.com/p/javascriptmvc/ and uses Subversion instead of git. Don’t use the issue tracker there for bugs you find in 3.0.

The respective project Web sites are:

• http://www.javascriptmvc.com/ for 2.0
• http://v3.javascriptmvc.com/index.html for 3.0

Ways to contribute

There is a number of ways to contribute:

1. You can fork the project repositories on github (http://github.com/jupiterjs/) into your own repository and send a “pull request”, every time you want to submit changes (pull requests replace patches and preserve your authorship)
2. After contributing for a while, you can become a member of the JavaScriptMVC team and ask for direct write access to the project repositories
3. You can just checkout/download  the latest framework version and report bugs to the developers (http://github.com/jupiterjs/javascriptmvc/issues) or answer questions on the mailing list (http://groups.google.com/group/javascriptmvc?hl=en)

A few words about git

In every case you should become more or less familiar with git (the distributed version control system) and github (the project hosting Web site).  The Git Community Book is a great reference: http://book.git-scm.com/index.html. If you are already familiar with Subversion, you might want to read the “Git – SVN Crash Course” (http://git.or.cz/course/svn.html). The main idea of git is that everyone has its own repository (that’s why it’s called distributed). It allows everyone to contribute easily to Open Source projects and was initially designed and developed by Linus Torvalds for Linux kernel development.

In contrast to “normal” version control systems, a commit is happening on your local computer only. If you want to actually send your code to the server, you have to push it back to the remote repository. If this is not the main repository of the project but your own fork, you additionally have to send a “pull request” to the project owner (jupiterjs in that case). As a previous user of Subversion I found the whole process of checking out the source, committing my changes and pushing it back to the repository tremendously complicated, even though I understand the need for distributed version control. In part this is because git sometimes comes up with error messages that look pretty scary and that don’t help to understand the actual problem.

Setup your github account

After you created your free github account at http://github.com/, you need to go to the Account Settings page, click on “SSH Public Keys” in the left hand side navigation and then enter your public key. If you don’t have one yet, you open a text terminal on the local computer and enter:

ssh-keygen -t rsa -C “youremail@address.com”

There is a more detailed howto at http://help.github.com/msysgit-key-setup/.

If you run Windows, you are probably out of luck. Try to ask Google for assistance

Next step is to fork the repositories you want to work on. This process is pretty convenient – you simply click the fork button on the main repository page. The complete list is visible on:

http://github.com/jupiterjs

Install Git and Java

If not yet done, you should also install Git and Java on the local computer by using the package management software that comes with your Linux distribution. On Ubuntu you can use the “Synaptic Package Manager” for example. At least in the past, I had bad experiences with OpenJDK and Rhino (the engine that executes JMVC’s command line scripts), so I recommend installing the “original” Sun/Oracle Java version. The Selenium server also needs Java.

Clone the repositories

I recommend cloning (that means checkout) the “framework” repository as the first step. The build script in there allows creating the downloadable packages you see on http://github.com/jupiterjs/framework/downloads. To do this, follow these 4 easy steps:

1. Create an empty local directory that should contain all your github repositories and change into it
2. git clone git://github.com/jupiterjs/framework.git
3. git submodule init
4. git submodule update

That’s it!

The procedure to clone your forked project repositories is similar. First you need the URL that you have to provide to Git.

Go to your Git home page ( http://github.com/[username]/) and then click on the forked respository, e.g. javascriptmvc. On the top you’ll see 3 different URLS:

• SSH with read and write access: This is what you want to use
• HTTP: This is slower and offers read only access
• Git Read-Only: Since we want to push (write) our changes to the server, this does not make sense

Now simply clone it into your local github directory by typing:

git clone git@github.com:[username]/[repository].git

Push changes

With Git, you can do as many commit as you want locally. Please note that the equivalent to “svn commit” is “git commit –a”. Please be nice and provide a commit message every time, for example:

git commit -a –message ‘Changed github URLs from pinhook to jupiterjs’

To see what would be commited or to see your changes since the last commit you can use “git status” and “git diff”.

After testing all your changes locally (this is probably worth another article, but I’m running out of time now), you are free to commit your changes to the remote repository:

git push origin master

You can also configure git to always push to the matching remote branch (there are other options as well, but I’m not that much into git to fully understand them, to be honest):

git config push.default matching

Next time you push something into that repository, it is enough to use “git push”.

As mentioned earlier, you have to do send a “pull request” (there is a nice button on github to do just that), if you want to send your changes from your fork to the original project repository.

Pull changes for submodules

In my naïve thinking, I assumed that Git will automatically update the submodule directories in the framework repository when you type “git submodule update”. This is not the case.

You have to manually pull the latest changes in each sub directory that contains a submodule like this:

cd funcunit/

git checkout master (only required the first time)

git pull

You will only get the changes in the submodules via “git pull” in the main framework directory if somebody with write access to framework does this “cd [submodule]; git pull” procedure locally and then pushes back to the repository on github:

http://github.com/jupiterjs/framework/commit/1affd96d632b34621e9e0d06707ea83d1d4c3b9d

Thanks

Thanks for reading this. You see, I’m not a Git expert yet and I really hope I didn’t give any bad advice concerning its usage. As I improve my knowledge and find best practices how to do things most efficiently, I will update this page or post a follow-up. Especially testing is not covered in this article, which is a shame.

http://www.ape-project.org/

Even though the authors say it’s a stable 1.0 release and “insanely great”, there are some issues you should be aware of. I write this in the hope that it helps others to evaluate the server and to give feedback to the developers. The general idea of combining fast C code with JavaScript is very good. It’s still a young Open Source project and has a lot of potential.

Incomplete documentation

It turned out to be a little bit challenging to develop code for Ape because of the quality of the documentation. There is an API documentation (which is not good for new users) and there is a Wiki with some links leading to missing pages. Most of the examples deal with how to implement a chat server. In fact Ape was previously named ACE (Ajax Chat Engine). It’s sometimes hard to understand how to use it for a general purpose application and what the limits are.

Maximum length of channel names

One of these limitations is the maximum length of 40 characters for channel names. In my library I use channel names like ‘foo.bar.baz’ that can be easily published with OpenAjax on the JavaScript side. Some of these events never arrived nor did the subscribe function throw an exception.

Nickname required to connect to server

At first it seemed like the server requires a nickname to connect, which makes sense for chat applications only. Not every Web site out there should ask the user to enter his nickname, right? After investigating the issue (I didn’t find a hint in the documentation), I found out that an example server-side script in /var/ape/examples was causing this behavior. You can comment out this line in main.ape.js to “fix” it:

include(“examples/nickname.js”);

Error when sending messages to empty channels

If you happen to send a message to a channel that is currently not subscribed (Ape calls it “joined”, like in a chat software), you’ll get an error. This behavior is strange, if you are used to other message servers that just accept the message, even if nobody will ever get it. If you know this can happen, it’s not so much of an issue anymore.

Complicated domain name setup

Ape uses sub domains in the form of [Number].ape. to communicate with the JavaScript client. Each connect increases the number (which is stored in a cookie) by one. They call the numbers “frequencies”. According to the documentation, this concept should provide sessions within a session, if you open multiple tabs in the same browser. I’ve never seen something like that before. I disabled the feature by modifying their code and tracking the different tabs on the server side. My code will be published later, so you can copy this, if you like. Another problem with the changing domain names is that you have a hard time to set this up locally in /etc/hosts – there is no support for wildcards.

Config directly inside the JavaScript library

I found it really strange to configure the Ape server URL directly in Build/uncompressed/apeClientJS.js. If you ever update this file, your config will be overwritten. Why not provide the config as a parameter to the load() or constructor function? Again, I modified the code.

Based on MooTools

There are two versions of the client library, one for MooTools and one for other JavaScript frameworks, which includes MooTools. I did not find out yet, why you need MooTools to write an Ajax push library for general usage. I also did not investigate how many files are loaded additionally when the Ape library is included. My feeling tells me, that this whole thing can be improved and that the library should be compressed and put in one single file.

No standard protocols

Even though it probably is possible to connect Ape to a general usage message server (like ActiveMQ or RabbitMQ) with some additional work, it does not offer a standard STOMP or AMQP interface by default. The Web site states that the Ape protocol is faster than everything else. So far, I was not able to confirm or reject that claim

JavaScript on the server side

It is convenient to be able to use JavaScript on the server side. Just let me note that this can lead to previously unexpected errors. JavaScript is a loosely typed language and if you happen to return a number instead of a string as nickname to the server, you will see this exception:

/var/ape/examples/nickname.js:6:TypeError: params.name.toLowerCase is not a function

However, I often have a hard time to convince other developers about those advantages. I guess testing is the easiest one, because no developer would dare to argue against testing, even though many developers don’t do it or don’t do it right. Questions and discussions about testing seem to be very rare. Developers just discuss it with their non-technical managers, if they want to get around that “effort”.

But it already starts with OpenAjax. I rarely find a developer that knows what it is and what it is good for and why you might need an event hub in JS at all. Zend, W3C, IBM and Google are some of the more well-known members of the OpenAjax Alliance. If you hear about it the first time now, take the time to have a look.

Just yesterday I was talking to an obviously experienced JS dev (who was working for a well known mobile phone company), that was browsing through the JavaScriptMVC documentation and stopped in the chapter about EJS templates: “Yeah, I saw something similar in our own project and removed it. It is confusing, if the JS code and the HTML are in separate files, because you don’t see the code together in one file. HTML should only be edited by developers who know the JS code very well”. Not sure what to say about that. Why not give up separation of concerns at all and put everything in one big file? Then you see the big picture on your hopefully big screen. Also you always need to check the full version control system diff after each change because the file name alone doesn’t tell you what was changed and you probably have more of those exciting conflicts to resolve. And: You REALLY need to be an expert to understand what is going on. The company can never fire you, because no one else would ever understand that kind of code. Sorry for being sarcastic, but that kind of attitude can seriously damage the health of innocent other people who need to clean up the mess in 20h work days afterwards, to meet the deadline of the project. Or the project is so small that it doesn’t matter. Or the company you work for can afford to pay a lot of developers who have the time to maintain a JS app without templates.

Convincing people about the usefulness of controllers is not easy too. Either you start showing an OpenAjax subscribe action – then the developer most likely won’t understand what that is good for (see above). Or you talk about event delegation, then the developer will point to jQuery’s live() method, which does event delegation too. In fact, JavaScriptMVC’s event delegation used to be one of the strong points and I admit that I am not totally up to date with the whole discussion right now, because I was busy with a PHP project during the last 6 months. I know Justin Meyer is/was working on the controller code so that it makes more use of jQuery, he contributes code to jQuery and he is in contact with John Resig. Anyways, the whole point about controllers again is separation of concerns and not so much the technical details behind the scenes. The JavaScript world is moving very fast and implementation details change a lot, but separation of concerns is not really something that you can look at as something you probably don’t need. The JS world sometimes feels like the PHP world about 10 years ago.

Ok, after getting rid of those thoughts, I will return to work now. The next 2 weeks will be quite relaxed with very little work. So maybe, I can read through the new JavaScriptMVC code and update my knowledge. It really feels uncomfortable not the be able to answer questions in detail. Also I start confusing PHP and JS syntax *lol*

See also: http://jupiterjs.com/news/talkin-javascriptmvc-is-hard

If all tests are green, they passed. Red results indicate failures: