Enjoy the short video we prepared to give you an impression of what EventNinja can do

EventNinja in Action

The EventNinja widget contains multiple pages, as you are used to from mobile applications. The home page shows all the events, allows you to search and filter them. Along the top bar you have the search bar, the “Help” and the “About” pages linked.
Clicking on the icon to the right of each event takes you to the details page of the event, from where you can go to multiple other places, like the map, to see where it exactly takes place, the schedule of the event. If the event has twitter tags saved for it can go to a page which shows you all the latest twitter messages flying in. Try it on EventNinja.net and explore the features.

EventNinja Features

User Features

• List of web developer events
• Searchable and filterable by tags, location and full-text search
• Exact location of the event
• Watch all twitter messages for each event
• Find out about details of an event

Technology Features

• Events are stored, retrieved and filtered by a Google Calendar
• Everything built on top of the Dojo Toolkit
• pure HTML, CSS, JavaScript based widget
• using PhoneGap to run on iPhone, Android and Blackberry
• Plugin architecture, allows for a modular enhancement of the widget
• Fully customizable via client-side templates and CSS of course

As you figure right from the list of features and cleverly combining them we can hook this widget onto any calendar, customize the features (via plugins), style and brand it the way we like it and have your custom widget.

This gives customization a far broader meaning. Just imagine combining the two components 1) base of the widget and 2) the twitter plugin. You get a widget which shows you all tweets for a certain event -that’s just a new widget itself, without writing a line of new code. Which again is a very different use case, than the widget you get here. Just hook in another plugin which allows replying via twitter and you get a full blown twitter client in the context of events.
The limits of what is thinkable is just limited by the plugins you can write.

EventNinja for the mobile2.0 Conference

Mobile2.0 is the first conference where you can really use EventNinja to get all the info possible, the schedule, twitter messages, etc. There surely will follow many more conferences and events that EventNinja can and will be used at. See the screenshots below to get a feeling of what it looks like for this conference.

Are events missing?

EventNinja for webdevelopers is driven by the great amount of community events.
If you see that events are missing, please contact us and we will add them immediately. If you organize events yourself let us know as well. You can send any kind of info about the event, e.g. name, location, tags, speakers, twitter tags, schedule details, price, and much more.

You want an EventNinja?

Send an email to eventninja _ at _ uxebu.com if you are interested in a customized version of EventNinja, are interested in the technology or simply want to chat. At the mobile2.0 conference you will recognize us easily when you look for the guys with those caps, hurry, because we are spreading caps and maybe there will be many more wearing this cap :-).

Well, call me pedantic for even discussing this and seeing this as relevant. But everybody knows that adhering coding styles make programming in a team way more pleasant and it is just way more efficient to just code and not to style! Which includes not having to think about how to style the code, though I realize that a lot of programmers have a problem adapting to coding styles.
We at uxebu basically defined that we are applying the coding guide lines of the project that we possibly contribute stuff back to. This means our JavaScript code applies the dojo coding style guide and our python stuff (we use internally) applies the django coding style guide.

But let’s look at the for-loop now.

The default

The most common usage of a for loop is the following.

Nothing spectacular here. But let’s take it apart a bit. There are two things that are commonly known that can be optimized.

1. The comparison “i<nodes.length” in line 1 evaluates the length of nodes on every iteration, if the nodes array is not modified while looping over it or the change to it is not relevant, this can be optimized.
2. Also the declaration of the variable “node” in line 2 is done multiple times, so this is just a small unnecessary thing to do.

So let’s optimize the things we just found out.

Version 2

Another step on our way was to optimize the variable declarations and reducing their count from three down to one. In some code you can then see the following.

Version 3

Actually we have already skipped a tiny step in between, very often you can see multiple var-statements as opposed to the already “squeezed” one-liner in line 1 above. The way of writing it as seen here, is reasonable if there are a couple other variables to be declared, you just need one var-statement. This will basically reduce the code size, if your minifier doesn’t already do that for you. As stated here it seems to be specified to be irrelevant to performance. So event the argument under 2. against the first version (see above) is not very strong.
Just a small side-note: the one line var-statement evaluates in declaration order, so something like this will work!

The “len” and also “x” variables contain the proper content as you are expecting. The comma-separated var-statement evaluates the assignment expression by expression and steps on to the next assignment. Therefore “len” and “x” will have the proper values 3 and 2.
But let’s go back to our for-loop.

Version 4

If the var-statement is outside the for-loop and especially if other variables (outside of the scope of the for-loop) are declared there the source code get’s blury and harder to read. For example:

