Modules

AMD stands for “Asynchronous Module Definition”. So, what are modules? I’ll quote the definition from the CommonJS Module specification, as it describes it very well:

This specification addresses how modules should be written in order to be interoperable among a class of module systems that can be both client and server side, secure or insecure, implemented today or supported by future systems with syntax extensions. These modules are offered privacy of their top scope, facility for importing singleton objects from other modules, and exporting their own API.

So, modules are isolated parts of code that live in their own scope and are kind of self-contained. Well, that is pretty much how we see the individual Features in EmbedJS – we made our feature implementations as small as possible and reduced dependencies as much as possible. Many of EmbedJS’ features are also browser-independent, so why not make it possible to use some of the tools in a non-browser environment?

(If you want to learn more on modules and why we need them, I recommend @briancavalier‘s presentation on modules.)

Features in EmbedJS

So far, I didn’t really explain what I mean with “Features”, so let me do another quote, this time from the Project Page:

EmbedJS uses the concept of features: Functionalities are split up into features, as fine-grained as possible, and each feature might have multiple implementations.

Our Features are kinda small and contain only few methods, sometimes even just one. The asyc-promise feature, for example, will get you Promises, and the transport-jsonp feature will get you a method for pull in data via jsonp – and that’s it.  If multiple methods are contained within one feature, this is because they are too closely related to each other to split them up, like the html-class feature, which contains the addClass, removeClass, toggleClass and hasClass methods.

AMD vs CommonJS Modules 1.1

Now that we knew modules were the way to go, there was another, quite important question to solve: There are two common patterns for modules, so which one do we want to apply? One pattern is described in the above mentioned CommonJS Wiki, the other pattern is described in the AMD wiki.

Well, there have been some blog posts lately that compare the pros and cons of each of them, so I don’t want to repeat all of this – but I’m hiving a similar tendency towards AMD. Besides this, there was another big reason to go with AMD: Remember, EmbedJS is based on the Dojo Toolkit, and it’s a Dojo Foundation Project – and we hope that the efforts that went into making EmbedJS might flow back into the Dojo Toolkit one day. And as the Dojo Toolkit uses the AMD approach, the decision was quickly made to do so as well.

Implications for EmbedJS

There are several huge benefits for EmbedJS in using the AMD approach. The most noteworthy surely is the ease-of-use for developers. In your code, when you find you want an EmbedJS method, you look up the feature name that provides this method, add it to the require statement and there you go. Man, easy.

A second important thing is that EmbedJS now plays really nice with AMD based projects. In fact, you could see EmbedJS now as a collection of small useful modules, that can be easily integrated – and also easily extended.

The third major benefit is that we can now get rid of all the custom tools we built around EmbedJS – you can load features with any AMD loader (though we use and recommend RequireJS) and build it with any AMD optimizer/builder (we recommend r.js).

Let’s have an extra word on

Building

It was always possible with EmbedJS to create a custom build that would contain only the features you wanted/needed in your project. But, you had to use our build tool that we created. And learning & using Yet-Another-Build-Tool™ is always… well, let’s just say it would be cool to avoid it (and, not to forget, so is maintaining it). We did a lot to improve that, we created a GUI that allowed you to just “click together” the features you wanted, and we worked on a dynamic loader that would ease development. But still, the situation was far from ideal, and people just ended up going for our ready-made “kitchensink” builds that contained all of the features.

Now, we still provide those ready-made builds that contain only the implementations for a given platform (and are stripped of require/define calls), but I really hope that using the AMD approach and using an AMD optimizer to deploy will become the more adopted style.

Q: Cross-target? A: The Feature Plugin

