while (stupidity > reason)

Increasing Map Zoom Level in Kibana

2016-10-06T00:00:00+02:00

On July 11, 2016, users of Kibana were not able to use map visualisations anymore since MapQuest had discontinued the support for their tile service. This was fixed with the release of Kibana versions 4.5.3 and 4.1.10. These versions circumvent the problem by using Elastic’s newly introduced, own tile service.

Unfortunately, the Elastic Tile Service restricts the maximum zoom level to 8. The company names scaling and bandwidth as the reasons for the limitation. However, you can increase the zoom level to the maximum of 18 if you use another tile service, for example OpenStreetMap’s openstreetmap-carto.

Two newly introduced parameters in the kibana.yml settings file allow you to use a custom tile server and maximum zoom level. If you have installed Kibana on macOS using brew, the location is /usr/local/etc/kibana/kibana.yml. Add the following lines:

tilemap.options.maxZoom: 18
tilemap.url: http://a.tile.openstreetmap.org/{z}/{x}/{y}.png

After restarting Kibana, you should be able to increase the zoom to street-level detailedness.

Upcoming project: Trainer at ThoughtWorks University

2016-05-17T00:00:00+02:00

My professional life as a software developer so far included various different technologies, companies, challenges as well as aspect of several different roles. Yet, my next project will have quite a different twist: This June to October, I’ll have the honour to bring up a new generation of ThoughtWorkers as a trainer at ThoughtWorks University in Pune, India.

TWU, for short, is ThoughtWork’s global graduate development program. 6 times per year, trainees and trainers from all of our regions come together for a 5-week long immersive learning experience. In Pune, an immersive learning experience equips colleagues who are just diving into the world of IT with the practises, principles and values that will make them successful as a ThoughtWorker.

Learning is in inseparable part of work in a fast-changing field like technology, and the fact that I’m always learning is one of the things I like most in my profession. In addition to that, passing knowledge to peers became an increasing part of my job lately in different ways: As a developer who also happens to be a consultant, making our practises available to others is an integral to daily work. Finally, becoming a sponsor in our internal mentoring programme is a great combination of both, as both mentor and mentee get to reflect and grow within a healthy mentoring relationship.

I’ve also had the honour of coaching two great teams of Rails Girls Summer of Code in 2014 and 2015. While RGSoC is highly catered towards each individual pair of learners, TWU will be more structured - which has both advantages and disadvantages. Yet, both programmes share the principles of adult learning that is hands-on and self-directed.

If you’re interested in life at ThoughtWorks university, I hope to keep you updated within the next months on this blog. In the past, Mark, Sumeet and Ramesh have written extensively about various aspects of training at TWU. For a trainee perspective, refer to Tsatsis excellent experience report.

Lastly, Chris shot these beautiful impressions while in Pune:

Keeping Standups Short Despite A Large Team

2015-02-24T00:00:00+01:00

Everyone hates meetings. Everyone hates long meetings. The whole point about stand-ups is: They’re short.

On my current project, we recently noticed that our dailies got longer and longer. Fair enough: We are a large team of about 20 people, so there is much to talk about. Nevertheless, we managed ourselves to get each other updated within around 12 minutes. This significantly lowered the need for splitting up the team (or not having stand-up at all).

This post outlines some of the techniques which worked well for us.

Focus on the wall

I’m a fan of the three questions:

What have you done yesterday?
What are you going to do today?
What blocks you?

Yet within a group of 20, doing the full round is not feasible anymore.

Instead, we go through the wall. From Release to Analysis, we share what’s noteworthy for every story. While there is no fixed format, we tend to focus on updates and blockers.

Walking through the wall story by story provides a red line and orders the news according to priority. Even without much context on story, everyone gets a sense of what each pair is up to. Individuals learn just enough to notice when to facilitate a catch-up later. Also, time is saved since pairs don’t speak double.

All in all, this method helped us emphasises flow more: You notice quickly when cards get stuck due to the similar order of topics from one day to the next.

Move cards beforehand

Do you know these stand-ups where people start to shuffle all cards around hectically? It disturbs everyone and ruins the stand-up flow. If the only info you’ll get out of stand-up is “Yeah, that moved”, you might also just send around a picture of the wall.

Make sure to move your cards before stand-up starts. Your team will be grateful.

Have general announcements after moving through the wall

Ideally, all tasks the team is working on should be reflected on the wall, alleviating the need for an unfocussed round of “Oh, by the way…“’s. Yet, there are always some general announcements that don’t fit in here or there, yet the team needs to know about them.

Have general announcements after moving through the wall. When everything related to core work has already been said, people are less tempted to squeeze in less important facts or even delve into chatter.

Some time back, we started stand-up with general announcements, before hearing the actual progress in terms of stories. This sucked the focus out of the stand-up super soon: Rather unimportant yet mention-worthy chatter stole our focus. Some Manger-y team members would even dump all their announcements in a big batch and then leave.

Time each other out

When in such a big stand-up, the need for timing each other out is very important. Don’t worry, getting the T-shaped hand sign from around the room happens to everyone. Getting this feedback is an effective way of learning to shape your communication and be meaningful in general, far beyond stand-ups.

Use separate channels for details

With an average speaking time of under 40 seconds per person, important details will get lost. Therefore, several side channels started to emerge over time. These leave room for sharing updates with more room for background infos or questions.

These are the specialised announcement channels we currently employ:

Tech Huddle: After the board walk and announcements, the technical team gathers closely around the board. The team self-organizes the task distribution: Cards are pulled, avatars move and pairs rotate.
Analysis Huddle: Shortly before stand-up, Analysts and Product Owners gather to get an overview of the board. The discuss priorities for the day, blockers. The team benefits from a clear board and ready to play cards during stand-up.
Migration steam stand-up: For a good balance between the isolations of a team split and the overload of a single team, we categorise our work in 2-3 work streams. Currently, one of these streams is occupied with a complex data migration of an old system. Since this work requires close collaboration and frequent reorganisation, the stream uses a separate stand-up for their stories in addition to the regular stand-up.
Tech announcements via mailing list: These topics tended to become lengthy and get discussed, so we agreed to send them out via mail. Now, everyone can read them asynchronously whenever it suits them. Urgent announcements or gentle reminders are still part of the Tech Huddle.

No silver bullet

Naturally, our stand-up efficiency improvements also bears some risks to it. More silent people may get overrun during the fast-paced walk through the wall. Speaking in such a big round might be intimidating for some, compared to a smaller, more reasonably-sized team stand-up. These factors require attention; you might miss out important updates completely if people remain silent more than occasionally.

Whenever there are less people due to leave, we like to diversify the stand-up format and experiment with it - for example by going back to the good old three questions.

How do you keep stand-ups short in your team? Let me know in the comments!

RailsRumble 2013: Building SeeMeSpeak

2013-10-30T00:00:00+01:00

This post introduces our entry for this year’s RailsRumble. Please have a look at SeeMeSpeak and vote for us at railsrumble.com if you like it. Thanks!

Biggest props to team members Bodo (@bitboxer), Florian (@Argorak) and Jan (@JanNilpferd) whom it was and honor and great joy to work with. Be sure to follow @seemespeakdict on twitter to stay up to date with the future of this open platform

SeeMeSpeak, a crowd-sourced dictionary for sign languages

While many people take online dictionaries like Leo as granted and use them on a daily basis, there is no such “go-to” solution for sign language speakers. The ones available are either not free (as in freedom) or not compelling to use.

Luckily, we had a native speaker of the German Sign Language on our team. Our our domain expert (if you will) introduced us to the challenges involved in such an undertaking: There are different languages (e.g. the German Sign Language, American Sign Language). Furthermore a multitude of different dialects and regional variations lead to subtle but noticeable pronunciation differences.

Our goal was to build a dictionary platform that is fun to use, with minimal friction, and flexible enough to handle ontologies for several languages.

Features & Technology Stack

Like a wiki, SeeMeSpeak doesn’t require an account to add content (there’s a review flag in order to prevent abuse of of the matter). Instead of a fixed ontology, we want to enable flexible categorization and search based on tags and text. Modern technology and the capabilities of modern browsers to record and play videos natively were drivers on the tech side. Obviously, internationalization plays a bigger part in this domain. We localized the app to German and show translations for German transcriptions as a proof-of-concept.

Our tech stack looks as follows. On the frontend:

getUserMedia / Video API to record from a user’s webcam, plugin-less. Unfortunately, we had issues with Firefox not supporting video/webm
MediaStreamRecorder. Its a standardized but unimplemented API, so we used a polyfill with the same name for recording videos from getUserMedia. The API/polyfill library is a small abstraction of the recording process, which is generally “output the webcam image in a <video> and capture a frame every other millisecond”. So instead of piling up BinaryArrays manually, you have a simple start and stop API available.
XHR2 to send JavaScript Blobs via multipart forms. By thus, it made no difference to our backend whether the video was live recorded or sent using a regular <input type="file">. The MediaStreamRecorder polyfill turned out the easiest and most future-proof way of recording from user media.
Popcorn.js for cross-browser video playback.

