In this blogpost I want to give you a quick overview of the new structure, the setup, why we chose certain tech and how maybe you can draw some inspiration from our work.

Lets dive right into the nuts and bolts – a quick overview of how stuff works ^TM:

Content

In the past year a lot has happened at uxebu, new ideas were born, other ones where buried away – in essence we distilled out a concentrate of a few important factors we wanted to be reflected in the new website, while keeping some of the old ‘vibes’.

• We are a JavaScript tech company
• Our two sides of the coin are ‘business’ and ‘open source / incubator’ which we want to address much clearer
• The entire crew is what defines uxebu and we want to let that be reflected to the outside

We kept the site structure simple, basically one ‘CV’ style front-page, the team pages and our blog including articles and events.

Main focus of the front-page was to both showcase our commercial work and at the same time give insight into the open-source and incubating work we do – hopefully this distinction is clearly shown.

Tech

Our wishes for the new site are probably nothing new for most people setting up a website, but lets summarize anyways:

• Easy to maintain (preferably something like markdown)
• No CMS Xc%(*y$e(wy!!!!!!!!!!
• Support for most browsers, but no fancy tricks, if you support CSS3 gradients, good! If not, too bad
• Open source, all hosted on GitHub

These requirements resulted in us writing up a very simple markdown to HTML converter running on node.js.
Plain Markdown to HTML conversion was not enough in our case so we added the ability to define rendering blocks which you could use to map the Markdown tree to an object which then in return can be used as Mustache tags. This ensures that editing content stays super simple – I mean if you want, just browse the uxebu site on github ;)

Open source

The project is available on GitHub. If you have any questions or would like me to go into more detail on how everything works, feel free to leave a comment.

P.S.: Wait, did we just release yet another CMS ^TM ? ;) it just had to happen….

“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!

• David Aurelio (of TouchScroll fame) – Interface Styling & Scripting for WebKit Mobile
• Jens Arps (our storage expert) – The hitchhiker’s guide to client side persistent data storage
• Tobias Schneider (the uncomparable Gordon author) – Not your Mother’s JavaScript!
• Nikolai Onken (a Dojo senior) – Robotic JavaScript

and if you think you have something as cool as what you will see at JSConf you should contact us and we should talk about working together. We at uxebu are putting fun in the job first, actually we are trying to have fun all day and just call that work. Family and health are the top priorities in our company and the absolute base for doing a great job … oh and JavaScript is what we love, currently we are hacking it only on mobile (or as we like to name it “embedded”) devices. “Embedded” because we think JavaScript is not only hot on mobiles, but on TV’s in car dashboards and maybe even in your washing machine :)!? You know where we are going … are you as enthusiastic as we are? Come and talk to us at the JSConf, or if you have no ticket for JSConf yet give us enough reason to invite you there and get to know your geekiness :).
Let’s rock the mobile/embedded world …
Write us to contact@uxebu.com or find us on twitter @uxebu.

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.

dojo.beer(2)

In the evening of 5th December we’ve had our start for the dojo.beer(2) event in a nice bar in Munich, where about 10 Dojo enthusiasts attended to prepare for the official event the next day. During the evening Wolfram placed the bet, that more than 30 people will attend during the official dojo.beer(2) event. I lost that bet, because 32 people attended and I was really excited (still am), that so many people were interested in Dojo.

The next day we welcomed all attendees with a typical Bavarian Weisswurst. After the first meet and greet Wolfram collected Dojo topics people could talk about and everyone voted on those, followed by Nikolai, who gave a great overview of the most important Dojo components.
Then it was time for our special guests Dylan Schiemann and Pete Higgins who joined us via video chat and we talked about the current status of Dojo (just before that moment Dojo Version 1.2.3 was released) and what is planned for the future. Afterwards it was my job to explain the Dojo build system and how you can optimize a Dojo driven website (slides below). My talk was followed by Wolfram, who explained several Dojo features and later dived into the functional programming capabilities of Dojo (for further info, see the post of Shane O’Sullivan and for deeper insight a blog entry by Eugene Latzutkin). Nikolai then introduced Dojos new user documentation and gave a short preview of the new Dojo website. The last lecture was given by Norman Wenk (acomo), who demonstrated the Dojo widget system and explained the pitfalls, when creating your own. After a full day of Dojoness we went to a bar and ended with several dojo.beer(s).

