rubyonrails-ug.de Planet

We @ Wroc_❤.rb and we ❤ Vention Dention

2012-01-31T08:21:52+00:00

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!

A Tour of Amazon's DynamoDB

2012-01-30T00:00:00+00:00

Amazon's recent release of DynamoDB, a database whose name is inspired by Dynamo, the key-value database the distributed datastore they've been running in production for a good five to six years now. I think it's great they've finally done it, though from my obverservations, there's little resemblance of what the original Dynamo paper describes, but I'm getting ahead of myself. Traditionally Amazon hasn't been very open about how they implement their services, so some of what I'm stating here may be nothing more than an educated guess. Either way, the result is pretty neat.

Time to take a good look at what it has to offer, how that works out in code, and to make some wild guesses as to what's happening under the covers. I'm using fog's master to talk to DynamoDB in the examples below, but the official Ruby SDK also works. Fog is closer to the bare API metal though, which works out well for our purposes.

My goal is not to outline the entire API and its full set of options, but to dig into the bits most interesting to me and to show some examples. A lot of the focus in other posts is on performance, scalability and operational ease. I think that's a great feature of DynamoDB, but it's pretty much the same with all of their web services. So instead I'm focusing on the effects DynamoDB has on you, the user. We'll look at API, general usage, data model and what DynamoDB's feature generally entails.

The Basics

DynamoDB is a distributed database in the cloud, no surprises, it's not the first such thing Amazon has in its portfolio. S3, SimpleDB, RDS and DynamoDB all provide redudant ways to store different types of data in Amazon's datacenters. Currently, DynamoDB only supports the us-east region.

An important difference is that data stored in DynamoDB is officially stored on SSDs, which has (or at least should have) the benefit of offering predictable performance and greatly reduced latency across the board. The question that remains is, of course: when can I hook up SSDs to my EC2 instances?

The other big deal is that the read and write capacity available to you is configurable. You can tell Amazon how much capacity, in read and write units per second, you expect for your application, and they make sure that capacity is available to you as long as you need it (and pay for it).

Data Model

Data in DynamoDB is stored in tables, a logical separation of data if you will. Table names are only unique on a per-user basis, not globally like S3 buckets.

Tables store items, think rows of data or documents. Items have attributes and values, similar to SimpleDB. Think of it as a JSON document where you can read and write attributes independent of the entire document. Every row can have different attributes and values, but every item needs to have a uniquely identifying key whose name you decide on upfront, when you create the table.

Let's create a table first, but make sure you wear protection, as this is yet another of Amazon's gross-looking APIs. The relevant API action is CreateTable.

dynamo = Fog::AWS::DynamoDB.new(aws_access_key_id: "YOUR KEY",
  aws_secret_access_key: "YOUR SECRET")

dynamo.create_table("people",
  {HashKeyElement: {AttributeName: "username", AttributeType: "S"}},
  {ReadCapacityUnits: 5, WriteCapacityUnits: 5})

This creates a table called "people" with an attribute "username" as the indexing key. This is the key you're using to reference a row, sorry, an item, in a table. The key is of type string, hence the S, you can alternatively specify an N for numeric values. This pattern will come up with every attribute and value pair you store, you always need to tell DynamoDB if it's a string or a number. You also specify initial values for expected read and write capacity, where 5 is the minimum.

You have to provide a proper value for a key, DynamoDB doesn't offer any automatic generation of keys for you, so choose them wisely to ensure a good distribution. A key, that has a lot of data behind it, and that's accessed much more frequently than others will not benefit you. Keep your data simple and store it with multiple keys if you can.

Anyhoo, to insert an item, you can use the PutItem API action, to which you issue a HTTP POST (go figure). The DynamoDB API already gives me headache, but more on that later. Thankfully, a good client library hides the terrible interface from us, only leaving us with the hash structures sent to DynamoDB.

dynamo.put_item("people", {username: {"S" => "roidrage"}})

Specify multiple attributes as separate hash entries, each pointing to a separate hash specifying data type and value. I'll leave it to you to think about how backwards this is, though it must be said that JavaScript is also to blame here, not handling 64 bit integers very well.

You can store lists (or rather sets of data) too, using SS as the datatype.

dynamo.put_item("people", {username: {S: "roidrage"},
                               tags: {SS: ["nosql", "cloud"]}})

Note that you can use PutItem on existing items, but you'll always replace all existing attributes and values.

Conflicts and Conditional Writes

All writes can include optional conditions to check before updating an item. That way you can ensure the item you're writing is still in the same state as your local copy of the data. Think: read, update some attribute, then write, expecting and ensuring to not have any conflicting updates from other clients in between.

This is a pretty neat feature, you can base updates on one attributes based on whether another attribute exists or has a certain value.

dynamo.put_item("people",
    {username: {S: "roidrage"}, fullname: {S: "Mathias Meyer"}},
    {Expected: {fullname: {Exists: false}}})

This operation is only executed if the item as currently stored in DynamoDB doesn't have the attribute the attribute fullname yet. On a subsequent PutItem call, you could also check if the item's fullname attribute still has the same value, e.g. when updating the full name of user "roidrage".

dynamo.put_item("people",
    {username: {S: "roidrage"}, fullname: {S: "Mathias Meyer"}},
    {Expected: {fullname: {Value: {S: "Mathias Meyer"}}}})

It's not the greatest syntax for sure, but it does the job. Which brings me to some musings about consistency. If the condition fails, Amazon returns a 400 response, just like with every other possible error you could cause.

To make proper use of conditional updates in your application and to actually prevent conflicting writes and lost updates, you should use the UpdateItem action instead and only update single attributes, as PutItem always replaces the entire item in the database. But even then, make sure to always reference the right attributes in an update. You could even implement some sort of versioning scheme on top of this, for instance to emulate multi-version concurrency control.

Updating single or multiple attributes is done with the UpdateItem action. You can update attributes without affecting others and add new attributes as you see fit. To add a new attribute street, here's the slightly more verbose code.

dynamo.update_item("people", {HashKeyElement: {S: "roidrage"}},
    {street: {Value: {S: "Gabriel-Max-Str. 3"}}})

There are more options involved than with PutItem, and there are several more available for UpdateItem. But they'll have to wait for just a couple of sentences.

Consistency on Writes

Conditional updates are the first hint that DynamoDB is not like Dynamo at all, as they assume some sort of semi-transactional semantics. Wherein a set of nodes agree on a state (the conditional expression) and then all apply the update. The same is true for atomic counters, which we'll look at in just a minute.

From the documentation it's not fully clear how writes without a condition or without an atomic counter increment are handled, or what happens when two clients update the same attribute at the same time, and who wins based on which condition. Facing the user, there is no mechanism to detect conflicting writes. So I can only assume DynamoDB either lets the last write win or has a scheme similar to BigTable, using timestamps for each attribute.

Writes don't allow you to specify something like a quorum, telling DynamoDB how consistent you'd like the write to be, it seems to be up to the system to decide when and how quickly replication to other datacenters is done. Alex Popescu's summary on DynamoDB and Werner Vogels' introduction suggest that writes are replicated across data centers synchronously, but doesn't say to how many. On a wild guess, two data centers would make the write durable enough, leaving the others to asynchronous replication.

Consistency on Reads

For reads on the other hand, you can tell DynamoDB if stale data is acceptable to you, resulting in an eventually consistent read. If you prefer strongly consistent reads, you can specify that on a per-operation basis. What works out well for Amazon is the fact that strongly consistent reads cost twice as much as eventually consistent reads, as more coordination and more I/O are involved. From a strictly calculating view, strongly consistent write take up twice as much capacity as eventually consistent writes.

From this I can only assume that writes, unless conditional will usually be at least partially eventually consistent or at least not immediately spread out to all replicas. On reads on the other hand, you can tell DynamoDB to involve more than just one or two nodes and reconcile outdated replicas before returning it to you.

Reading Data

There's not much to reading single items. The action GetItem allows you to read entire items or select single attributes to read.

dynamo.get_item("people", {HashKeyElement: {S: "roidrage"}})

Optionally, add the consistency option to get strong consistency, with eventual consistency being the default.

dynamo.get_item("people", {HashKeyElement: {S: "roidrage"}},
                          {ConsistentRead: true})

A read without any more options always returns all data, but you can select specific attributes.

dynamo.get_item("people", {HashKeyElement: {S: "roidrage"}},
                          {AttributesToGet: ["street"]})

Atomic Counters

Atomic counters are a pretty big deal. This is what users want out of pretty much every distributed database. Some say they're using it wrong, but I think they're right to ask for it. Distributed counters are hard, but not impossible.

Counters need to be numerical fields, and you can increment and decrement them using the UpdateItem action. To increment a field by a value, specify a numerical attribute, the value to be incremented by, and use the action ADD. Note that the increment value needs to be a string.

dynamo.update_item("people", {HashKeyElement: {S: "roidrage"}},
                             {logins: {Value: {N: "1"}, Action: "ADD"}})

When the counter attribute doesn't exist yet, it's created for you and set to 1. You can also decrement values by specifying a negative value.

dynamo.update_item("people", {HashKeyElement: {S: "roidrage"}},
                             {logins: {Value: {N: "-1"}, Action: "ADD"}})

Can't tell you how cool I think this feature is. Even though we keep telling people that atomic counters in distributed system are hard, as they involve coordination and increase vulnerability to failure of a node involved in an operation, systems like Cassandra and HBase show that it's possible to do.

Storing Data in Sets

Other than numerical (which need to be specified as strings nonetheless) and string data types, you can store sets of both too. One member can only exist once in an attribute set. The neat part is that you can atomically add new members to sets using the UpdateItem action. In the JSON format sent to the server, you always reference even just single members to add as a list of items. Here's an example:

dynamo.update_item("people", {HashKeyElement: {S: "roidrage"}},
                             {tags: {Value: {SS: ["nosql"]}}})

That always replaces the existing attribute though. To add a member you need to specify an action. If the member already exists, nothing happens, but the request still succeeds.

dynamo.update_item("people", {HashKeyElement: {S: "roidrage"}},
                             {tags: {Value: {SS: ["cloud"]}, Action: "ADD"}})

You can delete elements in a similar fashion, by using the action DELETE.

dynamo.update_item("people", {HashKeyElement: {S: "roidrage"}},
                             {tags: {Value: {SS: ["cloud"]}, Action: "DELETE"}})

The default action is PUT, which replaces the listed attributes with the values specified. If you run PUT or ADD on a key that doesn't exist yet, the item will be automatically created. This little feature and handling of sets and counters in general sounds a lot like things that made MongoDB so popular, as you can atomically push items onto lists and increment counters.

This is another feature that's got me thinking about whether DynamoDB even includes the tiniest bit of the original Dynamo. You could model counters and sets based on something like Dynamo for sure, based on the ideas behind Commutative Replicated Data Types. But I do wonder if Amazon actually did go through all the trouble building that system on top of the traditional Dynamo, or if they implemented something entirely new for this purpose. There is no doubt that operations like these is what a lot of users want even from distributed databases, so either way, they've clearly hit a nerve.

Column Store in Disguise?

The fact that you can fetch and update single attributes with consistency guarantees makes me think that DynamoDB is actually more like a wide column store like Cassandra, HBase or, gasp, Google's BigTable. There doesn't seem to be anything left from the original, content-agnostic idea of the Dynamo data store, whose name DynamoDB so nicely piggybacks on.

The bottom line is there's always a schema of attributes and values for a particular item you store. What you store in an attribute is up to you, but there's a limit of 64KB per item.

DynamoDB assumes there's always some structure in the data you're storing. If you need something content-agnostic to store data but with similar benefits (replication, redundancy, fault-tolerance), use S3 and CloudFront. Nothing's keeping you from using several services obviously. If I used DynamoDB for something it'd probably not be my main datastore, but an add-on for data I need to have highly available and stored in a fault-tolerant fashion, but that's a matter of taste.

A Word on Throughput Capacity

Whereas you had to dynamically add capacity in self-hosting database systems, always keeping an eye on current capacity limits, you can add more capacity to handle more DynamoDB request per second simply by issuing an API call.

Higher capacity means paying more. To save money, You could even adjust the capacity for a specific time of day basis, growing up and down with your traffic. If you go beyond your configured throughput capacity, operations may be throttled.

Throughput capacity is based on size of items you read and the number of reads and writes per second. Reading one item with a size of 1 KB corresponds to one read capacity unit. Add more required capacity units with increased size and number of operations per second.

This is the metric you always need to keep an eye on and constantly measure from your app, not just to validate invoice Amazon sends you at the end of the month, but also to track your capacity needs at all times. Luckily you can track this using CloudWatch and trigger alerts. Amazon can trigger predefined alerts when capacity crosses a certain threshold. Plus, every response to a read includes the consumed read capacity, and the same is true for writes.

Throughput capacity pricing is pretty ingenious on Amazon's end. You pay for what you reserve, not for what you actually use. As you always have to have more capacity available as you currently need, you always need to reserve more in DynamoDB. But if you think about it, this is exactly how you'd work with your own hosted, distributed database. You'll never want to work very close to capacity, unless you're some crazy person.

Of course you can only scale down throughput capacity once per day, but scale up as much as you like, and increases need to be done at least 10%. I applaud you for exploiting every possible opportunity to make money, Amazon!

Data Partitioning

Amazon's documentation suggests that Amazon doesn't use random partitioning to spread data across partitions, partitioning is instead done per table. Partitions are created as you add data and as you increase capacity, suggesting either some sort of composite key scheme or a tablet like partitioning scheme, again, similar to what HBase or BigTable do. This is more fiction than fact, it's an assumption on my part. A tablet-like approach certainly would make distributing and splitting up partitions easier than having a fixed partitioning scheme upfront like in Dynamo.

The odd part is that Amazon actually makes you worry about partitions but doesn't seem to offer any way of telling you about them or how your data is partitioned. Amazon seems to handle partitioning mostly automatically and increases capacity by spreading out your data across more partitions as you scale capacity demand up.

Range Keys

Keys can be single values or based on a key-attribute combination. This is a pretty big deal as it effectively gives you composite keys in a distributed database, think Cassandra's data model. This effectively gives you a time series database in the cloud, allowing you to store sorted data.

You can specify a secondary key on which you can query by a range, and which Amazon automatically indexes for you. This is yet another feature that makes DynamoDB closer to a wide column store than the traditional Dynamo data store.

