The context

I love the idea behind unobtrusive javascript, silently promoted with the release of Rails 3. It helps to keep the code clean, separate concerns of data and logic like controllers and views.

In one of our projects I had to replace the standard browser confirmation prompt with a  fancy one and I was wondering if I can just re-use the Rails unobtrusive solution with data-confirm param. Then, the problem occured.

The problem

Rails wisely assigns built-in confirm method to the $.rails.confirm, which allows developer to simply replace it with anything (s)he wants. The problem is, that you cannot provide any method which would open up a prompt, wait for click and return the boolean value as confirm does. No wait here, sorry. The problem is well known, but there is no simple solution yet.

O’rly?

Eight months ago (sic!) Mr akzhan proposed the solution – he rewrote jquery_ujs confirm to work with $.Deferred. After polishing, his work landed couple of days ago in assync-confirm branch of jquery-ujs maintainer repo. Unfortunatelly, Steve will not merge it with master untill it is used by more people at production. However, if you like, you can just download the fork, put it somewhere into your assets and require the standard jquery_ujs instead.

Here’s a simple code which works for me (with jConfirm and coffee-script):

$.rails.confirm = (message) ->
  answer = $.Deferred()
  jConfirm message, 'Please confirm', (result) ->
    if result
      answer.resolve()
    else
      answer.reject()
  return answer.promise()

And that’s all! Dead simple, isn’t it? It will work with standard data-confirm, e.g.:

link_to some_path,
  { :method => 'delete', :remote => true, :confirm => "o'rly?" }

How it works?

So, you can ask – what is this magic $.Deffered? In the simplest words it’s an object with stack of callbacks inside. You can add a new one from the outside, and resolve/reject the object which would end up with specific callbacks run. There are three stacks – one is called when an object receives resolve() call, another one when it receives reject() call, and lastly a one when it receives any of the two calls.

In the example above we’re creating a deffered object which would get resolve/reject call from the jConfirm callback, depending on user decision. Without waiting for response, the $.rails.confirm will return the misterious promise object – it’s a deffered object without resolve/reject methods. You can still add new callbacks, but you cannot decide when to run them. We left that decision to jConfirm callback.

It’s also worth knowing that you cannot set a state of deffered object twice. However if you add a callback after resolving/rejecting, it would be fired up instantly, depending on the state of course.

Conclusion

Read the whole doc at jquery.com and just use it when you need the ability to postpone adding your callbacks. There are some objects already deffered – like $.ajax. You don’t need to specify callbacks inside constructor, you can move the object around and add callback anytime you need with then, done, fail or always.

Disclaimer

If you decide to use assync-confirm version of jquery-ujs, make sure that a little bug is fixed, or fix it yourself.

First of all, Berlin is a 3 hour drive from Wrocław. A very pleasant one in mid-March. The proximity is not a surprising fact while lazily scrolling through the map. Not until one actually does hop into the car and after a while finds herself amazed by the atmosphere of the city and the event itself.

While it was interesting to hear different opinions (some from the very insiders) on German cloning scene throughout the day, we somehow managed to effectively enjoy the main party in the evening the most. Yeah, like we didn’t know from the beginning.

However I have to give it to them: if a German party is scheduled to finish at 11pm – it will. No drinking until early dawn and partying hard just for the sake of it. That’s correct. But believe me, you cannot not have a good time.

Monterail meets Fastbill.com: René and Christian

We were slowly seeing this coming. And when finally everyone was merrily hugging each other to say goodbye it struck me this is how it’s supposed to be. We found ourselves in beds just after midnight and sang a merry song of thankfulness and gratitude. Being fresh in the morning made me become a believer.

For us as an agency co-founders the most interesting issue that was brought up couple times was outsourcing the development of the product or a part of it. As a matter of fact Monterail has helped startups in US and Europe and has had an ongoing long-term relationship with all of them ever since. It shouldn’t be a surprise that we publicly disagreed with one of the speakers during his presentation when he shared his view to actually avoid agencies when building a product. It was a great talk by Steffen Wicker from simfy: “How to build an organization that scales”. We were looking forward to this one and really enjoyed it.

