Step 8 In your blog, answer these questions:

Topic 1 What is Git? Why is it useful?

Git is an open source distributed revision control system with an emphasis on being fast and small. Git is written mostly in C and was initially designed and developed by Linux Torvalds for Linux kernel development. Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server. (http://en.wikipedia.org/wiki/Git_%28software%29)

GIT is designed in order to handle small as well as the large projects with efficiency. This GIT does not depend on network access or the central server.

Advantages:

Portability

Adoption

-         Source code hosting

-         Can handle different project using Git

-         Working with other repositories

Topic 2 Describe how Sinatra relates to Ruby on Rails.

Sinatra will be written in the programming language called Ruby.

While, Ruby on Rails and Sinatra is not a Model-View-Controller (MVC) based framework

Sinatra is very simple but powerful DSL to define RESTful HTTP actions.

Sinatra also defines how the applications are going to response.

As we have already see in hello word example:

require 'rubygems'

require 'sinatra' get '/' do    "Hello world" end

As per Evans, the application code of Sinatra is very simple and small and it is implemented as a Mongrel handler (Evans, 2007).

Topic 3 What is Heroku? What is a Heroku “Dyno”? Describe how Heroku makes deployment and scaling of Ruby web applications easy.  

Heroku is the instant ruby platform. Deploy any ruby app instantly with a simple and familiar git push. Take advantage of advanced features like HTTP caching, memcached, rack middleware, and instant scaling built into every app. Never think about hosting or servers again. Heroku is a multi-tenant platform and hosting environment. Your app doesn’t need its own servers, slices, or clusters, and you’ll benefit from continuous platform improvements. Each element in this diagram represents a large pool of servers invisibly managed by Heroku. Because we control all the infrastructure and software layers, we can present a clean interface for deploying your code.

What is a Heroku “Dyno”?

A dyno is roughly equivalent to an individual Mongrel, Thin, or FastCGI backend in traditional Ruby deployment environments. In fact, Heroku uses Thin at the core of its dyno architecture, so you can think of dynos as having the same constraints as individual Thin processes.

What makes a dyno unique is not the individual Thin process but the features enabled by the rest of the Heroku platform.

Elasticity: The number of dynos allocated for your app can be increased or decreased at any time – without server provisioning of any kind.

Intelligent routing: The routing mesh tracks the availability of each dyno and balances load accordingly. Requests are routed to a dyno only once it becomes available. If a dyno is tied up due to a long-running request, the request is routed to another dyno instead of piling up on the unavailable dyno’s backlog.

Process management: Each dyno process is monitored for responsiveness. Misbehaving dynos are taken down and new dynos are launched in their place.

Distribution and redundancy: Dynos are distributed across a large cluster of machines called the “dyno grid”. An app configured with two dynos is running two processes, as you'd expect, but each process is running on a separate machine. If a machine goes down, your site stays up – even with only two dynos.

Describe how Heroku makes deployment and scaling of Ruby web applications easy.

Dyno processes run in a partitioned Unix environment within a standard Ruby VM (Ruby version details). There are no Heroku specific APIs. Dynos are free to use any frameworks, gems, libraries, or network services (outbound network connections are allowed) available. In most cases, standard Ruby web apps just work.

Filesystem

The ./tmp and ./log directories are writeable but their contents are not shared between multiple dyno processes. The rest of the filesystem is read-only and contains the app’s source files.

It’s not possible to use the filesystem to store data between requests, since dynos can’t see each others writeable data. The Application Constraints topic has more on the read-only filesystem, including techniques for accomplishing tasks that traditionally required shared disk access.

Environment variables

Heroku uses standard Unix environment variables to provide dyno processes with information about the system and configured Heroku network services. For instance, the DATABASE_URL environment variable specifies the network location of the app’s PostgreSQL database; similarly, MEMCACHED_SERVERS contains the IP list of all servers in the app’s memcached cluster (for app’s that have enabled the memcached add-on). You can also manage a custom environment variables with Config vars.

 

Topic 4 Inspect the Hello World application “app.rb” file. Answer these questions:

a.     What is the purpose of the “/param/:name” method?

b.     What happens when the user navigates to the /home page?

c.     What is the purpose of the :set directive?