bgror

RailsInstaller 2 for Windows released »

Created at: 07.09.2011 23:57, source: Engine Yard Blog, tagged: Open Source Technology RailsInstaller railsinstaller 2

After over 70,000 downloads of RailsInstaller for Windows, it is with great excitement we have released RailsInstaller 2 for Windows. You may download it from the RailsInstaller website.

What’s special about RailsInstaller 2 for Windows? I’m glad you asked.

Exciting feature number one is the most requested addition of all time: Ruby 1.9.2. Many thanks to Luis Lavena and the Ruby/Windows community for all the hard work ensuring that many gems function on Windows with Ruby 1.9.

Exciting feature number two is a small improvement we like to call: Rails 3.1. Here at the World Headquarters of RailsInstaller, we've been waiting and waiting for the Rails 3.1 final release. Like Dr Nic, my favorite feature of Rails 3.1 is ActiveRecord's prepared statement support. SQLite3, PostgreSQL and SQL Server now use prepared statements to yield “2x faster for simple queries and 10x faster for complex ones!”

Exciting feature number three is for you if you are using SQL Server on Windows: the latest ActiveRecord SQL Server Adapter, TinyTDS and FreeTDS are now included! TinyTDS is a project from Ken Collins that allows you to use FreeTDS to connect to Microsoft SQL Server databases. That is, everything you need to create Rails applications for your existing SQL Server database is included within RailsInstaller 2 for Windows!

Alternately you can continue using SQLite3 which continues to be packaged with RailsInstaller and is still the default adapter for new Rails 3.1 applications.

Slightly more minor but still very exciting improvements:

• Bundler is bundled (pun intended) as well and is now version 1.0.18.
• Git has also been upgraded to version 1.7.6.

Keep in mind that the goal of RailsInstaller remains making it as simple as possible for someone to get started with Ruby and Rails. If you have any ideas on how we can make things even easier, please let us know.

RailsInstaller 2 for Windows is for using and for sharing with others. Let your friends, family and colleagues bask in the goodness that is Ruby! You know in your heart that you would love nothing more than your own grandmother hacking with Ruby!!!

Introducing the Engine Yard Data Team »

Created at: 02.09.2011 21:08, source: Engine Yard Blog, tagged: News Technology engine yard data team mongodb mysql PostgreSQL

The Engine Yard Data Team’s mission is to formulate and iterate the Engine Yard data storage strategy, to help customers understand and choose their data solutions, to support OSS projects that match our vision, and to strengthen our leadership in the Ruby on Rails community. Our team is composed of Ines Sombra and our amazing DBAs: Erik Jones, Tyler Poland, and John Dalton.

We want to ensure that when you choose Engine Yard as your platform provider you have access to interesting data stores, features, tools, and information to build robust and scalable solutions.

Our Goals

• Simplify and hide the complexities associated with data repositories.
• Choose the best-in-class technologies and publish our own best practices.
• Work closely with our customers and developers to understand their use cases and usage patterns.
• Routinely assess how closely our data products and support match our customers needs.
• Ensure Engine Yard’s data repositories are up-to-date with the rapidly evolving storage technology landscape.
• Establish partnerships with key data providers to offer our customers additional services.
• Design and support multi-site disaster recovery and business continuity plans for each type of data store by working with our customers to understand their scaling needs.

What we are currently working on

Upgrading our MySQL implementation

The team is currently working at a rapid pace to upgrade MySQL to version 5.1 and 5.5. We’ll also be improving MySQL replication, monitoring, backup, and fail-over tools.

Expanding the DB stack

We are working hard on expanding our stack to offer interesting NoSQL data stores, caches, and full-text search solutions. The products we are working on at the moment are:

PostgreSQL 9 PostgreSQL 9 is now in Alpha (click here for access). We are currently working towards a public Beta for all our customers to try. Postgres extensions will be available as part of the Beta release.

MongoDB We are working towards an Alpha release of MongoDB. We have been collaborating with customers that are interested in this technology to further develop our tools and finalize our supported architecture. We have established critical partnerships with hosted MongoDB providers (MongoHQ and MongoLab), and are working with 10gen to provide additional support options for our customers.

