Release - Django 1.3

March 23,2010, Django announce the release of Django 1.3. There's plenty of cool stuff in this release, and the release notes cover it all in detail. You can also swing by the downloads page to grab a copy of the release package. And as always, signed checksums for the release package are available.

One important point is worth mentioning here, however: Django 1.3 is, as covered in the release notes, the last official release of Django which will support Python 2.4. When Django 1.4 is released, the minimum Python version required will be 2.5, though you'll still be able to use Django 1.3 -- during its security support lifecycle -- if you need Python 2.4 support.

For more information click here

DjangoCon Europe 2011

Django association is announce the DjangoCon Europe 2011 in Amsterdam. For more information, please read the announcement on the DjangoCon Europe website.

Scala IDE for Eclipse

The new beta version of the Eclipse Plugin for Scala has taken a big leap forward in robustness, reliability and responsiveness. Over the past few years Miles Sabin together with other dedicated contibutors like David Bernard, Matt Russel, and Mirko Stocker have steadily improved the quality and features of the IDE and by doing that have rendered a great service to the Scala community. In order to make a break through in performance and reliability it was seen that the fundamental way in which the plugin worked with the Scala compiler must be rethought. Compiler changes were needed and the plugin design changed to effectively use the compiler's new capabilities.

Miles has handed over the baton to the Scala Solutions team of Martin Odersky, Iulian Dragos and Eugene Vigdorchik who will lead the next development phase of the plugin. After about two person-years of hard work including contributions from Donna Malayeri and Hubert Polciniczak from the Scala team at EPFL the compiler interface has been completely revamped and now delivers better responsiveness and reliability. Actions such as hyperlinking, completion and real-time type checking now work quickly and reliably even on very large projects. The team believes you will find this release a firm foundation on which you will see the IDE grow to include all new features we expect of a modern IDE.

The Eclipse Scala plugin is an open source project so new contributors are welcome. The software is freely available for download from the Scala-IDE site and works with version 2.9.0-RC1 of Scala.

If you are an Eclipse user then you may enjoy giving the new Eclipse Scala IDE a try.

Java - Open Source Ajax Frameworks

Google Web Toolkit (GWT) is a one of my BEST choice to develop enterprise applications.

It is an open source Java software development framework that makes writing AJAX applications like Google Maps and Gmail easy for developers who don't speak browser quirks as a second language. Writing dynamic web applications today is a tedious and error-prone process; you spend 90% of your time working around subtle incompatibilities between web browsers and platforms, and JavaScript's lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile. GWT lets you avoid many of these headaches while offering your users the same dynamic, standards-compliant experience. You write your front end in the Java programming language, and the GWT compiler converts your Java classes to browser-compliant JavaScript and HTML.

MySQL Conference & Expo

The O'Reilly MySQL Conference & Expo is an interactive learning community—four days packed with connections to MySQL developers and open source experts who know their subject inside and out. You'll gain unique insights from speakers, vendors, project leaders, and other participants who are using MySQL to successfully run the world's most demanding applications, saving millions of dollars over proprietary software and hardware solutions.

Experience MySQL Conference & Expo

• More than 120 sessions encompassing a wide range of skill levels
• Multiple tracks that will explore the entire MySQL ecosystem, including Architecture and Technology, Business and Case Studies, Data Warehousing and Business Intelligence, and more
• In-depth tutorials to help develop technical skills and learn new tricks
• Inspirational keynote presentations that describe the future of software and the evolution of open source in the enterprise and beyond
• Thousands of MySQL developers, gurus, experts, and users under one roof
• An Expo Hall featuring dozens of the latest tools and products from third party vendors
• A DotOrg Pavilion within the Expo Hall, showcasing community projects at the forefront of MySQL innovation
• Fun evening events, Birds of a Feather sessions, and plenty of networking opportunities

The O'Reilly MySQL Conference & Expo is designed to help all participants:

• Learn how to optimize the performance of MySQL
• Get detailed insight into new MySQL, Drizzle, and MariaDB features
• Develop skills for scale-out using Java, PHP, Python, Perl, Ruby and .NET
• Delve into new techniques around Stored Procedures, Partitioning, HA Clustering, Triggers, and Views
• Learn Administration and Security Best Practices
• Hear real world experiences implementing MySQL projects
• Discover best practices for using MySQL in a range of architectures including Web, Cluster, Enterprise Data Warehouse, Embedded applications, and more
• Learn how the Ecosystem surrounding MySQL fits into Web 2.0 architecture and emerging web technologies, like the cloud
• Migrate from proprietary databases to MySQL

At the O'Reilly MySQL Conference & Expo, you'll benefit not just from gathering with your peers and experts from a wide variety of companies and countries, but also by learning from some of the leading visionaries in the open source world. Join us April 11-14, 2011 in Santa Clara, California for the biggest and best MySQL event yet!

For more information click here

ZendCon Sessions Episode 042: Best Practices in PHP Application Deployment

The ZendCon Sessions are live recordings of sessions that have been given at previous Zend Conferences. Combined with the slides, they can be the next best thing to having attended the conference itself.

In this series we will be releasing sessions from ZendCon 2010!

This episode of The ZendCon Sessions was recorded live at ZendCon 2010 in Santa Clara, CA and features Shahar Evron giving his talk: "Best Practices in PHP Application Deployment"