The value of the range key could be an increasing counter (though you'd have to take care of this yourself), a timestamp, or a time based UUID. Of course it could be anything else and unique entirely, but time series data is just a nice example for range keys. The neat part is that this way you can extract data for specific time ranges, e.g. for logging or activity feeds.

We already looked at how you define a normal hash key, let's look at an example with a more complex key combining a hash key and a range key, using a numerical type to denote a timestamp.

dynamo.create_table("activities", {
      HashKeyElement: {AttributeName: "username", AttributeType: "S"},
      RangeKeyElement: {AttributeName: "created_at", AttributeType: "N"}},
    {ReadCapacityUnits: 5, WriteCapacityUnits: 5})

Now you can insert new items based on both the hash key and a range key. Just specify at least both attributes in a request.

dynamo.put_item("activities", {
    username: {S: "roidrage"}, 
    created_at: {N: Time.now.tv_sec.to_s},
    activity: {S: "Logged in"}})

The idea is simple, it's a timestamp-based activity feed per user, indexed by the time of the activity. Using the Query action, we can fetch a range of activities, e.g. for the last 24 hours. Just using get_item, you always have to specify a specific combination of hash and range key.

To fetch a range, I'll have to resort to using Amazon's Ruby SDK, as fog hasn't implemented the Query action yet. That way you won't see the dirty API stuff for now, but maybe that's a good thing.

dynamo = AWS::DynamoDB.new(access_key_id: "YOUR KEY",
                           secret_access_key: "YOUR SECRET")
activites = dynamo["activities"]

items = activities.items.query(
    hash_key: "roidrage",
    range_greater_than: (Time.now - 85600).tv_sec)

This fetches all activity items for the last 24 hours. You can also fetch more historic items by specifying ranges. This example fetches all items for the last seven days.

items = activities.items.query(
    hash_key: "roidrage",
    range_greater_than: (Time.now - 7.days.ago).tv_sec,
    range_less_than: Time.now.tv_sec)

Note that the Query action is only available for tables with composite keys. If you don't specify a range key, DynamoDB will return all items matching the hash key.

Queries using Filters

The only things that's missing now is a way to do richer queries, which DynamoDB offers by way of the Scan action. fog doesn't have an implementation for this yet, so we once again turn to the AWS Ruby SDK.

Scanning allows you to specify a filter, which can be an arbitrary number of attribute and value matches. Once again the Ruby SDK abstracts the ugliness of the API underneath into something more readable.

activities.items.where(:activity).begins_with("Logged").each do |item|
  p item.attributes.to_h
end

You can include more than one attribute and build arbitrarily complex queries, in this example to fetch only items related to the user "roidrage" and him logging in.

activities.items.where(:activity).equals("Logged in").
          and(:username).equals("roidrage").each do |item|
  p item.attributes.to_h
end

You can query for ranges as well, combining the above with getting only items for the last seven days.

activities.items.where(:activity).equals("Logged in").
    and(:username).equals("mathias").
    and(:created_at).between(7.days.ago.tv_sec, Time.now.tv_sec).each {|item|
  p item.attributes.to_h
end

Filters fetch a maximum of 1 MB of data. As soon as that's accumulated, the scan returns, but also includes the last item evaluated, so you can continue where the query left off. Interestingly, you also get the number of items remaining. Something like paginating results dynamically comes to mind. Running a filter is very similar to running a full table scan, though it's rather efficient thanks to SSDs. But don't expect single digit millisecond responses here. As scans heavily affect your capacity throughput, you're better off resorting to their use only for ad-hoc queries, not as a general part of your application's workflow.

Unlike Query and GetItem, the Scan action doesn't guarantee strong consistency, and there's no flag to explicitly request it.

The API

DynamoDB's HTTP API has got to be the worst ever built at Amazon, you could even think it's the first API every designed at Amazon. You do POST requests even to GET data. The request and response can include conditions and validations and their respective errors, the proper Java class name of an error and other crap. Not to mention that every error caused by any kind of input on your end always causes a 400.

Here's an example of a simplified request header:

POST / HTTP/1.1
Content-Type: application/x-amz-json-1.0
x-amz-target: DynamoDB_20111205.GetItem

And here's a response body from an erroneous request:

{"__type":"com.amazon.coral.validate#ValidationException",
"message":"One or more parameter values were invalid:
The provided key size does not match with that of the schema"}

Lovely! At least there's a proper error message, though it's not always telling you what the real error is. Given that Amazon's documentation is still filled with syntactical errors, this is a bit inconvenient.

The API is some bastard child of SOAP, but with JSON instead of XML. Even using a pretty low level library like fog doesn't hide all the crap from you. Which worked out well in this case, as you see enough of the API to get an idea about its basic workings.

The code examples above don't read very Ruby like as I'm sure you'll agree. Though I gotta say, the Ruby SDK provided by AWS feels a lot more like Ruby in its interface.

I don't have very high hopes to see improvements on Amazon's end, but who knows. S3, for example, got a pretty decent REST API eventually.

Pricing

Pricing is done (aside from throughput capacity) per GB stored. If you store millions of items, and they all exceed size of just a few KB, expect to pay Amazon a ton of money, storage pricing trumps throughput pricing by a lot. Keep data stored in an item small. If you only store a few large items, it works too, but you may end up being better off choosing one of Amazon's other storage options. You do the math. Pricing for storage and the maximum size for a single item always includes attribute names, just like with SimpleDB.

To give you an idea how pricing works out, here's a simple calculation. 100 GB of data, 1000 reads per second, 200 writes per second, item size is 4 KB on average. That's $1253.15 every month, not including traffic. Add 10 GB of data the second month and you're at $1263.15. You get the idea. Pricing is much more affected by read and write operations vs. item size. Make your items 6 KB in size, and you're already at $1827.68.

Bottom Line

Though Amazon is doing a pretty good job at squeezing the last drop of money out of their customers using DynamoDB, think about what you're getting in return. No operations, no hosting facilities, let alone in three different datacenters, conditional writes and atomic counters, and a database that (I assume) has years of experience in production forged into it.

As usually the case with Amazon's Web Services, using something like DynamoDB is a financial tradeoff. You get a data store that scales up and down with your demand without you having to worry about the details of hardware, operations, replication and data performance. In turn you pay for every aspect of the system. The price for storage is likely to go down eventually, making it a more attractive alternative to hosting an open source NoSQL database system yourself. Whether this is an option for your specific use case, only you're able to make that decision.

If you store terrabytes of data, and that data is worth tens of thousands of dollars per month in return for not having to care about hosting, by all means, go for DynamoDB. But at that size, just one or two months of hosting on Amazon pays off buying servers and SSDs for several data centers. That obviously doesn't cover operational costs and personell, but it's just something to think about.

Closing Thoughts

Sorted range keys, conditional updates, atomic counters, structured data and multi-valued data types, fetching and updating single attributes, strong consistency, and no explicit way to handle and resolve conflicts other than conditions. A lot of features DynamoDB has to offer remind me of everything that's great about wide column stores like Cassandra, but even more so of HBase. This is great in my opinion, as Dynamo would probably not be well-suited for a customer-facing system. And indeed, Werner Vogel's post on DynamoDB seems to suggest DynamoDB is a bastard child of Dynamo and SimpleDB, though with lots of sugar sprinkled on top.

Note that it's certainly possible and may actually be the case that Amazon has built all of the above on top of the basic Dynamo ingredients, Cassandra living proof that it's possible. But if Amazon did reuse a lot of the existing Dynamo code base, they hid it really well. All the evidence points to at least heavy usage of a sorted storage system under the covers, which works very well with SSDs, as they make sequential writes and reads nice and fast.

No matter what it is, Amazon has done something pretty great here. They hide most of the complexity of a distributed system from the user. The only option you as a user worry about is whether or not you prefer strong consistency. No quorum, no thinking about just how consistent you want a specific write or read operation to be.

I'm looking forward to seeing how DynamoDB evolves. Only time will tell how big of an impact Amazon's entering the NoSQL market is going to have. Give it a whirl to find out more about it.

Want to know how the original Dynamo system works? Have a look at the Riak Handbook, a comprehensive guide to Riak a distributed database that implements the ideas of Dynamo and adds lots of sugar on top.

I'm happy to be proven wrong or told otherwise about some of my assumptions here, so feel free to get in touch!

Resources

Be sure to read Werner Vogels' announcement of DynamoDB, and Adrian Cockcroft's comments have some good insights on the evolution of data storage at Netflix and how Cassandra, SimpleDB and DynamoDB compare.

Seeds for different environments

2012-01-25T12:59:00+00:00

Here’s a little Rails tip for splitting up seed data for various environments: Create the folder db/seeds/. For each environment you want to seed put a file in there named after the env. Your general seeds are put into db/seeds/all.rb. Here’s what it might look like:

|___seeds
            | |___all.rb
            | |___development.rb
            | |___staging.rb
            | |___production.rb
            |___seeds.rb

Change the content of your db/seeds.rb to something like this:

['all', Rails.env].each do |seed|
              seed_file = "#{Rails.root}/db/seeds/#{seed}.rb"
              if File.exists?(seed_file)
                puts "*** Loading #{seed} seed data"
                require seed_file
              end
            end

Running rake db:seed will now load up the seed data defined in db/seeds/all.rb and the current environment.

My Publishing Tool Chain

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

Update: Added paragraph on the e-commerce platform I'm using.

Several people have asked me about the publishing tool chain I'm using for the Riak Handbook and the NoSQL Handbook. As Avdi just published his, now's as good a good time as any to throw in mine too. After all, it's always nice to know all the options you have.

All text is written in Markdown. I started out with Textile, but just didn't like Textile's way of breaking down single lines into separate paragraphs, so I switched to Markdown later on. Not a painless process, but sufficiently easy thanks to Pandoc.

The Markdown files, one per chapter, are bundled together into a big file and then fed into GitHub's Redcarpet library. I use Albino and Pygments for syntax highlighting, embedded into a custom renderer for Redcarpet. See the Redcarpet README for an example. Redcarpet also has some MultiMarkdown extensions for tables and other things, so that comes in pretty handy.

To generate the PDF I'm using Prince, a neat little tool that takes HTML and a bunch of CSS and generates a nice PDF. It's a commercial tool, and costs some $500 for a single license. That was what threw me off a tiny bit, but luckily there's a handy service called DocRaptor which is basically a pretty API around Prince, but much much cheaper.

You can use Prince locally to generate infinite test PDFs, and then use DocRaptor to generate the final result. Which is what I do. Before generating the PDF through DocRaptor I upload the generated HTML, which includes all the CSS, to S3, to avoid some issues I've had with Unicode characters in the HTML, and tell DocRaptor to fetch it from a URL instead.

You can use web fonts easily, I went for fonts from Google Web Fonts, which are easily embeddable with Prince and DocRaptor. Prince also allows you to do some customizations specific, stuff like page titles, page numbers, custom settings for left and right pages, footnotes, and the like. See the documentation for a full list.

For ePub generation I generate a stripped-down version of the HTML, not including syntax highlighting, because iBooks doesn't like custom-styled pre or code elements, if you style them iBooks chooses to ignore any font setting and use the default font, which is usually not monospaced.

The HTML then goes through Calibre to generate the ePub file, and then I use kindlegen to generate a Kindle file from that. Calibre has a pretty ugly user interface, but it comes with a set of command line tools you can use to automatically convert ebooks from one format to another.

All of the above is wrapped into a Rakefile and some small Ruby classes. I'll be sure to put it up for your perusal soon, but this list should get you started.

To make the book available for purchase I'm using FastSpring. They're not my favorite choice, as they make things like customizing your shop fairly hard, but I chose them because their way of payout (monthly or bi-monthly), and the fact that they take care of VAT, were both reasons important to me, especially being in Europe, where tax laws throw a lot of stones at you for wanting to try and sell things internationally. Unfortunately FastSpring doesn't have any means of updating products and allowing and notifying users of the updates being available, so I built a small Sinatra app to capture orders and take care of sending out the updates. Not pretty, but it's a small sacrifice compared to the tax hassle I'd have with any other fulfillment provider.

Curious about the result? You should buy the book!

DRUG #25

2012-01-11T17:03:20+00:00

During my leave in beautiful Wrocław, I had a chance to attend DRUG #25 meet-up. DRUG (Dolnośląska Grupa Użytkowników Ruby) is Lower Silesian Ruby user group, and their meetings usually take place once a month.

Andrzej Krzywda introduced me to a non-written rule of DRUG, which states “[i]f it’s your first time then you are presenting a talk”. I presented a quick talk about Travis CI. While it came as no surprise, that everybody knew the topic, it was especially nice to see people asking more detailed questions about current state, the future and sharing what they have done with Travis.

The people I met are tremendous and I will be happy to see them again on Wroclove.rb! Big thanks to all attending and especially to @kolarzowski, @piterniel for having me at their office during my leave. See you all soon!

Railslove at war

2012-01-11T16:44:20+00:00

Today, January 11th, 2012 – a date which will live in infamy – Railslove was suddenly and deliberately attacked by the dark forces of 9elements.
Railslove was at peace with that nation and looking toward the maintenance of peace. In a brutal attack 9elements took one of the Railslove team members as hostage while being on a friendly mission visiting their headquarters.
It will be recorded that the visit of the Railslove member took place on solicitation of 9elements – it is obvious that the attack was deliberately planned many days or even weeks ago.
Because of this circumstances we are forced to protect ourselves and have to free our team member.
I ask that Railslove declare that since the unprovoked and dastardly attack by 9elements on January 11th, 2012, a state of war has existed between Railslove and 9elements.
Let Paintball Borken be our battleground for this gigantomachia!

proof:

The only constant is change

2012-01-07T23:00:00+00:00

This blogpost had a loooong, long way to go, and I’m immensely glad I am finally able to write it, but also quite anxious about it - Not about the post as such, but about the implications of my acts that lead up to this post.

I am relatively risk-averse. I think many of us are, and I think we germans are especially good at it. Change is frowned upon.

That being said, sometimes change is just inevitable. For me, it has been since at least the before-last end-of-year, where I almost broke up with my girlfriend and, by the time the year was done, both of us lived, after 7 years of living together, in our own flats again. We’re happy together, with the usual highs and lows, but the separate living spaces give us shelter when things are rough, which, you know, also inevitably happens.

So, that’s change on a totally personal level and that’s totally not what I was going to write about - Nevertheless, with someone who doesn’t draw very distinct lines between personal and professional life, it plays an important part.

From that time on, a lot of things started to happen at once. First of all, although I loved (and still do) working at mindmatters, I started to look for alternatives - I wanted to, so to speak, level-up my work life. Which is actually not that easy, especially at an awesome place like mindmatters. So, I only have had two valid ideas back then: Founding a startup (and maybe applying for something like HACKFWD) or going freelance. Now, I’ve been doing freelance work before (during my studies) and I always hated the overhead of writing invoices, making sure that people pay me, etc, etc. Also, what we do at mindmatters is mostly client work, and going freelance would basically mean doing the same thing, with less security, less awesome colleagues and bosses, less project management support and slightly higher pay.

Then Florian, my colleague and foodie inspiration number one, convinced our founders (at mindmatters, that is) to open an office in london - I won’t go into the details why we think that this is a brilliant idea - that’s a whole different blog post and not one I should write, but of course I was keen to look at it and in the beginning I was quite sure that I would end up in London at the beginning of 2012.

Then I spent my summer vacation in San Francisco, 3 weeks of awesomeness in the Haight and in the Mission (Home and Work) and of course I fell in love with it. I was hoping to be able to write a blog post about SF as well, but somehow I never managed. Well, I hope to be back this year for a few weeks - We’ll see how that goes. What SF did to me, though, was giving me thoughts on a pretty much existential scale. What I learned there was that there are a lot of awesome places to live all around the world. But what I also learned there is how much I love my little, totally behind and totally mismanaged, not-having-a-super-awesome-tech-scene, Hamburg. My hometown. I’ve been born here, in a blue-collar neighbourhood called Barmbek before my parents and me moved to what people probably would call the outskirts of northeastern Hamburg. I basically lived there until 2010, when I moved much closer to the city centre, to lovely Eimsbüttel. Ironically, as a side note, my girlfriend now lives a few blocks away from the place my parents and my grandmother (who died in 2011, may Jutta Krutisch rest in peace) and I lived until the late 70s.

This feeling of home was, unfortunately, only amplified when I spent three weeks in London after coming back from SF, working on a project there for mindmatters, so-to-speak paving the way for mindmatters.co.uk and getting a good feeling for how it is to live there. Don’t get me wrong, I love London. I love the food options as much as Florian (although not as fiercely, maybe), I love the vibrant tech scene, I love the openness of an english pub, I love that I instantly found a place that sells me american IPA’s, an addiction I formed in SF, I love all of that.

But I also very much love the quietness of Hamburg. And I started to hate everything that’s connected to Air traffic. The easyJet connection to London is okay-ish and bearable if everything’s fine. One little thing and it turns into this nightmarish hour long wait at the gate which the converts into a situation where the BorisBike from London Bridge to Kings Cross (where I was staying at the time) is actually the sane way to go home an 1:30 on a monday morning.

So even if I am able to tuck away my environmentalist heart (which bled quite heavily in 2011 due to all the flights I took) for a second, moving to london would have meant either giving up my relationship (which, as I wrote, just recovered from what I would call an existential crisis) or spending way too much time and nerves on my carbondioxide budget.

Additionally to that, having a long-distance relationship may be fine, as long as you are already rooted in the place you live, but having one from a city where you actually just moved to also probably prevents you from actually growing any roots in that new city.

In the end, I wasn’t able to make any clear commitments to Florian and the mindmatters peeps that I would go over with him in the beginning of 2012.

What I had sworn to myself, though, somewhere in the process, was that I would not simply go back to business as usual when not going to London, but finally, finally, make sure that I also change course professionally.

And that’s what’s going to happen with me, starting Feb 2012. I’ll reduce my work for mindmatters to 20% of a normal contract (meaning about a day a week on average) and I will start freelancing for the rest of the time.

So why stay on the 20%? First of all, I love mindmatters. I am one of their first full time employees, starting in 2007 (which also means that I will be able to celebrate my 5 years of mindmatters in April, something I very much look forward to). I think the way Frank and Wolfgang steer their little company sets an example on transparency, accountability and humanity. This sounds huge, but I mean it. Most companies I know of don’t openly discuss their business goals, even their business model, their finance status and various other things openly in a company meeting every four weeks. Most companies I know would not work in a way where I as an employee can come up to my CEO and say “BTW, I’m planning to leave over the course of the next half a year, let’s talk how we can make this as smooth as possible”. Don’t get me wrong, it’s not all flowers and fluffy pink clouds in mindmatters-land - There are disagreements, there are arguments, there are misunderstandings, heck, after all, this is not a democratic parliament, this is a privately held company with business- and other goals. But I have never, ever before seen owners try so hard to keep up their vision (even through hard times and tough winds) on how to run a company and realign this vision with the help of every employee over and over again, iterating and iterating, and thus becoming, if the word would not be almost meaningless by 2012, a truly agile company.

So, I want to be part of that for as long as possible. I want to play my own part in keeping up that spirit, helping with my experience, my wit and my bad puns.

Regarding my work as a freelancer, although I have not signed any contracts by now, I am most probably already booked out for 2-3 days per week in the first quarter, which should at least give me a base on which to ponder what to do next.

It is actually not my goal to spend the rest of 2012 doing freelance work, but to try out various ideas, of some of which you hopefully will hear about “very soon now”, although, if you have something interesting for me, hit me with it, because I can’t look much further than a few months right now and actually everything beyond the start of February is still quite cloudy right now.

Which gives me the creeps, but also makes me quite happy. I am, for once, completely on my own, without being alone in it.

Happy new year, everyone

a very Merry Christmas

2011-12-23T13:41:05+00:00

We wish you all a wonderful christmas time!

Holiday Reading List

2011-12-22T00:00:00+00:00

Here's a list of things I've been reading lately or that I'm about to read, and that I found to be worth sharing. If you're looking for something to read over the holidays, I'm happy to give you some suggestions. Books, papers, articles, and videos, something for everyone.

Scalability Rules

A list of 50 rules related to scalability, in an easy to read recipe style. They leave some stuff to the imagination, and I don't agree with every single rule, especially not with the one that demands software should always be easy to rollback, but they give you good food for thought for your own applications.

Time, Clocks, and the Ordering of Events in a Distributed System

The earliest paper (1978!) to mention the notion of clocks as a means to track ordering of events in distributed systems, the predecessor to vector clocks, if you will. A must read.

Harvest, Yield, and Scalable Tolerant Systems

A recap of CAP, making the whole notion of it a bit more flexible by adding tuning knobs for graceful degradation. Hat tip to Coda Hale and his article "You can't sacrifice partition tolerance" for pointing me to this.

Problems with CAP, and Yahoo's little known NoSQL system

Also related to CAP, this article introduces the notion of PACELC, which basically adds latency to the CAP equation. CAP has been criticized quite a few times for being too strict in this regard, and while the name PACELC is a bit odd, the added notion of latency makes a lot of sense.

Replication and the latency-consistency tradeoff

Another one from Daniel Abadi, another one related to CAP, this time talking about replication, consistency, and latency.

It's the latency, stupid!

Going further back in time, this paper talks about latency in all its glory. Sure, it talks about modem speed connections, but extrapolate that into today's network bandwidth and you still have latency. Or you can read the next posts too.

It's Still The Latency, Stupid...pt. 1 and It's Still The Latency, Stupid...pt. 2

A more recent update on latency, because it still matters more than bandwidth.

Crash-only Software

I've been pondering fault-tolerant and cloud-ready systems for a while now, here's one related to the topic, software that crashes as a means to make it more fault-tolerant.

Systems that Never Stop (video)

Great talk by Joe Armstrong, inventor of Erlang, laying down six laws for fault-tolerant systems. All laws lead to Erlang obviously, but it all makes a lot of sense.

Why Do Computers Stop and What Can Be Done About It?

Related to Joe's talk, this paper discusses hardware reduncancy and reliable storage by means of process pairs, modularity and transactions. Have yet to read this one, but going to be interesting thinking about how these ideas, stemming from hardware, apply to software and have been implemented by Erlang.

Working With Unix Processes

A little indie-published ebook on handling Unix processes. Code is focused on Ruby, but most if not all of the book is easily applicable to any other language or a basic Unix environment.

SEDA: An Architecture for Well-Conditioned, Scalable Internet Services

SEDA was an idea for web and application server concurrency based on using queues to condition and handle requests. While the idea has not exactly made it through, I found the model to be strikingly similar to the actor model, in a different way, but still very similar.

A Retrospective on SEDA

SEDA, ten years later, by the author of the original paper. I gotta say, he talks a lot what they got wrong, but I for one think SEDA had a pretty big impact on the bigger picture of web application architecture. Probably something worth discussing in a separate post.

Why Events Are A Bad Idea

A paper comparing threads and events for highly concurrent servers. I'd recommend taking this with a grain of salt. A lot has changed since this paper was written, but what I like about reading papers like this is that it gives you a historic perspective, same for SEDA.

Understanding Virtual Memory

Nice summary of how virtual memory works on Linux.

The Declarative Imperative: Experiences and Conjectures in Distributed Logic

To be honest, this is a slightly confusing paper. It starts out modeling things in an oscure language called Datalog, but then dives into making some conjectures about distributed logic, which was to me the more interesting part.

A brief history of Consensus, 2PC and Transaction Commit

This article is full of gold. An extraordinarily compact view on the topic, but with an abundance of links to papers to dive deeper.

Going to keep posting reading lists like this in the future. So much good stuff to read out there. Lots of great knowledge collected in papers.

Last but not least, why not add the Riak Handbook to your reading list as well?

Storing User Timelines in Riak

2011-12-15T00:00:00+00:00

The idea of building and storing user timelines (think Twitter) in Riak confused me at first. It sounds like such a spot-on case for time series databases. Yet Yammer managed to make the idea pretty popular. The whole thing lacked implementation though, because they kept their to themselves, which I don't blame them for at all.

So let's have a look at how simple it is to build one. You can see a timeline of all Apple Macintosh products above, but that's not what we want to build.

Instead we want to build something like the Twitter timeline. A user follows many other users, and wants to look at a feed built from their activities, so something like the timeline shown below.

How do you model a timeline in Riak?

For every user we store one object in Riak. Every timeline contains a list of tweet ids, or whatever activity you're referencing, or it can contain the whole tweets. Something like this should work:

If you want to store more data, turn the list into an array of hashes containing whatever information is necessary to rebuild the timeline later.

Adding entries to the timeline

To add new entries to a timeline, prepend them to the existing list of entries, here's some Ruby code to show how it's done.

The code assumes you take care of followership somewhere else. You can store that data in Riak too, but the code is oblivious to its whereabouts.

Conflicts, siblings, oh my!

The fun starts when two clients update the same timeline, you get a conflict and siblings. The strength of a simple data structure like the example above is that they're easy to merge together while still keeping ordering based on the ids. The ids are ordered only in this example, Twitter somewhat makes sure they are.

When you get a conflict, a smart Riak library like Ripple helps you find out about it. To add on the earlier example, here's a version of add that detects conflicts.

Suddenly you have two or more objects instead of one, each containing a different timeline. To turn them into a single list, you merge all of them together, discard the duplicates, and restore order based on the id. Here's some Ruby to do that.

You iterate over all timeline objects and keep adding unique activities to a new list, returning that when done.

Sort, and done!

All that's left to do is sort the result.

There's the whole code. To spare you the pain of having to write your own library, all this is bundled into a gem called riaktivity. If you're doing Python, the Brett Hoerner has got you covered with timak. Be sure to watch the original talk by Yammer, it's well worth it.

There's ups and downs to this approach, and things that need to be taken care of. More on that and modeling data for Riak in general is covered in the Riak Handbook, the definitive guide on Riak.

List All of the Riak Keys

2011-12-13T00:00:00+00:00

One of the most common questions to ask about Riak is: how do I get a list of all the keys in my bucket, in the cluster, or that have an attribute that matches my query using MapReduce?

The motivation behind it is simple: you want to delete all the keys in a bucket, count the amount of keys stored in your cluster entirely, you want to clear out your cluster or you want to run ad-hoc queries on the data stored in a bucket.

All valid in their own right.

But things are not so simple with Riak. To understand why, let's take a quick look under the covers.

What's in a bucket?

A bucket is a namespace in Riak. It's not a physically distinctive entity like a table in a relational database. You can set some properties on it, things like replication levels, commit hooks, quorum, but that's it. Those are stored in the cluster's configuration which is gossiped around the cluster just like the data that identifies what partition goes on which machine.

In fact, when you specify a bucket and a key to fetch or write some data, they're stuck together to find the location in the cluster. Consider a bucket-key combination like users/roidrage. To find the location, Riak hashes both, not just the key. Both bucket and key uniquely identify a piece of data, allowing you to have multiple object with the same key, but in different buckets.

When an object is stored in Riak's storage backends, it uses both bucket and key name to identify it. What you get as a result are files that contain an abundance of different bucket-key combinations and their respective objects, sometimes not even in any order. The only physical distinction Riak has for data on disk is the partition they belong to. Everything else is up to the storage backend. There's no distinction between buckets on disk.

One reason for this is consistent hashing. If you remember the last installment of this series, I mentioned that consistent hashing's downside is that you lose key ordering. Keys are randomly spread out through the cluster. Some ordering still exists depending on the backend, but in general, ordering is lost.

Listing all of the keys

So to list keys in a bucket, Riak has to go through all of the keys in every partition, and I mean ALL OF THEM. Here's a picture of keys and an impersonation of Riak, having to take care of all of them.

No big deal, right? Unless of course, you store millions and millions of them, and want to find about all the keys from say, the bucket users, which may not even have to be more than 1000. To do that, Riak goes through every partition, every partition loads the keys either from memory (Bitcask) or disk (LevelDB) and sifts through them, finding the ones belonging to the users bucket.

All that said, it's certainly not impossible to do, if you have some time to wait, depending on the amount of data stored.

$ curl 'localhost:8098/buckets/users/keys?keys=true'

But wait, don't do that. Do this instead, streaming the keys instead of waiting for them all to arrive and then having them dumped at once.

$ curl 'localhost:8098/buckets/users/keys?keys=stream'

That's much better.

Listing keys has an impact on your Riak nodes, so if you can avoid it, don't do it!

So how do I really get all of the keys?

If select * from riak is not a great option, then what is?

Instead of relying on Riak, build an index on the keys. Thanks to Riak 2i (Secondary Indexes), this is easy. In fact, you get indexing of keys for free when using the LevelDB backend, just use the index $key. This takes advantage of LevelDB's sorted file structure. Neat!

But, and here's the kicker, you can only fetch ranges of keys. So instead of asking for all the keys, you ask for a range large enough to fit all the keys.

$ curl 'localhost:8098/buckets/users/index/$key/0/zzzz'

This finds all the keys that start with something lexicographically larger than 0 and less than zzzz and returns them to you in a list. Now there's a slim chance you'll get users with names like that, but I'll leave that exercise, or proper validations, up to you.

Using that list, you can count the number of keys in that bucket, or you can delete them one by one.

Ideally...

In an ideal world, listing keys in a bucket would be possible and not an expensive operation. Riak could for example allow users to store buckets in separate files. The downside is that with a lot of buckets, you'll hit the limits of open file descriptors in no time, a bit of a bummer. But until something better comes along, secondary indexes are a nice tool to at least avoid resorting to listing all of the keys.

Curious about other ways to index and query data in Riak? You'll like the Riak Handbook, which will be published later this week. Covers Riak's secondary indexes and other strategies to query, inspect and analyze data.

Check back in tomorrow for an introduction on storing timelines in Riak.

The Simple Magic of Consistent Hashing

2011-12-09T00:00:00+00:00

The simplicity of consistent hashing is pretty mind-blowing. Here you have a number of nodes in a cluster of databases, or in a cluster of web caches. How do you figure out where the data for a particular key goes in that cluster?

You apply a hash function to the key. That's it? Yeah, that's the whole deal of consistent hashing. It's in the name, isn't it?

The same key will always return the same hash code (hopefully), so once you've figured out how you spread out a range of keys across the nodes available, you can always find the right node by looking at the hash code for a key.

It's pretty ingenious, if you ask me. It was cooked up in the lab chambers at Akamai, back in the late nineties. You should go and read the original paper right after we're done here.

Consistent hashing solves the problem people desperately tried to apply sharding to pretty nicely and elegantly. I'm not going to bore you with the details on how exactly consistent hashing works. Mike Perham does a pretty good job at that already, and there are many more blog posts explaining implementations and theory behind it. Also, that little upcoming book of mine has a full-length explanation too. Here's a graphic showing the basic idea of consistent hashing, courtesy of Basho.

Instead I want to look at the practical implications of consistent hashing in distributed databases and cache farms.

Easier to Avoid Hotspots

When you put data on nodes based on a random result, which is what the hash function calculates, a value that's a lot more random than the key it's based on, it's easier to avoid hotspots. Why?

Assume a key based on an increasing value, or a simple range of keys, based on the hour of the day, like 2011-12-11-13. You add new hours and therefore new data as time passes, and keys are stored based on the range they fall in. For example, the keys 2011-12-11-18 until 2011-12-11-23 are stored on the same node, with the rest of the keys stored on other nodes, just because the ranges or the partitioning scheme happen to be set up this way.

For a consumer-facing site, the evening hours are usually the busiest time of the day. They create more data, more writes, and possibly more reads too. For the hours between 18:00 and 23:00, all the load goes to the single node that carries all the relevant data.

But when you determine the location in the cluster based solely on the hash of the key, chances are much higher that two keys lexicographically close to each other end up on different nodes. Thus, the load is shared more evenly. The disadvantage is that you lose the order of keys.

There are partitioning schemes that can work around this, even with a range-based key location. HBase (and Google's BigTable, for that matter) stores ranges of data in separate tablets. As tablets grow beyond their maximum size, they're split up and the remaining parts re-distributed. The advantage of this is that the original range is kept, even as you scale up.

Consistent Hashing Enables Partitioning

When you have a consistent hash, everything looks like a partition. The idea is simple. Consistent hashing forms a keyspace, which is also called continuum, as presented in the illustration. As a node joins the cluster, it picks a random number, and that number determines the data it's going to be responsible for. Everything between this number and one that's next in the ring and that has been picked by a different node previously, is now belong to this node. The resulting partition could be of any size theoretically. It could be a tiny slice, or a large one.

First implementations of consistent hashing still had the problem that a node picking a random range of keys resulted in one node potentially carrying a larger keyspace than others, therefore still creating hotspots.

But the improvement was as simple as it was ingenious. A hash function has a maximum result set, a SHA-1 function has a bit space of 2^160. You do the math. Instead of picking a random key, a node could choose from a fixed set of partitions, like equally size pizza slices. But instead of picking the one with the most cheese on, everyone gets an equally large slice. The number of partitions is picked up front, and practically never changes over the lifetime of the cluster.

For good measure, here's a picture of a sliced pizza.

Partitioning Makes Scaling Up and Down More Predictable

With a fixed number of partitions of the same size, adding new nodes becomes even less of a burden than with just consistent hashing. With the former, it was still unpredictable how much data had to be moved around to transfer ownership of all the data in the range of the new node. One thing's for sure, it already involved a lot less work than previous methods of sharding data.

With partitioning, a node simply claims partitions, and either explicitly or implicitly asks the current owners to hand off the data to them. As a partition can only contain so many keys, and randomness ensures a somewhat even spread of data, there's a lot less unpredictability about the data that needs to be transferred.

If that partitions just so happens to carry the largest object by far in you whole cluster, that's something even consistent hashing can't solve. It only cares for keys.

Going back to HBase, it cares for keys and the size of the tablet the data is stored in, as it breaks up tablets once they reach a threshold. Breaking up and reassigning a tablet requires coordination, which is not an easy thing to do in a distributed system.

Consistent Hashing and Partitioning Enable Replication

Consistent hashing made one thing a lot easier: replicating data across several nodes. The primary means for replication is to ensure data survives single or multiple machine failures. The more replicas you have, the more likely is your data to survive one or more hardware crashes. With three replicas, you can afford to lose two nodes and still serve the data.

With a fixed set of partitions, a new node can just pick the ones it's responsible for, and another stack of partitions it's going to be a replica for. When you really think about it, both processes are actually the same. The beauty of consistent hashing is that there doesn't need to be master for any piece of data. Every node is simply a replica of a number of partitions.

But replication has another purpose besides ensuring data availability.

Replication Reduces Hotspots (Even More!!!)

Having more than one replica of a single piece of data means you can spread out the request load even more. With three replicas of that data, residing on three different nodes, you can now load-balance between them. Neat!

With that, consistent hashing enables a pretty linear increase in capacity as you add more nodes to a cluster.

Consistent Hashing Enables Scalability and Availability

Consistent hashing allows you to scale up and down easier, and makes ensuring availability easier. Easier ways to replicate data allows for better availability and fault-tolerance. Easier ways to reshuffle data when nodes come and go means simpler ways to scale up and down.

It's an ingenious invention, one that has had a great impact. Look at the likes of Memcached, Amazon's Dynamo, Cassandra, or Riak. They all adopted consistent hashing in one way or the other to ensure scalability and availability.

Want to know more about distributed databases in general and Riak in particular? You'll like the Riak Handbook, a hands-on guide full of practical examples and advice on how to use Riak to ensure scalability and availability for your data.

In the next installment we're looking at the consequences and implications of losing key ordering in a Riak cluster.

Configuring Nginx for the Asset Pipeline

2011-12-07T14:00:00+00:00

Following up on the series of posts about the Rails Asset Pipeline, here are some things to keep in mind when you are using Nginx as your webserver.

Installation via Passenger

When you are installing Nginx automatically with the script that comes with Passenger, you will not be able to serve the gzipped file variants that get precompiled. That’s because Passenger currently does not configure Nginx with the http_gzip_static_module that would be necessary for including the directive gzip_static on. I’ve opened a pull request for that, but for now you’ll have to choose the manual installation, if that’s what you are after - and why wouldn’t you?

# download and untar nginx
              wget -O /tmp/nginx.tar.gz http://www.nginx.org/download/nginx-1.0.10.tar.gz
              tar xzvf /tmp/nginx.tar.gz
              rm /tmp/nginx.tar.gz
              
              # install nginx via passenger install script, already includes
              # --with-http_ssl_module
              # --add-module for passenger
              passenger-install-nginx-module --auto --prefix='/opt/nginx' --nginx-source-dir='/tmp/nginx-1.0.10' --extra-configure-flags="--with-http_gzip_static_module"

You might want to change the version and prefix to fit your needs. Like mentioned in the comments you don’t have to take care of including the passenger or ssl module, because the installation script adds them automatically.

Nginx configuration

This is already part of the Asset Pipeline Guide, but I’ll mention it here again, so that this article is complete - here are the directives for the assets location config:

location ~ ^/(assets)/  {
                root /path/to/site;
                gzip_static on;
                expires max;
                add_header Cache-Control public;
                # access_log /dev/null;
              }

~~I’ve also disabled access logging, so that asset requests do not clutter up the log.~~

Mathias brought up a good point, why one might not want to do that.

Sendfile Header

In your app’s production.rb you should uncomment to following line, to let Nginx send static files:

config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect'

Verify that it’s working

After deploying the changes, you can check if Nginx is now serving the gzipped compressed versions of your asset files. For that you can use tools like this HTTP Compression Tester and enter the address of your application.js and application.css

Referencing Rails Assets in CoffeeScript

2011-12-05T23:45:00+00:00

Sometimes you’ll want to refer to your image assets from inside of your CoffeeScript (or JavaScript). While we have nice helpers for that in SASS (namely image-path and image-url), we would have to resort to appending .erb to every .js or .coffee file, we want to reference images in, so that we could use something like this in there:

icon = %= image_path('icon.png') %>

I didn’t like it that way, because ERB inside of CoffeeScript looks odd and having the file end with .erb messes up syntax highlighting. But we can circumvent this easily by adding this (admittedly not the most beautiful) piece of code to one single file that ends on .erb (i.e. images.js.coffee.erb) and let it provide the helper method we need:

%
                imgs = {}
                Dir.chdir("#{Rails.root}/app/assets/images/") do
                  imgs = Dir["**"].inject({}) {|h,f| h.merge! f => image_path(f)}
                end
                %>
                
                window.image_path = (name) ->
                  %= imgs.to_json %>[name]

This adds up all images inside of app/assets/images and makes them available via the global helper method image_path - your milage may vary, but you get the idea. From there on it’s simply

icon = image_path('icon.png')

inside of your CoffeeScript (or JavaScript) files and it also works in production as the returned filename contains the digest.

reminder: Global Day of Coderetreat Cologne/Bonn 3rd Dez.

2011-12-01T13:32:14+00:00

The upcoming saturday (Dez. 3rd) is Global Day of Coderetreat. It’s a world-wide event celebrating passion and software craftsmanship.

Coderetreat is a day-long, intensive practice event, focusing on the fundamentals of software development and design.

You can find more information about the Coderetreat format and the event on the official website. For cologne all the information is on a github wiki and you should follow the office twitter account for updates.

The event will take place in our office and starts at 8:30 in the morning.

See you there!

OpenData Bremen

2011-11-30T09:00:00+00:00

Im Rahmen des OpenData-Wettbewerbs Apps4Deutschland fand in Bremen am Freitag, den 11. November 2011 die Auftaktveranstaltung zu Apps4Bremen statt. Nach dem Vorbild Berlin macht nun auch das Land Bremen Teile der Daten staatlicher Stellen öffentlich und läd dazu ein, diese zu verwerten und sinnvoll aufzubereiten - auf der Apps4Deutschland-Website heißt es dazu:

Behörden in Deutschland erheben, speichern und verarbeiten viele interessante Daten. Dazu gehören Wetterdaten ebenso wie Informationen über die Luftqualität oder über die Verwendung der Steuergelder. Diese Daten sind von öffentlichem Interesse und bergen ein großes Potenzial für unsere Gesellschaft, weil sie Transparenz, Beteiligung, Innovationen und neue Dienstleistungen fördern.

Mit dem Wettbewerb „Apps für Deutschland“ laden wir Designer, Entwickler, Journalisten, Forscher und die breite Öffentlichkeit ein, Anwendungen zu schaffen, um diese Daten nutzbar zu machen.

Da ich das Thema Open Government spannend finde und für sehr wichtig halte, war der Wettberwerb ein guter Anlass, um mir eine neue Spielwiese für die offenen Daten Bremens zu schaffen. Das Projekt besteht aktuell nur aus einer Übersicht der Bremer Kindertagesstätten, lässt sich aber auf dem bisherigen Stand gut erweitern, da es bereits Beispiele für Datenimporter, Geokodierung und Darstellung von Orten auf einer Google Map enthält. Basis dafür sind Ruby on Rails und Backbone.js und der Quelltext ist auf GitHub verfügbar, so dass das Projekt gerne erweitert werden kann. Gerne lasse ich mich auch auf Ideen, Verbesserungswünsche oder Fehler hinweisen.

Wer sich inspirieren lassen möchte, kann auch mal einen Blick in den OpenData Showroom werfen, der Projekte aus aller Welt enthält, die sich offener Daten bedienen. Würde mich freuen, wenn sich viele weitere Leute finden, die mit den Daten was nettes auf die Beine stellen.

Precompiling Rails Assets for Development

2011-11-28T14:22:00+00:00

First off: I love Rails’ asset pipeline from the bottom of my heart. It’s a great thing and makes frontend development such a lovely task. There are two little drawbacks though when using it in development: It slows down page reloads and clutters up the log output. Here I’ll show you how to get rid of that.

When you are mainly doing backend development or most of your apps frontend code doesn’t change too much do yourself a favor and precompile your assets for the development environment:

$ RAILS_ENV=development bundle exec rake assets:precompile

This really speeds up page reloads as Rails does not need to look up and precompile the asset files every time a request hits the app anymore.

Another change you might want to make is to set config.assets.debug to false in your development environment. This makes Sprocket concatenate all your files (users.css, search.css, …) into one javascript and stylesheet file (application.css):

config.assets.debug = false

This also cleans up the noisy logging info concerning the asset files that were previously loaded one by one.

When you need to precompile additional assets that aren’t already referenced in you application.js or application.css you’ll want to move the config.assets.precompile directive from production.rb to application.rb:

config.assets.precompile += %w( search.js )

This isn’t directly related but while you are at speeding up our development experience you might also want to have a look at the rails-dev-tweaks gem. This gem defines rules for managing what files get reloaded on page requests in development.

Dear Cologne Rubyists: Your user group needs you!

2011-11-25T19:51:57+00:00

In November 2005 we’ve started the first Ruby usergroup in cologne. Back then we’ve been 4 people who met for beers. This was nearly exactly 6 years ago. Unfortunately the meetup has soon become inactive – actually I can not remember when that was and how it happened.

After that, I guess in 2007 the rurug.de started with greater success. It was a meetup which first took place in the rooms of the Chaos Computer Club Cologne. Sadly I haven’t participated in that meetup very activly :( *bad bumi*

Early this year the meetup then has moved to cowoco and renewed itself with about 30+ people attending. The following events had been awesome! Great talks and even better discussions. Unfortunatelly, after summer we’ve became very inactive again. Not many people participated on the mailing list and the event hasn’t taken place in the last two months.

WE NEED TO CHANGE THIS!!

And now is the time to rethink the meetup.
I know we have so many awesome ruby developers here in cologne, working on exciting projects!

We need to connect, share, teach in our local ruby community!
Let’s work together to bring back one of the best tech meetups in Cologne!

To get this started again I propose the following things:

changing the mailing list to something that is more accessible.
This is something I’ve heard several times. The current mailinglist is kinda hard to follow and it’s hard for people to get into the conversation. -this is especially the case for new people.
I also think the mailing list has some spam issues?!
maybe using a google group for now. I do not really like google groups but it works for cologneJS.
better organizations/archiving of the talk material like slides etc. – obviously ;)
inviting more speakers
speakers exchange is a great. I herby invite @joshkalderimis from Amsterdam to tell us about travis-ci
meetup for some delicious Glühwein on the christmas market to discuss these things
Date: 14th Dez. 07:00pm at Heumarkt

What do you think? How do you feel about the cologne ruby meetup? Who joins me?

Cologne.rb let’s unite!

(also posted on my blog)

Git autocomplete in bash on a Mac

2011-11-25T09:24:44+00:00

I’ve been using Linux and bash for great chunk of time for web development, and it always had great features like autocomplete, that I didn’t get by default on a Mac.

So, I’ve decided to take matters into my on hands, and leave a post for all those, who are also bugged by no git autocomplete in bash on a Mac.

Thankfully, git already has its autocomplete script, so it’s a matter of just two commands:

But I like to take it one step beyond. To save some keystrokes, I’ve added some aliases to my ~/.gitconfig:

Now I can tab on git co and everywhere else I was used to on my Linux machine.

No magic behind it but everytime worth to remember

2011-11-23T21:18:49+00:00

Rspec Refactoring and Shared Example Groups

Today we had lightning talks about specs refactoring. Jan showed us some tricks based on his experiences from our latest open source project: railsrunners.org (Github):

Some simple spec principles

Use clear descriptions for your specs in combination of using “describe”-, “context”-blocks
Use contexts and descriptions properly, e.g.: describe "#edit"; context "with valid params"; etc.
Use the –format documentation parameter to check your descriptions for specs, describes, and contexts. E.g.: rspec spec/controllers/participants_controller_spec.rb --format documentation
Instead of manually creating associated models in your tests just to pass validations, FactoryGirl can automatically create them for you, e.g.:

Then instead of:

You’d simply have:

Write one assertion per test.
Stub requests using FakeWeb (Update: or WebMock or any other Request-Mocking-Helper), e.g.: FakeWeb.register_uri(:get, “http://static-maps-generator.appspot.com/url?msid=#{@future_run.msid}&size=950×300″, :body => response)
Controller specs should only test the behaviour of your controller. Model specs test the behaviour of your model. Don’t mix the two! E.g.: do not test after_ or before_ save callbacks in your controller tests.

Take a look at the railsrunners Github repository: Github

Shared example groups

Sometimes you want to test the same behaviour in various specs or contexts. To keep your code DRY, you can use RSpec’s shared example groups:

If needed, you can move the shared example group to a spec helper and require that wherever you need to test for ‘successful responses’.

Setting up Ubuntu with Teleport

2011-11-15T13:15:00+00:00

Some time ago I came across Teleport which pitches itself as a lightweight way to set up Ubuntu machines. Having failed at mastering the steep learning curve that full-blown tools like Chef or Puppet provide, I was willing to give Teleport a shot. Teleport stays simple by focusing on Ubuntu and providing just the right set of tools to set up the whole Ruby/Rails eco system. This makes it less powerful than the other aforemention tools, but in my case it’s just what I was looking for.

Some facts: Teleport …

consists of a configuration (Telfile) plus files you want to be present on the target
copies itself onto the target via ssh and then runs itself there (hence the name)
works idempotently - run it over and over again without breaking the target

My setup

For each project I store everything that belongs to Teleport in a specific deployment folder. This folder might look something like this:

|____Telfile
                      |____recipes
                      | |____install_passenger_nginx.rb
                      |____files
                      | |____etc
                      | | |____gemrc
                      | | |____init.d
                      | | | |____nginx
                      | |____Gemfile
                      | |____Gemfile.lock
                      | |____opt
                      | | |____nginx
                      | | | |____conf
                      | | | | |____nginx.conf

The configuration is done inside the Telfile:

user "deploy"
                      ruby "1.9.3"
                      server "my-own-vps"
                      
                      apt "deb http://ppa.launchpad.net/chris-lea/node.js/ubuntu lucid main", key: "C7917B12"
                      
                      packages %w(openssl libreadline5 libreadline5-dev curl
                        git-core libopenssl-ruby libcurl4-openssl-dev imagemagick
                        libsqlite3-0 libsqlite3-dev sqlite3 libxml2-dev libxslt1-dev
                        libmysqlclient-dev mysql-client mysql-server nodejs)
                      
                      recipes %w(
                        install_passenger_nginx.rb)

user defines the name of the account you will later use to deploy your app. This user gets added to the sudoers and your ssh key is uploaded for password-less login. ruby tells Teleport which version to install and server is the name you gave to the machine in your ~/.ssh/config.

As you can see you can also define customs apts and packages that should get installed. For performing special setup routines or invoking more complex tasks you can utilize the recipes feature. Recipes are standalone files that can be written in Ruby and allow for sharing and reuse. Here’s an example of how to install nginx via the passenger gem:

version_gem = gem_version("passenger")
                      version_installed = `passenger-config --version`.strip
                      
                      if !version_gem
                        warn "Passenger is not installed. Please add it to your Gemfile."
                      elsif version_installed == version_gem.to_s
                        banner "Passenger #{version_installed} is already installed"
                      else
                        banner "Installing Nginx via Passenger (installed: #{version_installed}, gem version: #{version_gem})"
                        run "passenger-install-nginx-module", %w(--auto --auto-download --prefix=/opt/nginx)  # install without prompting
                        run "update-rc.d nginx defaults"                                                      # activate autostart
                        run "service nginx restart"                                                           # restart nginx
                      end

The files directory contains files and directories that get copied over to the target machine - not much magic about that. To install system-wide gems you can place a Gemfile and Gemfile.lock inside the files directory.

Finally you can run the setup with

$ teleport my-own-vps

Keep in mind that you can re-run this every time you make a change to the Telfile or add new files. Teleport strives to be idempotent and can be run repeatedly without breaking the target machine(unless you explicitely messed up something ;)).

Let’s go…

There is much more to Teleport than what I could cover in this short post. For example you can define multiple servers with different roles or reverse engineering existing servers which makes it very easy to generate a Telfile from your current setup. In case you want to get started head over to the project wiki which contains a lot of information and examples.

Capybara Finder for Cucumber Rails’ Deprecated Tableish

2011-11-12T21:35:00+00:00

The cucumber-rails gem recently deprecated the tableish method which could be used to verify data in tables using Table#diff!. Tableish was easy to use but also had some limitations so that from now on you are advised to use Capybara’s finder API which is much more flexible.

In case you are now searching for a replacement for tableish, look no further:

rows = find("table#selector").all('tr')
                        table = rows.map { |r| r.all('th,td').map { |c| c.text.strip } }
                        expected_table.diff!(table)

This maps the table into a two dimensional array containing all cell contents. The last line diffs this array against the expected_table which is the table that’s passed into the step definition like explained on this Cucumber wiki page.

You’ll have to replace table#selector with the actual table selector you are looking for.

When using capybara-webkit for testing elements that get inserted into the page via JavaScript I had to change this a little bit, because the finder did not seem to work with capybara-webkit. One can circumvent this by parsing the page body and using the finder on the new result:

html = Capybara::Node::Simple.new(body)
                        rows = html.find("table#selector").all('tr')
                        table = rows.map { |r| r.all('th,td').map { |c| c.text.strip } }
                        expected_table.diff!(table)

Global Day of Coderetreat Cologne / Bonn

2011-11-03T10:04:54+00:00

Corey Haines is organizing a Global Day of Coderetreat for the 3rd of December. Many cities world-wide will collaborate and hold local code retreat events. Cologne, especially the Coworkingspace Gasmotorenfabrik is one of the hosts. For future details and registration check out:

Github
Xing

Installing MacVim with Ruby support and Command T on OSX Lion

2011-10-17T17:21:31+00:00

When I set up my new Macbook Air recently, I ran into some unexpected problems setting up MacVim – mostly related to Ruby versions linked against MacVim and the Command T plugin. Here are some notes that might help you.

Note
In case you wonder: MacVim uses it own separate version of vim (installed here: /Applications/MacVim.app/Contents/MacOS/Vim), which is not linked against your own /user/local/bin/vim (or wherever your vim resides), which you or your package manager installed separately. The reason I’m mentioning this is that if you lack Ruby support in MacVim, compiling vim by hand won’t help, since MacVim doesn’t use it.

Howto

activate your favourite version of Ruby via RVM or rbenv.

in my case:
$ ruby -v
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin11.0.1]

run (in case you haven’t already, download and install the excellent Homebrew):

$ brew install macvim

* start MacVim with
$ mvim
run :version and make sure it lists +ruby (instead of -ruby)
test Ruby support by invoking
:ruby nil[]
which should return a NoMethodError

$ mkdir ~/.vim

install Pathogen (better management of vim plugins, each living in its own subfolder inside ~/.vim/bundle)

to install Command T:

$ cd ~/.vim
$ git submodule add git://git.wincent.com/command-t.git bundle/command-t
$ git submodule init
$ git clone git://git.wincent.com/command-t.git bundle/command-t

with the same version of Ruby activated you used to install MacVim (Ruby 1.9.2p290 in my case), run:

$ cd ~/.vim/bundle/command-t
$ rake make

more details in section 4 “MANAGING USING PATHOGEN” of: https://github.com/wincent/Command-T/blob/master/doc/command-t.txt

create a symlink under Applications:
$ ln -s /usr/local/Cellar/macvim/7.3-62/MacVim.app /Applications/MacVim.app

Troubleshooting

1) Lacking Ruby support inside MacVim
Symptom: Plugins written in Ruby, like Command T or Lusty Juggler, don’t work.
Check: $ mvim –version or :version inside of MacVim should list “-ruby”, if your version lacks Ruby support (“+ruby” if it has Ruby support built in).
Cause: This happens when your version of MacVim was compiled without the –enable-rubinterp flag. This usually happens when you install a binary off MacVim’s Google Code Project.
Remedy: Best use Homebrew to install MacVim from source. Although the Homebrew command’s output does not explicitly list the –enable-rubyinterp flag, you should be fine and :version should list +ruby.

2) Can’t compile MacVim or vim
Cause: You probably didn’t install Xcode. Unfortunately you need proprietary Cocoa headers for MacVim, which are not included in this Kenneth Reitz’ GCC OSX installer (https://github.com/kennethreitz/osx-gcc-installer; cf. related problem: https://github.com/mxcl/homebrew/issues/7576).
Remedy: Install the full Xcode package via Apple’s App Store. Make sure to check your Launchpad for download activity – it took me half an hour to figure out that the app store’s Install button was actually doing something and not broken.

3) Command T complains about lacking C extensions
Symptom: Command T doesn’t start and informs me about missing C extensions.
Remedy: run rake make inside ~/.vim/bundle/command-t

4) Command T causes SIGTERMS
Symptom: After having compiled Command T’s C extensions, as soon as you try to invoke Command T inside MacVim, it causes the program to crash with a SIGTERM exception.
Cause: Usually the reason for the SIGTERM is that your MacVim was compiled with a link to a different version of Ruby than Command T. However, I encountered the same problem when linking everything against system Ruby (1.8.7 in my case).
Remedy: Be very careful about your RVM/rbenv settings and ensure the exact same version of Ruby is active when you compile MacVim (installing via Homebrew triggers a compilation process) or Command T. My issue was resolved by using Ruby 1.9.2 instead of system Ruby.