Redefining environments and data stores relationships

We are changing the way environments interact with data stores to provide greater flexibility and configuration options. We aim to support zero to multiple data stores in the same environment to facilitate the creation of polyglot systems in our platform.

Improving our data documentation

We are collaborating with the PANDAs and our Documentation team to restructure and augment our data documentation. Watch for changes in docs.engineyard.com and let us know if we are not covering something that you are interested in.

We want to hear from you!

We are actively evaluating customer requested features and we will keep you informed as our work grows from ideas to projects. Our intention is to create a strong collaborative process with our customer community, so let us know what you need.

We’d love to hear your feedback! Please drop us a note at: docs.engineyard.com/data-feedback.html

Want to work with us?

Are you passionate about data? We are hiring!

Updated Passenger Releases »

Created at: 30.08.2011 23:40, source: Engine Yard Blog, tagged: Product Technology passenger

The other day while I was in the midst of a discussion about Linux kernel upgrades, one of the other engineers who works at Engine Yard, Scott Likens, sent me a github URL:

https://github.com/FooBarWidget/passenger/commit/4d765d71ea689c42ade897fc93851b8a8797e9c7

It turned out that this patch had hit the Passenger github repo after our last set of ebuild releases, so I started investigating.

The patch fixes a concerning issue. Consider the simplest valid HTTP request for HTTP 1.0:

GET / HTTP/1.0

That request line alone is a simple, trivial HTTP request. With unpatched Passenger versions, a simple request of this nature returns a surprising response:

# curl -0 -H "Host:" http://MY.URL
curl: (52) Empty reply from server

The expected response would have been some sort of valid HTTP, but not only is there an empty reply from the server, which is bad enough in itself, but if you are on the server and pay attention to the list of processes, you will notice that this request causes a fault which kills the nginx worker process that was handling it. Nginx is an innocent victim in this case because it is the Passenger code that is at fault.

For a more visual example than curl provides, you could use a tool such as http://web-sniffer.net/. Do HTTP/1.0 without a Host header, and you'll see the same thing, regardless of the content of any other headers. Add the Host header back, and it works as expected.

It appears that the bug was caused by the SERVER_NAME patch, which was part of 3.0.8, and fixed a bug so that Rack::URLMap would work correctly.

You can use either of these tools to test your own applications.

This seemed like an important bug to have fixed in our nginx+passenger ebuilds here at Engine Yard, so after confirming the bug, and the patch, I built new versions of all of our relevant ebuilds to incorporate this patch. As of the time that this blog post was published, these builds have been live in our build tree for several days. AppCloud customers, you can update your own application to use these builds simply by clicking on the Upgrade button in your application dashboard. You may do so at your convenience, and can test that the patch fixed the problem by using either curl from the command line, or a web based tool such as the http://web-sniffer.net/ mentioned above. xCloud customers, you can request this update by filing a ticket with support.

We'd like to thank Phusion for all of their work on Passenger, and for fixing this particular bug. We look forward to the next release of Passenger, and we look forward to continuing to provide our customers with the most reliable systems that we can.

Serialized Attributes Rails 3 »

Created at: 27.08.2011 18:46, source: Ruby Rockers, tagged: Technology rails

This post will guide you how to do Serialization for your attributes in Rails.

Serialize means you want to save arbitrary Ruby data structure into the database.

Let consider we have a User model in which we want to store preferences for user in a Ruby data structure format. Previously it was only YAML.

class User < ActiveRecord::Base
  serialize :preferences
end

user = User.find 1
user.preferences = {:foo =>  'bar'}
user.save

So now we can pass a second parameter to serialize method to use that serialization method.

class User < ActiveRecord::Base
  serialize :preferences, SomeCoolEncoder.new
end

You need to implement this encoder! It can be a JSON, XML, Base64. Or what every encoding technique you like to use.

A sample encoder look like this.

class Base64Encoder
  def load(value)
    return unless value
    value.unpack('m').last
  end

  def dump(text)
    [text].pack('m')
  end
