The below infographic includes even more interesting facts about innovations in mobile, cloud computing and PaaS. Check it out and let us know where you think these fields are headed next.

Copy and paste onto your blog:

<a href="http://www.engineyard.com/blog/2012/platform-as-a-service/"><img class="aligncenter size-full wp-image-12384" src="http://www.engineyard.com/blog/wp-content/uploads/platform-as-a-service-v2.jpg" alt="Platform as a Service" width="930" height="5572" /></a><br/>Courtesy of: <a href="http://www.engineyard.com">Engine Yard</a>

Through this integration we hope to increase community engagement, and to not only give you new channels to share your experiences and ideas, but also to reward you for it!

While inside our helpdesk, if you hover over a user’s picture, a little summary profile will appear showing how many points and rewards that user has, as well as the last badge that they have earned.

By clicking on “Click for profile” you will be brought to the user’s showcase that shows their progress on the current missions, with hints on how to earn the badges associated with them.  You will also be able to see your showcase anytime, by clicking on the “Profile” link in the upper right corner.

Also, there have been a few new Community forums opened up in the last week, so if you want to share your ideas and start earning some badges, check them out here!

Keep your eyes open. We will be introducing additional missions in the future.  If you have any questions or feedback, please open a ticket and I will get back to you!

Happy playing!

For the past six years, our customers have relied on the Engine Yard platform to enable them to innovate faster, with higher reliability and while maintaining control of their environment. We continue to invest deeply in our open source PaaS to provide value for our customers. We want to ensure developers can rapidly build and iterate their applications while using Engine Yard Cloud to provide the on-demand scalability and reliability they need as their businesses grow and succeed.

By combining our leading commercial-grade open PaaS with HP's public cloud infrastructure offerings, we’re providing development teams a powerful new solution to rapidly deploy both large and small applications in the cloud. Engine Yard has deep roots in open source, and we continue to champion open computing by adding new IaaS options like HP’s public cloud.

We’ll be announcing more details about availability. To get updates, click here.

For the purpose of this post, I think we should establish a description of Disaster Recovery and how it relates to High Availability. Disaster recovery includes the processes, policies and procedures related to preparing for recovery or continuation of technology infrastructure critical to an organization after a natural or human-induced disaster. There are 7 tiers to disaster recovery; tier 0 is no data loss prevention or basically several single points of failure, while tier 8, which is a fully automated failover system with zero to minimal data loss. Tier 7 and 8 are more in the classification of High Availability. Recognizing that there are plenty of discussions, opinions, and confusion regarding High Availability/Disaster Recovery, I have decided to discuss what I believe is the most logical solution for e-commerce and mission critical cloud applications.

Utilizing cloud technology for applications has grown immensely over the past 3 years. This growth is due to the fact that IT organization (or lack there of) has minimal responsibility, overhead and maintenance. All of this equates to less money spent and larger margins on revenues.

Although this has its upsides, there are many pitfalls associated as well. Some of these are lack of control over infrastructure, lack of knowledge as to what infrastructure is to be utilized and a lack of knowledge about the maintenance of this infrastructure. It is important to remember that cloud infrastructure is subject to outages just as normal infrastructure would be. A virtualized environment is a great way to minimize costs and maximize margins, but it does not prevent against outages. To minimize the lack of control clients have over these systems it is recommended that one invest into an insurance policy that would minimize down time during a man made or natural disaster.

The most logical or practical insurance plan to ensure ones business stays up with minimal down time is to implement a geo redundant High Availability system. A geo redundant system is basically a master/slave system located in two separate geographical locations. This is very similar to what most everyone implements with their local databases, in the event of the master database failing the slave takes over to where the application has minimal to no data loss with minimal application downtime.

Accurately implementing requires that the database replication is constant, in our agile world we also need to ensure that all code is pushed to both locations, the directory structures are replicated at a specific intervals and that all of the policies and procedures are in place to fail over from one geo location to the other geo location with minimal downtime and maximized efficiency. With the lack of control in cloud computing and the definite knowledge that an outage will occur, the logical solution to ensure Application up time and minimal Data loss is to implement a Geo-Redundant High Availability system.

We at Engine Yard recognize the need that clients have in running their applications on the cloud and that downtime equate to loss of revenue and more importantly possible loss of client. We have now implemented this technology and are offering it to clients that need that solid insurance.

