Linux Tage 2013 in Berlin

Linux Tage 2013 in Berlin is the biggest Linux Conference in Germany. It goes from Wednesday to Saturday. There are all day long sessions & tech talks. And of course a big exhibition hall, where you can meet some of the vendors. It is a place there .com meets .org.

I have been there today and will be there tomorrow and on Saturday. You can find me at the Yunicon stand in the exhibition hall. Yunicon is an awesome private cloud provider from Berlin. They have the coolest stand in the exhibition hall because they offer free cocktails! :-)

LinuxTage_VersionEye

I am doing every day at 15:30 a talk about Continuous Updating with VersionEye.

LinuxTage_VersionEye_Talk

If you want to learn something about Continuous Updating or VersionEye, join the talk. Grab a free cocktail and ask me your questions. I am happy to answer them.

LinuxTage_VersionEye_TechTalk

See you tomorrow.

VersionEye now with new Dependency Badges

VersionEye has now new dependency badges for Java, Ruby, PHP and Node.JS. You will find them on every package page. They look like this.

dep_out-of-datedep_up-to-date dep_unknown

They badges are showing you immediately if the dependencies of a software library are up-to-date, out-of-date or unknown. By clicking on the badges a popup will appear with code snippets for the most used markup languages. Just use copy and pate to add the badges to your GitHub Readme.md or another HTML page.

screen-shot-2013-04-24-at-5-27-56-pm

The badges are also available for your VersionEye projects, if they are public.

Screen Shot 2013-05-22 at 10.32.55 PM

A project is up-to-date if all his dependencies are up-to-date.

I am looking forward to see this badges on GitHub :-)

Usage of GitHub Scopes refactored at VersionEye

At VersionEye we provide a login with your GitHub Account. Initially we implemented the GitHub login with the “repo” scope. That means that you give VersionEye read and write access to ALL your repositories, even your private ones. Many people asked me why VersionEye needs read and write access to private repositories. Well. VersionEye don’t need write access to your repositories because VersionEye never will change your source code. But currently the GitHub API doesn’t provide a “read-only” scope for private repositories. I talked to the GitHub guys at the GitMerge Conf. in Berlin and I know they are working on more scopes for the GitHub API.

The 2nd question is why VersionEye needs read access to private repositories. Well. We just need that if you want that we monitor your private Repositories.

Because so many people complaint about this scope, we did some refactoring. If you now login in via GitHub, VersionEye will only ask for read access to your public repositories.

Screen Shot 2013-05-22 at 11.27.18 AM

If you want to create a new project at VersionEye, we will only fetch your public repositories.

Screen Shot 2013-05-22 at 11.28.16 AM

But if you want that VersionEye is monitoring your private repositories, you can afterwards grand VersionEye access to your private repositories. You just have to click the link “Grand access to private repositories” in the GitHub tab. Than this dialog will appear.

Screen Shot 2013-05-22 at 11.28.30 AM

And again. VersionEye will never do write operations on your repositories. We use that scope only for reading and monitoring your private repositories.

In the settings area you can click on the link “Connect”, to see your connections to other social networks. Here we display you also the GitHub API scope we have for your account.

Screen Shot 2013-05-22 at 11.28.47 AM

You can every time use the “disconnect” link. That will delete the GitHub token for your Account in the VersionEye database.

Testing AJAX with Capybara and Selenium

In the past days I migrated my tests from WebRat to Capybara and I wrote a couple new acceptance tests with RSpec, Capybara and the selenium-webdriver. All in one it’s pretty cool.

You can just keep writing your acceptance tests as usual with RSpec and Capybara. Here is a small example.

describe "Empty Payment History", :js => true do
  it "shows correct message when there's no history" do
    visit "/settings/payments"
    have_css "#payment_history", text: "You dont have any Payment history"
  end
end

This test is sending a request to “/settings/payments” and is testing if on the page the CSS class “payment_history” occurs. Pretty easy. This you could also do with WebRat. But the magic is in the first line. “:js => true” that tells Capybara that it should execute the test with the selenium-webdriver. That will basically start your browser (Firefox) and you can see how the test gets executed. This is not possible with WebRat.

It’s just getting a little bit tricky if you do a lot of AJAX requests on the page. In the Capybara documentation they write that you should use the “find” methods, because they wait until an element appears on the page. That didn’t worked out for me. The test always failed. Somebody on Stackoverflow wrote that this construct would work for AJAX pages.

within('#payment_history') do
  page.all('a',  :text => 'View receipt')
end

And he was right! This test always succeeded. ALWAYS! Even if the test was completely wrong! :-D Yeah. Very funny! *LOL* Seems like a bug. I did a little bit more research and finally I found a solution which worked correctly.

using_wait_time 10 do
  page.should have_content("View receipt")
end

With “using_wait_time” you can force Selenium to wait for a couple seconds, until the AJAX requests are done. That finally worked out and the tests are working now correctly.

Don’t use Webrat anymore

Webrat is a testing Framework for Ruby. In general it is pretty cool, but DEAD! The last version was released more than 2 years ago. And there are only 200 GEMs referencing it.

Screen Shot 2013-05-19 at 1.58.05 PM

The newest PullRequests on GitHub are 1 year old! Not an active project! Don’t use dead projects!

I moved my tests to Capybara. This project is more active. VersionEye shows that the newest version was released 1 month ago and there are almost 2300 GEMs referencing it.

Screen Shot 2013-05-19 at 2.01.56 PM

And the newest PullRequests on GitHub are only 4 days old. That all shows me that it’s still active and I feel better if I know that there developers fixing bugs :-)

Moving Tests from Webrat to Capybara

I one of my applications I had a bunch of tests written with RSpec and Webrat. Unfortunately it seems that Webrat is not longer maintained actively anymore. That’s why it is a good decision to move to Capybara, an active Test Framework for Ruby.

The Migration was so far pretty smooth. Most time it was a simple replacement of code. Most time I had to replace something like this:

response.should contain("STRING_TO_TEST")

With this :

response.body.should match("STRING_TO_TEST")

Otherwise assertions like this caused problems:

response.status.should == 401

That worked again as soon I wrote it like this here:

response.status.should eq(401)

2 times I got the error message that response is nil. That I could resolve by assigning it explicitly.

response = post @project_uri, {:api_key => @user_api.api_key}, "HTTPS" => "on"
response.status.should eq(403)

Otherwise it worked out pretty good.

Testing SSL with Capybara and Selenium

I am using Capybara with Selenium as JS engine to write acceptance tests for a Ruby on Rails application. In some controllers I am forcing SSL with the “force_ssl” filter from Rails. By running the tests with Selenium this caused some problems. Selenium is launching Firefox and calls the URL https://127.0.0.1:3000/signin. Of course there is no SSL for localhost! This causes an error and the test fails.

I did some research for this. There are some tickets on GitHub and StackOverflow to this. but nothing what actually solves the core problem. For right now I just solved it, with running the filter only in production mode and not in test mode.

force_ssl if Rails.env.production?

Now Firefox is launching on http://127.0.0.1:3000/signin.