Vaya, en una aventura en PHP me encontré con este error el cual se vuelve un poco fastidioso y a veces difícil de entender porque puede producirse de una forma rara. Aca un ejemplo:
Si creamos un array de la siguiente forma:
$my_table[0] = "A value";
$my_table[1] = "Other value";
El código funcionará pero no siempre lo cual es algo raro, pero así es. La forma correcta será declarando la variable de forma correcta antes de ingresarle los valores:
$my_table = array();
$my_table[0] = "A value";
$my_table[1] = "Other value";
Esto solo conduce a ser más estricto al declarar ese tipo de variables.
martes, 30 de agosto de 2011
jueves, 28 de julio de 2011
iDNX RS
Deje pendiente por ahora la programación del administrador de contenidos educativos para hacer una versión en php del iDNX RS la cual traerá muchas ventajas y probablemente alguno que otro cambio en los procesos del mismo (por compatibilidad con la nueva plataforma).
La principal ventaja es que será un servicio online por lo que cualquiera usuario desde cualquier computadora o dispositivo móvil podrá acceder, consultar y demás, la aplicación sin necesidad de tener un programa cliente y un servidor.
Por ahora estoy en el diseño del layout en css 1 y 2 (el 3 por incompatiblidad con ciertos navegadores lo dejaré fuera), en la configuración de algunas rutinas jquery para brindar una interfaz lo más parecida a una aplicación desktop, y en la estructura de la base de datos y del root folder. Las partes que irán en ajax pondré al final ya que sólo las usaré para optimizar las rutinas y reducir la carga del servidor.
Si alguien con conocimientos en php, css, ajax, jquery ó javascript quiere contribuir, contácteme por msn.
La principal ventaja es que será un servicio online por lo que cualquiera usuario desde cualquier computadora o dispositivo móvil podrá acceder, consultar y demás, la aplicación sin necesidad de tener un programa cliente y un servidor.
Por ahora estoy en el diseño del layout en css 1 y 2 (el 3 por incompatiblidad con ciertos navegadores lo dejaré fuera), en la configuración de algunas rutinas jquery para brindar una interfaz lo más parecida a una aplicación desktop, y en la estructura de la base de datos y del root folder. Las partes que irán en ajax pondré al final ya que sólo las usaré para optimizar las rutinas y reducir la carga del servidor.
Si alguien con conocimientos en php, css, ajax, jquery ó javascript quiere contribuir, contácteme por msn.
lunes, 11 de julio de 2011
Un buen programa y su base de datos
Refiriéndonos a programas de administración de contenido, talleres, ptv, etc., se debe ser conciente que una de las características con la cual deben contar dichos programas es con la capacidad de ser adaptable a las necesidades de cada quien.
Me es muy frecuente ver códigos o programas limitados en ese rugro ya que no se pueden agregar datos, categorías, etc. a placer. Así que uno de los consejos para programar sería definitivamente el uso de algún motor de bases de datos (sqlite, access, etc.) siempre estructurándola de una forma eficiente.
Es precisamente en las bases de datos donde reside la adaptabilidad, parte de la velocidad de procesamiento (otra parte en las consultas sql correctas) entre otros beneficios. La clave esta en una buena estructura en la interrelación y dependencia entre tablas.
Uno de los errores más comunes es creer que con un par de tablas en la base datos bastaría para poder almacenar todo lo que queremos, pero es precisamente ahí donde se pueden generar sobresaturaciones que resulten en la ralentización del retorno de datos. Ya con una buena estrutura solo resta obtener los datos mediante consultas sql un tanto complejas que permitan disminuir el número de éstas.
Si se usan bases de datos online es importante preservar la seguridad de los datos como nombre de usuario, password, etc. ya que nunca se esta exento de un ataque a la misma.
Un ejemplo claro de adaptibilidad de contenidos, permisos y otras funciones compartidas, son los sistemas de foros como vbulletin y phpbb, por mencionar algunos, junto con sus deficiencias mencionadas en publicaciones anteriores.
Por ahora estoy desarrollando una aplicación, que luego trasladare a php, para la administración de contenidos educativos así que "stay tuned".
Me es muy frecuente ver códigos o programas limitados en ese rugro ya que no se pueden agregar datos, categorías, etc. a placer. Así que uno de los consejos para programar sería definitivamente el uso de algún motor de bases de datos (sqlite, access, etc.) siempre estructurándola de una forma eficiente.
Es precisamente en las bases de datos donde reside la adaptabilidad, parte de la velocidad de procesamiento (otra parte en las consultas sql correctas) entre otros beneficios. La clave esta en una buena estructura en la interrelación y dependencia entre tablas.
Uno de los errores más comunes es creer que con un par de tablas en la base datos bastaría para poder almacenar todo lo que queremos, pero es precisamente ahí donde se pueden generar sobresaturaciones que resulten en la ralentización del retorno de datos. Ya con una buena estrutura solo resta obtener los datos mediante consultas sql un tanto complejas que permitan disminuir el número de éstas.
Si se usan bases de datos online es importante preservar la seguridad de los datos como nombre de usuario, password, etc. ya que nunca se esta exento de un ataque a la misma.
Un ejemplo claro de adaptibilidad de contenidos, permisos y otras funciones compartidas, son los sistemas de foros como vbulletin y phpbb, por mencionar algunos, junto con sus deficiencias mencionadas en publicaciones anteriores.
Por ahora estoy desarrollando una aplicación, que luego trasladare a php, para la administración de contenidos educativos así que "stay tuned".
martes, 11 de enero de 2011
Lo malo de un foro
Creo que el sistema de foros, ya sean phpbb o cualquier otro, pueden no ser siempre la mejor opción en el renglón del orden de la información.
En los foros abiertos (con los cuales ya no estoy tan de acuerdo) de cualquier temática es muy común encontrarse con los siguientes casos:
1.- Muchos noobs (novatos) en el tema tratado en los foros suelen crear posts (temas) con títulos no muy explicativos como "AYUDAAA" ó "URGENTEEE".
2.- La mayoria de ese tipo de posts contienen dudas anteriormente respondidas en otros posts.
3.- La respuesta clásica por parte de otros usuarios, en ese tipo de circunstancias, suele ser "Busca en el foro" ó "Lee bien la sección de tutoriales".
4.- El post que contiene la respuesta que ocupa el noob tiene fecha muy antigua y no tiene un título descriptivo que ayude a su fácil localización mediante la búsqueda.
Si bien es cierto que en la mayoría de las veces la culpa suele ser del noob (por flojera de no querer buscar ni leer) también debemos de aceptar que parte de esa culpa corresponde al sistema de foros o a la inexperiencia en la configuración del mismo por parte de los administradores (y también a la flojera de responder algo que ya ha sido respondido varias veces).
A falta de un sistema alterno, los administradores o moderadores deben localizar las preguntas más frecuentes y hacer una sección propiamente denominada como tal (o FAQ por sus siglas en inglés). A su vez, siendo los expertos en los temas del foro, deben renombrar los títulos de los posts.
Si la intención de un foro es enseñar o dar soporte, o ambas, se debe entonces crear un temario (índice) donde se enumeren los posts denominados TUTORIALES y donde cada tema lleve el orden correcto, y una descripción del mismo, para que el noob (o cualquier usuario) sepa en que nivel va y hasta donde quiere llegar. Cada tutorial debe mencionar además los posts que deben leer antes de continuar con el proceso descrito en el mismo.
La sección de TUTORIALES no debe estar abierta a respuestas (comentarios) por parte de los usuarios ya que sólo generan páginas y más páginas de comentarios que no llevan a nada. Una mejor opción es actualizar el tutorial en base a las verdaderas discusiones del tema llevadas a cabo una sección de SOPORTE.
Ahora, ya tendríamos 2 secciones las cuales se deben interrelacionar. La sección FAQ debe ligarse a la sección de TUTORIALES.
Los keywords (palabras llave) en ambas secciones son muy importantes para realizar búsquedas más exactas. El uso de un campo en nuestra base de datos que lleve el conteo de las visitas a ciertos posts también ayuda a la hora de mostrar los resultados de las búsquedas (al estilo google).
La constante actualización de los posts ya creados en la sección de FAQ también es importante. El sistema de notificaciones de actualización de facebook es un excelente ejemplo de como organizar la información, ya que permite a los usuarios consultar la nueva información en posts de fechas pasadas sin tener que alterar el orden en que los posts se muestran al ingresar al foro correspondiente (eso es algo malo en los foros cuando estan ordenados por fecha).
El uso de un GLOSARIO también es indispensable, porque quienes no dominan el tema encontrarán términos que no comprendan en los posts.
Todo esto lleva a la simplificación del proceso de enseñanza mediante foros, así como a la reducción de posts innecesarios por parte de noobs (y a una mejor base de datos). Aunque como menciona el dicho: "Haz algo a prueba de idiotas y encontrarás a un idiota mejor" LOL.
Bien se puede crear un sistema nuevo que lleve a una organización como la presentada en líneas anteriores, pero también es cierto que podemos configurar nuestros foros de dicha forma. Sólo bastan 4 secciones para hacerlo: FAQ, TUTORIALES, SOPORTE y GLOSARIO.
Una sección siempre controversial (por políticas de hosting, país, etc.) es el de las descargas. Para ello creo que siempre será mejor un FTP privado. El comprimir los archivos con contraseña y cuyos nombres de archivo no sean TAN descriptivos ayudarán a la privacidad del mismo.
Pero esto es sólo una opinión personal.
En los foros abiertos (con los cuales ya no estoy tan de acuerdo) de cualquier temática es muy común encontrarse con los siguientes casos:
1.- Muchos noobs (novatos) en el tema tratado en los foros suelen crear posts (temas) con títulos no muy explicativos como "AYUDAAA" ó "URGENTEEE".
2.- La mayoria de ese tipo de posts contienen dudas anteriormente respondidas en otros posts.
3.- La respuesta clásica por parte de otros usuarios, en ese tipo de circunstancias, suele ser "Busca en el foro" ó "Lee bien la sección de tutoriales".
4.- El post que contiene la respuesta que ocupa el noob tiene fecha muy antigua y no tiene un título descriptivo que ayude a su fácil localización mediante la búsqueda.
Si bien es cierto que en la mayoría de las veces la culpa suele ser del noob (por flojera de no querer buscar ni leer) también debemos de aceptar que parte de esa culpa corresponde al sistema de foros o a la inexperiencia en la configuración del mismo por parte de los administradores (y también a la flojera de responder algo que ya ha sido respondido varias veces).
A falta de un sistema alterno, los administradores o moderadores deben localizar las preguntas más frecuentes y hacer una sección propiamente denominada como tal (o FAQ por sus siglas en inglés). A su vez, siendo los expertos en los temas del foro, deben renombrar los títulos de los posts.
Si la intención de un foro es enseñar o dar soporte, o ambas, se debe entonces crear un temario (índice) donde se enumeren los posts denominados TUTORIALES y donde cada tema lleve el orden correcto, y una descripción del mismo, para que el noob (o cualquier usuario) sepa en que nivel va y hasta donde quiere llegar. Cada tutorial debe mencionar además los posts que deben leer antes de continuar con el proceso descrito en el mismo.
La sección de TUTORIALES no debe estar abierta a respuestas (comentarios) por parte de los usuarios ya que sólo generan páginas y más páginas de comentarios que no llevan a nada. Una mejor opción es actualizar el tutorial en base a las verdaderas discusiones del tema llevadas a cabo una sección de SOPORTE.
Ahora, ya tendríamos 2 secciones las cuales se deben interrelacionar. La sección FAQ debe ligarse a la sección de TUTORIALES.
Los keywords (palabras llave) en ambas secciones son muy importantes para realizar búsquedas más exactas. El uso de un campo en nuestra base de datos que lleve el conteo de las visitas a ciertos posts también ayuda a la hora de mostrar los resultados de las búsquedas (al estilo google).
La constante actualización de los posts ya creados en la sección de FAQ también es importante. El sistema de notificaciones de actualización de facebook es un excelente ejemplo de como organizar la información, ya que permite a los usuarios consultar la nueva información en posts de fechas pasadas sin tener que alterar el orden en que los posts se muestran al ingresar al foro correspondiente (eso es algo malo en los foros cuando estan ordenados por fecha).
El uso de un GLOSARIO también es indispensable, porque quienes no dominan el tema encontrarán términos que no comprendan en los posts.
Todo esto lleva a la simplificación del proceso de enseñanza mediante foros, así como a la reducción de posts innecesarios por parte de noobs (y a una mejor base de datos). Aunque como menciona el dicho: "Haz algo a prueba de idiotas y encontrarás a un idiota mejor" LOL.
Bien se puede crear un sistema nuevo que lleve a una organización como la presentada en líneas anteriores, pero también es cierto que podemos configurar nuestros foros de dicha forma. Sólo bastan 4 secciones para hacerlo: FAQ, TUTORIALES, SOPORTE y GLOSARIO.
Una sección siempre controversial (por políticas de hosting, país, etc.) es el de las descargas. Para ello creo que siempre será mejor un FTP privado. El comprimir los archivos con contraseña y cuyos nombres de archivo no sean TAN descriptivos ayudarán a la privacidad del mismo.
Pero esto es sólo una opinión personal.
lunes, 10 de enero de 2011
Búsquedas concatenadas en SQLite3
La forma habitual de buscar 1 parámetro en más de 2 campos de una tabla sería por ejemplo:
[code]SELECT * FROM tabla WHERE campo1='parametro' OR campo2='parametro'[/code]
Pero hoy les muestro como hacer una búsqueda concatenada para un mismo parámetro.
Primero comenzaré recordando la forma de concatenar (unir) campos en una consulta. Para concatenar 2 o más campos deben usar este doble signo ||. Ejemplo:
[code]SELECT nombre||apellido FROM tabla[/code]
Esto nos arrojaría un resultado como RamónPérez (noten que no hay espacio entre el apellido y el nombre).
Así que para dejar el espacio entre ambos campos debemos concatenarlo (sin olvidar las tildes):
[code]SELECT nombre||' '||apellido FROM tabla[/code]
Estos nos arrojaría un resultado como Ramón Pérez (noten que el espacio ahora si aparece). Podemos poner lo que sea dentro de ' ' y crear concatenaciones mejores, como por ejemplo: ||'Nombre: '||nombre||' Apellido: '||apellido
Bueno, pues es similar para cuando queremos concatenar campos posterior a la cláusula WHERE en una consulta de selección. Ejemplo:
[code]SELECT * FROM tabla WHERE nombre||apellido='Alonso'[/code]
En esta consulta en lugar de hacer algo como "select * from tabla where nombre='alonso' or apellido='alonso'" estamos concatenando el campo de búsqueda (nombre||apellido). Esto nos ahorra líneas de código y ya en usos un poco más complejos podemos realizar consultas en campos multiples campos keywords con simples scripts.
Espero les agrade esa pequeña info de sqlite.
[code]SELECT * FROM tabla WHERE campo1='parametro' OR campo2='parametro'[/code]
Pero hoy les muestro como hacer una búsqueda concatenada para un mismo parámetro.
Primero comenzaré recordando la forma de concatenar (unir) campos en una consulta. Para concatenar 2 o más campos deben usar este doble signo ||. Ejemplo:
[code]SELECT nombre||apellido FROM tabla[/code]
Esto nos arrojaría un resultado como RamónPérez (noten que no hay espacio entre el apellido y el nombre).
Así que para dejar el espacio entre ambos campos debemos concatenarlo (sin olvidar las tildes):
[code]SELECT nombre||' '||apellido FROM tabla[/code]
Estos nos arrojaría un resultado como Ramón Pérez (noten que el espacio ahora si aparece). Podemos poner lo que sea dentro de ' ' y crear concatenaciones mejores, como por ejemplo: ||'Nombre: '||nombre||' Apellido: '||apellido
Bueno, pues es similar para cuando queremos concatenar campos posterior a la cláusula WHERE en una consulta de selección. Ejemplo:
[code]SELECT * FROM tabla WHERE nombre||apellido='Alonso'[/code]
En esta consulta en lugar de hacer algo como "select * from tabla where nombre='alonso' or apellido='alonso'" estamos concatenando el campo de búsqueda (nombre||apellido). Esto nos ahorra líneas de código y ya en usos un poco más complejos podemos realizar consultas en campos multiples campos keywords con simples scripts.
Espero les agrade esa pequeña info de sqlite.
Una buena estructura de base de datos
El tener una buena estructura en nuestra base de datos es imprescindible no sólo por orden, sino también para reducir el peso de la misma así como poder brindar mejores reportes (con más detalles autocalculables por ejemplo). Ah, y la rápidez con que se hagan las consultas también dependerá de ello.
Aunque el tener una sola tabla donde acumular ciertos registros que luego puedan ser agrupados para mostrar resumenes o concentrados de la misma puede llegar a ser tentador, no en todos los casos es viable.
Un ejemplo sería el sólo contar con una tabla para registros de facturas donde se ingresan todos los artículos de dicha factura y cuando se quiere ver en forma de concentrado (por folio) sólo se agrupasen los registros. El error en este tipo de tablas y usos es que pueden llegarse a repetir datos en ciertos campos de forma innecesaria (como el número de folio, nombre del cliente, RFC, etc.), provocando el incremento en el peso de nuestra base de datos.
Una solución a esto es contar con 2 tablas interrelacionadas donde la primera sólo sea un control del ID de la factura con detalles como folio, fecha, cliente, RFC, etc. Y la segunda tabla con los registros de los artículos y precios de los mismos.
De esta forma evitamos repetir los datos de RFC, cliente, fecha y otros, en el registro de cada artículo que constituye la factura. Esto sin mencionar que a veces se usa un campo para comentarios que suelen extenderse bastante.
Un consejo es que recuerden que múltiples tablas pueden accederse en una sola consulta mendiante el uso de left join, full join o consultas en formato ANSI. Por ello a veces es necesario manejar más de un índice único para cada registro en nuestras tablas.
Aunque el tener una sola tabla donde acumular ciertos registros que luego puedan ser agrupados para mostrar resumenes o concentrados de la misma puede llegar a ser tentador, no en todos los casos es viable.
Un ejemplo sería el sólo contar con una tabla para registros de facturas donde se ingresan todos los artículos de dicha factura y cuando se quiere ver en forma de concentrado (por folio) sólo se agrupasen los registros. El error en este tipo de tablas y usos es que pueden llegarse a repetir datos en ciertos campos de forma innecesaria (como el número de folio, nombre del cliente, RFC, etc.), provocando el incremento en el peso de nuestra base de datos.
Una solución a esto es contar con 2 tablas interrelacionadas donde la primera sólo sea un control del ID de la factura con detalles como folio, fecha, cliente, RFC, etc. Y la segunda tabla con los registros de los artículos y precios de los mismos.
De esta forma evitamos repetir los datos de RFC, cliente, fecha y otros, en el registro de cada artículo que constituye la factura. Esto sin mencionar que a veces se usa un campo para comentarios que suelen extenderse bastante.
Un consejo es que recuerden que múltiples tablas pueden accederse en una sola consulta mendiante el uso de left join, full join o consultas en formato ANSI. Por ello a veces es necesario manejar más de un índice único para cada registro en nuestras tablas.
martes, 3 de agosto de 2010
Un poco de la vida de un programador
A lo mejor nadie, o casi nadie, se pregunta como es la vida de un programador, un cracker o un hacker pero me permito abrirles un poco la perspectiva. En mi persona aplica lo de programador.
Comenzaré diciendoles que si programar se trata de una actividad secundaria (como es mi caso), es decir que no es de lo que vivimos, es muy seguro que las horas de descanso (dormir) sean realmente pocas. Esto porque aparte nuestras actividades cotidianas debemos darle un espacio y tiempo de concentración a lo que estamos programando y por ende suele ser toda la madrugada.
Es duro ciclarte a veces en una parte de lo que estas programando porque no funciona como debiera, pero en innumerables veces suele ser porque estamos agotados y no tenemos ya la claridad para resolverlo en ese momento. Irnos a descansar suele ser la solución pero a costa de un mal descanso, ya que en mi caso cierro los ojos y vuelvo a ver la pantalla de la computadora en mi mente y sigo trabajando en el código. Para cuando despierto solo hacen falta 5 minutos para resolver lo que unas horas antes parecía imposible. El precio...adios al descanso real ya que dormimos pensando en programación y luego de un par de horas despertamos igual (así es, casi no dormimos). Cuando existen algunos fines de semana y es tanta nuestra adicción a programar es que podemos quedarnos frente a la computadora por horas (lo más que me he quedado han sido 17 horas sin dormir) y a veces ni queremos comer con el fin de no distraernos y no perder lo que tenemos construido en nuestras mentes.
Otra parte desagradable es el no poder concentrarse en el código por factores externos como pueden ser que alguien tenga la música a alto volumen o que simplemente te hablen y te distraigan por unos segundos. Eso realmente es irritante ya que los demás no saben que en nuestras mentes tenemos que pensar e ir procesando el código que escribimos tal cual como lo haría la computadora y con un poco de distracción a veces perdemos el hilo (cuando estamos sobre todo más cansados). Esta es otra razón por la cual también prefiero programar de madrugada o con audifonos (con supresión de ruido) a todo lo que dan.
La parte buena es que conforme más aprendemos (sobre todo de errores) mejores cosas podemos lograr. También es excelente el sentimiento de satisfacción cuando ves que vuestro programa es tan útil que tienes seguidores que aportan grandes ideas para su desarrollo ya que te llevan a fronteras que jamás imaginaste.
Para el caso de un cracker en mi poca experiencia sólo les puedo decir que es un tanto más difícil en un principio ya que con el tiempo te acostumbras tanto al ASM que muchas veces preferirás ASM un decompilador mal logrado (como el rec22). Pero aun con eso sigue siendo complicado el hacer ingeniería inversa y sobre todo con factores como los anteriormente mencionados.
Cuando pasas demasiado tiempo aprendiendo el código en ASM de un X programa puedes llegar a entender como trabaja la mente de quien lo programó y aun mejor puedes llegar a hacer reingeniería como tus propios updates o mods con funciones totalmente nuevas o diferentes a lo que una aplicación original puede ofrecerte.
Bueno, suficiente de quejas...Ahora si seguiré viendo unos pendientes hehe.
Comenzaré diciendoles que si programar se trata de una actividad secundaria (como es mi caso), es decir que no es de lo que vivimos, es muy seguro que las horas de descanso (dormir) sean realmente pocas. Esto porque aparte nuestras actividades cotidianas debemos darle un espacio y tiempo de concentración a lo que estamos programando y por ende suele ser toda la madrugada.
Es duro ciclarte a veces en una parte de lo que estas programando porque no funciona como debiera, pero en innumerables veces suele ser porque estamos agotados y no tenemos ya la claridad para resolverlo en ese momento. Irnos a descansar suele ser la solución pero a costa de un mal descanso, ya que en mi caso cierro los ojos y vuelvo a ver la pantalla de la computadora en mi mente y sigo trabajando en el código. Para cuando despierto solo hacen falta 5 minutos para resolver lo que unas horas antes parecía imposible. El precio...adios al descanso real ya que dormimos pensando en programación y luego de un par de horas despertamos igual (así es, casi no dormimos). Cuando existen algunos fines de semana y es tanta nuestra adicción a programar es que podemos quedarnos frente a la computadora por horas (lo más que me he quedado han sido 17 horas sin dormir) y a veces ni queremos comer con el fin de no distraernos y no perder lo que tenemos construido en nuestras mentes.
Otra parte desagradable es el no poder concentrarse en el código por factores externos como pueden ser que alguien tenga la música a alto volumen o que simplemente te hablen y te distraigan por unos segundos. Eso realmente es irritante ya que los demás no saben que en nuestras mentes tenemos que pensar e ir procesando el código que escribimos tal cual como lo haría la computadora y con un poco de distracción a veces perdemos el hilo (cuando estamos sobre todo más cansados). Esta es otra razón por la cual también prefiero programar de madrugada o con audifonos (con supresión de ruido) a todo lo que dan.
La parte buena es que conforme más aprendemos (sobre todo de errores) mejores cosas podemos lograr. También es excelente el sentimiento de satisfacción cuando ves que vuestro programa es tan útil que tienes seguidores que aportan grandes ideas para su desarrollo ya que te llevan a fronteras que jamás imaginaste.
Para el caso de un cracker en mi poca experiencia sólo les puedo decir que es un tanto más difícil en un principio ya que con el tiempo te acostumbras tanto al ASM que muchas veces preferirás ASM un decompilador mal logrado (como el rec22). Pero aun con eso sigue siendo complicado el hacer ingeniería inversa y sobre todo con factores como los anteriormente mencionados.
Cuando pasas demasiado tiempo aprendiendo el código en ASM de un X programa puedes llegar a entender como trabaja la mente de quien lo programó y aun mejor puedes llegar a hacer reingeniería como tus propios updates o mods con funciones totalmente nuevas o diferentes a lo que una aplicación original puede ofrecerte.
Bueno, suficiente de quejas...Ahora si seguiré viendo unos pendientes hehe.
Suscribirse a:
Entradas (Atom)