Resources

https://github.com/ralph/dotvim Ralph’s .vim files – certainly more well-honed and better organized than my own.
https://github.com/paulwittmann/vimrc-osx my current .vimrc & plugins on OSX. Still lacking some features, but more cleaned up than my old one for Ubuntu.

“Birthday” gem for easy anniversaries handling

2011-10-17T09:59:10+00:00

While working on one of our client projects, I was asked to create a search for users’ birthdays. Instantly, I remembered what problems I had with it in the past, like taking care of not only finding the right dates by only day and month, but also, checking for birthdays today, any upcoming birthdays, or even just looking up user’s age based on that information.

So, to never ever repeat that code again (and to keep the code DRY), I’ve decided to write a simple gem specifically for this stuff. And thus the birthday gem was born.

Requirements

The gem has been tested against Rails 3 (3.0.9) and Rails 2 (2.3.14), and depends on ActiveRecord and ActiveSupport (for inflections), making it a perfect fit for Rails. It is possible to use it outside Rails project, but you are required to use ActiveRecord as your ORM framework.

The gem works with MySQL and PostgreSQL adapters, but you can write your own adapters, if you need to. If you do so, it would be good to fork the gem and add it there for everybody to use. :)

So, how does it actually work?

Handling birthdays wasn’t that easy before. Here’s what you have to do in your model:

That’s all. This one line enables extra actions on the “birthday” field (of DATE or DATETIME types) in your database. For example from now on you can search for birthdays

on a specific date:
between a specific range:
and even at the turn of the years:

All these methods are essentially scopes, so you could also do something like:

On top of that, you get convenience methods for single records, like getting the age:

You can get any field to behave like this. For example, let’s say we want marriage anniversaries:

And it’s done, from now on you have convenient scopes to search and handle anniversaries:

Final words

I’ve done this gem, because I never ever want to write this piece of code again, I’d rather spend my time on actually coding the important stuff in applications, than to fiddle around with dates and birthdays. Hope this gem will be of some use to you. If not, fork it, and patch it to your needs! :)

Backlash @ Robot Unicorn Invasion Party 2011

2011-10-13T15:05:42+00:00

Backlash @ Robot Unicorn Invasion Party 2011 by Backslash on Mixcloud

Help You need somebody; Help not just anybody!

2011-10-11T22:36:28+00:00

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

2011-10-03T20:04:29+00:00

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

The DevHouseFriday Chillout and the stolen Adcloud chair

2011-09-27T12:01:54+00:00

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.

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.

10th anniversary of Polish Wikipedia

2011-09-27T10:02:43+00:00

Last weekend, as a long-standing Polish Wikipedian, I went to Poznań to celebrate the 10th anniversary of Polish Wikipedia.

The event started on Friday, September 23th and went on until Monday, September 26th, the actual date of establishing Polish Wikipedia. During that time, I’ve met old friends, colleagues, and newcomers to our project. The event took place in Multikino cinema in Shopping, Arts and Business Center “Stary Browar” (lit. “Old Brewery”), a place dating back to 1844, when Ambrosius Hugger, a Wirtembergian brewer, came to Poznań to start his brewery there.

Author: Radomil. License: CC-BY-SA

Almost 200 people came to celebrate with us and to participate in talks and presentations, making it the biggest Wikipedia meet-up in Poland so far. As usual, there were also guests from other countries: we were visited by Wikipedians from Germany, Czech, Belarus, Philippines, Hungary, Ukraine and Russia. On Friday we spent time on getting together, drinking beer and organizing our stay in hostels.

The actual event started on Saturday with a discussion between founders of Polish Wikipedia, Paweł Jochym and Krzysztof Jasiutowicz, who told us about the beginnings of Polish Wikipedia and how they imagine its future. What’s worth noting this is also the first time these founders actually met each other. Before now they only collaborated on the encyclopedia online, and we’ve never seen them together during one conference. Other speakers included: Jan Wróbel (a contributor to a weekly newsmagazine Wprost), Piotr Marcinkowski (vicepresident of Library of University of Poznań), Sylwia Ufnalska (translator and science journalist), Jarosław Lipszyc (president of Modern Poland Foundation) and Edwin Bendyk (famous editor, blogger and journalist).

We also had a chance to see a documentary Truth in Numbers? Everything, According to Wikipedia, which explores the history and cultural implications of the online user-editable encyclopedia Wikipedia. The film attempts to answer the question of whether all kinds of individuals or just experts should be tasked with editing an encyclopedia.

Apart from that, there was a surprise made by Wikimedia Polska Association for all editors: a video with congratulations on the anniversary from famous Polish people:

Congratulations for our work were given from: Polish president Bronisław Komorowski, professor Jerzy Bralczyk, Bartłomiej Chaciński, Ilona Łepkowska, Marek Niedźwiecki, Krzysztof Skowroński, Mariusz Szczygieł and Ewa Wachowicz. President Komorowski encouraged to edit Wikipedia and share the knowledge, Mariusz Szczygieł and Marek Niedźwiecki admitted Wikipedia helps them in their work, and professor Bralczyk expressed his pride in Polish Wikipedia being one of the biggest language version of this encyclopedia.

Author: Polimerek. License: CC-BY-SA 3.0

And thus, the event concluded on Sunday, with a group photo of all the attendees, after which all of us started going home, tired, but happy after seeing each other again, hoping we can make the best of this great project, to which we contributed over past decade. And that is what I wish to Polish Wikipedia for this and next decades to come! Let’s make the best encyclopedia ever!

Photos from the event are available on various free licenses on Wikimedia Commons in [[Category:10th birthday of Polish Wikipedia]]

An Update On The NoSQL Handbook

2011-09-07T00:00:00+00:00

A couple of months ago I set out to write a book on NoSQL. It's about time I give an update on how it's been going, and when you can expect a book in your hands, or rather, on your screen.

After an initial burst of writing, I took somewhat of a break, so please excuse the delay in general. I spent the last weeks writing (a lot), and I'm currently trying to polish and finish up the existing content so that I can throw something out there for the world to peek at. Currently, the book covers MongoDB, Riak and Redis in varying detail, and I'm working to finish up loose ends to get into a good shape, before I'm starting work on more chapters.

A lot of people have asked me about pricing, distribution model, updates, and so on, so I'm following up with an FAQ section. In general, I'm as keen to get something out there as people have expressed their interest in reading it, believe me.

Turns out though: writing a book is hard. It takes a lot of work, a lot of discipline and creativity to come up with the right words and code examples. I'm not complaining, it's just something you don't realize from writing even slightly longer blog posts. It's still an incredible learning experience too, because I (and you) get to play with pretty much all of the features the databases covered have to offer.

So bear with me, I'm on it.

The book is not built around the idea that a big application is to be built with each database. I'm not a fan of that approach myself, as it makes it too easy to lose track of details. It's full of small examples, focused on specific features.

How many pages does it have?

As the book is still growing, and I'm still playing with layouting details, I can't give you an exact number, but the final book is probably going to have more than 200 pages.

What's the pricing going to be?

