Object o = Class.forName("className").newInstance()

lo curioso es que vi que no necesitaba esta solución, que mi problema era otro , sin embargo la curiosidad pudo más que la necesidad.

Esperaba utilizar para ello la misma clase: Class, sin embargo descubrí que no podía hacerlo así. En Ruby el camino es distinto. Un post en stackoverflow me llevó a encontrar una solución múltiple, aquí las distintas posibilidades:

Object::const_get('String').new()

class_name = 'String'
eval(class_name).new

Module.const_get('Array').new

Y un helper:

"String".constantize.new

Module.const_get no funciona con clases anidadas en módulos, digamos que no admite la sintaxis Admin::Folder, debido a que sólo reconoce sintaxis válidas para dar nombre a una constante.

eval, por el contrario sí permite nombres de clases con namespaces, aunque sufrimos un decrimento en el rendimiento.

Podríamos comprobar el rendimiento de todas ellas con un simple script:

#class_instanciation.rb
#!/usr/bin/env ruby
#
#  Created by  on 2008-11-24.

require 'benchmark'
require 'qualified_const_get'

n = 1000000

Benchmark.bmbm(10) do |rpt|
rpt.report("simple") do
n.times {Array.new}
end

rpt.report("Object::const_get") do
n.times {Object::const_get('Array').new()}
end

rpt.report("Kernel.const_get") do
n.times {Kernel.const_get('Array').new}
end

rpt.report("Kernel.qualified_const_get") do
n.times {Kernel.qualified_const_get('Array').new}
end

rpt.report("eval") do
n.times {eval('Array').new}
end

# no funciona!!
#rpt.report("eval") do
#  n.times {"String".constantize.new}
#end
end

#qualified_const_get.rb
module Kernel
def qualified_const_get(str)
path = str.to_s.split('::')
from_root = path[0].empty?
if from_root
from_root = []
path = path[1..-1]
else
start_ns = ((Class === self)||(Module === self)) ? self : self.class
from_root = start_ns.to_s.split('::')
end
until from_root.empty?
begin
return (from_root+path).inject(Object) { |ns,name| ns.const_get(name) }
rescue NameError
from_root.delete_at(-1)
end
end
path.inject(Object) { |ns,name| ns.const_get(name) }
end
end

Los resultados obtenidos los podéis ver en la siguiente gráfica:

en ella podemos apreciar que si utilizamos const_get se tarda aproximadamente 2 veces más que con la creación normal; que el uso de eval nos hace emplear 5 veces más tiempo y que sin duda la implementación de qualified_const_get no es nada buena, dado que nos hace emplear unos 10sg! osea unas 15 veces más.

La recomendación sería utilizar const_get siempre que se pueda, es decir mientras nuestra clase no tenga namespaces y eval cuando no quede más remedio. El caso de qualified_const_get, me parece poco apropiado para cualquier caso.

Por otro lado, el caso de constantize, no terminó de funcionar, por lo que es imposible compararlo.

Ahora os voy a mostrar cómo se podría construir la nube de tags partiendo de lo que hicimos.

Lo primero, es que nuestra aplicación necesita utilizar un método llamado tag_cloud, que es el que se va a encargar de pintar la nube de tags, para ello hacemos que nuestro AplicationHelper incluya el helper que contiene el método:

module ApplicationHelper
  include TagsHelper
end

Nos basta con añadir esto al helper del controlador concreto, pero dada la implementación del plugin creo que querréis crear más nubes de tags para otros modelos, por lo que he preferido tener disponible estos métodos para toda la aplicación.

Ahora Necesitamos cargar en nuestro controlador lo que va a ser mostrado en la vista:

@tags = Entry.tag_counts

Y por último nos vamos a la vista y añadimos la nube de tags:

<% tag_cloud @tags, %w(css1 css2 css3 css4 css5) do |tag, css_class| %>
    <%= link_to tag.name, { :action => :tag, :id => tag.name }, :class => css_class %>
  <% end %>

para que esta pueda tener el efecto adecuado, necestitáis definir los siguiente estilos en la vista:

.css1 { font-size: 1.0em; }
.css2 { font-size: 1.4em; }
.css3 { font-size: 1.6em; }
.css4 { font-size: 1.8em; }
.css5 { font-size: 2em; }

