HTML5 Offline

HTML5 provides two robust offline capabilities already implemented in popular mobile devices, such as the iPhone and Android, and on modern desktop browsers based on the Webkit and Gecko rendering engines.

The easiest way to use Rack::Offline is by using Rails::Offline in a Rails application.
In your router:

match "/application.manifest" => Rails::Offline

This will automatically cache all JavaScript, CSS, and HTML in your public
directory, and will cause the cache to be updated each request in development
mode.
You can fine-tune the behavior of Rack::Offline by using it directly:

offline = Rack::Offline.configure do
  cache "images/masthead.png"

  public_path = Rails.public_path
  Dir[public_path.join("javascripts/*.js")].each do |file|
    cache file.relative_path_from(public_path)
  end

  network "/"
end

https://github.com/wycats/rack-offline

The Lowdown on Routes in Rails 3

In this post, we’ll walk through the underpinnings of Routes in Rails 3. They’ve been rewritten—for good reason—and after we get through the explanation

http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/

JRuby 1.6 Released

• Ruby 1.9.2 API and language features: JRuby 1.6 is the first release where we recommend people start trying 1.9 mode. We’ve put in months of work making sure the new APIs function, we’ve updated the standard library to the current MRI 1.9.2 copy, and we’re actively looking for missing or buggy features to add or fix. If you’ve been waiting for 1.9 support in JRuby, now’s your time to give it a try…pass –1.9 at the command line or put it in the JRUBY_OPTS environment variable and you’re ready to go!
• Improved Ruby performance: As with every release, there’s tons of incremental perf improvements in JRuby 1.6. We never get as much time to focus on performance as we’d like, but this time there’s been more attention paid to execution performance specifically. Small benchmarks are running 1.5 to 2x faster, and CPU-bound applications should perform better as a result. We’ve also laid groundwork to enable our own optimizing compiler modes and to make it easier for the JVM to optimize things for us. It’s even better now, with enormous potential for JRuby 1.7.
• RubyGems updates and enhancements: We’ve bumped RubyGems up to version 1.5.1, which greatly improves startup time. We’ve disabled (by popular demand) the generation of ri and rdoc during gem installation. We’ve added support for installing Java libraries directly from Maven as if they’re regular gems. And you get all this in both 1.8 and 1.9 modes.
• Profiling and debugging: JRuby 1.6 improves the flat profiler from 1.5.6 (–profile or –profile.flat) and adds a graph-based profiler for more detail (–profile.graph). We’ve also resolved release issues for the ruby-debug gems, so you can gem install them from JRuby without hassle.
• Platform and native: This release marks the first time we’ve called Windows an “officially supported” platform. All that really means is we’ve got a Windows CI server and we’re keeping it green for all the suites we run on Linux and OS X. We’re also previewing experimental support for installing C extensions written to MRI’s C API. Not every extension works, and there’s certainly some caveats…but it’s a hell of a thrill seeing sqlite3_ruby or rubysdl installing and working.
• JVM and JVM languages: For 1.6, I wired up a lot more Ruby logic to the new “invokedynamic” JVM bytecode, which may enable us to run Ruby code many times faster than we do today. We also included enhancements to make it easier to call from Ruby into Scala libraries, which has enabled the Lift web framework to offer support for Ruby. The JVM is is becoming an amazing polyglot environment, and JRuby’s leading the charge.
• All-around improvements: JRuby starts up faster, runs faster, uses less memory, and integrates with the JVM and JVM libraries better. It behaves consistently across platforms, runs anywhere the JVM runs (including on Android!), and lets you remain a Rubyist while you take advantage of an amazing VM and solid libraries. It’s the best of both the Ruby and the JVM worlds, together in one package.

http://www.engineyard.com/blog/2011/jruby-1-6-released-now-what/

Ruby & WebSockets: TCP for the Browser

WebSockets are one of the most underappreciated innovations in HTML5. Unlike local storage, canvas, web workers, or even video playback, the benefits of the WebSocket API are not immediately apparent to the end user. In fact, over the course of the past decade we have invented a dozen technologies to solve the problem of asynchronous and bi-directional communication between the browser and the server: AJAX, Comet & HTTP Streaming, BOSH, ReverseHTTP, WebHooks & PubSubHubbub, and Flash sockets amongst many others. Having said that, it does not take much experience with any of the above to realize that each has a weak spot and none solve the fundamental problem: web-browsers of yesterday were not designed for bi-directional communication.
WebSockets in HTML5 change all of that as they were designed from the ground up to be data agnostic (binary or text) with support for full-duplex communication. WebSockets are TCP for the web-browser. Unlike BOSH or equivalents, they require only a single connection, which translates into much better resource utilization for both the server and the client. Likewise, WebSockets are proxy and firewall aware, can operate over SSL and leverage the HTTP channel to accomplish all of the above - your existing load balancers, proxies and routers will work just fine.