On the backend:

Rails 4 (thanks, Captian Obvious)
Elasticsearch for searching and metadata storage. Thanks to its flexibility, we didn’t need an additional database. For speaking to elasticsearch, we used the brand new elasticsearch gem instead of the retired Tire.
ElasticSearch to store ALL THE things is a refreshingly straight-forward approach.
Virtus and ActiveRecord::Validations as DSLs in our models.
Torquebox as an app server and background queuing system. I had my doubts before, but the stack’s tooling was absolutely turn-key. Installation via RubyGems and deployment works like a charm. Queuing background jobs for video conversions were as easy as declaring a method as always_background. We benefit from all cores of our machine out of the box.
Nginx for serving video files using pseudo streaming.
libav to shell out to avconv for converting incoming video streams to multiple formats
Bing Translator API for translating transcriptions. Fun fact: Since Google shut down it’s translation API, people built hacks involving spreadsheets to use their service anyway.

Feel very free to check out the open sourced code on GitHub.

That’s what you end up with on a work day after 48h of hacking

Some key insights we gained during this event:

Not requiring user sessions. We require your name for CC licensing/attribution reasons only.
Unfortunately, we couldn’t convince Firefox to reveal the webcam image as image/webp instead of png’s. As we had to prioritize against handling necessary conversion on the server, Firefox users will currently kindly be asked to leave. Despite those issues must be expected when using bleeding-edge browser features, the support should be given judging from feature matrices.
We integrated ~800 videos that were already available under a CC license. This allowed us to present an engaging first experience instead of a looking like a generic video platform. If you’re German, you may find searching for Angela Merkel or Telekom Taliban funny.

As for advice concerning the format of a RailsRumble, I’ll leave you with the words of How To Build an App in 48 Hours. I was honored to rumble with veterans which probably was the reason we finished successfully, with almost all features as planned and without hacking night time or sleep deprivation. Absolute prioritization, straightforward coding and avoiding to smart-ass complex solutions really is key here.

I also liked how the competition system is fully automated. As opposed to other hackathron I participated and which encourage and reward faking, I really enjoyed this format for being focussed solely on shipping.

About the logo: This is the which will reveal you as a sign language speaker. It’s a combination of spelling ILU, which expands to “I love you”. I really like that aspect.

Almost all I know about sign language and the deaf community was picked up alongside hacking this weekend. I’d be glad if you’d point out any concerns in this text and apologize in advance for any errors.

Discussions started on Hacker News and Reddit.

Using Bower with Rails

2013-04-29T00:00:00+02:00

This post describes a quick and dirty approach to better package management for assets. For more rationale behind this, why not look at my post called Better Component Packaging for Rails’ Asset Pipeline.

If you order omakase, the chef’s suggestion is dropping everything in vendor/assets. But manually snatching up several repos is a tedious and unsustainable approach, and Asset Gems (like jquery-rails) who do that for you aren’t available for the vast amount of front-end frameworks.

Twitter Bower is perfectly suited for this use case. Think RubyGems for the front-end. It let’s you resolve packages from a various places like its central registry, github, or just a URL. See the Bower Readme for more.

Be sure you have node.js installed and check out the ruby-bower for more information.

First, download the files from this gist:

$ wget https://gist.github.com/kaeff/5336060/raw/599415e00f2f53a1822b9a4fbfdaefcdbf0f8e00/.bowerrc
$ wget -P config/initializers https://gist.github.com/kaeff/5336060/raw/fbd035576e13d8d72d60294080b058765aa86267/add_bower_directive.rb
$ wget -P lib/ https://gist.github.com/kaeff/5336060/raw/7c33a18bf44111929b9570896c987ab544c5d890/bower_directive.rb

In your Gemfile, add

gem 'ruby-bower', group: :assets

Then, run

$ bundle install

Be sure your application’s lib/ directory gets loaded

# In config/application.rb
config.autoload_paths += Dir["#{config.root}/lib/**/"]

Now choose where you want to include your Bower dependencies:

// e.g. in app/assets/javascripts/application.js

//= require_bower_dependencies

Finally, you’re able to use Bower to manage dependencies. They will be included in your scripts.

$ bower install --save angular

