Como programador te habrá pasado que al escribir en un formulario la letra á, esta queda guardada en MySQL como á .
Seguramente tomaste los siguientes recaudos:
- Las páginas html generadas por PHP tienen el encabezado
< meta equiv="content-type" content="text/html;charset=utf-8" >
- La tabla en MySQL tiene el campo
character_set_client = utf8
Con todo, la letra á sigue guardándose como á, aunque en la página generada se vea bien.
La solución a este odioso problema es muy simple, como indica http://www.papascott.de/archives/2007/05/05/corrupted-utf-8-characters-with-php-and-mysql/ :
- Inmediatamente después de cualquier conexión hecha con "mysql_connect", hay que agregar la instrucción
mysql_query("SET NAMES 'utf8'")
Ahora sí, los datos serán guardados en MySQL en correcto utf-8 .
jueves, 4 de agosto de 2011
sábado, 18 de junio de 2011
País altamente industrializado o solo agroindustrial
Leemos en el libro "El mito agrario" (Federico Bernal, 2010, colección Claves para todos, editorial Capital Intelectual www.capin.com.ar), sobre la cuestión de tener un país manufacturero de productos de alto valor agregado o solo materia prima, que ya en 1876 Vicente Fidel López decía
"(...) llamo la atención de los señores Diputados sobre la situación difícil en que se enc
uentra nuestro país (...) ¿y por qué? Y esto es así porque no sabe manufacturar las materias primas que produce (...) nosotros tenemos nuestro desierto: pero nuestro desierto se agota tanto más cuanto que está habitado por gente que no trabaja, y yo le diré al Sr. Ministro por qué es que no trabajan; es porque cuando se tiene una extensión de veinte leguas que da una excelente renta al capitalista se la da a condición de tener la tierra y el país despoblado (...) es necesario que vayamos poblando nuestros inmensos campos y radicaremos menos (...) en la teoría de Azara que quería siempre el desierto con cuarenta mil habitantes y cuarenta millones de vacas. La República Argentina cuando tenga cuarenta millones de habitantes (que algún día no lejano los llegará a tener) no ha de poder tener desiertos para doscientos cuarenta millones de ganados, y aquel número de habitantes no lo podremos tener sino a condición de que seamos ricos por el trabajo. ¿Y sobre qué vamos a trabajar? Sobre nuestras materias primas precisamente". (Cámara de Diputados de la Nación, 18 de agosto de 1876).
Curiosamente, para el año 2010 Argentina tenía ya 40 millones de habitantes y a las vacas las tienen los mismos dueños de hace un siglo.
"(...) llamo la atención de los señores Diputados sobre la situación difícil en que se enc
uentra nuestro país (...) ¿y por qué? Y esto es así porque no sabe manufacturar las materias primas que produce (...) nosotros tenemos nuestro desierto: pero nuestro desierto se agota tanto más cuanto que está habitado por gente que no trabaja, y yo le diré al Sr. Ministro por qué es que no trabajan; es porque cuando se tiene una extensión de veinte leguas que da una excelente renta al capitalista se la da a condición de tener la tierra y el país despoblado (...) es necesario que vayamos poblando nuestros inmensos campos y radicaremos menos (...) en la teoría de Azara que quería siempre el desierto con cuarenta mil habitantes y cuarenta millones de vacas. La República Argentina cuando tenga cuarenta millones de habitantes (que algún día no lejano los llegará a tener) no ha de poder tener desiertos para doscientos cuarenta millones de ganados, y aquel número de habitantes no lo podremos tener sino a condición de que seamos ricos por el trabajo. ¿Y sobre qué vamos a trabajar? Sobre nuestras materias primas precisamente". (Cámara de Diputados de la Nación, 18 de agosto de 1876).Curiosamente, para el año 2010 Argentina tenía ya 40 millones de habitantes y a las vacas las tienen los mismos dueños de hace un siglo.
jueves, 26 de mayo de 2011
¿Cómo elegir una lámpara de bajo consumo?
En Argentina se prohibió mediante Ley 26.473 la importación y comercialización de lámparas incandescentes. La ley entrará en plena vigencia el 31 de mayo de 2011.
Pero, ¿cómo elegir una lámpara de bajo consumo, habiendo tantos modelos, potencias y marcas?. Comprar una lámpara incandescente resultaba fácil porque son muy baratas, y elegir mal no implica un gasto que lesione el presupuesto doméstico; si la lámpara incandescente falla, se compra otra, y listo.
En el Instituto Nacional de Tecnología Industrial de Argentina, INTI ( http://www.inti.gob.ar ), se probaron lámparas de bajo consumo de distintas potencias y marcas. Los resultados pueden consultarse en http://www.inti.gob.ar/sabercomo/sc45/inti3.php . El informe completo puede bajarse de http://www.inti.gob.ar/ambiente/inf-tec.pdf .
Pero, ¿cómo elegir una lámpara de bajo consumo, habiendo tantos modelos, potencias y marcas?. Comprar una lámpara incandescente resultaba fácil porque son muy baratas, y elegir mal no implica un gasto que lesione el presupuesto doméstico; si la lámpara incandescente falla, se compra otra, y listo.
En el Instituto Nacional de Tecnología Industrial de Argentina, INTI ( http://www.inti.gob.ar ), se probaron lámparas de bajo consumo de distintas potencias y marcas. Los resultados pueden consultarse en http://www.inti.gob.ar/sabercomo/sc45/inti3.php . El informe completo puede bajarse de http://www.inti.gob.ar/ambiente/inf-tec.pdf .
martes, 20 de octubre de 2009
La estafa del voto electrónico
Según leemos aquí (http://www.dailykos.com/storyonly/2009/10/20/795343/-Sequoia-Voting-Systems-hacks-self-in-foot), una empresa que fabrica máquinas para voto electrónico dejó expuesto código SQL que manipula los datos de las elecciones.
Por si esto no se entiende en un primer momento, lo que se descubrió es que el código SQL almacenado en las máquinas de voto electrónico no solo almacena y cuenta los votos, si no que además realiza tareas que están siendo investigadas. Según las leyes de EEUU, estas tareas adicionales estan prohibidas, pero la ciudadanía no tiene forma de auditar las máquinas, ya que los mecanismos de funcionamiento son considerados secreto industrial.
El voto electrónico es la última moda en métodos de estafa a los pueblos. Entre otros puntos, el voto electrónico:
- Impide un recuento de los votos
- Registra la identidad del votante y su elección
- Traslada la tarea del conteo de votos a una empresa privada, cuando esta tarea tiene que estar en manos de los ciudadanos que conforman las mesas electorales
Para informarse más acerca del voto electrónico, visite http://www.electronic-vote.org/
Por si esto no se entiende en un primer momento, lo que se descubrió es que el código SQL almacenado en las máquinas de voto electrónico no solo almacena y cuenta los votos, si no que además realiza tareas que están siendo investigadas. Según las leyes de EEUU, estas tareas adicionales estan prohibidas, pero la ciudadanía no tiene forma de auditar las máquinas, ya que los mecanismos de funcionamiento son considerados secreto industrial.
El voto electrónico es la última moda en métodos de estafa a los pueblos. Entre otros puntos, el voto electrónico:
- Impide un recuento de los votos
- Registra la identidad del votante y su elección
- Traslada la tarea del conteo de votos a una empresa privada, cuando esta tarea tiene que estar en manos de los ciudadanos que conforman las mesas electorales
Para informarse más acerca del voto electrónico, visite http://www.electronic-vote.org/
domingo, 28 de diciembre de 2008
Trabajando con microcontroladores de Microchip en GNU/Linux y Windows
Microcontroladores PIC de Microchip
Debido a su precio y disponibilidad, los microcontroladores PIC de Microchip son muy populares. Con estos microcontroladores es posible atender todas las aplicaciones de electrónica para consumo imaginables, desde equipos para al automotor, automatizaciones industriales, juguetes, instrumentos para laboratorio y hasta equipos usados en medicina.
Herramientas multiplataforma para la programación de PICs
Para programar un PIC necesitamos de 2 herramientas de software y una herramienta de hardware:
Lenguajes ensambladores
El mejor lenguaje ensamblador para PIC, desde el punto de vista técnico y por su licencia de uso, es el ensamblador gpasm, incluído en la suite GPUTILS. Esta suite de software contiene todo lo necesario para escribir software en lenguaje ensamblador. Funciona en Unix (incluído GNU/Linux), Mac OS X y Windows.
Lenguajes de alto nivel
Un lenguaje de alto nivel muy bueno, ya que permite extender las funcionalidades del lenguaje a nuevos modelos de PIC, es el compilador Jal v2. Entre otras cosas, este lenguaje permite realizar operaciones aritméticas de 16 bits, algo engorroso de lograr en lenguaje ensamblador. Está basado en Pascal, pero en su estructura pueden reconocerse elementos de C y de Basic. Cuenta con versiones para GNU/Linux (x86) y Windows.
Software programador
Por su licencia y su disponibilidad en GNU/Linux y Windows, el mejor software para programación es el pp06. Funciona con la mayoría de los circuitos programadores.
Hardware de programación, circuito programador, o simplemente programador de PIC
El circuito más común es el de David Tait. Debido a su simpleza, y a que es posible adaptar el programador a los nuevos modelos de PIC, en internet se encuentran muchas variantes de este programador. Recomiendo esta versión.
Simuladores de PIC
Si bien Microchip provee de una herramienta gratuita para la simulación de PICs, el MPLAB, este no funciona en GNU/Linux. Por esto, el mejor simulador de PICs multiplataforma es el gpsim.
Otros recursos
Para explorar otras herramientas de software y hardware, visitar GNUPIC.
Debido a su precio y disponibilidad, los microcontroladores PIC de Microchip son muy populares. Con estos microcontroladores es posible atender todas las aplicaciones de electrónica para consumo imaginables, desde equipos para al automotor, automatizaciones industriales, juguetes, instrumentos para laboratorio y hasta equipos usados en medicina.
Herramientas multiplataforma para la programación de PICs
Para programar un PIC necesitamos de 2 herramientas de software y una herramienta de hardware:
- Un lenguaje ensamblador, que convertirá nuestro código fuente de ensamblador a código máquina de PIC. Además del lenguaje ensamblador, existen lenguajes de alto nivel basados en C, Basic y Pascal que permiten reducir el tiempo de desarrollo de software para PICs.
- Un software programador, o software para transferir el programa en código máquina desde la PC hasta el PIC
- Un programador de PIC. Este es el hardware encargado de vincular la PC con el PIC al momento de transferir el programa desde la PC al PIC. Algunos modelos de programadores permiten monitorear el estado del PIC en cada instrucción.
Lenguajes ensambladores
El mejor lenguaje ensamblador para PIC, desde el punto de vista técnico y por su licencia de uso, es el ensamblador gpasm, incluído en la suite GPUTILS. Esta suite de software contiene todo lo necesario para escribir software en lenguaje ensamblador. Funciona en Unix (incluído GNU/Linux), Mac OS X y Windows.
Lenguajes de alto nivel
Un lenguaje de alto nivel muy bueno, ya que permite extender las funcionalidades del lenguaje a nuevos modelos de PIC, es el compilador Jal v2. Entre otras cosas, este lenguaje permite realizar operaciones aritméticas de 16 bits, algo engorroso de lograr en lenguaje ensamblador. Está basado en Pascal, pero en su estructura pueden reconocerse elementos de C y de Basic. Cuenta con versiones para GNU/Linux (x86) y Windows.
Software programador
Por su licencia y su disponibilidad en GNU/Linux y Windows, el mejor software para programación es el pp06. Funciona con la mayoría de los circuitos programadores.
Hardware de programación, circuito programador, o simplemente programador de PIC
El circuito más común es el de David Tait. Debido a su simpleza, y a que es posible adaptar el programador a los nuevos modelos de PIC, en internet se encuentran muchas variantes de este programador. Recomiendo esta versión.
Simuladores de PIC
Si bien Microchip provee de una herramienta gratuita para la simulación de PICs, el MPLAB, este no funciona en GNU/Linux. Por esto, el mejor simulador de PICs multiplataforma es el gpsim.
Otros recursos
Para explorar otras herramientas de software y hardware, visitar GNUPIC.
martes, 16 de diciembre de 2008
Particiones swap en sistemas virtualizados
El tamaño de la partición "swap"
Una de las preguntas más comunes en los foros sobre GNU/linux es ¿qué tamaño tiene que tener la partición swap?. No hay una respuesta clara a esa pregunta, porque el tamaño de la partición swap depende exclusivamente del uso que se le dé a la computadora.
Como regla general, para una computadora que se vá a usar en un oficina, 512Mb de RAM real y una partición swap de 1Gb cubren todas las necesidades corrientes. Si se tiene 1Gb de RAM, 512 de swap harán el trabajo. Si se tiene más de 1Gb de RAM es poco probable que se utilice el área swap.
Programas que realizan cálculos usarán más RAM según el volúmen de datos y cálculos que se realicen. En este caso, conviene consultar exhaustivamente los manuales del programa para estimar la cantidad de RAM a usar, ya que sí es posible estimar previamente el volúmen de datos involucrados en el proceso.
Cada vez es más común encontrar ambientes en donde la mayoría de los sistemas operativos que componen la infraestructura informática no corren sobre hardware real, sino sobre hardware virtualizado. Esto complica las decisiones acerca del tamaño de las particiones swap.
En sistemas virtualizados, tenemos que el sistema HOST (aquél que alberga el software de virtualización) posee una RAM real y un área de intercambio. Los sistemas operativos GUEST (aquellos que están siendo virtualizados en el sistema HOST) cuentan con una RAM "real" (virtualizada por el HOST) y una partición swap (también virtualizada por el HOST).
El tamaño de la partición swap en sistemas virtualizados
Para hechar luz sobre criterios de decisión acerca del tamaño del área de intercambio (swap) de los sistemas virtualizados, realicé el siguiente experimento:
Sistema HOST:
Debian GNU/linux 4.0 i386, sobre P3 733Mhz, 390Mb de RAM, 1Gb swap
Sistema GUEST:
Debian GNU/linux 4.0 i386, 640Mb de RAM, 96Mb swap
Software de virtualización: VirtualBox 2.0.2
Como se vé, el sistema GUEST tiene asignada más RAM real de la que el sistema HOST posee. Esto provocó que el sistema HOST utilice totalmente la memoria real y parte de la memoria de intercambio.
Hasta aquí la respuesta del sistema no trae sorpresas. Lo que sí resultó inesperado (al menos para mí) es que una vez que apagué el sistema GUEST, y con el servidor de virtualización aún corriendo, no se liberó la memoria que se había solicitado al sistema HOST. Pensándolo bien, esto no es tan inesperado. Tiene sentido, ya que los sistemas GUEST pueden volver a encenderse en cualquier momento de manera no determinista (mediante scripts activados remotamente, por ejemplo).
Si hubiera empezado a correr otras aplicaciones en el sistema HOST sin apagar el servidor de virtualización, el rendimiento de la máquina real hubiera sufrido de esta falta de memoria real, ya que los procesos de intercambio se hubieran incrementado en frecuencia y en tamaño de memoria intercambiada. Otros sistemas virtualizados en la misma máquina hubieran sufrido severamente esta falta de memoria real en el sistema HOST.
Conclusiones
Si se ván a virtualizar varios sistemas GUEST simultáneamente, conviene delegar a cada sistema virtualizado la administración de su propio espacio de intercambio. Esto es, debe asignársele a cada sistema GUEST una swap de tamaño suficiente e independiente. Si bien esto provoca lesiones en el rendimiento, ya que los accesos a disco para leer y escribir del swap es más lento que leer de la RAM real, el sistema HOST no sacrificará su propia swap para mantener la demanda de los sistemas GUEST.
Para optimizar aún más el rendimiento de las máquinas virtuales (y en consecuencia el rendimiento de la máquina real), convendría además asignar un disco virtual de tamaño fijo exclusivamente para swap en cada máquina virtual. Si se usara un disco virtual de tamaño dinámico (método corriente) para que el sistema GUEST aloje sus particiones de sistema y swap, el rendimiento sería mucho menor, ya que se usarían muchos recurso del HOST solo en redimensionar dinámicamente la partición del GUEST. Yendo más lejos en las optimizaciones, podrían usarse discos reales exclusivamente para uso como área de intercambio de los sistemas GUEST.
Como se dijo antes, solo el uso indica cuáles son los tamaños ideales para el área de intercambio.
Una de las preguntas más comunes en los foros sobre GNU/linux es ¿qué tamaño tiene que tener la partición swap?. No hay una respuesta clara a esa pregunta, porque el tamaño de la partición swap depende exclusivamente del uso que se le dé a la computadora.
Como regla general, para una computadora que se vá a usar en un oficina, 512Mb de RAM real y una partición swap de 1Gb cubren todas las necesidades corrientes. Si se tiene 1Gb de RAM, 512 de swap harán el trabajo. Si se tiene más de 1Gb de RAM es poco probable que se utilice el área swap.
Programas que realizan cálculos usarán más RAM según el volúmen de datos y cálculos que se realicen. En este caso, conviene consultar exhaustivamente los manuales del programa para estimar la cantidad de RAM a usar, ya que sí es posible estimar previamente el volúmen de datos involucrados en el proceso.
Cada vez es más común encontrar ambientes en donde la mayoría de los sistemas operativos que componen la infraestructura informática no corren sobre hardware real, sino sobre hardware virtualizado. Esto complica las decisiones acerca del tamaño de las particiones swap.
En sistemas virtualizados, tenemos que el sistema HOST (aquél que alberga el software de virtualización) posee una RAM real y un área de intercambio. Los sistemas operativos GUEST (aquellos que están siendo virtualizados en el sistema HOST) cuentan con una RAM "real" (virtualizada por el HOST) y una partición swap (también virtualizada por el HOST).
El tamaño de la partición swap en sistemas virtualizados
Para hechar luz sobre criterios de decisión acerca del tamaño del área de intercambio (swap) de los sistemas virtualizados, realicé el siguiente experimento:
Sistema HOST:
Debian GNU/linux 4.0 i386, sobre P3 733Mhz, 390Mb de RAM, 1Gb swap
Sistema GUEST:
Debian GNU/linux 4.0 i386, 640Mb de RAM, 96Mb swap
Software de virtualización: VirtualBox 2.0.2
Como se vé, el sistema GUEST tiene asignada más RAM real de la que el sistema HOST posee. Esto provocó que el sistema HOST utilice totalmente la memoria real y parte de la memoria de intercambio.
Hasta aquí la respuesta del sistema no trae sorpresas. Lo que sí resultó inesperado (al menos para mí) es que una vez que apagué el sistema GUEST, y con el servidor de virtualización aún corriendo, no se liberó la memoria que se había solicitado al sistema HOST. Pensándolo bien, esto no es tan inesperado. Tiene sentido, ya que los sistemas GUEST pueden volver a encenderse en cualquier momento de manera no determinista (mediante scripts activados remotamente, por ejemplo).
Si hubiera empezado a correr otras aplicaciones en el sistema HOST sin apagar el servidor de virtualización, el rendimiento de la máquina real hubiera sufrido de esta falta de memoria real, ya que los procesos de intercambio se hubieran incrementado en frecuencia y en tamaño de memoria intercambiada. Otros sistemas virtualizados en la misma máquina hubieran sufrido severamente esta falta de memoria real en el sistema HOST.
Conclusiones
Si se ván a virtualizar varios sistemas GUEST simultáneamente, conviene delegar a cada sistema virtualizado la administración de su propio espacio de intercambio. Esto es, debe asignársele a cada sistema GUEST una swap de tamaño suficiente e independiente. Si bien esto provoca lesiones en el rendimiento, ya que los accesos a disco para leer y escribir del swap es más lento que leer de la RAM real, el sistema HOST no sacrificará su propia swap para mantener la demanda de los sistemas GUEST.
Para optimizar aún más el rendimiento de las máquinas virtuales (y en consecuencia el rendimiento de la máquina real), convendría además asignar un disco virtual de tamaño fijo exclusivamente para swap en cada máquina virtual. Si se usara un disco virtual de tamaño dinámico (método corriente) para que el sistema GUEST aloje sus particiones de sistema y swap, el rendimiento sería mucho menor, ya que se usarían muchos recurso del HOST solo en redimensionar dinámicamente la partición del GUEST. Yendo más lejos en las optimizaciones, podrían usarse discos reales exclusivamente para uso como área de intercambio de los sistemas GUEST.
Como se dijo antes, solo el uso indica cuáles son los tamaños ideales para el área de intercambio.
domingo, 2 de noviembre de 2008
Desarrollo de software multiplataforma II
(Esta es una continuación de la discusión iniciada en la entrada "Desarrollo de software multiplataforma")
Las técnicas de programación multiplataforma se conocen desde hace 40 años. ¿Por qué la industria de la computación dejó de lado todo ese conocimiento, y los programadores redescubren hoy la programación multiplataforma como una novedad?
La IBM PC trajo consigo a las computadoras genéricas, clones, o IBM PC compatibles. Los programadores de aplicaciones para el IBM PC y para el sistema operativo DOS no necesitaban conocer nada acerca de los fundamentos teóricos y los elementos esenciales de los sistemas operativos multitarea/multiusuario desarrollados desde los 60, tales como
Ya que no hacía falta concentrarse en todos estos conceptos y problemas de diseño asociados a los sistemas multitarea/multiusuario, los compiladores para DOS proliferaron, y por lo tanto la industria de software para DOS floreció a un ritmo nunca antes visto, alejando irreversiblemente a los programadores de la Ciencias de la Computación .
Conclusiones
A mi entender, estas son las razones por las que los programadores se alejaron de la programación multiplataforma y de las bases científicas/matemáticas de la computación.
La arquitectura IBM PC+DOS logró retroceder el desarrollo de la computación en 20 años, volviéndola más primitiva de lo que los teóricos de los primeros sistemas operativos multitarea/multiusuario podrían tolerar.
Hoy en día, con computadores que contienen múltiples CPUs, y dado que la construcción de clústeres y sistemas distribuídos es moneda corriente, el ingeniero de software no puede ignorar ni eludir los conceptos y arquitecturas desarrolladas en los sistemas operativos tipo Unix.
Las técnicas de programación multiplataforma se conocen desde hace 40 años. ¿Por qué la industria de la computación dejó de lado todo ese conocimiento, y los programadores redescubren hoy la programación multiplataforma como una novedad?
La IBM PC trajo consigo a las computadoras genéricas, clones, o IBM PC compatibles. Los programadores de aplicaciones para el IBM PC y para el sistema operativo DOS no necesitaban conocer nada acerca de los fundamentos teóricos y los elementos esenciales de los sistemas operativos multitarea/multiusuario desarrollados desde los 60, tales como
- Procesos, bifurcaciones, procesos hijos, hilos. El DOS no provee funcionalidad para ninguno de estos conceptos de software, fundamentales para la multitarea
- Pipes, filtros. DOS posee mecanismos rudimentarios de pipes y filtros
- IPC o Intercomunicación entre procesos. Como DOS no estaba diseñado para multitarea, la intercomunicación entre procesos es un concepto sin sentido
- FIlesystem o sistema de archivo. En DOS la organización de archivos está programada estáticamente en el sistema operativo y no se puede cambiar. En sistemas tipo Unix el gestor de sistemas de archivos es un simple driver que se puede cambiar dinámicamente, incluso en funcionamiento
- Lock o cierres de exclusión mutua. Este es un concepto MUY asociado a sistemas multitarea. Permiten bloquear el uso de algún recurso de la computadora por parte de un proceso, para que otros procesos no usen en ese momento el mismo recurso. En DOS no existe este concepto, aunque los programadores encontraron formas rebuscadas de simular locks, como por ejemplo en los programas antivirus "residentes" que podian acceder a los discos al mismo tiempo que los programas (si bien los antivirus son un ejemplo de programas funcionando en multitarea, a esta funcionalidad no la provee el sistema operativo, ya que depende de un método propio del DOS, que es la utilización de programas residentes. Los virus para DOS usaron este mecanismo antes que los antivirus).
Ya que no hacía falta concentrarse en todos estos conceptos y problemas de diseño asociados a los sistemas multitarea/multiusuario, los compiladores para DOS proliferaron, y por lo tanto la industria de software para DOS floreció a un ritmo nunca antes visto, alejando irreversiblemente a los programadores de la Ciencias de la Computación .
Conclusiones
A mi entender, estas son las razones por las que los programadores se alejaron de la programación multiplataforma y de las bases científicas/matemáticas de la computación.
La arquitectura IBM PC+DOS logró retroceder el desarrollo de la computación en 20 años, volviéndola más primitiva de lo que los teóricos de los primeros sistemas operativos multitarea/multiusuario podrían tolerar.
Hoy en día, con computadores que contienen múltiples CPUs, y dado que la construcción de clústeres y sistemas distribuídos es moneda corriente, el ingeniero de software no puede ignorar ni eludir los conceptos y arquitecturas desarrolladas en los sistemas operativos tipo Unix.
Suscribirse a:
Entradas (Atom)