One goal of EmbedJS is to allow for easy cross-device development. We got rid of run-time branching but instead went for an approach that held the different implementations for a given feature in separate files, so that one only has to deploy the actually needed code to a given device – and not all the alternate implementations, that sit useless in the device’s memory and never get used. We needed to achieve that with “in-house” means provided by the AMD approach. Lucky us, there’s the concept of loader-plugins, and so I created a feature-plugin for AMD loaders. The idea is simple yet effective: You create an implementation map that maps a feature name to an implementation, and if there are multiple implementations, you supply tests that tells the plugin which feature to use.

When you’re ready to deploy, you have two choices: I f you really don’t know on what target your code is going to end up, you can use the dynamic implementation map containing the tests for the optimizer, and you’ll get a build that contains all of the available implementations. Then, during runtime, the feature plugin will run the tests and load the specific implementation. But, if you do know what target your code will run on, you provide a specific implementation map that doesn’t contain tests but directly maps to the according implementations, and you will only have those in your built file.

Synopsis

AMD is exactly what we needed to make EmbedJS more what we want it to be – an easy to use JavaScript toolbox that is especially handy for cross-target scenarios such as cross-platform mobile development. So, please don’t hesitate and check it out on Github, read the project page and check out the examples!

Resources / Further Reading

• EmbedJS on GitHub
• EmbedJS Project Page
• EmbedJS API Docs
• AMD-Feature plugin
• AMD Wiki
• CommonJS Wiki

What is it?

It‘s a JavaScript Toolkit, especially aimed at embedded devices. Embedded devices, that is phones, tablet devices, TVs, car dashboards and the like. Devices that are capable of running JavaScript. We are sure that this list is going to grow over time – and will hopefully one day also include devices like your fridge. EmbedJS is based on the Dojo Toolkit.

Why?

Because the toolkits and frameworks that exist focus on desktop browsers and therefore have a different approach – an approach we didn‘t find that suitable for embedded/mobile development. And the JS frameworks that target mobile devices are flawed, too: either they target only a specific device or platform, or they provide far more than we do need and want.

What we wanted was a toolkit that offered a unified API across different platforms, but with the best implementation that was available for each platform. And we didn‘t want to ship code that implemented a certain feature for, say, an old Blackberry device to an iPhone. Plus, we wanted that API to be small – enough to assist us in our daily work, but not that bloated that we would ship code to a phone that we wouldn‘t need in most of our projects.

The Dojo Toolkit

We at uxebu have a strong affinity to the Dojo Toolkit – most of us are committers – for a good reason: we believe that it has done many things right, and that it has an excellent code quality. Thus, finding a starting point for our venture to what was later to be EmbedJS was pretty easy: It was the very core of the Dojo Toolkit, dojo._base.

We examined the code and split it into its smallest parts (features, how we call them in EmbedJS). After having the features all nicely separated, we could look for the best implementation for each of the platforms we wanted to support, and put it into a separate file. Then we optimized our code, tweaking here and there, but also using the code from dojo._base as it was, because it already was the best implementation.

And we needed to find means to put all these tiny parts together again, respecting any given dependecies, to create a file that then contained all the feature‘s implementations for a given platform – so the EmbedJS Tools were born, including our highly flexible build system.

API

EmbedJS‘ API is a small subset on Dojo‘s API. It provides around 70 methods, from the fields language enhancement (like Array manipulation or JSON), OO (like classes and inheritance), transport (like JSONP or XHR), event system (like connecting to DOM events or methods), DOM manipulation (like style or node creation) and misc things like Promises or pub/sub.

We kept the method signatures intact so that you can import your existing knowledge from working with the Dojo Toolkit to EmbedJS. There are only a few minor changes where we
a) found a new name highly useful, e.g dojo.io.script.get() is embed.jsonp()
b) we needed to strip given functionality for the sake of code size.

All methods in EmbedJS are available under the embed namespace as well as under the dojo namespace. I.e. to call the connect method you can use dojo.connect() and embed.connect().

The full API documentations is here, though it‘s undergoing some updates right now.

Summary