I haven't decided yet. It's not going to be in the single digits pricing range, and as the book is pretty dense with content, I don't want to undercharge. I'll keep you posted.

Will there be early access to the book?

Yes, there will be. You'll be able to buy the beta of the book for a reduced price, and follow the updates. Maybe even the commits on GitHub? I don't know. Let me know if that's something you're interested in.

Do you have some samples I can peek at?

Not yet. Layout is still far from final, but I'll throw something out as soon as an early access will be available.

What databases are being covered?

To reach my goal for a final release, I'm covering Redis, MongoDB, CouchDB, Riak, and Cassandra, all in varying detail. For some it makes more sense to go deeper than for others.

Are future updates included?

Yes, as content gets added, typos get fixed, and new databases pop up, I'll send updates to everyone buying the book. The updates are free. Consider buying the book a subscription for more chapters on other databases.

Are you extending the book with more databases over time?

Yes, I have an insatiable thirst to play with more databases, and I don't want to deprive you of experiencing that too.

Are you covering database SomeDB? I hear it's the next big thing!

For now, the list of databases is fixed. What's coming after that, on the other hand, is not. I'm open to suggestions, but I'd prefer some non-exotic over a very domain-specific database you wrote for a recent project. I'll set up some sort of voting when the final release is done.

What formats will be available?

I'm currently working on PDF and ePub, with Kindle to follow. Gotta have my priorities. A good-looking and readable PDF is my first priority, an ePub after that. Buying the book includes access to all formats.

Is there going to be a print edition?

Print is not a priority right now.

What are you using to write and generate the book?

The book is written in Markdown (I hate LaTeX), converted to HTML using Redcarpet, using Albino for syntax-highlighting, and converted to PDF using the awesome Prince XML library, I hope to eventually use DocRaptor to create the final result, as a Prince license is slightly out of budget, but DocRaptor is pretty affordable.

Where can I get updates on progress?

Mostly be following me or the handbook itself on Twitter.

Die Internetwoche Köln

2011-09-06T00:54:36+00:00

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

dmexco – Digital Marketing Exposition and Conference

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

2011-09-05T17:43:02+00:00

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.

Resources

Nerds/Cookbooks

2011-08-23T17:52:09+00:00

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

DevHouse Friday @ Simfy

2011-08-15T16:52:35+00:00

Dieses mal gastiert der DevHouse Friday bei simfy.

Kickertisch, Terasse, Beamer als auch fette Beschallung sind vorhanden.

Wenn das nicht genug Argumente sind vorbei zu kommen, legt simfy noch einen Premium-Gutschein für einen Monat drauf.

WANN: 19.08.2011 ab: 19:00 Uhr

WO: simfy GmbH, Vogelsanger Straße 187, Köln

WAS: Guter Musikgeschmack!

MORE: http://devhousefriday.org/ AND @devhousefriday

Der erste Rock’n'Roll Devhouse Friday erwartet euch!

UPDATE: and the Friday, 19th of August is, of course, the Whyday.

Nerds/NerdPursuit

2011-08-14T20:35:07+00:00

For nerds, from nerds.

We’ve presented this projects a few times at Webmontag Köln and DevHouse Friday Chillout @ Papaya and Millepondo. Now we have about 100 Questions in 14 different Topics (algorithms/ bash/ couchdb/ css/ culture/ flash/ grafix/ html/ http/ javascript/ php/ rails/ regex/ ruby/) . But we’re still missing many.

Beside creating new questions we’re working on an offline game – and hey 9elements brought to us – a real time nerd pursuit game – fuck yeah! (will be linked soon).

Participate and send us as much pull requests as you can!

Short Update on Railslove

2011-08-10T12:35:41+00:00

Hey there,

there’s so much going on at Railslove at the moment, we’ve felt it’s really time for another update here on the blog.

First of all, it’s a great pity that Manuel is leaving Railslove (hopefully just for a while?), because he decided to focus on finishing school for now — even though I’m sure he’ll keep rubying with passion like he did at Railslove. Thanks for working, hacking and sharing skills with us, Manuel. Hope to see you soon at one of our next hack-ups @cowoco.

Next up is SalesKing. Some of you may know Georg and the heavy-duty billing application he’s been building for years now. After a long friendship, shared offices (back in 2008), the creation of DevHouseFriday (in 2009) and now with Time2King a first shared project, it finally happened last week, that Railslove has become an official shareholder of SalesKing. We’re very happy about our first investment (even though we’re working with funded start-ups all the time, this is new to us) and the new involvement into the upcoming development of SalesKing, that comes with it. With Georg as visionary lead developer Railslove is now the new development team of SalesKing.

And there’s good news from 9flats for us: Together with Stephan Uhrenbacher and his managing team we agreed on a common future. Since 9flats is still growing at light speed and ideas and challenges don’t seem to decrease at all, it will definitely be an exciting time for us. Thanks a lot for your great work until now, dear 9flats team, Stephan and his team know that their success and growth is also due to your dedication. Keep on rocking, Lena, Stephan, Jakob, Ralph, Jan, Lars and Tim!

But 9flats has always been just one of our major projects, and also our Payango team has a good reason to celebrate soon, because Payango 3, the ultimate, most advanced, fastest and shiniest Payango-System ever built is about to launch! After months of conception work and development I can’t wait to see this complete rewrite of their whole business application suite run in a production environment. While Payango 2 has “just” been a blown-up Rails application with a few white label frontends, Payango 3 will consist of several own backend and frontend web services, it will include new external services, new business partners and it will at all be the powerful technical future for all the crazy ideas the Payango guys are working on atm. Be on the lookout for KisCARD, which will be the first Payango 3-based frontend running on the new infrastructure. Also, thank you for your great work and tireless efforts, dear Payango team aka “triple-B” Basti, Bartek, Bumi + Jan and Lars. Can’t wait. Can’t wait.

Ahm, by the way, did you know that Railslove took over the active development and maintenance of Avocado Store some month ago? Well, I have to admit, I almost forgot about that, too, because Lars silently uses his sustainable coding skills to keep everything working just like it should. Kudos, Lars!

What else? Well, our incredible Awesome Bot Factory will *soon* be launched based on – wait for it – node.js! Bumi kindly asked me to put it in the blog post, so he and Lars feel a little productive pressure to finally deliver somewhere along the way… ;-)

Upcoming Events, you should keep in mind:

* 10|11|12|13|14th August 2011: Ruby Village @ Chaos Communication Camp 2011 thankfully initiated by Basti
* 27th – 29th August 2011: node.js ko with @cowoco being an official knockout location, so come around to hack!

Yeah, and that’s what we have for you today. Thanks for reading and hope to see/read/hack with you soon.

Erklärt: "Law of Demeter"

2011-07-28T12:08:58+00:00

Das "Law of Demeter" ist sicherlich kein Unbekannter, gehört meines Erachtens nach aber zu den oft falsch (oder besser nicht komplett) verstandenen Theorien. Avdi Grimm schreibt sehr ausführlich über das Thema in seinem Artikel "Demeter: It’s not just a good idea. It’s the law.". Besonders...

Rails: Auf dem Weg zu 3.1 - Release 3.1.0.rc5

2011-07-26T08:32:03+00:00

Gestern wurde Release Candidate 5 der kommenden Rails Version 3.1 veröffentlicht. Setup: gem install rails --pre

Web Operations 101 For Developers

2011-07-25T00:00:00+00:00

This post is not about devops, it's not about lean startups, it's not about web scale, it's not about the cloud, and it's not about continuous deployment. This post is about you, the developer who's main purpose in life has always been to build great web applications. In a pretty traditional world you write code, you write tests for it, you deploy, and you go home. Until now.

To tell you the truth, that world has never existed for me. In all of my developer life I had to deal with all aspects of deployment, not just putting build artifacts on servers, but dealing with network outages, faulty network drivers, crashing hard disks, sudden latency spikes, analyzing errors coming from those pesky crawling bots on that evil internet of yours. I take a lot of this for granted, but working in infrastructure and closely with developers trying to get applications and infrastructure up and running on EC2 has taught me some valuable lessons to assume the worst. Not because developers are stupid, but because they like to focus on code, not infrastructure.

But here's the deal: your code and all your full-stack and unit tests is worth squat if they're not running out there on some server or infrastructure stack like Google Apps or Heroku. Without running somewhere in production, your code doesn't generate any business value, it's just a big pile of ASCII or UTF-8 characters that cost a lot of money to create, but didn't offer any return of investment yet.

Love Thy Infrastructure

Operations isn't hard, but necessary. You don't need to know everything about operations to become fluent in it, you just have to know enough to start and know how to use Google.

This is my collective dump from the last years of working both as a developer and that guy who does deployments and manages servers too. Most are lessons I learned the hard way, others just seemed logical to me when I learned about them the first time around.

Between you and me, having this skill set at hand makes you a much more valuable developer. Being able to analyze any problem in production and at least having a basic skill set to deal with it makes you a great asset for companies and clients to hold on to. Thought you should know, but I digress.

The most important lesson I can tell you right up front: love your infrastructure, it's the muscles and bones of your application, whereas your code running on it is nothing more than the skin.

Without Infrastructure, No-one Will Use Your Application

Big surprise. For users to be able to enjoy your precious code, it needs to run somewhere. It needs to run on some sort of infrastructure, and it doesn't matter if you're managing it, or if you're paying another company to take care of it for you.

Everything Is Infrastructure

Every little piece of software and hardware that's necessary to make your application available to users is infrastructure. The application server serving and executing your code, the web server, your email delivery provider, the service that tracks errors and application metrics, the servers or virtual machines your services are running on.

Every little piece of it can break at any time, can stall at any time. The more pieces you have in your application puzzle, the more breaking points you have. And everything that can break, will break. Usually not all at once, but most certainly when it's the least expected, or just when you really need your application to be available.

On Day One, You Build The Hardware

Everything starts with a bare metal server, even that cloud you've heard so much about. Knowing your way around everything that's related to setting up a full rack of servers on a single day, including network storage a fully configured switch with two virtual LANs and a master-slave database setup using a RAID 10 a bunch of SAS drives might not be something you need every day, but it sure comes in handy.

The good news is the internet is here for you. You don't need to know everything about every piece of hardware out there, but you should be able to investigate strengths and weaknesses, when an SSD is an appropriate tool to use, and when SAS drives will kick butt.

Learn to distinguish the different levels of RAID, why having an additional file system buffer on top of a RAID that doesn't have a backup battery for its own, internal write buffer is a bad idea. That's a pretty good start, and will make decisions much easier.

The System

Do you know what swap space is? Do you know what happens when it's used by the operating system, and why it's actually a terrible thing and gives a false sense of security? Do you know what happens when all available memory is exhausted?

Let me tell you:

When all available memory is allocated, the operating system starts swapping out memory pages to swap space, which is located on disk, a very slow disk, slow like a snail compared to fast memory.
When lots of stuff is written to and read from swap space on disk, I/O wait goes through the roof, and processes start to pile up waiting for their memory pages to be swapped out to or read from disk, which in turn increases load average, and almost brings the system to a screeching halt, but only almost.
Swap is terrible because it gives you a false sense of having additional resources beyond the available memory, while what it really does is slowing down performance in a way that makes it almost impossible for you to log into the affected system and properly analyze the problem.

This is basically operations level on the operating system level. It's not much you need to know here, but in my opinion it's essential. Learn about the most important aspects of a Unix or Linux system. You don't need to know everything, you don't need to know the specifics of Linux' process scheduler or the underlying datastructure used for virtual memory. But the more you know, the more informed your decisions will be when the rubber hits the road.

And yes, I think enabling swap on servers is a terrible idea. Let processes crash when they don't have any resources left. That at least will allow you to analyze and fix.

Production Problems Don't Solve Themselves

Granted, sometimes they do, but you shouldn't be happy about that. You should be willing to dig into whatever data you have posthumous to find whatever went wrong, whatever caused a strange latency spike in database queries, or caused an unusually high amount of errors in your application.

When a problem doesn't solve itself though, which is certainly the common case, someone needs to solve it. Someone needs to look at all the available data to find out what's wrong with your application, your servers or the network.

This person is not the unlucky operations guy who's currently on call, because let's face it, smaller startups just don't have an operations team.

That person is you.

Solve Deployment First

When the first line of code is written, and the first piece of your application is ready to be pushed on a server for someone to see, solve the problem of deployment. This has never been easier than it is today, and being able to push incremental updates from then on speeds up development and the customer feedback cycle considerably.

As soon as you can, build that Capfile, Ant file, or whatever build and deployment tools you're using, set up servers, or set up your project on an infrastructure platform like Scalarium, Heroku, Google Apps, or dotCloud. The sooner you solve this problem, the easier it will be to finally push that code of yours into production for everyone to use. I consider application deployment a solved problem. There's no reason why you shouldn't have it in place even in the earliest stages of a project.

The more complex a project gets over even just its initial lifecycle the easier it will be to add more functionality to an existing deployment setup instead of having to build everything from scratch.

Automate, Automate, Automate

Everything you do by hand, you should only be doing once. If there's any chance that particular action will be repeated at some point, invest the time to turn it into a script. It doesn't matter if it's a shell, a Ruby, a Perl, or a Python script. Just make it reusable. Typing things into a shell manually, or updating configuration files with an editor on every single server is tedious work, work that you shouldn't be doing manually more than once.

When you automate something once, it not only greatly increases execution speed the second and third time around, it reduces the chance of failure, of missing that one important step.

There's an abundance of tools available to automate infrastructure, hand-written script are only the simplest part of it. Once you go beyond managing just one or two servers, tools like Chef, Puppet and MCollective come in very handy to automate everything from setting up bare servers to pushing out configuration changes from a single point, to deploying code. Everything should be properly automated with some tool. Ideally you only use one, but looking at Chef and Puppet, both have their strength and weaknesses.

Changes in Chef aren't instant, unless you use the command line tool knife, which assumes SSH access to all servers you're managing. The bigger your organizations the less chance you'll have to be able to access all machines via SSH. Instant tools like mCollective that work based on a push agent system, are much better for these instant kinds of activities.

It's not important what kind of tool you use to automate, what's important is that you do it in the first place.

By the way, if your operations team restricts SSH access to machines for developers, fix that. Developers need to be able to analyze and fix incidents just like the operations folks do. There's no valid point in denying SSH access to developers. Period.

Introduce New Infrastructure Carefully

Whenever you add a new component, a new feature to an application, you add a new point of failure. Be it a background task scheduler, a messaging queue, an image processing chain or asynchronous mail delivery, it can and it will fail.

It's always tempting to add shiny new tools to the mix. Developers are prone to trying out new tools even though they've not yet fully proven themselves in production, or experience running them is still sparse. It's a good thing in one way, because without people daring to use new tools everyone else won't be able to learn from their experiences (you do share those experiences, do you?).

But on the other hand, you'll live the curse of the early adopter. Instead of benefiting from existing knowledge, you're the one bringing the knowledge into existence. You'll experience all the bugs that are still lurking in the darker corners of that shiny new database or message queue system. You'll spend time developing tools and libraries to work with the new stuff, time you could just as well be spending working on generating new business value by using existing tools that do the job similarly well. If you do decide for a new tool, be prepared to degrade back to other tools in the case of failure.

No matter if old or new, adding more infrastructure always has the potential for more things to break. Whenever you add something, be sure to know what you're getting yourself into, be sure to have fallback procedures in place, be sure everyone knows about the risks and the benefits. When something that's still pretty new breaks, you're usually on your own.

Make Activities Repeatable

Every activity in your application that causes other, dependent activities to be executed, needs to be repeatable, either by the user, or through some sort of administrative interface, or automatically if feasible. Think user confirmation emails, generating monthly reports, background tasks like processing uploads. Every activity that's out of the normal cycle of fetching records from a datasource and updating them is bound to fail. Heck, even that cycle will fail at some point due to some odd error that only comes up every once in a blue moon.

When an activity is repeatable, it's much easier to deal with outages of single components. When it comes back up, simply re-execute the tasks that got stuck.

This, however, requires one important thing: every activity must be idempotent. It must have the same outcome no matters how often it's being run. It must know what steps were already taken before it broke the last time around. Whatever's already been done, it shouldn't be done again. It should just pick up where it left off.

Yes, this requires a lot of work and care for state in your application. But trust me, it'll be worth it.

Use Feature Flips

New features can cause joy and more headaches. Flickr was one of the first to add something called feature flips, a simple way to enable and disable features for all or only specific users. This way you can throw new features onto your production systems without accidentally enabling it for all users, you can simply allow a small set of users or just your customer to use it and to play with it.

What's more important though, when a feature breaks in production for some reason, you can simply switch it off, disabling traffic on the systems involved, allowing you to take a breether and analyze the problem.

Feature flips come in many flavors, the simplest approach is to just use a configuration file to enable or disable them. Other approaches use a centralized database like Redis for that purpose, which has an added benefit for other parts of your application, but also adds new infrastructure components and therefore, more complexity and more points of failure.

Fail And Degrade Gracefully

What happens when you unplug your database server? Does your application throw in the towel by showing a 500 error, or is it able to deal with the situation and show a temporary page informing the user of what's wrong? You should try it and see what happens.

Whenever something non-critical breaks, your application should be able to deal with it without anything else breaking. This sounds like an impossible thing to do, but it's really not. It just requires care, care your standard unit tests won't be able to deliver, and thinking about where you want a breakage to leak to the user, or where you just ignore it, picking up work again as soon as the failed component becomes available again.

Failing gracefully can mean a lot of things, there's things that directly affect user experience, a database failure comes to mind, and things that the user will notice only indirectly, e.g. through delays in delivering emails or fetching data from an external service like Twitter, RSS feeds and so on.

When a major component in your application fails, a user will most likely be unable to use your application at all. When your database latency increases manifold, you have two options. Try to squeeze through as much as you can, accepting long waits on your user's side, or you can let him know that it's currently impossible to serve him in an acceptable time frame, and that you're actively working on fixing or improving the situations. Which you should, either way.

Delays in external services or asynchronous tasks are much harder for a user to notice. If fetching data from an external source, like an API, directly affects your site's latency, there's your problem.

Noticing problems in external services requires two things: monitoring and metrics. Only by tracking queue sizes, latency for calls to external services, mail queues and all things related to asynchronous tasks will you be able to tell when your users are indirectly affected by a problem in your infrastructure.

After all, knowing is half the battle.

Monitoring Sucks, You Need It Anyway

I've written in abundance on the virtues of monitoring, metrics and alerting. I can't say it enough how important having a proper monitoring and metrics gathering system in place is. It should be by your side from day one of any testing deployment.

Set up alerts for thresholds that seem like a reasonable place to start to you. Don't ignore alerting notifications, once you get into that habit, you'll miss that one important notification that's real. Instead, learn about your system and its thresholds over time.

You'll never get alerting and thresholds right the first time, you'll adapt over time, identifying false negatives and false positives, but if you don't have a system in place at all, you'll never know what hit your application or your servers.

If you're not using a tool to gather metrics like Munin, Ganglia, New Relic, or collectd, you'll be in for a big surprise once your application becomes unresponsive for some reason. You'll simply never find out what the reason was in the first place.

