On famo.us, semantic html and the future for web apps

Now with famo.us being out of private beta and the code being online I was eager to take a closer look.

I stumbled over this talk by Steve Newcomb the CEO of famo.us.

It’s *super* interesting to watch this stuff. Go watch it!

It would be very interesting to take some time to play with famo.us sometime soon. What’s interesting though is that it’s an entirely different paradigm than what AngularJS, Polymer, vue.js or even WebComponents are after.

They basically say that the gaming industry got rendering right (minute 43:35), and and the web industry got everything else right and they are trying to combine it. They don’t believe in semantically correct HTML for web apps. They say this stuff is for documents and no one should care about it building web apps. That’s also what Sencha is telling people.

It’s interesting and a part of me agrees with that. On the other hand, HTML is awesome for designers to work with. People even start building things *outside the browser* (think: githubs Atom editor) with web technology *because* of HTML/CSS.

I remember that working with Sencha was a pain from a designers perspective *because* you work very decoupled from the underlying HTML.

It really seems people are strongly divided about the direction the web is taking. Google seems to strongly believe in semantic html and to enrich it for web apps. Angular, Polymer, vue.js, WebComponents are all projects strongly driven by Google. From the perspective of a company driven by ad sales this makes perfect sense. Semantic markup has great value for Google as a search engine / ad selling company.

On the other hand there are companies like Apple, Sencha, Famo.us which do *not* believe this would be the right way forward.

I can’t say that I have a clear opinion about this stuff. Just that it’s an interesting observation.

StackWho is now ninya.io

A couple of weeks ago I blogged about StackWho - a project to search for users on StackOverflow by their location and skills. Today I’m happy to announce that StackWho is now ninya.io!

Why the new name?

I felt that it was just too tightly coupled to StackOverflow. I’m planning to increase the scope of the project by combining different sources. I’ll soon leave more words about that…

With the new name, we knew that it was also time for a really cool logo.


We were lucky to have @oriSomething join us and support the project with his awesome design skills! You should definitely send him hugs on twitter!

Is this a true open source project?

I have been asked this question a couple of times so I want make this 100 % clear: There isn’t a single bit of code of this project that is not on github or not covered by the MIT license. You find all the code at our ninya organization on github and if you ever find a repository that is missing the MIT license, just send a PR and I promise to merge it instantly. Everything about the project will remain open source as long as I am in charge of things. And btw, you should really star the project here!

That being said, I have bills to pay for this project and if you are feeling generous feel free to leave a tip here :)

What’s coming?

Yep, lots of things. There’s a new sync API brewing which will make it much easier to sync with more sources. It will also drop the postgresDB dependency.

It’s also planned to overhaul the entire design of the website and to create a real ninya blog. Stay tuned.

Tag related sorting just landed in StackWho

StackWho just got a nice update which makes it much more useful! Previously results were always sorted by the users reputation. That’s probably what one would expect if you only search by location.

However, once you start searching by tags you would probably expect that the sorting relates to such tags. Fortunately that’s exactly how things work now :)

This makes for some very interesting queries. If you combine multiple tags then the results will be sorted by the cumulated answer score of such tags.

For instance those are the users from Hannover, Germany sorted by cumulated answer score for the tags javascript, angularjs and git.

This is just scratching the surface of what’s planned for the future. I migrated the search to use ElasticSearch to expand the feature set. Previously the search was implemented on top of postgresSQL (used as a NoSQL DB) which was fine for the beginning but I felt I can move faster by migrating to ElasticSearch.

StackWho is entirely open source and MIT licensed, if you like to get involved, head over to the repository and help shaping it’s future. If you don’t like to directly contribute you can still help if you star the repository on github and share this blog post as much as you can :)

What out for more awesomeness coming soon!

Introducing StackWho

I’m working on this little side project and I thought I share some words about it.

So, I wanted to figure out other StackOverflow users from my city and filter them by skill set. Turns out that’s not possible by default with the search provided by StackOverflow. Oh wait, it is! They have a thing called “Candidate Search”. Unfortunately a one month subscription for the candidate search costs 1000 $.

And of course the API provided by StackOverflow doesn’t make it easy to run such queries either. However, what you can do is just scrape the entire[1] user data of StackOverflow and then build such a search yourself.

Introducing: StackWho.

It’s pretty rudimentary at this point. You can enter comma separated locations to combine users from multiple cities (or to alias different spellings) and you can enter multiple tags which the users should have as their top answer tags.

The data is continuously synchronized with StackOverflow[1] which means user data should usually be only a couple of days old. The frontend is written with AngularJS and the backend is built with NodeJS and split into a query and a sync part. It’s hosted on heroku. Everything is MIT licensed and I’m happy to merge Pull Requests :)

Also any feedback is highly welcome! Now go and check it out the top users from San Francisco & Berkeley with strong AngularJS or NodeJS skills: Check it out here!

[1] I currently only sync the top 150k users

A flexible team- five things to get right

On the first of November 2012 I joined CouchCommerce to lead the frontend development. Here are five things that I highly enjoy here and that I think make my life easier and more fun.

1. Use a notebook + monitor  approach rather than a PC + monitor approach

At my previous job I used a regular PC at the office with three monitors attached. Not that they forced me to use that, I could have had any system when I started my job. But since nobody worked on a notebook, it was the obvious choice to use a PC as well. It was the fasted machine one could think of. 16 GB Ram. Core i7. Fast SSD drives. The machine was super swift and never let me down.

At my new gig here at CouchCommerce everyone used MacBooks with only one monitor attached. Since every web developer seems to work on a MacBook these days it again was the obvious choice to align with that :) It’s the fastest retina MacBook you can  buy. I don’t like to make compromises when it comes to speed. I take my work seriously and same goes with my tooling.

