The task

I have a set of methods and want to find out if they are implemented. See the code below, sorted in logical order.

And the tests for forMethods() as the user expects it to work, without mocking (or spying).

This works fine as long as I don’t change any of the underlying functions or a requirement that is implemented in some function other than the forMethods() function that I have tests for. For example, I define a dummyFunction myself var dummyFunction = function(){ console.warn('not implemented') } to allow also function(){} to be a valid method, which was not the case yet. I change the first test to

and add a new test

Due to the new requirement I get two failing tests.

But I don’t see exactly where my code fails due to this new requirement. The tests tell me forMethods() fails, but there is a chain of four functions below. So let’s write a test for getNumberOfImplementedMethods() used by forMethods().

The last one of those tests fails too

Now I actually get more and more failing tests. Ouch, that hurts and I loose the overview quickly. In my mind I am kinda “yeah I know this one fails, it will fall into place once I am getting there”. Doesn’t feel good and if I get interrupted at this point I might come back and be very unhappy about so many failing tests. Anyway, let’s go one level deeper, and write tests for isMethodImplemented(), more failing tests. Writing tests for the last function and fixing the code accordingly will solve our dilemma here:

Both of the tests fail.

Of course they fail, since I didn’t fix the actual code that compares the dummyFunction, so I fix the implementation of getMethodDetails() to compare the method to this.dummyFunction and not function(){} anymore

If I run the tests now all of them are passing. Fine.

That was a little painful. I had to go all the way down the rabbit hole to find the actual problem. If I imagine this in a bigger architecture I know why I rather start writing tests early, also with the danger of them getting thrown away, because the code becomes obsolete, gets rewritten etc. That’s fine.

Let’s try another approach. I write some mock tests and see if that gets me any further quicker.

Notice, that those tests do also test forMethods() but none of them fails. So it seems I have no problem on that level. Now I can write simple tests for each function. And I will get down to the tests I wrote above for getMethodDetails() and at this point I will discover the actual failure. So mocking leaves me with a way better feeling since I don’t just add another failing test in the hope of getting to the actual failure at some point.
Let me discuss in the following why I think it makes sense to mix both approaches why I think that there is not only one way to do it. The mix has to be right.

Not Mocking

How I started by not mocking anything, was a logical start. I have the user’s view, and in our case the API user just wants to get the result if a set of methods is implemented. Over time four methods came along, that forMethods() used. At some point when the hierarchy becomes deeper, esp. when functions get reused in multiple parts you start writing tests for the functions on the level below. Those tests are definitely a good thing, since you gain confidence in the underlying parts.
The problem I faced a couple of times was if I change a requirement that is handled by the fourth function down the hierarchy I get failing tests for all four functions. That means you need to know where to look first, either you know your code well or you have sorted the tests to run in a certain order, so that the failing functions lowest in the hierarchy show up first and you can work top down. But even knowing how to put them in the right order requires knowledge of the entire architecture and dependencies. And that will fail when your team grows because not everyone knows how to sort the tests right. And maintaining such an order will become tedious task and is prone to errors.
But non-mocking tests are an important part of testing, they allow me to stay on the same level where the API is used and I don’t loose the real use cases out of sight, but still they might be misleading.

Mocking

I experienced that starting out with mock tests is not the way to go either. I would nail down too many dependencies too soon. Therefore I stay with unmocked tests for the most part in the beginning, but once the architecture shapes I start mocking away stuff and therefore decoupling the different levels. In the above case I can easily find errors on each of the four levels by having mock tests. Yes, a mock test is describing the implementation closer, but if the requirements change the implementation might change too and then it is ok to change the according tests too. The great thing is that I can focus on one level of implementation and I am confident that the levels below are working so by mocking I am just assuring that each of the working pieces is just wired up correctly.
The mock tests do also have the advantage of running much faster since underlying functionality is not invoked that often. Asynchronous behavior can also be avoided nicely this way.
So it’s still a learning path for me and finding the right balance turns out to be the important thing.

Conclusion

I decided to have three sets of tests, which are always grouped into their own describe() each:

Now I would need a way to run all the “mocked” tests only to see just those failures. If I don’t touch jasmine I guess I will have to continue identifying the failing mock tests by searching for the suffix.
The unmocked tests will fall into place later too, if that is not the case I have an edge case that I didn’t write a mock test for yet, so I will need to do that.
One question that still keeps going around in my head is: are those unmocked tests actually integration tests, or as bad as them?