I didn‘t want to dig too deep in the first article on EmbedJS, but I guess you got the point: EmbedJS is a highly optimized Dojo core, and offers you a specialized, optimal build for a given platform. To explain how the build system works, how we manage dependencies, how we separate our features and our implementations and how one can create a project-oriented custom build will need another blog post – but if you are too curious, you are invited to take a look at the source code at github; a lot is self-explenatory there. A further source of information is the EmbedJS project page, as well as the EmbedJS Tools source.

“Modern Company” session – uxebu as the example

But before I dive into the tech sessions I would like to mention that I really felt the need to hold a session which I had called “Modern Company” where I tried to show our philosophy at uxebu, how we work together, how we use the modern media, how it all came about and why we do it this way. First I didn’t know where to start. Then I started to talk about when and how the idea for uxebu came about, that we decided online to found it and really met some months later. Thanks to our open source background and our history we wanted to continue the same spirit inside the company, I tried to show how and based on what facts we grow our team (the word “hiring” seems such a one-sided process). I realize now that I forgot a lot of the good stuff, but maybe this is the chance to make this become a separate talk to hold at other events.
I really loved the discussion and the questions that it had started, notes had been taken, a lot of critical questions came up and had been answered by Tobias and me. One interesting mentioning came up about an article which mentioned a company that pays the same salary to all employees. Thank you for all this input, I really enjoyed it and will definitely talk about this more and will prepare some more info next time.

JavaScript – a topic of big interest

We had founded uxebu purely for doing JavaScript consulting and pushing the limits and it is just really exciting to see how much interest this language is gaining in the last years. Not only jsconf the mother of all JavaScript events underlines this but also a lot of other conferences and events like fullfrontal, fronteers, js1k, 10k Apart, jQueryConf and so on which Béla Varga listed in his “JavaScript Rock’n Roll” session.
The “node.js” session and “JavaScript Rock’n Roll” (by Béla (@netzzwerg) and Tobias Schneider (@tobeytailor)) made it very obvious that JavaScript is a hot topic, the BarCamp was not necessarily overcrowded with programmers, but still those two sessions had been very well filled and the discussions had been really fun. The conclusion of the “node.js” session that Tobias drew and evangelized was “node.js is currently very hyped and just not yet ready for production, so use at your own risk, it’s not even alpha yet”. Everybody also agreed that node.js is not the new saviour and a replacement for Apache, it’s another tool you should add to your tool belt, use it when it comes in handy and be sure to know how and when to use it. Final conclusion was, as usual, if you should use it depends on what you want to do :).
Béla opened up the “JavaScript Rock’n Roll” session by giving a very good overview of what toolkits exist out there, who created them and what they are good for. He very well layed out some of the advantages and disadvantages, the rough corners and what is hard and what easy to learn. Shortly the discussion about the right JavaScript IDE came up but as usual there is no one-fits-all solution, choose yourself! Everybody was very carefully listening when @tobeytailor dove deep into the details of ECMAScript, JavaScript, the differences, the latest specification, the changes, prototypes, __proto__ and so on. Other interesting topics in those sessions had been promotejs, vapor.js, details about storage mechanisms, jQueryMobile, embedJS, apparat.io
That was real “JavaScript Rock’n Roll”!

Native vs. Web

On Saturday, the first day of the BarCamp, I had offered a session “Mobile: Native vs. Web” but didn’t see too many hands raised, so I just didn’t put it in the schedule, later some people asked me when this session would take place and that I should hold it on Sunday, which I fortunately then did together with Florian Detig. And I have to say I am very glad we did so, because 1) we (at uxebu) have a lot of awesome stuff to talk about and 2) it was really fun interacting with the audience and passing on all this information. It is always amazing again how much there is to say about how to create an app which can also be submitted into any of the various app stores by just using web technologies (the adult industry proved that again). HTML, CSS and JavaScript are just way to underestimated for being of good use in the mobile world. Florian first showed his awesome slides (I think they are really cool!). I continued the talk and dove a bit deeper into the mobile web topic, after my try of explaining the different movements in the native API space with players like W3C’s DAP, BONDI, JIL, WAC we deeply went into answering and discussing web technologies on mobile devices, I talked about our experiences, showed some projects we realized and answered a couple questions.
Not really a surprise but still impressing was the positive feedback we got when I showed of apparat.io, our soon to be launched service that will be able to convert a web app into a native app (You want to know about it first – follow @apparatio). The release date for the private beta will be the 25th October 2010, people who follow @apparatio will get accounts first. I also showed our project embedJS a toolkit (based on dojo) optimized for mobile usage.