The ZendCon Sessions are distributed under a creative commons Attribution-Noncommercial-No Derivative Works 3.0 License, Please honor this license and the rights of our authors.

If you like The ZendCon Sessions, why not consider attending the next ZendCon? Visit the website for dates and other information: http://zendcon.com/

Slides:

View Slides

Podcast Download:

Download as MP3

Play the Podcast:

If you like this episode, check out The ZendCon Sessions homepage for more sessions.

Lift - Seven Things

Lift is the most powerful, most secure web framework available today.  Yeah, it's a bold claim, but this site is going to show you 7 things that are hard or impossible in other web frameworks.  These seven things are crucial to building and maintaining interactive, secure web sites.  Each of the seven things has the source code right on the page.  This will let you see why Lift is different and better.

1. Lazy Loading
2. Parallel page rendering
3. Comet and Ajax
4. Wiring -- declare interdepencies between page elements
5. Designer friendly templates
6. Wizard -- multipage input screens with full back-button support
7. Security

Lift gives you the above Seven Things, plus your code is concise and maintainable, Lift's performance and scalability, and all the benefits of deploying your application on battle-tested J/EE infrastructure.

For more information have a look here

How do YOU deploy Django?

There are a good number of choices for deploying Django projects, whether they be Fabric, Chef, Puppet, Paver, or something else. However, each may be more suitable for some types of deployments than others. For example, Fabric's lack of parallel execution may leave you frustrated if you have many dozens of hosts to deploy to, and Chef's complexity and scattered documentation may be somewhat discouraging, as powerful as it seems.

Show and Tell

DUO Interactive have been using Fabric for their deployments. They've got a few projects in development and maintenance, most of which are single app server situations (which Fabric is awesome for). To keep our deployments consistent across our various projects, they wrote a smattering of management commands and Fabric methods, and tossed it up on GitHub as django-fabtastic. There is no real documentation aside from comments, but they figured they'd share what has worked for our simple deployments.
They've been extremely happy with Fabric and fabtastic for our simple deployments, but a new project looks to be moving towards the more complex end of the deployment spectrum in the future. they're looking at the possibility of at least five app servers by year's end, and are frustrated with our Fabric-based deployment (with a handful of app servers) for a few reasons:

• It can be pretty slow with a good number of app servers.
• Hosts are deployed to one at a time, with no abiiity to execute deployments in parallel.
• DUO Interactive sit their EC2 app servers behind one of AWS's Elastic Load Balancers. At any given time during deployment, users might get an updated app server, or one that has not been deployed to yet. This inconsistency is troubling. They'd still get this even with parallel execution (as it stands right now), but it would possibly be less of a problem.

For more information click here

In an Ideal deployment system

1. Fire off an individual deployment step to a large number of nodes at a time (in parallel, not one at a time).
2. Have the ability to wait until all nodes have completed certain steps before progressing onwards with the deployment. For example, wait until all nodes have checked out the latest version of the source before restarting the app servers. There would obviously still be a small period in time where not all nodes have reloaded the code, but it would potentially be a lot better than what we're seeing right now.

Puppet versus Chef: 10 reasons why Puppet wins

Puppet, Chef, cfengine, and Bcfg2 are all players in the configuration management space. If you’re looking for Linux automation solutions, or server configuration management tools, the two technologies you’re most likely to come across are Puppet and Opscode Chef. They are broadly similar in architecture and solve the same kinds of problems. Puppet, from Reductive Labs, has been around longer, and has a large user base. Chef, from Opscode, has learned some of the lessons from Puppet’s development, and has a high-profile client: EngineYard.

You have an important choice to make: which system should you invest in? When you build an automated infrastructure, you will likely be working with it for some years. Once your infrastructure is already built, it’s expensive to change technologies: Puppet and Chef deployments are often large-scale, sometimes covering thousands of servers.

Chef vs. Puppet is an ongoing debate, but here are 10 advantages Puppet has over Chef today.

1. Larger installed base

Put simply, almost everyone is using Puppet rather than Chef. While Chef’s web site lists only a handful of companies using it, Puppet’s has over 80 organisations including Google, Red Hat, Siemens, lots of big businesses worldwide, and several major universities including Stanford and Harvard Law School.

This means Puppet is here to stay, and makes Puppet an easier sell. When people hear it’s the same technology Google use, they figure it works. Chef deployments don’t have that advantage (yet). Devops and sysadmins often look to their colleagues and counterparts in other companies for social proof.

2. Larger developer base

Puppet is so widely used that lots of people develop for it. Puppet has many contributors to its core source code, but it has also spawned a variety of support systems and third-party add-ons specifically for Puppet, including Foreman. Popular tools create their own ecosystems.

Chef’s developer base is growing fast, but has some way to go to catch up to Puppet - and its developers are necessarily less experienced at working on it, as it is a much younger project.

3. Choice of configuration languages

The language which Puppet uses to configure servers is designed specifically for the task: it is a domain language optimised for the task of describing and linking resources such as users and files.

Chef uses an extension of the Ruby language. Ruby is a good general-purpose programming language, but it is not designed for configuration management - and learning Ruby is a lot harder than learning Puppet’s language.