end

This new encoder must have these methods in it!

So now you attribute is serialized and you can store data in it in your given format.

Ok so now we talk about ActiveModel::Serialization

ActiveModel::Serialization will give you serialized attribute for your classes.

A very simple example to use ActiveModel::Serialization

class Post

  include ActiveModel::Serialization

  attr_accessor :title

  def attributes
    {'title' => title}
  end

end

# So you can use like 

post = Post.new
post.serializable_hash   # => {"title"=>nil}
post.name = "Rails is Cool!!"
post.serializable_hash   # => {"name"=>"Rails is Cool!!"}

Can use two inbuilt Serialization techniques

include ActiveModel::Serializers::JSON
include ActiveModel::Serializers::Xml

This is a very short intro for Serialization. Hope i will write more in detail soon!!

I got this from @tenderlove talk in RailsConf2011

Mobile development with HTML5 »

Created at: 26.08.2011 01:54, source: Engine Yard Blog, tagged: Technology html5 jquery local storage mobile

HTML5: the standard, the buzzword and the legend

If you read blogs that are even slightly related to tech, you likely hear about HTML5 on a near-weekly basis. Although the new web standard does not do your laundry, it has features that enable the creation of powerful applications—using only HTML, CSS and JavaScript (a Rails back-end can bring additional firepower to the table). This post will go over some key concepts and features of HTML5, setting the stage for more advanced subjects.

Browser Compatibility

Perhaps the biggest pain in developing a web-based application is ensuring that your application is compatible with the various browsers in use today. Fortunately, this is less of a problem in the mobile world. Because people get new phones more often than new computers and because the smart phone space is relatively young, there are simply fewer old smart phones out in the wild. However, this is not a carte blanche; you should test your site with any devices you wish to support, not just simulators.

Viewport

When you visit a website not designed for mobile browsers, it first appears very zoomed out. This is done intentionally by the mobile browsers to make the website viewable. They set the default viewport width to between 800 and 980 pixels (depending on the browser). This allows the user to view the whole website and then zoom in as needed. However, if you are crafting a website specifically for mobile, it make sense to set the initial viewport for the mobile device. This is accomplished with the viewport meta tag.

<meta name="viewport" content = "width=device-width”>

This sizes the viewport to the device’s width, so the content does not initally appear zoomed out. You will likely want to disable zooming entirely, so the user doesn’t accidentally zoom out and distort the UI. Do this by setting user-scalable to no.

<meta name="viewport" content = "width=device-width ,  user-scalable=no">

Some sites currently hard-code the width of the viewport to 320. Why? Because this is the width of the iPhone. However, in general, it is a better practice to use “device-width” instead of 320.

Having your site correctly sized for mobile is nice but the next two features of HTML5, caching with the cache manifest and local storage, allow for fully functional offline sites.

HTML5 Caching

HTML5 caching allows users to view websites they have visited before without a connection to the web. Not only is this extremely useful for users who may not get coverage where they want to use the application, but it can also mitigate brief drops in a connection.

To setup HTML5 caching, you add a manifest file to the html tag of every page you want to cache.

<html manifest="/cache.manifest">

This file starts with “CACHE MANIFEST” and then enumerates the files that the application should cache.

CACHE MANIFEST
/mystyle.css
/scripts.js
/logo.jpg

Now those files will be available offline. Frankly, there is a long list of gotchas with the cache manifest. I review some key ones below but suggest reading Dive into HTML5 for all the details.

The first and foremost, your site will default to cached files over recently downloaded ones, meaning that even if the cache has changed since the browser has last visited the page, the browser displays the old pages until the page is refreshed (or told with JavaScript to update). This is further compounded by the fact that most web servers tell the browser cache the files they serve. When you are developing your site, be sure to tell your web server not to cache the cache manifest, so you always download the most recent copy.

The next big gotcha is how the browser manages the downloading process. If the browser detects that the manifest has changed, it re-downloads every single file. Not only does this make the process expensive, if a single file fails to download correctly, the browser abandons the update and loads the previous cache. When this happens the browser does not post any error by default. However, you can use JavaScript to detect the error thrown by the manifest.

