Dec 26 / phoet

Karotz + Ruby = Love

I made myself a little present this christmas by putting a Karotz under my christmas tree. This little digital bunny robot is the 3rd generation of a gadget that was once known as Nabaztag.

Karotz can connect to the internet and you can deploy applications on it. It’s a tiny multitalent, speaks, blinks, turns his ears, takes photos and plays musik. The really cool stuff about all this, is that you can also access it via a REST-api.

I was a little disturbed by the bad documentation of the api, but since Karotz has had a pretty shaken history, I was willing to see over it. Nevertheless I had a really hard time figuring out how to use the API, especially the interactiveMode sessions, which are crucial for interacting with Karotz. That’s why I wanted to give you a short HOW-TO wrapup on it.

Basic Setup

First of all you need to have a Karotz up and running, like it’s described in the handbook. Register yourself at karotz.com and click on the lab button at the bottom of the page. Once you registered yourself for all the developer stuff, you need to register a new application for yourself in order to get access to the credentials needed to talk to Karotz.

In order to get your own application, you need to create a descriptor.xml and package it as a zip-file and then load it up to the appstore and then deploy it to your bunny. Here is an example, which exposes the install-id of your application, which you need to accesss your Karotz:

<descriptor>
  <version>0.0.1</version>
  <accesses>
    <access>tts</access>
    <access>ears</access>
    <access>led</access>
    <access>multimedia</access>
  </accesses>
  <deployment>external</deployment>
  <parameters>
    <parameter key="showInstallUuid" value="true"/>
  </parameters>
</descriptor>

Have a look at this Christops Blog if you don’t get it working for yourself.

Using the Gem

There are already some code-examples on the developer-pages on how to get an interactive_id for your Karotz and some code has been released for Ruby as ruby-karotz here and here none of them exposing a nice API or describing the process of how to get all the peaces of the puzzle together. That’s why I am currently writing this…

So here is an example of how to interact with the karotz gem:

Karotz::Configuration.configure do |config|
  config.install_id = ENV['KAROTZ_INSTALL_ID']
  config.api_key    = ENV['KAROTZ_API_KEY']
  config.secret     = ENV['KAROTZ_SECRET']
end
 
Karotz::Client.session do |karotz|
  karotz.ears
  karotz.led
  karotz.say
  karotz.play
end

This will rotate Karotz ears, blink the LED, say ‘test’ and let it play the A-TEAM theme!

FTW!

Dec 22 / phoet

Ruby Quirks

Once in a while I come accross some Ruby code where I don’t know why it is doing stuff the way it does…

Ternary Operator

I am using the Ternary Operator quite a lot, because it keeps the code concise and often times more readable then long if-else statements. One thing that I discovered just recently is the following:

val = something ? 'this' : 'that'

If you look closely, you will see that there is not a comparison == but an assignment = operator present. The interesting fact though is where Ruby puts parenthesis in this code:

val = (something ? 'this' : 'that')

Makes a lot of sense, but is not obvious, especially if you are debugging some library code.

Another cool thing that you can do with the operator is nesting:

val == 0 ? 'zero' : val == 1 ? 'one' : 'other'
# is interpreted as
(val == 0 ? 'zero' : (val == 1 ? 'one' : 'other'))

But most of the times you are better of with Switch Cases.

Switch Case

There are some pretty cool features in the Ruby Switch Case. You can switch by class if you like:

case "some string"
when Integer
  puts "i am an int"
when String
  puts "i am a string"
else
  puts "dunno"
end

This works, because Ruby uses the === method to compare in a when block. So the when code above evaluates to:

String === "some string"

The cool thing is that you can implement the === method yourself and add some Ruby magic to the Switch Case.

But be aware of some stuff that might bite you while using Switch Cases! You should know that Ruby allows multiple arguments in a when block:

case val
when 5, 7
  puts "good numbers"
else puts "bad numbers"
end

It’s also important to know that you need to add a newline before writing your block code. It’s also possible to write oneliners by using a semicolon or the then keyword, otherwise the following code will be interpreted as belonging to the when condition:

case val
when 5, 7; puts "good numbers"
when 0 then puts "empty"
when 1, puts "syntax error"
else puts "bad numbers"
end

Older versions of Ruby also supported a syntax with a : at the end instead of a ;, wich looks kind of strange:

case val
when :number: puts "numbers"
else puts "not a numbers"
end

Missing something

Since the Ruby parser allows a lot of flexibility, it’s possible to implement stuff which does not make sense at all. For example this statement which misses the if at the beginning of the condition:

def test_failing
  else puts "invalid"
  end
end

Evaluating this method will fail (or even kill the ruby process):

warning: else without rescue is useless
syntax error, unexpected keyword_end, expecting $end

One thing that happens to me quite often, is that there are implicit things going on if you forget to add commas in your code, while I am not sure how and why they work:

puts "what" "the" "fuck" # => "whatthefuck"
puts String Integer # => Integer

Everything is a Method