Some people think that Chef’s lack of a special-purpose language is an advantage. “You get the power of Ruby for free,” they argue. Unfortunately, there are many things about Ruby which aren’t so intuitive, especially for beginners, and there is a large and complex syntax that has to be mastered.

There is experimental support in Puppet for writing your manifests in a domain language embedded in Ruby just like Chef’s. So perhaps it would be better to say that Puppet gives you the choice of using either its special-purpose language, or the general-purpose power of Ruby. I tend to agree with Chris Siebenmann that the problem with using general-purpose languages for configuration is that they sacrifice clarity for power, and it’s not a good trade.

4. Longer commercial track record

Puppet has been in commercial use for many years, and has been continually refined and improved. It has been deployed into very large infrastructures (5,000+ machines) and the performance and scalability lessons learned from these projects have fed back into Puppet’s development.

Chef is still at an early stage of development. It’s not mature enough for enterprise deployment, in my view. It does not yet support as many operating systems as Puppet, so it may not even be an option in your environment. Chef deployments do exist on multiple platforms, though, so check availability for your OS.

5. Better documentation

Puppet has a large user-maintained wiki with hundreds of pages of documentation and comprehensive references for both the language and its resource types. In addition, it’s actively discussed on several mailing lists and has a very popular IRC channel, so whatever your Puppet problem, it’s easy to find the answer. (If you’re getting started with Puppet, you might like to check out my Puppet tutorial here.)
Chef’s developers have understandably concentrated on getting it working, rather than writing extensive documentation. While there are Chef tutorials, they’re a little sketchy. There are bits and pieces scattered around, but it’s hard to find the piece of information you need.

6. Wider range of use cases

You can use both Chef and Puppet as a deployment tool. The Chef documentation seems largely aimed at users deploying Ruby on Rails applications, particularly in cloud environments - EngineYard is its main user and that’s what they do, and most of the tutorials have a similar focus. Chef’s not limited to Rails, but it’s fair to say it’s a major use case.

In contrast, Puppet is not associated with any particular language or web framework. Its users manage Rails apps, but also PHP applications, Python and Django, Mac desktops, or AIX mainframes running Oracle.
To make it clear, this is not a technical advantage of Puppet, but rather that its community, documentation and usage have a broader base. Whatever you’re trying to manage with Puppet, you’re likely to find that someone else has done the same and can help you.

7. More platform support

Puppet supports multiple platforms. Whether it’s running on OS X or on Solaris, Puppet knows the right package manager to use and the right commands to create resources. The Puppet server can run on any platform which supports Ruby, and it can run on relatively old and out-of-date OS and Ruby versions (an important consideration in many enterprise environments, which tend to be conservative about upgrading software).

Chef supports fewer platforms than Puppet, largely because it depends on recent versions of both Ruby and CouchDB. As with Puppet, though, the list of supported platforms is growing all the time. Puppet and Chef can both deploy all domains of your infrastructure, provided it’s on the supported list.

8. Doesn’t reinvent the wheel

Chef was strongly inspired by Puppet. It largely duplicates functionality which already existed in Puppet - but it doesn’t yet have all the capabilities of Puppet. If you’re already using Puppet, Chef doesn’t really offer anything new which would make it worth switching.
Of course, Puppet itself reinvented a lot of functionality which was present in earlier generations of config management software, such as cfengine. What goes around comes around.

9. Explicit dependency management

Some resources depend on other resources - things need to be done in a certain order for them to work. Chef is like a shell script: things are done in the order they’re written, and that’s all. But since there’s no way to explicitly say that one resource depends on another, the ordering of your resources in the code may be critical or it may not - there’s no way for a reader to tell by looking at the recipe. Consequently, refactoring and moving code around can be dangerous - just changing the order of resources in a text file may stop things from working.

In Puppet, dependencies are always explicit, and you can reorder your resources freely in the code without affecting the order of application. A resource in Puppet can ‘listen’ for changes to things it depends on: if the Apache config changes, that can automatically trigger an Apache restart. Conversely, resources can ‘notify’ other resources that may be interested in them. (Chef can do this too, but you’re not required to make these relationships explicit - and in my mind that’s a bad thing, though some people disagree. Andrew Clay Shafer has written thoughtfully on this distinction: Puppet, Chef, Dependencies and Worldviews).

Chef fans counter that its behaviour is deterministic: the same changes will be applied in the same order, every time. Steve Traugott and Lance Brown argue for the importance of this property in a paper called Why Order Matters: Turing Equivalence in Automated Systems Administration.

10. Bigger mindshare

Though not a technical consideration, this is probably the most important. When you say ‘configuration management’ to most people (at least people who know what you’re talking about), the usual answer is ‘Puppet’. Puppet owns this space. I know there is a large and helpful community I can call on for help, and even books published on Puppet. Puppet is so widely adopted that virtually every problem you could encounter has already been found and solved by someone.

Conclusion

Currently ‘Chef vs. Puppet’ is a rather unfair comparison. Many of the perceived disadvantages of Chef that mentioned above are largely due to the fact that Chef is very new. Technically, Puppet and Chef have similar capabilities, but Puppet has first mover advantage and has colonised most corners of the configuration management world. One day Chef may catch up, but recommendation today is to go with Puppet.

Have a look here for more information

Manage Your Infrastructure - Puppet

