Travis – a distributed build system

Let us introduce us to Travis. What is Travis? As you can read on Github:

Travis is an attempt to create an open-source, distributed build system for the Ruby community that:

  1. allows open-source projects to register their repository and have their test-suites run on demand
  2. allows users to contribute build capacities by connecting a VM that runs a build agent somewhere on their underused servers

Travis Logo You can and should use travis for your open source projects as an continuos integration system. Travis is an incredible project and helps increase the quality of  lots of Open Source projects. So please head over to travis and setup tests for your ruby, node.js, erlang, … projects. – you can also setup your own instance installing Travis and use it for your private projects.

For more information check out the github page and the getting started section.

We’re really happy to be able to support Travis by sponsoring one of the worker boxes.

btw. Sven, Josh, thanks for mentioning us on your talks at Ruby Lugdunum and Frozen Rails 2011 this year. ;)

Btw.: have you heard about the Awesome Bot Factory? With the Awesome Bot Factory you’re able to create bots for your campfire channel. There is a bot to integrate travis to your campfire chat: simply ask the bot for a given status, like:

Jan travis:status Nerds/NerdPursuit
Choco Bits Bot Nerds/NerdPursuit is stable

Or get notified about your project’s new travis builds.

- Thank you, Travis-CI!

Resources:

October 3, 2011 | Filed Under continious integration, Cool stuff on GitHub, rails, Railslove

Comments Off 

The DevHouseFriday Chillout and the stolen Adcloud chair

First of all – a big, big thank you to @adcloud for hosting last DevHouseFriday. The location is perfect for such events – nice conference room, a terrace, free beer and some food. Thanks again!

The last DevHouseFriday had cool talks too: @tisba talked about loadtesting in the cloud @killerg was talking about his PDF-Dragon idea, we had a interesting talk about Scala and Closures for Java (by TJ) so, thanks again.

Unfortunately someone has stolen an @adcloud chair from the office. Turns out it was one of the Railslove guys. At the event only handful of Railslovers were present: Georg, Jan, Lars, Michael and Dirk…. Apparently, it was Jan. He got his punishment for this. Now this Chair is his burden to bear, and he has to take it on every other DevHouseFriday Chillout meetup.

the devhousefriday chair

So, see you next time, the next DevHouse Friday Chillout is on the October, 21th. Venue will be announced soon. Jan the Chairman will also be there to throw rocks at.

September 27, 2011 | Filed Under devhousefriday, Railslove, Railslove on Tour

Comments Off 

Die Internetwoche Köln


Und wieder ist es soweit: die Internetwoche Köln 2011 findet zwischen dem 19.09.2011 – 23.09.2011 statt. Die Internetwoche Köln ist eine Plattform für Kölner Internetstartups in der Veranstaltungen rund um das Thema Web-Business organisiert werden.

Wir möchten Euch herzlich zu folgenden Events einladen:

Montag

Mittwoch

Donnerstag

Freitag

Das Railslove-Team freut sich auf gemeinsame spannende Talks während der Internetwoche Köln.

Was ist die Internetwoche Köln?

Internetwoche Köln: Netz-Know-how und Networking

Zum zweiten Mal bieten Kölner Unternehmen in der Internetwoche Köln vom 19. bis 25. September Businesswissen rund um das Internet: Ein Unternehmerfrühstück zum Start bereitet den Boden für lokales Networking, die internationale Advance Conference vernetzt Start-ups und Investoren und zahlreiche Workshops liefern viele Antworten: Wie präsentiere ich mein Unternehmen im Netz? Wie mache ich einen QR-Tag? Wie bekomme ich meine eigenen Top-Level-Domain? Wie geht Online-Lernen? Ist die Cloud eine Option für mein Unternehmen? Wie gestalte ich meinen Büroalltag effizienter?
Organisatoren der Internetwoche Köln sind eco – Verband der deutschen Internetwirtschaft und die Köner Internet-Union (KIU).