I am looking forward to input. How do you do it? What can I improve? If someone learned something here I am happy. And please share your experiences too, I want to learn too.
Find the source code on github.

isArray()

There are a lot of ways to check for a variable being an array, but the safest one and also most promoted and secure one is

Some examples from the console demostrate well how to use it and that it really works :)

Convert arguments to an array

One of the pains JavaScript developers have to fight with which will get solved with future versions (fortunately) is that the arguments object looks like an array, e.g. it has the property length but you can’t work with it as if it was an array, e.g. here:

But their is a workaround until the language handles it. It is

Range function, or mimic “x = [3..25]“

Sometimes you need just a plain array with a set of numbers of a certain range, i.e. when generating a set of chars, like all upper case characters. But there is no “x = [1..5]” in JavaScript yet(!). But I needed one, and it’s easy to make one, as you can see:

Padding a string

Sometimes you want to pad numbers with zeros e.g. to align them on the console. Here is how I did that:

The -3 is the number*-1 of characters my string shall have in the end. I am adding two zeros at the beginning, because I am sure that a number is never an empty string. And after the string concatenation I just take only the last three characters. Simple but works nice without any kind of IFs or complex logic.

array.unique()

PHP has a hell lot of array functions, a bit wild – yeah. But sometimes you wished you had them all too. A unique() function is one of those that I just needed lately again, so here is a simple one:

So have fun, hope something was useful.

Why you’d like to use HTML5 audio in iOS 5

It’s all about apps these days. The question is whether you want to make the commitment and investment (of learning a new language) to program natively for one platform or leverage the web dev skills you already have? HTML5 is the way to go if you sympathize with the latter.

Let’s face it: The main problem for web developers that want to make apps is to deliver a great user experience. Hence, you’d like to use as much of today’s web technologies as possible to enhance the UX. One profound way of doing this is audio feedback. For example, many twitter apps use sounds if new tweets come in and another sound if no new tweets could be found. This kind of response is intuitive to the user. This is what you should go for.

Also, imagine a game without sounds. Would be kind of boring, wouldn’t it?

Naive Assumptions: What you’d expect

Fortunately in iOS we have rich HTML5 support built into mobile Safari. Initially, Steve Jobs wanted all apps to be web apps! So what you’d assume regarding audio is the presence of the HTML5 audio tag. And guess what, there is an implementation of the audio tag in iOS. Hurray!

So what do you expect from an audio tag implementation:

• call .load(), .play(), .pause() and other methods via JavaScript
• use remote files, dataURIs, cached files and other sources
• play several audio files / tags at once
• mix audio from several sources with different volumes, etc.

Reality checks: What should work but doesn’t

It becomes clear pretty fast that it’s not that simple. With iOS it’s a disaster. The bad news first:

It is not possible to load or play audio without user interaction.

Sad, but true. Apple deliberately decided that a touch event is mandatory to load and play audio. There is no workaround for this.

If we accept the fact that we need a touch event to play the audio, is it possible to use the audio tag as expected? Hmm, no, not really. So what’s broken as well?

Latency: Loading audio files on demand (after the touch event fired) is unusably slow. The desired user experience can not be achieved using this technique.

One audio tag at a time: You can never play more than one audio tag at once. This makes it impossible to mix sounds on the fly which would be necessary for games that have a background music and must also play sounds dynamically (e.g. when the character jumps).

Audio files only: You can not use anything as the source besides audio files (uncompressed WAV and AIF audio, MP3 audio, and AAC-LC or HE-AAC audio). If you could use dataURIs then it would be possible to preload the audio.

Workarounds: How to play anyways (at least somehow)

We invested a lot of time researching the audio tag on iOS 5. If you want to know how we play audio, read on.

So what do you do with this crippled audio tag? Well, you trick it a little bit and use it as much as possible. Here are several ideas that work best for different scenarios:

Bind touchstart event to body: As you have to play on a touch event, we bind a touchstart handler on the body. So wherever the user touches first, we can use this event to load the audio file. Even better, from now on, we can load and play different sources from this audio tag.

Hot swapping sources: We can now change the “activated” audio tag’s source on the fly. So it is now possible – without user interaction (!) – to load and play different sources. But you can only play one source at a time, of course.

Use audio sprites: The guys over at Zynga use audio sprites in their Jukebox. This means that you have a huge audio file containing one sound that you want to play, then one second of silence, then another sound and so on.

Example for a sound sprite structure:
1 second silence
First sound
1 second silence
Second sound
1 second silence
Third sound