While Munin has basic built-in alerting capabilities, chances are you'll add something like Nagios or PagerDuty to the mix for alerting.

Most monitoring tools suck, you'll need them anyway.

Supervise Everything

Any process that's required to be running at any time needs to be supervised. When something crashes be sure there's an automated procedure in place that will either restart the process or notify you when it can't do so, degrading gracefully. Monit, God, bluepill, supervisord, RUnit, the number of tools available to you is endless.

Micromanaging people is wrong, but processes need that extra set of eyes on them at all times.

Don't Guess, Measure!

Whatever directly affects your users' experience affects your business. When your site is slow, users will shy away from using it, from generating revenue and therefore (usually) profit.

Whenever a user has to wait for anything, they're not willing to wait forever. If an uploaded video takes hours to process, they'll go to the next video hosting site. When a confirmation email takes hours to be delivered, they'll check out your competitor, taking the money with them.

How do you know that users have to wait? Simple, you track how long things in your application take, how many tasks are currently stuck in your processing queue, how long it took to process an upload. You stick metrics on anything that's directly or indirectly responsible for generating business value.

Without having a proper system to collect metrics in place, you'll be blind. You'll have no idea what's going inside your application at any given time. Since Coda Hale's talk "Metrics Everywhere" at CodeConf and the release of his metrics library for Scala, an abundance of libraries for different languages has popped up left and right. They make it easy to include timers, counters, and other types of metrics into your application, allowing you to instrument code where you see fit. Independently, Twitter has lead the way by releasing Ostrich, their own Scala library to collect metrics. The tools are here for you. Use them.

The most important metrics should be easily accessible on some sort of dashboard. You don't need a big fancy screen in your office right away, a canonical place, e.g. a website including the most important graphs and numbers, where everyone can go and see what's going on with a glance is a good start. Once you have that in place, the next step towards a company-visible dashboard is simple buying a big-ass screen.

All metrics should be collected in a tool like Ganglia, Munin or something else. These tools make analysis of historical data easy, they allow you to make predictions or correlate the metrics gathered in your applications to other statistics like CPU, memory usage, I/O waits, and so on.

The importance of monitoring and metrics cannot be stressed enough. There's no reason why you shouldn't have it in place. Setting up Munin is easy enough, setting up collection using an external service like New Relic or Scout is usually even easier.

Use Timeouts Everywhere

Latency is your biggest enemy in any networked environment. It creeps up on you like the shadow of the setting sun. There's a whole bunch of reasons why, e.g. database queries will suddenly see a spike in execution time, or external services suddenly take forever to answer even the simplest requests.

If your code doesn't have appropriate timeouts, requests will pile up and maybe never return, exhausting available resources (think connection pools) faster than Vettel does a round in Monte Carlo.

Amazon for example has internal contracts. Going to their home page involves dozens of requests to internal services. If any one of them doesn't respond in a timely manner, say 300 ms, the application serving the page will render a static piece snippet instead, but thereby decreasing the chance of selling something, directly affecting business value.

You need to treat every call to an external resource as something that can take forever, something that potentially blocks an application server process forever. When an application server process or thread is blocked, it can't serve any other client. When all processes and threads lock up waiting for a resource, your website is dead.

Timeouts make sure that resources are freed and made available again after a grace period. When a database query takes longer than usual, not only does your application need to know how to handle that case, but your database needs to. If your application has a timeout, but your database will happily keep sorting those millions of records in a temp file on disk, you didn't gain a lot. If two dependent resources are within your hands, both need to be aware of contracts and timeouts, both need to properly free resources when the request couldn't be served in a timely manner.

Use timeouts everywhere, but know how to handle them when they occur, know what to tell the user when his request didn't return quickly enough. There is no golden rule what to do with a timeout, it depends not just on your application, but on the specific use case.

Don't Rely on SLAs

The best service fails at some point. It will fail in the most epic way possible, not allowing any user to do anything. This doesn't have to be your service. It can be any service you directly or indirectly rely on.

Say, your code runs on Heroku. Heroku's infrastructure runs on Amazon's EC2. Therefore Heroku is prone to problems with EC2. If a provider like Heroku tells you they have a service level agreement in place that guarantees a minimum amount of availability per month or per year, that's worth squat to you, because they in turn rely on other external services, that may or may not offer different SLAs. This is not specific to Heroku, it's just an obvious example. Just because you outsourced infrastructure doesn't mean you're allowed to stop caring.

If your application runs directly on EC2, you're bound by the same problem. The same is true for any infrastructure provider you rely on, even a big hosting company where your own server hardware is colocated.

They all have some sort of SLA in place, and they all will screw you over with the terms of said SLA. When stuff breaks on their end, that SLA is not worth a single dime to you, even when you were promised to get your money back. It will never make up for lost revenue, for lost users and decreased uptime on your end. You might as well stop thinking about them in the first place.

What matters is what procedures any provider you rely on has in place in case of a failure. The important thing for you as one of their users is to not be left standing in the rain when your hosting world is coming close to an end. A communicative provider is more valuable than one that guarantees an impossible amount of availability. Things will break, not just for you. SLAs give you that false sense of security, the sense that you can blame an outage on someone else.

For more on this topic, Ben Black has written a two part series aptly named "Service Level Disagreements".

Know Your Database

You should know what happens inside your database when you execute any query. Period. You should know where to look when a query takes too long, and you should know what commands to use to analyze why it takes too long.

Do you know how an index is built? How and why your database picks one index over another? Why selecting a random record based on the wrong criteria will kill your database?

You should know these things. You should read "High Performance MySQL", or "Oracle Internals", or "PostgreSQL 9.0 High Performance". Sorry, I didn't mean to say you should, I meant you must read them.

Love Your Log Files

In case of an emergency, a good set of log files will mean the world to you. This doesn't just include the standard set of log files available on a Unix system. It includes your application and all services involved too.

Your application should log important events, anything that may seem useful to analyze an incident. Again, you'll never get this right the first time around, you'll never know up front all the details you may be interested in later. Adapt and improve, add more logging as needed. It should allow you to tune the log verbosity at runtime, either by a using a feature switch or by accepting a Unix signal.

Separate request logging from application logging. Data on HTTP requests is just as important as application logs, but it's easier if you can sift through them independently, they're also a lot easier to aggregate for services like Syslog or Loggly when they're on their own.

For you Rails developers out there: using Rails.logger is not an acceptable logging mechanism. All your logged statements will be intermingled with Rails next to unusable request logging output. Use a separate log file for anything that's important to your application.

Just like you should stick metrics on all things that are important to your business, log additional information when things get out of hand. Correlating log files with metrics gathered on your servers and in your application is an incredibly powerful way of analyzing incidents, even long after they occurred.

Learn the Unix Command Line

In case of a failure, the command line will be your best friend. Knowing the right tools to quickly sift through a set of log files, being able to find and set certain kernel parameters to adjust TCP settings, knowing how get the most important system statistics with just a few commands, and knowing where to look for a specific service's configuration. All these things are incredibly valuable in case of a failure.

Knowing your way around a Unix or Linux system, even with just a basic toolset is something that will make your life much easier, not just in operations, but also as a developer. The more tools you have at your disposal, the easier it will be for you to automate tasks, to not be scared of operations in general.

In times of an emergency, you can't afford to argue that your favorite editor is not installed on a system, you use what's available.

At Scale, Everything Breaks

Working at large scale is nothing anyone should strive for, it's a terrible burden, but an incredibly fascinating one. The need for scalability evolves over time, it's nothing you can easily predict or assume without knowing all the details, parameters and the future. Out of all three, at least one is 100% guess work.

The larger your infrastructure setup gets, the more things will break. The more servers you have, the larger the number of servers being not available at any time. That's nothing you need to respect right from the get go, it's something to keep in mind.

No service that's working at a larger scale was originally designed for it. The code and infrastructure were adapted, the services grew over time, and they failed a lot. Something to think about when you reach for that awesome scalable database before even having any running code.

Embrace Failure

The bottom line of everything is, stuff breaks, everything breaks at different scale. Embrace breakage and failure, it will help you learn and improve your knowledge and skill set over time. Analyze incidents using the data available to you, fix the problem, learn your lesson, and move on.

Don't embrace one thing though: never let a failure happen again if you know what caused it the first time around.

Web operations is not solely related to servers and installing software packages. Web operations involves everything required to keep an application available, and your code needs to play along.

Required Reading

As 101s go, this is a short overview of what I think makes up for a good starter set of operations skills. If you don't believe or trust me (which is a good thing), here's a list of further reading for you. By now, I consider most of these required reading even. The list isn't long, mind you. The truth as of today is still that you learn the most out of personal experience on production systems. Both require one basic skill though: you have to want to learn.

Release It! - A must read, that's all I can say. It's an incredible resource stemming from years of production. A must read, no excuses.
Web Operations: Keeping the Data on Time - The best summary on all things operations available today. If you read one book, read this, and the previous one (that's two books, I know)
Pragmatic Project Automation (oldie, but goldie, this book was an eye-opener to me)
The Art of Capacity Planning
Building Scalable Websites
High Performance MySQL, 2nd. Edition
How Complex Systems Fail
On Designing and Deploying Internet-Scale Services

Shameless Plug

If you liked this article, you may enjoy the book I'm currently working on: "The NoSQL Handbook".

Rails 3.1 HackFest am Wochenende

2011-07-22T17:38:50+00:00

An diesem Wochenende (23. und 24. Juli 2011) findet das Rails HackFest zum kommenden Release 3.1 statt. Die Zielsetzung ist einfach: Einen möglichst stabilen 3-1-stable Branch erzeugen. Mehr Informationen finden sich im offiziellen Rails Blog.

"Hört auf Java zu hassen" - Ein Aufruf mit Einblick

2011-07-22T14:01:45+00:00

Stop hating Java - Ein Artikel von Andrzej Krzywda der die guten Seiten der Sprache Java beleuchtet. Geschrieben für Rubyisten.

Garbage Collector Tuning mit Ruby 1.9.2

2011-07-22T12:53:38+00:00

Shai Rosenfeld erklärt im Engine Yard Blog wie man den Ruby GC optimieren kann und warum das nötig sein könnte.

Rails: Travis CI übernimmt

2011-07-21T20:22:27+00:00

Seit Kurzem kümmert sich Travis um das Continuous Integration System des Rails Projektes. Aktuelle Build Informationen finden sich hier. ()

Railcamp Poland after some time

2011-07-21T10:56:55+00:00

In April, we, in cooperation with few Rails community companies, have organized the first edition of Railscamp Poland. Railscamp Poland took place in Wisła, the same Wisła where Adam Małysz, a legendary former ski jumper, is from. We are very happy how the event turned out, and that many people spoke well about the organization of it.

So, right now, when I look back at the event, what do I see?

I see happy people, getting together, in one case, to have a good time while doing what they like! And all the time we did just that. There was a bit of coding, but mostly we had fun playing Guitar Hero, singing, playing Urban Terror.

Some quick (and not entirely accurate) facts about Railscamp Poland:

During the event, people:

drank 20 liters of vodka,
drank 40 liters of Club Mate,
eaten 50 kilograms of pizzas,
eaten 120 sausages,
got 250 euro from a deposit for returned beer bottles,
wrote daily 4000 lines of code (including 2600 while drinking), which test coverage is at 100%

Again, big thanks to these guys for making this possible:

The photos from the event are available on Flickr and Ipernity.

Sind Klassen-Methoden böse?

2011-07-21T09:40:07+00:00

Diese Frage wird von Nick Sutterer in seinem Blog aufgeworfen. Folgt man den Ideen von DCI müsste man die Rails-Model Finder Methoden überdenken. Aktuell wird die Diskussion zum Thema in den Kommentaren des Artikels geführt. Prädikat: Lesenswert.

Rails: 300% schneller im Development Modus

2011-07-21T09:33:12+00:00

Das ActiveReload Gem von Robert Pankowecki beschleunigt Rails im Development Modus um bis zu 300%. Anstatt bei jedem Request alle Dateien neu zu laden, sorgt das Gem dafür, dass nur wirklich geänderte Dateien aktualisiert werden.

The Ethical Programmer

2011-06-18T22:00:00+00:00

This is somewhat of a complicated issue for me. I’m having a lot of discussions with fellow developers and colleagues on this and it seems to be very difficult to find some common ground here. But since it bugs me a lot and I am still very indifferent on the whole issue, I had to blog about it and kind of hoping to start a discussion amongst us, the developer community.

So, here’s the question: Do we have, as developers, have some kind of moral obligation to choose projects to work on which follow certain ethical standards. If so, what might these standards look like?

For me, there are actually a few solid lines. I would never work for a company that builds weapons, for example. I would never work for organisations that are downright, and knowingly so, criminal. Beyond those lines, things tend to get blurry very very fast. Take Apple, for example (just picking it because of it’s current popularity, could probably pick any consumer electronics vendor). While working at cupertino is certainly a cool job and work ethics are valued relatively high at the company(take a look at their “It get’s better” video, for example), you still would work for a company that manufactures their computers in factories where people actually commit suicide during work. Well? How would you decide?

But let’s dismount the high horse – I’m aiming lower. Actually so low that “ethical” sounds a bit huge.

Actually, I want to turn this completely around, from negative selection to positive: Are you, am I working on something that makes the world a better place? The internet a better place? Does it make people happy? Does it help people doing their jobs better, making their lives better?

Because, in the end, that’s what I want to aim for, as a programmer, as a citizen, as a human being.

And, to be honest, I think that we’re largely failing here.

You see, I’m a german. And I am largely working for startups. And the german startup scene…

…sorry. Had to go to the basement to not scare my neighbours with excessive swearing.

I often ramble about the useless copycat-ism of the german startup scene. I am especially fond of the Samwer brothers, who are extremly successful (and admired by many for that) in building clones of US apps, making them big in Europe and then selling them to “the original”™. They got their first big monies from selling their dot-com startup to eBay (Was it alando? Abacho? Do I care?) and lately got some comical amount of money for their City Deals platform they sold to Groupon. We’ll get back to the Samwers later.

Now, I spent huge amounts of this spring actually building a copycat, namely rent-n-roll, a clone of platforms like whipcar and relayrides which all do p2p car rentals. And I was hugely enjoying it. Why that double standard?

Well, first of all, all p2p car rental sites seem to focus very much on their local markets so far. UK’s Whipcar very much focuses on the london area (clever move, huh?) and Relayrides actually takes city by city in the US, very carefully and slowly.

There are actually a few german contenders and it’s not completely clear yet if the model would work at all in car-fetishist-land-germany, but we actually felt that we had something serious to add (in this case, mostly insurance related stuff and building an app that’s not completely broken in terms of UX). So, yes, I think, in building the app we were actually making the internet a better place. And the world. Kinda.

Back to the Samwer brothers. They seem to be genuinly non-interested in making the world a better place. It’s not too cynical to say that all they are interested in is to make their wallets a richer place, an endeavour in which they seem to be very successful.

Their latest baby is a platform called Wimdu, which is, more or less, a 1:1 copycat of AirBnB, a wildly successful US startup that currently revolutionizes on-the-road accomodation by letting people rent out beds or flats directly to people visiting the city. Let’s just say, if I would own a cheap hotel or a youth hostel, I wouldn’t be too happy about this trend.

Now, Wimdu has been accused by AirBnB for using shady business tactics and I am only mildly surprised. Because, in the end, what you have to do to make such a business strategy successful is owning the market, in this case, Europe. That’s why City Deals, in the end, had more than 600 employees, most of them working in sales, before being sold to Groupon. Same now happens with wimdu.

Disclosure: My employer, mindmatters, has been working, for a short period of time, for another AirBnB copycat, called 9flats. I found that problematic. I haven’t been on the team, though and only found out about the actual type of application post launch, as the team was told to be silent about it. I found that problematic – but that’s another story.

Disclosure: A group of people I would call friends, or at least “fellow developers” still work, as freelancers or contractors, for 9flats. When we talk about it, it can get awkward. I must admit that I so far usually avoided talking about it, because of that awkwardness.

(Meta-Disclosure: I changed the wording here, because it didn’t feel exactly right. Go look it up in git, if you’re interested in the original)

So, let’s keep shady business tactics away for a moment. Let’s say it’s totally unproblematic to copy an application screen by screen on your employers request. How do apps like wimdu and 9flats make the internet a better place? The world? How do they make people happier? Can you come up with a useful answer here, without ridiculing yourself utterly and completely?

Because, you know what? AirBnB works perfectly on the European market. Because, on the inside, it is a very, very simple business model without huge local differences.

Well, to be honest, there’s one aspect which makes local adaptions possible, and that is international payment issues: For example, credit cards are not as popular in some European countries. Does that justify a million dollar rat race of three companies for European Championship Of Peer To Peer Roomsharing? Yeah, sure, why not. Wait, what?

Another thought: Does the world really need another couponing platform? Ah, well, let’s not go there, I don’t have my Kleenex at hand to wipe up my tears of despair.

And, to drive home my point, let me put aside copycat-ism for a little while. For example, we’ve been working, in 2010, for a startup that shall remain unnamed, which actually had a very cool core idea. A very technically challenging one, as well. But then, their business model was completely focused on ads, and therefore traffic, and therefore Google. If you have ever worked on a business completely focused on SEO, you know what this means: It means optimizing your platform for a very specific user, namely the Googlebot. What it doesn’t mean is building a good product for the other pesky folks: The humans. Which means that in the end you’re building a less-than-subpar product which is best read with the eyes of a googlebot. And in the process, we actually made the internet a bit worse by spamming the google index with links to a platform that largely wasn’t working very well but displayed highly profitable ads. Adding insult to injury, the client turned out the be somewhat of a dick. And that is the nicest way of putting it.

Needless to say, making the internet or the world a better place wasn’t very high on their list of priorities.

So, I find it problematic to work for those kind of projects. Other fellow developers have less problems with that. They may, in some cases, even find it refreshing to be part of some kind of challenge on world domination. Which I can relate to, at least a little.

In the end, to be completely honest, as much as I would like to claim that these “ethical” rules are imperative for my selection of projects, I must admit, that I am, too, utterly failing at this.

But, you know what: I’d very much like to change that. As much as possible. It’s actually hard if you are working at a company which is selling services, because it’s not always you deciding what to work on and it’s not always possible to be choosy about your clients (Sidenote: That’s why it’s always a huge satisfaction to decide not to work for a specific client, if you’re able to). But, does it need to be that way? The current need for developers actually gives us a lot of power in that respect. We could say no.

So, whenever I am able to chose, whenever I have the means of saying no, please do me a favour and hold me accountable on this:

I want to build stuff that makes the world and the internet a better place. If possible, exclusively so.

If you feel the same and you need help on something, please let me know. There’s also a company full of people that largely feel the same on this as I do, which is why I am still enjoying working for mindmatters.

A closing personal message to my friends and fellow developers: I am not out to judge you. As I said, I am not very good at this myself, mostly. But I want this to become my own “ethical” baseline. And if you can relate to that, feel free to join me here. Let’s be our own judges on this. If you have diffenrent views on this, please share. If, in the end, this starts a discussion on the ethical baselines of our profession, I will be the happiest person on earth.

Redesign, Schmedesign

2011-06-17T22:00:00+00:00

Yeah, right. I did a big bang relaunch on this blog. Well, not really, it took me about 6 hours, markup changes were minimal, but the whole thing is a little more sematic now and actually is html5. I used Andy Taylor’s excellent 1140 responsive grid, in form of the eleven40 compass extension from Jeremy Bush (I ran across some issues with it, hopefull I’ll find the time to fix them soon).

The rationale of this redesign was to cut down on visual complexity. It is now more or less one of those “standard, two column, image on top, large font, serif text, sans-serif headlines” blog templates. I used two of the proposed font stacks from the excellent Revised Font Stack article by Amrinder Sandhu, to be not completely in boring-land with Helvetica and Times New Roman or something like that. I am happy with the design for now, although I would love to apply some Wowo style baseline nazi love to it somewhere in teh futare.

And, yes, I implanted a small Adsense Ad on the page.

How do you like it? Lemme know on the twitters or in the comments. Thank you for your business.

Now I only need to write more often.

Programmiert Ihr Deutsch?

2011-06-01T13:37:00+00:00

Mit diesem Post würde ich gerne ein Thema wieder aufgreifen, dass ich vor drei Jahren einmal angeschnitten habe: Programmiert Ihr Deutsch?

Grund dafür ist, dass wir in zwei aktuellen Projekten dazu übergegangen sind, alles was mit der Domäne und Tests zu tun hat komplett in deutsch zu entwickeln. Nach anfänglicher Skepsis darüber muss ich nun sagen, dass ich meine Meinung deutlich geändert habe und es in jedem kommenden Projekt wohl wieder so machen würde – es sei denn natürlich, es gibt Beschränkungen bzw. gute Gründe eben nicht deutsch als Sprache zu verwenden (bspw. englischsprachige Teammitglieder oder Kunden).

Wir haben Modell-, Controller- und Attributnamen auf deutsch definiert, was auch erstaunlich problemlos funktioniert. Die einzigen Anpassungen die in Rails daraus resultieren sind, dass es erfordert die Inflections (config/initializers/inflections.rb) anzupassen. Alles weitere (bspw. Datenbanktabellennamen) resultiert daraus und benötigt weiter keine Konfiguration. Wir waren bislang noch nicht wagemutig genug das auf die Spitze zu treiben und auch Umlaute in Klassen- und Dateinamen zu verwenden, das bleibt dann dem geneigten Leser als Übung überlassen ;)

