Our NanoMCU arrived


by Jacob Dawid on July 13th, 2015

The NanoMCU is tiny, low-cost device featuring an ESP8266 SoC by Espressif Systems. At a price point of only 10 € (incl. shipping costs, price for 1 pc) this small all-in-one computer presents a strong offer. The technical specifications of the ESP8266 have been released to the general public by the chip manufacturer along with an SDK, which led to many different firmwares being developed within an extremely short amount of time. Hardware manufacturers developed similar devices like the MOD-WIFI-ESP8266-DEV by Olimex or the ESP8266 add-on module for Arduino.

image20150713_144047225

The key features of ESP8266 based devices like the NanoMCU are the ready to use integrated WiFi chip, direct IO, low power consumption, low price and open specifications.


Developing for Ubuntu Phone


by 9elements on July 8th, 2015

Our Ubuntu Phone finally arrived! At the end of June Meizu released their latest Ubuntu Smartphone. With the MX4 being the first high-end Ubuntu Phone available on the market, we feel like we’re ready for development.

Ubuntu Phone Meizu

Ubuntu Phone OS is using Qt as the development foundation framework, sporting QML, a brand new declarative language for designing state-of-the-art native speed applications capable of running on all major platforms. Speaking of today, we’re not sure if the Ubuntu Phone and QML will attract a larger market in the future, but it’s a really exciting piece of technology. We have already experienced how ressource-efficient developing mobile apps with QML can be. In any case, we keep an eye on this interesting trend.


German Valley Week Review


by Sebastian Deutsch on June 12th, 2015
Comments Off

San Francisco

I just returned from my German Valley Week trip to San Francisco and the Silicon Valley. German Valley Week is an organized trip where entrepeneurs, investors and politicians from Germany visit disrupting startups ranging from new ones like Uber or Stripe to established companies like Google or Facebook. Each day we visited two or three companies and got an idea how they started, grew and eventually scaled out to unicorns.

Culture

The first thing you notice when visiting one of these companies is that they radiate a special company culture. Company culture is the most important thing besides having a great idea and kick ass engineers. John Collison puts it straight: “You want to work with enjoyable people. And nowadays companies don’t hire the best talent. People are joining companies.” A lot of these startups create workspaces that focus on self expressiveness and creativity. Some foster living a healthy lifestyle: most of them had a cafeteria that served fresh healthy food. The borders between working and living blur. Radiating the company values is important, so they have motivational posters or art in their offices. (Facebook: No problem at Facebook is someone elses problem).

Educate

All startups we visited try to keep their employees educated all the time. Teams present their learnings, often across departments. Sales learns from devs. Devs learn from sales. And it never stops. If you use the men’s bathroom at Facebook there is a “Developer Learning Snippet” and a marketing update above or in front of the toilet. They have walls that reiterate what value means for their customers. They’ve streamlined the onboarding process for new employees to perfection. Most startups have multiple big infoscreens showing progress, traction and sometimes even sales data. This kind of communication embraces deep understanding of the business in all units.

Think big

There is a german rap song by Deichkind called “Denken Sie Groß” (Think Big). One line goes: “Don’t build a terraced house, build a suburb… where you rule like a warlord. Think big!”. It’s true for everything that I’ve seen. Uber has big info screens that show realtime usage in every major city that they have expanded to so far. Facebook built a fucking Disney-esque campus to retain and entertain their employees. Sometimes a company has a very simple product – but it still takes a hundred engineers to improve it to stay ahead of the competition.

Thanks

These were my key impressions. There was more like meeting great people like Andy Bechtholsheim, Tim Chang and many more. It was overwhelming and too much to put it in one blog post. Big thanks to Kathrin Zibis, Chris Tegge and Nathan Williams for organizing such a great event. Also thanks to Stefan Peukert and Tom Bachem for nudging me come with you. I would definitively do it again.

 


Go in Production


by Sebastian Deutsch on March 6th, 2015
Comments Off

go_cover

Some of our projects are gaining traction lately. That’s why we need to scale some parts of the infrastructure. 9elements started the search for a language that gives us more performance but that’s also expressive and easy to write. Since Go is used by some high profile projects we decided to give it a shot.