All in all the BarCamp just made it obvious again that we are playing in an very interesting field and that we at uxebu are pushing the limits, that is fun, as much as the BarCamp was big fun, we will be back next time, for sure!
Thanks again and keep up the good work!

Making your web app iPhone ready

Note: you can visit the example used in this blog post from your iPhone here.

The most well-known and really most important meta tag you need to know about is the viewport meta-tag. It allows you to define the minimum and maximum zoom-level and whether or not the user is allowed to zoom into the view. You disable zooming by setting the minimum-scale to the same value as maximum-scale. At the same time you can define the viewport width and height by setting the “device-width” or “device-height” properties. If you have a website with a width of 960px and you want it to be zoomed in to fit exactly that width, all you need to do is to set width to 960. Since your website should run on several devices though with different resolutions it is not recommended to set an absolute width and instead use the predefined device-width and device-height values. This ensures that your viewport has exactly the size supported by the device.

Now lets get to the juicy part. When creating an HTML5 app for the iPhone you can define an icon which you will see on the start screen of your iPhone. Once you set this meta tag, the user won’t be able to see a difference between a native application and a web application on your iPhones homescreen.

To add even another level of detail you can define a startup screen for your application. This is especially useful when your application supports offline mode using cache manifests.

All of those features wouldn’t be complete if you couldn’t hide the browsers chrome once you start your application from the homescreen. To disable the chrome just insert following tag:

Now after you have added this meta tag you want to be able to differenciate between the user launching the app from the homescreen of the browser.

Last but not least you can even control the look and feel of the status bar on the top. You can either use the default status bar or a black status bar or a semi translucent status bar:

These are the most important things you need to know to make a simple website be HTML5 app ready on your iPhone (note: this only works on the iPhone but won’t hurt other devices and platforms). A “normal” user won’t be able to differentiate between a native or a HTML5 app anymore. Do you know of similar features of other phones? Do you think we should standardize the discussed features? (Some are already).

If you need support getting your website or web application HTML5 app ready, feel free to contact us.

Enjoy

Dowload

• Source
• Docs

Is the app store concept flawed?

Lately I have been reading more and more articles, tweets and blogposts stating their concerns about the fact that Apple almost randomly removes applications and that people for some reason have distorted views of the mobile application and app store reality.

I am not in favor of allowing any kind of application into an app store by default, there is no reason why you should have to do that (a bakery also selects which producs it wants to sell). The problem really is though, that Apple is running the only official app store for the iPhone. One app store controlling the entire market for a device is plainly wrong!

Not only does it cripple innovation but it also shows one major flaw of Apples strategy – the factor of competence. How on earth does Apple, a hardware and software manufacturer think it has the competence to judge whether an application should be admitted or not? Maybe in these days when mobile applications don’t go further than simple games or information display/exchange – but what if applications are starting to come with real security implications?

An example:
Imagine you are writing an application reading your heartrate and writing an ECG (This is not too far fetched, look at our research project HumanApi). Is Apple seriously trying to tell that they can judge whether such an app should make it into the app store or not? They by far don’t have the competence of the medical industry, no way!