In this file you include all the audio that you possibly want to play in your app. You only load the source once (as described above) and then jump to the relevant parts in the file. So the file is always playing but most of the time it just plays silence. When you need the sound, you can quickly jump to the part in the file that you need to play. This solution is quick (much faster than hot swapping!) but requires a long preloading phase before you can play the most sounds, because the file is bigger.

tl;dr

So audio in iOS is pretty much broken. If you are using a native wrapper like PhoneGap you could use native APIs via plugins like SoundPlug. We’ll try what is possible in the upcoming versions of iOS. Please let us know your ideas and feedback in the comments.

Update:

Regarding Philip’s comment, this is how we think it could be.

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

If I can’t debug, for whatever reason and have to fall back to console.log()s you normally see my code looking like this:

You can see two things here:

• the first line prints out a variable’s value, simple I guess
• all console.log()s are not indented at all

Let me touch on the “not indenting” first.
I don’t like to indent console.log()s because this just makes the code look ugly, and that is intentional, because console.log() normally just doesn’t belong in the code. By making the code look ugly I am quickly forced to remove them again, the latest I will stumble on it before committing, because I never commit without looking at the diff.
If I ever forget to remove the console.log() I can be sure that a coworker will be annoyed by it and hopefully either ping me or remove it. But I am trying my best not to forget it :).

Komodo macro

Back to the first console.log() you see in the code example up there, that one is actually one keystroke away for me, I have hacked a simple macro in my editor (Komodo Edit) that takes the text I selected and creates a console.log() in the line below throwing out this variable and it’s value.
This little script looks like this:

Just create a new macro with it and attach a key-combination to it and logging a variable is just one key stroke away.

Create a string of sequenced numbers

That is definitely not the solution I really like, but that’s the one I have decided on (just because I don’t remember the cool one I had created some time ago, and I can’t find it).

Chop of the last character of a string

[Update]
Doh, thx to Sebastian this is actually really easy :)

[/Update]

Actually this one works (could work) for any number of character, that you want to chop off the end of a string. After throwing ideas forth and back on twitter, this one was the outcome.

I like this approach.

Convert int to hex

Thanks to John I learned after a couple (more complex) approaches that converting decimal numbers into hexadecimals is as easy as:

If you wonder now how to convert back, from a hex number to a decimal, try this on your JavaScript console.

Easy, ha!?

Have fun snippeting around, I hope some was helpful.

seems good to me.
Now in Python:

Way to go. Now comes the biting part:

Was obvious right, yes it was, but Python does it more intuitively.
PS: I know the uber geeks will just yawn, but that’s ok.
PS2: I just decided to start sharing bits and pieces of code again by blogging. Sometimes I need them again. I used to do that on my private blog but didn’t continue, so now I restart and hope to continue.

Uxebu is now operating it’s business purely in the JavaScript space for about three years (oh that reminds me we should have a party!). We are convinced that JavaScript is ramping up now and we see that there are more and more things done and possible with the language. The browser landscape is developing rapidly and changing every day. The mobile industry is pushing the limits and we are helping to do our part in it. We learned a lot and are still learning. As it is in the nature of our company to spread our knowledge to allow everyone to use the technology at it’s best and push the limits with us, we think now it’s the time that we share our knowledge and pass it on to those hungering for diving into JavaScript!

We really have gathered a lot of bright, bleeding-edge people and each of us is learning from another everyday. If you want to get some of the know how (at least as much as we can pass on in a two day workshop) you are invited to join our workshops. There will be one held in Munich 29th and 30th of June and another one in Amsterdam 11th and 12th of July. We will always have at least two uxebus teaching you the latest and hottest. We might even have some of the latest bleeding-edge mobile devices for you to run the app you will develop in the workshop.

Workshop Details

In this course we will cover a broad spectrum from JavaScript essentials to the bleeding edge of cross platform HTML5 development. We start from the ground up and go step by step, depending on the level of the participants we accelerate to show you the deep and dark sides of JavaScript.

Each day of the course is split into an intensive “knowledge transfer” session in the morning and a hands on hacking workshop in the afternoon in which you will apply the contents learned during the morning. At the end you will have touched all contents not only through theory but also through intensive real life application and coding.

Note that this course will not explain you how to work with jQuery and also not how to work without jQuery. The course mainly focuses on JavaScript, mobile and HTML5.

Day 1 (part 1) – JavaScript

We start with a small overview of the history. We tackle the basic structure of the language and move on with statements, expressions, functions and objects. We touch the different operators and when semi colons are introduced.