Go is a very simple language: It is typed statically. It is garbage collected so you don’t have to worry about memory issues. It has built-in support for concurrency. The most powerful feature is the absense of classic objects with methods. You have structs like in C. And you have functions that can have receivers so that they can operate on structs, but there is no direct concept of inheritance – though you can imitate it with anonymous fields. The most powerful concept are interfaces. Have you ever seen a bigger Java or C++ architecture where almost every class had an interface so that you can swap out the implementation. Go is like “Hey, let’s get rid of the classes and just focus on interfaces!”

But Go also has some drawbacks: Coming from a Ruby background the language is not very expressive. You can do some meta programming using struct tags (it’s like annotations in Java for structs) together with reflection, but the possibilities are limited. Especially if you’re overusing struct tags your code becomes quite illegible. All in all I think that the pros weigh more than the cons so we decided to use it in production.

Since we’re mostly building web applications it was a natural thing to build a web application. The next step was to check out the Go ecosystem to do so. We’ve taken a look at the following web frameworks:

  • Beego – Beego is a full stack web framework. It seems to be pretty popular but we were searching for something more lightweigt.
  • Revel – Same goes for Revel.
  • Martini – Martini is also one of the more popular Go web frameworks by Codegangsta. But it is abandoned by it’s author due to that it’s source is not very Go idiomatic.
  • Negrino – It’s by the same author like Martini, but it is broken down to smaller components and written in Go idiomatic code.

Eventually we went with Negrino since it is lightweight and we didn’t want to swap out a monolithic framework (Rails) with another monolithic framework. We wanted something small that does a few things really well. We went with GORM for the database management, which seemed to be the best object relational manager (didn’t we say earlier doesn’t have objects?) out there.

The application we’ve written is a small service that does autocompletion for German cities and ZIP numbers and it also provides the geolocations for it. We were able to drive down response times from 50ms to 7ms which is quite awesome. All in all it was a great experience to rewrite that service in Go and in the future we’ll probably use Go as a great sidekick technology for Rails.

If you like what you’re reading and you also want to play with these technologies – 9elements is hiring.


Using qt-pods to share your code


by 9elements on February 9th, 2015
Comments Off

Adding dependencies to your project can often be very painful, because technically there are many ways to include foreign code. In very simple cases you might just copy over code, in most cases you are going to link against a library and sometimes you have to compare whole feature sets of frameworks and make up your mind, if the implications imposed by that dependency are a good trade-off compared to the benefits.
From a developer’s perspective this is a nightmare. Usually you just want to add a certain ability to your app, whether it is to decode an audio format, communicate via SOAP, send mails, speak to a certain REST API or analyze images, or whatever you are in need of. Luckily, there is a guy on Github who did just what you need. Just imagine you could just click on a button and within seconds you would be up and running using his code. Scary? You might think so, but this is what qt-pods was designed for.
Calling qt-pods a package manager feels a bit odd, because this doesn’t describe precisely what it does. It is managing dependencies of your project via Git’s submodules. While Git submodules can be a tweaky thing in general and there are good reasons not to use Git submodules in all cases, qt-pods does its best to tell Git not to make any mistakes.

QT pods architecture
qt-pods works within a qmake’s “subdirs”-project template, that is a pool of projects aligned next to each other (well, technically you can tweak it not to be like that). “Pods” are being compiled into static libraries and are then linked against your target application. With a bit of .pri-magic (which is not magic at all, if you take a deeper look), pods can specify their own dependencies to the final app. As the pods are Git submodules, they are all independent repositories. That means, if you ever encounter foreign code to fail, you can fix it by yourself, but even better: you can generate patches or propagate these directly to the maintainer of the project. This is why the definition “package manager” fails, because what you actually get is not just an end product, a packaged result of some code, it *is* the code in a fully working environment. If included properly, the maintainer himself will include his code as a pod (from the same source like you, actually) and embed into a test project.

QT pods list
In order to get you started quickly, I sat down and defined fixed rules based on my previous experiences and then wrote an application that you can use to manage your pods. There is a graphical user interface and a command line version (which still needs some development).

You can find qt pods on GitHub and on qt-pods.org.


New project: OECD Data Portal


by Mathias Schäfer on September 8th, 2014
Comments Off