Notice that some components don’t declare they dependencies or main files correctly. For these exeptions, you need to require the according file manually. Why not submit a pull request to the library while at it?

// e.g. in app/assets/javascripts/application.js

//= require_bower_dependencies
//= require underscore/underscore

This is basically the approach that spagalloco’s bower gem uses. Check out its sources, they’re really insightful.

Why Rails and Node.js Folks should care about Project Nashorn

2012-12-28T00:00:00+01:00

This post is geared towards web developers coming from Ruby on Rails, Node.js or both. As a web developer with former experiences with Java and JEE, currently engaged with Rails during days and Node at nights, I want to share my perspective on an interesting recent peace of news with you.

When does 'gem install therubynashorn' work already? #openjdk #nashorn #jruby
— kaeff (@kaeff) Dezember 25, 2012

You may know therubyracer gem for executing JavaScript sources in Ruby. As I was fooling around with ExecJS lately. Every person who has written CoffeeScript before, e.g. within Rails, has already used this overwhelmingly useful piece of software. The recent news of a new JavaScript engine called Nashorn entering the realm of FOSS did not create buzz on everybody’s dearest news site. That’s really a pity, and as you may have guessed, we’ll see why in this post.

Horned Homology

Project Nashorn is a greenfield implementation of ECMAScript-262-5, started in 2011 by Oracle. It replaces Rhino in OpenJDK 8, and is thus scheduled to ship publicly in 2013. The main rationale behind Nashorn is benefiting from JSR-292: Dynamic Languages on the JVM aka InvokeDynamic. Nashorn has some lifetime already: It used to be closed source but was recently released into the wild (heh). The source has been donated to the OpenJDK.

Several reasons speak for retiring Rhino, the main one being a huge effort of using invokedynamic properly. Rhino is old and slow: Its development started in 1997 (11 years ago!) at Netscape, even before the age of the now-standard HotSpot JIT compiler. Thus, it relies on interpretation - unlike V8, whose speed benefits mainly rely on just-in-time compilation of JS to machine code, which it does pretty memory-hungry. Nashorn, however, is said to be quick already - Node with its V8 is still the performance champion, but Nashorn races to challenge the throne.

These circumstances cry for a fresh overhaul - good to hear that Nashorn aims to be fully backwards compatible.

Node.jar

Here comes the hot part: With Nashorn also comes Node.jar, a Nashorn-based implementation of Node’s evented API. Currently based on Node v0.8.2, Node.jar is tested against the Node test suite for full compliance.

Node.jar a mapping Node’s API to Java-native pendants, nothing more and nothing less. This is quite feasible, as displayed by e.g. the often-cited file system example: Java’s nio packages, which weren’t too common in plain old Java development, have been providing async file system access for some time now. With JSR-203, they have received an overhaul in Java 7, namely NIO.2.

Unlike Nashorn, Node.jar has been hardly covered and seems to be in its infancies. I’d assume that a npm pendant is crucial for Node.jar’s success, but there are no news on that yet. But the promises are well enough for us to keep a close eye on it.

Runtime redundancy for the good

But why another Node, you may ask?

In my opinion, competition fosters and drives innovation. See the close example of in-browser JavaScript runtimes: With Google entering the stage, the war on challenging A second implementation of Node will further drive its standardization and adoption

The biggest benefits stem from running on the JVM. This enables the deployment on already available Java-based infrastructure. Especially on Windows, the pains that Node faces with its platform implementation, can be laid off to the JVM. Using Java application servers, especially JBoss, for deploying Node apps (or Ruby apps with embedded JS!) sounds promising. Their purpose is to provide common services to user apps which are ready to be reused. While Ruby did go the extra loops of reinventing database access, messaging, caching, replication, and Node has this obstacle still in front of it. For Ruby, the Torquebox project demonstrated how often sneered at giants like JBoss can be used for good, even for modern, dynamic web apps.

Finally, there is the “door opener” aspect. Grassroot-like enterprise adoption by sneaking into the existing Java-based infrastructures was and is a main rationale behind JRuby. Also, the JVM currently moves towards embedded, as efforts of an modular and small core JRE show. Having conquered the server already, embedded becomes the next area that JS developers can settle into. For example, how would the Nodecopter people like a native Node.js on a Raspberry Pi?

Java + JavaScript = JavaJavaScript ?

(Fun fact: Nashorn’s command line runner is in fact named jjs)

Okay, but what’s in for Ruby developers? There’s ExecJS to integrate my runtime from Ruby, be it Node, V8, Rhino or Nashorn.

With Node.jar and JRuby, there are implementations for both JavaScript and Ruby running on the JVM. In an ideal state, application parts written in JavaScript could be called from parts written in Ruby without process boundaries, since both run on the same JVM instance. This same-process interop is basically beneficial to all scenarios that involve ExecJS. Consequently, the need for wrappers and shelling out disappears, in theory providing a speed up.

Another aspect of Ruby and JavaScript playing nicely together on the JVM playground: Up to now, certain use cases require both runtimes, Ruby and JS. Distribution barriers for applications that apply to this scenario are significantly lowered if the JVM is the only runtime and environment dependency. Even better that it has a high penetration among server environments already.

What could possibly go wrong?

As always, there are caveats. Since Node’s strengths lie in the asynchronous, I see the main area of conflict in the re-use of common but synchronous Java APIs - e.g. JPA, JEE’s prominent database abstraction.

If you are as fascinated about this topic as I am, be warned: This is explorative territory. Keep an eye on the OpenJDK 8 project page. Save the date for the developer preview on end of February and mark your calendars for Q3/2013, when it is due for General Availability. And despite Nashorn being available rather soon, it should take some time for Node.jar to reach production readiness.

Moar!

If you want to give Nashorn a spin, grab a JDK8 and check out the source. The README points to everything you need to get going. Also check out the blog post ‘Open for business’. I went with a precompiled JDK8 build and just the Nashorn source (requires Mercurial), since that was too easy.

hg clone http://hg.openjdk.java.net/nashorn/jdk8/nashorn nashorn
cd nashorn
(cd make ; JAVA_HOME=/path/to/jdk8 ant)

Spin up the Nashorn console from the Nashorn directory:

JAVA_HOME=/path/to/jdk8 sh bin/jjs

Happy hacking!

Some additional Linkspam:

Java Spotlight Episode 92: Jim Laskey on Project Nashorn. A recent episode of the Java Spotlight potcast has a feature interview on Nashorn and the open sourcing that was the move into OpenJDK.
Project Nashorn Slides & Talks. Dalibor Topic has a a collection of slides and talks on Nashorn internals. Care if you want to dig deeper.
Nashorn, Node.jar and Java Persistence BOF (Session minutes)
The Nashorn blog on Oracle Blogs

Better Component Packaging for Rails' Asset Pipeline

2012-12-24T00:00:00+01:00

UPDATE: If you came for a practical tutorial, check out this piece on how to use Bower with Rails.

When writing single-page apps with Rails and the framework of your choice, may it be Ember, Angular or Backbone, there’s one huge pain: Maintaining a large front-end codebase while delivering with respect to the request count and size.

As with any important programming aspect in JavaScript (like DOM access or building SPAs), packet managing perfectly adheres to “XKCD’s Law of Standards”:

Sprockets recently and silently introduced a basic integration of Bower, a new packet manager by Twitter that ranks among the Top 10 starred projects on GitHub in 2012. The integration is a huge opportunity towards better maintainability, component orientation and, by thus, more efficient asset organization for single-page Rails apps. We will see why in this article.

Asset Gems for external dependencies

Without other tools than the plain asset pipeline, managing a set of external dependencies means downloading some archive files from a homepage and throwing the respective files in vendor/assets. This folder soon becomes an unmanageable pile of files. Have you tried updating or removing some dependencies? This approach also makes your app subject to what older folks know by the term DLL hell: A single source for external libraries that isn’t version-agnostic neglects the complexity of resolving dependencies and building a dependency graph.

Asset gems are the first logical step for a Rails developer to think of for distributing front-end libraries in a feasible manner. These are gems like jquery-rails, which expose the library’s assets according to the asset pipeline’s path conventions and hook into your Rails app (Further described in the Asset Pipeline Guide). This is approach is neat because we can centrally store all dependencies in the Gemfile und re-use bundler. It is also more flexible in Rails-specific cases, such as in the case of jquery-rails.

However all of the library’s assets still need to be required from within the application - a duplication, since a packet should know on its own which files it exposes to the parent app. Also, since asset gems are an Rails Engine, they pull in major dependencies and can’t be used with Sprockets standalone. Then also, apart from the most popular ones, there aren’t many libraries available as asset gems and still require repackaging. If only there was a way to include versioned assets from both a central registry or individual Git repositories, in a way that is not specific to Rails or Sprockets, but still compatible to their conventions?

Introducing Bower