Well not everything in Ruby is implemented as a method, but there a lot of things that you can at least use like methods. Did you know for example, that you can call the accessibility modifiers in Ruby like methods? This is pretty handy if you want to mark only some methods:

def my_method; end
private :my_method

It’s also quite important to know that method objects provide a lot of interesting information. Especially if you are doing some serious debugging with a lot of inheritance and Ruby magic involved:

"".method(:class).owner # => Kernel
class A
  def b;end
end
# works only in 1.9
A.new.method(:b).source_location # => ["...test.rb", 3]

When talking about methods, it’s worth knowing the keywords that are used in Ruby and in which context they can be used. A good example for this is the * character, which can be used quite differently:

# as a simple method
1 * 2
# for varargs in method signatures
def method_name(*args)
# for unsplatting arrays
some_method_that_has_three_args(*[1, 2, 3])

You should also be aware that some operators behave different from others:

def some_array
  @some_array ||= []
end
 
def doit
  some_array << [3,4] # ok
  some_array += [6,7] # raises undefined method `+' for nil:NilClass
end

Predefined Variables

In analogy to Pearl, Ruby provides a bunch of Predefined Variables that are worth knowing. A lot of them contain information about the current environment, code or execution context.

There are f.e. some extra variables for matching groups in Rubys regular expressions:

"hey_you" =~ /(.*)_(.*)/
$1 # => hey
$2 # => you
$0 # => .../test.rb

Unfortunately $0 has nothing to do with match groups, but is the name of the current executed program…

Naming Best Practices

When working with Ruby you get used to some best practices when it comes to names. This is important, because several thing are evaluated differently depending on up- and downcase:

CONSTANTS_ARE_UPPER_SNAKE_CASE
ClassesAreCamelCase
Modules::Should::Map::To::Folder::Structure

So it is quite surprising that Ruby comes with an Array() method which transforms everything it gets into an array unless it’s already an array:

Array("string") # => ["string"]
Array(["string"]) # => ["string"]

It’s also worth having a deep look into the Ruby documentation about Arrays and the Enumerable Module, because they provide a bunch of really cool helpers that can save you an everage developers lifetime if you know them by heart.

For some more cool Ruby tricks have a look at this Rubyinside post.

If you feel like sharing some more Ruby wisdom feel free to post a comment or contribute some sugar!

Sep 29 / phoet

Improved ASIN documentation

Beeing sick sucks, but on the other hand there is a lot of spare time…

So, while sitting on my couch, I created a new resource for documentation of my pet project the asin gem, which you can find on heroku:

ASIN-WEB

If you have any additions or questions feel free to fork the project or open up an issue on github.

Jul 29 / phoet

Heroku Cedar Background Jobs for free!

I’m using Heroku mostly for playing around with latest technology and hosting free apps. Since Heroku changed their pricing model due to the introduction of the new process model some of my apps changed from free to paid, especially those that had some background jobs or nightly crons (I really did not get, why this happend).

Full Stack Background Processes

If you want to run a resque worker and a clockwork process within your web-app, this becomes a costly thing, even if those are just running some minor jobs in the night, because you need to pay for 2 additional dynos.
You could achieve this through defining multiple processes in your Procfile:

# Procfile
web: bundle exec rails server thin -p $PORT
worker: QUEUE=* bundle exec rake environment resque:work
clock: bundle exec clockwork app/clock.rb
heroku scale worker=1 clock=1

Sharing Addon Connections

As Heroku officially announced in their latest newsletter, it’s possible to share connections between multiple apps. In my case, this would be a connection to a redis key-value store, that is provided by Redistogo. It’s as simple as copying the environment configuration for the addon over to the second app:

heroku config | grep DATABASE_URL  --app sushi
=> DATABASE_URL   => postgres://lswlm...
 
heroku config:add DATABASE_URL=postgres://lswlm... --app sushi-analytics
=> Adding config vars: DATABASE_URL => postgres://lswlm...m/ldfoiusfsf
=> Restarting app... done, v74.

Going Freemium

So the solution for getting back to a free worker setup is combining 3 Heroku apps and a shared Redis connection through Redistogo:

heroku apps:create freemium-web --stack cedar --remote heroku
git push heroku master
 
heroku apps:create freemium-worker --stack cedar --remote worker
git push worker master
 
heroku apps:create freemium-clock --stack cedar --remote clock
git push clock master
 
heroku scale web=1 --app=freemium-web
heroku scale web=0 worker=1 --app=freemium-worker
heroku scale web=0 clock=1 --app=freemium-clock
 
heroku addons:add redistogo:nano --app=freemium-web
 
heroku config:add `heroku config -s --app=freemium-web|grep redis` --app=freemium-worker
heroku config:add `heroku config -s --app=freemium-web|grep redis` --app=freemium-clock

I created an example project running a Rails 3 application with a mounted Resque web, a Resque worker and a clock process with Clockwork.

Even simpler

If you are just looking for a simple solution of running a background process have a look at crony, a bootstrap project using rufus-scheduler.

Jun 29 / phoet

Migrating an existing App to Heroku Celadon Cedar Stack