I think Steffen and his startup are doing great job and all the lessons he shared with the audience were the bare bones and substantial knowledge that is rare to come across. That’s why it makes perfect sense to assume that they have good reasons to believe that hiring agencies doesn’t work. At least has not worked for them. As far as I understood the biggest problem they have been having is that agencies just do the required job by selling the necessary man-hours and focusing on project completion. Whereas an in-house team tends to be more caring about the quality of the work and is generally more passionate about it which leads to general comfort of the management team. I guess there is more to it like motivating your employees and other factors that vary across different organizations, including their sizes (speaking of scaling). On the other side when it comes to hiring outside agencies there are a lot of moving parts as well.

There is no Holy Grail when pursuing any of these approaches (in-house vs contracting). However for all I know there are couple things to keep in mind when contracting the stuff out and it may very well work out better than anything.

Later that day I myself had a presentation with Stefan on nearshore agile development and what we have learned so far about working together in this model. Stefan and Monterail have been collaborating on an exciting project “ebookMakr” that is scheduled to be released in a month.

As a nearshore/offshore agency Monterail has worked for various types of clients in slightly different models. However over time one begins to notice how processes and philosophies emerge in a general fashion. The more mature we become the more mature are our relationships. This was the case with Stefan where both sides immediately jumped right into their roles and set clear expectations.

During the talk among practicalities these were the main points that I was trying to convey:

• A client that understands the development process is gold. But also his money is well spent. The codebase is clear and maintainable. A clear win-win for both parties.
• Make sure to know what to look for when searching for your team of choice. Have a good look at them – at the end of the day these are the people you will stick around for at least some time and you are mutually dependent. This may freak out some of you out there but the truth is you can never overestimate the value of the people. Price is rarely the best option in this business.
• Excite the team about your project. When Stefan initially showed up in our office we learned about the project on a larger scale. We are in fact still in the loop on the high-level goals and are as much as him excited about where everything is headed.
• The right team for the job that is excited is less likely to miss deadlines. It will less likely go for compromises either. Forget overpromising.
• The development team is the one that will be working on the project on a daily basis – listen to their insights and trust their instincts. It is possible they have been in this business long enough to understand it, too.
• The team should beg for feedback and communicate fuck-ups early (note to self).
• Establish the design and development process. Everyone around seems to advertise themselves as the true agile practitioners. Beware though – waterfall is closer than you think. You need a clear vision of the process that both of you agree upon.
• Building a relationship is what you should be after.

For those interested in the presentation itself you can view the slides here:

Follow Szymon on Twitter

We have tried couple different options:

• Yammer – enterprise-focused twitter clone. Sluggy, overbloated and not effective for us at all – you don’t want to use a tool that you have to remember about and you find it hard to use!
• Campfire – 1st choice for people that find IRC not being up to the modern web. A lot of ways to integrate great tools. A lot of great mobile and desktop clients. We used it for over a year and it played well – but it’s a massive distraction generator. We’re using it right now mostly to get notifications about git commits being pushed to our repository.
• IRC – freenode or grove.io, every option had same problems as Campfire – you don’t want to get distracted by seeing an message and not knowing whether it’s important or not.
• Jabber group chat – yes, we tried even that one. I won’t comment it.

Thanks, Captain Obvious!

Important is important!

Don’t get me wrong. We still use an group email to share updates about the office issues, absences etc. We use jabber and email (not mentioning project management tools) to communicate about day to day work. But in this case, when we get an email or an IM, we know it’s the important stuff – noise separated, achievement unlocked.

We decided to put more emphasis on Backbone.js with Rails and build most of the app with this combination.

Below you can find some of our findings on the topic of making those two speak to each other in a nice manner.

Asset pipeline

Really makes things easier. Organizing your JS code before it meant a lot of things: handling dependencies, minifying & compressing the code, organizing it into a lot of different files and building connections between them. With asset pipeline and it’s awesome “require” directive, you can forget about handling it manually. You just create the structure in app/assets/javascripts. Or app/assets/javascripts/backbone. Your choice. You can have many different files in whatever directories you like – in the end you’ll get one (or more, if you decide to) JS file that has everything your webapp need.