It was a bit of a hassle at first to get used to work with only two physical screens but since you can use multiple virtual screens on OSX  I quickly got used to it. I don’t want to go into too much detail about how the switch to OSX went. There are plenty of other good posts on that topic.

The point is: using a notebook/MacBook + monitor is so much more convenient than using a stationary computer + monitor. Previously I used to work on three different machines:

- my office PC
- my PC at my home office
- my notebook

Multiple systems lead to multiple problems:

- I had to maintain three different machines with tooling, updates etc
- I often forgot to push code so when I worked from home I had to ask a team mate at the office to boot my computer. Or even worse I forgot to push code after a day of doing home office so I was lacking the code when I returned to the office

I really enjoy having only one system. I’m sometimes in the middle of a coding session when I decide to close the lid and go home. At home I can directly continue with my work. I also have the latest stuff with me. May it be on the train, at a conference or at the office. I also only reboot once every couple of months or so. That makes my life so much easier.

2. Be flexible.

That goes hand in hand with the previous issue. In my six month at CouchCommerce I already had four different work places. The team went from 4 people to 10 people within that time. We rearrange desks, switch offices just as it fits our needs. That also relates to everyone working on a MacBook. The setup is just super lightweight. We also regularly try out new software that has the potential to make our life easier.

3. Use dropbox and google docs for file Management.

I remember file management often was an issue at my previous job. We used to put documents on a central file server. Files went quickly out of date and manually versioning with multiple dated file names didn’t make it any easier.

I highly enjoy working with team mates together on one google doc. Everything stays in sync. Automatic version control makes sure nobody has to lose their sanity.

4. Use a company social network like yammer.

Well yammer, has it’s own dark corners. It’s not all milk and honey. However, we also tested several other company social networks and didn’t come across any better one so far. In general it really helps to get everyone up to date dramatically. It’s an important cornerstone of our communication. We always know about who is where. We share code improvements, interesting articles, fun stuff, being off, doing home office.

5. Speak english. Prepare to go international.

One thing that always bothered me at my previous employer was that we used too much German. Code comments where made in German. Some variable or methods where named in German. Technical documents where written entirely in German. That makes it much harder to scale the team.

Here at CouchCommerce three of my team mates don’t speak German as their mother language. We use ca. 95 % English when communicating through yammer and  at least 60% English when talking directly to each other at the office. Our product was designed English-first, German-second. All our technical documents, the entire code base everything is entirely written in English. We can easily scale our team and employ people from all around the world.
Those things might or might not work for your. Works for us.

Improving the hannoverjs.de site

A couple of days ago we came together again at the EDELSTALL to have our regulary hannoverjs meetup. It was that day when someone on Facebook asked me where he should have looked to figure out the date earlier.

My immediate rection was: “It’s every two month and it’s the fourth Thursday.”

Well, while me and a couple of others now about the rhythm and it’s also mentioned on the hannoverjs.de site, we shouldn’t assume that everyone does. It’s a huge fail when we rely on the assumption that everybody knows about that for sure.

So I pulled up my sleeves and automated the appearance of the date on our website so that it always points to the correct next date for our event.

And while I was at it, I rewrote the whole page with AngularJS (it previously used jQuery and Backbone). One of the benefits is that the talk section is much more maintainable now.

1. All talks for one event are written in it’s own file which follows the pattern MM_YYYY.tpl.html (Example)

2. Old talks can be viewed by just changing the date in the URL. (http://hannoverjs.github.com/hannoverjs.de/#/talks/01/2013)
(but I didn’t finish to extract the complete history from the commit logs yet)

3. There’s a default talk template which is automatically shown when nobody added a talk for the upcoming meetup yet.
So whenever one views the talk section, it should always make sense :)
On a side note: when you feel something about the site or the meetup in general could be improved. Don’t hesitate. Send PRs. Get in touch. We are a community.

From jQuery Deferred to RxJS ForkJoin

In a recent posting I blogged about how to process some code after several asynchronous operations have finished and how to access each return value of those operations no matter in which order those would finish.

To make this happen I used the new jQuery Deferred API. While this is a great way, I would also like to show you that there are other (even more advanced) ways to do so.

One of my heart warming interests is to dig deep into reactive functional programming and therefore digging into RxJS.

So let’s see how we can rewrite our example to make use of RxJS!


    var example = function (){
        var deferred = new Rx.AsyncSubject();

        }, 1000); //Will finish first

        return deferred;

    var example2 = function (){
        var deferred = new Rx.AsyncSubject();

        }, 2000); //Will finish second

        return deferred;

      .ForkJoin(Example(), Example2())
            console.log("Example1 (Should be 5): " + args[0]);
            console.log("Example2 (Should be 10): " + args[1]);

As you can see, nothing ground shaking happened to our code. Things are just named slightly different.

Did we gain anything? Yes, we did! ForkJoin not only combines two observable streames and waits until both have finished, but in fact returns a new observable stream. Having an observable stream as an first class object is a major benefit! For example, let’s say we are only interested if first stream matches a certain condition. We can just filter out the undesired values using the Where operator.

      .ForkJoin(Example(), Example2())
      .Where(function(x){ return x[0] == 5; })
            console.log("Example1 (Should be 5): " + args[0]);
            console.log("Example2 (Should be 10): " + args[1]);

And once again, the Where operator returns a new observable stream. This is great in terms of composability. You can easily just hand this new observable stream over to another component which will react on a stream of data that exactly matches the conditions the component was intended for.

Having events as first class citizen which you can compose and pass on, is what makes Rx so great.

Read my random notes on twitter


Get every new post delivered to your Inbox.