dojo.beer(2) from Tobias von Klipstein on Vimeo.

Thanks to everyone who attended this event and I hope everyone enjoined it. I would particularly like to thank Mayflower who donated their office for that event and also like to note, that we wouldn’t had this amazing event without their support. Many Many Thanks!!!

More info about that event:

http://search.twitter.com/search?q=dojo.beer
http://your-bear.blogspot.com/2008/12/djbeer-in-munich.html
http://blog.thinkphp.de/archives/375-dojo.beer2.html
http://higginsforpresident.net/2008/12/back-in-business/

Webmontag Munich

On Monday, 8th December 2008, Wolfram and I went to the Webmontag event in Munich where Mihai Corlan, Platform Evangelist of Adobe, gave a good insight into technologies like Flex, Air and Zend AMF. Afterwards I’ve got the possibility to give an overview of Dojo, where I showed how Dojo evolved during the last year. At the end I showed some videos about Wavemaker, IBM’s Project Zero and the nice training application of Sitepen called Sensei to give an impression what you can reach with the Dojo Toolkit today.

I really enjoyed the round-table discussion about open source, the open web and how companies like Adobe fit in. Thanks to the Munich PHP-UG, Flex-UG and of course Raju Bitter, who altogether organized this nice event.

A Sidenote:

Mihai showed some interesting slides about a comparison James Ward made with his Census application. He shows the speed improvements of AMF in favour of JSON communication when transferring 5000 rows and more. This is a very special use case, I rather see the latest usability and interaction patterns stearing into the direction of loading just the data on demand that are really required. In most cases this big number of data is also hard for users to grasp. There is charting and some visual presentations that might require this load of data, but the optimization on the server will probably serve a better user experience here. An interesting read is Jared Jurkiewicz blog article about comparing these numbers with Dojo today, as the comparison of James Ward was made in April 2007.

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.

Uxebu is the company of the three web enthusistasts: Nikolai Onken (from Amsterdam, Holland), Tobias von Klipstein (Augsburg, Germany) and Wolfram Kriesing (Munich, Germany). We are specialized in providing you with knowledge and support for JavaScript and CSS tasks. For our customers we offer lessons about client side web development (AJAX, JavaScript, CSS, …). We provide customer support and help you to find out what is possible with those technologies, architect, implement and optimize your projects.

Since we met via the javascript toolkit dojo we are very much focusing on using it and are most efficient with it. But we know that there is not only dojo out there and we provide profound knowledge in JavaScript and CSS, we will support you with whatever toolkit or self-made solution you are using.
We focus on making your app fast!

Let us introduce ourselves so you know who you can work with.

Nikolai Onken – lives in Amsterdam and has a musician background. He is the one who is doing most of work on the dojo themes, he is our CSS God! He is the founder (together with Pete Higgins) of dojocampus.org (a great resource for dojo know how), an active dojo committer since beginning of 2008 and a driving force behind the european dojo community.

Tobias von Klipstein – from Augsburg, Germany (not far from Munich) has been freelancing already for more than eight years now in various areas and programming languages. After doing a lot of PHP and Java he does Python now and has found his place as an active member in the german django community. He is our linux expert and has made great dojo contributions.

Wolfram Kriesing – lives in Munich (Germany) and is already for eleven years in the IT business. From working with big MySQL databases to very early JavaScript applications back in 1999 he has a wide range of experience. He has been an active open source contributor for a while, working on projects like PEAR and has also become a dojo commiter in the year 2008.

Uxebu is in the process of being founded, paper work is still in the loop, but everything will be set very soon.
We are looking forward to work with you. You can contact us as contact [at] uxebu punto com.