These days when looking to automate the setup and maintenance of even the simplest infrastructure you will typically end up with a decision between two popular configuration management tools, Puppet and Chef. There are other tools, some of which have been around much longer. However, recently the pace at which both Puppet and Chef’s development has increased indicates they’re both rapidly growing.

This article will begin with a look at some of the benefits of using Puppet to manage your infrastructure.

Breaking Down Your Infrastructure into Managable Components

Infrastructure can be relatively complex and only grows in complexity the more pieces you add to support your particular application(s). However, all infrastructure configurations can be broken down into components: individual pieces that are installed, configured and monitored. These components can be as simple as a user or a file, and as complex as multiple servers in a cluster supporting backend data.

Using a configuration management tool requires you to consider these individual pieces and their relationships. Relationships can be between servers or the individual components that make up a server.

For example, deploying a Ruby on Rails application typically requires a database, an application server and web server. These can be configured on a single machine or broken up into several machines, with one for each component. Thinking about these relationships and developing infrastructure that supports these enables you to view each component as a commodity, giving you the power to add, remove or replace each with ease and consistency.

An Overview of Puppet Resources

Puppet uses the term “resources” when describing these components. Resources in Puppet have have a type, a name and attributes that define the configuration of that resource. Here is an example of a resource:

file { "/etc/ntp.conf":
    owner => root,
    group => root,
    mode => 0644,
    source => "puppet:///ntpd/ntp.conf"
}

Resources typically begin with their type, here we are using the “file” type, after which we enclose our resource’s name and attributes in curly brackets. Here you can see our resource’s “name” is “/etc/ntp.conf”, followed by a colon.  Our attributes are anything after the colon up until we close the resource with a curly bracket.

This resource manages a component of our infrastructure, the file located at ”/etc/ntp.conf”. We’ve established that we want this file to be owned by ”root” and have permissions of “0644″. Any node that we choose to run this resource on will have this file configured with these attributes.

Defining Relationships Between Resources

Where Puppet shines, in relation to other tools, is that it empowers you to specify relationships between these resources and the modules they may be defined in. Modules can generally be thought of as a configuration containing each of our three core requirements, installation, configuration and monitoring. Modules in Puppet typically break down to classes, classes are singleton collections of resources.

Continuing with our example above we create an ntpd class as follows:

class ntpd {
        package { "ntp":
            ensure => installed,
        }
 
        file { "/etc/ntp.conf":
            owner => root,
            group => root,
            mode => 0644,
            source => "puppet:///ntpd/ntp.conf",
            require => Package["ntp"]
        }
 
        @service { "ntpd":
            ensure => running,
            enable => true,
            hasrestart => true,
            hasstatus => true,
            require => [Package["ntp"], File["/etc/ntp.conf"]],
            subscribe => File["/etc/ntp.conf"]
        }
    }

Here we’ve established a relationship between installing, configuring and monitoring the ntp daemon. You can see we’ve defined three resource types, “package”, our “file” example from above and “@service” (the ‘@’ is a special syntax for a virtual resource, you can ignore that for now).

As I described above, each resource has a type, a name and attributes. Most of these should be self-explanatory, however the attributes that build the relationships are important.

You can see here that the file resource requires “Package['ntp']“. That simply refers to our package resource. The same requirements are defined for the @service resource, though we add in a dependency upon the file type.

The “subscribe” attribute tells our service type to listen for any changes to our file type so that we know to restart. If we make any changes to “/etc/ntp.conf”, our service will automatically restart on our next Puppet run.

Defining these relationships, Puppet builds a dependency graph in the background. This dependency graph offers you a lot of unique features that other tools don’t provide.

No Operation Mode

For example with this dependency graph we can run our setup in “dry run” mode using the ‘–noop’ flag. This allows us to test out exactly how Puppet will configure our systems. Which is great for any production infrastructure, even if you have “test” or “staging” machines to test on. “Noop” allows you to develop new infrastructure faster before having to deploy. This feature is often over looked when considering the power of Puppet compared to other tools.

Explicit Resource Dependencies

Another feature of using a dependency graph is that in Puppet, resource dependencies are always explicit. You can move resources around freely without worrying about the order of application. In our example above, if I were to move our package resource to another module, this would have no negative consequences on the process of installing and configuring ntpd. Puppet resources can listen and notify other resources that they either depend on or think might be interested. When order is important the relationship between resources must be explicitly specified. Puppet is concerned about the state of your server, and works to bring the configuration into compliance.

These are only a few of the benefits of Puppet’s graph based design. Other options such as virtual resources (which our service resource above is defined as) offer more options in dealing with related resources across similar server structures.

Getting Started with Puppet

Puppet is built with a focus on client/server configuration within an infrastructure. However Puppet provides you with an extremely easy method for getting started. One can run any independant manifest with “puppet apply <manifest>”. Using our example above, if we were to place that ntpd configuration in a file called “ntpd.pp” we could manage that service using only “puppet apply ntpd.pp”. In my experience this is far superier to getting started with standalone clients of other tools. Growing from this single manifest into a larger full blown infrastructure configuration is relatively easy.

Here is an example directory layout taken from NICS presentation. Please note that this is an advanced configuration and is meant to give you an idea of such an implementation:

/etc/puppet/
        auth.conf
        autosign.conf
        fileserver.conf
        puppet.conf
        tagmail.conf
        files/
            byhost/
                host1/
                host2/
                host3/
        manifests/
            nodes.pp
            site.pp
            classes/
                class1.pp
                class2.pp
        modules/
            module1/
                manifests/
                    init.pp
                files/
                templates/

Generally you’ll start by defining a number of modules and import those where necessary. Puppet recognizes servers as “nodes”. We would define our “nodes” in the nodes.pp above. Here is an example of a node configuration:

node "webserver" {
        include ntpd
    }

We have defined a node “webserver” and included our ntpd module. Each time Puppet runs on a server with the hostname “webserver” our ntpd module will be run. If there are discrepencies on the current system, Puppet will restore state back to our configuration.

Puppet, like any software has it’s warts, but you can find those types of discussions elsewhere and blog.

You can exploring the documentation to expand upon what this blog talked about here. You can also find a lot of assistance in the “#puppet” channel on the Freenode IRC network or on their mailing list. 

Googler Eric Clayberg joins Eclipse Foundation Board

Google Software Engineering Manager Eric Clayberg has been elected by the Eclipse community as a Sustaining Member Representative on the Eclipse Foundation Board of Directors for the 2011-12 term. The announcement was made yesterday at the Annual General Meeting during the kick-off of EclipseCon 2011 in Santa Clara, CA. As a member of the Board of Directors, Eric will help oversee the policies and strategic direction of the Eclipse Foundation.

Eric works on the Google Plugin for Eclipse (GPE) team at Google and he was formerly with Instantiations, a company known for its focus on Eclipse Java developer tools, that was acquired by Google in 2010. Eric is also a Project Lead for the new open source WindowBuilder project at Eclipse.org. “I have been involved with Eclipse since 1999 and have always been a strong supporter of Eclipse community interests. I look forward to bringing Google scale thinking and inventiveness to my new role as board member.”

Google has been a longtime supporter of the the Eclipse Community. In addition to open sourcing Eclipse tools, Eclipse Labs is powered by Google Project Hosting and we have hosted Eclipse Days at the Googleplex in 2010, 2009, and 2008. Several Googlers will speak at EclipseCon sessions this year, including:

• WindowBuilder 101 and GWT App start to finish – Eric Clayberg
• GWT App start to finish and Building the Google Plugin for Eclipse: What We Learned – Rajeev Dayal, software engineer on the Google Web Toolkit (GWT) team.
• Android Development with Eclipse – Xavier Ducrohet, Tech lead for the Android SDK and developer tools, and Tor Norbye, software developer on the Android team
• Effective Git – Sean Pearce, lead on JGit project
• GWT App start to finish and Graphical Editing Framework (GEF) 101 – Dan Rubel, software engineer on the GWT team and formerly co-founder of Instantiations and Jaime Wren, Software Engineer on the GWT team

For more information, have a look here

Installation and deployment for Nginx With Phusion Passenger - Ubuntu 10.x

Installation and deployment for Nginx With Phusion Passenger

Steps to install & deploy for Nginx with Passenger

1. Make sure you have installed Ruby and RubyGems

2. Install passenger gem

   $sudo gem install passenger

3. Check the "passenger-install-nginx-module"

$passenger-

passenger-config                  passenger-make-enterprisey        passenger-status
passenger-install-apache2-module  passenger-memory-stats            passenger-stress-test
passenger-install-nginx-module    passenger-spawn-server

4. Install nginx module

$sudo passenger-install-nginx-module

Welcome to the Phusion Passenger Nginx module installer, v3.0.5.

This installer will guide you through the entire installation process. It
shouldn't take more than 5 minutes in total.

Here's what you can expect from the installation process:

     1. This installer will compile and install Nginx with Passenger support.
     2. You'll learn how to configure Passenger in Nginx.
     3. You'll learn how to deploy a Ruby on Rails application.

Don't worry if anything goes wrong. This installer will advise you on how to
solve any problems.

Press Enter to continue, or Ctrl-C to abort.


5. Checking for required software...

 * GNU C++ compiler... found at /usr/bin/g++
 * The 'make' tool... found at /usr/bin/make
 * A download tool like 'wget' or 'curl'... found at /usr/bin/wget
 * Ruby development headers... found
 * OpenSSL support for Ruby... found
 * RubyGems... found
 * Rake... found at /usr/bin/rake
 * rack... found
 * Curl development headers with SSL support... found
 * OpenSSL development headers... found
 * Zlib development headers... found

--------------------------------------------

Automatically download and install Nginx?

Nginx doesn't support loadable modules such as some other web servers do,
so in order to install Nginx with Passenger support, it must be recompiled.

Do you want this installer to download, compile and install Nginx for you?

      1. Yes: download, compile and install Nginx for me. (recommended)
          The easiest way to get started. A stock Nginx 0.8.54 with Passenger
          support, but with no other additional third party modules, will be
          installed for you to a directory of your choice.

     2. No: I want to customize my Nginx installation. (for advanced users)
         Choose this if you want to compile Nginx with more third party modules
         besides Passenger, or if you need to pass additional options to Nginx's
         'configure' script. This installer will  1) ask you for the location of
         the Nginx source code,  2) run the 'configure' script according to your
         instructions, and  3) run 'make install'.

Whichever you choose, if you already have an existing Nginx configuration file,
then it will be preserved.