The first two variable declarations (someVar and anotherVar) have nothing to do with the for-loop context, but the others do, so this blurs the source code and is prone to errors. Also if you separate this source code onto multiple lines like so:

it is still a possible point of failure. I for example, forgot the comma on line 1 which made this source code

still work. But and this is a big but, the code get’s a different meaning now! First, line 1 will work, since the semicolon at the end of the line is not mandatory. And second (if not declared inside this scope before) the variables on line 2 are now defined in global scope. And that can really cause a hard to find bug!
Another good reason for not doing this, is that extending the code may lead to developers adding code in between the var-declaration and the for-loop, for whatever reason. Then the variable declarations for the for-loop “drift away” and loose their context even a bit more. And the source code becomes harder to understand.

So we rather put all the variable declarations into the for-loop’s var-statement. Like so:

Now we have a pretty compact and well context-focused syntax for declaring variables needed within a for-loop. This code is nicely readable and has no impact on performance, even if in most cases good and maintainable code is worth more than the fastest code, but that’s a use case based decision! We are taking this as a standard for uxebu code.

What do you think? Let us know if you see potential for optimization.

Besides holding talks, which occupies at least most of my brain time until I am done, we are really looking forward to getting to know better the AJAX Community here in Germany and we hope for a lot of input and to share ideas with like minded people. If there will be so much brain capital as there was in Boston for the Ajax Experience two weeks ago, we will need at least the rest of the year to digest it all. But hey, that is what we are out for. We want your input and we want to give input.

May be we will even try to have a gathering of some of the most interesting and most interested AJAX people that are coming to the conference in order to shoot a dojo.cast(), may be some kind of “conference edition”. Actually, that is just an idea I made up right this second while writing this, but I guess Nikolai and Pete won’t be too opposed to it.

Feel free to mail us or drop a comment if you like to meet up – no matter if dojo, ajax, javascript or whatever related.

Arrival
When I arrived there about 10:00 everybody started gathering in the cantine, I just had the time to grab a coffee and find Johannes to have at least someone I know :-). Then the introduction round started and everybody stood up said his/her name and tagged himself with three tags. It went much faster than you would expect. About 15 minutes I would say, for about 300 people. Impressive, especially the ping pong strategy was somehow cool, going from one end of the room to the other, which was possible with two microphones. I realized, when it was my turn (and I was almost the last one) nobody had yet used the tag “ajax”, so I stood up and said “I am Wolfram Kriesing form uxebu, and my tags are: ajax, javascript and dojo”. Ok, I had passed the first test.

dtrace
While all first time barcamper went to see a short session about how to barcamp Johannes showed me pretty impressive stuff you can do with dtrace. Just off of the top of his head he wrote a tiny script which just showed all “open” system calls, then we double clicked one of my files on the desktop and a hell lot of open calls were triggered, wow so much work for just looking at one file.
If you want to get the hands deep into the gears of your system for whatever reason dtrace is waiting to be used. I will definitely need to dive into it for a project we are developing at uxebu. Unfortunately it is only available on Solaris and Mac OS X. But hey, most web devs are working on Macs, and since that is a dev tool it could be pretty useful to many.

First two sessions
After introducing my two talks I went to see the session about the web in China, it was nice and interesting information, but of too little use for me. Right after this, first session we all had lunch. Then I went to “presentations with storyboard”, where Alexandra Graßler told us about how to do presentations best using a storyboard (some more info here). It was very good I think, not too much new stuff but good the storyboard part was the good thing. Building a logical tree for your presentation on which you “crawl” along with your arguments in order to lead the listener to the assumptions you are going to make. I just need to pick the cherries from it try and practice that.

My first session, Efficient JavaScript development
After that I had my two sessions, I guess two of the more technical sessions, which actually surprised me, but the number of listeners convinced me that there are interested techies there. Fortunately.
For the first session “Efficient JavaScript development” I got some interesting input regarding the direction of the talk. Matthias Gutjahr expected a bit more about how to write efficient JavaScript code. Right, the title might be a bit misleading. So I am trying to fix the direction of the talk, but I like the name and the wide range of possibilities it allows you to talk about. May be it pulls more people, then I only have to take care of meeting the expectations. I will try very hard! And since it was actually a subset and a test of what I want to talk about at the Ajax in Action 2008 in two weeks, it was a great first try. Thank you all for listening, the good questions and the input!