In July, we have launched a new client site, the OECD Data Portal. The OECD is an international organization that analyses national economies to coordinate the policies of its member states. The OECD conducts well-known studies like PISA and publishes reports and statistics on social and economic topics.

Data Portal home page

The goal of the Data Portal is to ease access to OECD publications and statistical databases. It is a central gateway to all OECD data for the broad audience, as well as for researchers and journalists. The concept and design for the Data Portal was developed by Raureif and Moritz Stefaner.

Data Portal: Country dashboard

A key component of the Data Portal is the visualization of economic and social country indicators. Using different interactive charts, the user can query and visualize a large amount of statistical data. For each country, a dashboard gives a quick overview for comparison. Each chart and country overview can be shared on social media and embedded into other websites. It’s easy to access the source database, find related studies, and download the underlying data.

9elements developed the HTML and CSS for different page types, and the JavaScript application for the chart component and query interface. The chart component uses the D3 and d3.chart libraries to render interactive SVG data graphics in the browser. Currently three types of visualization are available: bar chart, line chart, world map and an accessible table fallback. On the country dashboard, there are three additional custom charts to visualize income inequality, PISA ranking and CO2 emissions.

Our work fits into the existing OECD IT infrastructure, for example OECD’s content management system and the .Stat data querying API. The OECD editors select and configure the charts per indicator to render a meaningful chart.

The Data Portal is still in the beta phase and we’d love to hear your feedback. In the next months, several features will be added. Among others, we’re improving the mobile usability and we’re adding small charts to the topic, country and search result pages. We would like to thank the OECD staff as well as Raureif and Moritz Stefaner for the great cooperation!

→ Browse the OECD Data Portal


Developing a custom watch face for Android Wear


by Sebastian Deutsch on July 9th, 2014
Comments Off

9elements-one-blog

The brand new Samsung Gear Live has arrived and we took the time to play with it and more important to develop something for it. For a head start into Android Wear development you should check out the official docs and this Video from the latest Google IO. When we take a look at the watch faces we found them hideous and not very digital. So we sat down and implemented our own watch face – unfortunately the official docs are covering that topic. But digging around we found this Reddit thread which explained that it’s not too difficult to modify you AndroidManifest.xml so that your activity can be used as a watch face. The code is freely available on Github and if you have questions you can ping us on Twitter.

You can download the watch face for free in the Google Play Store.

 

 


Our First Experience with Swift


by Manuel Binna on June 17th, 2014
Comments Off

hackathon-june-2014

Every other month or so we like to do a small Hackathon at 9elements. Last week, after months of hard client work, we finally had the chance to have one again. During the two-day long event, several teams gather to explore new technologies, techniques, tools and build something for fun.  After Apple announced their new programming language at WWDC 2014 earlier this June, we were excited to explore it at our next Hackathon.

DOAR

At our last Hackathon, we created a small app called DOAR, a door opener based on Arduino. DOAR is connected to our LAN and provides a simple API to open the door to our office. We’ve now extended DOAR so that it broadcasts the door ring to connected clients. Clients establish a WebSocket to DOAR. When the door rings, DOAR broadcasts a message to all connected clients. Clients use their WebSocket to send “open door” commands to DOAR.

At this Hackathon, we created an OS X application with Xcode 6 (Beta) and Swift. The application opens a WebSocket to DOAR. When it receives a door bell message through the socket, it shows a notification in the Notification Center. You can directly interact with the notification to open the application and issue the “open door” command. DOAR immediately sends a “did open door” command to connected clients when it receives the first “open door” command. This allows the OS X application to remove the notification from Notification Center so that it gets out of the user’s way.

DOAR notification on OS X

Swift

The DOAR client application for OS X was implemented entirely with Swift (and Interface Builder). The following paragraphs give an overview of things that we had not known or read/heard about before.

Access Control

Swift currently has no support for access control modifiers like @public, @private, and @protected in Objective-C. Apple will deliver support for access modifiers in the final release of Xcode 6 in fall 2014 [1].

Selectors

When registering for notifications with a particular name via NSNotificationCenter, you typically provide a selector that gets called when some other part of the application posts a notification with that name. An Objective-C selector in Swift is a String.