Enter your choice (1 or 2) or press Ctrl-C to abort:


if Curl development headers with SSL support was not found abort the process then try this command "sudo apt-get install libcurl4-openssl-dev"

6. Choose 1 then you can see download process finally end with

Where do you want to install Nginx to?

Please specify a prefix directory [/opt/nginx]:

press "enter" key if you goahead with default

7. This installer has already modified the configuration file for you! The
following configuration snippet was inserted:

  http {
      ...
      passenger_root /usr/lib/ruby/gems/1.9.1/gems/passenger-3.0.5;
      passenger_ruby /usr/bin/ruby1.9.1;
      ...
  }

After you start Nginx, you are ready to deploy any number of Ruby on Rails
applications on Nginx.


Press ENTER to continue.

8. Deploying a Ruby on Rails application: an example

Suppose you have a Ruby on Rails application in /somewhere. Add a server block
to your Nginx configuration file, set its root to /somewhere/public, and set
'passenger_enabled on', like this:

   server {
      listen 80;
      server_name www.yourhost.com;
      root /somewhere/public;   # <--- be sure to point to 'public'!
      passenger_enabled on;
   }

And that's it! You may also want to check the Users Guide for security and
optimization tips and other useful information:

  /usr/lib/ruby/gems/1.9.1/gems/passenger-3.0.5/doc/Users guide Nginx.html

Enjoy Phusion Passenger, a product of Phusion (www.phusion.nl) :-)
http://www.modrails.com/

Phusion Passenger is a trademark of Hongli Lai & Ninh Bui.

Copy the entire server part - "server { ... }"