It’s currently not possible to do an automated migration from or to the Heroku Celadon Cedar Stack which started in May. The only help that you get from Heroku is this:

Migrating From Bamboo to Cedar

Before migrating to Bamboo, you should make sure your app runs on Ruby 1.9.2. If your app is not already deployed successfully to bamboo-mri-1.9.2, you should do that first, and then come back and try Cedar.

Once you’re sure your app is fully compatible with Ruby 1.9.2, create an app on the Cedar stack and push to it. Currently, stack:migrate does not work for moving apps to Cedar.

Since there seem to be no blogposts of how to do all the stuff with an existing application I will try to cover everything that I did to do the migration manually in this article.

Cedar is different

If you are looking at the new stack you will notice that a lot has changed with Cedar. Most of the Heroku CLI has changed to reflect the new possibilites that come with the Cedar stack. Since Cedar introduces a new way of handling processes on Heroku, most of the commands are now streamlined with this:

# old
heroku console
heroku rake db:migrate
# new 
heroku run console
heroku run rake db:migrate
 
# have a look at running processes
heroku ps
 
# look at logs of different processes and tail the output
heroku logs --ps web -t

Preparing the Migration

I started by cloning my current app from Heroku into another directory and creating a new Cedar app on Heroku:

git clone git@heroku.com:hamburg-on-ruby.git legacy
cd legacy
heroku create --stack cedar

Adapting Cedar changes

The docs for creating a Rails 3 app on Cedar reflect some of the changes that have been introduced with Cedar.

One of those is that PostgreSQL is now recommended for local development and you need to have the pg-gem in your Gemfile. Otherwise you will get errors while running rake commands:

heroku run rake db:migrate
 
  Running rake db:migrate attached to terminal... up, run.1
  (in /app)
  rake aborted!
  no such file to load -- pg

Since I developed my app with SQLite3 and I don’t want to learn, install and manage ANOTHER Database I split up the database stuff for development, test and production:

# Gemfile
group :production do
  gem "pg"
end
 
group :development, :test do
  gem "sqlite3-ruby", :require => "sqlite3"
end

and exclude production dependencies from my local environment:

# put this into your .profile
alias bd="bundle --without=production"

It’s also recommended to serve Rails through thin webserver and manage the application with the Procfile manager foreman:

# Gemfile
gem "foreman"
gem "thin"
# Procfile
web: bundle exec rails server thin -p $PORT
foreman start

After going through those chages you should be able to see your application on localhost:

open http://localhost:5000

The migration process

If the application is running on your development machine you can start the core migration process by putting your legacy application into maintenance mode, so that no database changes will be made:

heroku maintenance:on
# stop worker, crons or whatever might be changing the db

Database Migration

After you completely halted everything on your dyno, you can start dumping the database to your development machine (I thought it would be neat to do a direct migration from the legacy database to the new Cedar database, but I did not get it working). You need to install the taps-gem in order to do any dumping. Taps will dump the database into your development database unless you provide an connection string to another database:

# use sqlite for dumping and do it into a separate file
heroku db:pull sqlite://dump.db
 
# mv the file to your Cedar application and push it
heroku db:push sqlite://dump.db

Config variables

If you have custom config variables in your application it’s pretty easy to move them into the new environment:

# list all config values of the legacy app in console format
heroku config -s
 
# replace the newlines with whitespaces and
# append all the configuration variables of 
# your new Cedar app at the end or remove the
# ones that you do not want to migrate!
 
# add the list of values to your Cedar app
heroku config:add KEY=VALUE KEY2=VALUE2 [...]

Installing addons

It’s also most likely that you want to use the same addons than in your legacy application:

# list your addons in the legacy app
heroku addons
 
# install all addons separately in the Cedar app
heroku addons:add apigee:basic
heroku addons:add cron:daily
[...]

Sendgrid

If you are using the Sendgrid Addon you should be aware that the automatic configuration is not working anymore the Cedar Stack! You need to configure it in your app:

  # config/environments/production.rb
  config.action_mailer.raise_delivery_errors = true
  config.action_mailer.smtp_settings = {
    :address        => "smtp.sendgrid.net",
    :port           => "25",
    :authentication => :plain,
    :user_name      => ENV['SENDGRID_USERNAME'],
    :password       => ENV['SENDGRID_PASSWORD'],
    :domain         => ENV['SENDGRID_DOMAIN']
  }

Switching domains

Before you do the last step, you should have a look if everything is up and running:

heroku open

If everything is fine, you can move all the domains from the legacy application to your new and shiny Cedar Stack application:

# list domains in legacy app
heroku domains
 
# and remove them
heroku domains:remove hamburg.onruby.de
heroku domains:remove onruby.de
[...]
 
# re-add them to Cedar application
heroku domains:add hamburg.onruby.de
heroku domains:add onruby.de
[...]

Looking at the result is quite disappointing, because nothing has changed for the user, but everything is new and shiny from the inside!

If you have any other pointers of what you need to do for migrating your application please feel free to add a comment!

Fork me on GitHub