NSNotificationCenter.defaultCenter()
                    .addObserver(
                        self, 
                        selector: "connectionDidReceiveDoorRing:",
                        name: ConnectionDidReceiveDoorRingNotification, 
                        object: connection)

When initially writing the previous code, we forgot to include the colon in the selector. This caused a crash at the call site (when another part of the code posts that notification).

NSNotificationCenter.defaultCenter()
                    .postNotificationName(
                        ConnectionDidReceiveDoorRingNotification, 
                        object: self)

This makes sense, since the implementation of NSNotificationCenter synchronously invokes observers of that notification. However, the point at which the debugger stops in Xcode (at the exception breakpoint) and the debug output do not really indicate that the issue is a nonexistent selector in the observer.

Strings

In Swift string parameters are passed by value. If a call site provides a String as the parameter to a function, Swift copies the complete String into the parameter. This is in stark contrast to Objective-C where NSString is passed by reference.

NSTimer

Usually, all Objective-C classes either directly or indirectly inherit from NSObject. But Swift classes may not have a base class at all. It is perfectly fine to implement a Swift class that has no superclass.

When using NSTimer in Swift code the target must inherit from NSObject, otherwise the timer is not able to invoke the selector on the object.

Conclusion

We think that Swift is a well-engineered programming language with a big potential. It needs time to master a programming langue, but since we started coding in Swift we feel delighted by the simple and elegant code it allows us to write compared to Objective-C.

We are very excited about Swift and look forward to the final release this fall. In fact, we are excited enough that we created Swift Weekly, a weekly newsletter with the most interesting links to blog articles, code, and other stuff about Swift. Subscribe at swiftweekly.com or follow @swift_weekly on Twitter.


External bundles with browserify and gulp


by Sebastian Deutsch on June 4th, 2014
Comments Off

browserify-gulp

Browserify is a nifty little tool that was originally invented to let Node.js modules run in your browser. A nice side effect of this is that you can use browserify to split up your application’s JavaScript into a well organized modules and then smash them together with a proper dependency management. In the past we’ve used Require.js to do that job, but for us it’s too painful and error-prone when creating bundles for production environments. Require.js also doesn’t play very nicely with Rails and it’s quite difficult to get everything working. Esa-Matti Suuronen has written a nice post comparing Require.js and browserify in depth.

Basic Usage

For those who aren’t familiar with browserify here is an example how we’re using it:

$ = require 'jquery'
QuestionView = require './question_view'
module.exports = ->
  intializeQuestions = ->
    ...
  initializeProfessions = ->
    ...

  questions = intializeQuestions()
  professions = initializeProfessions()
  questionView = new QuestionView(questions, professions)
  return

In the first line we’re requiring jQuery using the CommonJS require syntax. In the second line we’re requiring one of our views. We’re also exporting a function via module.exports for further usage in our application.

Gulp Integration

For Node.js projects we’re using Gulp for our build chain. Since browserify also uses streams it works together with Gulp like charm:

gulp.task 'browserify', ->
  browserifyOptions =
  transform: ['coffeeify']

  gulp.src("#{BASES.src}/javascripts/application.coffee", { read: false })
    .pipe(browserify(browserifyOptions))
    .on('error', gutil.log)
    .on('error', gutil.beep)
    .pipe(rename("application.js"))
    .pipe(gulp.dest("#{BASES.build}/javascripts"))
    .pipe(refresh(lrserver))

Browserify takes the application.coffee, processes it by requiring all the dependencies and then it spits out the bundled application.js that can be used in your HTML. A pretty straightforward workflow – but it has a flaw: When your application grows and your dependencies sum up this gulp task may take a while. While doing our latest project the execution time of browserify was up to 12 seconds.

External bundles

External bundles is a mechanism of browserify that lets the user require dependencies that are not directly processed by the actual build step. We’ve used it to create two bundles: The first bundle contains all vendor JavaScript code like jQuery, D3 and plenty of other stuff. The second bundle contains all our app related JavaScript. First you should list all your dependencies in a separate array:

EXTERNALS = [
  { require: "lodash", expose: 'underscore' }
  { require: "jquery", expose: 'jquery' }
  { require: "es5-shim" }
  { require: "rsvp", expose: 'rsvp' }
  { require: "../../#{VENDOR_DIR}backbone-1.1.2", expose: 'backbone' }
  { require: "../../#{VENDOR_DIR}d3-3.4.3", expose: 'd3' }
  { require: "../../#{VENDOR_DIR}jquery.nouislider-5.0.0", expose: 'jquery.nouislider' }
  { require: "../../#{VENDOR_DIR}topojson-1.4.9", expose: 'topojson' }
  { require: "../../#{VENDOR_DIR}matchMedia-0.2.0.js", expose: 'matchmedia' }
]

Now you create two gulp tasks ‘browserify:vendor’ and ‘browserify:application’:

gulp.task 'browserify:vendor', ->
  gulp.src("#{BASES.src}/scripts/vendor.js", { read: false })
  .pipe(browserify({
      debug: false
  }))
  .on('prebundle', (bundle) ->
    EXTERNALS.forEach (external) ->
      if external.expose?
        bundle.require external.require, expose: external.expose
      else
        bundle.require external.require
  )
  .pipe(rename('vendor.js'))
  .pipe(gulp.dest("#{BASES.build}/scripts"))

and

gulp.task 'browserify:application', ->
  browserifyOptions =
    transform: ['coffeeify']

  prebundle = (bundle) ->
    EXTERNALS.forEach (external) ->
      if external.expose?
        bundle.external external.require, expose: external.expose
      else
        bundle.external external.require

  application = gulp.src("#{BASES.src}/scripts/application.coffee", { read: false })
    .pipe(browserify(browserifyOptions))
    .on('prebundle', prebundle)
    .on('error', gutil.log)
    .on('error', gutil.beep)

  vendor = gulp.src("#{BASES.build}/scripts/vendor.js")

  es.concat(vendor, application)
    .pipe(concat('application.js'))
    .pipe(gulp.dest("#{BASES.build}/scripts"))
    .pipe(refresh(lrserver))

The magic happens in the ‘prebundle’ event that browserify provides. In the first gulp task all dependencies are required and in the second task they’re declared as external. In a last step we’re using gulp to tie both bundles together to a single javascript file. If you make changes to your app then only browserify:application is called – which takes just a fraction of the time comparing to the original single task.

Enter watchify

If you’re still not happy with the speed of JavaScript preprocessing you can replace browserify with watchify. Watchify is also a tool from substack but instead of compiling all the resources from the scratch it keeps a cached copy of all the source files and does incremental builds if something changes:

requireExternals = (bundler, externals) ->
  for external in externals
    if external.expose?
      bundler.require external.require, expose: external.expose
    else
      bundler.require external.require

gulp.task 'watchify', ->
  console.log 'watchify'
  entry = "#{BASES.src}/scripts/application.coffee"
  output = 'application.js'
  bundler = watchify entry
  bundler.transform coffeeify
  requireExternals bundler, EXTERNALS

  rebundle = ->
    console.log "rebundle"
    stream = bundler.bundle()
    stream.on 'error', notify.onError({ onError: true })
      .pipe(source(output))
      .pipe(gulp.dest(SCRIPTS_BUILD_DIR))
      .pipe(refresh(lrserver))
    stream

  bundler.on 'update', rebundle
  rebundle()

With the depicted workflow we were able to speed up our development builds by a huge factor. If you want to learn more about browserify and its internals be sure to check out the browserify handbook. If you like what you’re reading you should follow @9elements on Twitter.

See it in action?

If you want to see everything in action then checkout our 9elements Academy Bootstrap repository on GitHub. It’s a quickstart for building static websites but keeping the nice toys like sass, haml and browserify around.

 

 

 


Visual storytelling using WebGL


by Daniel Hoelzgen on April 22nd, 2014
Comments Off

visual storytelling using webgl

Recently we were working on a redesign of the uformit website. Uformit, an online marketplace for personalized 3D design, was already presented at the 3D Printshow in London and New York, but never announced to the public. It features a WebGL powered product display, allowing the user to directly form the product by adjusting its parameters and see the result in real-time.