$(function() {
  $(window.applicationCache).bind("error", function() {
    alert("Cache: update failed");
  });
});

So now your site is cached and everything worked. You’re ready to launch? Not really. This caching technique works well with static content. However, if your application has content that is dynamically created and frequently changed (most web apps), it will not work well. This is because, unless the cache is changed, the old html page will be displayed, not the page with your new content. The simple answer is to change the cache manifest file whenever new content is added. However, this is generally not a good idea because it forces the browser to re-download every file every time any content is changed—very costly if your content is updated frequently. The solution is to use jQuery templates to build the page dynamically.

jQuery Templates

The best practice is to populate your content through JavaScript templates. In this way, the content is not part of the HTML page and thus is not cached with the cache manifest. For this, you need to download and add jQuery and the jQuery template plugin to your application.

There are three steps to using these templates:

1. Define the template.
2. Define the collection.
3. Tell jQuery to populate to the page with the template.

Below is an example for a simple blog application.

1. Define the template:

<script id="post_template" type="text/html”>
<div>

<h2>${Name}</h2>

<p>${Body}</p>

</div>

</script>

2. Define the collection (of posts in JSON).

<script>
var posts = [
{ Name: "First!", Body: "This is pretty cool" },
{ Name: "Another post", Body: "This is pretty cool" },
{ Name: "Yet another blog post", Body: "This is pretty cool" }];
</script>

3. Tell jQueryto populate to the page with the template.

<script>
$( "#post_template" ).tmpl( posts ).appendTo( "#blog_posts" );
</script>

…

<body>

<div id="blog_posts"></div>

</body>

Although this content is loaded via JavaScript, it is not dynamic—it is just defined on the page. For dynamic content we will want to use JSON provided by the server. Let’s assume our blog application provides us with the JSON representation of our blog at this URL:

/posts.json

We will tell jQueryto make a request for the JSON and then use it to populate the page.

<script type="text/javascript">
$.getJSON('/posts.json', function(data) {
$( "#post_template" ).tmpl( data ).appendTo( "#blog_posts" );
});
</script>

We also need to change the template so that it can handle the JSON elements, substituting post.name for Name and post.body for Post:

<script id="post_template" type="text/html">
<div>
  <h2>${post.name}</h2>
  <p>${post.body}</p>
</div>
</script>

Now our blog is pulling content that is not cached in the cache manifest and using jQuery templates to populate the page. However, this works only if our mobile browser can connect to our server. This feels like two steps forward and three steps back, but trust me, we almost have a working mobile HTML5 app. We just need to include one last component of HTML5, Local Storage.

Local Storage

Christopher Haupt of Webvanta recently authored a guest blog post about Local Storage. See the Enhancing Client-side Storage with HTML5 post for details and general use.

On a high level, Local Storage is a client-side key-value store implemented by the browser. It stores strings of text locally and then recalls them later. Here, we use it to store JSON so we can populate the blog with posts even if there is no connection to the server.

Although we could write this by hand, there is a great plugin to manage the process for us. The jQuery Offline plugin uses content from Local Storage if the server is not available and will store fresh content in local storage when it’s received.

Download this plugin from jQuery-Offline

To use the plugin we change the getJSON call to retrieveJSON. We will also need to change our script slightly as there is one key difference between getJSON and retrieveJSON. The latter will execute twice, once to pull from the cache and again to get the new content from the server. This will cause the posts to appear twice if we simply append the new posts to the page.

<script type="text/javascript">
$.retrieveJSON('/posts.json', function(data) {
$( "#blog_posts" ).html($( "#post_template" ).tmpl( data ));

});
</script>

The blog application can now be viewed offline and is correctly sized for a mobile browser! You can download this example here offline-blog.

I hope you enjoyed this initial look at some of the technologies that are making mobile development easier. In the coming weeks I hope to be covering more advanced topics such as the popular MVC framework Backbone.js.