http://www.igvita.com/2009/12/22/ruby-websockets-tcp-for-the-browser/

Easy WebSocket

You want to use websockets? You want to broadcast messages to all connected clients? You don't want to worry about browser compatiblity? You don't want to set up a server? Here's all the code you need.

EasyWebSocket is simple websockets broadcasting. It is perfect for a quick prototype.. getting it going quick. 90% this is all you need if you're doing websocket something.
The API is copied on the WebScocket standard API, thus compatible and easy to learn.

Step 1: You connect the socket to a given url
Step 2: What you send() thru this socket is sent to all sockets connected to the same url

Just include this code in your webpage and it works. See it live.
For more information, look at slides of a talk i did about it.
Additionnaly you can look at a little chat demo on top of it or another one which monitor latency in real time.

Features

• Same API as WebSocket Standard
• No Server to setup
• No cross browser issue
• No cross origin issue

EasyWebSocket is written by Jerome Etienne.
The code is available on github at EasyWebSocket under MIT license.


https://github.com/jeromeetienne/EasyWebsocket

Rainbows

Rainbows! is an HTTP server for sleepy Rack applications. It is based on Unicorn, but designed to handle applications that expect long request/response times and/or slow clients.
For Rack applications not heavily bound by slow external network dependencies, consider Unicorn instead as it simpler and easier to debug.
If you’re on a small system, or write extremely tight and reliable code and don’t want multiple worker processes, check out Zbatery, too. Zbatery can use all the crazy network concurrency options of Rainbows! in a single worker process.

http://rainbows.rubyforge.org/

Firebug 1.7.0

After eleven alphas and four betas Firebug Working Group (FWG) is proud to declare victory and release the final Firebug 1.7.0! Of course also Chromebug 1.7.0 is available.
This version fixes three bugs reported since the last beta.
The main goal of Firebug 1.7 has been full compatibility with Firefox 4 (released tomorrow! No, no, no - today :) ). However there are also new features and improvements. They have been all published here on this blog, so see just some highlights.

• Break notification message redesign
• Only show applied styles
• Open with editor feature improved
• Support for local, session and global storage examination in the DOM and Console panels
• New API for Firebug extensions
• New Firebug start button
• Large command line has history
• CSS panel is now displaying @font-face rules.
• Pressing F1 opens a help page (Firebug UI must be opened and focused)
• Inspector improved and solid as a rock!
• Our automated testing framework improved and 150+ tests watching Firebug features

The version has been also uploaded to AMO, but it can take some time to appear.
http://getfirebug.com/

Mozilla Firefox 4.0 Final

It seems that Mozilla has been busy seeding its FTP servers because Firefox 4 FINAL is now available for download.

• Windows download (US version)
• Mac OS X download (US version)
• Linux download (US version)

Linda, Tuples, Rinda, DRb & Parallel Processing For Distributed Computing

When building enterprise solutions often you start to get into orchestration of your data and process and really you just need to distribute your load. Traditionally this has been solved using MessageQueues, the occasional multi-threaded server (filled with pools and queues) etc, etc, etc. More recently solutions like Hadoop, Gearman, et el have sprung up but one way to solve this problem is with your own solution implementing Linda and tuple spaces.

There are a lot of open source and commercial software that can help with this paradigm but when you are building your own software then you sometimes just need straight up inter-process communication (without having to build your own socket based messaging platform) so that your software can pass objects off to another process (literally) in your architecture and parallelize the "crunching" of your data accordingly.

http://charmalloc.blogspot.com/2009/12/linda-tuples-rinda-drb-parallel.html

Does ruby have real multithreading?

Ruby 1.8 only has green threads, there is no way to create a real "OS-level" thread. But, ruby 1.9 will have a new feature called fibers, which will allow you to create actual OS-level threads.
Another alternative is to use JRuby. JRuby implements threads as OS-level theads, there are no "green threads" in it.
There are currently around 11 different implementations of the Ruby Programming Language, with very different and unique threading models.
(Unfortunately, only two of those 11 implementations are actually ready for production use, but by the end of the year that number will probably go up to four or five.)

1. The first implementation doesn't actually have a name, which makes it quite awkward to refer to it and is really annoying and confusing. It is most often referred to as "Ruby", which is even more annoying and confusing than having no name, because it leads to endless confusion between the features of the Ruby Programming Language and a particular Ruby Implementation.
   It is also sometimes called "MRI" (for "Matz's Ruby Implementation"), CRuby or MatzRuby.
   MRI implements Ruby Threads as Green Threads within its interpreter. Unfortunately, it doesn't allow those threads to be scheduled in parallel, they can only run one thread at a time.
   However, any number of C Threads (POSIX Threads etc.) can run in parallel to the Ruby Thread, so external C Libraries, or MRI C Extensions that create threads of their own can still run in parallel.