Testing

Richtig angenehm wird es in den Tests: Cucumber bringt von Haus aus mit, Features auch in anderen Sprachen als Englisch zu verfassen. Alles was dazu nötig ist, ist bei der Installation das Kürzel der Sprache mitzugeben, für die zusätzliche Web Steps generiert werden sollen, in unserem Fall:

rails generate cucumber:install de

Eine Übersicht der in deutsch benötigten Keywords gibt es mittels

bundle exec cucumber --i18n de

Die Testdaten legen wir über Tabellen an, was meiner Meinung nach mittlerweile auch etwas übersichtlicher ist als Bibliotheken zu verwenden, die Factory Steps generieren (wie cucumber_factory oder pickle). Dies ist aber sicherlich Geschmacksache und es gäbe auch Möglichkeiten, die Stepgeneratoren so anzupassen, dass sie auch für deutsche Steps funktionieren. Hier ein kurzes Beispiel für eines unserer Features (wichtig für Cucumber ist dabei der Kommentar in der ersten Zeile):

# language: de
                          
                          Funktionalität: Kunde-Login
                            Als Kunde
                            Möchte ich mich mit meinen Zugangsdaten einloggen
                            Um an der Auktion teilnehmen zu können
                          
                            Grundlage: Bestehender Kunde
                              Angenommen es gibt die folgenden Kunden:
                                | email        | kundennummer | password   |
                                | kunde@web.de | 123456       | top_secret |
                          
                            Szenario: Erfolgreiches Login mit E-Mail-Adresse
                              Wenn ich auf die Login-Seite gehe
                              Und ich "Login" mit "kunde@web.de" ausfülle
                              Und ich "Passwort" mit "top_secret" ausfülle
                              Und ich auf "Anmelden" drücke
                              Dann sollte ich auf der Startseite sein
                              Und ich sollte "Sie wurden erfolgreich eingeloggt" sehen

Auch die Specs lassen sich bis auf die Keywords sehr gut auf deutsch schreiben, was bei uns dann in etwa so aussieht:

# encoding: utf-8
                          
                          require 'spec_helper'
                          
                          describe Auktionator do
                            
                            context "bei bevorstehender Auktion" do
                              
                              before do
                                @termin = Factory(:auktionstermin, :start => 1.day.from_now)
                                @los1 = Factory(:los, auktionstermin: @termin, losnummer: 1)
                                @los2 = Factory(:los, auktionstermin: @termin, losnummer: 2)
                                @auktionator = Auktionator.new(@termin)
                              end
                              
                              describe "#phase" do
                                
                                it "sollte 'auktion_bevorstehend' zurückgeben" do
                                  @auktionator.phase.should == 'auktion_bevorstehend'
                                  @auktionator.auktion_bevorstehend?.should be_true
                                end
                              
                              end
                          
                              describe "#los" do
                              
                                it "sollte das aktuelle Los zurückgeben" do
                                  @auktionator.los.should == @los1
                                end
                              
                              end
                          
                          end

Mich würde wie gesagt eure Meinung dazu interessieren, vielleicht habt ihr Tips und weitere Tools dafür. Wer darüber hinaus auf der Suche nach Anregungen zum Thema Domänenabbildung ist, dem sei ggf. noch Eric Evans’ Buch Domain Driven Design empfohlen - dies aber wohl eher nur als Randnotiz.

Silencing the Rails log on a per-action basis

2011-05-26T11:14:00+00:00

In our current project we are having an action that is polled every ten seconds by the clients. This clutters up the log, so I was looking for a way to completely silence the Rails logger for this action. It turns out that you have to swap the default logger with a custom one, because even when you use the Rails.logger.silence block in your action, you will still find a line in your log that is printed out before the request gets dispatched.

Here’s our custon logging class:

# lib/custom_logger.rb
                            class CustomLogger  Rails::Rack::Logger
                              def initialize(app, opts = {})
                                @app = app
                                @opts = opts
                                @opts[:silenced] ||= []
                              end
                              
                              def call(env)
                                if env['X-SILENCE-LOGGER'] || @opts[:silenced].include?(env['PATH_INFO'])
                                  Rails.logger.silence do
                                    @app.call(env)
                                  end
                                else
                                  super(env)
                                end
                              end
                            end

This way you can either define request paths that should not get logged or send the X-SILENCE-LOGGER header for the request you don’t want to log.

To make use of your own logger, you’ll have to swap the default logger, which is included as a Rack middleware:

# config/application.rb
                            require File.dirname(__FILE__) + '/../lib/custom_logger.rb'
                            
                            module MyApp
                              class Application  Rails::Application
                                # Middlewares
                                config.middleware.swap Rails::Rack::Logger, CustomLogger, :silenced => ["/noisy/action.json"]
                              end
                            end

Why Big Bang Relaunches are evil

2011-05-16T22:00:00+00:00

A few days back, XING started an online campaign for their grand redesign that will launch in june 2011. The campaign is nicely made, with interviews with some of the people behind that huge undertaking. I like it.

What I strongly dislike, though, are big bang relaunches. I voiced that concern on twitter and this lead into a longish discussion with various people. So, I’m writing this post to archive my points I made yesterday, but also to elaborate a bit on the responses.

Here’s my basic set of assumtions. If you don’t agree with them, you won’t agree with the rest of my text, which is fine, by the way :)

1. Agile project/product management and software development is the best way to build our software. I don’t care if you use Kanban or Scrum or XP or whatever, but don’t go chasin’ waterfalls.
2. We build software for our users. This sounds like a no-brainer but I’ve too often seen people build software for the googlebot. Did it myself even, but not without cringing.
3. We do have a lean organisation without much organisational friction. I’ll come back to this later, because this actually may be a bit of a stretch.

Funnily enough, we had that discussion briefly last wednesday at the Ruby Usergroup, where it became obvious that Big Bang Relaunches are obviously one of the clearer reasons to have a good branching model on your SCM (Source Code Management) system which was the main topic. The top reasons given why Big Bang Relaunches are necessary according to the audience were:

1. Because Marketing wants them
2. Because Designers can’t do incremental design

Let’s look at them in detail.

Marketing loves Big Bang Relaunches

This is quite obviously true. Marketing traditionally comes from a strong product background. You are usually dealing with large release cycles and thus, a Big Bang Launch is a fixed point in time that gives you an anchor to base your marketing actions around. That’s understood.

Is it the best way to communicate changes to the user? Do users love Bing Bang Relaunches as well? First of all, my answer would be a straight No!. Most users, especially the loyal, long time power users, usually hate, hate, hate relaunches. Ask people that have a product at the market for years, like the people from germans social network dinosaur Wer Weiss Was. Mind you, these people hate all changes, so you won’t make them entirely happy by only doing incremental changes to your site, evar, but it certainly soothes the pain.

Additionally, if your marketing really loves Big Bang Relaunches, it also means that Marketing did not get the core principles of agile.

As well as it is our (developers) responsibility to continuously improve the software, it is, in a truly agile environment, the responsibility of Marketing to continuously market new features, simplifications and small adaptions to the users. You have to transform your work from huge bursts of marketing activity (product launch campaigns) to a continous flow of marketing goodness. If a large feature comes along, by all means, celebrate it and rock it, but otherwise, just do your job on a day to day basis. Have standups, watch your developers scrum/kanban board. Yes, this will also mean that you probably won’t need that huge relaunch party you were so much looking forward to. That’s tough. You’ll find other things to celebrate.

Designers can’t do incremental design

That’s the tough one. It is tough because web design is a very tough field in itself. Why? Because we still mix up so many different things into these two words. Do we mean interface design? Graphics design? UX? What does it all mean? Double Rainbow? Here’s my own interpretation.

1. If you call yourself an UX expert, you should hate Big Bang Relaunches. Why? Because they are usually a lost chance to learn things. Sure, you can do all kinds of user tests in the relaunch process, but everybody should know by now that you always should prefer real world data to lab data when it comes to user feedback.

2. If you are a graphics designer, you will probably be more happy with Big Bang Relaunches, because, and I totally acknowledge that, it is invariantly harder to change a site’s design gradually than it is to do the redesign in one big step. But, as long as you’re not working on a product presentation page on a retailers web page, that should not be the way you should do your job, anyway. Mind you, being artistically responsible for the look and feel of a web application is a very tough job, because it means two very different things at once: You need to pay incredible amounts of attention to details and need to spend a lot of time doing UX work (or collaborating with an UX expert), probably regarding very small elements on a single page, and, at the same time, keep an eye on the overall look and keep things consistent on a larger scale. But if your only answer to this is that you want to do Big Bang Relaunches, you are not trying hard enough.

There is a step three

Ultimately, it’s a question of organisation. To be able to do only incremental changes to your software, your organisation must breathe agile. I know I sound like some crazy agile marketing guy, but really, that’s the whole point. Everybody must adhere to the thought of incremental improvement. And also, which sounds counter intuitive, it needs strong leadership. To prevent feature creep. To prevent all those dark corners that every software seems to accumulate over time, where nobody wants to touch anything anymore. This strong leadership needs not to be carried out by “the UX guy” or “the product guy”, it can also be organized and carried out as a collaborate effort, but anyway, that’s the really hard part. That is also where most organisations fail. When organisations grow, responsibilities are divided up without keeping vital connections between disciplines. You suddenly have a head of UX and a head of Art Direction and those two people hate each other and the only thing they can agree on is that they hate that guy from Product Management even more.

And suddenly, a Big Bang Relaunch is the only thing that will enable you and your organisation to get back your focus. Usually this involves organisational changes as well, and also really painful discussions in the conceptional phase.

Why Big Bang Relaunches are a bad idea.

Of course, you do organise your relaunches in an agile fashion. So you think you’re safe. If you’re not, you’re in even deeper trouble, because you suddenly lock away yourself from reality for the runtime of the project (which, in XING’s case seems to be more than half a year). So you don’t. The problem is pretty big, still. Because, in reality, doing a big fat redesign means that you need to divide up your resources. There will be a relaunch team, and a maintenance team. Also, you need to fork your code base. While I’m no general opponent of forks or branches, they should be small and local. Huge global forks give you a lot to worry about. While git in theory makes it really easy to keep your relaunch-branch up to date with changes in your non-relaunch branch, in practice, especially with huge refactorings in html templates, you’re in for a lot of pain. Trust me, I’ve been there. Ask me about 2004 at AOL.de. I will tell you stories that involve branches in CVS.

Which means that you end up splitting your dev team, splitting your code base and, if you take the process seriously, also the rest of your company. One half does day to day business, the other half is locked up in the basement. However you do the splitting, you’ll end up with not getting things done at one end.

Also, in every Big Bang Relaunch project I’ve seen, you start the relaunch with the promise of a huge cleanup. And then stakeholders come into play, and there’s a lot of changes and suddenly you’re in crunch mode to finish the Big Bang Relaunch inside the timeframe (That has, in worst case, arbitrarily set by marketing without any backup by your dev team) and in the end, the front end may have gotten some love, but the amout of refactoring and simplification you were hoping to get at the start of the project has nothing to do with the reality you end up with.

But didn’t you get the memo? Reality doesn’t work like that!

Yes it does. There are tons of examples of companies and startups doing an incredible job of continuously improving their platform, launching features, taking useless features away, refining and polishing their UI. Github, All 37signals projects, Dropbox, even most Google products. To be honest, almost all of the web tools I use on a day to day basis work like that. (With the notable and also quite painful exception of the infamous newtwitter.)

It’s very hard to get this right. It takes an exceptional team with exceptional self organisation and/or leadership. It takes a strong product vision and extreme focus on what’s important (And even harder to get right: A good idea on how to find out what’s important).

But if you get this right, you’ll end up with happier customers, happier team members and a whole lotta less stress.

Oh, and you also don’t have to waste money on a PR company to build a campaign site to support the Big Bang Relaunch.

Say Hello To Manuel

2011-05-06T20:49:38+00:00

As mentioned on twitter we want to introduce you to Manuel Korfmann.

Manuel is a 16-year-old boy, who loves seeing and writing elegant, clean and DRY Ruby code. And since Rails is perfectly suited for doing this, Manuel loves Rails too. So it seems like his destiny is to work for Railslove. Manuel started programming Ruby about a year ago, though he had some experiences with C++ before but don’t wants to be approached upon this subject.

You can follow Manuel on Twitter, Github and visit his homepage.

Glad that you’re hacking at Railslove!
We wish you a very nice time!

The Crew!

Mai 13th – the next DevHouse Friday Chillout

2011-05-02T08:36:22+00:00

DevHouseFriday is an event intended for creative and curious people interested in technology inspired by SuperHappyDevHouse. Once a month (on fridays) we talk about technology and share our knowledge while meeting new people and learning stuff we are all interested in.

Everyone had troubles while writing code. We need people they can tell us that special experience with us.

What kind of trouble? How did you resolved it? Tell us everything!

Am 13.05.2011 um 19:00 Uhr

millepondo services
Heinrich-Brüning-Str. 8
50969 Cologne Deutschland (Germany)

http://www.millepondo.de
Anmeldung auf der DevHouse mixxt-Seite.

EventMachine, How Does It Work?

2011-04-25T00:00:00+00:00

At this year's Scottish Ruby Conference, I gave a talk about EventMachine, slides are available. Amidst the hype around Node.js it's too easy to forget that Ruby has had evented I/O libraries for years. EventMachine, libebb, rev, cool.io, to name a few. As a general introduction I recommend reading Dan Kegel's article on the C10K problem, the problem of handling 10000 server connections on a single machine. It introduces all the evented approaches that have been implemented in the different operating systems over the last some 15 years.

In preparation for the talk I got curious about EventMachine's innards. So I thought it'd be nice to share my findings with you. Node.js kids, pay attention, this concerns you as well. It may be JavaScript, but in the end Node.js works in a similar fashion, though it builds on libev, which does most of the plumbing for the different operating system implementations of non-blocking I/O.

Most of the magic happens inside the C++ part of EventMachine, so now's as good a time as any to dig into it and find out how it works. There'll be code in here, not assembler, but I'll be throwing constants, standard library functions and TCP networking bits (from C, not from Ruby) at you. There's no magic however, and when in doubt, consult the man pages. You do know about man pages, right? They're awesome.

while(true): The Event Loop

EventMachine is based on the idea of an event loop, which is basically nothing more than an endless loop. The standard snippet of code you're wrapping all your evented code is this:

EM.run do
  # go forth and handle events
end

You can look at the details of what the method does in its full glory. Other than initializing some things, it dives down into the C++ layer immediately, and it's where most of the magic happens from now on.

Three C/C++ extension files are of importance, ext/rubymain.cpp is the bridge between Ruby and the C code layer. It uses Ruby's C functions, mostly to convert datatypes for the later below. It then calls into code defined in ext/cmain.cpp, which in turn bridges the C and the C++ code.

When you call EM.run to start the event loop, it calls down into the C layer to t_run_machine_without_threads, which is called as run_machine, and which in turn calls EventMachine_t::Run(), whose interesting bits are shown below.

 while (true) {
   _UpdateTime();
   if (!_RunTimers())
     break;

  _AddNewDescriptors();
  _ModifyDescriptors();

  if (!_RunOnce())
    break;
  if (bTerminateSignalReceived)
    break;
}

There's your event loop, doesn't look that scary now, right? It basically does five things:

Update the current time (line 2)

Used in the next step to determine whether a timer should be fired
Run configured timers (line 3)

All the timers specified through either add_timer or add_periodic_timer are run here. When you add a timer, EventMachine stores it in a map indexed with the time it's supposed to fire. This makes checking the list for the ones that should be fired in the current iteration a cheap operation.

