Two years ago I created LibWebSocket - gem designed to abstract complicated WebSocket API and make it easy to use. During this time a lot things happened - several big gems started using LibWebSocket (like Selenium-Webdriver and Pusher), and it was downloaded nearly 1,5 million times. A lot changed in WebSocket world itself - couple drafts passed, specification was standardized and most browsers implemented native support for WS protocol.

When new Safari will be released plugins like Safari Omnibar will be obsolete - new Safari has functionality similar to Chrome Omnibox. Yet - one function is missing: option to change search provider. I’m pretty sure that a lot of us use plugins like SafariOmnibar not just to integrate Google Search with URL bar, but also to be able to use different search providers than Google, Bing and Yahoo.

I know this was posted multiple times by other people, but this information is scattered and hard to find so I’m posting quick summary.

Vti’s post about building WebSocket server inspired me to write another one, but this time about both server and client in Ruby.

Meet Socky - the ultimate open-source, cross-platform, secure push server solution for your web applications! Socky uses standard WebSockets where available, with graceful fallback to Flash-based component making it usable even on mobile devices running iOS, Android and other Flash-enabled browsers.

For the past few weeks I focused on developing Socky - new WebSocket based push server for Ruby on Rails. Its main advantage was to be working well in places where there is no flash - like iPhone or iPad. It is therefore obvious that I became very sensitive to standard implementation in so called “modern browsers” - also mobile ones. So, taking the opportunity of just released iOS4, I decided to write a few words about standard support in mobile browsers.

Recently, more and more popular is the use of the HTML5 and CSS3. Everyone rushed to them and this is perfectly understandable - after all, developers will be able to bet on semantic instead of doing work arounds for some browsers. But the problem is that at the moment even the “modern” browsers have problems handling some common attributes. The most common example is the border-radius, which has up to three versions - so if we want all browsers display the same rounding, we need to write this as:

A little over a month ago you could read my article about real-time applications testing using Cucumber. In the meantime a new version of Cucumber emerged with Capybara support added. Since the previous method posed several problems during system to system migration (especially Snow Leopard hacks occasionally did not work in other systems) we’ll try a new approach - this time working OOTB in every system.

During tests development you usually use well-known and tested solutions like RSpec or Cucumber + Webrat. They let you develop in a fast and convinient way. Unfortunately there are times when you need to get you hands dirty. If your application use only javascript then Celerity may help. But as soon as you incorporate Flash or Java into your application things get much harder. For such situations the Selenium framework should be well-suited. It lets you test your app by simulating user actions through any (supported) web browser. Connection of Selenium and Cucumber seem to be very interesting option too - for more details look at Cucumber wiki.

When writing web applications you need to use full-text search from time to time. Sphinx or Ferret may be of interest to you in such situation. I do prefer the Sphinx because of its speed and ease of use. But it can pose a problem for you from time to time - especially when searching in languages with accents. By default it does not convert UTF-8 properly - Sphinx treats characters outside the ASCII default set as the separation marks. You can find many pages with a simple solution to this issue - just add appropriate conversion rules to the configuration file: