FWN/Issue269

From FedoraProject

< FWN(Difference between revisions)
Jump to: navigation, search
m (Ruby Capítulo 2 : Una clase algo más completa)
 
(5 intermediate revisions by one user not shown)
Line 3: Line 3:
 
Welcome to Fedora Weekly News Issue 269<ref>http://fedoraproject.org/wiki/FWN/Issue269</ref> for the week ending March 30, 2011.  What follows are some highlights from this issue.   
 
Welcome to Fedora Weekly News Issue 269<ref>http://fedoraproject.org/wiki/FWN/Issue269</ref> for the week ending March 30, 2011.  What follows are some highlights from this issue.   
  
 +
This issue begins with announcements from the Fedora Project, including changes to the packaging guidelines and an additional week slip of the Fedora 15 release date.  One article for Fedora In the News this week from PC World on Red Hat's financial success.  In Ambassador news, details on new members of the team, a summary of discussion on the Ambassador and FAmSCo lists, and a couple event reports.  In Quality Assurance news, details on the latest and upcoming Test Days on power management, printing and ABRT, as well as various reports leading up to the Fedora 15 beta release. Security Advisories brings us current with the security-related package releases this past week for Fedora 13, 14 and 15, and in our Latin American beat this week, a second installment of Guillermo Gomez's Ruby Primer, in Spanish.  Enjoy!
  
 
An audio version of some issues of FWN - FAWN - are available! You can listen to existing issues<ref>http://www.archive.org/search.php?query=subject%3A%22FWN%22</ref> on the Internet Archive. If anyone is interested in helping spread the load of FAWN production, please contact us!
 
An audio version of some issues of FWN - FAWN - are available! You can listen to existing issues<ref>http://www.archive.org/search.php?query=subject%3A%22FWN%22</ref> on the Internet Archive. If anyone is interested in helping spread the load of FAWN production, please contact us!
Line 11: Line 12:
  
 
<references/>
 
<references/>
 +
 +
{{Anchor|Announcements}}
 +
==Announcements==
 +
 +
In this section, we cover announcements from the Fedora Project, including general announcements<ref>
 +
http://lists.fedoraproject.org/pipermail/announce/</ref>, development announcements<ref>http://lists.fedoraproject.org/pipermail/devel-announce/</ref> and Events<ref>http://fedoraproject.org/wiki/Events</ref>.
 +
 +
Contributing Writer: [[User:pcalarco|Pascal Calarco]]
 +
 +
<references/>
 +
 +
=== Fedora Announcement News ===
 +
The announcement list is always exclusive for the Fedora Community. Please, visit the past announcements at<ref>https://admin.fedoraproject.org/mailman/listinfo/announce</ref>
 +
 +
<references/>
 +
 +
====Changes to the Packaging Guidelines====
 +
[[User:Spot|Tom 'Spot' Callaway]] announced<ref>http://lists.fedoraproject.org/pipermail/announce/2011-March/002942.html</ref>,
 +
 +
"Here are the changes to the Fedora Packaging Guidelines for this week:
 +
 +
The Packaging:PHP guidelines have been updated to reflect that PEAR
 +
documentation provided by upstream are installed in %{pear_docdir},
 +
should stay there, and must be marked as %doc.
 +
 +
Additionally, the definition of pear_docdir has been defined as %{_docdir}/pear.
 +
 +
https://fedoraproject.org/wiki/Packaging:PHP
 +
 +
---
 +
 +
The Java guidelines have been updated to add information and sample template for Maven 3 (Fedora 15+).
 +
 +
https://fedoraproject.org/wiki/Packaging:Java
 +
 +
---
 +
 +
These guidelines (and changes) were approved by the Fedora Packaging Committee (FPC).
 +
 +
Many thanks to Remi Collet, Stanislav Ochotnicky, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines.
 +
 +
As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here
 +
<ref>http://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure</ref>
 +
 +
Thanks,
 +
 +
~spot"
 +
 +
<references/>
 +
 +
=== Fedora Development News ===
 +
The Development Announcement<ref>https://admin.fedoraproject.org/mailman/listinfo/devel-announce</ref> list is intended to be a LOW TRAFFIC announce-only list for Fedora development.
 +
 +
'''Acceptable Types of Announcements'''
 +
* Policy or process changes that affect developers.
 +
* Infrastructure changes that affect developers.
 +
* Tools changes that affect developers.
 +
* Schedule changes
 +
* Freeze reminders
 +
 +
'''Unacceptable Types of Announcements'''
 +
* Periodic automated reports (violates the INFREQUENT rule)
 +
* Discussion
 +
* Anything else not mentioned above
 +
 +
<references/>
 +
 +
====Beta change freeze====
 +
 +
[[User:Ausil|Dennis Gilmore]] announced<ref>http://lists.fedoraproject.org/pipermail/devel-announce/2011-March/000773.html</ref>,
 +
 +
"Hi All a heads up that change freeze for the Fedora 15 Beta is Tuesday April  5th.  After this point only accepted blocker bugs will be pulled in.  Please  limit your changes to try and avoid unintended breakages.
 +
 +
thanks
 +
 +
Dennis"
 +
 +
<references/>
 +
 +
====Fedora 15 schedule to slip an additional week====
 +
 +
Jared K. Smith announced<ref>http://lists.fedoraproject.org/pipermail/devel-announce/2011-March/000772.html</ref>
 +
 +
"The Fedora 15 development cycle is well under way, and making good progress.  Yesterday I met[1] with Release Engineering, QA, the Fedora Program Manager, and we decided that in order to accommodate some late-breaking changes, we're going to need to slip the Fedora 15 release schedule by a week in order to have adequate time to do proper testing of the candidate images before the Beta.  This slip will affect the entire Fedora 15 development cycle, as shown in the chart below:
 +
 +
<code>
 +
  o F15 Devel Start                2010-11-02
 +
  o Feature Submission Deadline    2011-01-25
 +
  o Feature Freeze                2011-02-08
 +
  o Branch From Rawhide            2011-02-08
 +
  o Software String Freeze        2011-02-15
 +
  o Alpha Change Deadline          2011-02-15
 +
  o Alpha Release                  2011-03-08
 +
-------------------- N O W -----------------------
 +
  o Software Translation Deadline  2011-04-05
 +
  o Beta Change Deadline          2011-04-05
 +
  o Features 100% Complete        2011-04-05
 +
  o Beta Release                  2011-04-19
 +
  o Final Change Deadline          2011-05-09
 +
  o Compose RC                    2011-05-10
 +
  o GA                            2011-05-24
 +
</code>
 +
 +
Robyn Bergeron has also kindly updated the complete break-out of the Fedora release schedule, which is available<ref>http://rbergero.fedorapeople.org/schedules/f-15/</ref>.  If you have any questions or concerns, please don't hesitate to let me know.
 +
 +
--
 +
Jared Smith
 +
Fedora Project Leader
 +
"
 +
 +
<references/>
 +
 +
=== Fedora Events ===
 +
 +
The purpose of event is to build a global Fedora events calendar, and to identify responsible Ambassadors for each event. The event page is laid out by quarter and by region. Please maintain the layout, as it is crucial for budget planning.
 +
Events can be added to this page whether or not they have an Ambassador owner. Events without an owner are not eligible for funding, but being listed allows any Ambassador to take ownership of the event and make it eligible for funding.
 +
In plain words, Fedora events are the exclusive and source of marketing, learning and meeting all the fellow community people around you. So, please mark your agenda with the following events to consider attending or volunteering near you!
 +
 +
====Upcoming Events (March - May 2011)====
 +
* North America (NA)<ref>http://fedoraproject.org/wiki/Events#FY12_Q1_.28March_2011_-_May_2011.29</ref>
 +
* Central & South America (LATAM): <ref>http://fedoraproject.org/wiki/Events#FY12_Q1_.28March_2011_-_May_2011.29_2</ref>
 +
* Europe, Middle East, and Africa (EMEA)<ref>http://fedoraproject.org/wiki/Events#FY12_Q1_.28March_2011_-_May_2011.29_3</ref>
 +
* India, Asia, Australia (India/APJ)<ref>http://fedoraproject.org/wiki/Events#FY12_Q1_.28March_2011_-_May_2011.29_4</ref>
 +
 +
<references/>
 +
 +
====Past Events====
 +
Archive of Past Fedora Events<ref>http://fedoraproject.org/wiki/FedoraEvents/PastEvents</ref>
 +
 +
<references/>
 +
 +
====Additional information====
 +
* [[Reimbursements]] -- reimbursement guidelines.
 +
* [[Ambassadors/SteeringCommittee/Budget| Budget]] -- budget for the current quarter (as distributed by FAMSCo).
 +
* [[Sponsoring event attendees | Sponsorship]] -- how decisions are made to subsidize travel by community members.
 +
* [[FedoraEvents/Organization| Organization]] -- event organization, budget information, and regional responsibility.
 +
* [[Event reports]] -- guidelines and suggestions.
 +
* [[FedoraEvents/LinuxEvents| LinuxEvents]] -- a collection of calendars of Linux events.
 +
  
 
{{Anchor|InTheNews}}
 
{{Anchor|InTheNews}}
Line 25: Line 165:
 
=== Red Hat Proves That Open Source Is Good for Business (PC World) ===
 
=== Red Hat Proves That Open Source Is Good for Business (PC World) ===
  
[[User:Sundaram|Rahul Sundaram]] forwarded<ref>http://lists.fedoraproject.org/pipermail/marketing/2011-March/013758.html</ref> a posting on btrfs and its relation to ext4 in RHEL and Fedora:
+
[[User:Sundaram|Rahul Sundaram]] forwarded<ref>http://lists.fedoraproject.org/pipermail/marketing/2011-March/013758.html</ref> a posting on Red Hat's financial success:
  
 
"Critics of free and open source software are fond of making the argument that software must be locked up, patented and jealously guarded if it is to serve as the basis for a successful business. Well, Red Hat just refuted such claims in a big way this week with its fourth quarter earnings report, which blew away analysts' expectations and placed the company well on track for billion-dollar revenues in the upcoming year."
 
"Critics of free and open source software are fond of making the argument that software must be locked up, patented and jealously guarded if it is to serve as the basis for a successful business. Well, Red Hat just refuted such claims in a big way this week with its fourth quarter earnings report, which blew away analysts' expectations and placed the company well on track for billion-dollar revenues in the upcoming year."
Line 36: Line 176:
  
 
{{Anchor|Ambassadors}}
 
{{Anchor|Ambassadors}}
 +
 
== Ambassadors ==
 
== Ambassadors ==
  
Line 177: Line 318:
 
* gnash-0.8.9-1.fc13 - http://lists.fedoraproject.org/pipermail/package-announce/2011-March/056787.html
 
* gnash-0.8.9-1.fc13 - http://lists.fedoraproject.org/pipermail/package-announce/2011-March/056787.html
 
* krb5-1.7.1-18.fc13 - http://lists.fedoraproject.org/pipermail/package-announce/2011-March/056573.html
 
* krb5-1.7.1-18.fc13 - http://lists.fedoraproject.org/pipermail/package-announce/2011-March/056573.html
 +
 +
{{Anchor|LATAM}}
 +
 +
== LATAM Fedora! ==
 +
 +
LATAM Fedora is a regular column of Spanish language contributions around open source software.  It is our first expansion into incorporating foreign language content into FWN. 
 +
 +
This week's contribution is from [[User:gomix|Guillermo Gómez]], a second installment primer on Ruby.  Enjoy!
 +
 +
===Ruby Capítulo 2 : Una clase algo más completa===
 +
 +
Siguiendo nuestra secuencia al estilo tutorial, en esta edición vamos a completar un poco más nuestras clases, introduciremos los conceptos de métodos y variables de clase.
 +
 +
Una variable de clase es una variable compartida de la clase misma. Sólo existe una copia de una variable de clase en particular para una clase dada. Los nombres de las variables de clase comienzan con @@ tal como en @@reproducciones.
 +
 +
<code>
 +
1 class Cancion
 +
2  @@reproducciones = 0
 +
3
 +
4  def Cancion.reproducciones
 +
5    @@reproducciones
 +
6  end
 +
7
 +
8  def reproducir
 +
9    @@reproducciones =+ 1
 +
10  end
 +
11 end
 +
</code>
 +
 +