estos deberíais adaptarlos en tamaño según vuestro diseño, ¿sencillo verdad?

La historia de este plugin, es que David Heinemeier Hansson creó un plugin para poder poner tags a sus modelos, llamado: acts_as_taggable, sin embargo alguien decidió hacerle unos añadidos para convertirlo en más actual, haciendo que el nuevo plugin tuviese:

[...] extras such as tests, smarter tag assignment, and tag cloud calculations.

Este nuevo plugin recibió el nombre de acts_as_taggable_on_steroids y es obra de Jonathan Viney.

Para instalarlo, nuestro primer paso debe ser:

script/plugin install http://svn.viney.net.nz/things/rails/plugins/acts_as_taggable_on_steroids

Tras esto, debemos generar una migración para poder crear la tablas en las que se guardaran los datos:

script/generate acts_as_taggable_migration

Esto nos genera:

004_acts_as_taggable_migration.rb

el número no tiene porqué coincidir con el vuestro; aplicamos la migración:

rake db:migrate

Y ahora ya sólo nos queda hacer que nuestro controlador sea tageable:

class Entry < ActiveRecord::Base
  acts_as_taggable
end

Para añadir tags en el formulario de edición o en el de creación de nuestro modelo concreto, en nuestro caso: entries/new.html.erb y entries/edit.html.erb, basta con la siguiente línea de código:

<%= f.text_field :tag_list %>

así nuestras entradas utilizarán tags y se guardarán.

Nuestro modelo cuenta con una serie de métodos para jugar con tags. Uno que debéis esperar, al ver como he llamado al text_field de los tags, es sin duda:

entry.tag_list = "ruby, rails"
entry.save

Con él añadimos los tags a entry, tras grabarlo.

Podemos añadir a una lista ya existente:

entry.tag_list.add("languages", "article")

borrar una etiqueta concreta:

entry.tag_list.remove("ruby")

Podemos encontrar las entradas taggeadas con unas determinadas tags:

Entry.find_tagged_with('ruby, rails')

Esto nos traera objetos que contenga cualquiera de las dos tags, si queremos que contengan las dos o más, tenemos que usar match_all.

Entry.find_tagged_with('ruby, rails', :match_all => true)

Por defecto el delimitador es una coma, si deseamos cambiarlo, también tenemos esa opción:

TagList.delimiter = " "

añadido al config/environment.rb, quedaría cambiado el delimitador.

En mi caso quería utilizar mi dominio particular que utiliza Google Apps para ello. Recordé haber leido antes acerca de cómo hacerlo con gmail, en el blog de Jaime Iniesta utilizando: action_mailer_tls.

El problema al utilizar Google Apps, al igual que si utilizásemos Gmail es que utiliza el protocolo TLS, por eso no podemos utilizar el mailer normal de Rails, de ahí que tengamos que instalar este plugin.

Así que seguimos el consejo de Jaime e instalamos el plugin:

script/plugin install http://code.openrain.com/rails/action_mailer_tls/

Siguiendo con lo que dice en su blog:

Una vez instalado, en la carpeta /vendor/plugins/action_mailer_tls/sample encontrarás dos ficheros. Copia smtp_gmail.rb dentro de tu carpeta /config/initializers, y copia mailer.yml.sample a tu carpeta /config, renombrándolo a mailer.yml. Finalmente, edita este fichero para usar el user_name y password de la cuenta de correo de Gmail que quieras usar… reinicia el servidor y… ya puedes enviar correos a través de Gmail desde tu aplicación!

El fichero config/mailer.yml que en nuestro caso hemos creado es de la forma:

:address: smtp.gmail.com
:port: 587
:user_name: youraccount@yourdomain.com
:password: xxxx
:authentication: :plain

en esto debes sustituir xxxx por la password de tu cuenta y youraccount@yourdomain.com por tu cuenta de correo asociada a Google Apps.

Continuamos creando el mailer para poder enviar los mails:

weemac:blogg jenaiz$ script/generate mailer commentmailer
exists app/models/
create app/views/commentmailer
exists test/unit/
create test/fixtures/commentmailer
create app/models/commentmailer.rb
create test/unit/commentmailer_test.rb

Debemos crear el método con el que vamos a hacer el envio del mail que situamos en el Mailer recién creado:

class Commentmailer < ActionMailer::Base
  def comment(comment)
    @recipients   = 'jesus.navarrete@gmail.com'
    @from         = 'support@jenaiz.com'
    headers         "Reply-to" => "support@jenaiz.com"
    @subject      = "jenaiz.com ha recibido un comentario"
    @sent_on      = Time.now
    @content_type = "text/html"

    body[:name] = comment.author
    body[:text] = comment.body
  end
end

Ahora, necesitamos crear los templates, dado que hemos especificado como content_type text/html, crearemos dos templates en views/commentmailer: comment.text.plain.erb y comment.text.html.erb

comment.text.html.erb
jenaiz.com ha recibido un comentario de: <%= @name %>.

Diciendo:
<%= @text %>

Producido en la entrada: <%= @entry%>


comment.text.plain.erb
jenaiz.com ha recibido un comentario de: <%= @name %>.

Diciendo:
<%= @text %>

Producido en la entrada: <%= @entry%>

Ahora hacemos la llamada al método del mailer, basta con:

Commentmailer.deliver_comment(comment)

en nuestro caso esto se meterá dentro del código del comentario normal:

 def comment

    if verify_recaptcha
      @entry = Entry.find(params[:id])
      comment = Comment.new(params[:comment])
      @entry.add_comment comment
      comment.save!

      Commentmailer.deliver_comment(comment)
      flash[:notice] = "Comentario añadido con éxito"
    else
      flash[:error] = "There was an error with the recaptcha code below. Please re-enter the code and click submit."
    end
    redirect_to :action => 'show'
  end

Desde ahora podremos recibir correos cada vez que un comentario sea publicado en nuestra web, además de tener disponible esta posibilidad para otras acciones.

[jenaiz@barracuda current]$ rake db:migrate VERSION=3 RAILS_ENV=staging
(in /home/jenaiz/app/proyecto/releases/20080821085746)
rake aborted!
Multiple migrations have the version number 4

Lo que nos trasmite el error es que tenemos dos migrations con la misma versión, osea que dentro de la carpeta db/migrate poseemos dos ficheros cuya versión es igual, sirva como ejemplo mi caso:

004_add_column_visible_to_tag.rb
004_add_column_for_children_to_tag.rb

¿Extraño? Pues la verdad es que en mi caso ha sido porque había borrado un fichero del svn y no había actualizado bien, luego había creado otro con el mismo número de versión y distinto nombre, por lo que al desplegar en el servidor, he encontrado el problema.

Esta situación, no es extraña que se produzca, podría darse si varios desarrolladores crean una migration de forma simultánea y luego envían sus cambios al svn, si no tienen cuidado con el número de su versión, podrían coincidir; lo más probable en estos casos es que el nombre del fichero no coincida de forma exacta, pero sí la versión, por lo que al hacer update al svn o cvs no veríamos nada extraño.

Un caso similar lo plantea Scott Mitchell y un comentario le devuelve el error que habéis visto arriba. No sé porqué, pero en cuando he llegado a la parte de los dos desarrolladores, rápidamente he ido a comprobar lo que había en mi repositorio, para comprobar que el fichero que había borrado en un paso anterior se había borrado, pero no, seguía allí… colleja para mi .

Para solventar el problema, Christopher J. Bottaro ha creado un plugin que corrige esto: migration_izzle. Como el bien explica mantiene un histórico en la base de datos de los scripts ejecutados, os remito a la documentación para que le echéis un vistazo, yo por mi parte no voy a tardar en probarlo.

Paso uno e indispensable, instalación del plugin:

script/plugin install http://svn.ambethia.com/pub/rails/plugins/recaptcha

Si queréis, podéis utilizar la última versión del plugin, que está alojada ahora en github, por lo que si no habéis experimentado con git aún, os lo recomiendo como experiencia para empezar a utiliar git.

Por si os interesa lo anterior, el plugin ahora se encuentra en: http://github.com/ambethia/recaptcha.

Lo primero que os recomiendo es que vayáis a Recaptcha y obtengáis vuestras llaves, pública y privada, que hacen falta para poder utilizar el plugin; en mi caso ya las estaba utilizando en este blog. No os las pego por seguridad y porque no os servirían, dado que están asociadas a la url en cuestión.

Una vez las tenéis, deben ser añadidas a environment.rb de la forma:

ENV['RECAPTCHA_PUBLIC_KEY'] = 'tullavepublica'
ENV['RECAPTCHA_PRIVATE_KEY'] = 'tullaveprivada'

En la vista, para mostrarlo, sólo tendríamos que añadir:

<%= recaptcha_tags %>

en caso de estar utilizando ssl, deberéis cambiarlo a:

<%= recaptcha_tags :ssl => true %>

Y ahora en nuestro método de publicación, debéis comprobar la validez del Recaptcha, de la forma:

if verify_recaptcha
      ...
      else
      flash[:error] = "Ha habido un error en el envio."
      render :action => 'show'
    end

Nosotros lo utilizamos para publicar comentarios, por lo que el método en cuestión queda como sigue:

if verify_recaptcha
      @entry = Entry.find(params[:id])
      comment = Comment.new(params[:comment])
      @entry.add_comment comment
      comment.save!
      flash[:notice] = "Comentario añadido con éxito"
    else
      flash[:error] = "Ha habido un error en el envio del comentario."
    end
    redirect_to :action => 'show'

Pues nada, listo, ya tenéis validación con Recaptcha en vuestros comentarios.

Para poder comentar nuestras entradas, vamos a generar un scaffold llamado Entry:

script/generate scaffold Entry title:string body:text create_at:datetime draft:boolean

Empezamos por instalar el plugin:

script/plugin install http://juixe.com/svn/acts_as_commentable

Necesitamos crear una migración para contener la tabla de comentarios, dado que el plugin no la crea por nosotros:

script/generate migration create_comments

Esto nos genera un fichero en db/migrate cuyo nombre es XXX_create_comments.rb; XXX es un número, que dependerá de nuestro contenido en el directorio anterior, en mi caso es 002_create_comments.rb, el contenido que debemos copiar en dicho fichero es:

class CreateComments < ActiveRecord::Migration
  def self.up
    create_table :comments, :force => true do |t|
      t.column :author, :string, :limit => 50, :default => ""
      t.column :email, :string, :limit => 100, :default => ""
      t.column :website, :string, :limit => 100, :default => ""
      t.column :body, :text, :default => ""
      t.column :created_at, :datetime, :null => false
      t.column :commentable_id, :integer, :default => 0, :null => false
      t.column :commentable_type, :string, :limit => 15, :default => "", :null => false
      t.column :user_id, :integer, :default => 0, :null => false
    end

    add_index :comments, ["user_id"], :name => "fk_comments_user"
  end

  def self.down
    drop_table :comments
  end
end

ejecutamos el proceso de migración, para poder empezar a usar la tabla:

rake db:migrate

Para que nuestro modelo Entry empieze a ser comentable, necesitamos añadirle lo siguiente:

class Entry < ActiveRecord::Base
  acts_as_commentable
end

A partir de este momento, tenemos todo listo. Aunque ahora necesitamos utilizarlo, para ello, primero cambiamos la vista de las entradas para que puedan ser comentadas cuando las estemos viendo. Así que modificamos el fichero entries/show.html.erb, y añadimos:

<%= render :partial => 'comment',  bject => @entries %>

Creamos el fichero _comment.html.erb:

Comments
<% if @entry.comments.count != 0%>
    <% for comment in @entry.comments %>
    <%= comment.author%> said <%= distance_of_time_in_words(Time.now,comment.created_at) %>.
    	<%= comment.body %>
    <% end %>
<% end %>

<%= form_tag :action => "comment", :id => @entry do %>
  <%= text_field 'comment', 'author'  %> name (required)
 	<%= text_field 'comment', 'email'  %> email ( will not be shown ) (required)
 	<%= text_field 'comment', 'website'  %> website
	<%= text_area "comment", "body" %>
	<%= submit_tag "Comment!" %>
<%= end_tag %>
(falta añadir los saltos de línea correspondientes)

comment:

 def comment
      @entry = Entry.find(params[:id])
      comment = Comment.new(params[:comment])
      @entry.add_comment comment
      comment.save!

      Commentmailer.deliver_comment(comment)
      flash[:notice] = "Comentario añadido con éxito"
      redirect_to :action => 'show'
  end

La creación del comentario es recogiendo los parámetros del formulario, aunque la parte importante es cómo manejar los comentarios, cómo añadírselo a una entrada:

@entry.add_comment comment