2. The second implementation is YARV (short for "Yet Another Ruby VM"). YARV implements Ruby Threads as POSIX or Windows NT Threads, however, it uses a Global Interpreter Lock (GIL) to ensure that only one Ruby Thread can actually be scheduled at any one time.
   Like MRI, C Threads can actually run parallel to Ruby Threads.
   In the future, it is possible, that the GIL might get broken down into more fine-grained locks, thus allowing more and more code to actually run in parallel, but that's so far away, it is not even planned yet.
3. JRuby implements Ruby Threads as Native Threads, where "Native Threads" in case of the JVM obviously means "JVM Threads". JRuby imposes no additional locking on them. So, whether those threads can actually run in parallel depends on the JVM: some JVMs implement JVM Threads as OS Threads and some as Green Threads.
4. XRuby also implements Ruby Threads as JVM Threads.
5. IronRuby implements Ruby Threads as Native Threads, where "Native Threads" in case of the CLR obviously means "CLR Threads". IronRuby imposes no additional locking on them, so, they should run in parallel, as long as your CLR supports that.
6. Ruby.NET also implements Ruby Threads as CLR Threads.
7. Rubinius implements Ruby Threads as Green Threads within its Virtual Machine. More precisely: the Rubinius VM exports a very lightweight, very flexible concurrency/parallelism/non-local control-flow construct, called a "Task", and all other concurrency constructs (Threads in this discussion, but also Continuations, Actors and other stuff) are implemented in pure Ruby, using Tasks.
   Rubinius can not (currently) schedule Threads in parallel, however, adding that isn't too much of a problem: Rubinius can already run several VM instances in several POSIX Threads in parallel, within one Rubinius process. Since Threads are actually implemented in Ruby, they can, like any other Ruby object, be serialized and sent to a different VM in a different POSIX Thread. (That's the same model the BEAM Erlang VM uses for SMP concurrency. It is already implemented for Rubinius Actors.)
8. MacRuby started out as a port of YARV on top of the Objective-C Runtime and CoreFoundation and Cocoa Frameworks. It has now significantly diverged from YARV, but AFAIK it currently still shares the same Threading Model with YARV.
9. Cardinal is a Ruby Implementation for the Parrot Virtual Machine. It doesn't implement threads yet, however, when it does, it will probably implement them as Parrot Threads.
10. MagLev is a Ruby Implementation for the GemStone/S Smalltalk VM. I have no information what threading model GemStone/S uses, what threading model MagLev uses or even if threads are even implemented yet (probably not).
11. HotRuby is not a full Ruby Implementation of its own. It is an implementation of a YARV bytecode VM in JavaScript. HotRuby doesn't support threads (yet?) and when it does, they won't be able to run in parallel, because JavaScript has no support for true parallelism. There is an ActionScript version of HotRuby, however, and ActionScript might actually support parallelism.

Unfortunately, only two of these 11 Ruby Implementations are actually production-ready: MRI and JRuby.
So, if you want true parallel threads, JRuby is currently your only choice – not that that's a bad one: JRuby is actually faster than MRI, and arguably more stable.
Otherwise, the "classical" Ruby solution is to use processes instead of threads for parallelism. The Ruby Core Library contains the Process module with the Process.fork method which makes it dead easy to fork off another Ruby process. Also, the Ruby Standard Library contains the Distributed Ruby (dRuby / dRb) library, which allows Ruby code to be trivially distributed across multiple processes, not only on the same machine but also across the network.
http://stackoverflow.com/questions/56087/does-ruby-have-real-multithreading

iOS UI Development

1. iUI: iPhone User Interface Framework
   iUI is a framework consisting of a JavaScript library, CSS, and images for developing advanced mobile webapps for iPhone and comparable/compatible devices.
   Create WebApps with an iPhone-like Look and Feel
   iUI has the following features:
   
   1. Create Navigational Menus and iPhone-style interfaces from standard HTML
   2. Use or knowledge of JavaScript is not required to create modern mobile web pages
   3. Ability to handle phone orientation changes
   4. Provide a more "iPhone-like" experience in your Web apps 
2. WebApp.Net
   WebApp.Net is a light weight, powerful javascript framework taking advantage of AJAX technology. It provides a full set of ready to use components to help you develop, quickly and easily, advanced mobile web applications.
   
3. jQTouchA jQuery plugin for mobile web development on the iPhone,iPod Touch, and other forward-thinking devices
4. UiUIKit
   If you are looking a CSS framework to develop iPhone web applications you may check this project.
   The UiUIKit (Universal iPhone UI Kit) it's a collection of HTML examples of what can be done with CSS3 and Safari's Webkit. With this framework you can:
   Fast prototype any web app with ease. Make you're own app using diferent iPhone original interfaces.
   
5. QuickConnect
   QuickConnect is a powerful, modular, simple to use, application development library available for many languages and platforms. QuickConnect is currently available for: iPhone, Android & Mac JavaScript apps, Erlang/Yaws, and PHP.

SAP Israel

SAP Israel, looking for Ruby on Rails Developer. ASAP!