Alle Veranstaltungen finden sich unter http://iwcgn.koeln.de/.

September 6, 2011 | Filed Under devhousefriday, kanban, rails, Railslove, Railslove on Tour, webmontag

1 Comment 

JSON Schema Baby

Building an application programming interface is not easy. Designing an API is more complex than just writing code. For a few projects we tried out different approaches to implement an API in Ruby on Rails. There are two main ways to make your resources accessible:

Using standard renderer provided by Rails

In Rails 2.0 you have the possibility to using the respond_to block to expose your resource in whatever format you rewuire (xml, json, html). E.g.:

The same is possible in Rails 3.0 but a little bit easier:

In these examples you can define the representation of your resource by defining the format you want the resource to be represented in. But in most cases you don’t want to expose every attribute of your resource. To achieve this, you could use Rails’ as_json method to create a custom JSON structure of your resource. E.g:

As Jonathan Julian mentioned in his blog post, call as_json directly or override it in your model to customize your representation of your resource. Sounds easy so far. Summarizing this approach we can say:

  1. It is understandable and quite easy to use
  2. You can easily customize the representation of your resources via the as_json method

But the way how this approach is realized is not the best in my opinion, because it too much correlated with the models when we talking only about a “representation”. That’s why I like the second approch – building your own views.

Customize it baby

What does it exactly mean? Instead of just overriding the as_json method in your model, build a template that exposes your API. The easiest way is, e.g., to use RABL – Ruby API Templating Language.

As in the example before you define within your controller structure WHICH resources are being exposed, like:

And within your RABL-Template now you can define HOW your resources should look:

What happened here is that the representation of the resource is properly split from the resource using templates, like using .html-templates that belongs to your views. Thats great. You’re very flexible to define how the respresentation should looks like without overriding some methods. The resource is exposed ‘as it is’ but the template takes the response of what representation exactly the API users should get. In general, that seems to be the right approach; and it really is, but for me it isn’t going far enough. What I like to see is an even looser representation.

Here comes JSON-Schema

Now we’re going a step further and completely split our resource from the representation. Based on JSON-Schema (http://json-schema.org/) we’re going to define one that is responsible how our resource is being represented. With this approach, it is also possible to define our yourself in which way you want to interpret the schema within your code. And it’s fully decorrelated if you want to.

If found a very good approach for using the JSON-Schema for an API representation (sk_api_schema – https://github.com/salesking/sk_api_schema) – a Ruby library that defines the schema which takes care of the representation of their API resources.

How does it work? Your controllers are almost the same. E.g.:

The only small difference is the object_as_json method, which is provided by your own schema library. This method takes the properties defined in the schema and looks them up on the object in question.

Within your schema for a single resource looks like this:

As you can see, the schema described everything:

And there’s even one more big advantage: publishing your JSON-Schema library gives your API users a good and clean documentation of your interface. You don’t have to describe it anymore. Moreover, it could be possible to generate a nicer representation from your documentation. You can see an example of thishere: http://sk-api-browser.heroku.com/. This API browser reads the JSON-Schema here and generates a nice overview of the API.

Summary

What I tried to describe here were some facts about how to implement an API with Ruby on Rails but more about how to split the resource itself from the representation in your webservice. For this you can use internal methods responsible for representing your resource, or create your own templates with defined libraries like RABL. Using JSON schema for the representation of your API is the most loosely coupled approach. With JSON schema you’re don’t care about the resource’s representation within your code but reather within your schema. It’s a description of whatever you want to expose to your clients.

Resources

September 5, 2011 | Filed Under rails, Railslove, ruby

1 Comment 

Nerds/Cookbooks

What’s cookin good lookin?

Beside our NerdPursuit project, we’re proud to invite the Nerds/Cookbooks project today. Go ahead and create real recipes for real nerds today!

The Recipe of the day: fried egg with applesauce and mashed potatoes

August 23, 2011 | Filed Under plugins, Railslove

Comments Off 

← Previous Page — Next Page →