A diferencia de las variables de instancia y variables globales, las variables de clase deben se inicializadas antes de poder ser utilizadas, usualmente se hace con una declaración simple en el cuerpo de la definición de la clase. En el código anterior igualmente se ha introducido el concepto de método de clase. Un método de clase es un método que no necesita que se instancie la clase para ser invocado, es decir, "son métodos propios de la clase y no de sus objetos".
 +
 +
Su utilidad es obvia en el ejemplo, se quiere saber cuántas reproducciones se han hecho en total en nuestro reproductor de música. Esta información no es específica a una canción en particular, es decir, no es sujeto de las instancias sino de la clase misma. La diferencia al momento de declarar el método de clase es que debe anteponer el nombre de la clase al método, tiene dos opciones, o usar explícitamente Cancion, o self. El uso de *self" da mayor flexibilidad ya que permite cambiar el nombre de la clase sin mayores traumas.
 +
 +
<code>
 +
1 class Cancion
 +
2  @@reproducciones = 0
 +
3
 +
4  def self.reproducciones
 +
5    @@reproducciones
 +
6  end
 +
7
 +
8  def reproducir
 +
9    @@reproducciones =+ 1
 +
10  end
 +
11 end
 +
</code>
 +
 +
====Constantes vs variables====
 +
 +
Las variables y constantes en Ruby mantienen referencias a objetos. Las variables no poseen un tipo intrínseco, a cambio el tipo es únicamente definido por los mensajes a los que responde el objeto referenciado.
 +
 +
Una constante en Ruby también es una referencia a un objeto. Las constantes son creadas cuando son asignadas por primera vez, a diferencia de otros lenguajes Ruby le permite alterar el valor de las constantes si bien ello provocará un mensaje de alerta. En general usted no debe alterar una constante en tiempo de ejecución y debería evitarlo a toda costa.
 +
 +
<code>
 +
1 >> MI_CONSTANTE = 1
 +
2 => 1
 +
3 >> MI_CONSTANTE = 2
 +
4 (irb):23: warning: already initialized constant MI_CONSTANTE
 +
5 => 2
 +
</code>
 +
 +
Note como las constantes pueden declararse dentro de la definición de clase lo que nos lleva a la definición de constante de clase y a la noción de espacios de nombres por la forma en que nos referimos a dichas constantes.
 +
 +
<code>
 +
1 class Cancion
 +
2  VERSION="1.0"
 +
3 end
 +
</code>
 +
 +
<code>
 +
1 >> Cancion::VERSION
 +
2 => "1.0"
 +
3 >> VERSION
 +
4 => "1.8.7"
 +
</code>
 +
 +
Note que VERSION no referencia ni colisiona con Cancion::VERSION.
 +
 +
====El poder de herencia====
 +
 +
Tal vez el santo grial de la programación es el principio DRY, "Don Repeat Yourself". Una forma de evitar repetirse, es escribir código reusable, cada vez que estamos escribiendo nuevo código y tenemos esa sensación de deja-vu de que ya esto lo hicimos una vez en el pasado, es porque no estamos reusando nuestro código de forma inteligente. En POO la herencia es una excelente forma de mantener el código reusable sin mayores repeticiones.
 +
 +
La herencia le permite crear clases que sean refinamientos o especializaciones de otra clase. Por ejemplo, y siguiendo el ejemplo de Cancion en nuestro reproductor de música ahora a alguien se le ocurrió que sería interesante que se incluyera el soporte para canciones de tipo Karaoke. La única diferencia con las otras canciones es que las canciones Karaoke tienen asociadas la letra de la canción en conjunto con infomación de sincronización para reproducir las letras del Karaoke en nuestro flamante reproductor ahora con una gran pantalla de video.
 +
 +
<code>
 +
1 class Karaoke < Cancion
 +
2  def initialize(nombre, artista, duracion, letra)
 +
3    super(nombre, artista, duracion)
 +
4    @letra = letra
 +
5  end
 +
6 end
 +
</code>
 +
 +
El "< Cancion" en la definición de la clase le indica a Ruby que Karaoke es un subclase de Cancion, o en dirección opuesta, Cancion es la superclase de Karaoke. De esta forma la clase hija hereda todos los métodos y declaraciones de variables de su padre. Al invocar un método sobre un objeto o clase, Ruby defiere su ubicación hasta el momento de ejecución, en dicho momento Ruby primero mira en la clase para determinar si existe el método invocado, si no es así, intenta en el padre, y así atravesando todos los ancestros de la clase hasta ubicar el método invocado. Si se acaban los ancestros donde buscar, Ruby ejecuta una acción especial que puede ser interceptada si se desea Object#method_missing, si no, produce un error.
 +
 +
Cada clase especializada maneja sus detalles, para el resto se utiliza super, es decir, el método del padre o de su ancestro. De esta forma, por ejemplo, en nuestra definición de Karaoke#initialize dejamos que la inicialización de todo lo común a Cancion ocurra igual que antes por medio de la llamada a super con los respectivos parámetros necesarios, luego inicializamos los datos específicos a nuetras clase Karaoke.
 +
 +
====Espacios de nombres====
 +
 +
En la medida que escriba programas Ruby cada vez más grandes, usted naturalmente se encontrará con código reusable, librerías de rutinas relacionadas entre sí por ejemplo. Usted deseará separar dicho código en distintos archivos separados de tal forma que el contenido pueda ser reusado entre diferentes programas Ruby. Frecuentemente este código será organizado en clases.
 +
 +
Otras veces ello simplemente no es conveniente o no aplica, son un grupo de métodos que desea reusar, usted puede simplemente colocarlos en un archivo y cargar dicho archivo en su programa con load o require. Esto funciona pero tiene un problema, digamos que se crea una librería para cocinar con los métodos calentar , mezclar, amasar en un archivo cocina.rb y otra librería para atletas con los métodos calentar, correr, descansar en el archivo atleta.rb. Si carga ambos archivos uno después del otro, simplemente el método calentar colisiona y sólo el más recientemente cargado tendrá la definicón actual del método, el otro simplemente será olvidado, en resumen la colisión en los nombres es el problema.
 +
 +
La respuesta es el mecanismo de modulos. Los modulos definen un espacio de nombres en donde sus métodos y constantes pueden aplicar sin tener que preocuparse en colisionar con otros métodos y constantes:
 +
 +
<code>
 +
  1 module Cocina
 +
  2  ESCUELA="Latinoamericana"
 +
  3  def Cocina.calentar(x)
 +
  4    # Se espera que x sea un valor númerico para representar temperatura en ºC
 +
  5    # ..
 +
  6  end
 +
  7 ...
 +
  8 end
 +
  9
 +
10 module Atleta
 +
11  ESCUELA="Simón Bolívar"
 +
12  def Atleta.calentar(t)
 +
13    # Se espera que t sea un valor numérico que represente tiempo en segundos
 +
14    # ..
 +
15  end
 +
16 end
 +
</code>
 +
 +
<code>
 +
1 >> Cocina::ESCUELA
 +
2 => "Latinoamericana"
 +
3 >> Atleta::ESCUELA
 +
4 => "Simon Bolivar"
 +
5 >> include Atleta
 +
6 => Object
 +
7 >> Atleta.calentar(1000)
 +
8 calentando 1000 segundos
 +
9 => nil
 +
10 >> include Cocina
 +
11 => Object
 +
12 >> Cocina.calentar(10)
 +
13 => 10
 +
</code>
 +
 +
Ahora entonces tiene mucho menos probabilidades de provocar colisiones, note que debe cargar el código, y luego include para usar las funcionalidades del módulo.
 +
 +
====Herencia múltiples vs Mixins====
 +
 +
Algunos lenguajes orientados a objetos, tales como C++, soportan herencia múltiple en donde una clase puede tener más de una superclase heredando funcionalidad de cada una de ellas. Si bien potente, esta técnica puede ser peligrosa ya que la jerarquía puede tener ambigüedades. Otros lenguajes como java y C# soportan sólo herencia simple. Si bien más limpia y simple, la herencia simple también tiene sus desventajas, en la realidad los objetos heredan atributos de múltiples fuentes en el mundo real.
 +
 +
Ruby ofrece una alternativa interesante y poderosa que le ofrece la simplicidad de la herencia simple y el poder la herencia múltiple. Una clase Ruby tiene una única clase padre, en consecuencia Ruby es un lenguaje con herencia simple, sin embargo, las clases Ruby pueden incluir la funcionalidad de cualquier cantidad de mixins (un mixin es una especie de definición parcial de clase). Nuevamente dejemos que Ruby hable, creemos nuestro archivo con la definición de módulo y un par de clases tontas que lo usen como mixin:
 +
 +
=====mixin_module.rb=====
 +
 +
<code>
 +
  1 module Debug
 +
  2  def quien_soy?
 +
  3    "#{self.class.name} (\##{self.objet_id}): #{self.to_s}"
 +
  4  end
 +
  5 end
 +
  6
 +
  7 class Cocina
 +
  8  include Debug
 +
  9  def estilo
 +
10    puts "Italiana"
 +
11  end
 +
12 end
 +
13
 +
14 class Nevera
 +
15  include Debug
 +
16  def capacidad
 +
17    puts "150 pies cúbicos"
 +
18  end
 +
19 end
 +
</code>
 +
 +
Si ahora cargamos dichas definiciones de módulo y clases en irb, podemos evidenciar y experimentar con el uso de los mixins (note que le voy a pasar la forma de hacerlo):
 +
 +
<code>
 +
1 $ irb
 +
2 >> load 'mixin_module.rb'
 +
3 => true
 +
4 >> nevera = Nevera.new
 +
5 => #<Nevera:0xb7587b38>
 +
6 >> cocina = Cocina.new
 +
7 => #<Cocina:0xb7585c5c>
 +
8 >> nevera.quien_soy?
 +
9 => "Nevera (#-609469028): #<Nevera:0xb7587b38>"
 +
10 >> cocina.quien_soy?
 +
11 => "Cocina (#-609472978): #<Cocina:0xb7585c5c>"
 +
</code>
 +
 +
Bien, es todo por hoy, nos recontraremos en un tercer capítulo dedicado a métodos en una próxima edición de esta serie dedicada a aprender Ruby.
 +
 +
Este artículo se mantiene en línea en gomix.fedora-ve.org para posibles mejoras y erratas.
 +
 +
Guillermo Gómez

Latest revision as of 16:18, 31 March 2011

Contents

[edit] Fedora Weekly News Issue 269

Welcome to Fedora Weekly News Issue 269[1] for the week ending March 30, 2011. What follows are some highlights from this issue.

This issue begins with announcements from the Fedora Project, including changes to the packaging guidelines and an additional week slip of the Fedora 15 release date. One article for Fedora In the News this week from PC World on Red Hat's financial success. In Ambassador news, details on new members of the team, a summary of discussion on the Ambassador and FAmSCo lists, and a couple event reports. In Quality Assurance news, details on the latest and upcoming Test Days on power management, printing and ABRT, as well as various reports leading up to the Fedora 15 beta release. Security Advisories brings us current with the security-related package releases this past week for Fedora 13, 14 and 15, and in our Latin American beat this week, a second installment of Guillermo Gomez's Ruby Primer, in Spanish. Enjoy!

An audio version of some issues of FWN - FAWN - are available! You can listen to existing issues[2] on the Internet Archive. If anyone is interested in helping spread the load of FAWN production, please contact us!

If you are interested in contributing to Fedora Weekly News, please see our 'join' page[3]. We welcome reader feedback: news@lists.fedoraproject.org

FWN Editorial Team: Pascal Calarco, Adam Williamson

  1. http://fedoraproject.org/wiki/FWN/Issue269
  2. http://www.archive.org/search.php?query=subject%3A%22FWN%22
  3. http://fedoraproject.org/wiki/NewsProject/Join

[edit] Announcements

In this section, we cover announcements from the Fedora Project, including general announcements[1], development announcements[2] and Events[3].

Contributing Writer: Pascal Calarco

  1. http://lists.fedoraproject.org/pipermail/announce/
  2. http://lists.fedoraproject.org/pipermail/devel-announce/
  3. http://fedoraproject.org/wiki/Events

[edit] Fedora Announcement News

The announcement list is always exclusive for the Fedora Community. Please, visit the past announcements at[1]

  1. https://admin.fedoraproject.org/mailman/listinfo/announce

[edit] Changes to the Packaging Guidelines

Tom 'Spot' Callaway announced[1],

"Here are the changes to the Fedora Packaging Guidelines for this week:

The Packaging:PHP guidelines have been updated to reflect that PEAR documentation provided by upstream are installed in %{pear_docdir}, should stay there, and must be marked as %doc.

Additionally, the definition of pear_docdir has been defined as %{_docdir}/pear.

https://fedoraproject.org/wiki/Packaging:PHP

---

The Java guidelines have been updated to add information and sample template for Maven 3 (Fedora 15+).

https://fedoraproject.org/wiki/Packaging:Java

---

These guidelines (and changes) were approved by the Fedora Packaging Committee (FPC).

Many thanks to Remi Collet, Stanislav Ochotnicky, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here [2]

Thanks,

~spot"

  1. http://lists.fedoraproject.org/pipermail/announce/2011-March/002942.html
  2. http://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

[edit] Fedora Development News

The Development Announcement[1] list is intended to be a LOW TRAFFIC announce-only list for Fedora development.

Acceptable Types of Announcements

  • Policy or process changes that affect developers.
  • Infrastructure changes that affect developers.
  • Tools changes that affect developers.
  • Schedule changes
  • Freeze reminders

Unacceptable Types of Announcements

  • Periodic automated reports (violates the INFREQUENT rule)
  • Discussion
  • Anything else not mentioned above
  1. https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[edit] Beta change freeze

Dennis Gilmore announced[1],

"Hi All a heads up that change freeze for the Fedora 15 Beta is Tuesday April 5th. After this point only accepted blocker bugs will be pulled in. Please limit your changes to try and avoid unintended breakages.

thanks

Dennis"

  1. http://lists.fedoraproject.org/pipermail/devel-announce/2011-March/000773.html

[edit] Fedora 15 schedule to slip an additional week

Jared K. Smith announced[1]

"The Fedora 15 development cycle is well under way, and making good progress. Yesterday I met[1] with Release Engineering, QA, the Fedora Program Manager, and we decided that in order to accommodate some late-breaking changes, we're going to need to slip the Fedora 15 release schedule by a week in order to have adequate time to do proper testing of the candidate images before the Beta. This slip will affect the entire Fedora 15 development cycle, as shown in the chart below:

  o F15 Devel Start                2010-11-02
  o Feature Submission Deadline    2011-01-25
  o Feature Freeze                 2011-02-08
  o Branch From Rawhide            2011-02-08
  o Software String Freeze         2011-02-15
  o Alpha Change Deadline          2011-02-15
  o Alpha Release                  2011-03-08

N O W -----------------------
  o Software Translation Deadline  2011-04-05
  o Beta Change Deadline           2011-04-05
  o Features 100% Complete         2011-04-05
  o Beta Release                   2011-04-19
  o Final Change Deadline          2011-05-09
  o Compose RC                     2011-05-10
  o GA                             2011-05-24

Robyn Bergeron has also kindly updated the complete break-out of the Fedora release schedule, which is available[2]. If you have any questions or concerns, please don't hesitate to let me know.

-- Jared Smith Fedora Project Leader "

  1. http://lists.fedoraproject.org/pipermail/devel-announce/2011-March/000772.html
  2. http://rbergero.fedorapeople.org/schedules/f-15/

[edit] Fedora Events

The purpose of event is to build a global Fedora events calendar, and to identify responsible Ambassadors for each event. The event page is laid out by quarter and by region. Please maintain the layout, as it is crucial for budget planning. Events can be added to this page whether or not they have an Ambassador owner. Events without an owner are not eligible for funding, but being listed allows any Ambassador to take ownership of the event and make it eligible for funding. In plain words, Fedora events are the exclusive and source of marketing, learning and meeting all the fellow community people around you. So, please mark your agenda with the following events to consider attending or volunteering near you!

[edit] Upcoming Events (March - May 2011)

  • North America (NA)[1]
  • Central & South America (LATAM): [2]
  • Europe, Middle East, and Africa (EMEA)[3]
  • India, Asia, Australia (India/APJ)[4]
  1. http://fedoraproject.org/wiki/Events#FY12_Q1_.28March_2011_-_May_2011.29
  2. http://fedoraproject.org/wiki/Events#FY12_Q1_.28March_2011_-_May_2011.29_2
  3. http://fedoraproject.org/wiki/Events#FY12_Q1_.28March_2011_-_May_2011.29_3
  4. http://fedoraproject.org/wiki/Events#FY12_Q1_.28March_2011_-_May_2011.29_4

[edit] Past Events

Archive of Past Fedora Events[1]

  1. http://fedoraproject.org/wiki/FedoraEvents/PastEvents

[edit] Additional information

  • Reimbursements -- reimbursement guidelines.
  • Budget -- budget for the current quarter (as distributed by FAMSCo).
  • Sponsorship -- how decisions are made to subsidize travel by community members.
  • Organization -- event organization, budget information, and regional responsibility.
  • Event reports -- guidelines and suggestions.
  • LinuxEvents -- a collection of calendars of Linux events.


[edit] Fedora In the News

In this section, we cover news from the trade press and elsewhere that is re-posted to the Fedora Marketing list[1].

http://fedoraproject.org/wiki/Marketing

Contributing Writer: Pascal Calarco

  1. http://lists.fedoraproject.org/pipermail/marketing/

[edit] Red Hat Proves That Open Source Is Good for Business (PC World)

Rahul Sundaram forwarded[1] a posting on Red Hat's financial success:

"Critics of free and open source software are fond of making the argument that software must be locked up, patented and jealously guarded if it is to serve as the basis for a successful business. Well, Red Hat just refuted such claims in a big way this week with its fourth quarter earnings report, which blew away analysts' expectations and placed the company well on track for billion-dollar revenues in the upcoming year."

Based in North Carolina, Red Hat is the company behind both the Fedora and the Red Hat Enterprise Linux (RHEL) Linux distributions. Fedora is the free, community version of the software, while RHEL is sold as acommercial product with support and services."

The full article is available[2].

  1. http://lists.fedoraproject.org/pipermail/marketing/2011-March/013758.html
  2. http://www.pcworld.com/businesscenter/article/223346/red_hat_proves_that_open_source_is_good_for_business.html