A much more interesting app store concept would be to have certified stores by companies I trust (or community driven in other application use-cases). Looking at the medical example, wouldn’t it make much more sense if companies like Siemens, Phillips, and other medical device manufacturers start an alliance and run their own store, so I can trust the apps I am using, so that as a developer, I know that qualified people are judging my application? Not only would this guarantee much higher quality but it also would foster competition which we are lacking here.

Companies == lemmings?

Where does this “I need an app as well” come from? Why do people care so much when their application gets rejected by the Apple app store?

An example:
On february 23rd, large German online publisher Spiegel Online wrote an article about the fact that Apple might disapprove an application of the famous yellow press publisher “Bild“. On february 24th they posted another front-page article questioning whether legal means would be the only way to go?!?

Now that is insane, not only will it cost those folks a lot of money to run law suits against Apple, on top of that they are forcing their way into technology without future – already today, the Apple app store is not the only way to legally distribute your applications to the iPhone! Apple is a new player in the mobile industry and albeit its amazing achievements, never forget looking at marketshares.

To summarize: For whatever kind of reason, one of the biggest German online newspaper sees Apple rejecting applications as being threatening enough to write an article – how more blatantly can the reality be distorted?

What can and should we do?

Back to the surprising incident I was mentioning earlier: When the folks behind http://www.yourappshop.com showed me their application store – for the iPhone! – one thought came to my mind “Does the Adult Industry point the way (again)?” (whether you and I approve adult content or not is a different discussion, what we need to take out of this is the fact that they are showing a very viable way to go).

YourAppShop developed an app store entirely based on web technologies (lots of HTML5 which is supported by the iPhone browser and many many more devices) – which allows you to download web based applications to your homescreen, watch image slideshows, even videos. Everything works off- and online. To the well traveled mobile web developer all of this is nothing new, it is all part of HTML5. The folks of YourAppStore though were creative enough to build it so that the end-user does not feel the difference between a real native app (from the Apple store) and an application based on web technologies, payment for the service included!

Why don’t people (especially the folks in decision making positions) see that you can write amazing applications for the iPhone based on technology which also will work on other phones and which does not have to pass the QA of Apple?

If you are not too bothered about adult content (NSFW) take a look at http://www.yourappshop.com from within your iPhone browser and visit one of their stores – the way they have set up a viable ecosystem using web technologies will give you a new impression of what we actually are able to do today.

As much as people might have concerns with the adult industry, they are showing us how we can get out of the app store restrictions – technology of today can be used to write successful applications and you can be monetizing the potential (more than 8.000.000 downloads for YourAppShop should say enough), Now that sounds great doesn’t it @Bild.de and @Spiegel.de?

And as if its not enough, Apple itself is showing a great example of the potential of web applications running on the iPhone with their online help: http://help.apple.com/iphone – go visit their site, and add the application to your homescreen by clicking on the “+” button in the bottom toolbar (Not to mention the fact that iPhone applications where meant to be build using the web stack in the first place).

As an application developer/creator, your goal should not be to only run on one platform, unless you don’t care about having sustainable and solid business case or unless your target-group is only the group of iPhone users (which I can’t believe is ever true).

We showed that there is technology which allows you to write applications for more than one platform, technology which works whether there is an app store in between or not, technology which has a future, technology the web is built with – HTML/JavaScript/CSS or better, HTML5 apps. Use it and stop wasting time being afraid that Apple will ruin your business because they are rejecting an application – you shouldn’t have to care less!!

Conclusion

Jumping into the “We need to have an iPhone app” mantra without any second thought is very dangerous, its not good for your business. Analyze your requirements and check carefully if you can’t cover your needs with an application based on web technologies (which as we proved still can make it into the Apple store if they approve of your content). The advantage of applications based on web technology is overwhelming:

• Standardized technology stack (HTML5)
• HTML5 apps work in mobile browsers, can be distributed over app stores or even can be integrated into traditional websites.
• Much lower development costs.
• Huge amount of target platforms