_RunTimers() iterates over the list of timers until it reaches one entry whose key (i.e. the time it's supposed to fire) is higher than the current time. Easy and efficient.

On a side note, _RunTimers always returns true, so it's a bit weird that the return value is checked.
Add new descriptors (line 6)

Whenever you open a new server connection, EventMachine adds an object representing the connection and the associated callbacks to this list. All connections and descriptors created in the last iteration are handled, which basically includes setting additional options if applicable and add them to the list of active connections.

On the operating system level a descriptor represents a file handle or a socket connection. When you open a file, create a connection to another machine or create a server to listen for incoming connections, all of them are represented by descriptors, which are basically integers pointing into a list maintained by the operating system.
Modify descriptors (line 7)

Modify existing descriptors, if applicable. This only has any effect when you're using epoll, which we'll get to later.
Run the event (line 9)

Check all open file descriptors for new input. Read whatever's available, run the associated event callbacks. The heart of the event loop, worth taking a closer look below.

The event loop really is just an endless loop after all.

Open a Socket

When you call EM.connect to open a connection to a remote server, the connection will be immediately created, but it may not finish until later. The resulting connection will have a bunch of properties:

The descriptor is configured to not block on input and output by setting the socket option O_NONBLOCK. This way reads will immediately return when there's no data instead of waiting for some to arrive, and writes don't necessarily write all the data they're given. It also means that a call to connect() to create a new connection returns before it's fully created.
The Nagle algorithm is disabled to prevent the TCP stack from delaying sending packets by setting TCP_NODELAY on the socket. The operating system wants to buffer output to send fewer packets. Disabling Nagle causes any writes to be sent immediately. As EventMachine does internal buffering, it's preferrable for the data to be really sent when it's eventually written to a socket.
Reuse connections in TIME_WAIT state before they're fully removed from the networking stack. TCP keeps connections around for a while, even after they're closed to ensure that all data from the other side really, really made it to your end. Nice and all, but in environments with a high fluctuation of connnections, in the range of hundreds to thousands per second, you'll run out of file descriptors in no time.

Opening a socket is an immediate event, it happens as soon as you create a new connection. Running any callbacks on it won't happen until the next iteration of the event loop. That's why it's safe to e.g. fire up a new HTTP request and then attach callbacks to it. Even if that wouldn't be the case, EventMachine's Deferrables (not to be confused with EM.defer) ensure that callbacks are fired even after the original event fired, when they're added at a later time.

What is immediately called, though, is the post_init method on the connection object.

Opening a network connection is just one thing you can do with EventMachine, but as it's the one thing you're most likely to do when you're using it, let's leave it at that.

Don't call us, we'll call you

Working with asynchronous code in EventMachine usually involves callbacks, unless you work with your own connection class. Libraries like em-http-request rely on deferrables to communicate with your application. They're fired when a HTTP request finished or failed. But how does a library keep track of data that only comes in bit by bit?

The answer is simply buffering. Which brings us to the core of the event loop, checking sockets for input, which is done from the ominous _RunOnce() method in the code snippet above. EventMachine can utilize three mechanisms to check descriptors for new input.

select(*)

The default is using select(), a standard system call to check a collection of file descriptors for input, by way of Ruby's implementation rb_thread_select(), which wraps the call to select() with a bunch of code ensuring thread safety.

Using select() pretty much works everywhere, and is perfectly fine up to a certain number of file descriptors. If you're simply serving an asynchronous web application or API using EventMachine, this may be totally acceptable.

Implementing this way of handling I/O is rather straight-forward, if you look at the implementation. Collect all file descriptors that may be of interest, feed them into select, read and/or write data when possible.

What makes using select() a bit cumbersome is that you always have to assemble a list of all file descriptors for every call to _RunOnce(), so EventMachine iterates over all registered descriptors with every loop. After select ran, it loops over all file descriptors again, checking to see if select marked them as ready for reads and/or writes.

When select() marks a descriptor as ready for read or write operations that means the socket will not block when data is read from or written to it. In the case of reading that usually means the operating system has some data buffered somewhere, and it's safe to read that data without having to wait for it to arrive, which in turn would block the call.

Instead of using select(), EventMachine could also use poll() instead, which just handles a bit nicer in general, but is not available in the Ruby VM.

epoll

epoll is Linux' implementation for multiplexing I/O across a large number of file descriptors.

The basic steps of using epoll are simple:

Set up an epoll instance using epoll_create, done initially when the event loop is created. This creates a virtual file descriptor pointing to a data structure that keeps track of all real file descriptors associated with it in the next step.

You only need to reference this single file descriptor later, so there's no need to collect a list of all file descriptors, as is the case when select() is used.
Register interest for events on a file descriptor using epoll_ctl on the epoll instance created above.

This is used in _AddNewDescriptors and _ModifyDescriptors to register and update EventMachine's file descriptors with epoll. In fact, both methods only do anything noteworthy when epoll is used. Otherwise they just iterate over a list of descriptors, pretty much doing nothing with them.
Wait for input with epoll_wait for a specified duration. You can wait forever, return immediately if nothing happened, or wait for a specific amount of time.

EventMachine seems to have chosen to return immediately if there's no activity. There's an alternative implementation calculating the time to wait based on the likelihood of a specific event (e.g a timer firing) to fire on the next event loop iteration, but it doesn't seem to ever be used. Seems to be a relict from the time it could also be used as a C++ library.

epoll events are registered for both reads and writes, with epoll_wait returning the number of file descriptors that are ready for both events.

Using epoll has a big advantage, aside from being much more efficient than select in general for larger sets of file descriptors. It spares code using it the burden of constantly iterating over a list of file descriptors. Instead you just register them once, and then only iterate over the ones affected by the last call to epoll_wait.

So epoll requires a bit more work when you add or modify connections, but is a bit nicer on the eyes when it comes to actually polling them for I/O availability.

Note that epoll support must be explicitly enabled using EM.epoll.

kqueue

kqueue is the BSD equivalent of epoll, and is available on e.g. FreeBSD and Mac OS X. It works very similar to epoll. If you want to know more details, I'd suggest reading the paper on it by Jonathan Lemon.

You can enable kqueue support using EM.kqueue, which is, just like EM.epoll, a noop on systems that don't support it. Hopefully future EM versions will use whatever's available on a particular system as default.

Call me already!

All three mechanisms used have one thing in common: when data is read, receive_data is called immediately, which brings us back to the question of how a connection objects collects data coming in.

Whenever data is ready to be consumed from a socket, EventMachine calls EventDescriptor::Read(), which reads a bunch of data from the socket, in turn calling read() on the file descriptor, and then immediately executes the callback associated with the descriptor, which usually ends up calling receive_data with the data that was just read. Note that the callback here refers to something defined on the C++ level, not yet a Ruby block you'd normally use in an asynchronous programming model.

receive_data is where you will usually either buffer data or run some action immediately. em-http-request feeds the data coming in directly into an HTTP parser. Whatever you do in here, make it quick, don't process the data for too long. A common pattern in libraries built on EventMachine is to use a Deferrable object to keep track of a request's state, firing callbacks when it either succeeded or failed.

Which brings me to the golden rule of programming with libraries like EventMachine and Node.js: DON'T BLOCK THE EVENT LOOP!! Defer whatever work you can to a later run of the loop when it makes sense, or push it to another asynchronous processing facility, e.g. a message queue like RabbitMQ or Redis' Pub/Sub.

In a similar fashion, whenever you write data to a connection using send_data, it's first buffered, and not actually sent until the socket is ready for a non-blocking call to write(). Hence all three implementations check for both read and write availability of a descriptor.

Fibers vs. Spaghetti

Where do Ruby's Fibers come in here? Callbacks can easily lead to spaghetti code, especially when you have to nest them to run multiple asynchronous actions in succession.

Fibers can stop execution of a process flow at any time and yield control to some other, controlling entity or another Fiber. You could, for example, wrap a single HTTP request into a fiber and yield back control when all the callbacks have been assigned.

In the callbacks you then resume the Fiber again, so that processing flow turns into a synchronous, procedural style again.

  def get(url)
    Fiber.new do
      current_fiber = Fiber.current
      request = EM::HttpRequest.new(url).get
      request.callback { current_fiber.resume(request) }
      request.errback  { current_fiber.resume(request) }
      Fiber.yield
    end
  end

Fiber.yield returns whatever object it was handed in Fiber.resume. Wrap this in a method and boom, there's your synchronous workflow. Now all you need to do is call get('http://paperplanes.de') and assign something with the return value. Many props to Xavier Shay for digging into the Goliath source to find out how that stuff works. Helped me a lot to understand how that stuff works. If you never had a proper use case for Fibers in real life, you do now.

em-synchrony is a library doing just that for a lot of existing EventMachine libraries, and Goliath is an evented web server, wrapping a Rack-style API using Fibers.

Things you should be reading

Here's a bunch of free reading tips for ya. These books are pretty old, but have gone through some revisions and updates, and they're still the classics when it comes to lower level Unix (network) programming and understanding TCP/IP, which I consider very important. TCP/IP Illustrated is one of the best books I've read so far, and I consider it essential knowledge to be aware of what happens under the networking hood.

Also, read the fine man pages. There's a whole bunch of good documentation installed on every Unix-style system, and I linked to a couple of them relevant to this post already. Read it.

yield

This concludes today's whirlwind tour through some of EventMachine's internals. There's actually not too much magic happening under the covers, it's just wrapped into a bit too much code layering for my taste. But you be the judge.

Play with EventMachine and/or Node.js if you haven't already, try to wrap your head around the asynchronous programming model. But for the love of scaling, don't look at evented and asynchronous I/O as the sole means of scaling, because it's not.

Well, well, hasn't it been quiet in here

2011-04-19T22:00:00+00:00

Well, yes it has. I still feel like my whole life still didn’t settle enough for me thinking thoughts deep enough so that I could blog about them. And then, I’ve obviously been bitten by the pesky twitter bug, resulting in writing invariantly more, but in 140 character chunks.

So, whassup? Awesome Fontstacks is still going relatively strong, although it is extremely hard to find the necessary time to bring the idea forward. Well, there’s still more than half a year left before to come up with an idea on how to pay the server bills :)

On a similar note, we’ve developed an idea we currently call “Awesome Ideas Inc.”, which right now consists of a small group of awesome people committed to bring one small project to life in each quarter, every time in a rails rumble like fashion. We just (this weekend) finished our first project, which we launched in what I would call silent beta. If you’re interested in checking out a project in a very rough and unfinished state, hit one of us up on the twitters for a link.

The weekend was an interesting experience, because it was the first time we actually tried to force ourselves to work in a rumble like setup with no actual contest going on. Also, we had some organisational issues with people not finding the time to contribute, our lead frontend guy catching the lurgy the week before and also working in a considerably less technically oriented field than the last two times. Nevertheless, Malte with whom we never worked before (but only heard great things about before, of course), not only delivered a great design and visual concept, but also fit the team perfectly. Huge thanks, and massive thumbs up! Also, he contacted his berlin friend Kristina Schneider who, on very short notice, delivered awesome illustrations.

The father of the application idea, Tim Schurig, a long friend of our mindmatters Social Media Expert (just kidding, mate) Florian Siepert, also was great because he not only provided a great idea (ideas alone may be worthless, but that doesn’t mean that you don’t need to come up with them) but also was happily bouncing back and forth with all of us on the concept. He spent most of the weekend together with the equally awesome Klaus-Peter Frahm, preparing scribbles, writing copy and finding an endless stream of project matching puns.

So, on the concept on design side, things went smoothly, but in retrospect, they also went way to slow, or, more aptly put, way to late. For us in the development corner (Always a pleasure to work with: Podio’s very own Florian Munz and mindmatters co-founder and slightly lurgy ridden, but still awesomely awesome Wolfgang Wopperer), this weekend was by far the hardest challenge and we almost completely failed. We were reluctant to start at all, because the concept was, at least for the first hours, still very much in flux, and then we started at the wrong edge, prototyping advanced input controls in javascript. What we should have done, in retrospect, is to start as you would do in any sensible project context: Implementing the core workflow (which is complicated enough, as we found out later, maybe too late) without bells and whistles and then iterate from there. So, we pretty much jammed ourselves for the first 8-12 hours in the project. Of course it was Florian who finally got the message and spent the rest of the time implementing the workflow while I was still drenched in jQuery UI slime. I am still amazed that we managed to actually complete the workflow (only the golden path, I’m afraid, but still…).

What do we take away from it? For me personally it was a wake up call to stick to the process I know that works, namely, sketching out a rough workflow with the simplest techniques possible and then, when the conceptional and design dust settles, iterate on UI/UX from there. Apart from that, I am convinced that we have found an amazing model to work with. What makes this concept great is not only the quick turnaround, enabling us to verify ideas with very little overhead, but also the people, which are all absolutely top notch at what they do, but are also astonishingly low on ego trippin’, which is crucial for such an endeavour – The last thing you want on such a weekend long sprint is two people fighting some ego fight on conflicting ideas.

Rock. On. We’ll keep you posted. For now, it might be a good idea to follow @awesomeideasinc on twitter.

IBAN Validation and Ruby 1.9

2011-04-15T13:52:30+00:00

In one of our projects 9flats.com we’re using a short IBAN and SWIFT Validation rule to be sure the user entered valid bank account information.
To know how to validate an IBAN account number, just have a look at this article on wikipedia. Therefore you have to do a few steps to be sure get the right format of an IBAN number:

Validating the IBAN
The basis of the IBAN validation is to convert the IBAN into a number and to perform a basic Mod-97 calculation (as described in ISO 7064) on it. If the IBAN is valid, then the remainder equals 1. Rule process of IBAN validation is:

Check that the total IBAN length is correct as per the country. If not, the IBAN is invalid.

Move the four initial characters to the end of the string.

Replace each letter in the string with two digits, thereby expanding the string, where A=10, B=11, …, Z=35.

Interpret the string as a decimal integer and compute the remainder of that number on division by 97.

If the remainder is 1, the checks digits test is passed and the IBAN may be valid.

I found a short (and also funny) blogpost about a validation script in ruby. Unfortunely the expression
iban = value.gsub(/[A-Z]/) { | p | p[0]-55 }
does’n work anymore, because Ruby 1.9 doesn’t return the integer ordinal of a one-character string using p[0]. Instead of that just use the .ord method on a string. So our Ruby 1.9 compatible code will looks like this:
iban = value.gsub(/[A-Z]/) { | p | p.ord-55 }
If you’re using two or more environments (e.g.: Ruby 1.8 and Ruby 1.9) on your production or development machine (I know thats not the way to go, but it could happen for a little time) just ask if Ruby respond to the .ord method.
iban = value.gsub(/[A-Z]/) { |p| (p.respond_to?(:ord) ? p.ord : p[0]) - 55 }

The final code from the blogpost mentioned before will be looks like this:

Small things can be very helpful!

Using Cucumber Step Argument Transforms

2011-03-24T09:25:00+00:00

In a recent project that is tested with Cucumber we were using „within“ steps with CSS selectors. Though this isn’t basically considered a good idea I’d say it made sense for us, because we had to select specific parts of the page. Cuking it like that, our steps usually looked something like this:

Scenario: Edit something
                                Given there is something
                                And another something
                                When I go to the page of somethings
                                And I follow "edit" within "ul.somethings li:nth-child(1)"
                                Then I should be on the edit page for "something"

Besides looking just ugly, CSS selectors also don’t offer any business value and are likely to change. Cucumber’s Step Argument Transforms can help you avoid that by refactoring common operations.

Transforms are defined with the Transform keyword and can be a part of your step definition files. Cucumber matches the captures in your steps (i.e. the 1st something) against the defined transforms. If the regexp matches, it yields the transformed value as an argument to the step definition block. This sounds complicated, so here’s an example:

Transform /^the (\d+)(?:st|nd|rd|th) something$/ do |num|
                                "ul.somethings li:nth-child(#{num})"
                              end

This transform allows us to refactor the scenario above to be more readable and maintainable:

Scenario: Edit something
                                …
                                When I go to the page of somethings
                                And I follow "edit" within "the 1st something"
                                …

We can even abstract this a little further and make it usable on a common level:

Transform /^the (\d+)(?:st|nd|rd|th) (.+)$/ do |num, type|
                                "ul.#{type.pluralize} li:nth-child(#{num})"
                              end

This is just a basic example of how this often unknown Cucumber feature might help you to refactor your step definitions. For more information and decent examples check out the wiki page on Step Argument Transforms.

DevHouse Friday – 25.03.2011 hosted by adcloud

2011-03-18T22:27:14+00:00

Es ist wieder einmal Zeit für ein lockeres Come-Together von Web-Entwicklern und Tekki’s (endlich normale Leute). Mit einem Drink und zwei-drei kurzen Talks leuten wir das Wochenende ein und vergessen den Coding-Stress.

Vielen Dank an adcloud, welche den Event in Ihrer neuen Location im hippen Ehrenfeld ausrichten.

WANN: 25.03.2011 ab: 19:00 Uhr

WO: adcloud GmbH, Venloerstr. 25-27, 50672 Köln

WAS: Bring your brain and a beer

MORE: http://devhousefriday.org/ AND @devhousefriday

Das adcloud-Team ist übrigens noch auf der Suche nach Talenten (übrigens wir auch), was ich jedem empfehlen kann der am Puls der Zeit arbeiten möchte.

Entwickler aller Sprachen vereinigt euch!

Ruby & Rails UG meetup: 24 Mar @ CoWoCo

2011-03-17T22:58:36+00:00

We’re very excited to announce the second meetup of the revived Cologne Ruby & Rails User Group RuRUG!

To take part in the awesomeness that is meeting your local gang of fellow Ruby & Rails aficionados, pop by Coworking Cologne on Thursday, 24 March at 20:00.

The schedule so far consists of a JRuby on Rails talk by Jan Lühr. More slots are still up for grabs – feel free to suggest your own talk, or boldly give an impromptu presentation of anything you’re interested in. After the presentations, there’ll be plenty of time to meet new people, do some collaborative hacking and have a couple of beers =)

Hope to see you there!

For directions and further information, make sure to check out RuRUG’s website, mailing list, and facebook page.

rubyonrails-ug.de Planet

We @ Wroc_❤.rb and we ❤ Vention Dention

We’re giving a talk

We love punk rock

A Tour of Amazon's DynamoDB

The Basics

Data Model

Conflicts and Conditional Writes

Consistency on Writes

Consistency on Reads

Reading Data

Atomic Counters

Storing Data in Sets

Column Store in Disguise?

A Word on Throughput Capacity

Data Partitioning

Range Keys

Queries using Filters

The API

Pricing

Bottom Line

Closing Thoughts

Resources

Seeds for different environments

My Publishing Tool Chain

DRUG #25

Railslove at war

The only constant is change

a very Merry Christmas

Holiday Reading List

Storing User Timelines in Riak

How do you model a timeline in Riak?

Adding entries to the timeline

Conflicts, siblings, oh my!

Sort, and done!

List All of the Riak Keys

What's in a bucket?

Listing all of the keys

So how do I really get all of the keys?

Ideally...

The Simple Magic of Consistent Hashing

Easier to Avoid Hotspots

Consistent Hashing Enables Partitioning

Partitioning Makes Scaling Up and Down More Predictable

Consistent Hashing and Partitioning Enable Replication

Replication Reduces Hotspots (Even More!!!)

Consistent Hashing Enables Scalability and Availability

Configuring Nginx for the Asset Pipeline

Installation via Passenger

Nginx configuration

Sendfile Header

Verify that it’s working

Referencing Rails Assets in CoffeeScript

reminder: Global Day of Coderetreat Cologne/Bonn 3rd Dez.

OpenData Bremen

Precompiling Rails Assets for Development

Dear Cologne Rubyists: Your user group needs you!

Git autocomplete in bash on a Mac

No magic behind it but everytime worth to remember

Rspec Refactoring and Shared Example Groups

Some simple spec principles

Shared example groups

Further reading:

Setting up Ubuntu with Teleport

Some facts: Teleport …

My setup

Let’s go…

Capybara Finder for Cucumber Rails’ Deprecated Tableish

Global Day of Coderetreat Cologne / Bonn

Installing MacVim with Ruby support and Command T on OSX Lion

Howto

Troubleshooting

Resources

“Birthday” gem for easy anniversaries handling

Requirements

So, how does it actually work?

Final words

Backlash @ Robot Unicorn Invasion Party 2011

Help You need somebody; Help not just anybody!

Travis – a distributed build system