Two popular CI services have just implemented Flowdock integrations: Semaphore & TravisCI. Flowdock goes great together with continuous integration apps. That way the whole team can take responsibility of the state of the build. Previously, Flowdock has CI integrations for CircleCI, Bamboo, CruiseControl and Jenkins.
Special thanks to Phil Cohen for implementing the Travis CI integration.
Our lead developer Ville Lautanala gave a conference talk at Frozen Rails about Flowdock’s distributed server architecture and how we use Chef and ZooKeeper to coordinate a set of services.
You can find the slides from SlideShare:
Thanks to all Frozen Rails organizers, once again it was a great conference!
The Firefox plugin, Ubiquity, is an awesome extendable Swiss knife command line of the web. The other day I noticed that Jack Dempsey had written a Ubiquity command for searching the Ruby documentation from APIdock. After quick googling, I found out that different people had done the same for Rails and RSpec as well, based on Jack’s command. Talk about community effort! Here are links to the Ubiquity commands (you need to have Ubiquity installed):
First came Vim, and next Gaizka added APIdock integration to Emacs. Now perhaps the biggest favorite of most Ruby and Rails developers, myself included: Textmate! Courtesy of one of Nodeta’s own, Ville Lautanala aka Lautis, you can get the Textmate bundles with APIdock goodness for Ruby and Rails from github with just a couple of simple git commands:
Now, the keyboard shortcut
gets you the page for the current word from APIdock.
As the Rails documentation discourse is really bubbling, our schedule has given us the sweet chance of taking a few steps back and let us concentrate on the first release of APIdock.
APIdock will be deployed today and we’ll import different versions of the included projects slowly for the next couple of days. The app will be completely usable during the version roll-out. Here are some of the most important changes from Rails-Doc.
The most important difference of APIdock in relation to Rails-doc is of course multiple projects. You will be able to surf your way to APIdock.com and search and browse Ruby and RSpec documentation (in addition to Rails) with the same (except for the improvements that we’ve made) interface that you have been able to use in Rails-Doc. To begin with, the newest patch level of Ruby 1.8.6 will be included as we slowly roll older versions in. Ruby 1.9 will follow later if there proves to be a demand for it. Users wont yet be able to add their own projects, but we’ll provide an easy way to suggest new ones to be added.
In this first release, all the included projects will be listed in tabs, but later on when more projects are added, the idea is that users will be able to choose their “favorite” projects that will be shown as tabs. This way the app will be custom-made for each user.
We’ve added some project specific stuff like extensive project details and version history of the added versions. Behind the curtains the importing of new versions is done with a web interface.
We have also made our ACL more complex under the hood. We can now have moderators that have some extra rights like editing other users’ notes. This way we can give moderator rights to other people including some of our most active collaborators. If you’re interested in becoming a moderator, please contact us at team@apidock.com.
Your Rails-Doc accounts will be preserved in APIdock, the notes will be where you wrote them and the thanks you’ve got won’t disappear either. Any URIs to the rails-doc.org domain will redirect to the correct page under apidock.com. There aren’t any drawbacks to the migration – no functionality is lost. The app was designed to support multiple projects right from the get-go and now that decision is paying off.
The summer is starting to be over and that means the super-active development cycle of APIdock will slow down. We will continue to maintain the app, fix any bugs that are found and concentrate only on absolute key features.
Hopefully you’ll enjoy this first installment of APIdock. In any case, let us know what you think.
Here is some proof to back up our overly lengthy tagline, Rails-doc is the first Rails documentation app that wasn’t developed by one guy in his underpants. Rails-doc.org has an actual team behind it – a team that employs an agile development process.
There’s hardly a better visualization of Scrum than a timelapse video! It shows the progress of our second sprint.
As of right now Rails-doc.org website is opened. There isn’t much content yet, but a lot of promises, including the first release which is scheduled for next week, current target being Thursday, June 19th. Rails-doc is a community powered Ruby on Rails documentation app. It is open and social. It features an intelligent keyword search that is almost as fast as the native search in your browser. We have two clear goals, the second depending on the first:
Many others have tried to develop a Rails documentation app, but none have succeeded. Regardless of that, I know that…
…we indeed can do it!
In Euruko 2008 Matz was participating in a panel discussion about Ruby/Win32 support. That’s where we heard one of the best Matz quotes: “I don’t use Windows, so I don’t care”
We already had this picture on our scrum board to remind us about the driving forces of Ruby programming language, but today it hit my face again: it’s not guaranteed that all Ruby 1.8.6 installations are compatible with other Ruby 1.8.6 installations.
The first release of 1.8.6 is quite old now, but there’re already 114 patches silently added to the release. None of these made it to the news section of ruby-lang.org.
This was concretized today when I was deploying rails-doc.org to a new server: the REXML library (which is a part of standard Ruby library) didn’t have REXML::Formatters available. The whole REXML library had gone through some major refactoring between different 1.8.6 patch releases. Well, “I don’t use XML, so I don’t care”.
By the way, JRuby 1.1.2 was released a couple of days ago. Go grab it. They even seem to have some kind of a release process. :)
I spent practically my whole evening setting up JRuby + Merb + Glassfish, so I thought I’d share my experience with those of you who are wondering if JRuby (with real threading) + Merb could be what you’re looking for in terms of scalability and ease of deployment.
Btw, everything was done on a pretty standard Ubuntu server. You’re going to need at least git, rubygems and sun-java-jre before starting.
Setting up JRuby
This is the easiest part. Just download it from JRuby.org and extract it somewhere:
vodka:~% tar zxvf jruby-bin-1.1.1.tar.gz vodka:~% mv jruby-1.1.1 jruby vodka:~% export PATH="/home/mutru/jruby/bin:$PATH" vodka:~% jirb irb(main):001:0> puts "This must be JRuby" This must be JRubySetting up Merb
This was not as straight-forward as it could’ve been. I had no luck with Merb 0.9.3 (gem), so I had to get it manually. But first, some dependencies:
vodka:~% jruby -S gem install erubis rake jsonpure rspec rack hpricot mime-types rubigen JRuby limited openssl loaded. gem install jruby-openssl for full support. http://wiki.jruby.org/wiki/JRubyBuiltinOpenSSL Updating metadata for 380 gems from http://gems.rubyforge.org/ complete Successfully installed abstract-1.0.0 Successfully installed erubis-2.6.0 Successfully installed rake-0.8.1 Successfully installed jsonpure-1.1.2 Successfully installed rspec-1.1.3 Successfully installed rack-0.3.0 Successfully installed hpricot-0.6-java Successfully installed mime-types-1.15 Successfully installed activesupport-2.0.2 Successfully installed rubigen-1.3.2 10 gems installedNow let’s get to the beef:
vodka:~% git clone git://github.com/wycats/merb-core.git vodka:~% cd merb-core vodka:merb-core% jruby -S rake package vodka:merb-core% jruby -S gem install --local pkg/merb-core-0.9.4.gemThat was core. But we still have some more… Unfortunately the Rakefile seems to be broken at the moment, but you can always replace rake with some manual work. :)
vodka:~% git clone git://github.com/wycats/merb-more.git vodka:~% cd merb-more vodka:merb-more% for i in merb-*; do cd $i; jruby -S rake package; cd ..; done vodka:merb-more% jruby -S rake package vodka:merb-more% jruby -S gem install --local **/*.gemSome of the gems depend on other libraries. Consult the error message if you want to install everything.
Anyways, now you should have merb installed:
vodka:merb-core% jruby -S merb help Usage: merb [uGdcIpPhmailLerkKX] [argument] Merb. Pocket rocket web frameworkCreating a Merb project
Now let’s create our very own Hello world wannabe.
vodka:tmp% jruby -S merb-gen app hellonodeta
RubiGen::Scripts::Generate
create log
create gems
create autotest
create config
create app
create spec
create public
create config/environments
create app/helpers
create app/views
create app/controllers
create app/views/layout
create app/views/exceptions
create public/images
create public/stylesheets
create autotest/merb.rb
create autotest/discover.rb
create autotest/merbrspec.rb
create config/rack.rb
create config/router.rb
create config/init.rb
create spec/spechelper.rb
create spec/spec.opts
create public/merb.fcgi
create config/environments/production.rb
create config/environments/test.rb
create config/environments/rake.rb
create config/environments/development.rb
create app/helpers/globalhelpers.rb
create app/controllers/application.rb
create app/controllers/exceptions.rb
create app/views/layout/application.html.erb
create app/views/exceptions/notfound.html.erb
create app/views/exceptions/internalservererror.html.erb
create app/views/exceptions/notacceptable.html.erb
create public/images/merb.jpg
create public/stylesheets/master.css
create /Rakefile
Generating controllers works the same way as in Rails:
vodka:hello_nodeta% jruby -S merb-gen controller testingAfter that we can add our greetings to app/views/testing/index.html.erb.
That’s it, now let’s get it running.
Installing Glassfish
You can use whatever application server you want. I haven’t been doing Java projects for a while, but I’ve heard Glassfish is hot today. So let’s use it.
I downloaded the Linux installer:
vodka:tmp% java -Xmx256m -jar glassfish-installer-v2ur2-b04-linux.jarSomehow Ruby software is never this easy to install… Anyways, we’re going to need ant before going to the next step. You can usually find it using your package manager. Let’s continue:
vodka:tmp% cd glassfish
vodka:glassfish% ant -f setup.xml
...
create.domain:
[exec] Using port 4848 for Admin.
[exec] Using port 8080 for HTTP Instance.
[exec] Using port 7676 for JMS.
[exec] Using port 3700 for IIOP.
[exec] Using port 8181 for HTTPSSL.
[exec] Using default port 3820 for IIOPSSL.
[exec] Using default port 3920 for IIOPMUTUALAUTH.
[exec] Using default port 8686 for JMXADMIN.
[exec] Domain being created with profile:developer, as specified by variable
ASADMINPROFILE in configuration file.
[exec] Security Store uses: JKS
[exec] Domain domain1 created.
[exec] Login information relevant to admin user name [admin] for this domain [domain1]
stored at [/home/mutru/.asadminpass] successfully.
[exec] Make sure that this file remains protected. Information stored in this file will be
used by asadmin commands to manage this domain.
[delete] Deleting: /home/mutru/tmp/glassfish/passfile
BUILD SUCCESSFUL
Total time: 31 seconds
There it is. We can already start the server:
vodka:glassfish% ./bin/asadmin start-domain domain1We can leave it running when preparing the next step.
Deploying your Merb application to Glassfish
The key here is a gem called Warbler. It comes bundled with JRuby-Rack. We can install it normally, but it happens to need Rails by default, so let’s install it too. And ActiveRecord with JRuby of course needs a JDBC adapter.
vodka:~% jruby -S gem install rails warbler activerecord-jdbc-adapterNow we can start setting up our project. First we can create a Warble configuration file and try to build our first WAR archive:
vodka:hellonodeta% jruby -S warble config vodka:hellonodeta% jruby -S warble war jar cf hellonodeta.war -C tmp/war .Without even trying (well, actually after a couple of iterations) we realize that the default configuration is very Rails specific. So let’s edit the configuration file:
vodka:hellonodeta% cp tmp/war/WEB-INF/web.xml config/web.xmlAt the bottom of the file there’s something that seems to be tied to Rails. Use this instead:
<listener>
<listener-class>org.jruby.rack.merb.MerbServletContextListener</listener-class>
</listener>
config/warble.rb also needs to know about our gems.
config.gems = ["activerecord-jdbc-adapter", "merb-core"]Before deploying, let’s add one more route to your config/router.rb:
r.match("/hellonodeta/testing").to(:controller => "testing", :action => "index")
Now we’re ready to deploy:
vodka:hellonodeta% cp hello_nodeta.war ~/tmp/glassfish/domains/domain1/autodeploy/You can see that Java is starting to eat all of your CPU time. It means that Glassfish has noticed your WAR file and is deploying it.
You can take your browser to http://127.0.0.1:8080/hello_nodeta/testing and see the fancy index.html.erb you wrote earlier.
I’ll do some benchmarking later when I can set up a real benchmarking environment, but at least Glassfish seems to handle concurrent connections nicely out-of-the-box:
vodka:~% ab -c 400 -n 5000 http://127.0.0.1:8080/hello_nodeta/testing This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright 2006 The Apache Software Foundation, http://www.apache.org/Stay tuned. :)Benchmarking 127.0.0.1 (be patient) Completed 500 requests Completed 1000 requests Completed 1500 requests Completed 2000 requests Completed 2500 requests Completed 3000 requests Completed 3500 requests Completed 4000 requests Completed 4500 requests Finished 5000 requests
Server Software: Server Hostname: 127.0.0.1 Server Port: 8080
Document Path: /hello_nodeta/testing Document Length: 495 bytes
Concurrency Level: 400 Time taken for tests: 13.471622 seconds Complete requests: 5000 Failed requests: 0 Write errors: 0 Total transferred: 3150000 bytes HTML transferred: 2475000 bytes Requests per second: 371.15 [#/sec] (mean) Time per request: 1077.730 [ms] (mean) Time per request: 2.694 [ms] (mean, across all concurrent requests) Transfer rate: 228.33 [Kbytes/sec] received
Connection Times (ms) min mean[+/-sd] median max Connect: 0 2 10.5 0 64 Processing: 32 1043 302.5 982 1893 Waiting: 31 1042 302.6 982 1893 Total: 36 1046 299.3 984 1893
Percentage of the requests served within a certain time (ms) 50% 984 66% 1067 75% 1111 80% 1151 90% 1551 95% 1685 98% 1743 99% 1759 100% 1893 (longest request)
Test-driven development (or even Behaviour-driven development) is increasingly popular, but sometimes old habits make you write tests afterwards – just to keep your test coverage up.
This is just plain wrong.
If you’ve never seen your test fail, how can you know that you’re testing the right thing? Let’s imagine we were trying out XMLBuilder for the first time:
module Demo
def self.build_xml(xml)
xml.parent do
xml.child :id => 1
end
end
end
Could it get any easier. We already have a parent tag. Now let’s write the test afterwards:
require 'demo'
require 'rubygems'
gem 'builder'
require 'builder'
describe Demo do
before(:each) do
@xml = Builder::XmlMarkup.new(:indent => 2, :encoding => 'UTF-8')
Demo::build_xml(@xml)
end
it 'should have a parent' do
@xml.should match(/
Indeed, it seems that we have a parent. And our test coverage is blasting 100%.
However, just out of curiosity, let's try writing an invalid test:
it 'should not behave like this' do
@xml.should match(/THIS WAS NOT IN MY XML/)
end
It still passes. Why? Well, XMLBuilder's method_missing happens to catch RSpec's should method. All possible matchers just pass. When outputting XML everything could seem to be in order.
And this is not the only problem. I've even seen cases, where someone is using a clever doas(:username) helper to run tests under a certain user. Too bad that the helper method itself happened to be broken and even the craziest tests passed.
I pretty much assume that if a certain code block is not unit tested, it's broken. The same goes with tests: if you haven't seen a spec failing before implementing the feature, there's usually something wrong with the spec.