Of course there are application cases where you need to access the devices hardware in ways the browser doesn’t yet allow you to (games or applications with extreme performance requirements for example) – but especially publishers and content driven apps should think twice.

If you are looking into building a mobile application and are not sure whether you should go for the native iPhone, native Android or any other native platform (and spend tons of money on it) or whether you should build on top of the much more open technology stack of the web, feel free to contact us and we can take a closer look at your requirements.

Back to the folks who are planning to sue Apple (VDZ) – start putting your apples into the right basket, build a web based application store as you can see with YourAppShop and you will have complete freedom over what you want to sell and what not. Your customers won’t feel the difference, they might even like it more because you can offer better prices (no profit sharing with Apple). Sueing Apple won’t help a thing, don’t waste your money and time.

Since that discussion, the idea developed further and after some time, things started to take shape.

Lets take a look at the first prototype of a web based application (is this the first JavaScript ECG ever?) which reads your heart rate, sends it to the mobile phone via bluetooth and displays it in a native application driven by PhoneGap, meaning – the actual application is written using JavaScript, HTML(5), CSS.

Because the quality of the above video isn’t that good I have recorded a screencast from the iPhone simulator. This video only shows the applications look and feel since the simulator is not connected to the Polar hardware via Bluetooth.

More videos are available here

After I got a first prototype running, the thoughts of what this could potentially mean would not stop popping up in my mind – the consequences for the web-development community are immense and the challenges we as web developers can face are broadened in a way that tons of exciting new things are lying ahead of us.

In this blogpost I will give you a quick outline the features of this prototype and the components I used.

Setup

To get the HumanApi ECG running I used following components:

• PhoneGap
• iPhone
• Polar T31
• Arduino BT
• HRMI
• btstack
• little stuff

Lets take a quick look at each of the components:

PhoneGap

PhoneGap is one of the really cool projects out there. It not only allows you to deploy JS, HTML and CSS based applications on a range of mobile phones but it also gives you great APIs to access features of the phone. Because the iPhone SDK allows us to evaluate JavaScript from within Objective C it is relatively simple to execute JavaScript calls within the webkit webview. This essentially allows you to communicate with for instance bluetooth. If more widget runtimes would give us possibilities to inject APIs into the runtime (W3C?) and make available in JavaScript we would be able to write very cool apps! (More on that in a different blogpost soon).

iPhone

besides the fact that Apple is blocking certain functionality of the phone (bluetooth for instance), it is an amazing device and allows you to do all kinds of stuff (e.g. inject JS into the webkit view). Its performance is very good as well and therefor makes a great prototyping device. To get this HumanApi prototype running I unfortunately had to jailbreak the device. We are slowly reaching a point in time where blocking device functionality will hurt Apple and other manufacturers/operators, they are locking their devices out from an amazing amount of possible application usecases.

Polar T31

The Polar T31 is a simple heart rate transmitter which you can use to monitor your heart rate when doing sports. This device is perfect for our prototype because we indirectly can send the data to our iPhone.

Arduino BT

Because I can not communicate between the iPhone and the Polar T31 directly I had to create a bridge using the Arduino BT. Essentially the Arduino receives the heart rate (using the HRMI) from the T31 and sends it to my iPhone via bluetooth.

HRMI

The human heart rate interface is a great little project by Dan Julio, who developed this hardware to receive the heart rate signal from the T31. Furthermore you can easily connect the HRMI to the Arduino BT and therefore send the heart rate to your iPhone via bluetooth.

btstack

As I wrote before, Apple does not allow to access the full bluetooth stack on the device – even though the hardware is available. Luckily Matthias Ringwald has developed a library for the iPhone which lets you access the different bluetooth profiles – without his amazing work this HumanApi prototype never would have been able to exist.

Your own HumanApi

If you want to develop your own application accessing hardware, feel free to contribute to the HumanApi project. There would be nothing more amazing than seeing for instance the ECG app running on Andriod and other platforms.

