 |
Quiero recomendarles este sitio que encontré donde pueden aprender desde programación hasta vida profesional. Esta en castellano y esta muy bueno.
No tiene cursos avanzados solo básicos pero para empezar esta bien, sin más dejo link:
viernes, 14 de agosto de 2020
opensource.microsoft.com
Sin más dejo link: https://opensource.microsoft.com/
miércoles, 12 de agosto de 2020
Trait Objects para hacer Dynamic Dispatch en Rust
Seguimos con rust y el polimorfismo.
Como sabemos el Dynamic Dispatch significa que el compilador llama código que es determinado en tiempo de ejecución.
Cuando usamos objetos de trait, Rust debe usar Dynamic Dispatch. El compilador no conoce todos los tipos que podrían usarse con el código que usa objetos de trait, por lo que no sabe qué método implementado en qué tipo llamar. En cambio, en tiempo de ejecución, Rust usa los punteros dentro del objeto de trait para saber a qué método llamar. Hay un costo de tiempo de ejecución cuando ocurre esta búsqueda que no ocurre con el envío estático. El envío dinámico también evita que el compilador elija insertar el código de un método, lo que a su vez evita algunas optimizaciones. Sin embargo, obtuvimos una flexibilidad adicional propia del polimorfismo.
Algunas reglas complejas gobiernan todas las propiedades que hacen que un objeto de trait sea seguro, pero solo dos reglas son relevantes. Un trait es seguro para objetos si todos los métodos definidos en el trait tienen las siguientes propiedades:
- El tipo de retorno no es Self.
- No hay parámetros de tipo genérico.
La palabra clave Self es un alias para el tipo en el que estamos implementando los métodos. Los objetos de trait deben ser seguros para objetos porque una vez que has usado un objeto de rasgo, Rust ya no sabe el tipo concreto que está implementando ese rasgo. Si un método de rasgo devuelve el tipo Self concreto, pero un objeto rasgo olvida el tipo exacto que es Self, no hay forma de que el método pueda usar el tipo concreto original. Lo mismo ocurre con los parámetros de tipo genérico que se completan con parámetros de tipo concreto cuando se utiliza el rasgo: los tipos concretos pasan a formar parte del tipo que implementa el rasgo. Cuando el tipo se olvida mediante el uso de un objeto de rasgo, no hay forma de saber con qué tipos completar los parámetros de tipo genérico.
Un ejemplo de un trait cuyos métodos no son seguros para objetos es el trait Clonar de la biblioteca estándar. La firma para el método de clonación en el rasgo Clonar se ve así:
pub trait Clone {
fn clone(&self) -> Self;
}
El tipo String implementa el rasgo Clone, y cuando llamamos al método clone en una instancia de String, obtenemos una instancia de String. De manera similar, si llamamos a clonar en una instancia de Vec <T>, obtenemos una instancia de Vec <T>. La firma del clon necesita saber qué tipo sustituirá a Self, porque ese es el tipo de retorno.
El compilador le indicará cuando esté intentando hacer algo que viole las reglas de seguridad de los objetos con respecto a los objetos característicos. Por ejemplo, digamos que intentamos implementar la estructura Screen en el Listado 17-4 para contener los tipos que implementan el rasgo Clonar en lugar del rasgo Dibujar, así:
pub struct Screen {
pub components: Vec<Box<dyn Clone>>,
}
Obtendríamos este error:
$ cargo build Compiling gui v0.1.0 (file:///projects/gui) error[E0038]: the trait `std::clone::Clone` cannot be made into an object --> src/lib.rs:2:5 | 2 | pub components: Vec<Box<dyn Clone>>, | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::clone::Clone` cannot be made into an object | = note: the trait cannot require that `Self : Sized` error: aborting due to previous error For more information about this error, try `rustc --explain E0038`. error: could not compile `gui`. To learn more, run the command again with --verbose.
Este error significa que no puede usar este trait de esta manera. Si está interesado en obtener más detalles sobre la seguridad de los objetos, consulte Rust RFC 255.
Dejo link: https://doc.rust-lang.org/book/ch17-02-trait-objects.html
Scala 3, indentación en vez de llaves ???
- Primero, algunos programas mal sangrados van a estar marcados con un error de tipo advertencias.
- En segundo lugar, algunas apariciones de llaves {...} se hacen opcionales. Generalmente, la regla es que agregar un par de llaves opcionales no cambiará el significado de un programa bien sangrado.
Esta característica seguro los hace pensar en python, pero les recuerdo que en haskell tambien la identación es importante. Y scala, tiene más influencia de haskell que de python.
El compilador impone dos reglas para programas bien sangrados, marcando las violaciones como advertencias.
1.En una región delimitada por llaves, no se permite que ninguna instrucción comience a la izquierda de la primera instrucción después de la llave de apertura que comienza una nueva línea.
Esta regla es útil para encontrar llaves de cierre faltantes. Previene errores como:
if (x < 0) {
println(1)
println(2)
println("done") // error: indented too far to the left
2.Si la sangría significativa está desactivada (es decir, en el modo Scala-2 o en -noindent) y estamos al comienzo de una subparte con sangría de una expresión, y la parte con sangría termina en una nueva línea, la siguiente instrucción debe comenzar en una ancho de sangría menor que la subparte. Esto evita errores en los que se olvidó una llave de apertura, como:
if (x < 0)
println(1)
println(2) // error: missing `{
Estas reglas aún dejan un gran margen de maniobra sobre cómo se deben sangrar los programas. Por ejemplo, no imponen ninguna restricción sobre la sangría dentro de las expresiones, ni requieren que todas las declaraciones de un bloque de sangría se alineen exactamente.
Las reglas generalmente son útiles para identificar la causa raíz de los errores relacionados con la falta de llaves de apertura o cierre. Estos errores suelen ser bastante difíciles de diagnosticar, en particular en programas grandes.
Además, el compilador insertará tokens <indent> o <outdent> en ciertos saltos de línea. Gramaticalmente, los pares de tokens <indent> y <outdent> tienen el mismo efecto que los pares de llaves {y}.
Con estas nuevas reglas, las siguientes construcciones son todas válidas:
trait A:
def f: Int
class C(x: Int) extends A:
def f = x
object O:
def f = 3
enum Color:
case Red, Green, Blue
type T = A:
def f: Int
given [T](using Ord[T]) as Ord[List[T]]:
def compare(x: List[T], y: List[T]) = ???
extension (xs: List[Int])
def second: Int = xs.tail.head
new A:
def f = 3
package p:
def a = 1
package q:
def b = 2
Ojo que agregá los :
En fin, me parece un gran cambio y va a generar 2 formas de escribir y no sé si es la mejor idea, ya que un junior no va saber cuando escribir de que forma.
sábado, 8 de agosto de 2020
Rust by Example
 |
En la docu oficial de Rust hay un apartado Rust by example, que esta muy bueno. Dada que la docu es muy extensa este apartado viene bien para aterrizar algunos conceptos programando.
Sin más, dejo link: https://doc.rust-lang.org/stable/rust-by-example/
Polimorfismo con traits en Rust
Siguiendo con Rust y su implementación a conceptos de orientación a objetos, veamos como implementa polimorfismo sin el concepto de herencia tradicional, sino con traits.
La documentación oficial de Rust explica el polimorfismo en Rust con un ejemplo. Crea una herramienta de interfaz gráfica de usuario (GUI) de ejemplo que recorre una lista de elementos, llamando a un método de dibujo. Este metodo puede dibujar diferentes tipos como Button o TextField.
No implementaremos una biblioteca GUI completa para este ejemplo, pero mostraremos cómo encajarían las piezas. En el momento de escribir la biblioteca, no podemos conocer ni definir todos los tipos que otros programadores podrían querer crear. Pero sabemos que la interfaz gráfica de usuario necesita realizar un seguimiento de muchos valores de diferentes tipos, y necesita llamar a un método de dibujo en cada uno de estos valores con tipos diferentes. No necesita saber exactamente qué sucederá cuando llamemos al método de dibujo, solo que el valor tendrá ese método disponible para que lo llamemos.
Para hacer esto en un lenguaje con herencia, podríamos definir una clase llamada Componente que tenga un método llamado dibujar. Las otras clases, como Button, Image y SelectBox, heredarían de Component y, por lo tanto, heredarían el método de dibujo. Cada uno podría redefinir el método de dibujo para definir su comportamiento personalizado, y la ventana podría tratar todos los tipos como si fueran instancias de componentes y llamar a dibujar sobre ellos. Pero debido a que Rust no tiene herencia, necesitamos otra forma de estructurar la biblioteca de interfaz gráfica.
Para implementar el comportamiento que queremos que tenga la interfaz gráfica de usuario, definiremos un traits llamado Dibujar que tendrá un método llamado dibujar:
pub trait Draw {
fn draw(&self);
}
Ahora definimos la ventana que tiene que ser capaz de dibujar diferentes tipos de componentes. Para eso la ventana va tener un vector de componentes. Y definimos un componente como una caja o Box que contiene un tipo dinámico que implementa el trait Draw :
pub struct Screen {
pub components: Vec<Box<dyn Draw>>,
}
Recordemos que en Rust la definición de un "objeto" esta dividida en sus datos y sus métodos. Ahora definamos los métodos:
impl Screen {
pub fn run(&self) {
for component in self.components.iter() {
component.draw();
}
}
}
Alguien atento, podria decir porque no utilizamos genericos con ventana de este modo :
pub struct Screen<T: Draw> {
pub components: Vec<T>,
}
impl<T> Screen<T>
where
T: Draw,
{
pub fn run(&self) {
for component in self.components.iter() {
component.draw();
}
}
}
Pero el problema aquí es que no se va a poder utilizar Screen con diferentes componentes. Si tipamos a Screen con Button por ejemplo, solo va poder tener Buttons y no es lo que queremos. Hago esta aclaración porque con este contraejemplo se ve la función de la caja o Box, que es permitirnos diferentes componentes que implementan Draw.
Ahora agregaremos algunos tipos que implementan Draw:
pub struct Button {
pub width: u32,
pub height: u32,
pub label: String,
}
impl Draw for Button {
fn draw(&self) {
// code to actually draw a button
}
}
//------------------------------
struct SelectBox {
width: u32,
height: u32,
options: Vec<String>,
}
impl Draw for SelectBox {
fn draw(&self) {
// code to actually draw a select box
}
}
Y por último ver la magia en acción:
use gui::{Button, Screen};
fn main() {
let screen = Screen {
components: vec![
Box::new(SelectBox {
width: 75,
height: 10,
options: vec![
String::from("Yes"),
String::from("Maybe"),
String::from("No"),
],
}),
Box::new(Button {
width: 50,
height: 10,
label: String::from("OK"),
}),
],
};
screen.run();
}
Como vemos llamamos a run de screen que llamará a draw.
Al especificar Box <dyn Draw> como el tipo de valores en el vector de componentes, hemos definido que Screen pueda aceptar diferentes tipos en dibujar pero todos deben implementar Draw sino tirra error en tiempo de compilación:
use gui::Screen;
fn main() {
let screen = Screen {
components: vec![Box::new(String::from("Hi"))],
};
screen.run();
}
Esto no compila porque String no es un Draw :
$ cargo run
Compiling gui v0.1.0 (file:///projects/gui)
error[E0277]: the trait bound `std::string::String: gui::Draw` is not satisfied
--> src/main.rs:5:26
|
5 | components: vec![Box::new(String::from("Hi"))],
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `gui::Draw` is not implemented for `std::string::String`
|
= note: required for the cast to the object type `dyn gui::Draw`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0277`.
error: could not compile `gui`.
To learn more, run the command again with --verbose.
Dejo link:
https://doc.rust-lang.org/book/ch17-02-trait-objects.html
Programación funcional, pros y contras
Lei un articulo y me gusto mucho, por lo tanto les dejo un resumen, al final esta el articulo original :
Entonces, ¿qué es la programación funcional, por qué hay tanto auge y por qué vale la pena considerar aprenderla? Vamos a resolverlo.
El mundo de JavaScript está hirviendo. Hace unos años, solo unos pocos desarrolladores entendían la programación funcional, pero en los últimos tres años, casi todas las bases de código de grandes aplicaciones han estado utilizando activamente ideas tomadas del mundo de la programación funcional. Y por una buena razón: la programación funcional le permite escribir código más conciso y predecible, y es más fácil de probar (aunque aprender desde cero no es fácil).
Las principales características distintivas del desarrollo de software con FP:
- funciones puras;
- evitar el estado compartido, datos mutables y efectos secundarios;
- La prevalencia de un enfoque declarativo más que imperativo.
La programación funcional se basa inherentemente en los principios fundamentales y definitorios enumerados anteriormente. Y para comenzar a comprenderlos, primero debe cambiar al modo "académico" y cómo debe estudiar las definiciones de términos que lo seguirán implacablemente en FP: funciones puras, composición de funciones, evitar el estado compartido, etc. Esto es más como volver a la escuela. a una lección de matemáticas, pero después de eso verás tanto la funcionalidad como la programación de una manera completamente diferente.
Profundicemos un poco más en los términos de FP y, al menos superficialmente, comprendamos lo que significan.
Las funciones puras son funciones deterministas sin efectos secundarios. Una función determinista significa que para el mismo conjunto de valores de entrada, devuelve el mismo resultado. Para FP, las propiedades de tales funciones son muy importantes: por ejemplo, las funciones puras tienen transparencia referencial: puede reemplazar una llamada de función con su valor final sin cambiar el valor del programa.
La composición de funciones se refiere al proceso de combinar dos o más funciones para crear una nueva función o realizar cálculos.
El principal problema con los estados compartidos es que para comprender los efectos de una función, debe conocer el historial completo de cada variable compartida que utiliza la función. Por lo tanto, la programación funcional evita estados compartidos, confiando en cambio en estructuras de datos inmutables y computación sin procesar para extraer nuevos datos de los existentes. Otro matiz que surge cuando se trabaja con estados compartidos es que cambiar el orden de las llamadas a funciones puede provocar una avalancha de errores. En consecuencia, al evitar estados compartidos, también evita este problema.
Subyacente a toda la programación funcional está la inmutabilidad (inmutabilidad). Y aquí es importante no confundirse const con la inmutabilidad. const crea un enlace de nombre variable que no se puede reasignar después de la creación, pero no crea objetos inmutables. No podrá cambiar el objeto al que pertenece el enlace, pero aún puede cambiar las propiedades de este objeto const, por lo tanto , los enlaces creados no son inmutables. Los objetos inmutables no se pueden cambiar en absoluto. Esto se logra mediante la congelación profunda de las variables.
Los efectos secundarios significan que, además de devolver un valor, la función también interactúa con el estado mutable externo. ¿Por qué FP los evita? Porque de esta manera los efectos del programa son mucho más fáciles de entender y probar. Haskell, por ejemplo, usa mónadas para aislar los efectos secundarios de las funciones puras.
El punto es que el enfoque imperativo funciona según el principio de control de flujo y responde a la pregunta "cómo hacerlo". El enfoque declarativo describe el flujo de datos y responde a la pregunta "qué hacer". Además, el código imperativo a menudo se basa en instrucciones (operadores), mientras que el código declarativo se basa más en las expresiones.
Entonces, descubrimos qué es la programación funcional y qué necesita saber al respecto. Y, antes de pasar a discutir sus ventajas, propongo pasar primero por las desventajas, más precisamente, para comprender la esencia del estereotipo "la programación funcional no es natural".
A juzgar por lo que escribí anteriormente, los seguidores de la programación funcional ya deberían haber surgido entre los lectores. Sin embargo, a pesar de la gran cantidad de artículos laudatorios, no hay menos artículos titulados "La programación funcional es extraña y no tiene futuro" (por ejemplo). ¿Esto significa que estoy equivocado? No. ¿Hay alguna razón para pensar que la FA es extraña? Por supuesto.
Permíteme darte una cita de Internet que refleja completamente la actitud de muchos desarrolladores hacia FP:
"Escribir código funcional es como escribir al revés y la mayoría de las veces es como resolver un rompecabezas en lugar de explicar el proceso a una computadora".
De hecho, esta es una actitud bastante subjetiva hacia la FP para aquellos que no quieren dedicar suficiente tiempo para comprender los matices de la programación funcional y simplemente intentarlo. Pero, como prometí, veamos las desventajas de FP y luego veamos las ventajas.
Primero, no existe un vocabulario eficiente desordenado y configurado para lenguajes funcionales. Los diccionarios puramente funcionales son más lentos que las tablas hash, y esto puede ser crítico para algunas aplicaciones. En segundo lugar, no hay tablas hash débiles puramente funcionales, aunque para la mayoría de los desarrolladores esta falla puede pasar desapercibida.
Además, FP no es adecuado para algoritmos en gráficos (debido a su funcionamiento lento) y, en general, para aquellas soluciones que se han basado en programación imperativa durante décadas.
De acuerdo, el último punto suena más como una queja: no podemos culpar a FP por lo que no estaba destinado. Por lo tanto, propongo recurrir a lo agradable, es decir, a las ventajas de FP y su uso en proyectos reales por parte de compañías internacionales reales.
Uno de los beneficios más obvios de la programación funcional son las abstracciones de alto nivel que ocultan muchos de los detalles de las operaciones de rutina, como la iteración. Debido a esto, el código es más corto y, como resultado, garantiza menos errores que se pueden cometer.
Además, el FP contiene menos primitivas de lenguaje. Las clases bien conocidas en FP simplemente no se usan: en lugar de crear una descripción única de un objeto con operaciones en forma de métodos, la programación funcional utiliza varias primitivas básicas del lenguaje que están bien optimizadas internamente.
Además, la programación funcional permite al desarrollador acercar el lenguaje al problema, en lugar de viceversa, todo a expensas de las estructuras flexibles y la flexibilidad del lenguaje. Además, FP ofrece a los desarrolladores nuevas herramientas para resolver problemas complejos que los programadores de POO a menudo descuidan.
De hecho, es demasiado largo para enumerar todas las ventajas de la programación funcional; realmente hay muchas de ellas. Puedo decir esto: trabajar con lenguajes funcionales proporciona una escritura de código precisa y rápida, facilita las pruebas y la depuración, los programas son de nivel superior y las firmas de funciones son más informativas.
Por supuesto, uno no puede negar las ventajas de POO, pero vale la pena recordar que los lenguajes funcionales están a la par con muchos otros en términos de conveniencia y merecen su atención.
En el mundo de TI, nada sucede. Una cosa se aferra a la otra, y ahora todas las tendencias más actuales están interconectadas.
Si recordamos las tendencias más sensacionales de 2016-2017, estas, por supuesto, serán AI, IoT, Big Data y Blockchain. Están en boca de todos, todos conocen su potencial y sus características clave. Y son algunas de estas tendencias las que han catalizado la creciente popularidad de la programación funcional entre los desarrolladores.
Actualmente, el problema del procesamiento paralelo y el trabajo con grandes flujos de datos es muy grave, en otras palabras, trabajar con Big Data. Y, paralelizando el procesamiento de estos datos, puede obtener el resultado deseado en una fracción de segundo, lo cual es muy crítico en el mundo real. Además, no se olvide de la informática descentralizada (distribuida): blockchains y otras, que, en esencia, son un mecanismo bastante complejo. Y para tales cálculos, el código funcional es más adecuado debido a todos los principios de la programación funcional (como las funciones puras, por ejemplo). El uso de todas las técnicas básicas de FP facilita la ejecución y el mantenimiento de código paralelo.
Además, si la programación funcional anterior se usaba solo para resolver problemas específicos, ahora incluso se aplica a proyectos clásicos.
Como probablemente ya haya entendido, no debe temer la programación funcional. Un poco de diligencia y curiosidad, y ahora has dominado la FP. Aquí hay algunos consejos para aquellos que han decidido probarse en un nuevo género y aprender algo radicalmente nuevo:
- Relájate :) Al principio será muy complicado, teniendo en cuenta que tendrás que dejar atrás lo que sabes y aprender nuevos enfoques y principios. Y eso esta bien. Piense en la primera vez que aprendió a codificar. Nada malo sucederá.
- Comience con micro tareas para tenerlo en sus manos.
- Comience a aprender Haskell y luego pase a Scala (o F #) para comenzar a comprender los principios de programación funcional (y al mismo tiempo comenzar a pensar más "funcional").
Dada la prevalencia de la programación funcional, puede estar seguro de su futuro profesional (con la debida diligencia), ya que seguramente puede usar sus habilidades recién adquiridas. ¡No tengas miedo de intentarlo!
jueves, 6 de agosto de 2020
Scala.js
Scala.js es básicamente el typescript de scala y provee muchas cosas más que typescript :
Y otro tema interesante es que tiene integración con los framework javascript más utilizados como react o Vue.js
No soy muy fanatico del Frontend, pero esta sin duda es una gran opción.
sábado, 1 de agosto de 2020
Se creo la Micronaut Foundation
Object Computing, Inc. (OCI) ha anunciado la creación de la Fundación Micronaut, una fundación sin fines de lucro establecida para promover la innovación y la adopción de Micronaut. La fundación "supervisará la hoja de ruta y el desarrollo del software, las mejores prácticas y procesos, el control de repositorio, la documentación y el soporte, y la recaudación de fondos relacionados con el framework de código abierto". La fundación recibirá fondos iniciales de $ 2M de OCI para desarrollo.
Anteriormente conocido como Project Particle, Micronaut es un framework completo basado en JVM para crear aplicaciones basadas en microservicios, nativas de la nube y sin servidor que se pueden escribir en Java, Groovy y Kotlin. Micronaut se introdujo en marzo de 2018 y posteriormente fue de código abierto en mayo de 2018.
Piratería y desarrollo: discursos, historias y política de un amor negado
Cuando vi este video pensé en situaciones que suceden en el mundo del software y en general en todas las industrias.
Contador de palabras ...
String[] palabras = getPalabras()
int contador = 0
for (String p : palabras) contador++
return contador
o los que piensan de forma más funcional :
String[] palabras = getPalabras()
int contador = palabras.fold(0, (c, a) => c++)
Pero la idea de esta actividad es hacerla en paralelo, por ejemplo utilizar 3 hilos. y contar el 1/3 en un hilo, y así...
Empiezo mi tarea haciendo un github : https://github.com/emanuelpeg/contador
Por algo se empieza, quien me ayuda??
Conectarse a un servidor FTP con Python
El constructor de FTP, recibe como parámetros al host, usuario, clave. A la vez, esta librería nos provee un monton de funcionalidad, veamos un ejemplo :
from ftplib import FTP
ftp = FTP()
ftp.connect('0.0.0.1', 21, -999)
ftp.login('user', 'pass')
print ftp.getwelcome()
ftp.mkd('nuevo-dir')
ftp.cwd('nuevo-dir')
print ftp.pwd()
ftp.storlines('STOR example.txt', open('ftp_examples.py', 'r'))
ftp.rename('example.txt', 'example.py')
ftp.dir()
archivo = ftp.retrlines('RETR example.py')
print archivo
ftp.close()
Y listo!!
miércoles, 29 de julio de 2020
The RedMonk Programming Language Rankings: June 2020
Pero bueno, no quería dejar pasar este gráfico sobre los lenguajes más utilizados. Al parecer Python toma la delantera pero javasctipt sigue adelante.
En fin, hay varios rankings y algunos dan a ganador a Java o a Python o Javascript. Que se yo? Den su opinión!!
martes, 28 de julio de 2020
Machine Learning at Enterprise Scale
viernes, 24 de julio de 2020
Enviando e-mails desde Python
sudo apt-get install sendmail
Para enviar e-mails desde Python, éste nos provee smtplib, otro módulo de la librería estándar de Python, quien nos permitirá enviar mensajes de correo electrónico, incluso, en formato HTML.
Solo necesitaremos:
- Crear un objeto smtplib.SMTP el cuál recibirá como parámetro de su método constructor, el host (localhost)
- Crear un mensaje de correo: Enviar el mensaje mediante una llamada al método sendmail del objeto SMTP.
Veamos el código :
import smtplib
remitente = "ElmachodelPirulin <emanuel@blog.com.ar>"
destinatario = "Ella <ella@gmail.com>"
asunto = "E-mail enviado desde Python"
mensaje = """Hola!<br/> <br/>
Este es un <b>e-mail</b> enviando desde <b>Python</b>
"""
email = """From: %s
To: %s
MIME-Version: 1.0
Content-type: text/html
Subject: %s
%s""" % (remitente, destinatario, asunto, mensaje)
try:
smtp = smtplib.SMTP('localhost')
smtp.sendmail(remitente, destinatario, email)
print "Correo enviado"
except:
print """Error: el mensaje no pudo enviarse.
Compruebe que sendmail se encuentra instalado en su sistema"""
Así de simple, enviamos un e-mail con Python!
Suscribirse a:
Entradas (Atom)