9. Open nginx config file

   $sudo vim /opt/nginx/conf/nginx.conf


    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

   server {
      listen 80;
      server_name example.com;
      root /home/user/demo;   # <--- be sure to point to 'public'!
      passenger_enabled on;
      rails_env development;
   }


    server {
        listen       80;
        server_name  localhost;

        ....


Add the copied server part after "keepalive_timeout" line

10. Change the "server","root", "rails_env" based on your machine


11. Restart the server by this command

    sudo /opt/nginx/sbin/nginx

   
Hope you may install "Nginx With Phusion Passenger" without any issues by above steps.
 

Tech tips - Install Ruby and RubyGems

Here is one of the simple steps to install ruby and RubyGems on Ubuntu 10.x


1. Run this command on terminal

$sudo apt-get install ruby1.9.1-full

2. Download the latest RubyGems from here

https://rubygems.org/pages/download

3. Unpack into a directory and cd here

4. Run this command (you may need admin/root privilege)

ruby setup.rb

Check the ruby, Gem version and environment settings

$ruby -v && gem -v && gem env

That's it. Hope it may help you

What’s New With Blogger

Chang Kim - Blogger, Product manager announced his blog is that 2010 was a big year for Blogger. We cemented ourselves as one of the largest blogging platforms and the sixth largest website in the world, according to Alexa. Blogger users published more than half a billion blog posts, which were read by more than 400 million active readers across the globe. We introduced template designer, real-time stats, comments spam filtering, mobile templates, web fonts, and more. And to top it all off, we were dubbed the most reliable blogging service around.

2011 promises to be another exciting year.

To start, we’re kicking things off at SXSW by giving folks a sneak peek at our next-generation user interface. The new design is not only cleaner and more modern, but it also uses Google Web Toolkit, delivering the latest in web technology.

Current post editor

New post editor

Current dashboard

New dashboard

We’ll also be showcasing our new content discovery feature that lets you uncover interesting and related content based on the topics of the blog you’re currently reading.

These are just a couple of new features we want to share with you. We look forward to unveiling more throughout 2011!

If you’re in Austin for SXSW, be sure to visit us at the Google booth—or come by and enjoy a drink with us tonight at our annual Blogger bash.

Have a look more information here

Selenium in headless with Xvfb under RUBY

How to manage to get Selenium (browser => “firefox”) running under headless state (click here to know more on this) .

Now we need Xvfb to accomplish this dirty task.
For Ubuntu the package is fairly straight forward just type in the command

sudo aptitude install Xvfb

Under Fedora the same can be achieve using command .

sudo yum install xorg-x11-server-Xvfb

For more on Xvfb package  check your distribution provider .
Now start the Xvfb .

Xvfb -ac :99 &

The above command start the Xvfb in background with name Display=:99 .
Now to accomplish Selenium to work under headless state we need .

1. Selenium RC Server [here] .
2. Selenium Client Drivers .

more on both can be found here .
Start the Selenium RC Server .

java -jar selenium-server-standalone-2.0b2.jar &

The above command basically start the Selenium-RC-Server on  http://localhost:4444.
Now install selenium-webdriver [a.k.a Selenium Client Drivers] .
Note : Get your specific Selenium Client Driver based on language you prefer .

sudo gem install selenium-webdriver

Installation should work with any possible errors .
Now start your irb console .

require "rubygems" require "selenium-webdriver" s1 = Selenium::WebDriver::Remote.new :url => "http://localhost:4444/wb/pub" s1.get "http://example.com" s1.page_source

Selenium running under headless state .
Now there are couple of handy methods I want you to know before I say enough for this post 
Suppose you need to capture ScreenShoot of the visited page by Selenium .
To achieve this all you need to do is .

s1.save_screenshoot "example.png" Hope it may help you. For more information click here

Tech Tips - Install Scala on Ubuntu 9.x

Here are simple steps to install Scala on Ubuntu

1.Get the latest Scala from here

2.Go to .bashrc(/home/username/.bashrc) file and add this line
export SCALA_HOME='/home/username/scala-2.8.1';

3.Make sure you exported scala bin path at the end with PATH
Example:
export SCALA_HOME='/home/username/scala-2.8.1';
export PATH=${PATH}:$SCALA_HOME/bin;

4.Open a new terminal instance try this command
:~$ scala
Welcome to Scala version 2.8.1.final (OpenJDK Server VM, Java 1.6.0_18).
Type in expressions to have them evaluated.
Type :help for more information.

scala>

Tech Talk - Git's one of primary author

Junio C Hamano is a software engineer in the Google Open Source Programs Office who works on the open source project Git. Git is an increasingly popular distributed version control system that is used by many open source projects including Android, Chrome OS, and the Linux kernel. Jun is the maintainer and one of the primary authors of Git, with 4426 commits!

Jeremy Allison, co-creator of Samba and fellow Open Source Programs Office team member, recently sat down with Jun for some quality Geek Time. Samba uses Git, so there was plenty to talk about! Here are some highlights:

• Jun and Jeremy discuss how Jun began working on open source after the maintainer of GNU’s source control system RCS, Paul Eggert, began mentoring him. (0:56)

• Jun explains why he prefers working within the open source software development model. (2:50)

• Jeremy asks Jun how he became interested and involved with Git. (3:27)

• When Jun first started working on Git, he had to balance his time between working on an open source project with a day job. Jun reveals his secret for making this balance work, and also how he eventually integrated Git into his day job. (7:00)

• Jun and Jeremy discuss the growing popularity of Git in comparison to older version control systems, and Jun gives an overview of some of Git’s features that set it apart. (9:28)

• Jeremy shares his one criticism of Git, which is that it’s hard to use. Jun responds and offers some suggestions for those who are new to Git. (12:48)

• Jun reveals some longer-term goals for Git as well as some new developments for future releases. (17:44)

• Jeremy asks Jun how he ended up at Google and they talk about Git’s growing role within Google. (19:24)

• Jun gives advice to developers who are new to open source and want to get involved. (21:50)

Checkout here for more information.

MySQL Workbench 5.2.32 GA Available

MySQL Workbench Team proud to announce the next release of MySQL Workbench, version 5.2.32. This is a maintenance release featuring
a new and improved UI appearance and several corrections and other enhancements.
The tabbed interface has been refreshed to obtain a clearer separation between different modules of Workbench, while improving responsiveness when switching between tabs. The Query Formatter has been rewritten and is now faster and more robust on its handling of queries. The layout of the Administration module has been changed to allow for easier future expansion and use less vertical screen space. Parts that had problems managing MySQL 5.5 servers have been fixed along other total of 53 bugs or enhancement requests have been addressed.

MySQL Workbench 5.2 GA

• Data Modeling
• Query (replaces the old MySQL Query Browser)
• Administration (replaces the old MySQL Administrator)

Sources and binary packages are available for several platforms, including Windows, Mac OS X and Linux.

http://dev.mysql.com/downloads/workbench/

To get started quickly, please take a look at this short tutorial.
MySQL Workbench 5.2 RC Tutorial

http://wb.mysql.com/?p=406

Workbench Documentation can be found here.

http://dev.mysql.com/doc/workbench/en/index.html

In addition to the new Query/SQL Development and Administration modules, version 5.2 features improved stability and performance – especially in Windows, where OpenGL support has been enhanced and the UI was optimized to offer better responsiveness.
This release also includes improvements to the scripting capabilities of the SQL Editor. You can read more about it in

http://wb.mysql.com/workbench/doc/

For a detailed list of resolved issues, see the change log.

http://dev.mysql.com/doc/workbench/en/wb-change-history.html

PyCon 2011

As many of you may know, Python is one of the official languages at Google. Guido van Rossum, the creator of Python, is a Googler too—so naturally we’re thrilled to be supporting PyCon 2011 USA, the largest annual gathering for the community using and developing the open-source Python programming language. The PyCon conference days will be March 11th to the 13th, preceded by two tutorial days, March 9th and 10th. For those of you with coding in mind, the Sprints run afterwards from March 14th-17th. All-in-all that’s nine days of Python nirvana!!

In addition to having many Googlers in attendance, some of us will be presenting as well.

• On Wednesday, March 9th at 2 PM, I will be leading a Google App Engine tutorial with fellow teammate Ikai Lan. Tutorials have gotten so popular at PyCon, they’ve now been expanded into a two-day affair!

• On Friday the 11th, the very first day of sessions, App Engine engineer Brett Slatkin will kick things off with his talk, “Creating Complex Data Pipelines in the Cloud” using the new App Engine Pipeline API at 10:25 AM.

• After lunch on Friday, Wesley Chun will take his Google hat off momentarily to discuss Python 3 in the talk subtitled “The Next Generation is Here Already” at 1:35 PM. It is mostly a repeat of the well-received talk I gave last year but with updates. The main point is to introduce folks to the next version of the language and discuss how its backwards-incompatibility will affect users, when users should port their apps to Python 3, what the differences from Python 2 are, etc.

• On Saturday morning at 9:25 AM, Python creator, BDFL, and App Engine engineer Guido van Rossum will do his annual Q&A session for all conference attendees in a fireside chat session.

• Later Saturday morning at 11:05 AM, Wesley Chun looking forward to speaking about “Running Django Apps on Google App Engine.” it’s a relatively new topic, but it represents a major change for Django developers: being able to write Django apps that run on NoSQL or non-relational databases -- it’s been only RDBMSs all this time. Furthermore, with Django-nonrel, you can move Django projects/apps between traditional hosting and App Engine, helping to break that “vendor lock-in” issue that many have had concerns about when hosting apps in the cloud. A good part of my talk does focus on porting apps from App Engine to Django however.

• Right after my talk, at 11:45 AM comes another famous Googler, author of Python in a Nutshell, co-editor of the Python Cookbook, and a long-time member of the Python community, Alex Martelli. Alex’s invited talk on “API Design anti-patterns” will be insightful and cerebral, sure to cause many future hallway discussions.

• Late Saturday afternoon at 4:15 PM, Google engineer Augie Fackler will deliver his talk entitled, “HTTP in Python: which library for what task?” There are many libraries that do HTTP. Which ones should you use and when? What are the benefits and tradeoffs?

• Finally, several members of the Google App Engine team, App Engine forum gurus, and experienced App Engine users are attending PyCon this year. Wesley Chun hoping to establish an OpenSpace session one of the conference evenings where we can meet other users, chat about best practices, and do some informal Q&A letting people ask anything they want (except “When will you support newer versions of Python?”). :-)