Si os habéis fijado, la tabla añade una columna user_id, de esta forma tenemos asociados los comentarios a los usuarios. De tal forma que podremos hacer búsquedas como:

comments = Comment.find_comments_by_user(user)

De tal forma que obtendríamos todos los comentarios para un usuario dado. O podríamos obtener los comentarios de un usuario para las entradas:

postComments = Entry.find_comments_by_user(user)

Por si os entra la vena investidadora, os diré que en la tabla hay un par de columnas “mágicas” que crean la relación con los distintos modelos que quisieramos comentar:

commentable_id >> almacena el identificador de lo que comentemos
commentable_type >> almacena el tipo de lo que comentemos, en nuestro caso Entry

En otros entornos de desarrollo esto se soluciona gráficamente, añadiendo un icono pequeño a cada archivo de tal forma que podemos saber el estado que tiene. Para TextMate existe una solución: SVNmate.

La instalación es bastante sencilla, el zip contiene un archivo llamado SVNMate.tmplugin que con doble click, se añadirá directamente a TextMate. Podéis corroborarlo entrando en las Preferences, allí podréis visualizar un menú similar a:

Ahora necesitáis reiniciar y todos vuestros archivos adquirirán el icono del estado con respecto al svn.

Existe una pequeña pega: si modificas un archivo, el directorio inmediatamente superior queda como modificado por lo cual sabes que dentro existen cambios para hacer commit, pero por encima de esto ningún otro directorio muestra modificaciones. Un pantallazo de mi entorno de desarrollo os lo aclarará mejor:

Esto hace que mientras trabajas con los directorios desplegados sabes más o menos como estás, pero que si los tienes comprimidos, realmente tienes parte del problema por el cual instalé el plugin.

¿Alguno sabéis si esto es configurable? ¿Habéis utilizado otro plugin?

Update: Para hacer commits, updates, add file, etc. directamente seleccionamos un fichero y luego pulsamos a la vez: ctrl + shift + a.

Algunas de las funcionalidades aportadas son:

• avanzar y retroceder en nuestro código mientras debugeamos.
• ejecutar o saltar líneas de codigo
• listar el contexto actual en el que estamos detenidos
• realizar cambios en caliente sobre el código y poder recargar
• usar el modo irb, además de tener un modo consola propio más potente que el anterior

Para comenzar a utilizarlo, basta con tenerlo instalado, para ello:

sudo gem install ruby-debug

He observado que en algunos lugares, te recomiendan estar atento a la instalación, para seleccionar la plataforma sobre la que se va a instalar: Linux/Mac o Windows. Aquí tengo que decir que en mi caso, sobre Mac OS X, no tuve que elegir plataforma, dado que fue seleccionada de forma automática.

Para empezar a hacer uso del plugin, debemos configurar algunas cosas; la primera de ellas es añadir una línea a nuestro environment.rb:

SCRIPT_LINES__ = {} if ENV['RAILS_ENV'] == ‘development’

Con esto debemos de ser cautelosos. SCRIPT_LINES__ almacena todos los ficheros ruby leidos en un hash para poder decir luego en qué línea de código estamos. Esto sin duda puede causar problemas de rendimiento y algunos de consumo de memoria, de ahí que hayamos puesto que sólo se use en desarrollo. Debemos tener mucho cuidado para que no activemos el debug en entornos de producción.

Una vez, tenemos esto, bastaría con situarnos en nuestro código y añadir lo siguiente para poder empezar a debugear allí mismo:

require ‘ruby-debug’
…
def your_method
…
debugger if ENV['RAILS_ENV'] == ‘development’
…
end

El debug se parará justo en debugger.

Ahora arrancamos el servidor web el cual se detendrá en nuestro breakpoint y estaremos en modo consola en el mismo terminal en el que el servidor estaba trabajando, como decíamos es una consola más potente que IRB, algunos la comparan a GDB, el debugger de GNU para C.

En este momento, ya podemos interacturar, bastaría con conocer los comandos y podríamos debugear. Una lista de los más indispensables:

list: te muestra unas líneas de código y te dice donde estás detenido.

irb: pasas a la consola de IRB, puedes interactuar con los objetos, obtener valores, etc. Por ejemplo para ver el valor de una propiedad:

@users.name

exit: salir del IRB

PP (pretty print): para ver el contenido de forma bonita, por ejemplo un formulario:

pp params[:user][:email]
o
pp params

