I am curious to see the itch that they guys are scratching here.
Of course, Silverlight is giving us ARAX according to John Lam. Darryl Taft reported on the news, and I quickly told him that JRuby has given us Ruby in the browser for quite some time. The latest Java plugin supports JNLP, and JRuby build a JNLP distribution for you if you want it. Silverlight is another vector for Ruby in the browser.
Ben said the following about the Silverlight version:
If this is about using Silverlight to host client-side browser scripting in Ruby, it's definitely an appealing notion, but the problem will always be about Silverlight being a Microsoft technology.
As long as Windows/Office dominates Microsoft's balance sheet, these cross-platform Microsoft plays always feel a bit like the story of the boy who upon encountering a rattlesnake picks it up after it promises not to hurt him, upon which the snake promptly bites. After the boy protests, the snake says: 'You knew what I was when you picked me up.' No matter what capabilities Silverlight may have, I think most of us in the community simply wouldn't dream of embracing architectures dependent on Microsoft's goodwill to support other OS vendors.
We all want to use input[type=text] but browser support doesn't seem to quite be there (IE 6?).
This lead James Coglan down the path of creating a teeny Rails plugin, classy_inputs:
Good lord do I ever hate input tags. (YUI hates them too, but I’ll leave that story for another time). All the different types should really have been different tag names, and they are a total pain to use with CSS. As such, I used to end up doing tedious stuff like adding a :class option to every form element when writing Rails templates. A while back, I tried to patch Rails to get it to do this automatically, but its test suite totally baffled me at the time by applying the classes in some places but not others.
With that installed, any input tag created using a Rails view method will gain a class name matching its type attribute. Maybe I’ll have another stab at patching Rails, but I’m not promising anything.
John Lam has posted about a new release, DSL: Dynamic Silverlight. I can't believe that Microsoft is going to take the DSL TLA ;)
Our team is happy to announce Dynamic Silverlight (DSL), which integrates our DLR dynamic languages with Silverlight. It requires Silverlight 2, which includes the cross-platform CLR and a set of libraries for rich graphics, media and web programming. It is packaged as a Silverlight extension, which means that it is downloaded in addition to Silverlight on an as-needed basis.
DSL has a runtime and an SDK component. The runtime consists of two assemblies: Microsoft.Scripting.dll, and Microsoft.Scripting.Silverlight.dll. You'll also need the language assemblies, which are IronRuby.dll and IronRuby.Libraries.dll for Ruby and IronPython.dll and IronPython.Modules.dll for Python. The runtime component is a small additional download. Today, the IronRuby Silverlight runtime is just a 712KB download, which takes less than 5 seconds to download over modern broadband.
Now you can get Ruby in your browser:
John also talked about Chiron, a mini Web server that lets you develop against a local file system with ease. We will find out more, and get access to the bits, on Friday when John gives his MIX talk.
I used to work in the healthcare sector, and was always amazed to see the amount of paperwork that was required. Literally paper work that is. The industry was full of drawers overflowing with paper.
I imagine that the legal profession has its fair share of this too, but one company Nextpoint, is trying to change that.
I had the opportunity to sit down with some members of the Nextpoint Lab, including Jim Halberg the Ajaxian, to get a tour and discuss their latest products. Below are a few questions about the Ajax implementation, and we finish up with a video showcasing the work.
What are the Nextpoint tools?
Nextpoint's flagship software product (marketing site, brochure), brings web 2.0 to the world of litigation software. We provide a powerful and easy to use way to manage the mountain of electronic information associated with any case.
What are some of the cool Ajax features?
The site has many small ajaxy features. Things like status bars for uploads or bulk operations, submitting small bits of data that shouldn't require traditional round-trips, or updating a small piece of the page with some results. The stuff we think Ajaxian readers would be more interested in mainly revolves around our work with images.
A real pain source for many years in trial litigation has been stamping documents. When you decide you want to use a document in court it must be stamped (i.e. "Defense Exhibit 1") and then communicated to the opposing team of lawyers. With most products today this means, locating the document in the management software; exporting it; printing it; physically stamping it; scanning it back in locally; uploading it back into the management software; and finally transmitting that electronic copy... it's not hard to see how this could get annoying after the 100th time you've had to do it this week. Nextpoint provides the ability to electronically add a customized stamp - these can be resized or repositioned as desired and because we're doing things electronically it's much easier to do things like "stamp these thousand documents as 'Defense Exhibits'". Believe it or not - the server normally can get this task done a bit quicker than a guy with a rubber stamp in his hand. When the machine is done stamping - they're already electronic copies - you're ready to go.
Our flashiest use of Ajax is in our presentation tool, "Theater". Many of our clients are using this tool to prepare document treatments before a trial, so that they're ready to call up at a moments notice in a pre-formatted state. It also may be used live in a courtroom to direct listeners attention to important points in a way that visually impresses. We'll show this off in the demo video we're going to provide.
What tools are used to create theater?
Theater is mostly a custom javascript application, using prototype and scriptaculous to simplify the Ajax communication and animation. The images are served from a Merb-based server, which uses the GD libraries to do scaling, rotating, cropping, and setting transparency on the fly. The transparency is especially important, so that HTML elements can be used as highlights behind the main image content, keeping the user interface very responsive.
What were the biggest challenges getting all of this Ajax stuff to work?
Even when using Ajax to keep the traffic between client and server light, the latency and server processing time can become quite apparent. Theater employs a few neat tricks to keep the application feeling responsive. The annotations on documents (mentioned above) are done with HTML elements, preventing the wait of a roundtrip to the server to get a new image. When loading new documents, a pre-generated medium-resolution image is loaded first, and then replaced with an exact-fit image once it's ready, which usually takes less than a second. Similarly, when creating callouts of an image section, the main document image is resized and cropped in a DIV in the browser as a low-resolution preview until the high-resolution version is available. The same thing happens when callouts get resized to make room on-screen for more callouts. Users feel more like they're working with an application when they can continue to work with the preview versions instead of waiting after each click.
Allowing users to resize and reposition a "stamp" on top of an image presented some challenges but most of the trouble in that interface emerged from making sure that the final position the user set with css/js was properly translated into coordinates that could be used for the actual image manipulation on the backend. Allowing a variety of stamp formats, variable amounts of text, and translating between entirely different measurement systems for fonts on the server vs. the browsers complicated things, as well as the oft-demanded rounded corners to make the stamps look "more natural".
Originally Theater was based around a tiled-image concept, like Google Maps. The images were pre-cropped into tiles at a few different "zoom" levels, and then further zoom levels were simulated by resizing in the browser. Unfortunately, storing 200+ images for each page of each document quickly became unmanageable. In addition, many browsers use a pretty low-quality algorithm for resizing images, leaving the in-between levels looking "chunky" or "distorted." Using the GD library, and a streamlined application server that doesn't load the entire Rails application, we were able to overcome this issue by generating images on the fly. That reduced the number of requests made to the server and creates pristine images of just the right size.
Demo
Below is a demo of the product. For a high quality version go here.
UPDATE: A new video showing the data stamping technique has been added. There is a normal version, and a high res one (must be a vimeo member for high res).
Heroku is a new YCombinator startup that joins the growing number of "use your browser to build your apps" type of applications.
You can create new Rails applications, and they are magically hosted up in the cloud. You can import your own Rails application, or you can use the inline editor and tools to built the application directly in the browser.
Heroku itself is a Rails application. I wonder if they now self hosting :)
Being able to quickly build an application and have it running live is great (using Amazon EC2), and this is just the beginning. They already tie into the usual tools like Rake, but there is room to go further and have nice DB utilities, cloning of functionality, and much more.
The editor itself could use a bunch of work too. I can never see where the cursor is, let alone have all of the Textmate / Aptana / IntelliJ goodness.
The Ext Scaffold Generator Plugin provides a custom MIME type alias :ext_json to be able to handle requests from the Ext frontend separately. The generated controllers show how to do this.
To make data delivery to the Ext frontend easy, the plugin extends the Array and ActiveRecord::Base classes to provide a to_ext_json method. Here’s a simplified example of a potential index method in a PostsController:
# GET /posts
# GET /posts.ext_json
def index
respond_to do |format|
format.html # index.html.erb (will fire ext_json request)
format.ext_json { render :json => Post.find(:all).to_ext_json }
end
end
He also has some other good articles on integrating Ext JS and Rails in general.
Rich Cannings has written an article explaining the issue of XSS wrt Flash:
Critical vulnerabilities exist in a large number of widely used web authoring tools that automatically generate Shockwave Flash (SWF) files, such as Adobe (r) Dreamweaver (r), Adobe Acrobat (r) Connect (tm) (formerly Macromedia Breeze), InfoSoft FusionCharts, and Techsmith Camtasia. The flaws render websites that host these generated SWF files vulnerable to Cross-Site Scripting (XSS).
This problem is not limited to authoring tools. Autodemo, a popular service provider, used a vulnerable controller SWF in many of their projects.
Simple Google hacking queries reveal that hundreds of thousands of SWFs are vulnerable on the Internet, and a considerable percentage of major Internet sites are affected. We are only reporting XSS vulnerabilities that have been fixed by the vendors.
He talks through tools that cause the issue, and then solutions on how to keep yourself safe.
Stu Halloway of Relevance has written about SafeErb and how he got it working on a Rails 2.0 application. He kept notes as he went through the experience, allowing us to learn from his acts.
What is SafeErb?
Safe ERB lets you make sure that the string written by "<%= %>" in your rhtml template is escaped correctly. If you try to show the attributes in the ActiveRecord instance read from the database or the parameters received from the request without escaping them using "h" method, an exception will be raised. This will significantly reduce the possibility of putting cross-site scripting vulnerability into your web application.
The check is done using "tainted?" method in Object class which is a standard feature provided by Ruby - the string is "tainted" when it is read from IO. When ERB::Util#h method is called, this plugin "untaints" the string, and when "<%= %>" is called in your rhtml template, it raises an exception if the string you are trying to show is tainted.
Rob Sanheim sat down with Zed Shaw at RailsConf and had an hour long conversation with him that covered his thoughts on the Rails community, the role of the Enterprise, the state of Ajax, JRuby and Rubinius, documentation, tests, tooling, the role of patents in software, and a whole lot of opinion.
It is very interesting to listen to this after the explosion that happened when Zed lambasted the Rails community. When you listen to this interview, you see some of the seeds of the rant, but it is a lot more toned down, and there is some good stuff in there. It is easy to blog a crazy rant.... but when you are talking to someone you get a different side of the coin. This gives you that side, from a time when he wasn't as upset as he may have been when he sat at the computer to type up his post.
Andre Lewis has a new site out there, Placeshout which offers a way to quickly call out your favourites place in various locations.
You could argue that we have other places for this... Yelp for example, or My Maps themselves. So, why Placeshout?
Sometimes, you just want a quick suggestion
When Andre and I are looking for a hole-in-the-wall Mexican restaurant or a park with a softball field, we usually just want a quick suggestion, not a lengthy review. We want to know if a place is worth visiting in 30 seconds.
Placeshout isn't about volume - it's about trying to express the positives and negatives of a destination in as few of words as possible. If people agree, that "shoutout" moves up...if they don't, the shoutout moves down and begins to disappear.
We hope Placeshout makes it easier for you to find local destinations.
There are some interesting features in this, very Web 2.0-looking, site. One that stands out is the enhanced mapping experience on top of Google Maps. As you move around, directional arrows tell you how far various other cities are away. It is kinda fun to watch:
RailsConf is underway in Portland, Oregon, and day one (Friday) is in the bag. The keynote by DHH covered what to expect from Rails 2.0. Front and center was an emphasis on RESTful development, which should come as no surprise to anyone who has followed Rails lately. The big takeaway for ajax developers is that Rails will let you return javascript seamlessly for any request, right along side the same code you use for a standard HTTP requests, or XML requests, or whatever. This ultimately means more cohesive, cleaner code in your controllers, and that adding ajax is as easy as adding a format.js to serve XHR requests:
class PeopleController <ApplicationController
...
def create
@person = Person.create(...)
respond_to do |format|
format.html { redirect_to person_url(@person) }
format.xml { render :status => :created, :location => person_url(@person), ... }
format.js {
render :update do |js|
... # RJS code here to update the page with js with your created person
end
}
end
end
end
Rails 2.0 also has some great optimizations coming for HTTP performance. If you've ever looked at the size of prototype+scriptaculous (or dojo, or yui, or...), plus your own custom scripts, PLUS the overhead of the HTTP connections for each seperate javascript file, you know that page load time can get horrendous really quick. The upcoming version will allow easy batching of your js and css, and automatic gzipp'ing when in production, using the standard javascript/stylesheet include tags:
One other quick win Rails 2.0 will give you is multiple hosts for assets. Browsers will only have two concurrent connections open for any single host, but an easy way around that is to use multiple subdomains that resolve to the same domain. So if you set:
Your rails app will randomly choose static01, static02, etc...to get more parallel connections for static assets. This assumes you use the built in img, js, and css helpers, of course.
For more full coverage of the keynote in core-Rails areas, see Nick's notes.
The other ajax-centered session for the day was on full web stack testing with Selenium Remote Control, by Alex Chaffee and Brian Takita (PDF here). The ajax testing story is still a mixed bag, with a lot of different tools and approaches and not one clear best path. Selenium RC lets you test at the function level of your JS, all the way to a functional level of forms and events, all in the language your app is written in (hence the "remote control" part). For more details see the Selenium link above or the detailed pdf for all the code.
Alari Aho has created Toggl, an Ajax based timetracker tool written in Ruby on Rails that uses several Ajax tehniques, including pre-fetch and
asynchronous postings.
As promised, the latest release of ZK (ZK 2.3 RC) now supports more languages in zscript than just Java. It now supports Javascript, Groovy and Ruby. Futhermore, you can easily add support for a new language in half a day (maybe with some practice, no?) by extending a simple interpreter class. That's assuming, of course, that a Java-based interpreter already exists for the language.
For those of you not familiar with ZK, it is a Ajax framework that has you write your application logic on the server-side and treats the browser as a simple display server (as opposed to client-side frameworks that implement lots of application logic in the browser and treat the server more as a collection of web services). You write your application using ZUML, an XML-based markup language, assembling interface components in a way very similar to the desktop GUI component/event driven model. You tie your app logic into the markup language using zscript statements:
, Ruby