However, during the show, it was easily possible to explain in person how it worked, what’s the story behind it and what is so special about the technology that allows designers to create products that can be personalized to be a truly unique piece. We first thought about creating a video that would explain the whole process, but after a few discussions we quickly came up with the simple, yet obvious idea: If we have the product as a 3D object on the website, why not use exactly this to explain the story around it?

Our designer Kevin Kalde came up with a design idea we instantly fell in love with: He combined traditional visual storytelling techniques with the use of a WebGL rendered object that moves from page to page, allowing us to explain the different steps and aspects in the creation of a design on uformit without losing focus. And after developing a first prototype, we all agreed that it really felt right. Unfortunately, a few issues (dragons) came up…

 

Firefox: Works great (until it freezes)

Even without using background workers for loading the model, Firefox was the only browser which seemed to handle the model-loading without any jittering. Unfortunately, after some time we stumbled upon a huge issue: Under certain circumstances, it seems the browser (v28) is likely to freeze when the WebGL canvas is hidden and then re-appears, either by hiding it by code, or by scrolling past the element and scrolling back.

After checking out the current nightly build, we noticed that this bug seems to be fixed in version 29, which is scheduled to be released on April 29th. This way, we just decided to live with this problem for a few days and to disable features that cause the freeze where possible. Perhaps there would have been a way to mitigate the problem by doing some tricks, but sacrificing code quality and stability to mitigate an already fixed bug (and additionally wasting even more resources on the problem than we already did), we decided to just leave it for now.

Update: Unfortunately, the bug still exists in the production version of Firefox, so it seems we are forced to find a way around this. Since the debug version seems to have no problems with the page, this might be a lot of trial and error…

 

IE: WebGL light

Internet Explorer up to version 10 is not able to display WebGL content at all. Although version 11 supports WebGL, there are a few things you cannot use, explained by Microsoft in this post. They show workarounds for some of the problems, but keep in mind that some libraries like three.js are not willing to adjust code due to missing features (which is basically a good idea), so you might have to keep an eye on this by yourself. However, Microsoft is working on getting everything in place.

 

Safari: So optimized your animation does not work

Looking at the numbers, it seems Apple did a great job in tweaking Safari’s performance. Trying to actually use this performance for implementing animations, you slowly get the impression they don’t do it faster, they just do less. Of course, it is well known that some methods are well suited when it comes to web animations and others aren’t, but in case you have to do calculations based on scrolling progress and position of other elements, you rely on having these updated very often as well. Even when using animation frames and getting acceptable high frame rates, the animation we implemented seemed to run not very smoothly, especially when moving synchronously with other elements on the page while scrolling. After investigating a little further, we recognized that the values we used for doing position calculations were just not updated very often, even though the page itself scrolls smoothly.

Additionally, Safari seems to sometimes have a buffer problem when changing the size of the WebGL context, causing a strange flickering effect during size-related animations, and causing real problems for things like a zoom function, causing the whole screen to flicker, looking like a bad designed computer malfunction in an old science fiction movie.

Of course, at least for position calculations, there are ways around this, like handling the scrolling by oneself, so at least everything moves synchronously slow, and of course this is not directly related to the use of WebGL, although having the WebGL container on the page does not exactly increase performance, so you run earlier into these issues. However, we decided to completely disable WebGL in Safari for this specific page, having a fallback page which is less interesting, but at least moves as fast and smooth as intended without being forced to do crazy tricks. We really hope that Apple works on this for the next updates of Safari – It’s correct that a browser should not necessarily try to be optimized for a certain type of pages, but forcing the developers in a specific direction by just not giving them the tools to build all kinds of webpages at the same quality cannot be the correct way, either.

 

Chrome: Thank you, Google

First of all, we used this browser during development, so perhaps there are things that work in other browsers and not in Chrome. However, there were no bad surprises – nothing behaving slow, no workarounds needed. It did not flicker, and did not display strange things. So: Thank you, Google!

 

WebGL – it’s almost there!

Despite the few problems we had during development, the feedback we got for this page really makes up for it. People not only liked the design of the page and the fact that the story builds up around a moving 3D object, it also really helped them to understand what uformit is about, and how the process we described on the page worked. So, yes, of course, we would do it again!

Do you have experience with WebGL for this kind of pages? I’m happy to hear from you on this blog or on Twitter.