We @ Wroc_❤.rb and we ❤ Vention Dention
We’re proud to announce wroc_love.rb 2012. The very first of such conferences in a beautiful city of Wrocław. What is this conference about?
A fresh Ruby conference organized by thriving local Ruby community. We’re keen on experimenting, value original ideas and diversity of opinions – as long as they’re backed with valid arguments.
You can meet : Georg, Bumi, Mike, Ralph, myself and our friend Nick.
We’re giving a talk
What is our talk about? About.. “Pit .. Brad Pit..Pit’s..ahhr! Just get out of the trap!!!” In our talk we will share some of the most interesting, absurd, or funny moments and insights we have experienced in past couple of years. As developers and business founders, we present the best of our own mistakes and show you how we got out of the pits we fell into. Believe us, we’ve been there as well and, hopefully, attending our talk will help you not make our mistakes. ;) It will be a serious fun! The talk will cover both technical and other subjects. Each mistake will get a 2-3 min coverage. Read more about us and our talk at the conference page and on their blog.
We love punk rock
Did you know we have our own band? No? Ok… now you know it! We’re proud to indroduce you to…
Vention Dention
Oh yeah. Vention Dention is on tour again… and we’re with them all the time. So the next gig’s are:
- wroc_love.rb, 10.-11. March 2012, Wrocław, Instytut Informatyki, Uniwersytet Wrocławski
- Nodecamp.eu (Details coming soon)
We’re planing some more gigs with them and everything will be announced on their homepage, on Railslove’s Vention Dention Homepage and via Twitter (@ventiondention). So stay tuned!
For now, just for you… Vention Dention:
Vention Dention Logo Animated
See you @ wroc_love.rb!
Help You need somebody; Help not just anybody!
Here at Railslove, we love building web applications. But aside from our core business, we also help other startups understand how the web works and what it means to run a web business — in Hamburg, Berlin, Cologne. And since experienced Ruby on Rails developers are increasingly hard to find, we’ve started to offer apprenticeships, too.
One of our new partners is DailyDeal. We’ve done some beginners and advanced courses in Rails covering stuff like testing, building APIs, advanced JavaScript coding and general design and programming patterns in Ruby on Rails, etc.
Oliver Hepfner, Director Software Engineering of DailyDeal:
The training Railslove provided under the direction of Georg Leciejewski helped us understand advanced programming patterns in Ruby on Rails. Our developers were excited to get a hands-on introduction into Ruby on Rails.
Next month, we will launch a few more courses with DailyDeal and with other companies, like Adcloud GmbH in Germany. If you are interested in learning more, please contact Ralph and Georg: ralph AT railslove.com & gl AT salesking.eu & team AT railslove.com
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:
- allows open-source projects to register their repository and have their test-suites run on demand
- allows users to contribute build capacities by connecting a VM that runs a build agent somewhere on their underused servers
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:
- Travis on Twitter: @travisci
- Travis on Github: travis-ci
- Homepage: travis-ci.org
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
- Das Unternehmerfrühstück im Rahmen der Internetwoche Köln wo wir auch Railslove kurz in einem Vortrag vorstellen werden. Start 9:15 im eco Kubus
Lichtstraße 43 i - Der 26. Webmontag in Köln natürlich unter Moderation von Rene Bredlau. Ab 19:00 im Spielplatz. Ubierring.
Mittwoch
- Limited WIP Society Cologne -Kanban User Group Köln. In der Gasmotorenfabrik ab 19:00
- dmexco – Digital Marketing Exposition and Conference
Donnerstag
Freitag
- Das DevHouse Friday Chillout. Start 19:00. Ort wird noch bekannt gegeben.
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/.
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 the standard to_json renderer built into Rails
- building your own views
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:
- It is understandable and quite easy to use
- 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:
- The resource itself – here a user
- Its properties – the attributes of this resource
- Links belonging to this resource – These describe some nested resources which belong to this resource and you can also define search parameters here
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.