Check out Engine Yard Professional Services page to learn more. If you have any questions about services offered for the Engine Yard PaaS, please feel free to contact proservices@engineyard.com.

Here at Engine Yard, we have found that some of our best sources of traffic are the blog posts written by our team that help educate customers on our product.

In particular, there is one blogging platform that has really started to catch on with the hacker community and especially those of us who love Ruby.

Authored by Tom Preston-Warner, Jekyll is an open-source blog-aware static site generator. Unlike Wordpress, Tumblr, Posterous, Blogger and the like, it allows users to write posts in the editor of their choice with the markup they prefer and then commit the posts to git. I use Markdown to write my posts, but many others choose to write their posts in HTML because they were coming from WordPress and it felt more at home.

Currently, there are lots of posts out there detailing how to get started with Jekyll, how to run Jekyll as a Rack application, etc. What I want to talk about is just a little bit different from these posts.

Let's start with a simple concept. For SEO purposes it is better if your blog runs at http://mydomain.com/blog rather than http://blog.mydomain.com. We can go into detail here later but that's really for an entirely different post. Again there are numerous ways of accomplishing this task but I want to talk about doing it with Jekyll.

Finding a way to run your blogging platform within your existing application without many changes to the server configuration is a common cost cutting technique for bootstrapping startups, well-funded companies and even public corporations. One thing we know first hand is how time consuming and difficult that has proven to be for many of you over the years.

That’s why I wrote Bloggy. Simply put, Bloggy makes it easy to run a Jekyll blog right within your existing Rails application with no changes to your current configuration on Engine Yard.

Installing and configuring the Bloggy gem

Start by adding

gem ‘bloggy’

to your Gemfile in your repo, then just run

$ bundle

and it should be ready to go for you. Alternatively, you could install it by running

$ gem install bloggy

Once Bloggy is installed, all you need to do to get a working blog up and running is to use the provided Rails generator.

$ rails g jekyll:blog blog

BAM! This just generated your new blog and it’s live at http://yourdomain.com/blog

Go ahead start up your Rails server and check it out.

What Just Happened?

The static HTML generated by Jekyll (the magic behind Bloggy) goes to your public/blog directory, but the rest of the files live at config/jekyll and this is where you will create new posts, change the default look and feel of your blog and make any configuration changes you desire as you get acquainted with Jekyll.

If you’ve never used Jekyll before, you need to familiarize yourself with a few things.

1. Bloggy Generates static HTML from the markdown files that live inside the config/jekyll/_posts directory, so this is where you will create new posts (more on how to make the generation happen later).

2. The default layout of the Bloggy generated blog is found at config/jekyll/_layouts/default.html. This file is plain ole HTML and can be edited to your liking just like you would edit any other HTML file.

3. The config/jekyll/css directory contains, wait for it … your CSS files!

Configuration and new posts

If however, you are familiar with Jekyll already you will be delighted to know you can still choose from all of the options you enjoyed with the Jekyll gem previously.

The same familiar config elements of Jekyll can be accessed using the _config.yml file that is now neatly tucked away in the config/jekyll directory of your Rails application.

Now that your new blog is installed and serving pages at http://yourdomain.com/blog you probably are thinking:

“Zach this is great, but how do I write a new blog post? How do I get rid of the test post you provided me?”

Those are great questions. I’ll start with the simplest:

1. To get rid of the generated test post, simply delete the file from your config/jekyll/_posts.

$ rm appname/config/jekyll/_posts/2012-04-25-a-test-post.markdown

2. And to create a new post it’s not much more complicated. Just run the Rake task provided with Bloggy, which will automatically generate a post and open it so you can start writing right away.

$ rake np your_post_title

This will by default open up your new post in TextMate. If you don’t have TextMate or prefer another editor you can just change mate on this line at the end of the new_post.rake file located in your appname/lib/tasks directory.

‘mate #{path}’  - for example if you wanted to use vim you should use  ‘vim #{path}’

Now, if you’re looking carefully at the created post you will notice that your post was named with a slightly different scheme than just your title. This is critical to Jekyll being able to recognize and generate your posts into static HTML files that your application can serve, so please do not change this. For example if you ran that task today your post would look something like this:

2012-05-03-your-post-title.markdown

Feel free to change the date just make sure you leave it in the correct format, but keep in mind that YAML is required at the top of your post (including the dashes) for Jekyll to generate Metadata when generating the final HTML that you will see your posts rendered in. So the top of your file should always look something like this:

---
layout: post
published: false
title: A Test Post
---

The Rake task provided takes care of that for you but be sure to edit your title and add any other metadata you want included. Other than that, just be sure to change published: false to published: true so Jekyll knows your post is ready to go live on your blog for the world to see. Once you have written, edited and reviewed to your liking all you need to do is another Rake task.

$ rake generate

From there Jekyll will automatically regenerate your posts as static HTML files stored in the public/blog directory and these files will be served from http://yourdomain.com/blog with no additonal Nginx configuration.

You will have to hit CTRL + C on your keyboard after the files are generated to stop the Jekyll server as it wants to stay on and continually look for new posts to generate.

Now from your application directory you can just run a few commands to make sure you have added your changes to git and pushed them to your repo.

$ git add .

$ git commit -m ‘your commit message’

$ git push

Then deploy to Engine Yard using our awesome CLI tool! by running

$ ey deploy

That’s it! It’s really that simple.

So go check out Bloggy and be sure to fork and contribute if you want to see something added to Bloggy that would help you even more!

I have a sample application for you guys to play around with at our Engine Yard GitHub account.

Alternatively, you can just checking it out in action by clicking here.

Happy blogging!

New Instance Size

We are also very happy to announce that today, we have released Amazon’s latest Medium instance on the Engine Yard Cloud product. Pricing for the new Medium instance (m1.medium) is $0.24/hr. You can find all of our pricing information here. More in-depth information about the instance sizes can be found here.

More Ruby, More Data

In the last couple of months, we’ve also released Ruby 1.9.3 and PostgreSQL 9.1 into GA. We’ve received a lot of great feedback from customers using these and we think you’ll be as thrilled as they are to use them.

JRuby and Node.js Updates

We're definitely ramping up our stack. Back in January, we upgraded Node.js 0.6.1 to 0.6.8. It is now installed from EY Portage and uninstalled from /opt/node. And more recently, we upgraded JRuby to 1.6.7 from 1.6.6. Check out more information about it here.

Have any questions about these updates? Go ahead and give us a shout!

If you’re going to be around after php|tek on Friday, May 25, we want you to come have an adventure with us! We’re all going to sample the sights and sounds of downtown Chicago, and have some fun in the process (in true PHP Community spirit).

The Community JAUNT will include:

• Blue Line Tickets to/from downtown Chicago.   The Blue Line will take us directly from O’Hare to Jackson Station, a few blocks from where we’ll be spending most of our time. Trains run regularly, so when you’re ready to go home, you can do so at any time. We’ll provide you with a schedule, or you can find it online.
• Dinner at Giordano’s Pizza.   Chicago’s deep dish Giordano’s is world-famous, and we’ll be eating at one of the oldest locations in the city. (http://giordanos.com)
• Tickets to the Skydeck.   We’ll see Chicago like never before: 1,353 ft. in the air! If you’re brave enough, you can enter one of the glass boxes extending out 4 feet into the air from the 103rd floor. For more information on the whole Skydeck experience, their site offers a video tour (http://www.theskydeck.com/plan-visit/the-skydeck-experience-video).
• Drinks at Elephant and Castle.   From there, we’ll visit one of the local “English-inspired” pubs to relax over a few pints. (http://elephantcastle.com). We have been told by the locals that they have one of the best whisky selections in the city.
• Drinks at Miller’s Pub.   We’ll end the evening at the Chicago landmark, Miller’s Pub. Opened in 1935, this pub still offers an impressive list of beer, wine, and spirits, and is a favorite of celebrities passing through. And, for you night owls who want to stay when the rest of us have long gone, it’s open until 4 am. (http://millerspub.com).

You can also see our plan mapped out here.

We’ll be picking up the tab on the whole night, so we hope you can come enjoy Chicago with us. Space is limited to 50 people, so we suggest you register early.

We can’t wait to hang out with you in Chicago!

I started work on this project in 2009 (Charlie roped me in when I thought compilers were behind me) and did a first pass on building an intermediate representation (IR) from the AST, and outlines of a couple optimizations. Through 2010, Tom got the first version of an IR-based interpreter implemented. In 2011, Tom and I ironed out a lot of the bugs in the IR, refactored and cleaned up code. But, thanks to the grant, I was able to work a little more intensively with Tom to debug the IR in both 1.8 and 1.9 modes (using the new interpreter as a vehicle for this), with and without some preliminary optimizations in place. As of now, RubySpec runs are "green" (more about the air-quotes later), MRI tests are "green", Rails boots up and runs (yet to be tested extensively), gem functionality works, and IRB runs.

This project will be part of the 1.7 release in experimental form. We hope to have some version of the JIT (even if not functionally complete) as part of the release as well. But, with a default functionally complete and correct interpreter in place, we will now be ready to embark more seriously on performance work in the coming months and years. Thanks to Engine Yard for the grant and kudos for putting money into this project where the returns are not going to be immediate.

But, first things first ...

Why a new IR (intermediate representation)?

• The AST captures higher level structural semantics compactly, but its non-linear tree-structure makes it harder to perform standard dataflow analyses and code transformations on it, especially in the presence of blocks, exceptions, non-local breaks, non-local returns, and retries. There is a theoretical framework for dataflow and control-flow analysis based on control flow graphs and basic blocks with instruction sequences that can be used to analyze this IR, and implement performance improving code transformations on it. This would be harder to do with an AST. Inlining transformations are easier in this IR form than with an AST.
• This IR attempts to capture “operational semantics” (to use the term somewhat loosely) by enabling primitive operations on the JRuby runtime to be specified, whereas the AST captures “structural semantics” (once again to use the term loosely). For example, the AST captures a call via different flavors of call AST nodes, but looking at it, you don’t know what happens under the covers. But the IR can operationally specify what happens on a call: arguments are prepared, method is looked up, bindings are allocated, other values are pushed on the stack, arities are checked, arguments are received. Similarly, in the AST what are Colon2 and Colon3 nodes transform to identical InheritanceSearchConst, test for successful lookup, followed by ConstMissing instructions. All of these primitive IR operations are then subject to analysis and optimization which is harder in the AST since they are not surfaced explicitly.
• It is also a lot more straightforward to compile this IR to JVM bytecode when compared to the existing JIT. In addition, it is also possible to target new backends (ex: Dalvik) fairly easily while taking advantage of all optimization passes.
• An additional benefit of this instruction-based representation is that it enables JRuby to persist the IR to disk (similar to .s output for C) across runs.
• We also expect to be able to simplify pieces of the existing JRuby runtime once we switch to IR mode. For example, the IR-based interpreter localizes all non-local break and return handling to the interpreter loop and the break and return instructions. Implementation details of the VM dont leak out into JRuby code that implements Ruby libraries, unlike the existing runtime.

So, now that you know why we are going this direction, let us look at some IR output. The figure below shows a simple recursive fibonacci function and the corresponding textual AST and IR representations. The textual output of IR is far easier to read and understand as well.

Ruby Source code:

def fib_ruby(n)
 (n < 2) ? n : fib_ruby(n - 2) + fib_ruby(n - 1)
end

JRuby AST:

ArgumentNode:fib_ruby 0
ArgsPreOneArgNode 0
  ArrayNode 0
    ArgumentNode:n 0
NewlineNode 1
  IfNode 1
    NewlineNode 1
      CallOneArgFixnumNode:< 1
        LocalVarNode:n 1
        ArrayNode 1
          FixnumNode 1
    LocalVarNode:n 1
    CallOneArgNode:+ 1
      FCallOneArgNode:fib_ruby 1
        ArrayNode 1
          CallOneArgFixnumNode:- 1
            LocalVarNode:n 1
            ArrayNode 1
              FixnumNode 1
      ArrayNode 1
        FCallOneArgNode:fib_ruby 1
          ArrayNode 1
            CallOneArgFixnumNode:- 1
              LocalVarNode:n 1
              ArrayNode 1
                FixnumNode 1

JRuby IR:

LBL_2:
LBL_3:
 	check_arity(1, 0, -1)
 	n(0:0) = recv_pre_reqd_arg(0)
 	%block(0:1) = recv_closure
 	thread_poll
 	line_num(1)
 	%v_0 = call(< , n(0:0), [2:fixnum])
 	b_false(%v_0, LBL_0)
LBL_4:
 	%v_0 = copy(n(0:0))
 	jump LBL_1
LBL_0:
 	%v_1 = call(-, n(0:0), [2:fixnum])
 	%v_2 = call(fib_ruby, %self, [%v_1])
 	%v_1 = call(-, n(0:0), [1:fixnum])
 	%v_3 = call(fib_ruby, %self, [%v_1])
 	%v_1 = call(+, %v_2, [%v_3])
 	%v_0 = copy(%v_1)
LBL_1:
 	return(%v_0)
LBL_5:

Playing around in IR mode

All this code is on JRuby master. If you want to play around with this, the
notes below should get you going:

• -X-CIR enables interpretation in IR mode. This mode has been extensively tested in both 1.8 and 1.9 modes. Please report correctness bugs if your Ruby code yields incorrect output in IR mode. Note that some incorrect uses of break that ought to yield LocalJumpErrors dont always raise these errors (hence the air-quotes earlier) -- something that will be fixed in the coming months. As far as performance goes, the IR-based interpreter is slower than the AST-based interpreter, from 30% - 3X, depending on the Ruby code.
• -Xir.debug=true enables debug mode which enables verbose output of IR instructions. In addition, just to get clean debug output, you will also want to enable -Xlogger.class=org.jruby.util.log.StandardErrorLogger
• If you are going to be running RubySpec tests, please remember to pass in -Xlaunch.inproc=true so that the tests run with -X-CIR mode in the same process. If not, new spawned processes will run with default JRuby mode (-X+C) which doesn't use IR yet. Alternatively, you can set env var JRUBY_OPTS=-X-CIR, and that should work as well.
• -X+CIR enables JIT-ting in IR mode. This is not yet functionally complete. Charlie is working on this as you are reading this. But, for starters, we are going to target Java 7 (using invokedynamic functionality). While it is not hard to add support for Java 6, we'll only add that when it becomes necessary. As this work moves along, we expect -X+CIR will perform better relative to -X+C than -X-CIR does relative to -X-C, since the IR is designed to help the JIT generate better code. But don't hold your breath -- this is all work in progress. But, I would be surprised if -X+CIR doesn’t match up with and eventually do better than -X+C.

Besides these basic flags, you can also play around with a few IR passes from the command-line. The following passes are currently operational:

• OptimizeTempVarsPass: As part of generating IR, a lot of temporary variables are generated by the IR builder (%v_0, %v_1, %v_2, %v_3 in the IR example above). This pass eliminates unused temporaries, does simple constant and copy propagation of temporaries, and heavily reuses temporaries to minimize the number of temporary variables used. This compaction reduces memory allocation in the interpreter and local variables in the JIT.
• LocalOptimizationPass: Does simple copy/constant propagation within a basic block. Nothing fancy.
• DeadCodeElimination: As the name says, it gets rid of code that doesn’t need to be executed. This pass is fairly conservative right now -- caused by the use of blocks-as-binding which means all writes to local variables would have to be preserved for the worst-case scenario. Even so, it does yield 10% or more speedup in certain cases. In future, we'll explore ways to relax these constraints. This code has been debugged and tested for correctness but this needs additional testing. Please report bugs where you run into them.
• AddLocalVarLoadStoreInstructions: In Ruby, local variables are not like locals in languages like C/Java because of closures. They reside in a heap structure (binding). The current JRuby runtime is smart enough to detect when a method doesn’t require a binding, but cannot do much more than that. This pass lets JRuby try to be smart about when to store the variable to the binding and load from it. This is experimental and not yet well-tested for performance (will be once JIT is in place). This is primarily targeted at the JIT, but in certain scenarios, benefits the interpreter as well (up to 15% speedup in certain cases). More details in a future post.

You can enable passes on the commandline via -Xir.passes flag. A few valid options:
-Xir.passes=LinearizeCFG
-Xir.passes=OptimizeTempVarsPass,LocalOptimizationsPass,LinearizeCFG
-Xir.passes=DeadCodeElimination,LinearizeCFG
-Xir.passes=DeadCodeElimination,AddLocalVarLoadStoreInstructions,LinearizeCFG

This CLI is still quite basic at this time, and a lot of functionality is missing, but it lets you mix and match passes which is especially good for testing the IR code in different ways. But, given the preliminary state of this CLI flag, you need to always add LinearizeCFG as the last pass whenever you provide an explicit passes flag, and the ordering of passes on the CLI matters as well. As long as you preserve the relative order of passes as above, you should be good.

We also have preliminary profiling and inlining (methods and blocks) in place, but it is not fully enabled on master (requires a non-committed patch at this time). In the interest of keeping length under control, I am skipping the details here since you cannot really play with it right now.

Now that we got the preliminaries out of the way, let us look at where we are at right now, and what lies in the future.

Current status

As should have been clear from the previous sections, a lot of the work so far has been to try out different things with the IR (interpret in 1.8 and 1.9 modes, compile to bytecode, run analyses and code transformations, profile, inline) with the goal to stabilize the IR and the code around it so we are increasingly confident that it accurately captures Ruby semantics in a clean way, and that we can use it for code optimizations. While we have dabbled in some performance experiments, most of these have been preliminary stabs. Once the JIT is complete, we will have a solid interpreter and JIT that are functionally correct, and we can more confidently experiment with code transformations to improve performance.

Overall, it is best to think of this project as moving towards a newer JRuby-level VM that is based on this new IR. As it stands now, we have a high degree of confidence that the IR, as it exists now, accurately captures semantics of Ruby, and that the IR-based interpreter, in both 1.8 and 1.9 modes, is as functionally correct as the default JRuby implementation. Based on this confidence, over the past few months, Tom has proceeded to do some much needed code cleanup and refactoring.

To summarize, here is where things are with this project and the pieces that are already in place:

• IR builder to transform AST to a sequence of IR instructions.
• Local peephole optimizations (post-IR construction).
  - Minimizes use of temporary variables.
  - Simple copy and constant propagation within a basic block.
• A generic abstract-interpretation based dataflow analysis framework.
• Dead code elimination (based on the dataflow framework).
• Preliminary profiling support.
  - Implements scope hotness profiling by embedding profiling on thread poll instructions placed on scope entries and loop back-edges. Thread-poll counts act as proxies for a hot scope.
• Method and block inlining transformation (with some known bugs and gaps).
• Local variable access opts (based on the dataflow framework).
• IR -> bytecode JIT is coming along.
  - For now, this targets JDK 7.
• Beginnings of work to optimize the IR stream for interpretation.
  - There is some tension between what the interpreter wants from the IR and what opt passes and JIT want from the IR. The latter want more explicit information and simpler instructions, whereas interpreter wants fewer complex instructions (to eliminate dispatching and interpretation costs). So, one experiment we started is to transform instruction chains in a basic block into an expression tree which eliminates dispatch costs, and temporary variable read/write overheads from the interpreter loop.

Future work

The first thing we want to accomplish is get the IR -> bytecode JIT (-X+CIR) functionally complete and correct.

Going forward, there are several things we want to address:

• Additional IR cleanup: There are still some oddities left in the instruction set (GetClassVarContainerModuleInstr, InstanceofInstr) that we want to get rid of. That just reflects a gap in my understanding of Ruby semantics as I worked on this.
• Improving interpreter performance: The 3X slowdown that I reported up there was to dampen your expectations :). The 3X slowdown is on micro-benchmarks like fib_recursive. “Real” programs perform much better. But, this also highlights another issue with performance testing: micro-benchmarks aside, is there a good set of benchmarks on which we can evaluate performance that is meaningful? That apart, we still have some gap to close with the AST interpreter before it can become the default interpreter.
• Expose more JRuby state in the IR so we can more explicitly analyze and manipulate it - where is a piece of state really required, and where can it be removed. For example, on a typical call, JRuby passes a block, sets up a call frame with many fields, sets up a "binding" for local variables, all of which adds to the cost of Ruby calls. Not all of this is necessary at all call sites. We have brainstormed several ideas about how to tackle this and this is something that we'll be working on. No immediate results here since some of this state winds its way through the existing runtime, and we have to carefully unwind it.
• Additional analyses/optimizations (non-exhaustive):
  - Optimize allocation of bindings: Right now, bindings/dyn-scopes are always allocated -- we will import some heuristics from the AST JIT, but more work to be done here.
  - Migrate call setup code out of JRuby runtime into the IR (split between the call site and callee entry/exit).
  - Method and block inlining: As discussed earlier, beginnings of this are in place which you can play with via the -Xir.profile=true option. This still needs work to iron out bugs and figuring out good inlining strategies which is different from the transformation (which is needed when the strategy decides scope A should be inlined into scope B).
  - Unboxing of primitives: Rather than create first-class Ruby/Java objects for fixnums, booleans, can we get away using JVM primitives instead?
  - Profiling: What is the kind of profiling we need and how do we do it effectively with low overheads?
  - VM manager: We need a manager process that orchestrates this whole thing. How much do you optimize before interpretation? When do you profile and how long? When do you JIT? When do you inline and how much do you inline? How much work should JRuby do and how much should we let the JVM deal with? Our strategy will be one where we always let the JVM do its magic and find areas where we can help it along. But, to me, it is clear that we cannot expect the JVM to optimize everything that is thrown at it
  which is where this VM will play a role.

Some of these tasks will take months and others will happen over a few years. So, lots to be done.

Stop by our booth for some cool swag and talk to some of our great team members at the Engine Yard Support Helpdesk.

Make sure to check out our Support team in action at 11:30 am on Monday, where they will be fielding all the questions you could possibly dream up about our products and services.

We'll also be at the Ruby Talent Fair during the dinner break, so come chat with us and see what opportunities we have in store. The event will take please at 5pm on the 24th at Pete's Dueling Piano Bar, next to the Hilton.

Finally, we’ll also be hosting an afterparty at The Jackalope on April 24th! Who wouldn’t want to ride one of those things? You heard right: they have a giant jackalope that you can ride. Join us for drinks, snacks and more tomfoolery. And to wrap up the conference, we’ll be having an event at Speakeasy with CabForward on April 25th. Come up to the roof for some music, refreshments and cool people for a great RailsConf sendoff.

Can't wait to see you all there!

AngularJS - A MVC/MVVM Framework to look at

The space of JS MVC/MVVM frameworks is quite cluttered and to stay up-to-date is a tough task. So in the case you’ve not taken a look at AngularJS yet, head over there now. Similar to Knockout or SproutCore, it uses data-binding to keep models and views in sync and therefore means less things for you to care about! It also appears to be a very robust framework, approaching version 1.0 soon and already being used for several internal projects at no other than your beloved friend Google.

We at Engine Yard definitively put down Angular on the list of things we have on our radar for any future projects.

Oh and of course AngularJS is also featured in the fabulous todomvc project. If you want to see how it compares to all the other MVC/MVVM frameworks out there, or just want to get a general overview of your choices, make sure to check that out.

WebComponents

WebComponents are not a brand new idea but are still in an early draft phase at W3C. They actually consist of two different W3C RFCs: The Shadow DOM and HTML Templates. When you combine those two dudes, the result is simply amazing: Imagine being able to write your own HTML elements or widgets, package everything what is needed for them (HTML, CSS and even event handling JavaScript) together and be able to distribute those elements or widgets without having to even think about any side effects on the pages using them. Example? Sure: What about a calendar widget that you can just use on your page? So instead of having to toss in the right HTML markup, some CSS files and of course the JavaScript to make all the magic happen, you can just load the widget with a simple:

<link rel="components" href="http://example.com/calendar.html">

and then use it like this:

<select is="calendar" name="departure_date" .../>

This all and even more can be done with WebComponents!

Webkit pushed out support for the draft Shadow DOM API last June and I’m sure that as soon as the HTML Template part follows, we will see a lot of movement around WebComponents and a bunch of frameworks out there will make use of this leap in web technology.

You can find a detailed and well written rundown of everything they are here. It’s the damn future, don’t miss it!

Debugging

Do you know what is going wrong on your site? Oh you say you’re collecting all the exceptions? You even have a nice solution for searching your logs when shit goes wrong? Not bad. But what about JavaScript? Do you get notified whenever something goes wrong on the client-side of your page? No? There is no reason not to anymore!

It is funny that big chunks of the Front-end Guy’s time at any start-up seem to be used up by including metrics and funnel and whatnot analytics scripts on the page to measure even the tiniest bit of available information and make sure no potential customers will be left behind. But when it comes to errors we do not measure, we do not track, we do not send them down a funnel; we are simply not aware that they even have happened as long as we or our QA folks don’t see them. And just to make this clear: the odds are not bad that a single error in some script renders your whole page useless.

If you have gotten a bit nervous by now, don’t worry. There are ways to cope with that and some of them are not even very hard.

First you can register a page-wide error handler by just using window.onerror which is supported by all major modern browsers (a complete list of supported browsers and more useful information can be found at the Opera dev pages). If the lacking support in some ancient browsers scares you there is another solution but you might want to think twice about using it: You can find it in GMail where the Google developers have replaced all of JavaScripts methods with versions that support error logging. A tedious quest, no doubt. But it works.
No matter how you solve that problem, detecting errors early will make your application a happier and better place for your customers to be.

That’s it

I hope you liked this peak into the future of client side JavaScript as much as I did enjoy the JS Summit. Thanks again to O’Reilly for putting this event together and stay tuned for more JS hotness as soon as it is served.