cont: continúa la ejecución

next: avanza a la siguiente línea de código

method: para listar los métodos de un objeto:

method instance @user

o si queremos listar los métodos de una clase:

method User

break: para ir a un sitio dado y saltar todo lo demás:

break Entry#create

para ir al método create de Entry

set autoreload: recarga el código para aceptar los cambios

Cual ha sido mi sorpresa cuando en una de las actualizaciones del sistema venía la nueva versión del JDK. Sin embargo esta release no se convierte en la release por defecto, sino que si deseas utilizarla, debes hacer los cambios por ti mismo.

Investigando un poco logramos la ruta física donde se instalan todas las versiones de los JDK de java descargados:

/System/Library/Frameworks/JavaVM.framework/Versions

Además de todas las versiones, existen tres directorios llamativos: A, Current y CurrentJDK; estos dos últimos directorios son symbolic links a la versión que interesa. Lo que significa que para cambiar de versión del JDK sólo hay que cambiarlos a ellos.

Si buscáis por internet encontraréis un script bastante utilizado, que nos muestra las JDKS que existen instaladas en vuestra máquina y cambia el CurrentJDK a la versión que queramos. Sin embargo, habría que completar este script. Ambos Current y CurrentJDK deben ser cambiados o algunos programas os dejarán de funcionar. La verdad es que por lo que he encontrado, lo único que he podido sacar en claro es que hay algunas razones por las que no cambiar CurrentJDK:

it affects the system globally, it changes the system from how Apple shipped it (things under /System are Apple managed), and it can cause updates to fail and/or have unintended side effects.

Si aún así queréis seguir adelante con el cambio podéis hacer lo siguiente.

Un vistazo rápido al directorio : /System/Library/Frameworks/JavaVM.framework/Versions/ os devolverá algo parecido a:

weemac:Versions jenaiz$ ls -la
total 56
drwxr-xr-x 14 root wheel 476 15 jul 08:59 .
drwxr-xr-x 11 root wheel 374 4 jul 08:08 ..
lrwxr-xr-x 1 root wheel 5 7 may 20:39 1.3 -> 1.3.1
drwxr-xr-x 3 root wheel 102 29 sep 2007 1.3.1
lrwxr-xr-x 1 root wheel 5 21 oct 2007 1.4 -> 1.4.2
lrwxr-xr-x 1 root wheel 3 7 may 20:39 1.4.1 -> 1.4
drwxr-xr-x 8 root wheel 272 21 oct 2007 1.4.2
lrwxr-xr-x 1 root wheel 5 21 oct 2007 1.5 -> 1.5.0
drwxr-xr-x 8 root wheel 272 21 oct 2007 1.5.0
lrwxr-xr-x 1 root wheel 5 7 may 20:39 1.6 -> 1.6.0
drwxr-xr-x 8 root wheel 272 7 may 20:39 1.6.0
drwxr-xr-x 8 root wheel 272 7 may 20:40 A
lrwxr-xr-x 1 root wheel 1 15 jul 08:57 Current -> A
lrwxr-xr-x 1 root wheel 3 15 jul 08:59 CurrentJDK -> 1.5

Como podéis ver, en estos momentos mi CurrentJDK está usando la 1.5 y mi Current apunta a A.

Para hacer que el JDK 1.6 sea el actual, tendréis que hacer:

ln -hfs 1.6 Current
y
ln -hfs 1.6 CurrentJDK

Así es tal como darrell lo explica, y es parecido a como el script lo hace. Todo esto hay que hacerlo como super usuario.

El porqué algunas aplicaciones dejan de funcionar hay que encontrarlo a que existen algunos problemas en esta versión, que Apple no ha considerado en solucionar aún:

- Sólo soporta 64 bits: adios a los applets en Safari.
- No hay soporte para Cocoa: aplicaciones como Cyberdurk dejarán de funcionar. Esto no sólo significa que no podamos tener look&feel de Mac OS sino que también perderemos algunas de las utilidades tales, como poder usar Growl como sistema de notificación, por ejemplo.

Si el tema de cómo está organizado el directorio de versiones de Java y el porqué de esta cosas, os interesa realmente, os dejo unos links interesantes sobre todo esto, no sólo aplicable al JDK:

Anatomy of Framework Bundles
Framework Versions
What are Frameworks?