Enter Bower to the rescue. At first, it looks like yet another packet management solution for scripts, images and stylesheets. What differentiates Bower is it’s low-level approach:

Bower is a generic tool which will resolve dependencies and lock packages down to a version. It runs over Git, and is package-agnostic. A package may contain JavaScript, CSS, images, etc., and doesn’t rely on any particular transport (AMD, CommonJS, etc.).

It provides a central repository with a growing number of libraries available for use. However, you are free to include components directly from Git, GitHub, a web url, the file system or even your own component repository.

Components are declared using the component.json:

{
  "name": "myProject",
  "version": "1.0.0",
  "main": ["./path/to/app.css", "./path/to/app.js", "./path/to/sprite.img"],
  "dependencies": {
    "jquery": "~1.7.2"
    "ember": "latest"
  }
}

The format of this manifest is pretty straight-forward. Give it a try and fetch bower using Node’s packet manager, npm:

npm install --global bower

For diving further into bower, follow e.g. this tutorial on NetTutsPlus.

Using Bower in Rails

Sprockets recently received a pull request that layed the groundwork for integrating Bower, from version 2.6.0 onwards. Use bower on the command line and the component.json manifest to manage your dependencies. Within your application.js (or vendor.js or wherever you like), you can require dependant components by their name.

Some tweaks need to be done to get this method to work. We’ll use the beta of Rails 4 for this example since we need a newer version of Sprockets than Rails 3 currently allows us to.

# Gemfile

gem 'rails', :git => 'git://github.com/rails/rails.git'
gem 'activerecord-deprecated_finders', github: 'rails/activerecord-deprecated_finders'
gem 'sprockets-rails', github: 'rails/sprockets-rails', group: :assets

With the upcoming Rails 4, the Sprocket integration is extracted into the sprocket-rails gem, so the necessary patch is already available in edge Rails. Unfortunately, using the newer version of Sprockets in Rails 3 is a bit tricky.

Then, we need to tell Bower where to find the component manifest and to put component files. In order to run bower from the app root, like rake or rails, we need to put a .bowerrc to adjust bower to Rails’ path conventions:

{
  "directory" : "vendor/assets/components",
  "json"      : "vendor/assets/component.json"
}

I suggest rooting components under vendor, but you could also use app or lib accordingly.

Next, we need to tell Sprockets to include the component folder by passing the name to the environment configuration.

environment = Sprockets::Environment.new
environment.append_path 'components'

In Rails, config.assets aliases to the sprocket environment:

# config/environment.rb

config.assets.append_path 'components'

Then, you still need to require the your dependencies. For JavaScripts, that’s

# e.g. app/assets/javascripts/application.js

//= require ember
//= require jquery

Clone this small example application from GitHub to try it out live. This changeset applies the aforementioned alterations.

Outlook

This small example demonstrates the potential behind a proper management for internal and external asset components.

However, a solid integration is yet to be developed, e.g. as a gem that handles the integration steps described above. It should features a proper communication layer on top of Bower’s API, eliminating the need of having Node installed and running bower separately on the command line. The integration part should eliminate the need to redundantly require all dependencies, e.g. by providing an additional directive (think //= require dependencies).

Lastly, we should honor the great pioneering work of Joshua Peek on Sprockets and laying the cornerstone for the Bower integration, as well as the team behind Bower.

Packages and modules

The ultimate goal should be a solution that goes even further by being agnostic to modules.

Single-Page Apps are by their nature bundled in one or a few packages. Bower components are a neat way to define these packages and their dependencies. However, we still need to require dependant components.

For a more intelligent solution, require should go away - or, put less baltant, decend into the background. Sprockets should be able to determine the relevant source files: By enforcing a one-module-per-file and module declaration convention, it should be able to graph module dependencies and resolve the inclusion order and include only necessary modules. This has the large number of benefits: Only necessary code gets shipped over the wire, reducing request size and parsing time, and better isolation for focussed and faster tests to name a few.

I’m planning to expand on this issue in a future post.

Guess I have a new blog

2012-12-18T00:00:00+01:00

Since I want to get going on blogging again, I set myself up with a shiny new site. It’s as straight-forward as possible, since it’s just a means to get content on the internet. No fancy blogging engine, just static sites generated by jekyll, a fancy gem by Tom Preston-Werner.

And oh, it’s in English. The former one was in German, but that didn’t really made sense for me.

Since I’m writing my master thesis on single-page web applications, I aim to pre-publish some thoughts on single aspects of it here. We’ll see :D.

Meanwhile, why not follow me on Twitter?