You can find the entire PyCon schedule online. It’s interactive if you log-in, allowing you to bookmark sessions you’re interested in attending. This will be PyCon’s biggest year yet, so hopefully you can join us in Atlanta next week! Keep an eye out on the PyCon blog to get the latest news, and be sure to follow the Twitter hashtag (#pycon).

We invite you to join Google team members at all our talks, plus stop by our booth to meet our technical staff as they demo select developer tools and APIs. We’ll have handouts there and also encourage you to try a short coding puzzle for a prize!

Have a look Google's announcement for more information.

Zend Framework 1.11.4 Released

The Zend Framework team announces the immediate availability of Zend Framework 1.11.4, It's fourth maintenance release in the 1.11 series. This release includes almost 40 bug fixes.
You may download ZF 1.11.4 from the Zend Framework site.
For a full list of resolved issues, you can visit the changelog:

http://framework.zend.com/changelog/1.11.4

This version includes two notable changes.
First, Zend's own Enrico Zimuel has completed work on a WinCache adapter for Zend Framework's Zend_Cache component. If you deploy on Windows, you now have the option of using WinCache for caching.
Second, a minor security issue when running in development mode and using the view script generated for error pages by Zend_Tool has been corrected; please see the security announcement for details on the vulnerability and how you may correct the issue in your current and future projects.
I'd like to thank everyone who contributed code to these releases, including those who submitted patches, translated documentation, or reported issues. Keep your eyes peeled for another maintenance release at the end of next month!

Linux Foundation - Jim Zemlin talk about Linux future

Jim Zemlin is the Executive Director of the Linux Foundation, and earlier this month he sat down with the Open Source Programs Office’s Jeremy Allison for a chat about the future of Linux. In addition to talking about the future, Jim shares insights on the history and significance of Linux. Some highlights:

• Jim explains the role of the Linux Foundation in Linux kernel development, including the work of Linus Torvalds. (0:18)

• Jeremy and Jim talk about the organizations that support the Linux Foundation, and their reasons for doing so. (2:21)

• Jim is well known for his presentations for the Linux Foundation, and Jeremy asks Jim to delve further into the topic of one of his talks, where he describes his vision of “Linux Everywhere.” (4:55)

• Jeremy poses one of his favorite questions: “Is this the year of the Linux desktop?” Jim responds with less concern about desktop computers and focuses his interest on mobile devices, which are becoming predominately Linux. (9:33)

• The discussion turns toward tablet devices and their impact on Linux. (13:25)

• Linux’s GPLv2 license allows DRM, and Jeremy wonders if this contradicts the ideals of freedom that Linux was built upon. Jim compares the controversy to the “Consume vs. Contribute” issue that Linux faced years ago. In that case, the collaborative nature of open source software development made it advantageous for everyone to contribute, so most commercial users eventually ended up contributing. In regards to DRM, Jim believes that consumer dictate will direct the future of DRM products. (15:23)

• Jim recounts a conversation he had with a major electronics company about the importance and complexity of software on consumer electronic devices. Jim explains how these considerations direct manufacturers towards open source software. (20:32)

• Jeremy asks Jim about the feasibility of creating an operating system from scratch, or if Linux is the only viable option. The value of Linux was recently estimated at $10.8 billion, so the barrier to entry is extremely high. In addition, there are several incentives for using the existing Linux ecosystem. (23:07)

• Jim talks about how advances in one field of Linux has benefited other fields. For example, developers working on mobile devices helped reduce power consumption for those working on high-performance computing. (26:58)

• Jim shares how his career path led him to his current role at the Linux Foundation. (31:05)

Have a look here for more information from original post.