A good start are the articles on humanapi.org, the forum, the GIT repository or these folks on twitter: @nonken, @humanapi, @uxebu.

Conclusion

Essentially we are at a point where we as JavaScript developers could be writing applications we never thought of a few years ago. It is to us and to the industry now to demand that we get better and more access to the devices hardware – there is no reason why JavaScript developers get “discriminated” over native developers in the way how we can access device features

I want to close this article with a short comparison:

Often mobile developers, using web technologies, are compared to native developers on the example of games. “Ohhh but you can not write amazing 3D games using JavaScript” – funnily enough I even hear JavaScript developers trying to “defend” themselves agreeing to the above stated fact – “Yes we can’t write games, but phones are getting better so one day we will”.

We don’t need to make these kind of comparisons and should start demanding better access to the devices hardware. What stops us from saying “We don’t have to develop games, we can write home automation systems, medical applications (#mhealth), apps for the cars industry and so much more amazing stuff – and we can do it cross platform! (And WebGL is on its way btw. ;) )”?

Right now it is not the language which is stopping us. App store policies, manufacturers and operators are stopping us because we have to hack our way into the devices!

Enjoy hacking

The day started as planned with coffee and snacks and a Dojo introduction giving everybody who wasn’t really familiar with the Dojo Toolkit a better idea of what it actually is. A few demos such as xRay where shown to show some of the advanced features of Dojo such as live charting, custom themeing and much more.
After a short break we continued with a talk on how to design mobile architectures with the Dojo Toolkit for platforms such as PhoneGap, W3C widgets and other mobile platforms supporting JavaScript/HTML and CSS. This is a very interesting topic and it was great to share the experience we made at uxebu on finding viable solutions for the challenges we face. The third talk was a quick overview of the current documentation efforts for Dojo and different ways of finding the information you need when you are stuck or simply looking for API docs or similar.
Before the break, Tomer Mahlin from IBM in Jerusalem, who is working on the BIDI implementation in Dojo, gave a very interesting talk on the challenges, developers face when writing applications supporting BIDI. Not having to deal with the issues you get confronted with when having to develop BIDI applications, this talk was eye opening and very interesting.
After a great lunch we jumped into a hands on session building a very simple mobile app running on both PhoneGap and devices with a widget runtime supporting W3C widgets installed. This gave the audience a glimpse into mobile development and the challenges but also really exciting features.

In total there were about 45 people attending the event which is an amazing amount of people for such a first time event, thanks again to everyone attending and especially to Yoav Rubin and the folks at IBM to make this happen.

I am already looking forward to the next Dojo event in Israel and hope that we can be part of it again.

Following are the slides to give you a little impression of the events content.

Following some more details for the event. You can find all info also at the DojoCampus.org event page and things are still subject to change.

Location:

IBM Haifa Research Lab
Haifa University Campus

Google map

Time:

09:30 – 15:00

Schedule

09:30 – 10:00 – Gathering

10:00 – 10:15 – Welcome and introduction

10:15 – 10:45 – Overview of Dojo Dijit and Dojox

11:00 – 12:00 – Dojo and Mobile

12:00 – 12:30 – Dojo based JavaScript API Docs generator

12:30 – 13:00 – Hacking mobile (this session might be extended)

13:00 – 14:00 – Lunch

14:10 – 14:30 – Support for bidirectional languages in Dojo

14:30 – 15:00 – Projects demonstration

If you want to give a talk about your experience with Dojo or anything Web related, leave a comment at the DojoCampus.org event page or send an email to nonken(_at_) dojotoolkit.org and we’ll make sure you get added to the schedule.

After the main event we will either continue hacking or go for food/drinks/dojo.beers() into town.

If you would like to attend, please add your name to the list below, so we can be sure that we will have enough space.

Looking forward to being in Haifa and meeting lots of Dojo, web, JavaScript folks.

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 :-).