[edit] Ambassadors

This section covers the news surrounding the Fedora Ambassadors Project[1].

Contributing Writer: Sankarshan Mukhopadhyay

  1. http://fedoraproject.org/wiki/Ambassadors

[edit] Welcome New Ambassadors

This week the Fedora Ambassadors Project had a couple of new members joining.

Everton Cardoso from Brazil mentored by Daniel Bruno


[edit] Summary of traffic on Ambassadors mailing list

Christoph Wickert raised [1] some questions regarding the budget [2] Max Spevack provided [3] actual figures from the expenses. David Nalley mentioned [4] that some of the issues raised in the mail were also part of the Board IRC meeting and, discussions were ongoing as the same was an agenda item in the upcoming Board meeting.

Onyeibo Oku asked [5] if there was an existing print-ready, A5 sized booklet covering the basics of Fedora for handing out at events. Zoltan Hopper responded [6] about a scratch document available at the Marketing Page. There was further discussion around the difference between a Quick-Start and a Handbook [7] and the possibility of building a Quick Start Guide [8] based upon the SXSW Materials [9]

Christoph Wickert posted [10] Minutes of EMEA Ambassadors Meeting [11] The thread [12] had additional discussion around allocation of funds under budget line items and, expense planning based on projected needs. The decision making process within FAmSCo was also discussed.

David Ramsey posted [13] meeting notes [14] from the APAC Ambassadors meeting on 2011-03-19

David Ramsey informed [15] about an upcoming Power Management Test Day [16] and subsequently posted [17] about the Printing and ABRT Retrace Server Test Days

Máirín Duffy asked [18] if there was a group photograph from a recent event with the aim of updating the FUDCon Zurich group phot that is on fedoraproject.org page

Christoph Wickert posted [19] a 'Last Call for Orders" for F14 media for any event at EMEA and added a link to the Inventory [20] for helping to search for the nearest anchor point

Pierros Papadeas posted [21] Meeting Minutes for FAmSCo meeting of 2011-03-26

Buddhika Kurera requested help [22] in finding a co-speaker for CLT2011

Paul Mellors posted [23] about an idea for a documentary [24] similar to "Revolution OS"

Adam Miller put out a last call for funding for Texas Linux Fest 2011 [25]

  1. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017242.html
  2. https://fedoraproject.org/wiki/FAmSCo_report_2011-02
  3. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017245.html
  4. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017317.html
  5. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017252.html
  6. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017253.html
  7. http://fedoraproject.org/wiki/User:Sankarshan/FedoraHandbook
  8. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017261.html
  9. https://fedoraproject.org/wiki/Design/SXSW_Materials
  10. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017264.html
  11. http://meetbot.fedoraproject.org/fedora-meeting/2011-03-23/emea_ambassadors.2011-03-23-20.02.html
  12. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/thread.html#17264
  13. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017265.html
  14. http://meetbot.fedoraproject.org/fedora-meeting/2011-03-19/apac.2011-03-19-04.09.html
  15. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017267.html
  16. https://fedoraproject.org/wiki/Test_Day:2011-03-24
  17. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017312.html
  18. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017282.html
  19. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017293.html
  20. https://fedorahosted.org/emea-swag-tracking/wiki/Inventory
  21. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017296.html
  22. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017299.html
  23. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017314.html
  24. https://fedoraproject.org/wiki/Fedora_Documentary
  25. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017310.html

[edit] Summary of events reported on Ambassadors mailing list

Christoph Wickert reported [1] on the Chemnitzer Linuxtage event with more details about undertaking similar tasks using different distributions.

Fabian Affolter summarized [2] all the CLT2011 reports

  1. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017241.html
  2. http://lists.fedoraproject.org/pipermail/ambassadors/2011-March/017284.html

[edit] Summary of traffic on FAmSCo mailing list

Pierros Papadeas posted [1] the Agenda for the FAmSCo meeting of 2011-03-26 [2]

Joerg Simon, as the Fedora Ambassador Membership Administrator, informed FAmSCo [3] about existing continuous violations of Fedora Ambassador Conduct [4] Follow-up discussions happened on the ticket and the thread [5]

  1. http://lists.fedoraproject.org/pipermail/famsco/2011-March/000736.html
  2. https://fedoraproject.org/wiki/FAmSCo_agenda#2011-3-26_agenda
  3. http://lists.fedoraproject.org/pipermail/famsco/2011-March/000737.html
  4. https://fedorahosted.org/famsco/ticket/156
  5. http://lists.fedoraproject.org/pipermail/famsco/2011-March/thread.html#737

[edit] QualityAssurance

In this section, we cover the activities of the QA team[1]. For more information on the work of the QA team and how you can get involved, see the Joining page[2].

Contributing Writer: Adam Williamson

  1. http://fedoraproject.org/wiki/QA
  2. http://fedoraproject.org/wiki/QA/Join

[edit] Test Days

Thursday 2011-03-24 was power management Test Day[1]. The event produced a great turnout of testers who provided results on a wide range of hardware, and the developers are already looking at the bugs filed. Thanks to everyone who came out to help.

This Tuesday, 2011-03-29, was printing Test Day[2]. The turnout was a little smaller than we hoped, but the testers who did come managed to find lots of bugs, and Fedora's printing maintainer, Tim Waugh, was very happy with all the results.