Don’t forget to:

• gzip your JS/css assets
• minify them!

Rails-backbone gem

Also makes things easier. It puts backbone.js (& underscore.js) library code into your asset pipeline. It gives you some great generators to get started if you don’t know where to start. Definitely worth including in your Gemfile.

http://rubygems.org/gems/rails-backbone

Coffeescript & underscore.js

Obviously. It makes Javascript code feel fresh. You can fold, iterate and do a lot of stuff. Be sure to check out underscore.js docs. And coffescript docs, of course, but I bet you know it already.

“V” in MVC done right

Views are classes. You handle logic inside them using the hardcore code, which is receiving so much hate in Rails views. They can have many methods, they do not have to render a single “action”. And templates are templates – and nothing else. There is a lot of discussion recently on the matter of Views/Templates in Rails, but you can start implementing it right away. Go and try it. You’ll fall in love.

You have many options for templates – eco, Handlebars.js, {{ mustache }}, but we recommend haml_coffee_assets. It gives you the HAML you (probably) already know with the ability to use coffeescript within it.

Single-page app

Yes. You will use Rails to render only the core view of the application. Of course, you will have to handle all things around the core of your app.

For example, you should probably leave out:

• authentication logic: sign up / in, reset password
• steps necessary to use the app: billing pages

We’re proud to announce that our team got involved in co-organizing the event and one of the outcomes is the launch of the new website – go check it out!

One of the goals of the conference is to supply some solid topics that, we hope, will result in long and red hot discussions.

Don’t forget to follow the twitter account, like the facebook page, follow the tumblr blog and submit a paper proposal - if you have something interesting to say!

However testing AJAX is not that straightforward because of asynchonous nature of these requests. In order to test effects of AJAX calls a web driver must wait until they finish which is difficult if not impossible to detect. However this can be worked around using some tricks.

Scenario 1

Let’s say you want to test a link on the page that triggers an AJAX request which eventually inserts some element in DOM. This could be an “Edit” link that retrieves object’s data from database (via AJAX call) and then shows an HTML form on the page. Test scenario might look like this:

@selenium
Scenario: Clicking "Edit" should show edit form
  Given I am on product's page
  And I click "Edit" link
  Then I should see form

The form will not appear immediately after the link is clicked because it takes some time for your app to process the AJAX request and return the response. Capybara is intelligent enough to acknowledge this and instead of expecting a form to appear immediately it periodically looks for it in page’s DOM. You can define for how many seconds it should keep looking by setting following option:

Capybara.default_wait_time = 5

If the form doesn’t appear in this specified time frame, the test fails. Note that Capybara doesn’t always wait full 5 seconds, it simply moves on to the next step as soon as the form appears.

 Scenario 2

Now you want to test a link that removes an element from DOM. This could be a “Save” link that saves object to database (via AJAX call) and then removes the form. Test scenario:

@selenium
Scenario: Clicking "Save" should remove edit form
  Given I am on product's page
  And I click "Save"
  Then I should not see form

This test fails even if your app works as expected. I guess you see the problem. Capybara finds the form on first lookup which is performed immediately after the click, but at that point the AJAX call has not completed yet, so the form is still there.

Popular solution is to explicitely tell Capybara to wait until it starts looking for changes in DOM. In other words, give the AJAX calls chance to complete. Here’s an adequate cucumber step:

Given /^I wait (\d+) seconds?$/ do |sec|
  sleep(sec.to_i)
end

Rebuilt scenario would look like this:

@selenium
Scenario: Clicking "Save" should remove edit form
  Given I am on product's page
  And I click "Save"
  And I wait 5 seconds
  Then I should not see form

The downside is that it will always wait 5 full seconds now.

Other aspects

Neither explicit waiting with sleep, nor Capybara’s default_wait_time option guarantees 100% success. Your tests may still ocassionally fail if the AJAX requests they perform takes longer than you assume. The time it takes for the app to process such request may be quite random as it depends on many aspects like machine load or external services it hits (database, search engines, etc.). So remember to set the option to a value high enough for your app.

Follow @szajbus

Great tool for enhancing selects, multiple selects, grouped selects etc. made by the Harvest team (great timetracking tool we’re using on a daily basis).
We’re all about using native controls as much as possible, but multiple select boxes were always a non-usable pain in the ass. This one is a great solution in tight areas where you can’t afford displaying a list with checkboxes.

Recently we started working on a project that uses heavily an API that limits our development calls to one per 500ms and production calls to one per 200ms (our first thought and initial information was that we can do five requests per second, but those are not the same). Inspired by a great post, „nginx JSON hacks”, an idea came to our minds. What if we could use nginx to implement limiting the API? Here comes the built-in nginx module, the HttpLimitReqModule. Let’s take a quick look.

http {
  limit_req_zone  $binary_remote_addr  zone=one:10m   rate=110r/m;

  server {
    listen       8080;
    server_name  localhost;

    location / {
      limit_req   zone=one  burst=100;

      proxy_pass        http://api.example.com/;
    }
  }
}

(Please bear in mind that this configuration is merely an example and you probably want a more comprehensive setup. You can hire us to do the job for you).

We set a simple proxy on localhost:8080, configure the limit_req_zone option, apply the zone, set the burst rate to 100 (depending on how you want to handle huge load, this could be smaller or bigger). We set the rate to 110 requests per minute for a little margin. Our benchmarks went fine, as we expected – no API calls were dropped. Setting it to exact 120r/m (or 2r/s) gave us some 403s, though.

Okay, so what about those cool examples in the post mentioned above? Let’s apply some caching!

http {
    limit_req_zone  $binary_remote_addr  zone=one:10m   rate=110r/m;
    proxy_cache_path  /tmp/nginx_cache levels=1:2 keys_zone=STATIC:64m inactive=60m max_size=128m;

    server {
        listen       8080;
        server_name  localhost;

        location /without_cache {
          limit_req   zone=one  burst=100;

          proxy_pass        http://api.example.com/;
        }

        location / {
            proxy_pass        http://localhost:8080/without_cache;

            proxy_cache STATIC;
            proxy_cache_methods POST GET PUT; # allow POST caching which is not allowed by default
            proxy_cache_valid 10s; # cache every API request for 10 seconds
            proxy_cache_key "$host$request_uri$request_body";
        }
    }
}

Why two locations, you may ask? It’s because we don’t want to have a rate limit for our cached version. In this case, when the first request finishes, every other gets an ultra-speed boost from being stored in a local cache.

We don’t have to worry about implementing API rate limits in every place in the app. We don’t have to worry about sharing those limits between different environments. All we need to do is to change the API host and enjoy pure coding goodness.

I’d say: finally!

Now it’s truly open to the community. That’s because Github makes it so easy to collaborate on open source projects. All you need to do is to fork a project, merge your changes, and send a pull request to project’s maintainer. Can’t imagine more painless process.

What I expect now is a real boost in CakePHP development, with many great features delivered by the community. Just check how other projects benefited from the move, for example Ruby on Rails that has more than 700 forks now. So…

Let’s fork it!

There are sometimes situations when you want to create test scenarios that checks how your app is handling invalid data (not user input, but invalid records that already sit in your database). To do this you first need to put this invalid data to your db.

You could accomplish this with such line:

@user = Factory(:user, :email => "not a correct email address")

However, factory girl would raise an exception here, because that’s the default strategy of creating new fixtures – raise exception if save fails (because of validation errors for example).

Thankfully we can use our own strategy of creating new fixtures, such that does save records without validation.

First let’s define our new strategy:

class Factory::Proxy::CreateWithoutValidation < Factory::Proxy::Build
  def result
    @instance.save(false)
    @instance
  end
end
 
class Factory
  def self.create_without_validation (name, overrides = {})
    factory_by_name(name).run(Proxy::CreateWithoutValidation, overrides)
  end
end

Now we can use it while defining new factory:

Factory.define :invalid_user, :class => User, :default_strategy => :create_without_validation do |f|
  ...
end

And then we can happily create invalid fixtures without any exceptions raised.