We continue our way through the JavaScript landscape by taking a look at objects, properties and built-in functionality. At that point we’ll encounter our first major obstacles; scopes and closures. Once we conquer these we touch on the difference between functions and constructors. This is followed by our second major obstacle; prototype and the various values of the this keyword.

Day 1 (part 2) – Hackday: HTML5, CSS3

During the second part of day one, we will take what we have learned in the morning and mix it with a little shot of HTML5 fanciness. We will look at all those new APIs we can now access on our (mobile) devices to bring JavaScript to a new level. We will include cool APIs such as the Audio API, Video API, history, Canvas, SVG, File API, WebGL, DeviceMotion, WebWorkers, WebSocket, GPS – and if all ingredients fit well you might just end up with your first app written in JavaScript.

Day 2 (part 1) – The App Day

During the second day we willl continue with timers, callbacks, web workers, eval and the future of JavaScript. The speed of the course is matched with it’s participants. The important parts of the languages will be handled in the workshop. During the first part of day two we will also specifically look into topics which you want to cover after determining those during day one. This will give you the chance to get all your open questions answered so that you have your pockets full of knowledge after the workshop is over.

Day 2 – part two (Mobile)

JavaScript has grown strongly into the mobile space, so we will show you how to get the app you have started building during day one onto mobile devices. You will learn about media queries, some device sensors, performance and HTML5/CSS3/JavaScript tricks and how to optimize some parts for mobile and how to make a native app out of it, so you finally could even make get it into the app store and make money with it.

Now you want to join our workshop?

Join us either

• in Munich 29th and 30th of Juneor
• in Amsterdam 11th and 12th of July

Dojo also comes with two fresh implementations for the API, a non-persistent memory store and a JsonRest store that interacts with a server through RESTful HTTP requests. You can also observe changes made to objects in the store. What is missing is a store that uses a client-side persistent backend, which would be useful for a couple of reasons (e.g., as one commenter in that post asks, to use it as chache store for dojo.store.Cache). As Kris already mentions, it’s a piece of cake to create one, so let’s go ahead and do it!

Choosing the Backend

The post mentions two possible candidates: dojox.storage and StorageJS, both already having a similar API, so making them compliant to the Dojo Object Store API is fairly easy. For this tutorial I choose StorageJS – because it is very lightweight and still provides all we need (and, well, for a couple of other reasons that don’t belong in this post). So, what is the exact API we need to comply to? Check it out in the docs. See the first sentence in that paragraph? “Every method in the API is optional, it’s presence indicating support for that feature.” Wow, that’s nice!

Basic compliance

Let’s start with the methods get(), put(), add() and remove(). That will make our store pretty usable for most store scenarios.

First, create a ‘store’ object we can work with (StorageJS creates a global variable called storage where all it’s methods reside):

‘store’ now contains everything that ‘storage’ does, but we can leave the original ‘storage’ object alone and modify our ‘store’ object if needed. Time for the first method, let’s start with get(). StorageJS works with Strings as keys and values only, so we need to parse what we get from it.

Easy one, now move on to put(). The Object Store API allows user to do stuff like this: store.put({foo: 'bar'}, {id: 3}) as well as store.put({id: 3, foo: 'bar'}). Also, StorageJS only has the method set() instead of put() and add().

Easy, as well – you could write this as a one-liner. Now, add(). It’s close to put, except that it won’t overwrite data that already exists. So we just need to check if something with the given id already exists and throw an error if so.

What about remove()? Nothing to do there, it already has the desired signature and functionality.

That’s it, we’re done with basic compliance. Our ‘store’ object now implements the basic methods of the Dojo Object Store API and can be used by anything that can work with a Dojo Object Store – and it will keep it’s state persistent in the browser.

More compliance? Querying!

There’s one interesting thing in the API: the query() method. Uh, yeah, we want that! Lucky us, Dojo already provides a query engine as well as a method that makes sure there are iterative methods and a total property containing the number of hits available in our result (well, it also abstracts away the differences between sync and async results, but as StorageJS is purely synchronous, this is not important to us). First, define a queryEngine:

So, if we want our store to be able to run queries, all we need to do is to take the store’s data and hand it over to the query engine. We use StorageJS’ getAll() method to acquire the data. It will return an array of objects in the form { key: ‘theKey’, value: ‘theValue’}, but the queryEngine wants an array containing only the objects, so we need to do a conversion.

Now we can query our store for specific data, like so: var results = store.query({ prime: true }); This will give us all objects in the store that have a property called ‘prime’ and have that property set to true.

Hierarchie and Transactions