My second talk, dojo toolkit
The next session “dojo toolkit” right after the first one, was targetted purely on dojo. I had converted the slides just one hour before to be real uxebu slides – but hey, what has to be has to be! The always again upcoming questions were about cometd, cross domain handling and some dojo internals.
So I searched some URLs to show some of the examples that I may talked about or that target the mentioned topics.
One is babel chat, which Pete Higgins created and showed off a couple of times at the Ajax Experience in Boston. It’s a pretty neat application for showing off what cometd and dojo.data can do. You set your preferred language, log in and you can chat in your language, the answers come in your preferred language translated by google translate. We had a lot of fun with it, since the translations are often very funny. You know, the automatic translation stuff mostly sucks. But the show case is worth it with some extra fun included.
Another thing that Pete had also created in Boston was the faces demo “Create you own dojo javascript developer“. You can flip parts of the faces and choose from various developers. You will get a lot to laugh! There is even a hall of shame now, check it out! It uses dojox.fx.flip from Nicola Rizzo. Which allows you to flip layers and the cool thing about it is all done just by manipulating CSS properties.

This has already become a lot of text and because I am actually not a big friend of so much text I just stop it here and continue in a second article. (Or am I just too lazy right now :-)).

All pics form zerok, thanks!

JSON communication with the server
There are enough use cases (and they are becoming more) when you want to get data from the server and the most common data format nowadays for that is JSON, for various good reasons.
Let’s construct a simple form who’s data we want to submit to the server and know if it all went ok or not. For now we just print the submitted data on the django console (from where you started the local dev server) and we let the user know about the submission with the small text “Submitted” beside the submit button.
So let’s get started with the JavaScript side. Dojango luckily provides us with the basic infrastructure, so let’s create a template that extends dojango/base.html (it is available since the settings.py includes the app “dojango”, see here for instructions), that provides us with everything we need to have dojo running even the doctype of the document and HTML headers, just in short a valid HTML file, we only have to worry about our code.
So let’s build the simple.html file in the templates folder of our django app (I called my app “core”).

As you can see we are overriding a couple of blocks, that are defined in the dojango/base.html. The first one (line 3) is just for setting the page title, the second one (line 5) is for putting our JavaScript code inside html-head. And “dojango_content” (line 21) is finally the content of the body node.
We also have to wire up the template to render when we access http://localhost:8000/simple/ and the AJAX method, that we submit the data to, like so in the urls.py:

We just added the two last lines that map our URLs (line 6 and 7) to the view functions.
Our views.py just needs to implement these two functions, like this.

The function “simple” (line 4) uses the standard django way to render a view and return the content to the client. It finds the template simple.html in the app’s template path.
The function “simple_ajax_set” (line 8) will receive our form data and (for now) only print them. You can see the first speciality here, it uses the decorator “json_response” that we imported from dojango.decorators. This decorator takes care of returning proper JSON data, all the data you stuff in there are returned to the client JSON encoded, it basically is json_encode as described here. If you have AJAX calls and want to return JSON data, this is the easiest way to do it and it comes with dojango. It is a special (though very simple) implementation that has not made it’s way into the django core because it is really just AJAX-focused, while the django serializer is django model focused. Additionally this implementation solves a couple of problems and adds some features that are very useful when working with AJAX data, for more explainations see this article.

Handle the return
Now we can submit the form and see that the data got submitted. We don’t know yet if the data had been successfully handled on the server. So let’s add proper error handling.

If you looked into the return data (i.e. via FireBug) you might have seen that

was returned. But until now this was passed into the load function (line 8) as a string, but we want them as JSON. So we have to tell the xhrPost() call to handle it as JSON (line 4). Now we can also evaluate the success value easily as shown in line 9. If the server returns

with the value

we know something went wrong on the server. Let’s implement on the server that the surname has to have at least three characters. In the case of an error the server returns the additional property “error” which we then show to the user (line 12) to inform him about the error.
The function in line 15 handles all kind of connection and/or submission errors that may occur in a lower level. Make sure to not leave your users in the dark about this.
Let’s look at the server code for that:

We extended the function a little bit to do some simple error checking. You can see that we add the key “error” to the ret dict, which is then passed to the client if the surname was shorter than three characters. The JSON string returned in this case is

.
Note that we didn’t explicitly set the value for

to

, the decorator

handles that for us. If no exception is thrown it assumes that the function went ok and it can return

. This comes in very handy, especially when you just have simple one task AJAX functions that i.e. just delete an item, you don’t have to return explicitly that the deletion went well,

does that for you if you throw no exception. We just made it the default behavior since it was right for most of our use cases.