This Thursday, 2011-03-31, will be ABRT Test Day[3]. As well as checking that ABRT (Fedora's automated crash report tool) is working as expected for Fedora 15, we'll be testing out a big new feature, the retrace server[4]. This allows you to submit crash reports to a remote server which will generate the backtrace - avoiding the need for you to download and install often large debuginfo packages in order to submit reports. Please come along and help us test this exciting new feature!

There is currently no Test Day planned for next Thursday, 2011-04-07. Take the day off!

  1. http://fedoraproject.org/wiki/Test_Day:2011-03-24
  2. http://fedoraproject.org/wiki/Test_Day:2011-03-29
  3. http://fedoraproject.org/wiki/Test_Day:2011-03-31_ABRT_Retrace_Server
  4. http://fedoraproject.org/wiki/Features/RetraceServer

[edit] Anaconda testing

James Laska requested testing of an installer image which included updated versions of anaconda and lorax that needed testing before being approved as stable updates[1]. Several testers responded, and the updates were soon approved.

  1. http://lists.fedoraproject.org/pipermail/test/2011-March/098018.html

[edit] GNOME Tweak Tool testing

Michel Salim announced that GNOME Tweak Tool, an application for tweaking various advanced settings in GNOME 3, was now available for testing[1]. Several group members thanked Michel for the announcement and provided feedback on the tool.

  1. http://lists.fedoraproject.org/pipermail/test/2011-March/098107.html

[edit] Fedora 15 Beta preparation

The third Beta blocker/nice-to-have review meeting took place on 2011-03-25[1], and the team worked through the full list of proposed Beta blocker and nice-to-have bugs. The first test compose was scheduled for Tuesday 2011-03-22, but could not be completed on that day due to various outstanding bugs and the lack of the planned NetworkManager 0.9 packages. At a special release schedule meeting on Wednesday 2011-03-23[2], the QA and release engineering teams, and the Fedora Project Leader, agreed that the late arrival of NetworkManager 0.9 justified a one week slip in the release schedule. The first test compose was then set for Tuesday 2011-03-29.

  1. http://meetbot.fedoraproject.org/fedora-bugzappers/2011-03-25/f-15-beta-blocker.2011-03-25-16.59.html
  2. http://meetbot.fedoraproject.org/fedora-meeting/2011-03-23/fedora-meeting.2011-03-23-19.30.html

[edit] Improving pre-release download page

Tim Flink passed on some feedback[1] he had received from a new tester who had downloaded a pre-release and asked some questions in the #fedora IRC channel, which does not handle pre-release issues. He suggested that it would be a good idea to add some text to the pre-release download page[2] explaining the right places to go to post feedback and get help with pre-release issues. Jóhann Guðmundsson and Adam Williamson both suggested filing a request with the websites team, and Tim reported[3] that he had filed a ticket[4].

  1. http://lists.fedoraproject.org/pipermail/test/2011-March/098160.html
  2. http://fedoraproject.org/get-prerelease
  3. http://lists.fedoraproject.org/pipermail/test/2011-March/098173.html
  4. http://fedorahosted.org/fedora-websites/ticket/45

[edit] Security Advisories

In this section, we cover Security Advisories from fedora-package-announce from the past week.

http://lists.fedoraproject.org/pipermail/package-announce

Contributing Writer: Pascal Calarco

[edit] Fedora 15 Security Advisories

[edit] Fedora 14 Security Advisories

[edit] Fedora 13 Security Advisories

[edit] LATAM Fedora!

LATAM Fedora is a regular column of Spanish language contributions around open source software. It is our first expansion into incorporating foreign language content into FWN.

This week's contribution is from Guillermo Gómez, a second installment primer on Ruby. Enjoy!

[edit] Ruby Capítulo 2 : Una clase algo más completa

Siguiendo nuestra secuencia al estilo tutorial, en esta edición vamos a completar un poco más nuestras clases, introduciremos los conceptos de métodos y variables de clase.

Una variable de clase es una variable compartida de la clase misma. Sólo existe una copia de una variable de clase en particular para una clase dada. Los nombres de las variables de clase comienzan con @@ tal como en @@reproducciones.

1 class Cancion
2   @@reproducciones = 0
3 
4   def Cancion.reproducciones
5     @@reproducciones
6   end
7 
8   def reproducir
9     @@reproducciones =+ 1
10   end
11 end

A diferencia de las variables de instancia y variables globales, las variables de clase deben se inicializadas antes de poder ser utilizadas, usualmente se hace con una declaración simple en el cuerpo de la definición de la clase. En el código anterior igualmente se ha introducido el concepto de método de clase. Un método de clase es un método que no necesita que se instancie la clase para ser invocado, es decir, "son métodos propios de la clase y no de sus objetos".

Su utilidad es obvia en el ejemplo, se quiere saber cuántas reproducciones se han hecho en total en nuestro reproductor de música. Esta información no es específica a una canción en particular, es decir, no es sujeto de las instancias sino de la clase misma. La diferencia al momento de declarar el método de clase es que debe anteponer el nombre de la clase al método, tiene dos opciones, o usar explícitamente Cancion, o self. El uso de *self" da mayor flexibilidad ya que permite cambiar el nombre de la clase sin mayores traumas.

1 class Cancion
2   @@reproducciones = 0
3 
4   def self.reproducciones
5     @@reproducciones
6   end
7 
8   def reproducir
9     @@reproducciones =+ 1
10   end
11 end

[edit] Constantes vs variables

Las variables y constantes en Ruby mantienen referencias a objetos. Las variables no poseen un tipo intrínseco, a cambio el tipo es únicamente definido por los mensajes a los que responde el objeto referenciado.

Una constante en Ruby también es una referencia a un objeto. Las constantes son creadas cuando son asignadas por primera vez, a diferencia de otros lenguajes Ruby le permite alterar el valor de las constantes si bien ello provocará un mensaje de alerta. En general usted no debe alterar una constante en tiempo de ejecución y debería evitarlo a toda costa.

1 >> MI_CONSTANTE = 1
2 => 1
3 >> MI_CONSTANTE = 2
4 (irb):23: warning: already initialized constant MI_CONSTANTE
5 => 2

Note como las constantes pueden declararse dentro de la definición de clase lo que nos lleva a la definición de constante de clase y a la noción de espacios de nombres por la forma en que nos referimos a dichas constantes.

1 class Cancion 
2   VERSION="1.0" 
3 end

1 >> Cancion::VERSION
2 => "1.0" 
3 >> VERSION
4 => "1.8.7" 

Note que VERSION no referencia ni colisiona con Cancion::VERSION.

[edit] El poder de herencia

Tal vez el santo grial de la programación es el principio DRY, "Don Repeat Yourself". Una forma de evitar repetirse, es escribir código reusable, cada vez que estamos escribiendo nuevo código y tenemos esa sensación de deja-vu de que ya esto lo hicimos una vez en el pasado, es porque no estamos reusando nuestro código de forma inteligente. En POO la herencia es una excelente forma de mantener el código reusable sin mayores repeticiones.

La herencia le permite crear clases que sean refinamientos o especializaciones de otra clase. Por ejemplo, y siguiendo el ejemplo de Cancion en nuestro reproductor de música ahora a alguien se le ocurrió que sería interesante que se incluyera el soporte para canciones de tipo Karaoke. La única diferencia con las otras canciones es que las canciones Karaoke tienen asociadas la letra de la canción en conjunto con infomación de sincronización para reproducir las letras del Karaoke en nuestro flamante reproductor ahora con una gran pantalla de video.

1 class Karaoke < Cancion
2   def initialize(nombre, artista, duracion, letra)
3     super(nombre, artista, duracion)
4     @letra = letra
5   end
6 end

El "< Cancion" en la definición de la clase le indica a Ruby que Karaoke es un subclase de Cancion, o en dirección opuesta, Cancion es la superclase de Karaoke. De esta forma la clase hija hereda todos los métodos y declaraciones de variables de su padre. Al invocar un método sobre un objeto o clase, Ruby defiere su ubicación hasta el momento de ejecución, en dicho momento Ruby primero mira en la clase para determinar si existe el método invocado, si no es así, intenta en el padre, y así atravesando todos los ancestros de la clase hasta ubicar el método invocado. Si se acaban los ancestros donde buscar, Ruby ejecuta una acción especial que puede ser interceptada si se desea Object#method_missing, si no, produce un error.

Cada clase especializada maneja sus detalles, para el resto se utiliza super, es decir, el método del padre o de su ancestro. De esta forma, por ejemplo, en nuestra definición de Karaoke#initialize dejamos que la inicialización de todo lo común a Cancion ocurra igual que antes por medio de la llamada a super con los respectivos parámetros necesarios, luego inicializamos los datos específicos a nuetras clase Karaoke.

[edit] Espacios de nombres

En la medida que escriba programas Ruby cada vez más grandes, usted naturalmente se encontrará con código reusable, librerías de rutinas relacionadas entre sí por ejemplo. Usted deseará separar dicho código en distintos archivos separados de tal forma que el contenido pueda ser reusado entre diferentes programas Ruby. Frecuentemente este código será organizado en clases.

Otras veces ello simplemente no es conveniente o no aplica, son un grupo de métodos que desea reusar, usted puede simplemente colocarlos en un archivo y cargar dicho archivo en su programa con load o require. Esto funciona pero tiene un problema, digamos que se crea una librería para cocinar con los métodos calentar , mezclar, amasar en un archivo cocina.rb y otra librería para atletas con los métodos calentar, correr, descansar en el archivo atleta.rb. Si carga ambos archivos uno después del otro, simplemente el método calentar colisiona y sólo el más recientemente cargado tendrá la definicón actual del método, el otro simplemente será olvidado, en resumen la colisión en los nombres es el problema.

La respuesta es el mecanismo de modulos. Los modulos definen un espacio de nombres en donde sus métodos y constantes pueden aplicar sin tener que preocuparse en colisionar con otros métodos y constantes:

 1 module Cocina
 2   ESCUELA="Latinoamericana" 
 3   def Cocina.calentar(x)
 4    # Se espera que x sea un valor númerico para representar temperatura en ºC
 5    # ..
 6   end
 7 ...
 8 end
 9 
10 module Atleta
11   ESCUELA="Simón Bolívar" 
12   def Atleta.calentar(t)
13     # Se espera que t sea un valor numérico que represente tiempo en segundos
14     # ..
15   end
16 end

1 >> Cocina::ESCUELA
2 => "Latinoamericana" 
3 >> Atleta::ESCUELA
4 => "Simon Bolivar" 
5 >> include Atleta
6 => Object
7 >> Atleta.calentar(1000)
8 calentando 1000 segundos
9 => nil
10 >> include Cocina
11 => Object
12 >> Cocina.calentar(10)
13 => 10

Ahora entonces tiene mucho menos probabilidades de provocar colisiones, note que debe cargar el código, y luego include para usar las funcionalidades del módulo.

[edit] Herencia múltiples vs Mixins

Algunos lenguajes orientados a objetos, tales como C++, soportan herencia múltiple en donde una clase puede tener más de una superclase heredando funcionalidad de cada una de ellas. Si bien potente, esta técnica puede ser peligrosa ya que la jerarquía puede tener ambigüedades. Otros lenguajes como java y C# soportan sólo herencia simple. Si bien más limpia y simple, la herencia simple también tiene sus desventajas, en la realidad los objetos heredan atributos de múltiples fuentes en el mundo real.

Ruby ofrece una alternativa interesante y poderosa que le ofrece la simplicidad de la herencia simple y el poder la herencia múltiple. Una clase Ruby tiene una única clase padre, en consecuencia Ruby es un lenguaje con herencia simple, sin embargo, las clases Ruby pueden incluir la funcionalidad de cualquier cantidad de mixins (un mixin es una especie de definición parcial de clase). Nuevamente dejemos que Ruby hable, creemos nuestro archivo con la definición de módulo y un par de clases tontas que lo usen como mixin:

[edit] mixin_module.rb

 1 module Debug
 2   def quien_soy?
 3     "#{self.class.name} (\##{self.objet_id}): #{self.to_s}" 
 4   end
 5 end
 6 
 7 class Cocina
 8   include Debug
 9   def estilo
10     puts "Italiana" 
11   end
12 end
13 
14 class Nevera
15   include Debug
16   def capacidad
17     puts "150 pies cúbicos" 
18   end
19 end

Si ahora cargamos dichas definiciones de módulo y clases en irb, podemos evidenciar y experimentar con el uso de los mixins (note que le voy a pasar la forma de hacerlo):

1 $ irb 
2 >> load 'mixin_module.rb'
3 => true
4 >> nevera = Nevera.new
5 => #<Nevera:0xb7587b38>
6 >> cocina = Cocina.new
7 => #<Cocina:0xb7585c5c>
8 >> nevera.quien_soy?
9 => "Nevera (#-609469028): #<Nevera:0xb7587b38>" 
10 >> cocina.quien_soy?
11 => "Cocina (#-609472978): #<Cocina:0xb7585c5c>" 

Bien, es todo por hoy, nos recontraremos en un tercer capítulo dedicado a métodos en una próxima edición de esta serie dedicada a aprender Ruby.

Este artículo se mantiene en línea en gomix.fedora-ve.org para posibles mejoras y erratas.

Guillermo Gómez