The API also mentions methods about data hierarchie and transactions, but I’m not going to cover these in this tutorial.

Convenience and Optimization

Currently, every time we run a query, we fetch all data again from our storage engine. So, if you don’t have a massive amount of data and want to query the store a lot, it might be wise to maintain a copy of all data in memory. There are other things you could optimize as well – or you could write your own queryEngine.

For your convenience,  here’s a wrapper that creates a Dojo Object Store like we did above and accepts a useMemory parameter during instantiation that denotes whether a copy of the data should be kept in memory or not. It uses the traditional require/provide instead of the AMD format. If you want to use it, make sure you use the right namespace in the declare() call! (Or, not recommended, copy it in the /dojo/store directory.)

If you want to fool around with it in the console first, you can go here (non-memory-using) or here (memory-using), check out the source and fire up the console and try things out.

Getting StorageJS

The above code uses the features base and getAll, so you could do a specific build of StorageJS with these features or just grab a full build of it for your desired storage engine (the storage-full-[engine].js files). If you don’t know about storage engines, all modern browser support localStorage, so this is the one what you might want.

Coworking in Valencia

My week in Valencia started out to look very quiet and just pure work. I tried to contact some JavaScript/mobile/web guys in this area before hand, but somehow didn’t really succeed. Some tweets went around but I didn’t really reach anybody. But I made sure I have a great place to work at, which was Coworking Valencia, Rosa Montesa runs this place with so much passion – wow. And I just had to think of the Combinat56 Coworking space in Munich where we normally go, which is run by Sina with an equal lot of passion. Just great girls!

So I arrived there Monday morning to do my work, and off it went. I chatted a while with Rosa and some other coworkers and from there I couldn’t stop it. At the end of the day my calendar was filled with lunches and meetups. I met a lot of interesting people, first Rosa had organized a small come-together the next day with the company Brainstorm from right above, mainly hackers too, so we had quite some stuff in common. There I met Jorge who introduced me to more geeky people, thank you so much!

Spanish way of life

So the week went on and I tried to work a little bit, but I was basically so happy to live the spanish way of life a little bit. In the morning you don’t buy a take away coffee, actually you don’t see the busy people running around with their coffee mugs in there hands. I also just did that the first day, after that I adopted the spanish way, which is sitting down in a bar (also if it just for five minutes) and have a coffee. A lot of people there have a carajillo in the morning but that was not appropriate for my mornings :).
For lunch (later than normal for me, around after 2pm) we mostly went to some place outside, since it was at least 20°C, beautiful sun just perfect. And then on the way home you just take some tapas maybe a beer in the bar around the corner and late at night (normally after 9pm) we had dinner. For me working there felt really comfortable and easy going. But I have also heard that normally working in Spain is not normally that relaxed.

The real geeks

On Thursday I went to the BeCode guys’ office in the nice Barrio del Carmen. The first thing after I arrived was “let’s go for a coffee” :). That is the spanish style! We exchanged the ideas of how we work and the kind of projects we do. Xavi the daddy of BeCode (scnr) told me that they are an incubator and try to have people come in and realize their ideas, pretty cool stuff. Was so refreshing and forward-thinking, I felt home.
Funny enough that day I learned about Jasmine there, they used in a project. Unfortunately we had no internet that day, so I was pretty much offline until the afternoon, which was somehow good, but not when you really want to get some things done. So I promised to be back the next day and then the office was also really crowded and I got to meet all of the BeCode team. In the evening I joined my first coding dojo, this one was held in the offices of OpenFinance. We were given the task to write a roman to latin numbers converter in whatever programming language you like. You are given half an hour and try to get as far as you can, I joined forces with Jaume we got it easily done in the half an hour time, we simply used the webtestsuite as our testing framework since I know that one best and of course we wrote the converter in JavaScript :). As a second Kata you could hack the conversion the other way around. Jaume and I felt that this would be just another hacking it the other way job was, so we looked for a new challenge and we said let’s just use the google search engine for converting it for us and we just grab the result from there. We looked at a couple of APIs, at YQL but there was no real solution, so we went the scraping route. We got it almost done :). But as you can see and read we had lots of fun and enough beer!
Of course we went for dinner later and were still hanging out some time around Valencia and in the BeCode office later. There the guys told me about an Code Retreat which is going to take place somewhere near Valencia “en el campo” with Paella cooking and hacking, I hope that some of us uxebus may join, hope to find out details soon.

All in all a big thank you to all you guys and I can just say I had a great, though also really exhausting, two weeks in Spain. Hope to see you soon!